↑ Return to SSH and Tunneling

SSH Authentication: Server and Agents

Once you have generated these keys, you need to add the public key to your ssh account on the server. How this happens may vary. On a more-or-less public system (for example, here is the GitHub explanation) they may let you add this through a Website where it is added to your account information. In a corporate environment you may find that the IT department takes care of generating the key and adding it to the server. So you need to check with the server to see how they handle this.

If you have access to the server, such as it is a server you administer, there is a file called $HOME/.ssh/authorized_keys that holds the public keys of users, one to a line (and the lines are long, of course). Since you have not yet uploaded your key, this login to the server will need to be authenticated by using a password, but once you have added it you should be good in the future. Simply copy the file with your public key, then cat the file to the authorized_keys file to add it. Note that if you are the admin on this server and have the rights needed to do this, make very certain that you set the permissions properly so that no one else who gets on your server can read the file. The idea is to be secure, after all. So set the permissions to 600, or so that the owner can read and write, but no else has access. This file lives in the home directory of your account on the server, and it needs to be created the first time. The server admin may ask you to send in your public key so that the file can be created, but if you are doing this on a home machine you need to create it. Note that you may have a key from each machine you use to login from, so the file can have several keys in it. To add it to a remote server, first login using your password. Then copy the file and cat it to the authorized_keys file. Then test by logging out, and then login again. If you were successful, you will be logged in without a password being requested.

Agents

In use, you would need to use your passphrase each time you tried to open an ssh session. While it is possible to create a public key without a passphrase, it is a very bad idea to do this. And a short, memorable passphrase it almost as bad. The passphrase needs to be long to do its job. I would recommend that you first store this in a secure vault like KeePassX (see the tutorial on Passwords, Entropy, and Good Password Practices for more on this). But if you do a lot of SSH sessions in a day, this does get old. Fortunately, there is a good, reasonably secure solution, called an SSH agent. This is a program that resides in memory and holds your decrypted private key. Every time you go to a site using SSH it uses this key to generate a message which the server decrypts using your public key which it has. And when you shutdown your computer at the end of the day, it drops your key out of memory, so the next day when you boot up you need to enter your passphrase one more time. There are obvious security concerns here. If you don’t lock your computer every time you walk away from it, your private key can be grabbed by anyone.

In any Unix-like system the program ssh-agent should be installed. Many display managers will have hooks into the ssh-agent, and will find your key (xdm and kdm are two such) if it is in the default location. You will know this if a when you boot up you get a pop-up window asking you for your passphrase. Ubuntu is a little different, so you can read the Ubuntu man page for this here. For windows users, the PuTTY ssh agent is called Pageant. If you place a shortcut to it in the startup folder, it will run automatically every time you boot Windows.