# ssh: cannot open X display, check display name/server access

## wennote

[Solved] I can login to the remote server by ssh, however, I could not get X-windows. The error message is:

ERROR: Can not open X display, check display name/server access authorization.

             Device does not support full-screen.

I might need put my logname@remotedomain in the .Xauthority. It did not work.

Many thanks!Last edited by wennote on Tue Feb 03, 2009 10:40 pm; edited 1 time in total

----------

## dmpogo

 *wennote wrote:*   

> I can login to the remote server by ssh, however, I could not get X-windows. The error message is:
> 
> ERROR: Can not open X display, check display name/server access authorization.
> 
>              Device does not support full-screen.
> ...

 

in remote server Xforwarding is probably disabled (it is disabled by default in /etc/ssh/sshd_config )

----------

## Janne Pikkarainen

If X forwarding was already enabled, then you might want to emerge xauth.

----------

## wennote

The remote server is in my school. The program is SAS. I am pretty sure the X-forwarding is enable.

I did emerge -pv xauth

[ebuild R] x11-apps/xauth-1.0.3 USE="-debug -ipv6" 0KB

Total: 1 package (1 reinstall), size of downloads: 0 KB.

Thanks!

----------

## Gamma746

Make sure that X11Forwarding is set to "yes" in /etc/ssh/sshd_config on the server, that ForwardX11 is set to "yes" in /etc/ssh/ssh_config on the client, and that both the server and client have openssh built with the "X" use flag.

----------

## wennote

I did that and still...

 *Gamma746 wrote:*   

> Make sure that X11Forwarding is set to "yes" in /etc/ssh/sshd_config on the server, that ForwardX11 is set to "yes" in /etc/ssh/ssh_config on the client, and that both the server and client have openssh built with the "X" use flag.

 

----------

## cwr

Last time I did this I had to set the DISPLAY variable directly on the client;

that is, log in to wibble, ssh to wobble, and enter: export DISPLAY="wibble:0.0".

It isn't something I often do; if eg: gdm is running on the client a login via

xdm is a lot easier, but it did work.

Will

----------

## wennote

It makes lots of senses. I will do it when I get home. Many thanks!

 *cwr wrote:*   

> Last time I did this I had to set the DISPLAY variable directly on the client;
> 
> that is, log in to wibble, ssh to wobble, and enter: export DISPLAY="wibble:0.0".
> 
> It isn't something I often do; if eg: gdm is running on the client a login via
> ...

 

----------

## pgf

 *wennote wrote:*   

> I can login to the remote server by ssh, however, I could not get X-windows. The error message is:
> 
> ERROR: Can not open X display, check display name/server access authorization.
> 
>              Device does not support full-screen.
> ...

 

Have you tried doing 

```
xhost +
```

on your local machine?

----------

## wennote

I did:

export DISPLAY=" XXX.XXX.edu:0.0"

xhost XXX.XXX.edu

I got the error message:

xhost: unable to open display "xxx.xxx.edu:0.0"

Last time I did this I had to set the DISPLAY variable directly on the client;

that is, log in to wibble, ssh to wobble, and enter: export DISPLAY="wibble:0.0".

It isn't something I often do; if eg: gdm is running on the client a login via

xdm is a lot easier, but it did work.

----------

## wennote

New Error:

xlib: connection to "xxx.xx.edu:10.0" refused by server

xlib: Invalid MIT-MAGIC-COOKIE-1 key

ERROR: Cannot open X display. Check display name/server access authoriztion.

ERROR: Explorer failed to initialize.

ERROR: Device does not support full-screen.

----------

## pgf

 *wennote wrote:*   

> I did:
> 
> export DISPLAY=" XXX.XXX.edu:0.0"
> 
> xhost XXX.XXX.edu
> ...

 

Just to check: you do realize that the first command must be run on the remote system and the second on the local system? For example, I have a laptop that I use to connect to my remote server. On the laptop I execute the xhost command, then I ssh to the server. On the server I set and export the DISPLAY variable, then start the X app (like xterm).

----------

## wennote

I did make this mistake. Now I run xhost xxx.xx.edu in my local system. 

I have no authority to run the remote system. However, in my ubuntu system, I can access the X-windows by ssh -X xxx@xxx.xx.edu.

Well, I have no idea.

 *pgf wrote:*   

>  *wennote wrote:*   I did:
> 
> export DISPLAY=" XXX.XXX.edu:0.0"
> 
> xhost XXX.XXX.edu
> ...

 

----------

## cwr

Ok, I've dug out my notes and got the full story:

Given wibble, running Gnome, and wobble, just running,

open a terminal in wibble and enter:

 Xnest -ac :1.0 &

 twm -display :1.0 &

which gets you an X-window and a window manager on

the local machine.  twm is slow to start, searching for

missing i18n fontsets, but I can't find out where these

are set.  Anyway, in the end it runs.

Then log onto wobble with ssh -X and set  the DISPLAY

variable to "wibble:1.0".  X applications run on the client

will then run on the server.

/etc/X11/xinit/xserverrc on wibble may be needed to edited

to remove the "-nolisten tcp" argument if it is present.

Good luck - Will

----------

## wennote

At first, thank you for your time and message!

In wibble (my local machine):

$ Xnest -ac :1.0 &

[1] 11236

$ (EE) config/hal: NewInputDeviceRequest failed

(this message repeat itself 4 times)

BTW, my system currently has some other problems, after I did:

emerge --update --deep newuse world

I filed this in threads:

https://forums.gentoo.org/viewtopic-t-731552-highlight-daemon+mouse.html

I would more than glad to post my system info upon your request.

Thanks a lot!

----------

## Hu

Be aware that this method is very insecure.  It directs wobble to run unencrypted X traffic over the network back to wibble.  Anyone who can sniff traffic can see what you type.  Further, it allows anyone on wobble to connect to your X server, not just you.  Connecting them to the Xnest instance instead of the main server gets you some protection against them manipulating your main desktop, but they can still see your keystrokes.

The instructions about xhost + are even worse.  They open you up to anyone who can establish a TCP connection to the X server.

----------

## pgf

 *Hu wrote:*   

> The instructions about xhost + are even worse.  They open you up to anyone who can establish a TCP connection to the X server.

 

That is certainly conventional wisdom, but the setup described is a home network. Unless he has port 6000 open through the firewall the only thing he is exposed to is the other machines at home, if any. There should be no problem with running with access disabled for debugging purposes. As for the threat of sniffing, it is true but what is the likelihood? Again, not a huge threat.

----------

## Hu

 *pgf wrote:*   

> That is certainly conventional wisdom, but the setup described is a home network. Unless he has port 6000 open through the firewall the only thing he is exposed to is the other machines at home, if any. There should be no problem with running with access disabled for debugging purposes. As for the threat of sniffing, it is true but what is the likelihood? Again, not a huge threat.

 

It looks to me like this is an X forward from a university computer to wennote's home system, which would require a hole in the external firewall.  Since he did not mention needing to open that, I suspect he does not even have an external firewall.  Opening access for debugging is fine, but I got the impression that this thread was considered solved with the resolution of running the traffic in an insecure manner.

If this were a home network, he should have authority to fix the server configuration to enable X forwarding properly.

----------

## pgf

Interesting. My impression was that he was using ssh with X forwarding to tunnel through a firewall. If there was no firewall then the -X option would not be of any use. Of course this discussion got me thinking of my earlier answers, and I realize that I got muddled. Assuming the setup is something like this:

      uinversity-srv ---- FIREWALL ------------ Internet --------- FIREWALL -----  wennote

then you should try this:

1. From "wennote", ssh to "univeristy-srv" using the following command:

```
ssh -X university-srv
```

    if you get an error message similar to

```
Warning: untrusted X11 forwarding setup failed: xauth key data not generated

Warning: No xauth data; using fake authentication data for X11 forwarding.

```

   then add a -Y flag to the ssh command

2. Do NOT set the DISPLAY variable - it will be set automatically by ssh when you use the -X flag (my mistake previously). You should also NOT need any xhost command. 

If this does not work then post the error messages.

----------

## cwr

 *Hu wrote:*   

> Be aware that this method is very insecure.  It directs wobble to run unencrypted X traffic over the network back to wibble.  Anyone who can sniff traffic can see what you type.  Further, it allows anyone on wobble to connect to your X server, not just you.  Connecting them to the Xnest instance instead of the main server gets you some protection against them manipulating your main desktop, but they can still see your keystrokes.
> 
> 

 

Yes, I should have stressed that, thanks for bringing it up.  I was using it on a local network with no Internet access, and deliberately dropped all security just to get things to work.  I should have made that clear.

Will

----------

## artbody

i've just tested 

localhost: ssh_config

```
Host  192.168.0.*  # serverip for allowed host

ForwardX11 yes

CheckHostIP yes
```

same on the server

```

# Host  xxx.xxx.0.*  # serverip's from provider if dial-up

Host  xxx.xxx.xxx.xxx  # my IP

ForwardX11 yes

CheckHostIP yes
```

then connect with ssh to the server

```

 ssh -X root@serverip

```

works well with xterm and some other program's -> 

! BUT NOT WITH ALL !

scite -> a editor works

gentoo -> a filemanager didn't but works on my old Mandrake Linux Labtop

etc.

perhaps you could modify 

 ~/.ssh/config

             This is the per-user configuration file.  The format of this file

             is described above.  This file is used by the SSH client.

             Because of the potential for abuse, this file must have strict

             permissions: read/write for the user, and not accessible by oth‐

             ers.

instead of systemwide   /etc/ssh/ssh_config

in that case  ~/.ssh/config

```
ssh -X username@serverip
```

----------

## wennote

 *pgf wrote:*   

> Interesting. My impression was that he was using ssh with X forwarding to tunnel through a firewall. If there was no firewall then the -X option would not be of any use. Of course this discussion got me thinking of my earlier answers, and I realize that I got muddled. Assuming the setup is something like this:
> 
>       uinversity-srv ---- FIREWALL ------------ Internet --------- FIREWALL -----  wennote
> 
> then you should try this:
> ...

 

It works!!!!!

Thanks a lot! -Y is just like a magic!

----------

## pgf

 *wennote wrote:*   

> 
> 
> It works!!!!!
> 
> Thanks a lot! -Y is just like a magic!

 

That is great - simple is best. Please update the subject line in your original post to say [SOLVED]. It helps others who are looking for a solution to the same problem.

----------

## Hu

 *pgf wrote:*   

> My impression was that he was using ssh with X forwarding to tunnel through a firewall. If there was no firewall then the -X option would not be of any use. Of course this discussion got me thinking of my earlier answers, and I realize that I got muddled.

 

That is one use for it, but modern X startup scripts tend to include -nolisten tcp, so the X server will not have a TCP listener, and will thus be inaccessible to remote systems without the tricks that ssh plays.

----------

