Working with SSH Keys

SSH Keys are used for authentication to a remote system. Having SSH keys will relieve you from typing in your password every time you log in to a remote system if properly set up.

Quick Start

  1. If not already done: On your computer or in your thinlinc session, open a terminal and create your personal private/public key pair : 
    ssh-keygen -t ed25519

    ssh-keygen will ask for a passphrase: this should not be the same as your password (in case of a successful phishing attack, the attacker than knows your passphrase as well).

  2. Add the pub key (from your personal computer or thinlinc session) to the $HOME/.ssh/authorized_keys file on your I-MATH account. For Thinlinc: 

    cat $HOME/.ssh/id_ed25519.pub >> $HOME/.ssh/authorized_keys
chmod 600 $HOME/.ssh/authorized_keys
  3. If you log in the first time to a new SSH host, you have to accept the host key.
  4. Now, you are able to log in to host you are granted ssh access without providing a password. For more information, read the sections below.

Private/Public Key Creation

On Unix systems, the command ssh-keygen is used to create the Private/Public key pair, as shown in the example below 

$ ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/<USER>/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/<USER>/.ssh/id_ed25519.
Your public key has been saved in /home/<USER>/.ssh/id_ed25519.pub.
The key fingerprint is:
ae:73:55:6a:22:68:2e:1e:10:df:e6:a3:5d:57:07:2a <USER>@<HOST>
$

The output may differ, depending on the system you invoke the command. The example will create a ed25519 private/public key (-t ed25519).

When asked for the file in which to save the key, it is usually safe to go with the default, i.e. just pressing the ENTER key.

When asked for the passphrase, you have two choices:

  1. just pressing the ENTER key, hence not setting any passphrase, which in turn will leave your private key unprotected
  2. entering a pass phrase and thus encrypting the private key (see below for a discussion of the pros and cons of setting a pass phrase)

After You need to create the private/public key pair only once.

Using the Private/Public Key Pair for Authentication

After creating the key pair, you have to set up your account to make use of them. This is straight forward by adding your public key you created previously to the .ssh/authorized_keys file, e.g. 

$ cat $HOME/.ssh/id_ed25519.pub >> $HOME/.ssh/authorized_keys

You have to make sure this file has the proper permissions, else ssh refuses to authenticate using the private/public key mechanism. Therefore, do 

$ chmod 600 $HOME/.ssh/authorized_keys

Now, you are able to login to any system you are granted access without having to type in your password when using SSH. This is especially true if you did not set a pass phrase.

If you have set a passphrase, a dialog will pop up asking you for the pass phrase. You have to enter it only once, and it will be remembered for the duration of your session, thus any further ssh connections will work without the need to enter a pass phrase.

Using Private/Public Key Authentication from Outside Thinlinc

The above is all good and fine if you are using one of the Thinlinc terminals at IMATH. If you want to access the IT infrastructure of IMATH from the outside Thinlinc using SSH, follow those steps

  1. Create a SSH private/public key pair as described above for your private account (not your IMATH account).

  2. Copy the public key to your IMATH account for example by using scp (yes, OTP is already necessary).

  3. Log in to the IMATH IT infrastructure and type on in a terminal 
    cat <filename.publickey> >> $HOME/.ssh/authorized_keys

    Where <filename.publickey> is the file name of the public key you copied in step 2.

Why using a Passphrase?

The passphrase is used to encrypt and decrypt your private key. If somehow someone else gets possession of your private key, they will not be able to use it unless they also know the passphrase.

In case the private key is not protected by a passphrase, and the private key gets 'stolen', the thief is able to use the private key in order to log in on any computer you can, with your credentials.

So, the bottom line is to use a strong passphrase (>15 characters) to protect the private key. The security benefit outweighs the discomfort caused by the need to provide the passphrase the first time only the key is used.

ssh-agent

Under Linux: in standard use cases nothing to do here, all runs automatically.

TL;DR

The ssh-agent processes is typically not seen by a user. It will be started in the background. One purpose is to deliver the ssh passphrase on subsequent new ssh connections, so that the user does not have to provide the passphrase on each new connection. This caching stays active as long as a GUI session (=Thinlinc) is running. If a new GUI session is created, the pass phrase has to be given once again.

Storing the passphrase is also often done via a keyring service (keyring) . On Thinlinc: Typically a gnome-keyring-daemon and a ssh-agent is running per user: 

$ ps -ef | grep keyring

crose     632315       1  0 Feb09 ?        00:00:00 /usr/bin/gnome-keyring-daemon --start --components=pkcs11
crose     642701  632315  0 Feb09 ?        00:00:00 /usr/bin/ssh-agent -D -a /run/user/10688/keyring/.ssh

declare -x SSH_AUTH_SOCK="/run/user/10688/keyring/ssh"

$ eval "$(ssh-agent -s)"
$ ssh-add ~/.ssh/<private_key_file>

keychain: remote connection using ssh-agent

a) [alice@home] > b) bob@ssh.math.uzh.ch > c) charly@compute.math.uzh.ch

In case a remote login via ssh is done (a) and on the target host (b) the local keys should be used, an ssh-agent has to be started on the target host (b) and has to be supplied with the private key. 

[alice@home]
$ ssh bob@ssh.math.uzh.ch

[bob@ssh.math.uzh.ch]
$ eval `keychain --eval`
$ ssh-add ~/.ssh/id_ed25519

...

$ ssh charly@compute.math.uzh.ch