uog logo
School of Physics and Astronomy – computing
phas it logo

Contents

Using SSH

‘ssh’ (Secure Shell) is how you make a command-line connection from one machine to another. There are ssh clients for most OSs.

Most P&A machines can be connected to from any machine on campus, but only one or two will accept connections from off-campus. If you use the VPN (see the login notes for a discussion in context) then you are deemed to be on-campus (more or less – it's complicated). If you are not using the VPN, for whatever reason, you will have to connect through a ‘bastion’ machine; see below.

For more details, see Wikipedia, or a slightly more technical account.

The information on this page is ordered, roughly, from more- to less-important information, and from less to more arcane. Don't feel you have to read all of it at once. See below for:

When you connect to a machine using SSH, you are using a unix command-line.

How to use SSH §

Most unix machines (which includes macOS, remember) have an ssh client built in (which you will use via the Terminal). Windows 10 also has a built in OpenSSH client, which is installed by default in more recent builds (but alternative clients like Putty may still be preferable - see below).

There are many machines within different research groups in the School. Ask your colleagues or supervisor which machine you should connect to.

Suppose you aim to connect to foo.physics.gla.ac.uk, and your account in the single-signon directory is myname, then you would connect with:

home% ssh myname@foo.physics.gla.ac.uk
Password: xxxxxxxx
[...]
foo.physics%

At this point, you have command-line access to the target machine (foo.physics in this case), and can get to work.

Notes:

SSH Bastion machines §

There is a ‘bastion’ SSH machine, login.physics.gla.ac.uk, which is accessible from the open internet, and which is a backup if the VPN route won't work for some reason.

Key point 1: You typically don't need to use the bastion machine if you're on campus, and you don't need to use it if you're connecting through the VPN. That is, we expect the VPN to be your primary route for ssh access to individual machines, on the grounds that it is usually the lowest-friction mechanism. There are, however, some cases where VPN works poorly (hotel and airport WiFi are often aggravating here), and some use-cases which end up being clumsy via VPN.

Key point 2: In order to use the bastion login machine:

Re the first item, see below. Re the second item, create a ticket at the COSE IT helpdesk, asking to be added to the appropriate user group.

Short version: with the above steps complete, connect to this machine from off-campus with

% ssh -AX myname@login.physics.gla.ac.uk

(this machine is also aliased login.astro.gla.ac.uk for historical reasons).

The login machine exists purely so that you can connect to the school machines from off-campus. Typically, the first thing you will do when you connect to one of these machines is to ssh onwards, to the machine you aim to work on. You should not run jobs or otherwise work on this machine.

Notes:

X Windows (getting technical) §

If you want to be able to start an application which displays an X window (aka X11), then you will have to have an X server running on your local machine (ie, your laptop or your other off-campus machine). You may need to install further software to do this. (The -X option in the sample command above is there to help facilitate X connections).

A slightly specialised issue, so more discussion elsewhere.

SSH keys (heading for the arcane) §

It can be inconvenient to have to remember lots of passwords for remote machines. Better, is to use ssh keys. You can find lots of information about creating and using ssh keys on the internet; the following is a brief summary, with mention of some local peculiarities.

SSH keys are convenient in most cases, but as noted above they are necessary when connecting to login.physics.gla.ac.uk.

Key creation (one-time action)

To create such a key, you need to give the following command (unix):

home% ssh-keygen -t ed25519 -C my.email.address@glasgow.ac.uk

The content of the ‘comment’ after the -C option is arbitrary, and simply to help you identify or recognise this key, but your email address is a good choice. Select the defaults when prompted, and provide a good long password when prompted. This command line selects ‘ed25519’ keys; ‘rsa’ keys are the default, and OK, but somewhat dispreferred right now.

This will generate files ~/.ssh/id_ed25519 and ~/.ssh/id_ed25519.pub. The former is your ‘secret key’, protected by the password you provided; the latter is your ‘public key’, and should be a single long line of text. You want to look after the id_ed25519 file, typically leaving it on your laptop or desktop, backed up appropriately, and typically not leaving it on networked storage in your /home directory.

There's nothing Glasgow-specific about this key pair. You can install the public key on other machines to which you have ssh access.

Most modern operating systems have SSH support included out of the box, including Windows from 10 onwards using the command prompt or PowerShell, meaning that the above instructions should work in most cases like-for-like. We have a few extra Windows notes, though.

Deployment

There are two ways to deploy ssh keys:

  1. P&A machines, which use the single signon directory look in that system for the key.
  2. The typical way of using ssh keys (and the way you'll see described in online help for keys) is to put the public key – the single-line contents of the .pub file – into a file ~/.ssh/authorized_keys on the system you are connecting to. There are still some ‘old’ P&A machines which use this mechanism, as do most non-P&A systems where you may choose to use this key.

1. P&A school machines: to set up ssh keys for login.physics.gla.ac.uk, brutha.physics and other machines which use this user directory, you must go to the SSO identity page, log in, and paste in your public SSH key – the entire contents of the .pub file – where indicated.

2. Conventional (ie, non-P&A) setup (for your general information): The above is the ‘usual’ mechanism for installing SSH keys, if you're familiar with services such as github. But another common mechanism for installing keys involves placing them in a magic file on the target machine. We have some notes on that, for information.

Usage

Thereafter, you can log in to the machine by loading the key into a local ‘key agent’, supplying the long secret key password, and thereafter ssh-ing directly to the remote machine:

home% ssh-add
[enter key password]
home% ssh-add -l
2048 SHA256:XKk8SObrH+w3JECj ... [information about your key]
home% ssh myname@login.physics.gla.ac.uk
[...]
login.physics%

If your private key is called ~/.ssh/id_ed25519, then ssh-add will pick it up by default. See man ssh-add for more options.

The point is that this same password, unlocking this secret key, will allow you access to any machines which have this public key properly installed. If you lose this private key, you can still (possibly) connect using a password, but in that case you should generate a new key pair, install it on the required machines, and remove the old one.

If you use the -A option:

home% ssh -A myname@login.physics.gla.ac.uk

then the remote session will retain a connection to the ssh key agent on your local machine, which means that you can connect from that remote machine onwards, to further machines, still without using a login password. For example, you might use ssh -A myname@login.physics.gla.ac.uk to connect from outside to the bastion server, and then ssh myname@<desktop>.physics.gla.ac.uk to connect to your desktop machine.

(macOS and many Linux distributions start the ‘key agent’ fairly transparently; the Putty suite of tools has pageant as its key agent; depending on your platform you might need to Google for some details).

A caveat: using this -A option is convenient if you need to go from that remote machine onwards to others. Note, however, that the root user on that intermediate machine could in principle hijack this connection to make onward connections as you. This is of course unlikely, but if you have any reason not to trust root on that intermediate machine, then you should be aware of this.

Use the -v option to ssh to show verbose details about the connection, for debugging.

Good practices

Tunneling through SSH (eg, for VNC; arcane) §

Sometimes, you may need to connect ‘directly’ to a machine behind a bastion machine. It's possible to do this via one of the bastion machines (below, I refer to ‘your laptop’ since this is the most common case, but this can be any off-campus machine).

Plain SSH access through a bastion host

If you just want to directly ssh to an internal system, newer versions of ssh can use the ProxyJump feature, which simplifies things somewhat. You can use this on the command line:

% ssh -J user@bastion:port user@remote:port

You can usually omit the port, and the usernames if they are the same for the local and remote systems. If you need to jump through a chain of servers then you can do this as well:

% ssh -J <bastion1>,<bastion2> <remote>

You can also set this up to work automatically. Edit ~/.ssh/config and add something like

### The Bastion Host
Host bastion-host-nickname
  HostName bastion-hostname
  User username

### The Remote Host
Host remote-host-nickname
  HostName remote-hostname
  User username
  ProxyJump bastion-host-nickname

Then running

% ssh remote-host-nickname

does all the magic automatically.

This can be useful for things like git commits to an internal git server via ssh, for example.

You can also add key authentication into the mix (IdentityFile option) and forward other ports (LocalForward) this way.

Older versions of ssh can use ProxyCommand to achieve a similar goal. See https://www.ssh.com/ssh/command/ for details. Other guides are also out there, for example https://www.redhat.com/sysadmin/ssh-proxy-bastion-proxyjump.

Using VNC, Remote Desktop, SMB etc. through a SSH bastion host

This is slightly intricate, so if you think you might need to do this, consult with local IT support staff.

Note: Using the campus VPN is considerably less hassle, once you've done the initial setup, but some sites block VPN connections.

For example, you might have a VNC server running on machine foo.physics (see Wikipedia or a vncserver(1) manpage). To connect to this, you need to make a connection from your laptop VNC client to port 590x on foo.physics. The port is 5900 plus the VNC ‘display’ number, so if you have been given VNC display number :6 you will need to connect to port 5906. You can do this via login.physics by starting an ssh session from your laptop, as follows:

% ssh -L 5906:foo.physics.gla.ac.uk:5906 login.physics.gla.ac.uk

This sets up a connection from port 5906 on your local machine (such as your laptop) to port 5906 on foo.physics; not port 5906 on login.physics (look at the -L option in the ssh manpage for details). After that, you can use your usual VNC client on your laptop to connect to localhost:5906, and the connection will go, via login.physics. to the otherwise hidden machine foo.physics.

Host signatures (for the enthusiast) §

When you first ssh to a machine, you may see a message such as:

$ sshto login.physics.gla.ac.uk
The authenticity of host 'login.physics.gla.ac.uk (130.209.45.188)' can't be established.
ECDSA key fingerprint is SHA256:ArPUZV3s8WUW42uy2Wv2L40IJKiDcHL1gFbd23BdC3w.
Are you sure you want to continue connecting (yes/no)? yes

This is telling you that you haven't connected to this machine before.

If you see such a message unexpectedly, and especially if you see a message saying that the ‘fingerprint’ has changed, you should take it seriously. That appears with a rather alarming message starting

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

It may be that the machine providing the service has had to be changed. If you know that to be the case, then that's OK, and you can simply suppress the error message by editing your ~/.ssh/known_hosts file. The warning in this case will include text looking something like:

Add correct host key in /home/johnsmith/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/johnsmith/.ssh/known_hosts:3

Simply delete the indicated line – line 3 in this case – attempt to connect again, and the correct key will be added to this file during the connection (after another warning).

If you want to be paranoid, then check with this page for the correct fingerprint details, as listed below, for various possible combinations of key and hash function (ie, at least one of these should match what the warning message says):

login.physics.gla.ac.uk (and login.astro):

Note: the login.physics and login.astro machine is called haumea, and it replaced the previous machine ‘oort.astro’ in March 2023.

If you add the following to your ~/.ssh/known_hosts, as a single line (with a similar line for *.astro.gla.ac.uk), you will automatically trust any host keys signed with the school SSH key, and shouldn't be prompted for host keys in future.

@cert-authority *.physics.gla.ac.uk ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNYnX7tO3Y/q+qP/nvT3C2RY2KXBvn1UgTdLBeipBMzI8SKNA9Ji+rVyvZUe6oskcgltOSF3QumFgthmpkr2TvMrWvHtITkKFMCPcxYn1r1i9rNbNHRKa4zQg7+6qFOcAhCABaJODel8X9BlWguv3a++WoPvFbvdFR4TH3gzNyLuoK6aaB2ysiViuRpOwN77nT4Nu3WFlmkRuuJKg0Go/5UTtD5bIQ9DS0cSml+dMDz0AqexMJrEJEZIOD5mz8A0xcHNTPBdUehbUTeg780PZmtgRTEEXOAKS8EkQgcrmV2Exze5WrpZWBf+rbiSyQ+KqE6iyz8yUzUX5Em1fXbdKH P&A SSH CA