$ ssh [email protected]
[email protected]'s password:

You probably encounter such a prompt on a daily basis. However, did you know that there is A Better Way™?

In order to use keys for authentication, it is not necessary to understand the math behind public key cryptography. However, as illustrated by the color-mixing example, the premise is rather straightforward. By understanding the broad purpose of having two keys, you will avoid the cardinal error of revealing your private key while feeling comfortable sharing your public key.

To get started with generating keys, I will defer to Github’s thorough and easy-to-understand guide. If you have not already, go through the tutorial for pushing to Github using a key instead of a password.

Connecting with SSH

Any time you connect to a server with an ssh username and password, you could alternatively use a keypair. Once you have generated your keys, a utility called ssh-copy-id will allow you to configure logging in without a password. This tool is included in Ubuntu and RedHat. The tool is not included by default in OSX, though a community-developed version exists.

[dev@local ~]$ ssh -i ~/.ssh/id_rsa example.com
[email protected]'s password: ^C
[dev@local html]$ ssh-copy-id [email protected]
[email protected]'s password:
Now try logging into the machine, with "ssh '[email protected]'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
[dev@local ~]$ ssh -i ~/.ssh/id_rsa example.com
Last login: Thu Nov 10 10:06:56 2016
[dev@remotehost ~]$ echo "access granted"
access granted
[dev@remotehost ~]$ cat ~/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDCV+zx2ctGFlAdVWBKGrQJcRX+qdzXllS5nFa4bYWVqtt3UMayjE5yTNLS54pGar2e28GwhC0DWSAgMtMWEzwjZtzkSuLM/d0DkWt5HmXUQk++7QNICVo9ER4zR2m/fncgkkh5BMLuT6OUtZze4AbKyA26byfbfI6YylwHsLukn3sZeB3gcjpIUriO497xD1+Y7ZmSUf/F9uHAr9BNwgEbWhdgLTdGtRsRd2a4rJlDbSnQYybZdDRWXoMKhRxxlAFPwI/SzfxsVD1sxzbNfTET4nANfmvSsJvo87PeCmRaiEaSqrqxbI7CW6oA7Hp8aUBb0CFUMs1B58vfHs3b030VsiuAFziSOUbgc2bpP+oFCMRym7i2DGLzqIS3wTp3z9VI6IQ3iqYaRr9Kb069mjjfmyKcnV+FQwNDvx7z1HGnNuyg4Dtwsensob2zLKRqVcyvMCIgjAk9LABZyPhGhUGP65GuNnJeDT0Xg+e493GQgJzzMqujXWWqxmSWlUdDgQM6HQZGYSSAmqXyalaBYIBPzybK32GBjDTIsHWUMIWwB0+Fn6lbR3Tq8v3GMlsVD2WIWplN1TMj/ZBdRtAvJuRJlvYXv0GpigsqkoblcISN3eO4wyUuoRiWHxHNjU9BfU7AU1PX3/XmhLEnTzcsTpAM4XfRCbvJO/cmaINS7Lxg1Q==

Note that the first ssh attempt yielded a password prompt. After running ssh-copy-id, no such prompt was presented; the server accepted the key instead of a password.

Unless you have tried this before, expect to see one key in the authorized_keys file. I also recommend appending the key’s email address as an additional identifier.

[dev@remotehost ~]$ cat ~/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1y<snip>cmaINS7Lxg1Q== [email protected]

If you use the built-in ssh configuration to define hosts, you will not need to use the -i flag when logging in. Additionally, if your private key is located at ~/.ssh/id_rsa, then the -i flag is redundant.

[dev@local ~]$ cat ~/.ssh/config
Host widgets
    HostName 10.10.10.234
    User dev
    IdentityFile ~/.ssh/something_rsa

Host sprockets.stage
    HostName stage.example.com
    User dev

Host sprockets.live
    HostName example.com
    User dev_live

[dev@local ~]$ ssh widgets
Last login: Wed Nov 9 22:07:29 2016
[dev@widgets ~]$ echo "access granted"
access granted

 

Standard POSIX/Unix utilities offer a rich feature set. The ssh application was created in the mid-nineties, and the idea of public key cryptography itself has been around since the 1970’s. Smart people have been covering the same ground for decades, so it is wise to improve our own capabilities by standing on the shoulders of giants.