Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Open Source Microsoft Software

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.
This discussion has been archived. No new comments can be posted.

Microsoft Publishes OpenSSH For Windows Code

Comments Filter:
  • 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).
    • by vux984 ( 928602 )

      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

    • by ewhac ( 5844 ) on Tuesday October 20, 2015 @04:30PM (#50768255) Homepage Journal
      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>

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

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

  • > 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?

    • by 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?

    • by MobyDisk ( 75490 )

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

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

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

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

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

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

    • by vux984 ( 928602 ) on Tuesday October 20, 2015 @04:43PM (#50768377)

      How would this improve it?

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

    • by jonwil ( 467024 )

      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)

      • by Lennie ( 16154 )

        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.

  • by cyber-vandal ( 148830 ) on Tuesday October 20, 2015 @04:09PM (#50768087) Homepage

    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.

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

  • Where is bash? (Score:2, Insightful)

    by nyet ( 19118 )

    Pointless without bash.

    I''ll stick with cygwin, thanks.

    • by Anonymous Coward

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

      • by Anonymous Coward

        Get with the times, grandpa:

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

        • You too, gramps.

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

          Hmm, ok, maybe not...

    • by Wolfrider ( 856 )

      > Pointless without XTREE PRO GOLD

      --FTFY.

      / get off ma lawn

      • 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

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

  • by 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?

    • by danbob999 ( 2490674 ) on Tuesday October 20, 2015 @04:42PM (#50768373)

      it's a server, not a client

      • by Anonymous Coward

        server AND a client ....

    • 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 inclu

  • 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 [slashdot.org]. I was just playing around and never messed with it further, but it's made a fun story to tell.
    • by Lakitu ( 136170 )

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

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

    • by Ash-Fox ( 726320 )

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

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

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

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

      • by v1 ( 525388 )

        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 sha

Between infinite and short there is a big difference. -- G.H. Gonnet

Working...