ubuntu-mate, X11 cannot open the Display (solved)

[DiTBho]

so, I usually create rootfs myself (Gentoo Catalyst), this time I'm with a laptop that has Ubuntu-Mate pre-installed in flash.

I can ssh to a remote machine, everything is fine with this, but there is something wrong with X11.
Already tried/checked

• xhost +192.168.1.81 and/or xhost +
• /etc/ssh/sshd_config has "X11forwarding = yes"
• ssh remote_machine_IP -Y

ssh remote_machine_IP(192.168.1.81) -Y correctly sets the DISPLAY variable to "192.168.1.115:0.0", which is the IP of the laptop, and forces "X11forwarding=Yes" plus "trust it"; ssh connects, however, "xclock" always gets the answer "cannot open the display".

Any idea? 

server: 192.168.1.81
laptop: 192.168.1.115


notes:

• "xhost +" disables the access control, clients can connect from any host
• Enable X11 forwarding, by the -X option
• Enable trusted X11 forwarding, by using the -Y option

[DiTBho]

(
Temporary solution to get that damn X11 working
The laptop doesn't have an SSD, both kernel and rootfs are on an eMMC chip, which I can't reprogram at the moment.
For sure, in the near future, the end of March?, will definitely wipe out and flash my stage 4 onto it
)

[DiTBho]

Personally, I do find Ubuntu ... a weird distro.

I edited all the files related to both Xorg and lightdm, the default display manager used by Ubuntu-mate,
removed

Code: [Select]

-nolisten tcp
and added

Code: [Select]

-listen tcp
to every instance of parameters passed to /usr/bin/xorg, however, once restarted, it did not even show the port 6000.
Which is weird 

Even stranger, if I now connect to a remote machine via ssh, export the display, and try to launch xclock...

Code: [Select]

# xhost +
# ssh 192.168.1.81
# export DISPLAY=192.168.1.115:0.0
# xclock
it no longer says it can't find the display, it just doesn't show anything 

[DiTBho]

um, sshd has the following opts set

Code: [Select]

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost no


[alm]

I edited all the files related to both Xorg and lightdm, the default display manager used by Ubuntu-mate,
removed

Code: [Select]

-nolisten tcp
and added

Code: [Select]

-listen tcp
to every instance of parameters passed to /usr/bin/xorg, however, once restarted, it did not even show the port 6000.
Which is weird 

Try being a bit less ham-fisted, and look for a proper solution like this. Also, stop using the ancient xhost. Xauth is used for authorization these days. The less you fight a distribution, the less painful your experience will be. If you want to rip out everything and replace if with something else, then use a distribution more suited to these kinds of customizations.

What does ssh -v -X hostname show? Is xauth installed on the client you're logging in from?

[DiTBho]

Try being a bit less ham-fisted, and look for a proper solution like this.

Clumsy for what? to ensure that Xorg doesn't receive any "-nolisten TCP" parameters?
Your "proper solution", found by Googling, is *exactly* what i did about the display manager, and it didn't work.

Also, stop using the ancient xhost. Xauth is used for authorization these days. The less you fight a distribution, the less painful your experience will be. If you want to rip out everything and replace if with something else, then use a distribution more suited to these kinds of customizations.

I'm used to Gentoo, in theory a distribution like Ubuntu "should work" without having to change anything. However, if you look at the Google results, you can realize how many people are complaining, and how many have proposed it as a "temporary" solution just to understand whether or not xhost is creating problems.

[alm]

Clumsy for what? to ensure that Xorg doesn't receive any "-nolisten TCP" parameters?
Your "proper solution", found by Googling, is *exactly* what i did about the display manager, and it didn't work.

Why do you want to enable TCP listening anyhow?

Your "proper solution", found by Googling, is *exactly* what i did about the display manager, and it didn't work.

Try describing accurately what you did and what you observed, because you did not describe trying this. Just that you removed -nolisten tcp and added -listen tcp, which is not what the instructions say. Also, try to respond to questions like asking for specific output. Maybe reading and following the tips in this document will help you get more useful responses.

[DiTBho]

Why do you want to enable TCP listening anyhow?

I need X11 on port 6000.

[DiTBho]

According to this page, there several access control mechanisms that control whether a client application can connect to an X display server

• access based on host <----- old way to do it
• access based on cookie <----- "modern way"
• access based on user

so as brutal as it is, "xhost +" should work as a crude and straightforward solution.
But it doesn't.
And what I really don't understand is why if I launch xclock on the remote machine connected via ssh, it doesn't end with an error message, but stays there without showing anything

[DiTBho]

Code: [Select]


OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.81 [192.168.1.81] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/olimex/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/olimex/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/olimex/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/olimex/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/olimex/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/olimex/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/olimex/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/olimex/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.6
debug1: match: OpenSSH_5.6 pat OpenSSH_5* compat 0x0c000000
debug1: Authenticating to 192.168.1.81:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: umac-64@openssh.com compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: umac-64@openssh.com compression: none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<3072<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa SHA256:NiBZpE+69Fpsb+lndLeIuYS+eEVQ+JUapMTHLS8BICI
debug1: Host '192.168.1.81' is known and matches the RSA host key.
debug1: Found key in /home/olimex/.ssh/known_hosts:3
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/olimex/.ssh/id_rsa
debug1: Trying private key: /home/olimex/.ssh/id_dsa
debug1: Trying private key: /home/olimex/.ssh/id_ecdsa
debug1: Trying private key: /home/olimex/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to 192.168.1.81 ([192.168.1.81]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: exec
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 2 clearing O_NONBLOCK
Connection to 192.168.1.81 closed.
Transferred: sent 3264, received 4104 bytes, in 28.2 seconds
Bytes per second: sent 115.7, received 145.5
debug1: Exit status 0
(ssh -v -X 192.168.1.81)

When invoked with option -X or option ForwardX11, the SSH utility tunnels X11 traffic from remotely invoked clients to the local server. It does so by setting at the remote site the DISPLAY environment variable to point to a local TCP socket opened there by sshd, which then tunnels the X11 communication back to ssh. Sshd then also calls xauth to add at the remote site an MIT-MAGIC-COOKIE-1 string into .Xauthority there, which then authorizes X11 clients there to access the ssh user's local X server.

X11 connections between client and server over a network can also be protected using other secure-channel protocols, such as Kerberos/GSSAPI or TLS, although such options are now far more rarely used than SSH.

[DiTBho]

Try describing accurately

same as described in your link, plus:

Code: [Select]

basedir=/usr/lib/xorg
if [ -x "$basedir"/Xorg.wrap ]
   then
        exec "$basedir"/Xorg.wrap "$@" -ac -listen tcp
   else
        exec "$basedir"/Xorg "$@" -ac -listen tcp
   fi
(/usr/bin/Xorg)

Code: [Select]

exec /usr/bin/X -listen tcp "$@"
(etc/X11/xinit/xserverrc)

reload, and verified

Code: [Select]

pgrep X | xargs ps -lfwwwp
that there is "no-listen" argument passed to the running xorg

Code: [Select]

F S UID        PID  PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY        TIME CMD
4 S root       794   741  4  80   0 - 58454 poll_s 09:15 tty7       8:05 /usr/lib/xorg/Xorg -ac -listen tcp :0 -seat seat0 -auth /var/run/lightdm/root/:0 -listen tcp vt7 -novtswitch -ac -listen tcp

so, as you can see /usr/lib/xorg/Xorg has not been passed with "no-listen tcp"
and, in fact, it's now listening on tcp port

Code: [Select]

netstat -a | grep x11
tcp        0      0 *:x11                   *:*                     LISTEN
tcp6       0      0 [::]:x11                [::]:*                  LISTEN
however, I was expecting something listening on port 6000

[alm]

I need X11 on port 6000.

SSH port forwarding creates its own proxy that does not rely on the X server having an open TCP socket. You might be able to convince SSH to listen on port 6000 by setting X11DisplayOffset to 0.

and, in fact, it's now listening on tcp port

Code: [Select]

netstat -a | grep x11
tcp        0      0 *:x11                   *:*                     LISTEN
tcp6       0      0 [::]:x11                [::]:*                  LISTEN
however, I was expecting something listening on port 6000

Isn't the x11 service mapped to port 6000 according to /etc/services?

According to this page, there several access control mechanisms that control whether a client application can connect to an X display server

• access based on host <----- old way to do it
• access based on cookie <----- "modern way"
• access based on user

so as brutal as it is, "xhost +" should work as a crude and straightforward solution.
But it doesn't.

Assuming the client uses TCP sockets. I believe ssh will use Unix domain sockets by default.  But the more important point is that SSH expects to use xauth for authorization, so other access control mechanisms are irrelevant for SSH X11 forwarding.

Code: [Select]

debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
(ssh -v -X 192.168.1.81)

Looks like the X11 forwarding channel is successfully created. What is the value of $DISPLAY when logged in this way?

[DiTBho]

Strange, but the problem was /bin/hostname, which didn't work properly and prevented /usr/bin/xauth from adding the correct "display name", since it uses /etc/hosts to get the IP

What the fsck! Seriously!

/bin/hostname recompiled from a more recent source (Gentoo repo) -> problem solved!

So, it wasn't an Ubunto side problem (laptop with x11), but a Gentoo side problem (remote server).
Strange because it happened on both remote machines { x86/32, ppc32/be } I am using.

Anyway, fixed 

Going to re-build for all the other stages4-2024-02 { mips32r2/be, mips32r2/le, hppa2, ... }  the most recent sys-apps/net-tools(<<hostname) source!

[DiTBho]

Isn't the x11 service mapped to port 6000 according to /etc/services?

yup, from the outside, my port tcp/ip scanner (executed on the lab router) doesn't list the 6000 port as open, but only the ssh port, and a custom upper port, above 6000, that I use for telemetry.

I don't need to investigate why the 6000 "appears" closed from the outside. I just need it to be able to run Geany and an xterm launched from the remote servers to finish a couple of projects.

As soon as done, I will plan (likely next weekend?) to wipe out the entire eMMC where ubuntu is currently installed, and cook a stage4 arm64/le, with nothing but xorg, xterm, and a few other things I need to make the laptop a vt220-text-console + x11 terminal.

[mag_therm]

Well, you fixed it.

I am on Fedora, I prefer sshvnc. It is OK for sharing  on a remote server IF the remote user also uses vnc via localhost.

To remotely log into a running remote X11 via vnc client, (for ham radio remote access), I recently found this, which works well:

Installation and setup on the server:
https://tecadmin.net/how-to-install-x11vnc-server-on-fedora/
login: by a standard vncviewer client, per demo at the bottom of that link

[DiTBho]

yup, from the outside, my port tcp/ip scanner (executed on the lab router) doesn't list the 6000 port as open, but only the ssh port, and a custom upper port, above 6000, that I use for telemetry.

don't ask me why port 22 (ssh) and port 6022 (my telemetry) weren't included in the firewall rules, but port 6000 was 

Ubuntu is franly a mess of files upon files to configure, and for sure - out of the box - something went wrong.

I cleaned everything, and with greater emphasis, the following forces of the rules to leave traffic on those damn bloody ports!

Code: [Select]

ufw allow 22/tcp   # sshd
ufw allow 6000/tcp # x11
ufw allow 6022/tcp # telemetry

now, Fixed! 

[alm]

don't ask me why port 22 (ssh) and port 6022 (my telemetry) weren't included in the firewall rules, but port 6000 was 

Probably because having X unintentionally open to the internet is considered a security risk, due to the protocol (e.g. the IP-based authentication) and implementation being much less secure than say SSH. And if it's intentionally open, then the user can indicate it in the ufw config.

Ubuntu is franly a mess of files upon files to configure, and for sure - out of the box - something went wrong.

What went wrong, other than the xauth/xhost problem? The X server listening via TCP/IP is not a default configuration, so you can't really complain about that not working. I guess these days most people will tunnel it over SSH since that solves the authentication problem using common solutions like public keys.

[DiTBho]

Well, there are too many default settings levels with Ubuntu and it took me too much time to figure out what to fix/change/etc.

With Gentoo it's the opposite: you start with no-default-layers,  and add your own as you want and need.

Lightdm didn't even have settings. Just empty garbage in /etc/, and surely I would have added a "firewall"!
Let the user choose if he/she wants (apt-get install...), why do you want to pre-install it? And without a line of doc?
Worse, I see the other Ubuntu versions even have the port 22 blocked, so ... "no ssh from the outside as default set"

[DiTBho]

you shutdown the display manager

Code: [Select]

systemctl stop lightdm
and ... even the wifi turns off, and you have no-network

How idiotic is this???