4

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?

Improve this question
3
  • 3
    Works for me. What does "ssh -v -v -v client" tell you?
    – Paul Tomblin
    Jul 30, 2010 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 'SO- stop being evil'
    Jul 30, 2010 at 21:32
  • Check that 1) your permissions are right and 2) you're using the correct user. There is no reason this shouldn't work.
    – aggregate1166877
    Jul 14, 2021 at 3:07

3 Answers 3

Reset to default
3

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?

Improve this answer
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.

Improve this answer
-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.

Improve this answer
1
  • 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, 2015 at 8:25

You must log in to answer this question.

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