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 ?
--
--Dan
