Take the 2-minute tour ×
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:

http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

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
2  
output from the command you're giving to ssh with the -v flag? should be similar to this pastebin.com/xxe57kxg –  Rob Apr 16 '12 at 14:48
1  
also make sure your .ssh folder is chmod 700 –  Rob Apr 16 '12 at 14:55
2  
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

18 Answers 18

up vote 90 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
    
@WarrenYoung no matter how many times I set it up, I always forget about ssh-copy-id. I've only had to set the ~/.ssh directory before. –  Rob Apr 18 '12 at 15:04
2  
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
2  
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

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:

ssh-add
share|improve this answer

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

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.

D'oh!

share|improve this answer

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

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

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

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

  • 'no' to 'yes' for PubkeyAuthentication

Based on http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/

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

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 *.mydomain.org...IdentityFile ~/.ssh/some_limited_use.pub -- ssh-add ~/.ssh/some_limited_use.pub). –  tristan Feb 3 at 12:11

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

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

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

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

service ssh reload
share|improve this answer

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 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 at 16:09

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

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 created a /etc/ssh/username folder, owned by username, with the correct permissions, and placed the authroized_keys file in there. Then changed the AuthorizedKeysFile directive in ~/.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
2  
    
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 at 8:21

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
1  
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
1  
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 at 5:36

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

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
share|improve this answer
    
There exists already ssh-copy-id which does the last two steps automatically. –  jofel Apr 17 '12 at 13:05
1  
@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

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.

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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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