16

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".

Improve this question
7
  • 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
    Commented Sep 1, 2014 at 13:25
  • Agreed, it's a different error now, I've closed that question.
    – wkdmarty
    Commented Sep 1, 2014 at 14:00
  • See if this answer applies to your server.
    – Kenster
    Commented Sep 1, 2014 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
    Commented Sep 1, 2014 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 127.0.0.1:59566 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
    Commented Sep 1, 2014 at 14:18

7 Answers 7

Reset to default
14

My solution step by step:

1) login with option -X remote host login root

$ ssh -X [email protected]

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
localhost:10.0
[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

Improve this answer
3
  • 2
    The part xauth add .... is the trick
    – Wei
    Commented Dec 29, 2014 at 0:15
  • steps 3. and 4. did the trick for me
    – kiltek
    Commented Mar 3, 2017 at 12:53
  • followed these directions but am still getting the same error. that error. (X11 connection rejected because of wrong authentication. Error: Can't open display: localhost:10.0).
    – john-jones
    Commented May 23, 2023 at 10:49
6

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.)

Improve this answer
9
  • 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
    Commented Sep 1, 2014 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_u1686
    Commented Sep 1, 2014 at 11:53
  • ok perfect, I can see that 0.0.0.0:6011 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
    Commented Sep 1, 2014 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_u1686
    Commented Sep 1, 2014 at 13:10
  • 2
    "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
    Commented Sep 1, 2014 at 13:50
3

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

FINALLY.

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.

Improve this answer
1
  • This worked for me too. I tried all other methods, but yeah apparently the problem lied in the keys.
    – Auxiliary
    Commented Jan 7, 2016 at 19:34
3

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.

Improve this answer
3
  • 2
    Per man sshd, sshd runs ~/.ssh/rc instead of xauth, @PimpJuiceIT.
    – Ken Jackson
    Commented Feb 10, 2019 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.
    – mbauman
    Commented May 30, 2019 at 21:44
  • 1
    @KenJackson your answer pointed me to the snippet in this answer, which made X11 work for me. I added: if read proto cookie && [ -n "$DISPLAY" ]; then echo "add unix:${DISPLAY#localhost:} $proto $cookie" | xauth -q - fi to my ~/.ssh/rc.
    – Miron Veryanskiy
    Commented Oct 5, 2021 at 23:06
1

rm ~/.Xauth* and then reconnect.

This works for me. For more details

Improve this answer
0

One more wrinkle; sometimes X will run fine over SSH under your own individual user account, then throw "X11 connection rejected because of wrong authentication. Unable to init server: Could not connect: Connection refused" the moment you use "sudo" or attempt any operation as 'root'.

The solution appears to be to run "xauth list" as your individual user, then "sudo xauth add" to add all the same the individual keys for the 'root' administrator.

ie:

$ xauth list
sophia/unix:10  MIT-MAGIC-COOKIE-1  af8901b66c15a26f10d70e7e0199ea0b
sophia/unix:11  MIT-MAGIC-COOKIE-1  9f9bf2b2cacc242d20d06d9523b2d304
sophia/unix:12  MIT-MAGIC-COOKIE-1  ec167527428b7726d7f36b514a6daec3
sophia/unix:13  MIT-MAGIC-COOKIE-1  133573e87fc32af9634b04307df478fa

in a non-root user session which already has working X-over-ssh. Then "sudo xauth add" each of those keys, in this example:

$ sudo xauth add sophia/unix:13  MIT-MAGIC-COOKIE-1  133573e87fc32af9634b04307df478fa
$ sudo xauth add sophia/unix:12  MIT-MAGIC-COOKIE-1  ec167527428b7726d7f36b514a6daec3
$ sudo xauth add sophia/unix:11  MIT-MAGIC-COOKIE-1  9f9bf2b2cacc242d20d06d9523b2d304
$ sudo xauth add sophia/unix:10  MIT-MAGIC-COOKIE-1  af8901b66c15a26f10d70e7e0199ea0b

Now you should be able to use "sudo" with any command that needs X window support:

$ sudo baobab

...or whatever. There are a few useful admin-type commands (ranging from 'gparted' to xenserver administration) which can make use of the graphics support if it's available - even over an ssh connection to a distant, remote datacentre.

Improve this answer
0

Buidling on the reponse from carlb, I found that this one-line compound Bash command does the trick.

$ xauth list | while read LINE; do sudo xauth add $LINE; done

Improve this answer
1
  • 1
    Welcome to Super User! Before answering an old question having an accepted answer (look for green ✓) as well as other answers ensure your answer adds something new or is otherwise helpful in relation to them. Here is a guide on How to Answer. There is also a site tour and a help center.
    – help-info.de
    Commented Apr 12 at 9:11

You must log in to answer this question.

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