"Server refused our key" Only from MobaXterm bookmark setup

Question

Have a very strange problem, cannot figure it out on my own.

Archlinux server with openssh 8.8p1-1 I'm not using password for authentication, only SSH-RSA keys. Public key is stored on server inside /home/stiw47/.ssh/authorized_keys .ssh directory permissions are 700 and authorized_keys file permissions are 600 Everything was worked flawlessly for years until few days ago when openssh on server was updated from 8.7p1-2 to 8.8p1-1 Everything is still working in all ssh/sftp clients except from MobaXterm.

Let me try to explain little better:

• If I try to connect from FileZilla (sftp) or from JuiceSSH on Android (ssh), everything is ok with same private key as always, as for all these years.
• If I try to connect manually from terminal on other Linux machine or from MobaXterm terminal, with manually I mean with command: ssh -i 'C:\Users\stiw4\Documents\keys\id_rsa' [email protected] - everything is ok again
• If I try to use bookmark in MobaXterm (I like bookmark), then I get "Server refused our key" message

MobaXterm Bookmarks area screenshot

I have to mention that same that bookmark, with same private key, worked normally before openssh package upgrade on server and also working now if I downgrade openssh on server back to 8.7p1-2 I already deleted MobaXterm known_hosts file on Windows machine, but nothing changed.

I tried to debug it with running following on server:

sudo `which sshd` -p 2020 -Dd

And connecting from bookmark on port 2020, this is the log, I'm not understanding it good:

[sudo] password for stiw47:
debug1: sshd version OpenSSH_8.8, OpenSSL 1.1.1l  24 Aug 2021
debug1: private host key #0: ssh-rsa SHA256:uMBMgYez8RvbToK8ZpuVIOT6Kt9DtjwvEEmObduXSaw
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:s/mpg8gbKeFRefGxYjuHYgXFkL8KrklpgivPk9veSXI
debug1: private host key #2: ssh-ed25519 SHA256:MopYaB4XAi8QBkE+RumfZl6IT3y17c3Mu85X+11+wRY
debug1: rexec_argv[0]='/usr/bin/sshd'
debug1: rexec_argv[1]='-p'
debug1: rexec_argv[2]='2020'
debug1: rexec_argv[3]='-Dd'
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 2020 on 0.0.0.0.
Server listening on 0.0.0.0 port 2020.
debug1: Bind to port 2020 on ::.
Server listening on :: port 2020.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: sshd version OpenSSH_8.8, OpenSSL 1.1.1l  24 Aug 2021
debug1: private host key #0: ssh-rsa SHA256:uMBMgYez8RvbToK8ZpuVIOT6Kt9DtjwvEEmObduXSaw
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:s/mpg8gbKeFRefGxYjuHYgXFkL8KrklpgivPk9veSXI
debug1: private host key #2: ssh-ed25519 SHA256:MopYaB4XAi8QBkE+RumfZl6IT3y17c3Mu85X+11+wRY
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.0.53 port 50385 on 192.168.0.21 port 2020 rdomain ""
debug1: Local version string SSH-2.0-OpenSSH_8.8
debug1: Remote protocol version 2.0, remote software version MoTTY_Release_0.73
debug1: compat_banner: no match: MoTTY_Release_0.73
debug1: permanently_set_uid: 65534/65534 [preauth]
debug1: list_hostkey_types: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256 [preauth]
debug1: kex: host key algorithm: ssh-ed25519 [preauth]
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compression: none [preauth]
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compression: none [preauth]
debug1: expecting SSH2_MSG_KEX_DH_GEX_REQUEST [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_INIT received [preauth]
debug1: rekey out after 4294967296 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: rekey in after 4294967296 blocks [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user stiw47 service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "stiw47"
debug1: PAM: setting PAM_RHOST to "192.168.0.53"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user stiw47 service ssh-connection method publickey [preauth]
debug1: attempt 1 failures 0 [preauth]
userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
Received disconnect from 192.168.0.53 port 50385:14: No supported authentication methods available [preauth]
Disconnected from authenticating user stiw47 192.168.0.53 port 50385 [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup
debug1: PAM: cleanup
debug1: Killing privsep child 64262

Very strange situation for me, do you have some ideas?

Thanks.

Answer 1

This is caused by OpenSSH 8.8 disabling RSA signatures using the SHA-1 hash algorithm:

This release disables RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for <USD$50K

(see OpenSSH 8.8 - Potentially-incompatible changes).

You can also see the corresponding message in your provided log:

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

The functionality of these old keys can be restored by adding PubkeyAcceptedKeyTypes +ssh-rsa to /etc/ssh/sshd_config and restarting sshd. This however should only be treated as a temporary solution to replace the keys with ones using more modern and secure algorithms like Ed25519 (see ArchWiki - SSH keys - Ed25519) due to the security implications.

It seems the reason why they key is working from the terminal is a more recent implementation of the SSH protocol (compared to the one used in MobaXterm) which automatically uses SHA-256/512 instead of SHA-1 with these old keys. I was not able to verify this, but according to OpenSSH 8.8 - Potentially-incompatible changes:

[...] existing ssh-rsa keys will automatically use the stronger algorithm where possible.