xhost fails in new install

classic Classic list List threaded Threaded
9 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
Reply | Threaded
Open this post in threaded view
|

Re: xhost fails in new install

Oliver Doepner
Hi Mike,

Another consideration regarding the remote X problems:
- You could use sshfs to mount the remote directory into your local filesystem
- then run xpdf, display, or whatever other x-requiring program locally to open files from the locally mounted (but physically remote) directory.

For example, This is what I use to mount the directory that contains our photo and video archives from our family file server ("bubba") on my local machine (my laptop, for example). The "-o ro" is for read-only access:   sshfs -o ro oliver@bubba:/home/storage ~/bubba/storage

All you need is the sshfs package installed on the (local) client system and sshd installed on the (remote) server system.

If you have inconsistent numeric user ids on the 2 systems (e.g. user "oliver" might have id 1001 locally and 1002 remotely), you can add "-o idmap=user".

No root, no remote X complication and slowness, no fiddling with DISPLAY, no security compromises.

Cheers  :)
Oliver


On Tue, Nov 12, 2019 at 10:10 PM George N. White III <[hidden email]> wrote:
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

_______________________________________________
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

Problem solved!

X forwarding does *not* work with:

  + startx, then ssh -X
  + startx, then ssh -X and setenv DISPLAY bogus:0
  + startx, then ssh -Y
  + startx, then ssh -Y and setenv DISPLAY bogus:0
  + startx, then ssh -AX
  + startx, then ssh -AX and setenv DISPLAY bogus:0
  + [got bored here, stopped trying variants]

X forwarding works with telnet if:

  + bogus% startx -- -listen tcp

  + bogus-root% xhost  +roadgrime

  + bogus% telnet roadgrime

  + roadgrime% xterm &

X forwarding works with ssh if:

  + bogus% startx -- -listen tcp

  + bogus-root% xhost +roadgrime

  + bogus% ssh roadgrime

  + roadgrime% setenv DISPLAY bogus:0

  + roadgrime% xterm &

After ssh login, DISPLAY (in tcsh) isn't automatically set and
forwarding fails.  Using the "-display bogus:0" switch works as an
alternative to setting the DISPLAY envar.

After telnet login, DISPLAY *is* automatically set and forwarding
works if the other incantations above have been invoked.

Exhaustive testing -- restarting X over and over again -- is tedious
and error prone but I *think* the above is both necessary and
sufficient.

So: always startx with [no client args] " -- " [one server option],
"startx -- -listen tcp".


Oliver wrote:

> Another consideration regarding the remote X problems:
>
> - You could use sshfs to mount the remote directory into your local
> filesystem
>
> - then run xpdf, display, or whatever other x-requiring program
> *locally* to open files from the locally mounted (but physically
> remote) directory.

I mount (any one of 5) other machines on each other all the time.
Never heard of sshfs.  I have the same username & numerical ID on all
my computers so files on mounted remote $OTHERHOST that are accessible
to mds are available to mds on $HOST.

Interesting aside: On the old system/old browser, the browser would
*not* access files across mounts.  mount -t ext2 /dev/hda3 /mnt/moyet,
then try to access in the browser /mnt/moyet/html/file.html failed.
No longer the case. ()()()

> No root, no remote X complication and slowness, no fiddling with
> DISPLAY, no security compromises.

There was no complication, slowness, fiddling or security problems
before.  Looks like changing the startx invocation will restore that.

How the (apparent) necessity to start X with -listen tcp amd invoke
xhost relates to the assertion (here and elsewhere) that X forwarding
"just works" over ssh remains totally unclear.

Thanks all for various pointers.  Didn't know about Xserver options or
how to pass them when starting X before.  Defaults were always okay.


--
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

George N. White III
On Sun, 17 Nov 2019 at 00:43, Mike <[hidden email]> wrote:

Problem solved!

Glad  you got something that works for you.
 

X forwarding does *not* work with:

  + startx, then ssh -X
  + startx, then ssh -X and setenv DISPLAY bogus:0
  + startx, then ssh -Y
  + startx, then ssh -Y and setenv DISPLAY bogus:0
  + startx, then ssh -AX
  + startx, then ssh -AX and setenv DISPLAY bogus:0
  + [got bored here, stopped trying variants]

Your DISPLAY setting is not X forwarding.  The distinction is
important because of the security implications.  See:

Verbose (-v or -vv, etc.) output from ssh is used to find out why
forwarding fails.   You don't mention if your session got a 
DISPLAY=localhost:10 setting.   If forwarding was working your 
ssh session would have "DISPLAY=localhost:10".

 

X forwarding works with telnet if:

  + bogus% startx -- -listen tcp

  + bogus-root% xhost  +roadgrime

  + bogus% telnet roadgrime

  + roadgrime% xterm &


There is no such thing as X forwarding with telnet.   You don't say how DISPLAY 
is set, but I assume "setenv DISPLAY bogus:0"

The "listen tcp" just allows the X-server on bogus (the remote host) to directly
accept connections from roadgrime using DISPLAY=bogus:0
 
X forwarding works with ssh if:

  + bogus% startx -- -listen tcp

  + bogus-root% xhost +roadgrime

  + bogus% ssh roadgrime

  + roadgrime% setenv DISPLAY bogus:0

  + roadgrime% xterm &

After ssh login, DISPLAY (in tcsh) isn't automatically set and
forwarding fails.  Using the "-display bogus:0" switch works as an
alternative to setting the DISPLAY envar.

After telnet login, DISPLAY *is* automatically set and forwarding
works if the other incantations above have been invoked.

Exhaustive testing -- restarting X over and over again -- is tedious
and error prone but I *think* the above is both necessary and
sufficient.

Exahaustive testing without refering to the diagnostics is a waste of
time.    A comon reason for forwarding to fail is applying bad advice 
from the internet to configure ssh so it ignores failures in host key
authentication.   This allows you to have an ssh terminal session 
even though the remote system does not pass the identity test, but 
won't allow X forwarding.   
 

So: always startx with [no client args] " -- " [one server option],
"startx -- -listen tcp".


Oliver wrote:

> Another consideration regarding the remote X problems:
>
> - You could use sshfs to mount the remote directory into your local
> filesystem
>
> - then run xpdf, display, or whatever other x-requiring program
> *locally* to open files from the locally mounted (but physically
> remote) directory.

I mount (any one of 5) other machines on each other all the time.
Never heard of sshfs.  I have the same username & numerical ID on all
my computers so files on mounted remote $OTHERHOST that are accessible
to mds are available to mds on $HOST.

Interesting aside: On the old system/old browser, the browser would
*not* access files across mounts.  mount -t ext2 /dev/hda3 /mnt/moyet,
then try to access in the browser /mnt/moyet/html/file.html failed.
No longer the case. ()()()

> No root, no remote X complication and slowness, no fiddling with
> DISPLAY, no security compromises.

There was no complication, slowness, fiddling or security problems
before.  Looks like changing the startx invocation will restore that.

How the (apparent) necessity to start X with -listen tcp amd invoke
xhost relates to the assertion (here and elsewhere) that X forwarding
"just works" over ssh remains totally unclear.

The first step is to use verbose mode with ssh.
 
Thanks all for various pointers.  Didn't know about Xserver options or
how to pass them when starting X before.  Defaults were always okay.

The defaults have evolved as older configurations are found to 
be insecure.     
 
--
George N. White III


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