Mosh: SSH Agent Forwarding

[dt]

Would be great to be able to forward local SSH agents. Seems to ignore ForwardAgent yes in ~/.ssh/config

[jlynn]

:+1: I can't use mosh for this very reason. I need to be able to connect to other machines in the environment I'm accessing plus use my ssh key to push/pull code from github.

[peterjeremy]

This requires tunnelling the agent request from the server back to the client.

[phmarek]

I'd be interested in this feature, too.

[dt]

If #41 ends up being resolved be adding tunnels for arbitrary octet streams, agent forwarding should be trivial to add on top of that.

[thrillcall]

+1 for being able to ForwardAgent. In our case also critical for getting code to/from GitHub on remote servers.

[dbanck]

+1 I need the agent for sudo authentication.

[clneagu]

+1 mostly for github

[avleen]

+1 also!

[stianeikeland]

:+1: .. this would be very useful

[nostra]

+1

[plathrop]

+1

[plathrop]

Hard to resist the urge to say nothing but '+1' to @Mkaysi's comment...

[keithw]

All right, folks, the message has been heard loud and clear! We will put this on the roadmap for a release, probably the one immediately after 1.2. No need to keep +1ing - we will do it.

[Hidendra]

Any word on if this is still planned for 1.2 or near/after 1.3?

[chekhovs1]

+1 from me. I naively thought that this was implemented and after building mosh at the server systems and running it, realized that this is not quite ready yet. Any updates on the timeline?

[kergoth]

+1 for me as well, this is a blocking issue for me, as I do remote development, using local keys to communicate with upstream SCM repositories.

[ogrisel]

+1 mostly for being able to work with github when doing remote development from EC2 machines.

[tsuna]

Sorry for spamming everyone, GitHub doesn't appear to have a feature to get notifications of changes on an issue without +1'ing it. So +1 for me too.

[andreypopp]

@tsuna see at the bottom of any issue page

[Gonzih]

+1 for agent forwarding

[anahata0108]

Came to report another issue, saw this. Key forwarding is absolutely required to my workflow and I am seriously concerned about the way the mosh devs handle ssh keys if it wasn't baked in from the beginning.

[keithw]

Mosh works fine with SSH keys (or any SSH login method), since we just use SSH itself to handle authentication.

We don't allow the user to forward ssh-agent requests because, frankly, nobody has contributed the code and we haven't gotten around to it.

But in general, ssh-agent forwarding is inappropriate for high-security environments. There is little to stop a compromised remote host from requesting your credentials to do 'rm -rf /' (or modify authorized_keys) on a bunch of remote hosts. The user doesn't find out what the remote host wants to do with your credentials; the ssh-agent protocol just lets a process use your key to sign any request. If you forward ssh-agent, then it lets a remote host use your key to sign any request. It's almost the same security characteristics as just copying your credentials to the remote host in the first place -- but not quite, since the remote host loses access to your credentials after you log out (unless it uses them in the meantime to insert its evil key in your authorized_hosts file elsewhere).

I am surprised by all the people saying we need this because they are security freaks. You don't forward ssh-agent if you are a security freak. ssh-agent forwarding is a convenience feature that should not be on by default and should only be used when connecting to semi-trusted hosts.

@apeiron, no need for concern. A process that does ssh-agent forwarding just takes bytes from the remote host and ferries them to the local host's ssh-agent and similarly for the reply. It doesn't touch secret data. All it does is make remote requests to the ssh-agent look like they are coming from the local host. For the reasons above, that's a risky thing to allow, but actually making it happen is easy.

[maxcom]

@keithw ssh-agent has confirmation feature that can protect you from that scenario when remote host does 'rm -rf /' on other remotes.

ssh agent forwarding is really good for accessing git repository from development and testing servers. Also it is good for proxying ssh connections through other hosts when there is no direct connection.

[keithw]

Tell me more about this confirmation feature. My understanding is that there is no way for the agent (and therefore the local user) to learn what command the remote host intends on executing once it is able to authenticate. All the protocol allows is for ferrying public-key challenges and the associated responses.

[maxcom]

Yes, you can not controll what command is executed. But you can control
what hosts are involved.
31.10.2012 9:54 пользователь "Keith Winstein" [email protected]
написал:

Tell me more about this confirmation feature. My understanding is that
there is no way for the agent (and therefore the local user) to learn what
command the remote host intends on executing once it is able to
authenticate. All the protocol allows is for ferrying public-key challenges
and the associated responses.

—
Reply to this email directly or view it on GitHubhttps://github.com/keithw/mosh/issues/120#issuecomment-9933956.

[keithw]

I don't think that's right. The ssh-agent only learns which identity (key pair) the requesting process is trying to use. It doesn't learn which host the request came from (remember, forwarding makes the request appear to be coming from the local machine) and it doesn't learn which remote server that process is trying to connect to, or what command the process is trying to execute on the remote server. Happy to be corrected though if my understanding is off.

[maxcom]

Yes, it seems that you are right. So the better way to improve ssh-agent security is using different keys for different groups of servers. Anyway, that is generic weakness of single sing on systems. SSH has agent forwarding feature and it will be nice to have it in mosh.

[tsuna]

I think for most people waiting on this issue, this isn't as much about conveniency as it is about security.

[rinne]

But with ssh you can select which connections have agent forwarding and which not. So if you log into the system you don't trust, you shouldn't forward your agent to this.
I don't know if this is the case with OpenSSH, but at least the commercial one works so that for agent forward connections, ssh server adds a "forwarding identifier" so that the agent itself is able to see over what kind of path the forward is opened. Even if the system at the end of the path is compromised, it can also forge the end of the path, not the path that leads to it from the client.

[rinne]

And yes, agent forwarding for mosh is a must! Much more important than X11 or generic tcp stream forwarding.
It's also something that is not particularly performance critical, since agent connections don't happen all the time and individual sessions are typically in the magnitude of kilobyte or less.

[blueben]

Indeed. While I appreciate the hard work that goes in to the project, I don't think it is appropriate for the mosh project to determine which risks its users should find acceptable. If SSH supports it, mosh should support it. In this case, the scenario you are concerned about is most often found on bastion hosts to access machines which are otherwise inaccessible. If the user doesn't use ssh-agent forwarding, then they need to keep keys on the bastion host, which results in the exact same vulnerability should that host be compromised. There is no improvement in security simply because mosh doesn't support the feature. If I need additional security measures for my keys, I'll make sure they have passphrases or I'll use multi-factor auth with a FOB.

Put bluntly, mosh loses users because this feature doesn't exist. I can only use it in a few of my active terminals, holding out hope that I will eventually be able to use it for all my workflows when this feature is added. I evangelize mosh quite often and loudly, but the lack of agent forwarding is a common complaint. I evangelized to apeiron and he wants the feature badly enough that he came here to complain, so QED I suppose.

And yes, this feature is far more important than X11 or stream forwarding. I'm willing to bet your best and most common users are IT pros. This feature is far more desirable to them than these other features.

[keithw]

Again, the primary reason we don't have ssh-agent forwarding is that nobody has contributed the code.

But I don't agree that Mosh should necessarily support insecure protocols just because SSH does. The idea of Mosh is to improve on SSH, and one way is by having a simpler and more robust security story. SSH's many security holes have largely been because of its complexity and the large number of options (including letting you negotiate weak ciphers and weak protocols, leading to downgrade attacks). I don't think we want to follow SSH down every dark path.

For bastion hosts where the problem is connectivity, I (1) agree that copying and forwarding credentials have similar security risks (this is why I think it's silly all the people who think ssh-agent forwarding is so much more secure) but (2) disagree that either of these behaviors is justified.

The right approach is for the bastion host simply to proxy the (encrypted, authenticated) connection to the other machines, and to make the authenticated connection end-to-end. There is no need to trust the bastion host at all or give it credentials -- we are just using it as a network proxy. We can make Mosh (or socat) do this and it will be more secure than ssh-agent forwarding.

[treed]

For the bastion host problem in particular, this is one option (with ssh) on how to achieve that without agent forwarding:

host hidden
ProxyCommand ssh bastionhost nc -q 5 %h 22

OTOH, I agree that agent forwarding is pretty convenient for other cases. For me personally, what really keeps me from being able to use mosh at work is the fact that I need to open up new firewall holes. But I wouldn't say that agent forwarding is good for security.

[blueben]

And again, it has not been demonstrated that agent forwarding is inherently insecure to such a point that it should not be implemented in mosh. Further, as I pointed out above, any problems are easily mitigated with key passphrases and multi-factor auth. In addition, bastion hosts are well understood and oft used, usually as more than just a network proxy. In many cases, it's used as an intentional and auditable choke-point with tools which folks do not want installed on other servers. In other words, direct end-to-end connections are exactly what those environments are trying to avoid.

Let's not try and throw away everyone's workflows because we can't imagine the needs of other environments or they don't fit into one specific mindset. If we begin our argument with "the only right way is", we either know everything about every possible environment or we're fooling ourselves. If mosh can implement another, better way to directly reach hosts behind network choke points, that's great. But that does not make it unnecessary to implement this feature.

[martinrehfeld]

IMHO, it would make sense focusing on finding someone that actually can implement agent forwarding (maybe as a sponsored feature?). Arguing over it does not make the need go away. It's a bit of a shame that mosh cannot be enjoyed in a lot (dare I say: most) use-cases.

[romaninsh]

Please provide instructions how to support second host authentication without storing the key on intermediate server. If forwarding is undesired, what's the proper alternative?

[blueben]

@romaninsh It has been proposed that nobody use jump servers, but instead directly connect to everything everywhere. I suspect that anyone who proposes this may not realize that this is not always possible, and in fact a violation of a number of security protocols in many environments.

[rinne]

@romanish I don't think there is such alternative. If you don't count using password in second authentication :).

I'd say that need to use git, rsync, scp, et cetera is full justification to have agent forwarding. Those are often needed even if intermediate hosts are not used in logging to intranet hosts.

[keithw]

Using a jump server is fine. _Trusting_ a jump server with the plaintext of your communications, and the ability to execute arbitrary commands, is unnecessary if it's really just a jump server.

[blueben]

I'll make my own trust decisions, thanks.

[keithw]

@romanish: The "proper" alternative would probably be a protocol that let you authorize a host to perform some operations (e.g. to do a git push to github for a particular repository) using your credentials, in revocable and tracable fashion, without giving away the store.

The problem is that ssh-agent was not intended to be forwarded. The ssh-agent can't tell the difference between a local request and a remote one, and it can't tell who is making the request or what they want to do with your credentials. So there's not really enough information in the protocol to make sane security decisions. In most cases it's basically better to actually store a private key on the remote server itself (and give that identity limited authorizations), rather than blindly forward requests from the remote server back to your ssh-agent.

[blueben]

A private key store on the remote server. Did you just try to solve a perceived security issue by adding _more_ complexity? LOL

Come on, as security risks go, this one is far to the bottom of an extremely long list. While it is theoretically possible, the fact remains that if your jump/gateway server is compromised such that an attacker can request your keys then you've already lost the game and not-forwarding does absolutely nothing to improve your posture at that point.

[blueben]

Addendum after some more contemplation.

The issue here is that you're trying to solve the wrong problem. The keys are not what is important to defend against an attacker. What we actually want to defend is access to other machines. In that context SSH-forwarding is not the actual problem, but rather the use of keys without passphrases and hosts which allow access without multi-factor challenges. You can't solve the problem of poor key hygiene by making keys even more difficult and complex to manage.

[tsuna]

This issue is about having some support for SSH agent forwarding with Mosh. Could we please not turn this issue into a debate on whether this is more or less secure than another alternative, or which way is the best?

[romaninsh]

@keithw I understand your reasoning. Any rogue app on any host you log into can potentially request as many authentications as it wants without me noticing. (http://serverfault.com/questions/112920/how-can-i-activate-ssh-agent-confirmation-in-macosx-leopard)

It's also clear that forwarding octets alongside your connection is a no brainer for many and is essential feature. Clearly we are forwarding keystrokes all the way to the server, why only keystrokes.

I appreciate your effort to solve the problem with agent but it has nothing to do with mosh and by avoiding this feature you will alienate your users until eventually someone would fork your code and add the feature.

My suggestion would be to add this feature but put a big warning when it's used prompting user to secure their ssh-agent. As the popularity of "mosh" grows your message will make more people aware of the problem and would make it easier to come up with a solution.

Unfortunately I am in a whole different development universe, otherwise I would have helped you with the patch.

[keithw]

Thanks romaninsh. Yes, I think we will support ssh-agent forwarding with a flag like --unsafe-agent-forward, and we will also notify the user (with a popup message in the blue bar) when an agent request gets made. I suppose we could also just let the user turn forwarding on and off at runtime with a key combination.

I also would like to support gateway connections, with a syntax like mosh --via jumpserver remotehost, that don't trust the gateway host (any more than they trust any random gateway along the network path).

That's the plan, at least. Anybody who wants to get involved is welcome to contribute and join in on the mailing list or IRC channel.

[romaninsh]

@keithw Great decision! Me and everyone else really appreciate what you are doing, thanks for your patience.

[mbelgin]

The lack of ssh-agent is a show stopper for Mosh... Thanks for your considering to support it.

[rinne]

I must say that using language like unsafe-agent-forward in command line flags is quite misleading. I accept that agent forwarding should be something that needs to be explicitly enabled either by command line option or an item in a configuration file, because it enables additional way to authenticate and it may not be something that all users want and sometimes the user may want to log into a system that he doesn't trust, in which case forwarding agent connections from these systems is unwise.

A few points though:

1) If the user is running an authentication agent in his desktop machine, he must make two more or less conscious decisions in order to have his key to be visible in the remote host through agent connection. He must add the key to the agent and allow agent forwarding for ssh (or mosh once implemented) for the connection to that particular remote host.

2) The private authentication key can not be stolen via agent connection, but instead cryptographic operations (sign, decrypt) can be performed instead and they can be performed only while the connection with agent forwarding is open. In order for this being a real problem, it requires the system that is connected with agent forwarding enabled to have either compromised security or crooked administrator. While neither is unheard of, it would be much more damaging in a system like that to authenticate to another remote system using a password, which can be easily stored and used whenever the attacker wants until the password is changed or indefinitely, if the attacker installs some kind of backdoor using the password.

3) Same problem is in cases where the user is forced to store private authentication keys to remote hosts. In case these hosts are compromised, the key files can be stolen and passphrase to these keys can be snooped later or exposed to brute force password attacks or something more clever. The stealing of the key files and somehow acquiring the passphrase doesn't have to happen at the same time, so the attacker has time.

4) While forwarded agent can naturally also be used in installing backdoors just like the password, the time window for that is shorter and as said earlier, the user has control over which credentials are stored to the agent.

5) While standard agent in OpenSSH distribution doesn't have any method to require user confirmation for individual agent operations (i.e. requests to perform cryptographic operations on the private key stored to the agent) there is no reason why it must be so. Actually at least some agent implementations do just that and in addition to that also allow configuration per key to enable interactive verification for just some keys. Also other security features could be added to the agent. A couple ones intuitively coming to mind is to (add configuration to) reject agent operations if the desktop is idle or locked and allowing adding of keys without passphrase so that passphrase is asked only when the key is used for a first time and forgetting the passphrase if the key is not used within some configured period. I think that there are also some agent implementations that are doing just that (and honestly I've personally implemented one in past).

What I'm trying to say, is that mosh should have agent forwarding in order to be a viable solution for infinite number of administration and software development scenarions, and adding agent forwarding to mosh so that it's enabled by command line parameter or configuration file option is not a step backwards in security but clearly forwards, because it in most cases eliminates the need to store ssh private keys to remote hosts as well as use of passwords when logging to another remote host from these ones. "Logging to another remote host" in most cases mean using git or scp rather than actually opening an interactive shell connection to anywhere while ssh being just a vehicle for data transport and authentication.

I find it a bit peculiar that some mosh people have quite prejudiced attitude against the authentication methods in ssh, which is quite time proven, and at the same time mosh is using ssh for authentication and connection setup.

As said earlier, I volunteer to help in specifying the feature and provide with an analysis of security and listing the caveats, but I don't have time to familiarize myself with mosh implementation enough to be able to write the channel code required in the implementation.

However, OpenSSH is distributed with BSD-like license so at least the code to create agent listeners in a safe way (for proxy listeners opened by mosh server) and also connecting to ones (for mosh client to connect the local agent listener when receiving a forwarded agent connection via mosh connection) can be either grabbed from there or alternatively reimplemented using that as a security guideline.

[martinrehfeld]

+1 for cutting the --unsafe-agent-forward crap and using familiar ssh CLI switches, i.e. -A in this case. Either way, getting Agent Forwarding into mosh is the important part here.

[romaninsh]

+1 on "unsafe-agent-forward" as it was decided by the author. Please pay some respect to the person who gave us such a wonderful tool. If you think you could do better, fork and change the argument to whatever you want.

I run an open-source project of my own, and It's a hard job. Please respect the time of someone who is contributing to the community.

[blueben]

We can respect the author and his project and still criticize his opinion on a single matter. Forking is an action of last resort. Open source is not the place to be if you can't handle dissenting opinions, corrections of fact, and feedback in general. Please don't disrespect the process of open source by telling people to fork off over a discussion about the merit of a feature. This "My way or the highway" business has no place here.

On Dec 11, 2012, at 12:55 PM, Romans Malinovskis wrote:

+1 on "unsafe-agent-forward" as it was decided by the author. Please pay some respect to the person who gave us such a wonderful tool. If you think you could do better, fork and change the argument to whatever you want.

I run an open-source project of my own, and It's a hard job. Please respect the time of someone who is contributing to the community.

—
Reply to this email directly or view it on GitHub.

[rinne]

@romaninsh Been running software projects, open and otherwise, for 25 years and never seen a well documented reasoning against my (usually quite good) plans as sign of disrespect. Did you read my message at all? If you did, did you understand any of it?

[keithw]

Hi folks, let's try to keep the thread here relatively on-topic. (Or feel free to move ancillary discussion to the mosh-devel mailing list.) I appreciate everybody's feedback. The important thing now is to implement the feature, which probably requires a reliable buffered flow-controlled octet stream channel to carry the bytes back and forth. (I don't really want to get stuck depending on any length limit of these requests and replies. And I also don't want to get stuck implementing a protocol that mostly works but later we learn we need revisions and have to make a breaking change again.)

Anybody who wants to help with that is very welcome -- please get in touch on the mailing list. The time for discussion of exactly what the argument should be called is probably not now.

[jbaber]

Hm, I wonder if mosh ever got around to supporting agent forwarding... Whoa!

[ghost]

I'd love to use mosh while I'm commuting on the train. Regular ssh has issues with sketchy mobile service. Without ssh-agent support, however, it's a total non-starter.

I VPN into our data center. It's the only way in. I then gateway through a primary server where I do most of my work. All the hosts in our environment are trusted, since nobody outside our ops team has access.

And, as an above commenter said some months back, "I'll make my own trust decisions, thanks."

Adding this feature does not stop "security freaks" from simply not using it. NOT adding this feature, however, stops those of us with use cases for it from using Mosh. I think it's quite clear which is the better state of affairs.

[djmitche]

Security freaks are already not using mosh. It's got a long way to go to prove itself to the level that OpenSSH has. Agent forwarding would be nice, but with or without it, this isn't a tool to use on critical systems.

[romaninsh]

This feature is high on the list: https://docs.google.com/document/d/10o-TLA03bY4cZzEIZR-5wKmBecvYKpOEFRqSJFbIm3M/edit. I suppose we could put together some bounty on https://www.catincan.com

[rinne]

Actually I have an idea of how this could be implemented with reasonable effort and generic tunnels for that are not (necessarily) needed. Since all known agent flavours use more or less similar packet based protocol, I think mosh-server and client should parse it enough so it can just send the request packets back and forth as a separate protocol items and handle the stream connections only locally to the agent (and upstream ssh client making auth request). Then it could just timeout the requests rather than use blocking etc.

[jbaber]

@romaninsh Looks like you just volunteered to set up a catincan bounty and I just volunteered to pledge the first $10.

[steakknife]

Public critiquing is fine, there could be something obvious missing.

---

Implementing SSH Agent Forwarding for Mosh will let anyone securely log into other systems, while keeping their private keys safe on their trusted devices.

https://github.com/keithw/mosh/issues/120

If you haven't tried it already, Mosh is awesomesauce, especially for office warriors* that have to switch WiFi connections frequently or debugging something half-way across the world while on the train home.

Once you try Mosh, you'll never go back.

http://mosh.mit.edu/

• Fresh out of ninja hacker pirates. Overstocked on black helicopters and creepy surveillance vans though.

---

at https://www.catincan.com/proposal/mosh/ssh-agent-forwarding-mosh

Doubtful if anyone else can see it yet.

[steakknife]

I took a picture of a security freak once, but it came out blurry. ; )

Not waiting on hacker news visibility or CIH approval, it doesn't seem all that hard to ask some Googlers and make a hackathon weekend out of it. Notes from Timo or maybe a G Hangout would be awesomesauce.

[steakknife]

This proposal has been closed.

[keithw]

I really appreciate the entrepreneurialism being shown here -- I'm happy to mentor anybody who wants to work on this feature! Most of the main developers hang out in irc.freenode.org #mosh, or we can discuss over email ([email protected]). Please let me (and mosh-devel) know if there is something we can be doing to encourage this to happen. (I don't quite understand what happened with the opening/closing of the catincan thing, but in any event we are happy to help anybody who wants to put in the work to make this happen.)

[rinne]

I actually started to patch it together a while ago. I think it's a few days' work once I figure out how protobufs stuff work, how to push transport packets directly from the mosh-server serve() to protocol, and over overcome my natural resistance against c++ coding. Given all that, it becomes only a matter of finding those few days.

I think there are no real protocol compatibility issues, because the agent forwarding must be explicitly turned on anyways in server, so if this is not done, server never sends any agent related stuff downstream.

[romaninsh]

I'll donate at least $25, but I think catincan feature must be initiated by developer. https://www.catincan.com/node/add/proposal @keithw , would you mind creating it?

[rinne]

http://mailman.mit.edu/pipermail/mosh-devel/2013-May/000499.html

You can channel your donations to me :).

[billwanjohi]

@rinne's solution: #423

[ricardobeat]

:arrow_up:

[kenrestivo]

I am solving this problem with the following hack:

ssh -n -f [email protected] 'echo "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK" > ~/agentsock; sleep 1000000'

And then of course make sure I have done ssh-add on my local host, as per normal ssh-agent setup, and have ssh-agent running too.

Then in my mosh shell on the remote host, I just do:

. ~/agentsock

And away I go, ssh-forwarding with impunity.

[rinne]

Pretty much ruins the idea of automatic roaming, doesn't it?

[lexinator]

I do something similar except for ssh I use autossh. I also make a symlink to the most relevant ssh-agent pipe in my home directory and all my shells reference the symlink. Though I was doing this before my use of mosh.
https://github.com/lexinator/dotfiles/blob/master/.zshenv#L6

[vgulch]

+1 for agent forwarding

[Kroisse]

:+1: for agent forwarding

[dangermike]

+1.

[cofyc]

+1 Is it possible?

[MaximF]

Voting for agent forwarding!

[Sheco]

Agent forwarding is an important feature. +1

[sulphur]

+1

[ksalman]

+1 agent forwarding would be perfect

[salehi]

+1

[G10h4ck]

+1 agent forwarding would be perfect

[genjix]

would love this. mosh is already a great tool.

[patrickod]

+1 if this is possible. Would make life much easier

[dshadowwolf]

Actually... why couldn't mosh-server work as the 'key agent' process on the machine its running on and have the client forward the key to it that was used for the ssh connection? During the initial connect process (ie: the remote server isn't up yet and there is no locally running mosh-server or other key agent) mosh-client could stand in for the key agent to help the SSH process along.

I'm... not exactly sure what I'd do for the case that there is a locally running agent - perhap taking over from it and making sure the proper environment variable was modified before starting the SSH process for the initial connect&login ?

[gyulaweber]

It would be a killer feature
+1

[enaeher]

Is there a place I can donate to the project? I'd like to make a small donation to encourage the development of this feature.

[dshadowwolf]

Having done a bit more research, it has become clear that a back-channel would be needed to properly forward the credentials for security purposes. There is, it seems, a constant back and forth between the key-agent and the remote server, which would necessitate maintaining a communications channel for that. So my idea above would, in all likelihood, not be a true solution.

[moltar]

+1 definitely a must-have feature

[joemiller]

might as well throw in my own +1 =)

[TTimo]

+1 would be a most useful feature.

@kenrestivo's workaround is a great trick to have this work in the meantime.

[kilx]

+1

[sammcj]

+1

Please let us know if there is anything we can do to help test this.

[oskarth]

/me jumps on the +1 train

[lukusw]

I would love this also. +1

[Neal]

+1

[Jarred-Sumner]

+1

[matthew-andrews]

Could this thread be locked? https://github.com/blog/1847-locking-conversations

Every time I see a notification I think.. "maybe this is it.. maybe it's fixed!" but then it's just someone adding "+1" :disappointed:

(I realise I'm contributing to the noise - sorry for that)

[Sheco]

+1 to mathew-andrew's comment. :smile:

[x2q]

+1

[seeflanigan]

:+1:

So that we can mosh -A user@host and git pull without doing the ssh-keygen dance (yet...a...freaking...gain)

PS this project is REALLY cool, but is it still under active development? Last commit was in January...

[zx1986]

Dose mosh --ssh="ssh -A -p 22" YOUR_HOST work?

[gyulaweber]

unfortunately not :(

[vkovalen]

+1

[alinstoian]

+1

[vincentjorgensen]

Wondering if mosh is still under active development. Last commit to github was January 8, 2014. That's almost one year ago. Also, it seems that there is a patch for -A, but nobody is merging it. This would be a nice feature, but even nicer would be if the project wasn't abandoned, since it is such a useful tool.

[dk-dkopen]

Yes - ship it please! Let the user decide on the risk, esp. given that it's enabled explicitly.
Many valid points have been made above, both pro and con, but I'd rather have the choice.

Wondering if mosh is still under active development.

See https://github.com/keithw/mosh/issues/570 - the man himself answered that.

it seems that there is a patch for -A, but nobody is merging it

If you're referring to the Pull Request - https://github.com/keithw/mosh/pull/423
.. it seems there's a merge conflict.

This pull request contains merge conflicts that must be resolved.

[dk-dkopen]

Actually.. if Mosh were to implement "raw mode" suitable for use with SSH ProxyCommand + nc, providing a reliable TCP transport channel that stays up, that could account for all of SSH Agent Forwarding and tunnelling without Mosh (re)implementing it directly..

[termie]

+1

[xtimmu]

+1

[NoUseFreak]

:thumbsup:

[benlemasurier]

+1

[timesking]

+1

[jravetch]

:+1:

[takaidohigasi]

+1

[RubenKelevra]

+1

[codeshrew]

:+1:

[aaroncline]

:+1:

[PAStheLoD]

Hey,

Since the code works (thanks to kevinr), I couldn't stand it just sitting somewhere in a lonely Git repo. So, here's a Debian (actually Ubuntu) package, that works (for me at least): https://github.com/PAStheLoD/mosh/tree/master#but-if-you-do

[joshSzep]

+1 - I don't know enough to comment about the security issues that may or may not exist with agent forwarding, but it's a necessity in the environment I'm working in. :\

[fauust]

I may have found a workaround using 'tmux':

1. login with normal ssh client
2. open a tmux terminal and detach it
3. login with mosh
4. attach previously created tmux terminal
   You may be able to log with ssh-agent to your remote machines. I am not sure how long tmux will keep the link with the ssh-agent...

[patcon]

Just as one sample use-case that would seem to not work with the ProxyCommand solution:

When living in a country with poor internet connection, and wanting to treat your local workstation as a stupid shell for SSH'ing into your actual workstation on a cloud provider. Using agent forwarding has the benefit that, for all intents and purposes, it's like my SSH key were installed when I log in, and uninstalled when I log out.

[ddarbyson]

+1

[davydovmax]

Must have feature for me (can't use mosh without it).

[rinne]

The current version of agent patches on top of the current upstream master branch of mosh is in #696. Some maintainer asked for patches to be re-merged and I assumed that it meant that they were going to pull the feature to mainline. However it has been 17 days (after I re-merged the feature) and nothing has happened since.
For now, cloning mosh sources from https://github.com/rinne/mosh and compiling agent-forwarding-merge-20151128 branch (--with-agent-forwarding), does the trick.

[Omeryl]

:+1:

[ghost]

Has it been added to the main yet?

[andr-04]

@rinne, I get the following error by using your branch:

bash-3.2$ mosh --forward-agent xxx
mosh-server: illegal option -- A
Usage: mosh-server new [-s] [-v] [-i LOCALADDR] [-p PORT[:PORT2]] [-c COLORS] [-l NAME=VALUE] [-- COMMAND...]

[rinne]

Three possible explanations.

1) You don't compile mosh from agent branch (agent-forwarding-merge-20151128), see #696 which is the current pull request.

2) You have different mosh installed in your system and you are actually running it.

3) You don't have agent enabled version installed in the server side in the system you are logging into. The error message makes this one the likely culprit.

[andr-04]

Do you mean that mosh-server from branch must be installed on the ssh-server as well?

[rinne]

Yes. Mosh server must of course support agent forwarding too. Just like in ssh connections server creates the proxy authentication socket in remote host and forwards the agent requests to through the ssh protocol connection back to the client and client in its turn forwards them to the local agent socket, which can of course be another proxy socket, if there are multiple chained connections.

[yuriipolishchuk]

Looking forward for merge into master.

[arlofaria]

+1

[dlangille]

Any news on this getting into mosh? I cannot use it without ssh-agent.

[rinne]

@dlangille You might like to check out #696. The pull request there is up to date with current mosh master and while I don't hold my breath waiting it to be merged, you can compile from my forked code.

[skylerwshaw]

:+1:

[wagnerone]

Got excited about and really wanted to use Mosh. Spent a lot of time setting it up only to find agent forwarding doesn't work. Doh! Came here to find this discussion. Looking forward to a resolution!

[rinne]

@wagnerone Please check out #696.

[dlangille]

I appreciate the references to patches, but we need to get this into the code base before most people would consider using it.

[rinne]

Sure. Don't we all? The pointer was to more recent discussion and your upvotes and appreciations are appreciated there too. Lack of interest from the mainline developers has been quite ubiquitous all the way. I have been merging the mainline changes and resolving the conflicts every now and then in hope that they might merge the patches some day.

[dlangille]

Lack of developer interest is disappointing. Is it an objection to the feature, interests lie elsewhere, or complete silence on the topic?

[rinne]

My interpretation is that there is some small objection to the feature for the reason unclear (mainly "I don't use it, so it must not be necessary"). Secondly the patch is quite big, because mosh as it was (and is) wasn't really made to accommodate such extensions. About the actual implementation I've seen only minor and largely irrelevant discontent. I remember that @keithw wasn't originally sure, whether the way out-of-bans protocol (used by agent forwarding) data piggy-packs to mosh protocol packets is the right way to go, but that is so very basic decision in agent forwarding implementation that there isn't really too much to be done for that given that entire feature isn't going to be rewritten, which is something I absolutely won't do.

[yookoala]

Really like to see #696 merged.

Although I don't feel safe to store any SSH key on server, I need to occasionally do git pull PHP code base on server for deployments and upgrades. The lack of agent forwarding is a pain in ass.

[ei-grad]

I just use an extra pure-ssh connection to forward agent, when I need it, and do export SSH_AUTH_SOCK variable from that connection. And I'm happy.

[inertia186]

+1 to merge #696

[cgull]

I'd like to consider this for Mosh 1.3, after we release 1.2.6. I've started a discussion on the mosh-devel mailing list; if you're interested please comment there.

[tnguyen14]

@cgull do you have the link to the mailing list thread?

[cgull]

http://mailman.mit.edu/pipermail/mosh-devel/2016-May/001298.html
You can also subscribe to the list from there.
The list is also archived by http://gmane.org and https://mail-archive.com.

[rinne]

@tnguyen14 http://mailman.mit.edu/mailman/listinfo/mosh-devel

I regret that I don't have time for that mailing list, but just a quick response to specific concern of @cgull about nasty agents/agent clients potentially blocking the mosh session.

It may be possible for that to happen, but thenagain if you run a nasty program in your remote shell, it can freeze your terminal connection using much simpler approach like sending a kill signal to your mosh-server process or sending random crap to your pty. From what I remember about writing that agent forwarding code a few years back, I at least tried to write it so that if agent connection data starts to get buffered or traffic that is tunneled doesn't look like legit agent protocol packets of reasonable length, the agent connection gets very easily disconnected in order to save the terminal connection from blocking. I think agent connections are also dropped, if mosh client goes to off-line state, because it's most likely a right thing to do in aboutn 100% of the cases.

That much said, I don't think the oob-protocol (the one I implemented and on top of which the agent connections are forwarded) is in its current state suitable for general purpose tunneling. I think much more fundamental changes to mosh would be needed for that and I don't think that's worth the effort. In order to do that so that it really works, there would be need for (sub-)data channels with channel specific flow control and buffer management. That stuff is actually a big part of ssh protocol implementation and to get that stuff really to work took number of years. Easily disconnecting forwarded agent sessions is just a substitute for flow control and while it's usable for this specific stuff, it's not usable for generic tunneling.

Generic tunneling would also introduce a whole set of new semantic problems. E.g. what to do to a tunneled tcp connection, if the mosh connection gets into "disconnected state". Normal tcp connection would use retransmits and eventually break up the connection, if no ack packets are received, but since the tunnel proxy would remain open indefinitely, this would not happen and the only thing taking place would be a blocking tcp socket.

Anyways, I'm glad to see that there are at least some signs of maybe mainlining the agent forwarding.

[mikalv]

+1

[mefyl]

Well, +1

[tnguyen14]

@cgull now that 1.2.6 is released, is there any estimate on how long 1.3 will take to get out of the door?

[ksanislo]

For anyone who wants to be able to use mosh with ssh-agent forwarding, you can work around this problem by adding the following to your ~/.profile or other location that will run on ssh connect.

find /tmp -maxdepth 2 -type s -name "agent*" -user ${USER} -printf "%T@ %p\n" 2>/dev/null \
 | sort -n \
 | tail -1 \
 | cut -d' ' -f2 \
 | xargs -rn1 -I '{}' ln -sf '{}' /home/${USER}/.ssh/ssh_auth_sock

export SSH_AUTH_SOCK=/home/${USER}/.ssh/ssh_auth_sock

I also put the following into my user's crontab, so the symlink will follow when the local socket changes, though I don't think this is actually required since the .profile will catch it on the new login:

*   *   *   *   *   find /tmp -maxdepth 2 -type s -name "agent*" -user `whoami` -printf "\%T@ \%p\n" 2>/dev/null | sort -n | tail -1 | cut -d' ' -f2 | xargs -rn1 -I '{}' ln -sf '{}' /home/`whoami`/.ssh/ssh_auth_sock

It's not perfect, since it requires extra things on the remote server, but it gets the job done pretty well.

This is the same hack used to get ssh-agent forwarding to work with tmux, and I found this ticket by accident and personally didn't even realize that mosh wasn't forwarding the agent itself since I was already using this setup.

[silbernagel]

@ksanislo With that setup, how do you connect?

mosh bastion mosh internal_server?

If I could get this to work, there would be soo much happiness:)

[ksanislo]

@jorgelr I use mosh to my bastions, and typically just ssh to internal servers from there. Depending on what linux distro your bastion is running, you might need to tweak how you're making the symlinked ssh_auth_sock.

The general idea is that you want the environment variable inside your connected mosh session to end up set like this:

$ echo $SSH_AUTH_SOCK
/home/kens/.ssh/ssh_auth_sock

$ readlink -f $SSH_AUTH_SOCK
/tmp/ssh-Sq7wt8tgPj/agent.1151

So that symlink is pointed to the latest agent socket owned by your user, which should be the ssh connection that mosh created to connect. You'll still need ForwardAgent yes set in your .ssh/config file for the mosh bastion host.

[andersk]

I don’t want people to be misled here: @ksanislo’s suggestion requires that you leave open a separate SSH connection to the host in addition to the Mosh connection, to allow SSH to do the agent forwarding. The SSH connection that Mosh creates is used only for launching the Mosh server and is immediately closed.

[ksanislo]

Oh, you're right, the mosh session does go away instantly... I have a long running ssh between my home workstation and the bastion which is effectively where my ssh-agent ends up running...

I suppose it's easy enough to duplicate until there's a proper solution though, just:

nohup ssh ${bastion_host} sleep 365d &

from somewhere that will stick around is enough to keep the agent available. You could get more creative and put it in a while true loop in case it gets disconnected.

[silbernagel]

Thanks -- I'll see if I can't get it working. But would absolutely send beer once this functionality get solved the right way in mosh. Crossing fingers and arms:)

[geeohgeegeeoh]

BSD find doesn't honour -printf. The recipe works if you modify it on BSD to use ls, and awk out the fields to get date sort order to work.

for the transient ssh thing, surely we want tail -2 | head -1 to get the _second last_ ssh agent, which will be the long-lived instance? I'm confused. leave that out for now.

here is a BSD recipe which seems to work.

# ok lets try this.
# linux find /tmp -maxdepth 2 -type s -name "agent*" -user ${USER} -printf "%T@ %p\n" 2>/dev/null \
# | sort -n \
find /tmp -maxdepth 2 -type s -name "agent*" -ls 2> /dev/null \
 | awk '{print $8, $9, $10, $11}' \
 | sort -M \
 | tail -1 \
 | cut -d' ' -f4 \
 | xargs -rn1 -I '{}' ln -sf '{}' /home/${USER}/.ssh/ssh_auth_sock

[glensc]

@geeohgeegeeoh -1 for tail is deprecated with coreutils, does bsd tail support -n1? and perhaps it's just easier to use gfind instead than support ancient tools?

aside, i wrote earlier how i manage SSH_AUTH_SOCK in #696

[geeohgeegeeoh]

the example in the discussion uses tail. so, I used what I saw. if you want
to deprecate tail, pass on up the foodchain because the original script for
.profile I modified used it.

good luck persuading BSD people to adopt gnuisms

On Tue, Oct 25, 2016 at 3:15 PM, Elan Ruusamäe [email protected]
wrote:

@geeohgeegeeoh https://github.com/geeohgeegeeoh -1 for tail is
deprecated with coreutils, does bsd tail support -n1? and perhaps it's
just easier to use gfind instead than support ancient tools?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mobile-shell/mosh/issues/120#issuecomment-255938679,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF0YfPIf7BXPIfkLfT7jqisOe89CH52mks5q3ZBjgaJpZM4AFhH-
.

[andersk]

tail -n 1 is not a GNUism, it is required by POSIX (where tail -1 is not) and supported by at least GNU, FreeBSD, NetBSD, OpenBSD, DragonFly, Darwin, Tru64, HP-UX, IRIX, and Plan 9. See also (coreutils)Standards conformance.

[maximvl]

So no updates, ticket is still open, what's the official status? Any solution besides hacks in comments above?

[HaleTom]

+1

[rinne]

@MaximF Well there is a solution https://github.com/mobile-shell/mosh/pull/696 :)

[MaximF]

Thank you for an update @rinne! Out of curiosity - is there an ETA for merging that PR?

[dlangille]

Point of order: #696 has existed since [at least] Nov 28, 2015, i.e about 14 months ago. There are several discussion points already in this thread. Search for 696 and read.

[geeohgeegeeoh]

@andersk this is all probably OBE. the gnuism comment was about gfind. I didn't realize the specificity of the -n1 thing. My solution only sometimes works, its bad code. I'd far rather a clean solution which was generally applicable and portable was done, and I don't think coding to gnu find is that. POSIX behaviour is going to be fine, if tail -n1 is the syntax which is needed

[rlpowell]

On the point of security: my security team requires us to use a yubikey fob, which generates something like a one-time ssh key that is then required for login. We then ssh to a bastion host, and outward from there to the real hosts.

This means that without ssh forwarding, I literally can't log in to anywhere except the bastion hosts, for security reasons. This is a hard requirement from our security team. So arguing that agent forwarding is bad because security cuts no mustard with me.

So, yeah, no mosh for me, I guess.

[dlangille]

Following on from the previous post: tools, not policy.

Let us decide if ssh-forwarding is for us or not.

[zenhack]

A few folks have posed similar (though, I think, not identical) workarounds, but here's what I've come up with: from one shell on the client:

ssh -A ${host}

then, from another, log in with mosh:

mosh ${host}

and in the mosh shell:

export SSH_AUTH_SOCK=/tmp/ssh-<tab><tab>

...which should autocomplete to the socket forwarded by the first command. This doesn't allow roaming, since if the ssh connection breaks, you lose the agent, but it's good enough for getting a usable shell from a coffee shop's lousy wifi, which is my main use case. Would be nice to actually have the feature upstream though.

Ideally the first command could just be:

ssh -AfqN ${host}

Which would obviate the need to keep an extra terminal open. But for some reason I haven't figured out, the auth socket doesn't show up when I do that.

Also: I am so glad github added the reactions feature -- cuts down on +1 noise.

[Zenexer]

I got about halfway through the comments before giving up. Would someone mind summarizing where this issue stands?

Regarding the potential security issue: ssh-agent isn't just a program; it's also a protocol. There are other programs that implement the same protocol with better security. I use a YubiKey with the touch flag enabled; this means that each time a remote host wants to use my key, my YubiKey flashes, and I have about 15 seconds to touch it to authorize whatever's taking place.

The argument against this model, of course, is that there's no way for me to audit what's actually being authorized. However, the same is perfectly true without ssh-agent forwarding. You never have any guarantee that a given machine is doing what you tell it to do. It's up to the end user to decide which risks are most significant in their environment in a case such as this, where there's no ubiquitous best practice. (This is the "tools, not policy" argument.)

It's also worth noting that the userbase likely to utilize ssh-agent forwarding is probably more likely to find a workaround or store private keys on the intermediary than to alter their method because a single tool doesn't offer forwarding.

[dlangille]

The previous post, in short, says: tools, not policy.

Let the users handle the policy.

[rinne]

@Zenexer It stands in #696. Basically a working patch set has existed for years but not merged to mainline. Meanwhile I've been keeping my agent enabled branch in sync with mainline master branch every now and then.

[bukzor]

I set up a bounty, because money talks, and put in the first $50 to get the ball rolling, I hope.

https://www.bountysource.com/issues/1587475-ssh-agent-forwarding

[MaximF]

@bukzor That is an amazing idea, thank you! Made my contribution there as well! :)

[rinne]

@bukzor @MaximF All find and well, but as stated, the actual code has already been written (by me about 5 years ago). There has been some mild critique over where and how it should be implemented, but there has been absolutely zero activity in reimplementing it in any other way it has already been done (and not merged to mainline). The current state of working patch is in #696.

[MaximF]

If it is already ready, why not to just merge it?
Better to have some functionality than no functionality :)

On Aug 29, 2017, at 22:18, Timo J. Rinne [e-mail] wrote:

@bukzor @MaximF All find and well, but as stated, the actual code has already been written (by me about 5 years ago). There has been some mild critique over where and how it should be implemented, but there has been absolutely zero activity in reimplementing it in any other way it has already been done (and not merged to mainline). The current state of working patch is in #696.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[rinne]

It is the full agent functionality. But merging is something that is out of my hands.

[MaximF]

Do you mean you don't have privileges to merge into a master branch? If so,
let's just make a fork! ;)

2017-08-29 23:25 GMT-07:00 Timo J. Rinne [e-mail]:

It is the full agent functionality. But merging is something that is out
of my hands.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mobile-shell/mosh/issues/120#issuecomment-325894439,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOEUIj59WHB7k1zSapA9JPBDDgrPNKyks5sdQBmgaJpZM4AFhH-
.

[rinne]

There already is a fork that loosely follows the master branch of upstream mosh + agent patch. I won't commit myself to maintain it for the rest of my life though.

https://github.com/rinne/mosh

[bukzor]

@rinne Yes, this is about motivating upstream to take this seriously. There's actually two bounties now. A smaller one for this pull request in particular, and a larger for the original feature request.

[Apreche]

Just discovered Mosh today. Was excited to try it out. Discovered that Agent Forwarding didn't work. Connected to my server, and everything was great. Then I tried to git clone and realized there was no agent forwarding. Without that feature Mosh is completely useless to me. Saw that this issue is from 2012. That is very disappointing. Guess it's back to trusty old SSH for me.

[HaleTom]

If we have a working patch, what exactly is preventing the merge?

1. Enough time
2. Code quality
3. Design decisions
4. Other

What is blocking this so we can be clear about resolving it or working around it?

[rinne]

@HaleTom Lack of interest from the upstream developers' side.

[keithw]

Please see mailing list discussion on this (https://www.mail-archive.com/[email protected]/msg00980.html).

Excerpt:

The issue is basically the same since the original pull request in 2013 -- whatever change we make to the Mosh protocol to support ssh-agent forwarding is one we have to live with forever, and the limitations of the Mosh protocol make us not want to commit ourselves to these changes. Mosh does not handle big Instructions well; our fragmentation system is very simple, so adding reliable transport of not-exactly bounded OOB data in the synchronized SSP object makes me nervous.

There is some good news: we think we've figured out a way to do secure ssh-agent forwarding (something that could be enabled all the time, for any server, without the stern warning that accompanies ssh -A) and with a prototype that doesn't require changing the core Mosh protocol. Please stay tuned...

[rinne]

@keithw

we think we've figured out a way to do secure ssh-agent forwarding

Would you mind sharing?

[HaleTom]

I read the mailing list discussion on this and would appreciate anyone subscribed to that list posting here when the following tool is made available:

We have developed something internally (at Stanford) that you might
like that also does "secure" ssh-agent forwarding, by allowing the agent to
authenticate and limit (1) the host making the request, (2) the remote host
that host is trying to authenticate to, and (3) the command the host wants
to execute on the remote host. (With normal ssh-agent forwarding, the agent
can't learn any of these things and is basically signing a blank check.)
This works alongside SSH and Mosh. We hope to have a public beta soon and
will look forward to reports from anybody who wants to test it.

[HaleTom]

Hmm, is there any work-around for this issue until @keithw 's good news gets implemented (fingers crossed).

[rinne]

@HaleTom

We have developed something internally (at Stanford) ...

In the dawn of time when there was a standardisation effort for ssh protocol, there was also some new proposals for agent protocol. However, the protocol has remained much the same and there is no real standard for that. The pretty obvious extension that would allow policy based decisions in agent, would be a "forward notification" packet that all _clients_ would add to the forwarded agent connection (towards the agent) and include the information of the endpoint where that particular client is connected. That would mean that agent receiving an agent connection would get 0..n forward notification packets before anything else and could reconstruct the forwarding path before deciding whether to allow signatures and which keys or certificates to show etc.

Basically the user could then limit the agent forwarding to the systems he trusts. And the first level of forward notifications, would only need support in the client the user is using first. Server support is never needed.

Anyways, this is not mosh specific.

[keithw]

Hi folks,

Here is our prototype for secure agent forwarding that works with Mosh (or SSH): Guardian Agent.

Compared with traditional ssh-agent forwarding, Guardian Agent provides more-constrained agent forwarding that we think could safely be enabled on any connection. Like Mosh, this tool has to be installed on your local machine and on any host you want to Mosh to. It does not require anything to be installed (or any changes at all) on remote servers (e.g. GitHub) that you want that host to be able to SSH to using forwarded credentials.

This approach also does not require changes to the underlying Mosh protocol to carry ssh-agent request data within the interactive terminal, and we don't have to commit to (and support) a protocol for carrying reliable agent traffic between mosh-clients and mosh-servers. Right now, Guardian Agent 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. Based on feedback to this beta/prototype, we may incorporate the techniques behind Guardian Agent more deeply into Mosh.

There is a more detailed writeup in the README. Please let us know what you think, both about the usability of the tool or about the underlying mechanism. Please file any issues with the tool as GitHub issues in the Guardian Agent repository. We're looking forward to everybody's feedback.

[sbz]

+1
Same for me it doesn't work on version mosh 1.3.2 [build mosh 1.3.2]. I tried the following:

mosh --ssh="ssh -A" <server>
mosh --ssh="ssh -o ForwardAgent=yes" <server>

I can see the SSH_AUTH_SOCK variable is exported in the environment, but the agent forwarding doesn't seems to work.

SSH agent forwarding is a very nice feature, I would be happy to see that feature supported by mosh.

Description of the agent protocol can be found

• IETF RFC draft from the secsh group draft-ietf-secsh-agent-02
• OpenSSH PROTOCOL.agent from djm@ draft-miller-ssh-agent-02

[keithw]

@sbz Something like that is not going to work -- Mosh only uses SSH to authenticate and remotely invoke the mosh-server program. The SSH connection ends and is replaced with Mosh end-to-end. There's no SSH around to forward the agent requests.

If you want ssh-agent forwarding, use Guardian Agent! It works (and the design is more secure than normal ssh-agent forwarding, keeping in mind that Guardian Agent is beta software and needs the experience of people trying to break it and criticize the design).

[rinne]

I am very skeptic about a new agent implementation that requires a script wrapper around ssh is going to see any wide audience adoption. And an agent is already integrated to default sessions in most Linux distros and MacOS.
To that note, I've once more merged the current mosh master branch to my agent forwarding enabled version of mosh at https://github.com/rinne/mosh

[sbz]

@keithw Ok thank for your reply and clarification. I will try Guardian Agent!

@rinne I will checkout your branch, looks like the good commit to watch is rinne/mosh@dfa183d

[tnguyen14]

@keithw appreciate all the work you and your team put into mosh and Guardian Agent. I think it's great that there's a more secure option for agent forwarding. However, I agree with @rinne that wide adoption is rather unlikely, at least in the short term.

Now that there's a supposedly better solution for agent forwarding, I think mosh should also add support for the builtin agent forwarding, and let the users decide which one they want to use. I think it's detrimental to mosh to not merge #696. Clearly there is a lot of interest and support for that feature. Let the users decide which alternatives they prefer.

[webbp]

I would like this feature, too, but a <30 second workaround for connecting to a remote server and then accessing github is to just generate a new ssh key and add it to github, e.g.,
ssh-keygen -t rsa -b 4096 -C "[email protected]"
hit return several times
cat ~/.ssh/id_rsa.pub
copy it, go here: https://github.com/settings/ssh/new, paste

[rdnetto]

From the README:

Q: Is Guardian Agent secure?

A: Guardian Agent is a beta that was first released for beta testing in October 2017. It has not accumulated enough testing and scrutiny to make claims that the implementation is bulletproof.

IMO, this is a pretty strong signal that we should not use Guardian Agent for security-conscious environments, which are precisely the ones where we'd prefer agent forwarding over simply storing a key on the remote host.

I appreciate the desire to avoid the issues associated with agent forwarding, but until Guardian Agent is considered stable and secure, I don't think it's a viable alternative.

[keithw]

:-) We had a pretty similar disclaimer for the first few years of Mosh, and the results speak for themselves. There's no point in boasting about security before we have a track record. But I think the idea is that if you all try Guardian Agent and the feedback is good, we'll integrate it more tightly into Mosh. That sort of solves the problem of adoption.

[keithw]

In general, I know it's frustrating to have a PR sitting around and not get merged, but it's not just a question of the implementation -- we really don't want to complicate the protocol in a way that we then have to support forever going forward (especially by bolting it into the object that gets synchronized by SSP, which is unfortunately a bit of a kludge -- not Timo's fault, it's just that SSP is not very good at this use case).

If you look at where the security holes come from in OpenSSH and OpenSSL, it's largely from added complexity that wasn't _really_ necessary. Mosh has never had a significant security hole (yet -- knock on wood) and I don't think that's entirely luck -- it also comes from saying no to things that add complexity to the protocol in a way that makes it harder to reason about.

[rinne]

@keithw, just please mark the protobuf message numbers used in agent forwarding patch as reserved in upstream master, so they are not accidentally recycled later. Apart from that, I'm pretty much beyond caring.

[keithw]

Sounds pretty reasonable -- you want Mosh to keep tag 8 (your oob) reserved in TransportBuffers::Instruction?

[rinne]

@keithw "Sounds pretty reasonable -- you want Mosh to keep tag 8 (your oob) reserved in TransportBuffers::Instruction?"

Yes, please. As far as I understand, that should be enough to never break interoperability with agent enabled client vs non-enabled server and vice versa.

[xhalo32]

+1 add agent forwarding

[zviratko]

This discussion is a bit ridiculous.
It's true that enabling ssh-agent (without confirmation) is a security risk and could be considered bad practice.
But tons of people are doing it, using it and without it, mosh is usable just for their IRC screen hosts (like me).
To install it in an enterprise and use it to manage your servers, you usually _need_ ssh-agent support because sooner or later you'll hit a script that needs it (for git, automation, whatever).

mosh is either a supposed SSH replacement intended for use instead of SSH everywhere possible (in which case it will need to support all the silly stuff as well) or it is just a wrapper that makes roaming easier for few hosts (in which case you might argue improving security is a thing).
I say let the users decide.
I believe mosh security is on-par if not better than SSH with all it's legacy bloat, which should be one more reason to make it possible for people to actually use it as SSH replacement = ssh-agent is a prerequisite of that (and for the record I believe port forwarding as well)

[keithw]

Hi folks -- I'm going to lock the conversation here because it doesn't seem to be productive anymore. We are not making the protocol changes proposed in Timo Rinne's pull request, for the reasons we've explained earlier here: we really don't want to complicate the protocol in a way that we then have to support forever going forward (especially by bolting it into the object that gets synchronized by SSP, which is unfortunately a bit of a kludge -- not Timo's fault, it's just that SSP is not very good at this use case).

If you look at where the security holes come from in OpenSSH and OpenSSL, it's largely from added complexity that wasn't really necessary. Mosh has never had a significant security hole (yet -- knock on wood) and I don't think that's entirely luck -- it also comes from saying no to things that add complexity to the protocol in a way that makes it harder to reason about.

If you want ssh-agent forwarding with Mosh, please use Guardian Agent and provide feedback if you have it: https://github.com/StanfordSNR/guardian-agent

It works and I use it every day! If feedback is good, we may consider integrating Guardian Agent more closely into a future version of Mosh. It's true that Guardian Agent is newer and less-tested software, but, so was Mosh when it was younger. The only way it will be more-tested is if more people use it. And, we think it is a lot more secure than "uncontrolled" ssh-agent forwarding.