Hacker News Reader

Comment by verandaguy | Hacker News Reader

As tempting as it is to use SSH everywhere (for exactly the reasons outlined here), other protocols exist because they usually have some form of marginal gains over the alternatives, and marginal gains matter at scale.

Encrpytion isn't always something that's needed (arguably; though I'm all for enabling it everywhere it can be enabled), and in places where it's not critical, it adds performance overhead both client- and server-side.

SSH also has to be shoehorned into distributed chat applications, for example, else the interface deters inexperienced users and, again, almost inevitably, overhead is incurred. Using PGP for authentication and encryption in this case is a saner choice because it supports decryption by groups of recipients, and implementing a protocol over UDP (or even TCP) is plenty.

EDIT: Just to be clear, though, there are some pretty cool nonstandard uses of SSH out there. Medium OP's chat server is a great example.

View on HN

> As tempting as it is to use SSH everywhere (for exactly the reasons outlined here), other protocols exist because they usually have some form of marginal gains over the alternatives, and marginal gains matter at scale.

I heard people "at scale" also use micro services over HTTP. Or even Rest for mobile apps, where latency is a real issue.

So I am not buying that part. I think HTTP (over TCP) has won because the web has won. As always technical people are overestimating the importance of technical aspects of a product and thereby their own importance, when really it is all about usability and network effects.

>I think HTTP (over TCP) has won because the web has won.

For sure. If I were building a mobile app that had to talk to a server, a RESTful API would be the first thing that comes to mind.

It's not the most lightweight protocol, but it's the protocol with a structure and interface that's designed for this -- making it a natural choice.

You could to a certain extent implement a REST-like API over SSH, or UDP for that matter, but that takes extra effort, and the fact of the matter is that many developers are just working on a higher level of abstraction, and lack the expertise to build new protocol. (My reasoning is that the lower barrier of entry into software development has created many developers with skillsets specialized in use of more "modern" technologies).

TL;DR -- IMO, using verbs to act on resources is easier to grok than working in terms of packets for most developers, and is sufficient in most situations. I still believe there are better alternatives for high-performance networking.

There are also some significant vulnerabilities [1] in SSH by design / by default that must be disabled if used everywhere.

[1] https://news.ycombinator.com/item?id=11052745

It is very easy to write a virus that is not detected by any anti-virus. I don't see how dropping an SSH key on some machine is worse than dropping a remote shell on it.

It's not like SSH keys are stealthy or something - any sysadmin worth his salt will occasionally look at his authorized_keys list.

> any sysadmin worth his salt will have automated the population of his authorized_keys file and alert on any unauthorized changes.

FTFY

That appears to be surprisingly uncommon. By that I mean maintaining the authorized keys file at all.

I wish everyone checked their authorized_keys file like you do. Sadly, this is rarely the case across the board, based on my experience. People are lazy. There are good aspects of being lazy, but this is one of the sub-optimal cases.

In summary, this methodology would not likely be detected even in places where folks and admins are quite vigilant. The behavior and usage is expected. If I were unethical, I could gain access to thousands of companies by simply emailing a link to github and saying, "This script is giving me errors, what am I doing wrong?" Using the default settings in ssh an sudo, I can access all of their systems with no syslog entries and gain root to anything they have sudo on.

I use an SSH CA and it solves this problem.

It's simple to setup. You first create a CA, and then you sign the servers public key and the client's public key, and you take the resulting certs (alongside the CA's pubkey) and move them over to the machines. And I think it's important to note that you can do this process on any machine-- perhaps an air-gapped $30 Raspberry Pi, or if you're less paranoid you can do it on your laptop, but the point is that you can generate keys in bulk, offline, and move them over to dozens of machines in one fell swoop.

You still need to maintain an authorized_keys file in your homedir with your client public key, which means if someone was able to get the CA key they still wouldn't be able to get into the server without first getting the key that corresponds to the entry in your authorized_keys file. And likewise, if someone was able to get access to your user key, they would be able to login with it but wouldn't be able to add a backdoor key to the authorized_keys file unless they also had the CA key to sign it with, because both the client and server check the other's certificate against the CA pubkey.

Of course, if you see ssh keys as a panacea and subsequently use passwordless sudo or a weak enough password, they have root and can just edit your sshd_config and this was all for naught. But it does solve the problem of an unchecked authorized_keys file.

That helps, but you would still need to disable ssh multiplexing on all of your servers.

Why?

Any process running as you can piggy-back on those default-enabled channels without authentication or logging on the destination servers.

Reply on news.ycombinator.com