[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none"

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=877





------- Additional Comments From mohit_aron at hotmail.com  2004-06-08 05:41 -------
> My view is if a company wants to hack mac=none, ciphers=none into their
> SSH code.  That's fine. Not as if it is that hard or complex.

I took a look at the way my own sysadmins have added the "-c none". Seems
like they've had to add a "none2" for SSH2 (as I mentioned in my initial 
posting) to get around the fact that "ciphers" in "cipher.c" already 
contains a "none" for SSH1. Looks pretty arcane to me. The sysadmins probably
wanted to minimize code changes. Had the developers supported a "none" in
SSH2, that would have been a much better job. In addition, I don't see 
support for a "hmac=none" in our code - possibly they didn't realize that
hmac also eats away the performance. So having users do these code changes
is certainly far from optimal.

> > 10 Mbps networks hardly imposed any ovhd on the CPUs - my company is 
> > starting to use 1 Gbps networks - there the ovhd can be significant.
>
> Sounds like you really want to invest in encryption hardware.  Sokeris group
> sells a nice PCI/PCMCIA solution that runs under BSD/Linux for a very nice
> price.  I've seen a few gigabit cards with encryption chips right on it.  
> Which would be another good path to look at. That would make more pratical 
> sense than gutting security from an application.

I thought ssh encryption works at user-level - how would having encryption
in the network cards help ? It might help for VPNs where the IPsec resides
in the kernel. Anyhow, with tight IT budgets these days, a solution that
requires expensive hardware for hundreds of machines is not viable.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.