SSH - How to make X applications run on client?

Question

I have the reverse problem that most people seem to be having. If I start an X application while logged into ssh, it displays on the server(host) machine instead of the client(local). This is the command I use

$ ssh -X -p 6623 [email protected]

My $DISPLAY variable appears correct on the client.

$ echo $DISPLAY
:0

I want X applications from the server to display locally on the client (the machine I'm physically at). I don't know what is causing this.

Is the "server machine" the machine you are typing the command at (the computer in front of you) or the machine you are logged in to? Since X uses reverse terminology for client/server than the rest of the world, it's ambiguous. — samiam, Feb 03 '14 at 04:01
What is $DISPLAY set to when you are logged in to the server? Also, the guidelines we're give you at http://unix.stackexchange.com/questions/112217/ssh-xforwarding-fails-xauth-bad-display-name should help here — samiam, Feb 03 '14 at 05:02

slm · Accepted Answer · 2014-02-04T07:51:08.173

6

For the sake of this conversation lets say there are 2 machines named lappy and remotey. The lappy system is where you'd be running your ssh commands from. The system you're connecting to is remotey.

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 [email protected]

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 [email protected]

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 [email protected] "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 [email protected] "bash --norc"

Then followed by this command:

$ ssh -t -X -p 6623 [email protected] "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.

edited Feb 04 '14 at 07:51

answered Feb 03 '14 at 04:01

slm

363,520
117
767
871

Hi slm. Your answer works, but I'm trying to get the applications to run "while logged into ssh". I really appreciate your tips. Thank you. – Rucent88 Feb 03 '14 at 04:25
I want to 1) log into ssh 2) type xclock 3) see the xclock display in front of me. Instead the 3) is xclock appearing on host computer. – Rucent88 Feb 03 '14 at 04:34
Host is the computer running sshd – Rucent88 Feb 03 '14 at 04:38
@Rucent88 - very interesting, so if you drop the `-X` switch the GUIs are still being displayed on what I'm calling `lappy`? Is there any `$HOME/.ssh/config` file present? – slm Feb 03 '14 at 04:47
I'm sorry, but no. You're getting it backward. All GUI's are being displayed on what you call remotey. I'm using the term HOST in proper terminology with the ssh manpage. Your post is very informative, but you've misunderstood what I wrote. – Rucent88 Feb 03 '14 at 12:42
The only time I can get GUI to display on "lappy" is when I give it a specific application name at the end of ssh, like this `$ ssh -X -p 6623 [email protected] firefox` – Rucent88 Feb 03 '14 at 12:54
@Rucent88 - I just wanted to make sure I understand what you're trying to do, thanks for clarifying it, I think I understand your issue now. Given it works for the above command your issue is likely a stray command in either your `.bashrc` or `.bash_profile`, assuming you're using bash as your shell. Does this command also work? `echo "firefox" | ssh -X -p 6623 [email protected]`? – slm Feb 03 '14 at 14:31
Yes, the last command you put works to display GUI locally (lappy). – Rucent88 Feb 04 '14 at 02:30
@Rucent88 - yes. But the file `~/.bashrc` begins it's sourcing from `/etc/bashrc`, typically. So look at that file first, and follow things fro mthat file. There's a stray line that's setting something up that's the cause of your issue. – slm Feb 04 '14 at 06:40
I found the problem in my ~/.bashrc file. I don't remember putting this in the file, but everything started working as expected when I removed the line `DISPLAY=":0.0"; export DISPLAY` – Rucent88 Feb 04 '14 at 06:48
@Rucent88 - Terrific! It's always something simple one you tear it down. The commands I provided at the top should have found those errant lines: `grep DISPLAY $HOME/{.bash*,.profile*}`. Did that not find these lines? – slm Feb 04 '14 at 06:51
There was quite a bit of miscommunication that happened our exchange, but thankfully now it's resolved. I'll need to remember that Host=sshd and Local=ssh. :D I appreciate all your help. – Rucent88 Feb 04 '14 at 07:30
@Rucent88 - Expressing the situation w/ the correct terminology and in one that others understand is much of what I do here 8-). Different topic, I notice you had a couple of other Q's were those ever resolved to your satisfaction? If so can you accept them or make a not saying they're still open? - http://unix.stackexchange.com/users/49277/rucent88. – slm Feb 04 '14 at 07:38
Very belatedly, your example `$ ssh -X skinner "echo $DISPLAY"` that returns `:0` is doing so because `$DISPLAY` is evaluated before the `ssh` is executed. I would have expected a value of something like `:10` for an `ssh -X` connection – roaima Sep 08 '22 at 20:32

score 2 · Answer 2 · answered Feb 03 '14 at 11:13

The key problem here is the :0 on the last line:

$ ssh -X -p 6623 [email protected]
$ echo $DISPLAY
:0

That suggests that something on the ssh-server is overriding your DISPLAY environment variable after sshd sets it. Since you happen to have an X server running there on display :0, any requests that X clients do on that computer are going to the local (i.e. the ssh-server) X server. If you ran the ssh-server X server (sic!) on a different display, you would get

$ xclock
Error: Can't open display: :1

There is lots of places where things can go wrong, for starters I would suggest modifying your connection command to invoke a shell without any initialization. Remember to use the -t option to force tty allocation. For BASH, the command can look like this:

$ ssh -X -p 6623 -t [email protected] /bin/bash --norc --noprofile

Then check the value of DISPLAY.