4 ms·

> 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

by dozzie 11y ago

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

djmdjm 11y ago
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
- dozzie 11y ago
  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.
Laaw 11y ago
SSH is a protocol, not an implementation, all your complaints are just engineering problems.
sargun 11y ago
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 11y ago
  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 11y ago
    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 11y ago

by dozzie 11y ago

djmdjm 11y ago

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

dozzie 11y ago
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.

Laaw 11y ago

SSH is a protocol, not an implementation, all your complaints are just engineering problems.

sargun 11y ago

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 11y ago
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 11y ago
  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 11y ago