Setting Up a Common Authorized Keys File for Shared Access

To enable shared SSH access for multiple users, you must configure a dedicated group and place the authorized keys file in a directory owned by that group. This approach allows members of the group to read and append their public keys without requiring root privileges or compromising system security. The solution relies on proper file permissions rather than changing the global sshd_config to point to a root-owned file, which would break authentication for non-root users.

The Security Problem with Root-Owned Keys

A common misconception is that setting AuthorizedKeysFile /root/.ssh/authorized_keys in /etc/ssh/sshd_config allows any user to log in using keys stored in the root home directory. This configuration is fundamentally broken because the SSH daemon drops privileges before reading the authorized keys file. If the file is owned by root and has restrictive permissions (typically 600), non-root users cannot read it, resulting in an "Authentication failed" error. Even if you make the file world-readable, storing private user keys in a shared location violates basic security principles regarding key isolation and audit trails. You should never attempt to share a single authorized keys file across users by making it globally readable or writable by all users, as this creates a significant security vulnerability where one compromised account could inject malicious keys for others.

Creating a Shared Access Group

The correct method involves creating a specific Linux group that will manage access to the shared resources. First, create a new group named sshshared using the groupadd command. Then, add the users who need shared access to this group using usermod -aG sshshared username. This ensures that only designated users have the ability to interact with the shared authentication mechanism. It is crucial to use the -a flag to append the group to the user's existing groups, preventing the removal of other necessary group memberships. After adding users, verify the group membership with the groups command to ensure the configuration is applied correctly.

Setting Up the Directory Structure

Next, create a dedicated directory to store the authorized keys files. A standard location is /etc/ssh/shared_authorized_keys. Create this directory using mkdir -p /etc/ssh/shared_authorized_keys. Change the ownership of this directory to the sshshared group using chown root:sshshared /etc/ssh/shared_authorized_keys. Set the permissions to 750, which allows the owner (root) full control, the group to read and execute, and denies access to others. This permission structure ensures that only members of the sshshared group can list and access the keys within this directory. Inside this directory, create individual files for each user, such as /etc/ssh/shared_authorized_keys/user1.pub. Each file should be owned by the respective user but readable by the group. For example, set the permissions to 640 so that the owner can write and the group can read.

Configuring SSH Daemon Settings

Modify the sshd_config file located at /etc/ssh/sshd_config to include the shared keys directory. Add the following line to the configuration: AuthorizedKeysFile /etc/ssh/shared_authorized_keys/%u.pub .ssh/authorized_keys. The %u placeholder is replaced by the username during authentication, allowing the system to look for a specific file for each user while also falling back to the traditional .ssh/authorized_keys location. This hybrid approach provides flexibility, allowing users to maintain personal keys alongside shared ones. After editing the configuration file, restart the SSH service using systemctl restart sshd to apply the changes. Test the connection from a client machine to ensure that users can authenticate successfully using their respective public keys.

Maintaining and Securing the Setup

Regularly audit the contents of the shared directory to ensure that only authorized keys are present. Remove any obsolete keys promptly to maintain a clean and secure environment. Consider implementing additional security measures such as disabling password authentication and enforcing key-based login only. Review the /var/log/auth.log file for any authentication failures or suspicious activities. Implementing these practices helps maintain the integrity of your shared access setup. For more information on securing your server, see Securing an Ubuntu Server for Development Purposes. Additionally, understanding how to lock user accounts is vital for managing access revocation, as detailed in Locking User Accounts with Sudo Commands Without Rebooting.

Frequently Asked Questions

Can I use a single file for all users?

No, using a single file for all users is insecure and difficult to manage. Each user should have their own file to allow for easy revocation and auditing of access rights.

What permissions should the shared directory have?

The shared directory should have permissions set to 750, allowing root full access and the group read and execute permissions. This prevents unauthorized users from accessing the keys.

How do I remove a user from shared access?

To remove a user, simply delete their corresponding public key file from the shared directory and remove them from the sshshared group using gpasswd -d username sshshared.

Does this method affect existing SSH configurations?

No, this method does not affect existing configurations. By including .ssh/authorized_keys in the AuthorizedKeysFile directive, users can still use their personal keys if they exist.

Is it safe to store keys in /etc/ssh?

Yes, storing keys in /etc/ssh is safe as long as the directory permissions are strictly controlled. This location is standard for system-wide SSH configurations and resources.