Why am I still getting a password prompt with ssh with public key authentication?

Question

I'm working from the URL I found here:

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

My ssh client is Ubuntu 64 bit 11.10 desktop and my server is Centos 6.2 64 bit. I have followed the directions. I still get a password prompt on ssh.

I'm not sure what to do next.

Answer 1

Make sure the permissions on the ~/.ssh directory and its contents are proper. When I first set up my ssh key auth, I didn't have the ~/.ssh folder properly set up, and it yelled at me.

• Your home directory ~, your ~/.ssh directory and the ~/.ssh/authorized_keys file on the remote machine must be writable only by you: rwx------ and rwxr-xr-x are fine, but rwxrwx--- is no good¹, even if you are the only user in your group (if you prefer numeric modes: 700 or 755, not 775).
  If ~/.ssh or authorized_keys is a symbolic link, the canonical path (with symbolic links expanded) is checked.
• Your ~/.ssh/authorized_keys file (on the remote machine) must be readable (at least 400), but you'll need it to be also writable (600) if you will add any more keys to it.
• Your private key file (on the local machine) must be readable and writable only by you: rw-------, i.e. 600.
• Also, if SELinux is set to enforcing, you may need to run restorecon -R -v ~/.ssh (see e.g. Ubuntu bug 965663 and Debian bug report #658675; this is patched in CentOS 6).

¹ _{Except on some distributions (Debian and derivatives) which have patched the code to allow group writability if you are the only user in your group.}

Answer 2

If you have root access to the server, the easy way to solve such problems is to run sshd in debug mode, by issuing something like /usr/sbin/sshd -d -p 2222 on the server (full path to sshd executable required, which sshd can help) and then connecting from the client with ssh -p 2222 user@host. This will force the SSH daemon to stay in the foreground and display debug information about every connection. Look for something like

debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/

If it isn't possible to use an alternative port, you can temporarily stop the SSH daemon and replace it with one in debug mode. Stopping the SSH daemon does not kill existing connections so it is possible to do this through a remote terminal, but somewhat risky - if the connection does get broken somehow at a time when the debug replacement is not running, you are locked out of the machine until you can restart it somehow. The commands required:

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

Answer 3

Is your home dir encrypted? If so, for your first ssh session you will have to provide a password. The second ssh session to the same server is working with auth key. If this is the case, you could move your authorized_keys to an unencrypted dir and change the path in ~/.ssh/config.

What I ended up doing was create a /etc/ssh/username folder, owned by username, with the correct permissions, and placed the authorized_keys file in there. Then changed the AuthorizedKeysFile directive in /etc/ssh/config to :

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

This allows multiple users to have this ssh access without compromising permissions.

Answer 4

After copying keys to the remote machine and putting them inside the authorized_keys you've got to do something like this:

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa

Answer 5

I faced challenges when the home directory on the remote does not have correct privileges. In my case the user changed the home dir to 777 for some local access with in the team. The machine could not connect with ssh keys any longer. I changed the permission to 744 and it started to work again.

Answer 6

Just try these following commands

1. ssh-keygen

   Press Enter key till you get the prompt

2. ssh-copy-id -i root@ip_address

   (It will once ask for the password of the host system)

3. ssh root@ip_address

   Now you should be able to login without any password

Answer 7

SELinux on RedHat/CentOS 6 has an issue with pubkey authentication, probably when some of the files are created selinux is not setting its ACLs correctly.

To manually fix the SElinux ACLs for the root user:

restorecon -R -v /root/.ssh

Answer 8

We ran into the same problem and we followed the steps in the answer. But it still did not work for us. Our problem was that login worked from one client but not from another (the .ssh directory was NFS mounted and both clients were using the same keys).

So we had to go one step further. By running the ssh command in verbose mode you get a lot of information.

ssh -vv user@host

What we discovered was that the default key (id_rsa) was not accepted and instead the ssh client offered a key matching the client hostname:

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277                  

Obviously this will not work from any other client.

So the solution in our case was to switch the default rsa key to the one that contained user@myclient. When a key is default, there is no checking for client name.

Then we ran into another problem, after the switch. Apparently the keys are cached in the local ssh agent and we got the following error on the debug log:

'Agent admitted failure to sign using the key'

This was solved by reloading the keys to the ssh agent:

ssh-add

Answer 9

It would be SSH miss configuration at server end. Server side sshd_config file has to be edited. Located in /etc/ssh/sshd_config. In that file, change variables

• 'yes' to 'no' for ChallengeResponseAuthentication, PasswordAuthentication, UsePAM

• 'no' to 'yes' for PubkeyAuthentication

Based on http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/

Answer 10

Two comments: this will overwrite the original file. I'd just copy the public key generated and do something like:

cat your_public_key.pub >> .ssh/authorized_keys

This will append the key you want to use to the pre-existing list of keys. Also, some systems use the file authorized_keys2, so it's a good idea to make a hard link pointing between authorized_keys and authorized_keys2, just in case.

Answer 11

In /etc/selinux/config file changing SELINUX to disabled from enforcing made passwordless ssh work successfully.

Earlier I am able to do it on one way. Now from bothways I am able to do passwordless ssh.

Answer 12

My solution was that the account was locked. Message found in /var/log/secure: User not allowed because account is locked Solution: give the user a new password.

Answer 13

I ran into a similar problem and followed the steps using the debug mode.

/usr/sbin/sshd -d

This showed the following result

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 135.250.24.32 port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic

It was really confusing

[root@sys-135 ~]# ls -l /
drwxrwxrwx.   2 root root     4096 Dec 14 20:05 bin
drwxrwxrwx.   5 root root     1024 May  6  2014 boot
drwxrwxrwx.   2 root root     4096 Dec  2  2013 cgroup
drwxrwxrwx.  10 root root     1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root    12288 Dec 16 10:26 etc
drwxrwxrwx.  11 root root     4096 Jan 14  2014 lib
drwxrwxrwx.   9 root root    12288 Dec 14 20:05 lib64
drwxrwxrwx.   2 root root    16384 Jan 10  2014 lost+found
drwxrwxrwx.   2 root root     4096 Jun 28  2011 media
drwxr-xr-x.   2 root root        0 Dec 10 14:35 misc
drwxrwxrwx.   2 root root     4096 Jun 28  2011 mnt
drwxrwxrwx.   4 root root     4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root        0 Dec 10 14:35 proc
drwxrwxrwx.  45 root root     4096 Dec 16 10:26 root

It showed the root directory had permissions for every one. We changed it so that others would not have permissions.

[root@sys-135 ~]# chmod 750 /root

The key authentication started working.

Answer 14

Ensure that AuthorizedKeysFile points to the right location, use %u as a placeholder for username:

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

It may be that you just need to uncomment the line:

AuthorizedKeysFile .ssh/authorized_keys

Mind that you must reload ssh service for the changes to take place:

service sshd reload

Answer 15

These steps should help you out. I use this regularly among many 64bit Ubuntu 10.04 machines.

[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'

you could put this in a script with some prompts and invoke it as

script_name username remote_machine

Answer 16

I had similar problem with ssh. In my case the problem was that I installed hadoop cloudera (from rpm on centos 6) and it created user hdfs with home directory

/var/lib/hadoop-hdfs (not standard /home/hdfs).

I changed in /etc/passwd /var/lib/hadoop-hdfs to /home/hdfs, moved home directory to new location and now I can connect with public key authentication.

Answer 17

One thing that I had wrong was the ownership on my home directory on the server system. The server system was set to default:default so I:

chown -R root:root /root

And it worked. Another Cheap workaround is to Disable StrictModes: StirctModes no. in sshd_config. This will at least tell you if the key exchange and connection protocols are good. Then you can go hunt the bad permissions.

Answer 18

For me, the solution was opposite Wojtek Rzepala's: I didn't notice I was still using authorized_keys2, which has been deprecated. My ssh setup stopped working at some point, presumably when the server was updated. Renaming .ssh/authorized_keys2 as .ssh/authorized_keys fixed the problem.

D'oh!

Answer 19

I just had this same problem, and for me the solution was to set UsePAM to no. See, even with PasswordAuthentication set to no, you'll still get keyboard-interactive, and in my case my local ssh program kept defaulting to that, for some reason.

Extra background to help anyone with the same situation: I'm connecting from a host running Dropbear to one running OpenSSH. With PasswordAuthentication and UsePAM both set no on the remote machine, I'll get the following message if I enter ssh user@server:

ssh: Connection to user@server:22 exited: Disconnect received

Providing the identity file with -i, everything works as expected.

There may be a little more information here.

Answer 20

After checking the permissions, and trying several other solutions listed here, I finally removed the ssh directory on the server, the setup my public key again.

Server commands:

# rm -rf ~/.ssh

Local commands:

# ssh-copy-id user@192.168.1.1        # where <user> is your username and <192.168.1.1> is the server IP

Answer 21

In the past I came across some tutorials that describe how to achieve a ssh password-less setup, but some are sadly wrong.
Let's start over again, and check every step:

1. FROM CLIENT - Generate key: ssh-keygen -t rsa
   Public and private key (id_rsa.pub and id_rsa) will be automatically stored in the ~/.ssh/ directory.
   Setup will be easier if you use an empty passphrase. If you are not willing to do that, then still follow this guide, but also check the bullet point below.
   
   
2. FROM CLIENT - Copy public key to server : ssh-copy-id user@server
   Client public key will be copied to server's location ~/.ssh/authorized_keys.
   
   
3. FROM CLIENT - Connect to server: ssh user@server
   
   

Now, if it's still not working after the described 3 steps, lets try the following:

• Check ~/ssh folder permissions in client and server machine.
• Check /etc/ssh/sshd_config in the server to ensure that RSAAuthentication, PubkeyAuthentication and UsePAM options aren't disabled, they can be enabled by default with yes.
• If you entered a passphrase while generating your client key, then you may try ssh-agent & ssh-add to achieve password-less connections in your session.
• Check the contents of /var/log/auth.log on the server to find the issue why key authentication is skipped at all.

Answer 22

My scenario was that I have a NAS server on which I created a backupbot user, after the creation of my primary account, which was able to log in to initially create the backupbot user. After fiddling with sudo vim /etc/ssh/sshd_config, and creating the backupbot user, vim can create, at least on Ubuntu 16.04, and based on your ~/.vimrc config, a swap file left from your vim session's editing of /etc/ssh/sshd_config

Check to see if: /etc/ssh/.sshd_config.swp exists, and if it does remove it and restart the sshd daemon:

sudo rm /etc/ssh/.sshd_config.swp sudo service sshd restart

This magically resolved my issue. I had previously checked all my permissions and even the RSA fingerprints of the public and private keys. This is strange and probably a bug with sshd OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 Mar 2016