This project seems to be a poor-quality re-implementation of openssh's agent forwarding by someone who doesn't fully understand ssh's key mechanisms. In fact, it's a good deal less secure than `ssh -A`, as it exposes the agent proxy both in a unix domain socket AND in a tcp socket bound to localhost -- the latter of which is accessible by any local user.
The README uses very vague language, but my guess is that the author does not understand the difference between agent forwarding with `ssh -A` and copying private keys and starting a new ssh-agent.
Also it's unlikely that the extra complexity and the risks that poses is outweighed by the espoused benefits.
This seems like the type of untrusted software plugin that results in having some horrible overlooked exploit that compromises your entire system. All so you could increase your security by some tiny margin.
What is the danger? That some untrusted application will use the agent and mess up your servers? That is bad, I admit, but it could be worse. 'ssh -A' is much worse.
The alternative? With 'ssh -A', a single compromised system will allow every user's key to be used. Not just potentially exposing all of the organization's servers, but all of the servers which all of the users may independently have access to! Those systems may also have users connecting with 'ssh -A', exposing even more systems, etc.
This might not be so bad if you only access your employee's servers and you have a few machines. It is really serious if you are a contractor, or have contractors.
If, say, you are a freelancer and you use 'ssh -A' to a client and the client's server is compromised, all of your other client's servers may easily become compromised.
A hack as described here, preferably using a sockets-only approach, can allow your organization to essentially pre-authorize users. They must login to a host with valid credentials, receive access to an agent (but not the key), and can then authorize to other hosts.
This is a largely quick hack and Proof-of-Concept done in less than 30 minutes. Ideally, it would be implemented entirely with Unix sockets and it could be implemented this way, but I had trouble getting socat to do this. More work with socat or writing some Python would be a reasonable long-term solution.
This does the opposite of 'ssh -A'. With 'ssh -A', a local agent is forwarded to an untrusted remote host. The agent lives on the client and the remote server can use your local keys for authorization.
This script allows you to connect your local SSH clients to a remote agent. The remote agent may be managed by another user. The use case is when you intentionally want to do this, allowing other users to authorize themselves with your key, without directly revealing the secret.
This is quite simply, a way to have a (somewhat) secure shared-secret with SSH. It is not a way to use your own secret, private key with an ssh client living on a remote host.
The only way that 'ssh -A' can replicate this functionality is if another user on the remote system connected to your (forwarded) socket and did an ssh-add. That is a reasonable alternative, but it would be difficult to automate that process in a secure way.
The README has been updated to note the danger of using TCP here.
Perhaps for more clarity, this almost does the same thing as doing:
ssh -R22:localhost:9022 user@rhost -- ssh -A $USER@localhost -p 9022
In this case, for this to have feature-parity, another user on the remote system would have to access your socket and do an 'ssh-add' with one of their prive keys.
The differences here being that:
* rssh-agent daemonizes and gives the same output as 'ssh-agent'.
* a single SSH connection is established, not two.
It is again important to note that this allows you to use but private keys without filesystem access to those keys.
7 comments
[ 3.9 ms ] story [ 25.4 ms ] threadThe README uses very vague language, but my guess is that the author does not understand the difference between agent forwarding with `ssh -A` and copying private keys and starting a new ssh-agent.
This seems like the type of untrusted software plugin that results in having some horrible overlooked exploit that compromises your entire system. All so you could increase your security by some tiny margin.
The alternative? With 'ssh -A', a single compromised system will allow every user's key to be used. Not just potentially exposing all of the organization's servers, but all of the servers which all of the users may independently have access to! Those systems may also have users connecting with 'ssh -A', exposing even more systems, etc.
This might not be so bad if you only access your employee's servers and you have a few machines. It is really serious if you are a contractor, or have contractors.
If, say, you are a freelancer and you use 'ssh -A' to a client and the client's server is compromised, all of your other client's servers may easily become compromised.
A hack as described here, preferably using a sockets-only approach, can allow your organization to essentially pre-authorize users. They must login to a host with valid credentials, receive access to an agent (but not the key), and can then authorize to other hosts.
This does the opposite of 'ssh -A'. With 'ssh -A', a local agent is forwarded to an untrusted remote host. The agent lives on the client and the remote server can use your local keys for authorization.
This script allows you to connect your local SSH clients to a remote agent. The remote agent may be managed by another user. The use case is when you intentionally want to do this, allowing other users to authorize themselves with your key, without directly revealing the secret.
This is quite simply, a way to have a (somewhat) secure shared-secret with SSH. It is not a way to use your own secret, private key with an ssh client living on a remote host.
The only way that 'ssh -A' can replicate this functionality is if another user on the remote system connected to your (forwarded) socket and did an ssh-add. That is a reasonable alternative, but it would be difficult to automate that process in a secure way.
The README has been updated to note the danger of using TCP here.
ssh -R22:localhost:9022 user@rhost -- ssh -A $USER@localhost -p 9022
In this case, for this to have feature-parity, another user on the remote system would have to access your socket and do an 'ssh-add' with one of their prive keys.
The differences here being that:
* rssh-agent daemonizes and gives the same output as 'ssh-agent'.
* a single SSH connection is established, not two.
It is again important to note that this allows you to use but private keys without filesystem access to those keys.