5 ms·
For Kerberos, you would need fallback authentication methods always active, in case Kerberos servers went down. But fallback auths are potentially security risk
by dikei 7y ago
For Kerberos, you would need fallback authentication methods always active, in case Kerberos servers went down. But fallback auths are potentially security risks.
For client certificate, the fallback can be long-term certificates, locking up in a safe, that should only be opened when all other ephemeral certificate fail. I think this is less risky.
- gnufx 7y agoIt's amusing to see locking something up in a safe compared with keeping KDCs running (probably for MS Windows anyhow in an "enterprise" setting). It's not as if there isn't a list of ssh mechanisms to try anyway.
- felipelemos 7y agoYou can always have a long term certificate locked in a safe as a fallback to Kerberos
- dikei 7y agoThe point is you don't need a server-side fallback if you don't use Kerberos, since the server can validate login on its own. The fallback certificate is only client-side, and can be keep offline/air- gap from the main credentials.
- kerng 7y agoYou have to provision the key for the fallback cert on server in both cases. So not sure why one would be better then the other...
- dikei 7y agoYou don't need to provision key for fallback cert on server, because the server simply trust all certificates that was signed by the CA. You only need to get the CA to sign the fallback cert.