You are here

External login (ssh) servers

Printer-friendly versionPrinter-friendly version

This page is about our two SSH gateways - for all users and for staff, research postgraduates and visitors. The Informatics computer network is protected by a firewall so any login from outside that network has to use either an SSH gateway or OpenVPN or RDP.

General information about using School services from outside can be found in the remote working page.
For platform-specific advice; follow the links below:

Please note: these servers are just gateways to other DICE servers. To improve security they only have a small set of installed software. If a process uses too much of the ssh server's resources it will have to be killed to keep the server working for all users. Please avoid accessing these servers from machines that you can not trust (e.g. those not running anti-virus software; public machines in another institution). Ideally, use a Kerberos-authenticated SSH connection. You should regularly review your login activity to ensure that your account has not become compromised. If your ssh connection from home seems to time out and disconnect quickly, see ssh timeouts from home for a solution. If an ssh login attempt fails with the message ssh_exchange_identification: read: Connection reset by peer then see this advice page.

SSH Host Information

There are two SSH servers:

Host IP Address Key Fingerprint Service Name(s) Access / 2001:630:3c1:202:d6ae:52ff:fed2:600a

RSA - e9:ca:09:89:a9:42:96:c2:08:4c:8a:1f:1b:34:ee:0c

ECDSA - d7:5b:79:84:49:94:fb:e5:9a:c7:a3:29:83:65:e4:f8 /

ED25519 - f4:0e:ba:42:a5:e4:10:99:ba:67:05:e7:44:5f:9f:c2 and
All users / 2001:630:3c1:33:d6ae:52ff:febd:d5e4

RSA - MD5:cc:ba:eb:60:f0:a6:67:6b:8a:96:aa:99:b1:96:6f:d1 / SHA256:nbv18KADtvamBsCakZ3TihQdq+uwRhkCUV8txn6j8OE

ECDSA - MD5:f6:90:bf:e7:cc:8a:5b:e3:ed:42:db:3e:e1:f2:e9:93 / SHA256:uh5ZXZgejqHaOrmeswbL8+6zaeM+PoUR9dzD2BrbqK0

ED25519 - MD5:84:08:c1:e7:c7:e6:ad:6c:8f:b6:b1:95:96:a0:4f:81 / SHA256:DFNrla23fx6MfhN1TfCdvI3BupnZIOtUuc/UkJa9SHM

NEW Staff, research postgraduates and visitors

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: 

System Status

Home dirs (AFS)
Other services
Scheduled downtime

Choose a topic