[Bug 3506] Permission denied (publickey) with two -i identity files

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3506

--- Comment #7 from Damien Miller <djm at mindrot.org> ---
Here's an excerpt from an review email on that commit:

> This re-adds the agent signature type checking fallback, but also moves
> forward with the foreshadowed stricter signature type checking. sshd
> will check that the type of a pubkey signature is consistent with the
> key type advertised in the USERAUTH_REQUEST packet.
> 
> Because OpenSSH >= 7.6 were lax with this in some bases (legacy agents
> being one), I've put this stricter checking behind a compat flag and
> cranked the version number.
> 
> This also switches the various key algorithm knobs
> (PubkeyAcceptedKeyTypes, etc.) to check the pktype as is present in the
> userauth packet and not the type of the deserialised key blob as they
> currently do. The effect of this is to allow users to ban ssh-rsa if
> they want. More users have been asking to be able to do this to prevent
> the use of SHA-1 but still use RSA keys (via the rsa-sha2-* sigtypes).
> 
> This tweak to semantics has some possibility of breaking existing
> configurations, e.g. if they had "PubkeyAcceptedKeyTypes=ssh-rsa" in
> sshd_config. It might be able to fix this risk with some creative
> filtering of proposal strings.

So the bug that is being avoided (badly as far as certs are concerned)
is that <=7.6 would use an incorrect "public key algorithm name" field
in the SSH2_USERAUTH_REQUEST message
(https://www.rfc-editor.org/rfc/rfc4252#section-7) - it should actually
be the _signature_ algorithm being used and not the type of the public
key (this is arguably an error in the RFC)

Making this work for back-compat would require arranging for
sshconnect2.c:key_sig_algorithm() to return two strings: the actual
signing algorithm identifier as it does currently plus the algorithm
identifier to use in when the SSH2_AUTH_REQUEST is assembled in
sign_and_send_pubkey().

However. it's highly likely that additional compat problems would
remain. IIRC ssh-agent had problems wrt RSA/SHA2 signatures around then
too.

None of this helps you right now unfortunately. If you need something
sooner than someone getting motivated to fix this (which, honestly, may
never happen) than you options are 1) update the server to a version
>=7.8 or change to a different key type - ECDSA or ED25519 are fine
choices.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.