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

> What does this mean? It means that SSH has authentication built into the protocol. When you join ssh-chat, not only do I know who you claim to be, but I can also permanently and securely attach an identity to your connection without any user intervention on your part

This, known as fingerprinting, is collectively considered a bad thing. I am thankful this isn't elsewhere

Related:

SSH has become our universal (Unix) external access protocol

https://news.ycombinator.com/item?id=40995867

I'm hindsight, after the recent xz backdoor, combined with the fact sshd runs as root, we probably shouldn't use SSH for everything.

Basically all the benefits listed are already in https, just maybe not used often (thinks like client certificates). IMO it'd make more sense to make SSH use http2/http3 than it would to make HTTP use SSH.

SSH has some advantages, but it is not perfect. (Neither is HTTPS, TLS, etc; none of them are perfect, of course.)

> SSH knows your username

It is not always desirable, although of course an implementation might not necessarily need to use your local username as the remote username (especially if the implementation is on a computer that does not have usernames). The existing implementation does allow you to override the usernames, as they describe there.

Sending environment variables is also useful. You might not want to send some (or you might, like above, use a computer system that does not have environment variables, in which case the SSH client will need to have its own mechanism to specify them).

Sending these things automatically even if you do not want to do, can be a problem.

> SSH validates against your key pair

This is a helpful method, although the user may wish to force a specific method (and the server also might wish to do so).

Automatically offering all of the keys doesn't seem like very good to me, but allowing the user to manually associate which keys to use for which connections (allowing keys to be shared between connections if wanted), can be helpful. (This is not a problem with the SSH protocol, though; it is an issue with the client implementation.)

> SSH connections are encrypted

Encryption is helpful, but sometimes unencrypted connections are helpful (e.g. in case it is to another program on the same computer and encryption is not needed). If the client requests encryption and the server does not have it (or does, but with a weaker cipher than the client intends), then the client should display an error message and refuse to connect.

Key fingerprint validation is very helpful. This is not really specific to the SSH protocol though, and is possible with other protocols such as TLS, although the SSH client has a better user interface and user experience for this than some other programs (such as most web browsers).

(TLS has many complexity too though; most kinds of encryption will have many, although there are some experimental ideas for a somewhat simpler kind.)

> SSH supports multiplexing

Multiplexing in the protocol really is a useful feature for many purposes (although not everything should need it). Some examples are mentioned there, although others can be possible too.

> SSH is ubiquitous

It is true, and this is a good thing; but nevertheless there are some issues with this. There is still some complexity, even though it is fortunately not even half as complicated as modern WWW (although it also has a few complexities that WWW lacks).

There are also some issues having to do with different types of computers and user preferences. (WWW has these problems too and is even worse in many ways.) Environment variables can solve some of these things, but not all of them. (Some things can be solved without the server needing to know about them; e.g. you could easily program the terminal emulator to ignore the colours specified by the server, e.g. in case the server ignores the client's NO_COLOR variable.)

> SSH sounds awesome, and familiar… Binary protocol, mandatory encryption, key pinning, multiplexing, compression (yes, it does that too).

I think there are some benefits of binary protocols especially if it makes it simpler to parse than text protocols; however, text has different benefits.

TLS also supports compression, even though it is not always used (and there are aparently security issues with it that have to do with HTTP, is what I seem to remember), and also seems to be deprecated.

Multiplexing also would be possible with other kinds of protocols that are designed to support it.

Key pinning also can be done independently of the protocol; the SSH client does that, and it is helpful, but it isn't something that necessarily needs the SSH protocol in order to work.

They also mention that virtual hosting is not supported, so this is another problem with SSH. (TLS does have virtual hosting.)

> Why aren’t we using SSH for everything?

Well, I think although it has many benefits, there are also many problems with it (e.g. SSH does not have virtual hosting). However, both many of these benefits and many of these problems are mostly independent of the protocol.

Also, different protocols and different file formats are useful for different purposes, rather than needing only one kind. There are many kinds.

In my opinion, the user interface for SSH tends to be better designed in some ways, than the user interface of web browsers; however, this is not really an issue with either protocols themself.