I'm using ssh -X user@ip to connect to an SSH server (on the LAN, 100mbit/s connection).

It works well, but there's three issues:

  1. After some time (can't tell when exactly, a felt hour or so) when I would close a window and try to open another I get the error: Error: Can't open display: localhost:10.0 and I have to logout and back in to fix this.

  2. I can not type @. I first thought it's a locale issue, but locales are generated properly. The keyboard layout is proper aswell and other things like !")$(_? work.

  3. I can copy something on my PC and then paste it into the X11 forwarded window, but the other way around not so much. Something is copied (clipboard is overwritten) but it's not pastable (attempting to paste in some apps causes the app to be unresponsive for ~a minute).

I have xauth installed (both machines), I use default settings for X11 forwarding, server is OpenSSH_7.9p1 Raspbian-10+deb10u2, OpenSSL 1.1.1d 10 Sep 2019 debian XFCE4, client is OpenSSH_8.2p1, OpenSSL 1.1.1f 31 Mar 2020 on arch GNOME3.

I tried xclip -o and xsel -o -b but both don't print anything and run until I CTRL+C them.

Copying an @ on the PC and then pasting it into the server app works.


(DE keyboard layout): xev on client and server show the same keycode, client's XLookupString gives @ (40), on server q (71). The events/codes for the Alt Gr key I need to keep pressed for the @ and everything else is identical on both. xmodmap gives the exact same result on both.

Checking sshd log indeed gave me something: channel 3: open failed: administratively prohibited: open failed, which apparently is rather vague.

Server: X.Org X Server 1.20.4
Client: X.Org X Server 1.20.8

Verbosity gave me: Rejected X11 connection after ForwardX11Timeout expired

And searching that on the net gave me the fix. Setting ForwardX11Timeout to a high value fixed it. Setting it to unlimited is apparently not possible yet. Using -Y instead of -X would apparently fix this aswell but seems less secure than the config option.

1 Answer 1


1) So something network related stopped working. Look at the sshd logs on the remote computer for suspicious error messages. If you don't find anything, increase verbosity both for the ssh client and the sshd server (see man-pages on how to do that).

2) The remote X program connects to your local X server, but it will still use some remote settings. So it's not really about "locale", it's about keyboard X settings. Start xev via forwarding to see what happens when you type @ locally (whatever key combinations you need to use in your locale for this, you didn't tell us). xmodmap via forwarding may also be helpful.

3) I have no idea what happens here, this needs debugging on the X protocol level.

Also check if the X server and libraries on both the local and the remote computer have reasonably close versions. If they don't, try to make them closer. The X wire protocol is pretty stable, but if you two hosts disagree on something in there, that could explain your problems.

The ssh versions shouldn't matter much, ssh is just forwarding the X protocol transparently.

  • Please see my edit. 1) has been fixed.
    – confetti
    May 10, 2020 at 9:22
  • I am confused now on (2). So xev shows you get the keysym for @, but you still can't "type it"? Where exactly you cannot type it? Is it possible that this program (or these programs) use Alt Gr for something else?
    – dirkt
    May 10, 2020 at 14:23
  • No it shows the @ only on the client, on the server (X11 forwarded window) it shows up as q. The keycode and everything else (including the modifier key parts) is identical.
    – confetti
    May 10, 2020 at 14:24
  • What does setxkbmap -query show on the local host, and on the remote host? If you need to debug more details, use setxkbmap -print | xkbcomp - - > xxx.xkm on both, and compare the results wrt. to @ via xkbcomp xxx.xkm.
    – dirkt
    May 10, 2020 at 14:37
  • If I run this on the ssh server I get XKB extension not present on localhost:11.0 for both comands. Might that be causing the issues? Just in case, I've tried to not only run it within the ssh session but also within a terminal started on the remote host using X11 forwarding, but same message.
    – confetti
    May 10, 2020 at 16:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .