You are here

External login (ssh) servers

Printer-friendly versionPrinter-friendly version

This page is about the two SSH gateways to 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.

Why use an SSH gateway?

You can use an SSH gateway to login to Informatics through the firewall which protects the Informatics computer network from outside attackers. Other ways in include OpenVPN and the remote desktop service. If you're using a School of Informatics desktop computer, you don't need to use any of these things because you're already inside the Informatics firewall.

How to use an SSH gateway

For platform-specific advice, follow the links below:

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 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
Host bruegel.inf.ed.ac.uk
IP(v4) address 129.215.202.74
IP(v6) address 2001:630:3c1:202:d6ae:52ff:fed2:600a
RSA key fingerprint e9:ca:09:89:a9:42:96:c2:08:4c:8a:1f:1b:34:ee:0c
ECDSA key fingerprint d7:5b:79:84:49:94:fb:e5:9a:c7:a3:29:83:65:e4:f8
SHA256:AQiYv9ukTgLtA/EZXxyrSO9mJ0OwHl927t6bX9W0Q48
ED25519 key fingerprint f4:0e:ba:42:a5:e4:10:99:ba:67:05:e7:44:5f:9f:c2

and the second is:

Service staff.ssh.inf.ed.ac.uk
Access Staff, research postgraduates and visitors
Host hare.inf.ed.ac.uk
IP(v4) address 129.215.33.127
IP(v6) address 2001:630:3c1:33:d6ae:52ff:febd:d5e4
RSA key fingerprint MD5:cc:ba:eb:60:f0:a6:67:6b:8a:96:aa:99:b1:96:6f:d1
SHA256:nbv18KADtvamBsCakZ3TihQdq+uwRhkCUV8txn6j8OE
ECDSA key fingerprint MD5:f6:90:bf:e7:cc:8a:5b:e3:ed:42:db:3e:e1:f2:e9:93
SHA256:uh5ZXZgejqHaOrmeswbL8+6zaeM+PoUR9dzD2BrbqK0
ED25519 key fingerprint MD5:84:08:c1:e7:c7:e6:ad:6c:8f:b6:b1:95:96:a0:4f:81
SHA256:DFNrla23fx6MfhN1TfCdvI3BupnZIOtUuc/UkJa9SHM

Operating System

Both servers are running Scientific Linux version 7 which is based on Redhat Enterprise Linux (RHEL).

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: 
17/06/2018

System Status

Home dirs (AFS)
Network
Mail
Other services
Scheduled downtime

Choose a topic