Slashdot Mirror
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.
it's only 2015 guys...
now you can use Windows computers the way they were meant to be used, as dummy linux clients
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...
Everything I write is lies, read between the lines.
* 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.
Quo usque tandem abutere, Nimbus, patientia nostra?
No. Cygwin runs everything under one process. This will run separate processes for each SSH session, with privilege separation. Cygwin also uses its own /etc/passwd. This will use local windows users, and, hopefully, AD users.
And code will be sent upstream.
Much better if this works out.
Too bad opening an SSH into Windows will drop you into the complex abomination that is PowerShell.
The world's burning. Moped Jesus spotted on I50. Details at 11.
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.
The
You know it's going to be just yet another way of hacking into a Windows box.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
That, for example, in order to ssh into a remote Windows system you'll have to use Microsoft's ssh-client — because they'll use some funky cipher/digest combination or some other "extension". They did it to Kerberos before...
Or that interactive logins will only work on certain terminal emulators — because nothing else will be able to properly emulate powershell's window — just imagine the termcaps entry...
In the link I gave there is a large list of Microsoft's earlier attempts to kill a standard by first adopting it — read it up...
In Soviet Washington the swamp drains you.
K. Construct a for loop in PS that lists a directory and adds the words "This is cool" to the 13th line of any file of type "text" without downloading a module.
Off the top of my head (and using verbose commands to make it more obvious), I got:
dir | where -Property Extension -match '.te?xt' | foreach {
$i=0;$s=(Get-Content $_.FullName);
$s | foreach { if ( (($i++) % 13) -eq 0) { $_+" This is cool" } else { $_ } } | Set-Content $_.FullName
}
I haven't thought of a way to do the file type determination (other than by the extension), but that will do just for a post to an AC. It can all be done on a single line; I added the line breaks and indentation so it wasn't a big line of gobbledegook. Now it is several lines of gobbledegook!
The impressive part of the tab completion of Powershell is how context sensitive it is. When I typed the where command, I entered -p<TAB> and it expanded it to -Property (although just -p would work too). But the fun part was that I could then type e<TAB> and then go through the list of property names that are returned from the dir command that begin with the letter e; first Exists, then Extension. So it was aware what was being passed to the where command on the pipeline and returning the correct properties for that object.
So if I typed the following:
get-content "file.txt" | where -Property
...and pressed the tab key, it gives me the property name of Length as it knows that it is returning a string rather than a file. The same where command will work on (and give appropriate tab completion) on a directory listing, file output, database query, or XML tree list.