"ssh_pwauth" always true on CloudStack datasource with password

[ubuntu-server-builder]

This bug was originally filed in Launchpad as LP: #1747705

Launchpad details

affected_projects = ['cloud-init (Ubuntu)']
assignee = None
assignee_name = None
date_closed = None
date_created = 2018-02-06T16:15:29.170756+00:00
date_fix_committed = None
date_fix_released = None
id = 1747705
importance = medium
is_complete = False
lp_url = https://bugs.launchpad.net/cloud-init/+bug/1747705
milestone = None
owner = shota-a
owner_name = Shota Aratono
private = False
status = confirmed
submitter = shota-a
submitter_name = Shota Aratono
tags = []
duplicates = []

Launchpad user Shota Aratono(shota-a) wrote on 2018-02-06T16:15:29.170756+00:00

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.

[ubuntu-server-builder]

Launchpad user Scott Moser(smoser) wrote on 2018-02-09T14:32:41.137674+00:00

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)

[ubuntu-server-builder]

Launchpad user Shota Aratono(shota-a) wrote on 2018-03-02T10:06:17.724928+00:00

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?

[ubuntu-server-builder]

Launchpad user Scott Moser(smoser) wrote on 2018-03-02T14:44:51.610157+00:00

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?

[ubuntu-server-builder]

Launchpad user Dan Watkins(oddbloke) wrote on 2018-03-02T14:51:39.910657+00:00

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.