Slashdot Mirror
Microsoft Publishes OpenSSH For Windows Code (msdn.com)
An anonymous reader writes: Microsoft has published early source code for its OpenSSH-for-Windows port for developers to pick apart and improve. In a blog post on Monday, Steve Lee – the PowerShell team's principal software engineer manager – said Redmond has finished early work on a Windows port of OpenSSH 7.1, built in a joint-effort with NoMachine. Their rough roadmap from here: 1) Leverage Windows crypto APIs instead of OpenSSL/LibreSSL and run as Windows Service. 2) Address POSIX compatibility concerns. 3) Stabilize the code and address reported issues. 4) Production quality release.
You mean use?
x-forwarding means that you are forwarding the communications between the x-client and x-server through a network tunnel. Windows doesn't have an end user exposed client/server paradigm within the window manager for you to redirect like that.
My point here is that the ability to do x-forwarding is a feature of X itself not of openssh. Adding openssh to windows isn't the "missing piece" you need to do the equivalent of x-forwarding.
I suppose you could setup an openssh tunnel; and then use RDP through it... and maybe that will be supported; but RDP already has encryption and security features, and can already be run through a VPN tunnel. So you aren't really gaining much.
</SNARK>
Editor, A1-AAA AmeriCaptions
Last I checked, it was good practice to have several compatible implementations.
very funny, windows only does posix 1 which is 1990. you must be confusing window's level of posix compliance with something that is actually useful.
it's a server, not a client
How would this improve it?
Maybe ... key management; using the windows platform key stores. Integration with active directory etc.
If I can expect a windows machine to have an ssh daemon capable of tunneling the RDP port to my machine locally, I would be gaining a lot. Such as no longer exposing RDP directly to the client via a VPN.
ssh -L 3389:127.0.0.1:3389 myusername@somewindowsserver
Run that, and then try to connect to remote desktop on your local machine. It works with any proper SSH server, including Cygwin. Do you have any other requests?
You're right. Windows would never do something so careless as sharing network passwords in an insecure manner.
We all just need to get over it.
Sure, Though if they use the windows Crypto API then you can only connect with the Windows Compliant SSH client.
Embrace, extend, and break. Nothing new here.
Powershell supports using COM object APIs directly, so of course the design is going to look very different to bash.
I think the $64,000 question is whether or not Microsoft will continue to update their SSH implementation as new features are added to the standard, and if they'll support everything that SSH is known for (i.e. SFTP/SCP, tunneling, etc.)
A somewhat nightmare scenario is that they just add initial (and possibly even broken) support for it that is feature incomplete, and as a result, you start seeing new SSH clients come around that are broken and/or only work with the Microsoft implementation. In other words, kind of like what Microsoft did to ruin HTML4.
Maybe because PowerShell treats everything as a .NET object, so you get all the power of using .NET methods against that data, whereas bash treats everything through the pipeline as text, and so of course they are quite different.
For tail, you go get-content -path -tail . Not an equivalent for head though. select-string is basically grep, with support for regex and all.
They're not writing their own crypto, they're utilizing an existing one.
Change is certain; progress is not obligatory.
There is a hack-around way to get a remote command line but it's painfully obtuse and makes no sense.
A hack-around? No, it's one single, built-in command:
Enter-PSSession -ComputerName COMPUTER -Credential USER
Instant access to an interactive shell on a server. To borrow the example from Microsoft's page, the following lists all the Powershell processes on the server and saves them into a file (also on the server):
PS C:\Users\Anon> Enter-PSSession -Computer Server01
[Server01]: PS C:\> Get-Process Powershell > C:\ps-test\Process.txt
[Server01]: PS C:\> exit
PS C:\Users\Anon>
The only complication comes from the fact that remote access is turned off by default, so you have to configure your server to accept connections. But that is really how you want a server to be; secure by default.
There are no POSIX compliant linux or BSD distros. Partly because no one wants to pay for the certification.They are still mostly compatible.
As for systemd, POSIX doesn't specify the init system so a linux distro using it is not less POSIX than one using initd. Systemd however relies on linux-specific features like cgroups, so you won't be able to use it on all POSIX systems.
While what you say was roughly true (though MS themselves used it internally to do things like host Hotmail for years) for the early versions, Interix (the name of the runtime environment - or pseudo-OS - that ran in the POSIX subsystem) versions 3.5 (XP) through 6.1 (Win7) were all quite usable. They added features that made it a lot more capable than most people seem to realize. I'm not claiming it didn't still have limitations (mostly in the forms of APIs that are common on modern *nix-like systems being missing) or bugs (though the 6.1 release quashed most of the worst of those), but it was quite usable and in many ways (speed, user account management, file system conventions, etc.) better than Cygwin.
The most obviously missing thing, in terms of day-to-day usability, was software package support; you could build your own (after getting and building all the dependencies) but it wasn't usually very pretty. There were a number of attempts to solve this, of which the two most notable were InteropSystems/SUACommunity (a now basically defunct site; Microsoft was funding it and stopped when Win8 deprecated the Unix subsystem) and NetBSD pkgsrc. SUACommunity offered a fairly-usable collection of pre-built binaries (including useful things like newer compilers than MS provided and compatibility shims to implement functions missing from the official Interix SDK), while pkgsrc offered a *huge* collection of software (comparable to a typical Linux distro) in source form, with scripts to build and install it in Interix.
I used Interix, with great success, for years. I used it on school projects (faster and needing less HD footprint than dual-booting or virtualizing Linux on Windows), I used it (bash, from SUACommunity) as my everyday shell, I used its tools (everything from sed to git) for everyday operations (even piping output between Win32 and POSIX programs) both at home and at work, I used its openssh server to remotely access my Windows box (and of course used its client too, including for X forwarding, though I had to use the Win32 "Xming" server), and I used it to compile programs that would only build on *nix but that I wanted to run on Windows. It was one of the first things I installed on any new Windows machine (helped that I had MSDN access so I could get the supported Windows versions).
I was really pissed when Microsoft deprecated that subsystem. It was still usable for a while, of course, but with the SUACommunity site losing funding, its repo became dangerously outdated and then went offline entirely. I wasn't willing to run code (especially stuff like git and ssh/sshd) with known vulnerabilities, wasn't interested in maintaining the packages from source, and knew I'd eventually want to move to Windows versions that didn't support Interix at all.
MSYS helps provide the stuff I need, like git. Cygwin has gotten better than it used to be, though (last I checked) it still fails on some things that Interix could handle (like case-insensitive file system behavior and sudo). PowerShell is, once you learn it, actually preferable to a Unix shell for most purposes. Hardware is now cheap/powerful enough that virtualizing is no longer a significant burden on most machines. In the end, though, I still find myself really missing the easy power and interoperability of Interix.
There's no place I could be, since I've found Serenity...
You do realize that, between Windows Crypto API (released with NT 4.0, in 1996) and OpenSSL (first released in 1998), the Windows crypto API is the older, right? Granted, SSLeay (the precursor to OpenSSL) was started in 1995, so it predates the NT4.0 release, but it's hard to say when development *started* on CAPI. In either case, you're talking about very long-existing and well-established crypto code.
There's no place I could be, since I've found Serenity...
It was incredibly useful, actually.
You couldn't actually do anything with it, of course - that'd defeat the purpose (Microsoft's purpose, that is). But it allowed government agencies with a POSIX requirement to install NT, letting Microsoft get a foot into a lot of doors it was previously locked out of.
Those who can't do, teach. Those who can't teach either, do tech support.
What's funny is that if you look at source code today, probably even here on Slashdot, you'll find all sorts of Firefox-specific code in there. But we bemoan the days of needing to code for IE6 like the troubles are behind us.
"So long and thanks for all the fish."