Hi hacker news friends, welcome back.

Previous discussions if you're curious:

- https://news.ycombinator.com/item?id=8743374

- https://news.ycombinator.com/item?id=8828543

- https://news.ycombinator.com/item?id=11516582

- https://news.ycombinator.com/item?id=12217830

Don't let the haters get you down, come learn something and have a good time. Happy to answer questions if you have any.

While I agree with all the pros of SSH, the only issue for me is that you're spawning a remote shell which if not properly maintained / configure _could_ be a security risk, not because of ssh / key based authentication which are both great - but because you're one layer closer to the underlying OS - again which is fine if it's configured and secured properly but from what I've seen it's becoming more and more prevent for people to deploy servers / instances without truly understanding platform operations to a level where they choose a sensible OS distribution, keep SELinux enabled, run services in cgroups, automate patching etc... etc... and I think that's fine from the devaluing of operational experience and the whole replace one (modern) ops engineer with 5 devs mentality without considering that it may be more efficient to hire people and create roles based on their skill set and passion where they'll thrive best.

This uses golang.org/x/crypto/ssh which doesn't spawn a shell, but handles the SSH connection like you would any other network connection. And the same could and should be done for the other mentioned examples as well.

Using sshd for SSH services is like using inetd for TCP services.

SSH != remote shell -- pretty much one of the main points of this article.

Previous discussion: https://news.ycombinator.com/item?id=8743374

Cool toy, but be sure to read that too:

https://news.ycombinator.com/item?id=8828543

"Every keystroke is sent over the TCP connection. This is why you might notice lag in your typing."

Isn't that an opportunity to predict what someone is typing?

On the server side you could make predictions. However client A would not be able to see client B's keystrokes.

Its sort of like using Javascript to submit an HTML input field on every key press (AJAX).