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 ipcroe.rkkda.com:10.0 $ echo $XAUTHORITY /tmp/ssh-XXzKKhWE/cookies $ xterm 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 /etc/ssh/sshd_config:X11Forwarding yes /etc/ssh/sshd_config:X11DisplayOffset 10 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 email.
Created attachment 5828 [details] sshd log file
Created attachment 5829 [details] ssh log
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 you have).
Hmm. OK, I can get it to work between machines that are on the local network. It doesn't 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 network, but 65.25.214.194 (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, and not ipcroe.rkkda.com: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 make 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 problem... $ 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: http://x61.deja.com/[ST_rn=ps]/getdoc.xp?AN=580572848&CONTEXT=979080598.1582825579&hitnum=113 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 bug/erata lists...
The article does not apply anymore. OpenSSH does set up unix sockets, too, as of last May: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/session.c?r1=1.12&r2=1.13 $ 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.