Fwd: SSH2 Optimisation on 68060: findings
Hi!
From my unrelevant point of view we might be faced with the KEX problem on SSH again.
For some time now I couldn't connect anymore to Elgar. The connection always timed out:
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Debian-4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
Connection closed by 160.45.66.25
Maybe the KEX problem is re-introduced in newest libssh2-1 package. On Arrakis, where I don't have any problems connecting with SSH, there are the following packages installed:
ii libssh2-1:m68k 1.4.2-1.1
ii openssh-client 1:6.0p1-4
ii openssh-server 1:6.0p1-4
On Elgar there these versions installed:
ii libssh2-1:m68k 1.4.3-1
ii openssh-client 1:6.0p1-4
ii openssh-server 1:6.0p1-4
As a workaround I used ssh -o ConnectTimeout=600 elgar.buildd.net to be able to login again, but that's not a solution. In 2004 Adam Conrad wrote the following findings about the KEX problem:
Anfang der weitergeleiteten Nachricht:
> Von: "Adam Conrad" <adconrad@0c3.net>
> Betreff: SSH2 Optimisation on 68060: findings
> Datum: 28. Februar 2004 11:42:02 MEZ
> An: <m68k-build@nocrew.org>
> Kopie: "'Colin Watson'" <cjwatson@debian.org>
>
> Well, I just spent an evening mucking with openssl and openssh, and I
> have some interesting test results to report, and a shiny new SSH setup
> on a4000t that makes me a much less frustrated buildd admin.
>
> For starters, there was much talk of optimising openssl for the 68060.
> I gave in to this a week or two ago and installed gcc-3.0 in a Woody
> chroot (necessary, since gcc-2.95 doesn't do -m68060) and rebuilt
> openssl with -m68060. The results were less than stellar, to say the
> least. It did speed things up, but only by a few seconds in the best
> cases.
>
> Then, along came jt7's local admin (whose name I can't recall right now,
> sorry), and pointed out to me that "ssh2 connections to jt7 are
> perfectly speedy, I don't know what you're complaining about." I asked
> for an account, tested, waited ages to connect, and proceeded to call
> him a dirty stankin' liar. Then it was discovered that he was using the
> ssh client from ssh.com, whereas I was using either openssh or PuTTY,
> depending on which OS I was stuck with at any given moment. A quick
> test with the ssh.com client indeed showed that connections to an '060
> CAN be fast. But how?
>
> With some help from Colin Watson, it was discovered that the ssh.com
> client doesn't support (or, at least, doesn't advertise support for) the
> "diffie-hellman-group-exchange-sha1" key exchange method. This KEX
> isn't strictly required to match ssh2 spec, but PuTTY and OpenSSH both
> support it, while ssh.com (at least their older freely-available client,
> not sure about newer ones) doesn't.
>
> After reading up on what this KEX does[1], and why it might be a slight
> security risk to turn it off, I quickly hacked support for it out of the
> openssh source and rebuilt for m68k. The following table of test
> results is what came of this. Well, that and faster logins to my
> buildd.
>
> The results are in 4 sections, each with 2 subsections. The 2
> subsections show three test runs each of an ssh connection from
> lucifer[2] to a4000t[3], with .bash_profile running "logout" as soon as
> the shell is run, and an ssh connection from a4000t to newraff[4],
> running a wanna-build query on the state of a package.
>
> Keep in mind that the only machine running "hacked" ssh/ssl binaries is
> a4000t, the other two machines in this test are "stock".
>
> The 4 sections are as follows:
> 1. Default Woody (+security) packages
> 2. Default Woody ssh, with '060 optimised openssl
> 3. kex-optimised ssh, with default Woody openssl
> 4. kex-optimised ssh, with '060 optimised openssl
>
> As we can see, optimising openssl for '060 helps a little bit, but not
> enough that anyone would really notice or care (part of this may be in
> part due to gcc-3.0 sucking fat chicks through straws, and perhaps a
> gcc-3.3/3.4-compiled '060 libssl would fare a bit better in these tests,
> but that's merely conjecture at this point), however dropping support
> for the new(ish) KEX drastically improves performance. The small
> tradeoff in security (at least at this point in time, the new KEX may
> become more important in a few years) for the massive improvement in
> speed seems worth it to me.
>
> The only thing left to do is change this KEX support from "edit a
> #define and recompile" to "make it a config option for both client and
> server, and have a big blinking warning in the manpage about it lowering
> security". Given that openssh supports ssh1 without much for blinking
> warnings, the latter portion may not even be necessary.
>
> Last, but not least, the packages are available for download[5] from
> a4000t, however anyone running a DSA-LDAPed host (crest, kullervo?)
> can't use them, because you need a special build of ssh. If DSA
> sanctions this source change as being sane and not much of a risk, then
> I can build hacked versions of the DSA ssh as well for you.
>
> ... Adam
>
> (base)adconrad@a4000t:~$ COLUMNS=132 dpkg -l libssl0.9.6 ssh | grep ^ii
> ii libssl0.9.6 0.9.6c-2.woody.4
> ii ssh 3.4p1-1.woody.3
>
> ------ lucifer -> a4000t ------ ------ a4000t -> newraff ------
> real 1m33.890s real 1m32.429s
> user 0m0.370s user 0m5.000s
> sys 0m0.020s sys 0m56.340s
>
> real 1m32.308s real 1m32.442s
> user 0m0.380s user 0m4.880s
> sys 0m0.000s sys 0m55.640s
>
> real 1m32.785s real 1m31.911s
> user 0m0.360s user 0m4.980s
> sys 0m0.000s sys 0m56.640s
> ------------------------------- -------------------------------
>
> (base)adconrad@a4000t:~$ COLUMNS=132 dpkg -l libssl0.9.6 ssh | grep ^ii
> ii libssl0.9.6 0.9.6c-2.woody.5+060
> ii ssh 3.4p1-1.woody.3
>
> ------ lucifer -> a4000t ------ ------ a4000t -> newraff ------
> real 1m26.539s real 1m24.542s
> user 0m0.360s user 0m13.160s
> sys 0m0.020s sys 0m41.830s
>
> real 1m32.647s real 1m24.577s
> user 0m0.380s user 0m13.560s
> sys 0m0.020s sys 0m41.180s
>
> real 1m23.136s real 1m24.420s
> user 0m0.370s user 0m13.480s
> sys 0m0.010s sys 0m44.020s
> ------------------------------- -------------------------------
>
> (base)adconrad@a4000t:~$ COLUMNS=132 dpkg -l libssl0.9.6 ssh | grep ^ii
> ii libssl0.9.6 0.9.6c-2.woody.4
> ii ssh 3.4p1-1.woody.3+buildd
>
> ------ lucifer -> a4000t ------ ------ a4000t -> newraff ------
> real 0m14.742s real 0m15.810s
> user 0m0.090s user 0m1.090s
> sys 0m0.020s sys 0m8.250s
>
> real 0m14.730s real 0m15.612s
> user 0m0.070s user 0m1.180s
> sys 0m0.020s sys 0m8.150s
>
> real 0m14.770s real 0m15.571s
> user 0m0.090s user 0m0.960s
> sys 0m0.010s sys 0m8.360s
> ------------------------------- -------------------------------
>
> (base)adconrad@a4000t:~$ COLUMNS=132 dpkg -l libssl0.9.6 ssh | grep ^ii
> ii libssl0.9.6 0.9.6c-2.woody.5+060
> ii ssh 3.4p1-1.woody.3+buildd
>
> ------ lucifer -> a4000t ------ ------ a4000t -> newraff ------
> real 0m14.258s real 0m18.862s
> user 0m0.070s user 0m2.400s
> sys 0m0.040s sys 0m7.270s
>
> real 0m13.988s real 0m14.458s
> user 0m0.110s user 0m2.420s
> sys 0m0.000s sys 0m6.150s
>
> real 0m13.759s real 0m14.813s
> user 0m0.070s user 0m2.500s
> sys 0m0.020s sys 0m6.160s
> ------------------------------- -------------------------------
>
> [1]
> http://vesuvio.ipv6.cselt.it/internet-drafts/draft-ietf-secsh-dh-group-e
> xchange-04.txt
> [2] lucifer is a PowerPC750 533Mhz with 384 MB of RAM, running Sid
> [3] a4000t is a 68060 56Mhz with 128 MB of RAM, running Woody
> [4] newraff is a dual P4 Xeon 2.8GHz with 6GB of RAM, running Woody
> [5] http://a4000t.hk-soft.net/~adconrad/
>
>
> _______________________________________________
> M68k-build mailing list
> M68k-build@nocrew.org
> http://mailman.nocrew.org/cgi-bin/mailman/listinfo/m68k-build
>
--
Ciao... // Fon: 0381-2744150
Ingo \X/ http://blog.windfluechter.net
gpg pubkey: http://www.juergensmann.de/ij_public_key.asc
Reply to: