
Why aren’t we using SSH for everything? (2015) - fforflo
https://medium.com/@shazow/ssh-how-does-it-even-9e43586e4ffc#.r9qzj6hhl
======
tptacek
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.

~~~
technomancy
> leave you with no upsides.

Not even close.

While TLS technically supports client-side certs, all extant implementations
of it are unbearably clunky to use, completely ignored by all vendors.
Meanwhile the tooling around SSH keys (like ssh-agent) is seamlessly
integrated with your OS and works so well that it's easy to forget it even
exists.

Browser vendors completely dropped the ball on this; they dropped it so hard
it continues to hurt even after all these years.

~~~
e12e
This may be true, but at least x509 will get you _certificates_ right out the
gate (sadly without reliably working reject lists).

I've yet to get to the point of moving to "modern ssh" (ed25519 key/certs,
chacha20-poly1305 encryption etc) - with certificate only. Because keys are
*so' convenient. But they're also, while better than passwords, pretty bad: No
expiry, no easy rotation, no easy revocation.

I will say this though: it should be quite feasible to move to modern ssh,
banning keys and passwords (other than perhaps as a second factor), and moving
to certs only. But clearly deployment of reasonable ssh setups are lacking
behind the technological improvements.

------
fjarlq
HN discussion when this was originally posted 471 days ago:

[https://news.ycombinator.com/item?id=8828543](https://news.ycombinator.com/item?id=8828543)

~~~
13of40
I need to get on that hacker news api and figure out what the half life of a
HN user is, so we can tell whether 471 days is a meaningful value. I suspect a
large number of people reading this weren't around then. (I think I measured
that 2/3 of posters here don't have at least 501 karma, so you can use that as
a ballpark figure.)

~~~
quacker
Some users are lurkers. I created this account 1921 days ago but have only 201
karma.

That said, I don't remember the previous posting of this article, so linking
to previous comments is useful. It lets me compare the discussions and see how
opinions do or don't change.

~~~
13of40
You know, maybe I'm wrong, but I read the comment as a cheap way to register
superiority over the OP - essentially saying "we already talked about this, so
move along." That's not as valuable when "we" changes over time, and (as you
pointed out) a lot of "us" don't participate in every discussion. IMHO we'd be
better off if we didn't have to hear about it every time an old topic got
resurrected.

~~~
simoncion
> ...I read the comment as a cheap way to register superiority over the OP...

Whose comment? fjarlq's comment? If so, I _also_ might be wrong, but I read it
as "Here's old discussion on the topic. Might be worth reading to see if what
you want to talk about today has _already_ been hashed out, or if there's
discussion that you might find interesting.".

~~~
fjarlq
Yeah, I merely wanted to reference the old discussion in the hope that it
might improve the discussion today. I think it's fine when a story gets
discussed multiple times.

------
Sanddancer
Because it's easier to wrap an arbitrary protocol with TLS than it is to
tunnel it through ssh. Plus, TLS is already supported for the purposes you
mentioned. A number of MU*s already offer TLS access, IRC and XMPP have
supported TLS since forever, there's near ubiquitous support for it in any
language you want to write a client/server in, plus, as others have mentioned,
you don't have the security risks that SSH can potentially have. It just
provides too much weight for not enough benefit.

------
nzoschke
Ask a provider like GitHub and Heroku which git protocol they prefer: SSH or
HTTPS.

The answer is HTTPS.

Managing an SSH server with millions of customer pubkeys is a pain.
Python/twisted and Go have decent SSH implementations but there are quirks and
side effects a plenty.

Shells are scary. You have to be very careful about how you execute the
program on the remote side of the pipe. Shell command parsing and escaping is
gnarly.

Windows...

HTTPS with basic auth headers is much easier to scale.

The one gotcha is that it took a while for HTTP git to get "smart" and offer
as efficient transport as SSH with access to a .git dir.

~~~
technomancy
It's not as simple as you make it out to be. HTTPS git still has no consistent
way to cache credentials, so you're stuck either keeping it in plaintext on
disk or re-authenticating every time you push.

Even though client TLS certs are technically supported by a handful of
services, there's nothing for HTTPS that matches the security and convenience
of ssh-agent. It has a long way to go to catch up to where SSH was ten or
fifteen years ago.

~~~
tadfisher
git supports "credential helpers" [0] which allow arbitrary credential storage
and retrieval schemes. I've successfully used it with a Yubikey, for example,
although I promptly reverted to using SSH and my GPG authentication subkey
when it became clear that there is no single scheme that works on all
platforms I use.

[0] [https://git-scm.com/docs/git-credential](https://git-scm.com/docs/git-
credential)

~~~
nzoschke
The parent has a great point about credentials and ssh-agent in general. Netrc
isn't a great pattern.

But for git you have the right answer.

I completely forgot this aspect because on OS X you can delegate git auth to
Keychain with a helper.

[https://help.github.com/articles/caching-your-github-
passwor...](https://help.github.com/articles/caching-your-github-password-in-
git/)

~~~
technomancy
Apparently since the last time I checked, git actually includes a helper
script that allows you to use `gpg-agent` to decrypt your creds in an
analogous way to how `ssh-agent` works. It requires a bit of setup since for
some reason it's disabled by default, and it's a bit more moving parts (GPG
key plus username/password instead of a single keypair) but it's a lot better
than it used to be.

I hope this pattern catches on for services other than git.

~~~
tadfisher
A better solution is to simply use `gpg-agent` as your `ssh-agent`, as it
supports that protocol and it supports RSA authentication keys.

Then your public keys provide not only identity, but services can _verify_
that identity through their web of trust.

------
lamontcg
Doesn't scale, its very chatty as a protocol and its not actually very
reliable. I've seen software deployments over ssh scaled out to 1,000s of
target servers and its just not pretty. Also used sitescope for alerting and
the whole 'agentless' model (where 'ssh' is the real agent) is bad -- again
poor scalability in both the CPU and reliability domains...

------
nickysielicki
the better question is why we're not using pgp for everything.

I wish I could register for services with nothing but a public key. No email
address. No username. When I want to login, generate a login token and I'll
sign it and give it back.

------
zmanian
The noise protocol is great candidate for an everything crypto protocol.

http/2 and TLS1.3 are great but make some assumptions that might not be right
for everything.

Whats App is using Noise now in their apps.

------
eru
Some MUDs already support ssh, don't they? I know that some nethack servers
do.

~~~
gtaylor
Evennia (Python, Twisted + Django) is one of the most (the most?) popular
Python MUD servers and features SSH/SSL support:
[https://groups.google.com/forum/#!topic/evennia/4blKxTGQ3CE](https://groups.google.com/forum/#!topic/evennia/4blKxTGQ3CE)

More on Evennia itself: [http://evennia.com](http://evennia.com)

------
sqldba
1\. It can't be easily grokked. How many options does it have. Dozens?
Hundreds? Compare to FTP.

2\. Only specialists appear to understand the PKI infrastructure which
underpins this security enough to properly manage the keys; possibly with
expensive appliances. Compare to FTP; it's easy to grok managing and securing
a string.

3\. It's leaky. When you connect by FTP you present only the creds you desire.
When you connect over SSH you expose all of your identities / keys to the
other server. Pretty dumb.

~~~
pritambaral
Any secure system (more secure than FTP, at least) will have a lot of knobs.
Most of the time, it is well handled by sticking to defaults. THis is
something SSH has done well, and HTTPS not so well; I've had to set TLS
configs on my web servers, while SSH is a simple `apt install ssh && cat
/etc/ssh/ssh_host_ecdsa_key.pub`

> Only specialists appear to understand the PKI infrastructure ... Compare to
> FTP, it's easy to grok managing and securing a string.

It's also easy to break into a typical string-password-protected service. If
FTP needed the higher security, it would have to use complex crypto. Crypto is
hard.

But, as I said above, it doesn't have to be hard to use, only implement.

> It's leaky

Agreed, SSH should have some support for matching keys with hosts
automatically. But it already supports doing this manually. Check out
IdentityFile in ssh_config's manual.

------
wsfull
Idea: Maybe it's the "sh" in ssh that make it so useful. Environmental
variables instead of "HTTP headers". envdir

Opinion: In terms of "authentication" I still think ssh has the edge over
anything associated with http/https and www. Two parties should be able to
authenticate to each other without involving a third.

~~~
wsfull
Clarification: By "authentication" I mean keys that the users generate using
ssh-keygen. I do not mean certificates or "certficate authorities" (CA's).

~~~
spilk
TLS supports mutual authentication via X.509 certificates, and they can be
self-signed on both ends with some "accept" dialogs, similar to SSH's "do you
trust this host's key?" prompts.

~~~
wsfull
Is generating ed25519 keys slower or faster than generating self-signed certs?

Nothing wrong with OpenSSH supporting the option to use certs. They can be
useful to some users.

But the entire X.509 scheme to my knowledge was based around some idea of
third party verification.

This gave rise to the business of selling CA "services". Problematic to say
the least.

And still to this day, "self-signing" appears to be disfavored. Or perhaps the
openssl binary is just too loaded with options for users to learn the commands
to generate CA and server certs and keys.

Whether it truly is or not, ostensibly "SSL/TLS certificates" to the public
seems to require third party involvement.

ed25519 keys do not have this problem. And generating them is relatively fast.

------
dozzie
> 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.

~~~
sargun
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](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.

~~~
tptacek
By "no practical attack", you mean, "as long as you trust whichever government
controls your TLD _and_ whichever governments effectively control the global
DNS root" \--- which, for most of the hosts people on HN contact, means "as
long as you trust the NSA".

DNSSEC is a disaster. Avoid it.

[http://sockpuppet.org/blog/2015/01/15/against-
dnssec/](http://sockpuppet.org/blog/2015/01/15/against-dnssec/)

~~~
dsl
I hate to add "me too" replies, but it is important to get the message out
there that lots of really smart folks consider DNSSEC an absolute failure of
such epic proportions that you shouldn't even joke about building something
real on top of it.

The only thing DNSSEC has given us is widespread DDoS amplification.

~~~
ktRolster
What better option is there?

~~~
pferde
Not using DNSSEC and not having false sense of security. No sense of security
is better than a false one.

------
deathanatos
> _Fortunately, as long as the proxy doesn’t have the original server’s
> private key, then the key fingerprint will be different._

Will it? What is the proxy server happens to have a key whose fingerprint hash
is the _same_ as the original server's key?

SSH very recently upgraded how keys are fingerprinted; the screenshots in this
article are the old method, which as I learned recently, are MD5 hashes. (I
had thought they were SHA1.) SHA-256 is what gets used now. But, for example,
Ubuntu's LTS doesn't have the update. I'm glad they made the change, but I'm
left wondering how key exchanges aren't somewhat vulnerable on unupgraded
machines.

(e.g., fingerprints now look like:

    
    
      SHA256:7h5Q0O1Qc8G7Hv/hVIrx1d6ZTgnITwrutr1XDBYY0sg
    
    )

~~~
sargun
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.

~~~
userbinator
_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._

If I understand correctly that's basically a preimage attack, and even for MD5
where you can find arbitrary colliding pairs _very_ easily today, AFAIK no one
has come up with a single preimage example or practical attack.

~~~
TillE
Right, none of the published MD5 attacks allow you to generate data to match a
specific hash value. It's certainly a good idea to avoid MD5, but it's not
easily exploitable in most situations.

------
gbraad
Logging in to an IRC server over ssh could do the user verification using the
user key, just like https can do client certificates. It is an underrated
posibility perhaps..

~~~
e12e
Reminds me of: "Show HN: ssh chat.shazow.net" (the github repo actually links
to the medium article of this story now)
[https://news.ycombinator.com/item?id=8743374](https://news.ycombinator.com/item?id=8743374)

I suppose the natural thing would be to marry the Robust IRC server/gateway to
a golang ssh front-end, so that one could ssh in and be dumped right in a
(nick authenticated) robust irc sesssion...:

[https://github.com/robustirc/robustirc](https://github.com/robustirc/robustirc)

------
turbohedgehog
Does SSH have PFS?

~~~
malingo
Yes, if session keys are ephemeral.

"SSH session keys are ephemeral and are exchanged between hosts using DHE."

From: [https://lwn.net/Articles/572926/](https://lwn.net/Articles/572926/)

DHE:
[http://stackoverflow.com/questions/14034508](http://stackoverflow.com/questions/14034508)

------
hackaflocka
Encryption is about 2 orders of magnitude more computing intensive than non-
encryption.

It's expensive. That's why we aren't using Encryption for everything.

~~~
benchaney
Being two orders of magnitude more computing intensive that doing nothing
isn't really an issue.

