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
1  
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
show 3 more comments

14 Answers 14

up vote 71 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 ~ and your ~/.ssh directory 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).
  • Your private key file (on the local machine) must be readable and writable only by you: rw-------, i.e. 600.
  • 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.
  • 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).
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
1  
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
1  
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
show 4 more comments

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

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

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

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

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

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

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

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

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

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

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

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

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

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.