23

My machine recently stopped accepting incoming public key authentication. I have an ubuntu 11.04 desktop that I ssh into from a windows machine. I use putty with pageant. I am able to connect but only with interactive password authentication, not with my rsa key that I have setup.

I have already verified that the key is listed in ~/.ssh/authorized_keys. How do I fix this and what do I check?

3
  • 2
    First check that all three of ~, ~/.ssh and ~/.ssh/authorized_keys are only writable by you (in particular no group write permission). Look in /var/log/auth.log for log entries created at the time of your login attempts. Copy-paste them into your question (editing out names for privacy if you like). Also check whether the problem is purely on the server side or not: copy the private key over to the Linux machine (you'll need to convert PuTTY's private key file into the OpenSSH format) and see if ssh localhost works. Oct 20, 2011 at 14:12
  • my home directory was writable for some reason. That fixed it. Put it as an answer so I can accept it. Oct 20, 2011 at 17:46

9 Answers 9

30

If public key authentication doesn't work: make sure that on the server side, your home directory (~), the ~/.ssh directory, and the ~/.ssh/authorized_keys file, are all writable only by their owner. In particular, none of them must be writable by the group (even if the user is alone in the group). chmod 755 or chmod 700 is ok, chmod 770 is not.

What to check when something is wrong:

  • Run ssh -vvv to see a lot of debugging output. If you post a question asking why you can't connect with ssh, include this output (you may want to anonymize host and user names).
  • If you can, check the server logs in /var/log/auth.log.
  • If public key authentication isn't working, check the permissions again, especially the group bit (see above).
4
  • (from the U&L tag wiki, copied to AU) Oct 20, 2011 at 18:02
  • 1
    Nice answer! I forgot my homedir :o Nov 2, 2015 at 12:08
  • If you're running recent version of ssh (or sshd), DSA keys are no longer supported by default because of security problems. The only real fix is to upgrade to RSA or better keys. Feb 4, 2016 at 13:37
  • I changed the permissions of my home folder and what? I was locked out of SSH! I changed the ssh keys, no, server still refuses connection! I was crazy trying to find a solution and with your answer of chmod 700 to my home folder, ssh started working!!!!!!! Thanks! If my terminal connection dropped while trying to find the solution, I would be totally locked out of the server. So beware not to play with your home folder permissions! (I just changed my home folder permissions, not .ssh folder but still locked out of SSH)
    – Tarik
    Sep 3, 2017 at 12:17
11

I ran into the same thing and finally figured out that it was because I encrypted my home directory. SSH can't read the authorized_keys file until you log in, so basically it forces you to password authenticate first. See the section about the encrypted home directory on the following link:

https://help.ubuntu.com/community/SSH/OpenSSH/Keys#Encrypted_Home_Directory

5

If you check the permissions on the directories, and there is a "." right after them, then you may have selinux enabled, which will mess w/ the key exchange, and default to manual password identification.

You can disable SELinux to troubleshoot by following the instructions here: http://www.centos.org/docs/5/html/5.1/Deployment_Guide/sec-sel-enable-disable-enforcement.html, or just edit the /etc/selinux/config file and change it from "enforcing" to "disabled".

Hope this helps.

3
  • I had selinux enabled, but disabling it didn't seem to fix it. What did the trick for me was chmod 600 ~/.ssh/authorized_keys - the file was group-writeable. (via pyrosoft.co.uk/blog/2013/01/12/…) Apr 13, 2016 at 16:33
  • This helped me! Thank you! Oct 14, 2019 at 9:38
  • You should also be able to get SSH authentication working with SELinux by setting the correct SELinux contexts. Restoring the system-configured contexts on your home directory (restorecon ~ -R) is a good starting point. Oct 28, 2019 at 14:54
4

I would ensure that you have your settings in /etc/ssh/sshd_config correct.

To force the use of PKI only and to disallow passwords find the line

#PasswordAuthentication yes 

in your file, uncomment it and set it to

PasswordAuthenticate no

I would also read through the balance of the settings to ensure they make sense. In particular, try to ensure that you use RSA keys since DSA is know to be compromised.

1
  • 11
    You're explaining how to disable password authentication. This won't help make public key authentication work (the public key is tried first). Andrew: do not disable password authentication until you're sure public key authentication works! Oct 20, 2011 at 14:14
3

One possible cause of the problem is that you have DSA keys but now SSH (apparently) defaults to requiring RSA keys. I got the problem when upgrading to 16.04. You can see more here but the short answer is add the following to ~/.ssh/config:

PubkeyAcceptedKeyTypes ssh-dss
1

I fixed this problem by un-commenting "PasswordAuthentication yes" in /etc/ssh/sshd_config.

1

Due to a need for troubleshooting communication between two different machines, I had two private keys in ~/.ssh on the client side.

Instead of configuring each server host with the respective private key in ~/.ssh/identity as I should have done, I had the secondary (and in this case wrong) key configured for all hosts:

Host *
IdentityFile ~/.ssh/identity_b

Correcting ~/.ssh/identity resolved the issue:

Host a
IdentityFile ~/.ssh/identity_a
Host b
IdentityFile ~/.ssh/identity_b
0

I just had the same problem but changing the permissions with chmod wasn't helping, since it turned out I didn't have ownership of the ~/.ssh/authorized_keys file. You can change ownership of the .ssh directory with:

sudo chown -R "$USER" ~/.ssh
-1

Somehow this worked for me:

root@kaiser:~# vim /etc/ssh/sshd_config

Change this line from yes to no 28 StrictModes no

Try again

sysadmin@suselinux1:~> con sysadmin kaiser Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-25-generic i686)

Last login: Fri Nov 9 15:40:11 2012 from 10.1.3.25 sysadmin@kaiser:~$ date vie nov 9 17:53:11 CST 2012 sysadmin@kaiser:~$

2
  • 3
    Doing something without knowing what it does and why it works may be acceptable, but suggesting the same is bad, and to be fair, worse if it deals with a security system.
    – Mahesh
    Nov 10, 2012 at 5:17
  • 2
    agreed. let this be incentive to create better sshd docs, which don't exactly fall into the "nice saturday reading" category
    – code_monk
    Dec 25, 2014 at 5:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .