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.
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.
Maybe you are hitting against a problem I encountered once. I was experimenting with using addresses on the 127.* network for vserver `localhost' interfaces, much as you seem to be with routable addresses. I can't remember the details, save that the problems I discovered started with ssh X11 forwarding not working - and following the function calls in the source 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.
This was with an old version of vserver (ctx17), but I decided that requiring a patched libc to use vservers was a bit out of the question, as this bug would affect more than just SSH. Though it is not strictly required by the RFCs for localhost to be 127.0.0.1, the fact that the C library has it hardcoded, would not seem to lend itself well to the approach working in general. Besides, IPv6 *does* specify ::1 as being the loopback interface. I was stone-walled by the libc maintainers, and eventually decided this approach was not future-proof enough.
So, to implement per-vserver localhost, I realised I would have had to implement some kind of transparent masquerading of each vserver's `localhost' interface to per-vserver addresses. Unfortunately I wimped out at this point, but I think Alex Lyashkov has a similar feature in his fork of vserver.
In any case, it is highly recommended if you are concerned about network security to use iptables firewalling in the root server to only permit inward connections to your well known services - I highly recommend fwbuilder as it has an excellent network object model, a great GUI and works well with Linux vservers. Be sure to get the 1.1+ release, earlier releases have this annoying habit of automatically `up'ing vserver alias interfaces for you, but with the wrong name.
HTH, Sam.
Christian Jaeger wrote:
Hello
There's a problem in the interaction between (ssh and xauth and (linux-vserver or non-127.0.0.1 localhost ip's)):
If you use another ip than 127.0.0.1 (like say, 10.0.1.1) for localhost purposes like me (and use a /etc/hosts file like this:
10.0.1.1 localhost
192.186.1.1 ourvirtualhostname
), then ssh -X into this vserver won't work anymore except when you put "x11uselocalhost no" into the serverside sshd_config - but this opens up your X socket to non-local clients, which is not a good idea when considering the possibility of the presence of security holes in the X server code.
The script here solves the problem: http://pflanze.mine.nu/~chris/vserver/xauth
It changes the hostname for the setup of the authentification cookie from "unix" to "localhost" - this is all it takes to make the X authentification work again.
I'm cross-posting this to the openssh mailing list. Should openssh be changed, or should xauth be changed? What is the reason for the "unix" argument and why doesn't it work for the vserver/'strange-localhost' case?
Cheers Christian. _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
