I'm trying to set up a passwordless SSH login on CentOS 5.4:

  1. I generated RSA public key on the client.
  2. ssh-copy-id from client to server.
  3. Verified ~/.ssh/authorized_keys contains the client key.

The client still prompted for password. What did I miss?


EDIT: checked ssh_config and permissions as advised. This is the debug info from the client:

debug2: key: /home/saguna/.ssh/identity ((nil))
debug2: key: /home/saguna/.ssh/id_rsa (0x2b31921be9a0)
debug2: key: /home/saguna/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: Trying to reverse map address
debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/saguna/.ssh/identity
debug3: no such identity: /home/saguna/.ssh/identity
debug1: Offering public key: /home/saguna/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /home/saguna/.ssh/id_dsa
debug3: no such identity: /home/saguna/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]'s password: 
  • 1
    I get this too :( Mar 18, 2011 at 9:29
  • At this point you may have to enable debug mode on the server as well and find out why it's rejecting your pubkey offer. Oct 12, 2021 at 6:06

15 Answers 15


9/10 times it's because ~/.ssh/authorized_keys isn't at the right mode.

chmod 600 ~/.ssh/authorized_keys
  • 4
    FYI, I created a small script at github.com/centic9/generate-and-send-ssh-key which runs the necessary steps in one go and additionally ensures all the file/directory permissions which always caused me headaches...
    – centic
    Oct 7, 2015 at 11:31
  • 9
    If this does not work for someone, you should also look at @Gilles's answer. In particular, the home and ~/.ssh directories can't be writeable by anyone other than the user.
    – ostrokach
    Nov 5, 2015 at 3:01
  • I know this is old, but thanks a million to @centic. I was sure my permissions were correct but never bothered to check on the $HOME and .ssh/ directories.
    – jdferreira
    Mar 11, 2019 at 10:38

Check in /etc/ssh/sshd_config to allow authentication with a key. You should have something like this in it, and make sure the lines are not commented:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

Then restart sshd after you modify the file:

/etc/init.d/sshd restart
  • In addition to to Patkos Csaba's answer, check the permissions of your local and remote ~/.ssh folder.
    – user16115
    Sep 16, 2010 at 17:35
  • In my case, AuthorizedKeysFile was commented out and I also had to use an absolute path to authorized_keys.
    – Andrew
    Nov 28, 2014 at 18:46
  • I get 'Could not open a connection to your authentication agent.' when trying ssh-add
    – Manticore
    Sep 4, 2015 at 7:14
  • this should be the selected answer Mar 11, 2017 at 0:57
  • 2
    Maybe you don't understand the comments. The commented out lines show you the default values. You don't need to uncomment them if you want the default value. You only need to uncomment the property if you want to override the default value.
    – clearlight
    Mar 6, 2018 at 6:34

I found that with my system the problem was the user directory (/home/username) was equipped with the wrong permissions set. It was drwxr-x-w- and it needed to be drwxr-xr-x (with write permission only for the owner). The solution was to use chmod:

sudo chmod 0755 /home/username
  • 1
    Yah! Worked for me. ssh was giving me a password prompt because I botched the persmissions.
    – clearlight
    Mar 6, 2018 at 6:36
  • Yeah! It has solved my issue.
    – crackpot
    Feb 24 at 3:25

I'm not an expert here but came across such issue too, here are my two cents in addition to all the other suggestions.

Sometimes ssh-copy-id copies the wrong key to the remote server (may happen if you have several keys and/or are using non-default names for key files) or your authentication agent is misconfigured.

Here's a quote from the man pages:

If the -i option is given then the identity file (defaults to ~/.ssh/id_rsa.pub) is used, regardless of whether there are any keys in your ssh-agent. Otherwise, if this: ssh-add -L provides any output, it uses that in preference to the identity file.

So basically you want to check that:

  • Your system authentication agent (usually ssh-agent) sees the keys that you intend to use (check ssh-add -L output)
    • If you don't see the desired key, add it using ssh-add
  • The ssh-copy-id copied the same key to the remote machine (just log in to the remote server using password and check the contents of ~/.ssh/authorized_keys)
    • If you don't see the desired key on the remote server, you can implicitly tell ssh-copy-id which key to copy: ssh-copy-id -i ~/.ssh/some_public_key

Hope that helps.

  • 1
    You nailed it! Digging through my ssh-copy-id the problem is: DEFAULT_PUB_ID_FILE=$(ls -t ${HOME}/.ssh/id*.pub 2>/dev/null | grep -v -- '-cert.pub$' | head -n 1), which will default to the alphabetical first key - in my case I had an id_boot2docker.pub(which is apparently the default name for boot2docker ssh stuff). Seems like there are a bunch of different ssh-copy-id implementations around; mine came from brew install ssh-copy-id, which in turn is taken from openssh-portable. My man page explicitly mentions this behavior... Mar 29, 2017 at 11:43

The most common problem is invalid permissions on the server side. Check that none of your home directory, ~/.ssh and ~/.ssh/authorized_keys are writable by anyone but you (in particular they must not be group-writable).

If that's not the problem, run ssh -vvv server and look at the client's view of the conversation. In particular, check that the client is trying the key with the server.

  • Thank you!!! I don't understand why, but your home directory, ~/.ssh, and ~/.ssh/authorized_keys can't be writeable by anyone but you.
    – ostrokach
    Nov 5, 2015 at 3:00

In addition to all of the above, one can always check the sshd log file:

  • 2
    In my case I saw Authentication refused: bad ownership or modes for directory /home/administrator in this log file which pointed me in the right direction. Oct 9, 2020 at 11:54

As a complement to Omer Dagan answer for newer CentOS 7, use:

journalctl -f -u sshd

for looking at the sshd logs at the server.


I've had that problem on CentOS 7. For me, it turned out to be a problem with SELinux that prevented access to the user's authorized_keys file. I filtered the audit log for the authorized_keys filename and tried to log in from the client machine:

[root@centos ssh]# tail -f /var/log/audit/audit.log |grep authorized_keys
type=AVC msg=audit(1580206788.877:2649): avc:  denied  { read } for  pid=84056 comm="sshd" name="authorized_keys" dev="dm-0" ino=74366557 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file permissive=0

First, make sure that semanage is available. On CentOS 7, the required package is policycoreutils-python. You can install it by executing

yum -y install policycoreutils-python

Afterwards, I updated the context by executing:

semanage fcontext -a -t ssh_home_t /home/username/.ssh/
restorecon -FRv /home/username/.ssh/

...and it finally worked. I found the solution for that here:



  • While this may answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
    – MMM
    Jan 28, 2020 at 10:34
  • Thanks for the hint, answer has been edited. Jan 28, 2020 at 19:15

I tried the other fixes but found that I had to change the home directory to not be writable by others. The home directory was 777. I changed it to 755 and it worked.

  • 1
    welcome @dulcana, he tries to set a passwrodless ssh login, how changing permisions to 755 could help to solve the problem? Oct 20, 2015 at 16:10
  • 1
    @FranciscoTapia that's because sshd ensures that other users couldn't have maliciously created the authorized_keys file, refusing login by ssh key where group or other can write the file or any of their parents. Other answers have also mentioned this.
    – Ángel
    Nov 9, 2016 at 16:32

full chmod fix from https://github.com/centic9/generate-and-send-ssh-key/blob/master/generate-and-send-ssh-key.sh

log in with password / root and switch to the user you want to be able to connect to then run

chmod go-w ~ && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys

in my case /etc/ssh/sshd_config contained the following param:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys2

But ssh-copy-id created a file with name authorized_keys, so I had to modify the entry to the new name. more info about deprecated authorized_keys2


For me, it worked after I deleted the log file on the server and recreated it:

rm -rf /var/log/auth.log
nano /var/log/auth.log

Ctrl + x



and then

(using default options)
ssh-copy-id -i /path-to-public-key user@server

You might be referencing the wrong private key. If you have more than one key and a custom key pair (i.e. save the files as myKey and myKey.pub) then, you need to reference they private key associated to the public key you registered when you ran ssh-copy-id -i ~/.ssh/myKey.pub <username>@<ip-address>.

In other words, try to run ssh -i <path-to-key> <username>@<ip-address>


Easy to overlook this, but if you have an encrypted home directory, it will not work for the first session. Subsequent sessions will however work once the home dir is mounted and the authorized_file is accessible.


The problem was I had RSAAuthentication disbled in /etc/ssh/ssh_config

You must log in to answer this question.

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