openssh unix dev - Oct 2024 - Security of ssh across a LAN, public key versus password

On 2024/10/21 12:02, David Lang via openssh-unix-dev
wrote:
> A cert is a single factor, so is a password. Cert authentication
> is only two factor if you trust that the password is not stored
> along with the cert (which is on the untrusted client)
You can tell sshd to require *both* password and public key.
> This is why I push for challenge/response tokens, not simply
> cert authentication, and really wish that FIDO (such as yubikey)
> was an option, but the discussions I've seen about suporting
> that have not been encouraging.
hmm? That works pretty well in OpenSSH.

Stuart Henderson wrote:
>> This is why I push for challenge/response tokens, not simply
>> cert authentication, and really wish that FIDO (such as yubikey)
>> was an option, but the discussions I've seen about suporting
>> that have not been encouraging.
>
> hmm? That works pretty well in OpenSSH.
hmm, what I'm finding doesn't seem to use the FIDO challenge/response to
the
server, instead it looks like a public/private key that's unlocked with a
touch,
possibly storing the private key on the hardware dongle (but it seems like 
there's still a key you need to put on the client system)

Quoting from the yubikey website:
OpenSSH version 8.2p1 added support for FIDO hardware authenticators. FIDO 
devices are supported by the public key types ?ecdsa-sk? and ?ed25519-sk",
along
with corresponding certificate types.

It then goes on to talk about generating the key with ssh-keygen

I could easily be missing something about this.

David Lang