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

wkdmarty
  • 975

7 Answers7

14

My solution step by step:

1) login with option -X remote host login root

$ ssh -X root@192.168.1.39

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

Community
  • 1
Walter Caraza
  • 249
7

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

grawity
  • 501,077
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.

Ken Jackson
  • 311
  • 1
  • 3
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.

wkdmarty
  • 975
1

rm ~/.Xauth* and then reconnect.

This works for me. For more details

zzz92
  • 11
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.

carlb
  • 1
  • 1
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

Jon Rifkin
  • 1