ssh -X remote does not work due to problem with xauth

Matthias Apitz <[email protected]>
Newsgroups gmane.os.freebsd.devel.x11
Message-ID <20180510182928.GA3747@c720-r314251>

Hello,

I'm facing a problem with running from FreeBSD 'ssh -X remote host'. The
remotre server is a recent SLES Linux system. This thread started in
freebsd-questions@ and I now move it to here as it seems more a problem
of the Xorg server than a ssh problem of the base system.

When I launch 'ssh -X remote host' to get X11 forwarded to my workstation
this does not work, i.e. does not produce a DISPLAY env on the remote
host and says:

$ ssh -X apitzm@srap16dxr1
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Last login: Wed May  9 12:37:17 2018 from 10.49.8.33
apitzm@srap16dxr1:~>

I digged into it with -vv options for ssh and trussing the client. It seems it's
our end causing the problem:

$ uname -a
FreeBSD r314251-amd64 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314251: Sat Feb 25 17:14:40 CET 2017
root@r303343-amd64:/usr/obj/usr/src/sys/GENERIC  amd64

$ truss -s128 -f -o ssh.tr ssh -X -vv apitzm@srap16dxr1

$ grep xauth ssh.tr
 2505: stat("/usr/local/bin/xauth",{ mode=-rwxr-xr-x ,inode=15268663,size=41056,blksize=32768 }) = 0 (0x0)
 2505: write(2,"debug2: client_x11_get_proto: /usr/local/bin/xauth -f /tmp/ssh-adSkh4btDHWr/xauthfile generate :0 MIT-MAGIC-COOKIE-1 untrusted timeout 1260 2>/dev/null\r\n",153) = 153 (0x99)
 2506: execve("/usr/local/bin/xauth",0x80145a260,0x80145a408) = 0 (0x0)
 2506: stat("/tmp/ssh-adSkh4btDHWr/xauthfile-c",0x7fffffffdb80) ERR#2 'No such file or directory'
 2506: openat(AT_FDCWD,"/tmp/ssh-adSkh4btDHWr/xauthfile-c",O_WRONLY|O_CREAT|O_EXCL,0600) = 3 (0x3)
 2506: pathconf("/tmp/ssh-adSkh4btDHWr/xauthfile-c",_PC_LINK_MAX) = 32767 (0x7fff)
 2506: link("/tmp/ssh-adSkh4btDHWr/xauthfile-c","/tmp/ssh-adSkh4btDHWr/xauthfile-l") = 0 (0x0)
 2506: access("/tmp/ssh-adSkh4btDHWr/xauthfile",F_OK) ERR#2 'No such file or directory'
 2506: open("/tmp/ssh-adSkh4btDHWr/xauthfile",O_RDONLY,0666) ERR#2 'No such file or directory'
 2506: access("/tmp/ssh-adSkh4btDHWr/xauthfile",F_OK) ERR#2 'No such file or directory'
 2506: write(2,"/usr/local/bin/xauth:  file /tmp/ssh-adSkh4btDHWr/xauthfile does not exist\n",75) = 75 (0x4b)
 2506: access("/tmp/kde-guru/xauth-1001-_0",R_OK) = 0 (0x0)
 2506: open("/tmp/kde-guru/xauth-1001-_0",O_RDONLY,0666) = 4 (0x4)
 2506: write(2,"/usr/local/bin/xauth: (argv):1:  ",33) = 33 (0x21)
 2506: lstat("/tmp/ssh-adSkh4btDHWr/xauthfile-c",{ mode=-rw------- ,inode=24961,size=0,blksize=32768 }) = 0 (0x0)
 2506: unlink("/tmp/ssh-adSkh4btDHWr/xauthfile-c") = 0 (0x0)
 2506: lstat("/tmp/ssh-adSkh4btDHWr/xauthfile-l",{ mode=-rw------- ,inode=24961,size=0,blksize=32768 }) = 0 (0x0)
 2506: unlink("/tmp/ssh-adSkh4btDHWr/xauthfile-l") = 0 (0x0)
 2505: unlink("/tmp/ssh-adSkh4btDHWr/xauthfile") ERR#2 'No such file or directory'
 2505: write(2,"Warning: untrusted X11 forwarding setup failed: xauth key data not generated\r\n",78) = 78 (0x4e)

$ grep Sec ssh.tr
 2505: read(3,"\0\0\^A\^D\v\^_\0\0\0h\0\0\0\^Secdsa-sha2-nistp256\0\0\0\bnistp256\0\0\0A\^D\^Qa<x\^U\M-jW\M-Hy/\M-:\M-b\^Qc\M-\^\^SG\M^ZT|\M-ck7\M-H\M-s\M-gKNi\n\M^Ex\M-;D.\M-w\M-'\^O\^T\^Uls\M^Y\M-D\M-5{\M-6\M-3d\M-U\M-P\M-Ck\M-*7\a\^U\^W\M-^\M^Il\M-n\M-,\0\0\0 M\M-G"...,8192) = 364 (0x16c)
 2506: write(2,"couldn't query Security extension on display ":0"\n",50) = 50 (0x32)

One can simulate the xauth call locally and without redirecting STDERR and
will see the same error:

$ /usr/local/bin/xauth -f /tmp/xauthfile generate :0 MIT-MAGIC-COOKIE-1 untrusted timeout 1260
/usr/local/bin/xauth:  file /tmp/xauthfile does not exist
/usr/local/bin/xauth: (argv):1:  couldn't query Security extension on display ":0"

This, and the fact that my colleagues (coming from Ubuntu workstations)
do not face the problem, let me strongly think in a LOCAL problem, maybe
of the Xorg server which is xorg-7.7_2 from the ports.

I straced as well the remote sshd while I ssh'ed into the server. On the remote side there
is no xauth called:

$ grep exec sshd.tr
1369  execve("/usr/sbin/sshd", ["/usr/sbin/sshd", "-D", "-R"], [/* 3 vars */] <unfinished ...>
1369  <... execve resumed> )            = 0
1373  execve("/bin/bash", ["-bash"], [/* 12 vars */]) = 0
1375  execve("/usr/bin/readlink", ["readlink", "/proc/1373/exe"], [/* 15 vars */]) = 0
1377  execve("/usr/bin/tty", ["tty"], [/* 15 vars */]) = 0
1379  execve("/bin/uname", ["/bin/uname", "-n"], [/* 16 vars */]) = 0
1381  execve("/bin/uname", ["/bin/uname", "-m"], [/* 16 vars */]) = 0
1383  execve("/usr/bin/manpath", ["/usr/bin/manpath", "-q"], [/* 32 vars */]) = 0
1385  execve("/usr/bin/ls", ["ls", "/etc/bash_completion.d"], [/* 38 vars */]) = 0
1387  execve("/usr/bin/tty", ["tty"], [/* 43 vars */]) = 0
1391  execve("/usr/bin/sed", ["sed", "-r", "s@/*:|([^\\\\]):@\\1\\n@g;H;x;s@/\\n@"...], [/* 48 vars */]) = 0
1395  execve("/usr/bin/sed", ["sed", "-r", "s@/*:|([^\\\\]):@\\1\\n@g;H;x;s@/\\n@"...], [/* 49 vars */]) = 0
1397  execve("/usr/bin/dircolors", ["/usr/bin/dircolors", "-b", "/etc/DIR_COLORS"], [/* 53 vars */]) = 0
1399  execve("/usr/bin/tput", ["/usr/bin/tput", "hs"], [/* 55 vars */]) = 0
1401  execve("/usr/bin/tput", ["/usr/bin/tput", "tsl"], [/* 55 vars */]) = 0
1403  execve("/usr/bin/tput", ["/usr/bin/tput", "fsl"], [/* 55 vars */]) = 0
1405  execve("/usr/bin/tput", ["tput", "sc"], [/* 55 vars */]) = 0
1407  execve("/usr/bin/tput", ["tput", "rc"], [/* 55 vars */]) = 0
1410  execve("/usr/bin/tty", ["tty"], [/* 55 vars */]) = 0


$ grep xauth sshd.tr
$ 

The problem is LOCAL on FreeBSD.

Any ideas to nail this down?

Thanks

	matthias

-- 
Matthias Apitz, ✉ [email protected], http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEXmn7rBYYViyzy/vBR8z35Hb+nREFAlr0j4AACgkQR8z35Hb+
nRGL4RAAk/XOJsCGECWa7Y3bWKrDK7y015w7kN/DvJsSho5c2AHbZWMLyHuI/8Gs
nRJAV61pgSaTexsszriXnQje/UKe2JqliF7GVDuaNwCrxZU+YxoJSQEWDRtG9A/p
aKrjMFOUu6Er6sQA3pVrUlydCHF+7Mz/N+NLLjxM4VTJwcJBmVxcpwmww8b8dt+q
sLdrcq8I36iGDTt+6sUgKfaOADvOSEuCDeGpzSlG2bizCwJ/JGkxRnANvqXJlvat
ftZvsNioW79zy0MwGW99Fc0CltaTUUq6cFrdVAHrr02PL5heX/eqJyP8B8c+vugS
Y6Q4ByQl9r1l0ITaVFE/RAUYvDKZ3nUgK0/k733zE7NqGmsTSnoJx1yvV7bW8hpx
08T8L2BcIg48e4cU8RHFEgiu4vZOas1H4KIK3o4onsGOWu8/QJT5anGlQrnHYxEs
R20UGcTAEb69ssYoxeGv3DJ+wYsEQgNbMT3todhfAMPqjRlalycLBOSjpwsF+wAB
Ju/7iyL3BwhsMovVFOBMlqhs/ai/5jU1IZ9swvWR/oRmtjLzfmAdWD2FEXDboH0U
gpDTXQ5p2TFnNBvGEALYqbVMvPW4OvX0tKa9MqvqBerhPg40hGgoGZIC5FQDvPqN
VLf2ZKolg7NuBYycaIc9u6x7BdTFO+G0FxRKWaghzWNcSQrIcYI=
=UGbV
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.