Skip to main content


The admin wants to prevent users from creating their own authorized_keys files. How could this be accomplished?

#Linux #DFIR #CommandLine #Trivia

Hal Pomeranz reshared this.

in reply to Hal Pomeranz

I know you want a *NIX command-line answer, but a better approach might be just to disable keys in the sshd config file. The authorized_keys file only has public keys anyway, so isn't terribly sensitive, and changes to the sshd config file can be more easily (re)applied & audited by configuration management.
Protocol 2<br>PubkeyAuthentication no<br>
This entry was edited (1 year ago)
in reply to Hal Pomeranz

Set ownership of users .ssh/ directory to root, with users only having read/execute access to the directory and files (i.e., authorized_keys) contained therein.
This entry was edited (1 year ago)
in reply to Hal Pomeranz

two possible ways for the sshd_config

1) Set `AuthorizedKeysFile` to a file which is not writeable by the users and contains all authorized keys.

2) Set `AuthorizedKeysFile` to a dummy file or /dev/null. And configure AuthorizedKeysCommand and AuthorizedKeysCommandUser to run a command which returns the authorized key(s) for the user.

That way the users can connect with their keys but cannot add their own.

in reply to Hal Pomeranz

guess
I suppose sshd could be configured to look for authorized_keys files in a non-standard directory that was inaccessible to non-admin users. Not sure how to do it otherwise while still allowing admins to use publickey auth.
in reply to Hal Pomeranz

for user in `find /home/ -maxdepth 1 -type d`
do
mkdir $user/.ssh
touch $user/.ssh/authorized_keys
done

It's not pretty, and not really a one liner and I'm user someone who knows xargs better than me could do it with piping the find command. But making the file owned by root will let only me use it unless I need the user to be able to use it.

This is if I wanna do it in an emergency, and if I wanted to do this longterm, I'd just edit /etc/ssh/sshd_config

in reply to Hal Pomeranz

Yesterday's Linux DFIR command line trivia asked how an admin could prevent users from creating their own authorized_keys files.

@DavidJBianco suggested disabling Public Key authentication entirely. I have to disallow this answer because while it moots the authorized_keys file entirely, I believe the question implied that we wanted to keep Public Key authentication available. I'll be clearer next time.

Multiple people suggested changing the location of the authorized_keys file by setting AuthorizedKeysFile in sshd_config (looks like @llutz was the first to chime in on this idea). The admin could set the file path to a directory that was root-owned and populate the file with whatever keys they felt appropriate.

@mjharmon checked in with the command line solution I was expecting: using "chattr +i" to render users' authorized_keys files immutable. So we might do something like:

rm -f /home/*/.ssh/authorized_keys
for dir in /home/*; do
mkdir -p -m 700 "$dir/.ssh"
touch "$dir/.ssh/authorized_keys"
chattr +i "$dir/.ssh/authorized_keys"
done

The first "rm" command removes any existing authorized_keys files, or even symlinks if the user decided to get tricky. Then the loop ensures we have a ".ssh" directory for each user, which gets a new empty authorized_keys file, which then gets set immutable so it can't be changed.

Some suggested using file and directory permissions to solve the problem, but it simply isn't workable. Even if the root user created root-owned ".ssh" directories for all users (problematic because of the known_hosts file among other reasons) with root-owned authorized_keys files, the user could simply rename the root-owned ".ssh" directory because they have write permissions on their own home directory. Once the root-owned directory was moved out of the way, the user would be free to create their own directory with their own authorized_keys file.

EDIT: Actually @bbaugh points out the "chattr" solution above fails for exactly the same reason-- the user can rename the directory with the immutable file and then start a new directory with their own authorized_keys. You could make the ".ssh" directory immutable, but then you have problems with things like known_hosts again. On the whole, I like the sshd_config file change better.

#Linux #DFIR #CommandLine #Trivia

This entry was edited (1 year ago)
in reply to Hal Pomeranz

@DavidJBianco @llutz @mjharmon @bbaugh

The solution with chattr doesn't work. As the user could simply rename ~/.ssh/ and create a new one.

# as root
rm -rf /home/hal/.ssh
mkdir -p -m 700 /home/hal/.ssh
touch /home/hal/.ssh/authorized_keys
chattr +i /home/hal/.ssh/authorized_keys

# as hal
ls -ld /home/hal/.ssh
drwx------ 2 root root 4.0K 2023-01-12 23:25 /home/hal/.ssh/authorized_keys
mv ~/.ssh ~/.ssh_bak
mkdir -m 700 ~./ssh
touch /home/hal/.ssh/authorized_keys

in reply to Hal Pomeranz

Would it be possible to use SELinux to prevent writes? I haven't had much experience with it...
in reply to James Blanding

@ilikepi SELinux is generally implemented in “Targeted” mode these days. That means it does not attempt to interfere with normal interactive users on the system. So, no, you generally can’t use SELinux for this.
Unknown parent

Hal Pomeranz
@bbaugh @mjharmon @DavidJBianco @llutz Ugh, you're correct. You have to "chattr +i" the ".ssh" directory as well.