PuTTY X11 proxy: wrong authorisation protocol attempted

Question

I am trying to connect to an Ubuntu server to work on Qt-creator. Before everything goes wrong, I followed this tutorial. I downloaded putty and Xming and everything was working just fine.

then, suddenly, while working on Qt-creator I couldn't save any changes. So, I closed Qt-creator and restart the putty session. it asked me about username and password (as usual) then after log-in into the server and when I tried to run Qt-creator (as usual) the following message appears:

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

so, I tried to resolve the problem using two approaches found in the internet:

the first one is by getting the dpyname protoname hexkey using:

xauth list 

which should return the key which is then could be added using:

xauth add

However, it didn't work as the xauth list command returned nothing.

the second solution was to go to:

./etc/ssh/sshd_config

open the file: sshd_config and edit the ForwardX11Trusted line to read yes, and If no such line exists, add it in.

ForwardX11Trusted yes

then restart the ssh server and it should work.

However, it didn't work either. I could not open the file sshd_config using xdg-open or gedit and the same message appears again.

so why is this happening and what is the solution for it ?

Answer 1

While logged in as su, after a few "PuTTY X11 proxy: wrong authorisation protocol attempted" -type errors, I realized it was an authentication problem. Then I remembered to copy the .Xauthority file from my own profile /home directory to /root. Problem solved!

Answer 2

Solved.

I got it solved using a mixture of the two mentioned above.

1. I added the following line to '/etc/ssh/sshd_config'

ForwardX11Trusted yes

2. I installed xauth using

sudo apt-get install xauth

xauth list was empty for me before restart. It was, however, populated after the restart. I did xauth list after I tested it with putty.

Then I restarted ssh and it worked. Yay!

Note: What I actually did was restart my Raspberry Pi

Answer 3

I had a similar problem on a server at work because the home folder was out of disk space. After login, it couldn't write the Xauthority file and... couldn't forward.

Freeing up space resolved the issue.

I would imagine you would have a similar problem if home folder or .Xauthority permissions were set improperly so you did not have write access.

Answer 4

In my case, I noticed I could open the Display with root, but I was doing a su - grid, and this user grid was the one with the problem,

the solution was to close this session, and open a new session directly with grid, and it worked, something about doing the su - grid was failing...

Answer 5

The insight regarding the .Xauthority file is correct, but the approach of overwriting another user's file should give one pause. Consider the conflict created if two hypothetical users Alice and Bob both attempted to overwrite ~root/.Xauthority while logged in simultaneously. The user also needs to remember to do the rude copy whenever their personal copy is updated and would be blocked if ~root/.Xauthority could not be created or updated due to unrelated issues such as a read-only filesystem mount or complete lack of disk space.

The intent of the proposed solution can be honored by exploiting the XAUTHORITY environment variable, which could be conveniently set during login by the user's appropriate login-only script. This is illustrated by the .bash_profile fragment below:

if test -n "${DISPLAY}"
then
    XAUTHORITY=`LANG=C xauth info | awk '{ print $NF; exit; }'`
    export XAUTHORITY
fi

Note that the LANG=C prefix to the xauth invocation protects against unexpected results in locales with right-to-left reading order.

This approach has the benefits of being automatic, does not require write permission to files under ~root and prevents multiple simultaneous users from interfering with each other.

Note that there can be a difference in behavior between obtaining privileges via sudo and becoming root (or a different user) via su. On some systems, the pam_xauth module is enabled in /etc/pam.d/su, which performs automatic import of the session key and creation of a temporary authority file that will be pointed to by the XAUTHORITY environment variable. On such systems, by default su yields a shell that can communicate with the X11 display (thanks to the magic of the pam_xauth module) while a command invoked using sudo would not. The approach above does not interfere with the behavior of su on systems that have enabled the pam_xauth module and also, when the pam_xauth module is not enabled, allows su to work if the appropriate preserve environment argument is passed (e.g., su -p). If you are unsure of your system's configuration, compare and contrast the output of:

sudo xauth info

vs.

su -c 'xauth info'

when XAUTHORITY is not set and then set appropriately.

Answer 6

I had a similar problem on a server. The reason was that user got the wrong number of display (DISPLAY=localhost:10.0). When user connects to the server via SSH (as user called test1) he gets DISPLAY=localhost:11.0. When he connects as another user, and then becomes user (test1), he gets wrong number of display (DISPLAY=localhost:10.0). When I set the rifght number of DISPLAY (DISPLAY=localhost:11.0) it works.

Answer 7

check whether $DISPLAY variable is set, command: echo $DISPLAY if the display variable is not set, run this command: export DISPLAY=:0.0