SSH Keys

Parent page: SSH

What are SSH keys?

SSH relies on public key cryptography (PK) for its security.

PK is based on a "keypair", which consists of a private part, to be kept secret, and a public part, which can be disseminated freely. Anyone can use the public key to encode a message, but the message can only be decoded with the private part. This is why PK is sometimes described as "asymmetric encryption".

PK can also be used to verify identities: if someone is claiming to be Alice, then a second party, Bob, can send Alice a message encoded with Alice's public key. If the person claiming to be Alice can tell Bob what is in the message, then that person has access to Alice's private key. In this sense, possession of a private key establishes identity.

PK systems are the basis for the SSL and TLS protocols that protect most internet traffic, such as https websites.

On our systems, PK is used in SSH several ways:

• When connecting to our systems, your ssh client normally uses our system's public key to ensure that it has connected to the real (authentic) server.
• PK is used to establish an encrypted session so that all following traffic is secure from eavesdropping.
• The remote server can use your public key to verify your identity. If that fails, the remote server can ask for your password. This is really a secondary authentication mechanism, and is less desirable because your password is handled and possibly exposed.

We strongly recommend using PK to connect to our systems. This requires some additional configuration, but is both more secure and more convenient.

To use PK, you must generate a key pair and install it on any systems you intend to connect with.

You should ideally generate a key pair on your own system - a system that you believe to be secure. The reason for this is that the private part is security-sensitive, so you should always minimize its exposure.

When generating a key, you will be prompted you for a "passphrase". This is a string that is used to encrypt the private key. You should provide a strong passphrase that is memorable, and is not a password. This passphrase offers protection if the private key file is stolen.

The specific process to generate an SSH key pair depends on the operating system you use. For the Windows Putty or MobaXterm clients, see Generating SSH keys in Windows. For a Unix-like environment (Linux, Mac, Windows Subsystem for Linux or Cygwin), see Using SSH keys in Linux. In addition if you are using the cloud, OpenStack provides a method for creating keypairs: see the ssh key pair section on the Cloud Quick Start page.

Installing your key

To install the key, you must make the target/destination system aware of the public part of your key. On ComputeCanada, we have recently added a convenient new way to do this. You should visit:

https://ccdb.computecanada.ca/ssh_authorized_keys

This page will allow you to paste in the public key. Since both the public and private keys are plain text, you can examine them - for instance,

cat .ssh/id_rsa.pub

which should show something like this:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGhczaUoV6SzR2VEf9Rp4/P9xHVU8S72CKHrwKU+Yntx user@machine

Once your public key is loaded into CCDB this way, you can use it to login to any of our clusters. At present, OpenStack (cloud systems) do not read your key from CCDB as shown in the link above.

Sometimes, you may encounter a key that is in an alternate format - for instance, as generated by some SSH clients. for instance, this is a public key in PEM format:

-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAxFm+Fbs+szeV2Vg2T5ufg8az0jD9DD/A0iNLKef2/0gPULn1ebFQ
SvQwts5ZGcza9t6l7fSKObz8FiAwXn+mdmXrxx3fQIepWa2FeCNbTkiKTTpNmERw
H0v3RR3DpJd8cpg5jdJbINlqDUPdqXxZDPIyZuHbEYUiSrb1v5zscVdgVqhJYi9O
OiEj7dPOLp1ko6s7TSgY8ejGnbmUL/gl+/dfhMNKdhLXMXWByucF1577rfAz3qPn
4JMWrG5TCH7Jj8NpIxFhkV9Qjy40Ml81yDqMlbuE9CUZzVhATe8MdIvcXUQej8yl
ddmNnAXmfTDwUd5cJ/VSMaKeq6Gjd/XDmwIDAQAB
-----END RSA PUBLIC KEY-----

and this is the same key in RFC4716 format:

---- BEGIN SSH2 PUBLIC KEY ----
AAAAB3NzaC1yc2EAAAADAQABAAABAQDEWb4Vuz6zN5XZWDZPm5+DxrPSMP0MP8DSI0sp5/
b/SA9QufV5sVBK9DC2zlkZzNr23qXt9Io5vPwWIDBef6Z2ZevHHd9Ah6lZrYV4I1tOSIpN
Ok2YRHAfS/dFHcOkl3xymDmN0lsg2WoNQ92pfFkM8jJm4dsRhSJKtvW/nOxxV2BWqEliL0
46ISPt084unWSjqztNKBjx6MaduZQv+CX791+Ew0p2EtcxdYHK5wXXnvut8DPeo+fgkxas
blMIfsmPw2kjEWGRX1CPLjQyXzXIOoyVu4T0JRnNWEBN7wx0i9xdRB6PzKV12Y2cBeZ9MP
BR3lwn9VIxop6roaN39cOb
---- END SSH2 PUBLIC KEY ----

and finally in PKCS8

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxFm+Fbs+szeV2Vg2T5uf
g8az0jD9DD/A0iNLKef2/0gPULn1ebFQSvQwts5ZGcza9t6l7fSKObz8FiAwXn+m
dmXrxx3fQIepWa2FeCNbTkiKTTpNmERwH0v3RR3DpJd8cpg5jdJbINlqDUPdqXxZ
DPIyZuHbEYUiSrb1v5zscVdgVqhJYi9OOiEj7dPOLp1ko6s7TSgY8ejGnbmUL/gl
+/dfhMNKdhLXMXWByucF1577rfAz3qPn4JMWrG5TCH7Jj8NpIxFhkV9Qjy40Ml81
yDqMlbuE9CUZzVhATe8MdIvcXUQej8ylddmNnAXmfTDwUd5cJ/VSMaKeq6Gjd/XD
mwIDAQAB
-----END PUBLIC KEY-----

This method of installing an ssh key makes the key available to all systems. This is convenient, and is often desired. There may be circumstances in which you want to install a key on a specific system. You can do this by making the key appear in a file in your home directory on that system. For instance, to install a key that only works on Cedar, you can install your public key in the .ssh/authorized_keys file on Cedar. Since your home directory is shared by all nodes on a particular system, this will permit login to any of Cedar's login nodes (but not automatically to any of the other clusters). On systems with OpenSSH, the "ssh-copy-id" command is a convenient way to properly install keys into your authorized_keys file:

 ssh-copy-id -i computecanada-key username@cedar.computecanada.ca 

The authorized_keys mechanism is standard, and almost universally used on the internet. It is however somewhat fragile: specifically, SSH is quite picky about the permissions on the authorized_keys file, as well as your home directory and the .ssh subdirectory. this is described further in using SSH keys in Linux.

Advanced Key Usage

SSH Key Agent

Although it's important to secure your private key by encrypting it with the passphrase, it is inconvenient to have to enter your passphrase every time you use the key. Rather than leaving the private key unencrypted, we strongly suggest using an SSH key agent. This allows you to type the passphrase when starting up the agent, after which the agent supplies the private key for new connections. This really just avoids storing the unencrypted private key permanently on storage, where it might be stolen or copied.

Advanced Key Generation

ssh-keygen shown above is using defaults, which are OK, but may not be ideal. for instance:

• many people prefer a different key type (rather than the RSA default):

ssh-keygen -t ed25519

• you can specify a comment for the key, which may be convenient for distinguishing among multiple keys:

ssh-keygen -C 'computecanada systems'

• you can choose the name of the key file:

ssh-keygen -F computecanada-key

(this produces a file "computecanada-key" containing the private part, and "computecanada-key.pub" for the public part.

• you can choose longer keys for some key types such as RSA:

ssh-keygen -t rsa -b 4096

SSH Key constraints =

The public key syntax permits you to provide a number of very useful constraints that limit what the key is allowed to do. By default, a public key installed without constraints can do anything. For instance, this public key:

 restrict,command="squeue --me" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGhczaUoV6SzR2VEf9Rp4/P9xHVU8S72CKHrwKU+Yntx

can only perform one simple operation (showing whether you have any jobs in Slurm). An interesting example is:

 restrict,command="/usr/libexec/openssh/sftp-server" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGhczaUoV6SzR2VEf9Rp4/P9xHVU8S72CKHrwKU+Yntx

which allows the key to be used only for SFTP, which is how sshfs works.

The key constraint can also limit which hosts can connect using the key:

 restrict,from="d24-141-114-17.home.cgocable.net" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGhczaUoV6SzR2VEf9Rp4/P9xHVU8S72CKHrwKU+Yntx

Limiting by hosts is a powerful way to minimize the danger posed by a key being compromised. In this case, the "restrict" keyword turns off "pty allocation", which makes an interactive session behave peculiarly. For a source-constrained interactive session:

 restrict,from="d24-141-114-17.home.cgocable.net",pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGhczaUoV6SzR2VEf9Rp4/P9xHVU8S72CKHrwKU+Yntx

allows pty allocation.

There are a large number of these key constraints, which are documented in the sshd man page ("man sshd" on a linux system).

PK Best Practices

- DO encrypt your private key. - DO avoid copying your private key. In particular, it should NOT appear on our clusters. - DO use ssh-agent to make encrypted keys convenient. - DO NOT use agent-forwarding if you can avoid it. With agent-forwarding, any intermediate system(s) become trusted. - DO apply constraints to your public key to make it less powerful (dangerous).

Here are some links to two-minute videos on setting up SSH keys:

• Faster and more secure SSH
• Using SSH Keys on Windows
• Using SSH Keys on Mac
• Using SSH Keys on Linux

Compute Canada Data Base