4 ms·

I doubt we're getting rid of traditional long lasting keys anytime soon. They do have their uses and it'd be a waste not to use them. > Signing certificates wi

I doubt we're getting rid of traditional long lasting keys anytime soon. They do have their uses and it'd be a waste not to use them. > Signing certificates with your existing keys kind of make the whole point moot. You mean getting signed certificates from a SSH CA with an existing client public key? Why does it make the whole point moot? The SSO is responsible for verifying your identity. Rather, it seems pointless to generate a new SSH keypair each and everytime you want to get a certificate and login to a machine. You can certainly do it if you want but I don't see the point. You can keep using your existing SSH public keys to get short lived certificates and login to a machine, do you job, logout, and repeat the process with the same keys.

soraminazuki 5y ago
When you sign short term certificates with your existing keys, you're still using your existing keys, managed in the exact same way, to authenticate. The certificate would just be another layer of indirection. I fail to see how that would be a meaningful change. One of the primary benefits of the described setup is that there would only be a single long term key. It would be managed more securely because it won't be lying around on each user's personal machines.
- ayushnix 5y ago
  > The certificate would just be another layer of indirection. I fail to see how that would be a meaningful change. That certificate would only be issued after you've gone through SSO or some other certificate management process and it would have a defined expiry period, maybe even as short as a few minutes. It is a meaningful change. When using key based authentication, as long as you had your public key in the authorized_keys file on the server, you would be able to login without issues, even if your keypair is compromised. With certificates, even if your keypair is compromised, you wouldn't be able to login to that server because you'd have to compromise the SSO/MFA authentication step as well, which adds another layer of meaningful security in the process.
  - soraminazuki 5y ago
    I think we're in full agreement here. My prior comment was about using your existing keys as the CA.
    - ayushnix 5y ago
      Oh, I didn't realize you were talking about not using your SSH keypair as the SSH CA keypair. Well, that's kinda expected. The SSH CA keypair is the single point of failure in this case, which sounds worse than it is but it's okay to have such a thing because of the benefits, so it should be protected and isolated.

soraminazuki 5y ago

When you sign short term certificates with your existing keys, you're still using your existing keys, managed in the exact same way, to authenticate. The certificate would just be another layer of indirection. I fail to see how that would be a meaningful change. One of the primary benefits of the described setup is that there would only be a single long term key. It would be managed more securely because it won't be lying around on each user's personal machines.

ayushnix 5y ago
> The certificate would just be another layer of indirection. I fail to see how that would be a meaningful change. That certificate would only be issued after you've gone through SSO or some other certificate management process and it would have a defined expiry period, maybe even as short as a few minutes. It is a meaningful change. When using key based authentication, as long as you had your public key in the authorized_keys file on the server, you would be able to login without issues, even if your keypair is compromised. With certificates, even if your keypair is compromised, you wouldn't be able to login to that server because you'd have to compromise the SSO/MFA authentication step as well, which adds another layer of meaningful security in the process.
- soraminazuki 5y ago
  I think we're in full agreement here. My prior comment was about using your existing keys as the CA.
  - ayushnix 5y ago
    Oh, I didn't realize you were talking about not using your SSH keypair as the SSH CA keypair. Well, that's kinda expected. The SSH CA keypair is the single point of failure in this case, which sounds worse than it is but it's okay to have such a thing because of the benefits, so it should be protected and isolated.