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.

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.

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.