> Managing your hosts via Secure Shell simply leads to bespoke, unrepeatable, outcomes and crushing debt.

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.

I tried to distinguish between SSH the multiplexed secure network channel provider and Secure Shell, the default and overwhelmingly popular use case of SSH. Theyre different, but generally conflated. I have no real problem with the transport mechanism.

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.

They already had group policy for structured administration. What Windows was missing specifically was a non-GUI way for that unstructured "get in there and fix the problem" work flow. Structured workflows may well be better for you, but quick and dirty has a lot of appeal.

Sometimes you just have to give people the candy they want - even if its not good for them.

Group Policy can't manage Exchange, Active Directory, etc - prior to the introduction of Powershell you were at the mercy of what was provided with the RSAT and RDP for anything else.

> "get in there and fix the problem" work flow

Isn't this an anti-pattern considering the cloud tenants of treating machines as cattle not pets?

Windows had this problem much earlier with every employee getting a PC on their desk. They solved it with Group Policy and domains. That still works well.

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.

Cloud is irrelevant. Its scope and repeatable results. A decade ago I had these problems with owned facilities, owned hardware, and dedicated internal teams. But it was thousands of hosts, multiple datacenters, and thousands of internal users. My personal break point is/was “a few hundred” hosts. Below that bespoke management can scale at a reasonable human:resource ratio. Above that you need too many people, and then you cant control or inspect the rate of change or variance.

Where does your opinion on Ansible lie then? It's a systems configuration and orchestration tool that by default, uses SSH as the transport.

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.

See sibling. I dont have a problem witb using ssh as transport per se. Its using adhoc/bespoke Shell for introducing change. Its a bit unrelated but I, personally, lean more towards declarative than procedural and highly value intermediated access. Which doesnt quite match ansible afaik.

Right, so your issue is with shell access and using it for arbitrary systems changes then, and not SSH per se. You'd be just as annoyed if someone logged into a shell on the server via the console and started making unmanaged changes.

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.