xhost fails in new install

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

xhost fails in new install

Mike Spencer


I often work on bogus with a telnet connection open to roadgrime in an
xterm.  Both hosts on LAN, sometimes both wired, sometime roadgrime on
wifi.

Occasionally I want to run a command (e.g. display or xpdf) in the
roadgrime telnet session that will open a window on bogus.  In the
past I've run "xhost +roadgrime" as root on bogus and all was well.

Now not so good. Example session below.  Key words seem to be "access
control enabled".  I see that there are other security methods than
xhost.  Cookbooking the suggested line from the Xauth(1) manpage seems
not to help.

Is there an easy way to restore the xhost mechanism without frying my
brain on X manpages that are, for various reasons, difficult or
impenetrable?   If not, another way to achieve the same end?

--- Begin example session ---

bogus     = desktop -- Promts are on localhost
roadgrime = laptop  -- Prompts are in a telnet session in an xterm


bogus-root#  xhost +roadgrime

   roadgrime being added to access control list

roadgrime% xpdf repair.pdf &

   Error: Can't open display: bogus.nodomain.nowhere:0

roadgrime% display anvil.jpg &

   display: unable to open X server `bogus.nodomain.nowhere:0'
            @ error/display.c/DisplayImageCommand/424.

bogus-root# xhost

     access control enabled, only authorized clients can connect
     INET:roadgrime.nodomain.nowhere

bogus% xauth extract - $DISPLAY | ssh roadgrime xauth merge -

       mds@roadgrime's password: **********

       [exits silently]

roadgrime% display anvil.jpg &

   display: unable to open X server `bogus.nodomain.nowhere:0'
            @ error/display.c/DisplayImageCommand/424.

--- End example session ---

--
Michael Spencer                  Nova Scotia, Canada
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: xhost fails in new install

George N. White III

On Sat, 9 Nov 2019 at 02:01, Mike Spencer <[hidden email]> wrote:


I often work on bogus with a telnet connection open to roadgrime in an
xterm.  Both hosts on LAN, sometimes both wired, sometime roadgrime on
wifi.

Telnet is often banned by large enterprises, in favour of ssh, which supports
tunneling X11.   Even if you are not a large enterprise, "mainstream" approaches
generally get better documentation and fewer bugs than a "legacy"
configuration.
 

Occasionally I want to run a command (e.g. display or xpdf) in the
roadgrime telnet session that will open a window on bogus.  In the
past I've run "xhost +roadgrime" as root on bogus and all was well.

Now not so good. Example session below.  Key words seem to be "access
control enabled".  I see that there are other security methods than
xhost.  Cookbooking the suggested line from the Xauth(1) manpage seems
not to help.

Is there an easy way to restore the xhost mechanism without frying my
brain on X manpages that are, for various reasons, difficult or
impenetrable?   If not, another way to achieve the same end?

Newer distros versions have been restricting root's ability to use
X11 or even to use a "root" login  Your time is better spent
reading up on sshd configuration and X11 tunneling as these
are widely used.   Note that if your system is exposed to the
internet there are constant streams of hackers trying brute
force logins on the standard ssh ports, so many people
configure a non-standard port for their personal use.

[...]

--
George N. White III


_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: xhost fails in new install

Mike Spencer

George wrote:

> On Sat, 9 Nov 2019 at 02:01, Mike Spencer <[hidden email]> wrote:
>
>> I often work on bogus with a telnet connection open to roadgrime in an
>> xterm.  Both hosts on LAN, sometimes both wired, sometime roadgrime on
>> wifi.
>
> Telnet is often banned by large enterprises, in favour of ssh, which
> supports tunneling X11.  Even if you are not a large enterprise,
> "mainstream" approaches generally get better documentation and fewer
> bugs than a "legacy" configuration.

The machines in question sit side by side, connected by a router on a
nearby shelf.  I don't see that telnet vs. ssh is a security matter.
But see infra.

>> Occasionally I want to run a command (e.g. display or xpdf) in the
>> roadgrime telnet session that will open a window on bogus.  In the
>> past I've run "xhost +roadgrime" as root on bogus and all was well.
>>
>> Now not so good. Example session below.  Key words seem to be "access
>> control enabled".  I see that there are other security methods than
>> xhost.  Cookbooking the suggested line from the Xauth(1) manpage seems
>> not to help.
>>
>> Is there an easy way to restore the xhost mechanism without frying my
>> brain on X manpages that are, for various reasons, difficult or
>> impenetrable?   If not, another way to achieve the same end?
>>
>
> Newer distros versions have been restricting root's ability to use
> X11 or even to use a "root" login.

I've seen that on *older* distros, readily fixed with:

      xhost +local:root@localhost

On my present system (4.4.14 kernel, Slackware 14.2 on bogus; 3.10.17
Slackware 14.1 on roadgrime) it appears that root can run X apps by
default without doing that.  Also, AFAICT, not relevant to my X
problem.

> Your time is better spent reading up on sshd configuration and X11
> tunneling as these are widely used.

Well, that's a little confusing.  Had to gwgle around a bit to find a
connection between choice of remote login (telnet, rsh, rlogin, ssh)
and X.  Not obvious. So what I found was:

    We are now running so-called "xauth" authentication, which allows
    only the user logged in at the console to make X client programs
    that talk to the X server controlling the screen. The former
    system, so-called "xhost" authentication allows any user logged
    into the machine to make such connections and see anything you do
    on the computer.

Not a problem.  All single user machines here.

    The Unix command ssh is a replacement for rlogin that provides
    better security and other nice features. It compresses X windows
    traffic for X clients started in an ssh session and also take care
    of setting the DISPLAY environment variable and handling X
    authentication. Thus running X windows clients from one machine to
    another becomes much easier.
    [snip]
    To run an X windows program across the network, just invoke the
    program on the remote host. It just works without setting the
    DISPLAY environment variable on the remote host or invoking xhost
    on the local host.

Okay.  Lets try that.  ssh to roadgrime from an xterm on bogus.
Does ask for the roadgrime password but connection is proceeds as
expected.

Can't run xpdf(1) or display(1), error messages appear to be from the
respective apps, not from X or ssh.  Put "ForwardX11 yes" in
/etc/ssh_config and "X11Forwarding yes" in /etc/ssh/sshd_config.
Stopped & started sshd.  X apps still don't work.

   X11 forwarding is automatically disabled if UseLogin
   is enabled.  -- sshd_config(5) manpage

   [UseLogin no -- default]

X11UseLocalhost in sshd_config changed to "no", based on
X11UseLocalhost section of sshd_config(5) manpage that I don't really
understand.  Restart sshd, reconnect via ssh and try again.  No
improvement.

No better results with "ssh -X" or "ssh -Y".  The terminal session
works but not X apps.

Ohhhhhhhhhkay, so if ssh works, X "just works" as well?

Not so.

Any pointers?

>  Note that if your system is exposed to the internet there are
> constant streams of hackers trying brute force logins on the
> standard ssh ports, so many people configure a non-standard port for
> their personal use.

Well, that's interesting.

On my dialup connection, I normally see (with tcpdump) a steady stream
of attempts to reach numerous different ports, many of them neither
"well known" nor "registered".  AFAICT, they're all dropped by
iptables. No preponderance of ports 22, 23.

Now experimenting with a "wireless gateway" device using a SIM card
and data-only account.  As presently configured,  my computer gets an
address in 10.0.0.0/8 by DHCP.  I see no unsolicited packets at all
except ARP and DHCP from the device.

Whether or not the gateway device itself is vulnerable to attack
I don't know.  The manual is long, covers features I'll never use so I
haven't read it all closely.

In any case, I still want to have basic X functionality of seeing
roadgrime's windows on bogus' screen.  But I can't figure out what X,
xauth or anything else is doing to prevent it.

xhost +roadgrime is easy. Apparently the alternative(s) not?

--
Michael Spencer                  Nova Scotia, Canada       .~.
                                                           /V\
[hidden email]                                     /( )\
http://home.tallships.ca/mspencer/                        ^^-^^
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: xhost fails in new install

Robert McKay
On 2019-11-12 06:43, [hidden email] wrote:
> Ohhhhhhhhhkay, so if ssh works, X "just works" as well?

Usually it does.. not sure what's going wrong there.

> xhost +roadgrime is easy. Apparently the alternative(s) not?

I think your problem is likely due to X no-longer listening on TCP,
instead only on unix domain sockets.

When you are using X over telnet, what's really happening is that the X
client app you are trying to run (ie, xterm or whatever) is connecting
back to whatever host is specified in the DISPLAY environment variable.
This backchannel really has nothing to do with telnet at all (other than
telnetd possibly helping to setup the DISPLAY variable). It's a separate
tcp connection, with it's own authentication (in the xhost +host case
the only authentication being the src IP address).

If the X server specified in $DISPLAY is not listening for inbound tcp
connections, then there's no way it can work.

SSH should still work, because it works somewhat differently.. the ssh
client can talk to the X11 UNIX domain socket of your local X server and
then the remote ssh server actually listens on a new UNIX domain socket
on the remote side and they both cooperate to shuffle the X data back
and forth over the ssh session. That is to say, the DISPLAY variable on
the remote host is set to a unix domain socket that is managed by sshd
on that remote host. The remote client app is then connecting over the
UNIX domain socket to sshd, which is then forwarding the traffic back to
your local UNIX domain socket on the X server that you're sitting at.

You may be able to hunt through your x startup scripts and find where it
has -nolisten tcp and remove that;

https://superuser.com/questions/560532/what-is-the-nolisten-tcp-parameter-for-x

Actually, thinking about your ssh X forwarding not working, is it
possible that the DISPLAY variable on your X server (ie, the machine you
sit at) is broken? Like perhaps you hard-coded it to something like
hostname:0.0 or whatever in your .bashrc or .profile, and then when ssh
forwards that it won't work since it wouldn't even work locally. Can you
for example open a new xterm by typing xterm from the xterm that you
tried to ssh out of?

Rob
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: xhost fails in new install

Winston MacPherson
Hi Rob,

Thanks for reaching out to me so quickly. I was wondering if you could take a look at the pinebook pro 64 sometime when you have the chance? Maybe we can meet up at some point this week or weekend. at this point I am trying to install the destro (Ubuntu) on the eMMC and get it up and running again. 

Best regards,

Winston MacPherson 

On Tue, Nov 12, 2019 at 9:53 AM Robert McKay <[hidden email]> wrote:
On 2019-11-12 06:43, [hidden email] wrote:
> Ohhhhhhhhhkay, so if ssh works, X "just works" as well?

Usually it does.. not sure what's going wrong there.

> xhost +roadgrime is easy. Apparently the alternative(s) not?

I think your problem is likely due to X no-longer listening on TCP,
instead only on unix domain sockets.

When you are using X over telnet, what's really happening is that the X
client app you are trying to run (ie, xterm or whatever) is connecting
back to whatever host is specified in the DISPLAY environment variable.
This backchannel really has nothing to do with telnet at all (other than
telnetd possibly helping to setup the DISPLAY variable). It's a separate
tcp connection, with it's own authentication (in the xhost +host case
the only authentication being the src IP address).

If the X server specified in $DISPLAY is not listening for inbound tcp
connections, then there's no way it can work.

SSH should still work, because it works somewhat differently.. the ssh
client can talk to the X11 UNIX domain socket of your local X server and
then the remote ssh server actually listens on a new UNIX domain socket
on the remote side and they both cooperate to shuffle the X data back
and forth over the ssh session. That is to say, the DISPLAY variable on
the remote host is set to a unix domain socket that is managed by sshd
on that remote host. The remote client app is then connecting over the
UNIX domain socket to sshd, which is then forwarding the traffic back to
your local UNIX domain socket on the X server that you're sitting at.

You may be able to hunt through your x startup scripts and find where it
has -nolisten tcp and remove that;

https://superuser.com/questions/560532/what-is-the-nolisten-tcp-parameter-for-x

Actually, thinking about your ssh X forwarding not working, is it
possible that the DISPLAY variable on your X server (ie, the machine you
sit at) is broken? Like perhaps you hard-coded it to something like
hostname:0.0 or whatever in your .bashrc or .profile, and then when ssh
forwards that it won't work since it wouldn't even work locally. Can you
for example open a new xterm by typing xterm from the xterm that you
tried to ssh out of?

Rob
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug

_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: xhost fails in new install

George N. White III
In reply to this post by Mike Spencer
On Tue, 12 Nov 2019 at 02:43, Mike <[hidden email]> wrote:

George wrote:

> On Sat, 9 Nov 2019 at 02:01, Mike Spencer <[hidden email]> wrote:
>
>> I often work on bogus with a telnet connection open to roadgrime in an
>> xterm.  Both hosts on LAN, sometimes both wired, sometime roadgrime on
>> wifi.
>
> Telnet is often banned by large enterprises, in favour of ssh, which
> supports tunneling X11.  Even if you are not a large enterprise,
> "mainstream" approaches generally get better documentation and fewer
> bugs than a "legacy" configuration.

The machines in question sit side by side, connected by a router on a
nearby shelf.  I don't see that telnet vs. ssh is a security matter.
But see infra.

>> Occasionally I want to run a command (e.g. display or xpdf) in the
>> roadgrime telnet session that will open a window on bogus.  In the
>> past I've run "xhost +roadgrime" as root on bogus and all was well.
>>
>> Now not so good. Example session below.  Key words seem to be "access
>> control enabled".  I see that there are other security methods than
>> xhost.  Cookbooking the suggested line from the Xauth(1) manpage seems
>> not to help.
>>
>> Is there an easy way to restore the xhost mechanism without frying my
>> brain on X manpages that are, for various reasons, difficult or
>> impenetrable?   If not, another way to achieve the same end?
>>
>
> Newer distros versions have been restricting root's ability to use
> X11 or even to use a "root" login.

I've seen that on *older* distros, readily fixed with:

      xhost +local:root@localhost

On my present system (4.4.14 kernel, Slackware 14.2 on bogus; 3.10.17
Slackware 14.1 on roadgrime) it appears that root can run X apps by
default without doing that.  Also, AFAICT, not relevant to my X
problem.

> Your time is better spent reading up on sshd configuration and X11
> tunneling as these are widely used.


Debian's "man ssh" is only slightly shorter than War and Peace,
Other distros may only have the Cliff Notes version, but
there are some helpful internet resources.  I give one
below.
 
Well, that's a little confusing.  Had to gwgle around a bit to find a
connection between choice of remote login (telnet, rsh, rlogin, ssh)
and X.  Not obvious. So what I found was:

    We are now running so-called "xauth" authentication, which allows
    only the user logged in at the console to make X client programs
    that talk to the X server controlling the screen. The former
    system, so-called "xhost" authentication allows any user logged
    into the machine to make such connections and see anything you do
    on the computer.

Not a problem.  All single user machines here.

    The Unix command ssh is a replacement for rlogin that provides
    better security and other nice features. It compresses X windows
    traffic for X clients started in an ssh session and also take care
    of setting the DISPLAY environment variable and handling X
    authentication. Thus running X windows clients from one machine to
    another becomes much easier.
    [snip]
    To run an X windows program across the network, just invoke the
    program on the remote host. It just works without setting the
    DISPLAY environment variable on the remote host or invoking xhost
    on the local host.

Okay.  Lets try that.  ssh to roadgrime from an xterm on bogus.
Does ask for the roadgrime password but connection is proceeds as
expected.

What is the value of "DISPLAY" in a local terminal on roadgrime, and
what is the value in the ssh session on bogus?
 
You may have to provide some options to ssh (or put them in some
user config file).   I usually try  "ssh -AX" and then "ssh -AY".

On the system running the sshd, "/etc/ssh/sshd_config" has:

#X11DisplayOffset 10
#X11UseLocalhost yes

The offset of 10 means the first ssh forwarding session will set "DISPLAY=localhost:10.0" for
a host with "DISPLAY=:0.0".


Can't run xpdf(1) or display(1), error messages appear to be from the
respective apps, not from X or ssh.  Put "ForwardX11 yes" in
/etc/ssh_config and "X11Forwarding yes" in /etc/ssh/sshd_config.
Stopped & started sshd.  X apps still don't work.

   X11 forwarding is automatically disabled if UseLogin
   is enabled.  -- sshd_config(5) manpage

   [UseLogin no -- default]

X11UseLocalhost in sshd_config changed to "no", based on
X11UseLocalhost section of sshd_config(5) manpage that I don't really
understand.  Restart sshd, reconnect via ssh and try again.  No
improvement.

I've always left "X11UseLocalHost yes".

No better results with "ssh -X" or "ssh -Y".  The terminal session
works but not X apps.

Ohhhhhhhhhkay, so if ssh works, X "just works" as well?

Not so.

RedHat/CentOS/ScientificLinux 5--7 and Ubuntu 16.04+18.04 LTS
have worked for me (also MacOS) with just the _config file tweaks. 
In the distance path I have had to get into the gory details of Xauth.


Any pointers?


Running ssh in "verbose" mode (as mentioned in above link) should
provide better hints about where things go wrong.

>  Note that if your system is exposed to the internet there are
> constant streams of hackers trying brute force logins on the
> standard ssh ports, so many people configure a non-standard port for
> their personal use.

Well, that's interesting.

On my dialup connection, I normally see (with tcpdump) a steady stream
of attempts to reach numerous different ports, many of them neither
"well known" nor "registered".  AFAICT, they're all dropped by
iptables. No preponderance of ports 22, 23.

Now experimenting with a "wireless gateway" device using a SIM card
and data-only account.  As presently configured,  my computer gets an
address in 10.0.0.0/8 by DHCP.  I see no unsolicited packets at all
except ARP and DHCP from the device.

Whether or not the gateway device itself is vulnerable to attack
I don't know.  The manual is long, covers features I'll never use so I
haven't read it all closely.

In any case, I still want to have basic X functionality of seeing
roadgrime's windows on bogus' screen.  But I can't figure out what X,
xauth or anything else is doing to prevent it.

xhost +roadgrime is easy. Apparently the alternative(s) not?

--
Michael Spencer                  Nova Scotia, Canada       .~.
                                                           /V\
[hidden email]                                     /( )\
http://home.tallships.ca/mspencer/                        ^^-^^
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug


--
George N. White III


_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug