Problem
X forwarding does not seem to be working correctly when trying to establish a connection between two HP-UX (11.31) hosts
$ ssh -X serv1
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
Last successful login: Tue Jan 20 15:13:33 MET 2015 10.10.5.2
Last authentication failure: Tue Jan 20 14:29:02 MET 2015
Last login: Tue Jan 20 15:13:33 2015 from 10.224.5.2Notice the error message: xauth key data not generated
X applications will not start because of missing authorizations:
$ xclock
X11 connection rejected because of wrong authentication.
X connection to 10.224.5.21:16.0 broken (explicit kill or server shutdown).The SSH versions on both hosts are identical and is:
$ swlist SecureShell
# Initializing...
# Contacting target "serv1"...
#
# Target: serv1:/
#
# SecureShell A.06.20.012 HP-UX Secure Shell
SecureShell.Secure_Shell A.06.20.012 HP-UX Secure ShellAnalysis
sshd debugging
With some extra debugging info enabled via the SSH daemon we can see:
client1->serv1:
debug2: x11_get_proto: /usr/bin/X11/xauth -f /tmp/ssh-kBsmWX5ynL8E/xauthfile generate 10.20.76.3:15.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2>/dev/null
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.Trying to invoke the xauth command manually gives:
[serv1]$ /usr/bin/X11/xauth -f /tmp/ssh-kBsmWX5ynL8E/xauthfile generate 10.20.76.3:15.0 MIT-MAGIC-COOKIE-1 untrusted
/usr/bin/X11/xauth: error in locking authority file /tmp/ssh-kBsmWX5ynL8E/xauthfileThere is however a workaround available by using Trusted X11 forwarding, instead of:
[client1]$ ssh -X serv1Do:
[client1]$ ssh -Y serv1
[client1serv1]$ xclockBut with Trusted X11 one assumes that each client is per default a trusted one and this makes X11 forwarding even less secure:
$ man sshd
-X Enables X11 forwarding. This can also be specified on a per-host
basis in a configuration file.
X11 forwarding should be enabled with caution. Users with the
ability to bypass file permissions on the remote host (for the
user's X authorization database) can access the local X11 display
through the forwarded connection. An attacker may then be able
to perform activities such as keystroke monitoring.
For this reason, X11 forwarding is subjected to X11 SECURITY
extension restrictions by default. Please refer to the ssh -Y
option and the ForwardX11Trusted directive in ssh_config(5) for
more information.
-Y Enables trusted X11 forwarding. Trusted X11 forwardings are not
subjected to the X11 SECURITY extension controls
It looks very much that untrusted X11 forwarding in the current OpenSSH version of HP-UX is either broken or unsupported.
Truss debugging
Out of curiosity I executed two SSH connections with system call tracing via truss, one with trusted X11 and one with untrusted X11.
-
Trusted X11 :
$ truss -f ssh -vvvv -Y serv1 -
Untrusted X11 :
$ truss -f ssh -vvvv -X serv1
In the connection with X11 trusted enabled we see that xauth is referring to /home/acme/.Xauthority:
[client1]$ grep Xauth ssh_trusted_X.log
24612: stat("/home//.Xauthority-c", 0x7fffeab0) ERR#2 ENOENT
24612: creat("/home/acme/.Xauthority-c", 438) = 3
24612: link("/home/acme/.Xauthority-c", "/home/acme/.Xauthority-l") = 0
24612: access("/home/acme/.Xauthority", F_OK) = 0
24612: access("/home/acme/.Xauthority", W_OK) = 0
24612: open("/home/acme/.Xauthority", O_RDONLY, 0666) = 3
24612: unlink("/home/acme/.Xauthority-c") = 0
24612: unlink("/home/acme/.Xauthority-l")And this works fine of course.
However during the untrusted connectie xauth tries to create a temporary magic cookie in /tmp using an unsupported commando of itself:
10385: stat("/usr/bin/X11/xauth", 0x9fffffffffffdb00) = 0
debug2: x11_get_proto: /usr/bin/X11/xauth -f /tmp/ssh-WPMfSbLVs1pd/xauthfile generate 10.20.76.3:12.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2>/dev/null
10397: execve("/usr/bin/X11/xauth", 0x4003b180, 0x40053860) = 0 [32-bit]
10397: open("/usr/bin/X11/xauth", O_RDONLY, 0) = 3
10397: stat("/tmp/ssh-WPMfSbLVs1pd/xauthfile-c", 0x7fffea40) ERR#2 ENOENT
10397: creat("/tmp/ssh-WPMfSbLVs1pd/xauthfile-c", 438) = 3
10397: link("/tmp/ssh-WPMfSbLVs1pd/xauthfile-c", "/tmp/ssh-WPMfSbLVs1pd/xauthfile-l") = 0
10397: access("/tmp/ssh-WPMfSbLVs1pd/xauthfile", F_OK) ERR#2 ENOENT
10397: open("/tmp/ssh-WPMfSbLVs1pd/xauthfile", O_RDONLY, 0666) ERR#2 ENOENT
10397: access("/tmp/ssh-WPMfSbLVs1pd/xauthfile", F_OK) ERR#2 ENOENT
10397: unlink("/tmp/ssh-WPMfSbLVs1pd/xauthfile-c") = 0
10397: unlink("/tmp/ssh-WPMfSbLVs1pd/xauthfile-l") = 0
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
10385: unlink("/tmp/ssh-WPMfSbLVs1pd/xauthfile") ERR#2 ENOENT
Warning: No xauth data; using fake authentication data for X11 forwarding.
This behaviour is confirmed by running the generate command from within xauth:
[client1]$ xauth
Using authority file /home/acme/.Xauthority
xauth> generate
xauth: (stdin):1: unknown command "generate"
xauth>Conclusion
After consultation with HP support it appears that this behaviour has indeed been broken for many years:
QXCR1000761588 – HP-UX’s xauth(1) does not have the “generate” option Unfortunately, this enhancement request has never been implemented so we still have to live with the current limitation.
As a workaround we can force *Trusted X11 *for all connections by altering the default ssh_config client configuration file:
/opt/ssh/etc/ssh_config:
ForwardX11Trusted yes
ForwardX11 yesSee also: https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c01544532
Comments