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 all.
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 1.2.3.4:22->5.6.7.8:51724 (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 1.2.3.4: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.
Christian.
(BTW for some reason I don't get mail from the secureshell mailing list anymore for a few days now)
_______________________________________________
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
