From: Sam Vilain (sam_at_vilain.net)
Date: Mon 26 Apr 2004 - 05:00:13 BST
Christian,
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
> Vserver_at_list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
>
>
>
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver