We're not using it because... well... it's weird (for lack of a better word)? Sure, it's a multiplexing protocol that can support a few neat use cases like port forwarding and X11 tunneling, but that's really not what we want in most cases. It carries a lot of baggage in its clients and implementations that in principle shouldn't cause problems but in practice makes it suboptimal.
One of the most important aspects of why we don't use it: it's scary to work with. SSH's implementation of its protocol is much closer to the actual client implementation than the divide traditionally maintained between SSL and its clients. People are rightly afraid to get close to cryptographic code without sufficient training, and so there is the equivalent of a "If You Are Responsible: Keep Away" sign for most developers who might be inclined to improve the situation.
Still, the community found the impetus to augment the protocol and UI to help deal with latency issues that plague SSH via Mosh. It helps escape the legacy idea that RTTs will be consistent and therefore are ignorable in a shell implementation.
Ultimately, SSL is a better understood tunneling protocol and full of a lot less... maybe it's just the perspective we have in a world where SSL is ubiquitous but SSH is weird. Its rules are weird, its certificates are weird, its tooling is weird.
This is a common contention in Hacker News I'm often on the minority size of, but I submit that while syntactic interfaces (shell, programming) has clearly demonstrated its value and deserves to be better developed, the same can not be said for serial text entry interfaces. Something based around a streaming query protocol like SSL+HTTP/2 that makes some fundamentally different decisions than the legacy UNIX shell and supporting tooling would be substantially better, and be able to use existing web browser techniques and software.
Which is all abstract, but imagine for a moment something we've seen before: an Electron Shell based terminal. But what we haven't seen is someone really dive in and attempt to redefine the world around shells. So bear with me for a second...
Imagine an Electron Shell based terminal experience that works locally and remotely. A line buffer separate from the display accumulates and maintains the current prompt (because instead of PS1 being pseudo-executable in our shell it actually can attach scripting functions and web-browser style timers).
Executables logically return open dictionary objects (which can contain streams) instead of the current fixed set of indexed streams. We can use 0, 1 and 2 as legacy keys into these objects to maintain compatibility. But you could imagine a "rich-1" key that actually outputs rich markup, "error-1" that outputs rich markup for error, etc. And of course, media itself could either be file system references. These rich objects are just textual objects with references to valid HTTP/2 requests do what they do.
This actually resembles SSH's protocol on the outside, but using tools that are reusable elsewhere and a cryptographic stack and transit protocol that has more funding and attention and traction.
Yes. I would suggest anybody who poses the question "why not" to try to actually implement SSH from the scratch! I've looked at some "smaller" implementations than OpenSSH and they are still, like you say, "weird."
SSH appeared to me to be an implementation of the console application that got crypto and network code bolted on, everything kept together almost with the Sellotape. And it doesn't change when somebody has to re-implement it as most of the "features" have to exist for a thing to work.
However, there are also some advantages in using SSH for some purposes: for somebody who knows what he does, just the key management is actually less weird than the whole SSL thing. The tunneling is also very convenient and I like it.
One of the most important aspects of why we don't use it: it's scary to work with. SSH's implementation of its protocol is much closer to the actual client implementation than the divide traditionally maintained between SSL and its clients. People are rightly afraid to get close to cryptographic code without sufficient training, and so there is the equivalent of a "If You Are Responsible: Keep Away" sign for most developers who might be inclined to improve the situation.
Still, the community found the impetus to augment the protocol and UI to help deal with latency issues that plague SSH via Mosh. It helps escape the legacy idea that RTTs will be consistent and therefore are ignorable in a shell implementation.
Ultimately, SSL is a better understood tunneling protocol and full of a lot less... maybe it's just the perspective we have in a world where SSL is ubiquitous but SSH is weird. Its rules are weird, its certificates are weird, its tooling is weird.
This is a common contention in Hacker News I'm often on the minority size of, but I submit that while syntactic interfaces (shell, programming) has clearly demonstrated its value and deserves to be better developed, the same can not be said for serial text entry interfaces. Something based around a streaming query protocol like SSL+HTTP/2 that makes some fundamentally different decisions than the legacy UNIX shell and supporting tooling would be substantially better, and be able to use existing web browser techniques and software.
Which is all abstract, but imagine for a moment something we've seen before: an Electron Shell based terminal. But what we haven't seen is someone really dive in and attempt to redefine the world around shells. So bear with me for a second...
Imagine an Electron Shell based terminal experience that works locally and remotely. A line buffer separate from the display accumulates and maintains the current prompt (because instead of PS1 being pseudo-executable in our shell it actually can attach scripting functions and web-browser style timers).
Executables logically return open dictionary objects (which can contain streams) instead of the current fixed set of indexed streams. We can use 0, 1 and 2 as legacy keys into these objects to maintain compatibility. But you could imagine a "rich-1" key that actually outputs rich markup, "error-1" that outputs rich markup for error, etc. And of course, media itself could either be file system references. These rich objects are just textual objects with references to valid HTTP/2 requests do what they do.
This actually resembles SSH's protocol on the outside, but using tools that are reusable elsewhere and a cryptographic stack and transit protocol that has more funding and attention and traction.