Graphical User Interfaces (GUI) #

The Wynton HPC environment supports running a graphical user interface (GUI) on Wynton HPC while viewing and interacting with it on your local computer. More specifically, and in more technical terms, Wynton HPC supports NX and X11 Forwarding protocols.

X2Go (Remote Desktop) #

Requirements #

Due to limitation in X2Go Client, it is not possible to connect to Wynton HPC when using SSH password(*). Instead, in order to connect to Wynton using the X2Go Client, you have to have a working SSH key pair set up and configured the X2Go Client.

If you are connecting to Wynton from off campus, you will also have to use Two Factor Authentication (2FA) for Wynton. This is not needed if you are connected via the UCSF VPN.

Setup of the X2Go Client (once) #

First, you will need to install the X2Go Client on your local computer. For instructions on how to do this, see Installing X2Go Client. When you first run x2goclient:

  1. Use the menus to create a New Session …
  2. Pick a Session name, e.g. Wynton HPC
  3. Set the Host to a development node: dev1, dev2, dev3, or gpudev1pdev1 or pgpudev1
  4. Set the Login to your Wynton HPC username, e.g. alice
  5. In the Use RSA/DSA key for ssh connection, enter the path to the your private SSH Key.
  6. Select Try auto login (via SSH Agent or default SSH key)
  7. Check Use Proxy server for SSH connection
  8. Then in the Proxy server section:
    • Check Same login as on X2Go Server
    • Check Same password as on X2Go Server
    • Set Host to a Wynton HPC login node: or
    • In the RSA/DSA key: field enter the path to your private SSH Key.
    • Select SSH Agent or default SSH key
  9. In the Session type section, choose MATE

Logging in #

With the above setup, the following instructions opens a remote desktop window on your local computer:

  1. Launch the X2Go Client on your local machine
  2. Double click the session configured (above)
  3. Dialog Enter Passphrase to decrypt a key: Enter ssh key passphrase, if set, otherwise just ENTER
  4. If connecting from an off-campus location and not already authenticated:
    • Dialog Choose DUO Authentication Method: Perform Duo Authentication as prompted
    • Dialog Remember connection authentication for 12 hours? [y/N]: Answer y (this is important, it does not work if you choose ‘no’)
  5. Dialog MATE on dev2: Enter your Wynton HPC password (this happens for unknown reasons to some users, even when using SSH keys)
  6. Dialog Enter passphrase to decrypt a key: Enter ssh key passphrase, if set
  7. Dialog Enter passphrase to decrypt a key: Enter ssh key passphrase, if set (yes, twice)
  8. Wait! It will take a long time before the MATE window to appear, looks like an empty Linux desktop. Resize the window if you wish, and start up terminals, web browsers, etc. as you would do on your regular desktop.

X11 Forwarding over SSH #

You can also use X11 forwarding over the SSH connection used to connect to Wynton HPC.

Verify that you have a working X11 server (once) #

Note that, to do this, you will need to be running an X server on your local machine. You can check this by verifying that environment variable DISPLAY is set on your local computer, e.g.

{local}$ echo "DISPLAY='$DISPLAY'"

If DISPLAY is empty, that is, you get:

{local}$ echo "DISPLAY='$DISPLAY'"

then you don’t have a local X server set up and the below will not work. If you are on macOS, we recommend installing open-source XQuartz.

Log into the cluster with X11 forwarding #

To setup the X11 forwarding when connecting to the cluster, add option -X, or -Y on macOS, to your SSH call. For performance reasons, we will also add option -C to enable SSH compression. By using compression, the responsiveness and latency in GUIs will be much smaller - our benchmarks show a 5-7 times improvement when connected via the UCSF VPN (~60 Mbps download and ~5 Mbps upload). To login with X11 forwarding and compression enabled, do:

{local}$ ssh -X -C password: 
[alice@log1 ~]$ echo "DISPLAY='$DISPLAY'"
[alice@log1 ~]$ 

By checking that DISPLAY is set, we know that X11 forwarding is in place. If DISPLAY is empty, then make sure you have specified -X (or -Y).

Log into a development node with X11 forwarding #

Now, since we should not run anything on the login nodes, the next step is to head over to one of the development nodes. When doing so, we have remember to keep using X11 forward, that is, we need to use -X also here;

[alice@log1 ~]$ ssh -X dev1
alice1@dev1:s password: 
[alice@dev1 ~]$ echo "DISPLAY='$DISPLAY'"
[alice@dev1 ~]$ 

Comment: There is no need to use SSH compression in this second step. If used, it might even have a negative effect on the X11 latency.

Now we have an X11 forward setup that runs all the way back to our local computer. This will allow us to open, for instance, an XTerm window that runs on dev1 but can be interacted with on the local computer;

[alice@dev1 ~]$ xterm
[ ... an XTerm window is opened up ... ]

If you get an error here, make sure that DISPLAY is set and non-empty.

Tips: You can login into a development node in a single call by “jumping” (-J) via the login node, e.g.

{local}$ ssh -X -C -J alice@dev1
[alice@dev1 ~]$