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
Looking at the new code I feel like the chances this ever makes it upstream to pretty close to 0.
These patches are going to the portable version - which has always been a separately maintained branch of openssh. e.g. no PAM, no Kerberos ...
I stopped reading this when I got to this part:
whois 'domain [domain name]'
$web = New-WebServiceProxy 'http://www.webservicex.net/whois.asmx?WSDL'
$web.GetWhoIs('[domain name]')
Just put none in the `whois` box and move on.
If you have other suggestions though, send a pull request. The project has already gotten a bunch from the SmartOS and FreeBSD communities.
If anyone else on HN wants to add anything, the source is just markdown, so you can hack away (gulp does the HTML building and JS does the interactivity): https://github.com/certsimple/rosetta-stone/blob/master/rose...
An OpenSSL-like wrapper around WinCNG can be found in Heimdal's libhcrypto.
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.
If they implemented a good openssl to cryptoAPI shim it could be usable by other projects linked against OpenSSL.
Long term, if this is truly a first-party supported SSHd, it makes sense.
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.
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).
But maybe I'm forgetting something else?
http://rump2007.cr.yp.to/15-shumow.pdf
Always possible MS is not to be trusted, but there's nothing on the record to support that.
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.
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]
There are a few companies that give money to OpenBSD. Far too few, but there are some: http://www.openbsdfoundation.org/contributors.html
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.
[1] http://www.computerworld.com/article/2580728/security0/darpa... [2] http://www.theregister.co.uk/2015/07/08/microsoft_donates_to...
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.
So, no. You can't "just" implement a POSIX subsystem correctly. These systems are just not compatible. It will always be half broken.
As for choosing "_exactly_ the right behavior" ... the whole point of POSIX is to clearly define the exact right behavior!
Even worse when the architecture is completely different.
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.
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.
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?
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 -
That gives me some hope that it's being done right.
https://github.com/PowerShell/Win32-OpenSSH/commit/55f2ec682...
and "Add ANSI parsing engine and console draw support to SSH client":
https://github.com/PowerShell/Win32-OpenSSH/commit/7aac59e52...
Something about this reminds me of ANSI.SYS.
https://groups.google.com/forum/#!topic/alt.msdos.batch.nt/Y...
I would think so. Anything less would not be a real SSH server.
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.
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.
https://github.com/PowerShell/Win32-OpenSSH/wiki/Deploy-Win3...
"If you need key-based authentication:
Install key-auth package
run setup-ssh-lsa.cmd
reboot"
Reboot?
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)?
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).
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.
http://english.stackexchange.com/questions/45136/difference-...
Took me days to automate Windows 2012 with Packer. Ugh
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.
Also I had to up the memory ceiling on WinRM to 800Mb (WTF!) to even get it to complete.
I was so keen for WinRM support to land in Packer so I could avoid installing cygwin.
It was out of the frying pan and into the fire.
Native Windows SSH should _hopefully_ solve all this hassle.
ssh user@windows.machine.local dir d: | lessI don't work for them, I just think it's a nice tool, so much so I paid for the Pro version.
I might be overly nitpicky, but holy inconsistent coding styles Batman: compare https://github.com/PowerShell/Win32-OpenSSH/blob/bafc1df7c5c... to the other source files.
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.
EDIT: I misread this and though it was only a client. Geez. If it's a server, then of course it should be a service.
Also looks like it hasn't been updated since 2011.
(disclaimer: I work there.)