Rocky 9.5 x11 forwarding not working

I have upgraded my main server from Cent OS 8 Stream to Rocky 9.5 and most stuff is working but not x11 forwarding so I can’t open GUI tools like gedit and meld etc.

I haven’t changed anything on my Mint client which was working before the server upgrade. On the server the non comment lines of /etc/ssh/sshd.config are:

AuthorizedKeysFile	.ssh/authorized_keys
AllowTcpForwarding yes
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
Subsystem	sftp	/usr/libexec/openssh/sftp-server

When connecting and trying to start gedit there are no error messages and ps suggests it is running but nothing appears on my client screen. Here is the terminal output with the verbose option:

david@shigoto:~$ ssh -v -Y root@ichi
OpenSSH_8.9p1 Ubuntu-3ubuntu0.10, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /home/david/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to ichi [10.20.1.1] port 22.
debug1: Connection established.
...
debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.10
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.7
debug1: compat_banner: match: OpenSSH_8.7 pat OpenSSH* compat 0x04000000
debug1: Authenticating to ichi:22 as 'root'
...
Authenticated to ichi ([10.20.1.1]:22) using "publickey".
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: exec
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: client_input_hostkeys: searching /home/david/.ssh/known_hosts for ichi / (none)
debug1: client_input_hostkeys: searching /home/david/.ssh/known_hosts2 for ichi / (none)
debug1: client_input_hostkeys: hostkeys file /home/david/.ssh/known_hosts2 does not exist
debug1: client_input_hostkeys: host key found matching a different name/address, skipping UserKnownHostsFile update
debug1: Remote: /root/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /root/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: channel 0: setting env LANG = "en_NZ.UTF-8"
debug1: channel 0: setting env LC_MESSAGES = "en_NZ.UTF-8"
debug1: channel 0: setting env LC_CTYPE = "en_NZ.UTF-8"
debug1: channel 0: setting env LC_COLLATE = "en_NZ.UTF-8"
Web console: https://ichi:9090/

Last login: Fri Feb 14 10:44:08 2025 from 10.20.2.1
[root@ichi ~]# gedit
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from ::1 36336
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: channel 1: FORCE input drain
debug1: channel 1: free: x11, nchannels 2

Any suggestions welcomed.

Do you have xorg-x11-xauth installed? Yes, for without one gets:

debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Remote: No xauth program; cannot forward X11.
X11 forwarding request failed on channel 0

What do you get with echo $DISPLAY ?

I get: localhost:15.0.

In other words, SSH does not say that X11 forwarding is not possible and it also tells (via DISPLAY) to X11 clients which X11 server to talk to.

Now the question is, what do the X11 clients say when they try to start (and fail)?
Is it possible on the Mint’s X11 server to log what happens when client tries to start?

The last 6 lines of may capture in my initial post shows what -v logging gives when I start gedit. If I increase the verbosity using -vvv I get this:

[root@ichi ~]# gedit
debug3: receive packet: type 90
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from ::1 33402
debug2: fd 7 setting O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
debug3: send packet: type 91
debug3: receive packet: type 96
debug2: channel 1: rcvd eof
debug2: channel 1: output open -> drain
debug2: channel 1: obuf empty
debug2: chan_shutdown_write: channel 1: (i0 o1 sock 7 wfd 7 efd -1 [closed])
debug2: channel 1: output drain -> closed
debug1: channel 1: FORCE input drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug3: send packet: type 96
debug2: channel 1: input drain -> closed
debug2: channel 1: send close
debug3: send packet: type 97
debug3: channel 1: will not send data after close
debug3: receive packet: type 97
debug2: channel 1: rcvd close
debug3: channel 1: will not send data after close
debug2: channel 1: is dead
debug2: channel 1: garbage collecting
debug1: channel 1: free: x11, nchannels 2
debug3: channel 1: status: The following connections are open:
  #0 client-session (t4 r0 i0/0 o0/0 e[write]/0 fd 4/5/6 sock -1 cc -1 io 0x01/0x00)
  #1 x11 (t4 r3 i3/0 o3/0 e[closed]/0 fd 7/7/-1 sock 7 cc -1 io 0x00/0x00)

debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
debug3: send packet: type 98

Other than there is no window and no error message. I can use ctrl-c to end gedit and get back to the command prompt.

Some progress.

The extra debug info in my last post was from the Mint ssh client. I thought I would try and get extra info from gedit itself. Checking it’s command line options there is no verbose option but I did notice the option --display=DISPLAY X display to use so I tried gedit --display=localhost:15.0 and that worked!

Trying meld didn’t wok and if does not have a display option. On the other hand gitk worked straight away.

I guess this means with Cent OS 8 programs didn’t need to know much about X11 sessions or the defaults worked ok where as with Rocky 9 the defaults don’t suit all programs.

More progress. It look like the problem is Wayland and the gui programs are probably opening on the server’s local screen. I can get meld to work using GDK_BACKEND=x11 meld.

So I can seem to run all the main GUI programs I use, even if the solution is a bit clumsily. There is probably a better way to deal with this. It sounds like if I can stop Wayland running that may solve the problem.

Yeah you could change from Wayland to Xorg instead.

I found a fix that works for me at ssh - X11 forwarding works for some progs, other progs ignore $DISPLAY? - Unix & Linux Stack Exchange. I added to ~/.bash_profile this section:

if [ "$SSH_CONNECTION" != "" ] && [ "$DISPLAY" != "" ]; then
    export GDK_BACKEND=x11
fi

Thanks to @jlehtone for their suggestions. Hopefully this will save others time in future.

1 Like