Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

My server is running CentOS 5.3. I'm on a Mac running Leopard. I don't know which is responsible for this:

I can log on to my server just fine via password authentication. I've gone through all of the steps for setting up PKA (as described at http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-ssh-beyondshell.html), but when I use SSH, it refuses to even attempt publickey verification. Using the command

ssh -vvv user@host

(where -vvv cranks up verbosity to the maximum level) I get the following relevant output:

debug2: key: /Users/me/.ssh/id_dsa (0x123456)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred keyboard-interactive,password
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

followed by a prompt for my password. If I try to force the issue with

ssh -vvv -o PreferredAuthentications=publickey user@host

I get

debug2: key: /Users/me/.ssh/id_dsa (0x123456)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: No more authentication methods to try.

So, even though the server says it accepts the publickey authentication method, and my SSH client insists on it, I'm rebutted. (Note the conspicuous absence of an "Offering public key:" line above.) Any suggestions?

share|improve this question
    
simply use "ssh -v" you do not need more verbosity and include the whole output not just the lines you think are important –  cstamas Aug 18 '09 at 7:37

11 Answers 11

Besides the modes of files/directories, ensure that the ownership is correct! A user must own their own home directory, .ssh/, and files therein.

I had to run chown -R $user:$user /home/$user to get past my ssh failures.

share|improve this answer
    
+1, on one of my systems the permissions on .ssh were right but someone had made the account's home directory 777. –  GargantuChet Jul 14 at 18:59

Check username with wich you are trying to log in. By default it's your username on local machine.

share|improve this answer

Sounds like a configuration problem to me. Like Daniel suggested there are two things to check:

  1. The SSH keys in $HOME/.ssh/authorized_keys are readable; and
  2. SSHd is configured to allow public key login.
share|improve this answer

i just got trapped in the same problem accessing with fedora core 16 to cents 5.5

the logs and verbose looked exactly the same

the problem was the public key, it got some bogus data,regenerate it and post it in the sshd_server, you sshd_client is sending the key information but is not recognized by the server (it dint match any of the keys in authorized_keys)

share|improve this answer

I had a similar problem - remote PC couldn't use public key authentication to log in to CentOs 6 server. The problem in my case was SELinux related - the home directory of the user trying to log in had message up security contexts. I resolved this by using the restorecon tool thusly:

restorecon -Rv /home
share|improve this answer
1  
Thanks, Gareth! "restorecon -Rv /root/.ssh" did the trick nicely. –  tbroberg Dec 18 '12 at 20:08
    
To explain further: this command is telling SELinux to reset the SELinux tags for files under /home to whatever they usually are in the directory layout for /home. –  rakslice Aug 27 '13 at 22:20

The output of the client as in ssh -v will reveal that there is a problem at a certain step in the protocol, but when it's due to something on the server the client won't be informed of the cause. Check the server log files to find out what's wrong. You likely need to be root in order to have permissions to do so. For example, for an sshd configured to log to syslog, you might find the messages in /var/log/secure. Like these ones:

Authentication refused: bad ownership or modes for directory /home/you/.ssh
Authentication refused: bad ownership or modes for file /home/you/.ssh/authorized_keys

The reason in this case was a (stupid) default default of 0002. That means, write access for the group. (Groupname = username, but still.) The SSH daemon won't trust files that can be tampered with by others than the user (well, and root, of course). You can solve the problem using chmod.

chmod 700 ~/.ssh # solve the issue
chmod 720 ~/.ssh # reproduce the issue
# or similar for a file
share|improve this answer

1- check your /etc/ssh/sshd_config, ensure you have

RSAAuthentication yes
PubkeyAuthentication yes

2- check the secure log from remote machine, look-up the detail sshd daemon error log. e.g. in my Ubuntu

# grep 'sshd' /var/log/secure | grep 'Authentication refused' | tail -5
Aug  4 06:20:22 xxx sshd[16860]: Authentication refused: bad ownership or modes for directory /home/xxx
Aug  4 06:20:22 xxx sshd[16860]: Authentication refused: bad ownership or modes for directory /home/xxx
Aug  4 06:21:21 xxx sshd[17028]: Authentication refused: bad ownership or modes for directory /home/xxx
Aug  4 06:21:21 xxx sshd[17028]: Authentication refused: bad ownership or modes for directory /home/xxx
Aug  4 06:27:39 xxx sshd[20362]: Authentication refused: bad ownership or modes for directory /home/xxx

Then check the ownership and modes for directory /home/xxx, maybe you need run this

chmod 755 /home/xxx
share|improve this answer
1  
Check log file of system is a very important hint. –  Kane Jun 20 '12 at 9:59
1  
The home directory perms of 755 helped me - definitely required! –  Ben Mar 14 '13 at 22:50

Got it! Turns out it was a client-side issue. (I think that any server-side issue would have yielded more useful debug output.) For reasons unknown to me, on my Mac, the file /etc/ssh_config had the line

PubkeyAuthentication = no

I commented out that one line, and now everything works fine.

share|improve this answer

Also check that it can auto supply a key or not, use -i path/to/key if not or just to test

share|improve this answer

Check that your Centos machine has:

RSAAuthentication yes
PubkeyAuthentication yes

in sshd_config

and ensure that you have proper permission on the centos machine's ~/.ssh/ directory.

chmod 700 ~/.ssh/
chmod 600 ~/.ssh/*

should do the trick.

share|improve this answer
1  
the correct rights and filenames (sometimes authorized_keys2, sometimes without the 2) is very important! –  brandstaetter Feb 23 '12 at 20:25
2  
The permission of file authorized_keys is very important hint. Thanks. –  Kane Jun 20 '12 at 9:59
4  
You might also need to chmod go-w ~/ if it isn't so already. –  tylerl Aug 9 '12 at 18:51
    
Also check the ownership of /root/. I already faced a situation where /root/ was belonging to another user and this was preventing password-less authentication. –  ereOn Apr 25 '13 at 13:43
    
Also check if your home dir on remote server has permissions 755 (as Jinyu Liu mentions below) –  Attila Fulop Oct 4 '13 at 16:01

Double check that your permissions are correct and file structure (specifically spelling) are correct, for both local and remote machines. The URL you refer to states them all, but it's worth checking that what you have matches. Normally permissions will throw a relevant error though.

Have you checked that the sshd_config on your CentOS 5.3 box is set to allow PubkeyAuthentication or RSAAuthentication ?

Check the SSH server logs on the CentOS system - it may provide more information. I'm not sure if CentOS does the blacklisted ssh key checking that debian does, but I've seen ssh publickey rejections that are relatively silent as far as -vvv output goes, but the logs pretty clearly explained what was going on

share|improve this answer

Your Answer

 
discard

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