16

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 ?

  • The good news is: I am now able to open the file: sshd_config using sudo nano command and add the line: ForwardX11Trusted yes.. the bad news is: after the "adding step" the problem still exists !!! – McLan Jun 20 '13 at 16:07
  • What is the full command when you use xauth add? – Nate from Kalamazoo Jun 20 '13 at 22:35
  • ForwardX11Trusted is an option for the OpenSSH client,, not for the server. Adding it might prevent sshd from starting, depending on the version. – Gert van den Berg Feb 12 '19 at 16:00
10

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!

| improve this answer | |
  • This looks like answer to a different problem (although with the same symptoms). – DavidPostill Dec 13 '15 at 20:30
  • This worked for Raspbian Jessie on RaspberryPi – Dexter Jul 8 '16 at 7:00
  • This also worked for me on RPI. From PuTTy on Win10 simple leafpad worked fine, but sudo leafpad has thrown error in description above. Copying .Xauthority worked flawlessly. Thanks a lot! – Petr Újezdský Jun 2 '17 at 8:38
  • ok for the authorization problem... but still gives me "Cannot open display:"... ?any ideas – ZEE Oct 12 '17 at 3:04
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.

| improve this 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

| improve this answer | |
  • 3
    ForwardX11Trusted is not a valid option for sshd_config. It is a client parameter, not a server daemon parameter – HeatfanJohn Jan 21 '16 at 16:17
  • I'd done this quite some time ago. Don't know now. – Dheeraj Bhaskar Jan 26 '16 at 10:40
1

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

| improve this answer | |
0

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.

| improve this answer | |
0

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

| improve this answer | |
  • Did you notice that the user is working on a remote host (via PuTTY)? – G-Man Says 'Reinstate Monica' Apr 23 at 20:46
  • May be I didn't understood your question clearly, Yes, I do connect to the remote hosts by using the above. Where your seeing challenges here. – Naresh A Apr 24 at 1:04
  • export DISPLAY=:0.0 is used when the X server and the X client are on the same host.  Generally, if you login directly to computer A (possibly a laptop or a small desktop workstation) and then login remotely (PuTTY / ssh) to computer B (possibly a high-end machine with many CPUs and tons of RAM (and secondary storage; i.e., disk / SSD), but possibly headless), you want to run an X client on computer B but use the X server on computer A — so your answer would be inappropriate.  If you can touch the keyboard / mouse of computer B and see its screen, why not just login to it directly? – G-Man Says 'Reinstate Monica' Apr 24 at 1:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.