I have a problem with X forwarding through SSH. I've battled for ages, but no-one can seem to help.

I'm now taking a different tact. I would like to know how I would debug the errors?

What logs should I look in, what extra flags should I set (-v etc) and what should I look for?

Further Edit:

If I log into Putty into the server and try to xeyes, I get:

PuTTY X11 proxy: wrong authorisation protocol attemptedError: Can't open display: localhost:10.0

If I xauth generate $DISPLAY I get:

PuTTY X11 proxy: wrong authorisation protocol attemptedxauth: (argv):1: unable to open display "localhost:10.0".

  • In your question from the other day you describe different symptoms. Are you still suffering from "Can't open display", or did you solve that? If you solved that, and one of the answers to that question was helpful, you should select it as an answer to reward the person who helped you. – Kenster Sep 1 '14 at 13:25
  • Agreed, it's a different error now, I've closed that question. – wkdmarty Sep 1 '14 at 14:00
  • See if this answer applies to your server. – Kenster Sep 1 '14 at 14:04
  • Kenster, I didn't have either rc file on the server, so I created one and pasted the code. No difference. – wkdmarty Sep 1 '14 at 14:12
  • In the PuTTY logs, this comes up after I try to run an x program (after SSH login). 2014-09-01 15:16:38 Received X11 connect request from 2014-09-01 15:16:38 Opening X11 forward connection succeeded 2014-09-01 15:16:38 Nothing left to send, closing channel 2014-09-01 15:16:38 Forwarded X11 connection terminated – wkdmarty Sep 1 '14 at 14:18

My solution step by step:

1) login with option -X remote host login root

$ ssh -X root@

2) check if existing .Xauthority file

[root@localhost ~]# ls -al
[root@localhost ~]# vim .Xauthority

3) copy .Xauthority file to directory the other user

[root@localhost ~]# cp .Xauthority /home/oracle/
cp: overwrite `/home/oracle/.Xauthority'? y

4) set permissions for this file

[root@localhost ~]# chown oracle:oinstall .Xauthority
[root@localhost ~]# chmod 0600 .Xauthority

5) login oracle user

[root@localhost ~]# su - oracle

6) display setting in localhost:10.0

[oracle@localhost ~]$ echo $DISPLAY
[oracle@localhost ~]$ ls -al

7) lists xauth cookies existing

[oracle@localhost ~]$ xauth list
localhost.localdomain/unix:11  MIT-MAGIC-COOKIE-1  310f1b02c1080e73059391c193a1881b
localhost.localdomain/unix:10  MIT-MAGIC-COOKIE-1  41843db100830a2aa352641ac47bb759

8) adding

[oracle@localhost ~]$ xauth add localhost.localdomain/unix:10  MIT-MAGIC-COOKIE-1  41843db100830a2aa352641ac47bb75

9) test

[oracle@localhost ~]$ xclock

Hope they serve! @wcaraza

  • 2
    The part xauth add .... is the trick – Wei Dec 29 '14 at 0:15
  • steps 3. and 4. did the trick for me – kiltek Mar 3 '17 at 12:53

Make sure the SSH server has the xauth tool installed, and that your ~/.Xauthority file is writable. (Non-existent is also okay, as long as xauth can create it.)

Check if xauth data is being updated:

server$ xauth list

Try manually adding dummy xauth data (again, on the SSH server), and see if xauth has any problems (e.g. being unable to create the lockfile or to modify the Xauthority file itself):

server$ xauth add localhost:123 MIT-MAGIC-COOKIE-1 d7e2e4a8c5aa4430bfcc2abb436940d2

If necessary, re-run under strace.

Run the SSH service in debug mode, by setting LogLevel DEBUG2 in the server configuration (/etc/ssh/sshd_config), or by starting sshd in debug mode directly:

server$ sshd -rddp 12234

(In this example, 12234 is the temporary SSH port that you need to connect to. Any free port will do.)

  • Thank you. Xauth on the server can write to the .Xauthority file. But what should it be setting? server = N40L, client = Lin001. Should the xauth list on N40L show an entry for localhost:10 MIT-MAGIC-COOKIE-1 {Lin001'sHexKey}? – wkdmarty Sep 1 '14 at 11:15
  • @wkdmarty: Yes, your sshd will listen on a TCP port corresponding to display :10 (or :11, :12...), and this will show up as "localhost:10". As for the hex key, however, I don't really know if it's meant to use the same key – I think ssh actually generates a new one, and acts as a proxy... – grawity Sep 1 '14 at 11:53
  • ok perfect, I can see that is listening. My DISPLAY variable states N40L:11.0, which I'm thinking is wrong, so I'll change that to DISPLAY=localhost:10.0. Nope, still erroring. I did notice on the SSH connection this line: debug2: x11_get_proto /usr/bin/xauth list :0.0 2>/dev/null wherever I've seen SSH connection logging, this line is different...showing a key generation, never :0.0.? – wkdmarty Sep 1 '14 at 12:10
  • @wkdmarty: Normally sshd should set $DISPLAY to the correct value... and port 6011 does correspond to display 11, not 10, anyway. – grawity Sep 1 '14 at 13:10
  • 1
    "My DISPLAY variable states N40L:11.0...so I'll change that". To be blunt, leave DISPLAY alone. If ssh sets up X11 forwarding, it will set DISPLAY to a value that will work. Overriding the value that ssh sets will just make the troubleshooting process more difficult. – Kenster Sep 1 '14 at 13:50

It's working, it's working. haha.


After finding out that it wasn't the system, by adding a test user (which x forwarding worked "out the box"), I thought I'd start copying the .bash* startup files across to virginise the "broken" user.

None of the files were different, so next I deleted the users .ssh directory. When I ssh'd in, it moaned about "Server refused our key", but I could log in using password. Once logged in, I could x forward perfectly.

I'll now try to setup the key again and see if I can get that working too. Then it'll be back to normal.

  • This worked for me too. I tried all other methods, but yeah apparently the problem lied in the keys. – Auxiliary Jan 7 '16 at 19:34

One more thing that can cause this problem is the existence of a ~/.ssh/rc file on the server--the machine you're connecting to. Delete it (or rename it) to solve the problem.

  • 1
    Per man sshd, sshd runs ~/.ssh/rc instead of xauth, @PimpJuiceIT. – Ken Jackson Feb 10 at 4:58
  • Thank you! For more details, see: docstore.mik.ua/orelly/networking_2ndEd/ssh/…. It should be possible to add the appropriate commands to start up xauth within the rc file, but I've not found it. – Matt B. May 30 at 21:44

rm ~/.Xauth* and then reconnect.

This works for me. For more details

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.