Live data from Hacker News

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

medium.com

51–60 of 87 posts

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

#51

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 escapin…

I prefer ssh for this purpose since I don't want to store credentials somewhere in plain text.

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

#52
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...

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

#53
post #10

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…

> and leave you with no upsides.

The only place I've personally seen client-side certificates implemented in a browser was for StartSSL's site (which is famously janky in it's workflow). In contrast, pretty much anyone who does anything on the CLI in a unix environment has a client-side ssh key set up, already good to go.

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

#54
post #10

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…

Newer versions of OpenSSH have totally dumped the "90s crypto", although its important to note the problems with older ssh stuff are mostly due to things like RSA key lengths and use of RC4 and CBC. This stands in contrast to numerous gaping flaws in TLS stacks like the use of export ciphers, message maleability, inummerable weaknesses in x509 certs that allow spoofing/mitm and other horrible shit that is trivially c…

*"Also consider attack surfaces here, how many exploits have there been on say openssl and apache/nginx over the Past 1/5/10 years. How many on OpenSSH?"

This. I can't believe the top comment on this post is supporting TLS (as implemented currently) over SSH (where everyone is basically using openssh). There's pretty much a guaranteed "named" widespread TLS based attack exposed every month or so. Whether it's due to TLS the spec or the prevalent implementations, it doesn't matter. Any application designer choosing a protocol has to contend with the fact of shitty implementations of the underlying layer when thinking of security.

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

#55
post #51

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 escapin…

I prefer ssh for this purpose since I don't want to store credentials somewhere in plain text.

Why would you do that with either option?

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

#56

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 escapin…

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 te…

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

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

#57
post #40
post #34

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.

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

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.

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

#59
post #10

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…

If that's the case, how can I plug the HTTP/2 and TLS 1.3 stack into Linux-PAM and use it to login to my remote servers instead of using ssh?

Or are they not suitable for that?

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

#60
post #16

Earlier quoted context omitted.

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.

What better option is there?

Not using DNSSEC and not having false sense of security. No sense of security is better than a false one.
Post reply on HN