Install Win32 OpenSSH test release(github.com) |
Install Win32 OpenSSH test release(github.com) |
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.
It's still way too early to us as a daily driver - lots of small bugs - but nevertheless interesting.
For example:
$ ssh username@windows.example.com
...
C:\>
$ 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>For some reason putty works but iTerm has the backspace issue. Putty user: what's your $TERM?
Ctrl H works as a workaround BTW.
1. Userify cloud ssh key mgmt - https://userify.com
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?
Also, you probably want PowerShell if you manage a windows system remotely. (Ok, you specifically maybe not, but many users do)
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.
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.
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.
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.
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.
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 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 for Cygwin's sshd, we don't want to step their toes any more than we already have.
[1] http://blogs.msdn.com/b/powershell/archive/2015/10/19/openss...
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.
https://technet.microsoft.com/en-us/library/hh134826.aspx?f=...
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.
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.
ps | where {$_.StartTime -ge $1HourAgo}
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.
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.
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.