I'm working from the URL I found here:


My ssh client is Ubuntu 64 bit 11.10 desktop and my server is Centos 6.2 64 bit. I have followed the directions. I still get a password prompt on ssh.

I'm not sure what to do next.

  • 7
    output from the command you're giving to ssh with the -v flag? should be similar to this pastebin.com/xxe57kxg
    – Rob
    Commented Apr 16, 2012 at 14:48
  • 28
    also make sure your .ssh folder is chmod 700
    – Rob
    Commented Apr 16, 2012 at 14:55
  • 17
    assuming you've got root access to the server, /var/log/auth.log will tell you why the login is failing. Commented Apr 17, 2012 at 4:05
  • 9
    @UtahJarhead: On the CentOS server, it's likely to be in /var/log/secure. Commented Oct 2, 2013 at 20:36
  • 10
    Interesting, the chmod 0700 was the answer, but when I did ssh -v on the client side it didn't indicate an error related to why the key wasn't accepted, it just said it was trying password next even though my client sent a public key. How do they expect us to diagnose issues with no error information from the server? Commented Sep 19, 2018 at 18:39

30 Answers 30


Make sure the permissions on the ~/.ssh directory and its contents are proper. When I first set up my ssh key auth, I didn't have the ~/.ssh folder properly set up, and it yelled at me.

  • Your home directory ~, your ~/.ssh directory and the ~/.ssh/authorized_keys file on the remote machine must be writable only by you: rwx------ and rwxr-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.
  • Also, if SELinux is set to enforcing, you may need to run restorecon -R -v ~/.ssh (see e.g. Ubuntu bug 965663 and Debian bug report #658675; this is patched in CentOS 6).

¹ Except on some distributions (Debian and derivatives) which have patched the code to allow group writability if you are the only user in your group.

  • 55
    Thank you very much for pointing out restorecon. I've been scratching my head at precisely this issue for a while now. Commented Dec 3, 2012 at 14:56
  • 42
    Oddly enough, I was having problems with an account a friend set up on his VPS getting pubkey auth working. I thought all the permissions were correct, but it's important to remember that /home/USER must be 700 or 755
    – Rob
    Commented Jan 25, 2013 at 19:22
  • 18
    also, add -v to your ssh command to see what happens with that key. ssh -v user@host. Commented Feb 17, 2014 at 19:38
  • 6
    I also had to make sure my ~ itself, $HOME, was appropriately secure. It was originally 775 for some reason. chmod 700 $HOME did the trick. Commented Oct 3, 2015 at 13:39
  • 28
    chmod -R 700 ~/.ssh worked for me to meet the constraints of this answer (RHEL 7) Commented Nov 16, 2015 at 20:33

If you have root access to the server, the easy way to solve such problems is to run sshd in debug mode, by issuing something like /usr/sbin/sshd -d -p 2222 on the server (full path to sshd executable required, which sshd can help) and then connecting from the client with ssh -p 2222 user@host. This will force the SSH daemon to stay in the foreground and display debug information about every connection. Look for something like

debug1: trying public key file /path/to/home/.ssh/authorized_keys
Authentication refused: bad ownership or modes for directory /path/to/home/

If it isn't possible to use an alternative port, you can temporarily stop the SSH daemon and replace it with one in debug mode. Stopping the SSH daemon does not kill existing connections so it is possible to do this through a remote terminal, but somewhat risky - if the connection does get broken somehow at a time when the debug replacement is not running, you are locked out of the machine until you can restart it. The commands required:

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

(Depending on your Linux distribution, first / last line might be systemctl stop sshd.service / systemctl start sshd.service instead.)

  • 5
    I just tried this... and it works fine when I'm running sshd -d, but fails once I actually run service sshd start. I'm sure it's simple, but I'm not a Linux guru. Any thoughts?
    – N Rohler
    Commented Nov 30, 2012 at 5:18
  • 3
    For reference, this post explains the SELinux solution that addressed my problem.
    – N Rohler
    Commented Nov 30, 2012 at 5:36
  • 3
    I was also having trouble with getting public key authentication to work and I was pretty sure that directory permissions wasn't the problem. After running SSH in debug mode, I quickly found out that I was wrong and permissions were the problems. Commented May 14, 2014 at 5:36
  • 4
    Great advice, my user folder was with the wrong permissions.
    – gdfbarbosa
    Commented Dec 18, 2014 at 10:23
  • 2
    Thank you. Of all reasons, my user wasn't allowed to log in because the shell specified by ansible (/bin/zsh) on user creation didn't exist. I never would have guessed that.
    – chishaku
    Commented Oct 27, 2015 at 0:56

Is your home dir encrypted? If so, for your first ssh session you will have to provide a password. The second ssh session to the same server is working with auth key. If this is the case, you could move your authorized_keys to an unencrypted dir and change the path in ~/.ssh/config.

What I ended up doing was create a /etc/ssh/username folder, owned by username, with the correct permissions, and placed the authorized_keys file in there. Then changed the AuthorizedKeysFile directive in /etc/ssh/config to :

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

This allows multiple users to have this ssh access without compromising permissions.

  • 4
    ubuntu doc in it: help.ubuntu.com/community/SSH/OpenSSH/Keys#Troubleshooting
    – Fab V.
    Commented Mar 12, 2014 at 7:32
  • 4
    This answer is a salient one & helped me - for anyone wondering if this is the issue - you may see "pam_ecryptfs: Passphrase file wrapped" in your auth.log; somehow that wasn't enough to prompt me to remember the homedir was encrypted. Also you may find first logon asks for a passwords, subsequent sessions don't (since it's decrypted whilst the other sessions open).
    – pacifist
    Commented Jun 20, 2014 at 8:21
  • 1
    Holy crap I've searched wayyyy to long to resolve that issue, tank you so much !
    – h3.
    Commented Feb 13, 2015 at 17:33
  • WRONG... Don't give inaccurate or bad advice. It's not nice. Why do you hate people looking for help? kali@kali2:~/.ssh$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 [email protected] /home/kali/.ssh/config: line 4: Bad configuration option: authorizedkeysfile /home/kali/.ssh/config: terminating, 1 bad configuration options
    – Zack A
    Commented Jul 11, 2020 at 16:23
  • @ZackA don't be so angry, mate, you put that config in the wrong file. The AuthorizedKeysFile has to go in the file in your ssh server side config. In an Ubuntu server, I have in a pickyourownname.conf file inside the /etc/ssh/ssh_config.d/ directory. Commented Jun 23, 2021 at 19:57

Just try these following commands

  1. ssh-keygen

    Press Enter key till you get the prompt

  2. ssh-copy-id -i root@ip_address

    (It will once ask for the password of the host system)

  3. ssh root@ip_address

    Now you should be able to login without any password

  • 3
    On which server?
    – Alkanshel
    Commented Jun 17, 2014 at 19:47
  • 3
    @Amalgovinus Obviously you run this on the client, not the machine you're connecting to - you don't want a copy of your private key on the server! :)
    – nevelis
    Commented Sep 24, 2014 at 16:09
  • 14
    Please note that generally, allowing remote root logins is not a recommended security practice.
    – arielf
    Commented Jun 22, 2015 at 18:21
  • 4
    @nevelis: If it was obvious to them, they wouldn't have asked. Some people are new to ssh-keygen and they might not understand where the public and private keys are. That's why they're here. Commented Oct 19, 2021 at 1:47
  • 2
    Just elaborating on this answer: I was reluctant to use ssh-copy-id because I wasn't familiar with it; I've always just copied the .pub file, and when it didn't work, tried debugging it with ssh -v. But today, after half an hour of frustration, I thought what the hell, try using this utility instead. And then it just started working. I had to clear some unwanted keys from authorized_keys on my remote machine, but in the end it saved a lot of hassle. Sometimes the easy way really is better. 😏 Commented Oct 19, 2021 at 1:48

After copying keys to the remote machine and putting them inside the authorized_keys you've got to do something like this:

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa
  • 1
    Actually no you don't. ssh automatically uses ~/.ssh/id_rsa (or id_dsa) without having to use a key agent.
    – phemmer
    Commented Nov 7, 2013 at 1:29
  • 13
    This can still be helpful advice if one was to specify a differently named key in ~/.ssh/config (e.g. on host *.mydomain.org...IdentityFile ~/.ssh/some_limited_use.pub -- ssh-add ~/.ssh/some_limited_use.pub). Commented Feb 3, 2014 at 12:11
  • 1
    This has solved my problem with getting password prompt after adding a key. As 89c3b1b8-b1ae-11e6-b842-48d705 pointed out, the reason to run these commands manually was a non-standard name of a key file. Commented Sep 18, 2018 at 11:40
  • 2
    As pointed out by above in the comments, if you are using any key besides the default key, it is not added by default to the ssh agent. So be sure to check the key you want to use is in the agent's keychain: ssh-add -L
    – James
    Commented Mar 11, 2019 at 17:58
  • 1
    I had to do ssh-add ~/.ssh/id_rsa Thanks a ton! Commented Apr 13, 2020 at 11:59

I faced challenges when the home directory on the remote does not have correct privileges. In my case the user changed the home dir to 777 for some local access with in the team. The machine could not connect with ssh keys any longer. I changed the permission to 744 and it started to work again.

  • 11
    We had this problem too - 755 on the home dirs fixed it Commented Jul 18, 2012 at 14:52
  • I had permissions set to 777 and it was ignored, thanks!!!
    – ka_lin
    Commented Jul 4, 2016 at 13:56
  • Same here. Thanks. Was scratching my head for a while, wtf was happening.
    – Marcin
    Commented Oct 27, 2018 at 6:40
  • Yes see the answer here for further detail unix.stackexchange.com/questions/205842/…
    – Tim
    Commented Feb 19, 2019 at 3:53
  • 2
    This may well be the answer for people who have done the key generation correctly yet are still getting prompted for a password.
    – Fergie
    Commented Feb 21, 2019 at 12:37

We ran into the same problem and we followed the steps in the answer. But it still did not work for us. Our problem was that login worked from one client but not from another (the .ssh directory was NFS mounted and both clients were using the same keys).

So we had to go one step further. By running the ssh command in verbose mode you get a lot of information.

ssh -vv user@host

What we discovered was that the default key (id_rsa) was not accepted and instead the ssh client offered a key matching the client hostname:

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277                  

Obviously this will not work from any other client.

So the solution in our case was to switch the default rsa key to the one that contained user@myclient. When a key is default, there is no checking for client name.

Then we ran into another problem, after the switch. Apparently the keys are cached in the local ssh agent and we got the following error on the debug log:

'Agent admitted failure to sign using the key'

This was solved by reloading the keys to the ssh agent:


SELinux on RedHat/CentOS 6 has an issue with pubkey authentication, probably when some of the files are created selinux is not setting its ACLs correctly.

To manually fix the SElinux ACLs for the root user:

restorecon -R -v /root/.ssh
  • using openssh client on windows I was able to ssh root@mymachine into a CentOS6 mymachine without issue, but I have a lower-privilage user that I'd prefer to use, but ssh regularUser@mymachine still prompts me for a password. thoughts?
    – Groostav
    Commented Nov 11, 2018 at 10:06

It would be SSH misconfiguration at server end. Server side sshd_config file has to be edited, it is located in /etc/ssh/sshd_config.

In that file, change variables

  • yes to no for ChallengeResponseAuthentication, PasswordAuthentication, UsePAM

  • no to yes for PubkeyAuthentication

(Link to original source is now pointing to spam and was removed).

  • 1
    As in comments to question check the /var/log/secure or /var/log/auth.log. In my case I see "User xxx from xxx not allowed because not listed in AllowUsers" "input_userauth_request: invalid user xxx [preauth]" ( and "rexec line 35: Deprecated option ServerKeyBits" in /var/log/messages although I dunno what that is). To resolve vi /etc/ssh/sshd_config, add user xxx to AllowUsers list, service sshd restart *** BEWARE restarting sshd service with bad sshd_config might lock you out of a box!? ***. That worked.
    – gaoithe
    Commented Jan 3, 2019 at 12:30

I ran into a similar problem and followed the steps using the debug mode.

/usr/sbin/sshd -d

This showed the following result

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic

It was really confusing

[root@sys-135 ~]# ls -l /
drwxrwxrwx.   2 root root     4096 Dec 14 20:05 bin
drwxrwxrwx.   5 root root     1024 May  6  2014 boot
drwxrwxrwx.   2 root root     4096 Dec  2  2013 cgroup
drwxrwxrwx.  10 root root     1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root    12288 Dec 16 10:26 etc
drwxrwxrwx.  11 root root     4096 Jan 14  2014 lib
drwxrwxrwx.   9 root root    12288 Dec 14 20:05 lib64
drwxrwxrwx.   2 root root    16384 Jan 10  2014 lost+found
drwxrwxrwx.   2 root root     4096 Jun 28  2011 media
drwxr-xr-x.   2 root root        0 Dec 10 14:35 misc
drwxrwxrwx.   2 root root     4096 Jun 28  2011 mnt
drwxrwxrwx.   4 root root     4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root        0 Dec 10 14:35 proc
drwxrwxrwx.  45 root root     4096 Dec 16 10:26 root

It showed the root directory had permissions for every one. We changed it so that others would not have permissions.

[root@sys-135 ~]# chmod 750 /root

The key authentication started working.

  • I have same issue. Yesterday, I issued rsync -av ./root/ root@THE_HOST:/root to upload some files from my local working directory, then, this issue occurs (in fact, at first I didn't notice it. After cron jobs in other hosts fails in the next morning, I started digging the reason). The rsync -av ./root/ root@THE_HOST:/root command changed the owner and permission of the /root directory of the remote host. Fixed the permission, problem solved. Commented Jun 13, 2015 at 3:41
  • Failed publickey for root from port 54553 ssh2 I get same message and issue when I forgot to add the pubkey to a host authorized_keys. Adding this comment as in my case, I usually realize my mistake after I checked the debug and all the permissions plus config files #:o<
    – tuk0z
    Commented Sep 17, 2016 at 21:48

Ensure that AuthorizedKeysFile points to the right location, use %u as a placeholder for username:

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

It may be that you just need to uncomment the line:

AuthorizedKeysFile .ssh/authorized_keys

Mind that you must reload ssh service for the changes to take place:

service sshd reload

If both the private key and the username/password authentication methods are accepted by the server, and then if the private key fails, it will simply fall back to prompting for a username/password without displaying any error.

You can use the -vvv flag to determine if a private key was even attempted, (and which keys specifically), and why the key(s) are failing. Example: ssh -T -vvv myHost.com. Alternatively, you can use LogLevel DEBUG3 in ~/.ssh/config.

A common failure is that the server rejects the key. In that case, you will see something like this:

debug1: Next authentication method: publickey
debug1: Trying private key: /c/Users/myUsername/.ssh/id_rsa
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
[email protected]'s password:

According to the official spec for the SSH protocol (RFC 4252), the authentication packets have the following values:


This means that debug3: receive packet: type 51 indicates that the server rejected the key.


In the past I came across some tutorials that describe how to achieve a ssh password-less setup, but some are sadly wrong.
Let's start over again, and check every step:

  1. FROM CLIENT - Generate key: ssh-keygen -t rsa
    Public and private key (id_rsa.pub and id_rsa) will be automatically stored in the ~/.ssh/ directory.
    Setup will be easier if you use an empty passphrase. If you are not willing to do that, then still follow this guide, but also check the bullet point below.

  2. FROM CLIENT - Copy public key to server : ssh-copy-id user@server
    Client public key will be copied to server's location ~/.ssh/authorized_keys.

  3. FROM CLIENT - Connect to server: ssh user@server

Now, if it's still not working after the described 3 steps, lets try the following:

  • Check ~/.ssh folder permissions in client and server machine.
  • Check /etc/ssh/sshd_config in the server to ensure that RSAAuthentication, PubkeyAuthentication and UsePAM options aren't disabled, they can be enabled by default with yes.
  • If you entered a passphrase while generating your client key, then you may try ssh-agent & ssh-add to achieve password-less connections in your session.
  • Check the contents of /var/log/auth.log on the server to find the issue why key authentication is skipped at all.
  • 1
    Thanks for listing out the steps! I got to "ssh-copy-id user@server" and realized that I had originally copied over the wrong public key. Commented Apr 15, 2019 at 18:42
  • 1
    In your first bullet, it should read "check ~/.ssh folder permissions on client and server for the client and server users"
    – RichVel
    Commented Oct 24, 2019 at 5:20

In /etc/selinux/config file changing SELINUX to disabled from enforcing made passwordless ssh work successfully.

Earlier I am able to do it on one way. Now from bothways I am able to do passwordless ssh.


One thing that I had wrong was the ownership on my home directory on the server system. The server system was set to default:default so I:

chown -R root:root /root

And it worked. Another Cheap workaround is to Disable StrictModes: StirctModes no. in sshd_config. This will at least tell you if the key exchange and connection protocols are good. Then you can go hunt the bad permissions.

  • Me too. Look at the messages in /var/log/secure. I saw a message: "Authentication refused: bad ownership or modes for directory" ($HOME). Make sure there isn't write access to $HOME to Group or Other. I'd never have found this if I didn't have unauthorized root access to the server....
    – SoloPilot
    Commented May 6, 2018 at 15:43

At server:

$ ls -lh /home
$ sudo chmod 700 /home/$USER

It was directory permission issue. It was 777 at server, so I changed it back to 700. This fixed my issue with ssh password less login failure even after copying $USER/.ssh/id_rsa.pub to server $USER/.ssh/authorized_keys.


After checking the permissions, and trying several other solutions listed here, I finally just removed the ssh directory on the server, then setup my public key again.

Server commands:

rm -rf ~/.ssh

Local commands:

ssh-copy-id [email protected]        # where <user> is your username and <> is the server IP
  • Exactly what I finished by doing (after checking everything above!) but localy on the host and then It started working. I unfortunetly will never know why it didn't. Thanks. Commented Jan 9, 2020 at 22:25
  • 1
    debuging and understanding is always good, but when you need the things working NOW - this is it.
    – faceless
    Commented Aug 9, 2020 at 18:47

My solution was that the account was locked. Message found in /var/log/secure: User not allowed because account is locked Solution: give the user a new password.

  • I fixed it by changing password field in /etc/shadow for this user from ! to *. After that password authentication is still impossible, but user is not locked anymore. Commented Apr 7, 2016 at 11:53

I was having the exact same problem with PuTTY connecting to an Ubuntu 16.04 machine. It was puzzling because PuTTY's pscp program was working fine with the same key (and the same key worked in PuTTY to connect to another host).

Thanks to the valuable comment from @UtahJarhead, I checked my /var/log/auth.log file and found the following:

sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

It turns out that newer versions of OpenSSH don't accept DSA keys by default. Once I switched from a DSA to an RSA key, it worked fine.

Another approach: this question discusses how to configure the SSH server to accept DSA keys: https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication?lq=1


Two comments: this will overwrite the original file. I'd just copy the public key generated and do something like:

cat your_public_key.pub >> .ssh/authorized_keys

This will append the key you want to use to the pre-existing list of keys. Also, some systems use the file authorized_keys2, so it's a good idea to make a hard link pointing between authorized_keys and authorized_keys2, just in case.

  • Yeah, I noticed that too about the overwrite, but I didn't have any, so it didn't matter. I created a symlink to the authorized_keys2 but that didn't help.
    – Thom
    Commented Apr 16, 2012 at 14:46
  • Also, check the file/directory permissions. They are described on the website you provided.
    – Wojtek
    Commented Apr 16, 2012 at 15:00
  • 3
    your ~/.ssh dir must be 700 your private key file must be 600 your public key file must be 644 your auth file (on the remote) must be 644
    – Rob
    Commented Apr 16, 2012 at 15:03
  • @Rob that was the problem. If you'd post that as an answer, I'd accept it.
    – Thom
    Commented Apr 17, 2012 at 9:08

For me, the solution was opposite Wojtek Rzepala's: I didn't notice I was still using authorized_keys2, which has been deprecated. My ssh setup stopped working at some point, presumably when the server was updated. Renaming .ssh/authorized_keys2 as .ssh/authorized_keys fixed the problem.


  • This is also a configuration option in /etc/ssh/sshd_config, although I think I'd rename it like you did.
    – Rick Smith
    Commented Oct 14, 2015 at 21:17

These steps should help you out. I use this regularly among many 64bit Ubuntu 10.04 machines.

[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'

you could put this in a script with some prompts and invoke it as

script_name username remote_machine
  • There exists already ssh-copy-id which does the last two steps automatically.
    – jofel
    Commented Apr 17, 2012 at 13:05
  • 2
    @jofel keep in mind that in many systems ssh-copy-id does not exist. @Sriharsha after the mkdir you should add there chmod 700 .ssh too and btw you don't need be so verbose with ~/.ssh, just .ssh is enough since the commands are executed in the home directory anyway
    – janos
    Commented Apr 17, 2012 at 18:09

I had similar problem with ssh. In my case the problem was that I installed hadoop cloudera (from rpm on centos 6) and it created user hdfs with home directory

/var/lib/hadoop-hdfs (not standard /home/hdfs).

I changed in /etc/passwd /var/lib/hadoop-hdfs to /home/hdfs, moved home directory to new location and now I can connect with public key authentication.


I just had this same problem, and for me the solution was to set UsePAM to no. See, even with PasswordAuthentication set to no, you'll still get keyboard-interactive, and in my case my local ssh program kept defaulting to that, for some reason.

Extra background to help anyone with the same situation: I'm connecting from a host running Dropbear to one running OpenSSH. With PasswordAuthentication and UsePAM both set no on the remote machine, I'll get the following message if I enter ssh user@server:

ssh: Connection to user@server:22 exited: Disconnect received

Providing the identity file with -i, everything works as expected.

There may be a little more information here.


Yet another option is a variant of @Jagadish 's answer: to strace the ssh daemon.

It has the significant advantage, that we don't need to stop the sshd, what can result a complete lockout if something goes badly.

First, we find the pid of the main sshd process. Here we can see it by executing a pstree -pa|less.

  |-sshd,633 -D  <-- THIS IS WHAT WE WANT!
  |   `-sshd,21973   
  |       `-sshd,21996    
  |           `-bash,22000
  |               `-screen,638 -r

After knowing, that the pid is 633, we can strace it, following its children:

strace -p 633 -s 4096 -f -o sux

The result will be that everything what this sshd, and its child processes have done, will be strace-ed into the file named sux in the local directory.

Then reproduce the problem.

It will have a massive list of kernel call log, which is mostly incomprehensible/irrelevant for us, but not everywhere. In my case, the important thing was this:

6834  sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84

It was meants, that the sshd tried to log the message User cica not allowed because account is locked - it only couldn't, because logging is not enough verbose for that. But we already know, the pubkey was rejected because the account was locked.

It is not yet a solution - now we need to google, what means a "locked account" in the case of the sshd. It will be most likely some trivial /etc/passwd, /etc/shadow wizardry, but the important thing is done - the problem isn't a mysterious, but an easily debuggable/googlable one.

  • I tried that method. In my case, it was because the ownership of the .ssh folder was wrong. Using sshd -d showed the error, but unfortunately strace didn't catch it. Glad I learned about pstree in your response.
    – Wadih M.
    Commented Aug 16, 2021 at 16:01
  • @WadihM You are right - in this case, strace will only contain that sshd checked the ~/.ssh metadata with an fstat-related syscall. Possibly you would catch also the logging try, possibly not (it depends on, how verbose is sshd without the -d flag). Thanks the feedback!
    – peterh
    Commented Aug 16, 2021 at 18:41

My scenario was that I have a NAS server on which I created a backupbot user, after the creation of my primary account, which was able to log in to initially create the backupbot user. After fiddling with sudo vim /etc/ssh/sshd_config, and creating the backupbot user, vim can create, at least on Ubuntu 16.04, and based on your ~/.vimrc config, a swap file left from your vim session's editing of /etc/ssh/sshd_config.

Check to see if: /etc/ssh/.sshd_config.swp exists, and if it does remove it and restart the sshd daemon:

$ sudo rm /etc/ssh/.sshd_config.swp
$ sudo service sshd restart

This magically resolved my issue. I had previously checked all my permissions and even the RSA fingerprints of the public and private keys. This is strange and probably a bug with sshd, specifically this version:

OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 Mar 2016


In my case I had all permissions right and even when running ssh with -vvv flag I couldn't figure out what was the problem.

So I generated new certificate on remote host

ssh-keygen -t rsa -C "[email protected]"

and copied generated keys to local machine and added new public key to ~/.ssh/authorized_keys on remote host

cat id_rsa.pub >> authorized_keys

Using generated keys from remote host machine connection now works. So if other solutions fail this is another thing to try.


I had the same problem when connecting from Raspbian8 to Fedora34.

The debug error I received was:

userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

The solution was to append ssh-rsa to the value of PubkeyAcceptedAlgorithms in


and restart the service

thanks to Dave @ https://wiki.xdroop.com/space/Fedora/34/SSH+Pubkey+doesn%27t+work for this solution


I tried to log into a colleague's account without password, by pasting id_rsa.pub into her authorized_keys file. I got the permissions of all relevant files right, but still couldn't succeed with password-less login.

It turns out since I created the authorized_keys file with root permission, I had to chown and chgrp to the ones that match her profile.

sudo chown ${username} -R /home/${username}/.ssh
sudo chgrp ${groupname} -R /home/${groupname}/.ssh

It was easy to spot this mistake when you use the triple verbose mode ssh -vvv.


In my case, id_rsa authentication appears to be deprecated and is not utilized by default in SSH. Switching to ed25519 resolved my problem.

ssh-keygen -t ed25519
ssh-copy-id -i ~/.ssh/id_ed25519 username@remote

You must log in to answer this question.

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