15

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.

SamStephens
  • 251
  • 1
  • 3
  • 7

7 Answers7

14

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.
Scott Pack
  • 14,717
  • 10
  • 51
  • 83
  • 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`](https://man.openbsd.org/sshd_config#StrictModes) setting in `sshd_config`. It's not recommended to disable, but it is helpful for troubleshooting. – Lockszmith Dec 31 '21 at 16:53
7

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.

Daniel Lawson
  • 5,426
  • 21
  • 27
  • 1
    /var/log/auth.log held the answer for me: "Authentication refused: bad ownership or modes for directory /root" – kevlar1818 Feb 13 '18 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`](https://man.openbsd.org/sshd_config#StrictModes) setting in `sshd_config`. It's not recommended to disable, but it is helpful for troubleshooting. – Lockszmith Dec 31 '21 at 16:53
5

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.

MadHatter
  • 78,442
  • 20
  • 178
  • 229
Robin AA
  • 51
  • 1
  • 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`](https://man.openbsd.org/sshd_config#StrictModes) setting in `sshd_config`. It's not recommended to disable, but it is helpful for troubleshooting. – Lockszmith Dec 31 '21 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

papanito
  • 381
  • 4
  • 19
Ash
  • 169
  • 1
  • 5
  • 1
    Which system uses `/var/log/sshd`? Systems I know use either `/var/log/auth.log` or `/var/log/secure`. – kasperd Dec 12 '18 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

dawud
  • 14,918
  • 3
  • 41
  • 61
sepehr hakimi
  • 11
  • 2
0

Try 

/sbin/restorecon -r /root/.ssh

A possible problem with setting permissions.

gxx
  • 5,483
  • 2
  • 21
  • 42
abkrim
  • 407
  • 6
  • 18
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.

Law29
  • 3,507
  • 1
  • 15
  • 28
Yoganand Bijapur
  • 1