SSH
Remote Access with SSH
Remote Access with SSH
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 GNU/Linux lab, including from any campus Mac computer or, in some cases, your personal computer. Using SSH has some limitations and caveats that require occasional care and attention to avoid.
Contents
- SSH Availability and Support
- Basic Command-Line SSH Usage
- Remote Graphical User Interface (GUI) Access over SSH
- Public Key Authentication and Advanced SSH Usage
SSH Availability and Support
Hosts
The host machine is the machine to which you want to connect, in this case, a CS machine where you will do your work. All CS GNU/Linux workstations support incoming and outgoing SSH access.
Clients
The client machine is the machine that you are physically using to connect to the host.
VS Code
The VS Code Remote Development Extension includes an SSH client. In Fall 2020, most students will use this and can ignore the information below unless interested in how it actually works.
The GNU/Linux and macOS environments include a built-in SSH client. On Windows, you can use the standard SSH client in the Windows Subsystem for Linux (WSL) (a mostly-sort-of-GNU/Linux environment hosted inside the Windows operating system) or install a Windows-native SSH client like PuTTy or WSL).
We will support your use VS Code Remote Development or the 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, especially if using X forwarding.
Basic Command-Line SSH Usage
Assume:
- You are logged into a campus Mac or you are on campus using a
laptop with internet access and an SSH client installed. Let’s call
that machine
client
. - You wish to work on the CS server, whose host name is
cs.wellesley.edu
. On the campus network, “inside” thewellesley.edu
domain, you can leave off “.wellesley.edu
”. - 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 'cs (149.130.15.5)' 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 cs
in the future, aborting if it does not
match.
Warning: Permanently added 'cs,149.130.15.5 (RSA) to the list of known hosts.
On your client machine, open a terminal and use the
following ssh
client command to log in to the machine
cs
as user wwellesley
and establish a remote
command-line shell on cs
:
wendy@client: ~$ ssh wwellesley@cs
On your first login from your client machine, SSH will prompt for confirmation. →
On all logins, enter your CS password when SSH prompts for it:
wwellesley@cs's password:
Once you enter your CS password successfully, SSH will present you
with a shell running on cs
, as if you had logged in
physically and opened a terminal on cs
.
Notice that the prompt shows that your shell is running on
tempest
, indicated by @tempest
.
(tempest is the other name for the main CS server,
cs.)This prompt helps tell whether you are running
commands on your machine or the remote machine.
[wwellesley@tempest ~]$
Any commands you enter here run on cs
, manipulating
files on cs
, etc., but the interactive input/output
happens here in this terminal on your client machine instead of on
cs
’s screen and keyboard.
When you are done working on cs
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@tempest: ~]$ logout
Connection to cs closed.
wendy@client: ~$
Caveats
Be aware the remote work comes with some caveats that require you to more mindful of your work than when you work directly on a physical machine.
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 client machine 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.
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 (called X
) to be piped across
the network to your local client machine as well. Depending on your
client machine operating system, you may need extra software on the client
(your client machine) to display the GUI:
- For Wellesley campus Macs and GNU/Linux, this should work with no further setup.
- For macOS on your personal computer, install XQuartz, then log out of your Mac account and log in again.
- For Windows, it depends, and it’s a bit more complicated.
wendy@client: ~$ ssh -X wwellesley@cs
wwellesley@cs's password:
[wwellesley@tempest ~]$
As before, you get a command-line shell running on
cs
, but now, any GUI application that you launch from
the shell (e.g., emacs
) will run on `cs,
but will show its windows here on your local display.
GUI Caveats
In addition to the standard caveats about remote SSH work, you should take care interacting with remote GUI applications.
- Expect that startup of remote applications will be a little slower. If you are off campus or have a poor network connection on campus, the interface may get laggy (sometimes to the point of being unusable).
- If you close the graphical window by clicking the window-close button in your operating system, it may close more forcefully than you expect. Take care to save changes regularly. Try to remember to close the application through the application’s interface instead of with the window-close button.
- If
-X
does not seem to work, 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 client machine 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.
-
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. ↩