Native “SSH” on Windows via WS-Management

Did you know that you can now SSH to a Windows machine over WS-Management and its is a documented protocol that can be implemented from any platform and programming language? This is big news to me and I am surprised that, as management protocol geek, I hadn’t heard about it until I started to search MSDN for a related but much smaller feature (file transfer over WS-Management).

OK, so it’s not exactly SSH but it is a remote shell. In fact it comes in two flavors, which I think of as “dumb SSH” and “super SSH”.

Dumb SSH

Dumb SSH is the ability to remotely run a DOS-like command shell over WS-Management. Anyone who has had to use the Windows command shell as a scripting language ersatz understands why I call it “dumb”. I expect that even in Microsoft most would agree (otherwise why would they have created PowerShell?).

Still, you can do quite a few basic things using the Windows command shell and being able to do them remotely is not something to sneer at if you’re building a management product. If you’re interested, you need to read MS-WSMV, the WS-Management Protocol Extensions for Windows Vista specification (available here as a PDF). By the name of the specification, I expected a laundry list of tweaks that the WS-Management and WS-CIM implementation in Vista makes on top of the standards (e.g. proprietary extensions, default values, unsupported features, etc). And there is plenty of that, in sections 3.1, 3.2 and 3.3. The kind of “this is my way” decisions that you’d come to expect from Microsoft on implementing standards. A bit frustrating when you know that they pretty much wrote the standard but at least it’s well documented. Plus, being one of those that forced a few changes in WS-Management between the Microsoft submission and the DMTF standard (under laments from Microsoft that “it’s too late to change Longhorn”) I am not really in position to complain that “Longhorn” (now Vista) indeed deviates from the standard.

But then we get to section 3.4 and we enter a new realm. These are not tweaks to WS-Management anymore. It’s a stateful tunneling protocol going over WS-Management, complete with base-64-encoded streams (stdin, stdout, stderr) and signals. It gives you all you need to run a remote command shell over WS-Management. In addition to the base Windows command shell, it also supports “custom remote shells”, which lets you leverage the tunneling mechanism for another protocol than the one made of Windows shell commands. For example, you could build an HTTP emulation over this on top of which you could run WS-Management on top of which… you know where this is going, don’t you?

A more serious example of such a “custom remote shell” is PowerShell, which takes us to…

Super SSH

Imagine SSH with the guarantee that the shell that you log into on the other side was a Python interpreter, complete with full access to the server’s management API. I think that would qualify as “super SSH”, at least for IT management purposes (no so exciting if all you want to do is check your email with mutt). This is equivalent to what you get when the remote shell invoked over WS-Management (or rather WS-Management plus Vista extensions described above) is PowerShell instead of the the Windows command shell. I have always liked PowerShell but it hasn’t really be all that relevant to me (other than as a design study) because of its ties to the Windows platform. Now, thanks to MS-PSRP, the PowerShell Remoting Protocol specification (PDF here) we are only a good Java (or Python, or Ruby) library away from being able to invoke PowerShell commands from any language, anywhere.

I have criticized over-reliance on libraries to shield developers from XML for task that really would be much better handled by simply learning to use XML. But in this case we really need a library because there is quite a bit of work involved in this protocol, most of which has nothing to do with XML. We have to fragment/defragment packets, compress/decompress messages, not to mention the security aspects. At this point you may question what the value of doing all this on top of WS-Management is, for which I respectfully redirect you to your local Microsoft technology evangelist, MVP or, in last resort, sales representative.

Even if PowerShell is not your scripting language of choice, you can at least use it to create a bootstrap mechanism that will install whatever execution engine you want (e.g. Ruby) and download scripts from your management server. At which point you can sign out of PowerShell. For some reason, I get the feeling that we just got one step closer to Puppet managing Windows machines.

A few closing comments

First, while the MS-WSMV part that lets you run a basic command shell seems already available (Vista SP1, Win2K3R2, Win2K8, etc), the PowerShell part is a lot greener. The MS-PSRP specification is marked “preliminary” and the supported platform list only contains Windows 7 and Win2K8R2. Nevertheless, the word from Microsoft is that they have the intention to make this available on XP and above shortly after Windows 7 comes out. Let’s hope this is the case, otherwise this technology will remain largely irrelevant for years to come.

The other caveat comes from the standard angle. In this post, I only concern myself with the technical aspects. If you want to implement these specifications you have to also take into account that they are proprietary specifications with no IP grant (“Microsoft has patents that may cover your implementations of the technologies described in the Open Specifications. Neither this notice nor Microsoft’s delivery of the documentation grants any licenses under those or any other Microsoft patents”) and fully controlled by Microsoft (who could radically change or kill them tomorrow). As to whether Microsoft plans to eventually standardize them, I would again refer you to your friendly local Microsoft representative. I can just predict, based on the content of the specification, that it would make for some interesting debates in the DMTF (or wherever they may go).

This is a big step towards the citizenship of Windows machines in an automated datacenter (and, incidentally, an endorsement for the “these scripts have to grow up” approach to automation). As Windows comes to parity with Unix in remote scripting abilities, the only question remaining (well, in addition to the pesky license) will be “why another mechanism”. Which could be solved either via standardization of MS-PSRP, de-facto adoption (PowerShell on Suse Linux is only one Microsoft-to-Novell check away) or simply using PowerShell as just a bootstrapping mechanism for Puppet or others, as mentioned above.

[UPDATE: On a related topic, these two posts describe ways to transfer files over WS-Management.]

8 Comments

Filed under Automation, DMTF, Everything, Implementation, IT Systems Mgmt, Manageability, Mgmt integration, Microsoft, Portability, Specs, Standards, WS-Management

8 Responses to Native “SSH” on Windows via WS-Management

  1. Its curious and unfortunate that you’ve mis-used the name “SSH” here. That is not even close to what this is.

  2. Lance,

    I’ll admit that the first paragraph is a bit exaggerated, as an attention grabber. But I clarify this right away at the start of the second paragraph (“OK, so it’s not exactly SSH”).

    The point here is that from the point of view of IT management people (readers of this blog), it does what we use SSH for. Today, we connect over SSH to drop scripts and execute them. I understand that there are many other usages of SSH (I mention checking email using mutt in the blog) for which this is not all that useful (emacs, irc, etc are other examples). Clearly, this is a management API, not something as generic and flexible as SSH. Maybe it would be more appropriate to compare it to JMX on steroids (JMX which, BTW, can also run on top of WS-Management). And I am sure that aspect will come up if/when time comes for standardization of the protocol.

    But the fact remain that, in the IT management community, there are lots of things commonly done with Unix boxes using SSH that you can’t do on Windows (at least not natively) and this protocol will provide a native alternative on Windows. In that respect, it is SSH-like for us IT management monkeys.

  3. Pingback: William Vambenepe’s blog » Blog Archive » Whose ******* idea was this?

  4. Pingback: SSH nativo en Windows « El camello, el León y el niño. O la evolución del perro al lobo.

  5. Pingback: William Vambenepe’s blog » Blog Archive » Uploading a file to a Windows machine via WMI/WS-Management

  6. Pingback: William Vambenepe’s blog » Blog Archive » REST in practice for IT and Cloud management (part 1: Cloud APIs)

  7. Erich

    William,

    I respectfully submit the following:

    1. ssh the protocol allows for everything you have described above and more. Look at the paramiko ssh library for python, you can do everything described above, and more.

    2. there is no mention of security here, and this is the biggest feature of ssh. Does this ws management stuff allow me to have a cryptographically secure channel to the remote host? does it do key verification? does it allow for secure authenication chaining (that is i can log into host a, then log into host b from a, without host b ever seeing my private key)?

    3. The command line ssh client does not do some of the stuff you describe, i’ll concede that, however it may not be the job of the ssh client to ensure the remote host’s environment.

  8. Hi Erich,

    Thanks for the comment. Here are my responses:

    On (1): yes I know but you can’t SSH to most Windows machines, unless you’ve installed a listener there ahead of time. The point of my post is not to tell people to use WS-Management instead of SSH. It’s to tell them that they can use WS-Management when SSH is not an option.

    On (2): I didn’t touch on security, but the spec provide a list of profiles that you can choose from. See http://msdn.microsoft.com/en-us/library/cc251749%28PROT.10%29.aspx

    On (3): Yes, this is different from SSH in the sense that it only gives you access to one runtime. Which has pros (consistency) and cons (you have to use PowerShell). They are not quite the same beast.

    Another major drawback of what I describe is that it is pretty new and not widely available in the Windows environments out there.