An ssh login (or a file transfer using scp) can be done using public-key authentication instead of a password.
A public/private key-pair can be generated on your personal computer with
ssh-keygen -t rsa
Default location is ~/.ssh with names id_rsa and id_rsa.pub and you will be prompted to enter a passphrase (empty is bad). Directory ~/.ssh will be created (if it did not already exist) with protection 700, private key ~/.ssh/id_rsa with protection 600, and public key ~/.ssh/id_rsa.pub with protection 644. The public key will end with plain-text identification of the form username@hostname, e.g., "UserName@MyMac.local".
The public key must be added to ~/.ssh/authorized_keys for your account on the remote server. Here are three ways to do that.
1) OpenSSH has command ssh-copy-id which can be used for that purpose. Its man-page describes the procedure and options.
2) I setup my current server in my office (before moving it to my dept's server room) and did the transfer using swivel-chair-net, i.e., a flash drive with public keys for me at each of several computers.
3) I recently added a key from home. After establishing a vpn connection to my school's network, I used scp to transfer the public key and ssh to login in order to finish the task. Since an ssh-login with password would be impossible from home after I added the new public key to ~/.ssh/authorized_keys, I took the precaution of using two terminal windows.
term-A) scp transfer of public key; ssh login using password; cat id_rsa.pub >> .ssh/authorized_keys
term-B) ssh login using public key after supplying passphrase
If the second login from term-B had failed, then I would have been able to repair or revert using the term-A login. Since the second login was successful, I finished with "mv id_rsa.pub .ssh/home-id_rsa.pub" as well as confirming .ssh and authorized_keys had appropriate protection (700 and 600).
The passphrase is needed only occasionally. Since it is machine-specific, I am willing to enter it even when other people are observing me. (OTOH, I still need to be secretive entering my WeBWorK password when students are in my office.) The ssh-keygen command has an option to change a passphrase without changing the private/public key-pair, it also has an option to remove all keys for a host from a known_hosts file.
FWIW: I also have a back-door: a second user with non-obvious name and very complicated password. I've given this user sudo privileges, but being able to "su real-admin" (and supply its password) would suffice.
Hi Dick,
Thanks for this. Could you add documentation about this to the wiki, maybe under the Security and/or Administrator's category? This is good administrative security practice.
Jason
Thanks for this. Could you add documentation about this to the wiki, maybe under the Security and/or Administrator's category? This is good administrative security practice.
Jason
interim update:
A few subsequent experiments seem to show that public-key authentication is merely an alternative method --- it does not disable authentication via a password.
E.g., changing the key-pair in steps (1-2) did not prevent (3)
1) moving .ssh to ssh
2) repeating the ssh-keygen -t rsa command (which, with probability > 0.999, generates new keys even if passphrase is same)
3) having ssh me@host be successful after supplying my password (I presume password was required because public-key info did not match).
4) restoring the original .ssh folder also restored public-key authentication
Notes:
a) don't let techy-stuff influence you to simplify your passwords
b) remember that only a login is being authenticated by using your public-key --- expect to be required to supply your password for a "sudo ..." command after logging-in (but now with a fully encrypted session).
c) I need to read more of the O'Reilly book about SSH.
A few subsequent experiments seem to show that public-key authentication is merely an alternative method --- it does not disable authentication via a password.
E.g., changing the key-pair in steps (1-2) did not prevent (3)
1) moving .ssh to ssh
2) repeating the ssh-keygen -t rsa command (which, with probability > 0.999, generates new keys even if passphrase is same)
3) having ssh me@host be successful after supplying my password (I presume password was required because public-key info did not match).
4) restoring the original .ssh folder also restored public-key authentication
Notes:
a) don't let techy-stuff influence you to simplify your passwords
b) remember that only a login is being authenticated by using your public-key --- expect to be required to supply your password for a "sudo ..." command after logging-in (but now with a fully encrypted session).
c) I need to read more of the O'Reilly book about SSH.