Why isn't my public key allowing me to sign in without a password?

Question

On my home network I have a server running Ubuntu and another desktop running Windows 7. I'm using cygwin on the Windows machine to ssh into the server. I attempted to set up keys between these two machines. On the Windows machine I created keys using ssh-keygen -t rsa. I then 'scp'ed the resulting id_rsa.pub to the server and placed it in the ~/.ssh/authorized_keys file. As far as I know that should be all I need to make this work. But, as you may have guessed, it isn't.

I'm trying to ssh using [email protected]. My guesses (that I haven't been able to get great information on) are that I might need to set something up a bit different to use cygwin or that it could have something to do with using the ip address rather than the hostname... Any directions or ideas?

Solution 1

It's probably a permissions issue on either your ~/.ssh directory or your ~/.ssh/authorized_keys file.

Your ~/.ssh directory should be chmod'd to 700 and your authorized_keys file should be chmod'd to 644 at the very least. If you check your /var/log/secure log file, it should give you some hint as to the reason it's failing.

Solution 2

If you are having authentication problems with ssh, the first thing to investigate is what the client says with some debugging:

% ssh -v host
...
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/david/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
...

is a successful publickey connection.

% ssh -v host
...
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/david/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/david/.ssh/identity
debug1: Trying private key: /home/david/.ssh/id_rsa
debug1: Next authentication method: password
david@ace's password: 
...

This doesn't really offer much information as to why publickey authentication was being refused. The best information is available on the server. Sshd will log to the AUTH syslog facility, so you can find information where ever that is logged to (in the case of Debian /var/log/auth/).

Aug 19 08:18:36 ace sshd[10100]: Authentication refused: bad ownership or modes 
       for directory /home/david/.ssh

This tells us that the permissions for .ssh is wrong and we can easily fix it.

Aug 19 08:26:41 ace sshd[12156]: error: key_read: uudecode
       ZAAAAB3NzaC1kc3MAAACBAIUuAmpj9FuE71EfqJDVAfI+pUZ++xSWbUvEh7U36WW/...

This tells us that it failed to read that particular key, so we know to fix that.

If you don't get any useful information from the logs, you can turn up the logging. Edit /etc/ssh/sshd_config and change the LogLevel line to:

 LogLevel DEBUG

Then run

 /etc/init.d/ssh reload

Now when you try to connect you should see some logs like:

Aug 19 08:32:12 ace sshd[13537]: debug1: Checking blacklist file 
      /usr/share/ssh/blacklist.DSA-1024
Aug 19 08:32:12 ace sshd[13537]: debug1: Checking blacklist file 
      /etc/ssh/blacklist.DSA-1024
Aug 19 08:32:12 ace sshd[13537]: debug1: temporarily_use_uid: 1002/513 (e=0/0)
Aug 19 08:32:12 ace sshd[13537]: debug1: trying public key file 
      /home/david/.ssh/authorized_keys
Aug 19 08:32:12 ace sshd[13537]: debug1: fd 4 clearing O_NONBLOCK
Aug 19 08:32:12 ace sshd[13537]: debug1: matching key found: file 
      /home/david/.ssh/authorized_keys, line 1
Aug 19 08:32:12 ace sshd[13537]: Found matching DSA key: 
      1c:46:89:52:c1:79:c8:8f:43:3c:4e:77:ad:a1:5d:1b

This was a successful login.

If you need more information, you can use DEBUG2 and DEBUG3 to get further information. Don't forget to change your log level back again (probably to INFO) when you've fixed the problem.

Solution 3

Some distros provide a tool (it's really a shell script) called ssh-copy-id. I find using this gets around a lot of the headaches with copying the .pub portion of a user's key to a remote account's authorized_keys file.

Usage

$ ssh-copy-id user@remotehost

You can even tell it different keys to copy (it defaults to the id_rsa* keys.

$ ssh-copy-id -i ~/.ssh/somekey.pub user@remotehost

This script also takes care of creating the user's $HOME/.ssh directory on remotehost as well and set's the permissions up correctly.

$ ssh-copy-id --help
Usage: /usr/bin/ssh-copy-id [-i [identity_file]] [user@]machine

It has a basic man page to go along with it. On my Red Hat based distros (Fedora, CentOS, RHEL) it was part of the stock openssh-client package!

Solution 4

The permissions are important for the ~/.ssh/authorized_keys file. The file itself must not have permissions that allow anyone else to write to it chmod go-rwx ~/.ssh/authorized_keys Also, the .ssh directory must not allow writes to it chmod go-rwx ~/.ssh Your home directory should also not allow writes chmod go-w ~/

The reason for this is if anyone else was able to write to your directory (via group permission or other permission) then it would be quite easy for someone to cram authorized keys in there without your knowledge. If your home directory allows writes, then someone could recreate the .ssh directory and its contents.

View more solutions

Comments

[codingpitch]

This is what the permissions were set to to begin with I believe. I found in the /var/log/auth.log file some error messages leading me to believe my key got corrupted somehow...? I regenerated my keys and uploaded them and things seem to work now. Thanks!

[Tobias Kienzler]

Another reason for failure can be linebreaks in authorized_keys that don't belong there

[James M. Lay]

Thank you. I had wrong permissions on my $HOME directory. Would never have thought to look there.