47

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?

Improve this question
2
  • 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, 2009 at 7:37
  • This question is being closed because it is no longer answerable, and is attracting low quality answers.
    – HopelessN00b
    Mar 3, 2015 at 23:21

12 Answers 12

Reset to default
52

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.

Improve this answer
6
  • 1
    the correct rights and filenames (sometimes authorized_keys2, sometimes without the 2) is very important!
    – brandstaetter
    Feb 23, 2012 at 20:25
  • 5
    The permission of file authorized_keys is very important hint. Thanks.
    – Kane
    Jun 20, 2012 at 9:59
  • 7
    You might also need to chmod go-w ~/ if it isn't so already.
    – tylerl
    Aug 9, 2012 at 18:51
  • 1
    Also check if your home dir on remote server has permissions 755 (as Jinyu Liu mentions below)
    – Attila Fulop
    Oct 4, 2013 at 16:01
  • 1
    In other operating systems the SSH config file could also be living under: /etc/ssh/ssh_config
    – Yoshua Wuyts
    Aug 12, 2016 at 15:54
18

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
Improve this answer
3
  • 2
    Thanks, Gareth! "restorecon -Rv /root/.ssh" did the trick nicely.
    – tbroberg
    Dec 18, 2012 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, 2013 at 22:20
  • If you're logging in as root, it should be restorecon -Rv /root
    – youfu
    Mar 14, 2016 at 13:59
17

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
Improve this answer
2
  • 2
    Check log file of system is a very important hint.
    – Kane
    Jun 20, 2012 at 9:59
  • 2
    The home directory perms of 755 helped me - definitely required!
    – Ben
    Mar 14, 2013 at 22:50
11

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

Improve this answer
9

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.

Improve this answer
1
  • great! this was it. updated the file's location for catalina 10.15
    – laka
    Jan 23, 2021 at 23:34
4

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.

Improve this answer
1
  • +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, 2014 at 18:59
2

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

Improve this answer
2

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.
Improve this answer
2

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

Improve this answer
1

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
Improve this answer
1

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)

Improve this answer
-1

Another bitten by this. After a long search it turned out i was explicitly feeding ssh the public key (with the -i option) instead of the private key. Doh!

Improve this answer
0