disable encryption in ssh - SSH

This is a discussion on disable encryption in ssh - 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 ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: disable encryption in ssh

  1. 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

  2. Re: disable encryption in ssh

    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

  3. Re: disable encryption in ssh

    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.


  4. Re: disable encryption in ssh

    Dennis 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.

  5. Re: disable encryption in ssh

    On Nov 19 2007, 11:06 pm, Joe Pfeiffer 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.

  6. Re: disable encryption in ssh

    jik@kamens.brookline.ma.us wrote:
    > When [...] the writer is connected directly to [...] the reader [...]


    > When the writer is connected to the reader on a TCP/IP socket [...]


    > When the writer is connected to the reader over an SSH connection [...]


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


    No, you're comparing direct connections with SSH overhead *including*
    its protocol. It might be that the cost of encryption is outweighed
    by the cost of the ssh protocol, but since you've not measured that we
    can't tell.

    > If I put the reader and writer on different hosts [...] I get an
    > average speed of 30MB/s [...]


    That's 300 Mbit/s, so it looks like you're using gigabit ethernet.

    > [...] 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.

    Have you taken a look at either ssh/scp with compression, or rsync?

    I needed to restore a corrupted 15GB data file today from a backup. Using
    a hotel WiFi connection, it took only around 4 hours. Considering my
    backup server has only a 440 Kb/s ADSL upload link, that really is some
    serious apparent compression ratio.


    > 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. [...]


    > 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.


    OK, so you've authenticated. Now I subvert your connection with a
    typical MITM attack and substitute my own data. Your trust relationship
    has been subverted and the receiving system "knows" the data it's
    received is good, even though it's bad.

    Wham bam thank you mam.

    Or not.

    Chris

  7. Re: disable encryption in ssh

    >>>>> "CD" == Chris Davies writes:

    CD> jik@kamens.brookline.ma.us wrote:
    >> When [...] the writer is connected directly to [...] the reader
    >> [...]


    >> When the writer is connected to the reader on a TCP/IP socket [...]


    >> When the writer is connected to the reader over an SSH connection
    >> [...]


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


    CD> No, you're comparing direct connections with SSH overhead
    CD> *including* its protocol. It might be that the cost of encryption
    CD> is outweighed by the cost of the ssh protocol, but since you've
    CD> not measured that we can't tell.

    >> If I put the reader and writer on different hosts [...] I get an
    >> average speed of 30MB/s [...]


    CD> That's 300 Mbit/s, so it looks like you're using gigabit ethernet.

    >> [...] when you're on a gigabit LAN, you are surely not going to be

    CD> happy abuot the fact that your transfer that should be going at
    CD> around 100MB/s is instead going at 30.

    CD> Have you taken a look at either ssh/scp with compression, or
    CD> rsync?

    CD> I needed to restore a corrupted 15GB data file today from a
    CD> backup. Using a hotel WiFi connection, it took only around 4
    CD> hours. Considering my backup server has only a 440 Kb/s ADSL
    CD> upload link, that really is some serious apparent compression
    CD> ratio.


    >> 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. [...]


    >> 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.


    CD> OK, so you've authenticated. Now I subvert your connection with a
    CD> typical MITM attack and substitute my own data. Your trust
    CD> relationship has been subverted and the receiving system "knows"
    CD> the data it's received is good, even though it's bad.

    I don't understand this. 1) Once you've gotten to the user authentication
    stage, the key exchange has already provided MITM protection. As long as
    you've verified the server's key and the server hasn't been compromised,
    MITM is not an option. 2) What does this have to do with the presence or
    lack of encryption? Data integrity is handled entirely separately.

    CD> Wham bam thank you mam.

    CD> Or not.

    CD> Chris

    --
    Richard Silverman
    res@qoxp.net


  8. Re: disable encryption in ssh

    My own need for -e none flag is to copy pirated movies on my home
    network. I would not use it for any security sensitive operation.
    I have a gigabit network and ssh encryption overheat is significant.

    i

  9. Re: disable encryption in ssh

    Chris Davies writes:
    >No, you're comparing direct connections with SSH overhead *including*
    >its protocol. It might be that the cost of encryption is outweighed
    >by the cost of the ssh protocol, but since you've not measured that we
    >can't tell.


    I'm going to give you the benefit of the doubt and assume that you're
    making a straw-man argument and you don't *really* think there's any
    possibility that the SSH protocol is more expensive than the
    encryption. Anybody who has any experience in this field knows that
    encryption is computationally expensive.

    When I'm transferring data with encrypted SSH, SSH at both ends of the
    transfer maxes out the CPU while it's running. Do really think it's
    the SSH protocol that is hosing the CPU like that? It's obviously tne
    encryption, and if the CPU is maxed out during the transfer when
    encryption is enabled, then it's rather axiomatic that the transfer
    would ran faster without encryption.

    Obviously the SSH protocol introduces some overhead. That, however,
    is not really the point at all. The overhead of the SSH protocol is
    (a) small and (b) necessary if you want to use SSH to transfer data.
    The overhead of the encryption is NOT necessary if you don't feel the
    need for your data to be encrypted.

    >> If I put the reader and writer on different hosts [...] I get an
    >> average speed of 30MB/s [...]

    >
    >That's 300 Mbit/s, so it looks like you're using gigabit ethernet.


    Um, sure I am, but I'm only using 300 Mbit of a 1000 Mbit pipe. My
    transfer is using less than one third of the bandwidth available to
    it. That's just absurd.

    >Have you taken a look at either ssh/scp with compression, or rsync?


    Use them all the time. Doesn't help when you're transferring a huge
    file for the first time, one that's already compressed, or one that
    contains data that doesn't compress well. I encounter all of these
    situations on a regular basis.

    >OK, so you've authenticated. Now I subvert your connection with a
    >typical MITM attack and substitute my own data. Your trust relationship
    >has been subverted and the receiving system "knows" the data it's
    >received is good, even though it's bad.


    Don't care. I'm on my LAN. I trust the people on my LAN. If I didn't
    trust them, I wouldn't let them on the LAN. The software should let me
    accept the risk of an unencrypted transfer if I want to.

  10. Re: disable encryption in ssh

    In comp.security.ssh jik@kamens.brookline.ma.us wrote:
    > On Nov 19 2007, 11:06 pm, Joe Pfeiffer wrote:
    >> Have you actually performed any measurements showing the overhead of
    >> encryption is noticeable?

    >
    > I have.


    There's a lot going on here besides simple encryption overhead.

    See these patches against OpenSSH.
    http://www.psc.edu/networking/projects/hpn-ssh/

    While they can remove encryption, I've never found it to improve things
    significantly. The buffer changes do much more.

    --
    Darren Dunham ddunham@taos.com
    Senior Technical Consultant TAOS http://www.taos.com/
    Got some Dr Pepper? San Francisco, CA bay area
    < This line left intentionally blank to confuse you. >

  11. Re: disable encryption in ssh

    Ignoramus25898 wrote:
    > My own need for -e none flag is to copy pirated movies on my home
    > network. I would not use it for any security sensitive operation.
    > I have a gigabit network and ssh encryption overheat is significant.
    >
    > i


    Then use bittorrent, or rsync.

  12. Re: disable encryption in ssh

    Nico Kadel-Garcia writes:
    >Ignoramus25898 wrote:
    >> My own need for -e none flag is to copy pirated movies on my home
    >> network. I would not use it for any security sensitive operation.
    >> I have a gigabit network and ssh encryption overheat is significant.
    >>
    >> i

    >
    >Then use bittorrent, or rsync.


    Neither torrent nor rsync will help improve performance when
    transferring a large file for the first time on an internal network.

    --
    Help stop the genocide in Darfur!
    http://www.genocideintervention.net/

  13. Re: disable encryption in ssh

    ddunham@taos.com (Darren Dunham) writes:
    >In comp.security.ssh jik@kamens.brookline.ma.us wrote:
    >> On Nov 19 2007, 11:06 pm, Joe Pfeiffer wrote:
    >>> Have you actually performed any measurements showing the overhead of
    >>> encryption is noticeable?

    >>
    >> I have.

    >
    >There's a lot going on here besides simple encryption overhead.


    True enough.

    >See these patches against OpenSSH.
    >http://www.psc.edu/networking/projects/hpn-ssh/


    If these performance improvements are completely compatible with the
    SSH protocol, then why haven't they been folded back into the OpenSSH
    distribution?

    >While they can remove encryption, I've never found it to improve things
    >significantly. The buffer changes do much more.


    I hacked together an openssh that supports disabling encryption
    (although it doesn't work with UsePrivilegeSeparation set to yes,
    something that would have to be fixed by people more knowledgeable than
    I were this change to be put into the distribution), and I saw my
    throughput when transferring over ssh via localhost go up from 41MB/s
    with encryption to 54MB/s without it. 32% seems like a pretty
    significant improvement to me.

    It doesn't have to be either/or. Why not do both?

    --
    Help stop the genocide in Darfur!
    http://www.genocideintervention.net/

  14. Re: disable encryption in ssh

    In comp.security.ssh Jonathan Kamens wrote:
    > ddunham@taos.com (Darren Dunham) writes:


    >>See these patches against OpenSSH.
    >>http://www.psc.edu/networking/projects/hpn-ssh/

    >
    > If these performance improvements are completely compatible with the
    > SSH protocol, then why haven't they been folded back into the OpenSSH
    > distribution?


    I don't know either group, so I have no idea. I believe the question
    has come up before.

    >>While they can remove encryption, I've never found it to improve things
    >>significantly. The buffer changes do much more.

    >
    > I hacked together an openssh that supports disabling encryption
    > (although it doesn't work with UsePrivilegeSeparation set to yes,
    > something that would have to be fixed by people more knowledgeable than
    > I were this change to be put into the distribution), and I saw my
    > throughput when transferring over ssh via localhost go up from 41MB/s
    > with encryption to 54MB/s without it. 32% seems like a pretty
    > significant improvement to me.
    >
    > It doesn't have to be either/or. Why not do both?


    That's what the patches do, yes?

    Since I wasn't doing localhost transfers, my encryption speed was
    keeping up with the pipe. We got around an 80% reduction in time due to
    the buffer changes, and disabling encryption seemed like it might be
    making it go a little faster, but it wasn't significant to our eyes.
    Localhost is a different ballgame.

    --
    Darren Dunham ddunham@taos.com
    Senior Technical Consultant TAOS http://www.taos.com/
    Got some Dr Pepper? San Francisco, CA bay area
    < This line left intentionally blank to confuse you. >

  15. Re: disable encryption in ssh

    ["Followup-To:" header set to comp.security.ssh.]
    On 2008-01-13, Jonathan Kamens wrote:
    > ddunham@taos.com (Darren Dunham) writes:

    [...]
    >>See these patches against OpenSSH.
    >>http://www.psc.edu/networking/projects/hpn-ssh/

    >
    > If these performance improvements are completely compatible with the
    > SSH protocol, then why haven't they been folded back into the OpenSSH
    > distribution?


    The dynamic window adjust part of the change only help on systems that
    dynamically adjust the TCP window size. The HPN work did prompt the
    increase of the default SSH channel window size (a simpler change) to
    ~2MB in OpenSSH 4.7, which is large enough for the majority of network
    paths (ie if you don't have transcontinental gigabit or faster).

    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.

  16. Re: disable encryption in ssh

    In comp.security.ssh 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?

    Which IXP4XX? At least the 435 has a crypto accelerator. I think the 425
    also has it. Not sure about 455 or 465. If SSH could be coded to make use
    of that accelerator, that would be a big plus.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-01-25-0838@ipal.net |
    |------------------------------------/-------------------------------------|

  17. Re: disable encryption in ssh

    On 2008-01-25, phil-news-nospam@ipal.net wrote:
    > Which IXP4XX? At least the 435 has a crypto accelerator. I think the 425
    > also has it. Not sure about 455 or 465. If SSH could be coded to make use
    > of that accelerator, that would be a big plus.


    For OpenSSH, if OpenSSL's crypto libraries have a hardware 'engine" for
    it, OpenSSH can be configured to use it ("./configure --with-ssl-engine").

    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.

+ Reply to Thread