Individual staff member’s desktop computers themselves are supported by Center IT (ADM, CRD, VIDD) as well as Division IT groups (BSD, HB, PHS). Please see Center IT’s page in CenterNet about Laptops and Desktops for more information about support for desktop computing.
Note: If you request a Linux Desktop, Center IT will recommend that you use NoMachine from a Windows or Mac system instead as this is the most appropriate choice for most users.
Using these desktop computing resources, the following describes how to access additional computing resources at the Hutch.
SSH Clients for Remote Computing Resources
We use two common protocols to access remote compute resources. The first is the Hypertext Transfer Protocol (HTTP). This is the way your browser communicates with remote web servers. The second common protocol is Secure SHell (SSH). This is the method used to run a program on a remote server. Typically the program run is a
shell that gives you an interactive command line on the remote host.
Many programs you will want to run on a remote compute server are command line programs. These are easily executed from your
shell remote process. You use this method when opening a terminal (
shell) on your computer to connect to a remote compute server (like
rhino) and typing the name of the program or script.
rhinorefers to three locally managed servers that function as a data and compute hub for a variety of data storage resources and high performance computing (HPC). More information about
rhinoand other computing technology at Fred Hutch is available in the Large-Scale Computing section of this wiki.
You may also need graphical output (GUI) to use tools like R Studio or advanced text editors. If the remote program has a Graphical User Interface (GUI) then you use a Windows-like system called X (or X11 or XOrg or officially The X Window System). The X Window System is backward from the way you may think it works - what you run on your laptop or desktop is actually the X server, and the remote program you want to display on your device is the client. All SSH clients support tunneling the X traffic, so usually you will use SSH to start the remote GUI program, which is then displayed on your device.
This is a list of clients and servers by OS:
|OS||SSH client and
||XQuartz||OpenSSH is already installed on MacOS|
||Xorg||Already installed on supported Ubuntu systems|
||Windows Subsystem for Linux||Can be installed through “Software Center”|
puTTy is the most widely used secure shell software for Windows. You can install puTTy through “Software Center” and then simply connect to host name
The default Mac terminal is a good choice for connecting to and using SciComp Linux-based resources. We also recommend using iTerm2 for your local terminal program on your Mac. It has a richer feature set that comes in handy as your computing needs grow.
The only X11 client for Mac is XQuartz. Install XQuartz before running any Linux X11 apps such as RStudio or Matlab. Go here, and download and install the latest version of XQuartz.
After installing XQuartz just start the app. The XQuartz icon will appear in the toolbar showing that it is running. XQuartz is now running an X11 client and that is the only interaction that you need to do with XQuartz. After XQuartz is running, open the Mac terminal. The latest version of XQuartz sets the DISPLAY environment with the default Mac terminal window. We do not recommend using the terminal that comes with XQuartz.
When connecting to a
ssh always use the -Y flag to forward your Xsession to your Mac.
ssh -Y HutchID@rhino
After connecting to a
rhino verify that your X11 client is working by typing
Terminator is a convenient terminal emulator that can have multiple terminals in a single window. You can use Terminator on your Linux desktop. Windows and Mac users will need a X11 software to use SciComp resources as graphical desktop. We recommend NoMachine NX to connect to a Linux machine with Terminator.
After starting Terminator you can right click on the terminal window and either split it horizontally or vertically. This 1 min video shows you how it works:
SSH uses the TCP network protocol to make connections between systems. TCP is a persistent, stateful connection that is resilient to network interruptions. When you use SSH to run a program on a remote system (even a shell) the connection you make is tied to an SSH process on the remote machine, and all programs are children of that SSH process. If that process stops, all children stop as well. If the network connection does drop between your client and the server, your SSH process stops, and all your running programs stop.
There are several ways around this:
- NoMachine - you can use the NoMachine service
- GNU Screen or tmux - these utilities run a separate process on the remote host that is not tied to your SSH connection
- Cluster jobs - you can run your programs using our slurm cluster, which queues and executes programs independently of your SSH connection. This is best for non-interactive tasks, such as executing scripts that run from start to finish
NoMachine NX (Multi-OS)
NoMachine NX is a remote desktop software for Linux servers that gives you full remote access to a graphical user interface from Windows or Mac clients. It is installed on the SciComp session Servers
rhino03. To connect through the local Fred Hutch network or through a VPN connection please download and install the NoMachine Enterprise Client from NoMachine’s Site. Windows users can also install an older version from “Software Center”.
Configuration is very quick and the process is described in this video:
One of the nicest features of NoMachine is that you can disconnect from the server’s desktop environment and later resume the connection and continue right where you left off with all terminal windows in the same place. NoMachine from Windows or Mac is often a better choice than installing a Linux desktop.
Screen and tmux
GNU Screen and tmux are both terminal multiplexers. They run one or more shell processes on a remote system and enable you to disconnect and reconnect while leaving the process(es) running. They are both full-featured utilities that take a longer time to learn, but provide a useful set of features that aren’t available with simpler tools. Using the command below, you can get working with tmux quickly.
- Use SSH to connect to a remote system:
- On Fred Hutch systems, load the tmux environment module:
module load tmuxor just
- Start a tmux session by entering
tmux, or attach to your running tmux session using
tmux attachor just
- When in a session, typing
ctrl-dwill exit the tmux session
- Closing the lid of your laptop and/or exiting your local ssh client will leave the tmux session running
- Explicitly disconnect with
ctrl-b d(ctrl-b puts tmux into command mode, and the disconnect command is d)
A note about tmux iterm2 integration. If you are using iterm2 on a Mac, add
-CC to your tmux command. This will run a tmux console as well as tmux in that terminal. From there, you can use iterm2 commands to create a new tmux sessions in a new window (
command-n) or a new tab (
command-t). When you disconnect, simply reattach to that first tmux session, and iterm2 will re-open all your windows and/or tabs.
A note about the X Window System and terminal multiplexers. As stated above, on your laptop you are running an X server, and the remote program is a client. Terminal multiplexing allow your laptop to disconnect because the multiplexing server is running on the remote system and your device is the client. When you close your laptop, the X server stops. Clients exit at that point as a client cannot do anything without a server. See NoMachine for a workaround for X programs.
A note about screen:
ssh rhino will assign you to one of the available, specific servers (ie: rhino01, rhino02, rhino03) and screen instances are not shared across the servers. If you are interested in using screen to run a persistent session on the rhino cluster, consider:
- accessing a specific server directly eg:
- making note of which server you have logged into by
ssh rhinoand then log directly into it on your next session.
Advanced/Optional Setup for Making Things Easier: The SSH config file
Located in your home directory in the
.sshfolder is a file called
config(create it if it doesn’t exist). Your SSH client will read configuration options from this file when you use it. Any of the command line options can be specified in this config file to avoid overly complex SSH commands and make frequent use of remote servers more straightforward.
Sometimes the local user on your client device is not the same as your username on the remote system, or you have a different identity/user on a remote system. You can always
ssh firstname.lastname@example.org but you can also specify the alternate username in the config file.
|User||Your remote system username||Make ssh commands shorter and easier.|
|Identity||-i||SSH supports multiple identities and multiple keys. Use this option to specify a different SSH key from the default
If you use your password to ssh, you can certainly continue to do so. However, with a key you will have to type your password less frequently, or sometimes never. Many remote systems do not allow password authentication and require the use of keys.
Key Generations and passphrases
Create an SSH key - on MacOS or Linux, run
ssh-keygen and follow the prompts (change the file location if you are creating a new key but want to keep the old one). On Windows you will need
puttygen if using puTTY or follow the Linux instructions if using Cygwin.
You will be prompted to enter and then confirm a passphrase. This is the best protection of your ssh key, and should be a longer complex passphrase. Passphrase-less ssh keys are a security violation. See below for ways to automate local unlocking of your key to avoid having to use a complex passphrase frequently.
For extra points, read all about public key cryptography (it is very cool!).
You can copy your public key in any way you like. You can even cut-and-paste the key contents if that is easy. On Mac and Linux there is an auxiliary ssh command called
ssh-copy-key which will copy your default public key to a specified remote system (asking for your password to make the ssh connect to transfer the key). On Windows it is easiest to cut-and-paste the key into a remote session opened using a password.
No one wants to type a long passphrase every time they use SSH. Creating an SSH key with no passphrase is unsafe. There must be a better way… .
The following steps will get your MacOS device into a state where your SSH key passphrase is unlocked for you when you log into the Mac, and is automatically supplied to SSH. You will need to be logged in to your Mac, have a terminal open, and have an SSH key to start.
- Add your ‘key’ to the keychain - run
ssh-add -K <path to keyfile>the default is
~/.ssh/id_rsa. This will prompt for your passphrase, and then store it in your login keychain.
- Tell ssh to use it - add the following to your ssh config:
|UseKeychain||-o UseKeychain||yes/no||So not all config options have easy command line options. This tells your ssh client to use your keychain for the passphrase.|
|AddKeysToAgent||-o AddKeysToAgent||yes/no||Starts and ssh-agent process that will hold your unlocked key safely in memory for subsequent ssh session. Shutdown or reboot and this disappears.|
On Windows, puTTY can include a key management agent called
pageant.exe - you can download puTTY easily without it and can download it separately from the puTTY site.
Good key management
Your SSH key is actually in two parts - the public key, and the private key. Public/Private key pairs are fascinating if you are in to encryption. Be sure to search and read all about them.
Your SSH public key is not secret. It can and should be distributed. Typically your public key is added to your
~/.ssh/authorized_keys file (just add it to the end). Also, if there is a public key file in
~/.ssh on the remote system, that will work. You can email this, paste it, whatever. The trust is on the other end - any remote system that accepts your public key in agreeing that it identifies you.
Protect this. This is how you prove you own the public key. It is best to not put this anywhere other than your client device, and perhaps a backup if you like, though no lasting encryption will be done with it, so losing it will not destroy any data.
The best practices involving keys include:
- limit copies of your private key (there should be only one)
- do not enter a blank passphrase
- add your public key (cut-and-paste is fine) to
- you do not need to put both of your keys on every machine you want to use, only your client device
SSH supports an in-memory agent process that will hold your unlocked private key safely. This alleviates the need to type your passphrase for the duration of time the agent is running. See above for MacOS options. On Linux, you can run
eval $(ssh-agent) to start an agent, and
ssh-add [path to keyfile if not default] to add your key to the running agent process. On Windows, you can run puTTY’s
You can forward key requests from remote machine back to your running agent:
|ForwardAgent||-o ForwardAgent||yes/no||Forward agent requests back to the agent running on your client device.|
SSH supports using a proxy or “jump host” and can be configured to do so automatically.
|ProxyJump||-J||hostname||SSH will use the specified host as a middle-point before completing the connection to your desired host.|
You must start from a client that is running an X11 server. These include any supported Ubuntu Linux system, XQuartz on Macos, and NoMachine.
|ForwardX11||-X||yes/no||This will instruct your ssh client to set up a tunnel between the X11 server on your client device and a port on the remote machine. This port is specified by the
|ForwardTrustedX11||-Y||yes/no||Trusted X11 connections bypass X11 security features. The traffic is all still encrypted, but root on the remote machine may be able to access your client device. Some SSH implementations do not support X11 security extensions, so you must specify
Check on the remote system that you have a
DISPLAY environment variable set using
echo $DISPLAY and test X11 itself by running a simple X11 program like
All Together Now
Your SSH config supports multiple ‘stanzas’ to help you as your config may not be the same for remote hosts. The ‘stanza’ keyword is
Host. In the example below, everything from one
Host line to the next
Host line is applied the specified host.
Host *.fhcrc.org !snail.fhcrc.org ProxyJump snail.fhcrc.org Host *.fhcrc.org UseKeychain yes AddKeysToAgent yes IdentityFile ~/.ssh/id_rsa ForwardX11 yes ForwardX11Trusted yes ForwardAgent yes User <username>
This config contains all of the features mentioned above and will apply them to all
fhcrc.org hosts. It will use
snail (the SSH gateway host) for all hosts except
snail itself, as this would create a loop. You must place your username in the code above.
One final note - SSH does not do DNS resolution before consulting the config file, so typing
ssh rhino (or any short hostname without domain) will not trigger the
*fhcrc.org Host entries. You can add
rhino to the Host line to have this trigger the config as well.
Access via a Remote Location
Fred Hutch supports use of a VPN to remotely connect with our network. The network is protected by a firewall and there are currently 2 options to get access to resources inside the network, using VPN or the SSH gateway
snail.fhcrc.org. This is allowed as all SSH communication is encrypted, and the gateway system is audited.
The Fred Hutch desktop VPN service is the default choice for all remote connections. Please see the VPN page on CenterNet for more details.
Snail is a SSH gateway (also called bastion host or jump host) you can use to get remote access if you do not require the features that VPN provides. Using SSH can be easier for some users, for example if you have a network printer at home you cannot use it while connected to VPN. If you are outside the Fred Hutch network, use the following to connect to the Snail gateway first:
Once you are connected, from there you can then connect to the
Note: When you disconnect from
rhino, you will also then need to disconnect from
snailas well. To avoid this two step process, for example if you connect this way very often, you can add these 2 lines your ~/.ssh/config file you only have to type
Host rhino*.fhcrc.org ProxyCommand ssh email@example.com exec nc %h %p 2> /dev/null
If you are outside the Fred Hutch network type
ssh rhino.fhcrc.org to use the snail gateway and if you are inside type
ssh rhino to bypass the gateway.
Please see this page to learn more about ProxyCommand.
Updated: September 24, 2020Edit this Page via GitHub Comment by Filing an Issue Have Questions? Ask them here.