Ssh – Network namespace, ssh, X11

network-namespacessshx11xorg

I connect (via ssh -Y ...) from a machine (=client) to another machine (=server, actually in my LAN, but it is irrelevant); then I start a new network namespace (NNS, for short) on the server, I start an xterm (from the default namespace) which is displayed perfectly on my client, and lastly, from within the xterm, I join the non-default NNS,

ip netns exec NNSName bash

I can check that I am in the new NNS,

ip netns identify $$

and I can run complex programs like, for instance, OpenVPN from within the new NNS.

The rub is here: I would like to start a graphical application (even just xeyes, for the moment) from within the new NNS, but I can't, I am always told: Unable to open DISPLAY=...

Admittedly, I have only tried the obvious:

DISPLAY=:0.0
DISPLAY=:10.0
DISPLAY=localhost:10.0
DISPLAY=localhost:20.0
DISPLAY=ClientName:10.0
DISPLAY=ClientIPAddress:10.0

always with xhost + on the client, for pure debugging purposes.

I have no problems:

connecting via ssh -Y .... from client to server, running xeyes on the server and displaying it on the client;
starting a new NNS on the server, and starting graphical applications within the NNS to be displayed on the server (i.e., in this case forget about the client).

It is when I put these two things together (ssh and namespace) that I cannot display on the client applications running in the server's new NNS.

It appears the standard TCP port 6010 belongs to the ssh session with the default NNS, while the new NNS ought to get its own. I can surely start an ssh server in the new NNS and connect directly from the client to the server's new NNS, but I was wondering: is there any easier way to do this, i.e. to display graphical applications running in the server's new NNS on the client's X11-server?

Best Answer

I was on a similar situation, here is how I work around it.

Some background: I had to span several selenium Firefox instances within namespaces for binding them with different IP addresses. But as you know I was having the error:

Error: Can't open display: localhost:10.0

Instead of working with unix sockets as Marius suggested I have just bound SSHD X11Forwarding to * instead of localhost (adding "X11UseLocalhost no" to the config) and redirected simple TCP connections with socat.

Attention to the security consequences of doing this!!!!

After this change on sshd, the DISPLAY will automatically change when you login from this:

 DISPLAY=localhost:10.0

To something like:

 DISPLAY=10.0.0.1:10.0

After that I just have to do redirect the :

ip netns exec my-NNS socat tcp-listen:6010,reuseaddr,fork tcp:192.168.5.130:6010 &

Then you should be able to work with xeyes, firefox, x-whatever-you-want...:

ip netns exec my-NNS xeyes &

And voilà!

1. Display GUIs from remotey on lappy

        lappy               .-,(  ),-.    
           __  _         .-(          )-.          remotey 
          [__]|=|  ---->(    network     )------> ____   __ 
          /::/|_|        '-(          ).-'       |    | |==|
                             '-.( ).-'           |____| |  |
                                                 /::::/ |__|

      NOTE: on lappy, `ssh` to remotey, run GUI, see GUI on lappy

Your shell's configuration files are likely setting the environment variable DISPLAY=:0. You can grep for this like so:

 $ grep DISPLAY $HOME/{.bash*,.profile*}

If that doesn't return anything back then the system you're logging into is probably the culprit. Take a peek in this directory as well.

 $ grep DISPLAY /etc/profile.d/* /etc/bash*

If you'd rather just leave this be you can override this behavior by instructing ssh to redirect X traffic back to your client system, like so:

$ ssh -X user@remoteserver

Example

Here I have a remote server that has $DISPLAY getting set to :0 similar to yours.

$ ssh -X skinner "echo $DISPLAY"
:0

But no matter, I can still invoke X applications and have them remote displayed to my system that's doing the ssh commands. I don't even have to login, I can simply run GUI's directly like so:

$ ssh -X skinner xeyes

As a bonus tip you'll probably want to change which ciphers are being used, to help improve the performance of your X11 traffic as it passes over your SSH tunnel.

$ ssh -c arcfour,blowfish-cbc -X skinner xeyes

2. Displaying GUIs on remotey

        lappy               .-,(  ),-.    
           __  _         .-(          )-.          remotey 
          [__]|=|  ---->(    network     )------> ____   __ 
          /::/|_|        '-(          ).-'       |    | |==|
                             '-.( ).-'           |____| |  |
                                                 /::::/ |__|

      NOTE: on lappy, `ssh` to remotey, run GUI, see GUI on remotey

If you're SSH'ing into remotey from lappy but would like to keep the GUIs from being displayed on lappy, then simply drop the -X switch from your ssh invoke.

$ ssh -p 6623 pinker@192.168.0.200

3. Eliminating $HOME/.ssh/config

Often times a user's $HOME/.ssh directory can introduce unknowns as to what's going on. You can temporarily silence the use of the config file in this directory like so when performing tests.

$ ssh -F /dev/null -p 6623 pinker@192.168.0.200

4. Eliminating remote shell's configs

You can use the following test to temporarily disable the shell's configuration files on remotey like so:

$ ssh -t -X -p 6623 pinker@192.168.0.200 "bash --norc --noprofile"

With the above, none of the setup should be getting sourced into this Bash shell, so you should be able to either set DISPLAY=:0 and then display GUIs to remotey's desktop.

You can use the following trick to help isolate the issue, by first removing --noprofile and trying this command:

$ ssh -t -X -p 6623 pinker@192.168.0.200 "bash --norc"

Then followed by this command:

$ ssh -t -X -p 6623 pinker@192.168.0.200 "bash --noprofile"

The first version will tell you if the problem lies in your /etc/bashrc & $HOME/.bashrc chain of configuration files, while the second version will tell you if the problem lies in the $HOME/.bash_profile configuration file.

Ssh – How to Run a GUI Application on Remote Server’s X11 Display via SSH

Try doing it like this instead:

DISPLAY=:0 gedit

Or even, just:

export DISPLAY=:0

Before you run your commands.

The reason you see Cannot open display: with no display specified after the : is because $DISPLAY is not set, as ssh isn't aware you have an X session running.

You said you don't want to use ssh -X (X11 Forwarding), but in case others end up here, you might also look into using X11 forwarding, if you want the GUI application to display on your local (client) machine rather than the remote (server) machine.