> Leverage Windows crypto api’s instead of OpenSSL/LibreSSL and run as Windows Service
Was wondering about that. I'm surprised the OpenBSD team is accepting the commits - something so fundamental and Windows specific doesn't seem like their kind of thing - but great!
Why would the OpenBSD team not accept the commits? It is just linking to a system library that will always be present on the platform. It's like saying Windows opensource should be forced to use some thrid party filesystem library.
It's cute that there is some kind of VBScript for calling web services, but this line tells me that this document must have been authored by some kind of PowerShell apologist.
If I could send a pull request to Microsoft for inclusion of a legit whois binary on their OS--nope, you're right, I'm just full of spite on this subject. :)
I imagine it's nothing more complicated than "OpenSSL isn't the native crypto implementation on Windows, SChannel is". Microsoft's engineers are probably much more familiar with SChannel, and they don't want to have to test/validate two crypto systems in parallel. Besides, this should make OpenSSH better in the long run; it should be able to have any compatible crypto layer underneath.
SChannel implements SSL/TLS as a security support provider (SSP), native crypto interfaces are WinCNG (current) or CryptoAPI (legacy). A port of OpenSSH that used the native crypto library would likely use WinCNG.
An OpenSSL-like wrapper around WinCNG can be found in Heimdal's libhcrypto.
A crypto system is a big and complex thing, subtle and quick to anger, and I can't blame Microsoft for wanting to concentrate on the one they're already supporting, instead of having to support two.
On the other hand, for the exact same reason, I expect OpenSSH probably isn't interested in supporting anything besides LibreSSL and maybe OpenSSL, at least while they're so closely related.
You can already build OpenSSH without a libssl (make OPENSSL=no), it drops support for ssh1 and the only algos available are curve25519, aes-ctr, chacha, ed25519 (or were when it was first announced[0])
Duplication of effort and attack surface. Now, instead of worrying about just keeping Windows' crypto api secure, Microsoft would have to worry about libressl as well?
Long term, if this is truly a first-party supported SSHd, it makes sense.
Also, keep in mind that modern OpenSSH does not need to link against OpenSSL anymore. You will have to make do with the bundled ciphers ed25519 and chacha, which is useless for talking to your legacy systems, but if you are making a new deployment it might suffice (or even be desirable).
The article is not clear if that's an option with this new Windows port, but it would decrease the attack surface a lot, which can only be good. SChannel has had its fair share of nasties over the years.
I really don't like that there replacing an open source crypto with a closed source one. Putting on my tin foil hat but didn't Microsoft hand over a back door to the NSA already.
> Putting on my tin foil hat but didn't Microsoft hand over a back door to the NSA already.
What incident are you referring to? I can think of a couple of possible ones:
1. PRISM, which is still a big question mark, and if it's in your threat model, then running Windows, let alone running Windows with an SSH server of any form, is not something you want to be doing, regardless of whether a particular library in it is open-source.
2. _NSAKEY, which MS had a decently convicing explanation of: it was a signing key used to indicate NSA-approved cryptographic providers (for FIPS-ish auditing), not anything that could be used to break into a user's account remotely.
3. The removal of the Elephant diffuser from BitLocker. My personal opinion is that all "diffusers", custom block cipher modes, etc. for full-disk encryption are pseudoscience; if you really want integrity protection, change your filesystem so it uses 4064-byte sectors, a 16-byte IV, and a 16-byte authentication tag. In any case, it still requires physical access to the disk to attack, so it's not particularly useful as an NSA back door (unless your threat model is one of the "then you have bigger problems" ones).
The two cryptographers who originally publicly identified the backdoor (that Snowden eventually confirmed) work for Microsoft. So, the opposite of what you're insinuating.
They collaborated with the NSA to develop an exploit in the SSL implementation used in Outlook.com.
From the Snowden documents;
July 31, 2012
Microsoft (MS) began encrypting web-based chat with the introduction of the new outlook.com service. This new Secure Socket Layer (SSL) encryption effectively cut off collection of the new service for FAA 702 and likely 12333 (to some degree) for the Intelligence Community (IC). MS, working with the FBI, developed a surveillance capability to deal with the new SSL. These solutions were successfully tested and went live 12 Dec 2012.
It's not clear this should be called an "exploit". It sounds like Microsoft in its capacity as a cryptographic endpoint turning over either plaintext or session keys (or in the severely worst case, long-term private keys). It doesn't make much sense to me to refer to that as an "exploit".
Are you saying that you are familiar with the events that DonnyV is referring to but you are confident that they are mere legend? That you disagree with the published accounts?
Or are you saying that you are not familiar with that particular scandal, you've never heard of it, and your response is simply "Not that I know of."?
If you check his post history he basically just blanket denies everything relating to the Snowden NSA leaks and accuses people of believing in 'magic' when they discuss the agency's capabilities.
That's not true at all. I question it when people post conspiracy theory stuff with no evidence whatsoever. HackerNews is not that type of website, and I hope it never degenerates into it.
I'm surprised the OpenBSD team is accepting the commits
Theo has come a long way since he lost beaucoup bucks by spitting in DARPA's face after taking their money.[1] Now Microsoft and OpenBSD are besties.[2]
The saddest thing to me is that Yandex is on there. Not because they shouldn't be, but because so many American and Western companies are willing to take, take, take, but are unwilling to give back even a little bit.
>I'm surprised the OpenBSD team is accepting the commits
What commits? From the comments you will learn there were no commits and this is a classic embrace and extend. They are hijacking OpenSSL name, and rewriting it to use Microsoft crypto and APIs.
Best way to address POSIX compatibility concerns is implementing a proper POSIX layer in Windows (and not in a half-baked manner like the now deprecated SUA). I can't imagine how it would hurt anybody.
SUA was not half-baked, this is a very, very hard problem. There is a very serious difference in the way POSIX and Windows model a lot of really important OS primitives, from asynchronicity model in signals, to the semantics of syscalls like `fork`. Every process using these primitives on POSIX has specific behavior defined under those primitives, and if you don't choose _exactly_ the right behavior on the POSIX subsystem in Windows you will definitely break programs.
So, no. You can't "just" implement a POSIX subsystem correctly. These systems are just not compatible. It will always be half broken.
Indeed. The Cygwin project has done an amazing job working to act as a compatibility layer between Windows and POSIX, but even Cygwin, with all the time and energy that's gone into it, still has some rough edges. Not to say that using it isn't awesome, but it's not perfect.
Sure, its "easy" if Microsoft wants to redefine Windows in POSIX terms; iits not easy to keep Windows functioning as Windows and provide a POSIX compatibility layer, since Windows isn't designed around POSIX expectations.
Which for everyone that has written code across UNIX systems knows it has quite some issues across systems that are supposed to share some kind of common architecture.
Even worse when the architecture is completely different.
Is this not what midipix.org intends to do? Granted, they're nowhere near close to being finished at this point in time, but it would be great to see the project pick up steam in this space.
midipix looks awesome, but seems to be GPL (not LGPL). Does that mean anything using it must be GPL too? I think that would be unacceptable for such a low layer of the stack.
I don't know why you're being downvoted, but this is a legitimate concern for some businesses (well, legitimate may be too strong, but it is a concern a lot of legal departments will have).
After discussing this issue on #midipix on freenode, they had mentioned they will explore dual-licensing or some variant of such once the software is more stable and can be reliably deployed. In any case, the project is far too early in its infancy to start worrying about what license they might have.
I don't understand the point of dual-licensing. Anything licensed under a BSD-style license such as ISC or MIT can to my understanding be redistributed under GPL anyway. IANAL, TINLA.
That is a valid concern. On the other hand, win32 has a strong developer community with 20+ years of legacy as the primary API of Windows. Now only if Microsoft hadn't try to screw its own developers by trying to push a new framework every 5 years.
It does but as you say due to the emperor's new clothes every few years, the loyalty isn't there now. I know of no companies doing greenfield desktop dev that are using any of their tech. It's all Qt, CEF, python/wx and JavaFX. Even the financial companies we deal with who were pretty heavy with the WPF are canning it next cycle.
Incumbent MFC, Winforms and WPF stuff will live as long as VB6 did (and still does) though.
Edit as HN won't let me reply (submitting too fast). In Europe and JavaFX also has hardware acceleration as does CEF as it uses Chrome's rendering engine.
>> Even the financial companies we deal with who were pretty heavy with the WPF are canning it next cycle.
Where are you based? What are they planning to adopt?
My company is consulting a couple of hedge funds in New York and they have no plans of replacing WPF for their trading apps.
The desktop CLR VM plus proper GPU acceleration makes WPF faster than any alternative (when avoiding binding). As far as I'm aware no other UI toolkit comes anywhere close.
But it does, it just hides the link. All you have to do is to go to the child's comment by clicking the time link, then you'll get a reply box. In your case the comment you probably want to reply to is this: https://news.ycombinator.com/item?id=10416018
Will this OpenSSH server be able to run interactive console programs (like cmd.exe or python.exe), or will it be limited to (say) PowerShell?
Windows doesn't have a good API for hosting a console--it's not like Unix, where a pty has a master end and a slave end. Trying to run a console program in mintty.exe (https://github.com/mintty/mintty/issues/56) or Cygwin SSHD fails for this reason. I wrote a tool, winpty, that makes a best-effort attempt to emulate a Unix pty master by scraping the console buffer, but it has some limitations, so I'm not sure Microsoft would want to use it. Maybe they would expand the console API?
I too was very skeptical. Something about posts from "The Powershell Team" about porting sshd makes me deeply cynical that they would get the integration right from a layering perspective, i.e. as if they would make it support powershell and nothing else.
Fortunately this example shows it going straight into cmd and then they invoke powershell as a next step:
C:\Master>ssh.exe -l user@127.0.0.1
user@127.0.0.1's password: **********
Microsoft Windows [Version 10.0.10566]
(c) 2016 Microsoft Corporation. All rights reserved.
user@DEV-10566-829 C:\Users\user>powershell -File -
Cool. Looks like that is essentially listing DEVICE=ANSI.SYS in config.nt? Google results imply some things about 16-bit emulation here -- was that post about running actual DOS ANSI.SYS in a VDM running actual DOS COMMAND.COM, within a native Windows terminal?
Never was much of a windows fan, so a (slightly ignorant) question for someone who is a Win admin - can most administrative things nowadays be done via the command line on Windows (like we've been able to do in *nix land) or is there a gap between what can be done via the GUI vs the command line?
New Server features are primarily controllable via PowerShell and now only secondarily expose a bit of control via GUI. So, indeed PowerShell has taken precedence. However, it would be wrong to say that Windows administration is exactly like managing Unix systems. On the contrary, the more one works with it the more one realizes PowerShell is the anti-Bash.
Lacking in the aeons of interface legacy built into standard Unices, you won't find standbys like 'grep' readily available or even easily implemented. Rather, PowerShell is built from the ground up for scripting. While the addition of SSH will certainly be helpful for quickly checking statuses, (and possibly more in the future should readline usability of PowerShell improve) right now most PowerShell interactions happen via scripting from a local workstation or web or application inputs rather than directly via the interactive shell.
Microsoft are pushing the command line to the point that:
a) Many operations in newer bits of Windows have simple-mode available in the GUI, but more sophisticated options must be scripted. StorageSpaces has a few examples of this, where some of the options around tiered storage, SSD caching, and the layout of pools can only be accessed via posh.
b) Microsoft are pushing completely headless versions of Windows Server for 2016.
About headless version , it is so great to hear that , although I am not using windows , but hearing that is good news overall , it seems with new CEO Microsoft back on truck .
I would not remember with ballmer they released windows server with Metro UI . WTF !
Yep. Recent windows servers even default to boot straight to console these days, with none of the GUI services running. MS has realized that centralized deployment and maintenance is really useful and is acting accordingly, hence things like openssh for windows.
(From what I've heard from people using them) On the current server versions, PowerShell should allow to do all that the GUI can do. There is a GUI-less version and I think the GUI actually uses PowerShell underneath, so you can look up in a log how the commands look like for something you only knew how to do graphically before.
This is very goddamned awesome. All I hope is I can set the default user shell for my account. I already use msys2's zsh for my shell (because I use zsh everywhere, on all OS), and being able to ssh into my Windows machine 'normally' (for me, anyways) would be extremely useful.
And this gem: "SSH daemon needs to run as System to support key-based authentication".
Which means, either use weak authentication, or run the daemon as system. I don't even understand why, it's not like the public keys are particularly sensitive (certainly much less sensitive than being able to check passwords for validity)?
Have you checked what user OpenSSH usually runs as on a linux machine in order to allow key-based authentication? I'll give you a hint: it's root. That's no different than running as SYSTEM on Windows.
As a sibling comment mentioned, it makes perfect sense that the ability to create a user session requires a certain privilege. What struck me as odd, was that it only needed this on Windows when using key-based authentication - not when allowing password-based login.
AFAIK ssh needs access to /etc/shadow on Linux, if you want to use system passwords. But also, AFAIK, nothing stops you from running ssh in a chroot, without any such access (well, access to a /etc/shadow under the chroot probably).
Thank you for that. It makes a certain kind of sense, that impersonating a user/creating user sessions requires a high privilege. I think I'd still be more happy with it running as a low privilege user allowing log-in as "nobody"/"guest" and then elevating to a user with login/pw via "runas" or equivalent.
I can see how the only way to login directly to a certain user id would either require ssh to run as that user id or as System.
That is the crux of it. Windows is not going to fundamentally change its authentication system to work around SSH. It's going to feel "hacky" compared to SSH on *NIX (also console interactivity). You'll still need to run Windows updates as a scheduled task as the system user because remote connections have a remote token and the Window Update API blocks such connections...
You have to create a god damn scheduled task to do Windows Updates over WinRM. And it takes ages for Powershell to realise the task is running, and polling the status of the job is a PITA.
Took me days to automate Windows 2012 with Packer. Ugh
> You have to create a god damn scheduled task to do Windows Updates over WinRM.
Aha. That must be why I could never get updates working with Packer/WinRM. It would take a very long time to do a huge amount of work then end up never quite finishing properly.
> And it takes ages for Powershell to realise the task is running, and polling the status of the job is a PITA.
OK, so not really a proper solution then. Oh well.
It really is surprisingly bad, isn't it? I recently was involved in a continuous deployment system targeting Windows. We simply couldn't get WinRM to reliably upload fast and ended up installing SSH everywhere.
Having worked on that code (in Packer) - the WinRM protocol is completely unsuitable for use as an SCP replacement. It's amazing it works at all even for small files! The actual "winrmcp" implementation is here https://github.com/packer-community/winrmcp if you're interested in the inner workings.
OK, but that code (cp.go) uploads base64 chunks of 8K and echo's them to a file and decodes when done. That surely isn't the real WinRM file copy implementation right?
Well... I just went looking for how it's implemented and holy shit I don't think they considered this case. Top results say "use a file share". Wow. I feel less inadequate.
Yep definitely the worst thing ever. Not just that though; everything. I've lost so much hair in the last few months over trying to get a CD environment up on windows.
I'm interested in how this is going to work in PowerShell with the way everything works now, if there happen to be any details about that (whether here, somewhere else, or a past link)?
I don't know anything about PowerShell, but I have a similar question, I think: how is this going to work? Will I be able to do something like this command line (from my *nix machine)?
This is a key thing I'm curious about. How is drive mapping handled? If I "net use d: \\host\share" from one session, it won't nessarily translate and mount D: to all sessions (or will it)?
I can't check right now, but if you have two local users, Delta and Gamma, and Gamma mounts D:\, does Delta see it or is it specific to Gamma's session?
Mapped network drives are for each user separately. Actually, they are even different for the limited administrator token and the elevated one (e.g. if I run something as administrator here I won't see my mapped network drives, but instead have to use UNC paths).
It's not the best butt it's better than the others. You can always enhance putty features using MTPuTTY http://ttyplus.com/multi-tabbed-putty/ worth trying
I'm a fan of Bitvise SSH for a Windows SSH server; it's been enough to replace Terminal Services when each employee has their own work machine to remote desktop into.
It's nice that Microsoft recognizes the need for this functionality; I wonder how they will approach the potential per-client licensing issues they like to bring up with their server OS's.
A great openssh for windows for the time being. Being using this and it is great, only thing is not able to do powershell from it once connected to host.
I have had really good luck with this open source, native windows, ssh server.
http://www.kpym.com/2/kpym/index.htm
I have no affiliation with the project, i just thought i'd mention that it is a nice alternative i found.
Blargh. Another OSS project that doesn't expose any kind of version control (7zip is the worst offender). I know, gift horse etc etc but it does make it hard to track the history / future of the project.
Also looks like it hasn't been updated since 2011.
Why does this support telnet? Just seems crazy to me. Is it on by default? That would be a violation of any sane security policy pretty much anywhere. Seems like a serious edge case requirement and odd to bundle with SSH. This is like buying a new car but then having the dealer give you a free horse with your purchase.
Telnet has the unique advantage of having an implementation for the opposite part on any TCP/IP compatible system without external libraries, crypto etc. and that you can recreate both a server and a client in literally an hour with nothing but a C compiler and an ordinary libc.
Was wondering about that. I'm surprised the OpenBSD team is accepting the commits - something so fundamental and Windows specific doesn't seem like their kind of thing - but great!
PS. If you're coming from a Unix background and interested in learning posh: https://certsimple.com/rosetta-stone