Bug 55024 - request compilation with -c none for speed w/o rsh
request compilation with -c none for speed w/o rsh
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: openssh (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-10-24 12:25 EDT by Joe Harrington
Modified: 2008-05-01 11:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-10-24 12:31:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joe Harrington 2001-10-24 12:25:31 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.16-3smp i686)

Description of problem:
I'd like to see this package compiled with the "none" cipher enabled.

SSH ciphers vastly slow down the connection, by a factor of at least 3. 
When transferring large amounts of data, such as tens of gigabytes in a
network backup, the cost can be significant.  The question becomes, what
are we trying to protect?  There are two answers: authentication security
and data integrity.  If we don't authenticate securely, we get broken into
and damaged, so we have to protect that. That eliminates rsh as a solution,
as spoofing makes it too easy to abuse a .rhosts file.  Data integrity is
often much less important to spend resources to protect, because in many
instances the connection is short and protected (e.g., 2 machines on a
switch), the intruder must be active on that local net when the connection
is active, and it's less "desirable" from the standpoint of today's
intruders to scramble data than to login, as evidenced by the extreme
rarity of deliberate attacks on data during transfers.

Thus, for users with large data-transfer needs, an ssh capability with
encrypted login authentication but no data encryption is desirable.  The
risk of loss to me is greater if the transfer takes 3 hours than if the
transfer takes 1 hour, because those 2 hours of work time are very
valuable, and I may need the data for a class I'm teaching, or a
presentation, or to take with me on a plane flight.  So now, I have to use
rsh.  This opens me up to a *much* greater security risk, because now
there's a .rhosts file involved, I (or one of my students) may forget to
delete it, and you don't have to be present on the local net to take
advantage of it.  Plus, it has us using two different tools to do the same
job, depending on the size of the transfer.  The "none" cipher in ssh
provides the solution.  It is similar in speed to rsh, but still has ssh's
strong login authentication capability.

Time to transfer a 113940480-byte (108.6 MB) file between 2 machines with
100 mbps cards and a switch between them, best of 3 attempts per method:

method			time	scale to 10.86 GB
rcp		      10.1 sec	        16.8 min
scp/arcfour	      30.6 sec		51   min
scp/blowfish	      38.6 sec	1 hour   4   min 20 sec
scp/cast128	1 min  6.3 sec	1 hour  50   min 30 dec
scp/3des	2 min 45.5 sec  4 hours 35   min

I'm not asking for -c none to be the default, or even to be encouraged,
just that you not take it away as an option.  Leave the coddling to
Microsoft!  At the very least, please make available an alternative openssh
package with -c none turned on.

Thanks,

--jh--


Version-Release number of selected component (if applicable):
all Red Hat has ever released, including update in 7.2

How reproducible:
Always

Steps to Reproduce:
1. make a 10 GB dataset
2. transfer it with rsh
3. transfer it with ssh -c arcfour, experience long wait
4. go back the next day and restore your backup to eliminate hacking damage
from forgotten .rhosts file, try to remember what files you edited since
the backup, and how
5. wish you could have transferred it with ssh -c none


Additional info:
Comment 1 Nalin Dahyabhai 2002-03-07 12:26:52 EST
The OpenSSH team makes a conscious decision to not support the "none" cipher,
and that's not a decision I feel good about overriding.  I'm marking this as
deferred pending a firmer opinion one way or another.
Comment 2 Joe Harrington 2002-03-07 13:05:07 EST
I see that the package is produced by Red Hat from openssh.com sources.

Do you mean the openssh team at Red Hat, or the independent OSS development
team?  If you mean the team at openssh.com, it shouldn't be a difficult matter
to enable -c when configuring the sources.  It doesn't involve patching the
sources or anything like that; -c is supported in the sources.  If you mean at
Red Hat, could you bring the issue up with them directly, rather than waiting
for them to happen by this bug (which they may never since you've closed it)?  I
think it is quite out of line with the Linux philosophy to disable a feature
because you think users are not smart enough to handle it.  The docs are quite
clear against its use and it's not something people would accidentally turn on.

Thanks,

--jh--

Note You need to log in before you can comment on or make changes to this bug.