Cybersecurity Tutorial

Encrypting SSH Keys

One very important way of protecting your SSH credentials is with the use of public/private key pairs instead of a regular username and password. This allows you to authenticate yourself without transmitting any password over the network.

To take advantage of this, you simply generate a key pair with the ssh-keygen command and copy the public key to any systems onto which you wish to login. Typically, the public key goes into the file ~/.ssh/authorized_keys.

The linchpin to this mechanism is the private key. The private key must be protected with encryption. Otherwise, it becomes easy pray for credential thieves. ssh-keygen allows you to set a passphrase with which the private key will be encrypted. However, you can bypass this without entering a passphrase leaving the private key unencrypted. This of course, is not recommended and is specifically banned on NERSC systems.

With very few exceptions, all private SSH keys on NERSC systems must be encrypted. There are a few cases where unencrypted SSH private keys are necessary and allowed. However, other steps must be taken to mitigate the risk. The details of this are here(link to policy page).

Using SSH Agent

One way of reducing the number of times you need to type your password is through the use of tools like ssh-agent and the agent forwarding mechanism built into SSH. ssh-agent maintains an unencrypted copy of your private key in memory while you're logged in. This means that whenever you use ssh on that system you won't need to type your passphrase to decrypt your private key as long as ssh-agent is running.

Furthermore, the -A option to ssh allows the forwarding of access to a local ssh-agent. As the diagram shows, this allows you to login among several NERSC systems without repeatedly typing your passphrase and without the need for unencrypted private keys.

Schematic View of SSH-Agent