Why aren’t we using SSH for everything? (2015)

> Programmatic Data Streams

> RPC API

Please don't. Managing SSH sensibly (with checking keys properly) in any greater scale is awful. SSH was never meant for general communication, which reflects how it operates on implementation level and on protocol level. SSH servers require usable home directory locally and remotely (OpenSSH has some workarounds, but this quickly becomes ugly), you need to manage SSH keys, both public and local, and protocol has plenty of options useful for interactive administrative service, but terrible from security standpoint (have you disabled everything unnecessary? and are you sure it was everything?). If you use SSH in non-interactive, non-supervised mode, it is a disaster waiting to happen.

> Why aren’t we using SSH for everything?

Because it is not suited for everything. It is only suited for providing shell and for some non-interactive but human-supervised tasks.

HN discussion when this was originally posted 471 days ago:

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

I'm not sure how easy it is to forge a fingerprint. Given most of the MD5 collision work was done based on length-extension attacks, I think SSH is somewhat more tolerant to these. Nonetheless, your point stands - it is possible to forge a key that has the same fingerprint as the original server, but I cannot think of any practical way to do this.

SSH is also implemented by Golang, and Erlang (And probably a bunch of other languages). You're right that traditional SSH clients tend to need long-term storage, but one could easily turn off host key caching, and look to SSHFP records (http://www.ietf.org/rfc/rfc4255.txt) instead. I'd actually argue that SSHFP records are analogous to DANE. Paired with DNSSEC, I'm not there there's a practical attack there.

As far as the server side - apart from the storage of the keys (which is required with any cryptographic protocol), I'm not sure where the challenge comes in.

Bootstrapping trust is a problem in any situation. SSH server keys paired with an out of band mechanism for distributing public keys or SSHFP can prove to be a fairly reasonable method. I'd say somewhat more reasonable than what we had with HTTP + TLS for the longest time (until say Let's Encrypt). Even with that, certificate stores aren't particularly easy to manage.

Going back to the language-specific implementations of SSH. Those servers can be run without the necessary submodules to do shell-like stuff. I agree with you, it'd be crazy talk to use the system SSH daemon to do much of what's described by the author, but as a protocol, perhaps it is more reasonable.

Because it's not a very good protocol. Adopting it, instead of HTTP/2 and TLS 1.3, basically gets you everything that is bad about TLS (most notably, a legacy of 1990s cryptography) and everything that is bad about SSH (poor performance, extreme complexity), and leave you with no upsides.

For instance: the HTTPS stack will, with effort, allow you to opt in to protocol forwarding, via mechanisms that were designed to prevent accidental forwarding. The SSH stack, on the other hand, requires you to opt out of arbitrary TCP/IP port forwarding. Screwing that up will, more often than not, get you owned up Phineas Phisher-style.

The things this post appreciates about SSH are equally available in the HTTPS stack (even more so in the HTTP/2 stack). Unlike SSH, with its janky Connection Protocol, HTTP has for the last 10 years been designed as an arbitrary application protocol. SSH does a better job providing interactive terminal sessions. HTTP does a better job at everything else.