SSH public keys, or, how not to expose a password
As an independent Linux/Unix consultant, I am often asked to work on machines that I have never used before, and so I need a password to log in. While I can be given a password over the phone, that frequently starts a rash of “was that a b-as-in-boy, or a d-as-in-dog” stops. Seeing the password in the text is much easier, but you should not ever email a password: email is usually transferred over the internet at large in clear text and can easily be sniffed by anyone in the middle, or even someone who has a server next to yours in a rack! You could use PGP to encrypt your email before you send it, but PGP just doesn’t get used all that often, and often people don’t know how to use it.
SSH has a great, but infrequently used feature called public-key authentication, that allows a user secure access to a SSH-based Linux or Unix server that they have never accessed before. It works by utilizing public-key cryptography, which is a great topic for a late-night read!
In a nutshell, there are two halves to a key: the private key and the public key. They are connected in a way that if you encrypt something using the public key, only the private key can decrypt it, and if you encrypt something with the private key, anyone with your public key can decrypt it (this is how PGP signed emails work). The SSH daemon on most servers can also use this concept by allowing users to authorize their own public keys, which then allows them to log in without having to type a password, or even without having a password! (So always remember to change a disabled user’s shell when you disable their password.)
Public-key authentication can also be used as a handy way to log in to your server without having to type your (hopefully long & complicated) password every time.
In practice, it is almost as easy as the nutshell. Here, I am on a unix-based machine (a mac) and I am going to create a new public/private key pair.
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/jpk/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/jpk/.ssh/id_rsa.
Your public key has been saved in /Users/jpk/.ssh/id_rsa.pub.
The key fingerprint is:
19:9d:f5:11:46:dc:b2:69:f5:b6:09:1b:a7:c3:f4:49 jpk@pellinore.alchemycs.com
The key's randomart image is:
+--[ RSA 2048]----+
| .o=o |
| . o oo.o|
| . o .=.|
| o ++Eo|
| S o.O.+|
| = = |
| . |
| |
| |
+-----------------+
Note where it asks for a passphrase above. It is a really good idea to provide one: that way, it encrypts the private key so that if someone ever steals your laptop (and you don’t have your filesystem encrypted) they won’t instantly be able to log into any machine you have trusted that key on. This also requires you to type the passphrase each time you want to log in, but there are “ssh-agent” programs that let you type the passphrase once, and it stores it in memory until you close the agent (this is something that recent versions of MacOS X does).
When you generate a key, two files are created: .ssh/id_rsa file is the private key, and .ssh/id_rsa.pub file is the public key.
If you look at the file “id_rsa.pub”, it has a bunch of gibberish:
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAv1ARfiMlaUk3b5KBRTvfwmjrchpBAJrbyUlrQGJLK4/V0+qEquIvHiLrrMkT265dDE1Qadzlz0RTgmSgj+ubJZ2bKf0H8ZAzMbmyzcYblhtlGJYN7ZD1g5nUWANIj2U2FP7GMKC69pbquxZCJTZpK95Y3fVcHWFyb+3jt0Ex4bjI6TwW6fr0REQngOsqSU+h1rlnEOLZKKPoKcv5BkZ0y2r1RlPVnJtbjRdqt7SAiw0bUbBkiigII/L6+LFBJYzCp1jEZUw9wfIqjVUiKndKmOIdozt0Gg2c8Be0rpyez6IhlDvyRbLzk4grf1rkt6Odn/3+vrSr4eQ6tY3MbrkJuw== jpk@pellinore.alchemycs.com
On the server, the contents of the id_rsa.pub file need to be put into a file called “authorized_keys” that is under the “.ssh” directory for the new user.
Assuming I have copied that file to my current directory to the server using the root account, I can then set up the new account and include the file:
newserver# useradd -m newuser
newserver# mkdir ~newuser/.ssh
newserver# mv id_rsa.pub ~newuser/.ssh/authorized_keys
newserver# chown -R newuser ~newuser/.ssh
From there, you can log in to the server.
home$ ssh newserver.alchemycs.com
Enter passphrase for key '/Users/jpk/.ssh/id_rsa':
newserver$
A bit more about the ssh-agent I mentioned above. Typically you run ssh-agent with whatever is going to use the ssh public key file (eg, Terminal.app in MacOS). Then you would run ssh-add to add the passphrase to the ssh-agent.
Here, I will run ssh-agent on screen so I can have multiple logins to the server at once if I need.
home$ ssh-agent screen
...(screen starting)
home$ssh-add
Enter passphrase for /Users/jpk/.ssh/id_rsa:
Identity added: /Users/jpk/.ssh/id_rsa (/Users/jpk/.ssh/id_rsa)
home$I could also add multiple ssh key files by specifying a separate key file to ssh-add.
home$ ssh-add .ssh/id_rsa_2ndkey
Enter passphrase for .ssh/id_rsa_2ndkey:
Identity added: /Users/jpk/.ssh/id_rsa_2ndkey (/Users/jpk/.ssh/id_rsa_2ndkey)
home$SSH public key authentication is a great way to securely log onto new servers, as well as ease frequent logins to known servers.
If you’re nervous about a man in the middle attack let me give you something else to worry about. I don’t think there are too many people sniffing email these days, and if they are they probably work on the network, or you’re on an open wifi network. You might have a bad email admin that grabs a copy while the message is in transit, but hopefully you can trust your email admins.
I’m more worried about the sender or receiver’s computer being stolen or compromised. Email messages are usually clear text or easily read files on your computer (both sent and received).
Now with legal and regulatory requirements it should be expected at least one end of the email is going to be archived for n years. If one end is a government agency, including schools, city/state/county-government then anyone can make a public records request and if the agency doesn’t redact, well your password could be just handed out.