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

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

Hi David,
> 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.
Perhaps I'm misunderstanding the nature of your misunderstanding :)

I can say that I've been using certs backed by sk keys ever since OpenSSH
8.3 dropped, four years ago. Not only on my personal machines, but I also
implemented it in my previous job, both because I like doing it this way, and
because I wanted to show them a proof-of-concept.

I typically keep at least two yubikeys with separate sk keys on them. This
provides redundancy: I can retain access to any infrastructure so long as at
least one key is available. Each yubikey can also hold multiple sk keys, eg you
might want a different key per job.

You do need to export part of the private key onto the client node: `ssh-keygen
-K` covers this.

Then a typical workflow for me involves signing some other key which will be
used for certificate authentication:

```
ssh-keygen -s ~/.ssh/sk/work_ed25519_sk -I tim@<localhost> -n work -V
-5m:+8h ~/.ssh/certkeys/work_ed25519
```

That creates a cert which will be valid for eight hours. The remote servers are
configured to accept certs signed by my yubikey together with the principal name
of "work".

The benefit of this approach is the certificate is time-limited and backed by
2FA, but you can go ahead and use the certificate without demonstrating user
presence (i.e. touching yubikey) at every point in a chain of proxyjumps. It
provides what I consider to be a nice balance between security and convenience.

Cheers,

Tim

David Lang:
> hmm, what I'm finding doesn't seem to use the FIDO
challenge/response to the
> server,
It does.  That's why new key types (ECDSA-SK, ED25519-SK) were
required to accommodate the existing FIDO challenge/response format.
> 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)
In the U2F/FIDO WebAuthn model,
* on key generation
  . the private key is kept on the authenticator,
  . the public key and a key handle are sent to the remote server,
* and on key use
  . the remote server sends a challenge and includes the key handle,
  . the authenticator generates a response.

With OpenSSH,
* on key generation
  . the FIDO private key is kept on the authenticator,
  . the FIDO public key becomes the SSH public key,
  . the FIDO key handle makes up the SSH private key,
* and on key use
  . the remote server sends a FIDO challenge, and the SSH client
    supplies the FIDO key handle to the authenticator,
  . the authenticator generates a FIDO response which the SSH client
    forwards to the remote server.

The only principal difference is the disposition of the FIDO key handle.

-- 
Christian "naddy" Weisgerber                          naddy at
mips.inka.de