ssh: only some X programs are working

English Network/Internet
1

Since I switched from Tumbleweed to Leap 42.3 as my workstation system, some X11 applications on a CentOS server are not working on my workstation when using ssh with X11 forwarding to the server. For example, Emacs (GTK) , Evince and ncview work. Firefox, Matlab, RStudio do not work, there are no error messages, just nothing happens. Other users can use the programs just fine. Also from other Leap 42.3 machines, all applications work for me. Logging in with -X or -Y produce the same error.

When I log in with -v, I get the follow messages:

OpenSSH_7.2p2, OpenSSL 1.0.2j-fips  26 Sep 2016
debug1: Reading configuration data /home/sebschub/.ssh/config
debug1: /home/sebschub/.ssh/config line 1: Applying options for XXXX
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 25: Applying options for *
debug1: Connecting to XXXX port 22.
debug1: Connection established.
debug1: identity file /home/sebschub/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sebschub/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sebschub/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sebschub/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sebschub/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sebschub/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sebschub/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sebschub/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to XXXXXXXX:22 as 'XXXX'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:RNaUfY8c0gP144g3GKwe2kYPxN3USaKWLKKQjmADgBA
debug1: Host 'XXX' is known and matches the ECDSA host key.
debug1: Found key in /home/sebschub/.ssh/known_hosts:6
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/sebschub/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: Authentication succeeded (publickey).
Authenticated to XXX ([XXX]: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 LC_MONETARY = de_DE.UTF-8
debug1: Sending env LANG = en_GB.UTF-8
debug1: Sending env LC_TIME = de_DE.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
Transferred: sent 4020, received 6248 bytes, in 39.8 seconds
Bytes per second: sent 101.1, received 157.2
debug1: Exit status 0
OpenSSH_7.2p2, OpenSSL 1.0.2j-fips  26 Sep 2016
debug1: Reading configuration data /home/sebschub/.ssh/config
debug1: /home/sebschub/.ssh/config line 1: Applying options for XXX
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 25: Applying options for *
debug1: Connecting to XXX [XXX] port 22.
debug1: Connection established.
debug1: identity file /home/sebschub/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sebschub/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sebschub/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sebschub/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sebschub/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sebschub/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sebschub/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sebschub/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to XXX:22 as 'XXX'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:RNaUfY8c0gP144g3GKwe2kYPxN3USaKWLKKQjmADgBA
debug1: Host 'XXX' is known and matches the ECDSA host key.
debug1: Found key in /home/sebschub/.ssh/known_hosts:6
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/sebschub/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: Authentication succeeded (publickey).
Authenticated to XXX ([XXX]: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 LC_MONETARY = de_DE.UTF-8
debug1: Sending env LANG = en_GB.UTF-8
debug1: Sending env LC_TIME = de_DE.UTF-8

Now I start and close a working program, emacs in this case:

debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from ::1 60608
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: channel 1: FORCE input drain
debug1: channel 1: free: x11, nchannels 2
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from ::1 60610
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: channel 1: FORCE input drain
debug1: channel 1: free: x11, nchannels 2
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from ::1 60612
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: channel 1: FORCE input drain
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from ::1 60614
debug1: channel 2: new [x11]
debug1: confirm x11
debug1: channel 1: free: x11, nchannels 3
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from ::1 60616
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 5 win 65536 max 16384
debug1: client_request_x11: request from ::1 60618
debug1: channel 3: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 6 win 65536 max 16384
debug1: client_request_x11: request from ::1 60620
debug1: channel 4: new [x11]
debug1: confirm x11
debug1: channel 4: FORCE input drain
debug1: channel 4: free: x11, nchannels 5
debug1: channel 2: FORCE input drain
debug1: channel 2: free: x11, nchannels 4

Starting firefox produces the following output. I do not receive any windows, nothing happens, though:

debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from ::1 60672
debug1: channel 2: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 6 win 65536 max 16384
debug1: client_request_x11: request from ::1 60674
debug1: channel 4: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from ::1 60676
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from ::1 60678
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from ::1 60680
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: channel 2: FORCE input drain
debug1: channel 2: free: x11, nchannels 5
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from ::1 60682
debug1: channel 2: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from ::1 60684
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 8 win 65536 max 16384
debug1: client_request_x11: request from ::1 60686
debug1: channel 6: new [x11]
debug1: confirm x11
debug1: channel 6: FORCE input drain
debug1: channel 6: free: x11, nchannels 7
debug1: client_input_channel_open: ctype x11 rchan 8 win 65536 max 16384
debug1: client_request_x11: request from ::1 60688
debug1: channel 6: new [x11]
debug1: confirm x11
debug1: channel 6: FORCE input drain
debug1: channel 6: free: x11, nchannels 7
debug1: client_input_channel_open: ctype x11 rchan 8 win 65536 max 16384
debug1: client_request_x11: request from ::1 60690
debug1: channel 6: new [x11]
debug1: confirm x11
debug1: channel 6: FORCE input drain
debug1: channel 6: free: x11, nchannels 7
2

What do you mean by “other users can use the programs just fine.”

Are “other users” logged in locally or accessing the apps remotely, and if remotely are they using ssh with x11 forwarding also?

TSU

3

Other users logging in on the server (including me from another machine), using X11 forwarding, can use these particular X applications running on the server without problems. There are no other users logged in on my local machine but there are other people logged in on the server.

4

Could it be a display resolution issue, where the app might be rendered off-screen?

Maybe use top or some other app to verify that the app actually launched…

TSU

5

Interesting idea but I think this is not the case: There is no icon for the application in the KDE task bar. If I start emacs on the server, I get an icon on the workstation. Furthermore, I can see the X application I start on the server in top, but TIME is not increasing. It stays at a very low value of
0:00.09 as if it waits for something.

6

The problem seems to be dri3 forwarding over ssh. Is is already mentioned in a bug report and was/is also present in Fedora. Workaround is to use

$ LIBGL_DRI3_DISABLE=1 firefox

The Leap 42.3 machine that does not work uses Intel graphics while the one that does uses proprietary NVIDIA drivers. I guess this is the reason for the different behaviour (not that I understand what dri3 is…).