If you use SSH to admin­is­ter your own server there’s a strong pos­si­bil­ity that you use public key authentication rather than pass­word authen­ti­ca­tion to log into it. Pub­lic key authen­ti­ca­tion is gen­er­ally more desir­able than pass­word authen­ti­ca­tion for a num­ber of rea­sons. For one, it’s more secure; it does­n’t trans­mit any secrets over the wire and has a much larger secret to guess, mak­ing snoop­ing and brute force attacks prac­ti­cally impos­si­ble. Noth­ing secret is stored on the server either so one com­pro­mised login can­not com­pro­mise other logins. Because keys are unique to client, it becomes sim­ple to dis­able logins which have become com­pro­mised or have out­lived their use­ful­ness. Final­ly, if one knows what one is doing, one can set up key based authen­ti­ca­tion so that it does not require any pass­word entry to login, which is a great con­ve­nience.

One incon­ve­nience how­ever with pub­lic key authen­ti­ca­tion how­ev­er, is that log­ging in from a new machine is some­what more involved. You’ve can’t just install PuTTY (or what­ev­er) and type your pass­word to login. You need the a key to login and this com­puter does­n’t have it. Now, your first temp­ta­tion when pre­sented with this sit­u­a­tion might be to copy one of your pri­vate keys to the new machine and log in with it. How­ever there is an eas­ier way. Tem­porar­ily enable pass­word authen­ti­ca­tion 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 instruc­tions are writ­ten assum­ing both the new client and the server are Linux machi­nes.

From the new client machine, run:

ssh-keygen -t rsa

Pro­vide a pass­word for the key. Locate the gen­er­ated pub­lic and pri­vate keys on your com­puter

Now log in to the server from a client machine from which you already have access. Now enable pass­word access. Open up the /etc/ssh/sshd_­con­fig file and make the fol­low­ing change:

-PasswordAuthentication no
+PasswordAuthentication yes

Now restart the server:

/etc/init.d/sshd restart

Don’t wor­ry, this won’t dis­con­nect you. You should now be able to log in to the server from the new client. Do so. Now add the new pub­lic key to ~/.ssh/au­tho­rized_keys on the server. The sim­plest 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 log­ging the new client off and log­ging in again. It should prompt you for the key pass­word rather than for your user pass­word. If this works, you can go ahead and dis­able the pass­word login by chang­ing /etc/ssh/sshd_­con­fig again like such:

-PasswordAuthentication yes
+PasswordAuthentication no

And restart­ing the server again,

/etc/init.d/sshd restart

And you’re done. You can now login from the new machine with the same level of secu­rity you could from the old machine.

This method has a cou­ple of advan­tages over the alter­na­tive of copy­ing keys between com­put­ers. The first is that you don’t have to trans­mit any pri­vate keys over the net­work or make copies on to thumb drives or other remov­able media. This reduces the odds of a key get­ting inter­cepted or you for­get­ting to delete it from your thumb­drive and it becom­ing a secu­rity risk. Fur­ther­more, this makes your keys less promis­cu­ous and main­tains a one key per client relationship; none of the pri­vate keys ever leave the machines on which they were gen­er­at­ed. This allows you to keep bet­ter track of which machines have access to your server and mak­ing remov­ing com­pro­mised keys less trou­ble­some.

Allow­ing pass­word authen­ti­ca­tion does tech­ni­cally open the server up for brute force attacks but a suc­cess­ful brute force will usu­ally take a long while and as you can see, this process only takes a cou­ple minutes. The odds of a brute force suc­ceed­ing in that time are astro­nom­i­cally small, mak­ing this save for most real world use.¹ The alter­na­tive of tot­ing pri­vate keys around on flash drives seems so much more error prone to me.

If you have any oth­er/­bet­ter ideas on how to man­age keys don’t hes­i­tate to share in the com­ments bel­low.

1. 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. ↩