mkj/dropbear

Feature request: Certificate-based SSH logins

Opened this issue · 1 comments

gboor commented

Hello all!

We have quite a fleet of field devices to manage and handle SSH authentication with certificate-based logins, issuing certificates with a short lifetime for maintenance sessions.
A not insignificant part of our fleet consists of Teltonika devices, which all run dropbear as the SSH server. We can't apply this strategy with those and still need to maintain public keys for dozens of users across dozens of devices.

Would it be possible to add certificate-based authentication to dropbear? I can contribute here as well if needed, if someone can point me in the right direction (i.e.; where would this go in the source? Is svr-authpubkey.c a good place to start?).

mkj commented

Yes svr-authpubkey.c would be a start. Here are some quick thoughts on what would be required (only looking at server/auth signature verify support for now):

  • Add new signkey_names entries in signkey.c and enums for signkey_type and signature_type for "ssh-ed25519-cert-v01@openssh.com" and the other types. Most of them have the same signkey/signature, but RSA will have rsa-sha2-256-cert-v01@openssh.com as the signature name (similarly to the existing DROPBEAR_SIGNATURE_RSA_SHA256).
  • Each of the certificate types will need a new buf_rsa_cert_verify() etc function. Those would be in rsa.c etc. It would extract the public key from the encoded certificate, and then pass that to the underlying buf_rsa_verify, as well as verifying the certificate's signature against the signature key.
  • When handling certificate keys, checkpubkey_line() needs to instead look for cert‐authority entries in authorized_keys, and compare the authorized_keys entry with the encoded certificate key's signature key.
  • Options encoded in a certificate key should somehow get passed (and override) those in svr-authpubkeyoptions.c. This is mandatory at least for critical options, and probably worth doing for all the extensions.
  • valid principals needs to be checked against the user logging in. OpenSSH's spec is a bit lacking, my first guess is those are comma separated (though is , a valid in a username? who knows!).
  • Date validity before/after needs checking, and hopefully all those routers are running NTP! Maybe that could go in buf_rsa_cert_verify(), or perhaps alongside the principals check, I'm not sure.

Specs from https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL.certkeys?rev=HEAD