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
(
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
)
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
-nolisten tcp
and added
-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...
# 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
um, sshd has the following opts set
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost no
I edited all the files related to both Xorg and lightdm, the default display manager used by Ubuntu-mate,
removed
-nolisten tcp
and added
-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?
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.
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.
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
Try describing accurately
same as described in your link, plus:
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)
exec /usr/bin/X -listen tcp "$@"
(etc/X11/xinit/xserverrc)
reload, and verified
pgrep X | xargs ps -lfwwwp
that there is "no-listen" argument passed to the running xorg
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
netstat -a | grep x11
tcp 0 0 *:x11 *:* LISTEN
tcp6 0 0 [::]:x11 [::]:* LISTEN
however, I was expecting something listening on port 6000
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
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.
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?
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!
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.
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
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!
ufw allow 22/tcp # sshd
ufw allow 6000/tcp # x11
ufw allow 6022/tcp # telemetry
now, Fixed!
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.
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"
you shutdown the display manager
systemctl stop lightdm
and ... even the wifi turns off, and you have no-network
How idiotic is this???