On Tue, May 23, 2023 at 9:22 AM Kirk Wolf <k...@coztoolkit.com> wrote:
> 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 > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
