Graphical linux desktop access using x2go
This software is now deprecated within JASMIN and an alternative solution is soon to be available (May 2020): please look out for announcements.
This article explains how to use x2go to access a graphical Linux desktop environment within JASMIN. It explains:
- how x2go can help with graphical applications
- how to set up your connection to x2go server(s) within JASMIN
- how to set up an onward SSH connection from within your x2go session
Using X11 graphics over a wide-area network can be very slow, and is not recommended or supported on JASMIN. X2go helps by effectively providing an X11 server within the JASMIN environment, instead of on the end-user’s local machine at the end of a wide-area network path from JASMIN. The x2go client on the user’s local machine receives the graphical output in compressed form which is more efficient over a wide-area network.
Currently there are instances of x2go server available on
cems-sci1.cems.rl.ac.uk and on the bastion machine
At present this service should be considered “pre-production” as some aspects are still under evaluation and may be subject to change.
- See introductory article on x2go wiki at https://wiki.x2go.org/doku.php/doc:newtox2go
- You will need to install the x2go client which you can download (for Windows, Mac or Linux) from the link above
- The x2go client works with SSH key-based authentication. You should set up your connection as shown in one of the methods below.
Which server to connect to?
- If you “just” want a place to send graphical output to, but prefer to work interactively in your own terminal windows, connect to the x2go server on Host
- If you are likely to use graphical applications within the Linux desktop environment itself (e.g. web browser, text editors etc.) then connect to the x2go server on Host
Please be aware that using graphical applications to navigate files and folders in Group Workspaces or other large JASMIN file systems may cause very heavy load due to the “read ahead” required to support graphical navigation and may cause slow performance for you and other users.
Setting up your connection
1) From Inside the RAL network (e.g. STFC staff)
You can connect directly to the x2go server running on
Set set up the options as shown below, specifying the host to connect to, and "Try auto login (via SSH Agent or default SSH key)"
2) From outside the RAL network (all other users)
a) Use Proxy Server for SSH connection (DETAILS TO FOLLOW for this method)
b) set up manual SSH tunnel
2b) Using manually-created SSH tunnel
This example sets up an SSH tunnel to connect to jasmin-sci2.ceda.ac.uk
[In a terminal window on your local machine]
ssh -N -L localhost:6662:jasmin-sci2.ceda.ac.uk:22 email@example.com
(NB if you are setting up several of these for different sci machines, be sure to use a different port number for each sci machine (e.g. 6661 for sci1, 6662 for sci2).
The terminal will make a connection to the remote machine but will not display a login prompt.
[In a second terminal window]
ssh -A -p 6662 username@localhost
The authenticity of host '[localhost]:6662 ([::1]:6662)' can't be established.
RSA key fingerprint is SHA256:39mpHGnjyH7qK32Xfi1UFl6Nqls8Lwge+nMOfeKX5vs.
Are you sure you want to continue connecting (yes/no)? yes
Then logout: now that you’ve done this once, an entry for localhost:6662 will exist in ~/.ssh/known_hosts and x2go can make use of this as a proxy for jasmin-sci2.
Set up the connection page of your session preferences as follows, being sure to use the same port number on localhost as you used to set up the tunnel:
The desktop session should now start.
To locate the “Terminal” application within the KDE desktop on the server, click the Redhat Logo (bottom left), search for “terminal” and choose one of the 2 suggestions. Once set up, you should review the Connection and Input/Output preferences for your session (e.g. compression, DPI) to optimise the display quality for the performance of your connection.
To log out, click the RedHat logo [bottom left] and choose “Leave”, then Log Out / End Session:
- Do CTRL-C in First terminal window (where you set up the SSH tunnel) after you log out of your x2go desktop session.
Making onward ssh connections to other JASMIN hosts
One limitation of the current version of x2go is that SSH agent forwarding does not work. The instructions below work around this to enable you to initiate a session on the x2go server, then make a subsequent connection to another JASMIN machine.
1) In a terminal window on your local machine:
[localmachine $] ssh -A firstname.lastname@example.org
(or Putty with Agent Forwarding enabled)
[user@jasmin-sci1] $ echo $SSH_AUTH_SOCK /tmp/ssh-JChgR19617/agent.19617 # item 1: working socket
2) In X2go client:
Create X2go KDE session on jasmin-login3 in the usual way. This gives us our working X Server .
Open Xterm or Konsole
[user@jasmin-sci1] $ echo $SSH_AUTH_SOCK /home/user/.x2go/C-user-50-1456930617_stDKDE_dp32/ssh-agent.PID # item 2
But when you “ls" to test existence of this file, it will NOT exist (i.e. agent forwarding does not yet work properly)
So we generate a symbolic link to the working socket, in place of the missing file.
Replace the actual file names and paths with the ones from item 1 and item 2 in the previous steps, all on one line:
[user@jasmin-sci1] $ ln -s /tmp/ssh-JChgR19617/agent.19617 /home/user/.x2go/C-username-50-1456930617_stDKDE_dp32/ssh-agent.PID
Now we can test it:
(In a terminal window in the Linux desktop presented by x2go):
[user@jasmin-sci1] $ ssh -X -A email@example.com [user@jasmin-xfer1 ~]$ # successful onward connection using key, not asked for password
Since the link we created is a link outside the shell environment, it should persist for any ssh [ -A ] remote session from this active Linux desktop session.
Please close your session and log out from the desktop linux session when you have finished your work. Leaving your session open for long periods of time (overnight or over weekends) may unnecessarily consume system resources and can impair security.
Sessions left overnight or over a weekend will not necessarily persist. On the shared (sci) servers there are a number of background processes and timeouts which "clean up" to help keep the system stable, and it is possible that processes associated with desktop sessions can get terminated as part of this, so you should not rely on persistent sessions.