Setting up and using SSH Keys

References:

Motivation:

SSH connections are ephemeral and may be interrupted by network disruptions, sleeping computers, or simply the need to move to a different location. Often, you may want to have several concurrent connections to various systems. Each time you make an SSH connection, you must authenticate. It can be tedious and time consuming when you’re making so many connections with 2FA and also leaves you vulnerable to lockouts from DUO or your VT username. SSH keys are faster, less prone to human error, and when used properly can provide additional security.

Basic overview:

A Private Key + an associated Public Key = Key Pair which are created together

  • Private key (client side): This is kept secret, safe, and personal because it is proof of identity

  • Public key (server side): This is used to generate an authentication challenge from a server which should only be successfully answered by a client who possesses the associated private key

Oversimplified Steps to use keys:

  1. Generate a keypair (ssh-keygen) on your personal computer (e.g. ~/.ssh/id_<type> and ~/.ssh/id_<type>.pub)

  2. Install the contents of the public key on the server (on a line in ~/.ssh/authorized_keys)

  3. Connect!

A Helpful Idea for ARC Systems

You can use our OnDemand web interface to authenticate to ARC systems using the standard VT web login interface. From there you can get direct terminal access to ARC systems or edit the needed files (e.g. ~/.ssh/authorized_keys) via a GUI in the browser.

Best Practices

  1. Do not use PuTTY or MobaXterm clients

    1. Using these clients likely increases exposure to ongoing security risks because there are no automatic updates.

    2. Performance with these clients when connecting to ARC systems can be very poor due to the extra connections and processes they spawn.

    3. They are more difficult to support

  2. (required) Use a passphrase to protect your private keys. Without a password, you are bypassing the VT 2FA requirement for authentication.

  3. Use a modern public key cryptographic algorithm whenever possible: ECDSA or Ed25519.

    • Use RSA if needed for compatibility but only if the -b <bits> option to ssh-keygen is specified and <bits> = 3072 or 4096.

    • Ed25519 is sometimes considered better than ECDSA where it can be used because it is considered free from possible NSA influence. These two are supposed to have equivalent security levels.

    • Third, you may need to use RSA keys for compatibility but should not use keys smaller 3072 bits

  4. If your private key becomes compromised, delete it and remove any instances of the associated public key from all ~/.ssh/authorized_keys files.

  5. Make it a point to regularly delete old key pairs and generate and use new ones.

Minimum file and directory modes (permissions) for SSH Keys

Since SSH keys provide near-automatic authentication to remote systems, special care should be taken to protect the keys and SSH servers will require a certain modes for the relevant files and directories in order to ensure that they keys are protected.

You can use the “long listing” option for ls: ls -l <target> or the alias ll on ARC systems or the stat <target> command to view the modes of files and directories. Ensure that the modes are not any more permissive than the following:

  • ~ your home directory should not be writeable by the group or others 755 (drwxr-xr-x)

  • ~/.ssh directory: 700 (drwx------)

  • public keys (usually id_<type>.pub file): 644 (-rw-r--r--)

  • private keys (id_<type>): 600 (-rw-------)

See the “FILES” section of the SSH manual for a complete description.