0

I have a system where SSH-ing still asks for the password even though:

  1. My public key is correctly in the authorized_keys file on the remote server.
  2. My private key is stored as id_rsa in my .ssh directory.
  3. Permissions on the local client and remote server are correct. This includes the home directories, the .ssh directories, the authorized_keys file, and the key files themselves.
  4. SELinux is disabled on both client and server.

Additionally, /var/log/secure on the server reports the following error on each login attempt:

sshd[17110]: error: Could not get shadow information for <USER>

where I've replaced the actual username with the string <USER>.

What could be the cause of this and/or how do I get my SSH keys working?

3

The problem was that the public/private keys did not match on the client system. I fixed this by running:

$ cd ~/.ssh
$ ssh-keygen -y -f id_rsa > id_rsa.pub

This will generate the public key corresponding with the existing private key and write it to the id_rsa.pub file, thereby matching up the public/private keys again.

I could not find the answer to my problem in several of the Stack Exchange answers I found, so decided to ask/answer my own question here. How did this happen? What happened was that I had SSH keys working in the past, but at some point accidentally ran ssh-keygen again. This created a fresh pair of public/private keys. I realized this and tried to fix it by putting back my old private keys. As the server still had the old public key within the authorized_keys file, nothing needed to be changed there. Unfortunately, I did not change the public key on the client side leading to the current situation.

  • All this would have been impossible to guess given the information in the question... which again shows that really only the one in front of the computer can do proper debugging. BTW, you can use -v to put both ssh and sshd into verbose mode, that really helps in narrow down the cause. – dirkt Jun 11 at 8:25

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.