47

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?

14 Answers 14

45

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.
| improve this answer | |
  • Thank's! I will try this options and come back later to feedback! – Luis Dalmolin Mar 7 '12 at 14:25
  • What do you do if you don't see a /var/log/auth.log file? Is there a way to turn this on? – Steve Robbins Oct 11 '13 at 18:48
  • 1
    Logs might be in /var/log/secure if you don't have a /var/log/auth.log – Gene Gotimer Jul 17 '14 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. – CenterOrbit Nov 16 '14 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 – Dylan Pierce Oct 26 '15 at 0:37
20

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!)

| improve this answer | |
  • While this is certainly helpful, I think this is more an addition to the answer of xeyes. – gertvdijk Jun 14 '13 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. – GTRONICK Aug 5 '15 at 20:48
  • Man thanks! i spent hours searching for a solution... and this resolved all my problems. – Afaria Jun 21 '16 at 18:37
  • yup. that was it. glad i decided to read the next answer down – Katushai Aug 21 '16 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 '17 at 22:16
5

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).

| improve this answer | |
  • 1
    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 '13 at 13:35
3

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
| improve this answer | |
2

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

| improve this answer | |
1

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.

| improve this answer | |
  • 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 '13 at 17:11
  • Make sure you have the -----END RSA PRIVATE KEY----- bit, too. – tobych Nov 21 '13 at 22:07
1

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
| improve this answer | |
1

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)
| improve this answer | |
1

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

| improve this answer | |
0

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

| improve this answer | |
0

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.

| improve this answer | |
0

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.

| improve this answer | |
0

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 user@xx.xx.xx.xx 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
| improve this answer | |
0

TL;DR

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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