Export X from server to local system

Every now and then I have to verify a graphical application running on the remote server. That must be done via graphical output, no way to do it from the command line.

For those scenarios I usually export the X from the remote interface to my local workstation. That can be done simply by issuing:

ssh -X -C -c blowfish <username>@<remote-server>

From the ssh man page:

-X:
     Enables X11 forwarding. (X11 forwarding should be enabled
     with caution. Read the man page);
-C:
    Requests compression of all data;
-c cipher_spec:
    Selects the cipher specification for encrypting the session.
    The supported values are “3des”, “blowfish”, and “des”.

<EDIT>
Using a remote connection to a xenial ppc64el server from a Fedora24, I got the following error:

Unable to negotiate with <server>: no matching cipher found. 
Their offer: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,
aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

Adding blowfish-cbc (taken from the openssh man page) to the ssh_config files did not “blow it away” though. So to get rid of the error I simply removed the ‘blowfish‘ cipher type, and left the task to the system.
</EDIT>

After getting access you won’t notice any difference, for the result is the same as as regular ssh connection. The difference relies on the behavior when you run a graphical application from the CLI. Here I am running HardInfo in the remote system as an example:

hardInfo_3.png

Graphical interface being exported to a local workstation from a remote Ubuntu ppc64el system.

Please read the ssh man page carefully to get clearer all security considerations and get advantage of the X exporting when running graphical applications.

Have a nice day.

3 thoughts on “Export X from server to local system

  1. Thanks,
    Well, it was an easy choice for it was a legacy procedure we had in the team, and I was not there when the discussion about that happened, so I cannot answer with further details. But as for general reasons, as far as I understand, the team decided it was the fastest option in terms of interacting with the software being tested, just so to avoid bigger lags with the server.

    Like

Leave a comment