
Why aren’t we using SSH for everything? - dkua
https://medium.com/@shazow/ssh-how-does-it-even-9e43586e4ffc
======
otterley
For one thing, SSH performance for large transfers is abysmal over high-
latency links. SSH uses a small TCP window size because it was optimized for
quick response, not bulk transfers. (After all, it was designed to be a remote
shell protocol, not a generic file transfer protocol; scp and sftp were added
after the fact.) And unfortunately you can't currently specify a different
buffer size even if you wanted to.

More information can be found here: [http://www.psc.edu/index.php/hpn-
ssh](http://www.psc.edu/index.php/hpn-ssh)

~~~
jzila
Are there any plans to patch this into OpenSSH? It looks like they have a
great solution for the problem you highlighted.

~~~
dmm
Those patches are old. My understanding is that the parts that are reasonable
have been implemented and the parts that aren't (plaintext modes) have been
ignored.

If you need to transfer large files around a lot use what the supercomputing
centers use: GridFTP.

~~~
lotsofmangos
I'd never even heard of GridFtp before. It looks pretty good. I've taken to
not installing ftp on servers at all and just using ssh, but this might make
me think again.

------
kgilpin
Something 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 a
server, you are trusting that server not to lose or misplace it. In contrast,
an SSH public key doesn't require nearly such careful management.

~~~
dsl
SSH agent forwarding is extremely risky. Anyone with appropriate permissions
(legitimate or illegitimately gained) on a machine you have connected to can
use your credentials to open a new connection to any machine you have access
to.

~~~
btown
> on a machine you have connected to

Don't you have to be actively connected to the machine for this to work? i.e.
the server I haven't connected to for a few months has no way of opening
connections on my behalf at this point, right?

~~~
beagle3
You are right.

But once you connect, a year later - in those 3 minutes before you disconnect,
the attacker might have authenticated as yourself to 100 other machines -- and
appended their own key to .ssh/authorized_keys on these machines, so that the
compromise no longer needs you to be connected.

------
ivan_ah
Isn'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)

~~~
beagle3
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 that exposes it's non-
VPNness, is that the connection truly originate from the remote system - e.g.
if you connect through sshuttle to your peer, the connection go from the peer
to the peer on 127.0.0.1. That may or may not be a problem (e.g., logging is
much less useful this way).

Try sshuttle. I've stopped using VPNs since I started.

~~~
jamiesonbecker
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!

------
forgottenpass
_Why aren’t we using SSH for everything?_

Because "Use X for everything" is a terrible design decision? SSH uses
flexible transport with some desirable features and may be underutilized in
practice.

This question is starting to feel like people who want to staple every pie in
the sky idea to the bitcoin blockchain because it too has a set of desirable
properties.

~~~
shazow
You're right, we probably shouldn't use SSH to microwave our food.

But a lot of things where we use HTTP today, we could be using SSH if we had
better library support. Some more ideas towards the end of the post.

~~~
marcosdumay
> we could be using SSH if we had better library support

It's the firewall rules, not library availability.

~~~
Shish2k
Tunnel SSH over HTTP, best (worst) of both worlds :)

(I have tried this; it is both useful and terrible)

~~~
bashinator
Or you could just run `sshd` on port 443.

~~~
dec0dedab0de
But this would fail on many proxies, and any firewall that was aware of the
protocol.

------
falcolas
Neat trick, if you're so inclined to use such tricks:

    
    
        $ cat .ssh/authorized_keys
        command="tmux new-session -A -s base" ssh-rsa [...]
    

Automatically creates or joins a tmux session named base, and disconnects the
SSH session when you disconnect from the tmux session.

So, yeah, why don't we use SSH for more?

~~~
XorNot
It's multiplexing support uses static sized windows, which even on modern LANs
means you usually only see 3-5 mb/s transfer rates where you should be able to
- even with encryption overhead - achieve almost gigabit NIC speed.

Fortunately the HPN-SSH patches exist to solve this problem - but I really
want to know why their's so much resistance to adding them upstream.

~~~
acdha
> which even on modern LANs means you usually only see 3-5 mb/s transfer rates
> where you should be able to

On a WAN, sure, but even a mid-2000s gigabit LAN could routinely hit 800+Mb
with scp as long as you had tuned the underlying TCP stack (Linux was poor and
OS X/*BSD worse in that era) and weren't using something slow like 3-DES.

> Fortunately the HPN-SSH patches exist to solve this problem - but I really
> want to know why their's so much resistance to adding them upstream.

Looking at the patches, I'd be surprised if the problem wasn't the fact that
they change other things with security or reliability implications. Seeing
something like “Dynamic Window and ability to use NONE encryption” suggests
that it'd be better to break it up into some smaller generally-useful patches
and a separate patch for people in controlled environments who need as much
performance as possible.

~~~
XorNot
It is broken up into separate patches as well (scroll down the homepage).

But the NONE encryption makes a lot of sense in a "use SSH more" perspective.
When you need to move piles of totally non-private data, but want to use a
secure authentication mechanism (and message authenticity system) for issuing
shell commands...

------
josephg
Because SSH requires several seconds to initiate a session, even on a local
LAN.

Does anyone know why this is the case? Its always baffled me.

~~~
jloughry
A delay of several seconds every time when connecting via ssh is usually due
to the remote host trying to look up your IP address and timing out. Change
the remote host's sshd_config file to include the line "UseDNS no" and
connecting will be much quicker from then on.

------
bondolo
Key management is pretty primitive. It would be nice if SSH integrated better
with PGP/GPG. I recently spent too much time messing with monkeysphere,
keychain, gpg-agent, gpgsm etc. trying to use GPG derived keys for SSH. While
I could cobble something together I didn't feel that it was a solution I could
recommend to others as a general "best practice" because it involved too much
installing and configuring and was still somewhat brittle (eg. providing key
names to gpg-agent in my .bashrc file).

~~~
dredmorbius
But SSH keys really don't matter.

In PGP/GPG, key persistence matters _because you 're using them to decrypt
messages. Long after content was created you may need the key to decrypt it.

For SSH, the key is only strictly necessary during the session. Key
_distribution* (of your public key to systems you need access to) is a bit of
a pain, but between having your private key(s) where you need them, and
authorized keys on various servers, there's not all that much to worry about.
Host keys, perhaps, if you want to be rigorous about security.

------
sysk
It's not clear to me how SSH differs from SSL/TLS conceptually. It seems to me
both achieve similar goals (encrypted tunnel, client/server authentication).
Perhaps we should take the best bits of both protocols and create a new one?
But then, I am reminded of [http://xkcd.com/927/](http://xkcd.com/927/).

~~~
peterwwillis
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 designed to serve multiple services on multiple hosts. It depends on
your browser trusting an intermediary host which validates the host key, so
(in theory) the initial connection can't be MITM'd, and so the key can change
at any time or there can be multiple keys (which is needed for hosting
multiple services on multiple hosts). TLS is designed to integrate tightly
into an application.

When you compare the two protocols, TLS is clearly superior to SSH. But in
terms of the features they support (tunneling, authentication, etc), it's up
to the server to add missing features outside of the protocol to provide for
what the client wants to do.

For example, the SSH protocol basically provides an encrypted connection
through which you can do whatever you want, similar to TLS. To do IP tunneling
with SSH the application server activates extra functionality to connect the
encrypted session to a driver which opens an IP tunnel. Or to authenticate
your ssh session against a kerberos server, the ssh server does the actual
kerberos authentication; the protocol just informs the client of what 'basic'
methods they can use, and the client tries to use one that works with the
server's methods.

Incidentally, TLS the protocol supports client certificate authentication,
which provides similar functionality to SSH's public keys. The HTTP protocol
also does certificate pinning.

~~~
onnoonno
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?

~~~
peterwwillis
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...](https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning#Examples_of_Pinning)

------
feld
I wonder if his chat server has been hit by a botnet yet trying to ssh in and
then sending tons of shell commands

~~~
shazow
Lots of people spamming/flooding/DoS'ing "for fun", but no clueless bots
stumbling in accidentally yet.

Btw previous HN thread about ssh-chat here:
[https://news.ycombinator.com/item?id=8743374](https://news.ycombinator.com/item?id=8743374)

------
codingthebeach
It was difficult for me to get past the self-referential (and reverential)
tone of the writing, which felt more like an advertisement for the author's
cleverness than a real discussion of the pros and cons of SSH, but it could be
I woke up on the wrong side of the bed this morning.

------
silbak04
Somewhat relevant: I think Mosh solves a few problems that SSH lacks. This
article:
[https://news.ycombinator.com/item?id=8252093](https://news.ycombinator.com/item?id=8252093)
made it on Hacker News a bit ago. The video is wort the watch imo.

------
sharpneli
SSH can really be used for almost everything. It's a different thing if it
actually _should_ be used for everything.

My favourite one:
[http://en.wikipedia.org/wiki/SSHFS](http://en.wikipedia.org/wiki/SSHFS)

Whenever I'm developing for my mobile phone I actually have the contents
mounted on my desktop via sshfs as an actual filesystem.

What that means? Don't bother with FTP servers. ssh access to your server is
all you need.

------
emmanueloga_
If you rephrase this question like this, the answer is evident:

"Why aren't we using a protocol designed to add encryption to pseudo-devices
emulating a real text terminal device [1] for _everything_?"

1:
[http://en.wikipedia.org/wiki/Pseudo_terminal](http://en.wikipedia.org/wiki/Pseudo_terminal)

------
ashish01
Would be great to do this for mosh - mosh-chat It improves over SSH by
handling intermittent network connections.

~~~
Shish2k
mosh isn't a data stream tool like ssh though, it's actually more like VNC --
the reason it performs better is that it sends snapshots of the terminal over
UDP, allowing random packets to be dropped

------
ezequiel-garzon
What surprises me is the lack of total CLI control, potentially through SSH
and ideally using keys, of your hosting provider's control panel. Whether it's
CLI or some form of TUI, it's bound to be faster and more convenient for many
developers.

~~~
blfr
Cloud providers nowadays usually have some sort of CLI clients. OpenStack
comes with a full suite[1]. Google rolled out their own for Google Cloud[2].
And if there's nothing official, there are often tools built by users
available for interacting with the API.

Authentication is based on some sort of shared secret rather than keys though,
yes.

[1] [http://docs.openstack.org/user-
guide/content/ch_cli.html](http://docs.openstack.org/user-
guide/content/ch_cli.html)

[2]
[https://cloud.google.com/sdk/gcloud/](https://cloud.google.com/sdk/gcloud/)

------
spydum
Interesting idea, but isn't ssh very sluggish when it comes to throughput and
latency? Doesn't it cost quite a bit more in CPU? I'd hate to make ssh the
protocol replacement for http for a busy site.

~~~
monksy
It depends on the clipher you're using and the implementation/hardware.

~~~
otterley
It depends more on the TCP window size; OpenSSH uses a small one by default
and it cannot be changed.

See also [http://www.psc.edu/index.php/hpn-
ssh](http://www.psc.edu/index.php/hpn-ssh)

------
101914
MOre interesting question: Why aren't we using SSH-style authentication for
everything? And although they can be used with SSH, I do not mean
certificates.

~~~
iancarroll
I don't see why client side certificate authentication is excluded? You can
easily self sign and create your own CA. There aren't really any downsides.
Putty with cryptoapi support exists.

------
peterwwillis
What the...? Does the author just not know anything about SSH, or web
browsers? Why would we use SSH for everything?

On top of the fact that they're entirely different protocols and tools
designed for entirely different purposes, browsers already support virtually
everything SSH does. File transfers, authentication, client certs,
multiplexing, key pinning, etc. There is no need to use SSH, and if you did,
it would be slower, less secure, and generally more annoying than using the
existing tools built into browsers.

I find it aggravating when users read the manual to some software and think
they have discovered fire.

~~~
nickpresta
What does this even mean?

Your browser supports those things because it implements protocols, like HTTP,
TLS, and others. Your browser, or other tools, __could __support SSH, which I
think is the point of the article.

~~~
peterwwillis
This means the author doesn't know what they're talking about, and is asking a
dumb question.

The article's title is "Why aren't we using SSH for everything?", not "Why
don't browsers support SSH?". Both make no sense. It's like asking why FTP
clients don't support Voice-over-IP.

------
higherpurpose
I read somewhere that SSH can be MITM'ed by a global adversary on the first
visit (before it establishes the secure connection). Is that true?

~~~
singlow
Yes. It does not have any centralized certificate system like HTTPS so unless
you can manually verify the host's public key, you will not know whether your
first visit is being proxied. Of course, if the first one is proxied, so may
subsequent ones, and you would only get a warning if the proxy was removed or
if it's key changed.

~~~
shazow
SSH supports CA-style key signing, and it also supports server fingerprint
validation over DNSSEC (search for SSHFP DNS).

Unfortunately neither of these things are commonly used yet. Cloudflare is
adding DNSSEC support soon, so hopefully that will change.

~~~
agwa
It's going to take a lot more than Cloudflare adding DNSSEC support to make
SSHFP records viable. Every system running an SSH client will need to run its
own validating resolver. If you leave validation to an upstream server you
lose a significant amount of security.

~~~
tptacek
Not to mention that if your adversary is the Global Adversary, DNSSEC is
mostly useless.

------
throwaway593
> Why aren’t we using SSH for everything?

Because it doesn't support virtual hosts. And I can't afford 30 IPs for my
server.

Otherwise, it's a great protocol.

~~~
TylerE
Couldn't you use the same IP and different ports? There's nothing magic about
port 22 - and in fact on production servers you should almost certainly change
22 to something else.

------
forfengeligfaen
If you believe Jacob Appelbaum, we probably should not be using SSH for
anything
[http://media.ccc.de/browse/congress/2014/31c3_-_6258_-_en_-_...](http://media.ccc.de/browse/congress/2014/31c3_-_6258_-_en_-
_saal_1_-_201412282030_-_reconstructing_narratives_-_jacob_-
_laura_poitras.html#video)

~~~
shazow
Yea I was fairly confused about that announcement as I couldn't find anything
damning in the released docs about SSH. Do you have a reference to a specific
document/slide?

~~~
boracay
My guess is that, at least, some router ssh implementation is insecure,
possibly not by accident.

From the slides:

Page 19: "SSH [...] Potentially recover user names and passwords" Page 36:
"SSH - often have router configurations and user credentials [...]"

[http://www.spiegel.de/media/media-35515.pdf](http://www.spiegel.de/media/media-35515.pdf)

~~~
shazow
Right, I saw that also. Is it referring to routers that happen to run SSH with
default root/admin passwords or something? I couldn't find anything more
concrete.

------
ramigb
There is something about Finnish products that make them very strong, Nokia,
SSH, Rovio.

------
malkia
Because schools and filtering software

------
shazow
Sorry the title has been revised to "Why aren’t we using SSH for everything?"
in case mods see this.

