On Tue, Dec 12, 2017 at 05:25:27PM -0800, Paulm wrote:
> 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"
case $user in
user1)
do stuff
;;
user2)
do stuff
;;
user3)
do stuff
;;
*)
invalid user stuff
;;
esac
> > 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.
>
