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

bugzilla-daemon at mindrot.org bugzilla-daemon at mindrot.org
Wed Dec 7 08:12:50 AEDT 2022


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

--- Comment #9 from andy klier <andy.klier at zuar.com> ---
(In reply to Damien Miller from comment #7)
> 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.

we confirmed we can ssh to a server running `OpenSSH_8.2p1` thanks.

-- 
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.


More information about the openssh-bugs mailing list