← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1924614] Re: SSH key options are not respected when user is root

 

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3868

** Bug watch added: github.com/canonical/cloud-init/issues #3868
   https://github.com/canonical/cloud-init/issues/3868

** Changed in: cloud-init
       Status: Triaged => Expired

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1924614

Title:
  SSH key options are not respected when user is root

Status in cloud-init:
  Expired

Bug description:
  In user data, if "user" is set to "root" and "ssh_authorized_keys" are
  set, any SSH key options are ignored. For example, with the following:

      user: root
      ssh_authorized_keys:
        - cert-authority,principals="globalroot" ssh-ed25519 SomeEd25519Key Global User Issuing CA

  ...the following ends up in ~root/.ssh/authorized_keys:

      ssh-ed25519 SomeEd25519Key Global User Issuing CA

  However, the SSH key options are respected when "user" is not set to
  root.

  I think, but am not sure, that this is due to an oversight in the
  `apply_credentials` method in `cc_ssh.py`. In this snippet:

      if disable_root:                                             
          if not user:                                             
              user = "NONE"                                        
          key_prefix = disable_root_opts.replace('$USER', user)    
          key_prefix = key_prefix.replace('$DISABLE_USER', 'root') 
      else:                                                        
          key_prefix = ''                                          

  "key_prefix" being set to the empty string causes
  "ssh_util.setup_user_keys" to pass a non-None value to
  AuthKeyLineParser.parse, causing it to ignore the options set on the
  key in favor of the empty string. I think setting "key_prefix = None"
  here may fix the problem but don't know enough about the cloud-init
  development process + what the security implications of this might be.

  I'm testing in a Proxmox 6 environment using the Debian 10 OpenStack
  cloud-init image.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1924614/+subscriptions



References