SSH, the Secure Shell, supports remote login and command-line or GUI access across the network through encrypted tunnels protected by public-key cryptography.

SSH is a useful tool that allows doing all your work in your CS account, even while working outside the lab. Using SSH has some limitations and caveats that require occasional care and attention to avoid.

Contents

SSH Availability and Support

All CS GNU/Linux workstations support incoming and outgoing SSH access. GNU/Linux and macOS include an SSH client. SSH clients can be installed in Windows (e.g., PuTTy or WSL). We will support your use of built-in SSH clients on GNU/Linux and macOS, but you are on your own if you wish to setup an SSH client in Windows or use X forwarding on macOS. Consider alternatives if SSH is not working for you.

Basic SSH Usage

Assume:

  1. You are on campus using a laptop with internet access and an SSH client installed.
  2. You wish to work on the CS lab workstation whose host name is cardinal.wellesley.edu. On the campus network, “inside” the wellesley.edu domain, you can leave off “.wellesley.edu”.
  3. Your CS username is wwellesley.

In the example below, a line prefix up through the $ symbol indicates the command prompt. Text to its right on the same line is the command. Lines not starting with this prefix are output from commands.

First login

SSH always checks that the remote machine is who you think it is. The first time you connect to any given host from here, your local SSH client has no way of knowing if this is the same machine as last time, since there was no last time.

The authenticity of host 'cardinal (149.130.136.43)' can't be established.
RSA key fingerprint is SHA256:VV6Y83C2KcoUuyZEUYRcO/G/sDWnJ/gQRav88uGoXxE
Are you sure you want to continue connecting (yes/no)?

Enter yes at the prompt to continue.1

SSH will remember this fingerprint and check it again every time you connect to cardinal in the future, aborting if it does not match.

Warning: Permanently added 'cardinal,149.130.136.43 (RSA) to the list of known hosts.

On your laptop, open a terminal and use the following ssh client command to log in to the machine cardinal as user wwellesley and establish a remote command-line shell on cardinal:

wendy@laptop: ~$ ssh wwellesley@cardinal

On your first login from your laptop, SSH will prompt for confirmation. →

On all logins, enter your CS password when SSH prompts for it:

wwellesley@cardinal's password: 

Once you enter your CS password successfully, SSH will present you with a shell running on cardinal, as if you had logged in physically and opened a terminal on cardinal. Note that the prompt shows that your shell is running on cardinal, indicated by @cardinal.

[wwellesley@cardinal ~]$

Any commands you enter here run on cardinal, manipulate files on cardinal, etc., but the interactive input/output happens here in this terminal on your laptop instead of on cardinal’s screen and keyboard.

When you are done working on cardinal log out by typing logout, exit, or Control-D at the command prompt. SSH will close the connection and exit, returning you to the command prompt on your local machine.

[wwellesley@cardinal: ~]$ logout
Connection to cardinal closed.
wendy@laptop: ~$

Remote Graphical User Interface (GUI) Access over SSH

By default, SSH opens connections that support only text command-line interaction. The -X option of the ssh client allows individual windows from the host’s window system (call X) to be piped across the network to your local client machine as well. Depending on your laptop operating system, you may need extra software on the client (your laptop) to display the GUI. For GNU/Linux, this should work with no additional software. For macOS, install XQuartz.

wendy@laptop: ~$ ssh -X wwellesley@cardinal
wwellesley@cardinal's password: 
[wwellesley@cardinal ~]$

As before, you get a command-line shell running on cardinal, but now, any GUI application that you launch from the shell (e.g., emacs) will run on cardinal as before, but will show its windows here on your local display.

If -X yields error messages, try -Y (a slightly less secure version) instead.

Public Key Authentication and Advanced SSH Usage

Password authentication works fine for SSH, but can get tedious if you use SSH frequently, although using a password manager or keychain on your laptop may help. Password authentication is also susceptible to all the issues around passwords. Public key authentication is an attractive alternative.

Public key authentication is used by our course tools under the hood to help you avoid frequent password typing for version control operations, etc.

Several SSH features, like the SSH agent, host aliases, etc., make using SSH more efficient, robust, or secure. They generally require some learning and configuration work.

We do not have time to write about public key authentication or other features now, but feel free to ask. A quick web search for “ssh key” will yield many helpful resources.

Caveats

Off-Campus SSH Access

On campus, all CS GNU/Linux lab workstations and the CS server (cs.wellesley.edu, a.k.a. tempest.wellesley.edu) are accessible by SSH.

Off campus, only cs.wellesley.edu (tempest.wellesley.edu) is accessible. To SSH to a lab workstation from off campus, SSH to cs.wellesley.edu (now you are running a shell on campus!), and from there, SSH to the lab workstation.

Dropped SSH Connections

If you close your laptop, if the WiFi drops out, or if your laptop otherwise loses network access, the SSH connection will be broken, and any in-progress remote commands will terminate in error. This includes unfortunate results like losing your last few minutes (or more) of work. Save often, definitely before closing or moving your laptop! A dropped SSH connection can also mean losing your context if you had many shells or editor windows open. Unfortunately, this happens more often than desirable in various places on campus, including in the Science Center, due to sometimes spotty WiFi coverage.

Concurrent SSH Login and Local Login

If you log in to a workstation physically and also login as the same user remotely, you may experience odd effects when trying to start potential GUI applications like emacs. Even though your command-line SSH connection may not support GUI access, emacs might happily pop up on the GUI on the screen where your are logged in physically. This is pretty annoying if you are not actually in the lab, but forgot to logout before leaving this workstation. Log out when you leave.

  1. To be 100% sure, you could check the fingerprint with the system administrator, but in practice it’s reasonable to assume that this one is right, especially since you’re connecting from on campus.