ssh_pwauth: false fails to disable challenge/response authentication

[ubuntu-server-builder]

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

Launchpad details

affected_projects = []
assignee = None
assignee_name = None
date_closed = None
date_created = 2017-03-22T13:46:04.967839+00:00
date_fix_committed = None
date_fix_released = None
id = 1675021
importance = medium
is_complete = False
lp_url = https://bugs.launchpad.net/cloud-init/+bug/1675021
milestone = None
owner = fghaas
owner_name = Florian Haas
private = False
status = confirmed
submitter = fghaas
submitter_name = Florian Haas
tags = []
duplicates = []

Launchpad user Florian Haas(fghaas) wrote on 2017-03-22T13:46:04.967839+00:00

cc_set_passwords.py interprets the ssh_pwauth boolean configuration option, and depending on its setting will either enable, disable, or not touch the PasswordAuthentication option in sshd_config.

This neglects to also set ChallengeResponseAuthentication. It defaults to yes upstream, but many distributions, including Ubuntu, ship a default sshd_config that sets this to no. On a system with "ChallengeResponseAuthentication yes" however, "ssh_pwauth: false" has no real effect — and this poses a security problem for users of those systems, as they will most likely inadvertently leave password authentication enabled.

How to best address this is tricky. Obviously, "ssh_pwauth: false" should disable both PasswordAuthentication and ChallengeResponseAuthentication. What "ssh_pwauth: true" should do is debatable.

What complicates matters still is that one of the affected systems that ship with "ChallengeResponseAuthentication yes" is SLES, including the official JeOS OpenStack image, and SLES ships its own fork of cloud-init. So even if this does gets fixed in upstream cloud-init, someone still has to remind the SUSE folks to merge the patch (or update their default image).

[alexissavin]

I'm surprise to see little traction for this one. It would make a lot of sense to ensure that both "PasswordAuthentication" and "ChallengeResponseAuthentication" is properly set to "no" when "ssh_pwauth" is set to "false".

[blackboxsw]

I agree with this position @alexissavin, we did have a documentation-only update better represent how cloud-init admins can obtain such behavior where applicable https://github.com/canonical/cloud-init/pull/6265/files.

I could see this change being applicable in general in upstream cloud-init, but I would caution that an ideal PR would do the following:

• only set KbdInteractiveAuthentication = no when ssh_pwauth = false
• set KbdInteractiveAuthentication = no instead of ChallengeResponseAuthentication because ChallengeResponseAuthentication is now deprecated.
• Do not set KbdInteractiveAuthentication = yes in any case
• doc update to doc/rtd/module-docs/cc_set_password/data.yaml

[alexissavin]

Well, the idea, in my case, is to disable any password authentication through SSH as soon as an SSH key has been provided to the system during the provisioning process.

On FreeBSD, KbdInteractiveAuthentication is set to yes by default. There is no reference to ChallengeResponseAuthentication, probably since it's deprecated. So in the end, I do force manually the 3 options to no as soon as the system is able to deploy an SSH key to the default account:

• PasswordAuthentication = no
• ChallengeResponseAuthentication = no
• KbdInteractiveAuthentication = no