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.

Comments

IT'S A TR...REPEAT!

[Anonymous Coward]

Never liked any Star Wars movie. Didn't like Godfather. None of them. Never saw Goodfellas.

Re:IT'S A TR...REPEAT!

[Anonymous Coward]

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:IT'S A TR...REPEAT!

[NotInHere]

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!

[Anonymous Coward]

I was just echoing this exact sentiment not two days ago.

This new MS CEO doesn't seem to understand the notion of privacy. Having said this, I still trust Microsoft far more than I do Google.

Re:IT'S A TR...REPEAT!

[ArmoredDragon]

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:IT'S A TR...REPEAT!

[Anonymous Coward]

In other words, kind of like what Microsoft did to ruin HTML4.

What people seem to forget about this is that HTML4 was craptastic and incapable. Microsoft and Netscape added a heap of useful (proprietary) functionality to their browsers to compete with eachother but also to avoid the glacial pace of getting improvements added to the standard. Now that HTML has finally caught up in terms of functionality Microsoft has dropped their proprietary extensions support in their latest browser.

Proprietary extensions (and plugins) are a pain but had Microsoft not been competing with Netscape we would all be buying Netscape's browser and be locked in by their proprietary extensions to the standard.

Re:IT'S A TR...REPEAT!

[Anonymous Coward]

Aww, that's precious. The naive little boy thinks that Microsoft collects data out of the goodness of their hearts.

Re: IT'S A TR...REPEAT!

[Anonymous Coward]

Says the clueless noob who has no concept of the importance of privacy. I understand that at your age you can't think more than a couple days ahead but when you grow up you might feel differently.

Re:IT'S A TR...REPEAT!

[Anonymous Coward]

Aww, that's precious. The naive little boy thinks that Microsoft collects data out of the goodness of their hearts.

Aww the paranoid idiot thinks Microsoft actually wants to read his email and look through his files, the same people who have been telling us that Microsoft has had backdoors into the OS to access this information for years. So was that all bullshit? The NT & 2000 source code leaks reveal these? Why are they not just using these secret backdoors to collect all your personal information? Did they stop working or something? If they really wanted to read your emails then why not just use the NSA-style web dragnet then you can get that information from everybody not just Windows users? Your conspiracy theory makes no sense.

Seriously they do it so they can build these learning systems, that is the whole point of it, how do you suppose you can build learning machines with no data to work with?

Re:IT'S A TR...REPEAT!

[im_thatoneguy]

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.

Re:IT'S A TR...REPEAT!

[KGIII]

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.

Re:IT'S A TR...REPEAT!

[Anonymous Coward]

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.

Re: IT'S A TR...REPEAT!

[Anonymous Coward]

You're an idiot. There is a huge difference between someone voluntarily putting stuff up in public and Microsoft stealing private, guarded data straight from their PC.

Seriously, never get into the IT field. You'd be fired on your first day for lack of even basically security and networking knowledge.

Re: IT'S A TR...REPEAT!

[Anonymous Coward]

You're an idiot. There is a huge difference between someone voluntarily putting stuff up in public and Microsoft stealing private, guarded data straight from their PC.

Right but the latter does not happen. They arent reading your emails and stealing your files, that is just sensationalist bullshit perpetuated by scaremongers and terminally retarded like you that don't have the slightest clue about the difference between collecting telemetry data and "stealing" files. Is it some conspiracy agenda or genuine stupidity?

Re:IT'S A TR...REPEAT!

[Anonymous Coward]

It's telemetry data you fucking retard, learn the difference.

Re: IT'S A TR...REPEAT!

[Anonymous Coward]

If they don't want the data, then why are they collecting it even after all "privacy" settings have been set and why is it in the EULA?

Finally, we will access, disclose and preserve personal data, including your content (such as the content of your emails, other private communications or files in private folders), when we have a good faith belief that doing so is necessary to:
1. comply with applicable law or respond to valid legal process, including from law enforcement or other government agencies;

2. protect our customers, for example to prevent spam or attempts to defraud users of the services, or to help prevent the loss of life or serious injury of anyone;

3. operate and maintain the security of our services, including to prevent or stop an attack on our computer systems or networks; or

4. protect the rights or property of Microsoft, including enforcing the terms governing the use of the services - however, if we receive information indicating that someone is using our services to traffic in stolen intellectual or physical property of Microsoft, we will not inspect a customer's private content ourselves, but we may refer the matter to law enforcement.

You are one naive tool.

Re:IT'S A TR...REPEAT!

[Anonymous Coward]

Prove it. Oh wait, Microsoft encrypts their spyware data so that users can't even see what is happening on their own systems. I'm sure that's just to "keep users safe" too.

Finally, we will access, disclose and preserve personal data, including your content (such as the content of your emails, other private communications or files in private folders)

No it isn't, you ignorant noob.

Will it tunnel applications?

[damn_registrars]

I presume the answer to this is no, but I don't see an answer in the power shell blog post that this linked to. I expect I'm not the only admin who occasionally uses x-forwarding in ssh to tunnel applications from my work box to my home box, this could be useful for windows admin stuff as well (though certainly not a trivial matter).

Re:Will it tunnel applications?

[vux984]

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.

Re:Will it tunnel applications?

[ewhac]

I'm sorry; tunneling will only be available in SSH for Windows Server 2012 Enterprise (7 connections max; see your Microsoft rep for additional connection licenses).

</SNARK>

Re:Will it tunnel applications?

[Anonymous Coward]

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.

Re:Will it tunnel applications?

[Minwee]

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:Will it tunnel applications?

[Anonymous Coward]

I would not hold my breath expecting RDP tunneling. Hell Micro$oft cant even get a simple chat client (lync) right. Sure it is client/server but the server is not multi-point aware. Have Lync loaded on two different systems and you can get logged in but the message goes to one system while the sound plays on the other.

It is F-ing annoying and I can not seem to find a place to let them know there is an issue/complain on MS's site.

Add to it that MS's website requires you create an account with an email for any of the "Contact us" sections, then they ignore the RFC and dont allow a + in the e-mail address. So joe+smith@someplace.com is rejected.

So far all I have seen is crap software from them with lots of bugs and problems.

Re:Will it tunnel applications?

[pfleming]

This is how I do it.

Re: Will it tunnel applications?

[Anonymous Coward]

RDP tunneling already works with generic SSH tunnels. So as long as they support that, which is likely considering the OpenSSH heritage, it should work fine.

Re:Will it tunnel applications?

[Anonymous Coward]

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

Re:Will it tunnel applications?

[Anonymous Coward]

Windows doesn't have an end user exposed client/server paradigm within the window manager for you to redirect like that.

Any timeline for when this deficiency of Windows is going to get fixed?

Re:Will it tunnel applications?

[Anonymous Coward]

I've got exactly one use case of SSH on Windows right now that's difficult to replace:

ssh adminuser@prodserver cd somedir \&\& tar -zcf - proddir > backup.tgz

I have my own Win32 port of tar. I think the change directory and continue if successful can be done in powershell just fine.

Re:Will it tunnel applications?

[Ash-Fox]

I would not hold my breath expecting RDP tunneling.

I've done RDP tunneling just fine with Cygwin's OpenSSH:

ssh windows-server -L 13389:127.0.0.1:3389

Re:Will it tunnel applications?

[fustakrakich]

...tunnel applications from my work box to my home box...

Hope you don't work for the State Department...

Re:Will it tunnel applications?

[Anonymous Coward]

In circumstances that something is already running on 3389 on your local machine (such as RDP) just choose a different port. e.g.

ssh -L 3389:127.0.0.1:3390 myusername@somewindowsserver

Re:Will it tunnel applications?

[Anonymous Coward]

I believe that this is what you meant: ssh -L 3390:127.0.0.1:3389 myusername@somewindowserver

Re:Will it tunnel applications?

[KGIII]

Such as RDP? That works. It works over SSH.

Re:Will it tunnel applications?

[Anonymous Coward]

The Wayland project is working hard on "fixing" it, by taking the feature away from Linux systems.

Go all in!

[Anonymous Coward]

Microsoft should just dump Windows and go all in for POSIX.

Re: Go all in!

[Anonymous Coward]

Right while Linux distos break POSIX and go alk in for systemd

Re: Go all in!

[Anonymous Coward]

(Partial) Posix compliance was removed from windows and can't really be added without breaking way too many things.

There are so many things that are different (Take "fork" as a prime example) that just won't end up in Windows.

Re: Go all in!

[Anonymous Coward]

If MS went all in with POSIX, someone would have to re-port svchost.exe back into Windows for Linux compatibility:)

Re: Go all in!

[GuB-42]

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: Go all in!

[cbhacking]

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.

Re: Go all in!

[Anonymous Coward]

MacOS X is a posix compliant BSD.

Re: Go all in!

[Aighearach]

In the real world, the term POSIX doesn't imply "certified," only "compliant."

Re: Go all in!

[Anonymous Coward]

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: Go all in!

[cbhacking]

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.

Re: Go all in!

[Anonymous Coward]

Too difficult? For a third party using Win32 to emulate fork(2), maybe.
Microsoft could just throw an intern to add a pair of functions.
Then contribute a diff to Cygwin and voilÃ.
Sure they sort of hate MS but their UNIX works. Forking Cygwin sounds a lot saner to me than forking OpenSSH while ensuring you get no security support from upstream.
And all to pipe encrypted text between what VB6 apps?

upstream

[Anonymous Coward]

how about upstreaming?
I'd put that on the roadmap at least...

This will end well

[bobstreo]

> 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:This will end well

[Anonymous Coward]

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:This will end well

[MobyDisk]

How about instead, they change the Windows crypto APIs to use OpenSSL?

Re:This will end well

[Anonymous Coward]

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.

Re:This will end well

[Anonymous Coward]

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:This will end well

[Anonymous Coward]

Because the Windows crypto API is better and more secure in every way, and easier to keep patched and updated?

Re:This will end well

[Anonymous Coward]

But but GP uses Facebook and plays Call of Duty on Windows 10 all of the time and he hasn't had anything bad happen. Obviously Windows 10 must be a great choice for everyone if it can hold up under that kind of serious business!

Re:This will end well

[Anonymous Coward]

LOL! Thanks for that laugh, shill.

Re:This will end well

[Anonymous Coward]

I was about to post the same thing...

Use Microsoft APIs. Translation: allow government access to all who use it.

OpenSSL foundation should file suit to keep MS from using the good (? better than MS) OpenSSL name on this travesty of security.

Re:This will end well

[im_thatoneguy]

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.

Re:This will end well

[Anonymous Coward]

I remember OpenSSL having a giant security breach this year. I don't remember Microsoft's internal API suffering from a similar failure.

That is because it is even harder to find such a breach in closed source code than it is in a complicated but open-source codebase like OpenSSL. Many vulnerabilities in Microsoft's code will simply never be found.

The NSA is as likely and as capable of slipping a back door into OpenSSL as they are into Microsoft's internal code base.

In OpenSSL, the NSA can try to sneakily introduce a back door that no-one notices. They have probably tried that, maybe even succesfully. However, they can just force Microsoft to add it to their crypto API. Both are vulnerable to NSA and other government organisations, but the risks are clearly a lot larger for commercial, closed-source software from a country with a government that is hostile to privacy.

Re:This will end well

[Alioth]

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:This will end well

[perryizgr8]

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:This will end well

[Anonymous Coward]

Keep drinking the Kool-Aid buddy.

Re:This will end well

[Anonymous Coward]

So? That doesn't make it less secure than Microsoft's garbage which has been getting hacked for decades with no end in sight.

"to pick apart and improve"

[UnknowingFool]

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"

[Anonymous Coward]

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:"to pick apart and improve"

[Anonymous Coward]

"then they are replacing known problems for unknown problems."

Like last time? er... or should I say like every time.

Last time, their multiple layered solutions, had multi layered vulnerabilities. from the Key and seed, to the code, and the isolation layer, etc..etc.. Worse than holding water in a sieve. Some of thse bugs/vulnerabilities have existed for decades.

Microsoft needs to become Fort Knox, instead of a festering pile of rat dung.

Re:"to pick apart and improve"

[ericloewe]

Last I checked, it was good practice to have several compatible implementations.

Re:"to pick apart and improve"

[vux984]

How would this improve it?

Maybe ... key management; using the windows platform key stores. Integration with active directory etc.

Re:"to pick apart and improve"

[Anonymous Coward]

Lolz, no, cue the h4x0r security 'l33t experts' who will tell you to just go ahead and use *insert random unknown gibberish-looking URL to an overseas server hosting crypto libraries* because, 'hey at least it isn't MS'. What a wonderful security heuristic, when you can convince yourself it works.

Re:"to pick apart and improve"

[Anonymous Coward]

How would this improve it?

Maybe ... key management; using the windows platform key stores. Integration with active directory etc.

GP post said IMPROVE.

Re:"to pick apart and improve"

[jonwil]

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:"to pick apart and improve"

[Anonymous Coward]

Any random site on the net is more trustworthy than Microsoft have proven themselves to be.

Re:"to pick apart and improve"

[Anonymous Coward]

That's good, yes. But how do we know the ones being linked in from the Windows crypto APIs aren't backdoored or have their own unique security problems unless the code is available?

Re:"to pick apart and improve"

[Lennie]

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?

[cyber-vandal]

You mean use?

Re:Leverage?

[uCallHimDrJ0NES]

You mean use?

Man! I wish I had a mod point to leverage this upward.

Re:Leverage?

[cdrudge]

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:Leverage?

[Anonymous Coward]

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

Re:Leverage?

[Anonymous Coward]

Microsoft means: Change their software to use a propriety version of SSH that isn't backwardly compatible with this open-source version.

Re:Leverage?

[LinuxIsGarbage]

You mean use?

Man! I wish I had a mod point to use this upward.

FTFY.

Re:Leverage?

[Alien1024]

Urbandictionary has a great definition.

Welcome news

[Anonymous Coward]

This will remove a huge pain point in working with Windows. There are many more, but not having SSH access is a big one.
Next on the list should be porting Bash to Windows so they have a decent shell.

Re:Welcome news

[Anonymous Coward]

MS's SFU had ksh. Why would they take a step backwards for bash?

Re:Welcome news

[Anonymous Coward]

Bash is the default shell on most, if not all, Linux distros. SFU is EOL'd. Still, thanks, as I didn't know about that project.

About FREAKING Time.

[jellomizer]

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.

Re:About FREAKING Time.

[Anonymous Coward]

You do mean: "There should be no reason why the SSH protocol shouldn't be used standard across the board."

They already are

[s.petry]

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

Re:They already are

[jandrese]

It should be pointed out however that Microsoft carefully designed their POSIX subsystem to be almost completely useless in the real world. It was missing just enough critical (but not technically POSIX spec) parts to make it worthless.

Re:They already are

[ralphsiegler]

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.

Re:They already are

[Anonymous Coward]

So then they are compliant with a shitty spec?

Re:They already are

[Anonymous Coward]

A. Modern Windows no longer includes a POSIX subsystem
B. Classic Windows POSIX subsystem was trash
C. Right in the blog post they talk about had to hack up the code to get around the lack of POSIX compliance in (modern) Windows and how that is going to be a barrier to get their changes contributed back upstream since upstream requires POSIX-complient code

Re:They already are

[Anonymous Coward]

Careful there. It is hard to score when you keep moving the goal posts.

Re: They already are

[Anonymous Coward]

Make a shit-proof spec and someone will find a way to be a greater shit.

Re:They already are

[jandrese]

Pretty much. POSIX was kind of a minimal set of features that were common to the major Unix vendors at the time.

Re:They already are

[spauldo]

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

[Anonymous Coward]

Not to mention all the Posix calls are prefixed with underscore. Complete PITA. Having actually tried to port Posix code back in the day, I *very* quickly moved to Cygwin.

Time For What?

[Anonymous Coward]

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.

Re:Time For What?

[Anonymous Coward]

If they are using the Windows Crypto API's then toss out the standard open ssh on linux and install the new and improved Microsoft SSH. Where they store your keys on there cloud server. lol

Re: Time For What?

[Anonymous Coward]

Changing the crypto backed on the server won't require new ssh clients. The Microsoft crypto API powers a non trivial amount of https websites, and that works just fine with OpenSSL browsers.

Where is bash?

[nyet]

Pointless without bash.

I''ll stick with cygwin, thanks.

Re:Where is bash?

[Anonymous Coward]

> bash
Bad command or file name
Abort, Retry, Fail?

Re:Where is bash?

[Anonymous Coward]

Get with the times, grandpa:

C:\>bash
'bash' is not recognized as an internal or external command,
operable program or batch file.

Re:Where is bash?

[Anonymous Coward]

cygwin is a steaming pile of shit and should never be installed on anything you care about.

Re:Where is bash?

[ralphsiegler]

Cygwin is extremely useful when someone is forced to have a Windows machine but needs to work with Linux, BSD and Unix systems. Having the bash shell alone is reason enough to use it, let alone command line scriptable ssh, scp, sftp etc.

Re:Where is bash?

[Anonymous Coward]

cygwin is a steaming pile of shit and should never be installed on anything you care about.

Well, Linux has systemd, so they're even.

Re:Where is bash?

[LinuxIsGarbage]

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 installed in the application folder, so it's not even like it's space savings by relying on a shared 3 MB file.

Re:Where is bash?

[swb]

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.

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.

Re:Where is bash?

[Anonymous Coward]

To be brutally honest bash isn't going to be very useful for administering windows servers - Which is what this is for.

It's meant to remotely access powershell, which is what you'd probably want to use to administer your windows servers.

It fills the very glaring gap that's been present since Microsoft has been saying "Hey. Look at this great powerful command line scripting environment that lets you do everything" - Admins went "Great. So how do I remotely access this? Where's the ssh daemon?"

Long story short: You didn't. There is a hack-around way to get a remote command line but it's painfully obtuse and makes no sense. (And is in no way cross platform) The closest analog is to RDP in and get a powershell console (Which even server core supports)

Admins just want to be able to fire up putty (Or whatever they like) and do some quick 'n dirty work.

You can use powershell all day long to do remote, scripted tasks on servers but it's only good for repeatable tasks that were planned ahead of time. Sometimes you need that interactive environment.

Re: Where is bash?

[Anonymous Coward]

Powershell supports using COM object APIs directly, so of course the design is going to look very different to bash.

Re:Where is bash?

[Anonymous Coward]

How is that modded troll? It addresses the most obvious question in the whole fscking thread. Facepalm.

Re:Where is bash?

[chispito]

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:Where is bash?

[TheRealSlimShady]

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:Where is bash?

[Anonymous Coward]

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.

Re:Where is bash?

[MrKaos]

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 things to like and hate about PS however I think it is a good move on MS's part along with ssh.

It really is just proof that the *IX paradigm was the correct one all along and now many MS enthusiasts will start to understand why it is the right way - even if the PS offering is still messy and rough. Coupled with ssh I can administer MS boxes with ruthless efficiency that has been impossible in the MS space up until now.

Re:Where is bash?

[cbhacking]

Um... I'm going to give you the benefit of a doubt that you meant to say

Only one instance of a DLL can be loaded in a given process address space, so if two Cygwin libraries used by the same application rely on different versions of cygwin1.dll, one will fail

.

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?

[Wolfrider]

> Pointless without XTREE PRO GOLD

--FTFY.

/ get off ma lawn

Re:Where is bash?

[jabuzz]

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.

Re:Where is bash?

[Anonymous Coward]

It isn't that much of a problem requiring a Windows client as it is the most popular desktop OS around. Also, it doesn't require luck to get a hole in the firewall, just an administrator doing his job. There is always VPN to punch through into your network.

But the issue I was addressing wasn't that SSH access isn't better than what the current solution (it obviously is, otherwise they wouldn't be implementing it now), The point that I was making was that there is a current solution at all and that it wasn't some difficult hack.

Re:Where is bash?

[blincoln]

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" versions in a Linux VM. Very few people typically have it installed in a given organization, so just about anything you create with it ends up being a one-off hack for your own system, not something that can be shared.

Re:Where is bash?

[cbhacking]

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 for a few years in the early 90s, though still sometimes went back to XTree for heavier lifting in file operations (read: putting games onto, or pulling them off of, floppy disks). File Manager in WFW 3.11 pretty much replaced XTree for me, though I suspect I still had it installed on my first Win-capable box.

Re:Where is bash?

[monkeyhybrid]

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:Where is bash?

[monkeyhybrid]

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.

CLEAVAGE?

[Anonymous Coward]

Would always be welcome. What's that you say? Butts too? You're welcome.

putty

[Anonymous Coward]

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

[danbob999]

it's a server, not a client

Re:putty

[Anonymous Coward]

server AND a client ....

Re:putty

[Medievalist]

but how is this different from/better than, say, putty?

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 including Windows. It's significantly superior in both performance and capability to proprietary servers such as Tectia (I use both every day, so I can compare).

And why should I trust this over putty or running openssh inside cygwin?

You should not trust any of the above if you're running a closed source OS, because either way, you will be forced to run code you cannot audit or verify. Arrange your affairs so that trust is unnecessary, or switch to an OS you can audit, or to an OS that is audited by people you trust.

Re:putty

[monkeyhybrid]

On Soviet-Earth, you can trust OS audits you!

OpenSSH on Windows in 2001

[jdavidb]

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.

Re:OpenSSH on Windows in 2001

[Lakitu]

never forget that time jdavidb got sshd running in cygwin and an AC called him an idiot

NO MORE TELNET?

[Anonymous Coward]

about bloody time.

Re:NO MORE TELNET?

[Lennie]

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:NO MORE TELNET?

[Endlisnis]

I think you mean "fewer" vulnerabilities.

Re:NO MORE TELNET?

[Ash-Fox]

The problem with telnet is it's still vulnerable (all the clear).

Doesn't Windows Telnet support NTLMv2 encryption and authentication?

Leverage Windows crypto APIs

[Anonymous Coward]

see, that's where the problem is, because now it can't be trusted to be secure.

Windows Crypto API

[Anonymous Coward]

so basically they need to import the NSA keys, the NSA exploits, and other non-free components to ensure the safety of the American People.

Re:OpenSSL vs. someone's proprietary? Seriously?

[Anonymous Coward]

The MS library, sad to say, is superior to OpenSSL.

It won't be better than LibreSSL.

I don't mind them not leveraging OpenSSL. But I would like to see them leverage, or enable to bring in, LibreSSL.

LOL guess the got some learning to do...

[Anonymous Coward]

https://github.com/PowerShell/Win32-OpenSSH/issues/14

Re:LOL guess the got some learning to do...

[BitZtream]

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

the three rules of crypto

[v1]

1) Leverage Windows crypto APIs instead of OpenSSL/LibreSSL

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:the three rules of crypto

[Ash-Fox]

They're not writing their own crypto, they're utilizing an existing one.

Re:the three rules of crypto

[cbhacking]

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:the three rules of crypto

[im_thatoneguy]

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:the three rules of crypto

[bloodhawk]

1) Leverage Windows crypto APIs instead of OpenSSL/LibreSSL

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:the three rules of crypto

[v1]

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.

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 shallow bugs" principle. Before anyone jumps, no that's not a guarantee, there have been several cases of a bug being in plain sight for years in the linux kernel for example. But as a general rule, the more people that can review the code, the fewer bugs it will continue to harbor. Unless MS's APIs are open-source (I don't know for certain but I rather doubt it!) then instead of thousands of reviewers, it's had at most a dozen serious examinations. And the notion that MS is assisting shadowy short initials isn't even a bit far-fetched. Back doors have an extremely short life-expectancy in open-source. (I've seen it happen with a rogue commit, but they get found in under a few weeks typically) No open source? No telling what's in there. It's much harder to identify a well-hidden back-door or especially an intentional bias in closed source.

Not GPL

[Anonymous Coward]

This is impossible. OpenSSH isn't GPL. Everybody knows companies don't release code unless the GPL forces them to. Thanks god the GPL is there to protect my freedoms.

It got better.

[cbhacking]

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.

IE6

[Tenebrousedge]

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.

Re:IE6

[KGIII]

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 just because there needs to be open source competition. It's okay to admit there are problems. That's the first step towards recovery, they say.

Re: IE6

[Tenebrousedge]

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 of degree. Vendor prefixes are part of the standardization track now, not attempts to circumvent it, and no one is interested in any platform-specific features.

Re:-jews hiding posts-

[Anonymous Coward]

You high on drugs? Those links were not posted by a Jew.

Re:-jews hiding posts-

[Anonymous Coward]

The links in my - jew propaganda distraction - post, were obviously not posted by a jew. They and my post, expose you and your scum tribe. Some of them -
http://67.225.133.110/~gbpprorg/judicial-inc/Auschwitz.htm
http://67.225.133.110/~gbpprorg/judicial-inc/Hopie_ike.htm
http://67.225.133.110/~gbpprorg/judicial-inc/810dresden_primary.htm
http://67.225.133.110/~gbpprorg/judicial-inc/81murder_incorporated.htm
http://67.225.133.110/~gbpprorg/judicial-inc/Coure_d_Arlene.htm
http://67.225.133.110/~gbpprorg/judicial-inc/False_Flags_summary.htm http://jewishcrimenetworkdid911.blogspot.com/ - they kill and blame others.

The idiot bs links in your post from your jew fake 'alternative' media to distract from my post, those links were posted by you, a jew.
Fck off Pedo.

--
To others, the first post has more, and the facts as stated, copy all to rer read, add these below also in the first 'jew distraction post'. Stop the jews or they will do this to millions more kids when they kill adults with their bio virus. Targets by race and by age, so they keep the children. The jew fraud 'government' and 'states' were a fraud from the start. No one will stop them but you. Put the link pages on disk for backup. Don't wait, a lot is being wiped off the web. You won't find these. They will also wipe computers. They already can so just copy pages to disk. Pass on links to others. Make tribes. Chemtrail virus.

http://67.225.133.110/~gbpprorg/judicial-inc/haut_de_la_garenne_home_in_st_ma.htm
http://67.225.133.110/~gbpprorg/judicial-inc/84incestuous_dungeon_master_is_a_z.htm
http://67.225.133.110/~gbpprorg/judicial-inc/freidman_pedophiles_from_hell.htm
http://67.225.133.110/~gbpprorg/judicial-inc/7_18_zionists_target_children_in_porn.htm
http://67.225.133.110/~gbpprorg/judicial-inc/bl.ood_or_cannibal.htm
http://67.225.133.110/~gbpprorg/judicial-inc/marc_dutroux.htm
http://67.225.133.110/~gbpprorg/judicial-inc/Hate_Hoax_summary.htm
http://67.225.133.110/~gbpprorg/judicial-inc/Sayanim.htm
http://67.225.133.110/~gbpprorg/judicial-inc/81murder_incorporated.h
http://67.225.133.110/~gbpprorg/judicial-inc/False_Flags_summary.htm