LWN: Comments on "OpenSSH 5.4 released"

OpenSSH 5.4 released

BSchuller — Fri, 12 Mar 2010 13:53:39 +0000

Hi,

X.509 may be complex, it is widely used, and many
X.509 based infrastructures exist. Therefore, introducing a
home-grown version of X.509 requiring admins to effectively
run their own CA is hard to understand.
I think it would be a very good move if X.509 could be
supported in OpenSSH. Admins who think the security risk is
too high can always opt-out.

Best regards,
Bernd.

Dang! No HPN-SSH!

dlang — Thu, 11 Mar 2010 05:26:22 +0000

even on modern hardware the encryption overhead can limit transfer speeds.

on very modern system I can transfer data twice as fast over local gigE networks with HTTP or FTP than I can via SSH

Dang! No HPN-SSH!

martinfick — Thu, 11 Mar 2010 02:48:39 +0000

While I wouldn't want to tell you how to write secure software, I wouldn't dismiss the need for speed so quickly. Have you payed attention to CPU speed increases lately? A 3 year old desktop is far from a slow machine, especially for a single threaded app (since most CPU advances are simply adding cores). I run much older machines than that, 10+ years old, (as I suspect many using free operating systems do) and they do suffer greatly from encryption performance in local gigabit ssh file transfers. They also chew up over 50% of my CPU and all I care about is authentication and integrity from one machine in my basement to the other. Other non encrypted transfers are much faster on these machines and do not chew up my CPU.

OpenSSH 5.4 released

djm — Tue, 09 Mar 2010 23:56:21 +0000

I chose to avoid X.509 mostly because it is complex in encoding (ASN.1) and
semantics. Consider the number of ASN.1 related bugs that OpenSSL and other
implementations have suffered from - the fact that nobody gets this right is
a good signal that it is overly complex. Unfortunately, key/cert parsing and
validation is by necessity in the critical pre-authentication attack surface
of sshd, so bugs there are particularly nasty and could be used to write
worms.

The OpenSSH certificate format uses existing SSH signature formats and wire
encoding primitives, so all of that code is reused. Also, because these
certificates are not tied into such a heavyweight and hierarchical model of
identity, the the semantics of certificates and the workflow of creating
them is much simpler.

OpenSSH 5.4 released

herodiade — Tue, 09 Mar 2010 23:26:45 +0000

> the chances of sshd flipping out and using all your ram is much much less

Also note protection is on the _listening_ sshd (that's not a whole lot a code ; not the user's child processes for instance).

With regard to the new certificate format, does anyone here knows why X.509 doesn't fit well for SSH?

Someone maintains a patchset to include support for X.509 certificate here http://roumenpetrov.info/openssh/ ; I can see some benefit with that from an end-user perspective (mostly, reusing existing tools for pki management, certificates revocations lists, etc).

Dang! No HPN-SSH!

djm — Tue, 09 Mar 2010 22:25:57 +0000

err, s/prefer/prefer not/

Dang! No HPN-SSH!

djm — Tue, 09 Mar 2010 21:12:57 +0000

Yes, we are dinosaurs who would prefer to have to deal with thread race
conditions in security software. AES on my 3 year old desktop is >800Mbit/s
on a single core and RC4 is 2x faster again, so I don't think crypto
performance is a massive problem.

Dang! No HPN-SSH!

andikleen — Tue, 09 Mar 2010 14:45:22 +0000

One of the main reasons for HPN is multi threaded MACing/encryption,
which is needed for fast enough links because a single core cannot do full performance otherwise.

And yes multi threading your application is typically intrusive, but
it's also very needed if it is CPU time intensive and
you want to keep up with modern systems.

Tab completion in ssh

andikleen — Tue, 09 Mar 2010 13:50:19 +0000

The coolest new feature not mentioned is finally tab completion in ssh

But then see other comment for a serious misfeature.

Dang! No HPN-SSH!

andikleen — Tue, 09 Mar 2010 13:49:16 +0000

Fully agreed, it's really bizarre that OpenSSH is still single threaded even though cryptography takes so much CPU time. Basically you can't really use it on a serious network connection because of this problem. And in addition the small buffers also make it hard to use over a WAN.

I wonder if it's related to being developed on OpenBSD which is not exactly known for SMP scalability?

Perhaps the distros will use it some day at least, even if the maintainers can't get out of the 70ies.

Dang! No HPN-SSH!

tialaramex — Tue, 09 Mar 2010 11:51:22 +0000

Can you explain why it's a bad idea to be able to turn off secrecy? Sometimes I need to move a large file over the network, and the contents of that file are public (e.g. several TB of data published by the government). I don't care if someone sees this data, or even if they see me moving it, but I don't want anyone messing with it, thus I still need integrity. Of course I can move it with 'netcat' and then verify using sha1sum, but it'd sure be convenient if the default OS tools (ie OpenSSH) let me do this with a suitable incantation.

No-one is asking for this to be the default of course, but why can't we have it as an option without hacking the code?

Dang! No HPN-SSH!

djm — Tue, 09 Mar 2010 11:04:16 +0000

The default session window in OpenSSH is 2MB already.

This limit is enough for a path with 5 seconds latency at your DSL speed.
Put differently, if your one-way path latency is 100ms then unmodified
OpenSSH's window size should only start restricting performance if your
transfer rate is ~160Mbit/s.

If you are on Internet2 and want to move files between continental USA and
Europe at gigabit speeds, then you might still want the HPN patches.

Dang! No HPN-SSH!

BrucePerens — Tue, 09 Mar 2010 04:51:10 +0000

Yes, I know there are no 2MB static buffers. If you set the size of the communication buffers to 2MB, you would achieve the same speed increase as with the dynamic buffers used by the patch. That is, given a high-speed network connection. I don't know if this makes any difference for us folks with 3megabit/300kilobit DSL connections.

Dang! No HPN-SSH!

djm — Tue, 09 Mar 2010 04:24:21 +0000

We made some performance changes for high BDP links a few releases back,
which should have obviated the need for the HPN patches for all but the
highest BDP links. You should benchmark your connection to see if it
actually benefits from the HPN patches, which are quite intrusive.

The other component of the HPN patches that people sometimes ask for is the
ability to select a null cipher/MAC. We are not planning on implementing
that ever.

Dang! No HPN-SSH!

djm — Tue, 09 Mar 2010 04:20:23 +0000

You are misinformed. There are no 2MB static buffers in OpenSSH.

Dang! No HPN-SSH!

BrucePerens — Tue, 09 Mar 2010 01:51:19 +0000

So, is the alternative to set the static buffers to 2MB?

OpenSSH 5.4 released

BrucePerens — Tue, 09 Mar 2010 01:43:15 +0000

Remote servers without dedicated remote consoles are a lot cheaper than the other kind. Only $30 to $70 per month for a pretty good server. Of course I have them set to reboot if sshd dies, or if they can't reach their router.

OpenSSH 5.4 released

drag — Mon, 08 Mar 2010 20:30:27 +0000

As far as OpenSSH is concerned, specifically, the chances of sshd flipping out and using all your
ram is much much less then having other applications flip out and use all your RAM and having
OOM kill off sshd.

For most uses of Linux killing off sshd would have a similar effect of killing up 'getty' on a local
console. OOM Killer operating in this manner is effectively like having the Linux kernel perform
it's own denial service attack on userland.

OpenSSH 5.4 released

ewan — Mon, 08 Mar 2010 17:36:30 +0000

Oftentimes it is that stupid, and can make a bad situation considerably worse by cutting off any hope you might have had of SSHing in and fixing the actual problem.

OpenSSH 5.4 released

lkundrak — Mon, 08 Mar 2010 17:27:38 +0000

* Disable OOM-killing of the listening sshd on Linux. bz#1470

I'm wondering what sense does this make. Turning off a feature that would kill sshd once it goes mad and eats up all the memory and kill everything else instead? Or do they assume the oomkiller to be that stupid?

Dang! No HPN-SSH!

alex — Mon, 08 Mar 2010 17:04:02 +0000

Is it by any chance because the OpenSSH team are worried about security
auditing code that goes from statically allocated to dynamically allocated
buffers?

Dang! No HPN-SSH!

aaron — Mon, 08 Mar 2010 16:57:33 +0000

I guess this happens every OpenSSH release, but I keep hoping they'll merge some of the patches from the Pittsburg Supercomputing Center.
(See http://www.psc.edu/networking/projects/hpn-ssh )
It's truly amazing how they help transfers over higher-latency links (i.e. any distance over a mile.) They also help local transfers a fair bit.
Unfortunately, for now, if you can't patch your own SSHd, you have to use commercial file-transfer software, a Riverbed, or RSA-SSHd.

Please, O pufferfish, strap on a jetpack!

OpenSSH 5.4 released

nix — Mon, 08 Mar 2010 15:10:47 +0000

Your headline is wrong. The release notes say it 'removes support for SSH
protocol 1 by default'; i.e., you can still turn it back on.