[SID - Unstable] [workaround] ssh -X "cannot open display" on all four machines

[wizard10000]

** crossposted from r/debian **

Have four Sid machines here and ssh -X has worked fine on all of them for years. For the last two days I haven't been able to run graphical applications over ssh from any of these machines.

As mentioned in subject line, error says "cannot open display" and if I ssh into the machine $DISPLAY is indeed blank but from a local console $DISPLAY correctly reads :0

export DISPLAY=ip.of.ssh.guest:0 doesn't work either although it does set the variable on the host machine. xhost + also gives the cannot open display error.

Since this happened on all four machines at once I'm pretty sure it's nothing I did - but I haven't been able to resolve it yet.

Anybody else seeing this? Anybody got an idea how to resolve or which package to give a bug report?

edit: ssh -vv -Y user@ip.add.re.ss just gives "X11 forwarding request failed on channel 0"

[fabien]

Maybe it has something to do with the last update? (not from the last two days though)

openssh (1:9.7p1-4) unstable; urgency=medium

* Rework systemd readiness notification and socket activation patches to
not link against libsystemd (the former via an upstream patch).
[...]
Wed, 03 Apr 2024 12:06:08 +0100

[wizard10000]

Maybe. I'm sure they'll get it figured out and I imagine someone's already filed a bug but I don't seem to be able to figure out which application gets the bug report; I've looked for bug reports in xorg, ssh and xauth, nothing in those three packages yet.

[trinidad]

openssh (1:9.7p1-4) unstable; urgency=medium

* Rework systemd readiness notification and socket activation patches to
not link against libsystemd (the former via an upstream patch).
[...]
Wed, 03 Apr 2024 12:06:08 +0100

Sounds about right: https://sourcesmethods.com/xz-utils-bac ... iscovered/

TC

[wizard10000]

I just fixed it. In /etc/ssh/sshd_config I changed

#AddressFamily any

to

AddressFamily inet

and restarted sshd. Gonna go file a bug report now

edit: bug report submitted. https://bugs.debian.org/cgi-bin/bugrepo ... ug=1069236

[trinidad]

I don't think it's a bug. All your change is doing is avoiding using fallback from a failed ipv6 connection (default) and specifying ipv4 connection only. Not sure why it's happening but I suspect your machines were actually partially sucessful connecting via ipv6 but wouldn't pass x through the connection for some reason which is likely an x or systemd security change. Could be a lot of reasons.

TC

[wizard10000]

IPv6 is disabled on all four machines. I think "any" still should have fallen back to IPv4. I did just add that info to the bug report.

[trinidad]

Basically the x11 forwarding channel is not the same channel as the session channel. So yes, you could have been connected with ipv6 on the session channel and not known it, while the x11 forwarding channel could not connect ipv6 for some reason (either SSH client (not server) config settings or update changes to xorg or systemd) and because of the successful session channel connection the fallback default switch to ipv4 would not activate for x11 forwarding. Anyway I expect there will be ongoing quirks with SSH for unstable/testing users over the next year because DSA is due to be entirely deprecated for SSH in 2025.

TC