Showing posts with label auth key data not generated. Show all posts
Showing posts with label auth key data not generated. Show all posts

01 February 2013

329. ECCE, xterm and X forwarding: fixing broken "tail -f on output" in ECCE/'untrusted X11 forwarding' error


The problem
In ECCE when you highlight a running job on a remote server which you've set up with the frontendMachine option (here and here and here) which is a ROCKS 5.4.3/CentOS server and e.g. hit Alt+L or "Run Mgmt"/"Tail -f on Output file" and nothing happens, and when you set ECCE to provide verbose output (add "ECCE_RCOM_LOGMODE true" to ecce/apps/siteconfig/site_runtime) you see the following errors:

X11 connection rejected because of wrong authentication. X connection to localhost:43.0 broken (explicit kill or server shutdown).
and
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding.
Obviously there are non-ECCE related situation where you may see these errors too. Doesn't matter -- same solution.


The diagnostics
cat /etc/ssh/sshd_config |grep X11
X11Forwarding yes X11DisplayOffset 10
cat /etc/ssh/ssh_config |grep X11|grep -v ^#
ForwardX11 yes
sudo cat /etc/ssh/sshd_config |grep X11|grep -v ^#
X11Forwarding yes X11DisplayOffset 10

So, why localhost:43? And why isn't it working? From my workstation to the cluster which is connected to the net via the front node, and then from the cluster front to the cluster front's local name.

ssh -X server.external.dns
echo $DISPLAY
localhost:42.0
ssh -X server.local.dns
Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding.
echo $DISPLAY
localhost:44.0
yet
ssh -Y server.local.dns

works fine.

The solution:
Simpler than I thought:
I edited ~/.ssh/config on the server, and did
Host server.local.dns Hostname server.local.dns User me ForwardX11 yes ForwardX11Trusted yes

And now it works!

Presumably I could've just edited /etc/ssh_config instead, but it's a multi-user cluster and I'm happier to change things on a user-by-user basis.