When you think about renewal guidelines for SSH keypairs, the relevant question is: What do you want to protect yourself (or your org) against? If you account for the possibility that the private key itself gets into wrong hands unknowingly, it boils down to the computational effort to make the key usable for authentication. That effort is directly dependent on the strength of the passphrase of the private key. The crypto algorithms used for public key authentication in SSH are sufficiently robust that they are not a concern with current public knowledge. Of course that might change any minute in theory.
A central authentican system like LDAP allows you to enforce complexity rules for passphrases, enabling predictions of timeframe necessary to reconstruct the passphrase from a stored hash (factoring in salting and stuff like that). SSH keypairs can have a complex passphrase, a simple passphrase or no passphrase at all. I am not aware of a mechanism with which you could control that. On basis of that, my personal opinion is that first and foremost an organisation should have a policy regarding passphrase complexity for SSH keypairs. If you account for the possibility that people do not follow that policy and the passphrase of a private key that slips out can be 'cracked' in reasonable time, it makes sense to ask people to refresh them from time to time, since that is something you can enforce and validate, while passphrase changes on the private key are invisible to the administrator. Mind, people might still re-use the passphrase they had before, so this is not perfect. I do not see a justification to refresh the private key regularly because of the key material itself. Moving to a new workstation is not a trigger for a new private key in my opinion. It's a good practice to keep track of the systems that have the fingerprint of your public key in their authorized_keys file. I've seen cases where there are thousands of such systems. If a reason to abandon a private arises, you want to understand what needs to be updated. -Alex On Tue, May 23, 2023 at 07:39:11AM -0500, Lionel B. Dyck wrote: > For those into security (and shouldn't we all be) a question on ssh keys: > How often should a user change their ssh keys for z/OS (OMVS)? on their > workstation? > > When changing on the workstation, that probably happens every few years as > the workstation is replaced, the user then needs to update any git servers > they connect to with the new key as well as any other servers they access > via ssh by updating the authorized_keys file with the new public key. > > When changing on z/OS (OMVS), which probably never happens, the user needs > to update any git servers with the new key and any other servers they access > where their public key is in the authorized_keys file. > > Both the git server and any authorized_keys files would have to have the old > key removed (not critical as it is still intimately connected to the now > replaced private key but needed to keep things clean). > > Are there any best practices, guidelines, etc. on this? > > > Lionel B. Dyck <>< > Website: https://www.lbdsoftware.com > Github: https://github.com/lbdyck > > Worry more about your character than your reputation. Character is what you > are, reputation merely what others think you are. - - - John Wooden > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
