Microsoft To Support SSH In Windows and Contribute To OpenSSH

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.

Comments

Cygwin

[ls671]

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

Re:Odd thoughts:

[AFCArchvile]

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