I have an Ubuntu Server, running in a Cloud. I created a user (git). In the folder /home/git, I have created the .ssh/ dir, and the authorized_keys file.

But, when I put my SSH Public Key in the authorized_keys file, the server continues to ask me the password.

What did I do wrong?


16 Answers 16


On the server side, the ssh daemon will log errors in /var/log/auth.log, so check that file to see what's being reported.

From the client side, when establishing the connection you can add the -v flag (or -vv or -vvv) to increase verbosity. You might be able to identify your problem this way.

Here are other things to check.

  • Make sure /home/git/.ssh/authorized_keys is owned by git.
  • Make sure /home/git/.ssh/authorized_keys has a mode of 600 (-rw-------).

Also check the /etc/ssh/sshd_config file.

  • PubkeyAuthentication should be set to yes
  • There is also the AuthorizedKeysFile directive which determines the path where the authorized keys should be located. Ensure it's commented out or on the default of %h/.ssh/authorized_keys.
  • 1
    What do you do if you don't see a /var/log/auth.log file? Is there a way to turn this on? Oct 11, 2013 at 18:48
  • 1
    Logs might be in /var/log/secure if you don't have a /var/log/auth.log Jul 17, 2014 at 18:24
  • Silly mistake, I had scp-ed the .pub file to just inside the .ssh folder on the server that I wanted to connect to. Make sure to move it into the authorized_keys folder. Nov 16, 2014 at 16:19
  • I also had to remove group writing permissions from my home directory itself. Then I restarted ssh with sudo service ssh restart Oct 26, 2015 at 0:37

Also make sure your user home directory (in your case, /home/git) is only writable by you. I had this issue once because my home directory was group-writable. /var/log/auth.log said in it: "Authentication refused: bad ownership or modes for directory /home/chuck". (this is to make sure it doesn't use an authorized_keys file that someone other than you has been messing around with!)

  • While this is certainly helpful, I think this is more an addition to the answer of xeyes.
    – gertvdijk
    Jun 14, 2013 at 13:36
  • 1
    Oh my god, thanks a lot!. My eyes were burning because all the search i did on google. At last it worked!. Thank you so much.
    Aug 5, 2015 at 20:48
  • Man thanks! i spent hours searching for a solution... and this resolved all my problems.
    – Afaria
    Jun 21, 2016 at 18:37
  • yup. that was it. glad i decided to read the next answer down
    – Katushai
    Aug 21, 2016 at 7:44
  • Also check in /etc/passwd what is the home directory of the user. My bizarre problem was it hadn't a standard one
    – drodsou
    Jan 15, 2017 at 22:16

There are different ways to solve this: you can configure either sshd (server-side) or ssh (client-side) not to use password authentication. Disabling password authentication on the server makes your server more secure, but you will be in trouble if you loose your key.

To make ssh (client-side) using pubkey authentication, add some options to the ssh command:

ssh -o PubkeyAuthentication=yes -o PasswordAuthentication=no -X git@server

If this works, you can set the PasswordAuthentication=no option permanently in the ssh client config file /etc/ssh/ssh_config system-wide or ~/.ssh/config user-specific (on details, see man ssh_config).

  • 2
    By default all SSH client configuration (/etc/ssh/ssh_config) on Debian/Ubuntu systems already prefer PubkeyAuthentication and try that first as you will see when invoking ssh in verbose mode.
    – gertvdijk
    Jun 14, 2013 at 13:35

Are you using ~/.ssh/config on your local machine? I've run into this problem when I use the IdentityFile directive in the config file and point to the public key. For example:

Host Cloud
    Hostname cloud.theclouds.com
    User git
    IdentityFile ~/.ssh/config/mykey # This is correct

    # IdentityFile ~/.ssh/config/mykey.pub # This is incorrect

If you have multiple private keys, use the -v switch on your ssh connection command to check to see if your other primary keys are being uesd to try to connect. If they are not, tell the ssh client to use them with the following command:

ssh-add path/to/private/key

You can also add your key to the SSH Agent:

u@pc:~$ ssh-agent bash
u@pc:~$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/u/.ssh/id_rsa: # ENTER YOUR PASSWORD
Identity added: /home/u/.ssh/id_rsa (/home/u/.ssh/id_rsa)
  • 1
    This seems to be a necessary step when we are not using the default id_rsa key names.
    – Sbu
    Dec 31, 2020 at 9:17

If your home folder is encrypted then your authorized_keys file is not readable before login. You have to move it outside your home.

Here is explained and how to do: https://help.ubuntu.com/community/SSH/OpenSSH/Keys#Troubleshooting


Another thing to check for is whether there are extra carriage returns in your public key. I followed the advice above to review the /var/log/auth.log and saw an error when reading the key. The key was approximately two lines long instead of four. There were extra carriage returns embedded in the key.

When using the vi editor, use shift-j to join the lines and erase the extra space in the key string.

  • 1
    I triple checked permissions and sshd_config. Banged my head against the wall for a half hour. This was my mistake! Somehow, I've gotten into the habit of ending all files I hand edit with an extra linebreak. Even with one key and a carriage return at the end, it's enough to mess up authorization.
    – jrhorn424
    Sep 26, 2013 at 17:11
  • Make sure you have the -----END RSA PRIVATE KEY----- bit, too.
    – tobych
    Nov 21, 2013 at 22:07

I could the see following log message from /var/log/auth.log on remote server- userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedKeyTypes

That tells key of type ssh-rsa on my local system is not accepted by server. So changed server configuration by changing and appending value ssh-rsa to attribute/property PubkeyAcceptedKeyTypes in file /etc/ssh/sshd_config on my server and restarting sshd daemon

That resolved the issue



On Client side:

  • open configuration file /etc/ssh/ssh_config;
  • here look for PreferredAuthentications;
  • make sure password comes after publickey and not viceversa

In my case password was written before publickey, so ssh would prompt me for password even though I had copied my pub_key onto server.

This problem can be found out easily using verbose:

ssh -v compute@compute1 ... ... debug1: Authentications that can continue: publickey,password debug1: Next authentication method: password

As you can see password is chosen before trying to use publickey.

Edit /etc/ssh/ssh_config by moving password after publickey

PreferredAuthentications keyboard-interactive,publickey,password,hostbased,gssapi-with-mi

Now I can login without being prompt for pwd.


It could also be that you are calling

sudo git clone gituser@domain:repo.git

where the root users ssh key has not been added to the authorized_keys of gituser


On a machine running Ubuntu 18.04.02 LTS the suggestion to set permissions of ~/.ssh to 600 did not work for me. I had to set the permissions to 700, and then things worked fine.


I had my .ssh/ directory and authorized_keys file permissions correct but encountered this "prompt for password" issue due to a different, self-induced problem.

I had used a mouse-based highlight and copy/paste to copy the info from my local id_rsa.pub into the authorized_keys file on the server. This successfully copied the data in as a single line, but there where unwanted spaces at the end of the visible lines that were hard to see when editing the file with vi. Once I removed these unwanted spaces I could ssh in just fine.


So what happened for me is that I have 2 VMs to access from my local machine (2 keys id_rsa.pub and id_rsa2.pub). I realized that my ssh connection is using id_rsa.pub by default for any ssh [email protected] connection. I solved my issue by adding a config file and specify the identity to be used for every host like the following :

vi ~/.ssh/config

Add both hostnames and their identity file as follows:

Host server1.nixcraft.com
  IdentityFile ~/Users/.ssh/id_rsa1
Host server2.nixcraft.com
  IdentityFile /backup/home/aymen/.ssh/id_rsa2

There is one additional source of problems (again because of a wrong setting of file rights - this time the sshd deamon ):

ll /etc/ssh/ insgesamt 616 -rw-r----- 1 root root 3420 10. Dez 00:07 sshd_config

will cause this due to insufficient rights of this file . The error message delivered by sshd is (use systemctl status sshd):

sshd[4253]: gkr-pam: unable to locate daemon control file

just set the rights of the file to chmod 644 /etc/ssh/sshd_config

and everything is running fine again.

The whole sshd setup is very sensible to improper file rights.


Something that I could not find in these answers:

If you did not name your ssh-key file the standard way

(id_rsa, id_dsa, etc) it won't work unless you specified the change in a config. It makes sense of course, but this error does not show up in the /var/log/auth.log. I only managed to find the mistake by executing the following command with a -v flag to get more output:

ssh -v -o PubkeyAuthentication=yes -o PasswordAuthentication=no -X user@server

which gave me the following output: command output

Listing all files that it tried to access.

You must log in to answer this question.

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