Back then they didn’t really understand the point of ssh though. They had a vision of remote management via .net RPC and powershell.
SSH is an awesome tool & capability as a relatively high level network channel. The defacto “shell” approach leads to a lot of problems when used as a management device. It encourages adhoc, unstructured, and opaque changes. Managing your hosts via Secure Shell simply leads to bespoke, unrepeatable, outcomes and crushing debt.
Moving to a well structered, repeatable, management paradigm is the only way to survive large or long term deployments. I see “systems configuration” and “orchestration” as the most common ways to achieve that. Personally Ive been trying to move linux/bsd host management off of SSH for 10 years now. I will be very very happy when SSH shell instantiations approach zero per day.
Sometimes you just have to give people the candy they want - even if its not good for them.
Isn't this an anti-pattern considering the cloud tenants of treating machines as cattle not pets?
SSH and Remote Desktop solve a different problem. It may not be the one you have - but some of us just need to log into the machine because we have needs that don’t fit into some predefined workflow. Or we have so few boxes it’s not worth it.
Consider SSHing into a large build machine for compiling as an example.
SSH is not for management. SSH is for remote access. What people do with their remote access is not SSH's concern. Ad-hoc management is just as possible and easy via RSAT and PowerShell. Hell, I've seen management via ansible devolve into a mess of unmaintainable, unrepeatable script heap.
> Moving to a well structered, repeatable, management paradigm is the only way to survive large or long term deployments.
And how would such a paradigm remotely access the machines? The tool I use uses SSH for:
1. Running commands on remote machines, interactively & non-interactively;
2. Synchronising files on remote machines, via SFTP and Rsync;
3. Forwarding network ports to provide secure access to remote services, e.g. Redis.
Personally, I've been trying to move app deployment and debugging onto SSH in every team I've worked with, and I will be very happy when developers are able to treat a remote machine (development or production) as little more than just a well-managed local machine.
To answer your questions you probably have a dedicated on host agent. See MCollective or AWS SSM for examples Im familiar with. It doesnt really matter that the transport or message model is. Its more important that your actions are discrete, well modeled, with defined & structured inputs and outputs. Its also inportant that theres an intermediary so you can get the scope of control away relying on client and end hosts.
For #1 interactive is almost orthoganal. For #1 & #2 Its that you have structure, repeatability, validation, auditing, testability, etc. #3 again a transport problem, or similar.
For your last point my issue is if you treat dev and prod as similar change and access problems. The environment can certainly look or feel the same. But the output of dev should be discrete managed artifacts. If you need to do adhoc exploratory stuff on prod thats a good sign you lack control or valid synoptic model of your systems.
That said, we may be trying to solve different problems. I have lots of teams, more ICs, and many hosts. Getting from artifice to industry is important at some point.
Edit: go check out the mcollective demos to get an idea of how you can change the access/use model.
For Ansible users, Windows getting OpenSSH is a huge win, since we (presumably) will no longer have to jump through all the hoops WinRM throws you in order to configure Windows machines remotely.
SSH was originally intended to replace the aging unencrypted protocols that were used for remote access (telnet, rsh etc). It comes from a time when configuration management tools like ansible, puppet et all didn't exist, and most system management was ad-hoc, or done by home grown scripting. So it makes a sense that it behaves the same way as rsh for the most part.
WinRM (which this Microsoft implementation of OpenSSH will replace for most Ansible/UNIX users that are managing Windows systems) also allowed arbitrary command execution as well, so it was really no better.
As an outside observer, it really looked to me like Microsoft had their head in the clouds up until about 2011. It's like the whole decade between 2005-2015 for MS was about recognizing and coming to terms with the multiple "whole worlds out there" and getting past NIH syndrome.
An organisation large enough would have middle management and people who promote from within. And they are successful in one culture and it worked even for customers.
Then ...
The one place this didn’t apply was your choice of code editor. You could use whatever you wanted and that had long been tradition. I spent a lot of effort getting VIM to work only to realize it didn’t scale well to multi-million LOC code bases.
Really had nothing to do with the size of the file.
Passing serialised scriptblocks to the remote host, executing them, and getting serialized objects back. Meaning you can pass serialisable objects around, handle errors, the multiple output streams, etc. over the remoting connection.
Because it's integrated into the language, you can pull PowerShell modules over from the remote host to the local host automatically generating proxy stubs for them ("implicit remoting"). E.g. to manage and Exchange server you can remote to it, and bring the Exchange cmdlets back, and then import them locally as if they were a local module.
It's also able to do that and edit the proxies as it builds them for you, to allow and restrict what commands you get - based on your permissions and perhaps which tier of service you're paying for. And not just allow or restrict commands, but allow or restrict individual parameters on those commands, if desired.
That's fine in theory, except that some very common Windows Objects can't be serialized in any meaningful way (most painful one for me being the Windows Update Client), which means that certain "remote" operations are actually affecting the client machine, or are failing because the client lacks support for certain operations.
I've been using Powershell since v2, but to me, it's essentially a walled garden automation environment. Just one more way for Microsoft not to give you the tools to efficiently manage your fleet.
a) I think the normal use is something like SCCM or InTune to automate Windows Updates, not manually connecting to a machine and trying to script the Windows Update Client.
b) Microsoft built Azure Stack with PowerShell automation. Are you saying Microsoft refused to give themselves the tools to efficiently manage their own fleet? What tools even are these?
That’s why I can guarantee Remote Desktop has more usage than these remote rpc calls for ad-hoc work. Powershell is quite powerful but it’s features are more for programmers than users.
Because of its complexity RPC is not a replacement for ssh where you are typing commands directly to the remote machine.
This is partly why nobody developed proper open source Exchange clients: the Exchange protocol is MAPI over DCE/RPC, and you need to build a lot of infrastructure before it will even talk to you.
Samba still does amazing stuff on the directory RPC front.
A customer of mine fires up servers to run tasks on them. A few of those tasks are programs that unfortunately run only on Windows (the pain of updating those boxes!) I install ssh to be able to perform some basic operations on them and move files over sftp. Hopefully an integrated ssh server works better (issues with terminal, etc.)
I understand that this is not a scenario Microsoft would advocate in the past, but eventually Microsoft lost the war for servers so it's giving us interoperability tools now.