Why won't automatic login through ssh with authorized_keys work?

26,583

Solution 1

Although your problem may have already been solved by other answeres, I've locked myself out of enough machines from not validating sshd_config changes before signing off so have come up with the below process that might be useful for future debugging of sshd config changes:

DO NOT DISCONNECT an active ssh connection until AFTER testing has verified behaviour is as you expect.

a. verify what you think sshd is supposed to be doing

b. verify the configuration is valid using "-t"

c. start a verbose 'test' version of the server you can live monitor

d. start a verbose 'test' client connection you can live monitor


a. verify what you think sshd is supposed to be doing

Review the sshd configuration file without all the commentary with something like the below (assuming sshd_config is the correct file and in /etc/ssh)

$ grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"

This just clears things out so we verify what we think we're changing (not necessarily whether it is correct or not.)

b. verify the configuration is valid using "-t"

From the man page of the sshd's I'm using,

-t Test mode. Only check the validity of the configuration file and sanity of the keys. This is useful for updating sshd reliably as configuration options may change.

Other changes can have more subtle circumstances. For example, do not disable password authentication until you are sure that the public key authentication is working correctly.

c. start a verbose 'test' version of the server you can live monitor

$ sudo /usr/sbin/sshd -ddd -p 9999

This keeps your existing, working session active, but gives you another instance of sshd to verify your new configuration changes. SSHD is now running in the foreground to a user-defined port (9999 in our example.) and pushing a lot of noisy debug information you can track in /var/log/authlog (or possibly /var/log/auth.log depending on your OS.)

d. start a verbose 'test' client connection you can live monitor

Run the ssh client connection in verbose mode to display on your screen more information that might lead you to better debugging your error.

$ ssh -vvv -p 9999 server-name

You should now have enough information in either the server's log files, or the client's connection screen to isolate your problem.

The solution generally comes down to file permissions (as shown by Magnar and setatakahashi)

Best of luck

Solution 2

The server will ignore your authorized_keys file if the owner properties are wrong. Changing it to this fixes it:

chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/authorized_keys

Solution 3

$ chmod 700 ~

$ chmod 700 ~/.ssh

$ chmod 600 ~/.ssh/authorized_keys

Check for these attributes in /etc/ssh/sshd_config

$ sudo grep PubkeyAuthentication /etc/ssh/sshd_config

$ sudo grep Protocol /etc/ssh/sshd_config

Solution 4

Another important pitfall..

If your home directory is encrypted sshd will not have access to ~/.ssh/authorized_keys..

See this answer

Share:
26,583

Related videos on Youtube

Magnar
Author by

Magnar

Updated on September 17, 2022

Comments

  • Magnar
    Magnar over 1 year

    I have created a private/public dsa-keypair. I've put the public key on the server in

    ~/.ssh/authorized_keys
    

    Everything is set up like my other server, but it seems like the server is just ignoring my efforts.

    • Kristopher Johnson
      Kristopher Johnson about 15 years
      Check /etc/ssh/ssh_config and /etc/ssh/sshd_config to verify that nothing you want is disabled.
    • Vagnerr
      Vagnerr about 15 years
      You will want to check sshd_config too.
    • Kristopher Johnson
      Kristopher Johnson about 15 years
      Thanks. I updated the answer (which originally mentioned only ssh_config).
    • chris
      chris almost 15 years
      All of the above discussions are perfect for if you're using an openssh style of ssh. If you're system is using ssh2 then it has a totally wacky different way to manage keys. This article discusses the hows and whats. burnz.wordpress.com/2007/12/14/…
    • JaakL
      JaakL almost 12 years
      In case you already logged out from server and cannot log in due to invalid server configuration then following forces client to use password: ssh <user>@<server> -p <port> -o 'PasswordAuthentication yes' -o 'ChallengeResponseAuthentication no' -o 'PreferredAuthentications password'
    • Giovanni Toraldo
      Giovanni Toraldo about 11 years
      Usually checking /var/log/auth.log on Debian systems or /var/log/secure on RedHat ones should give you a clear advice of what is misconfidured (usually permissions problems)
    • ADTC
      ADTC over 8 years
      All else being equal, running restorecon -R -v /root/.ssh on the server side (not the connecting client) made a difference. Try this, if you fixed the permissions and it still wouldn't connect.
  • Dave Cheney
    Dave Cheney about 15 years
    ssh -vvv -l username server.domain will tell you if your sending a valid key
  • Olaf
    Olaf about 15 years
    Sometimes I've seen sshd complain about bad permissions on the home directory - so I'd add "chmod o-rwx ~" (or at least "chmod o-w ~") to the list as setatakahashi did. This usually becomes obvious when the logfile is monitored - the error messages I've seen there always pointed in the correct direction.
  • dwc
    dwc about 15 years
    This answer seems the most likely, but Dave Cheney's comment is the only way to see what's really going on. Also check server logs.
  • Memb
    Memb about 15 years
    I guess you should also check the ssh_config file on the client end to make sure it is doing what you expect. Use something like the below to grep out comments: > grep -v "^#" /etc/ssh/ssh_config | grep -v "^$"
  • Dave Cheney
    Dave Cheney almost 15 years
    Excellent point about ~, you must make sure that nobody other than yourself can write to your home directory, otherwise they could rename your ~/.ssh directory
  • SooDesuNe
    SooDesuNe over 12 years
    that last chmod should be: $ chmod 600 ~/.ssh/authorized_keys not $ chmod 600 ~/.sHh/authorized_keys
  • Soviero
    Soviero over 12 years
    Well, the client ssh configuration can be fixed at anytime, it's the server you get locked out of if you configured it wrong.
  • balolo
    balolo almost 12 years
    This did the trick, but my previous permissions were 0775 and 0644 respectively. Why did reducing the permissions help? Is this a security precaution that's configured somewhere?
  • Michael
    Michael about 9 years
    what should the attribute values be?
  • johndodo
    johndodo about 9 years
    Two important things: 1) make sure the owner of ~/.ssh/authorized_keys is correct; 2) check for failure reason in log: tail -f /var/log/auth.log