Stop copying ssh system keys and check folder permissions (#956)
BZ: 1979099
TESTED: By me and QA
BREW: 38818884
This is a continuation of previous MR 25 and upstream PR #937.
There were still issues when using non-standard file paths like
/etc/ssh/userkeys/%u or /etc/ssh/authorized_keys, and the choice
of storing the keys of all authorized_keys files into a single
one was not ideal. This fix modifies cloudinit to support
all different cases of authorized_keys file locations, and
picks a user-specific file where to copy the new keys that
complies with ssh permissions.
commit 00dbaf1e9ab0e59d81662f0f3561897bef499a3f
Author: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Date: Mon Aug 9 16:49:56 2021 +0200
Stop copying ssh system keys and check folder permissions (#956)
In /etc/ssh/sshd_config, it is possible to define a custom
authorized_keys file that will contain the keys allowed to access the
machine via the AuthorizedKeysFile option. Cloudinit is able to add
user-specific keys to the existing ones, but we need to be careful on
which of the authorized_keys files listed to pick.
Chosing a file that is shared by all user will cause security
issues, because the owner of that key can then access also other users.
We therefore pick an authorized_keys file only if it satisfies the
following conditions:
1. it is not a "global" file, ie it must be defined in
AuthorizedKeysFile with %u, %h or be in /home/<user>. This avoids
security issues.
2. it must comply with ssh permission requirements, otherwise the ssh
agent won't use that file.
If it doesn't meet either of those conditions, write to
~/.ssh/authorized_keys
We also need to consider the case when the chosen authorized_keys file
does not exist. In this case, the existing behavior of cloud-init is
to create the new file. We therefore need to be sure that the file
complies with ssh permissions too, by setting:
- the actual file to permission 600, and owned by the user
- the directories in the path that do not exist must be root owned and
with permission 755.
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>