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. The commands required:

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

(Depending on your Linux distribution, first / last line might be systemctl stop sshd.service / systemctl start sshd.service instead.)

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

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 5

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 6

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 7

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 8

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 9

It would be SSH misconfiguration at server end. Server side sshd_config file has to be edited, it is located in /etc/ssh/sshd_config.

In that file, change variables

• yes to no for ChallengeResponseAuthentication, PasswordAuthentication, UsePAM

• no to yes for PubkeyAuthentication

(Link to original source is now pointing to spam and was removed).

Answer 10

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 11

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 12

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 13

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 14

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

Server commands:

rm -rf ~/.ssh

Local commands:

ssh-copy-id [email protected]        # where <user> is your username and <192.168.1.1> is the server IP

Answer 15

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 16

At server:

$ ls -lh /home
$ sudo chmod 700 /home/$USER

It was directory permission issue. It was 777 at server, so I changed it back to 700. This fixed my issue with ssh password less login failure even after copying $USER/.ssh/id_rsa.pub to server $USER/.ssh/authorized_keys.

Answer 17

If both the private key and the username/password authentication methods are accepted by the server, and then if the private key fails, it will simply fall back to prompting for a username/password without displaying any error.

You can use the -vvv flag to determine if a private key was even attempted, (and which keys specifically), and why the key(s) are failing. Example: ssh -T -vvv myHost.com. Alternatively, you can use LogLevel DEBUG3 in ~/.ssh/config.

A common failure is that the server rejects the key. In that case, you will see something like this:

debug1: Next authentication method: publickey
debug1: Trying private key: /c/Users/myUsername/.ssh/id_rsa
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
[email protected]'s password:

According to the official spec for the SSH protocol (RFC 4252), the authentication packets have the following values:

SSH_MSG_USERAUTH_REQUEST    50
SSH_MSG_USERAUTH_FAILURE    51
SSH_MSG_USERAUTH_SUCCESS    52

This means that debug3: receive packet: type 51 indicates that the server rejected the key.

Answer 18

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 19

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 20

I was having the exact same problem with PuTTY connecting to an Ubuntu 16.04 machine. It was puzzling because PuTTY's pscp program was working fine with the same key (and the same key worked in PuTTY to connect to another host).

Thanks to the valuable comment from @UtahJarhead, I checked my /var/log/auth.log file and found the following:

sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

It turns out that newer versions of OpenSSH don't accept DSA keys by default. Once I switched from a DSA to an RSA key, it worked fine.

Another approach: this question discusses how to configure the SSH server to accept DSA keys: https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication?lq=1

Answer 21

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 22

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 23

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 24

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 25

Yet another option is a variant of @Jagadish 's answer: to strace the ssh daemon.

It has the significant advantage, that we don't need to stop the sshd, what can result a complete lockout if something goes badly.

First, we find the pid of the main sshd process. Here we can see it by executing a pstree -pa|less.

  |-sshd,633 -D  <-- THIS IS WHAT WE WANT!
  |   `-sshd,21973   
  |       `-sshd,21996    
  |           `-bash,22000
  |               `-screen,638 -r

After knowing, that the pid is 633, we can strace it, following its children:

strace -p 633 -s 4096 -f -o sux

The result will be that everything what this sshd, and its child processes have done, will be strace-ed into the file named sux in the local directory.

Then reproduce the problem.

It will have a massive list of kernel call log, which is mostly incomprehensible/irrelevant for us, but not everywhere. In my case, the important thing was this:

6834  sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84

It was meants, that the sshd tried to log the message User cica not allowed because account is locked - it only couldn't, because logging is not enough verbose for that. But we already know, the pubkey was rejected because the account was locked.

It is not yet a solution - now we need to google, what means a "locked account" in the case of the sshd. It will be most likely some trivial /etc/passwd, /etc/shadow wizardry, but the important thing is done - the problem isn't a mysterious, but an easily debuggable/googlable one.

Answer 26

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, specifically this version:

OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 Mar 2016

Answer 27

In my case I had all permissions right and even when running ssh with -vvv flag I couldn't figure out what was the problem.

So I generated new certificate on remote host

ssh-keygen -t rsa -C "[email protected]"

and copied generated keys to local machine and added new public key to ~/.ssh/authorized_keys on remote host

cat id_rsa.pub >> authorized_keys

Using generated keys from remote host machine connection now works. So if other solutions fail this is another thing to try.

Answer 28

I had the same problem when connecting from Raspbian8 to Fedora34.

The debug error I received was:

userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

The solution was to append ssh-rsa to the value of PubkeyAcceptedAlgorithms in

/etc/crypto-policies/back-ends/opensshserver.config

and restart the service

thanks to Dave @ https://wiki.xdroop.com/space/Fedora/34/SSH+Pubkey+doesn%27t+work for this solution

Answer 29

I tried to log into a colleague's account without password, by pasting id_rsa.pub into her authorized_keys file. I got the permissions of all relevant files right, but still couldn't succeed with password-less login.

It turns out since I created the authorized_keys file with root permission, I had to chown and chgrp to the ones that match her profile.

sudo chown ${username} -R /home/${username}/.ssh
sudo chgrp ${groupname} -R /home/${groupname}/.ssh

It was easy to spot this mistake when you use the triple verbose mode ssh -vvv.

Answer 30

In my case, id_rsa authentication appears to be deprecated and is not utilized by default in SSH. Switching to ed25519 resolved my problem.

ssh-keygen -t ed25519

ssh-copy-id -i ~/.ssh/id_ed25519 username@remote