Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Microsoft Open Source Security Windows

Microsoft To Support SSH In Windows and Contribute To OpenSSH 285

An anonymous reader writes: Microsoft has announced plans for native support for SSH in Windows. "A popular request the PowerShell team has received is to use Secure Shell protocol and Shell session (aka SSH) to interoperate between Windows and Linux – both Linux connecting to and managing Windows via SSH and, vice versa, Windows connecting to and managing Linux via SSH. Thus, the combination of PowerShell and SSH will deliver a robust and secure solution to automate and to remotely manage Linux and Windows systems." Based on the work from this new direction, they also plan to contribute back to the OpenSSH project as well.
This discussion has been archived. No new comments can be posted.

Microsoft To Support SSH In Windows and Contribute To OpenSSH

Comments Filter:
  • finally (Score:5, Funny)

    by Anonymous Coward on Tuesday June 02, 2015 @04:13PM (#49825707)

    it's only 2015 guys...

    • Re:finally (Score:5, Funny)

      by Anonymous Coward on Tuesday June 02, 2015 @04:19PM (#49825749)
      Just imagine the time warp when they discover rsync.
    • Odd thoughts: (Score:5, Insightful)

      by Penguinisto ( 415985 ) on Tuesday June 02, 2015 @04:34PM (#49825895) Journal

      * I remember joking about connecting to a 'doze server via SSH in 2005. Usually the response was a disgusted shiver.

      * I guess Microsoft finally got sick of seeing PuTTY's hegemony in the terminal/SSH client market, and decided that this, *this* was a market they could finally dominate in this day and age?

      * I shudder to think of how bastardized the command options are going to be, given the PowerShell's habit of using stuff like '-omgLookAtThisMassiveOptionNamingConvention', to the point where they have to alias a frickin' option...

      Ah well, good on 'em. I'll stick with using Linux and OSX clients, thanks much.

      • Re: (Score:3, Insightful)

        * I shudder to think of how bastardized the command options are going to be, given the PowerShell's habit of using stuff like '-omgLookAtThisMassiveOptionNamingConvention', to the point where they have to alias a frickin' option...

        Linux is full of aliased options.
        Can you explain the difference between:
        cp -r
        cp -R
        cp --recursive

        There are long options too, with no aliases
        ls --dereference-command-line-symlink-to-dir

        • Re:Odd thoughts: (Score:5, Informative)

          by Penguinisto ( 415985 ) on Tuesday June 02, 2015 @04:49PM (#49826035) Journal

          The big difference is that *nix started with short easy-to-type options... PowerShell did it the other way 'round. The difference is stark, truth be told; the former grew from a CLI mindset, whereas the latter is easing (back) into CLI from a GUI mindset.

          TBH, I rarely if ever use --option unless I have to, since the original -o is right frickin' there.

          • Re:Odd thoughts: (Score:5, Insightful)

            by nmb3000 ( 741169 ) <nmb3000@that-google-mail-site.com> on Tuesday June 02, 2015 @05:23PM (#49826263) Journal

            Well, when you're typing out Unix commands on an teletype that's 80 characters wide, creating short options first made a lot of sense.

            Powershell's approach is more verbose, but it's also a little more readable (same as long options in Linux), especially when you're dealing with things more complicated than "copy a file", such as "create AD forest trust" or "reconfigure Exchange retention policies". That said, I still tend to use short options by default.

            One thing nice about Powershell is that you can truncate options as long as they're not abmiguous. So you can make -Recursive be -Rec, or even -R, as long as there's not also a -Recreate or -Recover options. That seems to be a nice middle-ground.

            • One thing nice about Powershell is that you can truncate options as long as they're not abmiguous. So you can make -Recursive be -Rec, or even -R, as long as there's not also a -Recreate or -Recover options. That seems to be a nice middle-ground.

              Interesting tidbit. Reminds of the linux ip command, such as "ip a a 192.xxx" instead of "ip address add 192.xxx". There are others I'm sure, but that command I end up using a lot.

            • You can tab-complete commands and options, too.

              • Beyond that, you can get a list of all the available commands and the number and types of parameters they take.

            • Re:Odd thoughts: (Score:5, Interesting)

              by AFCArchvile ( 221494 ) on Tuesday June 02, 2015 @09:44PM (#49827597)

              My biggest gripe with some Powershell commands is that their defaults are not as time-tested as the near-equivalent *nix commands. Probably the best example is "get-winevent -log System" showing all of the events in the System log (which on a given system, might be as large as 4 GB in size).

              Sure, that's functionally the equivalent of performing "sudo cat /var/log/messages", but of course one could run "sudo less /var/log/messages" and obtain the powerful features of less, such as forward and backward navigation, and not loading the entire file into memory (this is a key weakness of "get-winevent" in general; if its output is piped, it is forced to load everything, therefore forcing the user to use the "-MaxEvents (int64)" switch to limit to the newest X events... and this is also setting aside the fact that Windows sorts by newest events first by default, though this can be changed with the "-Oldest" switch).

              The Windows event system in general is strange when looking back at it. You have the post-Vista API (accessible with "get-winevent" or the Event Viewer), and the pre-Vista API (accessible with "get-eventlog"). There are some event sources whose events aren't rendered properly (i.e.: the description of the event will read something like "The description for Event ID X in Source Y could not be found. It contains the following insertion strings: (text)" ( https://support.microsoft.com/... [microsoft.com] ). Some will render properly only in the post-Vista API, but not the pre-Vista API. Others will render properly only in the pre-Vista API, and not the post-Vista API. To my utter surprise and bafflement, event sources such as "Ntfs" and "mpio" fall into the category of rendering properly in pre-Vista API, but not post-Vista API... in Windows Server 2012. That's right, for some reason, the events of a couple of the most critical event sources could not be fixed.

              Powershell is nice as a scripting language, but it's a bear as a command shell. There have been years of complaints of slow loading, especially on systems with high disk I/O activity and/or stalled disks (it doesn't even have to be the system drive; ANY stalled disk on a Windows system may cause Powershell to stall eternally until the system is rebooted; I've seen this for years, in Server 2008 as well as Server 2012). The main reasons why the Command Prompt hasn't been entirely supplanted is because it's lightweight, and has stood the test of time for over 2 decades in NT.

              I recently changed careers from a mostly-Windows role to a mostly-Linux role, and it feels great to work with bash, even if I still haven't memorized most of the higher esoteric layers of shell scripting. It feels like the shell was designed for the OS, instead of being duct-taped into a jack-of-all-trades role. The way I log into a RDP-windowed Windows Server 2012 system is visual humor in itself: I right-click the taskbar to click "Task Manager", use it to open "File -> New Task", run "cmd.exe", maybe start Powershell off to the side, and don't EVER click on the Start corner (or button if it's 2012 R2) or the Charms bar. Control panel? Run "control". Computer management? "compmgmt.msc" still works. Search for a file? "dir /b /s" for it, or else creative uses of "find" will work. But don't EVER call up the abomination that is the Start Screen.

            • by bmo ( 77928 )

              Powershell's approach is more verbose, but it's also a little more readable

              I beg to differ. I really, really beg to differ.

              long.verbose.commands.that.grab.objects.are.impossible.to.read.

              --
              BMO

            • by donaldm ( 919619 )

              Well, when you're typing out Unix commands on an teletype that's 80 characters wide, creating short options first made a lot of sense.

              Graphical interfaces have been around since the 1970's and on workstations or any graphical interface you can display the equivalent of a standard 80x24 tty terminal or any sized terminal (within reason of course) so that was not the reason why creating so called short options made sense. Basically Unix people preferred efficiency in typing over long winded typing. As an example why type "copy" when you can type "cp" or "ls" when you wish to list files and directories. You can even alias commands and their

          • by bondsbw ( 888959 )

            PowerShell did it the other way 'round.

            Not really. PowerShell had many short commands since 1.0 in addition to the long versions... it's not that PS "started" one way or the other.

            the former grew from a CLI mindset, whereas the latter is easing (back) into CLI from a GUI mindset.

            Also not true. There's nothing about the long syntax that grew from a GUI mindset. It was created for consistency and ease of learning.

            PowerShell primary commands are formatted Verb-Noun. This is awfully convenient, as a PowerShell user can guess hundreds of commands just by learning a few verbs and a few nouns. I just counted, and to understand half of the 300+ b

            • by DaHat ( 247651 )

              PowerShell primary commands are formatted Verb-Noun. This is awfully convenient, as a PowerShell user can guess hundreds of commands just by learning a few verbs and a few nouns.

              Not to mention built in tab completion for arguments where you can read the man page after finding the cmdlet to know which arguments you will have to use, or just quickly tab through to what you know is going to be there.

        • by tlhIngan ( 30335 )

          Linux is full of aliased options.
          Can you explain the difference between:
          cp -r
          cp -R
          cp --recursive

          There are long options too, with no aliases
          ls --dereference-command-line-symlink-to-dir

          Easy. The difference is you're using GNU.

          UNIX traditionally only has short options, which are parsed using getopt(3). GNU adds getopt_long(3) which adds the long options, but I think only to GPL applications because you must link against a GPL library (libiberty?) in order to use them.

          Using getopt() to parse your command line i

          • According to the man page on my Mac:

            The getopt_long() and getopt_long_only() functions first appeared in GNU
            libiberty. The first BSD implementation of getopt_long() appeared in
            NetBSD 1.5, the first BSD implementation of getopt_long_only() in
            OpenBSD 3.3. FreeBSD first included getopt_long() in FreeBSD 5.0,
            getopt_long_only() in Fr

          • The man page was from http://unixhelp.ed.ac.uk/ [ed.ac.uk] so not specifically GNU.

      • Re:Odd thoughts: (Score:5, Insightful)

        by kosmosik ( 654958 ) <kos@kosm[ ]k.net ['osi' in gap]> on Tuesday June 02, 2015 @05:08PM (#49826167) Homepage

        > I guess Microsoft finally got sick of seeing PuTTY's hegemony in
        > the terminal/SSH client market

        You guess wrong. There is basically no market for terminal/ssh clients. And if it is it is peanuts. There is HUGE market for centralized management tools like OpenStack, Chief, Puppet, etc. - and that is at what Microsoft is aiming. Basically they need SSH compatibility to manage Linux boxes and they want and they do (Azure) manage Linux boxes.

        > I shudder to think of how bastardized the command options are going
        > to be, given the PowerShell's habit of using stuff like
        > '-omgLookAtThisMassiveOptionNamingConvention', to the point where
        > they have to alias a frickin' option...

        Oh like in GNU/Linux/BSD utils are just kosher and standardized... please... each tiny utility comes from few other schools of command line switches and are usually different. Threre is no standardisation of switches in commands used on Linux. Usually if you need to do something comples (that you haven't yet memorized) you need to open other terminal window with manual to do it. Of course this is a different *convention* from PowerShell but PS is not that bad - it is just different.

        > Ah well, good on 'em. I'll stick with using Linux and OSX clients, thanks much.

        Oh OSX clients and bastardized commands. Come on... ;)

        And for the record I really like Linux and use it all the time. I also happen to use Windows and OSX as clients and they are also fine. Any effort to bring more interoperability between those systems is welcome in my opinion.

        • Basically they need SSH compatibility to manage Linux boxes and they want and they do (Azure) manage Linux boxes.

          Almost. They need SSH compatibility to be managed by Linux boxes, yet with proper NT authentication instead of the band-aid which is Cygwin.

      • by rcoxdav ( 648172 )
        I wish that with Power-shell Microsoft would take the Cisco approach to the command line, where all you have to do is do the shortest unique version of a command or switch.
  • excellent (Score:5, Funny)

    by Anonymous Coward on Tuesday June 02, 2015 @04:23PM (#49825781)

    now you can use Windows computers the way they were meant to be used, as dummy linux clients

    • now you can use Windows computers the way they were meant to be used, as dummy linux clients

      I've been doing that for so long I've actually given Chameleon money (for Xoftware.) No, wait. Except the last time I actually wanted to do it was years ago, because it's been years since I had any Unix-specific machines. Now it's just PC Unix. I just threw away my last Unix machines, a POWER1 and an Indy R4400SC@200MHz. It wasn't worth dusting them off.

  • I mean, they will take OpenSSH, compile-it for Windows, and make sure Power Shell is the default login shell. Then what? What piece of code could the Open SSH project want from Microsoft exactly?

    • by viperidaenz ( 2515578 ) on Tuesday June 02, 2015 @04:47PM (#49826019)

      What piece of code would the Open SSH project possibly want from any developer?

      It's not like it's defect-free software that requires no more development.
      https://bugzilla.mindrot.org/s... [mindrot.org]

    • I think it will be the MS cli interface helper, sshclippy. "It looks like you're trying to ssh into a remote server. Wouldn't you like to use RDP instead?"

    • Probably the best thing they can do is throw resources at it, hire an existing dev to do it full time sort of thing.

    • by Burdell ( 228580 )

      You obviously haven't ported OpenSSH to a different OS before. Even among Unix/POSIX-like OSes, there is significant variance between platforms that something like OpenSSH has to deal with. Go look at the diff between OpenBSD OpenSSH and portable OpenSSH (for all the other supported platforms).

      Also, portable OpenSSH uses extended security features that tend to be platform-specific (but useful enough to make it worthwhile to use on each specific system). I expect that there is Windows security functionality

      • Indeed. I expect one of the things they'll be looking at doing is adding support for some of Windows' built-in authentication options. For example, recent versions of RDP use machine certificates, typically with a trust-on-first-use model similar to SSH. It would be nice if SSHing into a Windows box could re-use that machine cert, and SSHing from a Windows box could take advantage of the list of IP+cert pairs that you already trust. This would require some code changes to OpenSSH though, since it is of cour

    • I mean, they will take OpenSSH, compile-it for Windows, and make sure Power Shell is the default login shell. Then what?

      Then they have a vested interest in it so should contribute to maintaining it, even widely-used open source projects (PGP and OpenSSL for example) are often woefully under-resourced. It isn't as though OpenSSH is some bug-free, perfect product that requires no maintenance.

  • I wonder (Score:4, Funny)

    by John Allsup ( 987 ) <moostyle.martial ... ls[ ]co ['up.' i> on Tuesday June 02, 2015 @04:26PM (#49825813) Homepage Journal

    Are M$ getting sensible in their old age?

    • Re: (Score:3, Informative)

      by kosmosik ( 654958 )

      They have no choice. Well they could just stick with Windows Server and Windows Clients but it actually happens that they are offering Linux as a product/service (in their Cloud). So why not embrace and extend methods to manage Linux via their tools? In my opinion this is good trend.

    • Re:I wonder (Score:5, Informative)

      by the_povinator ( 936048 ) on Tuesday June 02, 2015 @04:41PM (#49825947) Homepage
      The linked-to blog contains an interesting statement which could be interpreted as bashing Ballmer:

      Finally, I'd like to share some background on today’s announcement, because this is the 3rd time the PowerShell team has attempted to support SSH. The first attempts were during PowerShell V1 and V2 and were rejected. Given our changes in leadership and culture, we decided to give it another try and this time, because we are able to show the clear and compelling customer value, the company is very supportive.

    • Re:I wonder (Score:4, Interesting)

      by slaker ( 53818 ) on Tuesday June 02, 2015 @04:44PM (#49825987)

      The new Microsoft CEO is much more comfortable with FOSS software. We're also seeing initiatives to support Docker containers on Windows and apt/yum/ports style software repositories and I don't think we'd have gotten any of that if Ballmer were still in charge.

  • Cygwin (Score:5, Interesting)

    by ls671 ( 1122017 ) on Tuesday June 02, 2015 @04:33PM (#49825879) Homepage

    You mean I don't need to install Cygwin anymore like I have been doing for the past 15 years to accomplish just that?

    Next proposal: implement rsync natively...

    • > Next proposal: implement rsync natively...

      Rsync fails on Windows/Unix interactions due to basic filesystem architecture. There are lot of differences betweeen NTFS and *nix filesystems like ACLs, timestamping and so on. So I don't really get how Microsoft could change rsync to work with NTFS since the problem is not in rsync but in general differences in which filesystems work - f.e. how to accurately map Windows ACLs to unix ACLs?

      Also I don't think that rsync support is something Microsoft clients (as

      • Not to mention such trivial things as how to translate paths f.e. C:\Users\foo to /home/foo or whatever. I don't think it is a problem which rsync should solve - it (if Microsoft ever embraces such idea) should be solved in lower layer than userland.

        • by ls671 ( 1122017 )

          You seems like you have been trying to use it, haven't you? Like most open source solutions, you might have to tweak it a bit to get it to do what you want and then again, you have to make compromise. But be assured it works in a satisfactory way for me. Just get a proprietary solution if you can't make it work as you wish. Oh my god, I just realized you sounded like a guy that would choose the later solution ;-)

          I know what you are saying although and there is some truth to it.

          Take care man ;-)

          • > You seems like you have been trying to use it, haven't you? Like most
            > open source solutions, you might have to tweak it a bit to get it to do what
            > you want and then again, you have to make compromise.

            Sorry I am an professional - for my clients I advice and implement what is best for them so in general I avoid tweaking (as in unstadarised hacks). Tweaking is good for my home machines but what I do on home machines I would not recommend to clients who just wish to do their business.

            > But be a

          • It involves more than a little bit of tweaking. Files that are "locked" on the Windows side make rsync hang, and fail when accessed over an rsync/SSH connection. This particularly includes the Outlook ".PST" file, the email storage file that is one of the most critical files to back up on a personal system.

      • by mlts ( 1038732 )

        The best managing (IMHO) of Windows ACLs with UNIX permissions I've seen would be the EMC Isilons. You can lop off all permissions except the bare UNIX ones (user, group, rwx), use Windows permissions for everything, and stuff in between.

        Adding GPO friendliness to Linux would go a long way in getting more boxes on the desktop The biggest reason why Windows is the primary desktop OS is because it has a lot of management tools.

        Now here is the ironic thing. MS doesn't lose if Linux gains. For example, they

        • > tl;dr, both MS and Linux would win big. Especially if Windows had the
          > ability to run Linux applications in Hyper-V wrapped Docker containers.

          Just run Linux kernel in hypervisor and do some glue to map Linux/UNIX convetions (process management/filesystem/networking/etc.) to Windows host. But that is problematic - you can do it in many ways (like you've said EMC is the way you like it). I guess the problem is that we need to have some standards regarding on how to map such things and the best way po

      • Rsync fails on Windows/Unix interactions due to basic filesystem architecture.

        Uh what? I use it all the time between Windows and Unix, Windows and Android... it works fine. If there are any problems, they are abstracted away by the client and/or server and I don't notice them at all.

  • by Alain Williams ( 2972 ) <addw@phcomp.co.uk> on Tuesday June 02, 2015 @04:35PM (#49825899) Homepage

    In which case they will have to release the code that corresponds to binaries - would be useful for checking that there is not some little tweaks to help the NSA -- but if they have already put those into the system DLLs (eg for encryption) we would not really know. Maybe I am too cynical but I am very suspicious of what they did to skype.

    • Does the OpenSSH license prevent making the code proprietary? I'd have guessed it was under a BSD license, which permits closed-source derived works.

  • Will this work out of the box? Because you basically have to go into the server you are accessing it and type some really weird shit on winrm to be able to even run scripts and god forsake you if you want to access the console remotely. Its so fucking annoying that I've met some people who just disable HTTPS and go straight for HTTP with basic authentication.

    • Of course it will be a PITA to use. It's Windows, and all of the administration tools have devolved over the years. You have horrible GUI tools, like the dreaded IIS manager, ridiculous CLI commands, like ntdsutil, diskpart and netsh. Why would this be any different?

  • by nimbius ( 983462 ) on Tuesday June 02, 2015 @05:33PM (#49826321) Homepage
    Losing nearly a billion dollars over an 8 year period, firing four-thousand permanent staff, and being dead last in search and browser rankings will do strange things to you. Steve Ballmer shoulders some of the blame for the nosedive with his nearly cult-like adherence to the redmond ethos of embrace-extend-extinguish in the face of a brand like linux that just can't be killed with it. But to think after 15 years as other slash dotters have commented that this will make any significant dent in the status quo is self-defeating at best.

    SSH gives windows users the ability to do real work, and thats a controversial sentiment but in most large corporations admins that handle LAMP, percona, or hadoop do it from a windows machine by company policy. Microsoft doesn't understand that outside of email and office, the real juggernauts of industry are so far removed from redmonds product line it may as well be a different language entirely. conceding a pittance, this ssh, and promising to commit code to openssh do two things. One, they add continued relevance to windows in an office environment that otherwise is the next prime target to be extinguished as quickly as the home market for windows. Two, they provide code to openssh not because they have any particular valuable insight to add to the project which has handled itself just fine for 15 years, but because they need to ensure their openssh implementation actually works with other well-established and quite serviceable implementations. So don't expect any real innovation.
  • Regarding Windows Firewall:
    The feature where you can supposedly define custom network groups for the scope. Can you finally create more than localsubnet? It would be nice to be able to define "My networks" as "x.x.x.0/24, y.y.0.0/16, 10.0.0.0/8" then set scope for multiple rules as "My networks".
  • Will the support sftp access in explorer? I could simplify a lot of my webDAV/samba stuff that way...
  • MS is adding actually useful standard tools (well, standard outside of the MS isle of incompatibility) to windows! Good. That means we are at a stage where they cannot ignore what works anymore. As usual for MS decades late, but better late than never.

"You know, we've won awards for this crap." -- David Letterman

Working...