Date: Thu, 10 May 2018 17:01:54 +0200 From: Matthias Apitz <guru@unixarea.de> To: Valeri Galtsev <galtsev@kicp.uchicago.edu> Cc: "James B. Byrne" <byrnejb@harte-lyne.ca>, freebsd-questions@freebsd.org Subject: Re: ssh -X remote does not work due to problem with xauth Message-ID: <20180510150154.GA2699@c720-r314251> In-Reply-To: <7edbad31-8ac8-9c27-2536-9a9a37a579b6@kicp.uchicago.edu> References: <mailman.103.1525953601.52518.freebsd-questions@freebsd.org> <587e3b37-c5c7-4af2-80e2-f7c040a4d221@unixarea.de> <7edbad31-8ac8-9c27-2536-9a9a37a579b6@kicp.uchicago.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
El d=C3=ADa jueves, mayo 10, 2018 a las 09:38:16a. m. -0500, Valeri Galtsev=
escribi=C3=B3:
>=20
>=20
> On 05/10/18 09:00, Matthias Apitz wrote:
> > On Thursday, 10 May 2018 14:34:27 CEST, James B. Byrne=20
> > <byrnejb@harte-lyne.ca> wrote:
> >>
> >> On Wed, May 9, 2018 14:09, Matthias Apitz wrote:
> >>
> >> What is the ownership of and permissions on .Xauthority on the remote
> >> host?
> >>
> >=20
> > It's owned by me, created as new if not there, but with size=3D0.
>=20
> Did you check that you are not up against hard quota, and the filesystem=
=20
> is not full? I already suggested that, but my message seems to miss your=
=20
> attention. One thing you can try on remote host is:
The remote host is one of our central development hosts, has not quota,
no file sys full and plenty much GB of disk space:
$ scp /boot/kernel/kernel apitzm@s70devl:.
$ ssh apitzm@s70devl ls -lh kernel
-r-xr-xr-x 1 apitzm apitzm 26M 10. Mai 16:49 kernel
$ ssh apitzm@s70devl LANG=3DC df -kh .
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_root-lv_root 337G 68G 268G 21% /
> Another possibility on multi-user system when this works for others but=
=20
> not for you is if you as UNIX user is prohibited [X]-forwarding by=20
> sysadmin (-"fascist"). I as sysadmin only twice during last decade had=20
> to restrict one single user from doing something, but it still is the=20
> possibility.
I don't think, that our IT department does such things against the Tech Head
I am :-)
I do thank for all replies, but have to say, that all ignored the provided=
=20
truss output (at least in all replies). Here it is again and shows that
there is a LOCAL problem; the LOCAL /usr/local/bin/xauth tries to
create the LOCAL file /tmp/ssh-adSkh4btDHWr/xauthfile (perhaps to move it o=
ver
the SSH channel to the remote end) and it fails doing this:
$ grep xauth ssh.tr
2505: stat("/usr/local/bin/xauth",{ mode=3D-rwxr-xr-x ,inode=3D15268663,si=
ze=3D41056,blksize=3D32768 }) =3D 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) =3D 153 (0x99)
2506: execve("/usr/local/bin/xauth",0x80145a260,0x80145a408) =3D 0 (0x0)
2506: stat("/tmp/ssh-adSkh4btDHWr/xauthfile-c",0x7fffffffdb80) ERR#2 'No s=
uch file or directory'
2506: openat(AT_FDCWD,"/tmp/ssh-adSkh4btDHWr/xauthfile-c",O_WRONLY|O_CREAT=
|O_EXCL,0600) =3D 3 (0x3)
2506: pathconf("/tmp/ssh-adSkh4btDHWr/xauthfile-c",_PC_LINK_MAX) =3D 32767=
(0x7fff)
2506: link("/tmp/ssh-adSkh4btDHWr/xauthfile-c","/tmp/ssh-adSkh4btDHWr/xaut=
hfile-l") =3D 0 (0x0)
2506: access("/tmp/ssh-adSkh4btDHWr/xauthfile",F_OK) ERR#2 'No such file o=
r 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 o=
r directory'
2506: write(2,"/usr/local/bin/xauth: file /tmp/ssh-adSkh4btDHWr/xauthfile=
does not exist\n",75) =3D 75 (0x4b)
2506: access("/tmp/kde-guru/xauth-1001-_0",R_OK) =3D 0 (0x0)
2506: open("/tmp/kde-guru/xauth-1001-_0",O_RDONLY,0666) =3D 4 (0x4)
2506: write(2,"/usr/local/bin/xauth: (argv):1: ",33) =3D 33 (0x21)
2506: lstat("/tmp/ssh-adSkh4btDHWr/xauthfile-c",{ mode=3D-rw------- ,inode=
=3D24961,size=3D0,blksize=3D32768 }) =3D 0 (0x0)
2506: unlink("/tmp/ssh-adSkh4btDHWr/xauthfile-c") =3D 0 (0x0)
2506: lstat("/tmp/ssh-adSkh4btDHWr/xauthfile-l",{ mode=3D-rw------- ,inode=
=3D24961,size=3D0,blksize=3D32768 }) =3D 0 (0x0)
2506: unlink("/tmp/ssh-adSkh4btDHWr/xauthfile-l") =3D 0 (0x0)
2505: unlink("/tmp/ssh-adSkh4btDHWr/xauthfile") ERR#2 'No such file or dir=
ectory'
2505: write(2,"Warning: untrusted X11 forwarding setup failed: xauth key d=
ata not generated\r\n",78) =3D 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\bni=
stp256\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-C=
k\M-*7\a\^U\^W\M-^\M^Il\M-n\M-,\0\0\0 M\M-G"...,8192) =3D 364 (0x16c)
2506: write(2,"couldn't query Security extension on display ":0"\n",50) =
=3D 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 unt=
rusted timeout 1260
/usr/local/bin/xauth: file /tmp/xauthfile does not exist
/usr/local/bin/xauth: (argv):1: couldn't query Security extension on displ=
ay ":0"
This, and the fact that my colleagues do not face the problem, let me
strongly think in a LOCAL problem, maybe of the Xorg server which is xorg-7=
=2E7_2
=66rom the ports.
Thanks again for reading my post.
matthias
--=20
Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ +49-176=
-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
May, 9: =D0=A1=D0=BF=D0=B0=D1=81=D0=B8=CC=81=D0=B1=D0=BE =D0=BE=D1=81=D0=B2=
=D0=BE=D0=B1=D0=BE=D0=B4=D0=B8=D1=82=D0=B5=D0=BB=D0=B8! Thank you very much=
, Russian liberators!
--LZvS9be/3tNcYl/X
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEXmn7rBYYViyzy/vBR8z35Hb+nREFAlr0Xt8ACgkQR8z35Hb+
nRFgwxAAkrfh+dibUbKJfqmDNIIdDWUPOFHoz8IIOQmanfczJwSMV0fXVMH572CJ
Mc88PVHO3f8+l//Go82NJx0saHkac+VYGCgkpXga5DfFI55NhDSyPm5PsRq6NLt4
X10Al/71RGAtkcB1m51lW6CpqXk0eI02at4NfgqmTqTJL/9bLqrNKMbl84aUPWdN
8PgxXeXyZ4Rmrae9QhTG9O1e4noWg+esNXO8bGTdCjf9cHJ/514XqGrhE3++wRjG
nkstd+7oVm05pc1M/k4EIwSoZ5ga1g3ePs/3U7L+3xPOwGP0oUXFVqkm+H9LtOxz
JkyMPBnGGre7mddMQTyNdf301thB4HN5ycrqlnTiG13jioA2YESF/xLHry7ddJGF
Ti6ynma+VacYHelcWubVxHMTQWTRD1rld3MNWzBwDm5d3tEg/8i+VXpJTf+aZgTM
+N2+vfQNpFI+6nvmgt/k27u2pmK8WohLS0f+cMZ549k04LiI0DJFeOUG1Vy4ha11
Sa9yxeabxf/imECvtg9P9r9OeM2R9jH1+5e+VvQZXAIQr8SzO32jlnhQhurFKxAR
R7R3D0XTDCc3y1uqdq8GRY7xI4Ldhgr9xpcHBx2EPWdX7004HChdx6lWV3VtDwKG
zyarTAuS5S818w0tWFyWkpEyGveUjXvlcezWzxMw/1NH0L1T03I=
=dd9/
-----END PGP SIGNATURE-----
--LZvS9be/3tNcYl/X--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180510150154.GA2699>