Magic cookie ssh issue

With the new Linux distros and with the fact that we are more an more groomed by developers with a more windi$sh mindset not to use Linux in a distributed fashion, It is getting worse and worse getting remote X-applications to work. Where it worked out of the box for a decade or so, now the packagers seemingly drop ssh remote X application server configs. I was convinced we evolved past that, but it seems we are devolving Linux again.

The problem:

The old display issue and auth problem so familiar with in the early 2000’s
"
X11 connection rejected because of wrong authentication.
Display localhost:10.0 unavailable, simulating -nw
"
Well, we’re back at that again with the new distros.

The web is full of the usual xhost+ and whatnot solutions and configuration of files to get this working we all know about.

Unfortunately the situation with recent distros became much much worse and troublesome with little regard for remote x-sessions but I found a solution.

Solution:

The client cookie is not the same as it’s root cookie when you do
ssh -l username -X serverip , and therefore fails.

To solve this situation you need to first do:
ONTHECLIENT$ xauth list | grep unixecho $DISPLAY | cut -c10-12 > /tmp/xauth
THEN
ONTHECLIENT$ sudo su
root@USER~$ xauth add cat /tmp/xauth

After this you can
ssh -l user -X serverip
and X-applications from the remote server will render on the client

This way the magic cookie is passed on.

QUESTION:

Since this has to be done before EVERY ssh command for a specific terminal, Is there any way to configure the client with above commands as soon as a terminal is opened ?
.bashrc might work for the first command but the “su” I dont know how to do that automatically for every terminal bash session.
It seems to me that the root system needs to detect a terminal opened in a user’s account, and then read the cookie and save a copy in the root xauth (I guess), should a user decide to use ssh .

Hopefully I dont have to use “expect” (which will work) but it will unfortunately openly disclose sudo password.
Is there a more elegant way to solve this cookie nonsense that distros seem to come with these days.

Passing the -v typically answers what is wrong. Another option is to look into the SSHD servers’ log files. Try it out. Last time I had an issue, and it turns out xhost wasn’t installed on the remote Linux server.

ssh -v yourname@server

Add more -vv to get more debug data:

ssh -vv yourname@server

x11-xserver-utils is already installed and that is what supplied xhost, so the problem is not there.

I did look at debug data, but I will do it again as the system changed a lot trying to fix this mess.

Thanks for the help so far, but the problem seems top be with the why-me-worry approach Debian is taking in general.
I came to the conclusion that my problems dealing with the latest Debian/MX distros on my servers are untenable.
Never had these issues.

To list a few…

  1. The issue listed in this thread…
  2. Even if I am working on the server with direct keyboard and monitor, I get display errors and apt upgrade e.g. cannot display any configuration dialogs, leading to unconfigured packages. No way out.
  3. Since the latest version, Now suddenly when I boot up and select to boot partion /sda2, once it booted up df shows it mounted to partition /sdb !!
    This happens randomly 3/10 times. 7/10 df will show /sda2
  4. Grub boots /sda2, but when I check with df it actually booted /sda8 !
  5. and way more.
    This all happens on the same rackserver with nothing changed.

I have a grave suspicion that it is the result of even more systemD lock-in encroachment and more bugs.

So I will put this thread on hold, too many problems with Debian/MX and rather install Devuan which is systemD-Free. If the problems disappear with Devuan or Slack, then I will know it is most likely systemD causing all this. So I will first have to check that.

I will return here if I need to continue the Debian installation and report on the Devuan install.

During 25 years of managing these servers, never seen such an abomination coming from a distro.

Installed Devuan which boots with sysV and not systemD.

Absolutely NO problems with Devuan and none of the partition disco that I found systemD does on the exact same server.
Something on this rackserver is confusing systemD.

So systemD is clearly the culprit here.

I cant use Devuan as the support is really lacky and obtuse, so I will probably move to another systemD-free such as slack or try to get MX sorted out with developers. Mx has great support.

i will see if I can make a video so you can see that I am not making this up. Hope I still have that partition on disk.