How do I debug "X11 connection rejected because of wrong authentication"

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


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


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.