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" > Betreff: SSH2 Optimisation on 68060: findings > Datum: 28. Februar 2004 11:42:02 MEZ > An: > Kopie: "'Colin Watson'" > > 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 port
Re: Fwd: SSH2 Optimisation on 68060: findings
Ingo Jürgensmann writes: >> 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. There is no need to rebuild the client, setting KexAlgorithms in the ssh config is enough. Note that there are now more algorithms that are preferred over diffie-hellman-group-exchange-sha1. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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/87mwqz2xkt@igel.home
Re: Fwd: SSH2 Optimisation on 68060: findings
Ingo J�rgensmann dixit: (You want to use UTF-8 nowadays.) >Maybe the KEX problem is re-introduced in newest libssh2-1 package. OpenSSH uses OpenSSL, not libssh, which is a completely orthogonal, separate implementation of the SSH protocol. bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs -- 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/pine.bsm.4.64l.1306091426180.14...@herc.mirbsd.org
Re: SSH2 Optimisation on 68060: findings
Am 09.06.2013 um 16:27 schrieb Thorsten Glaser : >> Maybe the KEX problem is re-introduced in newest libssh2-1 package. > OpenSSH uses OpenSSL, not libssh, which is a completely > orthogonal, separate implementation of the SSH protocol. Arrakis: ii libssl0.9.70.9.7k-3.1 m68k SSL shared libraries ii libssl0.9.80.9.8o-7 m68k SSL shared libraries ii libssl1.0.0:m68k 1.0.1e-2 m68k SSL shared libraries ii openssl1.0.1e-2 Elgar: ii libssl0.9.80.9.8c-4etch3+m68k1 m68k SSL shared libraries ii libssl1.0.0:m68k 1.0.1e-3 m68k SSL shared libraries ii openssl1.0.1e-3 -- 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/568573f4-8057-4314-ade3-c76696927...@2013.bluespice.org
Re: Relocation of Elgar to FU Berlin
On Sun, Jun 09, 2013 at 12:40:05PM +1200, schmitz wrote: > Ingo, > >Thanks for picking it up and hosting it! :-) > > Thanks to Adrian for giving it a new home, and let's not forget to > thank you for hosting it all this time! yup! > >>- replace the system disk with a new 250GB or 500GB drive > > > >Remember that AmigaOS is still 3.1 and it should stay that way. > >So, while it's no problem to replace the 40 GB disk by a larger > >one (it just needs some time), IDE is still slow on A4000s and we > >should prefer SCSI disks for performance reasons anyway. Actually, > >there is not really need for >40 GB disks, IMHO. > > The system disk won't need that much space - even for the buildd > chroots and scratch space we won't quite need as much. But let's not > forget the old IDE disks will wear out some time, and a new disk > might be what keeps elgar running a bit longer. > > Christian had procured IDE to SCSI adapters years ago - not sure > these are still available for sale anywhere. That would be about the > only option to hook up a large disk via SCSI. (We'd also need to > test and debug the SCSI driver, of course). They are EXPENSIVE... I can't believe that I paid 100EUR per piece. But nowadays you want SATA-IDE adapters, they run at about the same price, I think they were from acard. Sorry, I don't have my bookmarks here, I just arrived in Thun. And suddenly things don't seem so expensive anymore ;-) Other IDE options are the CF-IDE (or SD-IDE) converters, remember, the one I use to resurrect my Falcon? For booting that should work, but of cource not for chroot storage. > Concur - we had a break-in into kullervo or crest at some stage a > few years back, and that was through exim. Better make it accept > mail from a smarthost only. Do we have a smarthost for that? At the moment kullervo can receive email directly. Well, through a couple of hoops, but I am not running fetchmail on kullervo. I thought that when kullervo returns to NMMN, I would return to the old setup, since I do not have a mail server on the NMMN network. Christian -- 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/20130609155107.gb7...@chumley.earth.sol
Re: Relocation of Elgar to FU Berlin
Am 09.06.2013 um 17:51 schrieb "Christian T. Steigies" : >> Concur - we had a break-in into kullervo or crest at some stage a >> few years back, and that was through exim. Better make it accept >> mail from a smarthost only. > Do we have a smarthost for that? At the moment kullervo can receive email > directly. Well, through a couple of hoops, but I am not running fetchmail on > kullervo. I thought that when kullervo returns to NMMN, I would return to > the old setup, since I do not have a mail server on the NMMN network. Using a smarthost is the way to go for Elgar. Unfortunately it seems quite difficult an FU Berlin to get a smarthost assigned. I would prefer mailrouting through smarthosts to using fetchmail or such. Currently I'm running a pptp tunnel on Elgar to make mailrouting work. -- 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/2eb92133-f4ba-475d-a3a6-921824f92...@2013.bluespice.org
Re: Relocation of Elgar to FU Berlin
On 06/09/2013 05:51 PM, Christian T. Steigies wrote: Christian had procured IDE to SCSI adapters years ago - not sure these are still available for sale anywhere. That would be about the only option to hook up a large disk via SCSI. (We'd also need to test and debug the SCSI driver, of course). They are EXPENSIVE... I can't believe that I paid 100EUR per piece. But nowadays you want SATA-IDE adapters, they run at about the same price, I think they were from acard. Sorry, I don't have my bookmarks here, I just arrived in Thun. And suddenly things don't seem so expensive anymore ;-) Other IDE options are the CF-IDE (or SD-IDE) converters, remember, the one I use to resurrect my Falcon? For booting that should work, but of cource not for chroot storage. I have a large collection of 36GB SCA [1] hard disks, some of them are even 72GB. Those were once part of a large Alpha server and could probably be hooked up to the Amigas with an adapter much cheaper. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/51b4ca86.9020...@physik.fu-berlin.de
Re: Relocation of Elgar to FU Berlin
Adrian, On Sun, Jun 09, 2013 at 08:33:42PM +0200, John Paul Adrian Glaubitz wrote: > On 06/09/2013 05:51 PM, Christian T. Steigies wrote: > >>Christian had procured IDE to SCSI adapters years ago - not sure > >>these are still available for sale anywhere. That would be about the > >>only option to hook up a large disk via SCSI. (We'd also need to > >>test and debug the SCSI driver, of course). > > > >They are EXPENSIVE... I can't believe that I paid 100EUR per piece. But > >nowadays you want SATA-IDE adapters, they run at about the same price, I > >think they were from acard. Sorry, I don't have my bookmarks here, I just > >arrived in Thun. And suddenly things don't seem so expensive anymore ;-) > >Other IDE options are the CF-IDE (or SD-IDE) converters, remember, the one I > >use to resurrect my Falcon? For booting that should work, but of cource not > >for chroot storage. > > I have a large collection of 36GB SCA [1] hard disks, some of them are > even 72GB. Those were once part of a large Alpha server and could > probably be hooked up to the Amigas with an adapter much cheaper. True - I have one or two of these adapters spare over here that could be used. Are these SCS disks wide or narrow data path? I had trouble with the wide ones via adapter on my PC, can't remember whether these worked on m68k. Cheers, Michael -- 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/20130609201638.ga17...@mail.biophys.uni-duesseldorf.de
Re: Relocation of Elgar to FU Berlin
On Sun, Jun 9, 2013 at 10:16 PM, Michael Schmitz
wrote:
> True - I have one or two of these adapters spare over here that could be
> used. Are these SCS disks wide or narrow data path? I had trouble with the
> wide ones via adapter on my PC, can't remember whether these worked on m68k.
Any chance you connected the wide disk through a wide/narrow adapter
to the narrow connector of a _wide_ SCSI card? In that case, the SCSI
chip still sees a wide disk, while the data path is narrow.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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/CAMuHMdVk+Ji=KsNVCHGcZqyzQV-pKS+NW0O=cgq15tcxdsx...@mail.gmail.com
Re: Relocation of Elgar to FU Berlin
On Sun, Jun 9, 2013 at 5:51 PM, Christian T. Steigies wrote:
>> Christian had procured IDE to SCSI adapters years ago - not sure
>> these are still available for sale anywhere. That would be about the
>> only option to hook up a large disk via SCSI. (We'd also need to
>> test and debug the SCSI driver, of course).
>
> They are EXPENSIVE... I can't believe that I paid 100EUR per piece. But
Seems like a good deal, considering how much I paid for my first 80 MiB
hard drive ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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/camuhmdx8ykuijycgznves5jcmcyhsvhy_bksofckve9fgoo...@mail.gmail.com
