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?
- How to use an SSH gateway.
- Keep moving please.
- SSH security tips.
- Common SSH problems.
- SSH Host Information and key fingerprints.
- Operating System.
- Public Key Support.
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).
- ⇒ Remote desktop service.
- ⇒ OpenVPN - how and why.
- ⇒ Remote working.
- ⇒ Learn more about the firewall.
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:
- ⇒ Using ssh from Linux.
- ⇒ Using ssh from Mac.
- ⇒ Using ssh from Windows.
- ⇒ Using ssh from iOS and iPadOS.
- ⇒ Using ssh from Android.
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 |
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 |
ECDSA key fingerprint | SHA256:W1cfNfVjn9J/SLJB1CZiAwbO5IhAmRys+EtsKDBeUmU |
ED25519 key fingerprint | SHA256:YK6CIMrCXGKlQ1Saokfnpho5z1BLkJGCU/+wiznpp1w |
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 |
ECDSA key fingerprint | MD5:f5:b3:97:d5:c0:42:c0:52:3b:7f:cf:43:3d:c8:f1:a4 |
ED25519 key fingerprint | MD5:1b:e9:52:8f:1d:97:80:38:be:d6:10:17:4f:27:e1:ff |
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 |
ECDSA key fingerprint | MD5:3c:fc:e2:e4:7c:b6:21:c2:2a:c9:9f:ca:86:46:5f:ce |
ED25519 key fingerprint | MD5:df:1e:30:c3:0e:74:21:8e:5f:dc:90:df:21:72:78:b7 |
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.