I used puttygen to generate both my public and private key files (ssh2, 2048 bit). I have set up the settings in putty correctly and it is using the correct private key file. As for the public key, (I am using these keys for root) it is in /root/.ssh/authorized_keys

I have tried using chmod on .ssh to 700 and on authorized_keys to 400. That did not do anything.

Does anyone have any recommendations?

edit: here's an ls -ldZ of my .ssh folder and authorized_keys file

drwx------ root root ?                                /root/.ssh
-rw------- root root ?                                /root/.ssh/authorized_keys
  • give more information. what is remote server distro, version. is there any security layer between your client and server? (SELinux, iptables,...). Capture the audit log on your remote server when trying to connect to see any hint. Enable putty debug would be helpful.
    – cuongnv23
    Commented May 13, 2016 at 3:42
  • It's running CentOS 6.7, and as far as I'm aware there is no security layer blocking anything. Where would I look for the audit log? I tried checking the auth log but it seems to not exist. As far as putty debugging goes, do you want the event log? I checked it and it contained quite a bit of information, but leading up to checking the key not much was helpful.
    – Joel
    Commented May 13, 2016 at 4:11
  • Trying to ssh from Linux box with ssh -vvv could be helpful, although it can contain some private information to be filtered.
    – user140866
    Commented May 13, 2016 at 7:22
  • ls -ldZ ~ ~/.ssh ~/.ssh/authorized_keys on server.
    – Jakuje
    Commented May 13, 2016 at 8:29
  • @Joel you should take a look at file /var/log/audit/audit.log. Also, update your answer with output of command from @Jakuje
    – cuongnv23
    Commented May 13, 2016 at 9:49

7 Answers 7


I also had this problem seemingly out of nowhere, but only with FileZilla and not Putty. (key based auth)

For me the solution was simple (when I read the tip here) to just update Putty including Pageant.

  • I'm using putty clone kitty (9bis.net/kitty) update to newer version also fixed this issue Commented Jun 2 at 6:40
  • Thanks man, indeed I had 0.78 putty and 0.62 (2011) pageant from an old location. Upgrading pageant to 0.78 (2022) worked for me. Commented Jul 4 at 22:27

Set LogLevel to DEBUG in sshd_config, and I think you'll find (in auth.log of course) a reason why you publick key is refused.

  • You don't even need to change the log level. A denied login is always logged with a reason, and usually that reason is enough to figure it out. Commented May 13, 2016 at 21:38
  • 1
    not always, in my case it was sshd[xxxx]: Connection closed by authenticating user xxxx 10.x.x.x port xxxxx [preauth] so something more verbose than default was needed Commented Nov 3, 2022 at 13:02

Looking at the log /var/log/secure showed that it was just downright refused. I'm somewhat new to centos since I'm mainly a debian kind of guy, so I was unaware of /var/log/secure

After checking this and doing a bit of searching, it turns out PermitRootLogin no needs to be PermitRootLogin without-password if you want to specifically use just keys for root login. That did the trick. Thanks everyone for contributing.


We had the same error ("Server refused public-key signature despite accepting key") while trying to connect to ssh to a server using a key as root. It turned out that the problem was caused by the fact that the server's SSH configuration wasn't allowing the user root to use SSH keys.


Some protocol deprecation in progress..

  1. Upgrade putty to version 0.77 (that includes puttygen)
  2. Run puttygen, load id_rsa file, generate new PPK (overwrite old one)
  • 1
    I'm trying to figure out if this is my issue since my key is from like 2012. Can you link to more information?
    – claytond
    Commented Sep 8, 2022 at 14:26

I had this problem seemingly out of nowhere. Previously I'd added ssh keys and connected without issue. Even the SSH button to connect to the VM available through the Google Cloud Console website would fail to register keys.

The problem was that Google's Linux Guest Environment wasn't running. I resolved my issue by following the directions for In-Place Install: Linux Guest Environment.


We upgraded Ubuntu from 18 to 20 and experienced that error message. For hours I tried to get RSA up and running again, but with no success.

In the end, the solution was to create an ECDSA key in putty and no changes to any ssh configs were necessary.

You must log in to answer this question.

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