AuthorizedKeyCommand ldap

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

AuthorizedKeyCommand ldap

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

--
--Dan
Reply | Threaded
Open this post in threaded view
|

Re: AuthorizedKeyCommand ldap

Alexander Hall
On 12/11/17 23:49, 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 ?

AFAICT, he is using AuthorizedKeyCommand exactly as intended, generating
authorized_keys entries on demand.

What are you concerned about?

/Alexander

Reply | Threaded
Open this post in threaded view
|

Re: AuthorizedKeyCommand ldap

Paulm-7
In reply to this post by Dan Becker
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).



Reply | Threaded
Open this post in threaded view
|

Re: AuthorizedKeyCommand ldap

Dan Becker
On Mon, Dec 11, 2017 at 7:13 PM, Paulm <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: AuthorizedKeyCommand ldap

Stefan Johnson-2
On Tue, Dec 12, 2017 at 10:35 AM, Dan Becker <[hidden email]> wrote:

> On Mon, Dec 11, 2017 at 7:13 PM, Paulm <[hidden email]> wrote:
>
>
> 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
>

The AuthorizedKeysCommand option is supposed to be used in conjunction
with another option setting that determines the user that will call the
script.
This user should not be root.

The current version uses AuthorizedKeysCommandUser and the man page
states that it is recommended to use a dedicated user that has no other role
on the host than running the authorized keys commands.

The Red Hat Enterprise Linux 6 man page for sshd_config uses this other
option, instead.  AuthorizedKeysCommandRunAs.  This is like the above,
except if it is left empty, it is implied that the command gets run as the
user
logging into the system.

Hope this helps.
Stefan
Reply | Threaded
Open this post in threaded view
|

Re: AuthorizedKeyCommand ldap

Paulm-7
In reply to this post by Dan Becker
On Tue, Dec 12, 2017 at 09:35:27AM -0700, Dan Becker wrote:

> On Mon, Dec 11, 2017 at 7:13 PM, Paulm <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: AuthorizedKeyCommand ldap

Paulm-7
In reply to this post by Dan Becker
On Tue, Dec 12, 2017 at 09:35:27AM -0700, Dan Becker wrote:

> On Mon, Dec 11, 2017 at 7:13 PM, Paulm <[hidden email]> 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 ?

Also, because you're talking about authentication, I wouldn't be too
casual about handling errors.

Errors should be reported to syslog, not sent to /dev/null.

Reply | Threaded
Open this post in threaded view
|

Re: AuthorizedKeyCommand ldap

Edgar Pettijohn III-2
In reply to this post by Paulm-7
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 <[hidden email]> 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.
>

Reply | Threaded
Open this post in threaded view
|

Re: AuthorizedKeyCommand ldap

Paulm-7
> > > 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
> ;;

A solution that scales would use a regex that checks input for chars
not allowed in a username, and confirms the length of input doesn't
exceed the max length for a username.