Ask HN: Why not just use ssh for everything

Classic &quot;Worse is better&quot;<p>I shall let Rob Pike explain :<p>When I was on Plan 9, everything was connected and uniform. Now everything isn&#x27;t connected, just connected to the cloud, which isn&#x27;t the same thing. And uniform? Far from it, except in mediocrity. This is 2012 and we&#x27;re still stitching together little microcomputers with HTTPS and ssh and calling it revolutionary. I sorely miss the unified system view of the world we had at Bell Labs, and the way things are going that seems unlikely to come back any time soon.<p><a href="http:&#x2F;&#x2F;rob.pike.usesthis.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;rob.pike.usesthis.com&#x2F;</a>

SSH or SSL doesn&#x27;t get you e.g. end-to-end security; the model you propose is equivalent to chatting via a server over HTTPS, which is indeed very common. (In general, OpenSSH is great but the SSH protocol itself isn&#x27;t all that special.)<p>Something like TextSecure improves on the security of SSH&#x2F;SSL for its specific use case: end-to-end security, message-level forward-security even if the receiver is offline at the moment, deniable messages (instead of allowing the receiver to prove you sent them), etc.<p>Many other applications use SSL as a transport and try to add some X-factor (integration with Facebook&#x2F;GMail&#x2F;$GAME&#x2F;...); these applications would still get made if the underlying transport changed to SSH.

<i></i>tl;dr: security is the issue, users can&#x27;t be trusted<i></i><p>SSH is a &#x27;general purpose&#x27; protocol for remote filesystem access. Clients with lax permissions are an attack risk. Non-technical users can&#x27;t be depended upon to handle permissions. As such, SSH is commonly blocked at the firewall to prevent such malicious access.<p>HTTPS is rarely blocked. HTTPS is inherently safe because it doesn&#x27;t grant access to anything that isn&#x27;t explicitly defined the HTTP-layer API. HTTPS connections are usually handled via browsers that come with sandboxed memory spaces; even if a malicious actor manages to establish remote code execution in the client there&#x27;s little&#x2F;no risk of compromising the user&#x27;s OS via a buffer overflow or equivalent attack vector.

It takes a long time and many round trips to establish an SSH connection. You can keep a shared connection open as a workaround. But mobile devices (laptops included) don&#x27;t persist connections, because batteries.<p>Maybe you could do it on top of mosh? <a href="https:&#x2F;&#x2F;mosh.mit.edu&#x2F;" rel="nofollow">https:&#x2F;&#x2F;mosh.mit.edu&#x2F;</a>