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:


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, 2013 at 16:07
  • What is the full command when you use xauth add? Jun 20, 2013 at 22:35
  • 1
    ForwardX11Trusted is an option for the OpenSSH client,, not for the server. Adding it might prevent sshd from starting, depending on the version. Feb 12, 2019 at 16:00

7 Answers 7


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!

  • 1
    This looks like answer to a different problem (although with the same symptoms).
    – DavidPostill
    Dec 13, 2015 at 20:30
  • This worked for Raspbian Jessie on RaspberryPi
    – Dexter
    Jul 8, 2016 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! Jun 2, 2017 at 8:38
  • ok for the authorization problem... but still gives me "Cannot open display:"... ?any ideas
    – ZEE
    Oct 12, 2017 at 3:04
  • Works for sudo commands too. First use xauth list and make sure your current non-root user is listed, and then copy your ~/.Xauthority to /root/.
    – Yvon
    Aug 14, 2021 at 20:25


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

  • 7
    ForwardX11Trusted is not a valid option for sshd_config. It is a client parameter, not a server daemon parameter Jan 21, 2016 at 16:17
  • I'd done this quite some time ago. Don't know now. Jan 26, 2016 at 10:40
  • 1
    Do NOT add ForwardX11Trusted yes to your sshd_config as it will probably cause your ssh server to fail after being rebooted.
    – Ruzihm
    Sep 20, 2022 at 22:20

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.


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


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}"
    XAUTHORITY=`LANG=C xauth info | awk '{ print $NF; exit; }'`
    export XAUTHORITY

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


su -c 'xauth info'

when XAUTHORITY is not set and then set appropriately.


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.


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

  • Did you notice that the user is working on a remote host (via PuTTY)? Apr 23, 2020 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, 2020 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? Apr 24, 2020 at 1:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .