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.
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.
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.
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!
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.
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.)