ssh

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

Log in to a Terminal at the Institute.
Type in
```
ssh-keygen -t rsa -b 2048
```
ssh-keygen will ask some questions. Just press ENTER. This will create a Private/Public key pair without passphrase.

Still in the terminal, type in

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

and

chmod 600 $HOME/.ssh/authorized_keys

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 rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/home/<USER>/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/<USER>/.ssh/id_rsa.
Your public key has been saved in /home/<USER>/.ssh/id_rsa.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 RSA private/public key (-t rsa) with 2048 bits (-b 2048).

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:

just pressing the ENTER key, hence not setting any passphrase, which in turn will leave your private key unprotected
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_rsa.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 IMATH

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

Create a SSH private/public key pair as described above for your private account (not your IMATH account).
Copy the public key to your IMATH account for example by using scp.
Log in to the IMATH IT infrastructure and type on in a terminal
```
cat <publickey> >> $HOME/.ssh/authorized_keys
```
Where <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

To use a passphrase, stored and offered via keyring:

Keyring should be opened: this happens typically shortly after login if the first application tries to access the keyring.
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

The bourne shell should have the SSH_AUTH_SOCK variable set, to inherit expecially to all child shells.

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

Normally a Gnome/Cinnamon session starts during login the gnome-keyring process.
Manually set for current terminal https://www.commithub.com/add-your-ssh-key-to-the-ssh-agent/

$ 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_rsa

...

$ ssh charly@compute.math.uzh.ch