Functionally, yes, but ...
Best practice is to remove the public key of an "old" keypair from their
authorized_keys file.
The whole point about key rotation is to discard a key (or pair) that
might have been compromised.
If a key is reasonably* thought to be safe (uncompromised) there's NO
value in rotating it out, no need for a new key.
So don't leave those old public keys in authorized_keys. Get rid of them.
*I say "reasonably" because it's generally not possible to know that a
given key (or pair) has not been compromised.
So ... if one stops using a given SSH key, then one should remove the
public counterpart from (e.g.) authorized_keys.
-- R; <><
On 5/23/23 08:45, Allan Staller wrote:
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