SSHamble pubkey-hunt defense?

[Catalin Patulea]

My original post bounced, re-posting to the list; please note both my
original message and HD's response below.

On Sun, May 3, 2026 at 6:26 PM HD Moore <hdm at runzero.com> wrote:
>
> Hi Catalin.
>
> I can't speak for the OpenSSH team, but had a couple thoughts on this topic:
>
> 1. Moving to SSH certificates may mitigate this without requiring code changes to any clients/servers.
>
> 2. It would help if the pub key check sent proof of ownership of the private key (even a signed challenge of something basic/reusable like the date in UTC). There's probably a million reasons why this a bad idea, but definitely interested in what the team has to say about it.
>
> -HD
>
> > On May 3, 2026, at 8:17 PM, Catalin Patulea <cronos586 at gmail.com> wrote:
> >
> > Hi,
> >
> > I recently watched the SSHamble talk
> > (https://www.youtube.com/watch?v=G7GwXu684JY) which describes a
> > technique to discover associations between people and SSH servers by
> > probing for their public key. Only the public key (as available on eg.
> > GitHub) is needed, not the private key.
> >
> > This is because of a bit of logic in auth2-pubkey.c and anticipated by
> > the original author:
> >  /* XXX fake reply and always send PK_OK ? */
> >  /*
> >   * XXX this allows testing whether a user is allowed
> >   * to login: if you happen to have a valid pubkey this
> >   * message is sent. the message is NEVER sent at all
> >   * if a user is not allowed to login. is this an
> >   * issue? -markus
> >   */
> >
> > The information above is HD Moore's work, I'm just paraphrasing from
> > the video. The "attack" is implemented in SSHamble check_pubkey.go as
> > "pubkey-hunt": https://github.com/runZeroInc/sshamble/blob/main/cmd/check_pubkey.go
> > (another blog post on this: https://rushter.com/blog/public-ssh-keys/)
> >
> > I thought, would always sending PK_OK break anything in practice? I
> > wrote a small proof of concept patch:
> > https://github.com/cpatulea/openssh-portable/commit/581111bc1c1b088b569e798936bba50a7e883f0d,
> > patched it on top of Debian 13 openssh-server 10.2p1 and connected
> > from another terminal with two keys: key1 which is not in
> > authorized_keys, and key2 which is. The client connected successfully:
> >
> > debug1: Will attempt key: id ED25519 SHA256:<key1> explicit
> > debug1: Will attempt key: <key2> RSA SHA256:<key2> explicit
> > debug1: Offering public key: id ED25519 SHA256:<key1> explicit
> > debug1: Authentications that can continue: publickey
> > debug1: Offering public key: <key2> RSA SHA256:<key2> explicit
> > debug1: Server accepts key: <key2> RSA SHA256:<key2> explicit
> > Authenticated to localhost ([::1]:2222) using "publickey".
> >
> > I think this closes the information leak, because the server no longer
> > reveals any information about which keys are in authorized_keys.
> >
> > I guess this is a very superficial test. And I have no experience with
> > the OpenSSH codebase. To OpenSSH experts: is this kind of change
> > actually feasible or there's some side-effect with something else
> > which might make this more tricky?
> >
> > Thanks,
> > Catalin
>