Bug#933665: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedKeyTypes

[Gerald Turner]

Package: openssh-server
Version: 1:7.9p1-10
Severity: normal

Dear Maintainer,

I've been running several servers, upgraded across many Debian stable
releases, with sshd_config that had been tightened down in various ways
(example attached) including explicit PubkeyAcceptedKeyTypes (containing
ssh-rsa). After upgrading to buster a user reported that he could no
longer login with his RSA key.

sshd[17025]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedKeyTypes [preauth]

I tested and found that explicitly defining PubkeyAcceptedKeyTypes in
sshd_config breaks RSA pubkey auth, even when the line merely states:

PubkeyAcceptedKeyTypes ssh-rsa

However when PubkeyAcceptedKeyTypes is removed from the config, the
implicit defaults allow RSA to work.

I've attached sshd debug logs for the two scenarios.

My guess is there's some sort of config parsing glitch within ssh.

-- System Information:
Debian Release: 10.0
APT prefers stable
APT policy: (601, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-cloud-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openssh-server depends on:
ii adduser 3.118
ii debconf [debconf-2.0] 1.5.71
ii dpkg 1.19.7
ii libaudit1 1:2.8.4-3
ii libc6 2.28-10
ii libcom-err2 1.44.5-1
ii libgssapi-krb5-2 1.17-3
ii libkrb5-3 1.17-3
ii libpam-modules 1.3.1-5
ii libpam-runtime 1.3.1-5
ii libpam0g 1.3.1-5
ii libselinux1 2.8-1+b1
ii libssl1.1 1.1.1c-1
ii libsystemd0 241-5
ii libwrap0 7.6.q-28
ii lsb-base 10.2019051400
ii openssh-client 1:7.9p1-10
ii openssh-sftp-server 1:7.9p1-10
ii procps 2:3.3.15-2
ii ucf 3.0038+nmu1
ii zlib1g 1:1.2.11.dfsg-1

Versions of packages openssh-server recommends:
ii libpam-systemd 241-5
ii ncurses-term 6.1+20181013-2
ii xauth 1:1.0.10-1

Versions of packages openssh-server suggests:
pn molly-guard <none>
pn monkeysphere <none>
pn rssh <none>
pn ssh-askpass <none>
pn ufw <none>

-- debconf information:
openssh-server/permit-root-login: true
* ssh/use_old_init_script: true
ssh/encrypted_host_key_but_no_keygen:
ssh/disable_cr_auth: false
ssh/vulnerable_host_keys:
openssh-server/password-authentication: true

[Colin Watson]

Post by Gerald Turner
I've been running several servers, upgraded across many Debian stable
releases, with sshd_config that had been tightened down in various ways
(example attached) including explicit PubkeyAcceptedKeyTypes (containing
ssh-rsa). After upgrading to buster a user reported that he could no
longer login with his RSA key.
sshd[17025]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedKeyTypes [preauth]
I tested and found that explicitly defining PubkeyAcceptedKeyTypes in
PubkeyAcceptedKeyTypes ssh-rsa

This is the scenario explained in the entry in
/usr/share/doc/openssh-server/NEWS.Debian.gz for version 1:7.8p1-1,
which was reproduced from upstream's release notes for OpenSSH 7.8:

* sshd(8): The semantics of PubkeyAcceptedKeyTypes and the similar
HostbasedAcceptedKeyTypes options have changed. These now specify
signature algorithms that are accepted for their respective
authentication mechanism, where previously they specified accepted key
types. This distinction matters when using the RSA/SHA2 signature
algorithms "rsa-sha2-256", "rsa-sha2-512" and their certificate
counterparts. Configurations that override these options but omit
these algorithm names may cause unexpected authentication failures (no
action is required for configurations that accept the default for these
options).

I regret the inconvenience of the change, but given that it seems to
have been a deliberate change upstream (mentioned in their release
notes), I think it would be best to adapt to it.

The debug output you quote is indeed a bit misleading (I think I'll take
that up with upstream), but there's a clue hiding in the successful
debug output:

sshd[20199]: debug1: userauth_pubkey: test pkalg rsa-sha2-512 pkblob RSA SHA256:cN6+RJMBj25zximZ28B/CanFpjupWf/ABGrRGprS1LU [preauth]

Note that the default for PubkeyAcceptedKeyTypes now ends with
"rsa-sha2-512,rsa-sha2-256,ssh-rsa" rather than just "ssh-rsa".
Therefore, things should work again if you set "PubkeyAcceptedKeyTypes
rsa-sha2-512,rsa-sha2-256,ssh-rsa". Let me know if that works?

[Gerald Turner]

Post by Colin Watson
This is the scenario explained in the entry in
/usr/share/doc/openssh-server/NEWS.Debian.gz for version 1:7.8p1-1,
* sshd(8): The semantics of PubkeyAcceptedKeyTypes and the similar
HostbasedAcceptedKeyTypes options have changed. These now
specify signature algorithms that are accepted for their
respective authentication mechanism, where previously they
specified accepted key types. This distinction matters when
using the RSA/SHA2 signature algorithms "rsa-sha2-256",
"rsa-sha2-512" and their certificate counterparts.
Configurations that override these options but omit these
algorithm names may cause unexpected authentication failures (no
action is required for configurations that accept the default for
these options).

Oh shame on me - I thought I read the NEWS items (with apt-listchanges
helpfully emailing them to me), but not carefully enough. Sorry for the
bogus bug report.

Long ago (during stretch) I adopted the OpenSSH certifcate/CA model:

PubkeyAcceptedKeyTypes ssh-ed25519-cert-***@openssh.com

...which I believe is SHA-256, yet the configuration was unaffected by
the change in 7.8, otherwise I would've noticed a long while back on
personal workstations running Debian testing.

Post by Colin Watson
I regret the inconvenience of the change, but given that it seems to
have been a deliberate change upstream (mentioned in their release
notes), I think it would be best to adapt to it.
The debug output you quote is indeed a bit misleading (I think I'll
take that up with upstream), but there's a clue hiding in the
sshd[20199]: debug1: userauth_pubkey: test pkalg rsa-sha2-512 pkblob RSA SHA256:cN6+RJMBj25zximZ28B/CanFpjupWf/ABGrRGprS1LU [preauth]
Note that the default for PubkeyAcceptedKeyTypes now ends with
"rsa-sha2-512,rsa-sha2-256,ssh-rsa" rather than just "ssh-rsa".
Therefore, things should work again if you set "PubkeyAcceptedKeyTypes
rsa-sha2-512,rsa-sha2-256,ssh-rsa". Let me know if that works?

Yep it makes sense.

BTW, if you take the debug output up with upstream, maybe also consider
that there's no "ssh -Q key" or similar command that'll reveal the
values that can be supplied to PubkeyAcceptedKeyTypes.

$ ssh -Q key
ssh-ed25519
ssh-ed25519-cert-***@openssh.com
ssh-rsa
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-rsa-cert-***@openssh.com
ssh-dss-cert-***@openssh.com
ecdsa-sha2-nistp256-cert-***@openssh.com
ecdsa-sha2-nistp384-cert-***@openssh.com
ecdsa-sha2-nistp521-cert-***@openssh.com

...that's one of the first things I checked when dealing with the issue.

Thanks for the clarification!