Re: [Vserver] ssh -X login without "x11uselocalhost no"
From: Christian Jaeger (christian.jaeger_at_ethlife.ethz.ch)
Date: Mon, 26 Apr 2004 14:24:54 +0200 To: Sam Vilain <email@example.com>
At 16:00 Uhr +1200 26.04.2004, Sam Vilain wrote:
>Actually, my thoughts are that it would be nice to be able to
>disable the SSH X11 forwarding from listening on any IPv4 address at
Yes that would be nice.
>The "/unix" xauth entry is for connection over the unix socket,
>rather than TCP/IP. Unix sockets are very much like a TCP/IP
>socket, but the addresses refer to locations on the filesystem,
>typically within /tmp - rather than IPv4 network addresses. So an
>application "listens" on a filesystem path, and applications
>"connect" to that filename. `ls -l /tmp/.X11-unix' should show you
>examples of these types of sockets.
Yep that's what I guessed when seeing "unix" but I can't find the
unix socket file. lsof shows this:
sshd 15470 root 0u CHR 1,3 8 /dev/null
sshd 15470 root 1u CHR 1,3 8 /dev/null
sshd 15470 root 2u CHR 1,3 8 /dev/null
sshd 15470 root 3u unix 0xce25ab40 3266449 socket
sshd 15470 root 4u IPv4 3266398 TCP
sshd 15470 root 5r FIFO 0,5 3266451 pipe
sshd 15470 root 6w FIFO 0,5 3266451 pipe
sshd 15470 root 7u CHR 5,2 80 /dev/ptmx
sshd 15470 root 8u CHR 5,2 80 /dev/ptmx
sshd 15470 root 9u IPv4 3266460 TCP 220.127.116.11:6010 (LISTEN)
sshd 15470 root 10u CHR 5,2 80 /dev/ptmx
So yes, it does have a unix socket open, but why can't lsof show it
and why can't I find it under /tmp ? This is the same on a
non-virtual server. Using strace -f -o out sshd -d, I can see that
sshd tries to connect to /var/run/.nscd_socket but it gets a file not
found. No new socket file is created. But I see that sshd is calling
socketpair(PF_UNIX,..), so the socket shown by lsof is a pipe-like
anonymous socket to some child process. Again using lsof I see that
the process owning the other end of the socketpipe is the sshd parent
process (heh, I realize that even ssh -d does fork).
So no, the sshd does *not* have any unix socket *file* open.
>Maybe you are hitting against a problem I encountered once. (...)
>following the function calls in the source
(which source? libc, sshd, xauth?)
>one by one, I tracked the problem down to there being some
>combination of flags you can pass to the bind()/socket()/etc
>combination that specifies "a local address" rather than first
>resolving "localhost" in your application. Rather than resolving
>"localhost" for you, the libraries simply use a hardcoded 127.0.0.1
>- which, of course, doesn't work unless it's in your IPROOT, and the
>SSH X11 forwarding fails. As would port forwarding.
Well, as I said, "telnet localhost 6010" *works* (as does the whole
X11 forwarding if just the xauth cookie is correct; and xauth works
fine if you feed it "localhost" so it *does* resolve it to the
correct ip if it even does resolve it).
I think it's probably that if X clients want to connect to the X
server, and they see "unix" in the cookie, they try unix socket and
if that fails a hard-coded 127.0.0.1. If they see "localhost" in the
cookie, they resolve "localhost" and try the resulting correct ip
10.0.1.1. And that only the fact that X clients fall back to
127.0.0.1 makes the ssh X11 forwarding work at all, and that either
sshd should be changed to really offer a unix X11 socket or to use
"localhost" when setting up the authentification. Of course my
presumption would have to be verified.
(BTW for some reason I don't get mail from the secureshell mailing
list anymore for a few days now)