3 ms·
> 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.
by pritambaral 8y ago
> 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.
- donavanm 8y agoI 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.