From openssh-unix-dev at kaleta.sk Sat Oct 1 05:52:10 2005 From: openssh-unix-dev at kaleta.sk (Kaleta Stanley) Date: Fri, 30 Sep 2005 21:52:10 +0200 (CEST) Subject: idea against hacks - help to IDS of a new generation In-Reply-To: References: <20050929212927.16011.qmail@cdy.org> Message-ID: Hello, thank you for your answers ;) sshd is not only one source for intrussion detection for sure ;) i'll conciliate with syslog ;) br Stanley On Fri, 30 Sep 2005, Damien Miller wrote: > On Thu, 29 Sep 2005, Peter Stuge wrote: > >> On Thu, Sep 29, 2005 at 10:22:03PM +0200, Kaleta Stanley wrote: >>> what about to add "optional action" as parameter of sshd >>> (could be used for IDS' ) >>> in case of intrussion detection (anyway logged to syslog) >> >> Both your suggestions have been seen before, and the answer is that >> OpenSSH already exports the needed information through syslog, and >> that's where you (and tools) should look in order to make any >> decisions based on failed logins. > > Yes, and at the risk of repeating myself: a system that monitors and > reacts to system logs can help with *all* password guessing attacks, not > just those that happen to target ssh. > > -d > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From imorgan at nas.nasa.gov Tue Oct 4 03:34:54 2005 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 3 Oct 2005 10:34:54 -0700 (PDT) Subject: .spec file for SLES 9 Message-ID: <200510031734.j93HYsZj015753@sun601.nas.nasa.gov> Hello all, I'm gearing up for an RPM deployment of 4.2p1 on SuSE (SLES 9). However, the files under contrib/suse in the OpenSSH distribution appear to be out-of-date. In particular, SuSE seems to handle init scripts quite differently now. So, is anyone building local RPMs for SuSE? If so, could you post the .spec file you are using? Is there any interest in updating the contrib/suse section? I've done some initial work, but since I'm new to SuSE I defer to the experience of others. Thanks -- Iain Morgan From alan.cl.wong at nokia.com Tue Oct 4 13:57:01 2005 From: alan.cl.wong at nokia.com (alan.cl.wong at nokia.com) Date: Tue, 4 Oct 2005 12:57:01 +0900 Subject: HPH-SSH code incorporation Message-ID: Hi, We are deciding on to either entirely use HPH code to our OpenSSH or not for systems globally and I come down to a question. If HPH-SSH code is such an improvement to network performance for OpenSSH, then why has it not been incorporated to the OpenSSH code? Is there a reason? Is it because there are problems with the HPH-SSH code? Since the code has been out for a time and still has not been incorporated to the OpenSSH code. It creates doubt of there must be a reason why the OpenSSH group has not incorporated the patch. There are concerns of code scrutiny and review if it is not incorporated. OpenSSH has now become not just an application but a medium for data transfer and that means network performance is very critical. If network performance can be increased without decrease in security then it would make OpenSSH even more attractive. So the question is is there a reason why the OpenSSH group decided not to incorporate the code into theirs? Cheers, -Alan Alan CL. Wong R&D IT Security Team Leader Nokia From senthilkumar_sen at hotpop.com Tue Oct 4 19:19:43 2005 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Tue, 4 Oct 2005 14:49:43 +0530 Subject: GSSAPI Auth in SSH Message-ID: <44b801c5c8c4$c3f55e70$220110ac@sekco> Hello All, I noticed some different behaviour of GSSAPI Authentication mechanism in SSH and like to know the reasons for such behaviour. If I try GSSAPI auth for a user whose principal is not stored in KDC, the GSSAPI auth method is tried 2 times and it fails. If the user is stored in KDC and not having valid credentials, then SSHD tries GSSAPI one time and fails. The interesting part of this scenario is that client requests two time GSSAPI auth. whether the user is stored in KDC or not and this can be seen in the following debug, debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Delegating credentials debug1: Delegating credentials debug1: Authentications that can continue: publickey,gssapi-with-mic,keyboard-interactive debug2: we sent a gssapi-with-mic packet, wait for reply But why there is difference in behaviour of SSHD based on the users availability in KDC? It would be very much helpful to know the reasons for such a behaviour. Thanks, Senthil Kumar. From dtucker at zip.com.au Tue Oct 4 19:22:27 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 04 Oct 2005 19:22:27 +1000 Subject: HPH-SSH code incorporation In-Reply-To: References: Message-ID: <434249D3.6000109@zip.com.au> alan.cl.wong at nokia.com wrote: > We are deciding on to either entirely use HPH code to our > OpenSSH or not for systems globally and I come down to a question. I assume you mean HPN? http://www.psc.edu/networking/projects/hpn-ssh/ > If HPH-SSH code is such an improvement to network performance for > OpenSSH, then why has it not been incorporated to the OpenSSH code? Is > there a reason? Is it because there are problems with the HPH-SSH code? (speaking for myself) Short answer: lack of time to review and difficulty testing the patch and/or variants thereof. I did a review a of the (current at the time) patch while back: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=112316226728255 As far as I can see, none of those items have been addressed. > Since the code has been out for a time and still has not been > incorporated to the OpenSSH code. It creates doubt of there must be a > reason why the OpenSSH group has not incorporated the patch. There are > concerns of code scrutiny and review if it is not incorporated. OpenSSH > has now become not just an application but a medium for data transfer > and that means network performance is very critical. If network > performance can be increased without decrease in security then it would > make OpenSSH even more attractive. > > So the question is is there a reason why the OpenSSH group decided not > to incorporate the code into theirs? It basically needs to be split up, each piece tested individually and, if possible, simplified. We've worked the the HPN folk this way in the past (eg bugzilla #896). The testing part is difficult for folks without a transcontinental ATM link or similar handy. (I did some testing with a software solution to add latency but spent more time debugging the test rig than ssh.) -- 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. From rapier at psc.edu Tue Oct 4 23:07:10 2005 From: rapier at psc.edu (Chris Rapier) Date: Tue, 04 Oct 2005 09:07:10 -0400 Subject: HPH-SSH code incorporation In-Reply-To: <434249D3.6000109@zip.com.au> References: <434249D3.6000109@zip.com.au> Message-ID: <43427E7E.1060007@psc.edu> Darren Tucker wrote: > alan.cl.wong at nokia.com wrote: > >> We are deciding on to either entirely use HPH code to our >>OpenSSH or not for systems globally and I come down to a question. > > > I assume you mean HPN? > http://www.psc.edu/networking/projects/hpn-ssh/ > > >>If HPH-SSH code is such an improvement to network performance for >>OpenSSH, then why has it not been incorporated to the OpenSSH code? Is >>there a reason? Is it because there are problems with the HPH-SSH code? > > > (speaking for myself) Short answer: lack of time to review and > difficulty testing the patch and/or variants thereof. > > I did a review a of the (current at the time) patch while back: > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=112316226728255 > As far as I can see, none of those items have been addressed. We haven't actually had time to review your proposed changes and decide if we want to incorporate them. Its not that we think that they are bad ideas. I personally have no real problem with incorporating them once they are tested out but we've moved onto a different aspect of this project and this didn't just move to the back burner but fell off the stove. I'll pick it up, brush it off, and see what we find out. >>Since the code has been out for a time and still has not been >>incorporated to the OpenSSH code. It creates doubt of there must be a >>reason why the OpenSSH group has not incorporated the patch. There are >>concerns of code scrutiny and review if it is not incorporated. OpenSSH >>has now become not just an application but a medium for data transfer >>and that means network performance is very critical. If network >>performance can be increased without decrease in security then it would >>make OpenSSH even more attractive. >> >>So the question is is there a reason why the OpenSSH group decided not >>to incorporate the code into theirs? > > > It basically needs to be split up, each piece tested individually and, > if possible, simplified. We've worked the the HPN folk this way in the > past (eg bugzilla #896). My impression of that was that 896 was a bug. Addmittedly, the only way it could have been triggered was with our patch. Mike Stevens has more detail on that. > The testing part is difficult for folks without a transcontinental ATM > link or similar handy. (I did some testing with a software solution to > add latency but spent more time debugging the test rig than ssh.) Currently we have test sites in switzerland, Pittsburgh, Pennsylvania, and Boulder, Colorado. We might be able to provde access to those sites (I need to review our policy on this) in some limited manner. If I can then you'd be on rather hjigh BDP links. Not GigE but at least several hundred Mb. From jeremie at le-hen.org Wed Oct 5 08:08:22 2005 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Wed, 5 Oct 2005 00:08:22 +0200 Subject: [patch] LOCKED_PASSWD_STRING for FreeBSD Message-ID: <20051004220822.GE43195@obiwan.tataz.chchile.org> Hi, I dare to send you this very small patch that defines LOCKED_PASSWD_STRING for the FreeBSD operating system. The manpage had been unclear about this for a long time, up to 5.x days. Since 6.x, it has been made clearer, and thanks to Ceri Davies who highlighted this feature in OpenSSH, I made this patch. I hope this will reach OpenSSH source tree. This is not a big deal and I would add that, while not directly important for the FreeBSD OS since it doesn't use autotools stuffs, it is for users that don't use the stock OpenSSH provided with FreeBSD. Thanks for your work, keep on ! :-) Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > -------------- next part -------------- Index: configure.ac =================================================================== RCS file: /cvs/openssh/configure.ac,v retrieving revision 1.296 diff -u -p -u -r1.296 configure.ac --- configure.ac 22 Sep 2005 10:19:54 -0000 1.296 +++ configure.ac 4 Oct 2005 21:59:01 -0000 @@ -398,6 +398,7 @@ mips-sony-bsd|mips-sony-newsos4) ;; *-*-freebsd*) check_for_libcrypt_later=1 + AC_DEFINE(LOCKED_PASSWD_STRING, "*") ;; *-*-bsdi*) AC_DEFINE(SETEUID_BREAKS_SETUID) From jeremie at le-hen.org Wed Oct 5 08:09:27 2005 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Wed, 5 Oct 2005 00:09:27 +0200 Subject: [patch] LOCKED_PASSWD_STRING for FreeBSD In-Reply-To: <20051004220822.GE43195@obiwan.tataz.chchile.org> References: <20051004220822.GE43195@obiwan.tataz.chchile.org> Message-ID: <20051004220927.GF43195@obiwan.tataz.chchile.org> > I dare to send you this very small patch that defines > LOCKED_PASSWD_STRING for the FreeBSD operating system. > > The manpage had been unclear about this for a long time, up to > 5.x days. Since 6.x, it has been made clearer, and thanks > to Ceri Davies who highlighted this feature in OpenSSH, I > made this patch. > > I hope this will reach OpenSSH source tree. This is not a big > deal and I would add that, while not directly important for the > FreeBSD OS since it doesn't use autotools stuffs, it is for > users that don't use the stock OpenSSH provided with FreeBSD. > > Thanks for your work, keep on ! :-) I forgot to tell that I'm not subscribed to this list, so please, Cc: me explicitely when replying. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From alon.barlev at gmail.com Wed Oct 5 11:14:57 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 05 Oct 2005 01:14:57 +0000 Subject: ssh-agent add PKCS#11 support Message-ID: <43432911.2050602@gmail.com> Hello, PKCS#11 is a standard API interface that can be used in order to access cryptographic tokens. You can find the specification at http://www.rsasecurity.com/rsalabs/node.asp?id=2133, most smartcard and other cryptographic device vendors support PKCS#11, opensc also provides PKCS#11 interface. I can easily make the scard.c, scard-opensc.c and ssh-agent.c support PKCS#11. PKCS#11 is much more portable, standard, used standard than the current opensc implementation. I just written the PKCS#11 support for the openvpn project, and I think openssh can also benefit from the same implementation. Are you interested in merging PKCS#11 support? I don't won't to create a separate branch. After implementing the PKCS#11 support you can drop the opensc code, users can use the opensc PKCS#11 provider in order to access their keys. Does the current implementation of ssh-agent is the final one? I am asking this before I implement code that may be dramatically changed (For example, support X509 and PKIX). Best Regards, Alon Bar-Lev. From stuge-openssh-unix-dev at cdy.org Wed Oct 5 11:40:25 2005 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Wed, 5 Oct 2005 03:40:25 +0200 Subject: ssh-agent add PKCS#11 support In-Reply-To: <43432911.2050602@gmail.com> References: <43432911.2050602@gmail.com> Message-ID: <20051005014025.17868.qmail@cdy.org> On Wed, Oct 05, 2005 at 01:14:57AM +0000, Alon Bar-Lev wrote: > I can easily make the scard.c, scard-opensc.c and > ssh-agent.c support PKCS#11. If you do, may I suggest checking out libp11, also by the OpenSC project. http://www.opensc.org/libp11/ //Peter From dtucker at zip.com.au Wed Oct 5 12:12:41 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 05 Oct 2005 12:12:41 +1000 Subject: [patch] LOCKED_PASSWD_STRING for FreeBSD In-Reply-To: <20051004220822.GE43195@obiwan.tataz.chchile.org> References: <20051004220822.GE43195@obiwan.tataz.chchile.org> Message-ID: <43433699.2030101@zip.com.au> Jeremie Le Hen wrote: > I dare to send you this very small patch that defines > LOCKED_PASSWD_STRING for the FreeBSD operating system. > > The manpage had been unclear about this for a long time, up to > 5.x days. Since 6.x, it has been made clearer, and thanks > to Ceri Davies who highlighted this feature in OpenSSH, I > made this patch. Patch looks OK. Which FreeBSD man page(s) document the behaviour? -- 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. From jeremie at le-hen.org Wed Oct 5 17:29:24 2005 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Wed, 5 Oct 2005 09:29:24 +0200 Subject: [patch] LOCKED_PASSWD_STRING for FreeBSD In-Reply-To: <43433699.2030101@zip.com.au> References: <20051004220822.GE43195@obiwan.tataz.chchile.org> <43433699.2030101@zip.com.au> Message-ID: <20051005072924.GI43195@obiwan.tataz.chchile.org> Hi, > >The manpage had been unclear about this for a long time, up to > >5.x days. Since 6.x, it has been made clearer, and thanks > >to Ceri Davies who highlighted this feature in OpenSSH, I > >made this patch. > > Patch looks OK. Which FreeBSD man page(s) document the behaviour? Sorry, it is passwd(5). Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From alon.barlev at gmail.com Wed Oct 5 21:18:33 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 05 Oct 2005 11:18:33 +0000 Subject: ssh-agent add PKCS#11 support In-Reply-To: <20051005014025.17868.qmail@cdy.org> References: <43432911.2050602@gmail.com> <20051005014025.17868.qmail@cdy.org> Message-ID: <4343B689.8060105@gmail.com> Peter Stuge wrote: > On Wed, Oct 05, 2005 at 01:14:57AM +0000, Alon Bar-Lev wrote: > >>I can easily make the scard.c, scard-opensc.c and >>ssh-agent.c support PKCS#11. > > > If you do, may I suggest checking out libp11, also by the OpenSC > project. > > http://www.opensc.org/libp11/ Hello, I've seen this lib and I don't think it is flexible enough. It handles only one provider at a time, it does not allow to select object based on attributes and performs some unneeded operations with the token that may lead to incomparability. It also assume that public keys are stored on token, this is incorrect. I have a different implementation, that minimize the requirements from the token, it also support several providers so that the user can load all of his provider with the same configuration. The user can select objects based on slot id, slot name, token label and object id, object label, certificate subject name. The best way is for the user to select object by token label and certificate subject name then he can insert the token to any slot and even renew his certificate and the software will continue to work. Best Regards, Alon Bar-Lev From dtucker at zip.com.au Wed Oct 5 18:28:17 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 05 Oct 2005 18:28:17 +1000 Subject: [patch] LOCKED_PASSWD_STRING for FreeBSD In-Reply-To: <20051005072924.GI43195@obiwan.tataz.chchile.org> References: <20051004220822.GE43195@obiwan.tataz.chchile.org> <43433699.2030101@zip.com.au> <20051005072924.GI43195@obiwan.tataz.chchile.org> Message-ID: <43438EA1.1090504@zip.com.au> Jeremie Le Hen wrote: > Hi, > >>> The manpage had been unclear about this for a long time, up to >>> 5.x days. Since 6.x, it has been made clearer, and thanks >>> to Ceri Davies who highlighted this feature in OpenSSH, I >>> made this patch. >> Patch looks OK. Which FreeBSD man page(s) document the behaviour? > > Sorry, it is passwd(5). I can't see any mention on the web page: http://www.freebsd.org/cgi/man.cgi?query=passwd&sektion=5&manpath=FreeBSD+6.0-current Creating a locked user via adduser on FreeBSD 5.3 give the following entry in master.passwd: testu:*LOCKED*$1$wgpYdQ8Z$2H3SbvgLmQVV9zDxhSgtp/:[...] Is this version dependant? Or tool-dependant? -- 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. From senthilkumar_sen at hotpop.com Wed Oct 5 19:55:39 2005 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Wed, 5 Oct 2005 15:25:39 +0530 Subject: [patch] LOCKED_PASSWD_STRING for FreeBSD References: <20051004220822.GE43195@obiwan.tataz.chchile.org><43433699.2030101@zip.com.au><20051005072924.GI43195@obiwan.tataz.chchile.org> <43438EA1.1090504@zip.com.au> Message-ID: <47dd01c5c992$fadf8d10$220110ac@sekco> Darren wrote: > Jeremie Le Hen wrote: >> Hi, >> >>>> The manpage had been unclear about this for a long time, up to >>>> 5.x days. Since 6.x, it has been made clearer, and thanks >>>> to Ceri Davies who highlighted this feature in OpenSSH, I >>>> made this patch. >>> Patch looks OK. Which FreeBSD man page(s) document the behaviour? >> >> Sorry, it is passwd(5). > > I can't see any mention on the web page: > http://www.freebsd.org/cgi/man.cgi?query=passwd&sektion=5&manpath=FreeBSD+6.0-current > > Creating a locked user via adduser on FreeBSD 5.3 give the following > entry in master.passwd: > testu:*LOCKED*$1$wgpYdQ8Z$2H3SbvgLmQVV9zDxhSgtp/:[...] > > Is this version dependant? Or tool-dependant? I think it is pw(8) that do this locking in freebsd and also documented the behaviour. pw lock username did it for me. Thanks, Senthil Kumar. From senthilkumar_sen at hotpop.com Wed Oct 5 21:24:09 2005 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Wed, 5 Oct 2005 16:54:09 +0530 Subject: [patch] LOCKED_PASSWD_STRING for FreeBSD References: <20051004220822.GE43195@obiwan.tataz.chchile.org><43433699.2030101@zip.com.au><20051005072924.GI43195@obiwan.tataz.chchile.org><43438EA1.1090504@zip.com.au> <47dd01c5c992$fadf8d10$220110ac@sekco> Message-ID: <481001c5c99f$575e2d60$220110ac@sekco> Senthil kumar wrote:- > Darren wrote: >> Jeremie Le Hen wrote: >>> Hi, >>> >>>>> The manpage had been unclear about this for a long time, up to >>>>> 5.x days. Since 6.x, it has been made clearer, and thanks >>>>> to Ceri Davies who highlighted this feature in OpenSSH, I >>>>> made this patch. >>>> Patch looks OK. Which FreeBSD man page(s) document the behaviour? >>> >>> Sorry, it is passwd(5). >> >> I can't see any mention on the web page: >> http://www.freebsd.org/cgi/man.cgi?query=passwd&sektion=5&manpath=FreeBSD+6.0-current >> >> Creating a locked user via adduser on FreeBSD 5.3 give the following >> entry in master.passwd: >> testu:*LOCKED*$1$wgpYdQ8Z$2H3SbvgLmQVV9zDxhSgtp/:[...] >> >> Is this version dependant? Or tool-dependant? > > I think it is pw(8) that do this locking in freebsd and also documented > the > behaviour. If thts the case I hope the attached patch may honour locked accounts in freebsd. Thnx, Senthil Kumar. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freebsd_LOCKED_PASSWD_SUBSTR.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20051005/1add20a1/attachment.txt From jeremie at le-hen.org Wed Oct 5 22:09:25 2005 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Wed, 5 Oct 2005 14:09:25 +0200 Subject: [patch] LOCKED_PASSWD_STRING for FreeBSD In-Reply-To: <43438EA1.1090504@zip.com.au> References: <20051004220822.GE43195@obiwan.tataz.chchile.org> <43433699.2030101@zip.com.au> <20051005072924.GI43195@obiwan.tataz.chchile.org> <43438EA1.1090504@zip.com.au> Message-ID: <20051005120925.GM43195@obiwan.tataz.chchile.org> Hi Darren, > I can't see any mention on the web page: > http://www.freebsd.org/cgi/man.cgi?query=passwd&sektion=5&manpath=FreeBSD+6.0-current > > Creating a locked user via adduser on FreeBSD 5.3 give the following > entry in master.passwd: > testu:*LOCKED*$1$wgpYdQ8Z$2H3SbvgLmQVV9zDxhSgtp/:[...] > > Is this version dependant? Or tool-dependant? The manpage has just been updated on FreeBSD-CURRENT and backported to the RELENG_6 branch. Unfortunately the manpages available from the website are not up to date. I put the lastest RELENG_6 manual page into this text file : http://jeremie.le-hen.org/~tataz/passwd.5.txt Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From jeremie at le-hen.org Wed Oct 5 22:36:15 2005 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Wed, 5 Oct 2005 14:36:15 +0200 Subject: [patch] LOCKED_PASSWD_STRING for FreeBSD In-Reply-To: <481001c5c99f$575e2d60$220110ac@sekco> References: <47dd01c5c992$fadf8d10$220110ac@sekco> <481001c5c99f$575e2d60$220110ac@sekco> Message-ID: <20051005123615.GN43195@obiwan.tataz.chchile.org> Hi Senthil, > >I think it is pw(8) that do this locking in freebsd and also documented > >the > >behaviour. > > If thts the case I hope the attached patch may honour locked accounts in > freebsd. > > Thnx, > Senthil Kumar. > Index: configure.ac > =================================================================== > RCS file: /cvs/openssh/configure.ac,v > retrieving revision 1.296 > diff -u -p -u -r1.296 configure.ac > --- configure.ac 22 Sep 2005 10:19:54 -0000 1.296 > +++ configure.ac 4 Oct 2005 21:59:01 -0000 > @@ -398,6 +398,7 @@ mips-sony-bsd|mips-sony-newsos4) > ;; > *-*-freebsd*) > check_for_libcrypt_later=1 > + AC_DEFINE(LOCKED_PASSWD_SUBSTR, "*LOCKED*") > ;; > *-*-bsdi*) > AC_DEFINE(SETEUID_BREAKS_SETUID) You are true, but currently the implementation doesn't seem to make the difference. I tried to lock "nobody", this does not prevent cron jobs to be run, unfortunately. In the same way, OpenSSH provided in FreeBSD does not prevent from logging with keys when an account is locked, but Dag-Erling Smorgrav swore to fix this soon in the source tree. Your patch is better than mine, but not yet perfect : % obiwan:root# grep nobody /etc/master.passwd % nobody:$1$p0WuUGm5$o5/Q1k7bUg/WTtmA2mwGV0:65534:65534::0:0:Unprivileged user:/nonexistent:/usr/sbin/nologin % obiwan:root# pw lock nobody % obiwan:root# grep nobody /etc/master.passwd % nobody:*LOCKED*$1$p0WuUGm5$o5/Q1k7bUg/WTtmA2mwGV0:65534:65534::0:0:Unprivileged user:/nonexistent:/usr/sbin/nologin (Don't be afraid, I have already removed nobody's password :-)). I think we therefore should use LOCKED_PASSWD_PREFIX instead, the updated patch is attached. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > -------------- next part -------------- Index: configure.ac =================================================================== RCS file: /cvs/openssh/configure.ac,v retrieving revision 1.296 diff -u -p -u -r1.296 configure.ac --- configure.ac 22 Sep 2005 10:19:54 -0000 1.296 +++ configure.ac 5 Oct 2005 12:36:06 -0000 @@ -398,6 +398,7 @@ mips-sony-bsd|mips-sony-newsos4) ;; *-*-freebsd*) check_for_libcrypt_later=1 + AC_DEFINED(LOCKED_PASSWD_PREFIX, "*LOCKED*") ;; *-*-bsdi*) AC_DEFINE(SETEUID_BREAKS_SETUID) From jeremie at le-hen.org Wed Oct 5 22:39:18 2005 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Wed, 5 Oct 2005 14:39:18 +0200 Subject: [patch] LOCKED_PASSWD_STRING for FreeBSD In-Reply-To: <20051005123615.GN43195@obiwan.tataz.chchile.org> References: <47dd01c5c992$fadf8d10$220110ac@sekco> <481001c5c99f$575e2d60$220110ac@sekco> <20051005123615.GN43195@obiwan.tataz.chchile.org> Message-ID: <20051005123918.GO43195@obiwan.tataz.chchile.org> > Index: configure.ac > =================================================================== > RCS file: /cvs/openssh/configure.ac,v > retrieving revision 1.296 > diff -u -p -u -r1.296 configure.ac > --- configure.ac 22 Sep 2005 10:19:54 -0000 1.296 > +++ configure.ac 5 Oct 2005 12:36:06 -0000 > @@ -398,6 +398,7 @@ mips-sony-bsd|mips-sony-newsos4) > ;; > *-*-freebsd*) > check_for_libcrypt_later=1 > + AC_DEFINED(LOCKED_PASSWD_PREFIX, "*LOCKED*") > ;; > *-*-bsdi*) > AC_DEFINE(SETEUID_BREAKS_SETUID) By the way, this patch has already been made last year by Ruslan Ermilov : http://lists.freebsd.org/pipermail/freebsd-bugs/2004-August/008758.html -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From dtucker at zip.com.au Wed Oct 5 23:04:51 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 5 Oct 2005 23:04:51 +1000 Subject: [patch] LOCKED_PASSWD_STRING for FreeBSD In-Reply-To: <20051005123615.GN43195@obiwan.tataz.chchile.org> References: <47dd01c5c992$fadf8d10$220110ac@sekco> <481001c5c99f$575e2d60$220110ac@sekco> <20051005123615.GN43195@obiwan.tataz.chchile.org> Message-ID: <20051005130451.GA10566@gate.dodgy.net.au> On Wed, Oct 05, 2005 at 02:36:15PM +0200, Jeremie Le Hen wrote: > + AC_DEFINED(LOCKED_PASSWD_PREFIX, "*LOCKED*") Applied this one, thanks. -- 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. From cspark at choung.net Thu Oct 6 11:51:04 2005 From: cspark at choung.net (Choung S. Park / Choung Networks) Date: Wed, 5 Oct 2005 18:51:04 -0700 Subject: Possible security problem in hostbased user authentication? Message-ID: <026c01c5ca18$699f4a80$0a00a8c0@redice2> In auth2-hostbased.c, line #146 if (auth_rhosts2(pw, cuser, chost, chost) == 0) ^^^^^ shouldn't this be if (auth_rhosts2(pw, cuser, chost, ipaddr) == 0) ^^^^^^ The code was found in 4.2. Best regards, Choung S.Park From dtucker at zip.com.au Thu Oct 6 12:10:45 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 06 Oct 2005 12:10:45 +1000 Subject: Possible security problem in hostbased user authentication? In-Reply-To: <026c01c5ca18$699f4a80$0a00a8c0@redice2> References: <026c01c5ca18$699f4a80$0a00a8c0@redice2> Message-ID: <434487A5.9070906@zip.com.au> Choung S. Park / Choung Networks wrote: > In auth2-hostbased.c, line #146 > > if (auth_rhosts2(pw, cuser, chost, chost) == 0) > ^^^^^ > > shouldn't this be > > if (auth_rhosts2(pw, cuser, chost, ipaddr) == 0) > ^^^^^^ I don't think so. The surrounding code is: if (options.hostbased_uses_name_from_packet_only) { if (auth_rhosts2(pw, cuser, chost, chost) == 0) return 0; lookup = chost; It's the implementation of the HostbasedUsesNameFromPacketOnly sshd_config option. If you look at the authmethod code (in userauth_hostbased() above) you'll see that the host must also be able to prove possession of the private key corresponding to that host identifier to be allowed access. So the host can claim to be whatever it wants, but it won't get very far unless the server has a public key for that host, and the client has the matching private key. On a related note, it appears that HostbasedUsesNameFromPacketOnly is missing from sshd_config(5). -- 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. From cspark at choung.net Thu Oct 6 13:52:03 2005 From: cspark at choung.net (Choung S. Park / Choung Networks) Date: Wed, 5 Oct 2005 20:52:03 -0700 Subject: Possible security problem in hostbased user authentication? References: <026c01c5ca18$699f4a80$0a00a8c0@redice2> <434487A5.9070906@zip.com.au> Message-ID: <02e101c5ca29$50930750$0a00a8c0@redice2> Well... I admit it's not a high risk security issue since hostbased also uses pub/priv keys. However, if the options.hostbased_uses_name_from_packet_only is "enabled", the connected client will surely pass the test even if its IP is listed as "deny". Anyway, I don't think the person who wrote this routine intentionally decided to pass the two chost's. It seems one of those invisible bugs... :-( Best regards, Choung S.Park ----- Original Message ----- From: "Darren Tucker" To: "Choung S. Park / Choung Networks" Cc: Sent: Wednesday, October 05, 2005 7:10 PM Subject: Re: Possible security problem in hostbased user authentication? > Choung S. Park / Choung Networks wrote: > > In auth2-hostbased.c, line #146 > > > > if (auth_rhosts2(pw, cuser, chost, chost) == 0) > > ^^^^^ > > > > shouldn't this be > > > > if (auth_rhosts2(pw, cuser, chost, ipaddr) == 0) > > ^^^^^^ > > I don't think so. The surrounding code is: > if (options.hostbased_uses_name_from_packet_only) { > if (auth_rhosts2(pw, cuser, chost, chost) == 0) > return 0; > lookup = chost; > > It's the implementation of the HostbasedUsesNameFromPacketOnly > sshd_config option. If you look at the authmethod code (in > userauth_hostbased() above) you'll see that the host must also be able > to prove possession of the private key corresponding to that host > identifier to be allowed access. > > So the host can claim to be whatever it wants, but it won't get very far > unless the server has a public key for that host, and the client has the > matching private key. > > On a related note, it appears that HostbasedUsesNameFromPacketOnly is > missing from sshd_config(5). > > -- > 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. From David.Leonard at quest.com Tue Oct 4 09:22:43 2005 From: David.Leonard at quest.com (David Leonard) Date: Tue, 4 Oct 2005 09:22:43 +1000 (EST) Subject: .spec file for SLES 9 In-Reply-To: <200510031734.j93HYsZj015753@sun601.nas.nasa.gov> References: <200510031734.j93HYsZj015753@sun601.nas.nasa.gov> Message-ID: On Mon, 3 Oct 2005, Iain Morgan wrote: > I'm gearing up for an RPM deployment of 4.2p1 on SuSE (SLES 9). However, the files > under contrib/suse in the OpenSSH distribution appear to be out-of-date. In > particular, SuSE seems to handle init scripts quite differently now. > > So, is anyone building local RPMs for SuSE? If so, could you post the .spec > file you are using? Is there any interest in updating the contrib/suse > section? I've done some initial work, but since I'm new to SuSE I defer to > the experience of others. I rolled a spec file for work that seems to work for both suse and redhat based systems. You can pick the spec out of The %post script in that (perhaps dubiously) decides what script to install after looking around for LSB support. But, it seems to work pretty well. (You'll probably want to ditch the earlier stuff in the spec since it's pretty specific for linking against our product.) Cheers, d -- David Leonard Vintela Resource Central software engineer Quest Software; Brisbane, Australia; www.quest.com Phone: (US) +1 801 655 2755 (AU) +61 7 3023 5133 From Sai.Pullabhotla at jMethods.com Fri Oct 7 05:48:27 2005 From: Sai.Pullabhotla at jMethods.com (Sai Pullabhotla) Date: Thu, 6 Oct 2005 14:48:27 -0500 Subject: SSH Private Key File Format Message-ID: <200510061948.j96JmR1W007864@pyramid-01.kattare.com> Hello Fellow Developers, I'm trying to create a Java based tool to create and manage SSH key pairs. I found a draft that explains the format for public key. But I could not find any documentation as to how the private keys are stored. Can any one point me to a document that explains the private key file format? Thanks in advance. ? Regards Sai Pullabhotla President jMethods, Inc. Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com ? ? From dtucker at zip.com.au Sun Oct 9 17:13:30 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 09 Oct 2005 17:13:30 +1000 Subject: HPN Patch for OpenSSH 4.2p1 Available In-Reply-To: <43209913.7020801@psc.edu> References: <43209913.7020801@psc.edu> Message-ID: <4348C31A.5030209@zip.com.au> Chris Rapier wrote: > As a note, we now have HPN patch for OpenSSH 4.2 at > http://www.psc.edu/networking/projects/hpn-ssh/ > > Its still part of the last set of patches (HPN11) so there aren't any > additional changes in the code. It patches, configures, compiles, and > passes make tests without a problem. I've not done extensive testing for > this version of openssh but I don't foresee any problems. > > I did run a couple tests between two patched 4.2 installs (one in > switzerland, the other in pennsylvania, usa) and hit around 12MB/s with > the hpn patch and 500KB/s with the standard install. So it still seems > to work as expected. Have you done any analysis of the impact of the patch on low-latency/BDP links (ie LANs)? I've been doing some work with parts of the HPN patch. For scp'ing to and from localhost and LANs (see below), the scp changes on their own (actually, a variant thereof) shows a modest improvement of 2-3% in throughput. That's good. For the entire patch (hpn11), however, it shows a significant *decrease* in throughput for the same tests: 10% slower on OpenBSD to localhost, 12% slower on Linux to localhost and 18% slower Linux to OpenBSD via a 100Mb/s LAN). That's bad. I would imagine LANs are more common than high BDP networks that your patch targets :-) scp to localhost, OpenBSD 3.8-current, 733MHz P3/Celeron) -current -hpn11 real 2m40.966s 2m57.296s (10.2% slower) user 0m33.187s 0m45.820s sys 0m31.500s 0m37.539s scp to localhost, Fedora Core 3, 933MHz VIA CPU) -current -hpn11 real 3m19.578s 3m43.944s (12.2% slower) user 0m0.086s 0m0.082s sys 0m11.202s 0m12.152s scp FC3 to OpenBSD 3.8, 100Mb/s switched LAN, no stack tuning: -current -hpn11 real 1m59.486s 2m22.000s (18.8% slower) user 1m6.839s 1m18.344s sys 0m43.040s 0m43.004s I suspect that the buffer size increases you do are counterproductive for such networks. I also suspect that you could get the same performance improvements on high-BDP links as you currently do by simply increasing the channel advertisements without the SSH buffer changes and relying on the TCP socket buffer for output and decrypting quickly for input but I'm not able to test that. Test method, with a 64MB file: $ time for i in 1 2 3 4 5 6 7 8 9 0; do scp -ocompression=no -o ciphers=arcfour /tmp/tmp localhost:/dev/null; done -- 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. From mstevens at cmu.edu Sun Oct 9 23:24:35 2005 From: mstevens at cmu.edu (Michael A Stevens) Date: Sun, 9 Oct 2005 09:24:35 -0400 (EDT) Subject: HPN Patch for OpenSSH 4.2p1 Available In-Reply-To: <4348C31A.5030209@zip.com.au> References: <43209913.7020801@psc.edu> <4348C31A.5030209@zip.com.au> Message-ID: I would suspect those performance decreases are more of a CPU issue, as the platforms you named are relatively low performance. The issue I ran into when designing this was how often to poll the Operating System for an update of the window size. I'm not sure what the correct answer is, as this is a relatively stupid metric for forcing a syscall every window_size bytes. Ideally we would just be notified of changes to the TCP window maximum. Mike On Sun, 9 Oct 2005, Darren Tucker wrote: > Chris Rapier wrote: >> As a note, we now have HPN patch for OpenSSH 4.2 at >> http://www.psc.edu/networking/projects/hpn-ssh/ >> >> Its still part of the last set of patches (HPN11) so there aren't any >> additional changes in the code. It patches, configures, compiles, and >> passes make tests without a problem. I've not done extensive testing for >> this version of openssh but I don't foresee any problems. >> >> I did run a couple tests between two patched 4.2 installs (one in >> switzerland, the other in pennsylvania, usa) and hit around 12MB/s with >> the hpn patch and 500KB/s with the standard install. So it still seems >> to work as expected. > > Have you done any analysis of the impact of the patch on low-latency/BDP > links (ie LANs)? > > I've been doing some work with parts of the HPN patch. For scp'ing to > and from localhost and LANs (see below), the scp changes on their own > (actually, a variant thereof) shows a modest improvement of 2-3% in > throughput. That's good. > > For the entire patch (hpn11), however, it shows a significant *decrease* > in throughput for the same tests: 10% slower on OpenBSD to localhost, > 12% slower on Linux to localhost and 18% slower Linux to OpenBSD via a > 100Mb/s LAN). That's bad. I would imagine LANs are more common than > high BDP networks that your patch targets :-) > > scp to localhost, OpenBSD 3.8-current, 733MHz P3/Celeron) > -current -hpn11 > real 2m40.966s 2m57.296s (10.2% slower) > user 0m33.187s 0m45.820s > sys 0m31.500s 0m37.539s > > scp to localhost, Fedora Core 3, 933MHz VIA CPU) > -current -hpn11 > real 3m19.578s 3m43.944s (12.2% slower) > user 0m0.086s 0m0.082s > sys 0m11.202s 0m12.152s > > scp FC3 to OpenBSD 3.8, 100Mb/s switched LAN, no stack tuning: > -current -hpn11 > real 1m59.486s 2m22.000s (18.8% slower) > user 1m6.839s 1m18.344s > sys 0m43.040s 0m43.004s > > I suspect that the buffer size increases you do are counterproductive > for such networks. I also suspect that you could get the same > performance improvements on high-BDP links as you currently do by simply > increasing the channel advertisements without the SSH buffer changes and > relying on the TCP socket buffer for output and decrypting quickly for > input but I'm not able to test that. > > Test method, with a 64MB file: > $ time for i in 1 2 3 4 5 6 7 8 9 0; do scp -ocompression=no -o > ciphers=arcfour /tmp/tmp localhost:/dev/null; done > > -- > 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. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > From dtucker at zip.com.au Mon Oct 10 00:32:43 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 10 Oct 2005 00:32:43 +1000 Subject: HPN Patch for OpenSSH 4.2p1 Available In-Reply-To: References: <43209913.7020801@psc.edu> <4348C31A.5030209@zip.com.au> Message-ID: <20051009143243.GA16284@gate.dodgy.net.au> On Sun, Oct 09, 2005 at 09:24:35AM -0400, Michael A Stevens wrote: > I would suspect those performance decreases are more of a CPU issue, as > the platforms you named are relatively low performance. I don't think so. I just ran a quick test on a dual Athlon 2600MP (OpenBSD 3.8 with a multiprocessor kernel) scp to localhost and it was even slower (1m26.76s for -current and 1m49.18s for -hpn, a penalty of about 25%). Could you (or Chris) please compare -current (or 4.2p1 release) against -hpn for localhost and LAN connections on your hardware? -- 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. From rapier at psc.edu Mon Oct 10 11:24:20 2005 From: rapier at psc.edu (Chris Rapier) Date: Sun, 09 Oct 2005 21:24:20 -0400 Subject: HPN Patch for OpenSSH 4.2p1 Available In-Reply-To: <4348C31A.5030209@zip.com.au> References: <43209913.7020801@psc.edu> <4348C31A.5030209@zip.com.au> Message-ID: <4349C2C4.4060403@psc.edu> The performance hit is, initially somewhat suprising, but on reflection I think this is mostly going to be dependent on how the systems TCP stacks are tuned. I can see performance decreasing in the LAN if the receive buffer is too high. An easy test would be to run some iPerfs and see if the system TCP receive buffer shows a similar performance hit versus setting the the iPerf window to 64k. I'll run some similar tests to see if I'm right. However, this should only be an issue with non-autotuning kernels. Autotuning kernels such as linux 2.4.26+. 2.6+, and Windows Vista (nee Longhorn) will adjust the receive buffer to maximize throughput. Since HPN-SSH is auto-tuning aware this shouldn't be a problem on those systems. On non-autotuning kernels appropriate use of the -w option should resolve this. Again, I'll need to test this but I'm pretty sure thats the issue. Darren Tucker wrote: > Chris Rapier wrote: > >> As a note, we now have HPN patch for OpenSSH 4.2 at >> http://www.psc.edu/networking/projects/hpn-ssh/ >> >> Its still part of the last set of patches (HPN11) so there aren't any >> additional changes in the code. It patches, configures, compiles, and >> passes make tests without a problem. I've not done extensive testing >> for this version of openssh but I don't foresee any problems. >> >> I did run a couple tests between two patched 4.2 installs (one in >> switzerland, the other in pennsylvania, usa) and hit around 12MB/s >> with the hpn patch and 500KB/s with the standard install. So it still >> seems to work as expected. > > > Have you done any analysis of the impact of the patch on low-latency/BDP > links (ie LANs)? > > I've been doing some work with parts of the HPN patch. For scp'ing to > and from localhost and LANs (see below), the scp changes on their own > (actually, a variant thereof) shows a modest improvement of 2-3% in > throughput. That's good. > > For the entire patch (hpn11), however, it shows a significant *decrease* > in throughput for the same tests: 10% slower on OpenBSD to localhost, > 12% slower on Linux to localhost and 18% slower Linux to OpenBSD via a > 100Mb/s LAN). That's bad. I would imagine LANs are more common than > high BDP networks that your patch targets :-) I'll check this of course. We don't have any OpenBSD systems though but I'll try to find a spare box we can blow it on to. > I suspect that the buffer size increases you do are counterproductive > for such networks. I also suspect that you could get the same > performance improvements on high-BDP links as you currently do by simply > increasing the channel advertisements without the SSH buffer changes and > relying on the TCP socket buffer for output and decrypting quickly for > input but I'm not able to test that. Of course is possible to increase performance through other means. Transferring data in parallel for example, is a great way to do this. In fact the suggestions you made are ones we were planning on implementing in addition to the buffer hack. Especially now that we really are CPU limited as opposed to being buffer limited. However, that seems, in my view at least, to be an overly complicated way of going about it. The buffer hack is pretty straightforward and well known - the concept is laid out in Stevens TCP/IP Illustrated Volume 1 after all. > Test method, with a 64MB file: > $ time for i in 1 2 3 4 5 6 7 8 9 0; do scp -ocompression=no -o > ciphers=arcfour /tmp/tmp localhost:/dev/null; done I'll try this out and let you know what I find. Could you let me know what you had your tcp receive buffer set to when you tried these tests? Optimally for these local tests it should be set to 64k. By the way - I just ran the above test and didn't see any sort of substantive difference. There was a slight edge to the HPN platform *but* that was probably due to the scp hack. Of course, in this case the problem is likely to be disk speed limits (I'm on a powerbook at the moment and its disks are slow). Bypassing scp and doing a direct memory to memory copy is probably the right methodology. From dtucker at zip.com.au Mon Oct 10 20:07:44 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 10 Oct 2005 20:07:44 +1000 Subject: HPN Patch for OpenSSH 4.2p1 Available In-Reply-To: <4349C2C4.4060403@psc.edu> References: <43209913.7020801@psc.edu> <4348C31A.5030209@zip.com.au> <4349C2C4.4060403@psc.edu> Message-ID: <434A3D70.7090904@zip.com.au> Chris Rapier wrote: > The performance hit is, initially somewhat suprising, but on reflection > I think this is mostly going to be dependent on how the systems TCP > stacks are tuned. I can see performance decreasing in the LAN if the > receive buffer is too high. An easy test would be to run some iPerfs and > see if the system TCP receive buffer shows a similar performance hit > versus setting the the iPerf window to 64k. I'll run some similar tests > to see if I'm right. I think that what's happening is that on the source side, the buffers are growing larger than is necessary and ssh is spending disproportionately more time managing them. This would explain why I saw more impact for faster cpus: they can fill the buffers faster and thus are affected more. Going back to my earlier data: -current -hpn11 real 2m40.966s 2m57.296s (10.2% slower) user 0m33.187s 0m45.820s sys 0m31.500s 0m37.539s Note that there is a significant increase in user time. If the difference was purely due to stack tuning, I'd expect user time to be similar. I'm also going to profile ssh, but my bet is that extra time is in the buffer functions. > However, this should only be an issue with non-autotuning kernels. > Autotuning kernels such as linux 2.4.26+. 2.6+, and Windows Vista (nee > Longhorn) will adjust the receive buffer to maximize throughput. Since > HPN-SSH is auto-tuning aware this shouldn't be a problem on those > systems. On non-autotuning kernels appropriate use of the -w option > should resolve this. The Linux kernel used for the test was 2.6.12-1.1376_FC3. > Again, I'll need to test this but I'm pretty sure thats the issue. > > Darren Tucker wrote: >> Chris Rapier wrote: >> >>> As a note, we now have HPN patch for OpenSSH 4.2 at >>> http://www.psc.edu/networking/projects/hpn-ssh/ >>> >>> Its still part of the last set of patches (HPN11) so there aren't any >>> additional changes in the code. It patches, configures, compiles, and >>> passes make tests without a problem. I've not done extensive testing >>> for this version of openssh but I don't foresee any problems. >>> >>> I did run a couple tests between two patched 4.2 installs (one in >>> switzerland, the other in pennsylvania, usa) and hit around 12MB/s >>> with the hpn patch and 500KB/s with the standard install. So it still >>> seems to work as expected. >> >> >> Have you done any analysis of the impact of the patch on >> low-latency/BDP links (ie LANs)? >> >> I've been doing some work with parts of the HPN patch. For scp'ing to >> and from localhost and LANs (see below), the scp changes on their own >> (actually, a variant thereof) shows a modest improvement of 2-3% in >> throughput. That's good. >> >> For the entire patch (hpn11), however, it shows a significant >> *decrease* in throughput for the same tests: 10% slower on OpenBSD to >> localhost, 12% slower on Linux to localhost and 18% slower Linux to >> OpenBSD via a 100Mb/s LAN). That's bad. I would imagine LANs are >> more common than high BDP networks that your patch targets :-) > > I'll check this of course. We don't have any OpenBSD systems though but > I'll try to find a spare box we can blow it on to. Thanks. I'm most interested in the Linux results at this point, with and without the stack tuning. >> I suspect that the buffer size increases you do are counterproductive >> for such networks. I also suspect that you could get the same >> performance improvements on high-BDP links as you currently do by >> simply increasing the channel advertisements without the SSH buffer >> changes and relying on the TCP socket buffer for output and decrypting >> quickly for input but I'm not able to test that. > > Of course is possible to increase performance through other means. > Transferring data in parallel for example, is a great way to do this. In > fact the suggestions you made are ones we were planning on implementing > in addition to the buffer hack. Especially now that we really are CPU > limited as opposed to being buffer limited. > > However, that seems, in my view at least, to be an overly complicated > way of going about it. The buffer hack is pretty straightforward and > well known - the concept is laid out in Stevens TCP/IP Illustrated > Volume 1 after all. I'll have to dig out my copy and read that bit :-) >> Test method, with a 64MB file: >> $ time for i in 1 2 3 4 5 6 7 8 9 0; do scp -ocompression=no -o >> ciphers=arcfour /tmp/tmp localhost:/dev/null; done > > I'll try this out and let you know what I find. Could you let me know > what you had your tcp receive buffer set to when you tried these tests? > Optimally for these local tests it should be set to 64k. On OpenBSD: the default (16k send and recv). On Linux, whatever this decodes to: $ sysctl -a |egrep 'tcp.*mem' net.ipv4.tcp_rmem = 4096 87380 174760 net.ipv4.tcp_wmem = 4096 16384 131072 net.ipv4.tcp_mem = 98304 131072 196608 > By the way - I just ran the above test and didn't see any sort of > substantive difference. There was a slight edge to the HPN platform > *but* that was probably due to the scp hack. > > Of course, in this case the problem is likely to be disk speed limits > (I'm on a powerbook at the moment and its disks are slow). Bypassing scp > and doing a direct memory to memory copy is probably the right methodology. The source files for the Athlon were from RAM (/tmp mounted on mfs). The others were from local disk (reiserfs for Linux system, ufs w/softdep for the OpenBSD). -- 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. From rapier at psc.edu Tue Oct 11 01:51:10 2005 From: rapier at psc.edu (Chris Rapier) Date: Mon, 10 Oct 2005 11:51:10 -0400 Subject: HPN Patch for OpenSSH 4.2p1 Available In-Reply-To: <434A3D70.7090904@zip.com.au> References: <43209913.7020801@psc.edu> <4348C31A.5030209@zip.com.au> <4349C2C4.4060403@psc.edu> <434A3D70.7090904@zip.com.au> Message-ID: <434A8DEE.2020901@psc.edu> Here is what my test looked like. I used /dev/zero as a data source and /dev/null as a sink to avoid any disk IO issues. Compression was set to no to avoid any data compression on the stream. Cipher was RC4. A standard 4.1 server was running on port 22228 and a 4.1HPN server was running on 22229. The machine is a dual xeon 2ghz box with 1gb of ram running linux 2.4.29 and the receive buffer set to 4MB The command used was: time for i in 1 2 3 4 5 6 7 8 9 0; do head -c 100000000 /dev/zero | ./ssh -p 2222[8|9] -ocompression=no -o ciphers=arcfour localhost "cat - > /dev/null"; done 4.1p1 -> 4.1p1 real 0m22.300s user 0m18.160s sys 0m4.790s 4.1 -> 4.1HPN real 0m21.001s user 0m16.590s sys 0m4.790s 4.1HPN -> 4.1 real 0m21.982s user 0m17.380s sys 0m4.950s 4.1HPN -> 4.1HPN real 0m20.557s user 0m16.380s sys 0m4.770s Which is what I'd expect from a localhost connection. There doesn't seem to be any really statistically significant variation. Of course, its only a run of ten connections so I'll be rerunning it with a a couple hundred connections. I'll see what that looks like. I might run individual times on each connection and get some SD values just for curiosities sake. Now, here is the same test running between two machines connected via GigE on the same LAN (different subnets though average RTT of 0.859ms). The source machine I believe is single CPU Xeon 2.4Ghz, 1GB ram, linux 2.6.13. The sink is the machine referenced above. 4.1p1 -> 4.1p1 real 0m29.528s user 0m17.703 sys 0m4.276s 4.1 -> 4.1HPN real 0m22.874s user 0m17.202s sys 0m4.553s 4.1HPN -> 4.1 real 0m28.942s user 0m17.370s sys 0m4.134s 4.1HPN -> 4.1HPN real 0m22.315s user 0m16.621s sys 0m4.614s So where you saw a performance decrease I'm seeing an improvement of roughly 22%. I'm going to rerun these all these tests with more iterations but right now I'm, unfortunately, not seeing the same problems you are. Unfortunate because it just makes this a more complicated question :\ My gut feeling is that the tests, while somewhat different in details, are roughly equivilant in method. However, maybe there is a problem with my methodology. Let me know if you see anything. Chris Darren Tucker wrote: > Chris Rapier wrote: > >>The performance hit is, initially somewhat suprising, but on reflection >>I think this is mostly going to be dependent on how the systems TCP >>stacks are tuned. I can see performance decreasing in the LAN if the >>receive buffer is too high. An easy test would be to run some iPerfs and >>see if the system TCP receive buffer shows a similar performance hit >>versus setting the the iPerf window to 64k. I'll run some similar tests >>to see if I'm right. > > > I think that what's happening is that on the source side, the buffers > are growing larger than is necessary and ssh is spending > disproportionately more time managing them. This would explain why I > saw more impact for faster cpus: they can fill the buffers faster and > thus are affected more. > > Going back to my earlier data: > -current -hpn11 > real 2m40.966s 2m57.296s (10.2% slower) > user 0m33.187s 0m45.820s > sys 0m31.500s 0m37.539s > > Note that there is a significant increase in user time. If the > difference was purely due to stack tuning, I'd expect user time to be > similar. > > I'm also going to profile ssh, but my bet is that extra time is in the > buffer functions. > > >>However, this should only be an issue with non-autotuning kernels. >>Autotuning kernels such as linux 2.4.26+. 2.6+, and Windows Vista (nee >>Longhorn) will adjust the receive buffer to maximize throughput. Since >>HPN-SSH is auto-tuning aware this shouldn't be a problem on those >>systems. On non-autotuning kernels appropriate use of the -w option >>should resolve this. > > > The Linux kernel used for the test was 2.6.12-1.1376_FC3. > > >>Again, I'll need to test this but I'm pretty sure thats the issue. >> >>Darren Tucker wrote: >> >>>Chris Rapier wrote: >>> >>> >>>>As a note, we now have HPN patch for OpenSSH 4.2 at >>>>http://www.psc.edu/networking/projects/hpn-ssh/ >>>> >>>>Its still part of the last set of patches (HPN11) so there aren't any >>>>additional changes in the code. It patches, configures, compiles, and >>>>passes make tests without a problem. I've not done extensive testing >>>>for this version of openssh but I don't foresee any problems. >>>> >>>>I did run a couple tests between two patched 4.2 installs (one in >>>>switzerland, the other in pennsylvania, usa) and hit around 12MB/s >>>>with the hpn patch and 500KB/s with the standard install. So it still >>>>seems to work as expected. >>> >>> >>>Have you done any analysis of the impact of the patch on >>>low-latency/BDP links (ie LANs)? >>> >>>I've been doing some work with parts of the HPN patch. For scp'ing to >>>and from localhost and LANs (see below), the scp changes on their own >>>(actually, a variant thereof) shows a modest improvement of 2-3% in >>>throughput. That's good. >>> >>>For the entire patch (hpn11), however, it shows a significant >>>*decrease* in throughput for the same tests: 10% slower on OpenBSD to >>>localhost, 12% slower on Linux to localhost and 18% slower Linux to >>>OpenBSD via a 100Mb/s LAN). That's bad. I would imagine LANs are >>>more common than high BDP networks that your patch targets :-) >> >>I'll check this of course. We don't have any OpenBSD systems though but >>I'll try to find a spare box we can blow it on to. > > > Thanks. I'm most interested in the Linux results at this point, with > and without the stack tuning. > > >>>I suspect that the buffer size increases you do are counterproductive >>>for such networks. I also suspect that you could get the same >>>performance improvements on high-BDP links as you currently do by >>>simply increasing the channel advertisements without the SSH buffer >>>changes and relying on the TCP socket buffer for output and decrypting >>>quickly for input but I'm not able to test that. >> >>Of course is possible to increase performance through other means. >>Transferring data in parallel for example, is a great way to do this. In >>fact the suggestions you made are ones we were planning on implementing >>in addition to the buffer hack. Especially now that we really are CPU >>limited as opposed to being buffer limited. >> >>However, that seems, in my view at least, to be an overly complicated >>way of going about it. The buffer hack is pretty straightforward and >>well known - the concept is laid out in Stevens TCP/IP Illustrated >>Volume 1 after all. > > > I'll have to dig out my copy and read that bit :-) > > >>>Test method, with a 64MB file: >>>$ time for i in 1 2 3 4 5 6 7 8 9 0; do scp -ocompression=no -o >>>ciphers=arcfour /tmp/tmp localhost:/dev/null; done >> >>I'll try this out and let you know what I find. Could you let me know >>what you had your tcp receive buffer set to when you tried these tests? >>Optimally for these local tests it should be set to 64k. > > > On OpenBSD: the default (16k send and recv). > > On Linux, whatever this decodes to: > $ sysctl -a |egrep 'tcp.*mem' > net.ipv4.tcp_rmem = 4096 87380 174760 > net.ipv4.tcp_wmem = 4096 16384 131072 > net.ipv4.tcp_mem = 98304 131072 196608 > > >>By the way - I just ran the above test and didn't see any sort of >>substantive difference. There was a slight edge to the HPN platform >>*but* that was probably due to the scp hack. >> >>Of course, in this case the problem is likely to be disk speed limits >>(I'm on a powerbook at the moment and its disks are slow). Bypassing scp >>and doing a direct memory to memory copy is probably the right methodology. > > > The source files for the Athlon were from RAM (/tmp mounted on mfs). > > The others were from local disk (reiserfs for Linux system, ufs > w/softdep for the OpenBSD). > From rapier at psc.edu Tue Oct 11 02:36:48 2005 From: rapier at psc.edu (Chris Rapier) Date: Mon, 10 Oct 2005 12:36:48 -0400 Subject: HPN Patch for OpenSSH 4.2p1 Available In-Reply-To: <434A8DEE.2020901@psc.edu> References: <43209913.7020801@psc.edu> <4348C31A.5030209@zip.com.au> <4349C2C4.4060403@psc.edu> <434A3D70.7090904@zip.com.au> <434A8DEE.2020901@psc.edu> Message-ID: <434A98A0.9070506@psc.edu> Chris Rapier wrote: > So where you saw a performance decrease I'm seeing an improvement of > roughly 22%. I'm going to rerun these all these tests with more > iterations but right now I'm, unfortunately, not seeing the same > problems you are. Unfortunate because it just makes this a more > complicated question :\ This is the result for 200 iterations 4.1 -> 4.1 real 9m41.143s user 5m49.246s sys 1m27.408s 4.1 -> 4.1hpn real 7m27.732s user 5m34.037s sys 1m32.122s 4.1hpn -> 4.1 real 9m39.559s user 5m47.631s sys 1m22.784s 4.1hpn -> 4.1hpn real 7m24.340s user 5m33.001s sys 1m29.696s So I'm not sure what is happening with your results but I'm very interested in finding out. From cata at shivanet.ro Tue Oct 11 22:32:31 2005 From: cata at shivanet.ro (Catalin Toda) Date: Tue, 11 Oct 2005 15:32:31 +0300 Subject: openssh 4.2p1 bug Message-ID: <434BB0DF.608@shivanet.ro> hello, I have just installed openssh 4.2p1 and it seems that sshd child process crash if /var/empty/usr/lib do not exist. Here is a strace log ( before creating this directory): 26787 open("/etc/protocols", O_RDONLY) = -1 ENOENT (No such file or directory) 26787 getsockopt(3, SOL_IP, IP_OPTIONS, "", [0]) = 0 26787 socket(PF_UNIX, SOCK_STREAM, 0) = 6 26787 connect(6, {sa_family=AF_UNIX, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) 26787 close(6) = 0 26787 gettimeofday({1129033086, 170608}, NULL) = 0 26787 open("/etc/resolv.conf", O_RDONLY) = -1 ENOENT (No such file or directory) 26787 uname({sys="Linux", node="edge", ...}) = 0 26787 open("/etc/host.conf", O_RDONLY) = -1 ENOENT (No such file or directory) 26787 open("/etc/hosts", O_RDONLY) = -1 ENOENT (No such file or directory) 26787 open("/etc/ld.so.cache", O_RDONLY) = -1 ENOENT (No such file or directory) 26787 open("/lib/tls/i686/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 26787 stat64("/lib/tls/i686", 0xbfe596bc) = -1 ENOENT (No such file or directory) 26787 open("/lib/tls/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 26787 stat64("/lib/tls", 0xbfe596bc) = -1 ENOENT (No such file or directory) 26787 open("/lib/i686/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 26787 stat64("/lib/i686", 0xbfe596bc) = -1 ENOENT (No such file or directory) 26787 open("/lib/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 26787 stat64("/lib", 0xbfe596bc) = -1 ENOENT (No such file or directory) 26787 open("/usr/lib/tls/i686/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 26787 stat64("/usr/lib/tls/i686", 0xbfe596bc) = -1 ENOENT (No such file or directory) 26787 open("/usr/lib/tls/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 26787 stat64("/usr/lib/tls", 0xbfe596bc) = -1 ENOENT (No such file or directory) 26787 open("/usr/lib/i686/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 26787 stat64("/usr/lib/i686", 0xbfe596bc) = -1 ENOENT (No such file or directory) 26787 open("/usr/lib/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 26787 stat64("/usr/lib", 0xbfe596bc) = -1 ENOENT (No such file or directory) 26787 --- SIGSEGV (Segmentation fault) @ 0 (0) --- 26784 <... read resumed> 0xbfe5b1b8, 4) = ? ERESTARTSYS (To be restarted) 26784 --- SIGCHLD (Child exited) @ 0 (0) --- 26784 read(6, "", 4) = 0 26784 exit_group(255) = ? 1682 <... select resumed> ) = 1 (in [5]) 1682 --- SIGCHLD (Child exited) @ 0 (0) --- 1682 waitpid(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 255}], WNOHANG) = 26784 1682 waitpid(-1, 0xbf9c9ea0, WNOHANG) = 0 1682 rt_sigaction(SIGCHLD, NULL, {0x804c7d4, [], 0}, 8) = 0 1682 sigreturn() = ? (mask now []) 1682 close(5) = 0 1682 select(6, [3], NULL, NULL, NULL From dtucker at zip.com.au Tue Oct 11 23:06:56 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 11 Oct 2005 23:06:56 +1000 Subject: openssh 4.2p1 bug In-Reply-To: <434BB0DF.608@shivanet.ro> References: <434BB0DF.608@shivanet.ro> Message-ID: <434BB8F0.601@zip.com.au> Catalin Toda wrote: > I have just installed openssh 4.2p1 On what platform? > and it seems that sshd child process > crash if /var/empty/usr/lib do not exist. Here is a strace log ( > before creating this directory): If it's Linux/glibc then that's probably a known bug in glibc. See this post and the thread leading up to it: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=111061843820265 -- 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. From cata at shivanet.ro Tue Oct 11 23:16:21 2005 From: cata at shivanet.ro (Catalin Toda) Date: Tue, 11 Oct 2005 16:16:21 +0300 Subject: openssh 4.2p1 bug In-Reply-To: <434BB8F0.601@zip.com.au> References: <434BB0DF.608@shivanet.ro> <434BB8F0.601@zip.com.au> Message-ID: <434BBB25.2060506@shivanet.ro> hello darren, fedora core 2, Linux edge 2.6.13.2 #1 Fri Sep 23 08:51:19 EEST 2005 i686 athlon i386 GNU/Linux I do not think it is a bug, because after creating those directory (/var/empty/usr/lib) it worked. Darren Tucker wrote: > Catalin Toda wrote: >> I have just installed openssh 4.2p1 > > On what platform? > >> and it seems that sshd child process crash if /var/empty/usr/lib do >> not exist. Here is a strace log ( before creating this directory): > > If it's Linux/glibc then that's probably a known bug in glibc. > > See this post and the thread leading up to it: > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=111061843820265 > From andreas at mrs.ch Tue Oct 4 19:38:51 2005 From: andreas at mrs.ch (Andreas Fehr) Date: Tue, 4 Oct 2005 11:38:51 +0200 (CEST) Subject: make tests failure Message-ID: Re-post, as I think my last post didn't get through. Sorry, if somebody got it twice now Hi I run in the following make tests error and didn't find any solution to this. - This is a test on the localhost, so I guess, there is no man in the middle attack (hosts file is setup correctly, localhost points to 127.0.0.1) - I don't want to use protocol 1 anyway, so how can I skip the test? - I copied the known host file from my already installed ssh (~/.ssh/known_hosts) to ./regress/ but that didn't help - Just to be sure, I checked the 4.1 source of my current installation and it came up with the same error, but I can't remember seeing this error with the prev. installation. So I stopped the running sshd, removed the /etc/ssh directory and run the test again with the same result. - I'm running uname -a: Linux linuxbox 2.6.12.5 #1 Tue Aug 16 08:57:47 CEST 2005 ppc unknown unknown GNU/Linux Any help on this? Thanks, Andreas rm -f /home/andreas/tmp/openssh-4.2p1/regress/rsa_secsh.pub ssh-keygen -lf /home/andreas/tmp/openssh-4.2p1/regress/rsa_openssh.pub |\ awk '{print $2}' | diff - /home/andreas/tmp/openssh-4.2p1/regress/t4.ok ssh-keygen -Bf /home/andreas/tmp/openssh-4.2p1/regress/rsa_openssh.pub |\ awk '{print $2}' | diff - /home/andreas/tmp/openssh-4.2p1/regress/t5.ok ssh-keygen -if /home/andreas/tmp/openssh-4.2p1/regress/dsa_ssh2.prv > /home/andreas/tmp/openssh-4.2p1/regress//t6.out1 ssh-keygen -if /home/andreas/tmp/openssh-4.2p1/regress/dsa_ssh2.pub > /home/andreas/tmp/openssh-4.2p1/regress//t6.out2 chmod 600 /home/andreas/tmp/openssh-4.2p1/regress//t6.out1 ssh-keygen -yf /home/andreas/tmp/openssh-4.2p1/regress//t6.out1 | diff - /home/andreas/tmp/openssh-4.2p1/regress//t6.out2 ssh-keygen -lf /home/andreas/tmp/openssh-4.2p1/regress//t7.out > /dev/null ssh-keygen -Bf /home/andreas/tmp/openssh-4.2p1/regress//t7.out > /dev/null run test connect.sh ... @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA1 host key has just been changed. The fingerprint for the RSA1 key sent by the remote host is 4c:60:b8:06:71:1e:5f:76:a7:60:75:c3:4d:9d:be:8d. Please contact your system administrator. Add correct host key in /home/andreas/tmp/openssh-4.2p1/regress/known_hosts to get rid of this message. Offending key in /home/andreas/tmp/openssh-4.2p1/regress/known_hosts:2 RSA1 host key for localhost-with-alias has changed and you have requested strict checking. Host key verification failed. ssh connect with protocol 1 failed failed simple connect make[1]: *** [t-exec] Error 1 make[1]: Leaving directory `/home/andreas/tmp/openssh-4.2p1/regress' make: *** [tests] Error 2 From gert at greenie.muc.de Wed Oct 12 00:22:23 2005 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 11 Oct 2005 16:22:23 +0200 Subject: openssh 4.2p1 bug In-Reply-To: <434BBB25.2060506@shivanet.ro> References: <434BB0DF.608@shivanet.ro> <434BB8F0.601@zip.com.au> <434BBB25.2060506@shivanet.ro> Message-ID: <20051011142223.GR1060@greenie.muc.de> Hi On Tue, Oct 11, 2005 at 04:16:21PM +0300, Catalin Toda wrote: > I do not think it is a bug, because after creating those directory > (/var/empty/usr/lib) it worked. If applications crash due to nonexistance of a completely uninteresting directory - what do you call it, if not a bug? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From cata at shivanet.ro Wed Oct 12 00:54:11 2005 From: cata at shivanet.ro (Catalin Toda) Date: Tue, 11 Oct 2005 10:54:11 -0400 Subject: openssh 4.2p1 bug In-Reply-To: <20051011142223.GR1060@greenie.muc.de> References: <434BB0DF.608@shivanet.ro> <434BB8F0.601@zip.com.au> <434BBB25.2060506@shivanet.ro> <20051011142223.GR1060@greenie.muc.de> Message-ID: I meant to say that it is a bug and not related to glibc sorry for misunderstanding On Tue, 11 Oct 2005, Gert Doeringy wrote: > Date: Tue, 11 Oct 2005 16:22:23 +0200 > From: Gert Doering > To: Catalin Toda > Cc: Darren Tucker , openssh-unix-dev at mindrot.org > Subject: Re: openssh 4.2p1 bug > > Hi > > On Tue, Oct 11, 2005 at 04:16:21PM +0300, Catalin Toda wrote: > > I do not think it is a bug, because after creating those directory > > (/var/empty/usr/lib) it worked. > > If applications crash due to nonexistance of a completely uninteresting > directory - what do you call it, if not a bug? > > gert > From gert at greenie.muc.de Wed Oct 12 01:11:15 2005 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 11 Oct 2005 17:11:15 +0200 Subject: openssh 4.2p1 bug In-Reply-To: References: <434BB0DF.608@shivanet.ro> <434BB8F0.601@zip.com.au> <434BBB25.2060506@shivanet.ro> <20051011142223.GR1060@greenie.muc.de> Message-ID: <20051011151115.GT1060@greenie.muc.de> Hi On Tue, Oct 11, 2005 at 10:54:11AM -0400, Catalin Toda wrote: > I meant to say that it is a bug and not related to glibc Have you look at the URL quoted by Darren? http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=111061843820265 everybody else agrees that it's a bug in glibc, as it happens even when no openssh code is involved at all. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From xofon at pikomat.mff.cuni.cz Wed Oct 12 01:20:03 2005 From: xofon at pikomat.mff.cuni.cz (Petr Skovron) Date: Tue, 11 Oct 2005 17:20:03 +0200 Subject: scp bug: newly created dirs do not inherit sgid bit Message-ID: <20051011152003.GA6203@pikomat.mff.cuni.cz> Dear developers, I discovered that directories created by scp when recursive copying into a sgid directory do not inherit the sgid bit. I believe this is a bug. A patch to fix this is attached. Regards, Petr Skovron -------------- next part -------------- --- scp.c.orig 2005-10-11 16:50:17.000000000 +0200 +++ scp.c 2005-10-11 16:57:25.000000000 +0200 @@ -876,8 +876,12 @@ run_err("%s: set times: %s", vect[0], strerror(errno)); } - if (mod_flag) + if (mod_flag) { + if (stat(vect[0], &stb)==0) + mode= (mode & S_IRWXU) | + (stb.st_mode & ~S_IRWXU); (void) chmod(vect[0], mode); + } if (vect[0]) xfree(vect[0]); continue; From cata at shivanet.ro Wed Oct 12 01:52:22 2005 From: cata at shivanet.ro (Catalin Toda) Date: Tue, 11 Oct 2005 11:52:22 -0400 Subject: openssh 4.2p1 bug Message-ID: Yes I read it , but I have in fact two systems both with fc2, and one of them have this issue, one not as you can see first system without any problem: [root at oil root]# rpm -qa | grep glibc glibc-headers-2.3.3-27.1 glibc-kernheaders-2.4-8.44 glibc-common-2.3.3-27.1 glibc-devel-2.3.3-27.1 Linux oil 2.6.10-1.770_FC2 #1 Sat Feb 26 19:23:30 EST 2005 i586 i586 i386 GNU/Linux and second with problem descibed in previous emails: [root at edge bin]# rpm -qa | grep glibc glibc-2.3.3-27.1 glibc-headers-2.3.3-27.1 glibc-kernheaders-2.4-8.44 glibc-common-2.3.3-27.1 glibc-devel-2.3.3-27.1 From alon.barlev at gmail.com Wed Oct 12 02:19:20 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 11 Oct 2005 18:19:20 +0200 Subject: openssh and pkcs#11 In-Reply-To: <200510111109.48719.aj@dungeon.inka.de> References: <200510111109.48719.aj@dungeon.inka.de> Message-ID: <434BE608.4000608@gmail.com> Hello Andreas, On 10/11/05, Andreas Jellinghaus wrote: > Peter Koch pointed me to your posting on openssh-devel mailing list. I am very glad that he did. > I'm one of the opensc people, and from my point of view your idea > is a good one. The current openssh-opensc code has a number of issues, > for example the ssh-agent does not test the pin properly or ssh does > not ask for a pin, unless patched. Also the ssh-agent does not forget > the pin if the card is removed :( > > So I think it is a good idea to move from opensc interface to pkcs#11 > and new code with - I hope :) - those issues fixed. I think the main reason to go into PKCS#11 is that it is more standard, and widely supported... Opensc is a good project to support PKCS#15 smartcards... But PKCS#11 is the right way to go when dealing with applications. The fact that opensc supports PKCS#11 (Not very well... but support) making the decision easier. > Your comment on libp11 is right. currently we only made > the code we used elsewhere a standalone project, and haven't given > it much thought or work. I think the idea of having a common library > is good, to minimize code duplication (and using pkcs#11 directly is > not that easy). But that doesn't mean it is tied to the current code. > That code is only what was available at no cost. Yes... I figured it out... This is why I didn't use it. But I don't agree that using PKCS#11 directly is not that easy... PKCS#11 is quite simple API... The complex issue is to integrate with openssl... without overhead of reloading objects... Another issue is to deal with prompting the user to insert his card... Also, it is very difficult to support plug&play environment... All these almost always must be dealt in application level... > Feedback on improving libp11 is always welcome, or even suggestions > for a total replacement. OK... I will send them off-topic. > anway, back to the main issue: if you implement pkcs#11 support for > openssh, I would be very interested in testing and using it. > If there is anything I can help with, please let me know. > (but I'm quite busy at the moment with opensc and stuff, but I hope > once we have the next release out of the door that will improve.) Thanks!!! But I still did not receive the OK I need in order to start develop openssh support for PKCS#11. I am still waiting... Best Regards, Alon Bar-Lev From alon.barlev at gmail.com Wed Oct 12 02:21:46 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 11 Oct 2005 18:21:46 +0200 Subject: ssh-agent add PKCS#11 support In-Reply-To: <1129044796.1144.171.camel@localhost> References: <43432911.2050602@gmail.com> <1129044796.1144.171.camel@localhost> Message-ID: <434BE69A.5080201@gmail.com> Darren J Moffat wrote: > On Wed, 2005-10-05 at 02:14, Alon Bar-Lev wrote: > >>Hello, >> >>PKCS#11 is a standard API interface that can be used in >>order to access cryptographic tokens. You can find the >>specification at >>http://www.rsasecurity.com/rsalabs/node.asp?id=2133, most >>smartcard and other cryptographic device vendors support >>PKCS#11, opensc also provides PKCS#11 interface. > > > Did you get any response on this ? > > We would be very interested in this for Solaris. We use a derivative of > OpenSSH in OpenSolaris. The ssh-agent hasn't changed much, if any. > We also have very extensive PKCS#11 support including a "software > smartcard". > > If you are interested in doing this via OpenSolaris; assuming OpenSSH > isn't interested or you just want to try it with more PKCS#11 libraries > see http://www.opensolaris.org/os/community/security/ or contact us via > security-discuss at opensolaris.org. > > Thanks. > Hello, No I didn't. I am still waiting for a response... I don't think that writing this kind of code is worth the effort, unless it is going to be merged... Maybe I'll just write it and see what happens... Best Regards, Alon Bar-Lev. From openssh at baker-net.org.uk Wed Oct 12 07:41:33 2005 From: openssh at baker-net.org.uk (openssh at baker-net.org.uk) Date: Tue, 11 Oct 2005 22:41:33 +0100 Subject: Error when cross configuring openssh 4.2p1 Message-ID: <200510112241.33549.openssh@baker-net.org.uk> I see that lots of improvements have happened in cross configure support compared to version 3.8p1 but a couple of problems remain 1) The check that openpty does not reacquire controlling terminal (line 1326 in configure.ac) does not have a default value - I ran the test on my target and checked it was OK but I'm not sure what is the best default for others. 2) The etc_default_login check at line 2973 in configure.ac attempts to define a default behaviour but configure still fails unless you specify --disable-etc-default-login I suspect at least the former is dependent on what target you are building for, I'm building on a Suse 9.3 system for a armv5b-softfloat-linux target. From dtucker at zip.com.au Wed Oct 12 08:24:14 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 12 Oct 2005 08:24:14 +1000 Subject: Error when cross configuring openssh 4.2p1 In-Reply-To: <200510112241.33549.openssh@baker-net.org.uk> References: <200510112241.33549.openssh@baker-net.org.uk> Message-ID: <434C3B8E.5030205@zip.com.au> openssh at baker-net.org.uk wrote: > I see that lots of improvements have happened in cross configure support > compared to version 3.8p1 but a couple of problems remain > > 1) The check that openpty does not reacquire controlling terminal (line 1326 > in configure.ac) does not have a default value - I ran the test on my target > and checked it was OK but I'm not sure what is the best default for others. > > 2) The etc_default_login check at line 2973 in configure.ac attempts to define > a default behaviour but configure still fails unless you specify > --disable-etc-default-login > > I suspect at least the former is dependent on what target you are building > for, I'm building on a Suse 9.3 system for a armv5b-softfloat-linux target. There's a patch for this here: http://bugzilla.mindrot.org/show_bug.cgi?id=1097 I'm pretty sure it addresses #1, not sure about #2. If you can confirm that it works OK then we can apply it too. -- 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. From dtucker at zip.com.au Wed Oct 12 08:39:51 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 12 Oct 2005 08:39:51 +1000 Subject: make tests failure In-Reply-To: References: Message-ID: <434C3F37.8050207@zip.com.au> Andreas Fehr wrote: > - This is a test on the localhost, so I guess, there is no man in the > middle attack (hosts file is setup correctly, localhost points to > 127.0.0.1) > > - I don't want to use protocol 1 anyway, so how can I skip the test? There's no easy way, but if you really want to you can do "make tests LTESTS="[list of tests]". A better approach is to fix the problem (see below). > - I copied the known host file from my already installed ssh > (~/.ssh/known_hosts) to ./regress/ but that didn't help > > - Just to be sure, I checked the 4.1 source of my current installation > and it came up with the same error, but I can't remember seeing this > error with the prev. installation. So I stopped the running sshd, > removed the /etc/ssh directory and run the test again with the same > result. > > - I'm running uname -a: Linux linuxbox 2.6.12.5 #1 Tue Aug 16 08:57:47 > CEST 2005 ppc unknown unknown GNU/Linux If you're using OpenSSL 0.9.7g then there's a bug in the PPC assember code which can cause this. I don't know if any other versions are affected. The attached patch fixes this (I didn't write it, I just happen to have it handy), or alternatively you can rebuild OpenSSL without assembler optimizations. -- 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssl-0.9.7g-ppcasm.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20051012/00230784/attachment.ksh From dtucker at zip.com.au Wed Oct 12 14:16:38 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 12 Oct 2005 14:16:38 +1000 Subject: openssh 4.2p1 bug In-Reply-To: <1129044625.434bda910df3e@shivanet.ro> References: <434BB0DF.608@shivanet.ro> <434BB8F0.601@zip.com.au> <434BBB25.2060506@shivanet.ro> <20051011142223.GR1060@greenie.muc.de> <20051011151115.GT1060@greenie.muc.de> <1129044625.434bda910df3e@shivanet.ro> Message-ID: <434C8E26.8000406@zip.com.au> cata at john.ve.carpathiahost.net wrote: > Yes I read it , but I have in fact two systems both with fc2, and one of them > have this issue, one not [...] > maybe a kernel issue, > afaik glibc has only wrapper function for kernel calls... The description I got from the engineers was that the crash occurs when glibc attempts to write to a segment mapped readonly. Maybe the map-readonly feature is only enabled for certain kernels, but I don't know. Did you try the 10-line testcase program in the URL? What was the result? -- 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. From senthilkumar_sen at hotpop.com Wed Oct 12 16:17:11 2005 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Wed, 12 Oct 2005 11:47:11 +0530 Subject: Binary compatibility problem in OpenSSH from OpenSSL mailing list Message-ID: <01d101c5cef4$979147f0$220110ac@sekco> Hello All, There seems to be a binary compatibility problem with OpenSSL and OpenSSH 4.2p1. The details can be found at http://www.mail-archive.com/openssl-users at openssl.org/msg41869.html . The discussion is closed with pointing a problem in key.c in OpenSSH and corresponding thread is at http://www.mail-archive.com/openssl-users at openssl.org/msg41878.html I would like to know the comments from OpenSSH developers on the specified fix. Thanks, Senthil Kumar. From markus at openbsd.org Wed Oct 12 18:14:02 2005 From: markus at openbsd.org (Markus Friedl) Date: Wed, 12 Oct 2005 10:14:02 +0200 Subject: Binary compatibility problem in OpenSSH from OpenSSL mailing list In-Reply-To: <01d101c5cef4$979147f0$220110ac@sekco> References: <01d101c5cef4$979147f0$220110ac@sekco> Message-ID: <20051012081402.GA28852@folly> On Wed, Oct 12, 2005 at 11:47:11AM +0530, Senthil Kumar wrote: > Hello All, > > There seems to be a binary compatibility problem with OpenSSL and OpenSSH > 4.2p1. The details can be found at > http://www.mail-archive.com/openssl-users at openssl.org/msg41869.html . The > discussion is closed with pointing a problem in key.c in OpenSSH and > corresponding thread is at > http://www.mail-archive.com/openssl-users at openssl.org/msg41878.html > > fix. well, it's a bug in the library, and the library should be fixed IMHO. the manpage for EVP_MD_CTX_init has this example, and that's similar to the code we use: EVP_MD_CTX_init(&mdctx); EVP_DigestInit_ex(&mdctx, md, NULL); EVP_DigestUpdate(&mdctx, mess1, strlen(mess1)); EVP_DigestUpdate(&mdctx, mess2, strlen(mess2)); EVP_DigestFinal_ex(&mdctx, md_value, &md_len); EVP_MD_CTX_cleanup(&mdctx); if you want to make sure openssh survives when the shared lib changes the size of EVP_MD_CTX, then you need to change these files as well: % grep EVP_MD_CTX *.c kex.c: EVP_MD_CTX md; kex.c: EVP_MD_CTX md; kexdh.c: EVP_MD_CTX md; kexgex.c: EVP_MD_CTX md; key.c: EVP_MD_CTX ctx; scard.c: EVP_MD_CTX md; ssh-dss.c: EVP_MD_CTX md; ssh-dss.c: EVP_MD_CTX md; ssh-rsa.c: EVP_MD_CTX md; ssh-rsa.c: EVP_MD_CTX md; % -m From appro at fy.chalmers.se Wed Oct 12 18:27:23 2005 From: appro at fy.chalmers.se (Andy Polyakov) Date: Wed, 12 Oct 2005 10:27:23 +0200 Subject: Binary compatibility problem in OpenSSH from OpenSSL mailing list In-Reply-To: <20051012081402.GA28852@folly> References: <01d101c5cef4$979147f0$220110ac@sekco> <20051012081402.GA28852@folly> Message-ID: <434CC8EB.90709@fy.chalmers.se> >>There seems to be a binary compatibility problem with OpenSSL and OpenSSH >>4.2p1. The details can be found at >>http://www.mail-archive.com/openssl-users at openssl.org/msg41869.html . The >>discussion is closed with pointing a problem in key.c in OpenSSH and >>corresponding thread is at >>http://www.mail-archive.com/openssl-users at openssl.org/msg41878.html >> >>fix. > > well, it's a bug in the library, and the library should be fixed IMHO. Yes, and second url above refers to a patch to address this problem. Internal discussion is going on to swiftly release 0.9.7i. A. From dtucker at zip.com.au Thu Oct 13 00:18:07 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 13 Oct 2005 00:18:07 +1000 Subject: make tests failure In-Reply-To: References: Message-ID: <434D1B1F.8040802@zip.com.au> Andreas Fehr wrote: > An update to 0.9.7h did fix the problem. Thanks for your help! No prob. Be aware that 0.9.7h has a binary compatibility problem (probably only an issue so if you build openssl as a shared library). See the thread on openssh-unix-dev in the last day or so. -- 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. From tim at multitalents.net Thu Oct 13 06:30:50 2005 From: tim at multitalents.net (Tim Rice) Date: Wed, 12 Oct 2005 13:30:50 -0700 (PDT) Subject: Binary compatibility problem in OpenSSH from OpenSSL mailing list In-Reply-To: <434CC8EB.90709@fy.chalmers.se> References: <01d101c5cef4$979147f0$220110ac@sekco> <20051012081402.GA28852@folly> <434CC8EB.90709@fy.chalmers.se> Message-ID: On Wed, 12 Oct 2005, Andy Polyakov wrote: > >>There seems to be a binary compatibility problem with OpenSSL and OpenSSH > >>4.2p1. The details can be found at > >>http://www.mail-archive.com/openssl-users at openssl.org/msg41869.html . The > >>discussion is closed with pointing a problem in key.c in OpenSSH and > >>corresponding thread is at > >>http://www.mail-archive.com/openssl-users at openssl.org/msg41878.html > >> > >>fix. > > > > well, it's a bug in the library, and the library should be fixed IMHO. > > Yes, and second url above refers to a patch to address this problem. > Internal discussion is going on to swiftly release 0.9.7i. A. It looks like there is a typo in http://cvs.openssl.org/chngview?cn=14514 s/EXP_MAX_MD_SIZE/EVP_MAX_MD_SIZE/ -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From appro at fy.chalmers.se Thu Oct 13 17:55:21 2005 From: appro at fy.chalmers.se (Andy Polyakov) Date: Thu, 13 Oct 2005 09:55:21 +0200 Subject: Binary compatibility problem in OpenSSH from OpenSSL mailing list In-Reply-To: References: <01d101c5cef4$979147f0$220110ac@sekco> <20051012081402.GA28852@folly> <434CC8EB.90709@fy.chalmers.se> Message-ID: <434E12E9.2040601@fy.chalmers.se> >>Yes, and second url above refers to a patch to address this problem. >>Internal discussion is going on to swiftly release 0.9.7i. > > It looks like there is a typo in http://cvs.openssl.org/chngview?cn=14514 > s/EXP_MAX_MD_SIZE/EVP_MAX_MD_SIZE/ Thanks for catching this [my working directory for configured for fips, which is how the typo slipped through]. Cheers. A. From cata at shivanet.ro Thu Oct 13 23:25:54 2005 From: cata at shivanet.ro (Catalin Toda) Date: Thu, 13 Oct 2005 16:25:54 +0300 Subject: openssh 4.2p1 bug In-Reply-To: <434C8E26.8000406@zip.com.au> References: <434BB0DF.608@shivanet.ro> <434BB8F0.601@zip.com.au> <434BBB25.2060506@shivanet.ro> <20051011142223.GR1060@greenie.muc.de> <20051011151115.GT1060@greenie.muc.de> <1129044625.434bda910df3e@shivanet.ro> <434C8E26.8000406@zip.com.au> Message-ID: <434E6062.2020700@shivanet.ro> one one machine it worked on one did not.... Darren Tucker wrote: > cata at john.ve.carpathiahost.net wrote: >> Yes I read it , but I have in fact two systems both with fc2, and one >> of them >> have this issue, one not > [...] >> maybe a kernel issue, >> afaik glibc has only wrapper function for kernel calls... > > The description I got from the engineers was that the crash occurs when > glibc attempts to write to a segment mapped readonly. Maybe the > map-readonly feature is only enabled for certain kernels, but I don't know. > > Did you try the 10-line testcase program in the URL? What was the result? > From dtucker at zip.com.au Thu Oct 13 23:36:46 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 13 Oct 2005 23:36:46 +1000 Subject: openssh 4.2p1 bug In-Reply-To: <434E6062.2020700@shivanet.ro> References: <434BB0DF.608@shivanet.ro> <434BB8F0.601@zip.com.au> <434BBB25.2060506@shivanet.ro> <20051011142223.GR1060@greenie.muc.de> <20051011151115.GT1060@greenie.muc.de> <1129044625.434bda910df3e@shivanet.ro> <434C8E26.8000406@zip.com.au> <434E6062.2020700@shivanet.ro> Message-ID: <434E62EE.6020705@zip.com.au> Catalin Toda wrote: >> Did you try the 10-line testcase program in the URL? What was the >> result? > one one machine it worked on one did not.... Well, there you go: the system where it crashed is broken, and the brokenness has nothing to do with OpenSSH. Fix it and OpenSSH will probably work fine. -- 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. From cata at shivanet.ro Fri Oct 14 00:02:12 2005 From: cata at shivanet.ro (Catalin Toda) Date: Thu, 13 Oct 2005 17:02:12 +0300 Subject: openssh 4.2p1 bug In-Reply-To: <434E62EE.6020705@zip.com.au> References: <434BB0DF.608@shivanet.ro> <434BB8F0.601@zip.com.au> <434BBB25.2060506@shivanet.ro> <20051011142223.GR1060@greenie.muc.de> <20051011151115.GT1060@greenie.muc.de> <1129044625.434bda910df3e@shivanet.ro> <434C8E26.8000406@zip.com.au> <434E6062.2020700@shivanet.ro> <434E62EE.6020705@zip.com.au> Message-ID: <434E68E4.1040906@shivanet.ro> I have already fixed it, I have reported this in order to bring more information ... thank you for your time Darren Tucker wrote: > Catalin Toda wrote: >>> Did you try the 10-line testcase program in the URL? What was the >>> result? >> one one machine it worked on one did not.... > > Well, there you go: the system where it crashed is broken, and the > brokenness has nothing to do with OpenSSH. Fix it and OpenSSH will > probably work fine. > From openssh at baker-net.org.uk Fri Oct 14 02:54:44 2005 From: openssh at baker-net.org.uk (openssh at baker-net.org.uk) Date: Thu, 13 Oct 2005 17:54:44 +0100 Subject: Error when cross configuring openssh 4.2p1 In-Reply-To: <434C3B8E.5030205@zip.com.au> References: <200510112241.33549.openssh@baker-net.org.uk> <434C3B8E.5030205@zip.com.au> Message-ID: <200510131754.44634.openssh@baker-net.org.uk> On Tuesday 11 October 2005 23:24, Darren Tucker wrote: > openssh at baker-net.org.uk wrote: > > I see that lots of improvements have happened in cross configure support > > compared to version 3.8p1 but a couple of problems remain > > > > 1) The check that openpty does not reacquire controlling terminal (line > > 1326 in configure.ac) does not have a default value - I ran the test on > > my target and checked it was OK but I'm not sure what is the best default > > for others. > > > > 2) The etc_default_login check at line 2973 in configure.ac attempts to > > define a default behaviour but configure still fails unless you specify > > --disable-etc-default-login > > > > I suspect at least the former is dependent on what target you are > > building for, I'm building on a Suse 9.3 system for a > > armv5b-softfloat-linux target. > > There's a patch for this here: > http://bugzilla.mindrot.org/show_bug.cgi?id=1097 > > I'm pretty sure it addresses #1, not sure about #2. > > If you can confirm that it works OK then we can apply it too. I can confirm that it fixes the first problem but not the second. I've only tried building so far, not running but as I'm running a version I built by defaulting the first test I'm fairly confident this patch will behave the same. I also noticed that the code to build/etc/ssh/ssh_prng_cmds generates commands that work on the host rather than the target when cross compiling. This doesn't matter too much as it won't be used unless the user specifies --with-rand-helper as it is assumed SSLs PRNG is seeded internally for cross compiles but the failure mechanism isn't good - If I'm reading correctly any commands not supported on the target will just not be used for entropy generation potentially resulting in lower than expected entropy, possibly even completely predictable on small systems. As it isn't possible to generate this reliably when cross compiling the ideal option would be to force the user to supply a file of commands to use if it will be usedbut I'm happy to accept that may be too much effort to be worthwhile for a rare problem. If you want a cross compile environment to test any future patches in then Dan Kegel's crosstool (http://kegel.com/crosstool/) will build one for you fairly easily. I've tested it with Linux and cygwin hosts and heard reports of it working on OS/X so I'd expect it to work on other BSD based OSs too. From openssh-unix-dev at mlists.thewrittenword.com Fri Oct 14 09:08:40 2005 From: openssh-unix-dev at mlists.thewrittenword.com (Albert Chin) Date: Thu, 13 Oct 2005 18:08:40 -0500 Subject: scp bug: newly created dirs do not inherit sgid bit In-Reply-To: <20051011152003.GA6203@pikomat.mff.cuni.cz> References: <20051011152003.GA6203@pikomat.mff.cuni.cz> Message-ID: <20051013230840.GG56312@mail1.thewrittenword.com> On Tue, Oct 11, 2005 at 05:20:03PM +0200, Petr Skovron wrote: > > I discovered that directories created by scp when recursive > copying into a sgid directory do not inherit the sgid bit. I believe > this is a bug. A patch to fix this is attached. Does rcp do so? -- albert chin (china at thewrittenword.com) From xofon at pikomat.mff.cuni.cz Fri Oct 14 10:10:04 2005 From: xofon at pikomat.mff.cuni.cz (Petr Skovron) Date: Fri, 14 Oct 2005 02:10:04 +0200 Subject: scp bug: newly created dirs do not inherit sgid bit In-Reply-To: <20051013230840.GG56312@mail1.thewrittenword.com> References: <20051011152003.GA6203@pikomat.mff.cuni.cz> <20051013230840.GG56312@mail1.thewrittenword.com> Message-ID: <20051014001004.GA16674@pikomat.mff.cuni.cz> On Thu, Oct 13, 2005 at 06:08:40PM -0500, Albert Chin wrote: > On Tue, Oct 11, 2005 at 05:20:03PM +0200, Petr Skovron wrote: > > > > I discovered that directories created by scp when recursive > > copying into a sgid directory do not inherit the sgid bit. I believe > > this is a bug. A patch to fix this is attached. > > Does rcp do so? The version /* $OpenBSD: rcp.c,v 1.41 2005/03/31 18:39:21 deraadt Exp $ */ seems to behave the same, with the respective code around lines 677 (mkdir) and 689 (chmod). > albert chin (china at thewrittenword.com) Petr Sk From shadoweyez at gmail.com Sat Oct 15 10:59:17 2005 From: shadoweyez at gmail.com (David) Date: Fri, 14 Oct 2005 17:59:17 -0700 Subject: Openssh hash request Message-ID: <43505465.4060102@gmail.com> Please forgive if this is the wrong place... As a user of the excellent ssh and sshd I would like to see the next version of openssh contain support for the SHA-2 hashes (SHA-256, SHA-384, and SHA-512) as the SHA-1 hash is now known to be vulnerable to a 2^69 and possibly a 2^63 key-space search. As of version 0.98 openssl contained support for these hashes so it would be nice if openssh followed suit. I posted this request before on comp.security.ssh and was correctly told that by default sshd regenerates the key every 60 mins. But consider a server using SHA-1, and an attacker who wants the user/password, or a file being transfered, and captures the cipher data. While they cannot see your session in "real time" they still could capture the data and key-search the SHA-1 hash, making it easier to break the key. While I'm no crypto-expert, this does _NOT_ seem like a good thing(tm). Are there any plans to implement these hashes into openssh? TIA, David From smooge at gmail.com Sat Oct 15 12:50:31 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Fri, 14 Oct 2005 20:50:31 -0600 Subject: Openssh hash request In-Reply-To: <43505465.4060102@gmail.com> References: <43505465.4060102@gmail.com> Message-ID: <80d7e4090510141950h79b7f16fx9809aa3358514dc2@mail.gmail.com> On 10/14/05, David wrote: > Please forgive if this is the wrong place... > > As a user of the excellent ssh and sshd I would like to see the next > version of openssh contain support for the SHA-2 hashes (SHA-256, > SHA-384, and SHA-512) as the SHA-1 hash is now known to be vulnerable to > a 2^69 and possibly a 2^63 key-space search. As of version 0.98 openssl > contained support for these hashes so it would be nice if openssh > followed suit. There are several questions that would need to be answered: 1) Does the SSH spec allow for any algorithms other than SHA1? If it doesnt then the first place to work it through would be the IETF. [I do not know the answer myself..] 2) How long do you want your message to be secure? If you say forever... then you are best off not saying anything. If you say 100 years.. it would probably be best not to say anything. If you are looking for 10 years then does the search space time for 2^60 or more fit into that time frame. (Searching 2^30 (approx 1 billion keys) a second it would take 34 years to search for this. This doesnt take in account parrelization or other items). -- Stephen J Smoogen. CSIRT/Linux System Administrator From dtucker at zip.com.au Sat Oct 15 14:40:17 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 15 Oct 2005 14:40:17 +1000 Subject: Error when cross configuring openssh 4.2p1 In-Reply-To: <200510131754.44634.openssh@baker-net.org.uk> References: <200510112241.33549.openssh@baker-net.org.uk> <434C3B8E.5030205@zip.com.au> <200510131754.44634.openssh@baker-net.org.uk> Message-ID: <43508831.2060607@zip.com.au> openssh at baker-net.org.uk wrote: > On Tuesday 11 October 2005 23:24, Darren Tucker wrote: >> http://bugzilla.mindrot.org/show_bug.cgi?id=1097 >> >> I'm pretty sure it addresses #1, not sure about #2. >> >> If you can confirm that it works OK then we can apply it too. > > I can confirm that it fixes the first problem but not the second. I've only > tried building so far, not running but as I'm running a version I built by > defaulting the first test I'm fairly confident this patch will behave the > same. I've attached another patch which tries to fix the /etc/default/login thing. > I also noticed that the code to build/etc/ssh/ssh_prng_cmds generates > commands that work on the host rather than the target when cross compiling. > This doesn't matter too much as it won't be used unless the user specifies > --with-rand-helper as it is assumed SSLs PRNG is seeded internally for cross > compiles but the failure mechanism isn't good - If I'm reading correctly any > commands not supported on the target will just not be used for entropy > generation potentially resulting in lower than expected entropy, possibly > even completely predictable on small systems. As it isn't possible to > generate this reliably when cross compiling the ideal option would be to > force the user to supply a file of commands to use if it will be used but I'm > happy to accept that may be too much effort to be worthwhile for a rare > problem. Regardless of the where the commands come from, you still have to have enough of them working to provide enough entropy (based on the entropy-per-byte estimates in ssh_prng_cmds) for OpenSSL's prng to consider itself seeded. > If you want a cross compile environment to test any future patches in then Dan > Kegel's crosstool[...] Thanks, I'll check that out. -- 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. From deraadt at cvs.openbsd.org Sat Oct 15 16:15:51 2005 From: deraadt at cvs.openbsd.org (Theo de Raadt) Date: Sat, 15 Oct 2005 00:15:51 -0600 Subject: Openssh hash request In-Reply-To: Your message of "Fri, 14 Oct 2005 17:59:17 PDT." <43505465.4060102@gmail.com> Message-ID: <200510150615.j9F6Fp4c002229@cvs.openbsd.org> > Please forgive if this is the wrong place... > > As a user of the excellent ssh and sshd I would like to see the next > version of openssh contain support for the SHA-2 hashes (SHA-256, > SHA-384, and SHA-512) as the SHA-1 hash is now known to be vulnerable to > a 2^69 and possibly a 2^63 key-space search. As of version 0.98 openssl > contained support for these hashes so it would be nice if openssh > followed suit. > > I posted this request before on comp.security.ssh and was correctly told > that by default sshd regenerates the key every 60 mins. But consider a > server using SHA-1, and an attacker who wants the user/password, or a > file being transfered, and captures the cipher data. While they cannot > see your session in "real time" they still could capture the data and > key-search the SHA-1 hash, making it easier to break the key. > > While I'm no crypto-expert, this does _NOT_ seem like a good thing(tm). > Are there any plans to implement these hashes into openssh? Youare no crypto-expert, but as the SSH protocol uses these things as HMAC varients, none of the above makes any sense. From mkvemuri at yahoo.com Sat Oct 15 16:54:02 2005 From: mkvemuri at yahoo.com (Murali K. Vemuri) Date: Fri, 14 Oct 2005 23:54:02 -0700 (PDT) Subject: help with openssh Message-ID: <20051015065402.87048.qmail@web50108.mail.yahoo.com> Can anybody help me with this : ? I first generated rsa key with this : ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key then I went on to generate the DSA key too....(just incase my SSHD does not like RSA). ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key and then I ran root at 00_00_09_PECA_NP1:/usr/bin# sshd -d -d -d -d -d -d -d -d -d debug3: RNG is ready, skipping seeding debug2: read_server_config: filename /etc/ssh/sshd_config debug1: sshd version OpenSSH_3.7.1p2 debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type Could not load host key: /etc/ssh/ssh_host_rsa_key debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key. debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type Could not load host key: /etc/ssh/ssh_host_dsa_key Disabling protocol version 2. Could not load host key sshd: no hostkeys available -- exiting. and this is how my sshd_config in /etc/ssh/ looks like: # $OpenBSD: sshd_config,v 1.65 2003/08/28 12:54:34 markus Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. #Port 22 Protocol 2 #ListenAddress 0.0.0.0 #ListenAddress :: # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 768 # Logging #obsoletes QuietMode and FascistLogging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m PermitRootLogin yes #StrictModes yes RSAAuthentication yes #PubkeyAuthentication yes #AuthorizedKeysFile .ssh/authorized_keys # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCreds yes # Set this to 'yes' to enable PAM authentication (via challenge-response) # and session processing. Depending on your PAM configuration, this may # bypass the setting of 'PasswordAuthentication' UsePAM yes #AllowTcpForwarding yes #GatewayPorts no #X11Forwarding no #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #KeepAlive yes #UseLogin no UsePrivilegeSeparation yes #PermitUserEnvironment no #Compression yes #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS yes #PidFile /var/run/sshd.pid #MaxStartups 10 # no default banner path #Banner /some/path # override default of no subsystems Subsystem sftp /usr/lib/openssh/sftp-server regards MKV __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From senthilkumar_sen at hotpop.com Sat Oct 15 17:27:13 2005 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Sat, 15 Oct 2005 12:57:13 +0530 Subject: help with openssh References: <20051015065402.87048.qmail@web50108.mail.yahoo.com> Message-ID: <036601c5d159$df6749f0$220110ac@sekco> "Murali K. Vemuri" wrote: > Can anybody help me with this : ? > > I first generated rsa key with this : > > ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key > > then I went on to generate the DSA key too....(just incase my SSHD does > not > like RSA). > > ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key > http://www.mail-archive.com/secureshell at securityfocus.com/msg00479.html is this helping you? Thanks, Senthil Kumar. From bob at proulx.com Mon Oct 17 05:59:33 2005 From: bob at proulx.com (Bob Proulx) Date: Sun, 16 Oct 2005 13:59:33 -0600 Subject: scp bug: newly created dirs do not inherit sgid bit In-Reply-To: <20051014001004.GA16674@pikomat.mff.cuni.cz> References: <20051011152003.GA6203@pikomat.mff.cuni.cz> <20051013230840.GG56312@mail1.thewrittenword.com> <20051014001004.GA16674@pikomat.mff.cuni.cz> Message-ID: <20051016195933.GA11119@dementia.proulx.com> Petr Skovron wrote: > Albert Chin wrote: > > Petr Skovron wrote: > > > I discovered that directories created by scp when recursive > > > copying into a sgid directory do not inherit the sgid bit. I believe > > > this is a bug. A patch to fix this is attached. > > > > Does rcp do so? > > The version > /* $OpenBSD: rcp.c,v 1.41 2005/03/31 18:39:21 deraadt Exp $ */ > seems to behave the same, with the respective code around lines 677 > (mkdir) and 689 (chmod). Because rcp was developed on BSD a better question seems to me to be what is the overall behavior of using rcp on BSD systems? AFAIK directories always behave as if the sgid bit is set there. (The behavior originated there and sgid simulates it on SysV systems.) Therefore no special handling is needed to get the overall behavior on BSD systems. Bob From bob at proulx.com Mon Oct 17 06:09:58 2005 From: bob at proulx.com (Bob Proulx) Date: Sun, 16 Oct 2005 14:09:58 -0600 Subject: scp bug: newly created dirs do not inherit sgid bit In-Reply-To: <20051011152003.GA6203@pikomat.mff.cuni.cz> References: <20051011152003.GA6203@pikomat.mff.cuni.cz> Message-ID: <20051016200958.GB11119@dementia.proulx.com> Petr Skovron wrote: > Dear developers, I am not an ssh developer but your issue interested me. > I discovered that directories created by scp when recursive > copying into a sgid directory do not inherit the sgid bit. I believe > this is a bug. A patch to fix this is attached. I was not able to recreate your issue on my GNU/Linux system. Therefore I don't think I understand it fully. Could you create a small test case that illustrates the problem? I tried the following. mkdir foodir bardir chgrp staff foodir chmod g+ws foodir touch bardir/bar scp -r bardir foodir/ ls -ld foodir foodir/bardir foodir/bardir/bar drwxrwsr-x 3 bob staff 72 2005-10-16 14:07 foodir drwxr-sr-x 2 bob staff 72 2005-10-16 14:07 foodir/bardir -rw-r--r-- 1 bob staff 0 2005-10-16 14:07 foodir/bardir/bar On my system the sgid bit was inherited as I expected. Are you using the 'scp -p' option? If so then the -p will explicitly set the permissions of the newly created files to the mode in the source. This will override the sgid directory behavior as expected. Bob From djm at mindrot.org Mon Oct 17 09:36:08 2005 From: djm at mindrot.org (Damien Miller) Date: Mon, 17 Oct 2005 09:36:08 +1000 (EST) Subject: Openssh hash request In-Reply-To: <80d7e4090510141950h79b7f16fx9809aa3358514dc2@mail.gmail.com> References: <43505465.4060102@gmail.com> <80d7e4090510141950h79b7f16fx9809aa3358514dc2@mail.gmail.com> Message-ID: On Fri, 14 Oct 2005, Stephen J. Smoogen wrote: > On 10/14/05, David wrote: >> Please forgive if this is the wrong place... >> >> As a user of the excellent ssh and sshd I would like to see the next >> version of openssh contain support for the SHA-2 hashes (SHA-256, >> SHA-384, and SHA-512) as the SHA-1 hash is now known to be vulnerable to >> a 2^69 and possibly a 2^63 key-space search. As of version 0.98 openssl >> contained support for these hashes so it would be nice if openssh >> followed suit. > > There are several questions that would need to be answered: > > 1) Does the SSH spec allow for any algorithms other than SHA1? If it > doesnt then the first place to work it through would be the IETF. [I > do not know the answer myself..] For the per-packet MAC, only HMAC-SHA1 and HMAC-MD5 are supported. In reality, even these are overkill (in terms of MAC length). Wang, Yin and Yu's results on SHA1 don't matter for its use in HMAC anyway. > 2) How long do you want your message to be secure? If you say > forever... then you are best off not saying anything. If you say 100 > years.. it would probably be best not to say anything. If you are > looking for 10 years then does the search space time for 2^60 or more > fit into that time frame. (Searching 2^30 (approx 1 billion keys) a > second it would take 34 years to search for this. This doesnt take in > account parrelization or other items). Finding a hash collision doesn't render your encrypted messages vulnerable. -d From xofon at pikomat.mff.cuni.cz Mon Oct 17 21:48:29 2005 From: xofon at pikomat.mff.cuni.cz (Petr Skovron) Date: Mon, 17 Oct 2005 13:48:29 +0200 Subject: scp bug: newly created dirs do not inherit sgid bit In-Reply-To: <20051016200958.GB11119@dementia.proulx.com> References: <20051011152003.GA6203@pikomat.mff.cuni.cz> Message-ID: <20051017114829.GA24588@pikomat.mff.cuni.cz> > I was not able to recreate your issue on my GNU/Linux system. > Therefore I don't think I understand it fully. Could you create a > small test case that illustrates the problem? I tried the following. > > mkdir foodir bardir > chgrp staff foodir > chmod g+ws foodir > touch bardir/bar > scp -r bardir foodir/ When scp copies a local file to local, ordinary cp is invoked (as scp -v should show), see scp.c line +-462. > ls -ld foodir foodir/bardir foodir/bardir/bar > drwxrwsr-x 3 bob staff 72 2005-10-16 14:07 foodir > drwxr-sr-x 2 bob staff 72 2005-10-16 14:07 foodir/bardir > -rw-r--r-- 1 bob staff 0 2005-10-16 14:07 foodir/bardir/bar > > On my system the sgid bit was inherited as I expected. To recreate the relevant behaviour, use scp -r localhost:bardir foodir or scp -r bardir localhost:foodir (my system is linux debian 3.1 with kernel 2.4.30). When replying, please send me a Cc:, as I am not a member of the list. Thanks. > Bob Petr From smooge at gmail.com Mon Oct 17 23:49:51 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Mon, 17 Oct 2005 07:49:51 -0600 Subject: Openssh hash request In-Reply-To: References: <43505465.4060102@gmail.com> <80d7e4090510141950h79b7f16fx9809aa3358514dc2@mail.gmail.com> Message-ID: <80d7e4090510170649l360f3340neff8691940c72254@mail.gmail.com> On 10/16/05, Damien Miller wrote: > On Fri, 14 Oct 2005, Stephen J. Smoogen wrote: > > > For the per-packet MAC, only HMAC-SHA1 and HMAC-MD5 are supported. In > reality, even these are overkill (in terms of MAC length). > > Wang, Yin and Yu's results on SHA1 don't matter for its use in HMAC > anyway. > > > 2) How long do you want your message to be secure? If you say > > forever... then you are best off not saying anything. If you say 100 > > years.. it would probably be best not to say anything. If you are > > looking for 10 years then does the search space time for 2^60 or more > > fit into that time frame. (Searching 2^30 (approx 1 billion keys) a > > second it would take 34 years to search for this. This doesnt take in > > account parrelization or other items). > > Finding a hash collision doesn't render your encrypted messages > vulnerable. > Thanks Damien for taking the time to clarifying me. After Theo's email, I read the HMAC RFC and then some crypto books to clarify what my mistakes were. I realized I was wrong on several levels because of mis-thinking that the SHA-1 problem was a way to bounce back an unencrypted packet versus a collision. The assumptions I was making was that the plain text was always a set size and no key was involved. Both of these assumptions are invalid. I should not have posted part 2 before doing that reading... I would have realized the whole question was mute. Again thankyou for taking the time to clarify. You guys are busy enough and I should have kept my mouth shut. -- Stephen J Smoogen. CSIRT/Linux System Administrator From mike.d.cross at btconnect.com Wed Oct 19 02:25:59 2005 From: mike.d.cross at btconnect.com (Mr.Mike Cross) Date: Tue, 18 Oct 2005 17:25:59 +0100 Subject: Help with SSH V4.2p1 and netgroups in password file - OSF/1 Message-ID: <06CEEEF03AF17242A37146CDD777632E9C2FD1@HEMV2CUKER.he.local> Hi I'm using either V3.2 or V4.2p1 depending on the system. Server - OSF/1 V5.1 latest patch kit. If the system has all the accounts in the password file - ssh lets the users login. If the system has "+" at the end of the passwd file, users in the local password file or in NIS can login if I change the /etc/svc.conf to have "passwd=local" and add + at users:x::::: to the passwd file, the users who are local to the passwd file can login, but the users in the netgroup fail to login, just getting access failed and re-prompted for their password. The system works for login/telnet/ftp/rsh/login so I believe that the system is configured correctly, have I missed some configuration option? Any help will be very welcome. Thanks Mike From dtucker at zip.com.au Wed Oct 19 23:26:15 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 19 Oct 2005 23:26:15 +1000 Subject: Help with SSH V4.2p1 and netgroups in password file - OSF/1 In-Reply-To: <06CEEEF03AF17242A37146CDD777632E9C2FD1@HEMV2CUKER.he.local> References: <06CEEEF03AF17242A37146CDD777632E9C2FD1@HEMV2CUKER.he.local> Message-ID: <43564977.5000306@zip.com.au> Mr.Mike Cross wrote: > I'm using either V3.2 or V4.2p1 depending on the system. I don't think there was an OpenSSH 3.2 release (there was 3.2.2p1 and 3.2.3p1). > Server - OSF/1 V5.1 latest patch kit. > > If the system has all the accounts in the password file - ssh lets > the users login. > > If the system has "+" at the end of the passwd file, users in the > local password file or in NIS can login > > if I change the /etc/svc.conf to have "passwd=local" and add > + at users:x::::: to the passwd file, the users who are local to the passwd > file can login, but the users in the netgroup fail to login, just > getting access failed and re-prompted for their password. OpenSSH's sshd will check that the user has a valid passwd entry (as returned by getpwnam). You need to tell /etc/svc.conf (or whatever the equivalent to /etc/nsswitch.conf is) to look in NIS too. -- 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. From hadmut at danisch.de Thu Oct 20 05:50:17 2005 From: hadmut at danisch.de (Hadmut Danisch) Date: Wed, 19 Oct 2005 21:50:17 +0200 Subject: scp and IPv6 address? Message-ID: <20051019195017.GA22068@danisch.de> Hi, I was just using ssh to access an IPv6 machine. ssh root at 2002:1234::1 (example address) works, while scp root at 2002:1234::1:/etc/motd . works not, scp parses this as hostname 2002 and file path 1234::1:/etc/motd It's a syntax problem. The manpage addresses this problem for -L and -R arguments, but not for scp arguments. Any idea how to deal with this problem? regards Hadmut From logix at foobar.franken.de Thu Oct 20 06:12:51 2005 From: logix at foobar.franken.de (Harold Gutch) Date: Wed, 19 Oct 2005 22:12:51 +0200 Subject: scp and IPv6 address? In-Reply-To: <20051019195017.GA22068@danisch.de> References: <20051019195017.GA22068@danisch.de> Message-ID: <20051019201251.GC51833@foobar.franken.de> On Wed, Oct 19, 2005 at 09:50:17PM +0200, Hadmut Danisch wrote: > I was just using ssh to access an IPv6 machine. > > ssh root at 2002:1234::1 (example address) > > works, while > > scp root at 2002:1234::1:/etc/motd . > > works not, scp parses this as hostname 2002 and file path > 1234::1:/etc/motd > > It's a syntax problem. > > The manpage addresses this problem for -L and -R arguments, but not > for scp arguments. Any idea how to deal with this problem? scp root@\[2002:1234::1\]:/etc/motd . works for me. bye, Harold From Jason.C.Burns at wellsfargo.com Fri Oct 21 02:02:00 2005 From: Jason.C.Burns at wellsfargo.com (Jason.C.Burns at wellsfargo.com) Date: Thu, 20 Oct 2005 11:02:00 -0500 Subject: SSH, glibc, and Red Hat Message-ID: Greetings all, I have a quick question. I'm building an rpm (ssh 4.2p1) for some RH-AS machines and it's been working just fine. However, I needed to install it on an older box (AS 2.1), and received the following error: starting /usr/sbin/sshd... /usr/sbin/sshd: /lib/i686/libc.so.6: version `GLIBC_2.3' not found (required by /usr/sbin/sshd) /etc/init.d/wfssh: Error 1 starting /usr/sbin/sshd... bailing. My only question is that is openssh dependant on libc >= 2.3, or is this due to the version of libc on my build machine? I couldn't find any documentation on dependencies, so if that exists, if someone could point me that way as well, I would most appreciate it. Thanks! Jason From GILBERT.R.LOOMIS at saic.com Fri Oct 21 02:16:32 2005 From: GILBERT.R.LOOMIS at saic.com (Loomis, Rip) Date: Thu, 20 Oct 2005 12:16:32 -0400 Subject: SSH, glibc, and Red Hat Message-ID: <4E25ECBBC03F874CBAD03399254ADFDE105966@US-Columbia-CIST.mail.saic.com> > I have a quick question. I'm building an rpm (ssh 4.2p1) for > some RH-AS > machines and it's been working just fine. However, I needed > to install > it on an older box (AS 2.1), and received the following error: [[deleted]] > My only question is that is openssh dependant on libc >= 2.3, > or is this due to the version of libc on my build machine? This is due to the version of libc on your build machine. If you need to support an older box you're going to either need to build on that box (or one with a compatible set of libraries) or else find a way to specify linkage with the older set of libraries. The usual solution is the former--I still have functional Solaris 2.5.1 boxes here just in case, to use as build hosts. Hope this helps-- --Rip From bryce1 at obviously.com Fri Oct 21 06:06:43 2005 From: bryce1 at obviously.com (Bryce Nesbitt (mailing list account)) Date: Thu, 20 Oct 2005 13:06:43 -0700 Subject: KeepAlive/ClientAliveInterval not working? Idle timeout. Message-ID: <4357F8D3.3010201@obviously.com> I have set /etc/ssh/sshd_config with: KeepAlive yes ClientAliveInterval 3 However, no KeepAlive type messages seem to be sent. I've verified this by looking at the network lights, which don't flicker every 3 seconds. I am attempting to keep interactive ssh sessions alive longer. If don't type anything for about 2 minutes, the sessions close. If I run a "idle" script (which just prints to the screen every 30 seconds) the sessions stay open. Sessions to a different host stay open, so I don't think it is a client problem. My client is ttsh on Windows 2000 My server is OpenSSH 3.1p1 (from RedHat) My host is RedHat Linux Is this a bug? Does anyone have advice on keeping interactive terminal ssh sessions from timing out? I have reviewed past posts to this list without luck. This message about sshd timeouts was the closest topic: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=103077014128847&w=2 From johnb at ugrad.cs.ualberta.ca Fri Oct 21 06:46:04 2005 From: johnb at ugrad.cs.ualberta.ca (John Bartoszewski) Date: Thu, 20 Oct 2005 14:46:04 -0600 Subject: KeepAlive/ClientAliveInterval not working? Idle timeout. In-Reply-To: <4357F8D3.3010201@obviously.com> References: <4357F8D3.3010201@obviously.com> Message-ID: <20051020204604.GA27774@ugrad.cs.ualberta.ca> On Thu, Oct 20, 2005 at 01:06:43PM -0700, Bryce Nesbitt (mailing list account) wrote: > My client is ttsh on Windows 2000 Does ttsh do Protocol 2? From tim at multitalents.net Fri Oct 21 06:54:03 2005 From: tim at multitalents.net (Tim Rice) Date: Thu, 20 Oct 2005 13:54:03 -0700 (PDT) Subject: KeepAlive/ClientAliveInterval not working? Idle timeout. In-Reply-To: <4357F8D3.3010201@obviously.com> References: <4357F8D3.3010201@obviously.com> Message-ID: On Thu, 20 Oct 2005, Bryce Nesbitt (mailing list account) wrote: > I have set /etc/ssh/sshd_config with: > KeepAlive yes > ClientAliveInterval 3 > > However, no KeepAlive type messages seem to be sent. I've verified this > by looking at the network lights, which don't flicker every 3 seconds. > > I am attempting to keep interactive ssh sessions alive longer. If > don't type anything for about 2 minutes, the sessions close. If I run a > "idle" script (which just prints to the screen every 30 seconds) the > sessions stay open. Sessions to a different host stay open, so I don't > think it is a client problem. This works on more current versions. Usefull with sonicwall firewalls. # turn KeepAlive off and check the client every 5 minutes # fail after 6 tries (30 minutes) # should take care of intermintint LAN problems TCPKeepAlive no ClientAliveInterval 300 ClientAliveCountMax 6 KeepAlive became TCPKeepAlive at about version 3.8 > > My client is ttsh on Windows 2000 > My server is OpenSSH 3.1p1 (from RedHat) > My host is RedHat Linux > > Is this a bug? Does anyone have advice on keeping interactive terminal > ssh sessions from timing out? > > I have reviewed past posts to this list without luck. This message > about sshd timeouts was the closest topic: > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=103077014128847&w=2 > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mike.d.cross at btconnect.com Sat Oct 22 04:15:19 2005 From: mike.d.cross at btconnect.com (Mike D Cross) Date: Fri, 21 Oct 2005 19:15:19 +0100 Subject: Help with SSH V4.2p1 and netgroups in password file - OSF/1 References: <06CEEEF03AF17242A37146CDD777632E9C2FD1@HEMV2CUKER.he.local> <43564977.5000306@zip.com.au> Message-ID: <00f201c5d66b$664352a0$0508a8c0@CPQ28337508517> Darren Thanks for the response, we are using 3.2.2p1, my mistake, sorry We finally realised that the ":x:" was the issue, removing it solved the problem. Mike ----- Original Message ----- From: "Darren Tucker" To: "Mr.Mike Cross" Cc: Sent: Wednesday, October 19, 2005 2:26 PM Subject: Re: Help with SSH V4.2p1 and netgroups in password file - OSF/1 > Mr.Mike Cross wrote: > > I'm using either V3.2 or V4.2p1 depending on the system. > > I don't think there was an OpenSSH 3.2 release (there was 3.2.2p1 and > 3.2.3p1). > > > Server - OSF/1 V5.1 latest patch kit. > > > > If the system has all the accounts in the password file - ssh lets > > the users login. > > > > If the system has "+" at the end of the passwd file, users in the > > local password file or in NIS can login > > > > if I change the /etc/svc.conf to have "passwd=local" and add > > + at users:x::::: to the passwd file, the users who are local to the passwd > > file can login, but the users in the netgroup fail to login, just > > getting access failed and re-prompted for their password. > > OpenSSH's sshd will check that the user has a valid passwd entry (as > returned by getpwnam). You need to tell /etc/svc.conf (or whatever the > equivalent to /etc/nsswitch.conf is) to look in NIS too. > > -- > 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. > > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.344 / Virus Database: 267.12.4/142 - Release Date: 18/10/2005 > > From alon.barlev at gmail.com Sun Oct 23 08:37:58 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 22 Oct 2005 22:37:58 +0000 Subject: openssh PKCS#11 support Message-ID: <435ABF46.1080802@gmail.com> Hello All, As I promised, I've completed and initial patch for openssh PKCS#11 support. The same framework is used also by openvpn. I want to help everyone who assisted during development. This patch is based on the X.509 patch from http://roumenpetrov.info/openssh/ written by Rumen Petrov, supporting PKCS#11 without X.509 looks like a bad idea. *So the first question is: What is the merge status of Ruman's patch?* The PKCS#11 patch modify ssh-add and ssh-agent to support PKCS#11 private keys and certificates. It allows using multiple PKCS#11 providers at the same time, selecting keys by id, label or certificate subject, handling card removal and card insert events, supports card insert to a different slot, handling session expiration. One significant change is that the ssh-agent prompts for passwords now... So you need to configure it with a program that asks for PIN, a program such as x11-ssh-askpass. Current implementation (ssh-add asks for passwords) is not valid for dynamic smartcard environment. *So the second question is whether this approach of handling passwords is valid for merge?* Current implementation uses the askpin program also for promoting card insert... Don't be confused, it only expects ok or cancel. If we continue in merge I will also allow select a different program for card prompt. A common scenario is the following: $ ssh-agent xterm -> $ ssh-add --pkcs11-ask-pin `which x11-ssh-askpass` $ ssh-add --pkcs11-add-provider --pkcs11-provider /usr/lib/pkcs11/MyProvider.so $ ssh-add --pkcs11-add-id --pkcs11-slot-type label --pkcs11-slot "MyToken" --pkcs11-id-type subject --pkcs11-id "/C=XX/CN=YY" $ ssh myhost In order to see available object, you can use: $ ssh-add --pkcs11-show-slots --pkcs11-provider /usr/lib/pkcs11/MyProvider.so Opensc users should add: --pkcs11-sign-mode sign $ ssh-add --pkcs11-show-objects --pkcs11-provider /usr/lib/pkcs11/MyProvider.so --pkcs11-slot 0 Look at ssh-add for more options. If this patch is finally accepted, I believe that all opensc code can be removed from all components of openssh, and simply use the opensc PKCS#11 provider. Some general comments 1. I think that ssh-add should be cleaned up, and support arguments properly, the openbsd-compact does not getopt_long. 2, I think that it is best that ssh-agent have a configuration file, so that static configurations may be provided, also ssh-agent lacks logging in none debugging mode, this should also be corrected. 3. I don't support reader plug&play for now... Since PKCS#11 does not support it. It can be supported on the price of invalidating all open sessions. Looking forward to receive any comments, Best Regards, Alon Bar-Lev. From alon.barlev at gmail.com Mon Oct 24 08:37:17 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon, 24 Oct 2005 00:37:17 +0200 Subject: openssh PKCS#11 support In-Reply-To: <200510231219.42207.aj@dungeon.inka.de> References: <435ABF46.1080802@gmail.com> <200510231219.42207.aj@dungeon.inka.de> Message-ID: <435C109D.1000602@gmail.com> Hello Andreas, Thank you for your quick feed-back! Andreas Jellinghaus wrote: > compile error :) > > gcc 4.0.* (current kubunto 5.10). > > compiles fine with gcc 3.4. Sorry... I'd put prototype in-side function... Strange that gcc 4 does not accept it... Please tell me if moving "static void usage (void);" to global scope helps. > Some other notes from my side: > - a version without x.509 would be great. from my point of view x.509 is > something most people don't need and a huge source of complexity > with very little benefit. most people work much better with rsa keys only, > not with (ca signed) certificates, cert chains, lists of trusted cas, crls, > and all the other stuff. for the small scale it is a HUGE overhead with > much more cost than pay off. I don't agree... You can use self-signed certificates for small scale... You get the same complexity of RSA keys. Then the implementation handles only one format of authentication method... The usage of self-signed certificates should be integrated into the ssh-keygen and then it will be as simple as using rsa keys. I hope I won't regret this... But... I think that ssh should use X.509 (self-signed and not) or kerberos identities, TLS as protocol, and PKCS#11 as cryptographic interface... If you drop all proprietary implementations, I think you find a much simpler code and simpler user experience. Anyway... if X.509 patch will not be merged, I will implement RSA only implementation... Although I think it is a mistake. > ironically now that people use x.509 large scale we see it doesn't work > for them either. like the us dod with a CRL > 50 mb or belgium with a > similar big CRL. This issue can be easily resolved using a proper algorithm... If this is the last issue that blocks X.509 merging, I can work with Rumen in order to hash CRL in order to handle large CRLs. Another approach may be to trust each authorized end certificate, and leave out the X.509 hierarchy... You get the same management difficulties of RSA keys... But without the overhead of X.509. For a conclusion, if you are open for it... I think we should discuses the X.509 issue more deeply... > - how can I use the ssh command with my pkcs#11 module? > the binary tells me: no support for smart cards. I think it is very > important to have direct ssh support, too. You run ssh-agent xterm, then in the opened xterm you simply ssh... Oh... You want to run ssh without ssh-agent...?!?! I think you can write a simple script and then use: $ ssh-agent script Again... If it is required, I will add this... But maybe a better design is to remove all private key code from ssh and make ssh fork ssh-agent as a child... Or making ssh-agent a library... Some help regarding X.509... If that what you meant... You should add the CA into /etc/ssh/ca/ca-bundle.crt (PEM). You should add the following to ~/.ssh/authorized_keys x509v3-sign-rsa subject=/C=XX/CN=YY Also try MandatoryCRL no in /etc/sshd_config > > - ssh-add: why new --options? openssh has lots of options that > can be placed in the config file or given via -o Option=Value. > I think it would be very user friendly to be able to put the options > in the config file, and then also pass them as usual with -o. 1. ssh-add does not read config file... 2. I think that ssh-add should be called in script... 3. Most of static options (provider, askpin) should be of ssh-agent... This is part of my note for maintainers... I will read all static options from config file. > - I'm not sure why the agent needs the ask pin program. can you > explain? (I thought you give the pin when you add a key, and if > the card is removed or something like that, the agent simply > drops it, so you have to add it again). I don't think it is comfortable for the user to execute commands if he remove/insert his card, and after expiration... Current implementation prompt for PIN (if needed) when you ssh... I think it is the best. If most user think that ssh-agent should forget keys I will alter current behavior. I think a better implementation would be to allow the ssh-agent notify ssh that a password is required along with a prompt, than ssh will get this password and forward it to the agent... > - the --pkcs11-add-id option: why not use the "normal" > "-s 0" instead of --pkcs11-add-id --pkcs11-slot 0 I wanted to make the interface as generic as I could... Most user will NOT use the slot id... Most (I hope) will prefer to use the --pkcs11-slot-type label --pkcs11-slot "token label" since it will find the right slot based on their token label, so they can insert their token to any slot. In opensc implementation you must specify slot id... So I can make an alias and accept -s argument... > > - are --pkcs11-id-type and --pkcs11-id required? what is the > default? could be wrapped into a complex string like > "-s 0:id:0" or "-s 0:label:Andreas Jellinghaus" or similar. > that would be at least a lot less to type :) I prefer options to be clear... Even if I need to type some more... I will be happy to receive more comments on this... > - what exactly does --pkcs11-protected-authentication ? If you have external key-pad or biometric support, you need to pass NULL to C_Login... > > Sorry, need to go now, will test later. Looking forward! > > Thanks for your patch, great work! Thanks! > > Regards, Andreas > Best Regards, Alon Bar-Lev. From alon.barlev at gmail.com Mon Oct 24 19:00:45 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon, 24 Oct 2005 11:00:45 +0200 Subject: openssh PKCS#11 support In-Reply-To: <200510241005.55015.aj@dungeon.inka.de> References: <435ABF46.1080802@gmail.com> <200510231219.42207.aj@dungeon.inka.de> <435C109D.1000602@gmail.com> <200510241005.55015.aj@dungeon.inka.de> Message-ID: <435CA2BD.60003@gmail.com> Andreas Jellinghaus wrote: > Hi Alon, > >>I don't agree... >>You can use self-signed certificates for small scale... You >>get the same complexity of RSA keys. > > > no, for example x.509 patch will still check validity times and > refuse expired certificates. that is additional complexity. > > think of the horror if your only way to login as root on some > machine is certificate based, it expires, and now you are no > longer allowed to login. sorry, but that is not a scenario I want. > Again... I don't agree... You can set the default validFrom, validTo of self-signed certificates to be from beginning of time to the end of time. So it will behave exactly the same as RSA keys. >>I think that ssh should use X.509 (self-signed and not) or >>kerberos identities, TLS as protocol, and PKCS#11 as >>cryptographic interface... If you drop all proprietary >>implementations, I think you find a much simpler code and >>simpler user experience. > > > please address only one issue at a time. if the issue is pkcs#11, > then it should be addressed on base of the current openssh > code (without x.509) I think. if you bundle several issues you risk > getting all rejected because of one part. I don't agree... If I implement PKCS#11, I should consider how people mostly use PKCS#11... As generic as PKCS#11 is, it is used in X.509 environment where it hold a private key and a certificate. In the none-standard environments (ssh, gpg) people tend to use only raw keys. Part of my mission of adding support for PKCS#11 interface to open source applications is to make them more standard, so that they can be used in environments where it was difficult to be used so far. >>Anyway... if X.509 patch will not be merged, I will >>implement RSA only implementation... > > > from my point of view it would be great to have both. > if pkcs#11 is accepted into openssh, then roumen > will most likely accept patches to improve x.509 patch > to play well with pkcs#11, too. These are not two separate issues. If openssh will not support X.509, I will still require X.509 certificate on the PKCS#11 token. I will not support a tokens that are outside of X.509 world. > >>You run ssh-agent xterm, > doesn't help me on a console. You can use ssh-agent ssh.... :) >>You want to run ssh without ssh-agent...?!?! I > > yes. for example If I'm working at the console of > one server (plain virtual console, no agent, no X) > and then need to log in on other machines to get updates > pulled. I would want to plugin/out my token all the > time, but rather > ssh -I 0 otherserver > to login remote. > > that currently works. if you want to replace opensc support, > the feature set should not shrink. > > true, you can hack work arounds, but that would be still unfriendly > to the users, when right now they can use "ssh -I 0 ...". OK... If all be accepted with the agent, I will patch ssh also. Although I think current design can be improved if ssh-agent will be implemented as a library and be used by ssh if it cannot find running ssh-agent. There is no point in duplicating code... >>Some help regarding X.509... If that what you meant... >>You should add the CA into /etc/ssh/ca/ca-bundle.crt (PEM). >>You should add the following to ~/.ssh/authorized_keys >>x509v3-sign-rsa subject=/C=XX/CN=YY > > > well, that exactly demonstrates that a CA can create man in the > middle attacks by issuing key/certs to several people with the same > subject. nobody will notice. > > I like ssh because it is plain, simple, secure. You can still use public key hash... I simply don't like it... So it only demonstrate that ssh can be plain, simple, secure... :) > but back to the issue: please take a look at pam_pkcs11. > sure, it is for login, but they have lots of mappers to implement > such shemas or other ideas. maybe it would be helpful to > implement the same concepts and make the config look the > same? would be a nice service for users. True... pam_pkcs11 did a wonderful work on parsing extensions... You can provide it as a library then it can be used by many applications. >>1. ssh-add does not read config file... > > ouch. but does it have to, if it communicates with ssh-agent? > (or does the agent neither read the config file?) ssh, ssh-add find their agent by looking on environment variables. >>2. I think that ssh-add should be called in script... > > no issue here. -o SomeOption=somevalue > should work, I guess? Not on current up-stream implementation. >>I don't think it is comfortable for the user to execute >>commands if he remove/insert his card, and after expiration... >>Current implementation prompt for PIN (if needed) when you >>ssh... I think it is the best. > > > sorry, I disagree. the point of the ssh agent if for many people > so they can create scripts and have non interactive tasks. > if you suddenly halt somewhere in the middle and prompt > for pins, you might confuse users and break those scripts. > people expect it to work. or to fail. but if something hangs > because input is asked somewhere, that is very, very confusing > and hard to debug. 1. If you don't askpin program, ssh-agent will fail and won't prompt anything. 2. You can config your own askpass program that takes the PIN from other place (Like environment or file) >>If most user think that ssh-agent should forget keys I will >>alter current behavior. > > if cards are removed? I think so. the current does not, > which is also ok, because (at least with usb crypto tokens) > you can hook to the hotplug event and run ssh-add -D > and xlock. Well... I will be glad to receive other comments regarding this... I really don't think so... > btw: I wonder what everyone thinks about this: > do you think it would be ok security wise, to have a screen > lock that not only requires card and pin to unlock, but > also adds the pin to agents like the ssh agent? I think that unlock should be enough... >>I prefer options to be clear... Even if I need to type some >>more... I will be happy to receive more comments on this... > > > you could have long+short options like most apps? > or - my preference - config file options. All can be provided... But first major issues should be agreed upon... (PIN handling, X.509) Best Regards, Alon Bar-Lev. From bob at proulx.com Tue Oct 25 15:15:15 2005 From: bob at proulx.com (Bob Proulx) Date: Mon, 24 Oct 2005 23:15:15 -0600 Subject: SSH, glibc, and Red Hat In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE105966@US-Columbia-CIST.mail.saic.com> References: <4E25ECBBC03F874CBAD03399254ADFDE105966@US-Columbia-CIST.mail.saic.com> Message-ID: <20051025051515.GA31903@dementia.proulx.com> Loomis, Rip wrote: > Jason.C.Burns at wellsfargo.com wrote: > > I have a quick question. I'm building an rpm (ssh 4.2p1) for some RH-AS > > machines and it's been working just fine. However, I needed to install > > it on an older box (AS 2.1), and received the following error: > [[deleted]] > > My only question is that is openssh dependant on libc >= 2.3, > > or is this due to the version of libc on my build machine? > > This is due to the version of libc on your build machine. > If you need to support an older box you're going to either > need to build on that box (or one with a compatible set of > libraries) or else find a way to specify linkage with the > older set of libraries. > > The usual solution is the former--I still have functional > Solaris 2.5.1 boxes here just in case, to use as build hosts. An alternative solution if building on an older machine just won't work for some reason is to keep a chroot on the newer machine. I do this and it is quite useful to build for the older platform. Create a complete copy of the older system in a sub-directory and then use chroot(1) to that location and build. Bob From dtucker at zip.com.au Tue Oct 25 15:35:47 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 25 Oct 2005 15:35:47 +1000 Subject: SSH, glibc, and Red Hat In-Reply-To: <20051025051515.GA31903@dementia.proulx.com> References: <4E25ECBBC03F874CBAD03399254ADFDE105966@US-Columbia-CIST.mail.saic.com> <20051025051515.GA31903@dementia.proulx.com> Message-ID: <20051025053547.GA25304@gate.dodgy.net.au> On Mon, Oct 24, 2005 at 11:15:15PM -0600, Bob Proulx wrote: > An alternative solution if building on an older machine just won't > work for some reason is to keep a chroot on the newer machine. I do > this and it is quite useful to build for the older platform. Create a > complete copy of the older system in a sub-directory and then use > chroot(1) to that location and build. The only thing to watch for there is for kernel-related things since you're obviously running on the same kernel in the chroot. This was the case with the descriptor passing bugs in Linux 2.0 kernels: the Debian folk used chroots as you described. configure found that descriptor passing worked fine (which it did, on the host's kernel) even though it didn't on the target. They eventually added some code to detect the buggy kernel versions at runtime. -- 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. From vinschen at redhat.com Tue Oct 25 18:46:19 2005 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 25 Oct 2005 10:46:19 +0200 Subject: [PATCH] Fix duplicated text in contrib/cygwin/ssh-user-config Message-ID: <20051025084619.GT27476@calimero.vinschen.de> Hi, The contrib/cygwin/ssh-user-config script accidentally prints Shall I create an SSH2 RSA identity file for you? (yes/no) (yes/no) _ where one "(yes/no)" would have been sufficient. The below patch fixes that. Please apply. Thanks, Corinna Index: contrib/cygwin/ssh-user-config =================================================================== RCS file: /cvs/openssh_cvs/contrib/cygwin/ssh-user-config,v retrieving revision 1.3 diff -p -u -r1.3 ssh-user-config --- contrib/cygwin/ssh-user-config 13 Nov 2003 00:28:49 -0000 1.3 +++ contrib/cygwin/ssh-user-config 25 Oct 2005 07:45:38 -0000 @@ -198,7 +198,7 @@ fi if [ ! -f "${pwdhome}/.ssh/id_rsa" ] then - if request "Shall I create an SSH2 RSA identity file for you? (yes/no) " + if request "Shall I create an SSH2 RSA identity file for you?" then echo "Generating ${pwdhome}/.ssh/id_rsa" if [ "${with_passphrase}" = "yes" ] @@ -217,7 +217,7 @@ fi if [ ! -f "${pwdhome}/.ssh/id_dsa" ] then - if request "Shall I create an SSH2 DSA identity file for you? (yes/no) " + if request "Shall I create an SSH2 DSA identity file for you?" then echo "Generating ${pwdhome}/.ssh/id_dsa" if [ "${with_passphrase}" = "yes" ] -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc. From karolinac at software.com.pl Tue Oct 25 20:35:10 2005 From: karolinac at software.com.pl (Karolina Choroszynska) Date: Tue, 25 Oct 2005 12:35:10 +0200 Subject: proposition of writing the article to Linux+ DVD magazine Message-ID: <1130236511.13148.2.camel@jeden.software.com.pl> Good morning, I'm working at Software publishing house which publishes magazines from the IT field. One of them is Linux+ DVD magazine (please visit our web www.lpmagazine.org). I'm looking for the linux developpers who are interrested in cooperation with the redaction of Linux+ DVD by writing the article concerning the scurity in Linux (for exemple OpenBSD 3.8, or to transmit the documents in ssh with Openssh). Would you be interested in such way of cooperation. Please feel free to contact me by responding to this email Regards Karolina Choroszynska Software-Wydawnictwo From bob at proulx.com Wed Oct 26 06:10:30 2005 From: bob at proulx.com (Bob Proulx) Date: Tue, 25 Oct 2005 14:10:30 -0600 Subject: SSH, glibc, and Red Hat In-Reply-To: <20051025053547.GA25304@gate.dodgy.net.au> References: <4E25ECBBC03F874CBAD03399254ADFDE105966@US-Columbia-CIST.mail.saic.com> <20051025051515.GA31903@dementia.proulx.com> <20051025053547.GA25304@gate.dodgy.net.au> Message-ID: <20051025201030.GA11452@dementia.proulx.com> Darren Tucker wrote: > The only thing to watch for there is for kernel-related things since > you're obviously running on the same kernel in the chroot. Certainly. And a good thing to note. > This was the case with the descriptor passing bugs in Linux 2.0 kernels: > the Debian folk used chroots as you described. configure found that > descriptor passing worked fine (which it did, on the host's kernel) > even though it didn't on the target. They eventually added some code > to detect the buggy kernel versions at runtime. Yes that can be a problem. But that is almost the same problem as when you compile something for the local machine and then boot to a different kernel on the same machine. Things that depend upon the kernel might work differently. So what you say the Debian folks did, which was to detect the situation at runtime, sounds like a best case solution for things that depend upon the kernel. I say almost the same problem because obviously most people don't lose features when installing new kernels. But it does happen at times. I often boot into older kernels in order to test something or to try to recreate some particular configuration. Fortunately there are few things that are sensitive to the kernel version. Bob From Jason.C.Burns at wellsfargo.com Wed Oct 26 10:40:45 2005 From: Jason.C.Burns at wellsfargo.com (Jason.C.Burns at wellsfargo.com) Date: Tue, 25 Oct 2005 19:40:45 -0500 Subject: SSH, glibc, and Red Hat Message-ID: >> The only thing to watch for there is for kernel-related things since >> you're obviously running on the same kernel in the chroot. >Certainly. And a good thing to note. >> This was the case with the descriptor passing bugs in Linux 2.0 kernels: >> the Debian folk used chroots as you described. configure found that >> descriptor passing worked fine (which it did, on the host's kernel) >> even though it didn't on the target. They eventually added some code >> to detect the buggy kernel versions at runtime. >Yes that can be a problem. But that is almost the same problem as when you compile something for the local machine and then boot to a different >kernel on the same machine. Things that depend upon the kernel might work differently. So what you say the Debian folks did, which was to detect >the situation at runtime, sounds like a best case solution for things that depend upon the kernel. >I say almost the same problem because obviously most people don't lose features when installing new kernels. But it does happen at times. >I often boot into older kernels in order to test something or to try to recreate some particular configuration. Fortunately there are few >things that are sensitive to the kernel version. All very good ideas, but in the essence of compatibility, I think I'll just create a VM of the OS/kernel that's having the problems and just add it to the build script. Thanks for all the info, you guys have been immensely helpful. Jason From H.Koenig at science-computing.de Thu Oct 27 03:06:55 2005 From: H.Koenig at science-computing.de (Harald Koenig) Date: Wed, 26 Oct 2005 19:06:55 +0200 Subject: openssh 4.2p1 zlib compression broken for old clients Message-ID: <20051026170655.GA8721@tyl.science-computing.de> Hello OpenSSH developers, openssh 4.2p1 breaks old openssh clients up to 3.4p1 when they try to use compression: # ssh-3.4p1 -C remote-host-with-4.2p1 pwd no matching comp found: client zlib server none,zlib at openssh.com option "-vv" shows ... debug2: kex_parse_kexinit: zlib ... debug2: kex_parse_kexinit: none,zlib at openssh.com ... debug2: mac_init: found hmac-md5 no matching comp found: client zlib server none,zlib at openssh.com using the small patch below makes the old ssh clients happy again with option "-C" ------------------------------------------------------------------------------- --- openssh-4.2p1/sshd.c~ 2005-10-05 17:58:21.000000000 +0200 +++ openssh-4.2p1/sshd.c 2005-10-26 18:17:44.000000000 +0200 @@ -2014,7 +2014,7 @@ myproposal[PROPOSAL_COMP_ALGS_STOC] = "none"; } else if (options.compression == COMP_DELAYED) { myproposal[PROPOSAL_COMP_ALGS_CTOS] = - myproposal[PROPOSAL_COMP_ALGS_STOC] = "none,zlib at openssh.com"; + myproposal[PROPOSAL_COMP_ALGS_STOC] = "none,zlib at openssh.com,zlib"; } myproposal[PROPOSAL_SERVER_HOST_KEY_ALGS] = list_hostkey_types(); ------------------------------------------------------------------------------- Harald Koenig PS: yes I know about the security issues using such old ssh clients, but it's only used in fairly protected small internal customer networks, and the customer insists not to change anything in those environments running the old ssh clients... (the surrounding environment is pretty well maintained which is the reason for the 4.2p1 sshd;-) -- "I hope to die ___ _____ before I *have* to use Microsoft Word.", 0--,| /OOOOOOO\ Donald E. Knuth, 02-Oct-2001 in Tuebingen. <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// Harald Koenig \/\/\/\/\/\/\/\/\/ science+computing ag // / \\ \ koenig at science-computing.de ^^^^^ ^^^^^ From H.Koenig at science-computing.de Thu Oct 27 03:13:13 2005 From: H.Koenig at science-computing.de (Harald Koenig) Date: Wed, 26 Oct 2005 19:13:13 +0200 Subject: openssh 4.2p1 zlib compression broken for old clients In-Reply-To: <20051026170655.GA8721@tyl.science-computing.de> References: <20051026170655.GA8721@tyl.science-computing.de> Message-ID: <20051026171313.GA12864@atuin.science-computing.de> On Oct 26, Harald Koenig wrote: > openssh 4.2p1 breaks old openssh clients up to 3.4p1 when they try to use compression: > > # ssh-3.4p1 -C remote-host-with-4.2p1 pwd > no matching comp found: client zlib server none,zlib at openssh.com one more note on that topic: for more recent ssh clients, the connection does not fail anymore, but compression falls back to "none" which result in an unexpexted performace loss... Harald Koenig -- "I hope to die ___ _____ before I *have* to use Microsoft Word.", 0--,| /OOOOOOO\ Donald E. Knuth, 02-Oct-2001 in Tuebingen. <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// Harald Koenig \/\/\/\/\/\/\/\/\/ science+computing ag // / \\ \ koenig at science-computing.de ^^^^^ ^^^^^ From imorgan at nas.nasa.gov Thu Oct 27 04:31:35 2005 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 26 Oct 2005 11:31:35 -0700 (PDT) Subject: openssh 4.2p1 zlib compression broken for old clients In-Reply-To: <20051026170655.GA8721@tyl.science-computing.de> from "Harald Koenig" at Oct 26, 2005 07:06:55 PM Message-ID: <200510261831.j9QIVZXG007708@sun601.nas.nasa.gov> On Wed Oct 26 10:06:55 2005, Harald Koenig wrote: > > Hello OpenSSH developers, > > openssh 4.2p1 breaks old openssh clients up to 3.4p1 when they try to use compression: > This is spelt out pretty clearly in the ChangeLog for 4.2p1 and (if I recall correctly) in the release announcement on this list. Admittedly, the sshd_config(5) man page does not appear to call out this issue. Set Compression=yes in your sshd_config and the old clients should behave. > # ssh-3.4p1 -C remote-host-with-4.2p1 pwd > no matching comp found: client zlib server none,zlib at openssh.com > > option "-vv" shows > > ... > debug2: kex_parse_kexinit: zlib > ... > debug2: kex_parse_kexinit: none,zlib at openssh.com > ... > debug2: mac_init: found hmac-md5 > no matching comp found: client zlib server none,zlib at openssh.com > > using the small patch below makes the old ssh clients happy again with option "-C" > > > ------------------------------------------------------------------------------- > --- openssh-4.2p1/sshd.c~ 2005-10-05 17:58:21.000000000 +0200 > +++ openssh-4.2p1/sshd.c 2005-10-26 18:17:44.000000000 +0200 > @@ -2014,7 +2014,7 @@ > myproposal[PROPOSAL_COMP_ALGS_STOC] = "none"; > } else if (options.compression == COMP_DELAYED) { > myproposal[PROPOSAL_COMP_ALGS_CTOS] = > - myproposal[PROPOSAL_COMP_ALGS_STOC] = "none,zlib at openssh.com"; > + myproposal[PROPOSAL_COMP_ALGS_STOC] = "none,zlib at openssh.com,zlib"; > } > > myproposal[PROPOSAL_SERVER_HOST_KEY_ALGS] = list_hostkey_types(); > ------------------------------------------------------------------------------- > > > Harald Koenig > > PS: yes I know about the security issues using such old ssh clients, but it's > only used in fairly protected small internal customer networks, and the customer > insists not to change anything in those environments running the old ssh clients... > (the surrounding environment is pretty well maintained which is the reason for > the 4.2p1 sshd;-) > -- > "I hope to die ___ _____ > before I *have* to use Microsoft Word.", 0--,| /OOOOOOO\ > Donald E. Knuth, 02-Oct-2001 in Tuebingen. <_/ / /OOOOOOOOOOO\ > \ \/OOOOOOOOOOOOOOO\ > \ OOOOOOOOOOOOOOOOO|// > Harald Koenig \/\/\/\/\/\/\/\/\/ > science+computing ag // / \\ \ > koenig at science-computing.de ^^^^^ ^^^^^ > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Iain Morgan From H.Koenig at science-computing.de Thu Oct 27 18:55:22 2005 From: H.Koenig at science-computing.de (Harald Koenig) Date: Thu, 27 Oct 2005 10:55:22 +0200 Subject: openssh 4.2p1 zlib compression broken for old clients In-Reply-To: <200510261831.j9QIVZXG007708@sun601.nas.nasa.gov> References: <20051026170655.GA8721@tyl.science-computing.de> <200510261831.j9QIVZXG007708@sun601.nas.nasa.gov> Message-ID: <20051027085522.GA26251@atuin.science-computing.de> On Oct 26, Iain Morgan wrote: > This is spelt out pretty clearly in the ChangeLog for 4.2p1 and (if I recall > correctly) in the release announcement on this list. Admittedly, the > sshd_config(5) man page does not appear to call out this issue. thanks for your pointer to the docs (and sorry for not having read/understood them all). maybe you can answer two more open questions on that topic, please ? > Set Compression=yes in your sshd_config and the old clients should behave. a) what's the reason/benefit for the new delayed compression, or otherway round: what's the (maybe furture) drawback if I'll use "Compression yes" in sshd_conf for backward compatibility ? is this to avoid small packets for authentication getting larger by zlib compression ? b) what's the reason of the different code in sshconnect2.c/ssh_kex2() and sshd.c/do_ssh2_kex() for this setup ? sshconnect2.c/ssh_kex2() already uses if (options.compression) { myproposal[PROPOSAL_COMP_ALGS_CTOS] = myproposal[PROPOSAL_COMP_ALGS_STOC] = "zlib at openssh.com,zlib,none"; } else { myproposal[PROPOSAL_COMP_ALGS_CTOS] = myproposal[PROPOSAL_COMP_ALGS_STOC] = "none,zlib at openssh.com,zlib"; } and thus offers a fallback to old "zlib" scheme, while sshd.c/do_ssh2_kex() reads if (options.compression == COMP_NONE) { myproposal[PROPOSAL_COMP_ALGS_CTOS] = myproposal[PROPOSAL_COMP_ALGS_STOC] = "none"; } else if (options.compression == COMP_DELAYED) { myproposal[PROPOSAL_COMP_ALGS_CTOS] = myproposal[PROPOSAL_COMP_ALGS_STOC] = "none,zlib at openssh.com"; } not offering a fallback for old clients. why not allowing a fallback for compatibility to old "zlib" in case that an old client does not yet support the new "delayed" scheme ? if that's not a good idea, what about a new setting "delayed+compat-fallback" for "Compression" which would allow new ssh clients to benefit/use "delayed" compression and wouldn't break it for old clients ? the patch below might be a possibility to offer both ways at the same time ?! btw: the comment for "compression" in servconf.h is no longer exact, because with the COMP_DELAYED setting it's no longer a boolean value, so "true" might be misleading (COMP_DELAYED==2 is true, but only _delayed_ compression is allowed): int compression; /* If true, compression is allowed */ ^^^^ suggestion for giving delayed compression with legacy fallback: ------------------------------------------------------------------------------- diff -ur ../../orig/openssh-4.2p1/kex.h ./kex.h --- ../../orig/openssh-4.2p1/kex.h 2005-07-26 13:54:56.000000000 +0200 +++ ./kex.h 2005-10-27 10:43:07.000000000 +0200 @@ -38,6 +38,7 @@ #define COMP_NONE 0 #define COMP_ZLIB 1 #define COMP_DELAYED 2 +#define COMP_DELAYED_COMP 3 enum kex_init_proposals { PROPOSAL_KEX_ALGS, Only in .: kex.h~ diff -ur ../../orig/openssh-4.2p1/servconf.c ./servconf.c --- ../../orig/openssh-4.2p1/servconf.c 2005-08-12 14:11:37.000000000 +0200 +++ ./servconf.c 2005-10-27 10:46:55.000000000 +0200 @@ -738,6 +738,8 @@ value = 0; /* silence compiler */ if (strcmp(arg, "delayed") == 0) value = COMP_DELAYED; + if (strcmp(arg, "delayed+fallback") == 0) + value = COMP_DELAYED_COMP; else if (strcmp(arg, "yes") == 0) value = COMP_ZLIB; else if (strcmp(arg, "no") == 0) Only in .: servconf.c~ diff -ur ../../orig/openssh-4.2p1/sshd.c ./sshd.c --- ../../orig/openssh-4.2p1/sshd.c 2005-07-26 13:54:56.000000000 +0200 +++ ./sshd.c 2005-10-27 10:47:22.000000000 +0200 @@ -1998,6 +1998,9 @@ if (options.compression == COMP_NONE) { myproposal[PROPOSAL_COMP_ALGS_CTOS] = myproposal[PROPOSAL_COMP_ALGS_STOC] = "none"; + } else if (options.compression == COMP_DELAYED_COMP) { + myproposal[PROPOSAL_COMP_ALGS_CTOS] = + myproposal[PROPOSAL_COMP_ALGS_STOC] = "none,zlib at openssh.com,zlib"; } else if (options.compression == COMP_DELAYED) { myproposal[PROPOSAL_COMP_ALGS_CTOS] = myproposal[PROPOSAL_COMP_ALGS_STOC] = "none,zlib at openssh.com"; Only in .: sshd.c~ ------------------------------------------------------------------------------- thanks for your comments, Harald Koenig -- "I hope to die ___ _____ before I *have* to use Microsoft Word.", 0--,| /OOOOOOO\ Donald E. Knuth, 02-Oct-2001 in Tuebingen. <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// Harald Koenig \/\/\/\/\/\/\/\/\/ science+computing ag // / \\ \ koenig at science-computing.de ^^^^^ ^^^^^ From markus at openbsd.org Thu Oct 27 20:26:20 2005 From: markus at openbsd.org (Markus Friedl) Date: Thu, 27 Oct 2005 12:26:20 +0200 Subject: openssh 4.2p1 zlib compression broken for old clients In-Reply-To: <20051027085522.GA26251@atuin.science-computing.de> References: <20051026170655.GA8721@tyl.science-computing.de> <200510261831.j9QIVZXG007708@sun601.nas.nasa.gov> <20051027085522.GA26251@atuin.science-computing.de> Message-ID: <20051027102620.GA2343@folly> allowing zlib compresison is a server side risk. delaying compression until the user is authenticated reduces the server side risk. i don't see why the code should change. if it's a problem, then only in the documentation: Compression Specifies whether compression is allowed, or delayed until the user has authenticated successfully. The argument must be ``yes'', ``delayed'', or ``no''. The default is ``delayed''.