SSH login still asking for password - help

Linux and Unix-Like Ubuntu
1

trying to set up ssh password-less login with private key, something I have done many times before but on this occasion I keep being asked for the password despite transferring the key. Troubleshooting I have done

  1. checked permissions/ownership on the host .ssh directory and authorized_keys file set to 700 and 600 respectively.
:~/.ssh$ ls -l
total 4
-rw------- 1 sysadmin sysadmin 564 Jan 10 10:07 authorized_keys

:~$ ls -ld .ssh
drwx------ 2 sysadmin sysadmin 4096 Jan 10 09:33 .ssh
  1. checked the key is actually present in the authorized_keys file
  2. run sshd with debug
:~/.ssh$ sudo /usr/sbin/sshd -d -p 2222
[sudo] password for sysadmin:
debug1: sshd version OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: private host key: #3 type 4 ED25519
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: rexec_argv[2]='-p'
debug1: rexec_argv[3]='2222'
Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 2222 on 0.0.0.0.
Server listening on 0.0.0.0 port 2222.
debug1: Bind to port 2222 on ::.
Server listening on :: port 2222.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.100.112 port 53402 on 192.168.1.101 port 2222
debug1: Client protocol version 2.0; client software version OpenSSH_8.9p1 Ubuntu-3ubuntu0.10
debug1: match: OpenSSH_8.9p1 Ubuntu-3ubuntu0.10 pat OpenSSH* compat 0x04000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.13+esm2
debug1: permanently_set_uid: 103/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none [preauth]
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user sysadmin service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "sysadmin"
debug1: PAM: setting PAM_RHOST to "192.168.100.112"
debug1: PAM: setting PAM_TTY to "ssh"

Please can someone kindly point out what I am doing wrong here?

2

I have run into this type of problem on a number of occasions. Usually once every year or two.

Usually there are more details in the server's log as to why it's not honoring the key. Usually something like /var/log/authlog or /var/log/secure or /var/log/syslog has more details about why a key isn't accepted.

Frequently it's an ownership / permissions issue. The parent directories all the way up to root can also contribute in addition to just the key file and directory it's in. If you have the namei command on the platform your'e on, namei -l authorized_keys file makes it convenient to see permissions from the file all the way back to root.

I've also had situations where everything about the file is correct and the problem is that the server didn't support the cipher type being used.

Finally, take a look at the OpenSSH: Legacy Options page for more details on cipher / algorithm mismatch that may be causing you problems. Too new of a client compared to the server and too new of a server compared to the client.

3

Not sure what you are doing wrong since we cannot see what you are doing; but you might consider ensuring that the sshd_config file has the correct settings for key authentication, something like:

PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
4

I found the solution here:
https://confluence.atlassian.com/bitbucketserverkb/ssh-rsa-key-rejected-with-message-no-mutual-signature-algorithm-1026057701.html

5

In the first post, the log says key_parse_private2: missing begin marker - so the key seems to be malformed or not in the format that ssh want it to be.