I ran the command below on secureCRT ssh client:

$ DISPLAY=abc.xyz.com:0 ; export DISPLAY
$ /bin/xhost +abc.xyz.com

But it output this error:

/bin/xhost:  unable to open display "abc.xyz.com"
# cat /etc/system-release
Red Hat Enterprise Linux Server release 7.5 (Maipo)
# whoami

How to troubleshoot this error?

  • you did both of these on the same system? is there a display 0 running and available on the system? if not, this won't work.
    – 0xSheepdog
    Commented Sep 17, 2018 at 21:40
  • Does X Forwarding work through ssh .... ssh -X [email protected] Commented Sep 17, 2018 at 21:48
  • @0xSheepdog I did both on my laptop using ssh client. Am actually now aware of display 0. how to verify that? Commented Sep 17, 2018 at 22:56
  • @RubberStamp I will test this command... but what are we trying to test with -X option? Commented Sep 17, 2018 at 23:19
  • I don't know much about SecureCRT except they charge a lot of money for an application that others do for free. MobaXterm is a fairly good freeware solution. Paid version removes some of their restrictions. Anyway, it has an X server built in and configures it by default.
    – 0xSheepdog
    Commented Sep 17, 2018 at 23:35

1 Answer 1


Assuming that you have two hosts:

  • hostA has the display you want to use
  • hostB has the application you want to run

First, you log in to hostA and run xhost +hostB on it to allow hostA's display to be accessed by hostB. Then, you log into hostB, run DISPLAY=hostA:0 ; export DISPLAY on it, and start your application.

Also note: these are old-style completely unencrypted X11 connections, which are usually disabled by default on modern Linux distributions. If you want to use these commands, you may first have to do something on hostA to configure its X11 server to listen for incoming connections over the TCP protocol, and not just over local UNIX sockets.

(For a long time, this was done by adding a -nolisten TCP option to the X server command line, and you would need to remove this option to use unencrypted X11 connections. Modern Xorg X servers may flip the sense of these options: you might need to add an explicit -listen TCP option to enable non-local unencrypted X11 connections.)

On a Linux/Unix system, DISPLAY=:0.0 refers to a X11 display that is accessible using UNIX socket /tmp/.X11-unix/X0, so it is the first (and usually only) local X11 server. On a Windows system, this mechanism does not exist.

The UNIX socket mechanism is used only when it is available on the local system architecture and the hostname part of the DISPLAY variable is an empty string. If a hostname is listed, even if it is "localhost", a TCP connection is used.

If a TCP connection is used, DISPLAY=hostname:X.Y refers to a X11 server listening on hostname in TCP port (X+6000).

When you start a Windows-based X11 server - perhaps a commercial one like Reflection X, or a free one like VcXsrv or the classic Xming, it will by default start listening on TCP port 6000 as soon as it is started. Modern versions may default to listening on localhost only for security; the classic alternative is listening on all IP addresses the system has.

The modern, secure way of using X11 is SSH-based X11 forwarding. When you start a SSH client with X11 forwarding enabled, it will connect to the local X11 server on the SSH client host using whatever mechanism available. It will pass on this connection to whatever host you connect to using a secure subchannel in the SSH connection.

Then the sshd daemon on the remote host will start listening on a free TCP port (usually in the 6010+ range), sets up a DISPLAY=localhost:X.0 (where X = chosen port number - 6000), and also cooperates with the SSH client to automatically set up xauth cookies for you, if required by the X11 server at the SSH client side.

As far as the X11 server on the client host is concerned, the incoming X11 traffic comes from the local SSH client process, so xhost command is normally not needed on the SSH client host.

The result: you don't need to set DISPLAY manually, nor the xhost command at all. Just make sure your local X11 server is running, enable X11 forwarding in your SSH client, connect to the remote host with SSH and start any X11 GUI program. The windows of that program will just pop up on your local display. It just works.

This can be something of a revelation to someone that is used to the classic style of setting up X11 connections.

More than 15 years ago, I showed this to a grumpy old database administrator, who occasionally had needed to go to the server room to install Oracle as firewalls did not allow the classic un-encrypted X11 connections.

He hugged me.

  • HostA is my laptop Commented Sep 17, 2018 at 22:58
  • HostB is rhel 7.x where we are running a product installer that needs gui input. Commented Sep 17, 2018 at 22:59
  • Does hostA have a working X server for the display? Running both commands on the same system won't do anything helpful. Setting the display variable tells your X app where to draw the app, the $DISPLAY. xhost +hostname tells your X server (display) that x-apps from 'hostname' are allowed to draw on the display. Running both on the same system is like dialing your own phone number from that very phone... not gonna work.
    – 0xSheepdog
    Commented Sep 17, 2018 at 23:30
  • @0xSheepdog hostA is my windows laptop... running ssh client to connect to hostB Commented Sep 17, 2018 at 23:43
  • 1
    When using any SSH client with X11 forwarding, you must not alter the DISPLAY setting on the remote host manually. When the SSH client requests X11 forwarding, the sshd on the remote server will understand you'll want to have GUI programs displayed on your local display, and automatically sets it up for you. If you change DISPLAY afterwards, you'll break the forwarding.
    – telcoM
    Commented Sep 21, 2018 at 11:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .