There are a few of us here that cannot get X11 Forwarding to work with
OpenSSH's "sshd". Using OpenSSH's "ssh" to talk to a site running
www.ssh.com's "sshd" works fine for X11. But using OpenSSH's "ssh" to
talk to OpenSSH's "sshd" results in no X11 joy at all. Here's a
sample where I ssh'ed back into my own machine to test the forwarding:
$ ssh ipcroe.rkkda.com
$ echo $DISPLAY
$ echo $XAUTHORITY
xterm Xt error: Can't open display: ipcroe.rkkda.com:10.0
Forwarding seems to be set up as per the manual pages...
$ root grep X11 /etc/ssh/*config
/etc/ssh/ssh_config: ForwardX11 yes
We are using the openssh-*-2.3.0p1-4.i386.rpm's from RedHat on RH 7.0.
I've run ssh and sshd in debug mode and attached the logs to this
Created attachment 5828 [details]
sshd log file
Created attachment 5829 [details]
Very weird. Works for me, though.
The server log shows that there's a listener socket open, but it doesn't show
any connections, or even a connection request. I can do X11 forwarding reliably
here as well (this is using the default configuration, which appears to be what
Hmm. OK, I can get it to work between machines that are on the local network.
work when the machine running sshd is the one that has the ssh port forwarded to
it by the
firewall. That is, the machine that is known as 192.168.1.100 on the local
188.8.131.52 (ipcroe.rkkda.com) to the rest of the world.
Could this be an X issue? Should sshd set the DISPLAY to 192.168.1.100:10.0,
That's correct. The listener listens on port (6000 + displaynumber), or 6010.
It appears that you'll need to forward that port as well. If that's the case, I
can close this bug report.
But it doesn't seem right to have to punch a hole at 60xx thru the firewall to
OpendSSH work in this case, when the one from www.ssh.com works without
having to do this. I mentioned this to a couple guys around here, and they
don't think thats the way it should work.
Hmm, when I force the DISPLAY to the private IP address, then I get a new
$ DISPLAY=192.168.1.100:12.0 xterm
debug: client_input_channel_open: ctype x11 rchan 2 win 4096 max 2048
debug: fd 7 setting O_NONBLOCK
debug: channel 1: new [x11]
debug: confirm x11
debug: X11 connection uses different authentication protocol.
debug: X11 rejected 1 i1/o16
debug: channel 1: read failed
debug: channel 1: input open -> drain
debug: channel 1: close_read
debug: channel 1: input: no drain shortcut
debug: channel 1: ibuf empty
debug: channel 1: input drain -> closed
debug: channel 1: send eof
debug: channel 1: write failed
debug: channel 1: output open -> closed
debug: channel 1: close_write
debug: X11 closed 1 i8/o128
debug: channel 1: send close
debug: channel 1: rcvd close
debug: channel 1: full closed2
debug: channel_free: channel 1: status: The following connections are open:
#0 client-session (t4 r0 i1/0 o16/0 fd 4/5)
#1 x11 (t7 r2 i8/0 o128/0 fd 7/7)
X connection to 192.168.1.100:12.0 broken (explicit kill or server shutdown).
Actually, you're right. If ssh.com sshd is setting DISPLAY to localhost:10,
then it's a non-problem on the server machine for just that reason. The client
just needs to know which IP to connect to, and there has to be a matching xauth
cookie for the display.
I think the second part is what's causing the disconnects. Try running "xauth
list ipcroe.rkkda.com:12" and feeding the output back in using "xauth add
192.168.1.1:12 MIT-MAGIC-COOKIE-1 ...".
Using xauth list ... seemed like a reasonable idea. So I tried it.
Unfortunately, xauth list doesn't produce any output at all.
'Nother dead end.
Actually, dejanews article:
talks about this very issue, but since I installed openssh from the rpm, I don't
have the source to even think about trying the patch it suggests. The xauth command seems like it should provide
a (temporary) workaround, but since we connect from so many different workstations it's kind of a pain...
Does anyone know if the openssh people know about this problem? It's not listed in any of their current
The article does not apply anymore. OpenSSH does set up unix sockets, too, as of last May:
$ xauth list
netcore.fi:11 MIT-MAGIC-COOKIE-1 01576248d4d94dc2df16e98cd4978648
otso.netcore.fi/unix:11 MIT-MAGIC-COOKIE-1 01576248d4d94dc2df16e98cd4978648
Effectively this should already be the way described in the deja article.
Perhaps DISPLAY would have to be modified to use the unix domain socket.
I don't think this bug applies to current FC3 openssh packages.