SSH

• Server: ssh.math.uzh.ch

• Username / Password: <IMATH username> / <IMATH Password>

• Usage

  • copy files: SFTP

  • start applications (text based and gui): SSH

Filetransfer - SFTP

• Server: ssh.math.uzh.ch
• User: I-MATH account name
• Password: I-MATH password

Connections problem: Oops! Something wrent wrong

• If the SSH host keys changed, you might see an error during connecting and finaly the connection fails:

• In this case, remove the old SSH Hostkey from ~/.ssh/knownhosts

Jumphost

In some situations (e.g. security reasons) it's necessary to log in on a SSH jumhost first and from there to the final SSH destination.

• Painful

[personal computer] ssh <user>@jumphost.example.com
[jumphost] ssh <user>@sfinalhost.example.com

• Better, but still much to to type

[personal computer] ssh -J <user>@jumphost.example.com <user>@sfinalhost.example.com

• Lazy user solution:

# File `~/.ssh/config` (on personal computer):
Host jumphost
        Hostname jumphost.example.com

Host finalhost
        User <user>
        Hostname finalhost.example.com
        ProxyJump jumphost

# Just type
[personal computer] ssh finalhost

Tip: if a host shows anoying banner on logging, suppress it by:

$ ssh -o LogLevel=error <user>@<host>

# the option can also specified in ~/.ssh/config in general 
LogLevel error

# the option can also specified in ~/.ssh/config per host
Host finalhost
  LogLevel error

Shell

Examples for console on Unix(-oid) systems (Linux, OSX, ...):

• Copy the desktop from your math account to the local computer:

  • scp -r login@ssh.math.uzh.ch:Desktop .

  (replace login with your user name)

• Copy files from baxter (compute) to your local computer outside the institute. This cannot be done directly, but using an SSH tunnel:

  • PORT=1234
    BAXTER=192.168.133.16
    LOGIN=login
    ssh -f $LOGIN@ssh.math.uzh.ch -L $PORT:$BAXTER:22 -N
    rsync --partial --progress --exclude=.svn -auvz -e "ssh -p $PORT" $LOGIN@localhost:/export/user/login/data .
    CMD="ps -eo pid,args | grep 'ssh -f $LOGIN@ssh.math.uzh.ch -L $PORT:$BAXTER:22' | grep -v  'grep' | cut -c1-6"
    PID=`eval $CMD`
    kill -9 $PID
    echo `eval $CMD`

  Here, PORT specifies the port number on your system used for the SSH tunnel (any random number larger than 1024 and less than 65535 should do, if not used by another program), BAXTER is the IP address of baxter, LOGIN your math account name, /export/user/login/data is the source directory, . the destination directory. The last four lines kill the SSH tunnel. The option --partial to rsync ensures that if the transfer breaks, you can continue it later.

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. Log in to a Terminal at the Institute.
2. 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.

3. 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:

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_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

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.

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

Problems

no connection/ timeout

The SSH Server is protected with an IP blacklist.

An IP address will show up on the blacklist, if more than 3 logins (with an unknown user id) or 5 logins (with a known user id and a bad password) will occur during 5 days.

A successful login will reset the counter.

If you think your IP address has been blocked (indication: no password prompt appears), you can free your IP address:

http://www.math.uzh.ch/my > SSH > Open

Proxy by SSH (browser)

• ProxyBySsh