Slashdot Mirror
Why Aren't We Using SSH For Everything?
An anonymous reader writes: A post at Medium asks why, in this age of surveillance and privacy-related bogeymen, we aren't making greater use of SSH for our secure computing needs?
"SSH is one of the most accessible secure protocols ever, second only to HTTPS of course. Let's see what we have so far: Binary protocol, mandatory encryption, key pinning, multiplexing, compression (yes, it does that too). Aren't these the key features for why we invented HTTP/2?
Admittedly, SSH is missing some pieces. It's lacking a notion of virtual hosts, or being able to serve different endpoints on different hostnames from a single IP address. On the other hand, SSH does have several cool features over HTTP/2 though, like built-in client authentication which removes the need for registration and remembering extra passwords."
"SSH is one of the most accessible secure protocols ever, second only to HTTPS of course. Let's see what we have so far: Binary protocol, mandatory encryption, key pinning, multiplexing, compression (yes, it does that too). Aren't these the key features for why we invented HTTP/2?
Admittedly, SSH is missing some pieces. It's lacking a notion of virtual hosts, or being able to serve different endpoints on different hostnames from a single IP address. On the other hand, SSH does have several cool features over HTTP/2 though, like built-in client authentication which removes the need for registration and remembering extra passwords."
>Admittedly, SSH is missing some pieces
Should read, "Admittedly, SSH is missing some crucial features, that make its use in this context impossible."
SSH can be used for virtual hosting environments just fine with things like force-command chrooting automatically when a user logs in based on username or pubkey. The protocol is not hostname aware, so it cannot handle "different hostnames from a single IP", you have to have a different user account name in order to do similar tricks. I do not think that is a limitation though, since you are talking to the underlying system, not to a content serving system like a web server.
If anything is missing, it's probably only missing on Windows.
Support on Linux and Mac is jut fine, I think.
Windows:
- client support is kind of OK
- virtual filesytem support is kind of OK
The biggest missing solution:
- Windows server support. There are some expensive solutions, not sure how well they work.
New things are always on the horizon
I know back in 1995 when Cygwin came out it got a reputation of being pretty flakey.
But it's come a long way in the last 2 decades.
These days, pretty much any time you think you have a "hmm, Linux can do this but I don't know how to do it on Windows", Cygwin is probably a very good possibility.
Hummm... configuring openssh is really not difficult on most modern Linux distributions.
Install the openssh packages, execute ssh-keygen once per user and you are basically done.
The only tricky part for some novice users is to copy the public key to the server (in .ssh/authorized_keys) but recent versions of openssh provide the ssh-copy-id tool that can do that for you.
Despite the similarity of the names, OpenSSH and OpenSSL are maintained by entirely different teams. Of note is that the organization which maintains OpenSSH recently forked OpenSSL into LibreSSL which, once it stabilizes, is expected to behave more safely.
And if SOCKS isn't enough, you can also do ssh -w 42:42 to link a pair of tun interfaces between the two sides. (Slightly less cool because you have to manually configure networking on both ends for it.)
And then the summary decides to hold compression up as the super amazing feature that nobody has ever heard of...
Or we could just finally implement DNSSEC, and put the keys (Or, rather, the fingerprint) in the DNS.
Someone is about to point out that DNS can be subverted and hijacked, even with DNSSEC.
Well, considering that SSL keys are commonly *emailed* to people, if anyone has subverted your DNS, or anyone's DNS, you're screwed anyway. At least with DNSSEC, it requires hacking into the actual registrar account and changing records there, instead of just tricking the least-secure SSL-issuer's DNS. (And registrars already have pretty good protection against that, considering that stealing domain names was a hobby a few years ago. And if they don't, you can always change registrars, whereas you can't stop insecure SSL-issuers you've never met from existing and issuing bogus keys for you.)
And with people getting *mailed* SSL keys actually means if the DNS is stolen for a few minutes, which people would never notice (Especially if the attackers are smart enough to just redirect MX records, and hand over every piece of mail *except* the SSL keys.), everyone can run MiTM attacks against people for a *decade* with the key they got mailed. (You could get the key revoked, but only if you know it exists, and pretending that key revocations actually worked.) Whereas with the keys in the DNS, as soon as you fix the DNS, it's fixed, everything's over.