5 ms·

Am author. Yea Kerberos is another option. If you have all the necessary pieces, that is... you’d need managed devices, an LDAP/AD setup, DNSSEC & SSHFP, PAM &

Am author. Yea Kerberos is another option. If you have all the necessary pieces, that is... you’d need managed devices, an LDAP/AD setup, DNSSEC & SSHFP, PAM & various agents on servers. Certificates offer all the same benefits, and a few more, with less work & fewer moving pieces. They’re also more flexible since you can control the auth flow to get a cert.

gnufx 7y ago
So, you're not doing it wrong if you have Kerberos providing actual SSO (for "all" services) since before certificate authN was available. You need GSSAPI anyhow if you have Kerberized home directories and not typing passwords at ssh. Although you're likely to have LDAP (in which you can store public keys), all you need is the KDC and a simple Kerberos setup on ssh clients and servers. I wonder why anyone thinks you need more. Kerberos tickets and infrastructure are roughly equivalent to using ephemeral certificates as far as I can see. The one reason you might want certificates is if you require FIDO MFA, as I don't know if you can use anything other than OTP with Kerberos implementations. (The hook for "the auth flow" is preauth.)
AndyMcConachie 7y ago
What do SSH X.509 certs provide that DNSSEC and SSHFP RRs don't? SSH X.509 certs reminds of MTA-STS for SMTP, a shoe horning of the broken web PKI into another protocol that doesn't need it. Also, I'm not convinced that TOFU for SSH is really all that terrible. Maybe it's just my use case and my situation, but I SSH to the same servers over and over again. And if I need to give access to someone new I give them the public key first. SSH X.509 looks like a complex solution to a not very big problem that can be more easily solved with DNSSEC and SSHFP.
- tptacek 7y ago
  What do SSH x.509 certs do that DNSSEC doesn't? Sure, I'll bite: * They put authentication to your SSH servers entirely under your own control, without escrowing keys to the operators of the TLDs. * They're deployable independently, without enrolling all of the rest of your infrastructure into DNSSEC and all its unreliability and complexity. * They integrate with IDPs, so that users can get short-duration authenticators based on MFA logins, without storing long-lived secrets on their machines. SSH X.509 certificates have nothing to do with the web PKI, other than that they use the same encoding. Engineering orgs that use SSH CAs run their own CAs. That's the point. Happy to have helped!
  - gnufx 7y ago
    I'd expect a policy dictating using ephemeral certificates like Kerberos keys would actually have them for web services too, not just ssh (as with Globus).
rb12345 7y ago
You can pretty much get away with just a Kerberos KDC (and optionally pam_krb5) if setting up user accounts on the servers by hand/via configuration management is a practical option. At scale, you'd want LDAP to set the user IDs and other account attributes everywhere. Managed devices are nice but not entirely necessary. You can also use "GSSAPIKeyExchange yes" to solve the trust-on-first-use issue without resorting to DNSSEC, since the server identity gets verified via Kerberos in that case. The main benefits of certificates I can see are the increased auth flow options and better scaling at large scales since you lose the service ticket traffic.

gnufx 7y ago

So, you're not doing it wrong if you have Kerberos providing actual SSO (for "all" services) since before certificate authN was available. You need GSSAPI anyhow if you have Kerberized home directories and not typing passwords at ssh. Although you're likely to have LDAP (in which you can store public keys), all you need is the KDC and a simple Kerberos setup on ssh clients and servers. I wonder why anyone thinks you need more. Kerberos tickets and infrastructure are roughly equivalent to using ephemeral certificates as far as I can see. The one reason you might want certificates is if you require FIDO MFA, as I don't know if you can use anything other than OTP with Kerberos implementations. (The hook for "the auth flow" is preauth.)

AndyMcConachie 7y ago

What do SSH X.509 certs provide that DNSSEC and SSHFP RRs don't? SSH X.509 certs reminds of MTA-STS for SMTP, a shoe horning of the broken web PKI into another protocol that doesn't need it. Also, I'm not convinced that TOFU for SSH is really all that terrible. Maybe it's just my use case and my situation, but I SSH to the same servers over and over again. And if I need to give access to someone new I give them the public key first. SSH X.509 looks like a complex solution to a not very big problem that can be more easily solved with DNSSEC and SSHFP.

tptacek 7y ago
What do SSH x.509 certs do that DNSSEC doesn't? Sure, I'll bite: * They put authentication to your SSH servers entirely under your own control, without escrowing keys to the operators of the TLDs. * They're deployable independently, without enrolling all of the rest of your infrastructure into DNSSEC and all its unreliability and complexity. * They integrate with IDPs, so that users can get short-duration authenticators based on MFA logins, without storing long-lived secrets on their machines. SSH X.509 certificates have nothing to do with the web PKI, other than that they use the same encoding. Engineering orgs that use SSH CAs run their own CAs. That's the point. Happy to have helped!
- gnufx 7y ago
  I'd expect a policy dictating using ephemeral certificates like Kerberos keys would actually have them for web services too, not just ssh (as with Globus).

rb12345 7y ago

You can pretty much get away with just a Kerberos KDC (and optionally pam_krb5) if setting up user accounts on the servers by hand/via configuration management is a practical option. At scale, you'd want LDAP to set the user IDs and other account attributes everywhere. Managed devices are nice but not entirely necessary. You can also use "GSSAPIKeyExchange yes" to solve the trust-on-first-use issue without resorting to DNSSEC, since the server identity gets verified via Kerberos in that case. The main benefits of certificates I can see are the increased auth flow options and better scaling at large scales since you lose the service ticket traffic.