There is something about Finnish products that make them very strong, Nokia, SSH, Rovio.
Why aren’t we using SSH for everything?
101–105 of 105 posts
Re: Why aren’t we using SSH for everything?
#102Earlier quoted context omitted.
SSH is designed to serve a single service on a single host. It distributes its host key on the first connection and caches it indefinitely, assuming it will never change. SSH is designed with a limited set of protocol features, and everything else is kind of hacked on top of proprietary client/server pairs. SSH is designed as a loose encrypted session (kind of like a pipe) for an application on a host. TLS is designe…
Maybe it would be nice then if TLS would somehow cache host keys, too? Like my browser caching the relationship: www.bank.com is 1.2.3.4 with pub key XYZ Or is this already implemented and I am too stupid to find it?
Since this kind of goes against the point of using an intermediary to verify the host key, and multiple services and hosts make this much more difficult to support, it's not built into TLS. But the application can add support for it. There are experimental web standards and methods for various OSes/applications here https://www.owasp.org/index.php/Certificate_and_Public_Key_P...
Re: Why aren’t we using SSH for everything?
#103Something else worth mentioning; SSH has built-in support for single-sign-on, via SSH agent forwarding. As long as my public key is available anywhere (and that's exactly what it's designed for), then I can be authenticated by any system, anywhere. Thus, a problem which is so vexing in so many other scenarios, is very cleanly addressed by SSH. Fundamentally, a password is a shared secret. So you send your password to…
Agreed! On nomenclature - you're saying ssh agent forwarding, but the functionality you describe is actually simply public keys on remote machines. The only time you need to forward is when you're logging into another machine through a third machine -- and as other commenters have pointed out, you're extending your trust model to that third machine.
Re: Why aren’t we using SSH for everything?
#104Something else worth mentioning; SSH has built-in support for single-sign-on, via SSH agent forwarding. As long as my public key is available anywhere (and that's exactly what it's designed for), then I can be authenticated by any system, anywhere. Thus, a problem which is so vexing in so many other scenarios, is very cleanly addressed by SSH. Fundamentally, a password is a shared secret. So you send your password to…
Agreed! On nomenclature - you're saying ssh agent forwarding, but the functionality you describe is actually simply public keys on remote machines. The only time you need to forward is when you're logging into another machine through a third machine -- and as other commenters have pointed out, you're extending your trust model to that third machine.
(blatant plug) Userify can distribute those public keys and reduce (but not eliminate) the cases where agent forwarding is required.
Re: Why aren’t we using SSH for everything?
#105Isn't there a problem when you tunnel TCP over TCP with increasing window sizes (auto throttling mechanism meant to prevent packet fragmentation)? Every time I've tried to keep a long-running ssh tunnel for printing / http, the connection degrades after a while. I'm sure there are some flags that can be set, but I thought this was the major show stopper for the "everything over shh" (since ssh uses TCP protocol)
Simple port tunnelling (-L and -R command line arguments) do not suffer from TCP over TCP. And if you want VPN-style usage, look into sshuttle. It is one way only, and that's a good thing! (Most of the time you only need connections going one way and none going the other way). If you do want two way, either use two sshuttle connections (one each way) or OpenVPN. The only thing about sshuttle that I've encountered tha…
I have to agree that VPN's are usually a bit too much; generally speaking, VPN's are a chainsaw when a scalpel is more appropriate!