This page is about the three SSH gateways into the School of Informatics, which are:

  • student.ssh.inf.ed.ac.uk is for everyone. You need a VPN client to use it - either the University VPN or the School VPN.
  • staff.ssh.inf.ed.ac.uk is for staff, research postgraduates and visitors. You need a VPN client to use it - either the University VPN or the School VPN.
  • remote.ssh.inf.ed.ac.uk can be used without a VPN, but only by staff, research postgrads and visitors who have applied for access. (You can ask for access using the computing support form.) If you don't use remote.ssh.inf.ed.ac.uk in a while, your access will be removed, and you'll have to re-apply if you need access again. This is a security measure.

Note that if you're connected to the Edinburgh University network - including its eduroam wifi network - you will not need VPN for ssh.

Contents of this page

Scroll down to see these sections, or click one.

Why use an SSH gateway?

An SSH gateway is a way to login to an Informatics computer even when you're outside the Informatics firewall (which protects the Informatics computer network from outside attackers).

Note that if you're already using a School of Informatics desktop computer in an Informatics lab or office, you won't need any of these, because you're already inside the Informatics firewall.

How to use an SSH gateway

For platform-specific advice, see these pages:

Keep moving please

As soon as you have logged in to the SSH gateway, you should use ssh again to login to another computer. The General Purpose Servers page suggests some computers to login to, if you don't have your own Informatics computer.

To encourage you to use other computers, there isn't much software installed on the SSH gateways, and if a process uses too much of the ssh gateway server's resources it will have to be killed to keep the server working for all users.

SSH security tips

Please don't use the ssh gateways from a computer that you don't trust - for example those not running anti-virus software, or shared or public computers.

Please use Kerberos whenever possible - that way, ssh won't ask you for a password, and your password will not go over the network.

Please review your login activity regularly, to check that your account has not become compromised.

Common SSH problems

If you can't login with ssh, see these pages:

SSH Host Information and key fingerprints

There are three SSH servers. Here are their host details and key fingerprints:

The first ssh server is:

Service ssh.inf.ed.ac.uk
student.ssh.inf.ed.ac.uk
Access All users (VPN required)
Operating System Ubuntu Jammy
Host athos.inf.ed.ac.uk
IP(v4) address 129.215.202.173
IP(v6) address 2001:630:3c1:202:216:3eff:fec2:50de
RSA key fingerprint SHA256:1+YwAdrOimr4XPu4AmnGpc60pWtKYx+bdwVd7/213SE
MD5:23:ed:75:c1:48:e3:4f:d8:eb:52:92:3e:3a:73:1a:c8
ECDSA key fingerprint SHA256:W1cfNfVjn9J/SLJB1CZiAwbO5IhAmRys+EtsKDBeUmU
MD5:0e:c2:67:3d:ab:b0:f1:94:f8:ce:0c:3f:b8:8c:45:bc
ED25519 key fingerprint SHA256:YK6CIMrCXGKlQ1Saokfnpho5z1BLkJGCU/+wiznpp1w
MD5:b3:16:43:d0:21:f1:c0:cb:f4:17:cf:21:92:bb:a5:7e

and the second is:

Service staff.ssh.inf.ed.ac.uk
Access Staff, research postgraduates and visitors (VPN required)
Operating System Ubuntu Jammy
Host porthos.inf.ed.ac.uk
IP(v4) address 129.215.202.174
IP(v6) address 2001:630:3c1:202:216:3eff:fe0b:14ea
RSA key fingerprint MD5:b3:d3:3d:79:a5:79:bd:37:69:e9:0d:6c:ea:43:25:0f
SHA256:TF7xMTnG6NOMwbavr6/ZoiES87CPu3bJU5rUn9mo/fY
ECDSA key fingerprint MD5:f5:b3:97:d5:c0:42:c0:52:3b:7f:cf:43:3d:c8:f1:a4
SHA256:3kEk6wHt3ikLPxkfvq8hZGn01GAo9KeHnYj7CXrYJ7I
ED25519 key fingerprint MD5:1b:e9:52:8f:1d:97:80:38:be:d6:10:17:4f:27:e1:ff
SHA256:csyK53VbH/4IYlGLr9Stpwc9OfrzRC0UuENAxB740Pw

and the third is:

Service remote.ssh.inf.ed.ac.uk
Access Staff, research postgraduates and visitors - globally accessible on request
Operating System Ubuntu Jammy
Host aramis.inf.ed.ac.uk
IP(v4) address 129.215.202.175
IP(v6) address 2001:630:3c1:202:216:3eff:fecb:1813
RSA key fingerprint MD5:04:a6:b0:ab:75:fb:3e:9b:c3:b0:c2:f6:d9:8e:7c:e8
SHA256:iY1vCwAI5ORPAh6n2ADiksnw8jfZCWKenBwxqcelLnE
ECDSA key fingerprint MD5:3c:fc:e2:e4:7c:b6:21:c2:2a:c9:9f:ca:86:46:5f:ce
SHA256:0lB2r56T9/ACZqNNlITW+GnhEL4XInSNv9/lVuAb7LA
ED25519 key fingerprint MD5:df:1e:30:c3:0e:74:21:8e:5f:dc:90:df:21:72:78:b7
SHA256:UYAdK5JaduC2nFWVbzqp50b8zaZNEg3mrKI8XMFjS8I

Operating System

All SSH servers run Ubuntu 22.04 (Jammy Jellyfish).

Public Key Support

In theory the use of ssh public key authentication is much more secure than using passwords, especially in that it effectively prevents "brute force" style attacks. However, there are a number of issues which have led to us taking the decision to block all authentication using ssh public keys.

The main issue with ssh public key authentication is that it does not fit well with our use of AFS for home directories. Access to an AFS home directory requires the acquisition of a Kerberos ticket, this will not occur automatically when a user authenticates using a public key (but does when using a password or GSSAPI authentication). This would lead to the user having to authenticate with a password immediately after having authenticated with a public key which is confusing and negates the main reasons for using a public key.

A secondary issue is the management of the private key. If the file containing the private key is not kept secure then it can be used to gain unauthorised access to systems which hold the public key. There is the option to set a pass phrase on the private key file but not all users do this and there is no way for that to be mandated. This reduces the security of the systems holding the public key to the level of that holding the private key. The worst aspect though is that the private key can be easily copied onto many separate hosts with varying levels of security. A number of high profile organisations have suffered intrusions because of this problem.

Most people who use public keys appreciate being able to make use of the "single sign on" that it offers when used in conjunction with an ssh key agent. This means that a user only has to enter a pass phrase once to access the private key and from then on they can make as many connections as necessary without having to manually authenticate. In Informatics we use Kerberos for authentication and this provides the ability to do true "single sign on". Using GSSAPI authentication (i.e. Kerberos) is the most secure way to access the Informatics ssh service and also the most convenient once a small amount of configuration has been done on your system. Further details on how to configure your system to use Kerberos can be found elsewhere on this site.

Last reviewed: 
13/09/2023