Wrong access permissions of authorized keys directory when using root-owned location

[Andreas Florath]

When using a central, root-owned directory to store ssh keys, cloud-init changes the permissions of the key directory which renders the keys unusable.

I'm using a similar approach as described here:
https://www.ssh.com/ssh/key/
MOVING SSH KEYS TO A ROOT-OWNED LOCATION

but I'm using the config

    AuthorizedKeysFile /etc/ssh/keys/%u

In the original image, the permissions of the keys directory /etc/ssh/keys are 0755 - owned by root:root. It contains all the keys of the users. All keys have 0644 permissions and are also owned by root:root. (The background: Users are not allowed to change their ssh keys.)

After the machine boots and cloud-init finishes, the permissions of the key directory /etc/ssh/keys is 0700 and it is impossible to use key-authentication, because sshd cannot access the key files.

IMHO the reason for this is, that cloud-init changes the permission of the keys directory

https://git.launchpad.net/cloud-init/tree/cloudinit/ssh_util.py#n259

        util.ensure_dir(os.path.dirname(auth_key_fn), mode=0o700)

which is wrong in this use case.

[Ryan Harper (raharper)]

Thanks for filing a bug.

It's not clear to me why sshd can't read /etc/ssh/keys with mode 0700 but it can read /home/%u/.ssh which is 0700.

One possibility would be for cloud-init to skip setting mode on the directory if it already exists; you mentioned that the original image already contained this directory.

[Andreas Florath (ansreas)]

Hmmm - I'm really struggling here because it looks that there is no defined / documented requirements for the .ssh directory only a recommendation

man ssh:

     ~/.ssh/
             This directory is the default location for all user-specific configuration and authentication information. There is no general requirement to keep the entire contents of this di‐
             rectory secret, but the recommended permissions are read/write/execute for the user, and not accessible by others.

And there is also no defined / documented permissions for the AuthorizedKeysFile.

BTW: there is also a use case for encrypted home directories documented for Ubuntu: https://help.ubuntu.com/community/SSH/OpenSSH/Keys
"Encrypted Home Directory"

> To solve this, create a folder outside your home named /etc/ssh/<username> (replace "<username>" with your actual username). This directory should have 755 permissions and be owned by the user. Move the authorized_keys file into it. The authorized_keys file should have 644 permissions and be owned by the user.

Then edit your /etc/ssh/sshd_config and add:

AuthorizedKeysFile /etc/ssh/%u/authorized_keys

Debug shows what happens here:

    Aug 08 19:29:24 vm1 sshd[1758]: debug1: temporarily_use_uid: 1002/1004 (e=0/0)
    Aug 08 19:29:24 vm1 sshd[1758]: debug1: trying public key file /etc/ssh/keys/florath
    Aug 08 19:29:24 vm1 sshd[1758]: debug1: Could not open authorized keys '/etc/ssh/keys/florath': Permission denied
    Aug 08 19:29:24 vm1 sshd[1758]: debug1: restore_uid: 0/0

    # id florath
    uid=1002(florath) gid=1004(florath) ...

Purely depending on the (non-)existence of the parent directory does not solve the problem in all cases.

Setting the permissions might be based on a decision like:

   if re.search("%u", os.path.basename(auth_key_fn)):
      mkdir -p os.path.dirname(auth_key_fn)
      chown -R root:root os.path.dirname(auth_key_fn)
   else
      current behavior

This might work in some more use cases but looks hackisch to me.

Looking for alternatives:

Adding a directory level like

   AuthorizedKeysFile /etc/ssh/keys/%u/authorized_keys

does not help.

AuthorizedKeysCommand is not handles by cloud-init.

Helpless.....

[Ryan Harper (raharper)]

Right, sshd will assume the user's uid before reading the authorized_keys file.
This means each directory in the path to the key file must be readable by the
target user.

That generally means for the path, we need to visit each layer and verify
that the user has access to each path.

[Ryan Harper (raharper)]

As a workaround, you could include a runcmd in user-data which fixes up the directory permissions:

runcmd:
  - chmod 0755 /etc/ssh/keys

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3417