Back in June, we announced our intentions to bring SSH to Windows by supporting and contributing to the OpenSSH community. Our objective was to not only port OpenSSH so that it worked well on Windows, but to openly contribute those changes back into the portable version of OpenSSH. Of the many options available, one clearly stood out: the previous work that NoMachine had already published in bringing OpenSSH to Windows. The NoMachine port was based on OpenSSH 5.9, so we’ve spent the time since our initial announcement working with NoMachine to bring this port in sync with OpenSSH 7.1.
With this initial milestone complete, we are now making the code publicly available and open for public contributions. We will continue to partner with NoMachine on development in this public repository. Please note that this code is still very early and should be treated as a developer preview and is not supported for use in production.
Here’s how our rough roadmap looks:
- Update NoMachine port to OpenSSH 7.1 [Done]
- Leverage Windows crypto api’s instead of OpenSSL/LibreSSL and run as Windows Service
- Address POSIX compatibility concerns
- Stabilize the code and address reported issues
- Production quality release
At this point, the roadmap is specifically around providing a Windows port of OpenSSH with complete feature parity and interoperability. Our goal is to get to milestone 5 within the first half of 2016.
We welcome your contributions, as well as feedback on any issues you run into.
Steve Lee
Principal Software Engineer Manager
PowerShell Team
Hey guys,
Are there any status updates on this project? It looks like the last official up date was in October of 2015. I’m really looking forward to a Microsoft supported OpenSSH and, just like a kid waiting for Christmas, I’m eager to hear how close we are to a production quality product.
Regards,
Teagle
We hope to have an update this month (both to the roadmap as well as an updated package), however, we won’t hit our target for being production quality.
Any update on this team?
I’ve spent the past couple of days (barely) getting OpenSSH-Win32 running (server and client tools)… I can confirm that the current code is not ready for prime time (server authentication code in particular seems to be a “big ball of messed up”).
I don’t know if they accept fixes from the wild, but I’m going to try to get a build environment set up so I can dig into a few of my specific problems and then contribute them back up… assuming I can make sense of the stuff they’ve done so far to get the port running.
Please submit pull requests!
At the point where Microsoft is using their own crypto, I don’t think that you can realistically call it OpenSSH anymore, it’s MS SSH, not that there’s anything wrong with that. If it is developed, officially released and maintained by Microsoft, it should be done according to Microsoft standards, like any other MS tool, not bolted on. Folks that don’t WANT to use MS SSH, can continue to use OpenSSH.
Thank you for making it easier for us IT guys that work with both on a daily basis. I really appreciate the new Microsoft customer focus.
Is there any plan to have a powershell interface which can help use existing powershell commands to work over SSH interface ? For example, in a test scenario the host machine is copying back and forth test content from target machine thru powershell. Also host tries to retrieve many information about the target device thru powershell. Now if we have facility not to change the powershell calls from host when using SSH interface is greatly useful. If we have a function call made thru powershell which asks powershell to use SSH (or by that means any transport ) , it would be really useful. This means existing calls will work and we can make calls from any type of server (Windows, Linux etc) as long as it has got SSH support.
@Prasad: Nothing is in plan right now, but we’ve certainly been thinking about it. Right now, our main priority is getting to production-quality with plain old OpenSSH.
Are you planning on doing anything to make the shell work correctly so that things like arrow keys while cursoring through a man page with less works? I’m not sure how much of this is the Command Prompt/PowerShell window or how much of it is the SSH application, but, at the moment it looks largely useless. It looks like apps like ncurses based ones don’t work properly. I’m glad to see that the Command Prompt/PowerShell window was improved some in Windows 10, but, it appears to still need a lot of improvement. You really do need to do something about this. It’s about 25 years overdue.
@Jon: Right now, we’re very much in an “alpha” state. By the time we release an officially supported version, we’d like to have a complete experience that includes much of what you’re talking about here. You can check out our current roadmap on GitHub. I don’t want to guarantee that everything will be perfect, but we’d like to fix many of these problems by the time we integrate with the main OpenSSH repository.
Thanks,
Joey
Great evolution!
I’m looking for logging at the server side: logs of logins, errors etc. Can’t find anything. Does anyone have a clue?
thanks!
I noticed this didn’t have packaging yet – so I put together a chocolatey package for it. More details here: https://www.linkedin.com/pulse/fastest-way-get-your-hands-new-win32-openssh-darwin-sanoy
This work on porting OpenSSH to Windows is greatly appreciated I work at an organisation where we compile software for multiple platforms. OpenSSH on Windows will greatly simplify my job.
What I don't understand is why Windows no longer has a POSIX subsystem. Until Windows 8 there was SUA which was an optional component to install on Win7 ultimate and earlier Windows versions. Although SUA was riddled with bugs and had an outdated gcc compiler due to persistent neglect by Microsoft it was nevertheless a fully fledged UNIX subsystem with ssh client and server.
Instead of reinventing the wheel why did Microsoft not just reinstate SUA to make it stable together with the ssh ability it had?
Indeed, wrapping this stuff with PS would be a good selling point. I know I would jump at it instantly, but I have already posted my wish list.
6. Dig out UNIX Services for Windows source code and release it "For greater good"
Joke aside, it might help with the POSIX stuff.
Fantastic!
@Steve Lee Thank you for the update!
@Yosi: Nice catch! Just fixed it.
Would you split the tag "SSH" and "OpenSSH"? Currently it is a single tag "SSH OpenSSH" so isn't useful to search posts.
Fantastic!
Until now, it's just an ssh.exe. Are there any specific Powershell Commands to work with?
@Deepak, the work is happening on GitHub and you can download binaries today github.com/…/releases
Any update on this? Can't wait to see it in action 🙂
@Donny V it is an open-source mysophobia
I think it makes the most sense for MS to leverage Windows Crypto for SSL rather than OpenSSL or LibreSSL.
SSL and for that matter SSH are standard protocols, just like TCP/IP and a dozen others. By being a standard protocol, that means it has to be interoperable with others that implement the standard.
Having one implementation of a standard is bad practice for a number of reasons. It is a single-point-of-failure which means if it is hacked, or broken the entire Web goes down. We just experienced this over the last year with OpenSSL while Windows Crypto API held it's own with no updates required for some of them.
For that matter, why LibreSSL? Why not do all of that within OpenSSL as a separate branch? Why BoringSSL from Google?
On the outwards, SSL looks the same to us by design. However, internally, there are many ways to code it and optimize for different things. Windows Crypto API is built and centered around SSL on Windows which is far more optimized for Windows than OpenSSL is. Microsoft supporting 2 SSL libraries is expensive for development and support. Replacing Windows Crypto for OpenSSL doesn't make much sense either.
Now why OpenSSH for SSH? Probably because Windows doesn't have one built-in anyway so the fastest way to develop it is use what is already out there. Other than that, MS could build their own Windows SSH components themselves and still be interoperable with OpenSSH.
It would be better with the OpenSSH design to work closely together.
We should concentrate on LibreSSL.
Which brings the default security from the OpenBSD team.
Microsoft should support on regular basis OpenSSH, OpenBSD, and LibreSSL with a donation.
And improve the safety of the mass
http://www.openbsdfoundation.org/donations.html
http://openbsdstore.com
http://www.libressl.org
I cannot wait for this, a long time coming and definitely a step in the right direction!
Microsoft shouldn't take on the security cost and risk of managing, patching another ssl library when they already have their own. Multiple implementations is a good thing for security overall.
I'm still not seeing a reason why you would want to use Windows Crypto API
When what you have already (OpenSSL) works, why make a change?
Quite encouraging, thank you for the good news. Seems nowadays Microsoft is probing different directions to bring new life in their products, and while some of the moves seem (at least) dubious, others are (at least) promising fun and profit for users. Thank you, and I hope all the messages "don't use Windows crypto" or "don't create a fork" are based upon some misunderstanding. I hope that when the developers consider their additions mature enough they will take an effort to have them accepted into main OpenSSH codebase, and as a result we'll use OpenSSH capable of one more type of encryption. Good, why not?
I am currently developing PowerShell tools using WinRM endpoints to provide secure delegation of some custom management functions. How can I future-proof my current development without inhibiting my ability to transition to the new standard once it is production ready?
Will there be a straightforward path to migrating to ssh? (i.e. Invoke-Command -ssh)
Will there be a replacement for PSSessionConfiguration? In particular, RunAsUser – I don't want the end user account to have any privileges beyond running the script.
Will we be able to use ssh keys to connect from non-domain accounts and map them onto windows security principals (not necessarily the principal of the connecting user)? I believe currently certificate based authentication can only be mapped to local accounts.
Any best practices I can implement now with this transition in mind?
Thanks!
Good.
thank you
And please use SSPI for Kerberos support rather than MIT. If you're going to integrate it with Windows properly, a half-assed attempt it should not be. 🙂
"Leverage Windows crypto api’s instead of OpenSSL/LibreSSL and run as Windows Service"?
Why make it compliant with OpenSSH, then work hard on making it not? Certainly it's a space consideration.
What shells can you run? Only unix shells or cmd.exe as well?
Do you support programs using the Windows Console API or are you limited to piping a pair of stdio? Given my bad experiences with existing SSH servers on Windows I always assumed the SSH protocol was not capable of the former.
Don't do step 2
It will be critical for our environment that you include support for GSSAPI/Kerberos server authentication (the gss-group* and gss-gex* key exchange mechanisms, RFC 4462 etc.). This support was originally by Simon Wilkinson, and later incorporated into various Unix distributions which continue to maintain it, but never included in OpenSSH proper. Taking advantage of Kerberos for automatic server authentication and avoiding the need to maintain hostkeys is just as important as having Kerberos SSO for users.
Best not call it OpenSSH if it's not.
I wish MS would just throw PowerShell in the garbage and embrace cygwin for console management.
@Qed for what it's worth, they did send an announcement to the mailing lists in June: lists.mindrot.org/…/034050.html
However, I think you have a very good point. It is odd that development is taking place on a public fork, with no upstream interaction. The OpenSSH developers would probably have valuable input on Microsoft's patches.
The closed source argument is really absurd on Windows. At some level anything compiled against the windows runtime is using close source code on the backend. If that bothers you stop using Windows.
Regarding Windows crypto api, it should not be a surprise that we have an affinity to what is available in Windows. You can always recompile OpenSSH and use OpenSSL or LibreSSL.
@ryan, this is a complete port including sshd, ssh, sftp, and related tools like ssh-keygen
@alex, the port currently doesn't have any specific Windows dependencies so it should work on Win7
@bicentennial.w, undeadly.org/cgi
Why the windows crypto api? The openbsd has done a good job with this.
Changing that out not only moves critical code to closed source where the rest of us can not examine it, It can only introduce new bugs. If your adding capacity, and your intention is to share with the upstream project, why not just work with the upstream project?
Great news. As a long time OpenBSD user, welcome! (and thanks for the cash, and code….:-)
Do I see a trap here?! If the Windows port uses the closed source crypto api is the whole OpenSource OpenSSH-idea then still intact?
Do I see a trap here?! If the Windows port uses the closed source crypto api isn't the whole OpenSource OpenSSH-idea still intact?
Great work,
Leverage Windows crypto api’s instead of OpenSSL/LibreSSL << very bad idea
I really appreciate this effort and would also like to thank you for contributing to the OpenBSD Foundation. Your opensource efforts are visible to the community and are beginning to swing public opinion on Microsoft. Keep it up!
That said, I would love to hear more about your plans on integrating your changes to the upstream.
SSH is the venerable Swiss army knife and is ubiquitous in my non-Windows environment—so I’m very pleased to see Windows get this functionality as well and I’m even more impressed to see Microsoft change its ways and give back to the community.
I’m supplied Windows never had its own version of an encrypted terminal session like SSH. I definitely approve of this!
@Steve Trotman: It is still a pre-alpha version, but something that is worth releasing for testing. I guess anybody related to Windows development treats Visual C++ compatibility and building inside VS as a high-priority task, as it greatly increases development speed (at least for those used to the IDE). Currently the sources depend on being built by GCC. Once that's dealt with, surely MS will build it with MSBuild and MSVC.
@Donny: As long as it does not violate the license, I'm pretty sure MS will integrate most parts with those already in the OS. If I had a decent and familiar API that has been tested throroughly tested, I'd sure be to port over the related parts to increase integration, specially such a crucial part that has received quite some criticism lately. No moth passes by without a critical Flash vulnerability, and no season without a critical OpenSSL security hole.
@Ryan: I think that is what they mean by step 2. Running as a Windows Service most likely refers to the server. (I dunno what's the gain of running the client as a service.) Off-topic: could you give me some links on where to educate myself on terminals and there capabilities? (Both Unix and Windows)
On my Christmas wish list is:
– Windows Credential Store integration, so logging into Windows automatically unlocks credentials to my Linux boxes, so long as I have them saved in the store and I need not specify usernames if there is only one credential saved.
– Scriptable Powershell front-end
– Subterminal support
– Reuse code to enable SSH authentication in Visual Studio Git integration.
Since you are using Windows Crypto how are you going to support ed25519 keys?
> Leverage Windows crypto api’s instead of OpenSSL/LibreSSL and run as Windows Service
Please reconsider this step. I don't trust closed source crypto, especially coming from a company that provides law enforcement backdoors for accessing already-mounted BitLocker volumes on locked Windows PCs.
Why can't you contribute your different crypto code directly into the repository? In addition, OpenSSL already supports hardware acceleration, so why do you need to use your own special crypto at all? If you want the trust of developers, all crucial functions of your OpenSSL implementation should be open source.
Can you explain why you want to use native Windows crypto Apis?
What's the advantage over the already working OpenSSL implementations
Had been nice if it could include the X11Forward, I know that microsoft is incompatible with X11, but without the X11Forward the use of openssh is quite pointless in a such windows based OS.
I do no think switching from Open/LibreSSL to Windows crypto API is good decision, because it brings no value to end-user, while making difference between Microsoft branch and OpenBSD upstream much larger.
I do not thing, also, OpenBSD will ever include CryptoAPI abstraction layer to support this, so the only real result will be either Microsoft version will be not OpenSSH, but some fork, probably incompatible after a few years (why do we need incompatible ssh at all?) or Microsoft version will be a few version behind OpenBSD one.
Maybe you will reconsider bringing that well known NIH illness to this project?
I am concerned about your plans to use the windows crypto APIs. I can see why it would be ideal for some but please make it optional and not default.
Great! Please please take your time and do it right…better to release in late 2016 with rock-solid code than to rush and suffer endless error messages and backlash. Stability and Linux compatibility are way more important here than performance or a Q2/Q3 release date. Keep up the good work!
I took a quick look at the code. Please don't call strcpy() inside a SSP with user-supplied data! (Indeed, please don't call strcpy() at all.)
Thanks for your hard work!
Any chance we can get an X11 server next? It would be amazing to have a Microsoft-provided X11 server that played nicely with OpenSSH. I use X11 forwarding all the time, and I'd love to be able to ditch Cygwin.
I hope Microsoft will continue sponsoring OpenBSD development, which maintains the OpenSSH and LibreSSL projects:
http://www.openbsdfoundation.org/donations.html
http://www.openbsd.org/donations.html
This is good news. I have long been looking forward to managing my windows machines from a tmux tab. You should add official support for all supported windows variants right at the start, since somebody will invariably fork with that objective, and then you risk not being the go-to-implementation/build anymore. Or did I miss already officially announced Win7 Support? Is there a beta channel for installers I can sign up for? Will I be able to use this as a SSH <-> PowerShell_Remoting Bridge by installing it on just one machine?
So why haven't any Microsoft PowerShell or NoMachine developers been working with the upstream OpenSSH community mailing lists, or reporting bugs in the official tracker?
http://www.openssh.com/list.html
http://www.openssh.com/report.html
The earlier blog post from June 3 indicated support for an SSH server. Is that still planned?
I'm wondering whether the server would be able to run ordinary console programs inside it, or whether it would be limited to PowerShell. AFAIK, while a Unix pty has master and slave ends, the Windows console API doesn't really have a "master" end. (The analogy isn't quite right, because a console program can do things a Unix pty client can't, such as read the console buffer.) Of course, Microsoft can add new Windows APIs.
Would be great if you add support for authentication protocol agnosticism SSPI/SSPIPFC, would be great for some of our customers using our EAP SSP. Contact me directly for more details.
I don't think I like that your replacing an open source SSL with a closed source Windows crypto api.
I have had really good luck with this open source, native windows, ssh server.
http://www.kpym.com/…/index.htm
I have no affiliation with the project, i just thought i'd mention that it is a nice alternative i found.
I would love to see this code be buildable via a Visual Studio 2015 solution. Having to use GCC for the build seems just silly given the context and all the work done to improve C standards support in newer Visual Studio releases. I feel it would also increase corporate buy-in in certain environments as well.
If popular, will this be included by default in future Windows releases? For me, it is crucial, that it ran on all editions of at least Windows 10 and Windows Server 2016. Maybe a backport to Windows 8.1 and Windows Server 2012 (in a Service Pack of some kind maybe) would be ideal, I can't imagine what is possible.
It would be very nice to just be able to count on OpenSSH being part of PowerShell as a server+client for server OSes and client for workstation OSes (+server as a feature to turn on with a simple command).
Let me add a bit more detail. The current port doesn't require a POSIX subsystem (such as Cygwin, although it's needed for compilation as it depends on gcc) to run. However, to get the changes accepted back into OpenSSH, we need to do some work to make the code compliant with the rest of OpenSSH which is dependent on POSIX.
@Joel, good question. Windows no longer has a POSIX subsystem. Our customers/partners would prefer not to have to deploy a POSIX subsystem just for SSH (resources, patching, etc…). We're looking at some options to have OpenSSH run on Windows "natively".
Can you expand a little bit on what "Address POSIX compatibility concerns" means?