Sign up ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

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.

share|improve this question
output from the command you're giving to ssh with the -v flag? should be similar to this – Rob Apr 16 '12 at 14:48
also make sure your .ssh folder is chmod 700 – Rob Apr 16 '12 at 14:55
assuming you've got root access to the server, /var/log/auth.log will tell you why the login is failing. – UtahJarhead Apr 17 '12 at 4:05
Did you password-protect your key? – Kevin Apr 18 '12 at 18:02
@Kevin no, I didn't. – Thom Apr 18 '12 at 21:38

19 Answers 19

up vote 178 down vote accepted

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.

share|improve this answer
I think if you test, you'll find that the public key file just has to be readable by the owner (400), and then only during ssh-copy-id or similar. Similarly, the authorized_keys file mode check only tests that it is not world or group writeable. It can be 400, too, if you don't need to add more keys to it, or 600 if you do. I didn't feel comfortable making factual changes to your answer beyond the one typo fix, so I'll leave the edits to you. – Warren Young Apr 17 '12 at 16:16
For authorized_keys 600 is more than enough, and I recommend to keep it that way. The public key does not "have to be" 644 (600 is enough), but it doesn't matter, it's "public" anyway. – janos Apr 17 '12 at 18:22
Thank you very much for pointing out restorecon. I've been scratching my head at precisely this issue for a while now. – Richard Barrell Dec 3 '12 at 14:56
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 Jan 25 '13 at 19:22
Also remember to check the owner and group settings, I used RSYNC to copy over an authorized_keys file and didn't notice that owner/group was set to 1000 instead of root! – nak Feb 16 '13 at 17:23

If you have root access to the server, the easy way to solve such problems is to run sshd in debug mode, e.g.:

service ssh stop      # will not kill existing ssh connections
/usr/sbin/sshd -d     # full path to sshd executable needed, 'which sshd' can help
...debug output...
service ssh start

(If you can access the server through any port, you can just use /usr/sbin/sshd -d -p <port number> to avoid having to stop the SSH server. You still need to be root though.)

In the debug output, 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/
share|improve this answer
Great advice thanks – Chris Diver Nov 20 '12 at 16:37
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 Nov 30 '12 at 5:18
For reference, this post explains the SELinux solution that addressed my problem. – N Rohler Nov 30 '12 at 5:36
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. – ub3rst4r May 14 '14 at 5:36
Great advice, my user folder was with the wrong permissions. – barbosa Dec 18 '14 at 10:23

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.

share|improve this answer
ubuntu doc in it: – Fab V. Mar 12 '14 at 7:32
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 Jun 20 '14 at 8:21
Holy crap I've searched wayyyy to long to resolve that issue, tank you so much ! – h3. Feb 13 at 17:33

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.

share|improve this answer
We had this problem too - 755 on the home dirs fixed it – davidfrancis Jul 18 '12 at 14:52

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

share|improve this answer
On which server? – Amalgovinus Jun 17 '14 at 19:47
@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 Sep 24 '14 at 16:09
This is the simplest, and best solution – BЈовић Mar 3 at 13:22
Please note that generally, allowing remote root logins is not a recommended security practice. – arielf Jun 22 at 18:21

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
share|improve this answer
Actually no you don't. ssh automatically uses ~/.ssh/id_rsa (or id_dsa) without having to use a key agent. – Patrick Nov 7 '13 at 1:29
This can still be helpful advice if one was to specify a differently named key in ~/.ssh/config (e.g. on host * ~/.ssh/ -- ssh-add ~/.ssh/ – tristan Feb 3 '14 at 12:11

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
share|improve this answer

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

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

share|improve this answer
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 Apr 16 '12 at 14:46
Also, check the file/directory permissions. They are described on the website you provided. – Wojtek Rzepala Apr 16 '12 at 15:00
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 Apr 16 '12 at 15:03
@Rob that was the problem. If you'd post that as an answer, I'd accept it. – Thom Apr 17 '12 at 9:08

It would be SSH miss configuration at server end. Server side sshd_config file has to be edited. Located in /etc/ssh/sshd_config. In that file, change variables

  • 'yes' to 'no' for ChallengeResponseAuthentication, PasswordAuthentication, UsePAM

  • 'no' to 'yes' for PubkeyAuthentication

Based on

share|improve this answer

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

[ ! -f ~/.ssh/ ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/ | 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
share|improve this answer
There exists already ssh-copy-id which does the last two steps automatically. – jofel Apr 17 '12 at 13:05
@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 Apr 17 '12 at 18:09
@janos : points noted. thank you. – Sriharsha Apr 19 '12 at 3:08

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.


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

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.

share|improve this answer

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:

share|improve this answer

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.

share|improve this answer
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. – LiuYan 刘研 Jun 13 at 3:41

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
share|improve this answer

protected by Mat Feb 25 at 20:05

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.