Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

medium.com

Post reply on HN
Print view View original

81–87 of 87 posts

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

#81

Post by pritambaral »

nzoschke wrote: post #46

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…

> millions of customer pubkeys is a pain

And millions of passwords isn't because ... ? Whatever solution the industry has arrived at for storing a large number of user passwords and authenticating against them, can be applied to SSH keys too. I would be greatly suprised if Github uses ~/.ssh/authorized_keys to handle SSH authentication at its scale.

> Python/twisted and Go have decent SSH implementations but

So is the case with HTTPS implementations. It's just a standard, how it's implemented is not under its control. On the other hand, we have some good implementations of HTTPS, and similarly we have good implementations of SSH too: libssh2.

> Shells are scary.

So don't use shells over the SSH protocol. Make the server execute (upon successful auth) something that isn't a shell.

> Windows...

Agreed. Until user-agents popularly support a protocol, adoption faces large obstacles.

> HTTPS with basic auth headers is much easier to scale

Easier how? You have to do less computation to verify the password? This has nothing to do with the transport, and everything to do with the cryptographic strength of the password. SSH is better here because of its good support of keys (versus TLS client certs).

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

#82

Post by pritambaral »

sqldba wrote: post #32

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

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.

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

#83

Post by dozzie »

djmdjm wrote: post #5
dozzie wrote: post #2

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

I don't agree we should use SSH for everything, but > Managing SSH sensibly (with checking keys properly) in any greater scale is awful. The certificate key format introduced by OpenSSH allows for quite easy large-scale key management so long as your clients and servers are OpenSSH or golang x/crypto/ssh

Managing host keys is much more than just dumping at some point in time all the certificates in some directory, even if under version control. Servers are (can be) deployed and ramped down and reinstalled and moved from network to network all the time, and not always by you nor by somebody who cares about your configuration management system, which leads to plenty of fun in tracking what keys the servers have and should have.

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

#84

Post by technomancy »

nzoschke wrote: post #61
tadfisher wrote: post #56

Earlier quoted context omitted.

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

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

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.

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

#85

Post by ryanlol »

pritambaral wrote: post #80
ryanlol wrote: post #55

Earlier quoted context omitted.

Why would you do that with either option?

HTTPS auth provided by Github et al. don't support client certs, only username/password pairs. There is no equivalent to ssh-agent for HTTPS (because authenticating to HTTPS URLs is not a standard).

I still don't see why that'd require storing of plaintext credentials.

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

#86

Post by tadfisher »

technomancy wrote: post #84
nzoschke wrote: post #61

Earlier quoted context omitted.

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

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

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.

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

#87

Post by dsl »

ktRolster wrote: post #47
dsl wrote: 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?

https://dnscrypt.org/
Post reply on HN