On Tue, Dec 12, 2017 at 09:35:27AM -0700, Dan Becker wrote: > On Mon, Dec 11, 2017 at 7:13 PM, Paulm <pa...@tetrardus.net> wrote: > > > 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). > > > > > > > > > Thank you for the above > > We have someone suggesting we implement something similar to the above with > a twist. > > The script they call acts similar to this > > user="$1" > hostname="$(hostname)" > curl -s -q -m 5 -f -H "Authorization: Token ${secret}" " > https://auth.site.com/sshkeys/?user=${user}&hostname=${hostname}"; > 2>/dev/null > exit $? > > > My main concern comes from the fact this process is being ran as root and > injecting the username as an arg "$1" > > Example : > > What happens if someone runs ssh '"&rm -rf /'@host, is there a sanitation > in the ssh daemon ?
Your script will live in the filesystem, potentially executable by other programs/users, not just sshd. Regardless of any kind of input sanitation sshd does, your script should probably do it too - or be extra careful about how it handles the input.
