But I think there is actually a relatively safe way of having a password auth on login through os-server-password API in Nova:
https://docs.openstack.org/api-ref/compute/#servers-password-servers-os-server-password

Though, it would need a modification of all images, or supplying more metadata to them.

1. You'd need to have a script like this: https://paste.openstack.org/show/bn7fIrRf8Olkni9cI4QT/
2. Add to cloud.cfg: https://paste.openstack.org/show/b1kcVmdbkWC2OUZL9yg3/
3. In Horizon local_settings add "OPENSTACK_ENABLE_PASSWORD_RETRIEVE = True"

What this flow will do:
1. A random password is being generated and set for user `clouduser`
2. A password is being encrypted with public part of SSH key, which you supplied for instance
3. Encrypted version of the password is sent back to the metadata
4. In horizon you can fetch the password from the metadata and decrypt it using your SSH private key

I'd suggest to additionally modify the script/image to expire the password after the first login, as well as to prohibit password auth via SSH.

But I can totally get why password auth might be valuable, especially in cases where instance get misconfigured and need to have a way to login via console.

вт, 14 окт. 2025 г. в 16:43, Sean Mooney <smooney@redhat.com>:

On 14/10/2025 15:38, Jeremy Stanley wrote:
> On 2025-10-14 10:19:32 -0000 (-0000), hamid.lotfi@gmail.com wrote:
>> When creating an instance in OpenStack, you can use the --user-data
>> option to pass a cloud-init configuration file to the instance at
>> boot time. This file allows you to automate initial setup tasks such
>> as setting a user password
> [...]
>> password: ahmad
> [...]
>
> While probably okay for testing purposes, this is not safe in general.
> See https://wiki.openstack.org/wiki/OSSN/OSSN-0074 for one reason, but
> there are also other ways metadata might end up exposed.
>
> The better solution, and what basically everyone I know does, is to
> avoid password login and use SSH key authentication instead. Even the
> risks from instance metadata leaks notwithstanding, passwords can (and
> will) be remotely brute-forced if your sshd is listening on an
> Internet-reachable address. If someone manages to fish your SSH public
> key digest out of metadata on the other hand, there's not really
> anything they can do with that.

+100

the nova metadata api is not intened to sore password cert or any other
sensitive info.

that is explcity not an intened usecase for this api.

we store metadata in plain text and auth to that endpoint is optional.

most deployment will use a shared secerte between nova and neutron for
some minimal auth but the metadata api is not a secret store.
you should use barbican or vault if you need secret storage.

>