Re: Replacing SSH Keys - best practices?
On Tue, May 23, 2023 at 9:22 AM Kirk Wolf 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 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 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, dest
Re: Replacing SSH Keys - best practices?
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 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 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 t
Re: Replacing SSH Keys - best practices?
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 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
Re: Replacing SSH Keys - best practices?
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 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
Re: Replacing SSH Keys - best practices?
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 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 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
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 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
Replacing SSH Keys - best practices?
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
