> Well, teach your sysadmin to use the system configuration tester when they edit a system configuration file.
Wrong. Teach your sysadmin not to overload a single service with different
functions (debugging channel, user-facing shell service, running remote
commands, file upload, and config distribution channel), especially not the
one that should not be used in batch mode, without human supervision.
When you write an application, you don't put a HTTP server in database
connection handling code, but when it comes to server management, suddenly the
very same approach is deemed brilliant, because you don't run an agent (which
is false, because you do, it's just not a dedicated agent).
Good heavens, no! You'd only have two different instances of the same service
that is difficult to work correctly with.
For serving as a debugging channel and user-facing shell access, SSH is fine
(though I've never seen it managed properly in the presence of nodes being
installed and reinstalled all the time). But for everything else (unattended):
* you don't want commands execution, port forwarding, or VPN in your file server
* you don't want remote shell in your daemon that runs parametrized procedures -- but you do want it not to break on quoting the arguments and call results (try passing shell wildcards through SSH)
* you don't want port forwarding and remote shell in config distribution channel; in fact, you want config distribution channel itself to be reconfigured as little as possible, so it should be a totally separate thing that has no other purpose whatsoever
* you don't want to maintain a human-user-like account ($HOME, shell, etc.) for any of the above, since they likely will never see a proper account on the server side; you want each of the services to have a dedicated UID in /etc/passwd, own configuration in /etc/$service, own data directory, and that's it
Each of the tasks above has a daemon that is much better at them than SSH. The
only redeeming quality of SSH is that it's there already, but it becomes
irrelevant when the server's expected life time gets longer than a few days.
Wrong. Teach your sysadmin not to overload a single service with different functions (debugging channel, user-facing shell service, running remote commands, file upload, and config distribution channel), especially not the one that should not be used in batch mode, without human supervision.
When you write an application, you don't put a HTTP server in database connection handling code, but when it comes to server management, suddenly the very same approach is deemed brilliant, because you don't run an agent (which is false, because you do, it's just not a dedicated agent).