Re: Reverse agent forwarding architecture
- From: Leif Åstrand <leif@xxxxxxxxxxxx>
- Date: Thu, 10 Jul 2008 09:58:04 +0300
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 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?
- Prev by Date: RE: Deliberately create slow SSH response?
- Next by Date: Re: Deliberately create slow SSH response?
- Previous by thread: Re: Reverse agent forwarding architecture
- Next by thread: sshd and chroot logging