As part of another SSH client article we potentially generated a new ssh key for use in ssh public-key authentication.
$ ssh-keygen -t rsa -b 4096 # if you don't already have a key
SSH public-key authentication has intrinsic benefits; but many see it as a mechanism for non-interactive login: you don’t have to remember, or type, a password.
This behavior is dependent, however, on having a non-encrypted private key. This is a security risk, because the non-encrypted private key may be compromised, either by accidential mishandling of the file or by unauthorized intrusion into the client system. In almost all cases, ssh private keys should be encrypted with a passphrase.
$ ssh-keygen -t rsa -b 4096 -f test Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again:
If you already have a passphrase that is not encrypted, use the
ssh-keygen to set one.
$ ssh-keygen -p -f ~/.ssh/id_rsa
Now the private key is protected by a passphrase, which you’ll be prompted for each time you use it. This is better than a password, because the passphrase is not transmitted to the server; but we’ve lost the ability to authenticate without having to type anything.
OpenSSH provides a dedicated agent process for the sole purpose of handling decrypted ssh private keys in-memory. Most Unix and Linux desktop operating systems (including OS X) start and maintain a per-user SSH agent process automatically.
$ pgrep -lfu $USER ssh-agent 815 /usr/bin/ssh-agent -l
ssh-add command, you can decrypt your ssh private key by
inputing your passphrase once, adding the decrypted key to the running
$ ssh-add ~/.ssh/id_rsa # the path to the private key may be omitted for default paths Enter passphrase for /Users/user1234/.ssh/id_rsa: Identity added: /Users/user1234/.ssh/id_rsa (/Users/user1234/.ssh/id_rsa)
The decrypted private key remains resident in the
$ ssh-add -L ssh-rsa [redacted] /Users/user1234/.ssh/id_rsa
This is better than a non-encrypted on-disk private key for two reasons: first the decrypted private key exists only in memory, not on disk. This makes is more difficult to mishandle, including the fact that it cannot be recovered without re-inputing the passphrase once the workstation is powered off. Second, client applications (like OpenSSH itself) no longer require direct access to the private key, encrypted or otherwise, nor must you provide your (secret) key passphrase to client applications: the agent moderates all use of the key itself.
The default OpenSSH client will use the agent process identified by the
SSH_AUTH_SOCK environment variable by default; but you generally
don’t have to worry about it: your workstation environment should
configure it for you.
$ echo $SSH_AUTH_SOCK /private/tmp/com.apple.launchd.L311i5Nw5J/Listeners
At this point, there’s nothing more to do. With your ssh key added to the agent process, you’re back to not needing to type in a password (or passphrase), but without the risk of a non-encrypted private key stored permanently on disk.