3

OK, I know the basics of how to set up passwordless ssh: create a keypair using ssh-keygen then add the public key from id_dsa.pub into the host's .ssh/authorized_keys. So for two different machines client and host, I can ssh from client into host without entering a password. Good so far.

But I have some software which requires that client be able to ssh into itself without a password. Naively I do the same thing: simply copy .ssh/id_dsa.pub into .ssh/authorized_keys, same directory. But it doesn't work. If I type

user@client:~$ ssh client

then it still asks for my password, even though the public key of client is in its own authorized_keys file.

Am I missing something?

migrated from stackoverflow.com Jul 30 '10 at 18:11

This question came from our site for professional and enthusiast programmers.

  • 3
    Works for me. What does "ssh -v -v -v client" tell you? – Paul Tomblin Jul 30 '10 at 18:06
  • 1
    First check that your home directory, the .ssh directory and the authorized_keys file are only writable by the user, not by the group. If it still doesn't work, post the output of ssh -vvv client. Also look at the server logs (e.g., /var/log/auth.log) if you have access to them. – Gilles Jul 30 '10 at 21:32
2

Use ssh-copy-id user@client and it will copy the correct data to the correct place. If it's the same user as you, though, it can be problematic since it may overwrite something important. Make a copy of your .ssh directory before trying.

EDIT: Strangely enough, I tried to add my id_rsa.pub to my .ssh/authorized_keys and it worked. Are you sure that your local sshd is configured to accept shared key authentication?

0

If I'm not mistaken the default options (and default locations of the private keys) are governed by the /etc/ssh/ssh_config file.

However, an ssh command option allows you to specify the location of the private key to be used as well.

-1

Another problem that will have a similar symptom is a failure to add localhost to /etc/hosts.allow, the control file for TCP wrappers. You can temporarily rename /etc/hosts.deny to determine if this is the source of your problem.

  • IF sshd were set to use tcpwrappers, and localhost was not in the hosts.allowed file, then the entire connection would be disallowed. That is an entirely different symptom. – Jenny D Jan 27 '15 at 8:25

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.