SSH X11 not working
Posted
by
azat
on Server Fault
See other posts from Server Fault
or by azat
Published on 2011-06-09T14:36:13Z
Indexed on
2012/04/07
5:32 UTC
Read the original article
Hit count: 1155
I have a home and work computer, the home computer has a static IP address.
If I ssh from my work computer to my home computer, the ssh connection works but X11 applications are not displayed.
In my /etc/ssh/sshd_config
at home:
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
At work I have tried the following commands:
xhost + home HOME_IP
ssh -X home
ssh -X HOME_IP
ssh -Y home
ssh -Y HOME_IP
My /etc/ssh/ssh_config
at work:
Host *
ForwardX11 yes
ForwardX11Trusted yes
My ~/.ssh/config
at work:
Host home
HostName HOME_IP
User azat
PreferredAuthentications password
ForwardX11 yes
My ~/.Xauthority
at work:
-rw------- 1 azat azat 269 Jun 7 11:25 .Xauthority
My ~/.Xauthority
at home:
-rw------- 1 azat azat 246 Jun 7 19:03 .Xauthority
But it doesn't work
After I make an ssh connection to home:
$ echo $DISPLAY
localhost:10.0
$ kate
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
kate: cannot connect to X server localhost:10.0
I use iptables
at home, but I've allowed port 22. According to what I've read that's all I need.
UPD.
With -vvv
... debug2: callback start debug2: x11_get_proto: /usr/bin/xauth list :0 2>/dev/null debug1: Requesting X11 forwarding with authentication spoofing. debug2: channel 1: request x11-req confirm 1 debug2: client_session2_setup: id 1 debug2: fd 3 setting TCP_NODELAY debug2: channel 1: request pty-req confirm 1 ...
When try to launch kate
:
debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 55486 debug2: fd 8 setting O_NONBLOCK debug3: fd 8 is O_NONBLOCK debug1: channel 2: new [x11] debug1: confirm x11 debug2: X11 connection uses different authentication protocol. X11 connection rejected because of wrong authentication. debug2: X11 rejected 2 i0/o0 debug2: channel 2: read failed debug2: channel 2: close_read debug2: channel 2: input open -> drain debug2: channel 2: ibuf empty debug2: channel 2: send eof debug2: channel 2: input drain -> closed debug2: channel 2: write failed debug2: channel 2: close_write debug2: channel 2: output open -> closed debug2: X11 closed 2 i3/o3 debug2: channel 2: send close debug2: channel 2: rcvd close debug2: channel 2: is dead debug2: channel 2: garbage collecting debug1: channel 2: free: x11, nchannels 3 debug3: channel 2: status: The following connections are open: #1 client-session (t4 r0 i0/0 o0/0 fd 5/6 cc -1) #2 x11 (t7 r2 i3/0 o3/0 fd 8/8 cc -1) # The same as above repeate about 7 times kate: cannot connect to X server localhost:10.0
UPD2
Please provide your Linux distribution & version number.
Are you using a default GNOME or KDE environment for X or something else you customized yourself?
azat:~$ kded4 -version Qt: 4.7.4 KDE Development Platform: 4.6.5 (4.6.5) KDE Daemon: $Id$
Are you invoking ssh directly on a command line from a terminal window?
What terminal are you using? xterm, gnome-terminal, or?
How did you start the terminal running in the X environment? From a menu? Hotkey? or ?
From terminal emulator `yakuake` Manualy press `Ctrl + N` and write commands
Can you run xeyes from the same terminal window where the ssh -X fails?
`xeyes` - is not installed But `kate` or another kde app is running
Are you invoking the ssh command as the same user that you're logged into the X session as?
From the same user
UPD3
I also download ssh
sources, and using debug2()
write why it's report that version is different
It see some cookies, and one of them is empty, another is MIT-MAGIC-COOKIE-1
© Server Fault or respective owner