Hello Maksim, My cloud provider provides an openstack API too to manage resources. I'm using Terraform to do so. When attempting to upload a new public key using the openstack_compute_keypair_v2 resource of the https://registry.terraform.io/providers/terraform-provider-openstack/opensta... provider, the API server responds with the following error message: {"badRequest": {"code": 400, "message": "Keypair data is invalid: failed to generate fingerprint"}} The provider's issue tracker point to the Openstack API server about similar problems, that seems to be valid since the error message comes from server side: https://github.com/terraform-provider-openstack/terraform-provider-openstack... Thanks, Ivan On Fri, Oct 10, 2025, at 00:39, Maksim Malchuk wrote:

Ivan,

SSH keys supported in the sshd daemon inside Linux OSes, it's not OpenStack related. Where did you face problems?

On Fri, Oct 10, 2025 at 1:35 AM Ivan Marton <openstack@martonivan.hu> wrote:

...

__ Dear Openstack community,

I'm wondering if there are any plans to support sk-ssh-ed25519@openssh.com SSH public key formats for the keypairs endpoint. I did not find in the public documentation any explicit information about supported SSH public keys, but according to my experiences the mentioned format is not accepted.

Did I miss something? Is it supported in any recent versions? Is it on the roadmap?

Thank you all for any reply!

Best regards, Ivan Marton

-- Regards, Maksim Malchuk

On Fri, Oct 10, 2025, at 00:59, Clark Boylan wrote:

On Thu, Oct 9, 2025, at 3:46 PM, Ivan Marton wrote:

...

Hello Maksim,

My cloud provider provides an openstack API too to manage resources. I'm using Terraform to do so. When attempting to upload a new public key using the openstack_compute_keypair_v2 resource of the https://registry.terraform.io/providers/terraform-provider-openstack/opensta... provider, the API server responds with the following error message: {"badRequest": {"code": 400, "message": "Keypair data is invalid: failed to generate fingerprint"}}

The provider's issue tracker point to the Openstack API server about similar problems, that seems to be valid since the error message comes from server side: https://github.com/terraform-provider-openstack/terraform-provider-openstack...

Someone from the Nova team probably needs to chime in on the underlying mechanism and what the proper fix is. (I think Nova uses the python cryptography pacakage to serialize and deserialize keys so potentially some update there?)

That said we stuff multiple keys into a single Nova key object and this works. I think Nova only validates the first key listed. I haven't tested this with sk key variants (we're a mix of traditional RSA and ed25519 keys), but it is probably worth testing if you create a single Nova key with multiple keys in it (separated by newlines) and the first one is of an acceptable type do keys of unknown types (to Nova) make it into your instances? It seems to me that the underlying cryptography module does support these public keys since https://github.com/pyca/cryptography/commit/51a6dd28ccbb7587fff9e951299b17aa.... That commit appeared in version 43.0.0 first. (In 2.7 that I see in https://github.com/openstack/nova/blob/076498ed95958a5d6ccb784f3d336657584bc... this was still not there. 2.7 was released on May 31, 2019, while 43.0.0 on Jul 20, 2024.)

Is there chance to have that dependency being bumped up to some newer version? Thanks, Ivan

Hi, Just some side notes from my side for cryptography bump as this came up recently in a discussion with our downstream team as well. There is a patch that tries to bump it in requirements repo: https://review.opendev.org/c/openstack/requirements/+/958191 I tried to add as comments my findings, as I remember the bottleneck is now in pysaml2 which depends on pyOpenSSL, (and cryptography at the end) and there is no new release of pysaml2 that bumps these dependencies. There is PR of pysaml2 to replace pyOpenSSL with cryptography, that would be good (at least for bumping the versions) for us: https://github.com/IdentityPython/pysaml2/pull/977 Best wishes Lajos Katona (lajoskatona) melanie witt <melwittt@gmail.com> ezt írta (időpont: 2025. okt. 10., P, 2:48):

On 10/9/25 16:31, Ivan Marton wrote:

...

...

It seems to me that the underlying cryptography module does support

[...] these public keys since https://github.com/pyca/cryptography/ commit/51a6dd28ccbb7587fff9e951299b17aac39ee5cc <https://github.com/ pyca/cryptography/commit/51a6dd28ccbb7587fff9e951299b17aac39ee5cc>. That commit appeared in version 43.0.0 first. (In 2.7 that I see in https:// github.com/openstack/nova/blob/076498ed95958a5d6ccb784f3d336657584bc63a/ requirements.txt#L13 <https://github.com/openstack/nova/ blob/076498ed95958a5d6ccb784f3d336657584bc63a/requirements.txt#L13> this was still not there. 2.7 was released on May 31, 2019, while 43.0.0 on Jul 20, 2024.)

Is there chance to have that dependency being bumped up to some newer version?

You and Clark are correct, whether or not Nova supports the key types depends only on the version of the Python 'cryptography' library installed as it does not deal with the key types directly.

IMO we could bump the required version for release versions circa 2024 and newer. As long as 43.0.0 is available for install in the common distros of the time.

That said, the version in the requirements.txt represents the minimum version needed to use Nova in general, as using newer key types is not strictly "required".

What really matters is the version indicated in the upper-constraints.txt [1] for the given Nova release. The version on the master branch allows up to version 43.0.3 as of today. This version is also shown as the upper bound for OpenStack versions 2025.2 and 2025.1. Generally upper bound versions are selected within the range of the common distros package versions at the time of that OpenStack release.

Note that I don't think you actually have to adhere to upper-constraints.txt either in your environment depending on how you deploy.

If you are able to install cryptography 43.0.0 in your environment, you should automatically get Nova working with it (after service restart).

This was my experience anyway in the past with https://bugs.launchpad.net/nova/+bug/1555521.

-melwitt

[1]

https://opendev.org/openstack/requirements/src/commit/af5fa8a98f1f093d01d87f...

On 10/10/25 00:18, Ivan Marton wrote: [...]> Since the server-side environment is not under my control, all I could

do is to contact the service provider's support and ask for solution from them by sharing the details in this thread with them.

From users' perspective, it would be beneficial to enforce the newer cryptography module version, to ensure that regardless of the local environment, this feature would be available. But that may be a product level decision.

Gotcha. I wonder what version of OpenStack they are running. We can bump the minimum required version in Nova as high as 43.0.3 on the master branch and based on your experience, I think we should. Bumping the version on the master branch would help future us when service providers are installing >= 2026.1 Gazpacho later on. I don't think we could do it on a stable branch however because a new higher required version wouldn't be very "stable" :) for those already consuming existing stable branches. -melwitt

Dear Mentors, I tried to follow the project repository link, but I received a *"Forbidden / Access Denied"* message. It seems I don’t have permission to view the repository. Could someone please help me with access? Thank you in advance! Best regards, *Tomris (IRC nick: tomrist)* пт, 10 окт. 2025 г. в 16:43, Jeremy Stanley <fungi@yuggoth.org>:

On 2025-10-09 17:47:35 -0700 (-0700), melanie witt wrote: [...]

...

whether or not Nova supports the key types depends only on the version of the Python 'cryptography' library installed as it does not deal with the key types directly. [...]

What's the actual intent behind this check? Is it simply an attempt to prevent uploading bogus/malformed keys? If so, as Clark pointed out, the check has been trivially bypassable for years (in OpenDev we've been treating it as a feature).

Or is there some additional functionality in Nova that depends on being able to parse keys rather than just treating them as an opaque blob? -- Jeremy Stanley

Thank you for response! I cant access: https://opendev.org/openstack/ironic, ->project repository, and https://docs.openstack.org/contributors/common/irc.html - project public chat link Thanks On Sat, 11 Oct 2025 at 20:49, Clark Boylan <cboylan@sapwetik.org> wrote:

On Sat, Oct 11, 2025, at 1:30 AM, Tomris Teymurlu wrote:

...

Dear Mentors,

I tried to follow the project repository link, but I received a *"Forbidden / Access Denied"* message. It seems I don’t have permission to view the repository.

Could someone please help me with access?

Can you be more specific about what URL you are trying to access and how? For example if you are trying to `git clone`, then the `git clone` command and `git --version` output would be helpful. If trying to browse a repository via the web then the URL you have requested and your browser version would be helpful.

...

Thank you in advance!

Best regards, *Tomris (IRC nick: tomrist)*

Hi Tony, I use Google Chrome, and i did not come across with such problems before. Regards, Tomris On Sun, 12 Oct 2025 at 06:32 Tony Breeds <tony@bakeyournoodle.com> wrote:

On Sun, 12 Oct 2025 at 11:24, Tomris Teymurlu <tomristt9@gmail.com> wrote:

...

Thank you for response! I cant access: https://opendev.org/openstack/ironic, ->project

...

and https://docs.openstack.org/contributors/common/irc.html - project

repository, public chat link

It's quite possible that your web-browser user-agent "looks" like an AI bot crawler and is being blocked.

What web-browser are you using?

Yours Tony.

On Sun, 12 Oct 2025 at 18:35, Tomris Teymurlu <tomristt9@gmail.com> wrote:

Hi all again,

I have just installed Microsoft edge browser and try to enter links now i can successfully access pages😊 thank you for your assistance!

That's great. It would help us, hopefully, improve the service if you'd still replay to the questions in my other reply. Yours Tony.

On 10/10/25 9:42 PM, Jeremy Stanley wrote:

On 2025-10-09 17:47:35 -0700 (-0700), melanie witt wrote: [...]

...

whether or not Nova supports the key types depends only on the version of the Python 'cryptography' library installed as it does not deal with the key types directly. [...]

What's the actual intent behind this check? Is it simply an attempt to prevent uploading bogus/malformed keys? If so, as Clark pointed out, the check has been trivially bypassable for years (in OpenDev we've been treating it as a feature).

Or is there some additional functionality in Nova that depends on being able to parse keys rather than just treating them as an opaque blob?

Looking at the code, it seems that the main objective of that logic is not validation but calculation of fingerprint from the provided public key data. Fingerprint is stored in DB associated when public key is created or imported, and then returned by the keypair API. https://docs.openstack.org/api-ref/compute/?expanded=list-keypairs-detail#ke... Technically we may be able to drop the fingeprint given the fact that the whole public key data is returned by the API, that change is a bit tricky due to API impact.

On 10/10/25 05:42, Jeremy Stanley wrote:

...

On 2025-10-09 17:47:35 -0700 (-0700), melanie witt wrote: [...]

...

whether or not Nova supports the key types depends only on the version of the Python 'cryptography' library installed as it does not deal with the key types directly. [...]

What's the actual intent behind this check? Is it simply an attempt to prevent uploading bogus/malformed keys? If so, as Clark pointed out, the check has been trivially bypassable for years (in OpenDev we've been treating it as a feature).

Or is there some additional functionality in Nova that depends on being able to parse keys rather than just treating them as an opaque blob?

I just had a look at the code and the intent appears to be a combination of what you and Takashi mentioned.

In the code [1], the comment says, "Test that the given public_key string is a proper ssh key. The returned object is unused since pyca/cryptography does not have a fingerprint method." So it's a basic validation check (indirectly by calling load_ssh_public_key()) and at the same time it generates a fingerprint to return as a REST API response parameter.

I'm guessing it was just trying to "help" a person uploading a key if they did a bad copy pasta or similar. That's the first piece.

On 14/10/2025 01:11, melanie witt wrote: that or this may have also been used in the past when we generated a key to provide them with the finger print as well as the key?

The second piece is if we wanted to remove the 'fingerprint' API response parameter, we could do that in a new API microversion.

do we even supprot that any more or did we remove that in 2.92 https://docs.openstack.org/nova/latest/reference/api-microversion-history.ht... as of zed we nolonger supprot generating keypairs server side, we only supprot uploading an existing key. i geusse we didnt remove ti https://docs.openstack.org/api-ref/compute/#id240 long term i would like to remove the keypair api form nova entirly and add it to keystone. in my dream world keystone user would have keypair registered and you woudl be able to use an ssh key to auth to keystone to get a token. nova would also supprot using the same keyapir form keyston to inject into the instance as we do today via cloud init but it would not be stored in nova anymore. the ssh keypair is really the only user owned data that nova stores today the rest is all project owned. if we were adding it today it woudl have either been in keystone or barbican not nova so if we are evolving this api in the future i think we shoudl consider moving it to a more suitable service then nova. perferable keystone but that just because i really really woudl like to be able ot login to opensack with an ssh key.

-melwitt

[1] https://github.com/openstack/nova/blob/8b81b5f91ffe1f9c38a483d151b82316d443d... [2] https://cryptography.io/en/latest/hazmat/primitives/asymmetric/serialization...

On 14/10/2025 14:50, Jeremy Stanley wrote:

On 2025-10-14 09:10:19 +0100 (+0100), Sean Mooney wrote: [...]

...

long term i would like to remove the keypair api form nova entirly and add it to keystone.

in my dream world keystone user would have keypair registered and you woudl be able to use an ssh key to auth to keystone to get a token.

nova would also supprot using the same keyapir form keyston to inject into the instance as we do today via cloud init but it would not be stored in nova anymore. [...]

And also ideally rename it. The term "keypair" was accurate when Nova was generating both halves of the key, but what the API (and documentation) calls a keypair now is really just a public key digest used to verify that the user has possession of the corresponding private key. OpenSSH keeps them in a file called "authorized_keys" so something like "sshauthkey" might make sense.</bikeshed>

we do actully use it for one other usecase. we use it to encrypt the admin password of a server and return it to the client if you have cloud init or similar generate it but again we are just use the public key for its intended usecase, to encypte data that only the private key can decrypted. so we coudl definlty call it publickey or simialr althoguh it can be an x509 certificat as well for windows guest and winrm ectra so ya if we were to do this properly in keystone in teh future we shoudl choose a more accurate name i agree. that also make the upgrade path on the nova side simple ebcause you do not need to disambiguate where the key is sotred. if tis keypair its still in nova if its <new name> you pass a refence to it in keystone or where ever it lives.