Support chrome-ssh-agent

[rpwoodbu]

Although ssh agents don't work through mosh, it could still be desirable to cache the decrypted version of the ssh key, so subsequent ssh-initiated mosh sessions don't require providing a passphrase. Perhaps this could be implemented as a checkbox option (defaulted to unchecked) on the main session window. Then when the user first provides the passphrase, it will be cached. Unchecking the option should immediately throw away the decrypted key.

It may also be desirable to provide a field indicating how long to cache the key (ala ssh-add -t).

[rpwoodbu]

One important detail: This should only cache in memory, never on disk. Therefore this needs to go in the memory of the JS background page. But if there is no mosh session running, Chrome will eventually unload the background page, which will throw away the key unexpectedly. Perhaps there's a way to prevent Chrome from doing this. If so, it should only be prevented iff there is currently a key cached.

[rpwoodbu]

This seems easier said than done. There's no straightforward way to prevent the background page from going "inactive", which throws away all of its in-memory state. The best solution I've found so far is to set an alarm that fires every minute, but that is awfully hacky, and wasteful. What I want is a session-persistent in-memory store (never on disk), but I can't seem to find such a thing.

[computersarecool]

+1 This would be so nice.

[scottj97]

Why don't ssh agents work through mosh? I think this should be mentioned in the wiki on Key-based SSH Auth. I looked all over for how to make it work.

[rpwoodbu]

I think I explained why pretty well in this issue. I'm amenable to making this clear in the wiki.

[scottj97]

Forgive me for being blind but I just reread this issue and I don't see any explanation of why ssh agents don't work, only an explanation of why caching the decrypted key would be difficult. The only mention of agents is in the first clause "Although ssh agents don't work...".

Perhaps I should file it as a separate feature request? I'm running Win10 with Pageant for PuTTY and it would be nice if mosh-chrome could use that agent instead of asking for the password each time.

Suggestion for wiki page on Key-based SSH Auth:

Q: How do I use an SSH agent so I don't have to type in my encrypted private key's password every time? A: Mosh-chrome is unable to use an SSH agent because [explanation]. You can avoid the need to type in a password by using an unencrypted private key, but this has security drawbacks.

[rpwoodbu]

Ah, sorry for the confusion. I was talking about why implementing one in Mosh for Chrome is difficult, when you're asking about why Mosh for Chrome can't use an agent the system already has.

The short answer is: It can, but it needs help.

Being a Chrome App, chatting with a program outside of the browser and not available over the network is tricky, but AIUI not impossible. I don't want to complicate Mosh for Chrome with that.

However, I did add code a while back to talk the same protocol as OpenSSH's ssh-agent to a specialized Chrome app which is used by my company and is not publicly indexed in the Chrome Web Store. If someone were to implement a general "agent forwarder" app (or even a full-blown in-browser agent) which follows the same simple protocol, it would be trivial to whitelist the app ID in Mosh for Chrome. I'd love to see this happen, and would happily provide consultation.

If anyone is interested in trying to build an agent app, look at both mosh_app/mosh_window.js and mosh_nacl/mosh_nacl.cc and search for "agent". This has all the data marshaling code for the agent. Basically, it takes OpenSSH-style agent communication data, packetizes it, and sends it to the agent app using Chrome's inter-app communication facility. Packetization is easy, as the agent data is actually already made of packets, but placed in simple frames for sending over a streaming connection. As Chrome's inter-app comms are packet-oriented, it makes better sense to pop the data out of the frame on the way out and reconstitute it on the way in, rather than implementing a streaming protocol between the apps.

Also, this was modeled after the same functionality in the Secure Shell app, so you'd get a two-fer if a common public agent app were created.

[rpwoodbu]

@scottj97 I've added an entry to the wiki, inspired by your suggestion, salted to taste. :)

[scottj97]

Perhaps I'm out of my league here, but wouldn't a Chrome ssh-agent app have the same problems caching the decrypted key as Mosh itself would have? Or if it was only an agent forwarder app, wouldn't it have the same problems chatting with an agent outside of the browser? I'm not understanding how making a separate Chrome app would solve any problem that can't be solved directly in Mosh-chrome.

[scottj97]

Let me (attempt to) answer my own question: you don't want to complicate mosh-chrome with that. I get it.

[rpwoodbu]

@scottj97 Yeah, that's basically it. I've already created the facility to communicate with an external agent, so let's use that. An external agent is a better design since it would also allow other apps (like Secure Shell) to use it. But you're right: all of the difficulties of making a workable and secure agent app, which I've described in this issue, remain. It clearly isn't impossible, but it will require more research and effort.

I personally don't need this feature, and it is a big enough nut to crack that I can't justify the time. So if the community wants this, I'm happy to offer help, guidance, and advice, but I need someone else to lead the charge.

I think the first best solution would be to "NaCl-up" ssh-agent. That would work on all platforms (including Chrome OS, which has no local ssh agent outside of dev mode). OpenSSH is already in webports, so this may not be too hard to accomplish. And if you started a NaCl binary in an invisible window, that should keep the app from terminating itself. I suspect there are some parts of the Mosh for Chrome codebase that would be useful for this; if those are identified, I'd be happy to do the work of breaking those out into a separate project.

[rpwoodbu]

@scottj97 I decided to spend a little more time researching this (you seem to have piqued my interest). You indicated earlier that what you really want is for Mosh for Chrome to reach out to your PuTTY agent in Windows. That is indeed best for platforms != Chrome OS. Gaining access to some random program running on your local system is tricky, and for good security reasons. But it is possible.

See this document on Chrome Native Messaging. tl;dr: If you create a special JSON "manifest" file and a special registry key, Chrome will run an external program specified in the manifest and make it possible for Chrome extensions to communicate with it. This program would be an arbiter between Chrome's messaging protocol and that of the PuTTY agent. It would be trivial to take the existing external agent feature of Mosh for Chrome and enhance it to use this method as well (assuming that the PuTTY agent protocol is the same as ssh-agent).

The idea is similar for Linux. It's almost too easy; I might have to throw something together just to see it work. If I do so, that could act as a model for Windows/PuTTY. (Incidentally, there's a certain irony to the fact that I work on an app that is popular among Windows users, yet I haven't run Windows on any of my machines in about 10 years. Obviously, someone else would need to write the Windows/PuTTY version of this.)

The caveat here is that the user would need to install this special program on their system the old-fashioned way. I.e., this can't just come as an app from the Chrome Web Store. That's not unreasonable considering that you're breaking out of the sandbox, so to speak.

[rpwoodbu]

I threw together a proof-of-concept Native Messaging app that indeed allows Mosh for Chrome to access the local ssh-agent. It wasn't hard at all. Even though Linux users have a native mosh app, I'll try to find some time to clean it up, put a bow on it, and publish it on GitHub, at least as a model for how to do such a thing. It would also be the place to put a NaCl-ified ssh-agent, making this useful to Chrome OS users (and a decent option for Windows users).

I fear, though, that PuTTY's Pageant agent protocol will be substantially different than that of OpenSSH's ssh-agent, so getting that to work may be a significant effort. Maybe someone can do some research on that. You could also consider just running ssh-agent in Windows, perhaps with Cygwin or whatever the new hotness is. Or we could just NaCl-ify ssh-agent.

[scottj97]

I much appreciate all your work towards this. All I was asking for was an FAQ entry since I'd spent so long trying to figure out how to make it work. :)

[fastcat]

This might be of interest here: https://github.com/google/chrome-ssh-agent though it looks like it might be somewhat tweaked to specifically work with Google's ssh client?

[rpwoodbu]

@fastcat That's pretty interesting! The fact it is meant to work with Secure Shell is a Good Thing(tm), as Mosh for Chrome already has the same kind of support, it is just that the agent app ID is hard-coded. I'll have to investigate how best to support both.

[rpwoodbu]

The chrome-ssh-agent app doesn't currently permit connections from anything other than Secure Shell. I'll see if I can get Mosh for Chrome whitelisted.

[rpwoodbu]

Sent pull request.

[scottj97]

Your PR looks like it was released in chrome-ssh-agent v0.0.17 on November 2, 2018. Is there (or should there be) a FAQ on how to enable this in mosh-chrome? Or is there still work to do in mosh-chrome to enable its use?