Using SSH for command line access and connection encryption (Jalapeno)
How to use SSH to connect to Linux servers for running commands and encrypting connections to other services
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 main interactive server, jalapeno.fmrib.ox.ac.uk, even VNC have to be secured using a SSH session. This page describes how to open an SSH connection to jalapeno.fmrib.ox.ac.uk and also advanced options like password-less logins (where allowed) and X11 forwarding.
N.B. When connecting to jalapeno from a computer within the FMRIB network (not via VPN) if you use the short name 'jalapeno' you will ensure that you connect via the most optimal network.
SSH is natively supported on UNIX platforms (Linux/Mac OS X) and the latest versions of Windows 10 and 11. Windows users uncomfortable with the use of the command line may use a third-party program; we recommend puTTY for this and details follow on where to obtain and how to configure and use this program.
SSH Key Fingerprints
On first connection to a server you will be asked to trust the 'key' that the server presents, for example:
The authenticity of host 'jalapeno.fmrib.ox.ac.uk (192.168.2.5)' can't be established. ECDSA key fingerprint is SHA256:tu9+BPNYH1f0aIQAublcuchNEx/ak++YupLTeMzXW0U. 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) |
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 |
lcmodel.cluster.fmrib.ox.ac.uk | RSA: SHA256:umXshZ+p9XY00mMavsPcsQkSEIPSu798ugeQJ0I284k Legacy SSH clients: RSA: MD5:98:ff:de:1f:00:c8:b7:bf:e9:e5:61:3b:ec:58:52:89 |
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 |
Connecting from Linux/Mac OS X/Windows Command Line
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@jalapeno.fmrib.ox.ac.uk ls /home/fs0/jbloggs
The X11 windowing system employed by UNIX computers allows you to use graphical applications remotely, so you are able to run a graphical application over the network. Due to security issues with X11 require that SSH is used to secure the connection, you do this by using the -Y option to the SSH command. So for example to run FSLView on jalapeno.fmrib.ox.ac.uk, displaying on your local computer:
ssh -Y jbloggs@jalapeno.fmrib.ox.ac.uk fslview
The X11 connection stays open for as long as the SSH connection is running, so keep this terminal running to continue using the X11 applications.
The number of active X11 connections is a limited resource (shared with VNC sessions), so only use the -Y option if you intend to run a graphical program.
For further information on using X11 programs see the instructions on using X11">using X11.
X11 over ADSL and other slow connections
For slow connections (ADSL home broadband) it is usually advantageous to enable compression of the SSH connection. You can do this by using the -C switch to the ssh command line, e.g. ssh -C -Y jbloggs@jalapeno.fmrib.ox.ac.uk
Connecting from Windows with puTTY
Before you can start an SSH session to jalapeno.fmrib.ox.ac.uk you need to install an SSH terminal client. We recommend the client puTTY which can be obtained from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html. There are several downloads available from the site, choose the Windows Installer(putty-0.xx-installer.exe - where xx is the current release version) which will install puTTY system-wide and put a launcher in the Windows menu.
Once you have installed puTTY, launch it and you will be presented with the main configuration dialogue
To create a simple connection, enter the host name of the machine you wish to connect to into the hostname field, e.g. jalapeno.fmrib.ox.ac.uk, and make sure that SSH is selected. Now click on Open
To prevent you having to enter host details each time you want to connect, you can save the session settings. To do this, enter the host details as above then enter a name for the session in the Saved Sessions field and click on Save.
To load up a saved session, select the session from the list and click on Load.
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:
Host * TCPKeepAlive yes ServerAliveInterval 120
Set the permissions on the file:
chmod go= ~/.ssh/config
New sessions will use these settings.
<pclass="line867">
X11 forwarding
To use graphical X11 applications under Windows you will require a X11 server application, for example Xming-mesa, but before continuing, consider whether you can use the VNC service instead - this can sometimes be more efficient and offers other advantages (such as session persistence).
See our X11 page for installation instructions for Xming and further information on using X11.
Once you have a working X11 server installed, you can configure puTTY to enable X11 forwarding and so allow the use of graphical applications. To do this open your saved session and in the tunnels section enable the X11 forwarding tick box.
Return to the Session section and Save the session if you would like it to always forward X11.
For slow connections (dial-up or home broadband) it is usually advantageous to enable compression of the SSH connection. You can do this by loading in your session and visiting the SSH category. Click to Enable compression and then return to the Session category and Save the session.
Advanced usage
Password-less Logins
There are two methods of obtaining password-less login, public/private key cryptographic certificates or kerberos single sign-on. Kerberos can only be used on FMRIB desktops and servers; certificate identification can be used on your personal computer (or those of other departments). If you are using certificate identification it is also possible to forward your key onto subsequent hosts.
Password-less login has been disabled on jalapeno since May 2020 due to concerns that stolen keys from another facility may be used to aquire unauthorised acccess
Password-less/Certificate authentication
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 not 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).
How you setup this kind of authentication depends on your operating system, see below.
Linux/Mac OS X
Suppose you wish to connect from machine A.somewhere.com to machine B.somewhere.com without requiring a password.
Creating a key
First, create a public/private key pair on the machine you are connecting from (e.g. your laptop). On this machine run:
ssh-keygen
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.
Depending on your operating system and OS version 'XXX' may be 'rsa', 'ecdsa` or `ed25519` (or 'ecdsa-sk' or 'ed25519-sk' if you have a hardware key generator).
To transfer the public key, use ssh-copy-id:
ssh-copy-id username@B.somewhere.com
If you use the 1Password password vault software then this can manage your SSH keys (and sign Git commits) - see https://developer.1password.com/docs/ssh/manage-keys/
Starting a session
Both Linux and Mac OS X desktop environments will open a dialogue box requesting your private key passphrase the first time you attempt an SSH connection. The password will then be stored in memory for future use, so you should only be required to enter this once per desktop login session. In the case of Mac OS X it even offers to store the passphrase in your keychain to remove even this prompt.
Configuring your .ssh/config file for Keychain access
First, add the ssh passphrase to Keychain:
ssh-add -K ~/.ssh/id_rsa
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 <PATH TO IDENTITYFILE>
Replacing <PATH TO IDENTITYFILE> with the path to your private key - if you have more than one (e.g. ECDSA) then add additional IdentityFile lines for each key.
Agent forwarding
If you've logged into Jalapeno you will find that SSHing to another machine now requires a password again. You have two options, kerberos which will handle subsequent SSH 'hops' or SSH to jalapeno.fmrib.ox.ac.uk using the -A option. The latter option helps to protect from key loggers, but should only be used if you trust the owner/maintainer of the remote machine as admin users there are able to get at your key through the forwarded agent.
ssh -A -Y -C joebloggs@jalapeno.fmrib.ox.ac.uk
To then SSH to, for example jalapeno18.fmrib.ox.ac.uk from that session:
ssh -A -Y jalapeno18.cluster.fmrib.ox.ac.uk
You will now be authenticated using your private key, passed through your connection to jalapeno.
Security Warning
Be aware that the root user on the remote machine has full access to your agent (and your keys), so don't forward to a machine you don't trust.
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
Microsoft Windows with puTTY
The puTTY installer includes tools for generating (PuTTYgen) and using (Pageant) SSH keys.
Generating a key pair
To generate your own key pair, start PuTTYgen from Windows > All Programs > PuTTY > puTTYgen
In the window that opens, ensure that SSH-2 RSA is selected at the bottom of the window and the number of bits in the key is set to 1024, then click on Generate. You will be asked to move the mouse pointer around randomly in the Key section of the window to generate some random numbers for creating the key with.
Once the key has been created you need to secure it - enter a comment to help you identify it in the Key comment box (eg FMRIB Key) and then enter a key passphrase (and confirm) in the next two boxes. '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) and don't forget it as your key cannot be recovered without this password.
You can now save your private key by clicking on the Save private key button (don't bother with saving your public key as this can be recovered from the private key file). Save this somewhere secure, avoid publicly accessible folders if you have a computer shared with others. One good location is a memory stick that you can remove from the computer once the key has been loaded into memory in the next step.
At the top of this window is your public key, you need to transfer this to jalapeno.fmrib.ox.ac.uk to enable logins using the key pair. Select all the text in the Public key for pasting into OpenSSH authorized_keys file section, right click and choose Copy from the menu that pops up. Open PuTTY and connect to jalapeno.fmrib.ox.ac.uk. Now enter the following:
mkdir -p ~/.ssh chmod 700 ~/.ssh cat >> ~/.ssh/authorized_keys <<EOF
Take care, these double angle brackets are very important, if you use a single bracket (at the start of the command) you will overwrite any existing keys.
Right-click and the key should be pasted into your terminal window. Hit the return key and then type:
EOF chmod 600 ~/.ssh/authorized_keys
<pChmod command - The chmod commands make sure that your .ssh folder and the authorized_keys file within is only read/write for your account - any other permissions will cause the password-less login to fail silently.
Using your key
You now need to import your key into Pageant, run the program from Windows > All Programs > PuTTY > Pageant, the program will appear in the right-hand section of your task bar and looks like a computer with a hat on top of it. Once it is running, right click on its icon (you may have to click on the upward pointing arrow on Windows 7 to be able to find the icon) and choose Add key, find your private key file that you saved above and open it. You will be asked for the passphrase used to encrypt the key.
Now for as long as Pageant is running PuTTY will try key authorisation before requesting your password. When you have finished using jalapeno.fmrib.ox.ac.uk, please remove the key from Pageant by either right-clicking on the icon and choosing Show keys and then remove the key by selecting it from the list and click Remove Key or quit Pageant (right-click on icon and choose Exit).
Troubleshooting
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. Obviously the solution to this is to have only one key pair, which may not be possible/appropriate.
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 Mac 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 Jalapeno from a remote machine) use the command:
kinit
this will ask you for your password and create a ticket
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.
Kerberos requires your computer to be known to our password server so is not available on your personal laptop for example - use certificate authentication for these computers
Persistent Terminal Sessions
The tmux and screen programs provide a textual equivalent to VNC - you create a terminal session with jalapeno.fmrib.ox.ac.uk that will survive loss of connectivity. This is ideal for users accessing jalapeno.fmrib.ox.ac.uk via the wireless or remote access VPN service from a mobile or home based device. The terminals provided lacks some of the features that you expect from a normal SSH session (terminal scrolling won't work) and although X11 programs will work, they will not survive a dropped connection.
Below are some basic instructions for Screen.
Launching screen
Once you have opened a SSH session to jalapeno.fmrib.ox.ac.uk you can launch screen by typing in the command:
screen
this will create a new login session which will persist should you lose your connection.
Using screen
Screen has several options for managing sessions and indeed can handle more than one screen, all options are prepended with CTRL-A (hold the control key down and press the A key). For a full list of commands type CTRL-A ?.
The first thing you will notice is that you can no longer scroll back through your terminal - screen implements its own scroll buffer. To access this, type CTRL-A [ you can now scroll through the buffer to look at previous output. If you want to copy some output, place the cursor at the start of the section and hit return. Move to the end of the section and hit return to mark this point then press return to exit this mode. You can now paste whatever you just marked using CTRL-A ].
If you started screen from a SSH session with X11 forwarded you can run X11 commands, but be aware these will not survive a dropped connection.
If you need multiple screen sessions you can create a new one with the command CTRL-A c, switching between this and the original session can be achieved using CTRL-A CTRL-A. With more than two sessions you can move back and forward using CTRL-A n and CTRL-A p (next and previous respectively).
Detaching a session
If you want to leave the screen session running you can detach from the screen process using the command CTRL-A d, this will return you to the terminal prompt from which you launched screen. Closing the terminal window (or disconnecting the network) will also detach.
Attaching to a running screen session
If you only have one screen session, you can re-attach using
screen -r
If you have several screen sessions, you can find all your sessions using
screen -ls
Choose the session you wish to connect to (looks like ABCD.pts-X.jalapeno) and connect to it with
screen -r 1234.pts-5.jalapeno
Proxying/Tunnelling
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 method (hiding the complexity from your). Our servers typically run local firewalls that prevent access to network services other than SSH, for example 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 HTTP (the WWW) uses port 80. By using a fixed number a SSH client can connect without you needing to know this number. Sometimes a service may be setup to run on a non-standard port, in which case you could tell your SSH client to connect to this port.
Tunnelling using the command line
If you have access to the SSH command line program you can start a tunnel using the -L option:
ssh -L XX:host.domain:YY user@host2.domain
This command will connect to host2.domain and then use this connection to connect 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:jalapeno18.cluster.fmrib.ox.ac.uk:5922 joebloggs@jalapeno.fmrib.ox.ac.uk
would connect port 5922 on your computer to port 5922 on jalapeno18.cluster.fmrib.ox.ac.uk (which is not visible outside our firewall) using a SSH connection to jalapeno.fmrib.ox.ac.uk.
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 jalapeno.fmrib.ox.ac.uk.
ssh -A -t -l `fmribusername` jalapeno.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 jalapeno.fmrib.ox.ac.uk -W %h:%p
This would ensure that any SSH connections to hidden.domain would be proxied via jalapeno (possibly because connections are only allowed from jalapeno.fmrib.ox.ac.uk or only jalapeno.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.fmrib.ox.ac.uk is on the FMRIB internal network and you want to SSH to it then add:
Host myimac.fmrib.ox.ac.uk ProxyCommand ssh jalapeno.fmrib.ox.ac.uk -W %h:%p
A SSH/VNC tunnel would then be:
ssh -C -L 5901:localhost:5901 username@myimac.fmrib.ox.ac.uk
Tunnelling in puTTY on Windows
The tunnel syntax is the same as that for Linux / OS X, and the setup pane for this is under the SSH section to the connection setup window. Enter a port number on your computer into the Source Port input box and ether the destination computer/port combination as hostname.domain:port, eg jalapeno.fmrib.ox.ac.uk:5922. Leave the default options of Local and Auto then click Add. The port forward will appear in the list above. If you need to remove this from a connection at a later date, select it from the list and click on Remove.
You can modify the forwards in a running SSH connection by clicking on the puTTY logo in the top left of your session window and choosing Change settings. This will take you to a version of the session configuration window containing only the options you can change in a running session.