3

I'm logging into a remote server using ssh -x and then running xterm. Whenever the keyboard bell is trying to be run, I get the following messages and xterm exits:

xterm: warning, error event received:
X Error of failed request:  BadAccess (attempt to access private resource denied)
  Major opcode of failed request:  104 (X_Bell)
  Serial number of failed request:  468
  Current serial number in output stream:  469

This was all working perfectly fine when I went home last night and was failing when I came back in this morning. As far as I can tell, nothing has changed.

I've tried turning off the bell (xset b off) locally and remotely. Remotely, I get a similar error, but for X_ChangeKeyboardControl. Locally, the xterm still exits with the same error.

I looked on my system and do not have a xconf.d directory.

uname -a returns the following:

Linux <node-name> 4.18.0-16-generic #17~18.04.1-Ubuntu SMP Tue Feb 12 13:35:51 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Sinkem
  • 31

2 Answers2

1

(Bradford's answer is correct, but to expand on what he wrote)

That's the result of the limitations placed on X11 Forwarding by the default ssh client config. If you have access, add both ForwardX11 yes and ForwardX11Trusted yes to the system /etc/ssh/ssh_config which will enable the desired behavior by default for all users on the system.

Otherwise, invoke ssh -Y when connecting to relevant hosts.

Here is how the ssh_config(5) man page describes the ForwardX11 setting:

ForwardX11 Specifies whether X11 connections will be automatically redirected over the secure channel and DISPLAY set. The argument must be ''yes'' or ''no''. The default is ''no''.

X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the user's X11 authorization database) can access the local X11 display through the forwarded connection. An attacker may then be able to perform activities such as keystroke monitoring if the ForwardX11Trusted option is also enabled.

Here is how the ssh_config(5) man page describes the ForwardX11Trusted setting:

ForwardX11Trusted If this option is set to ''yes'', remote X11 clients will have full access to the original X11 display.

If this option is set to ''no'', remote X11 clients will be considered untrusted and prevented from stealing or tampering with data belonging to trusted X11 clients. Furthermore, the xauth(1) token used for the session will be set to expire after 20 minutes. Remote clients will be refused access after this time.

The default is ''no''.

See the X11 SECURITY extension specification for full details on the restrictions imposed on untrusted clients.

I verified the issue and fix on my FreeBSD 13.1 system (client) connecting to a Redhat Linux server (server).

Note sshd_config enables X11Forwarding by default.

omar.s
  • 11
0

I had this problem.

I believe the fix is that you need to also enable "trusted" X11 forwarding by either using the -Y option instead of -X or by using ForwardX11Trusted yes in your .ssh/config file.

Bradford C. Smith
  • 1