10

I have a new and vexing problem with ssh forwarding my X11 connection when logging in from a Mac (10.7.2) to Linux (Ubuntu 8.04). I have no trouble using ssh -X to log in to the remote machine and starting an X11-based application from that shell.

What has recently started happening is that additional invocations of X11 applications from that same shell, after a while (on the order of hours), are unable to start because the forwarded display is being blocked (I presume). When attempting to start xterm, for example, I get the usual message about a bad DISPLAY setting, such as:

xterm Xt error: Can't open display: localhost:10.0

But the X11 application I started right when I logged in is still running along just fine, using that exact same display (localhost:10.0), just that it was started earlier.

I turned on verbose logging in sshd_config and I see this in the /var/log/auth.log file in response to the failed xterm startup attempt:

sshd[22104]: channel 8: open failed: administratively prohibited: open failed

If I ssh -X to the server again, starting a new shell and getting assigned a new display (localhost:11.0), the same process repeats: the X11 applications started early on run just fine for as long as I keep them open (days), but after a few hours I cannot start any new ones from that shell.

Particulars: OpenSSH sshd server running on Ubuntu 8.04, display forwarded to a Mac running Lion (10.7.2) with the default Apple X server. The systems are connected on an Ethernet LAN with a single switch between them. Neither machine is running a firewall. Until recently (a few days ago) this setup worked perfectly so I am mystified as to where to look next. I am by no means an X11 or SSH expert but have good UNIX/Linux experience. Nothing obvious has changed in either client or server configuration although I have tried changing a few options to try to debug this, like setting sshd_config's TCPKeepAlive to no, and setting "host +localhost" (you can tell I've been Googling).

When logging in from a Linux 11.10 laptop to the same remote host over the same network and switch, this problem does not occur -- an xterm can be invoked successfully hours later from the same ssh login shell while the same experiment from the Mac fails (tested this morning to be sure), so it would appear to be a Mac-specific issue.

With "LogLevel DEBUG3" set on the remote machine (sshd server), and no change made in the client connections by me, /var/log/auth.log shows one slight change in connection status reports overnight, which is the port number used by the one successful ssh session from the Linux machine (I think), connection #7 below:

sshd[20173]: debug3: channel 7: status: The following connections are open:\r\n #0 server-session (t4 r0 i0/0 o0/0 fd 14/13 cfd -1)\r\n #3 X11 connection from 127.0.0.1 port 57564 (t4 r1 i0/0 o0/0 fd 16/16 cfd -1)\r\n #4 X11 connection from 127.0.0.1 port 57565 (t4 r2 i0/0 o0/0 fd 17/17 cfd -1)\r\n #5 X11 connection from 127.0.0.1 port 57566 (t4 r3 i0/0 o0/0 fd 18/18 cfd -1)\r\n #6 X11 connection from 127.0.0.1 port 57567 (t4 r4 i0/0 o0/0 fd 19/19 cfd -1)\r\n #7 X11 connection from 127.0.0.1 port 59007

In this report, everything is the same between status reports except the port number used by connection #7 which I believe is the Linux client -- the only one still maintaining a display connection. It continues to increment over time, judging by a sequence of these reports overnight.

Thanks for any help,

-Mike

mklein9
  • 331
  • 2
  • 9
  • I'm experiencing the same problem. – churnd Jan 06 '12 at 14:40
  • I turned on -vvv on the ssh command to get debug info from the Mac's client side ssh session. I got this: `code`Rejected X11 connection after ForwardX11Timeout expired ForwardX11Timeout is an option in the Mac's ssh client that limits forwarding from an untrusted connection. Potentially using -Y instead of -X would work. ForwardX11Timeout is not documented in Lion's ssh man page. Its default appears to be 20 minutes. Setting it higher in ssh_config is possible but Lion's X server crashes if set to > 596 hours... which, in milliseconds, overflows 31 bits. Arrgh. Hope this fixes it. – mklein9 Jan 06 '12 at 16:30

3 Answers3

13

The ssh sessions started after I changed the Mac client's /etc/ssh_config to include the line:

ForwardX11Timeout 596h

are all working fine and have been all day. By now they all would have been refusing to start new xterms. So I believe this is the answer, and luckily a simple solution, but the timeout will still happen 3-1/2 weeks from now.

mklein9
  • 331
  • 2
  • 9
3

man ssh_config

ForwardX11Trusted

If this option is set to "yes" remote X11 clients will have full access to the original X11 display. If this option is set to "no" remote X11 clients will be considered untrusted and prevented from stealing or tampering with data belonging to trusted X11 clients. Furthermore, the xauth(1) token used for the session will be set to expire after 20 minutes. Remote clients will be refused access after this time. The default is "no" See the X11 SECURITY extension specification for full details on the restrictions imposed on untrusted clients.

Community
  • 1
Isabella
  • 31
  • 1
1

To add to "answered Jan 7 '12 at 0:11 mklein9 28129" "The ssh sessions started after I changed the Mac client's /etc/ssh_config to include the line:

ForwardX11Timeout 596h

... but the timeout will still happen 3-1/2 weeks from now."

Apparently you can use 0 and this sets timeout to infinity (as long as the connection is on).

ForwardX11Timeout 0

...

AB.
  • 11
  • 1