Public Key Authentication for SSH Made Easy
Instead of logging
in to SSH using a traditional password, you can also authenticate yourself
without a password using a technique called public key authentication. This has
more advantages than you would expect: as well as being convenient and more
secure, you could use it to allow applications on your computer to access a
remote system without knowing anything about the authentication, and mount SSH
filesystems without being prompted.
How does public key cryptography work? Two keys are generated on the client computer: the public key and the private key. What makes the two keys special is that a message encrypted with one can only be decrypted with the other.
You give your public key to the server, which stores it in a list. Your private key stays hidden. When you attempt to log in, the server encrypts a message with your public key and sends it to you. Only your matching private key can decrypt the message. Your computer proves to the server that it has successfully decrypted the message. The server then logs you in.
Public key authentication for SSH has many security advantages: a password is never transmitted in any form over the network, the key needed to decrypt the server’s message is much harder to guess compared to a password because it is much longer, and the server does not need to store your private key to know you have it.
Got all that? Now that you understand how it works, let’s set up public key authentication on Ubuntu or another Debian-based distribution.
First, you need to generate the key pair on the client system unless you already have. You can find if you have a key pair by checking for for these two files:
~/.ssh/id_rsa
(your private key)
~/.ssh/id_rsa.pub
(your public key)
If you don’t have them (you will be warned if you do), generate a new key pair on your local computer (run this as your normal user):
ssh-keygen -t rsa
You will be asked two questions. Press enter to accept the default location for the keys. Then you will be asked for a passphrase. If you choose to use a passphrase, then you will be required to enter it whenever you use the private key. If you are doing this for extra security, you will want one. If you want convenience, leave it blank.
Now you are ready to tell the server your public key. There is a utility that
does this for you called ssh-copy-id. You’ll need to specify the user, host,
and any other details that are needed to log in via SSH.
ssh-copy-id -i ~/.ssh/id_rsa.pub username@remotehost
Once the SSH server has the key, you should be able to log in without your password! If it didn’t work, you may need to make a configuration change.
SSH in to the server, and open the SSH server configuration file:
sudo nano /etc/ssh/sshd_config
If the server didn’t let you in using your key, find the PubkeyAuthentication
line and change it to yes.
If you’re sure that the key is working, you can turn off password authentication
now. Just don’t lock yourself out! Find the PasswordAuthentication line and
change it to no.
Restart the SSH server on the remote system to make your changes take effect:
sudo /etc/init.d/ssh restart
Enjoy the convenience and security!
Archived Comments
Andrei
Perfect article.
Thank you!
Dominik
w00t! Really incredible article! Thanks a LOT!
Brian Pence
Remember, though, that the security of publickey authentication is entirely dependent on your ability to keep the private key private. If you must use public key authentication, you should NEVER generate one without a password! Why would you sacrifice security for convenience?? Consider this… if you have an unencrypted private key (no password) stored on your PC or Linux workstation and your workstation is compromised, your servers should be considered compromised as well. If a hacker can obtain the key, it will give him access to your server.
Having a password on the key helps, but if your system is compromised, you should consider the possibility that your keystrokes are being logged and your password stolen.
Possibly having the key file stored on a floppy, USB key, or other removable device that is only inserted at login time might help, but again, if your system is compromised, the key file could be swiped off of the removable device when inserted.
The most secure way I’ve found to authenticate is by using a smartcard or USB encryption token. The concept is the same as the typical publickey authentication except that the private key is guaranteed to remain private.
The smartcard or USB token has a CPU inside that handles the mechanics of the key authentication. The key pair is generated inside the token and only the public key comes out (which you place on the server). The private key cannot be accessed.
The authentication bits that happen at login time occur inside the token by its own CPU, so the private key is not exposed.
The difference between smartcard and publickey may seem unimportant at first, but can be summed up this way….
file-based publickey authentication can only assure you that the user logging in has a *copy* of the key (there may be others).
smartcard-based publickey authentication assures you that the user is in posession of the hardware key (of which there is only one)
Of course, the amount of time/energy/money you spend securing your system should be somewhat proportional to what you are securing. If it’s your home linux box, plain passwords or publickey are probably enough. If it’s a business or government server, you’ll probably want to go with something stronger like smartcard.
If you’re interested in talking about this more, contact me at bpence@celestialsoftware.net
Brian Pence
Celestial Software
http://www.celestialsoftware.net
AbsoluteTelnet (for telnet and ssh)
bobm
If you still get a password request make sure that the ‘authorized_keys2’ is chmod’d to 600.
that fixed it for me.
matt illingworth
If it is still asking for a password it might be to do with your home directory
permissions. In /var/log/auth.log on server it will say something about the
permissions being wrong on the home folder.
To reset your home folder back to default permissions run:
chmod -R 755 /home/matt
chmod 644 /home/matt/.dmrc
The .dmrc file has to be set to 644 or when you log in you get an error.
Anon
Great article.
Easily explained. Thanks!
jimcooncat
Now that you have this all set up, make it even more convenient with seahorse:
http://www.debianadmin.com/ssh-key-authentication-using-seahorse-gui.html
If you’re a command-line-only nut, check out keychain:
http://www-106.ibm.com/developerworks/linux/library/l-keyc2/
And for the more complex, where you need to logon another computer from the one where you’re remotely logged into, there’s authentication forwarding:
http://www.ibm.com/developerworks/linux/library/l-keyc3/