Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

OK, I know the basics of how to set up passwordless ssh: create a keypair using ssh-keygen then add the public key from 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/ 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?

share|improve this question

migrated from Jul 30 '10 at 18:11

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

Works for me. What does "ssh -v -v -v client" tell you? – Paul Tomblin Jul 30 '10 at 18:06
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

3 Answers 3

up vote 1 down vote accepted

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 to my .ssh/authorized_keys and it worked. Are you sure that your local sshd is configured to accept shared key authentication?

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
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 at 8:25

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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