On 9 jul 2008, at 19:40, AMuse wrote:
Leif: I'm not sure I understand the problem you are facing clearly.
What is the security problem in keeping your customers' login
passwords available to employees?
The security problem lies in trusting the employee after he quits his
job. At that point he might save all the customers' passwords and use
them for personal gains without our authorization. Currently this is
only a hypothetical threat, but still a risk that must be considered.
The remedy to this would be exchanging every password that the
employee has ever had access to, but this would require an increasing
amount of effort as our customer base grows.
For that matter, why would you want people to have access to each
others' passwords?
This is not about people's personal passwords, but the password that a
customer provides us with so we can get our job done on their server.
As a rule of thumb we have very little control over the customers'
servers, and in the case of shared hosting we might even be using the
one and only user account that the customer has access to, so
exchanging the password there would also cause additional effort for
the customer.
That is usually a security risk in itself, and makes incident
response and forensics a lot more difficult.
This exactly what we have realized, but due to the nature of our
business we need shell or sftp access all the time. Classical
solutions, such as distributing public keys using LDAP or centralized
authentication using Kerberos are not feasible as they would require
modifications that we're not entitled (or even authorized) to do to
the customers' servers.
With the default authentication options of SSH (none, password,
keyboard-interactive and public key) only public keys seem to enable
keeping the secret out of the hands of employees.
That's why we're looking for a solution that would only require adding
a row to the authorized_keys file on each new server we need access to
and a private key that should never leave our trusted server but only
be used for calculating responses to the authentication requests.
/Leif Åstrand
Leif Åstrand wrote:
Dear Experts,
I'm working at a consulting agency facing the security problem in
keeping our customers' login passwords available to employees. This
basically means that when someone quits we would have to replace
all the passwords that he has had access to.
The first step towards a better solution would be using public key
authentication, but if the private keys where available to the
employees we would still be facing the same problems.
The next step would be keeping the private keys stored out of reach
from the employees, who would only forward the authentication
challenges to the entity managing the private keys, i.e. the same
concept as normal agent forwarding but in reverse.
We've constructed a simple proof of concept consisting of three
parts:
1) A "key server" where a ssh agent is loaded with private keys.
2) A wrapper on the key server listening to a tcp port and
forwarding all connections to the unix socket used by the ssh agent
there.
3) A "fake" ssh agent for the clients, which opens a unix socket
and forwards all connections through a ssh tunnel to the tcp port
on the key server.
By pointing SSH_AUTH_SOCK to the socket of the fake agent one can
then use the private key on the key server for authentication when
connecting to a host with a matching public key. Limitations with
this simple solution include that they leave tcp ports open that
anyone with access to clients or the server might use and that the
key server has no functionality for providing varying levels of
access depending on where the employee is allowed to log in.
At that point we realized that we do not have the resources to
develop an industrial strength solution, that we are probably not
the only company facing these problems and that there might already
exist a system, or at least bits and pieces, that might solve our
problem. We've been looking for a solution out there, but all the
search phrases we can come up with only give us even more
descriptions on how normal agent forwarding works...
Is anyone of you aware of a system that we might use, or even
existing pieces that would fit into the pattern?
/Leif Åstrand
