Comment by Someone1234 | Hacker News Reader

Comment by Someone1234 | Hacker News Reader

Microsoft has a real hole in their stack in my opinion...

So on Linux you have SSH (for shell) and X11 Forwarding/VNC for GUI remoting. On Windows you have RDP for GUI and nothing for remote shell.

Now, I know what you're going to say, "WMI" but WMI was never designed for use over the internet. You have to forward two fixed ports and a dynamic range (shudder). Plus it isn't security hardened either by design or through fire.

VPN you say? In theory yes. But the reality on the ground is that for most SMBs they're still using RDP or SSH directly to manage Windows/Linux servers, and if Windows wants to compete (and they are dropping RDP) they need to have an "answer" to SSH.

Essentially they need to take whatever WMI is, wrap it into a secure protocol, and bind it to just a single port, then harden the heck out of whatever process directly runs on that port (before you hit the WMI interface itself).

Or alternatively write an SSH server (literally), and after login redirect input to a Powershell process. Nobody would complain about that (plus free SFTP support!).

PS - I'm totally going to get attacked by "VPN purists" here. But really everyone knows that SSH and RDP is extremely common for SMBs/private individuals. Let's quit pretending that it is not and support the client that actually exists, not the client you wished existed.

You are ignoring Windows Remote Management, Microsofts implementation of the WBEM standard protocol for remote management of devices.

https://msdn.microsoft.com/en-us/library/aa384426(v=vs.85).a...

"Windows Remote Management (WinRM) is the Microsoft implementation of WS-Management Protocol, a standard Simple Object Access Protocol (SOAP)-based, firewall-friendly protocol that allows hardware and operating systems, from different vendors, to interoperate. The WS-Management protocol specification provides a common way for systems to access and exchange management information across an IT infrastructure. WinRM and Intelligent Platform Management Interface (IPMI), along with the Event Collector are components of the Windows Hardware Management features."

Have you ever tried using wsman? It is not fun.

And, being SOAP-based, it's certainly nothing like a command-line.

But most of all, it's not fun.

I've used winrm for some VM config scripts. The ps script would clone a VM from a base image, boot it, then remote into it to config network and other things.

It was a bit arcane to set up but mainly it was slow, like, really slow. All the SOAP serialization is terrible for performance but it is flexible and it did work.

I'm not a ssh expert (I live in the MS world), but powershell remote sessions (PSSession) seems like what you are talking about here... it's like running in a powershell window on a remote machine.

I'm not too confident powershell is really good enough to compete with the ancient unix shell. I've tried using it to automate windows machines, but it's certainly not a smooth experience.

Part of that is the lack of a history of automation - basic things to do with processes and I/O are kind of schizophrenic. All of the basics are clearly unix inspired (standard streams, processes, redirection - this is all unix-like), but many windows tools use different conventions to exchange data and control channels - powershell has a real object model.

In principle powershell's richer object model is a boon to automation - it's so much easier not to make mistakes if you don't need to massage your data through lots of slightly different text-based hacks, but the object model just isn't nearly pervasive enough. Sometimes you still need plain text/binary streams, and the transition isn't great. More fundamentally, the object model isn't well thought out - it's built on .NET, but that's clearly a single-process focused world view, and for a inter-process management tool, that poses problems. Even if sending objects between processes would work smoothly, there's the issue that objects don't compose or reflect as smoothly as text. It's hard to put your finger on, but for example, you can use things like regex's to do fairly fancy pattern matching on strings, and the equivalent for objects just isn't there in powershell. As a result, things work great if you're doing something that the underlying processes "want" you to do - but if you're trying to hack around some limitation, or try something novel, it's much more painful than in bash.

I think it's also worth mentioning some practical problems: Powershell is really slow and heavy. You can cheaply pipe and juggle data in a unix shell, but by doing that in powershell I've seen machines grind to a halt. A fresh powershell instance has a working set of 100MB on my machine; bash: 5MB. That's a problem. Startup time, similarly, is slow. This isn't a problem if you're working purely interactively - no human is going to notice an extra 10ms here or there, but in scripting, you can easily start so many processes that the difference becomes very noticable.

Powershell isn't terrible, but it just doesn't work as well as the unix shell, despite all the warts that has. Maybe some day everything will speak powershell, and it'll faster, smaller, and have a better story concerning pattern matching, but right now it's relatively ineffective compared to a plain unix shell, in my experience (which is windows centric).

Agreed on most of your points... PowerShell is by far the most powerful shell I've ever worked with on any platform... that said, I don't like it. It's very verbose.

As a JS guy, these days most of my scripts run via node/iojs and are as platform agnostic as possible. More and more I know it only needs to run in linux, or is guiding dockerization. Even then, bash scripts tend to be easier to reason about.

You could always write JScript. Ha ha ha!

http://blog.idleworx.com/2010/01/windows-scripting-host-and-...

I've seen a few open-source projects actually use this. (IIRC, it was WiX)

Actually, I did do a bit of JScript WSH scripts back in the day, well before PowerShell was an option even. IT works relatively well... I even shoved some initial logic into a few of my node scripts for windows that would, if run from WSH relaunch themselves in node.

The biggest issue with JScript in general is probably the lack of open options for certain classes of COM controls, that and COM collections are a beast (the enumeration wrapper you need in JScript is horrible). JScript was my preference just the same back with Classic ASP scripts. Could re-use my logic client and server-side, which usually worked out pretty well... though almost everybody used VBScript, which usually meant in a project both engines were loaded on the server. The other issue was runtime initialization for every request meant you were somewhat limited, though for a couple hundred users on a system at once around 1999-2002, it wasn't bad.

PowerShell is far more usable than sh or even bash as a scripting language. It's more like perl or python were integrated into a nice little command processor, since you can use all the .net libs (though not without some irritating effort). The problem is the cmd host is garbage, the utilities aren't burned into people's brains like the unix ones are, and they have weird Windows specific issues, like not being able to fork off a subprocess.

A scripting language that can not fork off a subprocess does not sound particularly usable to me. Certainly not more usable than bash, which I find eminently usable.

bash gets a bad rap, because there's a ton of horrible shell scripts floating around. For some reason, when people write in bash, they decide that since it's not a "real" programming language, they don't need to take it seriously. They will UPPERCASE all variables (so ugly, and stems from lack of understanding - you're supposed to uppercase environment variables only), fail to make use of functions, fail to make use of variable scoping, invariably choose the worst available comparison tools ("["), fail to make use of appropriate utilities (which is particularly egregious, considering the fact that the utilities (coreutils, moreutils, etc.) are the API of shell programming).

This is rather unfortunate. Well written bash is efficient, and, dare I say it, can be elegant. Of course, there are nicer shells around - zsh comes to mind - but bash is fine.

For the sake of political correctness, I shouldn't say this, but I will say it regardless - Windows Powershell does not come close to the feature set or expressiveness that bash+the Linux userland can have in the hands of someone who knows what they're doing.

> A scripting language that can not fork off a subprocess does not sound particularly usable to me.

See Powershell's Start-Job[0] Get-Job[1] Remove-Job[2].

> Windows Powershell does not come close to the feature set or expressiveness that bash+the Linux userland can have in the hands of someone who knows what they're doing.

Well nobody can argue that Powershell doesn't have just under fifty years of back-catalogue. That's obviously a massive advantage and head start, as is the expertise that comes along with it.

As to the "expressiveness," I'd need to know more specifically what you're referring to to address that point.

[0] https://technet.microsoft.com/en-us/library/hh849698.aspx

[1] https://technet.microsoft.com/en-us/library/hh849693.aspx

[2] https://technet.microsoft.com/en-us/library/hh849742.aspx

> fail to make use of appropriate utilities (which is particularly egregious, considering the fact that the utilities (coreutils, moreutils, etc.) are the API of shell programming).

Some people avoid a lot of the things in the coreutils/moreutils toolbox because they need their shell scripts to be portable between *nix types, and not everything in there is POSIX compliant, even if you set POSIXLY_CORRECT, or even when it is, the syntax is different. I could go through the trouble of having the script check what type of system it's running on and then select the proper flags and syntax, or I could just write something that will work everywhere that might not take advantage of some "feature" found in coreutils.

> bash gets a bad rap, because there's a ton of horrible shell scripts floating around

I remember when this was the most common defense of VB :D

I recently tried to automate windows machines as well. You are spot on. Dealing with obscure objects requires you to make mock calls and try and reflect on the underlying types. With bash, you don't have types, just text, which allows you to think outside the box.

Powershell reeks of development with C# on Windows. You have specific function calls that can do very niche things such as convert an application to a virtual machine in IIS. The problem comes up when you are trying to do something novel or just out of the scope of what Microsoft thought up. Bash allows for those things by having separate and reusable components that do their one job well.

Get-Object and Set-Object don't work universally as advertised so you can't just write boilerplate and expect things to work. Instead, you have to google "how do I set up a virtual application?" or "how do I change bindings to an existing virtual application?" You'll get the job done, but you won't feel like you learned anything. I'm glad you wrote this up. It's been something that's been bothering me, but I was having difficulty verbalizing it.

I bet that C# would actually make a better scripting language than powershell - you can actually use most of .net easily (especially generics), and async support is a real boon in scripting. It's mostly missing a decent library to do practical process-glue stuff - the .NET `Process` is verbose, incomplete, and a minefield.

SSH access to PowerShell would be a game changer IMHO for Microsoft. Also, have you seen this? http://www.powershellserver.com/download/

You can have remote access to powershell...

I don't know if it exists the other way around or not, but it would be really nice if Windows had a built in SSH client as well. I can't tell you how many times I've been working on a client's Windows Server machine and needed to remote into a Linux server, but neither I nor they had access to download Putty.

Agreed... I generally wind up with git extensions everywhere which includes most of the gnu tools including ssh. The only down side is that ssh via windows command shell, even in conemu doesn't do ansi/drawing properly... never really investigated as I just try to avoid it all.

http://www.mls-software.com/opensshd.html

Are you aware that is already possible to remote login into a powershell session without any add-on on windows server? Just use Enter-PsSession -computername

PowerShell Server "gives users the power to securely manage Windows remotely through PowerShell from any standard SSH client"

Or you can just run OpenSSH (there are a few nicely packaged versions of it available for Windows) and use PowerShell as the shell. :-)

You can't. At least you couldn't the last time I tried. Powershell hangs in SSH.

I got your point. Manage windows boxes from non-windows stations.

http://www.powershellserver.com/

MS should really include something like this in Windows.

Hell, I (or you) should find the time and write it ourselves, node.js has great TLS support and has a Windows port.

> We are improving remote manageability via PowerShell with Desired State Configuration as well as remote file transfer, remote script authoring and remote debugging

Is PowerShell not what you're looking for, or is it not implemented similar to SSH?

Remote Powershell exists, but you don't have a great deal of control over the Powershell interface (like you would with an SSH daemon), if you want to "opt-in" users one by one for remote Powershell, well, you cannot.

Also setting it up to work over the internet securely is, a touch complicated: http://blogs.technet.com/b/askpfeplat/archive/2012/09/17/wan...

It is a cool party trick that it can work via a web-browser and IIS. But if that's what it takes to make Powershell remoting secure without a VPN then it isn't workable.

Just getting it to work with shell, and no web browser access is a lot simpler than that.

A few lines. See my reply at https://news.ycombinator.com/item?id=9343060

Powershell currently only runs on Windows. One can't use powershell remoting from a Mac OS or *nix machine. Until someone adds non-windows support for Powershell, they need to have a built-in ssh server that opens powershell as the shell. Btw, even if that does happen, it's still difficult to use PS. Any errors that occur in the remote environment get displayed as XML blobs on the client :(

PowerShell web access might be a good alternative: http://blogs.technet.com/b/askperf/archive/2012/11/05/window...

You don't need this. You just need Enter-PSSession [ipaddress], which allows you to interact with it like ssh. You need to enable powershell remoting first though.

Yes, but only if both PCs are in the same domain. Getting PowerShell remoting to work in other environments requires a lot of configuration.

That's not true. I had it working over the internet, separate domains with public/private certs fairly easily.

I'd be interested in how you set it up, can you maybe share it somewhere?

Guides like https://wprogramming.wordpress.com/2011/07/11/remote-pssessi... don't seem "fairly easy" to me (that's why I said it requires a lot more configuration compared to Enter-PSSession when both parties are in the same domain).

There's a lot of waffle in that. If you actually look at the commands his asking you to enter, it isn't that much.

It's essentially, Enable-PSRemoting

And commands 1 to 3 in the following guide after Enable-PSRemoting. Try to ignore the waffle. You probably do want to to disable HTTP though.

http://www.sirchristian.net/blog/2013/03/11/using-powershell...

Trying to get SSH to work with certs can involve just as much or more stuff than that.

Maybe i'll write a super simple guide, just listing the bare commands, since the documentation/tutorials for powershell seem non-existent despite being pretty powerful..

Sort of. Enter-PSSession is backed by http or https [1] and is not as good as ssh. You can interact with PowerShell, but you can't interact with command-line programs launched from PS.

[1] Grep for "http" on this page: http://ss64.com/ps/enter-pssession.html

Most stuff I use have PS cmdlets so its not really an issue with me.

If only that was cross platform like SSH is.

http://ss64.com/ps/enter-pssession.html

Reply on news.ycombinator.com