authorized_keys for multiple chrooted users with the same home directory

Question

We are running CentOS 6.9 with OpenSSH_5.3p1 and created chrooted accounts for external users with the same home directory (mounted to htdocs). Problem is that the file .ssh/authorized_keys2 is owned by the first user (and this works already). How can I make it work for another user?

I tried to add an AuthorizedKeysFile in sshd_config with multiple file paths and I got the error garbage at end of line.

I tried to add an AuthorizedKeysFile in sshd_config in the match block of the second user and I got the error 'AuthorizedKeysFile' is not allowed within a Match block.

I cannot change the home directory because otherwise the path is different from the real path for development.

Any suggestions how to solve it? May I have to upgrade OpenSSH to a newer version that supports multiple entries for AuthorizedKeysFile (I think I have to build it with rpm)? What about security updates afterwards?

Solution

One option is to use tokens to give each user a unique authorized_keys file.

From man sshd_config:

AuthorizedKeysFile

Specifies the file that contains the public keys that can be used for user authentication. The format is described in the AUTHORIZED_KEYS FILE FORMAT section of sshd(8). AuthorizedKeysFile may contain tokens of the form %T which are substituted during connection setup. The following tokens are defined: %% is replaced by a literal %, %h is replaced by the home directory of the user being authenticated, and %u is replaced by the username of that user. After expansion, AuthorizedKeysFile is taken to be an absolute path or one relative to the user's home directory. Multiple files may be listed, separated by whitespace. Alternately this option may be set to none to skip checking for user keys in files. The default is .ssh/authorized_keys .ssh/authorized_keys2.

Emphasis mine.

So you can set:

AuthorizedKeysFile    .ssh/%u_authorized_keys

Then for user foo create an authorized_keys file .ssh/foo_authorized_keys.

A note on permissions

From man sshd:

~/.ssh/authorized_keys
...
If this file, the ~/.ssh directory, or the user's home directory are writable by other users, then the file could be modified or replaced by unauthorized users. In this case, sshd will not allow it to be used unless the StrictModes option has been set to no.

So you may need to stick your keys outside .ssh/, or else set StrictModes to no. If you set StrictModes to no make sure another user can't create an authorized_keys for someone else, or delete the other user's authorized keys. Probably best off doing something like:

AuthorizedKeysFile    .ssh_%u/authorized_keys

Create a directory .ssh_foo/ for user foo, that only foo can read/write.

---

You can choose if you want to also allow .ssh/authorized_keys by using

AuthorizedKeysFile    .ssh/authorized_keys    .ssh_%u/authorized_keys

This will allow the "normal" form of authorized_keys to still work, and an authorized_keys file must be owned by your user and have correct permissions or it will be ignored. Still consider that it should not be possible to create an authorized_keys file for another user, which could just mean touching the file as root so it's empty.

Comments

[Centimane]

Define "make it work". What action are you trying to take that's failing? I assume you're trying to SSH without a password to many different accounts using the same home directory? Is it that you're having trouble giving each user a unique authorized_keys file given that they share a home-dir?

[Radek Stašek]

Thanks a lot. I solved it with "AuthorizedKeysFile .ssh_%u/authorized_keys2", because the directory needs ownership of the user, too. As mentioned in my question it was not possible to declare more than one file with my openssh version (I think support was added in release 5.9). I had to create this user specific .ssh-directory for all existing non-chrooted users, too.

[Centimane]

@hellcode I figured to put the note of it: 1. just in case your syntax was wrong and 2. In case of other people with the same question where multiple files is allowed. Good to hear it solved it for you anyhow.