Discussion:
[mosh-devel] Secure agent forwarding with Mosh
Keith Winstein
2017-11-09 04:55:55 UTC
Permalink
Hi folks,

We developed a (prototype) tool that does secure agent forwarding and works
with Mosh. Would be grateful for testing and feedback:
https://github.com/StanfordSNR/guardian-agent

Compared with traditional ssh-agent forwarding, this tool provides
more-constrained agent forwarding that we think could safely be enabled on
any connection. It works alongside any version of Mosh or SSH. Users run
sga-guard (the agent) on their local machine, in a separate window
alongside the interactive session. sga-guard prompts the user to approve
forwarded ssh requests from the intermediary host, either with an X11 popup
or in that second terminal window. Unlike with ssh-agent forwarding, the
agent can enforce limits on which intermediary host can run which command
on which servers.

Based on feedback to this beta/prototype, maybe we can agree on a good way
to incorporate these techniques more deeply into Mosh. (Even if it's just a
mosh -A flag that sets this up automatically instead of needing a second
terminal window.)

There is a more detailed writeup in the README:
https://github.com/StanfordSNR/guardian-agent

We're grateful for feedback, whether about the usability of the tool, the
underlying mechanism, or the best way to make this smooth for Mosh users.

Thanks all,
the Guardian Agent developers (Dima Kogan, Henri Stern, David Mazieres,
Keith Winstein)
Daniel Roethlisberger
2017-11-09 14:43:51 UTC
Permalink
Post by Keith Winstein
We developed a (prototype) tool that does secure agent forwarding and works
https://github.com/StanfordSNR/guardian-agent
Compared with traditional ssh-agent forwarding, this tool provides
more-constrained agent forwarding that we think could safely be enabled on
any connection. It works alongside any version of Mosh or SSH. Users run
sga-guard (the agent) on their local machine, in a separate window
alongside the interactive session. sga-guard prompts the user to approve
forwarded ssh requests from the intermediary host, either with an X11 popup
or in that second terminal window. Unlike with ssh-agent forwarding, the
agent can enforce limits on which intermediary host can run which command
on which servers.
Based on feedback to this beta/prototype, maybe we can agree on a good way
to incorporate these techniques more deeply into Mosh. (Even if it's just a
mosh -A flag that sets this up automatically instead of needing a second
terminal window.)
This is an interesting project. However, note that all I'm
looking for is for mosh to support a -A workalike of ssh -A. If
it's not a drop-in replacement for ssh -A for typical use cases,
or can be configured that way easily, then it's not the solution
to my problem.

Specifically, I am not interested in manually approving agent
requests. The ratio of hassle to mitigated risk is unreasonable
in my opinion. It addresses a narrow category of attacks while
not helping against other attacks with similar prerequisites and
risk (e.g. injecting commands into TTYs of SSH sessions from the
compromised system, or replacing a legit auth challenge on the
compromised server as it is being handed to the client machine's
agent where it will be approved by the user). So unless the
confirmations can be easily removed by configuration or patching,
I won't be overly excited about this.

Contrary to your README document, I don't believe the risks of
agent forwarding through a compromised system are
underappreciated. Rather, they are being conciously accepted,
especially as they are not going away even with manual approvals.

As a minor nitpick, I would prefer a solution that actually uses
the same protocol and hence does not need additional network and
firewall considerations on top of mosh.

-Daniel
--
Daniel Roethlisberger
http://daniel.roe.ch/
Keith Winstein
2017-11-13 09:04:38 UTC
Permalink
Post by Daniel Roethlisberger
Specifically, I am not interested in manually approving agent
requests. The ratio of hassle to mitigated risk is unreasonable
in my opinion. It addresses a narrow category of attacks while
not helping against other attacks with similar prerequisites and
risk (e.g. injecting commands into TTYs of SSH sessions from the
compromised system, or replacing a legit auth challenge on the
compromised server as it is being handed to the client machine's
agent where it will be approved by the user). So unless the
confirmations can be easily removed by configuration or patching,
I won't be overly excited about this.
Thanks for your feedback, Daniel. I think if you try it, you will be
pleasantly surprised.

On the issue of "manually approving agent requests" -- you don't have to.
The local agent gets to see and approve each request, but the user can
"allow forever" and doesn't need to approve each request manually.

Re: "additional network and firewall considerations," Guardian Agent just
runs over autossh. If you can SSH to the intermediary, you can run Guardian
Agent.

On the "other attacks with similar prerequisites" -- if I understand you,
Guardian Agent already prevents these attacks. The "legit auth challenge"
is bound to the triple of { intermediary machine, command, server }, so
it's not possible to "replace" a legit auth challenge and use the user's
credentials to execute a different command (or on a different server, or
from a different intermediary) than what was requested. (The way that
Guardian Agent works is that the local agent actually issues the command to
the remote server before handing over the session to the intermediary.) So
while a compromised intermediary machine can *ask* to execute an evil
command, the agent will know about it and it won't match some prior "allow"
rule in the local configuration.

(To be clear, this works best for commands like 'git fetch-pack' to a
particular repository or something like that, where the command is not
going to allow arbitrary follow-on commands to be executed. If the user
wants to execute a shell or some other interactive session, then yes, this
doesn't prevent a malicious intermediary from later inserting arbitrary
input into the session. Probably the best thing in that case, if you really
don't trust the intermediary, would be to just to use the intermediary to
ferry ciphertext bytes and not to let it see the plaintext at all. But even
in that case, at least Guardian Agent still lets you lock down which
intermediaries can connect to which remote servers.)

-Keith

Loading...