Skip to content

Re-design ssh keys management on VMs #387

Description

@OpenNebulaSupport

In the current implementation there is no way to delete ssh key(s) via OpenNebula on instantiated VM: clearing the content of "SSH public key" field in Sunstone with subsequent 'Continue" button pressing doesn't remove the key from authorized_keys file on the VM. The onevm updateconf <vm_Id> command behaves identically.
If you clean the content of "SSH public key" and then add another key, even dummy one like ssh-rsa no-key then it is appended to the authorized_keys file. So its content is always extended with new values preserving the old ones too.
The logic behind current implementation is the following: we didn't want to wipe out any other existing keys that could be added by other means (e.g. ansible).
There is a request to introduce the way to completely clear the inherited SSH key on an individual VM after instantiation.

We have already discussed that internally and pupped up with the following ideas:

  1. Adding SSH_PUBLIC_KEY_EXCLUSIVE=YES/NO ( with default =NO) this would wipe any additional key
  2. Wrapping context-injected keys in a managed block, e.g.:
# --- BEGIN OPENNEBULA CONTEXT KEYS ---
ssh-ed25519 AAAA... user@host
# --- END OPENNEBULA CONTEXT KEYS ---
  1. Use AuthorizedKeysFile in /etc/ssh/sshd_config file as described here. Maybe we could prefix or postfix such keys (e.g. /etc/ssh/keys/%u.one) which are coming from OpenNebula and that way we won't overlap with other potential keys management tools?

OpenNebula version: 7.4.0
one-context package: 7.4.0

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions