Re: SSH Private Key Handling Policy?

[Paul Hosking <phosking () employees org>]

On Wed, Aug 5, 2009 at 8:45 AM, Matt Harrison<mharr19 () gmail com> wrote:
> We've suggested the
> ssh-agent approach outlined in Daniel Robbins article here -
> http://www.ibm.com/developerworks/library/l-keyc.html - but they don't
> want to take that approach because it requires them to enter the
> passphrase which would have to be stored in the script calling the
> service account login process.
>
> Any ideas?

It looks like part of the issue is compartmentalization.  Why do so
many users have access to this key?  And how can you limit access to
the key or what hosts accept that key?

The devil's in the details of how these service accounts are used.  If
you have one host talking to many hosts then that allows much more
control over access to the key.  If it is many hosts talking to many
hosts then another consideration is to look at whether there are
groups of hosts that interact and generating different keys for each
group.

One way to limit access to keys is to house them on a bastion host.
Access to that host should be limited to only those individuals that
mange the tasks associated with those service accounts and other
functions on the bastion host.  This should limit who can get
immediate access to the service account key(s) even if the accounts
interact with hosts that allow widespread access to the service
account on the given host.

As described, this would work well for a one-to-many process.  Let's
say host A is our bastion host and hosts B and C are servers that need
to run jobs via our service account(s).  Talking A -> B and A -> C is
all fine with keys only on A.  But what if we needed to move data B ->
C (neither of which houses a key)?  We'll need a bit more
configuration to support many-to-many functionality.

This is when we'll need SSH Agent, agent forwarding, and Keychain to
help make it easy.  Keychain is a nice script that helps manage
ssh-agent.  With this combination, we can load our password-less
key(s) in to the agent (no password prompts and hard-coded credentials
in scripts) and SSH from our bastion host to our first host (A -> B)
while forwarding agent requests (ssh -A serviceacct@hostB).  Once
logged in to B, we can then scp data to C and authentication is
handled by our agent (with our key) back on our bastion host.

It should be noted that root can bypass your efforts.  Again with the
details but it sounds like you have a lot of people with carte blanc
access to root on these systems.  Anyone with root can obviously add
their own keys to your service accounts.  And root on a host with a
forwarded agent socket (B and C in our above example) can trivially
access that connection to log in to other hosts using keys cached by
the agent as long as that socket is available / ssh session is active.
 While they can't get a copy of the keys in this manner, it does offer
a window of opportunity to move around as your service account, adding
their own keys to the service account on various hosts, etc.  As you
can see, we can do a few things to mitigate risks with SSH keys.  But
we still have to address the fundamental issue of who gets privileged
access.

One final note – you can further mitigate the risk of password-less
SSH keys by restricting what hosts they can be used from and what
commands they can do.  The AUTHORIZED_KEYS file can store both the
public key and restrictions to it's use.  That is, assuming root
doesn't alter it.

------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------