X2Go is a solution for remotely accessing X11-based desktops and applications more efficiently than using standard X11 forwarding. The X2Go server is available for Linux, and the client is available for all major desktop operating systems. Users must be authorized before they can use X2Go with SENS servers. X2Go is an open source remote desktop software for Linux that uses a modified NX 3 protocol. X2Go gives remote access to a Linux system's graphical user interface. It can also be used to access Windows systems through a proxy.
X2Go enables to access a graphical desktop of a computer over the network. The protocol is tunneled through the Secure Shell protocol, so it is encrypted.
Installation
Two parts are available in official repositories. They can be installed with the following packages:
- x2goserver - X2Go server
- x2goclient - X2Go client based on Qt5
Server side
Configure Secure Shell daemon
X2Go uses Secure Shell in order to work, so you need to configure sshd daemon to allow X11 forwarding. Follow the instructions at OpenSSH#X11 forwarding and OpenSSH#Daemon management.
Check fuse kernel module is loaded
In order for the server to be able to access files on the client computer, the fuse module is needed. One can check that lsmod | grep fuse returns a match, otherwise load the fusekernel module.
Setup SQLite database
Run the following command on the server to initialize the SQLite database (which is required in order for the x2go server to work):
Control published applications
X2Go can publish the installed applications in a menu to the client.This is controlled by the files in /etc/x2go/applications/. This location however is not created by default and can be created by creating a symlink to /usr/share/applications/.Alternatively instead of creating a symlink one could also create a folder and link only the desired applications instead.
See [1] for more information.
Start X2Go server daemon
Now all you need to do is start the system x2goserver.service.
Client side
Run X2Go Client on the client computer, the one that wants to access the server:
For the list of available options, see x2goclient(1).
ssh username@host is successful.You can now create several sessions, which then appear on the right side and can be selected by a mouse click. Each entry consists of your username, hostname, IP, and port for SSH connection. Furthermore you can define several speed profiles (coming from modem up to LAN) and the desktop environment you want to start remotely.
Access the local desktop
To access the local desktop, the one currently running on the server rather than a new one, one can choose the option 'Connection to local desktop' in 'session type' in the X2Go Client as long as the users match, if it is user foo accessing the session of user foo.
However to access the local desktop of a different user, one needs to install x2godesktopsharingAUR and launch x2godesktopsharing.
Exchange data between client and server (desktop)
On the X2Go client (e.g. laptop) local directories could be shared. The server will use fuse and SSHFS to access this directory and mount it to a subdirectory media of your home directory on the server. This enables you to have access to laptop data on your server or to exchange files. It is also possible to mount these shares automatically at each session start.
Leave a session temporarily
Another special feature of X2Go is the possibility of suspending a session. This means you can leave a session on one client and reopen it even from another client at the same point. This can be used to to start a session in the LAN and to reopen it later on a laptop. The session data are stored and administered in a SQLite database on the server in the meanwhile. The state of the sessions is protocolled by a process named x2gocleansessions.
Troubleshooting
The desktop environment does not start
Local session prevents X2Go new session
It happens that when a desktop session already runs locally and X2Go tries to start a new one, it fails.This is typically an issue related to D-Bus, see [2] for details.
If D-Bus fails to start, try using a Custom desktop command instead of the default session type. For the command, use the desktop starter as an option of dbus-launch, for example dbus-launch startxfce4. This is a way to launch a session bus instance, set the appropriate environment variables so that the new session can find the bus.
Path issue
It may be that the desktop environment's executable, startkde, startgnome or startxfce4 is not in the $PATH when logging in using SSH. In this case, do not simply choose the defaults of KDE, Gnome or XFCE but use the full paths to the executable, for example /usr/bin/startxfce4. You can also start openbox or another window manager.You should be asked for your server's password and user name, now and after login you will see the X2Go logo for a short time, and the desktop.
No selection screen in x2goclient
A regression in iproute2 causes ss to show no result when specifying the -u flag, as done in /usr/bin/x2golistdesktops. [3]
See [4], [5] for more information.
Sessions do not logoff correctly
Due to this bug the X2Go sessions might not logoff correctly. The script that initiates the session spits out many log lines that might confuse X2go. A simple workarround is to create a custom session script and redirect the log output either to a file or to /dev/null and then point your X2Go-client to this custom script.
Here is a sample script for an XFCE session:
Notification area disappeared
If you log in, but the notification area is missing, you can use exactly the same fix as for #Local session prevents X2Go new session.
Shared folders do not mount (Windows Clients)
The ssh-daemon used by the X2go windows client uses depreceated ssh-dss keys by default and because Arch does not accept them your shared folders will not mount. Check out this bug report for more information.
This can be solved on the windows side by generating different type of key:
And simply replace c:UsersUser.x2goetcssh_host_dsa_key and c:UsersUser.x2goetcssh_host_dsa_key.pub with the newly generated key files.
Other workarrounds from [6] might help, too.
Workaround for failing compositing window manager for remote session
This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.
This is useful for situations, when the computer running x2goserver is used also for local sessions with e.g. compiz as the window manager. For remote connections with x2goclient, compiz fails to load and metacity should be used instead. The following is for GNOME, but could be modified for other desktop environments. (Getting compiz ready is not part of this how-to.)
Create /usr/local/share/applications/gnome-wm-test.desktop:
Create script /usr/local/bin/gnome-wm-test.sh:
Modify the following gconf key to start the session with gnome-wm-test window manager:
/bin/bash: No such file or directory when connect (or what ever shell you use)
In you ssh configuration, if you chroot a user, this user need to have his own /bin directory inside his chrooted directory. If not, you will not be able to connect.
X2go Dpi
X2Go client: Cannot connect to remote X2Go server from local Wayland session: 'The connection with the remote server was shut down'
X2Go client launches as expected from a local Wayland session but attempting to connect to a remote X2Go server fails. This problem is usually caused by Qt on Wayland.
Follow the instructions in Desktop entries#Modify environment variables and change the lines starting with
to
X2Go client: Cannot connect to xyz:22 - Could not apply options
x2go client can not parse custom user ssh config files with tokens.
This ssh config
will result in connection failure with debug output:
This ssh config works:
X2Go server: localhost ssh tunnel on server fails with sshd error: error: connect_to localhost port xyz: failed.
X2Go server requires IPv4 for localhost ssh tunnel on the server. If you configure the sshd server to use IPv6 only
X2Go client connections will fail.
See also
- You have a Dedibox dedicated server
- You have installed Windows Server 2012 R2 on the server
This tutorial shows you how to change the language of the Windows Server 2012 R2 operating system, that is available for installation from the management console.
Change the langue of Windows
You have to enter the “Panneau de configuration” by pressing the “Windows key” + R then enter the command: control
X2go Client Windows
Go to the section “Ajouter un langue”
The list shows the language installed by default. Click on “Ajouter un langue”
In our example we want to add English as language:
If the language is used in more than one country, choose the desired country from the list:
Once the language is chosen, you have to “mount” it to the first position of the list:
Now you have to to check that the language you want to use is available, to check it go to Options
Click on télécharger et installer to download and install the language:
Download in process…
Installation of the language pack
X2go Centos 8
The language pack will be available after the next reboot:
X2go Client
X2go Client Windows
And here is the result: