Microsoft Publishes OpenSSH For Windows Code (msdn.com) 164
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.
Re: (Score:1)
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.
Re: (Score:2)
I don't trust a single thing they [microsoft] do
Welcome to slashdot. Your position is quite shared on this place.
Re:IT'S A TR...REPEAT! (Score:5, Interesting)
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.
Re: (Score:2)
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.
Re:IT'S A TR...REPEAT! (Score:4, Insightful)
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.
IE6 (Score:2)
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 bui
Re: (Score:2)
Handwave the issue away for your favorite browser... There's nothing to see here!
Dude, you know I donated enough so that Mozilla put my name in a newspaper, right? (A long with a bunch of other names, I forget which paper - one of the big ones, but I still have a copy at home.) Don't worry, you can minimize it if you want but the principle is exactly the same. I don't even dislike Mozilla - I have stopped using their browser for usability reasons but I still support them financially when the mood strikes ju
Re: IE6 (Score:2)
I don't have a browser preference; as long as it complies with standards that's fine with me. Your point is that compatibility issues still exist. There will always be new features and varying levels of support for new features. This is an entirely different issue than Microsoft's attempt to create a deliberately incompatible Web tied to their own OS. At this point no one has the marketshare to even attempt such a thing, and certainly not Mozilla. You're trying to paint a difference in kind as a difference
Re: (Score:1)
Aww, that's precious. The naive little boy thinks that Microsoft collects data out of the goodness of their hearts.
Re: (Score:1)
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.
Will it tunnel applications? (Score:1)
Re: (Score:3)
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... an
Re:Will it tunnel applications? (Score:5, Informative)
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?
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
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... [ietf.org]
"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 cons
Re: (Score:2)
Such as RDP? That works. It works over SSH.
Re:Will it tunnel applications? (Score:5, Funny)
</SNARK>
Re: (Score:1)
...tunnel applications from my work box to my home box...
Hope you don't work for the State Department...
Re: (Score:3)
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.
Re: (Score:2)
In the real world, the term POSIX doesn't imply "certified," only "compliant."
They already are (Score:2)
Re: (Score:2)
Re: (Score:1)
So then they are compliant with a shitty spec?
Re: (Score:2)
It got better. (Score:5, Interesting)
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 [netbsd.org]. 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.
Re: (Score:3)
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.
Re:They already are (Score:4, Informative)
Re: (Score:2)
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
Re: (Score:1)
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.
Re: (Score:2)
Yep. There was actually a reverse-Wine project called Linux Binaries on Windows [cowlark.com] 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.
This will end well (Score:1)
> Leverage Windows crypto api’s instead of OpenSSL/LibreSSL and run as Windows Service
NSA compliant key exchange? Or just the inability to add large keys?
Re: (Score:1)
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?
Re: (Score:3, Insightful)
You're right. Windows would never do something so careless as sharing network passwords in an insecure manner. [microsoft.com]
We all just need to get over it.
Re: (Score:2)
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.
Re: (Score:2)
How about instead, they change the Windows crypto APIs to use OpenSSL?
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
"to pick apart and improve" (Score:2, Insightful)
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.
Re: "to pick apart and improve" (Score:1)
It won't improve it but Microsoft aren't interested in supporting and patching two underlying crypto implementations, and they will have to keep supporting theirs, so it's pretty natural from Microsoft's point of view.
Re: (Score:3)
Last I checked, it was good practice to have several compatible implementations.
Re:"to pick apart and improve" (Score:5, Informative)
How would this improve it?
Maybe ... key management; using the windows platform key stores. Integration with active directory etc.
Re: (Score:2)
No, they are replacing crypto code you can look at and audit for backdoors with crypto code written by a company who is well known for being extremely friendly with the NSA and cant be trusted not to put backdoors in their crypto code.
Thanks but no thanks Microsoft, I will be sticking with the cygwin ssh I already have (at least with that I can see all the crypto code)
Re: (Score:2)
If you are using Windows you already have a problem, it doesn't matter much on Windows if your SSH uses their crypto API, right ?
They can already just install hidden updates and what else could go wrong.
Leverage? (Score:5, Funny)
You mean use?
Re: (Score:1)
You mean use?
Man! I wish I had a mod point to leverage this upward.
Re: (Score:3)
You mean use?
Man! I wish I had a mod point to use this upward.
FTFY.
Re: (Score:1)
leverage [lev-er-ij, lee-ver-]
verb (used with object), leveraged, leveraging.
1. to use (a quality or advantage) to obtain a desired effect or result.
Re: (Score:1)
Wow. If leverage is a waste of letters to say "use," the above is DEFINITELY a waste of words to say "yes."
Hilarious: captcha: useful
CLEAVAGE? (Score:1)
Would always be welcome. What's that you say? Butts too? You're welcome.
Re: (Score:1)
Urbandictionary has a great definition. [urbandictionary.com]
About FREAKING Time. (Score:2)
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.
Time For What? (Score:1)
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.
Where is bash? (Score:2, Insightful)
Pointless without bash.
I''ll stick with cygwin, thanks.
Re: (Score:1)
> bash
Bad command or file name
Abort, Retry, Fail?
Re: (Score:1)
Get with the times, grandpa:
C:\>bash
'bash' is not recognized as an internal or external command,
operable program or batch file.
Re: (Score:2)
You too, gramps.
C:\>zsh
'zsh' is not recognized as an internal or external command,
operable program or batch file.
Hmm, ok, maybe not...
Re: (Score:2)
> Pointless without XTREE PRO GOLD
--FTFY.
/ get off ma lawn
Re: (Score:2)
Whoa, flashback. Thanks for that. I was... probably around 7 the last time I seriously used XTree? It was a great program for the time - a superb file manager, and I really liked the option to have it unload itself from memory when launching another program (read: game) - but unless I *had* to operate over a text console it really wasn't my preferred environment. I used GEOS/GeoWorks [wikipedia.org] for a few years in the early 90s, though still sometimes went back to XTree for heavier lifting in file operations (read: put
Re: (Score:2)
Ah, man, XTree was great back in the day (and probably perfectly adequate for most things today too).
And for Windows users, how about Norton Desktop back in the Windows 3.1 days? I was rather fond of that too, at the time.
Re: (Score:2)
Re: (Score:2)
5-10 years ago I would have agreed with you. These days, IMO, it's *far* better to just run Linux in a VM if you need a Windows base OS but want access to Unix/Linux command-line tools. VirtualBox and VMWare both support mapping filesystem locations within the host environment through to guests.
Cygwin is an impressive technical achievement, but it's a nightmare to install due to the archaic packaging system and installer. Certain tools (in particular, grep) perform much more poorly than running the "normal"
Re: (Score:2)
cygwin is a steaming pile of shit and should never be installed on anything you care about.
My biggest issue with Cygwin is bringing dependency hell to Windows.
Applications ported to Windows via Cygwin rely on cygwin1.dll (I'm thinking standalone applications, not the pure Cygwin Environment).
Only one instance of a DLL can be loaded in RAM, so if two Cygwin applications rely on different versions of cygwin1.dll, one will fail if loaded at the same time. Why can they not version the DLL or something (cygwin45.DLL)? Or not rely on Dynamic Linking? The DLL is always included with the application, and
Re: (Score:2)
Um... I'm going to give you the benefit of a doubt that you meant to say
.
What you wrote initially is completely false. Windows is entirely capable of loading two DLLs with the same name but different paths at the same time, across different processes.
Re: Where is bash? (Score:2, Informative)
Powershell supports using COM object APIs directly, so of course the design is going to look very different to bash.
Re: (Score:2)
where the heck is stuff like less, tail, head, etc? IIRC the last time I went looking for it, PowerShell's version of tail and grep are totally retarded and difficult next to the relative simplicity of $foo | tail -n 10 or something.
I agree that's a pretty stupid command not to replicate. PowerShell is object oriented, though, so parsing flat text files isn't as critical as you'd think.
Re: (Score:3)
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.
Re: (Score:2)
It kind of boggles my mind why Microsoft bothered to make PowerShell so unique and so incompatible with a well-known Unix shell like Bash.
PowerShell isn't always totally awful, but where the heck is stuff like less, tail, head, etc? IIRC the last time I went looking for it, PowerShell's version of tail and grep are totally retarded and difficult next to the relative simplicity of $foo | tail -n 10 or something.
This is why it is called 'Powers Hell' because of the brain fuck you get from using it. It has a long way to go before it reaches the elegance of shell. The object paradigm and perlishness is interesting.
They could have just made it a near-bash clone, along with a non-retarded shell window that supported putty or ConEmu-style terminal features and it would be SO MUCH better.
My question is whether it was just part of the "we're microsoft" culture of pretending that nothing else exists or whether it was some deliberately conspiratorial move to force an investment of time and effort on the part of Windows admins to keep them in the fold versus learning a skill that could be portable to Unix shells.
I've been spending a lot of time in the PS space lately to see if I can apply decades of shell programming to PS and found that I can easily. If MS are expecting this goal then they have failed because it took me an afternoon writing regular expressions to convert PS into shell scripts that ran. There are t
Re: (Score:2, Insightful)
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: [microsoft.com]
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
Re: (Score:2)
The problem with this is two fold. First you must have a Powershell to being with, which means you have to launch from a Windows machine. On the other hand if I can get a Powershell on a remote machine with SSH I can use any client under the sun from a mobile phone to a workstation and everything in between.
The second issue is good luck with getting holes in the firewall so you can do a remote Powershell in the first place.
putty (Score:1)
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?
Re:putty (Score:4)
it's a server, not a client
Re: (Score:1)
server AND a client ....
Re: (Score:2)
PuTTY is an excellent windows SSH client supporting a limited but growing subset of the SSH protocol. PuTTY's author, Simon Tatham, also publishes a fine SFTP client for windows. The only real problem with these programs is that they store settings in the registry instead of simple text configuration files.
OpenSSH is a superb implementation of the entire SSH protocol suite, both client & server, available for multiple operating systems - now inclu
Re: (Score:2)
On Soviet-Earth, you can trust OS audits you!
OpenSSH on Windows in 2001 (Score:2)
Re: (Score:2)
never forget that time jdavidb got sshd running in cygwin and an AC called him an idiot
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:1)
the three rules of crypto (Score:2)
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.
Re: (Score:3)
Re: (Score:3)
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.
Re: (Score:2)
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
Rules #1, #2 and #3 only apply to your average Joe developer. Microsoft's cryptography libraries predate OpenSSL and they serve as the foundation of dozens of Microsoft products including Windows Server etc.
Re: (Score:2)
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.
Soooo what your saying is everyone should dump OpenSSL and LibreSSL for the windows ones that predate it? I know OpenSSL has had trouble but that is fucking moronic. FYI those rules are meant to apply to home devs and small time dev shops where it is nearly always far worse to write your own security than to utilise one that is professionally written.
Re: (Score:2)
That's half of it - getting crypto done right can be a very subtle thing, and doing something even slightly different can have an unexpected/unintended and sometimes catastrophic impact on the crypto. It's agonizingly easy to accidentally introduce bias without noticing.
The other half of that is the "many eyes make for sha
Re: (Score:2)
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