On Mon, Dec 11, 2017 at 03:49:24PM -0700, Dan Becker wrote: > I am reading a blog proposing to use the AuthorizedKeyCommand to hook into > another authentication mechanism by calling a shell script > > https://blog.heckel.xyz/2015/05/04/openssh-authorizedkeyscommand-with-fingerprint/ > > Do I have a valid concern in thinking this might not be a prudent method of > authentication ? >
I don't know why he uses the term 'dynamic authorized_keys file'. I know what he means, but it's not a file. (When people misuse basic terms I immediately question their depth of understanding.) As for your question - these are some thoughts, not intended to be comprehensive: As I see it, the key will be somewhere - in the authorized_keys file in the user's home directory, in an LDAP directory, or perhaps elsewhere. Regardless of where it's kept, it needs to be secured against tampering. Is the local host more secure in that regard than an LDAP dir? That depends on the quality of the sysadmins who set up the server and how the network infrastructure is designed. The same applies to any other mechanism for remotely storing public keys. sshd(8) will complain if the perms for the user's authorized_key file aren't correct, so it offers a safe-guard against misconfiguration. The mechanism for retrieving the key from a remote server should use SSL/TLS to validate the server's identity and protect the contents. The utility invoked by sshd to fetch the key needs to be secured, requiring special privileges to modify it. Locally, points of attack would be the tool itself or the user's authorized keys file, or the server's public key. They're all files, so file permission restrictions would have to be circumvented. If the tool is not written in a type-safe language, then it could create additional vulnerabilities as well. In larger environments, keeping track of authorized_keys files for users and hosts, making sure they're (only) on the hosts they need to be on, and keeping them accurate and up-to-date can be tedious and error prone, even with a config management system. One could argue that that method allows for vulnerabilities that would not exist if the keys were managed centrally. Again, it depends on the quality of the sysadmins' work. The security requirements in an infrastructure are probably not the same for all hosts, so you could use a hybrid strategy, using a local authorzed_keys file for hosts that need greater protection (e.g., database servers, firewalls, DMZ hosts, etc) if that makes you more comfortable. (Generally speaking, I think too much uniformity can sometimes be a weakness).
