EDIT: This question was reworked to make it more useful to the community and less specific to me.

Questions seem to come up reasonably often regarding ssh and problems with authorised keys access, but very few seem to have a clear answer anywhere;

Server keeps asking for password after I've copied my SSH Public Key to authorized_keys

ssh not accepting public key

how do I use ssh with key access in 11.10

passwordless ssh not working

So, In the communities opinion, what is the tried and tested method for getting to the bottom of such problems?

  • Please post the output from ssh -v on the client, and anything relevant from ~/.ssh/config. Are you doing anything beyond just sshing to one host for an interactive session?
    – poolie
    Mar 18, 2012 at 12:16
  • 1
    are you using an encrypted disk/folder on the server?
    – duffydack
    Mar 18, 2012 at 12:28
  • @poolie I've added the relevant parts of ssh -v to the question and actually spotted where the problem lies myself. Thanks for the prod in the right direction.
    – Ashimema
    Mar 18, 2012 at 12:57
  • @duffydack Nope, no encrypted disks or directories in this case. Cheers
    – Ashimema
    Mar 18, 2012 at 12:57
  • 1
    I managed to get to the bottom of this, but I can't post the answer for another 6 hours... Thanks for your help guys.. I will add the answer when i can and mark as answered.. Hopefully the next time someone searches for this, they'll be able to answer it themselves with the directions in my answer..
    – Ashimema
    Mar 18, 2012 at 13:21

1 Answer 1


Analysing the problem

There are two places an ssh connection can go wrong, on the server or at the client. We want to rule them out one at a time.

On the Server

To increase the logging on the server set the following line in your /etc/ssh/sshd_config file;

LogLevel DEBUG

There's also a DEBUG2 and DEBUG3 to get even more information sent to the logs.

To monitor the logs, use the command tail -f /var/log/auth.log

On the Client

You can add verbosity to your client connection with a -v option.

ssh -v [email protected]

There is also a -vv and -vvv to increase the verbosity of the output

Spotting the Error

Set your log monitoring going on the server with the above command and then try connecting to it from the client using a verbosity level also above. Now, carefully check the outputs from each and look for could not's, Permission denied's, no such identity:'s or Incorrect RSA1 identifier's etc. These are most likely the problem if your in a similar position to me.

Common Pitfalls

Permissions - Client Side

The certificates and known_hosts (usually found within ~.ssh) all need to be readable by the user. In the simplest instant, id_rsa, id_rsa.pub and knwon_hosts should be owned by and in your user group and should be readable by the user, below is the 'default' setup.

-rw------- username username id_rsa

-rw-r--r-- username username id_rsa.pub

-rw-r--r-- username username known_hosts

Permissions - Server Side

Again, the certificates and this time the authorized_keys files must be readable by the user being logged in. Defaults as shown below:

-rw------- username username authorized_keys

-rw-r--r-- username username id_rsa

Encrypted Drives/Directories

SSH on the server needs to be able to see/read the authorized_keys file and associated server certificates; therefore if they are on an encrypted device then a session must be live for the device to be readable by the daemon. This is often seen when you can login via password and whilst that session is live, you can then login via authorised keys and no password.

You must log in to answer this question.

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