If you use SSH to administer your own server there’s a strong possibility that you use public key authentication rather than password authentication to log into it. Public key authentication is generally more desirable than password authentication for a number of reasons. For one, it’s more secure; it doesn’t transmit any secrets over the wire and has a much larger secret to guess, making snooping and brute force attacks practically impossible. Nothing secret is stored on the server either so one compromised login cannot compromise other logins. Because keys are unique to client, it becomes simple to disable logins which have become compromised or have outlived their usefulness. Finally, if one knows what one is doing, one can set up key based authentication so that it does not require any password entry to login, which is a great convenience.
One inconvenience however with public key authentication however, is that logging in from a new machine is somewhat more involved. You’ve can’t just install PuTTY (or whatever) and type your password to login. You need the a key to login and this computer doesn’t have it. Now, your first temptation when presented with this situation might be to copy one of your private keys to the new machine and log in with it. However there is an easier way. Temporarily enable password authentication on the server and add the new client while it’s open. All you need is access to an already active client. I’ll show you what to do.
These instructions are written assuming both the new client and the server are Linux machines.
From the new client machine, run:
ssh-keygen -t rsa
Provide a password for the key. Locate the generated public and private keys on your computer
Now log in to the server from a client machine from which you already have access. Now enable password access. Open up the /etc/ssh/sshd_config file and make the following change:
-PasswordAuthentication no +PasswordAuthentication yes
Now restart the server:
Don’t worry, this won’t disconnect you. You should now be able to log in to the server from the new client. Do so. Now add the new public key to ~/.ssh/authorized_keys on the server. The simplest way to do this goes such:
On the client,
scp ~/path/to/new_key.pub user/password@server:new_key.pub Password: ********
And on the server,
cat ~/new_key.pub > ~/.ssh/authorized_keys rm new_key.pub
Try logging the new client off and logging in again. It should prompt you for the key password rather than for your user password. If this works, you can go ahead and disable the password login by changing /etc/ssh/sshd_config again like such:
-PasswordAuthentication yes +PasswordAuthentication no
And restarting the server again,
And you’re done. You can now login from the new machine with the same level of security you could from the old machine.
This method has a couple of advantages over the alternative of copying keys between computers. The first is that you don’t have to transmit any private keys over the network or make copies on to thumb drives or other removable media. This reduces the odds of a key getting intercepted or you forgetting to delete it from your thumbdrive and it becoming a security risk. Furthermore, this makes your keys less promiscuous and maintains a one key per client relationship; none of the private keys ever leave the machines on which they were generated. This allows you to keep better track of which machines have access to your server and making removing compromised keys less troublesome.
Allowing password authentication does technically open the server up for brute force attacks but a successful brute force will usually take a long while and as you can see, this process only takes a couple minutes. The odds of a brute force succeeding in that time are astronomically small, making this save for most real world use.1 The alternative of toting private keys around on flash drives seems so much more error prone to me.
If you have any other/better ideas on how to manage keys don’t hesitate to share in the comments bellow.
- I’m not a security researcher, this is just my opinion so I waive any liability. However, I’d be surprised if I was wrong. ↩