Cookies on this website

We use cookies to ensure that we give you the best experience on our website. If you click 'Accept all cookies' we'll assume that you are happy to receive all cookies and you won't see this message again. If you click 'Reject all non-essential cookies' only necessary cookies providing core functionality such as security, network management, and accessibility will be enabled. Click 'Find out more' for information on how to change your cookie settings.

How to use SSH to connect to Linux servers for running commands and encrypting connections to other services

Introduc​​​​​​tion

SSH provides a way to access a secure command line interface on a remote computer and can also encrypt other network connections to services running on this or other servers. This is the only connection method we allow to our interactive access server, clint.fmrib.ox.ac.uk and is often used to secure otherwise insecure access mechanisms such as basic VNC. This page describes how to open an SSH connection to clint.fmrib.ox.ac.uk and also advanced options like password-less logins (where allowed) and X11 forwarding (deprecated and not covered here).

N.B. When connecting to clint from a computer within the FMRIB network (not via VPN) if you use the short name 'clint' you will ensure that you connect via the most optimal network.

Warning - As the clint.fmrib.ox.ac.uk server is exposed to networks outside of FMRIB's control it is subject to more stringent security update policies than other systems. The server is configured to automatically reboot each morning between 4 and 6am when security updates need to be installed. We provide a second backup host which will take over the role should there be an issue with the primary server. You should not rely on persistent connections to FMRIB via these hosts - please use the Open OnDemand system for this use case.

SSH is natively supported on UNIX platforms (Linux/Mac OS X) and the latest versions of Windows 10 and 11.

Checking Host Identity

On first connection to a server you will be asked to trust the 'fingerprint' that the server presents, for example:

The authenticity of host 'clint.fmrib.ox.ac.uk (163.1.84.7)' can't be established.
ED25519 key fingerprint is SHA256:PRk37atjCbSlcFYdGAv35aPig8IVXEmpmn2b4nUV39Y.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

To confirm you are connecting to the correct server this should match the values given in this table. Note, where multiple values are provided only one key will match, which one is dependent on the version of the SSH software you are using and thus the encryption type selected

​Host ​Key(s)
clint.fmrib.ox.ac.uk
ED25519: SHA256:PRk37atjCbSlcFYdGAv35aPig8IVXEmpmn2b4nUV39Y
ECDSA: SHA256:ETgTv/8nyOFInESYWuAhvmePFzlIOuQa9p1hPB9GcxA
RSA: SHA256:NucUaVxG9tHDVsIcxcOls4pumT+B3Px+2bc/YIF/F1Q
lcmodel.cluster.fmrib.ox.ac.uk
​ED25519: SHA256:ciK5WL7dh82P/ClTnge6CLyAecpWKOvet40xgF7ay+c
RSA: SHA256:uHQ9hD0VeaYm6Aq3KcRZQjmdiMlOhIubEXv/7DDTpC0
ECDSA: SHA256:NpEbDm2b9K27vje/bg3GGGpXgppLH7ClLDyq+ORh3Ro
Legacy hosts...
​jalapeno.fmrib.ox.ac.uk ​ECDSA: SHA256:tu9+BPNYH1f0aIQAublcuchNEx/ak++YupLTeMzXW0U 
RSA: SHA256:BLUMpCfMdbN+kfwyrL/IxKZew6ZRE7MHsfYNLSYdtrw
ED25519: SHA256:ytTX9byL8GSXMJxdK3SEcO4Pc2MyaopLjkwngmvY1cA

Legacy SSH clients:
ECDSA: MD5:e6:ff:81:a6:4f:f6:f4:6d:1f:64:4b:ad:b7:2a:6b:80 
RSA: MD5:6a:c3:83:d7:85:20:eb:43:2c:6e:56:5c:ab:06:37:9e
ED25519: MD5:b1:9a:e3:34:57:0d:f9:3c:ac:7e:b1:59:5a:c8:0b:3d 
​jalapeno18.cluster.fmrib.ox.ac.uk ​RSA: SHA256:89GL5iqNv8tFJ1lO4UjY0pflp5SbS2248Qny0ViYvus

Legacy SSH clients:
RSA: MD5:aa:2b:a6:1e:60:c3:b1:73:17:d1:f2:e7:69:96:f7:06
​jalapeno00.cluster.fmrib.ox.ac.uk ​RSA: SHA256:L/SJJTnysSrfZHI2OHK8EPJGJ9JyqXBX6fm1TVud04o
ECDSA: 256 SHA256:wlMxH/QW1n/1gd3cNEfpoTpBEEgwEyiXVpD3eAxfmOQ 
ED25519: 256 SHA256:wIu37KTuuOHrVBK93JjqS0sGODR70FPU+3SNKEkdHtk

Legacy SSH clients:
ED25519: MD5:36:6d:9c:58:0c:ab:3e:53:c3:d4:68:71:76:21:37:33
RSA: MD5:e8:d0:58:ca:95:25:2f:d1:36:53:20:fd:75:cc:d5:92 
ECDSA: MD5:37:44:36:90:7f:88:6e:a0:51:db:8c:0c:72:40:5a:e0
​cuda03.cluster.fmrib.ox.ac.uk RSA: SHA256:pWStUj6tAKMHR+5IcOX9nORju5onjgFhFZtHwIslbWE 
ECDSA: SHA256:T7w28MEhbwWI8jHY9eToSg5aGR7Xx7nYVwkdm7oE7fY 
ED25519: SHA256:OGr9ITgOpvxnaa3KnrT0JyOLotBuU77Cfu8qG78OExQ

Legacy SSH clients:
RSA: MD5:ab:f9:0f:b8:4f:88:cc:35:39:7e:50:a0:58:c0:38:88
ECDSA: MD5:38:fe:1f:8e:e5:8f:58:62:c1:d7:21:9b:c4:8c:5a:98 
ED25519: MD5:ce:34:e6:10:68:06:de:47:5c:9b:9c:8b:8c:6b:11:7b 

Installing a ssh client



Windows

Microsoft provide installation instructions and a brief introduction to their SSH client. It is based on the same software that Linux and macOS use, so the commands described here are the same.

N.B. Where a configuration file is mentioned below with '~' in it's name, '~' represents your computer account's home folder and should be replaced with '%USERPROFILE%'.

Linux/macOS


A SSH client is installed by default on Linux and macOS, so there is no need to install any additional software.

Opening a connection

To open a remote terminal session simply type: 

ssh username@hostname

in a terminal. This will open a plain, text only, connection.

If you only wish to run one command on the remote host and then exit, then this command can be appended to the ssh command e.g.: 

ssh jbloggs@clint.fmrib.ox.ac.uk ls /home/fs0/jbloggs

Proxying/Tu​​​nnelling

SSH is capable of securing other network connections that don't by default support encryption (acting as a 'proxy'). The option to run X11 programs through SSH uses this mechanism, but handles it without further configuration on your part. Our servers typically run local firewalls that prevent access to network services other than SSH, for example raw VNC; by sending your connection through SSH you can successfully get through this firewall. Before you can set this up you need know which port the service is running on and also which port on your local computer to connect the tunnel to. 

Ports are identified by a number, quite a few services will use a well known port, for example SSH uses port 22 and HTTPS uses port 443, so this is the number you would need to use at the server end, and you need to select a port on your computer that isn't already in use, adding 8000 to the server number is usually OK if you are only tunnelling that service from one server, so for HTTPS try 8443 (and for each additional server tunnel add 1, e.g. the next would be to 8444).

​Openning a tunnel

The option -L creates a tunnel for you, and needs an argument, port:server:port, e.g.:

ssh -L XX:host.domain:YY user@host2.domain

This command will connect to host2.domain and then use this connection link up port XX on your computer to port YY on the computer host.domain. host2 and host need not be the same, and indeed you can use this method to connect to computers that are not visible outside of the FMRIB firewall. For example: 

ssh -L 5922:lcmodel.cluster.fmrib.ox.ac.uk:5922 joebloggs@clint.fmrib.ox.ac.uk

would connect port 5922 on your computer to port 5922 on lcmodel.cluster.fmrib.ox.ac.uk (which is not visible outside our firewall) using a SSH connection to clint.fmrib.ox.ac.uk.

​X11 fo​​rwarding (Deprecated)




We do not support the use of X11 on our interactive server clint.fmrib.ox.ac.uk, but you may need to use this on other hosts, however, where available we recommend you use VNC instead.

Windows hosts can use the Windows Subsystem for Linux to provide X11 facilities - see Microsoft's instructions for information on installation and use.

To enable X11 over SSH you would typically add the option -Y to your ssh command:

ssh -Y username@hostname

Advanc​ed usage

Certifi​​cate authentication

Password-less login has been disabled on our externally visible host clint.fmrib.ox.ac.uk due to concerns that stolen keys from facilities our users may have accounts on may be used to aquire unauthorised acccess.

This method of authentication is achieved by creating a public/private key pair. Your identity is confirmed by encrypting a piece of information with your private key. The remote computer can then use your pre-shared public key to decrypt this and confirm your identity.

This is only secure if the private key is kept safe, which is typically achieved by encrypting the key with a passphrase which is requested the first time you open a connection. As long as the passphrase is different to your account password your account is protected to some extent from key logging attacks (although the malware may still see you type your password when you move between machines within FMRIB's network). Some password managers, for example 1Password can secure your private key, releasing on biometric confirmation.

Suppose you wish to connect from machine A.somewhere.com to machine B.somewhere.com without requiring a password.

First, create a public/private key pair on the machine you are connecting from (e.g. your laptop).

If you use 1Password, see their instructions for managing keys, if you don't then on your device run:

ssh-keygen -t ed25519

(On other sites you may see ssh-keygen used without options or with '-t rsa', this uses an older encryption key method - we recommend you use ed25519 when connecting to our servers.)

When asked for a passphrase 'DO NOT' use your FMRIB password - as discussed above we want to keep your FMRIB password safe from key loggers so choose something different (see our page on passwords for advice on choosing a secure password).

This will create two files in the folder .ssh within you home directory:

`id_XXX` 
your private key (keep this safe)
`id_XXX.pub` 
your public key which you need to transfer to the machine you wish to connect to.

XXX would ordinarily be ed25519 (or 'ed25519-sk' if you have a hardware key generator (not covered here)), but may be 'rsa' or 'ecdsa' when you are connecting to other services - you can have more than one key/type.

To transfer the public key, use ssh-copy-id:

ssh-copy-id username@B.somewhere.com

Now when you start an ssh session with a server a dialogue box requesting your private key passphrase will be presented on the screen (or for 1Password users a authorisation window requesting that you use Touch ID, or equivalent, or if biometrics are turned off, then your vault password or an 'Accept' button if the vault is already unlocked). The password will then be stored in memory for future use, (1Password requires re-authorisation each time it is used) so you should only be required to enter this once per desktop login session.

Warning:

The SSH agent has one significant flaw, it doesn't allow you to specify which key it tries when a login is started. So if you have a significant amount of keys in your local agent then it's possible for your remote account to be locked because of too many incorrect login attempts before it gets round to your key.
For 1Password users see their 'Match key with host' instructions on how to work around this, other users can update their ~/.ssh/config file as follows:

Host hostname.domain
  User remoteusername
  IdentityFile ~/.ssh/id_ed25519_hostname
  IdentitiesOnly yes

This will ensure that the identity `id_ed25519_hostname` is used when connecting to `hostname.domain`. This example also shows how to specify your remote username so that you no loneger need username@ at the start of your SSH commands.

Configuring your .ssh/config file for Keychain access

For macOS users not using 1Password, it is possible to store the private key in the macOS Keychain.

First, add the ssh passphrase to Keychain: 

ssh-add --apple-use-keychain --apple-load-keychain ~/.ssh/id_ed25519

Then, create a ssh configuration file, if it doesn't exist already: 

touch ~/.ssh/config

In the Host * section make sure you have the following. If it's empty, just copy and paste the following lines: 

Host *
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_ed25519

 If you have more than one identity file then repeat the `ssh-add` command for each addition id file and duplicate the IdentityFile lines for each.

Keeping your key secure

Once the key safe has been unlocked it will remain so until you log out of your desktop environment. If someone were to be able to use your computer without your knowledge (say you've left your computer logged in overnight) they would be able to access your FMRIB account without knowing your password. To prevent this, the ssh-add command can be used to lock the key store:

ssh-add -x

You will be asked for a password to lock the store with. When you return, unlock with: 

ssh-add -X

giving the password you specified to lock the store. If you want to forget the key entirely then you can do so with: 

ssh-add -D

​​Kerberos Single Sign-On

Kerberos is a secure authentication mechanism which all Linux and Mac OS X desktops and servers use to verify your password. When you log into one of the FMRIB desktop computers a Kerberos ticket will be generated which will allow you to log into FMRIB servers via SSH without requiring a password. The ticket has limited lifetime, so after approximately 1 day it will expire and you will then have to enter your password to SSH around (although macOS machines typically keep the ticket renewed for you). Opening an SSH session on a server does not automatically generate a Kerberos ticket.

Creating a Kerberos Ticket

To create a new ticket (for example after SSHing to clint.fmrib.ox.ac.uk from a remote machine) use the command:

kinit

this will ask you for your password will then be given a kerberos ticket.

For computers on our ethernet networks, you can create a kerberos ticket using the command:

kinit username@IPA.FMRIB.OX.AC.UK
Listing your Kerberos Tickets

To get a listing of your currently allocated tickets use the command 

klist

this gives validity dates for the tickets, allowing you to check if your ticket(s) have expired. 

Renewing a Kerberos Ticket

To renew a valid ticket use 

kinit -R

for tickets that have expired you must create a new ticket as above.

Removing kerberos tickets

To prevent use of a valid ticket on this host use

kdestroy

Persis​​tent Terminal Sessions

The tmux program provides a textual equivalent to VNC - you create a terminal session with clint.fmrib.ox.ac.uk that will survive loss of connectivity (remember this host is subject to reboot without warning overnight). This is ideal for users accessing clint.fmrib.ox.ac.uk via the wireless or remote access VPN service from a mobile or home based device. The terminal provided lacks some of the features that you expect from a normal SSH session (terminal scrolling won't work as expected).

For instructions on using tmux see the tmux wiki.

Advanc​ed tunnelling

Sometimes it may be necessary to do multiple jumps to get to your remote host, this can be done using SSH chaining. Say you need to connect to port Z on machine hidden.remote.com, which is behind gateway.remote.com, but a firewall rule on gateway.remote.com only allows connections from clint.fmrib.ox.ac.uk

ssh -A -t -l `fmribusername` clint.fmrib.ox.ac.uk -L X:localhost:10YYY ssh -A -t -l `remoteusername` gateway.remote.com -L 10YYY:localhost:10YYY ssh -t -l `remoteusername2` hidden.remote.com -L 10YYY:localhost:Z

This would allow you to connect to localhost:X and be transported to port Z on hidden.remote.com for as long as this SSH connection was open. 

Replace 10YYY with a high port number (>1024) chosen at random. If you receive any Bind failed messages this means that the chosen port is already in use, so choose a different one for this leg of the journey. 

If you need to do this regularly then you can configure your SSH settings to automatically proxy connections. In ~/.ssh/config (creating it as necessary): 

Host hidden.domain
    ProxyCommand ssh clint.fmrib.ox.ac.uk -W %h:%p

This would ensure that any SSH connections to hidden.domain would be proxied via clint (possibly because connections are only allowed from clint.fmrib.ox.ac.uk or only clint.fmrib.ox.ac.uk can see the host) and port forwarding will be setup as per the SSH command line. For example if host myimac.desk.fmrib.ox.ac.uk is on the FMRIB internal network and you want to SSH to it then add: 

Host myimac.desk.fmrib.ox.ac.uk
     ProxyCommand ssh clint.fmrib.ox.ac.uk -W %h:%p

A SSH/VNC tunnel would then be: 

ssh -C -L 5901:localhost:5901 username@myimac.desk.fmrib.ox.ac.uk

Session tim​​e out issu​es

If you have SSH sessions that sit idle for long periods you may experience time-outs on your session. Ideally you should disconnect when you aren't using the server, but if you have a good reason for staying connected you can configure the SSH client to keep the session running. To do this, create (or edit) the file ~/.ssh/config adding the following:

   
Host *
TCPKeepAlive yes
ServerAliveInterval 120

Set the permissions on the file:

chmod go= ~/.ssh/config

New sessions will use these settings. ​​

On this page