Ssh public key guide

2008/06/25 by Lassi A. Liikkanen

On this page:
o Read first
o Why public
o Ssh2open
o Open2Ssh
o Between similar
o Identification
o Authorization
o Problems
o References

Ssh public key authentication guide

This document describes the basic procedure to establish a public key based authentication between two UNIX/Linux operating systems. This is a hands-on -style guide intented to overcome the biggest problems. If you wish to achieve a more thorough understanding, check references

Good to know first

The basic concepts:

local host
The machine you connect from to the...
remote host
...the other machine
public key
A deciphered string that matches your...
private key
which is the key "unlock" systems that know your public key. For an operational authentication system, both are needed.
comes with the private key, which together with the public key provides...
matching the public and private key

Ssh client (command ssh) behaves quit nicely and is relatively easy-to-use application. Beneath the surface there is still quite a lot going on. The most important fact of the all is that there are actually three distinct ssh applications even though you hardly ever see any signs of them. First of all, the original releaser of the SSH application, SSH communications, has released two versions of the SSH protocol, SSH1 and SSH2. In addition, there is the open source SSH project called OpenSSH that supports both SSH protocols in one application. In practice the OpenSSH and SSH1 are functionally similar which would be good for the user, but SSH1 is nowadays considered outdated and in the dominance of SSH2 it is essential to know the difference.

To apply this guide you need to be aware of what ssh you are running in the machines you're about to connect. This is done in the originating computer's shell with the command
ssh -V
For example, one of my home university's, (University of Helsinki) machines displays the following:
ssh -V
ssh: SSH Secure Shell (non-commercial version) on sparc-sun-solaris

which tells you that were dealing with a SSH client, that is actually capable of SSH1 and SSH2. To test this, try
ssh2 -V

that should bring you the same result IF you're running SSH's own SSH, OpenSSH installations usually don't have ssh2 command available.

Next you should know which SSH daemon (host application) is running in the other end. To do this, you must connect to the remote host you want to establish the authentication to. Login as normally and once logged in repeat the previous procedure, but this time for the daemon like this:
sshd -V
The daemon application does not actually understand the -V option, but evokes the built-in help page and also displays daemon version, e.g.:
sshd -V
sshd: option requires an argument -- V
sshd version OpenSSH_3.5p1

so my in my case I will be connecting between an SSH(2) and OpenSSH. This is important as the SSH(2) and OpenSSH(2) use the different key format which requires you to translate the key in order to get it working between the systems.

One final thing about the protocols. The daemon normally controls which protocols you can use. The standard procedure is the SSH2 protocol. Therefore if you connect with ssh, which implies SSH1, to a machine that accepts or at all uses SSH2 your protocol will be SSH2. This also is a significant detail. You can ensure the used protocol by connecting to the remote host with the verbose option:
ssh -v
most certainly it will be SSH2 and this guide will assume SSH2 protocol as synonym for SSH connections.

Why to use public key

Public keys can be used to increase your login security as they remove the need to use the actual password repeatedly. Especially useful when used in co-operation with the ssh-agent. They can also be used to bypass the password prompts if you leave the key passphrase empty. Even though this may be handy at sometimes it is also a big potential security risk!. So always use the passphrase if you really don't know the risks and want to take them.

Next subchapter will describe how this is actually achieved

From SSH to OpenSSH

Go to the hidden ssh2 directory below your own home directory:
cd ~/.shh2
Run the ssh key generator application and follow the directions
Now you've created the keys, the public key identified by the extension .pub and private which lacks the extension. Now remember, the private key is really private so don't give it to anyone!. Depending on the system your keys will be named like key_dsa_2048_a. If you wish, you can generate more keys, but they are not needed.

Most guides tell you next to upload you public key to the remote server and enjoy life ever after. I'm not going to do that as that is not enough. If you're not using the agent you must also manually edit or create the identification file to the same directory. For example, my identification file looks like this:
cat identification
#Comment, just to show I know how to comment
IdKey key_dsa_2048_a
The functional part is the IdKey preceeded with a space and the actual, relative or absolute path to the private key file.

Now you can upload the public key file, for example using scp
Note that the directory on OpenSSH system is .ssh NOT .ssh2. Now, login to your remote host and go the directory you sent the file to:
cd ~/.ssh
Next you must reformat the public key in order to get the SSH2 (SECSH) format work OpenSSH2 format. You must use the ssh-keygen of the OpenSSH package
ssh-keygen -i -f >> authorized_keys

This commands will append your reformatted key to the 'keyring' and delete the unnecessary SSH2 formatted public key.

Now everything SHOULD work as expected, just connect as you used to.

From OpenSSH to SSH

Go to the hidden ssh directory below your own home directory:
cd ~/.shh
Run the ssh key generator application and follow the directions
ssh-keygen -t [ dsa | rsa ]
OpenSSH keygen should ask you for a keyname if you don't specify one at the command line. You must select the type of the key by giving either argument dsa or rsa, as indicated by the brackets and the pipe sign in the above syntax. My example key is called test-key which not the standard for the OpenSSH. The ease your life, use the standard id_dsa | id_rsa . Now you've created the keys, the public key identified by the extension .pub and private which lacks the extension. Now remember (again), the private key is really private so don't give it to anyone!

Next step, as we're going transfer the key to SSH environment, is to reformat it. It can be done like this:
ssh-keygen -e -f >
Now the key can be uploaded into the remote host like this: scp
Before you can log in with the public key, you must change the settings in the remote machine.

So login in to the remote server and edit the ~/.ssh2/authorization file. You should add the uploaded file's name to the file, e.g.:

Now it's almost done. You can now use the public key to login to the SSH remote host, but if you used a key name different from the default options (id_rsa or id_dsa) you'll have to specify the identity file with the option -i followed by the parameter filename like:
ssh -i test-key

In case of OpenSSH this is the private key file, in SSH2 the identification file that points to the key files.

From SSH to SSH or
from OpenSSH to OpenSSH

In case your two systems are similar, things are a lot easier. Follow the instructions above but ignore the step where the key is reformatted, note that you may have to rename or copy the public keys at some point.

Directory and file reference

~/.ssh for OpenSSH
~/.ssh2 for SSH's SSH

authorized_keys (or authorized_keys2) for OpenSSH
authorization (file pointing to public key files) for SSH's SSH

id_dsa OR id_rsa for OpenSSH
identification (file pointing to private key files) for SSH's SSH

Identification in particular

To repeat myself, the identification part is handled as follows in the two systems:

Id in SSH2

In the ~/.ssh2 directory you have a file called identification, which contains one private key filename on a row preceeded by the term IdKey. Most cases you'll only have a one entry in this file.

Id in OpenSSH(2)

In the ~./ssh directory you have a file called either id_rsa or id_dsa (or both) that contains your private key. Multiple keys require using the -i identity_file option with the client program.

Authorization in particular

Auth in SSH2

In the ~/.ssh2 directory you have a file called authorization, which contains one public key filename on a row preceeded by the term key. All machines you want to connect must have an entry here.

Auth in OpenSSH(2)

In the ~./ssh directory you have a file called either authorized_keys2 that contains catenated public keys in the OpenSSH(2) key format. As with SSH2, each and every machine you're connecting from require their public key as a part of this file.

Typical problems

Tip 1

SSH application may be picky about the file privileges so use only the minimal options to keep your keys secured otherwise the application considers your keys unreliable, which is just the case. You should have the following privileges:
chmod 0711 ~/. (home directory)
chmod 0700 ~/.ssh2
chmod 0600 ~/.ssh2/my_private_key1
chmod 0600 ~/.ssh2/my_private_key2
So it should work just fine.

Tip 2

There is of course the issue of configuring the SSH client to use the methods in a way appropriate for you. For example, some systems may have configured to normally not to even try public key authentication. If this happens you should consult the manual and follow the next tip.

Tip 3

In most cases, you can do additional troubleshooting while the client operates in the verbose mode
ssh -v [additional parameters].

Tip 4

Remember that on the host machine, both private and public key must be accessible for succesful identification and authorization, because the client will not even try the public key if it can't locate both keys when establishing a connection with the remote host
ls ~/.ssh2/mykey*


Barret and Silverman (2001) SSH : The Secure Shell. The definitive guide. Available online
Chapter six is especially relevant for public key authentication issues.

Branderburg's article Password-free login with SSH (

Keywords: [computers] , [unix] Document's status: Ok (Document dates explained)

This document created: 2005/04/22
Modified: 2008/06/25
Published: 2008/02/16

This document's permanent URI (linking):

© Lassi A. Liikkanen 2005 - 2021. All rights reserved.
^Top of the Page^

*Change layout:
Printable printable
Large text


@lassial Twitter feed: