Re: [Vserver] ssh -X login without "x11uselocalhost no"

From: Christian Jaeger (
Date: 04/26/04

  • Next message: Steven Carter: "Requiring non-empty passphrase."
    Date: Mon, 26 Apr 2004 14:24:54 +0200
    To: Sam Vilain <>

    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> (ESTABLISHED)
    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 (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
    >- 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 If they see "localhost" in the
    cookie, they resolve "localhost" and try the resulting correct ip And that only the fact that X clients fall back to 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)

  • Next message: Steven Carter: "Requiring non-empty passphrase."