Ask HN: Why not just use ssh for everything

[biturd]

We have all these so called secure messaging apps, some are OSS, some are not, it's kinda a mess.

I can open an ssh connection to a remote server, a friend can do the same, and we can use wall or tail files or whatever, essentially, we can chat, insecurely on a box that we have a secure connection to.

I am sure it would not be hard to make the ssh libraries the core of an app that chats, talks, walks, runs, or does whatever, securely.

Why aren't we just doing thing instead of reinventing all these secure transports?

[SixSigma]

Classic "Worse is better"

I shall let Rob Pike explain :

When I was on Plan 9, everything was connected and uniform. Now everything isn't connected, just connected to the cloud, which isn't the same thing. And uniform? Far from it, except in mediocrity. This is 2012 and we'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.

http://rob.pike.usesthis.com/

[EvanPlaice → SixSigma]

tl;dr: Network Administration 101. SSH is an application-layer protocol. Just because it provides an 'easy' path to encrypted remote filesystem access doesn't mean it's a one-size-fits-all solution.

Just because *nix hosts treat everything as a file doesn't mean all networking can be handled via remote filesystem access (ex windows hosts, network hardware, etc).

SSH is an application-layer protocol. VPN provides access at multiple layers of the networking stack depending on the protocol used (ex PPTP, L2TP).

For instance, if you need to remotely activate all the machines on a remote network for maintenance. A simple approach is to broadcast a WOL (Wake-On-Lan) packet to the remote subnet. Due to WOL being a Layer 2 protocol, this is not possible using SSH alone.

Same goes for remote monitoring the status/health of a remote network via SNMP traps (also Layer 2).

Remote router/switch configuration, packet analysis, and many other lower level administration tasks require access to the lower layers of the network stack. All of which can be accomplished over a VPN but not SSH.

As for the reasoning behind using HTTPS, see my other comment. SSH access should only be granted to 'trusted' clients and it's usually a good idea to disable it when a 'safe' alternative is available.

[biturd → SixSigma]

So this is just a dev wanting to scratch an itch issue and/or arrogance and/pr ignorance?

I always wondered why there was a separate layer for VPN's when you can so easily use ssh for a VPN at least for a secure way to use the internet. I suppose if you want it for the act of "being" on a remote network as if you are local is a VPN advantage, but I'm pretty sure ssh has a way to make that happen as well.

If I get this correct, it is a good idea to use ssh as a chat app's security methods?

[SixSigma → biturd]

"just a dev" - do you mean Rob Pike ?

[JoachimSchipper]

SSH or SSL doesn'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't all that special.)

Something like TextSecure improves on the security of SSH/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.

Many other applications use SSL as a transport and try to add some X-factor (integration with Facebook/GMail/$GAME/...); these applications would still get made if the underlying transport changed to SSH.

[EvanPlaice]

tl;dr: security is the issue, users can't be trusted

SSH is a 'general purpose' protocol for remote filesystem access. Clients with lax permissions are an attack risk. Non-technical users can't be depended upon to handle permissions. As such, SSH is commonly blocked at the firewall to prevent such malicious access.

HTTPS is rarely blocked. HTTPS is inherently safe because it doesn't grant access to anything that isn'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's little/no risk of compromising the user's OS via a buffer overflow or equivalent attack vector.

[pshc]

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't persist connections, because batteries.

Maybe you could do it on top of mosh? https://mosh.mit.edu/