19

I'm getting prompted for a password even though it looks like my SSH key is accepted. As far as I can tell, the line "Server accepts key: pkalg ssh-rsa blen 277" in the logs below mean my key is accepted.

Here are debug logs:

debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/sam/.ssh/id_rsa debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 277 debug2: input_userauth_pk_ok: fp <<HASH REDACTED>> debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Trying private key: /home/sam/.ssh/id_dsa debug1: Trying private key: /home/sam/.ssh/id_ecdsa debug2: we did not send a packet, disable method debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 1

Help much appreciated, everyone I've found who is having SSH problems fails at an earlier point that I'm seeing.

Improve this question

7 Answers 7

Reset to default
17

Your private key was most certainly not accepted, it was only attempted. There are a number of ways SSH key based authentication can fail, and the logging is not really that great so debugging this particular problem is one of my personal pet peeves. I've found that the error is usually a result of one of the following situations.

  • Your ~/.ssh/authorized_keys file is too open. For your own protection sshd attempts to protect you from yourself. If the permissions on your authorized keys file then it will fail the authentication. Run chmod -R go-rwx ~/.ssh.
  • Your public key in ~/.ssh/authorized_keys is malformed. This could be a result of any number of problems, but the most common is a copy paste issue. Some terminals, when copy/pasting across screens, will interpret a line wrap as a new line. Each entry in the authorized_keys file must be a single line. You can check this by changing the size of your terminal emulator and seeing if there's a break, comparing the output of wc -l ~/.ssh/authorized_keys against the number of keys that should be in there, or whatever works best for you. Just make sure each key is one line and you should be fine.
Improve this answer
1
  • 2
    For anyone coming here trying to understand where the 'access is too open' issue originates, I'm posting here because it took me quite a bit of searches to find it myself. This is enforced by the StrictModes setting in sshd_config. It's not recommended to disable, but it is helpful for troubleshooting. Commented Dec 31, 2021 at 16:53
8

The ssh -v output you pasted suggested that it tried to use the key but that didn't work, so it moved on to keyboard-interactive.

Have you checked the authentication log on the server you are connecting to? (eg, /var/log/auth.log). If your setup at the remote end is incorrect, eg wrong permissions, then ssh -v (or -vv or -vvv) won't tell you this, but it will be logged by sshd.

Improve this answer
2
  • 2
    /var/log/auth.log held the answer for me: "Authentication refused: bad ownership or modes for directory /root" Commented Feb 13, 2018 at 20:18
  • For anyone coming here trying to understand where the 'bad ownership or modes for directory' error comes from, I'm posting here because it took me quite a bit of searches to find it myself. This is enforced by the StrictModes setting in sshd_config. It's not recommended to disable, but it is helpful for troubleshooting. Commented Dec 31, 2021 at 16:53
6

In my case, file /var/log/authlog showed:

[ID 800047 auth.info] Authentication refused: bad ownership or modes for directory

I had checked correct ownership/permissions in .ssh but the $HOME had 777 permissions. Setting 755 permissions on $HOME allowed sftp to work. Thanks again.

Improve this answer
1
  • For anyone coming here trying to understand where the 'bad ownership or modes for directory' error comes from, I'm posting here because it took me quite a bit of searches to find it myself. This is enforced by the StrictModes setting in sshd_config. It's not recommended to disable, but it is helpful for troubleshooting. Commented Dec 31, 2021 at 16:53
2

If you have access to the server (directly or via another login), check the server logs in (say) /var/log/sshd or /var/log/secure depending on your system

It is typically caused by a permissions error on your ~/.ssh/authorized_keys file. Make sure it's not world readable, but crucially that it is readable by the user (sometimes a service user) running sshd

Improve this answer
1
  • 1
    Which system uses /var/log/sshd? Systems I know use either /var/log/auth.log or /var/log/secure. Commented Dec 12, 2018 at 10:33
1

Permissions of ~/.ssh/authorized_keys in remote is important (600 for my systems RHEL and Solaris)

Permissions of you home directory in remote is important (700 in my systems)

At the end run sshd in remote machine in debug mode on another port can be helpful:

sudo /usr/sbin/sshd -p 5555 -dd

5555 is an example port, you can change it. For more info in this regard you can see: http://ubuntuforums.org/archive/index.php/t-2219973.html

Improve this answer
0

I found that there is a problem if I use the sshd service. To avoid this problem, stop the sshd service with service sshd stop and then start the sshd daemon from the command prompt with sudo /usr/sbin/sshd.

Improve this answer
0

Try 

/sbin/restorecon -r /root/.ssh

A possible problem with setting permissions.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.