Permission denied (publickey) after rebuilding to Debian 10

Posted February 15, 2020 3.1k views
Debian 10


I just rebuilded a droplet to Debian 10 and i’m getting Permission denied (publickey) error on ssh access, i followed the guide of DO documentation but i’m still getting the same error. I’ve already try deleting the old known_hosts, removing entries of the old server, but nothing seems to work.


These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
1 answer

Hi @afboteros,

Let’s first being with the usual stuff, I know you mentioned you’ve actually checked the permissions and other stuff like that but let me post how they should be just in case:

  • Your home directory ~, your ~/.ssh directory and the ~/.ssh/authorized_keys file on the remote machine must be writable only by you: rwx------ andrwxr-xr-x are fine, but rwxrwx---is no good, even if you are the only user in your group (if you prefer numeric modes: 700 or 755, not 775).
  • If~/.ssh or authorized_keys is a symbolic link, the canonical path (with symbolic links expanded) is checked.
  • Your ~/.ssh/authorized_keys file (on the remote machine) must be readable (at least 400), but you’ll need it to be also writable (600) if you will add any more keys to it.
  • Your private key file (on the local machine) must be readable and writable only by you: rw——-, i.e. 600.

Now that we’ve passed the standard stuff, let’s get going on the more interesting stuff.

If you try and run thus on your droplet

/usr/sbin/sshd -d -p 2222

Can you connect then without a password, using the SSH key? What does the debug information says on your droplet? It should state something like

Authentication allowed

In this case, what you can do is temporarily stop the SSH daemon and replace it with one in debug mode. Don’t worry, stopping the SSH daemon won’t kill any existing connections. This means it’s possible to run this without being connected to the droplet’s Console but it’s somewhat risky. If the connection does get broken for any kind of reason, you’ll need to connect using your droplet’s console. Anyway, you can run the following

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

If it again runs with the debug mode being on, then for sure it’s the SELinux causing the issues, it’s most probably set to Enforcing. The .ssh dir will probably be mislabeled. Look at /var/log/audit/audit.log. Check with ls -laZ and then Run restorecon -r -v /path/to/users/.ssh.


  • Hi, first of all, the .ssh directory in my droplet does not exits on user folder ~/.ssh, only /root/.ssh is present, but i’m trying to log in with an user different than root.

    When running the command:

    /usr/sbin/sshd -d -p 2222

    The output says:

    Could not load host key: /etc/ssh/ssh_host_rsa_key
    Could not load host key: /etc/ssh/ssh_host_ecdsa_key
    Could not load host key: /etc/ssh/ssh_host_ed25519_key
    debug1: setgroups() failed: Operation not permitted
    debug1: rexec_argv[0]='/usr/sbin/sshd'
    debug1: rexec_argv[1]='-d'
    debug1: rexec_argv[2]='-p'
    debug1: rexec_argv[3]='2222'
    debug1: Set /proc/self/oom_score_adj from 0 to -1000
    debug1: Bind to port 2222 on
    Server listening on port 2222
    debug1: Bind to port 2222 on ::.
    Server listening on :: port 2222.