back to article Temperature of Hell drops a few degrees – Microsoft emits SSH-for-Windows source code

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 remote-access …

  1. David 132 Silver badge
    Thumb Up

    Good.

    I applaud them for their hard work.

    Even if, for some reason, images of Admiral Ackbar come unbidden to my mind as I read this.

    1. Ole Juul

      Re: Good.

      Indeed. It'll be nice to just be able to connect to those Windows machines.

    2. Anonymous Coward
      Anonymous Coward

      Re: Good.

      "that it will integrate OpenSSH support into its Windows PowerShell tool, allowing admins to securely log into Windows boxes and remote-control them using the command line and scripts – just like they can with Linux, BSD and other Unix-y operating systems."

      Just like Powershell already can do somewhat more securely than SSH, you mean?

      1. ratfox
        Angel

        Re: Good.

        Just like Powershell already can do somewhat more securely than SSH, you mean?

        Wow, Powershell has been ported to Linux and BSD? I didn't know that.

        1. Anonymous Coward
          Anonymous Coward

          Re: Good.

          "Wow, Powershell has been ported to Linux and BSD? I didn't know that."

          Not BSD afaik, but Microsoft has ported some of it to CentOS, Debian GNU/Linux, Oracle Linux, Red Hat Enterprise Linux, SUSE Linux Enterprise Server, and Ubuntu Server , see:

          http://blogs.msdn.com/b/powershell/archive/2015/05/06/powershell-dsc-for-linux-is-now-available.aspx

          And then there is also: http://pash.sourceforge.net/

          1. Frumious Bandersnatch

            Re: Good.

            but Microsoft has ported some of it to CentOS, Debian GNU/Linux, Oracle Linux, Red Hat Enterprise Linux, SUSE Linux Enterprise Server, and Ubuntu Server

            But they're all just "Linux". I don't see the point in saying that they ported to this distro and that one when they're all essentially the same target assuming they use standard tools like autoconf.

            1. h4rm0ny

              Re: Good.

              >>"But they're all just "Linux". I don't see the point in saying that they ported to this distro and that one when they're all essentially the same target assuming they use standard tools like autoconf."

              Actually, this is a bit of a red herring. What Microsoft did was create an Open Source service and provide it as package for these distributions and the package is designed to allow people to manage those OSs using Powershell from a remote machine. They haven't ported Powershell itself to GNU/Linux and that wouldn't really make sense as Powershell is OO-based and GNU/Linux exposes little to none of itself as objects. The package is more like a proxy way of configuring things, monitoring, etc. It's designed to facilitate management of your GNU/Linux boxes in Azure. The source is available if you want to compile it on something else.

    3. Anonymous Coward
      Anonymous Coward

      Re: Good.

      I trust American corporation crypto to the same degree that I trust my mates when I'm pissed.

      1. Graham Dawson Silver badge

        @anon Re: Good.

        You mean "far more than is sensible"?

      2. Anonymous Coward
        Anonymous Coward

        Re: Good.

        "I trust American corporation crypto to the same degree that I trust my mates when I'm pissed."

        Well I trust it more than someone I don't know's crypto...just look at the numerous holes we have had in SSH, Open SSL, etc.

  2. streaky

    Windows Crypto API

    Leverage Windows crypto api’s instead of OpenSSL/LibreSSL and run as Windows Service

    Backdoor it more? How about keep it OpenSSL so people can at least pretend it's secure?

    1. Anonymous Coward
      Anonymous Coward

      Re: Windows Crypto API

      It looks OpenSSL had far more bugs than CryptoAPI, and OpenSSL code is a real mess.

      Anyway, CryptoAPI is the native crypto library on Windows, fully integrated with it and are updated with it, so it does a lot of sense to port the OpenSSH to use it, just like it need to run as a Windows service, and possibly avoid too many POSIX compatibility layers.

      The number of applications under Windows using OpenSSL and don't updating it properly is appalling.

  3. Richard Plinston

    POSIX

    >> Address POSIX compatibility concerns

    Are they concerned that they may accidentally be compatible with POSIX, or is that "Address POSIX _in_compatibility concerns" ?

    1. h4rm0ny

      Re: POSIX

      You say "POSIX compatible" as if it's a good thing. The Windows OS is a fully OO environment. Pretty much every part of it including its permissions system (which is a Hell of a lot more powerful and manageable than the default UNIX -rwx/rwx/rwx approach). So why the Hell would tying it down to the ancient POSIX standard which was developed for UNIX make sense or be considered an advantage for Windows?

      1. Anonymous Coward
        Anonymous Coward

        Re: POSIX

        Windows is not a fully OO environment - most of the Win32 API is a C one (some more recent ones uses interfaces and C++ semantic, others may use COM, but still is not a full OO API especially since there's no inheritance).

        That said, Windows implements a different model than Unix. Sometimes it's better, sometimes it's worse, often it's just different. Using SUA (an optional component) you can have a POSIX environment on Window, but IMHO, any first class application in Windows has to work as a "native" one, not pretending to be still in its *nix environment, and should not require any optional compatibility layer.

        1. Anonymous Coward
          Anonymous Coward

          Re: POSIX

          "Windows is not a fully OO environment"

          Windows Powershell is fully OO - which I think the OP was referring to. Think a toolset like BASH but far more powerful and secure with fully OO features, so no parsing text files any more and worrying about text formatting , etc, etc.

          "Get a clue. Posix means Posix ACLs which give fine-grained access control not unlike Windows ACLs."

          Clearly you are the one without a clue. POSIX type ACLs are not fine grained and are nothing like Windows ACLs. To get anything vaguely close on *NIX you need to run NFS v4. And even then you can't get equivalent to Windows granularity, as you can only permission down to the file level, not to each individual config setting like in Windows....

          1. Nigel 11

            Re: POSIX

            Please note *nix != Posix. If you are running a filesystem that doesn't support Posix ACLS then that filesystem is not Posix compliant. Depending on how you define "system", it may mean that your "system" is also not compliant.

            You're also inaccurate about NFS V3. Although posix ACLs are not part of the NFS V3 specification, they can be supported by additional RPCs (which have been a standard part of Red Hat flavours of Linux for many years).

            http://wiki.linux-nfs.org/wiki/index.php/ACLs (which also suggests that even some NFS V2 implementations have ACLs; can't vouch for that, never used NFS V2)

            As for ACLs on config settings, that's rather necessary if you're supposed to store all your config settings for unpteen different applications into one and only one entity called "The Registry". In the Linux world it would be called a folder heirarchy or a filesystem, with ACLs ... again, argue that the Windows way is better if you wish, but that's not the same as claiming that it can't be done at all under Posix.

          2. Pirate Dave Silver badge
            Pirate

            Re: POSIX

            "Think a toolset like BASH but far more powerful and secure with fully OO features, so no parsing text files any more and worrying about text formatting , etc, etc."

            LOL. If you think Powershell is more powerfull than BASH, you need to have another think. Although I will concede that I am inferring BASH is on a mostly-proper *nix system like Linux or the BSDs with all the attendant utilities. I would imagine BASH on a Windows box would be about as useless as Powershell on a Linux box.

            Don't get me wrong, Powershell is a great step-up from DOS batch files in most instances, but a BASH-killer it ain't. As to text-parsing, eh, last time I checked, import-csv still had annoyances with blank lines in the input file.

            1. h4rm0ny

              Re: POSIX

              >>"LOL. If you think Powershell is more powerfull than BASH, you need to have another think. Although I will concede that I am inferring BASH is on a mostly-proper *nix system like Linux or the BSDs with all the attendant utilities. I would imagine BASH on a Windows box would be about as useless as Powershell on a Linux box."

              This has been debated before on El. Reg. Yes, Powershell is not a good fit for GNU/Linux and Bash is not a good fit for Windows. This is because Windows is an OO environment and GNU/Linux is not. But your comment about Powershell not being more powerful than Bash is woefully misinformed. It is not only better designed and more self-consistent, but it has vastly more capabilities. MS looked at Bash, Python, et al. and created a scripting language that really took advantage of the last thirty years of progress in a way Bash never could (because it's very old). The below is a good starting list for advantages of Powershell over Bash and that's before I get into the far greater standardization of it. The below list was posted by TheVogon. I claim no credit for its excellent summation:

              1) Object oriented pipes so that I don't have to format and reparse and be concerned about language settings.

              2) Command metadata. PowerShell commands, functions and even *script files* expose metadata about the names, positions, types and validation rules for parameters, allowing the *shell* to perform type coercion, allowing the *shell* to explain the parameters/syntax, allowing the *shell* to support both tab completion and auto-suggestions with no need for external and cumbersome completion definitions.

              3) Robust risk management. Look up common parameters -WhatIf, -Confirm, -Force and consider how they are supported by ambient values in scripts you author yourself.

              4) Multiple location types and -providers. Even a SQL Server appears as a navigable file system. Want to work with a certain database? Just switch to the sqlserver: drive and navigate to the server/database and start selecting, creating tables etc.

              5) Fan-out remoting. Execute the same script transparently and *robustly* on multiple servers and consolidate the results back on the controlling console. Try icm host1,host2,host3 {ps} and watch how you get consolidated, object-oriented process descriptions from multiple servers.

              6) Workflow scripting. PowerShell scripts can (since v3) be defined as workflows which are suspendable, resumable and which can pick up and continue even across system restarts.

              7) Parallel scripting. No, not just starting multiple processes, but having the actual *script* branch out and run massively parallel.

              8) True remote sessions where you don't step into and out of remote sessions but actually controls any number of remote sessions from the outside.

              9) PowerShell web access. You can now set up a IIS with PWA as a gateway. This gives you a firewall-friendly remote command line in any standards compliant browser.

              10) Superior security features, e.g. script signing, memory encryption, proper multi-mode credentials allowing script to be agnostic about authentication schemes which may go way beyond stupid username+password and use smart cards, tokens, OTPs etc.

              11) Transaction support right in the shell. Script actions can join any resource manager such as SQL server, registry, message queues in a single atomic transaction. Do that in bash?

              12) Strongly typed stripting, extensive data types, e.g first class xml support and regex support right in the shell. Optional static/explicit typing. Real lambdas (script blocks) instead of stupidly relying on dangerous and error prone "eval" functions.

              13) Real *structured* exception handling as an alternative to outdated traps (which PowerShell also has). try-catch-finally blocks.

              14) Instrumentation, extensive tracing, transcript and *source level* debugging of scripts.

              15) Consistent naming conventions covering verb-noun command names, common verbs, common parameter names.

              1. Pirate Dave Silver badge
                Pirate

                Re: POSIX

                "But your comment about Powershell not being more powerful than Bash is woefully misinformed. It is not only better designed and more self-consistent, but it has vastly more capabilities."

                Really? Funny, after using Bash for 15 years and Powershell for 5 years, I still say Bash is better.

                It's more consistent, more mature, and there is a much better chance of googling a "proper" and perhaps even an "elegant" way to perform a given task instead of the hackish nature that surrounds the Powershell documentation. It reminds me of classic VB in that respect - folks finding ways of making something work, but is it a good and proper way, or just a hack they stumbled upon that will disappear in the future?

                Not to mention it has a better grasp (meaning not-iron-fisted) of variable scopes - for quick one-off admin tasks global variables are useful and are no problem in Bash, but it's a PITA to have to prefix every single occurrence with $global: in Powershell just because MS decreed that we must do that, and no escaping it.

                Why does get-mailbox support the -filter switch, but get-msoluser doesn't? That doesn't seem terribly consistent and is a PITA at times when dealing with Office365 users.

                Why is it such a bitch to escape all the switches to a call to "icacls /grant"? Why does it take 5-10 lines of "native" Powershell code to do the same thing as a single call to icacls? There's granularity, and then there's being a total pain in the ass (to the point where it's easier to put the icacls call in a BATCH FILE and call that from powershell).

                And why, why, why can't csv-import have enough sense to skip blank lines in an input file?

                So yes, on paper, Powershell should be the cat's meow. But down in the nuts-n-bolts, it just isn't. Like most MS products, it's a decent attempt, and nothing more. Bash is still better in my book.

        2. the spectacularly refined chap

          Re: POSIX

          Using SUA (an optional component) you can have a POSIX environment on Window, but IMHO, any first class application in Windows has to work as a "native" one, not pretending to be still in its *nix environment, and should not require any optional compatibility layer.

          OK then, using this definition name a single native Windows application: I certainly can't. The lowest system call layer of Windows is not publicly documented - the lowest level access you can get is the interface exposed by NTDLL.DLL. Above that for what is usually regarded a "native" Windows application you have the Win32/Win64 API as implemented by WIN32.DLL. Most of the "native" facilities you are keen to emphasise are facilities in those compatibility layers that implement the public APIs rather than features of the underlying OS kernel itself.

          1. Anonymous Coward
            Anonymous Coward

            Re: POSIX

            Above that for what is usually regarded a "native" Windows application you have the Win32/Win64 API as implemented by WIN32.DLL. Most of the "native" facilities you are keen to emphasise are facilities in those compatibility layers that implement the public APIs rather than features of the underlying OS kernel itself.

            Of course. Anyone who has ever studied the NT kernel design at any point will have seen the diagrams that include the Win16, Win32 and Win64 subsystems as just another module among the others, e.g. the POSIX subsystem or indeed the OS/2 subsystem. Talking of a "optional compatibility layer" is not only demonstrating ignorance of the specifics of the Windows kernel but its founding tenets.

        3. Uffe Seerup

          Re: POSIX

          > Windows is not a fully OO environment - most of the Win32 API is a C one

          Even the original C based APIs use the concept of *handles* and *object types*. The handles are actually references to objects, the dynamic virtual method table for an object is created when it is "opened". So yes, the fundamental design philosophy of Windows was always object-oriented, even if the actual method of implementation has gone through several iterations. The object-orientation is why - even today - the model fits well with a PowerShell model.

          Unlike *Nix, the object permissions in Windows are established when the object is opened or created. You ask for a set of permissions and - if granted - corresponding methods will be pointed to by the dispatch table of the object. Slots for methods corresponding to permissions you didn't ask for will point to a "denied" method. This has the obvious advantage that 1) Windows does not need to check permission on each "syscall" - it's encoded in the way the DMT is set up and 2) handles can be passed to lesser privileges processes - as they point to the same DMT they will inherit the permissions.

      2. Nigel 11

        Re: POSIX

        (which is a Hell of a lot more powerful and manageable than the default UNIX -rwx/rwx/rwx approach)

        Get a clue.

        Posix means Posix ACLs which give fine-grained access control not unlike Windows ACLs. You can argue that Windows ACLs are better if you wish, but displaying your ignorance of Posix is not a good start.

        1. h4rm0ny

          Re: POSIX

          >>"Get a clue. Posix means Posix ACLs which give fine-grained access control not unlike Windows ACLs. You can argue that Windows ACLs are better if you wish, but displaying your ignorance of Posix is not a good start."

          I wrote "default UNIX -rwx/rwx/rwx approach". You seem to have disregarded that in favour of what you would prefer I had said. Sure, you can add ACLs to GNU/Linux or UNIX and some people do. But they are not the default and they see minority usage. They are also a great deal harder to work with and less capable than Windows where they are the default approach. I don't think you could shoe-horn the more capable Windows ACLs into POSIX-compliance. Feel free to show me how you could, if you want to try though. ;)

          As to the other poster, yes, I perhaps should not have written "fully" OO as there are some non-OO APIs in Windows. My background is UNIX so I'm prone to the occasional misspeak on Windows. But they key word in my post was "environment". You can manage the entirety of Windows via Powershell in an OO fashion and whilst if you're programming on Windows you might use a non-OO API, what I'm getting at is that working within the environment, pretty much everything exposes itself with an OO interface. And I do not see why or how people want Windows to suddenly be "POSIX compliant" as they sometimes post on El Reg. I don't think they actually know what they're asking for or what they think it would gain. A little like a builder of row-boats looking at a car and demanding it have hooks added for the oars to go in. Perhaps Nigel 11 here would like to explain what advantage there is to Windows in tying itself down to being "POSIX compliant". How and why would you even want to handle files or processes in the way POSIX lays out when there are better approaches?

          1. Anonymous Coward
            Anonymous Coward

            Re: POSIX

            "I do not see why or how people want Windows to suddenly be "POSIX compliant""

            Windows has been POSIX compliant for many years already.

            1. h4rm0ny

              Re: POSIX

              >>"Windows has been POSIX compliant for many years already."

              Ehhhhh, in a sense, but not really (imo). It can offer a mostly POSIX-compliant environment. You can install Cygwin and have a POSIX world in which to play. But the functionality of Windows is a super-set of that. It would be a little like saying that C++ is C compliant. Not a fan of analogies, but I think that one works. So I concede you're sort of right, but would say that in practical terms it is not, nor tries to be.

              1. Anonymous Coward
                Anonymous Coward

                Re: POSIX

                "Ehhhhh, in a sense, but not really (imo). "

                No it is for older versions at least, fully POSIX compliant. There is no "not really". POSIX is a standard and Windows has previously implemented all required aspects. However support for it is now deprecated: https://technet.microsoft.com/en-gb/library/cc754351.aspx

                1. h4rm0ny

                  Re: POSIX

                  >>"No it is for older versions at least, fully POSIX compliant. There is no "not really". POSIX is a standard and Windows has previously implemented all required aspects. However support for it is now deprecated: https://technet.microsoft.com/en-gb/library/cc754351.aspx"

                  At the very least since Vista, Windows is not POSIX compliant. I'm not really interested in arguments that say Windows is POSIX compliant because ten years ago it was. Because, whilst not wishing to sound like Bill Clinton, that's a rather funny definition of "is".

                  1. Anonymous Coward
                    Anonymous Coward

                    Re: POSIX

                    "At the very least since Vista, Windows is not POSIX compliant"

                    Wrong again - SUA is available and supported for Windows 7 - making it fully POSIX compliant. Windows 8 / 10 - maybe not. But hardly anyone that cares is using those yet anyway.

          2. JoeF

            Re: POSIX

            Maybe ACLs see "minority usage."

            But the most widely used Linux distribution, Android, uses something even better than Posix ACL, namely SELinux. That makes SELinux very widely used in the *nix world.

            SELinux is way more powerful than ACLs, be it the Posix or MS variant.

            1. h4rm0ny

              Re: POSIX

              >>"But the most widely used Linux distribution, Android, uses something even better than Posix ACL, namely SELinux. That makes SELinux very widely used in the *nix world. SELinux is way more powerful than ACLs, be it the Posix or MS variant."

              I have worked with SELinux. It's a patch over the UNIX security model that is constantly tripping people up and not well integrated into GNU/Linux itself. SELinux on Android I have no experience with. However, in either case it's basically a layer over the top of the UNIX permissions system to try and wrap it up in something more usable. It's odd how all I initially wrote was that Windows permissions were much more capable and maintainable than the default UNIX permissions systems and the first two replies I got were people immediately responding with alternatives to the default UNIX permissions system. You and they are both really reinforcing my point that the default (and most commonly used on GNU/Linux) permissions system is limited and hard to work with.

              As to SELinux being "way more powerful" than Windows ACLs, I find that not to be the case at all. What is it you think makes SELinux superior to Windows ACLs?

              1. Richard Plinston

                Re: POSIX

                > You and they are both really reinforcing my point that the default (and most commonly used on GNU/Linux) permissions system is limited and hard to work with.

                The default Unix/Linux permissions system is perfectly adequate and is not 'hard to work with'. It has proven itself over many decades. Because Unix/Linux has inode file systems allowing multiple file links and various other flags, such as sticky bit, setuid and setgid, the fit of this model is perfectly matched to the system. I would agree that if the file permission system was applied to Windows filesystems then it would be an ineffectual nightmare, but that is because it is not an inode system.

                Because Windows started off with an extremely poor (to the point of non-existence) permissions system, and file systems that lacked the basic facilities offered by inode based systems, then NT had to implement a layer of permissions over the top of the file system. They used ACLs. ACLs may be more flexible in many respects (you can have them on Unix/Linux too if you want). These are far more complicated, whether they are 'easier' or 'harder' to work with depends entirely on what you are used to and whether you know how to use the facilities correctly.

                1. h4rm0ny

                  Re: POSIX

                  >>"These are far more complicated, whether they are 'easier' or 'harder' to work with depends entirely on what you are used to and whether you know how to use the facilities correctly"

                  No it doesn't "depend entirely" in what you are used to. A pretty massive component of hiw easy or hard it is to work with them depends on what you use them FOR.

                  UNIX permissions are simple and adequate for basic scenarios. They can be made to work for more complex scenarios with a lot of expertise and a tolerance for people emailing you every other day to say such and such needs to be added to this group or the other for some obscure reason. A proper system if ACLs is what you want for any moderately complex environment however. Easy management of nested groups and hierarchical, trickle down permissions is a basic requirement for a capable permissions system. Amongst others.

                  These are not things that "depend entirely" on which you are most familiar with. I don't see your part about inodes having any bearing on this, either.

                  1. Richard Plinston

                    Re: POSIX

                    > No it doesn't "depend entirely" in what you are used to.

                    Yes it does. If you know how to use the facilities then it is 'easy' compared to facilities that you don't know how to use.

              2. Richard Plinston

                Re: POSIX

                > SELinux. It's a patch over the UNIX security model

                SELinux is built into the kernel. It may appear to be 'a patch' because ordinary users can be set to operate in an 'unconfined' domain where the usual permission system operates.

                1. h4rm0ny

                  Re: POSIX

                  >>"SELinux is built into the kernel. It may appear to be 'a patch' because ordinary users can be set to operate in an 'unconfined' domain where the usual permission system operates"

                  You don't seem to understand. It is a kernel module, yes. That has no bearing on it being a patch over the default UNIX permissions system. "Patch" = "thing that papers over the original conceptual model with a new conceptual model to try and graft on some modern functionality and security". Being in the kernel has no bearing on that - you haven't understood the context or argument.

                  1. Richard Plinston

                    Re: POSIX

                    > "Patch" = "thing that papers over the original conceptual model with a new conceptual model to try and graft on some modern functionality and security"

                    Linux (and other Unix like systems) supports various filesystems and various security models (DAC, ACL, MAC). In particular there can be different domains that have certain security models. That does not mean it is a 'patch', it is a modular hierarchy. The OS checks the domain, if it is set to one system then it uses, say, ACLs, if it is in a different domain (unconfined) then it uses permissions.

                    1. h4rm0ny

                      Re: POSIX

                      I believe the point you were contesting was that the default UNIX permissions system is less maintainable and less capable than Windows permissions. Like the other two posters, you keep trying to argue how you can use other systems on Linux if you choose. That both doesn't refute what I wrote and also glosses over the fact that only a minority of GNU/Linux installs and userbase actually makes use of such systems. The reason being, of course, that they are kludgy and ugly and fiddly to manage. Windows ACLs are built in at a very deep level to the design and are consistent across file systems, processes and configuration options. SELinux is something built above the default UNIX permissions system as a patch, an overlay. It doesn't matter if it's implemented in the kernel or wherever, conceptually that is what it is. Now you can try and dress it up in different language as you are attempting, call it "a modular hierarchy" wherever the Hell you got that from, but it remains what it is. A late addition that exists above the conceptual model that is the UNIX permissions system and manipulates that still existing lower model to get what it wants, it does not replace it as you attempt to suggest. It's all still there - turtles all the way down. Whereas ACLs are a basic component of Windows and universally used. Because they're easy and everything integrates with them naturally.

                      Re-phrasing something as "a modular hierarchy" or missing the point / confusing things by going on about it being implemented in the kernel, doesn't change what it is nor alter the fact that you're shifting ground from what I actually did which was compare Windows ACLs to default UNIX permissions - you know, those things that most GNU/Linux installs actually use in practice.

                      1. Richard Plinston

                        Re: POSIX

                        Whereas ACLs are a basic component of Windows

                        Only since NT (earlier Windows up to ME had nothing*), and then they have been changed with newer releases, such as 2000. And role based was 'patched on' in Server 2003.

                        > and universally used.

                        What percentage of all the millions of home based or SMB Windows machines have ever had a user set up an ACL? Where control is actually required ACLs is all you got.

                        > above the conceptual model that is the UNIX permissions system

                        Exactly. A hierarchy. The permissions model still works, and works well for most situations, but ACLs can be added to directories and/or files in those cases where more complexity is required.

                        * Actually you could have early Windows with a permissions system if you ran Windows on DR-DOS (since 3.31) or Novell-DOS (or some others) but MS-DOS never had that.

      3. Rick Giles
        Linux

        Re: POSIX

        its permissions system (which is a Hell of a lot more powerful and manageable than the default UNIX -rwx/rwx/rwx approach)

        I smell someone that can't convert Octal in their head...

        1. h4rm0ny
          WTF?

          Re: POSIX

          >>"I smell someone that can't convert Octal in their head..."

          I smell someone who hasn't noticed that computers moved on to 16, 32 and 64-bits since the days of ancient IBM mainframes (hint: octal doesn't make sense except when you have a word length that is a multiple if three, e.g. 12, 24, 36-bit machines and you don't seem to have been told we don't use those any more). As it happens I can convert to octal in my head seeing as it's just counting in binary, but I figured as my aim was to explain something rather than score Internet Points, I'd use the friendly notation that GNU/Linux systems themselves actually display it as. Or are Brian Fox and Richard Stallman similarly people who "can't convert Octal in their head" seeing as they chose to use the same notation I did in my post when they put together Bash back in the day?

          I don't know which is sadder - your godawful attempts to score points or the implication that a knowledge of octal being an aide to using a permissions says anything positive about the permissions system in question.

          1. Peter Gathercole Silver badge

            Re: POSIX @h4mn0ny

            Octal use in UNIX comes from it's DEC roots, not anything IBM did.

            DEC PDP-6, PDP-7, PDP-8, and PDP-10 (aka System10) variously had 12, 18 and 36 bit word lengths, which fitted octal (3 bits per nibble) very well, especially as they used 6-bit characters.

            When the PDP11 came along, which was a 16 bit system, DEC programmers had octal so ingrained in their mindset, that they stuck with octal, rather than switching to hexadecimal, which works better for 8/16 bit words. This stuck with the original UNIX developers at Bell Labs.

            You will also remember that Unics(sic) started on the PDP-7.

  4. thames

    Ugh!

    I just had a look at it. I picked a file at random - auth-passwd.c and looked at the Microsoft version versus the equivalent from the portable OpenSSH project. The Microsoft version is nearly twice as long (378 lines versus 216), with the addition of huge #ifdef hacks, converting back and forth between UTF8 and UTF16, and all sorts of other horrors.

    If I look at the altered source in all the files as a whole, there are 363 #ifdef or #ifndef sections related to what has been hacked in for Windows support. Other platforms (e.g. Linux, Apple, AIX) manage with just a couple of special cases.

    I'm not sure the OpenSSH developers would want that sort of thing hacked into their upstream source base. If it was me, I would certainly turn it down until the MS developers figure out how to separate that sort of stuff out in a minimally intrusive way.

    I'm really hoping they can get this working, as getting the server daemon working would be really handy for me when doing automated testing of software in VMs. So far though, the stuff that Microsoft has been working on looks like it needs a lot of work to meet the quality standards of what I would expect to be required to be accepted into the mainline branch of a major open source project.

    1. A Non e-mouse Silver badge

      Re: Ugh!

      To be fair, this is an early release of code and Windows is quite different from *nix. (Despite the early claims by Microsoft of POSIX conformity by Windows). Also, I don't think we know if the files you looked were originally modified by NoMachine or Microsoft.

      IIRC, there are often patches to the Linux kernel, which in their first draft, are horrible. But as both sides (maintainers and submitters) learn about each others problems, the code improves. (Isn't this one of the benefits of open source...?) And don't they say you should always through away version 1.0 code as that's where you work out how the code really needs to be written?

      Finally, remember this: MS are working on open source code in the open.

      I'm not generally an MS acolyte, but cut them a bit of slack. They're newbies in this open source world and we all had to start somewhere.

      1. Anonymous Coward
        Anonymous Coward

        Re: Ugh!

        I'm not generally an MS acolyte, but cut them a bit of slack. They're newbies in this open source world and we all had to start somewhere.

        No, for 2 reasons:

        * THEY may be new to Open Source, but that doesn't mean the code has to be. Open Source is not exactly a new idea, is it?

        * They could have made their entrance into the Open Source world with code that is less critical to platform security. Open or not, I think they're a long distance from trustworthy. Remember Kerberos?

    2. Anonymous Coward
      Anonymous Coward

      Re: Ugh!

      Windows API are mostly UTF-16, unlike Linux which is mostly UTF-8. So it doesn't look strange - nor it's an "horror" - just the way things need to be done (a better way would be to use UTF-16 everywhere in a Windows application, but it could be an even more complex task, depending on how the original code was written).

      Also, I hope for authentication it will use Active Directory authentication - otherwise it's pretty useless under Windows, and it will mean more Windows-specific code.

      Linux, OSX, AIX are all more or less *nix based systems with a common heritage. Windows is not, and has a fairly different implementation. Every cross platform application wishing to support Windows needs a fair number of #ifdef - unless you rely on even uglier layers like cygwin.

      For example, the way Git is implemented under Windows is truly horrible.

      1. Paul Crawford Silver badge

        Re: Ugh!

        "a better way would be to use UTF-16 everywhere in a Windows application"

        No a much better way would be some thin compatibility layer for Windows that allows UTF-8 to be used in Windows in place of UTF-16.

        UTF-16 is horrible and breaks all of the native C/C++ string handling and all legacy text applications. At least UTF-8 is usable, even if you have the unpleasantness of off characters in old editors and variable length strings for a fixed number of "characters" when outside of the ASCII Latin alphabet.

        1. Anonymous Coward
          Anonymous Coward

          Re: Ugh!

          C has no native string handling so it's not a language problem, just an implementation one <G>.

          C++ is an object oriented language so a proper string object should be able to manage its internal representation without issues even if it changes across platforms.

          What is best between UTF-8 and UTF-16 is debatable, but the real problema are badly coded application which always implied strings are only 8 bit ASCII - even ANSI had multi byte code sequences to allow for languages with more than 255 characters. Just some Western-centric developers, especially many US ones, could never understand their language is not the only one used world wide.

          If you have unpleasant characters, change application, it was written by someone without proper knowledge about string management.

          A "thin" compatibility layer would just be useful for lazy developers and would mean a lot of conversions from UTF-8 and the internal UTF-16 encoding - which would hit perfromance.

        2. Kristian Walsh Silver badge

          Re: Ugh!

          UTF-16 is horrible and breaks all of the native C/C++ string handling and all legacy text applications. At least UTF-8 is usable, even if you have the unpleasantness of off characters in old editors and variable length strings for a fixed number of "characters" when outside of the ASCII Latin alphabet.

          UTF-8 also breaks legacy text applications. The thing is, most of the time the text can pass through such systems unmolested, so that it looks like it's working. But only most of the time. Sooner or later, you'll hit a service that wants ISO-8859 or UTF-8, and you'll give it the other one, and you'll get garbled output, or mysterious runtime exceptions.

          The idea of eight-bit text is so deeply ingrained into UNIX and its descendants that it can be hard to explain that this is is only one of several possible approaches to text processing, and the reason for it had more to do with what language the systems designers spoke, rather than any sound technical judgement (Had the Japanese invented the mainframe, we would have had 12-bit or 16-bit characters, because 8 bits are inadequate for the set of symbols they need to write their language). The other UNIX thinking trap is conflating the idea of a machine-readable "text file" with the idea of human-readable "text". It's the mental equivalent of "YY/MM/DD" date recoding, or 32-bit IP addresses; fine for the initial use scenario, but seriously limiting in the long term.

          On your other criticisms: as pointed out above, C++ strings can have any size of character. I wrote and used a 16-bit Unicode string class for years in my code. It took me less than a morning to write it (it's just a specialisation of the existing basic_string<T> template).

          On the second point, you're raising a non-issue. As a rule, a programmer never needs to know the number of "characters" in a string of natural-language (i.e., not command-line switches, configuration verbs, or other stuff that UNIX-like OSes send around) text, only the amount of storage it occupies... which is just as well, because you never can know this in most cases.

          If you're wondering why not, then first you must define what a "character" is, and it's not the same as "byte", or even "Unicode code-point". If this input form has preserved my input correctly, the two sequences "éiginnte" and "éiginnte" will not be the same length (different code-sequences can produce the same output glyphs). And that's before we get to the questions of language - Dutch treats the pair i,j as a single letter in many cases: is the word "rijk" [four codepoints] four or three characters long; is it the same "length" as "rijk" [three codepoints]?. How about "sœur"?

          Luckily, all you need to care about is how much space these code-points occupy (8,9,4,3,4 codepoints, in order). Any ideas that this number is easily related to the number of displayed glyphs, or the "length" of the text the reader sees, is a fallacy.

    3. h4rm0ny

      Re: Ugh!

      >>"I just had a look at it. I picked a file at random - auth-passwd.c and looked at the Microsoft version versus the equivalent from the portable OpenSSH project. The Microsoft version is nearly twice as long (378 lines versus 216), with the addition of huge #ifdef hacks, converting back and forth between UTF8 and UTF16, and all sorts of other horrors."

      I don't consider "nearly twice as long" as a file in OpenSSH to be a criticism. Maintainable code is often longer than hard to maintain code just because it's better structured. Your comment reminds me of ancient C programmers decrying Open Source with, well as it happens, exactly the same criticism - "but look, it's twice as many lines of code". No-one who is objective and knows about code should be making a criticism like the one above. As to converting between UTF-8 and UTF-16, well if one peer is using the former and the other the latter, what exactly would you suggest?

      Anyway, you are surely not holding up the labyrinth that is the OpenSSH project as an example of clean, well-structured coding. Are you? :/

    4. Warm Braw

      Re: Ugh!

      >Other platforms ... manage with just a couple of special cases

      That's because the other platforms are Unix (I'll leave aside the discussion about why there should be a need for such special cases at all in this day and age). There's a whole load of stuff that Windows just does differently - process creation in particular (which is a big deal for a protocol that has so much hacky stuff in for tunneling X and secure file transfer) and that's before we get to cryptography, permissions, file names, environment, dotfiles, etc, etc...

      If you were starting from scratch writing OpenSSH with a view to it being ported to Windows, you'd arrange the code very differently (actually, you'd arrange the functionality rather differently, but that ship has sailed). At this point, it seems there is a choice between making significant changes to the existing code (even if it's just re-arranging the source into a different structure so the architecture-dependent stuff is less scattered) or having huge chunks of conditional hacks. I doubt if either of those approaches is likely to appeal to the OpenSSH maintainers (especially as they pride themselves on their clean code base to which the porting hacks are retro-fitted).

      Tl;dr - maybe writing something from scratch for Windows would have been a better idea. Unfortunately, PuTTY doesn't have a server...

  5. Chairo
    Thumb Up

    Wow!

    they made it available on GitHub. You would think Microsoft of today would put it somewhere with Windows 10 only access.

    So they are not all completely evil?

    1. Anonymous Coward
      Anonymous Coward

      Re: Wow!

      > "So they are not all completely evil?"

      Considering Microsoft's track record, they aren't completely anything.

      1. Anonymous Coward
        Anonymous Coward

        Re: Wow!

        Considering Microsoft's track record, they aren't completely anything

        Failing in a market they can't subvert and monopolise?

      2. Anonymous Coward
        Anonymous Coward

        Re: Wow!

        "Considering Microsoft's track record, they aren't completely anything."

        I'd posit they are completely full of shit.

    2. phuzz Silver badge
      Gimp

      Re: Wow!

      Always remember, Microsoft is so big that one department might be working entirely contrary to another department.

      Also, this might be costing them a bit of money, but it's gaining them some goodwill/PR, and if it makes it easier to run a Windows server, they might even sell more licenses than they would otherwise.

  6. Message From A Self-Destructing Turnip

    Bonjour

    "Je m'appelle Monsieur Nadella"

  7. Anonymous Coward
    Childcatcher

    Found it!

    Yep, the obfuscated telemetry code is there as expected

    1. Paul Crawford Silver badge

      Re: Found it!

      [citation required]

      1. James O'Shea

        Re: Found it!

        "[citation required]"

        I quite agree. The OP should, by all means, either post the alleged code or retract the unfunny comment.

        I'm not particularly fond of MS, but the level of MS hatred around here really goes way over the top at times. If MS did, in fact, park some hidden code to call home into their version of SSH, then they should be exposed. If they did not do this, then saying so is simply defamation. And that's wrong, even if it _is_ MS which is being defamed.

  8. Kobblestown

    Cygwin SSH server

    So how is it better than Cygwin's SSH server (apart from the use of CryptoAPI)? I have used it for years to log in to Windows machines. I don't use PowerShell but I assume I can invoke it from a Cygwin shell. Or is that not the case? I'm genuinely asking.

    1. theOtherJT Silver badge

      Re: Cygwin SSH server

      You can indeed invoke powershell from inside cygwin.

    2. Anonymous Coward
      Anonymous Coward

      Re: Cygwin SSH server

      1) You don't need to install all the cygwin stuff (and maintain it yourself)

      2) It should be better integrated with the OS itself

      3) It should be better integrated with Windows security and accounting - i.e. in many situations you may wanto to know from Windows logs who connected and when, and manage permission through active directory.

      Especially if you have a large number of server, and not a few, all are good reason for a "native" SSH server.

      1. Kobblestown

        Re: Cygwin SSH server

        "1) You don't need to install all the cygwin stuff (and maintain it yourself)"

        Well, but Cygwin is always the first thing I install on any Windows machine I use. Ok, the second one - I furst install Firefox and then use it to download the Cygwin setup utility. BTW, is there some native Windows application akin to the 'screen' terminal multiplexer?

        "3) It should be better integrated with Windows security and accounting - i.e. in many situations you may wanto to know from Windows logs who connected and when, and manage permission through active directory."

        Not my use case, really. But just out of curiosity - can Cygwin be set up for LDAP authentication against AD. Anyone here knows? It can be done statically with mkpasswd but it would certainly be better to be always up to date with AD.

  9. kryptylomese

    SSH on Linux is not just a means to remotely log into a server, it also allows for lots of clever traffic forwarding tricks that I think that most Windows guys will not be familiar with. One excellent utility is "sshuttle" which creates an instant VPN using SSH and some special firewall implementation and no software is needed to be installed at the other end. I do not believe that Windows has an equivalent (yet). It is also possible to create a full VPN over SSH.

    It has of course been possible to SSH to and from a Windows computer for a long time but SSH on Windows is feature limited.

    These methods are a security concern due to the ease that firewalls can be circumvented, and I would worry about Windows boxes being able to use them (administrators will turn the service on without fully understanding the implications) in a production environment.

    1. Anonymous Coward
      Anonymous Coward

      "it also allows for lots of clever traffic forwarding tricks that I think that most Windows guys will not be familiar with"

      Windows guys just use IPSEC for that sort of stuff, and do it properly at the network level...

      1. kryptylomese

        Sigh - Windows will soon have SSH built in (which is the topic of this forum).

        My point is that you (Windows guys) now have other options that are in some ways more powerful e.g. SSH's ability to port forward, and I do not think that you would really go to all the trouble of setting up an IPSEC VPN when one command will do the same job, and can also forward other ports as desired in the same command (which IPSEC cannot do).

        It would seem that Windows guys only use the tools they are given, Linux guys build tools to work more efficiently, and they understand the security implications.

        1. Maventi

          Agree @kryptylomese - sadly in my experience is that Windows folks are generally (but there are some exceptions fortunately) very blind to any other way of doing anything - to them 'Windows' and 'computers' are virtually synonymous. The folks with 'nix experience generally accept that there any many ways to achieve anything and simply get on with what suits the task at hand. Yes I do generalise, but I've lived in both camps in my years in industry and it's something I've often noticed.

          Many of the 'nix folks are still wary of Microsoft for their past attempts to actively make 'simply getting on with the task' very difficult in a heterogeneous environment. That seems to be much less true these days so perhaps it's time to bury the hatchet, shake hands and move forward together?

          I applaud the SSH effort - it will really help to build some bridges in the every increasing mix of stuff we see in a datacentre these days.

          Fighting over scripting languages and such is just silly. Find a tool that works for you and get on with the job.

      2. Peter Gathercole Silver badge

        @AC re. IPSEC.

        Ah, but SSH works at a user level, so you can use it to do tricks through systems that you don't have admin access to (like most organizations with silo'd platform support.)

        Whether this is a good or bad thing depends on whether you're a sysadmin in a heterogeneous environment that you don't completely control, or whether you're in IT security!

  10. CAPS LOCK

    There's a lot of embracing and extending going on here...

    .... I expect, down the road a bit, there may be some extinguishing.

    1. phil 27

      Re: There's a lot of embracing and extending going on here...

      I can't believe its taken until capslock's post for the obvious leopard spots history of microsoft and new protocols to come out although someone hinted at it with kerberos earlier. What short memories you all have while bickering about posix and permissions systems...

  11. T J
    Megaphone

    Um...

    http://www.freesshd.com/

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like