You are here

Using ssh from Linux

Most Linux distributions have an SSH client installed by default. For Fedora and Redhat it is in the openssh-clients package; on Debian and Ubuntu it is in the openssh-client package.

Before you can use ssh, you must be using a VPN - either the University VPN or the School's OpenVPN. The VPN page can help with that.

Then, to access an Informatics SSH server, start a terminal, and enter something like the following (replacing 'yourusername' with your DICE Informatics username):


There are several SSH servers - see the External login servers page for the names.

How to manage your host keys

One of the ways in which SSH ensures the security of your connection is with host keys. When you first login to a machine you will be prompted to accept the key. The dialog will look something like this:

The authenticity of host ' (2001:630:3c1:202:bacb:29ff:fea8:d12)' can't be established.
ECDSA key fingerprint is SHA256:PAvZ5s2rxWV/IyI8+sBkbZmP3iCffArdUt/IdhgBrS0.
Are you sure you want to continue connecting (yes/no/[fingerprint])? 

Once you have entered yes at the prompt, you will be informed that the key has been accepted:

Warning: Permanently added ',2001:630:3c1:202:bacb:29ff:fea8:d12' (ECDSA) to the list of known hosts.

After this key has been accepted, you will be alerted if it ever changes. This is designed to prevent man-in-the-middle attacks. It is rarely necessary to change a host key, but when it happens - for instance due to a reinstallation of the machine - the Computing Team will inform all users by email and the fingerprint of the new host key will be specified. The list of SSH server host keys is available for reference.

After a host key has changed, the first time you attempt to login you will be presented with a rather alarming looking dialog like this:

Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/yourusername/.ssh/known_hosts to get rid of this message.
Offending key in /home/yourusername/.ssh/known_hosts:3
RSA host key for has changed and you have requested strict checking.
Host key verification failed.

If you have not received any message from the Computing Team containing details of host key changes, you should not proceed any further. You should immediately contact the support team, giving full details of which service you were attempting to access, and what happened.

If you are happy that this change in host key is legitimate, then you can go ahead and remove the old keys which are stored in your known_hosts file. This is done using the ssh-keygen command. For example:

ssh-keygen -R

Once you have removed the old key, at the next login you will be prompted to accept the new key in the same way as described earlier. You might also get a warning about the key differing for the IP address of the server, like this:

Warning: the RSA host key for '' differs from the key for the IP address ''
Offending key for IP in /home/yourusername/.ssh/known_hosts:3

This warning can be stopped by removing the key stored for that IP address in a similar way to before:

ssh-keygen -R

How to protect your ssh data

The openssh client stores its configuration information in the ~/.ssh directory in your home directory. It's important to protect this directory so that it's not readable by other users. To do that, run this command on your computer:

chmod g-rwx,o-rwx ~/.ssh

When a home directory is in AFS, there are additional AFS ACLs to consider. Since AFS ACLs are directory based, and are stored separately, the Unix permissions are not sufficient to ensure that other users cannot read your files. You should also do:

fs setacl -dir ~/.ssh/ -acl system:authuser none system:anyuser none

IPv6 and IPv4

The SSH servers are accessible using IPv6. Client software will typically prefer IPv6 where it is available, and this can cause problems if your internet provider doesn't properly support this protocol. If that happens, you can force the SSH client software to use IPv4. This can either be done by specifying the -4 option on the command line, or by having the following in your .ssh/config file.

Host *
  AddressFamily inet

Alternatively, to force the client to use IPv6, use the -6 command line option or put this in .ssh/config:

Host *
  AddressFamily inet6

Using GSSAPI (Kerberos) authentication

The recommended way to authenticate with the Informatics SSH service is to use GSSAPI wherever possible. This is highly secure and, as it supports single-sign-on, it's very convenient too, once you have a Kerberos client installed and configured on your system. See the notes on how to configure Kerberos for your machine.

Before making your first ssh connection you need to authenticate to the Informatics Kerberos service, like this:

kinit -f yourusername@INF.ED.AC.UK

You will be prompted to enter your Informatics password. After you have successfully authenticated you will have the convenience of single-sign-on: you can make as many ssh connections as you like, without being prompted for a password, for the lifetime of the Kerberos ticket.

To make it all work correctly you need to set some configuration options for your ssh client. This is done by editing the file .ssh/config in your home directory. Note that the file will not exist if you have not previously needed to set any options. You need to add a stanza like this:

Host *
  User yourusername
  GSSAPIAuthentication yes
  GSSAPIDelegateCredentials yes

where you must set your username appropriately. After that you can login to Informatics machines without having to give your username or password.

If, on connecting with ssh to an Informatics machine, you do not have access to your home directory and see a message like this:

Could not chdir to home directory /afs/ Permission denied

... this is probably because you have not obtained forwardable tickets. This is the default on most OSes, but if you experience this, you can explicitly obtain forwardable tickets using kinit -f

Your Kerberos credentials will expire after 18 hours. This will not affect your SSH connection, but it will result in the loss of access to your home directory. By default, renewing your credentials using kinit on the client side will not help. To solve this problem the GSSAPIRenewalForcesRekey option must be enabled. This can be done in your ~/.ssh/config file like this:

Host *
  GSSAPIRenewalForcesRekey yes

Please note that not all ssh implementations support GSSAPIRenewalForcesRekey. For example, the version included with macOS does not. If you see an error message like:

line 5: Bad configuration option: gssapirenewalforcesrekey

... then remove the line from your configuration.

Forwarding to your desktop

If you have a desktop machine on the Informatics network, you can forward a connection to it through one of the SSH hosts. Add a stanza like this to your SSH client configuration (possibly incorporating previous suggestions above).

Host mydesktop
  User myusername
  ForwardX11 no
  ProxyCommand ssh -x -W %h:%p

Replace mydesktop with the name of your desktop machine. If you do not have permission to use the staff SSH server then replace with

Note that if you are not using GSSAPI authentication you will be prompted for the password twice, once for each machine.

Last reviewed: 

System Status

Home dirs (AFS)
Other services
University services
Scheduled downtime

Choose a topic