What does "X11UseLocalhost no" do?
Randy Yates
FC4/linux box to a bsd machine, run xclients on the bsd machine, and
have them X display back to my home machine without specifying the
"X11UseLocalhost no" option in the /etc/ssh/sshd_config file.
I don't understand what the manpage says about this option. Can
someone please explain?
--
% Randy Yates % "Bird, on the wing,
%% Fuquay-Varina, NC % goes floating by
%%% 919-577-9882 % but there's a teardrop in his eye..."
%%%% <ya...@ieee.org> % 'One Summer Dream', *Face The Music*, ELO
http://home.earthlink.net/~yatescr
Randy Yates
> I found that I can't ssh (with X11 port forwarding) from my home
> FC4/linux box to a bsd machine, run xclients on the bsd machine, and
> have them X display back to my home machine without specifying the
> "X11UseLocalhost no" option in the /etc/ssh/sshd_config file.
That is, the sshd_config file on the bsd machine.
--
% Randy Yates % "And all that I can do
%% Fuquay-Varina, NC % is say I'm sorry,
%%% 919-577-9882 % that's the way it goes..."
%%%% <ya...@ieee.org> % Getting To The Point', *Balance of Power*, ELO
http://home.earthlink.net/~yatescr
Richard E. Silverman
RY> I found that I can't ssh (with X11 port forwarding) from my home
RY> FC4/linux box to a bsd machine, run xclients on the bsd machine,
RY> and have them X display back to my home machine without specifying
RY> the "X11UseLocalhost no" option in the /etc/ssh/sshd_config file.
RY> I don't understand what the manpage says about this option. Can
RY> someone please explain?
When doing X forwarding, sshd listens on a TCP socket for connections from
X clients. Normally, it will accept connections addressed to the loopback
address only (127.0.0.1), restricting it to clients on the local host.
X11UseLocalhost no means it will accept connections from anywhere.
--
Richard Silverman
r...@qoxp.net
Randy Yates
Thank you for this explanation, Richard. However, I'm afraid I still
don't quite understand.
Since I am constantly getting confused over who's the "source" and
who's the "destination" allow me to establish the following convention.
If an "entity" resides on a source I'll use the suffice ".src" and
likewise ".dst" for the destination.
So in this scenario I'm running the ssh.src client on host.src and
connecting to the sshd.dst server running on host.dst, and I had
established the option "X11UseLocalhost no" in the sshd_config.dst
file. I am then attempting to run X11 clients on host.dst.
In that scenario I *was* running xclients on the local host, i.e., on
host.dst. The DISPLAY.dst variable was set to localhost:10.0 and
127.0.0.1:10.0 and in both cases X client connections were refused
when the X11UseLocalhost yes option was set in sshd_config.dst.
However, host.dst is the host at my ISP where he runs "virtual
machines" under bsd. Could it be that this virtual machine is
causing the problem?
--
% Randy Yates % "Remember the good old 1980's, when
%% Fuquay-Varina, NC % things were so uncomplicated?"
%%% 919-577-9882 % 'Ticket To The Moon'
%%%% <ya...@ieee.org> % *Time*, Electric Light Orchestra
http://home.earthlink.net/~yatescr
Neil W Rickert
>Thank you for this explanation, Richard. However, I'm afraid I still
>don't quite understand.
Let me try to explain differently.
I am currently logged into my work machine from home, and I am doing
X-forwarding.
In the shell on my work machine:
% echo $DISPLAY
localhost:10
% netstat -an | grep '60.*LISTEN'
*.6000 *.* 0 0 24576 0 LISTEN
127.0.0.1.6010 *.* 0 0 24576 0 LISTEN
The first of those output lines is because I am running an
X-server on the work machine. That line has nothing to do with X
forwarding. The second line, with the "127.0.0.1.6010" corresponds
to DISPLAY="localhost:10" with the X-forwarding.
If I were to use "X11UseLocalhost no", then the output from those
commands would instead be:
% echo $DISPLAY
host:10
% netstat -an | grep '60.*LISTEN'
*.6000 *.* 0 0 24576 0 LISTEN
*.6010 *.* 0 0 24576 0 LISTEN
Note that the "10" in $DISPLAY could be 11, 12, ... in which case
the corresponding netstat line would be for port 6011 or 6012 or ...
>In that scenario I *was* running xclients on the local host, i.e., on
>host.dst. The DISPLAY.dst variable was set to localhost:10.0 and
>127.0.0.1:10.0 and in both cases X client connections were refused
>when the X11UseLocalhost yes option was set in sshd_config.dst.
Your $DISPLAY looks okay.
When you say "connections were refused", this could mean either of
two things. It could mean that the network connection was refused,
or it could mean that authentication was refused by the X-server.
Checking "netstat" output should help. You should see a listener
on port 6010 for your DISPLAY value.
If there is no listener on port 6010, then your sshd server
does not allow X-forwarding. That has to be fixed in the sshd
configuration on the server. If there is a listener, but you are
not authenticating properly to the X-server, then something is
funky about .Xauthority or whatever file xauth is using.
I hope that helps tell you what to look for.
--
DO NOT REPLY BY EMAIL - The address above is a spamtrap.
Neil W. Rickert, Computer Science, Northern Illinois Univ., DeKalb, IL 60115
Randy Yates
$ xterm
X11 connection rejected because of wrong authentication.
X connection to localhost:10.0 broken (explicit kill or server shutdown).
> Checking "netstat" output should help. You should see a listener
> on port 6010 for your DISPLAY value.
[dc_admin@uspsdata ~]$ netstat -an
netstat: kvm not available
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 200.46.204.173.6010 *.* LISTEN
> If there is no listener on port 6010, then your sshd server
> does not allow X-forwarding. That has to be fixed in the sshd
> configuration on the server. If there is a listener, but you are
> not authenticating properly to the X-server, then something is
> funky about .Xauthority or whatever file xauth is using.
Do you mean .Xauthority.dst? How would I investigate/fix
such a problem? And why does placing "X11UseLocalhost no"
make it work?
> I hope that helps tell you what to look for.
Thanks Neil. By the way, do you know of a good tutorial on X11
operation/security? This .Xauthority file and xhosts and xauth and
blah-blah-blah constantly confuse me and I've never really understood
it all.
--
% Randy Yates % "...the answer lies within your soul
%% Fuquay-Varina, NC % 'cause no one knows which side
%%% 919-577-9882 % the coin will fall."
%%%% <ya...@ieee.org> % 'Big Wheels', *Out of the Blue*, ELO
http://home.earthlink.net/~yatescr
Neil W Rickert
>$ xterm
>X11 connection rejected because of wrong authentication.
>X connection to localhost:10.0 broken (explicit kill or server shutdown).
>> Checking "netstat" output should help. You should see a listener
>> on port 6010 for your DISPLAY value.
>[dc_admin@uspsdata ~]$ netstat -an
>netstat: kvm not available
>Active Internet connections (including servers)
>Proto Recv-Q Send-Q Local Address Foreign Address (state)
>tcp4 0 0 200.46.204.173.6010 *.* LISTEN
Weird. Have you tried setting $DISPLAY to "200.46.204.173:10"?
Or does "localhost" resolve to "200.46.204.173" when you do an IP
address lookup on your system? Or were you using "X11UseLocalhost
no" when you did that "netstat"?
>> If there is a listener, but you are
>> not authenticating properly to the X-server, then something is
>> funky about .Xauthority or whatever file xauth is using.
That seems to be your problem.
>Do you mean .Xauthority.dst? How would I investigate/fix
Try
xauth list
It should list the correct file. (Don't post the data).
> And why does placing "X11UseLocalhost no"
>make it work?
With the default "X11UseLocalhost yes", the xauth data for my
connection looks like
hostname/unix:10 MIT-MAGIC-COOKIE-1 0000000000000000000000000000000
(I changed the numeric data to all 0s to suppress the actual value, and
I replaced the actual hostname with the numeric value).
If I were to use "X11UseLocalhost no", then instead, it would say:
hostname:10 MIT-MAGIC-COOKIE-1 0000000000000000000000000000000
The use of "hostname/unix:10" might not be supported by older
X11 software. Instead, it might be looking for an entry for
"localhost:10". If you have that problem, you could try
xauth add localhost:10 MIT-MAGIC-COOKIE-1 0000000000000000000000000000000
to see if that works. Replace the string of zeros by the actual value
that xauth lists for the "hostname/unix:10" line.
If that happens to fix your problem, you could probably add lines
in ".profile" to do the fixup whenever you login.
>Thanks Neil. By the way, do you know of a good tutorial on X11
>operation/security? This .Xauthority file and xhosts and xauth and
>blah-blah-blah constantly confuse me and I've never really understood
>it all.
Off hand, no. I normally use the man pages for that kind of info.
But there is probably a decent web site somewhere.
The wikipedia entry
http://en.wikipedia.org/wiki/X_Window_System
might be a good starting point.
Per Hedeland
Rickert <phis...@cs.niu.edu> writes:
>Randy Yates <ya...@ieee.org> writes:
>>Neil W Rickert <phis...@cs.niu.edu> writes:
>
>>$ xterm
>>X11 connection rejected because of wrong authentication.
>>X connection to localhost:10.0 broken (explicit kill or server shutdown).
>
>>> Checking "netstat" output should help. You should see a listener
>>> on port 6010 for your DISPLAY value.
>
>>[dc_admin@uspsdata ~]$ netstat -an
>>netstat: kvm not available
>>Active Internet connections (including servers)
>>Proto Recv-Q Send-Q Local Address Foreign Address (state)
>>tcp4 0 0 200.46.204.173.6010 *.* LISTEN
>
>Weird. Have you tried setting $DISPLAY to "200.46.204.173:10"?
>
>Or does "localhost" resolve to "200.46.204.173" when you do an IP
>address lookup on your system? Or were you using "X11UseLocalhost
>no" when you did that "netstat"?
I believe the above is an effect of what Randy mentioned earlier:
>>>>However, host.dst is the host at my ISP where he runs "virtual
>>>>machines" under bsd. Could it be that this virtual machine is
>>>>causing the problem?
At least for FreeBSD's 'jail' functionality, the jail(2) man page
(http://www.freebsd.org/cgi/man.cgi?query=jail&sektion=2) says:
All IP activity will be forced to happen to/from the IP number
specified, which should be an alias on one of the network interfaces.
I.e. it can be expected (I haven't verified this) that an attempt to
bind() a socket to any other specific address (including 127.0.0.1,
which would "belong" to the jail-hosting host) is transformed into a
bind() to the jail-specific address. It could possibly also explain the
failure of the connection - as I read the above, an attempt to connect
to 127.0.0.1 should proceed with the destination address unchanged, but
with the source address transformed to the jail-specific address.
Such a connection should definitely fail, and possibly not with the
"Connection refused" that would be expected on a "normal" host where
nothing was listening on a matching address/port - I can't see how it
could get as far as attempting authentication though, but maybe that's
just lack of precision in the error message from Xlib.
As an aside, calling a FreeBSD 'jail' a "virtual machine" is probably an
exaggeration - it's more like chroot on steroids. But most users of such
an ISP service are probably just interested in running a server or two
plus doing the up/downloads that may be needed in conjunction with that,
and for this it is a good match.
--Per Hedeland
p...@hedeland.org
Randy Yates
Hi Per,
Yes, I suspect you've hit the nail on the head.
> Such a connection should definitely fail, and possibly not with the
> "Connection refused" that would be expected on a "normal" host where
> nothing was listening on a matching address/port - I can't see how it
> could get as far as attempting authentication though, but maybe that's
> just lack of precision in the error message from Xlib.
What happens if the jail-specific address was abc.def.ghi.jkl.6010 while
sshd was listening on localhost.6010?
> As an aside, calling a FreeBSD 'jail' a "virtual machine" is probably an
> exaggeration - it's more like chroot on steroids. But most users of such
> an ISP service are probably just interested in running a server or two
> plus doing the up/downloads that may be needed in conjunction with that,
> and for this it is a good match.
You obviously know a lot more about this than me. I just have the
faintest notion that things are somehow "virtualized" and have
never had to be concerned about it until now.
Thanks much for shedding light, Per.
--
Randy Yates
> Randy Yates <ya...@ieee.org> writes:
>>Neil W Rickert <phis...@cs.niu.edu> writes:
>
>>$ xterm
>>X11 connection rejected because of wrong authentication.
>>X connection to localhost:10.0 broken (explicit kill or server shutdown).
>
>>> Checking "netstat" output should help. You should see a listener
>>> on port 6010 for your DISPLAY value.
>
>>[dc_admin@uspsdata ~]$ netstat -an
>>netstat: kvm not available
>>Active Internet connections (including servers)
>>Proto Recv-Q Send-Q Local Address Foreign Address (state)
>>tcp4 0 0 200.46.204.173.6010 *.* LISTEN
>
> Weird. Have you tried setting $DISPLAY to "200.46.204.173:10"?
Yes, I tried that - same error message.
> Or does "localhost" resolve to "200.46.204.173" when you do an IP
> address lookup on your system? Or were you using "X11UseLocalhost
> no" when you did that "netstat"?
No, I had set it back to "yes" temporarily.
OK, thanks.
--
% Randy Yates % "She's sweet on Wagner-I think she'd die for Beethoven.
%% Fuquay-Varina, NC % She love the way Puccini lays down a tune, and
%%% 919-577-9882 % Verdi's always creepin' from her room."
%%%% <ya...@ieee.org> % "Rockaria", *A New World Record*, ELO
http://home.earthlink.net/~yatescr
Per Hedeland
>p...@hedeland.org (Per Hedeland) writes:
>>
>> At least for FreeBSD's 'jail' functionality, the jail(2) man page
>> (http://www.freebsd.org/cgi/man.cgi?query=jail&sektion=2) says:
>>
>> All IP activity will be forced to happen to/from the IP number
>> specified, which should be an alias on one of the network interfaces.
>>
>> I.e. it can be expected (I haven't verified this) that an attempt to
>> bind() a socket to any other specific address (including 127.0.0.1,
>> which would "belong" to the jail-hosting host) is transformed into a
>> bind() to the jail-specific address. It could possibly also explain the
>> failure of the connection - as I read the above, an attempt to connect
>> to 127.0.0.1 should proceed with the destination address unchanged, but
>> with the source address transformed to the jail-specific address.
>
>Hi Per,
>
>Yes, I suspect you've hit the nail on the head.
Well, maybe not... - I tested it a bit now.:-)
>> Such a connection should definitely fail, and possibly not with the
>> "Connection refused" that would be expected on a "normal" host where
>> nothing was listening on a matching address/port - I can't see how it
>> could get as far as attempting authentication though, but maybe that's
>> just lack of precision in the error message from Xlib.
>
>What happens if the jail-specific address was abc.def.ghi.jkl.6010 while
>sshd was listening on localhost.6010?
The jail simply won't allow a process to listen on 127.0.0.1 - here's an
example of starting sshd itself inside a jail:
# /usr/sbin/sshd -o ListenAddress=127.0.0.1:2222
# netstat -an | grep 2222
tcp4 0 0 192.168.1.45.2222 *.* LISTEN
I.e. sshd's request to bind() to 127.0.0.1 was silently transformed to a
bind() to the jail-specific address (192.168.1.45 in this case). The
same happens with the default "wildcard" bind():
# /usr/sbin/sshd -p 1234
# netstat -an | grep 1234
tcp4 0 0 192.168.1.45.1234 *.* LISTEN
However, it seems I was wrong about the connection to 127.0.0.1 having
its destination address untouched:
# telnet 127.0.0.1 1234
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.2p1 FreeBSD-20050903
^]
telnet> z
Suspended
# netstat -an | grep 1234
tcp4 0 0 192.168.1.45.1234 192.168.1.45.52789 ESTABLISHED
tcp4 0 0 192.168.1.45.52789 192.168.1.45.1234 ESTABLISHED
tcp4 0 0 192.168.1.45.1234 *.* LISTEN
I.e. that connection had both source and destination address transformed
from 127.0.0.1 to 192.168.1.45 (could be that the jail functionality
just transformed the destination address, the source would follow from
that with standard IP routing logic).
So, at this point I really have no explanation for either your failure
with X11UseLocalhost=yes or your success with X11UseLocalhost=no - only
for the netstat output.:-) Probably Neil was more on track with the
suggestions about checking xauth and ~/.Xauthority, there could be some
mismatch with the data there due to the jail transformations. The jail
I'm testing on isn't really set up for allowing ssh into it, and in
particular not for X11 forwarding back out (no X11 binaries or
libraries), so I can't check that.
>You obviously know a lot more about this than me. I just have the
>faintest notion that things are somehow "virtualized" and have
>never had to be concerned about it until now.
Oh, I didn't mean to critize your terminology - I assumed that your ISP
called the service "virtual machine".
--Per Hedeland
p...@hedeland.org