[SOLVED] X11 forwarding request failed on channel 0

abhisheks77 · 04-30-2014, 10:26 PM

Hello,
I have RHEL 6.3 container. I am trying to run xclock from MobaXterm and it is not successful. At the time login itself, it give me error, which I mentioned in subject line

Code:

[465376.L9701067] ➤ ssh -X root@linux_123
X11 forwarding request failed on channel 0
Last login: Wed Apr 30 20:16:11 2014 from 10.24.46.23
[root@linux_123 ~]# xclock
Error: Can't open display:
[root@linux_123 ~]# echo $DISPLAY

[root@linux_123 ~]# cat /etc/ssh/sshd_config | grep X11 | grep -v "#"
X11Forwarding yes
X11UseLocalhost no
[root@linux_123 ~]#

I reloaded ssh daemon also, still no luck.

jpollard · 05-01-2014, 08:09 AM

the "X11UseLocalhost" should be yes.

This will prevent remote attacks to the port over the network, and limit attacks to users logged in on linux_123.

And did you restart the sshd service after changing the configuration file to enable X11Forwarding ?

abhisheks77 · 05-01-2014, 11:45 AM

I have changed it, still no luck

Quote:

[root@linux_123 ~]# cat /etc/ssh/sshd_config | grep X11 | grep -v "#"
X11Forwarding yes
X11UseLocalhost yes
[root@linux_123 ~]# service sshd stop
[root@linux_123 ~]# service sshd start
[root@linux_123 ~]# /etc/init.d/sshd reload
[root@linux_123 ~]# xclock
Error: Can't open display:
[root@linux_123 ~]# echo $DISPLAY

[root@linux_123 ~]#

I logged out and login back and still it is throwing same error

shivaa · 05-01-2014, 12:42 PM

First thing, DISPLAY variable is not set, so system can't decide where to open x-utility. Set it first.

Code:

localhost# setenv DISPLAY <hostname>:port_no

Second, on system linux_123 invoke following cmd:

Code:

linux_123# xhost +<hostname>

Note: Here hostname is machine, from where you're invoking ssh to linux_123 machine.

abhisheks77 · 05-01-2014, 01:24 PM

Shivaa, This Linux container (parallels). I try to find, but it doesn't have xhost
Also, how should I know, what should be port_no ?

jpollard · 05-01-2014, 02:04 PM

The X server doesn't normally open the TCP port anyway. It is a security weakness because the access keys are passed without encryption.

did you restart the sshd service on linux_123?

Logging out of linux_123 does not restart the service.

Sorry, just saw that you had.

After restarting, make a ssh connection. It should forward the X protocol.

abhisheks77 · 05-01-2014, 02:13 PM

Hi again jpollard, Yes, I restarted ssh and logged out and login back, but still it was same issue.

jpollard · 05-01-2014, 03:37 PM

That implies that sshd was compiled without port forwarding.

abhisheks77 · 05-01-2014, 03:54 PM

But it says ENABLED in conf file

Quote:

~]# cat /etc/ssh/sshd_config | grep X11 | grep -v "#"
X11Forwarding yes
X11UseLocalhost yes

Do I need to recompile or can I test it by any way, if it is forwarding ?

jpollard · 05-02-2014, 03:27 AM

If you have a DISPLAY environment variable defined then it should be forwarding.

Of course, if you still have it being defined in the profile, you can't tell - it may be forwarding, but you are getting the wrong DISPLAY value with the wrong key - thus it would still fail.

shivaa · 05-02-2014, 03:42 AM

To me, it looks an issue of wrong DISPLAY setting. In simple words, your local machine don't know where to open/launch the x utility. However, try to set DISPLAY variable as (use port no. 0.0):

Code:

localhost# setenv DISPLAY linux_123:0.0

abhisheks77 · 05-02-2014, 10:30 AM

It is not accepting proper display settings. I tried this. Am I missing something ?

Quote:

linux_123# export DISPLAY linux_123:0.0
-bash: export: `linux_123:0.0': not a valid identifier
linux_123# export DISPLAY 10.53.16.34:0.0
-bash: export: `10.53.16.34:0.0': not a valid identifier
linux_123# export DISPLAY=localhost:0.0
linux_123# echo $DISPLAY
localhost:0.0
linux_123# xclock
Error: Can't open display: localhost:0.0
[root@linux_123 ~]#

abhisheks77 · 05-02-2014, 12:07 PM

I am able to fix it.
I created .Xauthority file manually. Apart from this, ssh daemon was not able to restart properly. When I did reload and restart, still few old processes were holding it. I killed all ssh processes and then it worked.
Thanks Shivaa and jpollard