Hacker News Reader

Comment by pjs_ | Hacker News Reader

Drives me nuts that somewhere along the devops journey people decided that SSHing into a private server used for internal tools is an antiquated and outrageous thing to expect. People for some reason are actually excited about the prospect -- "we're gonna make it so you never have to SSH!". Little do they know that I like SSH. A lot more than I like clicking on the AWS console. And then somehow we're expected to debug the bastard using logz.io or similar -- unconscionable to me but maybe I'm old

View on HN

Not wanting to use SSH has nothing to do with not liking it. It's about getting your infrastructure to a state where everything you need to manage and troubleshoot it can be done _without_ SSH. This doesn't mean replacing it with click-ops, but having robust deployment and automation in place, an external and centralized log/metrics store, and everything else that minimizes the need to manually manage it at all.

Additionally, removing SSH means removing a large security risk, the need to create and rotate keys, and all the associated mess that we take for granted. It's a huge operational and security burden.

Doesn't it just move the targets?

We also have to deal with ridiculously complex permissions structures in cloud dashboards. This is also an operational burden, and certainly a security burden if you get it wrong...

The idea is to reduce the burden and simplify operations. You likely already need cloud dashboards for other things, and you really can't avoid that. You also can't remove SSH without improving automation, but once you do, you'll realize you simply don't need SSH at all.

A sibling comment mentioned cattle vs pets, which is related to this. If servers are not valuable, can be quickly recreated, and the infrastructure is self-healing, that means that you've done all the hard work, and don't need SSH for taking care of your pets.

I think the use of IDEs really made this practice less simple. Terminal mode emacs and vi/m are simple with SSH, VSCode and other things start getting more complex.

I think the extensions to VSCode and others to run remotely with a browser are starting to bring some of this back into fashion.

Connecting over SSH with VSCode is the most convenient SSH experience I've ever had: VSCode runs locally, connects via SSH and makes it feel like I'm working locally. I can edit files, open terminals, run software, etc. It's like running vim, a couple terminals and a scp file manager, but with the convenience of a desktop application

Technically you need an extension (Remote - SSH) but I think that's installed by default. It runs some remote code on the server to make it more seamless, but that has never gotten in the way.

Unless something has changed, VSCode runs in a server / client model with the FE on your local machine and the code / language servers running remotely (I don't use it, I stick to neovim).

VScode has connect to remote server via ssh mode built in, and there's an extension to use a docker container on the server, making it pretty easy to provision dev environments for new developers.

only if you are developing on a remote server which I never do.

I do use GUI text editors, file browsers and other tools that work over SSH.

some of us have the misfortune of having to use wsl…

Completely agree that ssh is simpler than clicking on a web console.

A good reason for not relying on ssh is 'cattle vs pets'--using ssh administration can make snowflakes where changes aren't tracked and diagnosable/reproducible. With versioned deployment of system changes you always know how things got to be and can configure many to be the same.

I find it a lot easier to manage a single Linux server than multiple AWS services and a separate third party service for every single thing. Stuff built on top of AWS like Heroku is even worse.

The problem is that a lot of people are now just not comfortable running things in-house. Subscribing to another service and adding an integration feels like the safe option.

That’s not always practical for performance or availability reasons.

I am mostly thinking of circumstances where a single server would provide equal or better performance and availability than AWS.

where it would not, you can run multiple redundant servers (although that may mean more work)

I think it's because a lot of people don't actually know how to get full use out of a terminal. When you have to manually enter ssh commands and credentials every single time, browser-based solutions become very attractive.

it's just a bit sad that there was never a proper port knocking protocol established, which had features and was provably secure in theory and implementation, than no one would have issues de/activating ssh per on need-basis

Reply on news.ycombinator.com