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."
I use SSH for everything. I use it between my cell phone and the wall charger. I use it between my thermostat and my furnace. Probably most importantly, I use it between my my remote control and TV. Never can be too careful these days.
Better known as 318230.
Recent Snowden documents shed doubt on whether the NSA isn't actually able to crack ssh, too. http://www.spiegel.de/international/germany/a-1010361.html
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
One of the coolest client-side features of most SSH clients (at least OpenSSH and PuTTY support it) is the ability to turn any SSH connection into a SOCKS5 proxy, provided the server will let you. If your Internet connection has a restrictive stateful firewall on it that blocks your access to many useful legitimate sites, you can just stunnel out over TLS and then have the ability to go outbound on any port (including SSH's default port of 22) using your SOCKS5 proxy. I've used RDP over SSH over TLS before to get around restrictive filters.
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.
SSH connections take For. Eh. Ver. relatively speaking:
Subsequent requests using the same connection are quick enough:
% time ssh localserver exit ssh localserver exit 0.00s user 0.00s system 20% cpu 0.039 total
But compare to an HTTPS connection to a remote host:
A brand new request to a remote server takes just 263ms, and a second request only 81ms. Considering that the server is 25ms away, that makes it a bit faster than a cached SSH connection to a local machine.
But even more than that, SSH in this context is a transport, not a protocol. It allows you to build and manage secure connections, but you still have to write a protocol on top of it ("I'll send this command, and you reply with..."). Even if you "cheat" and use SFTP, you're still missing out on fixes to the thousands of little issues people have worked out with HTTP over the years. What's the SFTP equivalent of If-Modified-Since? How will redirects to remote servers work? What's your cross-domain scripting policy? How are you going to handle anonymous connections?
Use SSH for SSH. Use HTTP for HTTP. They're separate things for good reasons.
Dewey, what part of this looks like authorities should be involved?
Why aren't we using SSH to monitor the computer's microphone?
We ARE using SSH to monitor your microphone.
Sincerely,
The [3 characters redacted]
telnet and ftp practically died a while back, http is on the way out. In most corporate environments, other protocols such as X are local only and remote use is over ssh tunnels. IMAP/SMTP takes place over TLS when using decent providers. I guess there is a question of whether SSH and HTTPs should be merged. But a lot of work has been put in both and would be difficult to replicate and make as secure from the start. No hurry.
The only exceptions are organizations with lax security (like Sony apparently) and cases where security or integrity is completely not an issue. I guess if you broadcast a video as unencrypted UDP over a local network, that's fine.
SSH as a protocol was designed for interactive login, and it has some issues when used for other applications. But there is one key aspect of it that needs to break out of SSH, the public key cryptography part.
When creating an account on a web site, rather than entering a User ID and password the browser should generate a public-private pair, and send the public part to the other side. Logins can then be done just like SSH does, with a cryptographic exchange.
The "lost password database" goes away completely. If you got the database on the far end it would only contain public keys, which would not allow logins. The whole "everyone must change their password" nonsense goes away.
So don't force SSH on us, but let's all work to get more public key based logins.
What's wrong with Medium? It's essentially just a blogging platform, right?
I think, because only a fraction of 'net users are security conscious.
The rest just use the 'defaults' of their apps and search result links for things like email , online shopping, and online banking, and trust(?) that the people providing the access to their email, online banking, and online shopping, kept them safe.
Uh, Linux geek since 1999.
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.
I confused medium.com with the other site that is often the target of /. article links. Dammit now I am stuck, I can't remember it, it has a simple name as well, it is one with "scientific" topics but really crap content in a fancy css scrolling article... Sorry about that...
Violence is the last refuge of the incompetent. Polar Scope Align for iOS
Condoms are pretty good for safe sex. I think we should be using condoms to protect our bank accounts, for giving everyone safe drinking water, for screening passengers at airports and for securing your valuables in hotel rooms.
Got any reliable citations for those sources, or is it just the nebulous "some"? I mean, some sources say the NSA has brainwave scanners and can tell what you're thinking from a van outside your house. But those guys are nuts.
The protocol is an open standard, and anybody who has looked at OpenSSH's source code has "cracked" it. It's not terribly complex. If you're transmitting over an unencrypted connection or using a compromised cipher or key, anybody can figure out what you're doing.
The real issue (and what you're probably thinking of) is whether the NSA has backdoors in or has cracked different encryption ciphers that are commonly used over SSH. If they have, that's a much more widespread problem than just SSH, because those ciphers are used elsewhere, too (like in HTTPS).
Karma: Terrifying (mostly affected by atrocities you've committed)
Not every web service can mail you a physical symmetric cipher, banks maybe, but they focus on making online banking much like PayPal than providing the hardest security they can implement. On the other hand, the SSL/TLS protocol does just what described (symmetric key delivery) in a pretty automatic way, by providing the browser a public key, the browser generates an encryption key locally, encrypts it with the server's public key, then sends it to the server, which will use it for future communications with the client.
I think you just answered the poster's question, by the way. SSH is quite good for what it does, but what it does doesn't cover every conceivable need.
A better question might be,"Why aren't we using SSH *in more situations where it might be useful*?"
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Turn on compression with -C and select a fast cipher with -c
ssh -C -c blowfish-cbc,arcfour -X
Also, some applications (Firefox) seem to do all their own per-pixel rendering rather than using appropriate X primitives. For those applications, VNC with a a minimum color palette may work much better, or choose a different application that does the same job.
Speaking of choosing different applications, consider CLI options. A CLI interface is quite usable at about 64 kbps. I use the GUI only for a browser and email, and occasionally virt-manager. The browser and email can use the socks proxy feature of ssh, so that only leaves virt-manager as the only application I ever forward.
Remote root access is allowed by default on at least some distros.
So take that up with the maintainers of the (braindead) distros you didn't mention and get something done about it. Your complaint has nothing whatsoever to do with the OpenSSH software itself.
..Mullah or Pope, Preacher or Poet, who was it wrote: "Give any one species too much rope and they'll fuck it up"?
What's wrong with Medium? It's essentially just a blogging platform, right?
So is Slashdot, if you're Bennett Haselton.
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.