"ssh_pwauth" always true on CloudStack datasource with password

[Shota Aratono]

ssh_pwauth is set forcefully to true when
- Using CloudStack datasource
- Using VM template supports password reset feature.

When cloud-init obtain password from virtual router, cloud-init set ssh_pwauth to true nevertheless originall ssh_pwauth value is No/unchanged.
I read the code and found this behavior is in https://github.com/cloud-init/cloud-init/blob/master/cloudinit/sources/DataSourceCloudStack.py#L148 .

I'd like to use password for only virtual console and forbid ssh password authentication.
The easiest solution is remove the code https://github.com/cloud-init/cloud-init/blob/master/cloudinit/sources/DataSourceCloudStack.py#L150 but I'm not sure about side effect.

How do you think this?
The version of cloud-init is 17.1-46-g7acc9e68-0ubuntu1~16.04.1, on ubuntu 16.04.

[Scott Moser (smoser)]

Hi, thanks for the good bug report.
I believe that you should be able to override the datasource provided config
in user-data. Try providing user-data as:

#cloud-config
ssh_pwauth: False

Please let me know if that works for you or not. I do realize that its unfortunate to have to do that. Generally speaking the precedence ordre for config in cloud-init is:
  /etc/cloud/cloud.cfg
  /etc/cloud/cloud.cfg.d/*
  data-source provided config (there isnt a lot of these)
  user-provided config (user-data)

[Shota Aratono (shota-a)]

HI,

I confirmed that I can override ssh_pwauth value with user-data.
But, it's does not fit for my use case.
Since deploing VM is done by user, I can't control user-data.

I think the best solution is cloud-init don't update PasswordAuthentication in /etc/sshd_config
when ssh_pwauth value is 'unchanged'.
As I wrote before, the root cause is CloudStack datasource overwrites ssh_pwauth value forcibly.
So I'd like to remove this behavior.

Is it helpful to creating the patch?

[Scott Moser (smoser)]

Shota,
The change that put that behavior in was
 https://git.launchpad.net/cloud-init/commit/?id=e626359a6ea

If I understand what you're asking for correctly, then we would break ssh access to a system that the Vm template password reset property set.

Does the guest have access to those properties? Is there any other way that the creator of the VM could indicate that they wanted password access only on the console?

[Dan Watkins (oddbloke)]

I can't remember the exact details, but I believe that this change was landed to support a CloudStack deployment that didn't support SSH keys at all. In my ignorance of the broader CloudStack ecosystem, I assumed that this was true of all CloudStack deployments, so setting it in the data source made sense (so that people would be able to access their instances somehow).

Given that my assumption is false, I would be happy with backing out that setting _provided there is a way for vendors to set it back_. I believe backing out the setting will regress existing CloudStack deployments that expect the current behaviour (and regress them in a serious way; it would completely deny users' access to their VMs).

Does CloudStack support vendor data[0]? If it does, then we can ensure that (a) it's possible to use vendor data to restore the old behaviour, and (b) we document how people do so. If it doesn't, then I'd be hesitant to make this change.

[0] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Using+ConfigDrive+for+Metadata%2C+Userdata+and+Password suggests "maybe" to me.

[James Falcon (falcojr)]

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