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.
The question is for whom?
1)Leverage Windows crypto APIs instead of OpenSSL/LibreSSL and run as Windows Service
How would this improve it? How open is this crypto code? Yes, Open SSL/Libre SSL has had problems but if the Windows Crypto API is not open then they are replacing known problems for unknown problems.
Well, there's spam egg sausage and spam, that's not got much spam in it.
You mean use?
There should be no reason why the SSH protocol should be used standard across the board. Not having it on Windows has created way too many unencrypted ports. Just as long as MS just doesn't screw it up and only make it a secure Telnet client, but where you can secure port communication across servers.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
POSIX is just a set of standards. Windows was POSIX compliant back in NT 3.5. You must be confusing POSIX with something else. You won't find me defend Microsoft often, so mark this on your calendar..
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Just as long as MS just doesn't screw it up and only make it a secure Telnet client, but where you can secure port communication across servers.
MS products have LONG had the ability to secure all server communications via IPSec. I don;t see what it brings them, beyond an encrypted telnet session. Though adding to my ability to manage windows servers form the command line, from my Linux terminal does help me. Unfortunately it also requires that I learn PowerShell WichIsJustTheMost-Fucking-AwefulCommandLine-Tool.
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
Pointless without bash.
I''ll stick with cygwin, thanks.
Perhaps they will just "improve the user experience" by sending the passwords and keys secretly to MS's servers? Or will that feature be added on next forced update?
Would always be welcome. What's that you say? Butts too? You're welcome.
Obviously, I didn't rtfa.l, but how is this different from/better than, say, putty?
And why should I trust this over putty or running openssh inside cygwin?
Wow, we've come a long way. I remember getting sshd from OpenSSH running in Cygwin long ago and posting about it here on Slashdot. I was just playing around and never messed with it further, but it's made a fun story to tell.
Secession is the right of all sentient beings.
After the nerve that Microsoft showed with the whole Malware 10 fiasco, I don't trust a single thing they do any more.
I never thought I would say that I wish Steve Ballmer had never left.
How about instead, they change the Windows crypto APIs to use OpenSSL?
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.
I don't trust a single thing they [microsoft] do
Welcome to slashdot. Your position is quite shared on this place.
This is probably true.
The problem with telnet is it's still vulnerable (all the clear).
While an up to date OpenSSH OpenSSL/LibreSSL is not.
New things are always on the horizon
I think you mean "fewer" vulnerabilities.
Rule #1 of crypto: don't write your own
Rule #2 of crypto: DON'T write your own
Rule #3 of crypto: DON'T WRITE YOUR OWN
They're not difficult rules to follow. But then they seem to enjoy writing their own rules, despite what's good for the consumer.
I work for the Department of Redundancy Department.
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.
It is you that is the idiot.
From RFC3696 Written by the same person that wrote the RFC for SMTP.
http://tools.ietf.org/html/rfc...
"Without quotes, local-parts may consist of any combination of
alphabetic characters, digits, or any of the special characters
! # $ % & ' * + - / = ? ^ _ ` . { | } ~
period (".") may also appear, but may not be used to start or end the
local part, nor may two or more consecutive periods appear."
So, a valid Email address can be
F-U!Now@somewhere.com
U=Id10t@somewhere.com
IMa*here@somewhere.com
and even
I^_^I@somewhere.com
Believe it or not These are valid Email addres by the RFC as well
Joe\@home@somewhere.com
Joe\ Smith@somewhere.com
Aww, that's precious. The naive little boy thinks that Microsoft collects data out of the goodness of their hearts.
Doesn't Windows Telnet support NTLMv2 encryption and authentication?
Change is certain; progress is not obligatory.
I've done RDP tunneling just fine with Cygwin's OpenSSH:
ssh windows-server -L 13389:127.0.0.1:3389
Change is certain; progress is not obligatory.
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...
NT was designed from the beginning to support essentially a union of the system calls from a bunch of OS standards, which it implemented as "subsystems". Win32 is the *default* subsystem, but it's still a subsystem; calling the Win32 "system call" CreateFile goes into a user-mode library that translates it into the actual NT syscall NtCreateFile. NtCreateFile also implements all the functionality needed for POSIX open. Similarly, NtCreateProcess has several options never used by the Win32 call CreateProcess, but that facilitate syscalls such as POSIX fork.
I'm very skeptical that the POSIX subsystem "can't be added without breaking way too many other things" since it was available in Win8.0 (NT 6.2) and removed in Win8.1 (NT 6.3), and there's really not *that* big a difference under the covers between those versions. Maybe MS took the opportunity of Win10 to make a bunch more changes that they couldn't make without breaking POSIX compatibility, but I'm skeptical.
There's no place I could be, since I've found Serenity...
...tunnel applications from my work box to my home box...
Hope you don't work for the State Department...
“He’s not deformed, he’s just drunk!”
I remember OpenSSL having a giant security breach this year. I don't remember Microsoft's internal API suffering from a similar failure. The NSA is as likely and as capable of slipping a back door into OpenSSL as they are into Microsoft's internal code base. And as evidenced by Heartbleed, even with lots of eyes, we aren't confident that it will be noticed.
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.
Wut? Ruin HTML4? HTML 5 is largely HTML4 + DHTML. Microsoft added features that developers wanted. It took from 1997 when Microsoft released DHTML until 2014 when the w3c formalized HTML5 for an official "Standard" to decide that Microsoft's approach was wrong.
Between 1994 when HTML4 was ratified and 20 years later when HTML5 was ratified essentially everything was equally standards non-compliant. Microsoft, Apple and Netscape were all adding extensions and moving exponentially faster than the w3c. The lack of standards compliance is an indictment of w3c's ability to keep up with the fast moving pace needed for innovation to take place. We're seeing the same thing again with webkit adding extensions that developers want. But since the w3c is so slow to offer standards the webkit extensions are simply going to be the defacto standard. Hopefully we'll see HTML6 before 2035 and not bemoan in 5 years how horribly non-standards compliant webkit has become as browser developers refuse to restrict themselves to the W3C's glacial pace.
In the real world, the term POSIX doesn't imply "certified," only "compliant."
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."
Such as RDP? That works. It works over SSH.
"So long and thanks for all the fish."
Aww the paranoid idiot thinks Microsoft actually wants to read his email and look through his files
You mean they don't want to? Then I guess they won't mind stripping all of the spyware out of Windows 10 and changing their EULA to restrict themselves from my files, right?
Oh wait, you're a just an idiot shill.
And this, ladies and gentlemen, is why Wine Is Not an Emulator. Wine is essentially the same thing, but translating to Linux system calls rather than NT system calls.
He's not wrong - shill or not - OpenSSL is a disaster. That's why the OpenBSD group forked it and started LibreSSL, to clean up the mess. The heartbleed vulnerability was one such consequence of OpenSSL's spaghetti-like design.
Oolite: Elite-like game. For Mac, Linux and Windows
There's a huge difference between more-or-less-standard but vendor-prefixed trial CSS features and IE6's DX filters and transforms. IE6 was not even theoretically portable or standards-based. The Venn diagram of feature support for browsers is mostly intersecting, but IE6 was nearly a disjoint set. It supported a bare minimum of CSS and HTML standards (badly) and otherwise required entirely separate code. It's not that compatibility is no longer a concern, but these days no one is dumb enough to try to build their own platform-locked Web.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Wifi sense does not seem to be insecure in the least. It is as secure as you telling your friend your password. And it is as deliberate too. If you want to troll, at least make sure you are accurate.
Wealth is the gift that keeps on giving.
Yea, its MS's fault that some other application is broken ... sudo isn't part of SSH or Windows, they're using some other app to get sudo like functionality and that app is broken, or there is a terminal emulation issue. Probably doesn't have much at all to do with openssh
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Yep. There was actually a reverse-Wine project called Linux Binaries on Windows that basically strapped an ELF program loader to the POSIX subsystem. It never really got anywhere - partially because it was one person's hobby project, not a major long-running effort like Wine, and partially because a lot fewer people cared - but it was a cool idea. In theory, the same thing could be done with Cygwin, but it would be (even) less performant.
There's no place I could be, since I've found Serenity...