| 2017-03-22 13:46:04 |
Florian Haas |
bug |
|
|
added bug |
| 2017-03-22 13:52:40 |
Florian Haas |
description |
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 this patch. |
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. |
|
| 2017-03-22 13:53:17 |
Florian Haas |
description |
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. |
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). |
|
| 2017-03-29 20:49:25 |
Scott Moser |
cloud-init: status |
New |
Confirmed |
|
| 2017-03-29 20:49:29 |
Scott Moser |
cloud-init: importance |
Undecided |
Low |
|
| 2017-03-29 20:49:33 |
Scott Moser |
cloud-init: importance |
Low |
Medium |
|
| 2017-06-01 13:43:52 |
Guilherme Moro |
information type |
Public |
Public Security |
|
| 2023-05-10 21:52:32 |
James Falcon |
bug watch added |
|
https://github.com/canonical/cloud-init/issues/2837 |
|
| 2023-05-10 21:52:33 |
James Falcon |
cloud-init: status |
Confirmed |
Expired |
|
