You are here

External login (ssh) servers

Printer-friendly versionPrinter-friendly version

This page is about the two SSH gateways into the School of Informatics:

  • student.ssh.inf.ed.ac.uk is for all users.
  • staff.ssh.inf.ed.ac.uk is for staff, research postgraduates and visitors.

How to use an SSH gateway

For platform-specific advice, follow the links below:

Why use an SSH gateway?

An SSH gateway is a way to login to an Informatics computer through the firewall (which protects the Informatics computer network from outside attackers). Other ways include the remote desktop service and OpenVPN.

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.

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 avoid accessing the ssh gateways from machines that you can not trust - for example those not running anti-virus software, or public machines in another institution.
Ideally, use Kerberos to authenticate your SSH connection.

You should regularly review your login activity to ensure that your account has not become compromised.

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

SSH Host Information

There are two SSH servers. The first is:

Service ssh.inf.ed.ac.uk
student.ssh.inf.ed.ac.uk
Access All users
Operating System Ubuntu Focal
Host auriga.inf.ed.ac.uk
IP(v4) address 129.215.202.38
IP(v6) address 2001:630:3c1:202:bacb:29ff:fea8:d12
RSA key fingerprint SHA256:aviY6lcxhKE0H7PofATPrxHA+j7W6WOp+aO2sTXRDWQ
6a:d6:2d:11:b6:85:9a:3b:d3:3f:e4:44:ea:18:67:13
ECDSA key fingerprint SHA256:PAvZ5s2rxWV/IyI8+sBkbZmP3iCffArdUt/IdhgBrS0
35:f8:8b:d8:04:a6:fa:8d:09:95:5f:79:dd:a6:4c:1e
ED25519 key fingerprint SHA256:WicgoLcme2IviSSQ+WUHLqDBT/VI5e05NWS/qW8g9lE
13:61:3e:9a:3b:44:a2:50:84:0c:62:cf:6b:a8:d0:a3

and the second is:

Service staff.ssh.inf.ed.ac.uk
Access Staff, research postgraduates and visitors
Operating System Ubuntu Focal
Host pegasus.inf.ed.ac.uk
IP(v4) address 129.215.32.3
IP(v6) address 2001:630:3c1:32:bacb:29ff:fea8:d6a
RSA key fingerprint MD5:d4:83:84:3d:e8:4d:06:26:ba:18:2a:a1:5a:66:36:aa
SHA256:AQL+0wyGfFepc2DseNfBm1+Qyd4ySMufbe53MTuEa+Q
ECDSA key fingerprint MD5:0a:5d:2f:6c:d6:09:b4:ae:62:a3:13:45:3f:3b:70:23
SHA256:RRQBrxsXFUjv0pK2e4aqORFbB+Poqv1Fp9hRzVj8wfA
ED25519 key fingerprint MD5:9f:69:8e:4a:86:5e:37:18:3b:b5:f6:58:cf:7a:9b:bd
SHA256:X1P5gvcPmvwYapmaSm+Y0BVvwNPauM7PH0sTomfFSB0

Operating System

Both SSH servers are running Ubuntu 20.04 (Focal Fossa). If you require access to an SL7 machine we provide sl7.login.inf.ed.ac.uk which you may access via SSH once you have logged into the main SSH service.

As these services are directly exposed to the internet the security settings are much tighter than on other DICE machines. In particular, users only have permission to list their own processes, this means that commands such as top and ps will NOT give you a complete list of all currently running processes. It is also not possible to list current logins using commands such as finger, w, who and last.

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: 
29/03/2021

System Status

Home dirs (AFS)
Network
Mail
Other services
University services
Scheduled downtime

Choose a topic