windows client #293

ericsnowcurrently opened this Issue Jul 7, 2012 · 40 comments


None yet

What is required for a windows client (native, not cygwin)?


keithw commented Jul 10, 2012

The first thing required is for us to have a maintainer or contributor on the Windows platform who knows what users there prefer and what is a realistic way to port Mosh over there.

nvx commented Jul 13, 2012

I'd imagine incorporation into PuTTY or KiTTY would be the long-term way to go, but in the short-term, inclusion into Cygwin would be nice.

Probably depends on #96

wizzard0 commented Sep 2, 2012

inclusion into Cygwin would be nice.

Please not Cygwin :)

Ideal mosh for Windows is a stand-alone, zero dependencies binary which fits on a USB stick and can be carried over from machine to machine.


keithw commented Sep 2, 2012

We'll look forward to that pull request with the Windows client from you! Thanks in advance.

jquick commented Oct 5, 2012

If you want you can PuTTY ssh to a local osx/linux box and then mosh out. That's what I do for work.

ymattw commented Oct 19, 2012

+1. I hate the cygwin setup program.

bcomnes commented Oct 29, 2012

I emailed the PuTTY developers a while back to see if they were interested in implementing this. Basically, this is what I was told:

  • They need more documentation on mosh's State Synchronisation Protocol. Right now they say they would need to read through the source code of Mosh to figure out how to implement it.
  • They do not think it would be hard to come up with a PuTTY based implementation of Mosh.
  • None of the PuTTY devs find a personal need or use for mosh. I understand this to mean there is little motivation internally for the port.
  • It will likely to be implemented only if someone submits a "sensible patch"
  • They are unaware of any cryptographers that have taken a serious look at the protocol to check if its actually secure.

Mosh is an ideal ssh application for nomadic chromebook (as chrome extension). Imagine opening bunch of mosh sessions, moving to a different location and have the same sessions connected!

Hey, and you will get windows support for free!

I really like the chrome extension idea. You may want to use something like MOAI (android/ios/windows/chrome game framework) which lets you use LUA glue to get a very multiplatform solution.

< pipe dreaming >The sessions state can be stored in the cloud (Google drive?) so that logging in from separate chrome will open exactly the same sessions... puff And if mosh can multiplex output to all connected clients... puff Imagine seeing that your chromebook is not enough and opening your desktop machine with all the same screens... puff < / pipe dreaming >

A chrome extension doesn't quite pertain to the concept of a Windows client (I'd rather have PuTTY integration) but there is a SSH Terminal native client app for Chrome/Chromebooks.

ipkn commented Apr 10, 2013

I wrote a native windows port of mosh. (but very limited currently)

Would you try it?

EDIT: source on and related codes are under win directory.

nvx commented Apr 10, 2013

No source?

micolous commented May 6, 2013

I've gotten the repository above to build, and I've written build instructions and cleaned up the project files for Visual Studio to no longer depend on hard-coded paths. These are in my repository

You'll need Visual Studio 2010 in order to build. Instructions are at

However in my binary and in the binary supplied by @ipkn above, mosh-client crashes with "illegal instruction" when attempting to connect:

mosh.exe!ae_init(_ae_ctx * ctx, const void * key, int key_len, int nonce_len, int tag_len)  Line 672 + 0x20 bytes   C++
mosh.exe!Crypto::Session::Session(Crypto::Base64Key s_key)  Line 191 + 0x1b bytes   C++
mosh.exe!Network::Connection::Connection(const char * key_str, const char * ip, int port)  Line 343 + 0xd0 bytes    C++
mosh.exe!Network::Transport<Network::UserStream,Terminal::Complete>::Transport<Network::UserStream,Terminal::Complete>(Network::UserStream & initial_state, Terminal::Complete & initial_remote, const char * key_str, const char * ip, int port)  Line 66 + 0x59 bytes C++
mosh.exe!STMClient::main_init()  Line 145 + 0x52 bytes  C++
mosh.exe!STMClient::main()  Line 310    C++
mosh.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow)  Line 129    C++
mosh.exe!__tmainCRTStartup()  Line 547 + 0x2c bytes C
mosh.exe!wWinMainCRTStartup()  Line 371 C

I suspect there may be an issue with some compiler flags, but it is something I need to have more of a look at.

micolous commented May 9, 2013

I found the issue with the illegal instruction error that I was getting. It appears to be because SSSE3 optimisations have been forcibly enabled, and my processor does not support them. AMD added support for this in late 2011, and Intel added support for it in 2006.

I've addressed this in 17bbf0a.

I've left SSE2 turned on, as this was added to Intel CPUs in 2001, and AMD CPUs in 2003. I believe it is reasonable enough to expect that the majority of Windows users will have CPUs with support for these instruction sets.

Outstanding issues that I have:

  • The terminal is quite slow to redraw (as much latency as mosh is compensating for on a 200ms RTT)!
  • There is a "set font" function in the control box of the window, however this doesn't appear to do anything.
  • Seems to lose connection with the server with "crypto integrity error" after about a minute and not recover.

FauxFaux referenced this issue in FauxFaux/PuTTYTray Aug 17, 2013


Feature request: MOSH #84

Zenexer commented Sep 13, 2013

While I like Chrome extensions, I'm in favor of a native client for this purpose. Ideally, mosh should be platform independent, rather than ported, but perhaps that's asking too much.

+1. In the situations I'd need to use mosh, I'm invariably on a windows box, and I'd much rather have a native client than have to mess around with Cygwin.

I should note here I don't know enough about Win32 C++ programming in order to make this work nicely, or as a part of PuTTY (which is why I haven't responded in 6 months). IMHO this should be a part of PuTTY, and this is probably the best way forward from here. It's a lightweight and self-contained client.

I don't like the idea of using Chrome or Cygwin as they both introduce huge amounts of dependencies.

There's other projects that introduced mosh protocol support for platform specific clients like ConnectBot (Android) and iSSH (iOS).

In the interim I've been using PuTTY to SSH to a Linux machine on my local network, and then using that to run mosh to remote systems. This works fairly well, but has extra setup steps. It could be automated by using profiles in PuTTY to execute mosh on connect.

MHM5000 commented Jul 14, 2014


@wbond, @Yasushi, @noodle1983, @risacher, @mloar: each of you have PuTTY forks (or something) here on github. If you have any interest in Mosh, please read this thread and tell us what you think. Thank you for your time!

mloar commented Sep 5, 2014

I've done some Win32 porting work in the past and could probably get @micolous port working better.

As for integrating into PuTTY, my involvement was limited to updating some GSSAPI authentication patches that someone else wrote as changes were made in the upstream. Now that the PuTTY authors have finally integrated those patches, I no longer maintain my fork. I never found the PuTTY codebase that friendly to work in, anyway.

I don't have time to look at this now, but I should be able to in a couple of weeks.

wbond commented Sep 6, 2014

Unfortunately my work with PuTTY has just been adding some missing features to psftp.exe. I won't bring much to the table in terms of knowledge of Windows APIs, and I tend only to use Windows to support users of my software.


cgull commented May 26, 2015

I had a look at @micolous' fork. As it stands the code is not ready to pull-- files are duplicated & modified, #ifdef WIN32 is liberally sprinkled, the new Windows code has essentially no comments. But it didn't seem fundamentally broken. Also, I'd guess the slowness issues are more about the Win32 GUI's display code than anything in Mosh itself.

Just my opinion, but if someone who knows Windows and platform issues better than I were to spend some time cleaning up the source and cleanly breaking out the ifdefs into separate platform code, that might be well received. I don't know a lot about Windows development, but I suspect MinGW might be an easier/cleaner port for Mosh than the plain Win32 environment.



Are there news about this?

I would love to deploy Mosh on several machines, but lacking a free and easy to use Mosh client on Windows is an issue to me.

Maybe you already looked at this:

Kind regards.

@timofonic If you want to use mosh on Windows today, easily, I would strongly encourage you to look at mosh-chrome. It has matured greatly in the last couple of years to the point that I wouldn't bother using PuTTY.

@cgull You may wish to edit the original bug posting to mention the Chrome app version, and maybe amend the website to indicate that the Chrome app is the easiest way to run it on Windows. I wrote a pull request for this, mobile-shell/moshweb#36.

The code there is written by @ipkn, so unfortunately I cannot shed further light on how it's works or it's style. 😞

Others, it is known there is demand for a Windows mosh client, but there is nobody with sufficient knowledge to step up and finish this work. There is no need to constantly spam the bug with "+1" or offering to test it. This is what you do by posting:


Instead of whineing, write some damn code.

I'm now unsubscribing from this thread because I'm fed up of spam updates for the last two years. I have no plan to work on mosh for Windows further.

If you decide to @ me for comment, I will be referring your messages to GitHub's abuse team. ❤️


Sorry, but I use Pale Moon on all my systems. I disagree to use Google Chrome/Chromium.

I can't find one for XUL/Pale Moon. I agree a web client could be interesting for some use cases, but a native app would be preferred.

PuTTY authors = stoneheaded +MIT/BSD license = forking hell.

The only usable and flexible alternative for Windows seems to be MobaXterm (I fail to understand why there's a zillion of putty forks and console emulators instead merging efforts to make a multiplatform version of that, it uses forks of PuTTY and others.

WinSwitch (a GUI wrapper for xpra, NX, VNC, RDP, ssh X display forwarding) seems near of MobaXterm, but lacks console and MOSH support :(


cgull commented Feb 24, 2016

@micolous, @timofonic, I think it's extremely unlikely that PuTTY will ever support Mosh as part of the core putty.exe. Its authors are very conservative about changes, because it's security software. (So are we.) Running mosh-client as a backend process in conjunction with PuTTY seems more plausible.

Actually, if you like the way PuTTY works, consider using Cygwin, mintty, openssh, and Mosh-- mintty is derived from PuTTY source.

As for a Windows port-- it seems that none of Mosh's developers has had an interest in doing that, and nobody has yet brought forth work that we can use.

Just to be clear-- the work that @ipkn and @micolous did looks like a good start, though. It seemed reasonably well designed, and I didn't see changes to core Mosh code that would be unworkable. The issues I saw seemed like they were all fairly easily fixable with some time and attention; I'd encourage any developer who's interested in a native Windows Mosh to take a look at it and start a discussion about what would need to be done to integrate it into core Mosh.

cgull referenced this issue in rpwoodbu/mosh-chrome Aug 23, 2016


Chrome App Migration? #127

I summarized the "MOSH TO-DO" just for easier future discussion:

Summary: Compatibility with Mosh (mobile shell)
Class: wish: This is a request for an enhancement.
Difficulty: taxing: Needs external things we don't have (standards, users etc)
Priority: low: We aren't sure whether to fix this or not.

Several people have asked us to extend PuTTY to add compatibility with Mosh, a rather unusual remote-terminal application that's particularly suited to use over bad networks.

This is a tempting idea in principle, but there are several practical problems:

  • ☒ The used SSP (State Synchronization Protocol) doesn't seem to have any public documentation.
    • It makes difficult to write another implementation.
  • ☒ It doesn't transport a terminal stream, updates the screen by other means.
    • This isn't like all the protocols currently supported by PuTTY.
    • Adding support would need hooks into the middle of the current monolithic terminal emulator, becoming a fairly large amount of work.
  • ☒ It's use of the network is very different from all our existing backends, which use small numbers of TCP connections.
  • ☑ It does require an SSH client implementation for authentication and key-exchange.
    • There are some major parts of PuTTY that could be re-used.
  • ☒ It uses OCB, patented in the USA.
  • It's possible that someone could write a patch to add Mosh compatibility to PuTTY that we'd be willing to accept, but it's not the most likely thing ever.
  • Will this be always true?

cgull commented Oct 2, 2016 edited

@rpwoodbu has adapted to a single-package, native Windows install with no dependencies. This looks like it might be a very good solution for Windows users. I urge people to try his early builds and give him some feedback. See the discussion and download links towards the bottom of rpwoodbu/mosh-chrome#127.

It also looks like he might be about to push a 0.4.0 release, so check for that too.

Zenexer commented Oct 2, 2016 edited

For those of you looking for a native solution, msys2 does offer a mosh package. I've been using it with ssh-pageant, Gpg4win, and a smart card without issue for some time now without issue. The default terminal emulator is mintty, which is based on PuTTY's terminal emulation components, but there are plenty of other options available.

It's also worth noting that Windows 10 Anniversary Edition offers WSL, which does support mosh inside cmd.exe. However, it's a bit more difficult to deploy at scale, and there's little to no chance you'll get it to work with a smart card.

Prior to using either of those, I did use mosh-chrome for a while, but the performance is mediocre and it's death to laptop batteries. Naturally, it works great on ChromeOS. It's very customizable is mostly user-friendly (aside from key management), but terminal emulation has some minor bugs. It lacks agent support, so it won't work with smart cards. It's definitely the easiest option of the three.


rpwoodbu commented Oct 6, 2016

@Zenexer Re Mosh for Chrome performance: Take another look. In the early days, it did have some performance issues, and occasionally would get into a funk and take all the CPU. I don't think that's the case anymore (but if so, please report on the mosh-chrome project). The terminal emulation (not my code) has also improved, and is quite good these days.

I would greatly appreciate any feedback on the Windows port that @cgull mentioned. I do intend to release it in a few days barring any bug reports.

Zenexer commented Oct 6, 2016

@rpwoodbu It's not really an issue with Mosh for Chrome or the terminal. The issue is that anything Chrome-related gobbles battery on Mac, Linux, and Windows (but seemingly not ChromeOS). That includes Electron apps, too, although Visual Studio Code seems to be better than most. JS desktop apps wrapped in Qt have the same issue. Such apps--including Chrome--are always the number one cause of battery drain on my Mac, Linux, and Windows devices. If I have to go an extended period of time on a single charge, I have to keep web-based apps closed.

For example, at this moment, the top CPU hogs on my laptop are:

  • Slack (MacGap)
  • HipChat (Electron)
  • Telegram (recently added Qt web controls)
  • Chrome

All of those are "closed" (in the Mac sense) with the exception of Chrome, meaning they're not in the foreground and there's no visible window, yet they're each consistently using 1-4% CPU. That's a lot when you need to work for an entire day without charging.


cgull commented Oct 6, 2016

This is wandering off topic, but Mosh itself is not the best thing for battery life. It sends/receives a message every 3 seconds and (especially in versions before 1.2.6) is computationally intensive compared to SSH, even when idle. The constant messages are probably the more significant problem currently, because that can cause radios to be brought up/shut down to transmit the messages constantly.

Mosh for Chrome performance should also have improved because it now has Mosh 1.2.6, though.

Zenexer commented Oct 9, 2016

Actually, I haven't really had any issues with battery drain while using mosh from msys2, Homebrew, or Arch. Some terminal emulators will use a lot of power if there are frequent updates, though (e.g., iTerm2).

Would it be possible to implement Mosh's protocol using javascript?


cgull commented Mar 23, 2017

Yes. But you'd need an OCB implementation and UDP sockets, and you'd have to reimplement some fairly tricky, idiomatic C++ code. Mosh has been reimplemented before (in an Android app).


rpwoodbu commented Mar 23, 2017

Doesn't the Android app actually just use the C++ Mosh code?

In case you missed it, @pratham2003, Mosh for Chrome is now in a beta version as Mosh for Windows.

Zenexer commented Mar 25, 2017

My biggest beef with Mosh for Chrome (and similar apps) is that they don't offer integration with GPG through the ssh-agent or putty-agent protocols. I haven't gotten it working with the msys2 version, either, though it should be possible.


rpwoodbu commented Mar 25, 2017

@Zenexer This is harder than it sounds. The Chrome sandbox is quite strict. However, there is a way, and it may even be appropriate now that there's a "native" Mosh for Windows.

The only way (that I'm aware of) of escaping the Chrome sandbox is to use Native Messaging. This makes it possible to communicate with a native app from a Chrome app (or extension). At that point, pretty much anything is possible. But registering a native app (even one that is already installed) requires installing a file in a magic location (or writing a registry key on Windows).

I never bothered with any of this, because the primary use-case was Chrome OS, and other platforms had native solutions... or so I thought. It wasn't until recently that it became apparent to me that Windows users didn't have a great native solution, and many were using Mosh for Chrome. That's why I was willing to make Mosh for Windows (which is really just Mosh for Chrome bundled with the Chromium browser in a native installer).

Since there's a native installer, there's a mechanism for registering a native app, and even delivering that native app should a proxy be needed between Chrome and ssh-agent. On top of that, there's already some ssh-agent support in Mosh for Chrome (via a 3rd-party Chrome extension, not really for public consumption). So a motivated individual could hack this up fairly easily.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment