Wrong access permissions of authorized keys file and parent directory when using absolute AuthorizedKeysFile
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Fix Released
|
High
|
Dan Watkins |
Bug Description
[Impact]
For users who provide more than one unique SSH key to cloud-init and have a shared AuthorizedKeysFile configured in sshd_config, cloud-init 20.4 started writing all of these keys to such a file, granting all such keys SSH access as root. Previously, cloud-init did not handle such sshd_config configuration, and so would have written users' keys to the hardcoded `~/.ssh/
[Test Case]
This test case has been written for use with the cloud-init integration testing framework:
```
ABSOLUTE_
BACKDOOR_KEYS = "/etc/backdoor_
USER_DATA_TMPL = """\
#cloud-config
bootcmd:
- sed -i "s,#AuthorizedK
runcmd:
- |
cat << EOF > {1}
{{}}
EOF
""".format(
# This test checks that we do not write keys into an absolute
# AuthorizedKeysFile by default, because doing so presents a security issue.
#
# Because we're intentionally testing that we do not write authorized keys to
# the location configured for sshd, we cannot SSH into the system using keys in
# that path. We use runcmd to populate a second configured path to grant us
# access; runcmd will install the key after all the SSH key determination has
# been completed, therefore not affecting it.
def test_test(
# We shouldn't write out absolute files until we've figured out how to do
# it right
user_data = USER_DATA_
)
with session_
assert client.execute(
"test -f {}".format(
).failed
```
[Regression Potential]
This update touches only cloud-init's SSH handling, by reverting a commit which modified its behaviour. It has been present in Ubuntu images since the 6th of January.
Users who have started relying on the new behaviour (cloud-init writing keys to non-standard AuthorizedKeysFile locations configured in sshd_config) in the past ~2 weeks will see this behaviour stop working.
[Original Report]
Starting on the 6th January 2021 we started observing SSH authentication issues in AWS AMI builds.
We have SSH configured with an absolute (i.e. rather than per-user) authorised keys file, e.g.
AuthorizedKe
We observed that the file and parent folder permissions had been modified, to:
/etc/ssh - 0700
/etc/
These permissions would be fine if the authorised keys file were in a users home directory, but not for a centrally owned absolute file.
We investigated and identified that between the 4th and 6th January 2021, cloud-init on Ubuntu 16.04 was upgraded from 20.3-2-
https:/
While trying workarounds (e.g. oneshot service to revert permissions), we then ran into another change that appended exit(142) to the command option:
https:/
which then meant, as root is disabled, that SSH would not work using the authorised key pair for any user. This is because cloud-init first writes the key for the user (e.g. ubuntu) and in our case writing the key to /etc/ssh/
There are similarities to https:/
description: | updated |
information type: | Public → Private Security |
description: | updated |
information type: | Private Security → Public Security |
Hi Kevin,
Thanks for using cloud-init, and for taking the time to file such a detailed bug! Apologies for having broken your workflow.
I can reproduce the issue that you're seeing locally, and I'm going to start digging into what we need to do to address it.
I have one clarifying question: when launching an image with an older cloud-init and sshd_config as described, I don't see /etc/ssh/ authorized_ keys created or populated. As best I can tell, cloud-init places keys in per-user .ssh/authorized _keys regardless of the AuthorizedKeysFile set in sshd_config. Does this match the behaviour you were seeing previously? (I believe this is the bug that we were setting out to fix in the commits you've linked, so I'm not necessarily surprised by this: I just want to make sure that we're all on the same page as far as expected behaviour goes.)
Thanks!
Dan