This is nothing "amazingly new", but more of a reminder to secure your "authorized_keys" file for SSH. One of the first things I see even simple bots do to obtain persistent access to a UNIX system is to add a key to the authorized_keys file of whatever account they are compromising. 

So here are a few things you can do to make your "authorized_keys" file more secure:

authorized_keys file location

The default location is .ssh/authorized_keys and .ssh/authorized_keys2. Make sure to specify a location (default is fine, but more later). One file is fine. the "authorized_keys2" file was used back in the day to retain backward compatibility with older SSH versions. Most importantly, you want to control the location of the file, and for the later discussion, we are going to assume the default location.

File Permissions

This is probably the easiest change you can make. By default, most systems set the permissions to "0600" and make the file owned by the user. This looks "ok" at first as only the user has read/write access. But in this case, we try to prevent someone who compromised the user's credentials from modifying the file. A better option is to make sure the file is owned by the root and set to read-only (0444). The user must still be able to read the file, so 0400 will not work if the file is owned by root. Next, you may also set the "immutable" flag. It does not offer a ton of extra security, as the attacker has to be root anyway, but it offers some more detection capabilities.

Central Management

Even small "IoT" style systems can often be managed with tools like Ansible. This opens up more possibilities to better manage authorized_keys files. First of all, you do not have to store the key files in the user's home directory. You could set up a central location for all the key files. Something like /etc/ssh/authorized_keys. In this directory, you may not maintain individual files for each user. The sshd configuration file accepts "tokens" as part of the filename. You now use

AuthorizedKeysFile /etc/ssh/authorized_keys/%U 

The token "%U" is replaced with the numeric userid. Or you can use "%u" for the username (this may be easier to keep consistent across different systems).

There is also the possibility to use a command to retrieve the key on demand using the "AuthorizedKeysCommand". This way, the keys are not exposed on the system, but personally I am a bit afraid of any denial of service issues with this setup. But there are a lot of options to further secure SSH keys by, for example, constantly rotating them or integrating them with other centrally managed access systems.

File Monitoring

Changes to authorized_keys files should be monitored using systems like Aide, Wazuh/OSSEC, or Tripwire. This may not always be an option on minimum Linux systems (IoT). Some homegrown solutions may work well enough in these cases (Ansible could easily alert you of changes). Do not allow "perfect" to get in the way of "good enough". 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|