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.2

Notice 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 Shell

Analysis

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/xauthfile

There is however a workaround available by using Trusted X11 forwarding, instead of:

[client1]$ ssh -X serv1

Do:

[client1]$ ssh -Y serv1
[client1serv1]$ xclock

But 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 yes

See also: https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c01544532

Leave a comment