5 ms·

Umm, please correct me if I'm wrong but I think you're confusing SSH keys with SSH certificates. A SSH client key can be reused to create short lived SSH client

Umm, please correct me if I'm wrong but I think you're confusing SSH keys with SSH certificates. A SSH client key can be reused to create short lived SSH client certificates. You can keep using that SSH client key to encrypt data, sign data, login to GitHub etc. There's no such thing as "short-lived keys", there's short lived SSH certificates.

deleted 5y ago
[deleted]
pphysch 5y ago
Yes, a cert is just a public key that's been "stamped" by a certificate-authority (CA), allowing it to be validated by servers holding the CA public key (as well as enforcing other policies like lifespan, principles). It is a totally separate file and does not modify the original public or private key, which indeed have no notion of lifespan. If you are constantly regenerating uncompromised SSH keys, you are probably doing something wrong. The GP is misleading in this way.
- ayushnix 5y ago
  > If you are constantly regenerating uncompromised SSH keys, you are probably doing something wrong. Yup, there's no real reason to generate a new SSH key pair each and every time you want to get a short lived certificate. The SSO or CA management system (like Vault) is responsible for verifying your identity.
  - dfox 5y ago
    This is also true for X.509, there is exactly zero reason to generate new key (if it was not compromised) or even new CSR for certificate renewal. Yet people tend to do this which only increases the opportunities to fuck something up in the process. (Well, it does not make much sense, but over last year I have seen at least three instances of somebody overwriting the only copy of newly generated private key with the old one…)
    - ayushnix 5y ago
      > This is also true for X.509, there is exactly zero reason to generate new key (if it was not compromised) or even new CSR for certificate renewal. It might make sense to regenerate the private key on each certificate renewal if the private keys are kept unencrypted, as they often are in the X.509 scenario. If the keys are encrypted and if your web server manages to get the password to decrypt that key each and every time it serves a request, then yeah, I don't see the point of regenerating the private key on certificate renewal.
- soraminazuki 5y ago
  One of the first things the article mentions is rekeying. Since the step utility does in fact regenerate keys when obtaining certificates, it actually does have a lifespan. Besides, how do you even tell that your keys have been compromised?
  - ayushnix 5y ago
    > One of the first things the article mentions is rekeying. Since the step utility does in fact regenerate keys when obtaining certificates, it actually does have a lifespan. I went through the article again. Essentially, rekeying makes sense if the private keys in question, whether they are host private keys or client private keys, are kept unencrypted on disk. Host private keys typically are, so it might make sense to rekey host private keys. However, if your user private key is kept encrypted on disk, as it should be, there isn't really a good reason to rekey. The step tool seems to abstract that process and it also generates a new key pair on each login but that keypair never even touches the disk, according to the article. This makes sense assuming the step tool generates a key pair and doesn't encrypt the private key. In that case, yes, rotating/regenerating the client keypair on each login make sense.
  - pphysch 5y ago
    Those are choices made by the Smallstep SaaS and are not reflective of the underlying SSH cert technology.
    - soraminazuki 5y ago
      The thing is, the topic of the article centers around the step utility and security practices that it considers is the best. My comments were in relation to the article, not all the possible ways in which SSH certificates can be used.
soraminazuki 5y ago
Yes, but the entire point of the described setup is to get rid of traditional long lasting keys in favor of ephemeral certificates (which I believe is another way of saying signed keys) obtained through SSO. Signing certificates with your existing keys kind of make the whole point moot.
- ayushnix 5y ago
  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.

deleted 5y ago

[deleted]

pphysch 5y ago

Yes, a cert is just a public key that's been "stamped" by a certificate-authority (CA), allowing it to be validated by servers holding the CA public key (as well as enforcing other policies like lifespan, principles). It is a totally separate file and does not modify the original public or private key, which indeed have no notion of lifespan. If you are constantly regenerating uncompromised SSH keys, you are probably doing something wrong. The GP is misleading in this way.

ayushnix 5y ago
> If you are constantly regenerating uncompromised SSH keys, you are probably doing something wrong. Yup, there's no real reason to generate a new SSH key pair each and every time you want to get a short lived certificate. The SSO or CA management system (like Vault) is responsible for verifying your identity.
- dfox 5y ago
  This is also true for X.509, there is exactly zero reason to generate new key (if it was not compromised) or even new CSR for certificate renewal. Yet people tend to do this which only increases the opportunities to fuck something up in the process. (Well, it does not make much sense, but over last year I have seen at least three instances of somebody overwriting the only copy of newly generated private key with the old one…)
  - ayushnix 5y ago
    > This is also true for X.509, there is exactly zero reason to generate new key (if it was not compromised) or even new CSR for certificate renewal. It might make sense to regenerate the private key on each certificate renewal if the private keys are kept unencrypted, as they often are in the X.509 scenario. If the keys are encrypted and if your web server manages to get the password to decrypt that key each and every time it serves a request, then yeah, I don't see the point of regenerating the private key on certificate renewal.
soraminazuki 5y ago
One of the first things the article mentions is rekeying. Since the step utility does in fact regenerate keys when obtaining certificates, it actually does have a lifespan. Besides, how do you even tell that your keys have been compromised?
- ayushnix 5y ago
  > One of the first things the article mentions is rekeying. Since the step utility does in fact regenerate keys when obtaining certificates, it actually does have a lifespan. I went through the article again. Essentially, rekeying makes sense if the private keys in question, whether they are host private keys or client private keys, are kept unencrypted on disk. Host private keys typically are, so it might make sense to rekey host private keys. However, if your user private key is kept encrypted on disk, as it should be, there isn't really a good reason to rekey. The step tool seems to abstract that process and it also generates a new key pair on each login but that keypair never even touches the disk, according to the article. This makes sense assuming the step tool generates a key pair and doesn't encrypt the private key. In that case, yes, rotating/regenerating the client keypair on each login make sense.
- pphysch 5y ago
  Those are choices made by the Smallstep SaaS and are not reflective of the underlying SSH cert technology.
  - soraminazuki 5y ago
    The thing is, the topic of the article centers around the step utility and security practices that it considers is the best. My comments were in relation to the article, not all the possible ways in which SSH certificates can be used.

soraminazuki 5y ago

Yes, but the entire point of the described setup is to get rid of traditional long lasting keys in favor of ephemeral certificates (which I believe is another way of saying signed keys) obtained through SSO. Signing certificates with your existing keys kind of make the whole point moot.

ayushnix 5y ago
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.