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? For that matter, why would you want people to
have access to each others' passwords? That is usually a security risk
in itself, and makes incident response and forensics a lot more difficult.
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
