Install Win32 OpenSSH test release
github.comThis project is _not_ about bringing UNIX to Windows. It is about bringing the open ssh protocol to Windows. As a daily UNIX and Windows user in an enterprise environment, I can say that a fully integrated sshd is a welcomed addition. I have written and maintained many WinRM interop ruby gems and cannot wait until we can deprecate them in favor of a better and sane remote she'll implementation. This is a real milestone, keep up the great work.
As for Cygwin sshd, it does work if posix is the order of the day but if you need a reliable terminal (for things like powershell) that scales to hundreds of servers and many admins Cygwin simply fails the test. Clunky domain authentication, private key auth is a joke, powershell only works sometimes (thanks PTY), network tokens are non-existent, etc. the list goes on and on.
See also https://github.com/PowerShell/Win32-OpenSSH/wiki/ssh.exe-exa... once you've got it running. To work around a bug, you'll currently need to run `powershell -File -`
It's still way too early to us as a daily driver - lots of small bugs - but nevertheless interesting.
So once you've done this and you SSH in to the Windows box, I assume you just end up, basically, in a command window?
For example:
$ ssh username@windows.example.com
...
C:\>
Yes. From my Mac:
$ ssh mike@192.168.0.12 mike@192.168.0.12's password: Microsoft Windows [Version 10.0.10586] (c) 2015 Microsoft Corporation. All rights reserved. C:\Users\Mike>powershell -File - PS C:\Users\Mike>
Backspace doesn't work from a Linux box SSHing into Windows (strange world we live in), but otherwise it's great.
See https://github.com/PowerShell/Win32-OpenSSH/issues/57.
For some reason putty works but iTerm has the backspace issue. Putty user: what's your $TERM?
Ctrl H works as a workaround BTW.
$TERM from PuTTY - xterm $TERM from Terminal.app - xterm-256color
It may just be the settings in your SSH client (some of them are weird). Which SSH client are you using and have you tried any others?
What about ^H?
Works as backspace. DEL is working, but not updating the screen if that makes sense.
Interesting that the build instructions refer to Cygwin. It's a bit surprising, I'd have expected something more native. What does this bring to the table that regular Cygwin OpenSSHd couldn't do 10 years ago?
Powershell integration. Cygwin SSH drops you into a bash prompt running on the Windows box. Powershell is much more deeply integrated with Windows, and is more useful for actual system administration (e.g. configuring IIS, SQL Server, etc) than Cygwin's bash.
What "integration" are you seeing? It looks to me like they're just dumping you out to a CMD.EXE instance and leaving it up to you if you want to run Powershell. It's nice to see MSFT embracing SSH and all, but this is nothing that we haven't already been able to do for going on 10 years (likely longer) w/ OpenSSH on Win32.
This is just a very early step one in their roadmap [1]. The deeper integration is in the next few steps in their development plan.
[1] http://blogs.msdn.com/b/powershell/archive/2015/10/19/openss...
Asides from being an actual Windows app as you mentioned, it's also a current OpenSSH codebase.
But cygwin seems to have v7.1 too. Is it "just" a build that doesn't depend on cygwin.dll? (Although I can appreciate that's probably a nontrivial porting job). Genuinely curious about what's new here.
It's an early alpha build. This is "just" getting to a point where they're working on a modern codebase. MS has said that they're going to add more functionality as they develop this into a much more useful admin tool.
Feature request: Domain group policy setting for authorized keys. Make some ssh key(s) authorized to logon as some domain user(s) for every machine in the domain.
We're going to be porting our Linux/UNIX (python) shim [1] to PowerShell asap so that you can provide your users an actual UX for key management... integrating it with group policies would be really cool too. (However, it might be orthogonal to our goal of local admin accounts to eliminate dependence on centralized auth.)
1. Userify cloud ssh key mgmt - https://userify.com
You could do this right now w/ w/ a "Startup Script" or using Group Policy Preferences. The authorization to logon is, presumably, tied to the "User Right" to logon interactively and shouldn't have anything to do w/ the SSH server (since it's just userland).
Authorized keys in the context of ssh means the ability to logon without password using public key authentication.
Now that I'm thinking about this, anybody know how they're doing public key authentication for domain accounts at all? If you don't use a password to logon, how are you supposed to get a Kerberos ticket to use domain network resources?
Yeah-- that was a pretty braindead response. I was thinking "authorized hosts". Now I feel silly.
re: the public key authentication for domain accounts - They're calling the undocumented NtCreateToken() API in "win32auth.c". They don't need a password to create a token going that route. They've also got an LSA Security Package to do the key validation inside LSA. I'm looking at this very quickly, but I'm not seeing that they extended the AD schema to store the public key in the user's AD account. That would be the best way to handle it, ultimately-- just have the DCs use that SSH-LSA Security Package to authenticate the users against the public key stored in their AD account.
I think you can use "klist" with "get":
https://technet.microsoft.com/en-us/library/hh134826.aspx?f=...
On Linux you can still execute 'kinit' to power up and get a ticket. (Via password).
I'm sure there will be something similar. Unless authentication in the first place cannot be decoupled from ssh login, then your key would have to be able to grant you a Kerberos ticket.
You can already install OpenSSH for Windows without bothering with PowerShell. See http://linuxbsdos.com/2015/07/30/how-to-install-openssh-on-w...
Can you run PowerShell through this?
Also, you probably want PowerShell if you manage a windows system remotely. (Ok, you specifically maybe not, but many users do)
Microsoft is going about the whole SSH thing in a very backwards way.
If all they did was make or back an official POSIX environment, all of this comes for free.
Insisting that PowerShell be the focal point for all these changes is just bizarre.
Just install msys2.
A half-bad Unix on top of Windows, with its own duplicate way of handling services, storage, users, permissions and everything else, is a pretty poor setup. Powershell (particularly the way it separates data from presentation) is one of the best shells on any OS. Being able to access it from Linux is a good thing.
As soon as Microsoft open sources PowerShell I'll be more than happy to take a look at it and perhaps add it to MSYS2. Until then for me and many like me, it's neither half bad nor half good, it lies orthogonal to the scale on which I judge software.
This "separate data from presentation" sounds like TCO-speak. Way too frequently referenced to be a genuine inspiration.
It's only "half bad" (if that even) because while the whole world moved on from Windows to Unix (OSX, Linux), Microsoft dug their heels in. Think of it as paying down long overdue technical debt.
> This "separate data from presentation" sounds like TCO-speak. Way too frequently referenced to be a genuine inspiration.
Huh? It's a very specific thing. When you run stuff on Powershell, you pipe it to 'select' or 'where' and pick fields, rather than running grep / sed / awk and inventing regexs to scrape stuff.
Before accusing me of 'TCO speak' and being 'ungenuine' - for mentioning something that's a well known engineering concept, particularly in the Unix world (ever used TeX?), you could have done <1 minute of research.ps | where {$_.StartTime -ge $1HourAgo}If someone created a solid port of PowerShell to nix it would be a god-send.
They purchased a reasonably nice POSIX environment when they bought Interix in 1999 (https://en.wikipedia.org/wiki/Interix). Interix was a lot of fun to use, and I really wish it still existed as a product. I used to have fanciful dreams of a POSIX-based Linux-like "distribution" of Windows that kept a lot of the things I like about the Windows NT environment (NTFS filesystem, kernel object manager, service control manager) but jettisoned those things I don't.
Yeah, it went through a pile of rebrands until Windows 8 when it ended up getting pulled in one of the preview releases IIRC. I've wanted similar to you just so that people could target some kinda baseline on Windows with FOSS.
I mean, I get that coming from the other direction, powershell seems like a nice treat. And if you use it, colour me impressed. I know in some cases, it's the only option for doing script work on Windows machines. But there is a much bigger and more sane ecosystem waiting if MS just rallied around SFU again. Probably cheaper too, tell the investors that.
>I mean, I get that coming from the other direction, powershell seems like a nice treat. And if you use it, colour me impressed. I know in some cases, it's the only option for doing script work on Windows machines.
Your dismissive attitude towards PowerShell makes me think you either haven't put much time into using it (if any) or haven't touched it since the 1.x days (even then the benefits over a string-based shell should have been obvious). It's a really good shell and is in a completely different league than sh/bash/zsh. It's not the best scripting language and there are still warts but until they make a solid and practical Ruby or Python based shell it's going to sit far and away from the rest.
If the many replies you've gotten haven't been enough motivation I encourage you to actually try it out for a while.
I don't know, most of the people who are replying seem to be quite rude about it. I certainly judge software by the community and I'd hate to need a question answered by them. /s
As for actually trying it... I'd love to, but every time I do I come up against limitations. Mostly because none of the projects I use write shell scripts for powershell.
But again, that doesn't justify PS being the only one that gets any official attention on Windows, hence me mentioning msys2 earlier.
I think the rudeness is mostly a response to what seemed like dismissiveness with an apparent lack of personal experience. I had a hard time containing my incredulousness as well to be honest.
As far as official attention goes, I think Microsoft is right to stay focused. Third parties can and should feel free to build their own solutions though.
I loved using SFU/Interix with Gentoo-prefix on XP and Win7 enterprise. I'm using Msys2 now and am pretty happy with it. There are mingw packages for practically everything but openssh is msys only. So this native openssh should give some speedup.
There's a huge difference in functionality and philosophy between powershell and posix. For one, everything in powershell is an object. What this means, is that when you pipe things together, you're not just piping output strings, you have iterators, arrays, closures, typed values, etc at your disposal. Additionally, in powershell, you can use arbitrary CLR libraries as if they were native. Posix shells, in contrast, tend to require you to write and build wrapper libraries to import the functions into your scripting environment.
So in short, using a posix shell would mean getting rid of all of the work MS has put into an insanely flexible command environment over the past several years. Insisting on posix just denies the flexibility to experiment and develop something which serves a different problem set, or approaches a problem from a new angle.
PowerShell is the focal point for Windows on Azure, for Server Core and for Server Nano. So it makes perfect sense from that perspective. As a Windows and Linux user, this is absolutely fantastic.
msys2 still can't overcome some of the limitations of mintty so it kinda makes sense.
More choice in this case isn't a bad thing.
Why is having PowerShell be the focal point for this bizarre? PowerShell is Windows' native command line interface.
Most of the scriptable administration tools (which are being heavily promoted as the primary way to administer Windows boxes these days) are PowerShell based, the tools for talking to Azure are PowerShell based, the new package manager in Windows 10 is PowerShell based, etcetera.
OpenSSH isn't being ported to Windows to make Windows overall more POSIXish; it's being ported to make managing Windows boxen from POSIX ones easier, and vice versa.
I don't know why YCOmega is getting downvoted, msys2 is actually an extremely nice environment, now that Interix has been dead for quite some time.
I wish msys2 would figure out how to port Cygwin's sshd, or figure out how to use Microsoft's new one to give me a msys2'ed zsh prompt instead of Powershell.
As far as I can tell (initial glance only), building this port requires Visual Studio which is a shame. It'd require a bit of effort to port. I wish MS had gone down the CMake route again.
As for Cygwin's sshd, we don't want to step their toes any more than we already have.
Managing Windows from the command line these days without PowerShell is severely handicapping yourself. It's not practical to divorce PowerShell from Windows command line administration.
This is great news. @ Userify[1], we're looking forward to porting our shim to PowerShell asap.