Bdtyktl

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

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

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.

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.