Can't get SSH public key authentication to work

Question

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?

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 07:37
This question is being closed because it is no longer answerable, and is attracting low quality answers. — HopelessN00b, Mar 03 '15 at 23:21

score 52 · Answer 1 · answered Aug 18 '09 at 11:25

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.

answered Aug 18 '09 at 11:25

pyhimys

1,287
10
10

1

the correct rights and filenames (sometimes authorized_keys2, sometimes without the 2) is very important! – brandstaetter Feb 23 '12 at 20:25
5

The permission of file **authorized_keys** is very important hint. Thanks. – Kane Jun 20 '12 at 09:59
7

You might also need to `chmod go-w ~/` if it isn't so already. – tylerl Aug 09 '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
1

Also check if your home dir on remote server has permissions `755` (as Jinyu Liu mentions below) – Attila Fulop Oct 04 '13 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 '16 at 15:54

score 18 · Answer 2 · answered Feb 20 '12 at 23:02

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

answered Feb 20 '12 at 23:02

Gareth

181
1
2

2

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
If you're logging in as root, it should be `restorecon -Rv /root` – youfu Mar 14 '16 at 13:59

score 17 · Answer 3 · answered Aug 04 '11 at 13:53

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

The home directory perms of 755 helped me - definitely required! — Ben, Mar 14 '13 at 22:50

score 11 · Answer 4 · answered Aug 18 '09 at 04:26

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

score 8 · Answer 5 · answered Aug 18 '09 at 16:16

8

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.

answered Aug 18 '09 at 16:16

great! this was it. updated the file's location for catalina 10.15 – laka Jan 23 '21 at 23:34

score 4 · Answer 6 · answered Aug 23 '13 at 22: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.

answered Aug 23 '13 at 22:34

Visser

141
2

+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 '14 at 18:59

score 2 · Answer 7 · answered May 13 '13 at 12:57

2

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

answered May 13 '13 at 12:57

Creotiv

121
2

score 2 · Answer 8 · edited Sep 04 '12 at 12:59

2

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

The SSH keys in $HOME/.ssh/authorized_keys are readable; and
SSHd is configured to allow public key login.

edited Sep 04 '12 at 12:59

Khaled

36,533
8
72
99

answered Aug 18 '09 at 06:46

sybreon

7,405
1
21
20

score 2 · Answer 9 · answered Aug 18 '09 at 13:17

2

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

answered Aug 18 '09 at 13:17

Jimsmithkka

570
4
13

score 1 · Answer 10 · answered Feb 14 '12 at 18:52

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

score 1 · Answer 11 · answered Mar 31 '12 at 02:26

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)

score -1 · Answer 12 · answered Mar 03 '15 at 22:46

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

answered Mar 03 '15 at 22:46

Ellert van Koperen

111
1

Can't get SSH public key authentication to work

12 Answers12