@Edent just wanted to second the people using FIDO tokens (builtin now) or the Secure Enclave/TPM: my goal is not to copy keys across devices and to use something which simple file collecting malware couldn’t grab. That matters more to me than rotation because an attacker can likely accomplish whatever they’re interested in before any reasonable expiration window.
@Edent as others mentioned, this is a Gitlab specific "feature". Classic SSH keys don't have any date information. There's a thing called "SSH Certificates" that use X509 certs to if you want that pain. (Useful in other ways though.)
re: Same keys - its fine, IMO. Better to have different keys per computer. Also better to have different keys per security domain. (Personal servers vs corporate servers vs external companies.) But 'better' is relative and marginal.
@Edent I think you should just "delete" your key on the gitlab server and upload it again, without expiration date.
Personally, I don't believe in these kinds of expiration dates. They're for a) people who regularly move machines and forget to wipe/revoke old keys, or b) organizations with some churn that want to prevent old employee access lingering forever. Almost no-one[tm] needs this. There's no cryptographic/inherent danger from non-expiring keys, only organizational issues.
@Edent (I usually have my SSH keys in hardware modules, either yubikey/smartcard or TPM/virtual smartcard, or secure enclave on MacOS X. This way they either move with me when I move machines, or they were bound to the decommissioned machine and cannot linger.)
@Edent I don’t think SSH keys have a built-in expiration, so I suspect this is something defined on the Gitlab side.
You could generate a fresh key pair, and add it, or from a quick search, it looks like you can possibly delete and re-add it in GitLab.
The main reason to make a new key pair would be if your current one is using an older algorithm that’s less favoured nowadays, or a smaller key size than you’d choose now.
Add comment