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 pinker@

My $DISPLAY variable appears correct on the client.

$ echo $DISPLAY

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.

  • What are you using for your ssh command? (i.e. what flags?)
    – FDinoff
    Feb 3 '14 at 4:00
  • 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 3 '14 at 4:01
  • Sorry, I will edit my post.
    – Rucent88
    Feb 3 '14 at 4:07
  • What is $DISPLAY set to when you are logged in to the server? Also, the guidelines we're give you at unix.stackexchange.com/questions/112217/… should help here
    – samiam
    Feb 3 '14 at 5:02

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


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

$ ssh -X skinner "echo $DISPLAY"

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@

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@

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@ "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@ "bash --norc"

Then followed by this command:

$ ssh -t -X -p 6623 pinker@ "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.

  • 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 3 '14 at 4: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 3 '14 at 4:34
  • Host is the computer running sshd
    – Rucent88
    Feb 3 '14 at 4: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 3 '14 at 4: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 3 '14 at 12:42

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

$ ssh -X -p 6623 pinker@
$ echo $DISPLAY

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 pinker@ /bin/bash --norc --noprofile 

Then check the value of DISPLAY.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.