disable encryption in ssh

I have ported ssh onto my IXP4XX platform running snapgear 2.6.17. I
like to disable encryption in ssh. This would allow us to continue to
make use of the SSH tunnels but without the overhead of encryption.
Has anyone done it and how do I disable encryption in ssh?

Thanks

Dennis wrote:
> I have ported ssh onto my IXP4XX platform running snapgear 2.6.17. I
> like to disable encryption in ssh. This would allow us to continue to
> make use of the SSH tunnels but without the overhead of encryption.
> Has anyone done it and how do I disable encryption in ssh?

You cannot disable encryption, at least not in any standards-compatible
way. You can pick weaker and/or faster ciphers if you're really worried
about overhead. ARCFour and Blowfish are pretty fast. DES is slow.

For OpenSSH:
man ssh_config
man sshd_config

On 2007-11-19, Dennis <(E-Mail Removed)> wrote:
> I have ported ssh onto my IXP4XX platform running snapgear 2.6.17. I
> like to disable encryption in ssh. This would allow us to continue to
> make use of the SSH tunnels but without the overhead of encryption.
> Has anyone done it and how do I disable encryption in ssh?

Use tenet ?

(running and ducking :-)


--
There is an art, it says, or rather, a knack to flying.
The knack lies in learning how to throw yourself at the ground and miss.
Douglas Adams

On 2007-11-19, Rikishi 42 <(E-Mail Removed)> wrote:
> On 2007-11-19, Dennis <(E-Mail Removed)> wrote:
>> I have ported ssh onto my IXP4XX platform running snapgear 2.6.17. I
>> like to disable encryption in ssh. This would allow us to continue to
>> make use of the SSH tunnels but without the overhead of encryption.
>> Has anyone done it and how do I disable encryption in ssh?
>
> Use tenet ?
Use *telnet*.....

Dawn..., managed to have a typo, insuch a small phrase.
Guess it's bedtime for old people.


--
There is an art, it says, or rather, a knack to flying.
The knack lies in learning how to throw yourself at the ground and miss.
Douglas Adams

On Mon, 19 Nov 2007 16:57:16 -0600, Allen Kistler wrote:

> Dennis wrote:
>> I have ported ssh onto my IXP4XX platform running snapgear 2.6.17. I
>> like to disable encryption in ssh. This would allow us to continue to
>> make use of the SSH tunnels but without the overhead of encryption. Has
>> anyone done it and how do I disable encryption in ssh?
>
> You cannot disable encryption, at least not in any standards-compatible
> way.

I disagree. RFC 4253 specifies that, during handshake, client and
server can agree not to use any bulk encryption.

"H.K. Kingston-Smith" <HKK-(E-Mail Removed)> writes:

> On Mon, 19 Nov 2007 16:57:16 -0600, Allen Kistler wrote:
>
>> Dennis wrote:
>>> I have ported ssh onto my IXP4XX platform running snapgear 2.6.17. I
>>> like to disable encryption in ssh. This would allow us to continue to
>>> make use of the SSH tunnels but without the overhead of encryption. Has
>>> anyone done it and how do I disable encryption in ssh?
>>
>> You cannot disable encryption, at least not in any standards-compatible
>> way.
>
> I disagree. RFC 4253 specifies that, during handshake, client and
> server can agree not to use any bulk encryption.

That may be the case, but all? current ssh client/server applications
have at least 3DES as the default mandatory crypto.

I believe that you would have to modify the configure options for both
sides and recompile with a '--with-none' option to allow for disabled
crypto. The default builds use '--without-none' to force encryption.

Short of that, if you want to reduce overhead to a minimum, BLOWFISH is
probably the way to go.

HTH,

Marc Schwartz

Dennis <(E-Mail Removed)> writes:

> I have ported ssh onto my IXP4XX platform running snapgear 2.6.17. I
> like to disable encryption in ssh. This would allow us to continue to
> make use of the SSH tunnels but without the overhead of encryption.
> Has anyone done it and how do I disable encryption in ssh?

Have you actually performed any measurements showing the overhead of
encryption is noticeable?

I've got no idea as to the actual answer to your question, but having
run SSH talking to 486s and ARMs, I just can't believe it matters.

On Mon, 19 Nov 2007 20:42:35 -0600, Marc Schwartz wrote:

> "H.K. Kingston-Smith" <HKK-(E-Mail Removed)> writes:
>
>> On Mon, 19 Nov 2007 16:57:16 -0600, Allen Kistler wrote:
>>
>>> Dennis wrote:
>>>> I have ported ssh onto my IXP4XX platform running snapgear 2.6.17. I
>>>> like to disable encryption in ssh. This would allow us to continue to
>>>> make use of the SSH tunnels but without the overhead of encryption.
>>>> Has anyone done it and how do I disable encryption in ssh?
>>>
>>> You cannot disable encryption, at least not in any
>>> standards-compatible way.
>>
>> I disagree. RFC 4253 specifies that, during handshake, client and
>> server can agree not to use any bulk encryption.
>
> That may be the case, but all? current ssh client/server applications
> have at least 3DES as the default mandatory crypto.

3DES must be supported all right, but that does not imply that it
must be used to the detriment of no encryption. Client and server are
free to agree not to use any bulk encryption. It is up to implementations
to allow users to do such a thing.

> I believe that you would have to modify the configure options for both
> sides and recompile with a '--with-none' option to allow for disabled
> crypto. The default builds use '--without-none' to force encryption.

I believe that you are talking about OpenSSH. That's a different
story. I am talking about what is allowed by the standards. But, if
OpenSSH is what the OP ported then your advice is probably sound.

> Short of that, if you want to reduce overhead to a minimum, BLOWFISH is
> probably the way to go.

I believe that AES-128 is likely to perform better than Blowfish.

When I ported SSH to Snapgear running on our IXP4XX platform, I port
openssl-0.9.7c.tar.gz. The performance is pretty slow. Wondering how
we can speed it up...



On Nov 20, 8:29 am, "H.K. Kingston-Smith" <HK...@yahoo.com> wrote:
> On Mon, 19 Nov 2007 20:42:35 -0600, Marc Schwartz wrote:
> > "H.K. Kingston-Smith" <HK...@yahoo.com> writes:
>
> >> On Mon, 19 Nov 2007 16:57:16 -0600, Allen Kistler wrote:
>
> >>> Dennis wrote:
> >>>> I have ported ssh onto my IXP4XX platform running snapgear 2.6.17. I
> >>>> like to disable encryption in ssh. This would allow us to continue to
> >>>> make use of the SSH tunnels but without the overhead of encryption.
> >>>> Has anyone done it and how do I disable encryption in ssh?
>
> >>> You cannot disable encryption, at least not in any
> >>> standards-compatible way.
>
> >> I disagree. RFC 4253 specifies that, during handshake, client and
> >> server can agree not to use any bulk encryption.
>
> > That may be the case, but all? current ssh client/server applications
> > have at least 3DES as the default mandatory crypto.
>
> 3DES must be supported all right, but that does not imply that it
> must be used to the detriment of no encryption. Client and server are
> free to agree not to use any bulk encryption. It is up to implementations
> to allow users to do such a thing.
>
> > I believe that you would have to modify the configure options for both
> > sides and recompile with a '--with-none' option to allow for disabled
> > crypto. The default builds use '--without-none' to force encryption.
>
> I believe that you are talking about OpenSSH. That's a different
> story. I am talking about what is allowed by the standards. But, if
> OpenSSH is what the OP ported then your advice is probably sound.
>
> > Short of that, if you want to reduce overhead to a minimum, BLOWFISH is
> > probably the way to go.
>
> I believe that AES-128 is likely to perform better than Blowfish.

On Nov 19 2007, 11:06 pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
> Have you actually performed any measurements showing the overhead of
> encryption is noticeable?

I have.

I have a script which generates data and another script which reads it
and times how long it took for the data to arrive. These scripts also
know how to send data over a socket, to emulate what the performance
of an unencrypted SSH stream might be.

When stdout of the writer is connected directly to stdin of the
reader, I get an average speed on a 60-second test of 128MB/s.

When the writer is connected to the reader on a TCP/IP socket over
127.0.0.1, I get an average speed of 118MB/s.

When the writer is connected to the reader over an SSH connection to
127.0.0.1 using the arcfour cipher (the fastest available cipher,
according to my experiments), I get an average speed of 16MB/s. Note
that this is with a single 2.4GHz CPU.

In other words, the encrypted transfer speed is *** 86% SLOWER ***
than the unencrypted transfer speed.

If I put the reader and writer on different hosts to spread the CPU
load of encrypting and decrypting across two hosts instead of one,
then I get an average speed of 30MB/s, which is still 74% slower than
the unencrypted transfer speed.

You might not notice this if you're on a 10Mbit or even 100Mbit
network, since SSH can still encrypt and decrypt faster than the data
can be transferred over the network. But when you're on a gigabit
LAN, you are surely not going to be happy abuot the fact that your
transfer that should be going at around 100MB/s is instead going at
30.

Early versions of SSH had the "-e none" option to disable encryption
on the data channel. I have always regretted that this option was
removed, and I've never understood why. I mean, I could obviously
understand not making it the default. I could even understand
requiring that it be specified on the command line, i.e., not allowing
it to be set in the config file, if you wanted to be extra-paranoid
about making sure that people understand what they're doing when they
create a connection without encryption. But removing the option
entirely? I think that sucks, and I wish the maintainers of OpenSSH
would put it back.

When I'm transferring a file over my LAN, I don't need the file to be
encrypted. I just need a secure way to authenticate to the other end
when initiating the transfer.