SSH Keys: Difference between revisions

''Parent page: [[SSH]]''

<!--T:1-->

SSH relies on [https://en.wikipedia.org/wiki/Public-key_cryptography 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.

To use PK, you must generate a key pair and install it 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 [[Cloud_Quick_Start#SSH_key_pair|ssh key pair]] section on the Cloud Quick Start page.

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:

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:

  -----END RSA PUBLIC KEY-----

and this is the same key in RFC4716 format:

  ---- BEGIN SSH2 PUBLIC KEY ----

   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|using SSH keys in Linux]].

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.

  ssh-keygen -t rsa -b 4096

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.

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

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).

- DO encrypt your private key.

- DO avoid copying your private key.  In particular, it should NOT appear on our clusters.