OpenSSH for Windows update(blogs.msdn.com)
blogs.msdn.com
OpenSSH for Windows update
http://blogs.msdn.com/b/powershell/archive/2015/10/19/openssh-for-windows-update.aspx
145 comments
Why would the OpenBSD team not accept the commits? It is just linking to a system library that will always be present on the platform. It's like saying Windows opensource should be forced to use some thrid party filesystem library.
My guess is they won't just write an openssl to schannel shim and instead sprinkle ifdefs throughout the code which would be a recipe for disaster.
Looking at the new code I feel like the chances this ever makes it upstream to pretty close to 0.
Looking at the new code I feel like the chances this ever makes it upstream to pretty close to 0.
I think that there is nothing to accept.
These patches are going to the portable version - which has always been a separately maintained branch of openssh. e.g. no PAM, no Kerberos ...
These patches are going to the portable version - which has always been a separately maintained branch of openssh. e.g. no PAM, no Kerberos ...
> PS. If you're coming from a Unix background and interested in learning posh: https://certsimple.com/rosetta-stone
I stopped reading this when I got to this part:
Just put none in the `whois` box and move on.
I stopped reading this when I got to this part:
whois 'domain [domain name]'
$web = New-WebServiceProxy 'http://www.webservicex.net/whois.asmx?WSDL'
$web.GetWhoIs('[domain name]')
Just put none in the `whois` box and move on.
The main aim is to be useful. Someone who wants to lookup Whois is better served by giving them something that will achieve that task.
If you have other suggestions though, send a pull request. The project has already gotten a bunch from the SmartOS and FreeBSD communities.
If you have other suggestions though, send a pull request. The project has already gotten a bunch from the SmartOS and FreeBSD communities.
If I could send a pull request to Microsoft for inclusion of a legit whois binary on their OS--nope, you're right, I'm just full of spite on this subject. :)
Actually, pretty sure most linux distributions don't ship with the whois binary.
(This is entirely based on the fact that I find myself installing it far too often)
(This is entirely based on the fact that I find myself installing it far too often)
That's a feature. My initial installations don't include much. Tools are installed the first time I need to use them.
Or hell, use something like https://github.com/bone187/PowerShell-Whois/blob/master/whoi.... I like PowerShell but sometimes the community makes me wonder.
That's certainly a lot cleaner than using the WSDL implementation. I've bumped the release on npm and used this instead - thank you.
If anyone else on HN wants to add anything, the source is just markdown, so you can hack away (gulp does the HTML building and JS does the interactivity): https://github.com/certsimple/rosetta-stone/blob/master/rose...
If anyone else on HN wants to add anything, the source is just markdown, so you can hack away (gulp does the HTML building and JS does the interactivity): https://github.com/certsimple/rosetta-stone/blob/master/rose...
Was just coming here to voice my concerns over this choice as well, wondering what their reasoning is for changing crypto systems.
I imagine it's nothing more complicated than "OpenSSL isn't the native crypto implementation on Windows, SChannel is". Microsoft's engineers are probably much more familiar with SChannel, and they don't want to have to test/validate two crypto systems in parallel. Besides, this should make OpenSSH better in the long run; it should be able to have any compatible crypto layer underneath.
SChannel implements SSL/TLS as a security support provider (SSP), native crypto interfaces are WinCNG (current) or CryptoAPI (legacy). A port of OpenSSH that used the native crypto library would likely use WinCNG.
An OpenSSL-like wrapper around WinCNG can be found in Heimdal's libhcrypto.
An OpenSSL-like wrapper around WinCNG can be found in Heimdal's libhcrypto.
A crypto system is a big and complex thing, subtle and quick to anger, and I can't blame Microsoft for wanting to concentrate on the one they're already supporting, instead of having to support two.
On the other hand, for the exact same reason, I expect OpenSSH probably isn't interested in supporting anything besides LibreSSL and maybe OpenSSL, at least while they're so closely related.
On the other hand, for the exact same reason, I expect OpenSSH probably isn't interested in supporting anything besides LibreSSL and maybe OpenSSL, at least while they're so closely related.
So you think it'll remain a fork, rather than a platform for OpenSSH?
If they implemented a good openssl to cryptoAPI shim it could be usable by other projects linked against OpenSSL.
If they implemented a good openssl to cryptoAPI shim it could be usable by other projects linked against OpenSSL.
You can already build OpenSSH without a libssl (make OPENSSL=no), it drops support for ssh1 and the only algos available are curve25519, aes-ctr, chacha, ed25519 (or were when it was first announced[0])
[0] http://article.gmane.org/gmane.os.openbsd.cvs/130612
[0] http://article.gmane.org/gmane.os.openbsd.cvs/130612
Duplication of effort and attack surface. Now, instead of worrying about just keeping Windows' crypto api secure, Microsoft would have to worry about libressl as well?
Long term, if this is truly a first-party supported SSHd, it makes sense.
Long term, if this is truly a first-party supported SSHd, it makes sense.
Also, keep in mind that modern OpenSSH does not need to link against OpenSSL anymore. You will have to make do with the bundled ciphers ed25519 and chacha, which is useless for talking to your legacy systems, but if you are making a new deployment it might suffice (or even be desirable).
The article is not clear if that's an option with this new Windows port, but it would decrease the attack surface a lot, which can only be good. SChannel has had its fair share of nasties over the years.
The article is not clear if that's an option with this new Windows port, but it would decrease the attack surface a lot, which can only be good. SChannel has had its fair share of nasties over the years.
I really don't like that there replacing an open source crypto with a closed source one. Putting on my tin foil hat but didn't Microsoft hand over a back door to the NSA already.
> Putting on my tin foil hat but didn't Microsoft hand over a back door to the NSA already.
What incident are you referring to? I can think of a couple of possible ones:
1. PRISM, which is still a big question mark, and if it's in your threat model, then running Windows, let alone running Windows with an SSH server of any form, is not something you want to be doing, regardless of whether a particular library in it is open-source.
2. _NSAKEY, which MS had a decently convicing explanation of: it was a signing key used to indicate NSA-approved cryptographic providers (for FIPS-ish auditing), not anything that could be used to break into a user's account remotely.
3. The removal of the Elephant diffuser from BitLocker. My personal opinion is that all "diffusers", custom block cipher modes, etc. for full-disk encryption are pseudoscience; if you really want integrity protection, change your filesystem so it uses 4064-byte sectors, a 16-byte IV, and a 16-byte authentication tag. In any case, it still requires physical access to the disk to attack, so it's not particularly useful as an NSA back door (unless your threat model is one of the "then you have bigger problems" ones).
But maybe I'm forgetting something else?
What incident are you referring to? I can think of a couple of possible ones:
1. PRISM, which is still a big question mark, and if it's in your threat model, then running Windows, let alone running Windows with an SSH server of any form, is not something you want to be doing, regardless of whether a particular library in it is open-source.
2. _NSAKEY, which MS had a decently convicing explanation of: it was a signing key used to indicate NSA-approved cryptographic providers (for FIPS-ish auditing), not anything that could be used to break into a user's account remotely.
3. The removal of the Elephant diffuser from BitLocker. My personal opinion is that all "diffusers", custom block cipher modes, etc. for full-disk encryption are pseudoscience; if you really want integrity protection, change your filesystem so it uses 4064-byte sectors, a 16-byte IV, and a 16-byte authentication tag. In any case, it still requires physical access to the disk to attack, so it's not particularly useful as an NSA back door (unless your threat model is one of the "then you have bigger problems" ones).
But maybe I'm forgetting something else?
The two cryptographers who originally publicly identified the backdoor (that Snowden eventually confirmed) work for Microsoft. So, the opposite of what you're insinuating.
http://rump2007.cr.yp.to/15-shumow.pdf
Always possible MS is not to be trusted, but there's nothing on the record to support that.
http://rump2007.cr.yp.to/15-shumow.pdf
Always possible MS is not to be trusted, but there's nothing on the record to support that.
They collaborated with the NSA to develop an exploit in the SSL implementation used in Outlook.com.
From the Snowden documents;
July 31, 2012
Microsoft (MS) began encrypting web-based chat with the introduction of the new outlook.com service. This new Secure Socket Layer (SSL) encryption effectively cut off collection of the new service for FAA 702 and likely 12333 (to some degree) for the Intelligence Community (IC). MS, working with the FBI, developed a surveillance capability to deal with the new SSL. These solutions were successfully tested and went live 12 Dec 2012.
From the Snowden documents;
July 31, 2012
Microsoft (MS) began encrypting web-based chat with the introduction of the new outlook.com service. This new Secure Socket Layer (SSL) encryption effectively cut off collection of the new service for FAA 702 and likely 12333 (to some degree) for the Intelligence Community (IC). MS, working with the FBI, developed a surveillance capability to deal with the new SSL. These solutions were successfully tested and went live 12 Dec 2012.
It's not clear this should be called an "exploit". It sounds like Microsoft in its capacity as a cryptographic endpoint turning over either plaintext or session keys (or in the severely worst case, long-term private keys). It doesn't make much sense to me to refer to that as an "exploit".
Actually, sorry that was the FBI they worked with.
No.
Sorry, I don't understand this response.
Are you saying that you are familiar with the events that DonnyV is referring to but you are confident that they are mere legend? That you disagree with the published accounts?
Or are you saying that you are not familiar with that particular scandal, you've never heard of it, and your response is simply "Not that I know of."?
Are you saying that you are familiar with the events that DonnyV is referring to but you are confident that they are mere legend? That you disagree with the published accounts?
Or are you saying that you are not familiar with that particular scandal, you've never heard of it, and your response is simply "Not that I know of."?
If you check his post history he basically just blanket denies everything relating to the Snowden NSA leaks and accuses people of believing in 'magic' when they discuss the agency's capabilities.
That's not true at all. I question it when people post conspiracy theory stuff with no evidence whatsoever. HackerNews is not that type of website, and I hope it never degenerates into it.
[deleted]
I'm surprised the OpenBSD team is accepting the commits
Theo has come a long way since he lost beaucoup bucks by spitting in DARPA's face after taking their money.[1] Now Microsoft and OpenBSD are besties.[2]
There are a few companies that give money to OpenBSD. Far too few, but there are some: http://www.openbsdfoundation.org/contributors.html
The saddest thing to me is that Yandex is on there. Not because they shouldn't be, but because so many American and Western companies are willing to take, take, take, but are unwilling to give back even a little bit.
[1] http://www.computerworld.com/article/2580728/security0/darpa... [2] http://www.theregister.co.uk/2015/07/08/microsoft_donates_to...
Theo has come a long way since he lost beaucoup bucks by spitting in DARPA's face after taking their money.[1] Now Microsoft and OpenBSD are besties.[2]
There are a few companies that give money to OpenBSD. Far too few, but there are some: http://www.openbsdfoundation.org/contributors.html
The saddest thing to me is that Yandex is on there. Not because they shouldn't be, but because so many American and Western companies are willing to take, take, take, but are unwilling to give back even a little bit.
[1] http://www.computerworld.com/article/2580728/security0/darpa... [2] http://www.theregister.co.uk/2015/07/08/microsoft_donates_to...
>I'm surprised the OpenBSD team is accepting the commits
What commits? From the comments you will learn there were no commits and this is a classic embrace and extend. They are hijacking OpenSSL name, and rewriting it to use Microsoft crypto and APIs.
What commits? From the comments you will learn there were no commits and this is a classic embrace and extend. They are hijacking OpenSSL name, and rewriting it to use Microsoft crypto and APIs.
> Address POSIX compatibility concerns
Best way to address POSIX compatibility concerns is implementing a proper POSIX layer in Windows (and not in a half-baked manner like the now deprecated SUA). I can't imagine how it would hurt anybody.
Best way to address POSIX compatibility concerns is implementing a proper POSIX layer in Windows (and not in a half-baked manner like the now deprecated SUA). I can't imagine how it would hurt anybody.
SUA was not half-baked, this is a very, very hard problem. There is a very serious difference in the way POSIX and Windows model a lot of really important OS primitives, from asynchronicity model in signals, to the semantics of syscalls like `fork`. Every process using these primitives on POSIX has specific behavior defined under those primitives, and if you don't choose _exactly_ the right behavior on the POSIX subsystem in Windows you will definitely break programs.
So, no. You can't "just" implement a POSIX subsystem correctly. These systems are just not compatible. It will always be half broken.
So, no. You can't "just" implement a POSIX subsystem correctly. These systems are just not compatible. It will always be half broken.
Indeed. The Cygwin project has done an amazing job working to act as a compatibility layer between Windows and POSIX, but even Cygwin, with all the time and energy that's gone into it, still has some rough edges. Not to say that using it isn't awesome, but it's not perfect.
Microsoft does control the kernel, and given that, none of this stuff is particularly complicated.
As for choosing "_exactly_ the right behavior" ... the whole point of POSIX is to clearly define the exact right behavior!
As for choosing "_exactly_ the right behavior" ... the whole point of POSIX is to clearly define the exact right behavior!
Sure, its "easy" if Microsoft wants to redefine Windows in POSIX terms; iits not easy to keep Windows functioning as Windows and provide a POSIX compatibility layer, since Windows isn't designed around POSIX expectations.
Do you actually have specifics, here? I'm happy to discuss things like how to model fork() in-kernel.
Which for everyone that has written code across UNIX systems knows it has quite some issues across systems that are supposed to share some kind of common architecture.
Even worse when the architecture is completely different.
Even worse when the architecture is completely different.
Is this not what midipix.org intends to do? Granted, they're nowhere near close to being finished at this point in time, but it would be great to see the project pick up steam in this space.
midipix looks awesome, but seems to be GPL (not LGPL). Does that mean anything using it must be GPL too? I think that would be unacceptable for such a low layer of the stack.
I don't know why you're being downvoted, but this is a legitimate concern for some businesses (well, legitimate may be too strong, but it is a concern a lot of legal departments will have).
After discussing this issue on #midipix on freenode, they had mentioned they will explore dual-licensing or some variant of such once the software is more stable and can be reliably deployed. In any case, the project is far too early in its infancy to start worrying about what license they might have.
After discussing this issue on #midipix on freenode, they had mentioned they will explore dual-licensing or some variant of such once the software is more stable and can be reliably deployed. In any case, the project is far too early in its infancy to start worrying about what license they might have.
Thanks for mentioning it. I check their website occasionally and hope that it'll be a reliable and sustainable alternative.
We have enough POSIX to go round, I think. No need for any more ;)
[deleted]
and I'm just here still using UnxUtils :D
no installation needed too
Because people would build for that instead of Win32.
That is a valid concern. On the other hand, win32 has a strong developer community with 20+ years of legacy as the primary API of Windows. Now only if Microsoft hadn't try to screw its own developers by trying to push a new framework every 5 years.
It does but as you say due to the emperor's new clothes every few years, the loyalty isn't there now. I know of no companies doing greenfield desktop dev that are using any of their tech. It's all Qt, CEF, python/wx and JavaFX. Even the financial companies we deal with who were pretty heavy with the WPF are canning it next cycle.
Incumbent MFC, Winforms and WPF stuff will live as long as VB6 did (and still does) though.
Edit as HN won't let me reply (submitting too fast). In Europe and JavaFX also has hardware acceleration as does CEF as it uses Chrome's rendering engine.
Incumbent MFC, Winforms and WPF stuff will live as long as VB6 did (and still does) though.
Edit as HN won't let me reply (submitting too fast). In Europe and JavaFX also has hardware acceleration as does CEF as it uses Chrome's rendering engine.
That's interesting.
>> Even the financial companies we deal with who were pretty heavy with the WPF are canning it next cycle.
Where are you based? What are they planning to adopt?
My company is consulting a couple of hedge funds in New York and they have no plans of replacing WPF for their trading apps.
The desktop CLR VM plus proper GPU acceleration makes WPF faster than any alternative (when avoiding binding). As far as I'm aware no other UI toolkit comes anywhere close.
>> Even the financial companies we deal with who were pretty heavy with the WPF are canning it next cycle.
Where are you based? What are they planning to adopt?
My company is consulting a couple of hedge funds in New York and they have no plans of replacing WPF for their trading apps.
The desktop CLR VM plus proper GPU acceleration makes WPF faster than any alternative (when avoiding binding). As far as I'm aware no other UI toolkit comes anywhere close.
> Edit as HN won't let me reply
But it does, it just hides the link. All you have to do is to go to the child's comment by clicking the time link, then you'll get a reply box. In your case the comment you probably want to reply to is this: https://news.ycombinator.com/item?id=10416018
But it does, it just hides the link. All you have to do is to go to the child's comment by clicking the time link, then you'll get a reply box. In your case the comment you probably want to reply to is this: https://news.ycombinator.com/item?id=10416018
ssssh! There is a reason the system is as it is...
Will this OpenSSH server be able to run interactive console programs (like cmd.exe or python.exe), or will it be limited to (say) PowerShell?
Windows doesn't have a good API for hosting a console--it's not like Unix, where a pty has a master end and a slave end. Trying to run a console program in mintty.exe (https://github.com/mintty/mintty/issues/56) or Cygwin SSHD fails for this reason. I wrote a tool, winpty, that makes a best-effort attempt to emulate a Unix pty master by scraping the console buffer, but it has some limitations, so I'm not sure Microsoft would want to use it. Maybe they would expand the console API?
Windows doesn't have a good API for hosting a console--it's not like Unix, where a pty has a master end and a slave end. Trying to run a console program in mintty.exe (https://github.com/mintty/mintty/issues/56) or Cygwin SSHD fails for this reason. I wrote a tool, winpty, that makes a best-effort attempt to emulate a Unix pty master by scraping the console buffer, but it has some limitations, so I'm not sure Microsoft would want to use it. Maybe they would expand the console API?
I too was very skeptical. Something about posts from "The Powershell Team" about porting sshd makes me deeply cynical that they would get the integration right from a layering perspective, i.e. as if they would make it support powershell and nothing else.
Fortunately this example shows it going straight into cmd and then they invoke powershell as a next step:
That gives me some hope that it's being done right.
Fortunately this example shows it going straight into cmd and then they invoke powershell as a next step:
C:\Master>ssh.exe -l [email protected]
[email protected]'s password: **********
Microsoft Windows [Version 10.0.10566]
(c) 2016 Microsoft Corporation. All rights reserved.
user@DEV-10566-829 C:\Users\user>powershell -File -
That gives me some hope that it's being done right.
There are these two interesting commits, "Add pty mode support code":
https://github.com/PowerShell/Win32-OpenSSH/commit/55f2ec682...
and "Add ANSI parsing engine and console draw support to SSH client":
https://github.com/PowerShell/Win32-OpenSSH/commit/7aac59e52...
Something about this reminds me of ANSI.SYS.
https://github.com/PowerShell/Win32-OpenSSH/commit/55f2ec682...
and "Add ANSI parsing engine and console draw support to SSH client":
https://github.com/PowerShell/Win32-OpenSSH/commit/7aac59e52...
Something about this reminds me of ANSI.SYS.
you could run ANSI.sys in modern cmd.exe, sadly there's no ANSI.sys in Win7 anymore.
https://groups.google.com/forum/#!topic/alt.msdos.batch.nt/Y...
https://groups.google.com/forum/#!topic/alt.msdos.batch.nt/Y...
Cool. Looks like that is essentially listing DEVICE=ANSI.SYS in config.nt? Google results imply some things about 16-bit emulation here -- was that post about running actual DOS ANSI.SYS in a VDM running actual DOS COMMAND.COM, within a native Windows terminal?
IIRC, the command.com only bootstrap the ANSI coloring, after that you can run anything in cmd.exe
> Will this OpenSSH server be able to run interactive console programs
I would think so. Anything less would not be a real SSH server.
I would think so. Anything less would not be a real SSH server.
Never was much of a windows fan, so a (slightly ignorant) question for someone who is a Win admin - can most administrative things nowadays be done via the command line on Windows (like we've been able to do in *nix land) or is there a gap between what can be done via the GUI vs the command line?
From a sysadmin in the field - it's complicated.
New Server features are primarily controllable via PowerShell and now only secondarily expose a bit of control via GUI. So, indeed PowerShell has taken precedence. However, it would be wrong to say that Windows administration is exactly like managing Unix systems. On the contrary, the more one works with it the more one realizes PowerShell is the anti-Bash.
Lacking in the aeons of interface legacy built into standard Unices, you won't find standbys like 'grep' readily available or even easily implemented. Rather, PowerShell is built from the ground up for scripting. While the addition of SSH will certainly be helpful for quickly checking statuses, (and possibly more in the future should readline usability of PowerShell improve) right now most PowerShell interactions happen via scripting from a local workstation or web or application inputs rather than directly via the interactive shell.
New Server features are primarily controllable via PowerShell and now only secondarily expose a bit of control via GUI. So, indeed PowerShell has taken precedence. However, it would be wrong to say that Windows administration is exactly like managing Unix systems. On the contrary, the more one works with it the more one realizes PowerShell is the anti-Bash.
Lacking in the aeons of interface legacy built into standard Unices, you won't find standbys like 'grep' readily available or even easily implemented. Rather, PowerShell is built from the ground up for scripting. While the addition of SSH will certainly be helpful for quickly checking statuses, (and possibly more in the future should readline usability of PowerShell improve) right now most PowerShell interactions happen via scripting from a local workstation or web or application inputs rather than directly via the interactive shell.
Microsoft are pushing the command line to the point that:
a) Many operations in newer bits of Windows have simple-mode available in the GUI, but more sophisticated options must be scripted. StorageSpaces has a few examples of this, where some of the options around tiered storage, SSD caching, and the layout of pools can only be accessed via posh.
b) Microsoft are pushing completely headless versions of Windows Server for 2016.
a) Many operations in newer bits of Windows have simple-mode available in the GUI, but more sophisticated options must be scripted. StorageSpaces has a few examples of this, where some of the options around tiered storage, SSD caching, and the layout of pools can only be accessed via posh.
b) Microsoft are pushing completely headless versions of Windows Server for 2016.
About headless version , it is so great to hear that , although I am not using windows , but hearing that is good news overall , it seems with new CEO Microsoft back on truck .
I would not remember with ballmer they released windows server with Metro UI . WTF !
Yep. Recent windows servers even default to boot straight to console these days, with none of the GUI services running. MS has realized that centralized deployment and maintenance is really useful and is acting accordingly, hence things like openssh for windows.
(From what I've heard from people using them) On the current server versions, PowerShell should allow to do all that the GUI can do. There is a GUI-less version and I think the GUI actually uses PowerShell underneath, so you can look up in a log how the commands look like for something you only knew how to do graphically before.
That is so cool. I have to look into this...
This is very goddamned awesome. All I hope is I can set the default user shell for my account. I already use msys2's zsh for my shell (because I use zsh everywhere, on all OS), and being able to ssh into my Windows machine 'normally' (for me, anyways) would be extremely useful.
I suggest making Update update, ie lower case, I was confused as to why Windows Update was getting ssh
Or perhaps even "Update on OpenSSH for Windows", which eliminates that ambiguous structure and maintains headline capitalization.
I thought standard title rules were every word other than words like 'and' and 'is' were capitalized.
I don't believe there is a hard rule for titles that should take precedence over clarity.
The more things change..., from:
https://github.com/PowerShell/Win32-OpenSSH/wiki/Deploy-Win3...
"If you need key-based authentication:
Install key-auth package
run setup-ssh-lsa.cmd
reboot"
Reboot?
And this gem: "SSH daemon needs to run as System to support key-based authentication".
Which means, either use weak authentication, or run the daemon as system. I don't even understand why, it's not like the public keys are particularly sensitive (certainly much less sensitive than being able to check passwords for validity)?
https://github.com/PowerShell/Win32-OpenSSH/wiki/Deploy-Win3...
"If you need key-based authentication:
Install key-auth package
run setup-ssh-lsa.cmd
reboot"
Reboot?
And this gem: "SSH daemon needs to run as System to support key-based authentication".
Which means, either use weak authentication, or run the daemon as system. I don't even understand why, it's not like the public keys are particularly sensitive (certainly much less sensitive than being able to check passwords for validity)?
Have you checked what user OpenSSH usually runs as on a linux machine in order to allow key-based authentication? I'll give you a hint: it's root. That's no different than running as SYSTEM on Windows.
As a sibling comment mentioned, it makes perfect sense that the ability to create a user session requires a certain privilege. What struck me as odd, was that it only needed this on Windows when using key-based authentication - not when allowing password-based login.
AFAIK ssh needs access to /etc/shadow on Linux, if you want to use system passwords. But also, AFAIK, nothing stops you from running ssh in a chroot, without any such access (well, access to a /etc/shadow under the chroot probably).
AFAIK ssh needs access to /etc/shadow on Linux, if you want to use system passwords. But also, AFAIK, nothing stops you from running ssh in a chroot, without any such access (well, access to a /etc/shadow under the chroot probably).
Regarding System User: https://github.com/PowerShell/Win32-OpenSSH/issues/2, it needs that right to generate user tokens
Thank you for that. It makes a certain kind of sense, that impersonating a user/creating user sessions requires a high privilege. I think I'd still be more happy with it running as a low privilege user allowing log-in as "nobody"/"guest" and then elevating to a user with login/pw via "runas" or equivalent.
I can see how the only way to login directly to a certain user id would either require ssh to run as that user id or as System.
I can see how the only way to login directly to a certain user id would either require ssh to run as that user id or as System.
That is the crux of it. Windows is not going to fundamentally change its authentication system to work around SSH. It's going to feel "hacky" compared to SSH on *NIX (also console interactivity). You'll still need to run Windows updates as a scheduled task as the system user because remote connections have a remote token and the Window Update API blocks such connections...
Very off topic - I thought that publically was a mis-spelling, but apparently it may be acceptable now!
http://english.stackexchange.com/questions/45136/difference-...
http://english.stackexchange.com/questions/45136/difference-...
For those interested the source code is here: https://github.com/PowerShell/Win32-OpenSSH/
I am waiting the moment when I can throw away WinRM and SSH to all the servers.
You have to create a god damn scheduled task to do Windows Updates over WinRM. And it takes ages for Powershell to realise the task is running, and polling the status of the job is a PITA.
Took me days to automate Windows 2012 with Packer. Ugh
Took me days to automate Windows 2012 with Packer. Ugh
For others facing a similar situation, I very strongly recommend starting here instead of DIY. :-)
https://github.com/joefitzgerald/packer-windows
https://github.com/joefitzgerald/packer-windows
> You have to create a god damn scheduled task to do Windows Updates over WinRM.
Aha. That must be why I could never get updates working with Packer/WinRM. It would take a very long time to do a huge amount of work then end up never quite finishing properly.
> And it takes ages for Powershell to realise the task is running, and polling the status of the job is a PITA.
OK, so not really a proper solution then. Oh well.
Aha. That must be why I could never get updates working with Packer/WinRM. It would take a very long time to do a huge amount of work then end up never quite finishing properly.
> And it takes ages for Powershell to realise the task is running, and polling the status of the job is a PITA.
OK, so not really a proper solution then. Oh well.
Hell yes. Watching packer shit a brick 5 times a day trying to upload virtualbox guest additions via WinRM makes me want this yesterday.
Also I had to up the memory ceiling on WinRM to 800Mb (WTF!) to even get it to complete.
Also I had to up the memory ceiling on WinRM to 800Mb (WTF!) to even get it to complete.
It really is surprisingly bad, isn't it? I recently was involved in a continuous deployment system targeting Windows. We simply couldn't get WinRM to reliably upload fast and ended up installing SSH everywhere.
Having worked on that code (in Packer) - the WinRM protocol is completely unsuitable for use as an SCP replacement. It's amazing it works at all even for small files! The actual "winrmcp" implementation is here https://github.com/packer-community/winrmcp if you're interested in the inner workings.
OK, but that code (cp.go) uploads base64 chunks of 8K and echo's them to a file and decodes when done. That surely isn't the real WinRM file copy implementation right?
Well... I just went looking for how it's implemented and holy shit I don't think they considered this case. Top results say "use a file share". Wow. I feel less inadequate.
Well... I just went looking for how it's implemented and holy shit I don't think they considered this case. Top results say "use a file share". Wow. I feel less inadequate.
Yep that's horrible whatever the basis for it is.
Oh wow that's just horrible. I wish I hadn't looked now!
Yep definitely the worst thing ever. Not just that though; everything. I've lost so much hair in the last few months over trying to get a CD environment up on windows.
This. Everything about Windows and automation just feels like Bill & co really hates you personally, hates your company, and even the air you breath
I can't help but nod knowingly :)
I was so keen for WinRM support to land in Packer so I could avoid installing cygwin.
It was out of the frying pan and into the fire.
Native Windows SSH should _hopefully_ solve all this hassle.
I was so keen for WinRM support to land in Packer so I could avoid installing cygwin.
It was out of the frying pan and into the fire.
Native Windows SSH should _hopefully_ solve all this hassle.
This, so much. The current "endpoint bindings" are really aggravating to deal with, the slow speed... I can't wait! :-)
I'm interested in how this is going to work in PowerShell with the way everything works now, if there happen to be any details about that (whether here, somewhere else, or a past link)?
I don't know anything about PowerShell, but I have a similar question, I think: how is this going to work? Will I be able to do something like this command line (from my *nix machine)?
ssh [email protected] dir d: | lessYou should be able to do that just fine. 'dir d:' runs on the windows box and 'less' on the unix box.
Excellent. That's very useful!
This is a key thing I'm curious about. How is drive mapping handled? If I "net use d: \\host\share" from one session, it won't nessarily translate and mount D: to all sessions (or will it)?
I can't check right now, but if you have two local users, Delta and Gamma, and Gamma mounts D:\, does Delta see it or is it specific to Gamma's session?
Mapped network drives are for each user separately. Actually, they are even different for the limited administrator token and the elevated one (e.g. if I run something as administrator here I won't see my mapped network drives, but instead have to use UNC paths).
Drive letter mappings differ even between Delta and when Delta opens a command prompt as administrator.
[deleted]
It would be good if there was a good free terminal for Windows. The only option is putty.
Check out MobaXTerm:
http://mobaxterm.mobatek.net/
I don't work for them, I just think it's a nice tool, so much so I paid for the Pro version.
http://mobaxterm.mobatek.net/
I don't work for them, I just think it's a nice tool, so much so I paid for the Pro version.
It's not the best butt it's better than the others. You can always enhance putty features using MTPuTTY http://ttyplus.com/multi-tabbed-putty/ worth trying
mintty is excellent. I also find ConsoleZ works well for running cmd.exe but it's not fully xterm compatible like mintty.
This is exciting to hear.
I might be overly nitpicky, but holy inconsistent coding styles Batman: compare https://github.com/PowerShell/Win32-OpenSSH/blob/bafc1df7c5c... to the other source files.
I might be overly nitpicky, but holy inconsistent coding styles Batman: compare https://github.com/PowerShell/Win32-OpenSSH/blob/bafc1df7c5c... to the other source files.
Ugh. And calling strcpy() with user-supplied data inside a SSP of all places... :-(
What's the plan for supporting OpenSSH in the long run? Or is this just a one off port that will become stale after a few years?
I've been running OpenSSH on Windows servers for years, using Cygwin.
I'm a fan of Bitvise SSH for a Windows SSH server; it's been enough to replace Terminal Services when each employee has their own work machine to remote desktop into.
It's nice that Microsoft recognizes the need for this functionality; I wonder how they will approach the potential per-client licensing issues they like to bring up with their server OS's.
https://www.bitvise.com/ssh-server
It's nice that Microsoft recognizes the need for this functionality; I wonder how they will approach the potential per-client licensing issues they like to bring up with their server OS's.
https://www.bitvise.com/ssh-server
Out of curiosity...why run this as a service?
EDIT: I misread this and though it was only a client. Geez. If it's a server, then of course it should be a service.
EDIT: I misread this and though it was only a client. Geez. If it's a server, then of course it should be a service.
So that you can ssh into a machine without manually starting sshd (or ssh-service) first.
Probably so that it can keep running even if no user account is logged in.
sshd on unix runs as a daemon, similar to a windows service.
A great openssh for windows for the time being. Being using this and it is great, only thing is not able to do powershell from it once connected to host.
http://www.mls-software.com/opensshd.html#botpage
http://www.mls-software.com/opensshd.html#botpage
I have had really good luck with this open source, native windows, ssh server.
http://www.kpym.com/2/kpym/index.htm
I have no affiliation with the project, i just thought i'd mention that it is a nice alternative i found.
Blargh. Another OSS project that doesn't expose any kind of version control (7zip is the worst offender). I know, gift horse etc etc but it does make it hard to track the history / future of the project.
Also looks like it hasn't been updated since 2011.
Also looks like it hasn't been updated since 2011.
Why does this support telnet? Just seems crazy to me. Is it on by default? That would be a violation of any sane security policy pretty much anywhere. Seems like a serious edge case requirement and odd to bundle with SSH. This is like buying a new car but then having the dealer give you a free horse with your purchase.
Telnet has the unique advantage of having an implementation for the opposite part on any TCP/IP compatible system without external libraries, crypto etc. and that you can recreate both a server and a client in literally an hour with nothing but a C compiler and an ordinary libc.
That is great, i have tried some ssh servers for windows they have all been constantly crashing or not working with ssh keys.
Cool. Looks like Userify.com (SSH Key management) will support yet another platform sometime next year.
(disclaimer: I work there.)
(disclaimer: I work there.)
Interesting, they're still using MinGW. I wonder if they'll ever get it to build under MSVC?
[deleted]
That's a good engineering project. Lucky team working on it!
[deleted]
[deleted]
The comment submit button doesn't even work in Safari. That must have taken some effort to break.
Was wondering about that. I'm surprised the OpenBSD team is accepting the commits - something so fundamental and Windows specific doesn't seem like their kind of thing - but great!
PS. If you're coming from a Unix background and interested in learning posh: https://certsimple.com/rosetta-stone