Earlier, I showed you how to create a pair of keys on your local workstation, and then transfer the public key to a remote server. This allows you to disable username/password authentication on the server, making it much harder for the bad guys to break in. The only problem with this that we didn't address is that the public key goes into an authorized_keys file that's in the user's own home directory. So, the user can manually add extra keys to the file, which would allow the user to log in from other locations besides the one that's been authorized. And, there's also the problem of having authorized_keys files all over the place, in every user's home directory. That makes it a bit hard to keep track of everyone's keys.

One way to handle this is to move everyone's authorized_keys file to one central location. Let's take Vicky, my solid gray kitty. The administrator created an account on the server that she needs to access and allowed her to create and transfer her key to it before disabling password authentication. So, Vicky now has her authorized_keys file in her home directory on that server, as we see can here:

vicky@ubuntu-nftables:~$ cd .ssh
vicky@ubuntu-nftables:~/.ssh$ ls -l
total 4
-rw------- 1 vicky vicky 233 Oct  3 18:24 authorized_keys
vicky@ubuntu-nftables:~/.ssh$

Vicky owns the file, and she has both read and write permissions on it. So, even though she can't transfer other keys to it the normal way once the administrator has disabled password authentication, she can still transfer key files manually, and manually edit the authorized_keys file to include them. To thwart her efforts, our intrepid administrator will create a directory within the /etc/ssh/ directory to hold everyone's authorized_keys files, like so:

sudo mkdir /etc/ssh/authorized-keys

Our intrepid administrator's full admin privileges allow him to log into the root user's shell, which allows them to go into the directories of all other users:

donnie@ubuntu-nftables:~$ sudo su -
[sudo] password for donnie: 
root@ubuntu-nftables:~# cd /home/vicky/.ssh
root@ubuntu-nftables:/home/vicky/.ssh# ls -l
total 4
-rw------- 1 vicky vicky 233 Oct 3 18:24 authorized_keys
root@ubuntu-nftables:/home/vicky/.ssh#

The next step is to move Vicky's authorized_keys file to the new location, changing its name to vicky, like so:

root@ubuntu-nftables:/home/vicky/.ssh# mv authorized_keys /etc/ssh/authorized-keys/vicky

root@ubuntu-nftables:/home/vicky/.ssh# exit
donnie@ubuntu-nftables:~$

Now, we have a bit of a conundrum. As you can see here, the file still belongs to Vicky, and she has both read and write privileges. So, she can still edit the file without any administrator privileges. Removing the write privilege won't work, because since the file belongs to her, she could just add the write privilege back. Changing ownership to the root user is part of the answer, but that will prevent Vicky from being able to read the file, which will prevent her from logging in. To see the whole solution, let's see what I've already done with my own authorized_keys file:

donnie@ubuntu-nftables:~$ cd /etc/ssh/authorized-keys/
donnie@ubuntu-nftables:/etc/ssh/authorized-keys$ ls -l
total 8
-rw------- 1 vicky vicky 233 Oct 3 18:24 vicky
-rw-r-----+ 1 root root 406 Oct 3 16:24 donnie
donnie@ubuntu-nftables:/etc/ssh/authorized-keys$

The eagle-eyed among you have surely noticed what's going on with the donnie file. You have seen that I changed ownership to the root user and then added an access control list, as indicated by the + sign. Let's do the same for Vicky:

donnie@ubuntu-nftables:/etc/ssh/authorized-keys$ sudo chown root: vicky

donnie@ubuntu-nftables:/etc/ssh/authorized-keys$ sudo setfacl -m u:vicky:r vicky 

donnie@ubuntu-nftables:/etc/ssh/authorized-keys$

Looking at the permissions settings, we see that Vicky has read access to the vicky file:

donnie@ubuntu-nftables:/etc/ssh/authorized-keys$ ls -l 
total 8
-rw-r-----+ 1 root root 406 Oct 3 16:24 donnie
-rw-r-----+ 1 root root 233 Oct 3 18:53 vicky
donnie@ubuntu-nftables:/etc/ssh/authorized-keys$

While we're at it, let's look at her access control list:

donnie@ubuntu-nftables:/etc/ssh/authorized-keys$ getfacl vicky
# file: vicky
# owner: root
# group: root
user::rw-
user:vicky:r--
group::---
mask::r--
other::---
donnie@ubuntu-nftables:/etc/ssh/authorized-keys$

Vicky can now read the file so that she can log in, but she can't change it.

The final step is to reconfigure the sshd_config file, and then restart the SSH service. Open the file in your text editor and look for this line:

#AuthorizedKeysFile     .ssh/authorized_keys .ssh/authorized_keys2

Change it to this:

AuthorizedKeysFile      /etc/ssh/authorized-keys/%u

The %u at the end of the line is a mini-macro that tells the SSH service to look for a keys file that has the same name as the user who's logging in. Now, even if the users were to manually create their own authorized_keys files in their own home directories, the SSH service would just ignore them. Another benefit is that having the keys all in one place makes it a bit easier for an administrator to revoke someone's access, should the need arise.

Be aware that there's a lot more to managing SSH keys than what I've been able to present here. One problem is that while there are a few different free open source software solutions for managing public keys, there aren't any for managing private keys. A large corporation could have thousands or perhaps even millions of private and public keys in different places. Those keys never expire, so they'll be around forever unless they get deleted. If the wrong people get hold of a private key, your whole system could become compromised. As much as I hate to say it, your best bet for managing SSH keys is to go with a commercial solution, such as ones from https://www.ssh.com/ and CyberArk.

You've learned several cool tricks here for beefing up your server security. Now, let's look at how to create different configurations for different users and groups.