SSH Interop, OpenSSH 1 <-> 2 <-> ssh.com
Mirrored from
* http://www.ticam.utexas.edu/adminworld/sshinterop.html (web-archive)
* http://www.cs.berkeley.edu/~dtliu/sshinterop.html (web-archive)
* http://www.hanwave.net/pn/modules.php?op=modload&name=News&file=article&sid=25
Getting OpenSSH to work with ssh.com and itself
Problem: The password-less public key authentication mechanisms of OpenSSH, protocol version 1, OpenSSH protocol version 2 and ssh.com's protocol 2 suite don't interoperate seamlessly.
Summary: In this article, I show how I got passwordless authentication amongst these three implementations. This is to be used as a reference for anybody who needs to set up their PKI accross different implementations.
Notes:
If you're like me and you need work on multiple machines, you might be interested in using public key authentication and passwordless login to save yourself the trouble of typing your password every time you log on to a machine. Unfortunately, there are two popular implementations of ssh (done by OpenSSH and ssh.com) and two protocols (version 1 and version 2) which are not transparently compatible with each other. I've recently had to go through the hassle of making three of the four above combinations work with each other and thought I would sum things up so that somebody else might save their time and sweat.
Here is a simplified version of the configuration that I was dealing with:
Figure 1: There are three computers, all running various versions/distributions of linux and ssh. The three implementations of ssh covered in this configuration network are {(OpenSSH, protocol 1), (OpenSSH, protocol 2), (ssh.com, protocol 2)}. I didn't have to deal with (ssh.com, protocol 1) or any other implementations so they are not covered here. If you have any information on how to get them to work (or just that it was trivial), send me an email and I will integrate your solutions to this document.
Since there are six ways to connect the three different ssh implementations, I will describe how I got each of the six permutations to work. To be clear, the two protocol versions SSH1 and SSH2 do not interoperate, but it is often the case that an SSH2 client or server can operate in SSH1 compatilibity mode, which means that it can talk to an SSH1 client/server. For the rest of this article, I will assume that your SSH2 peer is able to operate in SSH1-compatibility mode. To find out what protocol and implementation you are running on your system, invoke ssh -V. There are examples at the end.
The following are the six interconnects in figure 1. Click the link that represents your own client->server combination.
(openssh, protocol 1)->(ssh.com, protocol 2)
I apologize, but this two have eluded me. Thus far I've been able to live without them. The problem is that since one side of the connection uses the SSH1 protocol, SSH1 keys are needed on boths sides of the connection. None of the ssh utilities that I have allow the conversion of SSH1 keys and I haven't figured out how to do it manually. If you figure this out, please mail me and I'll post it up.
client$ ssh-keygen
Generating RSA keys: ...............oooooO...........................oooooO
Key generation complete.
Enter file in which to save the key (/home/dtliu/.ssh/identity):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/dtliu/.ssh/identity.
Your public key has been saved in /home/dtliu/.ssh/identity.pub.
The key fingerprint is:
1024 9f:0c:9c:d8:9c:3d:ef:a2:14:31:31:26:56:43:ed:f5 dtliu@client
Copy the public key from the client to the server to the server:
client$ scp ~/.ssh/identity.pub server:.ssh
dtliu@server's password:
identity.pub 100% |*****************************| 333 00:00 ETA
On the server, append the newly obtained key to the ~/.ssh/authorized_keys file, which stores SSH1 public keys in the OpenSSH implementation:
server$ cat ~/.ssh/identity.pub >> ~/.ssh/authorized_keys
Modify the permissions of the authorized_keys file. If this file is write-able by anybody other than the user, then server will deactivate PK authentication.
server$ chmod 600 ~/.ssh/authorized_keys
At the client, decrypt and register your key with the ssh-agent:
At the client, try and login to the server:
client$ ssh server
Last login: Sun Feb 17 03:25:21 2002 from client.cs.berkeley.edu
Password-less login
At this point, you'll probably want to set up passwordless login, which is done with the following commands:
Invoke ssh-agent and it's outputted shell commands:
client$ eval `ssh-agent`
Agent pid 12899
Decrypt and add your newly generated private key to ssh-agent's database:
client$ ssh-add ~/.ssh/identity
Need passphrase for identity
Enter passphrase for dtliu@client:
Identity added: identity (dtliu@client)
Note: If you are registering another private key, then substitute private key for ~/.ssh/identity:
client$ ssh-add
Now you should be able to do a password-less login to the server:
client$ ssh server
Last login: Sun Feb 17 02:23:27 2002 from client
No mail.
server$
As you will soon notice, this only gives you password-less login through this terminal. To achieve true one-time per system authentication, I would recommend using the Keychain utility. This involves downloading the keychain program and adding two lines to your ~/.bashrc or ~/.bash_profile (or ~/.cshrc) files. The utility then keeps you from entering your passphrase more than once.
On the client, generate a DSA key pair (default). In the ssh.com implementation, SSH2-related keys go in ~/.ssh2:
client$ ssh-keygen
Generating 1024-bit dsa key pair
4 .oOoo.oOo.oO
Key generated.
1024-bit dsa, dtliu@alfalfa.CS.Berkeley.EDU, Sun Feb 17 2002 03:36:40 -0800
Passphrase :
Again :
Private key saved to /automount/calaeno/home4/dtliu/.ssh2/id_dsa_1024_a
Public key saved to /automount/calaeno/home4/dtliu/.ssh2/id_dsa_1024_a.pub
Copy the newly generated public key to the server's ~/.ssh directory. Notice here that OpenSSH keeps all keys (SSH1 or SSH2) in the ~/.ssh directory:
client$ scp ~/.ssh2/id_dsa_1024_a.pub server:.ssh
On the server, append the newly acquired public key to the ~/.ssh/authorized_keys2 file. There are two things to notice here. First, we must import the key from the ssh.com public key format to the OpenSSH public key format. Not all versions of ssh-keygen allow you to do this conversion. This is done with the "-i -f " options. Secondly, OpenSSH keeps all SSH2 public keys in the authorized_keys2 file as opposed to the authorized_keys file. Starting with OpenSSH version 2.9, SSH2 keys can also go in the authorized_keys file:
server$ ssh-keygen -i -f id_dsa_1024_a.pub >> authorized_keys2
On the server, make sure that the private key is not write-able by 'group' or 'other':
server$ chmod 600 ~/.ssh/authorized_keys2
On the client, add the line "IdKey id_dsa_1024_a" to the ~/.ssh2/identification file. This tells the ssh client which files contain the private keys:
client$ echo "IdKey id_dsa_1024_a" >> ~/.ssh2/identification
On the client, decrypt and register your key with the ssh-agent
On the client, try a password-less login:
client$ ssh server
Authentication successful.
Last login: Sun Feb 17 03:43:06 2002 from client.cs.berkeley.edu
server$
a
On the client, make a DSA key pair:
client$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/dtliu/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/dtliu/.ssh/id_dsa.
Your public key has been saved in /home/dtliu/.ssh/id_dsa.pub.
The key fingerprint is:
08:72:39:e1:26:ae:22:f1:a2:07:bf:db:73:97:61:b6 dtliu@bj.cs.berkeley.edu
On the client, export the newly acquired public key to the ssh.com format. This can be done invoking the '-e -f ' options, assuming your ssh-keygen is capable:
client$ ssh-keygen -e -f ~/.ssh/id_dsa.pub > newPubKey
On the client, copy the converted public key to the ssh.com server's ~/.ssh2 directory, restoring the original name:
client$ scp newPubKey alfalfa:.ssh2/id_dsa.pub
dtliu@server's password:
scp: warning: Executing scp1 compatibility.
tmp 100% |*****************************| 727 00:00
On the server, append the string "Key id_dsa.pub" to ssh.com's authorization file. This tells the ssh.com sshd server which public keys are capable of authenticating users:
server$ echo "Key id_dsa.pub" >> ~/.ssh2/authorization
On the client, decrypt and register your key with the ssh-agent
Try performing a password-less login to the server:
client$ ssh server
Last login: Sun Feb 17 2002 02:29:21 -0800 from client.cs.berkeley.edu
dtliu@client$
About ssh-keygen's options for import/export to ssh.com's public-key format
I had two recent eversions of ssh-keygen, both of which were able to convert from ssh.com's public key format to OpenSSH's public key format.
OpenSSH_2.9p2. To convert from ssh.com to OpenSSH:
computer$ ssh-keygen -i -f
To convert from OpenSSH.com to ssh.com:
computer$ ssh-keygen -e -f
OpenSSH_2.5.2p2. This version can only convert dsa keys and only from ssh.com to OpenSSH: To convert from ssh.com to OpenSSH:
computer$ ssh-keygen -X
Enter file in which the key is (/home/dtliu/.ssh/identity): id_dsa_1024_a.pub
ignore: ---- BEGIN SSH2 PUBLIC KEY ----
ignore: Subject: dtliu
ignore: Comment: "1024-bit dsa, dtliu@chris, Sun Feb 17 2002 08:30:10 -0800"
ignore: ---- END SSH2 PUBLIC KEY ----
ssh-dss
AAAAB3NzaC1...jEy/S13rcA==
Detailed Information on Configuration
My testbed consisted of the following three linux boxes:
ssh-implementation version distro-version
OpenSSH2 OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f Red Hat 7.2
OpenSSH1 SSH Version OpenSSH-1.2.3, protocol version 1.5. Debian (kernel 2.4.14)
ssh.com2 ssh: SSH Secure Shell 2.4.0 (non-commercial version) on i686-pc-linux-gnu Red Hat 6
Figuring out your Implementation/Protocol
Here is ssh -V invoked on four different machines: The following both support SSH2, as shown in red:
OpenSSH_2.5.2p2, SSH protocols 1.5/2.0, OpenSSL 0x0090600f:
OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
The following only supports SSH, as shown in red:
SSH Version OpenSSH-1.2.3, protocol version 1.5
I'm not sure how to determine whether ssh.com's implementations support only ssh1 or only ssh2, but these both support protocol version 2.
ssh: SSH Secure Shell 3.0.0 (non-commercial version) on i686-pc-linux-gnu
ssh: SSH Secure Shell 2.4.0 (non-commercial version) on i686-pc-linux-gnu
* http://www.ticam.utexas.edu/adminworld/sshinterop.html (web-archive)
* http://www.cs.berkeley.edu/~dtliu/sshinterop.html (web-archive)
* http://www.hanwave.net/pn/modules.php?op=modload&name=News&file=article&sid=25
Getting OpenSSH to work with ssh.com and itself
Problem: The password-less public key authentication mechanisms of OpenSSH, protocol version 1, OpenSSH protocol version 2 and ssh.com's protocol 2 suite don't interoperate seamlessly.
Summary: In this article, I show how I got passwordless authentication amongst these three implementations. This is to be used as a reference for anybody who needs to set up their PKI accross different implementations.
Notes:
- Please note that the SSH1 protocol has been known to suffer from a security vulnerability...so if you can help it, upgrade to SSH2 as soon as possible.
If you're like me and you need work on multiple machines, you might be interested in using public key authentication and passwordless login to save yourself the trouble of typing your password every time you log on to a machine. Unfortunately, there are two popular implementations of ssh (done by OpenSSH and ssh.com) and two protocols (version 1 and version 2) which are not transparently compatible with each other. I've recently had to go through the hassle of making three of the four above combinations work with each other and thought I would sum things up so that somebody else might save their time and sweat.
Here is a simplified version of the configuration that I was dealing with:
Figure 1: There are three computers, all running various versions/distributions of linux and ssh. The three implementations of ssh covered in this configuration network are {(OpenSSH, protocol 1), (OpenSSH, protocol 2), (ssh.com, protocol 2)}. I didn't have to deal with (ssh.com, protocol 1) or any other implementations so they are not covered here. If you have any information on how to get them to work (or just that it was trivial), send me an email and I will integrate your solutions to this document.
Since there are six ways to connect the three different ssh implementations, I will describe how I got each of the six permutations to work. To be clear, the two protocol versions SSH1 and SSH2 do not interoperate, but it is often the case that an SSH2 client or server can operate in SSH1 compatilibity mode, which means that it can talk to an SSH1 client/server. For the rest of this article, I will assume that your SSH2 peer is able to operate in SSH1-compatibility mode. To find out what protocol and implementation you are running on your system, invoke ssh -V. There are examples at the end.
The following are the six interconnects in figure 1. Click the link that represents your own client->server combination.
- (openssh, protocol 1)->(ssh.com, protocol 2)
(ssh.com, protocol 2)->(openssh, protocol 1) - (openssh, protocol 1)->(openssh, protocol 2)
- (openssh, protocol 2)->(openssh, protocol 1)
- (ssh.com, protocol 2)->(openssh, protocol 2)
- (openssh, protocol 2)->(ssh.com, protocol 2)
(openssh, protocol 1)->(ssh.com, protocol 2)
(ssh.com, protocol 2)->(openssh, protocol 1)
I apologize, but this two have eluded me. Thus far I've been able to live without them. The problem is that since one side of the connection uses the SSH1 protocol, SSH1 keys are needed on boths sides of the connection. None of the ssh utilities that I have allow the conversion of SSH1 keys and I haven't figured out how to do it manually. If you figure this out, please mail me and I'll post it up.(openssh, protocol 1)->(openssh, protocol 2)
Generate a pair of SSH1 keys on the client. Take the default key name ~/.ssh/identityclient$ ssh-keygen
Generating RSA keys: ...............oooooO...........................oooooO
Key generation complete.
Enter file in which to save the key (/home/dtliu/.ssh/identity):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/dtliu/.ssh/identity.
Your public key has been saved in /home/dtliu/.ssh/identity.pub.
The key fingerprint is:
1024 9f:0c:9c:d8:9c:3d:ef:a2:14:31:31:26:56:43:ed:f5 dtliu@client
Copy the public key from the client to the server to the server:
client$ scp ~/.ssh/identity.pub server:.ssh
dtliu@server's password:
identity.pub 100% |*****************************| 333 00:00 ETA
On the server, append the newly obtained key to the ~/.ssh/authorized_keys file, which stores SSH1 public keys in the OpenSSH implementation:
server$ cat ~/.ssh/identity.pub >> ~/.ssh/authorized_keys
Modify the permissions of the authorized_keys file. If this file is write-able by anybody other than the user, then server will deactivate PK authentication.
server$ chmod 600 ~/.ssh/authorized_keys
At the client, decrypt and register your key with the ssh-agent:
At the client, try and login to the server:
client$ ssh server
Last login: Sun Feb 17 03:25:21 2002 from client.cs.berkeley.edu
Password-less login
At this point, you'll probably want to set up passwordless login, which is done with the following commands:
Invoke ssh-agent and it's outputted shell commands:
client$ eval `ssh-agent`
Agent pid 12899
Decrypt and add your newly generated private key to ssh-agent's database:
client$ ssh-add ~/.ssh/identity
Need passphrase for identity
Enter passphrase for dtliu@client:
Identity added: identity (dtliu@client)
Note: If you are registering another private key, then substitute private key for ~/.ssh/identity:
client$ ssh-add
Now you should be able to do a password-less login to the server:
client$ ssh server
Last login: Sun Feb 17 02:23:27 2002 from client
No mail.
server$
As you will soon notice, this only gives you password-less login through this terminal. To achieve true one-time per system authentication, I would recommend using the Keychain utility. This involves downloading the keychain program and adding two lines to your ~/.bashrc or ~/.bash_profile (or ~/.cshrc) files. The utility then keeps you from entering your passphrase more than once.
(openssh, protocol 2)->(openssh, protocol 1)
This one is actually the same as (openssh, protocol 2)->(openssh, protocol 1)(ssh.com, protocol 2)->(openssh, protocol 2)
There are two caveats here. One is that the ssh.com version (2.4.0) that I was using could only handle dsa encryption/decryption. Secondly, for the OpenSSH server to read ssh.com's public key, you must convert (import) the key from ssh.com's format to OpenSSH's format. Therefore, all pairs needed to be DSA key pairs.On the client, generate a DSA key pair (default). In the ssh.com implementation, SSH2-related keys go in ~/.ssh2:
client$ ssh-keygen
Generating 1024-bit dsa key pair
4 .oOoo.oOo.oO
Key generated.
1024-bit dsa, dtliu@alfalfa.CS.Berkeley.EDU, Sun Feb 17 2002 03:36:40 -0800
Passphrase :
Again :
Private key saved to /automount/calaeno/home4/dtliu/.ssh2/id_dsa_1024_a
Public key saved to /automount/calaeno/home4/dtliu/.ssh2/id_dsa_1024_a.pub
Copy the newly generated public key to the server's ~/.ssh directory. Notice here that OpenSSH keeps all keys (SSH1 or SSH2) in the ~/.ssh directory:
client$ scp ~/.ssh2/id_dsa_1024_a.pub server:.ssh
On the server, append the newly acquired public key to the ~/.ssh/authorized_keys2 file. There are two things to notice here. First, we must import the key from the ssh.com public key format to the OpenSSH public key format. Not all versions of ssh-keygen allow you to do this conversion. This is done with the "-i -f " options. Secondly, OpenSSH keeps all SSH2 public keys in the authorized_keys2 file as opposed to the authorized_keys file. Starting with OpenSSH version 2.9, SSH2 keys can also go in the authorized_keys file:
server$ ssh-keygen -i -f id_dsa_1024_a.pub >> authorized_keys2
On the server, make sure that the private key is not write-able by 'group' or 'other':
server$ chmod 600 ~/.ssh/authorized_keys2
On the client, add the line "IdKey id_dsa_1024_a" to the ~/.ssh2/identification file. This tells the ssh client which files contain the private keys:
client$ echo "IdKey id_dsa_1024_a" >> ~/.ssh2/identification
On the client, decrypt and register your key with the ssh-agent
On the client, try a password-less login:
client$ ssh server
Authentication successful.
Last login: Sun Feb 17 03:43:06 2002 from client.cs.berkeley.edu
server$
(openssh, protocol 2)->(ssh.com, protocol 2)
There are a couple of tricks needed to get this pair to work together. First the ssh.com server only understands dsa-style keys, so you have to ask the OpenSSH ssh-keygen program to make you a DSA key. Second, the OpenSSH and ssh.com keys have incompatible formats, so you have to get ssh-keygen to convert your public key from OpenSSH format to ssh.com format. Not all versions of ssh-keygen allow you to do this conversion.a
On the client, make a DSA key pair:
client$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/dtliu/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/dtliu/.ssh/id_dsa.
Your public key has been saved in /home/dtliu/.ssh/id_dsa.pub.
The key fingerprint is:
08:72:39:e1:26:ae:22:f1:a2:07:bf:db:73:97:61:b6 dtliu@bj.cs.berkeley.edu
On the client, export the newly acquired public key to the ssh.com format. This can be done invoking the '-e -f ' options, assuming your ssh-keygen is capable:
client$ ssh-keygen -e -f ~/.ssh/id_dsa.pub > newPubKey
On the client, copy the converted public key to the ssh.com server's ~/.ssh2 directory, restoring the original name:
client$ scp newPubKey alfalfa:.ssh2/id_dsa.pub
dtliu@server's password:
scp: warning: Executing scp1 compatibility.
tmp 100% |*****************************| 727 00:00
On the server, append the string "Key id_dsa.pub" to ssh.com's authorization file. This tells the ssh.com sshd server which public keys are capable of authenticating users:
server$ echo "Key id_dsa.pub" >> ~/.ssh2/authorization
On the client, decrypt and register your key with the ssh-agent
Try performing a password-less login to the server:
client$ ssh server
Last login: Sun Feb 17 2002 02:29:21 -0800 from client.cs.berkeley.edu
dtliu@client$
About ssh-keygen's options for import/export to ssh.com's public-key format
I had two recent eversions of ssh-keygen, both of which were able to convert from ssh.com's public key format to OpenSSH's public key format.
OpenSSH_2.9p2. To convert from ssh.com to OpenSSH:
computer$ ssh-keygen -i -f
To convert from OpenSSH.com to ssh.com:
computer$ ssh-keygen -e -f
OpenSSH_2.5.2p2. This version can only convert dsa keys and only from ssh.com to OpenSSH: To convert from ssh.com to OpenSSH:
computer$ ssh-keygen -X
Enter file in which the key is (/home/dtliu/.ssh/identity): id_dsa_1024_a.pub
ignore: ---- BEGIN SSH2 PUBLIC KEY ----
ignore: Subject: dtliu
ignore: Comment: "1024-bit dsa, dtliu@chris, Sun Feb 17 2002 08:30:10 -0800"
ignore: ---- END SSH2 PUBLIC KEY ----
ssh-dss
AAAAB3NzaC1...jEy/S13rcA==
Detailed Information on Configuration
My testbed consisted of the following three linux boxes:
ssh-implementation version distro-version
OpenSSH2 OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f Red Hat 7.2
OpenSSH1 SSH Version OpenSSH-1.2.3, protocol version 1.5. Debian (kernel 2.4.14)
ssh.com2 ssh: SSH Secure Shell 2.4.0 (non-commercial version) on i686-pc-linux-gnu Red Hat 6
Figuring out your Implementation/Protocol
Here is ssh -V invoked on four different machines: The following both support SSH2, as shown in red:
OpenSSH_2.5.2p2, SSH protocols 1.5/2.0, OpenSSL 0x0090600f:
OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
The following only supports SSH, as shown in red:
SSH Version OpenSSH-1.2.3, protocol version 1.5
I'm not sure how to determine whether ssh.com's implementations support only ssh1 or only ssh2, but these both support protocol version 2.
ssh: SSH Secure Shell 3.0.0 (non-commercial version) on i686-pc-linux-gnu
ssh: SSH Secure Shell 2.4.0 (non-commercial version) on i686-pc-linux-gnu
Sources
- comp.security.ssh
- Keychain: A very nice utility that facilitates one-time authentication.
- www.openssh.com: Open source ssh client/server.
- www.ssh.com: Commercial ssh clienter/server and their Documentation on public-key authentication
- The snailbook
Labels: authentication, openssh, pkc, public key, ssh, ssh interop, ssh.com
Eingestellt von wolfik Am/um
9/18/2007 09:54:00 AM
