Bug 2151002
| Summary: | Undercloud creating 1024- bit SSH Public/Private Key - Enable upgrades from 16.x to 17.1 (which requires 2048+ bit keys) | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Jamie Fargen <jfargen> |
| Component: | tripleo-ansible | Assignee: | Andre <afariasa> |
| Status: | CLOSED ERRATA | QA Contact: | Khomesh Thakre <kthakre> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 16.2 (Train) | CC: | afariasa, alee, arcsingh, bshephar, cjeanner, dwilde, ggrasza, hrybacki, jbadiapa, jjung, jpodivin, jpretori, jschluet, lbezdick, lsvaty, mabdulsa, mburns, mgarciac, parthee, pgrist, pnavarro, pweeks, rdiazcam |
| Target Milestone: | ga | Keywords: | Triaged, UpgradeBlocker, Upgrades |
| Target Release: | 17.1 | Flags: | jpretori:
needinfo?
(pnavarro) astillma: needinfo? (afariasa) |
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | tripleo-ansible-3.3.1-1.20230518201535.el9ost | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-08-16 01:12:55 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 2129048, 2129049, 2016660 | ||
|
Description
Jamie Fargen
2022-12-05 20:02:01 UTC
This is the command I used to generate the ecdsa key on the undercloud, it is the largest size ecdsa key that is possible to create and though less than 2048 bits seems to be accepable for RHEL9.1 crypto policy. $ ssh-keygen -t ecdsa -b 521 Is this the code responsible for creating the keypair on the undercloud? /usr/share/openstack-tripleo-heat-templates/extraconfig/post_deploy/undercloud_post.sh: ssh-keygen -b 1024 -N '' -f $HOMEDIR/.ssh/id_rsa When OSP17.1 is released, which will be based on RHEL9.1+, it seems that this could block access to the overcloud nodes via the heat-user. This seems like a foreseeable blocker that could be encountered in upgrades to OSP17.1 (considering it is based on RHEL9.1). So before upgrading to OSP17.1 I would recommend that deployments add a 521 bit ecdca keypair to the stack user on the undercloud and push out this ecdca public key to the overcloud compute and controllers and ensure they can access the systems using this key. Small typo in comment #3, it is actuall an ecdsa keypair. (In reply to Jamie Fargen from comment #3) > When OSP17.1 is released, which will be based on RHEL9.1+, it seems that > this could block access to the overcloud nodes via the heat-user. This seems > like a foreseeable blocker that could be encountered in upgrades to OSP17.1 > (considering it is based on RHEL9.1). So before upgrading to OSP17.1 I would > recommend that deployments add a 521 bit ecdca keypair to the stack user on > the undercloud and push out this ecdca public key to the overcloud compute > and controllers and ensure they can access the systems using this key. The code you're referring to was changed in Wallaby which is what OSP17 is based on. So this won't have any impact on 17. https://github.com/openstack/tripleo-heat-templates/commit/11a79ab8f75f7661285590d64981f10525535da2 1024 bit keys were still fine with the version of openssh used in RHEL8 weren't they? When it comes to using a key for instances you want to deploy on the overcloud, generating your own key as per your requirements seems reasonable. The key we're generating during the deployment is intended to manage the overcloud nodes themselves rather than cater for instances deployed on the overcloud. If dfg:security want to change it to increase the size, I see no problems with it. Other than we need to be sure to handle it properly during updates to avoid being locked out. But provided 1024bit keys are still supported on RHEL8, I don't think this is a OpenStack bug per se. Brendan, Thanks for pointing out where the keys are generated. I was looking someplace else (tripleo-ansible). I agree that this is not a problem for fresh installs on OSP 17, and I'm inclined to not specify a key size so that the crypto modules will pick the right one instead. This is relevant for example if FIPS is enabled. They may, however, be a problem for upgrades to 17.1 because you could be locked out of your nodes when you update to RHEL 9 for OSP 17.1. In that sense, this is an OpenStack (or at least an upgrade bug). You can't just rerun the script above without the -b option because those keys are the ones used to talk to the overcloud. Fortunately, the security DFG recently wrote a playbook to allow you to rotate your keys. It looks like we need to make that playbook more readily available as a second day operation - and make sure that it is called prior to upgrade. Raising severity due to the blocker+ Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Release of components for Red Hat OpenStack Platform 17.1 (Wallaby)), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2023:4577 |