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" <adcon...@0c3.net> > Betreff: SSH2 Optimisation on 68060: findings > Datum: 28. Februar 2004 11:42:02 MEZ > An: <m68k-bu...@nocrew.org> > Kopie: "'Colin Watson'" <cjwat...@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-bu...@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 -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/a88b4265-089b-4f20-818f-6a07f3e67...@2013.bluespice.org
