Lionel, You don't say what opsys or product that you are using to generate ssh keypairs, but some default to the same name if you don't provide the name of the new keypair.
There's nothing wrong with rotating keys by installing a new one on both the client and server(s) that use it and then removing the old key after some overlap. An overlap is often necessary to allow for distribution. Another option is to use OpenSSH certificates (which are not X.509). This involves having a ca key create a signed certificate for a user key. The ca key could be protected in a hardware token. You then would distribution the ca public key to all of your servers. The avoids the requirement for updating authorized_keys with user public keys. This would on;y be an option for OpenSSH servers (or a few other products) Kirk Wolf Dovetailed Technologies http:// <http://dovetail.com/>coztoolkit.com On Tue, May 23, 2023, at 8:02 AM, Lionel B. Dyck wrote: > Actually when a new key pair is generated in my testing the old key pair is > overlaid. > > But you are correct in the authorized_keys file and in the git server keys. > > > 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 > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of > Allan Staller > Sent: Tuesday, May 23, 2023 7:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Replacing SSH Keys - best practices? > > Classification: Confidential > > It is not necessary to remove the "old keypair". SSH will cycle through any > available keys until it finds one that works. > > Theoretically, at some point this could become a performance bottleneck. In > practical terms it seems to be a non-issue. > > My USD $0.02 worth. > > > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of > Lionel B. Dyck > Sent: Tuesday, May 23, 2023 7:39 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Replacing SSH Keys - best practices? > > [CAUTION: This Email is from outside the Organization. Unless you trust the > sender, Don't click links or open attachments as it may be a Phishing email, > which can steal your Information and compromise your Computer.] > > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ::DISCLAIMER:: > ________________________________ > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain > viruses in transmission. The e mail and its contents (with or without > referred errors) shall therefore not attach any liability on the originator > or HCL or its affiliates. Views or opinions, if any, presented in this email > are solely those of the author and may not necessarily reflect the views or > opinions of HCL or its affiliates. Any form of reproduction, dissemination, > copying, disclosure, modification, distribution and / or publication of this > message without the prior written consent of authorized representative of > HCL is strictly prohibited. If you have received this email in error please > delete it and notify the sender immediately. Before opening any email and/or > attachments, please check them for viruses and other defects. > ________________________________ > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
