Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

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 I did wrong?

share|improve this question
    
Where do you put ypur public? in user git or in root? how do you acces it? as ssh <you>@<server> o <git>@<server> or root@<server>.. check that and add more info. –  maniat1k Mar 7 '12 at 12:42

9 Answers 9

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

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

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.
share|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
    
Logs might be in /var/log/secure if you don't have a /var/log/auth.log –  CoverosGene Jul 17 at 18:24

You have to lock the user with passwd -l username , this will change /etc/shadow file by inserting a ! before the encrypted password. To unlock use passwd -u username.

share|improve this answer
1  
No, you don't... –  psusi May 23 '13 at 1:45

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.

share|improve this answer
    
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. –  Toby Champion Nov 21 '13 at 22:07

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

share|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
    
This was my problem. Thanks! –  Rob Fisher Mar 24 at 17:45

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

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

share|improve this answer

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

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

Your Answer

 
discard

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.