Using SSH for command line access and connection encryption
Introduction
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. 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 proxy facilities to allow access to restricted network services.
Note
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/macOS) and the latest versions of Windows 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:PRk37atjCbSlcFYdGAv35aPig8IVXEmpmn2b4nUV39YECDSA: SHA256:ETgTv/8nyOFInESYWuAhvmePFzlIOuQa9p1hPB9GcxARSA: SHA256:NucUaVxG9tHDVsIcxcOls4pumT+B3Px+2bc/YIF/F1Q |
lcmodel.cluster.fmrib.ox.ac.uk |
ED25519: SHA256:ciK5WL7dh82P/ClTnge6CLyAecpWKOvet40xgF7ay+cRSA: SHA256:uHQ9hD0VeaYm6Aq3KcRZQjmdiMlOhIubEXv/7DDTpC0ECDSA: SHA256:NpEbDm2b9K27vje/bg3GGGpXgppLH7ClLDyq+ORh3Ro |
Installing a ssh client
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.
Note
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:
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.:
Proxying/tunnelling
SSH is capable of securing other network connections that don't by default support encryption or are only visible to the remote access host - this is called proxying or tunnelling.
To access an SSH enabled computer through the access host you can use the command:
The -J option tells SSH to first connect to clint.fmrib.ox.ac.uk then from there connect onto internal.hidden.host.
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):
This would ensure that any SSH connections to any host in 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:
If the service you need to use is not SSH they you need to know what port the service is listening on, e.g. 443 for HTTPS traffic. You also need to identify a port on your local computer that isn't already in use, typically adding 8000 to the remote port number is a reasonable approach, e.g. 8443.
Openning a tunnel
The option -L creates a tunnel for you, and needs an argument, port:server:port, e.g.:
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:
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.
If you have configured proxy jumping in your .ssh/config file then you can simplify this command to:
Advanced usage
Certificate authentication
Warning
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 acquire unauthorised access.
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:
Note
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. For advice on choosing a password see the University's advice.
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:
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:
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 longer 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:
Then, create a ssh configuration file, if it doesn't exist already:
In the Host * section make sure you have the following. If it's empty, just copy and paste the following lines:
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:
You will be asked for a password to lock the store with. When you return, unlock with:
giving the password you specified to lock the store. If you want to forget the key entirely then you can do so with:
Persistent terminal sessions
The tmux program provides a text based persistent session - 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 this introduction to Tmux and the tmux wiki.
Advanced 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.
Session time out issues
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:
Set the permissions on the file:
New sessions will use these settings.