From dtucker at zip.com.au Thu Mar 1 13:17:45 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 01 Mar 2007 13:17:45 +1100 Subject: What would cause keyboard-interactive packet connection close In-Reply-To: <200702271438.l1REcgbK043047@himinbjorg.tucs-beachin-obx-house.com> References: <200702271438.l1REcgbK043047@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <45E637C9.3090503@zip.com.au> Tuc at T-B-O-H.NET wrote: [...] > FreeBSD 5.X (I don't remember off hand) and it identifies > as : > > OpenSSH_3.5p1 FreeBSD-20030924, SSH protocols 1.5/2.0, OpenSSL 0x0090704f The client-side debug that you posted looks like sshd is either crashing or killing the connection during keyboard-interactive authentication. The problem may lie in sshd or in one of the PAM modules that it's configured to use. You can try forcing password auth ("ssh -o PreferredAuthentications=password yourserver") which may work around the problem, but it's dependent on your server's configuration. If you can get on to the server you could check the syslog or, better yet, run sshd in debug mode to give you a much better idea of what's going on. Anyway I'm pretty sure FreeBSD had their own keyboard-interactive code in versions of that vintage to support PAM so it's unlikely that we will be able to help you. You probably need to seek help from the FreeBSD folks. -- 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 ml at t-b-o-h.net Thu Mar 1 13:28:38 2007 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Wed, 28 Feb 2007 21:28:38 -0500 (EST) Subject: What would cause keyboard-interactive packet connection close In-Reply-To: <45E637C9.3090503@zip.com.au> Message-ID: <200703010228.l212ScPx077338@himinbjorg.tucs-beachin-obx-house.com> > > Tuc at T-B-O-H.NET wrote: > [...] > > FreeBSD 5.X (I don't remember off hand) and it identifies > > as : > > > > OpenSSH_3.5p1 FreeBSD-20030924, SSH protocols 1.5/2.0, OpenSSL 0x0090704f > > The client-side debug that you posted looks like sshd is either crashing > or killing the connection during keyboard-interactive authentication. > The problem may lie in sshd or in one of the PAM modules that it's > configured to use. > It should be : auth required pam_nologin.so no_warn auth sufficient pam_opie.so no_warn no_fake_prompts auth requisite pam_opieaccess.so no_warn allow_local auth required pam_unix.so no_warn try_first_pass account required pam_login_access.so account required pam_unix.so session required pam_permit.so password required pam_unix.so no_warn try_first_pass That seems to be the default on the client side, and I know I didn't change it on the server side. > > You can try forcing password auth ("ssh -o > PreferredAuthentications=password yourserver") which may work around the > problem, but it's dependent on your server's configuration. > :( It claims : debug1: authentications that can continue: publickey,keyboard-interactive debug3: start over, passed a different list publickey,keyboard-interactive debug3: preferred password debug1: no more auth methods to try Permission denied (publickey,keyboard-interactive). > > If you can get on to the server you could check the syslog or, better > yet, run sshd in debug mode to give you a much better idea of what's > going on. > If I could, yea. Unfortunately just not able to due to other circumstances. > Anyway I'm pretty sure FreeBSD had their own keyboard-interactive code > in versions of that vintage to support PAM so it's unlikely that we will > be able to help you. You probably need to seek help from the FreeBSD folks. > Ok, thanks. Tuc From dtucker at zip.com.au Thu Mar 1 23:54:14 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 01 Mar 2007 23:54:14 +1100 Subject: Call for release testing. Message-ID: <45E6CCF6.2010501@zip.com.au> Hi All. We are planning on doing one of our regular OpenSSH releases (4.6/4.6p1) some time next week. This is a mostly a bugfix release, but there is one new feature: sshd now allows the enabling and disabling of authentication methods on a per user, group, host and network basis via the Match directive in sshd_config. The bugs fixed are: #52 ssh hangs on exit. #1252 sftp returns 0 when upload is unsuccessful due to a full device. #1259 small typos in ssh-rand-helper(8). #1265 SCP progress doesn't map to standard out or standard error. #1275 Config parsing (parse_time) in Host: context acts globally. #1281 getrrsetbyname() does not check the presence of SIG records. #1283 findssl assumes existence of 'which'. #1267 PermitOpen - Multiple forwards don't works plus many more small fixes and man page tweaks. Thanks to all who contributed. More detail may be found in the ChangeLog in the portable OpenSSH tarballs. The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable snapshots are available at: ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/ or one of its mirrors listed at http://www.openssh.com/portable.html#ftp Running the regression tests supplied with Portable does not require installation and is a simply: $ ./configure && make tests Testing on suitable non-production systems is also appreciated. Please send reports of success or failure to openssh-unix-dev at mindrot.org. 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 stuge-openssh-unix-dev at cdy.org Fri Mar 2 00:36:22 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 1 Mar 2007 14:36:22 +0100 Subject: Call for release testing. In-Reply-To: <45E6CCF6.2010501@zip.com.au> References: <45E6CCF6.2010501@zip.com.au> Message-ID: <20070301133622.14524.qmail@cdy.org> On Thu, Mar 01, 2007 at 11:54:14PM +1100, Darren Tucker wrote: > Testing on suitable non-production systems is also appreciated. > Please send reports of success or failure to > openssh-unix-dev at mindrot.org. CVS is all good with Linux 2.6.19.1 and glibc 2.4. //Peter From svallet at genoscope.cns.fr Fri Mar 2 02:49:48 2007 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Thu, 1 Mar 2007 16:49:48 +0100 Subject: Call for release testing. In-Reply-To: <45E6CCF6.2010501@zip.com.au> References: <45E6CCF6.2010501@zip.com.au> Message-ID: <20070301164948.2cb7519d@tx174.tx.local> On Thu, 01 Mar 2007 23:54:14 +1100 Darren Tucker wrote: > Please send reports of success or failure to > openssh-unix-dev at mindrot.org. 20070302 builds fine and passes all tests on Tru64 5.1A Simon From christian.pfaffel-janser at SIEMENS.com Fri Mar 2 00:19:32 2007 From: christian.pfaffel-janser at SIEMENS.com (Christian Pfaffel-Janser) Date: Thu, 01 Mar 2007 14:19:32 +0100 Subject: Proposed patch: ssh-keygen allows writing to stdout for moduli generation Message-ID: <1172755172.5509.12.camel@atpc020c> Hello all, I propose the following patch to ssh-keygen.c for openssh version 4.5. It allows to redirect output of the moduli operations to stdout, to do something like e.g.: $ ssh-keygen -G - -b 2048 | ssh-keygen -T - -f - >moduli Best regards, Christian --- ssh/ssh-keygen.c.old 2007-03-01 12:43:06.000000000 +0100 +++ ssh/ssh-keygen.c 2007-03-01 12:47:32.000000000 +0100 @@ -1270,13 +1270,16 @@ main(int ac, char **av) } if (do_gen_candidates) { - FILE *out = fopen(out_file, "w"); - - if (out == NULL) { - error("Couldn't open modulus candidate file \"%s\": %s", - out_file, strerror(errno)); - return (1); - } + FILE *out; + + if (strcmp(out_file, "-") != 0) { + if ((out = fopen(out_file, "w")) == NULL) { + fatal("Couldn't open modulus candidate file \"%s\": %s", + out_file, strerror(errno)); + } + } else + out = stdout; + if (bits == 0) bits = DEFAULT_BITS; if (gen_candidates(out, memory, bits, start) != 0) @@ -1287,8 +1290,16 @@ main(int ac, char **av) if (do_screen_candidates) { FILE *in; - FILE *out = fopen(out_file, "w"); + FILE *out; + if (strcmp(out_file, "-") != 0) { + if ((out = fopen(out_file, "w")) == NULL) { + fatal("Couldn't open moduli file \"%s\": %s", + out_file, strerror(errno)); + } + } else + out = stdout; + if (have_identity && strcmp(identity_file, "-") != 0) { if ((in = fopen(identity_file, "r")) == NULL) { fatal("Couldn't open modulus candidate " @@ -1298,10 +1309,6 @@ main(int ac, char **av) } else in = stdin; - if (out == NULL) { - fatal("Couldn't open moduli file \"%s\": %s", - out_file, strerror(errno)); - } if (prime_test(in, out, trials, generator_wanted) != 0) fatal("modulus screening failed"); return (0); From sxw at inf.ed.ac.uk Fri Mar 2 05:54:55 2007 From: sxw at inf.ed.ac.uk (Simon Wilkinson) Date: Thu, 1 Mar 2007 18:54:55 +0000 Subject: Call for release testing. In-Reply-To: <45E6CCF6.2010501@zip.com.au> References: <45E6CCF6.2010501@zip.com.au> Message-ID: On 1 Mar 2007, at 12:54, Darren Tucker wrote: > We are planning on doing one of our regular OpenSSH releases > (4.6/4.6p1) > some time next week. This is a mostly a bugfix release, but there is > one new feature: I take it there's no chance of any of the GSSAPI/Kerberos bugs on bugzilla.mindrot.org being fixed for this release? Simon. From vinschen at redhat.com Fri Mar 2 05:49:53 2007 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 1 Mar 2007 19:49:53 +0100 Subject: Call for release testing. In-Reply-To: <45E6CCF6.2010501@zip.com.au> References: <45E6CCF6.2010501@zip.com.au> Message-ID: <20070301184953.GA5033@calimero.vinschen.de> On Mar 1 23:54, Darren Tucker wrote: > Hi All. > > We are planning on doing one of our regular OpenSSH releases (4.6/4.6p1) > some time next week. This is a mostly a bugfix release, but there is > one new feature: > [...] > Testing on suitable non-production systems is also appreciated. > Please send reports of success or failure to > openssh-unix-dev at mindrot.org. Current CVS builds and runs fine on Cygwin. However, the testsuite didn't work out of the box. After some time I figured out that this is related to the lineendings in the pidfile (CRLF instead of just LF). It occured to me that OpenSSH on Cygwin is still built so that it uses textmode instead of binary mode when writing files. However, the right way to do this is to read files in textmode (which allows CRLF as well as LF lineendings) and to write in binary mode, except the path to the output file is mounted in textmode(*). So, I hope it's still not too late to get the below patch in, before 4.6p1 is released. With this patch, the testsuite runs fine OOTB as well. Thanks in advance, Corinna Index: configure.ac =================================================================== RCS file: /cvs/openssh/configure.ac,v retrieving revision 1.370 diff -p -u -r1.370 configure.ac --- configure.ac 6 Oct 2006 23:07:21 -0000 1.370 +++ configure.ac 1 Mar 2007 18:38:52 -0000 @@ -360,7 +360,7 @@ int main(void) { exit(0); } ;; *-*-cygwin*) check_for_libcrypt_later=1 - LIBS="$LIBS /usr/lib/textmode.o" + LIBS="$LIBS /usr/lib/textreadmode.o" AC_DEFINE(HAVE_CYGWIN, 1, [Define if you are on Cygwin]) AC_DEFINE(USE_PIPES, 1, [Use PIPES instead of a socketpair()]) AC_DEFINE(DISABLE_SHADOW, 1, (*) I really hate having to consider this Windowism. -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From dtucker at zip.com.au Fri Mar 2 10:09:09 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 02 Mar 2007 10:09:09 +1100 Subject: Proposed patch: ssh-keygen allows writing to stdout for moduli generation In-Reply-To: <1172755172.5509.12.camel@atpc020c> References: <1172755172.5509.12.camel@atpc020c> Message-ID: <45E75D15.3000406@zip.com.au> Christian Pfaffel-Janser wrote: > I propose the following patch to ssh-keygen.c for openssh version 4.5. > It allows to redirect output of the moduli operations to stdout, to do > something like e.g.: > > $ ssh-keygen -G - -b 2048 | ssh-keygen -T - -f - >moduli If your platform has it you can use /dev/stdout for this: ssh-keygen -b 2048 -G /dev/stdout | ssh-keygen -T - -f - >moduli -- 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 Bill.Colvin at opticatech.com Fri Mar 2 07:49:26 2007 From: Bill.Colvin at opticatech.com (Bill Colvin) Date: Thu, 1 Mar 2007 13:49:26 -0700 Subject: Call for release testing. Message-ID: <116F1768869C4944A925A2A65CEE2E29566DA4@otisbs01.oti.local> On Thu, 01 Mar 2007 23:54:14 +1100 Darren Tucker wrote: > Please send reports of success or failure to > openssh-unix-dev at mindrot.org. Tried testing with Snapshot 20070302 There seems to be an implicit assumption that if locate exists as an executable on the system, then there will be a database that can be used by locate to find various files. This may not always be the case. In these situations configure will fail. If execute permissions are removed from locate or updatedb is executed, then configure will succeed. Other than that I saw no problems with building, installing or using the Snapshot. Bill From Bill.Colvin at opticatech.com Fri Mar 2 06:25:08 2007 From: Bill.Colvin at opticatech.com (Bill Colvin) Date: Thu, 1 Mar 2007 12:25:08 -0700 Subject: OpenSSH use of OpenSSL in FIPS Mode Message-ID: <116F1768869C4944A925A2A65CEE2E29566D8D@otisbs01.oti.local> Now that OpenSSL has received FIPS 140-2 certification, does anyone know if the work started a couple of years ago to allow OpenSSH to use OpenSSL in FIPS mode will be reactivated? Bill From djm at mindrot.org Fri Mar 2 13:28:15 2007 From: djm at mindrot.org (Damien Miller) Date: Fri, 2 Mar 2007 13:28:15 +1100 (EST) Subject: Call for release testing. In-Reply-To: <116F1768869C4944A925A2A65CEE2E29566DA4@otisbs01.oti.local> References: <116F1768869C4944A925A2A65CEE2E29566DA4@otisbs01.oti.local> Message-ID: On Thu, 1 Mar 2007, Bill Colvin wrote: > On Thu, 01 Mar 2007 23:54:14 +1100 > Darren Tucker wrote: > > > Please send reports of success or failure to > > openssh-unix-dev at mindrot.org. > > Tried testing with Snapshot 20070302 > > There seems to be an implicit assumption that if locate exists as an > executable on the system, then there will be a database that can be used > by locate to find various files. > > This may not always be the case. In these situations configure will > fail. If execute permissions are removed from locate or updatedb is > executed, then configure will succeed. ??? I don't think we use locate. [djm at fuyu openssh]$ AUTOCONF_VERSION=2.61 autoreconf [djm at fuyu openssh]$ grep -i '[^l]locate' configure.ac Makefile.in configure [djm at fuyu openssh]$ -d From dtucker at zip.com.au Fri Mar 2 13:34:48 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 02 Mar 2007 13:34:48 +1100 Subject: Call for release testing. In-Reply-To: <116F1768869C4944A925A2A65CEE2E29566DA4@otisbs01.oti.local> References: <116F1768869C4944A925A2A65CEE2E29566DA4@otisbs01.oti.local> Message-ID: <45E78D48.3020908@zip.com.au> Bill Colvin wrote: > On Thu, 01 Mar 2007 23:54:14 +1100 > Darren Tucker wrote: > >> Please send reports of success or failure to >> openssh-unix-dev at mindrot.org. > > Tried testing with Snapshot 20070302 Thanks. > There seems to be an implicit assumption that if locate exists as an > executable on the system, then there will be a database that can be used > by locate to find various files. At what point is that? The only thing I can think of that uses locate is contrib/findssl.sh, and that's basically an unsupported but sometimes useful tool. -- 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 josh-lists at untruth.org Fri Mar 2 15:36:22 2007 From: josh-lists at untruth.org (Joshua Hill) Date: Thu, 1 Mar 2007 20:36:22 -0800 Subject: OpenSSH use of OpenSSL in FIPS Mode In-Reply-To: <116F1768869C4944A925A2A65CEE2E29566D8D@otisbs01.oti.local>; from Bill.Colvin@opticatech.com on Thu, Mar 01, 2007 at 12:25:08PM -0700 References: <116F1768869C4944A925A2A65CEE2E29566D8D@otisbs01.oti.local> Message-ID: <20070301203622.A6694@chiba.halibut.com> On Thu, Mar 01, 2007 at 12:25:08PM -0700, Bill Colvin wrote: > Now that OpenSSL has received FIPS 140-2 certification, does anyone know > if the work started a couple of years ago to allow OpenSSH to use > OpenSSL in FIPS mode will be reactivated? Does it much matter? The portion of OpenSSL included within the FIPS validation boundary (that is, the part that was actually validated, and is covered under the certificate) is just a hair more than the algorithms. (It's the algorithms, along with some self test and state logic). You can verify this fact by reading the security policy: http://csrc.nist.gov/cryptval/140-1/140sp/140sp733.pdf Using any additional functionality that is relevant to FIPS 140 (which would certainly include any key management process, for example, the SSL or TLS protocol implemented within OpenSSL, or the SSH v2 protocol present for OpenSSH) necessitates a separate validation process and a separate certificate. For the FIPS 140 validation scheme, using a validated sub-module is a significant advantage for closed source software, but it's a fairly small advantage for an open-source library. Josh From gert at greenie.muc.de Fri Mar 2 18:00:05 2007 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 2 Mar 2007 08:00:05 +0100 Subject: Call for release testing. In-Reply-To: <45E6CCF6.2010501@zip.com.au> References: <45E6CCF6.2010501@zip.com.au> Message-ID: <20070302070003.GB440@greenie.muc.de> Hi, On Thu, Mar 01, 2007 at 11:54:14PM +1100, Darren Tucker wrote: > Running the regression tests supplied with Portable does not require > installation and is a simply: > > $ ./configure && make tests ok for yesterday's CVS snapshot on NetBSD 2.0.3 / Sparc64. 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 d.marner at mikro-software.de Fri Mar 2 20:17:28 2007 From: d.marner at mikro-software.de (marner) Date: Fri, 02 Mar 2007 10:17:28 +0100 Subject: bending openssh output Message-ID: <1172827048.7069.22.camel@localhost> Hi there. I am not sure if this is the right place to address my question, but I need someone how knows about the channel system of openssh. At the moment, I try to modify the openssh source to fit to my needs. Therefore I modified the openssh source so it can be called from my source like a function (simply changed "void main()" to "void ssh()"). This works perfect for the moment, but now comes the problem: When I use openssh to build up a connection to a ssh server like this: ssh -myparameter pass user at host "ls -al * | grep .txt" I usually get a single line returned like -rw-r--r-- 1 user group 1223 2007-01-01 08:00 mydata.txt Now my question: Where in the openssh source can I redirect the output of this line from stdout to a string variable I use? (so I could modify/parse it before writing it to stdout) I tracked it down to the clients side of the source. Somewhere in clientloop.c I think. I am not sure which way would be the best approach... as far as I understand the source, there exists a set of filedescriptors for writing and reading which are polled by select. But modifying these could create problems with other functionalities of ssh. I just want to redirecting the console output to my array. Any hints? (please don't ask why I am trying such difficult things instead of redirecting stdout in the shell. it would take to long to explain. Actually, it's a kind of Systemmonitoring Tool for monitoring/controlling many clusternodes simultaneously. the only requirement for all nodes which are to be monitored is a running openssh daemon. I would be very happy if someone could help me a little... daniel marner From Bill.Colvin at opticatech.com Sat Mar 3 01:08:27 2007 From: Bill.Colvin at opticatech.com (Bill Colvin) Date: Fri, 2 Mar 2007 07:08:27 -0700 Subject: OpenSSH use of OpenSSL in FIPS Mode In-Reply-To: <20070301203622.A6694@chiba.halibut.com> References: <116F1768869C4944A925A2A65CEE2E29566D8D@otisbs01.oti.local> <20070301203622.A6694@chiba.halibut.com> Message-ID: <116F1768869C4944A925A2A65CEE2E29566E03@otisbs01.oti.local> > -----Original Message----- > From: Joshua Hill [mailto:josh-lists at untruth.org] > Does it much matter? Yes it definitely does matter, particularly to government agencies (and more and more businesses) that are required to use FIPS certified crypto algorithms. > Using any additional functionality that is relevant to FIPS 140 (which > would certainly include any key management process, for example, the > SSL or TLS protocol implemented within OpenSSL, or the SSH v2 protocol > present for OpenSSH) necessitates a separate validation process and a > separate certificate. These protocols support a smorgasbord of crypto algorithms, and those that are actually used in a particular session are negotiated to a common acceptable set between the two parties. If one of those parties is operating in FIPS mode using openssl, then the set of algorithms would be restricted to those supported. I believe the algorithms that have een certified are sufficient to suppot any of these protocols. > For the FIPS 140 validation scheme, using a validated sub-module is > a significant advantage for closed source software, but it's a fairly > small advantage for an open-source library. The whole point behind getting FIPS certification for the OpenSSL source library is so that other open source applications (e.g. Apache or OpenSSH) can take advantage of it and provide applications that are only using FIPS Certified algorithms for those users that require it in their environments. Bill From jan.iven at cern.ch Sat Mar 3 00:49:07 2007 From: jan.iven at cern.ch (Jan Iven) Date: Fri, 02 Mar 2007 14:49:07 +0100 Subject: Call for release testing. In-Reply-To: References: <45E6CCF6.2010501@zip.com.au> Message-ID: <45E82B53.5090507@cern.ch> On 01/03/07 19:54, Simon Wilkinson wrote: .. > I take it there's no chance of any of the GSSAPI/Kerberos bugs on > bugzilla.mindrot.org being fixed for this release? Seconded - I'd love to see e.g. #1008 fixed upstream.. and that is a two-line patch. To stay on the subject: CVS of 20070302 builds and self-tests fine on an i386 RHEL4-clone, using ./configure --prefix=/usr --with-tcp-wrappers --disable-strip --without-zlib-version-check --with-pam --with-selinux --with-linux-audit --with-kerberos5 make SUDO=sudo make tests From josh-lists at untruth.org Sat Mar 3 03:19:08 2007 From: josh-lists at untruth.org (Joshua Hill) Date: Fri, 2 Mar 2007 08:19:08 -0800 Subject: OpenSSH use of OpenSSL in FIPS Mode In-Reply-To: <116F1768869C4944A925A2A65CEE2E29566E03@otisbs01.oti.local>; from Bill.Colvin@opticatech.com on Fri, Mar 02, 2007 at 07:08:27AM -0700 References: <116F1768869C4944A925A2A65CEE2E29566D8D@otisbs01.oti.local> <20070301203622.A6694@chiba.halibut.com> <116F1768869C4944A925A2A65CEE2E29566E03@otisbs01.oti.local> Message-ID: <20070302081908.A31923@chiba.halibut.com> I Wrote Re: OpenSSH supporting the FIPS-a-fied OpenSSL: > > Does it much matter? Bill Colvin responded: > Yes it definitely does matter, particularly to government agencies (and > more and more businesses) that are required to use FIPS certified crypto > algorithms. [...] > The whole point behind getting FIPS certification for the OpenSSL source > library is so that other open source applications (e.g. Apache or > OpenSSH) can take advantage of it and provide applications that are only > using FIPS Certified algorithms for those users that require it in their > environments. My point is that the OpenSSL validation does not accomplish the generally desired end. In order for a US federal agency to use hardware or software to protect certain types of information, all the relevant crypto functionality of that hardware or software needs to be covered by a FIPS 140 certificate. The crypto functionality explicitly includes _all_ key establishment functionality, including the implementation of the key establishment and data protection protocols (e.g., TLS and SSHv2). The portion of the OpenSSL library that was actually evaluated only include the cryptographic algorithms, and a bit of additional logic. Thus, any product that includes the FIPS validated OpenSSL component, and additionally includes some other crypto functionality (for example, an implementation of the TLS protocol, the SSHv2 protocol, or really almost anything else that is likely to be built on top of this particular validated module) will need to go through its own separate FIPS 140 validation process. Josh From skeleten at shillest.net Sat Mar 3 05:29:25 2007 From: skeleten at shillest.net (Norihiko Murase) Date: Sat, 03 Mar 2007 03:29:25 +0900 Subject: (20070302) Warning messages on FreeBSD 4.11-RELEASE (Re: Call for release testing.) In-Reply-To: <45E6CCF6.2010501@zip.com.au> References: <45E6CCF6.2010501@zip.com.au> Message-ID: <20070303032925.69f425%skeleten@shillest.net> Two kinds of the warning messages were displayed when I tried building the snapshot 20070302 on the machine where FreeBSD 4.11-RELEASE is running. The environment under which I built it is as follows: CPU: i386 family OS: FreeBSD 4.11-RELEASE Compiler: gcc 2.95.4 20020320 [FreeBSD] (/usr/bin/gcc) The options I specified in executing the configure script are as follows: ./configure --prefix=/usr/local/OpenSSH --datarootdir='$(prefix)' --with-rpath \ --without-osfsia --with-zlib=/usr/local/zlib --without-skey --with-tcp-wrappers \ --with-libedit=/usr/local/libedit --without-audit --without-pam \ --with-ssl-dir=/usr/local/OpenSSL --without-rand-helper \ --with-privsep-user=sshd --with-privsep-path=/var/empty \ --without-sectok --without-opensc --without-kerberos5 \ --with-xauth=/usr/X11R6/bin/xauth --without-ipaddr-display \ --with-default-path=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin \ --with-superuser-path=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin \ --without-4in6 --with-pid-dir=/var/run The warning messages displayed when I built it are classified into two: (1) warning: `MAXSYMLINKS' redefined (2) warning: `__nonnull__' attribute directive ignored Both kinds of them are displayed when openssh/openbsd-compat/bsd-misc.c is compiled, just as follows: ------------------------------------------------------------ gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -I. -I.. -I. -I./.. -I/usr/local/OpenSSL/include -I/usr/l ocal/zlib/include -I/usr/local/libedit/include -DHAVE_CONFIG_H -c bsd-misc.c In file included from /usr/include/resolv.h:60, from ../openbsd-compat/getrrsetbyname.h:59, from ../openbsd-compat/openbsd-compat.h:45, from ../includes.h:167, from bsd-misc.c:18: /usr/include/sys/param.h:194: warning: `MAXSYMLINKS' redefined ../defines.h:72: warning: this is the location of the previous definition In file included from bsd-misc.c:31: ../xmalloc.h:26: warning: `__nonnull__' attribute directive ignored ------------------------------------------------------------ I'm very happy if you give me some comments about this. Thanks, --- Norihiko Murase From stuge-openssh-unix-dev at cdy.org Sat Mar 3 13:02:34 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 3 Mar 2007 03:02:34 +0100 Subject: bending openssh output In-Reply-To: <1172827048.7069.22.camel@localhost> References: <1172827048.7069.22.camel@localhost> Message-ID: <20070303020234.16804.qmail@cdy.org> On Fri, Mar 02, 2007 at 10:17:28AM +0100, marner wrote: > I would be very happy if someone could help me a little... I would suggest using popen() //Peter From bob at proulx.com Sun Mar 4 04:46:07 2007 From: bob at proulx.com (Bob Proulx) Date: Sat, 3 Mar 2007 10:46:07 -0700 Subject: bending openssh output In-Reply-To: <1172827048.7069.22.camel@localhost> References: <1172827048.7069.22.camel@localhost> Message-ID: <20070303174607.GA27718@dementia.proulx.com> marner wrote: > When I use openssh to build up a connection to a ssh server like this: > ssh -myparameter pass user at host "ls -al * | grep .txt" > > I usually get a single line returned like > -rw-r--r-- 1 user group 1223 2007-01-01 08:00 mydata.txt > > Now my question: > Where in the openssh source can I redirect the output of this line from > stdout to a string variable I use? (so I could modify/parse it before > writing it to stdout) In shell you can grab the output of commands put put them into a string using the old backtick `...` style or the newer $(...) style. I suggest the newer style because the quoting rules are easier to understand. var=$(ssh -myparameter pass user at host "ls -al * | grep .txt") Then you can modify the output of ssh as a string and print it or not. Bob From jdvf at optonline.net Sun Mar 4 06:38:41 2007 From: jdvf at optonline.net (John Devitofranceschi) Date: Sat, 03 Mar 2007 14:38:41 -0500 Subject: Call for release testing. In-Reply-To: <45E6CCF6.2010501@zip.com.au> References: <45E6CCF6.2010501@zip.com.au> Message-ID: <45E9CEC1.7010404@optonline.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mac OS X version 10.4.8 $ uname -a Darwin enoch.local 8.8.0 Darwin Kernel Version 8.8.0: Fri Sep 8 17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/RELEASE_PPC Power Macintosh powerpc $ ./configure --with-ssl-dir=/usr/local/ssl $ /usr/local/ssl/bin/openssl version OpenSSL 0.9.8d 28 Sep 2006 All tests ok. Stock openssl had an issue with version mismatch between library and include files so I had to use the fresher one that I keep in /usr/local. jd - -- John Devitofranceschi, E-Mail: jdvf at optonline.net Fax: +1 203 348 8219 PGP Fingerprint: 0D33 5A27 0810 9543 64FB DF4A 54CF 4B40 1335 4673 "What," asked Mr. Croup, "do you want?" "What," asked the marquis de Carabas, a little more rhetorically, "does anyone want?" "Dead things," suggested Mr. Vandemar. "Extra teeth." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) iD8DBQFF6c6/VM9LQBM1RnMRAoocAJ4lenwzrsx2L088SSOUz1xLS7pmsgCgyPH1 A2Zz8zv/zg6FC3OzYLtTFkA= =LYSD -----END PGP SIGNATURE----- From frederik at a5.repetae.net Mon Mar 5 11:27:46 2007 From: frederik at a5.repetae.net (Frederik Eaton) Date: Mon, 5 Mar 2007 00:27:46 +0000 Subject: sshd leaking processes Message-ID: <20070305002746.GA755@a5.repetae.net> Hello, I am experiencing a problem with OpenSSH_4.3p2 Debian-8, OpenSSL 0.9.8c 05 Sep 2006 I have a tool which I use to generate command lines for end-end encryption through firewalls, following directions from an old discussion on this mailing list (thanks btw). It gives me something like this: ssh -p 47774 localhost -o "ProxyCommand=ssh -v -v vds5.dedi.blackcatnetworks.co.uk -- 'nc localhost 47774'" -- 'echo hi' When I run that, two sshd processes appear at the final destination host, and don't go away until I kill them. I am wondering if this problem is known to have been fixed in a recent version, or if I should download the latest version and try, or what. The end of the output I see from the above command is (note this is verbose output from the ProxyCommand ssh, not the parent one): debug1: Entering interactive session. debug2: callback start debug2: x11_get_proto: /usr/X11R6/bin/xauth list :0.0 2>/dev/null debug1: Requesting X11 forwarding with authentication spoofing. debug2: channel 0: request x11-req confirm 0 debug1: Requesting authentication agent forwarding. debug2: channel 0: request auth-agent-req at openssh.com confirm 0 debug2: client_session2_setup: id 0 debug1: Sending environment. debug1: Sending env LANG = en_US.UTF-8 debug2: channel 0: request env confirm 0 debug1: Sending command: nc localhost 47774 debug2: channel 0: request exec confirm 0 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 hi debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK debug1: Killed by signal 1. Many thanks, Frederik -- http://ofb.net/~frederik/ From dtucker at zip.com.au Mon Mar 5 11:43:28 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 05 Mar 2007 11:43:28 +1100 Subject: sshd leaking processes In-Reply-To: <20070305002746.GA755@a5.repetae.net> References: <20070305002746.GA755@a5.repetae.net> Message-ID: <45EB67B0.10601@zip.com.au> Frederik Eaton wrote: > Hello, > > I am experiencing a problem with > > OpenSSH_4.3p2 Debian-8, OpenSSL 0.9.8c 05 Sep 2006 > > I have a tool which I use to generate command lines for end-end > encryption through firewalls, following directions from an old > discussion on this mailing list (thanks btw). It gives me something > like this: > > ssh -p 47774 localhost -o "ProxyCommand=ssh -v -v vds5.dedi.blackcatnetworks.co.uk -- 'nc localhost 47774'" -- 'echo hi' > > When I run that, two sshd processes appear at the final destination > host, and don't go away until I kill them. > > I am wondering if this problem is known to have been fixed in a recent > version, or if I should download the latest version and try, or what. You're using "traditional" netcat (ie 1.10) on the intermediate server? What's happening is that sshd closes the stdio to the "nc" processes and waits for it to exit, but the nc process never checks for this closure and never exits, thus deadlocks. You can substitute connect[1] for netcat as it does not have this particular problem. See also http://bugzilla.mindrot.org/show_bug.cgi?id=396 It's possible that the recent changes for bug #52 help in this situation but I suspect not. [1] http://zippo.taiyo.co.jp/~gotoh/ssh/connect.html -- 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 djm at mindrot.org Mon Mar 5 11:49:20 2007 From: djm at mindrot.org (Damien Miller) Date: Mon, 5 Mar 2007 11:49:20 +1100 (EST) Subject: sshd leaking processes In-Reply-To: <20070305002746.GA755@a5.repetae.net> References: <20070305002746.GA755@a5.repetae.net> Message-ID: On Mon, 5 Mar 2007, Frederik Eaton wrote: > Hello, > > I am experiencing a problem with > > OpenSSH_4.3p2 Debian-8, OpenSSL 0.9.8c 05 Sep 2006 > > I have a tool which I use to generate command lines for end-end > encryption through firewalls, following directions from an old > discussion on this mailing list (thanks btw). It gives me something > like this: > > ssh -p 47774 localhost -o "ProxyCommand=ssh -v -v vds5.dedi.blackcatnetworks.co.uk -- 'nc localhost 47774'" -- 'echo hi' > > When I run that, two sshd processes appear at the final destination > host, and don't go away until I kill them. It is normal to have two sshd processes when privilege separation is enabled, but it is not normal for them to linger. How do they appear in the output of a 'ps awwwwwx'? > I am wondering if this problem is known to have been fixed in a recent > version, or if I should download the latest version and try, or what. It would be a good idea to try a recent release, or better yet, one of the snapshots at http://www.mindrot.org/openssh_snap/ -- these are to be openssh-4.6 very soon.. > The end of the output I see from the above command is (note this is > verbose output from the ProxyCommand ssh, not the parent one): If you can recreate the problem with a more recent version, a debug trace from sshd would be more instructive than the output of the client. -d From frederik at a5.repetae.net Mon Mar 5 13:17:30 2007 From: frederik at a5.repetae.net (Frederik Eaton) Date: Mon, 5 Mar 2007 02:17:30 +0000 Subject: sshd leaking processes In-Reply-To: <45EB67B0.10601@zip.com.au> References: <20070305002746.GA755@a5.repetae.net> <45EB67B0.10601@zip.com.au> Message-ID: <20070305021730.GA2137@a5.repetae.net> > You're using "traditional" netcat (ie 1.10) on the intermediate server? Yes > What's happening is that sshd closes the stdio to the "nc" processes > and waits for it to exit, but the nc process never checks for this > closure and never exits, thus deadlocks. > > You can substitute connect[1] for netcat as it does not have this particular problem. Thanks a lot, that indeed works. Frederik -- http://ofb.net/~frederik/ From kladko at aspectlabs.com Mon Mar 5 12:13:10 2007 From: kladko at aspectlabs.com (Stan Kladko) Date: Sun, 4 Mar 2007 17:13:10 -0800 Subject: OpenSSH use of OpenSSL in FIPS Mode Message-ID: <008901c75ec3$71b8ab30$640a0a0a@fomalhaut> >From our experience working on FIPS 140-2 conformance testing of IT products when a decision is made on whether a particular IT solution is FIPS 140-2 compliant multiple factors need to be taken into account, including the FIPS Pub 140-2 standard, FIPS 140-2 Derived Test Requirements, CMVP FAQ and Implementation Guidance. The ultimate authority in this process belongs to the CMVP. The CMVP provides its current interpretations and guidelines as to the intepretation of the FIPS 140-2 standard and the conformance testing/validation process on its public web site http://csrc.nist.gov/cryptval/ In particular, the official CMVP FAQ available at http://csrc.nist.gov/cryptval/140-1/CMVPFAQ.pdf discusses incorporation of another vendor's cryptographic modules in a subsection of Section 2.2.1 entitled "Can I incorporate another vendor's validated cryptographic module". In particular, the following is specified: " Yes. A cryptographic module that has already been issued a FIPS 140-1 or FIPS 140-2 validation certificate may be incorporated or embedded into another product. The new product may reference the FIPS 140-1 or FIPS 140-2 validated cryptographic module so long as the new product does not alter the original validated cryptographic module. A product which uses an embedded validated cryptographic module cannot claim itself to be validated; only that it utilizes an embedded validated cryptographic module. There is no assurance that a product is correctly utilizing an embedded validated cryptographic module - this is outside the scope of the FIPS 140-1 or FIPS 140-2 validation. " Note that the CMVP FAQ does specify that a FIPS 140-1/2 validated module may be incorporated into another product. It then specifies that making a decision on whether a product is correctly utilizing an embedded module is outside of the scope of the FIPS 140-1 or FIPS 140-2 validation. A subsection of Section 2.1 of the CMVP FAQ entitled "A vendor is selling me a crypto solution - what should I ask?" specifies in particular: "Verify with the vendor that the application or product that is being offered is either a validated cryptographic module itself (e.g. VPN, SmartCard, etc) or the application or product uses an embedded validated cryptographic module (toolkit, etc). Ask the vendor to supply a signed letter stating their application, product or module is a validated module or incorporates a validated module, the module provides all the cryptographic services in the solution, and reference the modules validation certificate number." Note that it is specified that the validated module shall provide "all the cryptographic services in the solution". A typical IT solution may provide a variety of services. From such a set of services all the cryptographic services shall be provided by a validated cryptographic module. A typical network protocol, such as IPSec/IKE, TLS, SSH, S-MIME or 802.11 protocol family may provide a complex variety of services. Some of such services may have cryptographic nature and utilize Approved or allowed for use cryptographic algorithms, such as encryption, decryption, signatures, hashes, message digests and others. Other services provided by a network protocol may be of non-cryptographic nature, such as packet routing, packet assembly/disassembly, defragmentation, radio and link layer communications, firewalling, network address translation, address resolution, quality of service, re-transmission and others. While the ultimate verdict for a particular solution belongs to the CMVP, it is generically logical to assume that non-cryptographic services of a particular network protocol or a set of protocols may be implemented outside of a validated cryptographic module. This is also logical having in mind that in many cases non-cryptographic services of a particular protocol may be delegated to other devices in the IT solution. For instance, in some wireless LAN access systems an implementation of the 802.11 protocol set is provided jointly by a wireless access switch and a wireless access point, where the wireless access point may provide non-cryptographic services of the 802.11 protocol set such as radio transmissions, frequency and signal strength control, initial wireless client association and others. Another widely used example is a web server offloading cryptographic functionality of the HTTPS/TLS protocol to a FIPS 140-2 validated cryptographic accelerator card (many such cards are available on the market). It is then also important to consider industry-wide interpretation patterns and precedents in this field. After performing a review of the FIPS 140-2 validated products list http://csrc.nist.gov/cryptval/140-1/140val-all.htm one may conclude that implementing non-cryptographic services of a particular network protocol outside of a validated cryptoraphic module can in many cases be considered as an industry trend. There are multiple examples which illustrate such a trend. For illustration purposes only we can take a look at the example of the Microsoft Kernel Module http://csrc.nist.gov/cryptval/140-1/140sp/140sp241.pdf Here I would like to re-iterate that there are many other modules which follow a similar trend, the module is just one example out of many. The analysis here is generic, applies to a large number of validated modules, and is not intended to make any specific statements as to the validation of this particular module. As specified by the vendor, the Kernel Module is used by the vendor impelementation of the IPSec/IKE protocol http://www.microsoft.com/technet/archive/security/topics/issues/fipseval.mspx?mfr=true In particular it is stated that "Both IPSEC and EFS in Windows 2000, XP, and Server 2003 use the FIPS-140-1 or FIPS 140-2 (as appropriate) evaluated Kernel Mode Cryptographic Module to encrypt the traffic packet data and file contents respectively if configured appropriately with the selections of FIPS compliant algorithms." A review of the Kernel Module Security Policy then shows that the module's services are specified as services performing cryptographic algorithms supported by IPSec/IKE(such as encryption/decryption and key agreement) and not as providing a full IPSec/IKE protocol impelementation. This could again serve as an illustration of the fact that non-cryptographic services of a particular protocol are in many cases implemented outside of a cryptographic module. A similar analysis could be performed for other protocols specified in http://www.microsoft.com/technet/archive/security/topics/issues/fipseval.mspx?mfr=true such as S/MIME (used in Outlook), TLS (used in Explorer), Remote Desktop Protocol and Encrypting File System. While the example discussed here does not directly consider to the SSH protocol, it bears significant degree of similarity to the question considered in this e-mail thread. Other examples can be discussed by analyzing the list of historically validated products http://csrc.nist.gov/cryptval/140-1/140val-all.htm . To conclude, both the historical perspective and the current CMVP guidance point to a possibility of non-cryptographic services in an IT solution being impemented outside of a validated cryptographic module. We are not aware of any CMVP regulations explicitely denying use of embedded validated cryptographic modules to satisfy the requirements of FIPS 140-2 statement, provided that the set of conditions specified in the CMVP FAQ and other relevant documentation is satisfied. With this in mind, the ultimate decision for a particular product/protocol belongs to the CMVP and the analysis presented in this e-mail can serve for discussion purposes only. With best regards, Stan Kladko, Aspect Labs FIPS 140-2 Lab www.aspectlabs.com >> > Does it much matter? >Bill Colvin responded: > Yes it definitely does matter, particularly to government agencies (and > more and more businesses) that are required to use FIPS certified crypto > algorithms. [...] > The whole point behind getting FIPS certification for the OpenSSL source > library is so that other open source applications (e.g. Apache or > OpenSSH) can take advantage of it and provide applications that are only > using FIPS Certified algorithms for those users that require it in their > environments. >My point is that the OpenSSL validation does not accomplish the generally >desired end. In order for a US federal agency to use hardware or >software to protect certain types of information, all the relevant crypto >functionality of that hardware or software needs to be covered by a FIPS >140 certificate. The crypto functionality explicitly includes _all_ >key establishment functionality, including the implementation of the >key establishment and data protection protocols (e.g., TLS and SSHv2). The portion of the OpenSSL library that was actually evaluated only include the cryptographic algorithms, and a bit of additional logic. Thus, any product that includes the FIPS validated OpenSSL component, and additionally includes some other crypto functionality (for example, an implementation of the TLS protocol, the SSHv2 protocol, or really almost anything else that is likely to be built on top of this particular validated module) will need to go through its own separate FIPS 140 validation process. Josh From santhi.amirta at gmail.com Mon Mar 5 22:42:55 2007 From: santhi.amirta at gmail.com (Santhi_M) Date: Mon, 5 Mar 2007 17:12:55 +0530 Subject: Call for release testing. References: <45E6CCF6.2010501@zip.com.au> Message-ID: <001801c75f1b$75491cf0$2d0110ac@samco> > Hi All. > > We are planning on doing one of our regular OpenSSH releases (4.6/4.6p1) > some time next week. This is a mostly a bugfix release, but there is > one new feature: > > sshd now allows the enabling and disabling of authentication methods on > a per user, group, host and network basis via the Match directive in > sshd_config. > $ ./configure && make tests are passed in HP-UX 11i version 1.0 and 2.0 platforms. Regards, Santhi. From josh-lists at untruth.org Tue Mar 6 04:46:26 2007 From: josh-lists at untruth.org (Joshua Hill) Date: Mon, 5 Mar 2007 09:46:26 -0800 Subject: OpenSSH use of OpenSSL in FIPS Mode In-Reply-To: <008901c75ec3$71b8ab30$640a0a0a@fomalhaut>; from kladko@aspectlabs.com on Sun, Mar 04, 2007 at 05:13:10PM -0800 References: <008901c75ec3$71b8ab30$640a0a0a@fomalhaut> Message-ID: <20070305094626.A31632@chiba.halibut.com> On Sun, Mar 04, 2007 at 05:13:10PM -0800, Stan Kladko wrote: > Ask the vendor to supply a signed > letter stating their application, product or module is a validated module or > incorporates a validated module, the module provides all the cryptographic > services in the solution, and reference the modules validation certificate > number." And that last part is the rub. > A typical network protocol, such as IPSec/IKE, TLS, SSH, S-MIME or 802.11 > protocol family may provide a complex variety of services. Some of such > services may have cryptographic nature and utilize Approved or allowed for > use cryptographic algorithms, such as encryption, decryption, signatures, > hashes, message digests and others. Other services provided by a network > protocol may be of non-cryptographic nature, such as packet routing, packet > assembly/disassembly, defragmentation, radio and link layer communications, > firewalling, network address translation, address resolution, quality of > service, re-transmission and others. Though there may exist certain protocols that combine security and non-security relevant functionality, the vast majority of IPSec/IKE, TLS and SSHv2 _is_ security relevant from a FIPS 140 perspective. > "Both IPSEC and EFS in Windows 2000, XP, and Server 2003 use the FIPS-140-1 > or FIPS 140-2 (as appropriate) evaluated Kernel Mode Cryptographic Module to > encrypt the traffic packet data and file contents respectively if configured > appropriately with the selections of FIPS compliant algorithms." > > A review of the Kernel Module Security Policy then shows that the module's > services are specified as services performing cryptographic algorithms > supported by IPSec/IKE(such as encryption/decryption and key agreement) and > not as providing a full IPSec/IKE protocol impelementation. This could again > serve as an illustration of the fact that non-cryptographic services of a > particular protocol are in many cases implemented outside of a cryptographic > module. I think that we agree that one could design a module that does implement all of the security relevant portions of a protocol. Is it done in the case of Microsoft's Kernel Module? I have no idea, and I wouldn't care to speculate. Is this the case for OpenSSL's validated module, a case where literally anyone with a bit of time on their hands can look at the module and determine precisely what the module is (and is not) doing? I don't think so. In particular, within SSHv2 and TLS there are key agreement protocols. (If we want to get all reference, you'll note that these protocols are listed in FIPS 140-2's IG 7.1). As key establishment protocols are security relevant, and thus the code that implements them must be included within a FIPS boundary. Does it have to be included within the OpenSSL sub-module? No, of course not. But if this functionality exists within the "IT device", it does need to be included within SOME FIPS module. Josh From kladko at aspectlabs.com Tue Mar 6 08:28:20 2007 From: kladko at aspectlabs.com (Stan Kladko) Date: Mon, 5 Mar 2007 13:28:20 -0800 Subject: OpenSSH use of OpenSSL in FIPS Mode References: <008901c75ec3$71b8ab30$640a0a0a@fomalhaut> <20070305094626.A31632@chiba.halibut.com> Message-ID: <016f01c75f6d$32e65ba0$640a0a0a@fomalhaut> Coming back to the quote from the CMVP FAQ "Ask the vendor to supply a signed letter stating their application, product or module is a validated module or incorporates a validated module, the module provides all the cryptographic services in the solution, and reference the modules validation certificate number." It is specified that the module provides "all the cryptographic services in the solution". It is not specified that the module provides "all the security-relevant services in the solution". The FIPS 140-2 standard in focused on the cryptography. There are many generically security relevant functionalities such as antivirus protection, firewalling, IPS/IDS and others which are not currently covered by the FIPS 140-2 standard. An antivirus solution which uses a cryptographic module for its operations can satisfy requirements of the FIPS 140-2 by delegating its cryptographic functions to an embedded FIPS 140-2 validated module. Including the entire antivirus solution in the FIPS 140-2 validation would hardly improve the overall security since FIPS 140-2 does not currently have requirements in the field of antivirus protection. In a similar fashion, the FIPS 140-2 standard does not currently have requirements related to network vulnerabilities or denial of service attacks. The main job of a FIPS 140-2 testing lab is to consistently apply current regulations including the FIPS 140-2 standard, the Derived Test Requirements and the Implementation Guidance. One can have suggestions for further improvements which could be communicated to the CMVP and potentially incorporated in the future versions of the standard or in the implementation guidance. For the current version of the standard a testing lab needs to apply the current regulations impartially to all vendors. If in the future the CMVP decides to introduce a simple and inexpensive program for validating compliance of IT solutions with embedded FIPS 140-2 modules it might be a reasonable idea. For now, as explained in the CMVP FAQ, such validation is not available. Since the CMVP does not have a formal program for validation of IT solutions with embedded FIPS 140-2 modules, the question is how is the actual compliance/non-compliance determined. Our experience is that the compliance is determined by the federal agency/buyer selecting the solution. During the process the customer may contact the CMVP, testing labs or security experts for an opinion. In many cases, though, the buyers make such decisions independently. Here one shall mention that FIPS 140-2 is only a security baseline and each federal agency may establish its own requirements exceeding the requirements of FIPS 140-2. In the particular example of network protocols our experience shows that federal agencies generally do accept networking products (IPSEC/TLS/SSH etc.) with embedded FIPS 140-2 validated crypto software modules or hardware cards as FIPS 140-2 compliant. ----- Original Message ----- From: "Joshua Hill" To: "Stan Kladko" Cc: Sent: Monday, March 05, 2007 9:46 AM Subject: Re: OpenSSH use of OpenSSL in FIPS Mode > On Sun, Mar 04, 2007 at 05:13:10PM -0800, Stan Kladko wrote: >> Ask the vendor to supply a signed >> letter stating their application, product or module is a validated module >> or >> incorporates a validated module, the module provides all the >> cryptographic >> services in the solution, and reference the modules validation >> certificate >> number." > > And that last part is the rub. > >> A typical network protocol, such as IPSec/IKE, TLS, SSH, S-MIME or 802.11 >> protocol family may provide a complex variety of services. Some of such >> services may have cryptographic nature and utilize Approved or allowed >> for >> use cryptographic algorithms, such as encryption, decryption, signatures, >> hashes, message digests and others. Other services provided by a network >> protocol may be of non-cryptographic nature, such as packet routing, >> packet >> assembly/disassembly, defragmentation, radio and link layer >> communications, >> firewalling, network address translation, address resolution, quality of >> service, re-transmission and others. > > Though there may exist certain protocols that combine security and > non-security relevant functionality, the vast majority of IPSec/IKE, > TLS and SSHv2 _is_ security relevant from a FIPS 140 perspective. > >> "Both IPSEC and EFS in Windows 2000, XP, and Server 2003 use the >> FIPS-140-1 >> or FIPS 140-2 (as appropriate) evaluated Kernel Mode Cryptographic Module >> to >> encrypt the traffic packet data and file contents respectively if >> configured >> appropriately with the selections of FIPS compliant algorithms." >> >> A review of the Kernel Module Security Policy then shows that the >> module's >> services are specified as services performing cryptographic algorithms >> supported by IPSec/IKE(such as encryption/decryption and key agreement) >> and >> not as providing a full IPSec/IKE protocol impelementation. This could >> again >> serve as an illustration of the fact that non-cryptographic services of a >> particular protocol are in many cases implemented outside of a >> cryptographic >> module. > > I think that we agree that one could design a module that does implement > all of the security relevant portions of a protocol. Is it done in the > case of Microsoft's Kernel Module? I have no idea, and I wouldn't care > to speculate. > > Is this the case for OpenSSL's validated module, a case where literally > anyone with a bit of time on their hands can look at the module and > determine precisely what the module is (and is not) doing? I don't > think so. > > In particular, within SSHv2 and TLS there are key agreement protocols. > (If we want to get all reference, you'll note that these protocols > are listed in FIPS 140-2's IG 7.1). As key establishment protocols are > security relevant, and thus the code that implements them must be included > within a FIPS boundary. Does it have to be included within the OpenSSL > sub-module? No, of course not. But if this functionality exists within > the "IT device", it does need to be included within SOME FIPS module. > > Josh From josh-lists at untruth.org Tue Mar 6 10:36:43 2007 From: josh-lists at untruth.org (Joshua Hill) Date: Mon, 5 Mar 2007 15:36:43 -0800 Subject: OpenSSH use of OpenSSL in FIPS Mode In-Reply-To: <016f01c75f6d$32e65ba0$640a0a0a@fomalhaut>; from kladko@aspectlabs.com on Mon, Mar 05, 2007 at 01:28:20PM -0800 References: <008901c75ec3$71b8ab30$640a0a0a@fomalhaut> <20070305094626.A31632@chiba.halibut.com> <016f01c75f6d$32e65ba0$640a0a0a@fomalhaut> Message-ID: <20070305153643.B27806@chiba.halibut.com> On Mon, Mar 05, 2007 at 01:28:20PM -0800, Stan Kladko wrote: > It is specified that the module provides "all the cryptographic services in > the solution". Do you not consider key establishment a "cryptographic service"? It would seem that we are largely speaking past each other in this instance. I acknowledge that some services (such as Anti-Virus, as you mentioned) may be generally considered a "security service", but would not normally be relevant to FIPS 140. This is not the matter at hand, however. The matter at hand is: "Should OpenSSH be modified to allow it to use the FIPS module within OpenSSL?" My contention is that this would not be particularly useful action to take as: (1) Key establishment _is_ relevant to FIPS 140. (2) OpenSSH implements key establishment such that the protocol is largely outside of OpenSSL. Yes, OpenSSH uses the underlying crypto algorithms provided by OpenSSL, but the key establishment is done outside OpenSSL. As a consequence of (1) and (2), if one were to modify OpenSSH to take advantage of the validated portion of OpenSSL, one would still not have a package that would be appropriate for use within the US Federal Government. In fact, to accomplish this end, one would still have to go through a separate validation process for the OpenSSH functionality, which means that it's about the same condition prior to the entire OpenSSL sub-component validation. Josh From kladko at aspectlabs.com Tue Mar 6 12:01:22 2007 From: kladko at aspectlabs.com (Stan Kladko) Date: Mon, 5 Mar 2007 17:01:22 -0800 Subject: OpenSSH use of OpenSSL in FIPS Mode References: <008901c75ec3$71b8ab30$640a0a0a@fomalhaut> <20070305094626.A31632@chiba.halibut.com> <016f01c75f6d$32e65ba0$640a0a0a@fomalhaut> <20070305153643.B27806@chiba.halibut.com> Message-ID: <021101c75f8a$f66e7c70$640a0a0a@fomalhaut> My understanding is that the OpenSSL module supports the cryptographic key establishment algorithms used in OpenSSH, such as Diffie-Hellman. If OpenSSH properly uses these algorithm implementations it will be in a similar class with respect to FIPS 140-2 compliance as Microsoft Internet Explorer, VPN client and other well known software titles which use Microsoft Crypto Providers. Regards, Stan ----- Original Message ----- From: "Joshua Hill" To: "Stan Kladko" Cc: Sent: Monday, March 05, 2007 3:36 PM Subject: Re: OpenSSH use of OpenSSL in FIPS Mode > On Mon, Mar 05, 2007 at 01:28:20PM -0800, Stan Kladko wrote: >> It is specified that the module provides "all the cryptographic services >> in >> the solution". > > Do you not consider key establishment a "cryptographic service"? > > It would seem that we are largely speaking past each other in this > instance. I acknowledge that some services (such as Anti-Virus, as you > mentioned) may be generally considered a "security service", but would > not normally be relevant to FIPS 140. > > This is not the matter at hand, however. The matter at hand is: "Should > OpenSSH be modified to allow it to use the FIPS module within OpenSSL?" > > My contention is that this would not be particularly useful action to > take as: > (1) Key establishment _is_ relevant to FIPS 140. > (2) OpenSSH implements key establishment such that the protocol is > largely outside of OpenSSL. Yes, OpenSSH uses the underlying crypto > algorithms provided by OpenSSL, but the key establishment is done > outside OpenSSL. > > As a consequence of (1) and (2), if one were to modify OpenSSH to take > advantage of the validated portion of OpenSSL, one would still not > have a package that would be appropriate for use within the US Federal > Government. > > In fact, to accomplish this end, one would still have to go through > a separate validation process for the OpenSSH functionality, which > means that it's about the same condition prior to the entire OpenSSL > sub-component validation. > > Josh From enrique.moliner at aragon.catastro.meh.es Tue Mar 6 18:48:26 2007 From: enrique.moliner at aragon.catastro.meh.es (enrique moliner) Date: Tue, 6 Mar 2007 08:48:26 +0100 Subject: priotc text hp-ux renicer program (version 1.7) Message-ID: <006e01c75fc3$d2be5960$b9d5390a@zaragoza.catastro.minhac.es> http://perso.wanadoo.es/priotc/ PRIOTC with source FREE_ENDUSER license Author: Enrique Moliner Martinez, from Zaragoza (Spain) Version is download file name. Automatic HP-UX pid renicer and serializer For use in HP-9000 (others?) unix systems with 'HP-UX' B.10.20 or higher This is a configurable 'automatic renicer' program: Get variable CPU time to pids depending on defined nice-value and cmd/prog/param names or patterns in configuration file, by only renice if match: -At startup, priotc renices all pids to defined nice. .When priotc is already running, watch ONLY for renice NEW pids or equal pid if a change in command-name or program-name is detected (like occurs in an exec command). Then, at any time, any nice value or serialize is valid by manually 'renicer', 'serialize' user commands and the hp-ux restrictions. This is also an 'automatic serializer program: Serialize a pid with nice >= that defined in configuration file if actually low free pages in the system. -For system performance, all serialized pids runs together in a sequential non- timeshare cpu use, but only if hp-ux detect low free pages. If enough pages, serialized pids runs also timeshare. Priotc serializes pids with high nice value (to run slow) >=that defined nice for [serialize] in the configuration file. ---------------------------------------------------------------------------- ------------ This source FREE ENDUSER license: -Is free unloaded with the source program -This program (source/executable) can be distributed ONLY in original form and ever completely free. .This program only can be modified for internal use, and in this case can not be distributed. The modified program ever must show the program author name (initial credits). -The documentation can be modified and distributed, ever free and with the reference of the program author name. FILES priotc.c source code priotc.cfg_example single configuration example priotc.comp for compiling priotc priotc.doc documentation file priotc.ver versions (read before installing) Download only if you accept free_enduser license: Backup your old version before load this version. priotc1-7.zip Report bugs to cmolimar at hotmail.com ********************************************************************************************** PAntes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos Before printing this email, assess if it is really needed. ********************* Aviso Legal ********************* Este mensaje y cualquier fichero adjunto est? dirigido ?nicamente a sus destinatarios y contiene informaci?n confidencial. Si usted considera que ha recibido este correo electr?nico por error (por el asunto, por el remitente o por cualquier otra causa), le informamos que cualquier revisi?n, alteraci?n, impresi?n, copia o transmisi?n de este mensaje o de cualquier fichero adjunto est? prohibida y puede constituir un acto ilegal. Por favor, notif?quele el error al remitente respondiendo a este e-mail y elimine el mensaje y su contenido inmediatamente. El Ministerio de Econom?a y Hacienda se reserva las acciones legales que le correspondan contra todo tercero que acceda de forma ileg?tima al contenido de cualquier mensaje externo procedente del mismo. ********************* Disclaimer ********************* This e-mail and any files transmitted with it are intended solely for the use of the intended recipients and may contain confidential information. If it appears (from the subject matter or address information or otherwise) that you received this email in error, please note that any review, dissemination, disclosure, alteration, printing, copying or transmission of this e-mail or any file transmitted with it is prohibited and may be unlawful. Please notify us by return email and delete this email and its contents immediately. Spanish Ministry of Finances may take any legal action, according with the illegal access to the content of any external message from the Ministry. ********************************************************************************************** From orkaan at orkaan.org Tue Mar 6 21:13:59 2007 From: orkaan at orkaan.org (Daniele Calore) Date: Tue, 6 Mar 2007 11:13:59 +0100 Subject: Call for release testing. In-Reply-To: <45E6CCF6.2010501@zip.com.au> References: <45E6CCF6.2010501@zip.com.au> Message-ID: <20070306111359.6535782f@puzzi> On Thu, 01 Mar 2007 23:54:14 +1100 Darren Tucker wrote: > Please send reports of success or failure to > openssh-unix-dev at mindrot.org. Tried testing with Snapshot 20070306 on Tru64 version 5.1B. # sizer -v; uname -svrp Compaq Tru64 UNIX V5.1B (Rev. 2650) OSF1 alpha v5.1 2650 alpha # ./ssh -V OpenSSH_4.5p1-snap20070306, OpenSSL 0.9.8d 28 Sep 2006 All tests are OK. -- Daniele Calore ( orkaan at orkaan.org) From marquess at oss-institute.org Tue Mar 6 23:13:46 2007 From: marquess at oss-institute.org (Steve Marquess) Date: Tue, 06 Mar 2007 07:13:46 -0500 Subject: OpenSSH use of OpenSSL in FIPS Mode In-Reply-To: <20070305094626.A31632@chiba.halibut.com> References: <008901c75ec3$71b8ab30$640a0a0a@fomalhaut> <20070305094626.A31632@chiba.halibut.com> Message-ID: <45ED5AFA.3060002@oss-institute.org> Joshua Hill wrote: > ... > I think that we agree that one could design a module that does implement > all of the security relevant portions of a protocol. Is it done in the > case of Microsoft's Kernel Module? I have no idea, and I wouldn't care > to speculate. > ... > A tangential observation to your discussion with Dr. Kladko: you are in effect saying that open source software should be held to a higher standard than proprietary software. During the five year process that led to the OpenSSL FIPS Object Module validation (#733), we were subjected to repeated challenges from anonymous "interested parties", each of which had to be painstakingly addressed. Each of which delayed the process. The end result was a better product, or at least a higher comfort level for the CMVP, but at the cost of a validated result now obsolescent to the point of near irrelevance for commercial purposes (fortunately OSSI now has the financial backing to pursue additional validations of more current versions). Dr. Kaldko is pointing out that the actual practice of FIPS 140-2, and claims of validation thereof, doesn't agree with the theory you espouse. Entirely aside from the possible merits of that theory, where open source is involved FIPS 140 isn't a level playing field. I think the results would be very entertaining indeed if someone like Groklaw's Pamela Jones were to take an interest in that topic. -Steve M. -- Steve Marquess marquess at oss-institute.org From root at paesimetal.com.br Wed Mar 7 01:14:53 2007 From: root at paesimetal.com.br (System Anti-Virus Administrator) Date: 6 Mar 2007 14:14:53 -0000 Subject: virus encontrado em mensagem enviada "Re: Valeu!!" Message-ID: Atencao: openssh-unix-dev at mindrot.org Um virus foi encontrado numa mensagem de Email que acabou de ser enviada por voce. Este scanner de Email a interceptou e impediu a mensagem de chegar no seu destino. O virus foi reportado como sendo: Worm.Somefool.AR Por favor atualize seu antivirus ou contate o seu suporte tecnico o mais rapido possivel pois voce tem um virus no seu computador. Sua mensagem foi enviada com o seguinte envelope: REMETENTE: openssh-unix-dev at mindrot.org DESTINATARIO: jayme at paesimetal.com.br ... e com o seguinte cabecalho: --- MAILFROM: openssh-unix-dev at mindrot.org Received: from localhost (HELO paesimetal.com.br) (127.0.0.1) by localhost with SMTP; 6 Mar 2007 14:14:53 -0000 X-MessageWall-Score: 0 (paesimetal.com.br) Received: from [200.204.85.113] by paesimetal.com.br (MessageWall 1.0.8) with SMTP; 6 Mar 2007 14:12:33 -0000 From: openssh-unix-dev at mindrot.org To: jayme at paesimetal.com.br Subject: Re: Valeu!! Date: Tue, 6 Mar 2007 11:14:10 -0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016_00001414.00000C4E" X-Priority: 3 X-MSMail-Priority: Normal --- From josh-lists at untruth.org Wed Mar 7 09:58:10 2007 From: josh-lists at untruth.org (Joshua Hill) Date: Tue, 6 Mar 2007 14:58:10 -0800 Subject: OpenSSH use of OpenSSL in FIPS Mode In-Reply-To: <45ED5AFA.3060002@oss-institute.org>; from marquess@oss-institute.org on Tue, Mar 06, 2007 at 07:13:46AM -0500 References: <008901c75ec3$71b8ab30$640a0a0a@fomalhaut> <20070305094626.A31632@chiba.halibut.com> <45ED5AFA.3060002@oss-institute.org> Message-ID: <20070306145810.A28729@chiba.halibut.com> Joshua Hill wrote: > I think that we agree that one could design a module that does implement > all of the security relevant portions of a protocol. Is it done in the > case of Microsoft's Kernel Module? I have no idea, and I wouldn't care > to speculate. Steve Marquess replied: > A tangential observation to your discussion with Dr. Kladko: you are in > effect saying that open source software should be held to a higher > standard than proprietary software. I'm not sure that I was saying that, but it does seem a consequence of the open source model; anyone can "look over the shoulder" of the validation laboratory and vendor, so anyone who has different ideas as to what should and should not be allowed can bring issues to NIST's attention. It's just the standard open source "many eyes" ideal, but brought to the regulatory setting. > Dr. Kaldko is pointing out that the actual practice of FIPS 140-2, and > claims of validation thereof, doesn't agree with the theory you espouse. If you re-read the discussion, you'll find that we're not really disagreeing about much up to this point, only talking past each other's points. It is clear that the current FIPS scheme allows one to validate a module that implements a limited set of cryptographic primitives, along with minimal state logic and self-tests. Further, it is clear that as long as your larger "IT device" implements no extra FIPS 140 relevant security functionality, that you can sell a your IT device, including the validated sub-module, into the US Federal setting. The central matter that is left unresolved here is this: Is it acceptable to build larger scale FIPS relevant security protocols using the primitives provided by the validated sub-module, _not_ seek an additional validation on this larger scale security functionality, and then sell your IT device into the US Federal setting? I'm fairly certain that the answer here is "no", but it would be interesting to see what CMVP might say on the matter. Josh From Jefferson.Ogata at noaa.gov Wed Mar 7 10:33:04 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Tue, 06 Mar 2007 23:33:04 +0000 Subject: OpenSSH use of OpenSSL in FIPS Mode In-Reply-To: <20070306145810.A28729@chiba.halibut.com> References: <008901c75ec3$71b8ab30$640a0a0a@fomalhaut> <20070305094626.A31632@chiba.halibut.com> <45ED5AFA.3060002@oss-institute.org> <20070306145810.A28729@chiba.halibut.com> Message-ID: <45EDFA30.5040604@noaa.gov> On 2007-03-06 22:58, Joshua Hill wrote: > The central matter that is left unresolved here is this: Is it > acceptable to build larger scale FIPS relevant security protocols > using the primitives provided by the validated sub-module, _not_ seek > an additional validation on this larger scale security functionality, > and then sell your IT device into the US Federal setting? > > I'm fairly certain that the answer here is "no", but it would be > interesting to see what CMVP might say on the matter. There you're getting into the fundamental issue of how the entire concept of FIPS 140-2 validation is broken by design. What counts as larger-scale security functionality? Is the pseudo-terminal driver included, since the data passes through it on the way to openssh? What about the VFS code that is used to page the openssl shared libraries in? What about the kernel page fault handler? Then there's the rest of the kernel--someone could have trojaned it to surreptitiously pull all data out of openssl buffers before encryption and transmit it to a third party. Or syslogd could be trojaned. And so on, ad infinitum. You have to draw the line somewhere on where the boundary on validation is going to lie. And no matter where you draw it, there will be ways to subvert the behavior of the validated code. If you follow the line of reasoning that the code "outside" the cryptographic module has to be validated also, the ultimate conclusion is that you have to validate the universe. That would be time-consuming, and certainly exceed NIST's resources. Not offering any answers here, only questions. Sorry. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From spatil at sonoasystems.com Wed Mar 7 00:37:02 2007 From: spatil at sonoasystems.com (spatil) Date: Tue, 06 Mar 2007 19:07:02 +0530 Subject: sshd Termination by SIGALRM Message-ID: <45ED6E7E.7050407@sonoasystems.com> Hi, I am seeing a problem where in sshd gets terminated by SIGALRM. sshd was listening on the socket and was not restarted. I saw a recent bug fix in openBSD openssh CVS which mentions: Clear alarm() before restarting sshd on SIGHUP. Without this, if there's a SIGALRM pending (for SSH1 key regeneration) when sshd is SIGHUP'ed, the newly exec'ed sshd will get the SIGALRM and not have a handler for it, and the default action will terminate the listening sshd. Analysis and patch from andrew at gaul.org. In my case no such signal was received. I am using OpenSSH 3.8.1p1 on FC3 with linux-2.6.16.13 kernel. The signal system call in Linux might fail if there is any pending signal for the process. It returns ERESTARTNOINTR. The following code in openssh sshd.c:main(): /* Mark that the key has been used (it was "given" to the child). */ if ((options.protocol & SSH_PROTO_1) && key_used == 0) { /* Schedule server key regeneration alarm. */ signal(SIGALRM, key_regeneration_alarm); alarm(options.key_regeneration_time); key_used = 1; } might cause a problem if signal call fails because of the above stated reason. In such a case the default handler (SIG_DFL which is terminate) gets called since alarm function gets executed anyways. Is my analysis correct ? From djm at cvs.openbsd.org Thu Mar 8 10:10:22 2007 From: djm at cvs.openbsd.org (Damien Miller) Date: Wed, 7 Mar 2007 16:10:22 -0700 (MST) Subject: Announce: OpenSSH 4.6 released Message-ID: <200703072310.l27NAMxP006468@cvs.openbsd.org> OpenSSH 4.6 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots and purchased T-shirts or posters. T-shirt, poster and CD sales directly support the project. Pictures and more information can be found at: http://www.openbsd.org/tshirts.html and http://www.openbsd.org/orders.html For international orders use http://https.openbsd.org/cgi-bin/order and for European orders, use http://https.openbsd.org/cgi-bin/order.eu Changes since OpenSSH 4.5: ============================ * sshd now allows the enabling and disabling of authentication methods on a per user, group, host and network basis via the Match directive in sshd_config. * The following bugs have been fixed in this release: - Clear SIGALRM when restarting due to SIGHUP. Prevents stray signal from taking down sshd if a connection was pending at the time SIGHUP was received - sftp returned a zero exit status when upload failed due to write errors (bugzilla #1252) - fixed an inconsistent check for a terminal when displaying scp progress meter (bugzilla #1265) - Parsing of time values in Match blocks was incorrectly applied to the global configuration (bugzilla #1275) - Allow multiple forwarding options to work when specified in a PermitOpen directive (bugzilla #1267) - Interoperate with ssh.com versions that do not support binding remote port forwarding sessions to a hostname (bugzilla #1019) * Portable OpenSSH bugs fixed: - "hang on exit" when background processes are running at the time of exit on a ttyful/login session (bugzilla #52) - Fix typos in the ssh-rand-helper(8) man page (bugzilla #1259) - Check that some SIG records have been returned in getrrsetbyname (bugzilla #1281) - Fix contrib/findssl for platforms that lack "which" (bugzilla #1237) - Work around bug in OpenSSH 0.9.6e that broke aes256-ctr, aes192-ctr, arcfour256 (bugzilla #1291) Checksums: ========== - SHA1 (openssh-4.6.tar.gz) = c1700845be464a769428f34ef727c1f530728afc - SHA1 (openssh-4.6p1.tar.gz) = b2aefeb1861b4688b1777436035239ec32a47da8 Reporting Bugs: =============== - please read http://www.openssh.com/report.html and http://bugzilla.mindrot.org/ OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From marquess at oss-institute.org Thu Mar 8 12:11:10 2007 From: marquess at oss-institute.org (Steve Marquess) Date: Wed, 07 Mar 2007 20:11:10 -0500 Subject: OpenSSH use of OpenSSL in FIPS Mode In-Reply-To: <45EDFA30.5040604@noaa.gov> References: <008901c75ec3$71b8ab30$640a0a0a@fomalhaut> <20070305094626.A31632@chiba.halibut.com> <45ED5AFA.3060002@oss-institute.org> <20070306145810.A28729@chiba.halibut.com> <45EDFA30.5040604@noaa.gov> Message-ID: <45EF62AE.9020201@oss-institute.org> Jefferson Ogata wrote: > On 2007-03-06 22:58, Joshua Hill wrote: > >> The central matter that is left unresolved here is this: Is it >> acceptable to build larger scale FIPS relevant security protocols >> using the primitives provided by the validated sub-module, _not_ seek >> an additional validation on this larger scale security functionality, >> and then sell your IT device into the US Federal setting? >> >> I'm fairly certain that the answer here is "no", but it would be >> interesting to see what CMVP might say on the matter. >> > > There you're getting into the fundamental issue of how the entire > concept of FIPS 140-2 validation is broken by design. > > What counts as larger-scale security functionality? Is the > pseudo-terminal driver included, since the data passes through it on the > way to openssh? What about the VFS code that is used to page the openssl > shared libraries in? What about the kernel page fault handler? Then > there's the rest of the kernel--someone could have trojaned it to > surreptitiously pull all data out of openssl buffers before encryption > and transmit it to a third party. Or syslogd could be trojaned. And so > on, ad infinitum. > > You have to draw the line somewhere on where the boundary on validation > is going to lie. And no matter where you draw it, there will be ways to > subvert the behavior of the validated code. If you follow the line of > reasoning that the code "outside" the cryptographic module has to be > validated also, the ultimate conclusion is that you have to validate the > universe. That would be time-consuming, and certainly exceed NIST's > resources. > > Not offering any answers here, only questions. Sorry. > On the basis of a past interactions with the CMVP I can tell you that they are keenly aware that software modules operate in the context of a larger computing environment and thus are subject to all the security vulnerabilities of that environment. Randy Easter, currently the director of the NIST CMVP, once said something along the lines of "with software there is no security". They have explicitly stated to me that the possibility of malicious attack (i.e., subversion of *non-cryptographic* security related functionality) was not a significant concern for FIPS 140-2 level 1. They don't attempt to check for security flaws like buffer overflows, for example. As I understand their perspective FIPS 140-2 isn't broken by design, it just has a scope limited to the cryptographic correctness and integrity of the module and not the overall security of the operational environment in which the module is embedded. That the CMVP is concerned about *cryptographically* relevant functionality I can also attest to personally :-) This thread has generated some interesting material. I'm going to distill it down to a section in the OpenSSL FIPS Object Module User Guide and ask my test lab to get it reviewed by the CMVP. -Steve M. -- Steve Marquess Veridical Systems, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 301-524-9915 cell 301-831-8447 land/fax marquess at oss-institute.org From wtchang at redhat.com Fri Mar 9 02:45:35 2007 From: wtchang at redhat.com (Wan-Teh Chang) Date: Thu, 08 Mar 2007 07:45:35 -0800 Subject: OpenSSH use of OpenSSL in FIPS Mode In-Reply-To: <45EF62AE.9020201@oss-institute.org> References: <008901c75ec3$71b8ab30$640a0a0a@fomalhaut> <20070305094626.A31632@chiba.halibut.com> <45ED5AFA.3060002@oss-institute.org> <20070306145810.A28729@chiba.halibut.com> <45EDFA30.5040604@noaa.gov> <45EF62AE.9020201@oss-institute.org> Message-ID: <45F02F9F.50603@redhat.com> Steve Marquess wrote: > > This thread has generated some interesting material. I'm going to > distill it down to a section in the OpenSSL FIPS Object Module User > Guide and ask my test lab to get it reviewed by the CMVP. It would be a greater service to the vendors and users of software cryptographic modules if CMVP could review and publish the distilled material that you provide in the Implementation Guidance for FIPS 140-2. Thanks! Wan-Teh From vinschen at redhat.com Fri Mar 9 04:41:30 2007 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 8 Mar 2007 18:41:30 +0100 Subject: Announce: OpenSSH 4.6 released In-Reply-To: <200703072310.l27NAMxP006468@cvs.openbsd.org> References: <200703072310.l27NAMxP006468@cvs.openbsd.org> Message-ID: <20070308174130.GA23722@calimero.vinschen.de> Hi, On Mar 7 16:10, Damien Miller wrote: > OpenSSH 4.6 has just been released. It will be available from the > mirrors listed at http://www.openssh.com/ shortly. > > OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 > implementation and includes sftp client and server support. A user on the Cygwin mailing list found a problem with 4.6p1 when using protocol version 1. The bug report was rather short: $ ssh -1 somemachine Disconnecting: Corrupted check bytes on input. I can reproduce this behaviour and when starting ssh with -vvv flags, the above error message is printed in this context: debug1: Found key in /home/corinna/.ssh/known_hosts:221 debug1: Encryption type: 3des debug1: Sent encrypted session key. debug2: cipher_init: set keylen (16 -> 32) debug2: cipher_init: set keylen (16 -> 32) debug1: Installing crc compensation attack detector. Disconnecting: Corrupted check bytes on input. The problem is that only the Cygwin 4.6p1 version seems to be affect. I tested the following combinations, the rows are the ssh version with which I tried to connect to the sshd versions in the columns, always with version 1.5 protocol. sshd: Linux 4.5 Linux 4.6 Cygwin 4.5 Cygwin 4.6 ssh: Linux 4.5 ok ok ok corrupted Linux 4.6 ok ok ok corrupted Cygwin 4.5 ok ok ok corrupted Cygwin 4.6 corrupted corrupted corrupted ok Apparently it doesn't have anything to do with the last minute patch I sent to this list a couple of days ago. It doesn't matter whether I use text read/write, or text read/binary write, or binary read/write. The effect is always the same. Since the checksums are transmitted using sockets, and sockets are unconditionally using binary read/write mode anyway, this was not to be expected. So, my question is this: Is there any change in the protocol 1 code which could explain this behaviour? Where shall I look if I try to debug this further? I'm rather a bit stumped right now. Thanks in advance, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From dtucker at zip.com.au Fri Mar 9 07:25:22 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 09 Mar 2007 07:25:22 +1100 Subject: Announce: OpenSSH 4.6 released In-Reply-To: <20070308174130.GA23722@calimero.vinschen.de> References: <200703072310.l27NAMxP006468@cvs.openbsd.org> <20070308174130.GA23722@calimero.vinschen.de> Message-ID: <45F07132.3000909@zip.com.au> Corinna Vinschen wrote: > Hi, > > On Mar 7 16:10, Damien Miller wrote: >> OpenSSH 4.6 has just been released. It will be available from the >> mirrors listed at http://www.openssh.com/ shortly. >> >> OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 >> implementation and includes sftp client and server support. > > A user on the Cygwin mailing list found a problem with 4.6p1 when > using protocol version 1. The bug report was rather short: > > $ ssh -1 somemachine > Disconnecting: Corrupted check bytes on input. > > I can reproduce this behaviour and when starting ssh with -vvv flags, > the above error message is printed in this context: > > debug1: Found key in /home/corinna/.ssh/known_hosts:221 > debug1: Encryption type: 3des > debug1: Sent encrypted session key. > debug2: cipher_init: set keylen (16 -> 32) > debug2: cipher_init: set keylen (16 -> 32) > debug1: Installing crc compensation attack detector. > Disconnecting: Corrupted check bytes on input. > > The problem is that only the Cygwin 4.6p1 version seems to be affect. > > I tested the following combinations, the rows are the ssh version > with which I tried to connect to the sshd versions in the columns, > always with version 1.5 protocol. > > sshd: Linux 4.5 Linux 4.6 Cygwin 4.5 Cygwin 4.6 > ssh: > Linux 4.5 ok ok ok corrupted > Linux 4.6 ok ok ok corrupted > Cygwin 4.5 ok ok ok corrupted > Cygwin 4.6 corrupted corrupted corrupted ok > > Apparently it doesn't have anything to do with the last minute patch I > sent to this list a couple of days ago. It doesn't matter whether I use > text read/write, or text read/binary write, or binary read/write. > The effect is always the same. Since the checksums are transmitted > using sockets, and sockets are unconditionally using binary read/write > mode anyway, this was not to be expected. > > So, my question is this: Is there any change in the protocol 1 code > which could explain this behaviour? Where shall I look if I try to > debug this further? I'm rather a bit stumped right now. If you're using OpenSSL 0.9.8e you could try backing out this bit in openbsd-compat/openssl-compat.h: /* OpenSSL 0.9.8e returns cipher key len not context key len */ #if (OPENSSL_VERSION_NUMBER == 0x0090805fL) # define EVP_CIPHER_CTX_key_length(c) ((c)->key_len) #endif -- 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 Fri Mar 9 08:57:47 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 9 Mar 2007 08:57:47 +1100 Subject: Announce: OpenSSH 4.6 released In-Reply-To: <45F07132.3000909@zip.com.au> References: <200703072310.l27NAMxP006468@cvs.openbsd.org> <20070308174130.GA23722@calimero.vinschen.de> <45F07132.3000909@zip.com.au> Message-ID: <20070308215747.GA13218@gate.dtucker.net> On Fri, Mar 09, 2007 at 07:25:22AM +1100, Darren Tucker wrote: > Corinna Vinschen wrote: [...] > > $ ssh -1 somemachine > > Disconnecting: Corrupted check bytes on input. > > > > I can reproduce this behaviour and when starting ssh with -vvv flags, > > the above error message is printed in this context: > > > > debug1: Found key in /home/corinna/.ssh/known_hosts:221 > > debug1: Encryption type: 3des > > debug1: Sent encrypted session key. > > debug2: cipher_init: set keylen (16 -> 32) > > debug2: cipher_init: set keylen (16 -> 32) > > debug1: Installing crc compensation attack detector. > > Disconnecting: Corrupted check bytes on input. > > > > The problem is that only the Cygwin 4.6p1 version seems to be affect. > > > > I tested the following combinations, the rows are the ssh version > > with which I tried to connect to the sshd versions in the columns, > > always with version 1.5 protocol. > > > > sshd: Linux 4.5 Linux 4.6 Cygwin 4.5 Cygwin 4.6 > > ssh: > > Linux 4.5 ok ok ok corrupted > > Linux 4.6 ok ok ok corrupted > > Cygwin 4.5 ok ok ok corrupted > > Cygwin 4.6 corrupted corrupted corrupted ok > > If you're using OpenSSL 0.9.8e you could try backing out this bit in > openbsd-compat/openssl-compat.h: > > /* OpenSSL 0.9.8e returns cipher key len not context key len */ > #if (OPENSSL_VERSION_NUMBER == 0x0090805fL) > # define EVP_CIPHER_CTX_key_length(c) ((c)->key_len) > #endif In fact, if you're using OpenSSL 0.9.8e I suggest you apply the following patch to it, recompile everything and see if your problem persists. The symmetry of the problem (ie it works with itself but doesn't interoperate) is the same as what I saw with the AES counter-mode problems in OpenSSH bug #1291. That workaround above only helps for the bits of OpenSSH that use EVP_CIPHER_CTX_key_length, it doesn't help where OpenSSL itself uses it, which may be the case here. See bugzilla #1291 for details. Index: crypto/evp/evp_lib.c =================================================================== RCS file: /home/dtucker/src/security/openssl/cvs/openssl-cvs/openssl/crypto/evp/evp_lib.c,v retrieving revision 1.10.2.1 diff -u -p -r1.10.2.1 evp_lib.c --- crypto/evp/evp_lib.c 29 Nov 2006 20:47:13 -0000 1.10.2.1 +++ crypto/evp/evp_lib.c 3 Mar 2007 23:54:00 -0000 @@ -225,7 +225,7 @@ int EVP_CIPHER_key_length(const EVP_CIPH int EVP_CIPHER_CTX_key_length(const EVP_CIPHER_CTX *ctx) { - return ctx->cipher->key_len; + return ctx->key_len; } int EVP_CIPHER_nid(const EVP_CIPHER *cipher) -- 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 Fri Mar 9 09:11:51 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 9 Mar 2007 09:11:51 +1100 Subject: Announce: OpenSSH 4.6 released In-Reply-To: <20070308215747.GA13218@gate.dtucker.net> References: <200703072310.l27NAMxP006468@cvs.openbsd.org> <20070308174130.GA23722@calimero.vinschen.de> <45F07132.3000909@zip.com.au> <20070308215747.GA13218@gate.dtucker.net> Message-ID: <20070308221151.GA13832@gate.dtucker.net> On Fri, Mar 09, 2007 at 08:57:47AM +1100, Darren Tucker wrote: > On Fri, Mar 09, 2007 at 07:25:22AM +1100, Darren Tucker wrote: [...] > > If you're using OpenSSL 0.9.8e you could try backing out this bit in > > openbsd-compat/openssl-compat.h: > > > > /* OpenSSL 0.9.8e returns cipher key len not context key len */ > > #if (OPENSSL_VERSION_NUMBER == 0x0090805fL) > > # define EVP_CIPHER_CTX_key_length(c) ((c)->key_len) > > #endif > > In fact, if you're using OpenSSL 0.9.8e I suggest you apply the following > patch to it, recompile everything and see if your problem persists. I'm pretty sure this is it: Cipher 1 blowfish uses EVP_CIPHER_CTX_key_length but doesn't include the header with the workaround. You can also try this (untested): Index: cipher-bf1.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/cipher-bf1.c,v retrieving revision 1.7 diff -u -p -r1.7 cipher-bf1.c --- cipher-bf1.c 1 Sep 2006 05:38:36 -0000 1.7 +++ cipher-bf1.c 8 Mar 2007 22:08:54 -0000 @@ -35,6 +35,8 @@ #include "xmalloc.h" #include "log.h" +#include "openbsd-compat/openssl-compat.h" + #if OPENSSL_VERSION_NUMBER < 0x00906000L #define SSH_OLD_EVP #endif -- 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 Sat Mar 10 02:00:15 2007 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 9 Mar 2007 16:00:15 +0100 Subject: Announce: OpenSSH 4.6 released In-Reply-To: <20070308215747.GA13218@gate.dtucker.net> References: <200703072310.l27NAMxP006468@cvs.openbsd.org> <20070308174130.GA23722@calimero.vinschen.de> <45F07132.3000909@zip.com.au> <20070308215747.GA13218@gate.dtucker.net> Message-ID: <20070309150015.GA27761@calimero.vinschen.de> On Mar 9 08:57, Darren Tucker wrote: > On Fri, Mar 09, 2007 at 07:25:22AM +1100, Darren Tucker wrote: > > Corinna Vinschen wrote: > [...] > > > $ ssh -1 somemachine > > > Disconnecting: Corrupted check bytes on input. > > > [...] > In fact, if you're using OpenSSL 0.9.8e I suggest you apply the following > patch to it, recompile everything and see if your problem persists. > > The symmetry of the problem (ie it works with itself but doesn't > interoperate) is the same as what I saw with the AES counter-mode > problems in OpenSSH bug #1291. > > That workaround above only helps for the bits of OpenSSH that use > EVP_CIPHER_CTX_key_length, it doesn't help where OpenSSL itself uses it, > which may be the case here. See bugzilla #1291 for details. > > Index: crypto/evp/evp_lib.c > =================================================================== > RCS file: /home/dtucker/src/security/openssl/cvs/openssl-cvs/openssl/crypto/evp/evp_lib.c,v > retrieving revision 1.10.2.1 > diff -u -p -r1.10.2.1 evp_lib.c > --- crypto/evp/evp_lib.c 29 Nov 2006 20:47:13 -0000 1.10.2.1 > +++ crypto/evp/evp_lib.c 3 Mar 2007 23:54:00 -0000 > @@ -225,7 +225,7 @@ int EVP_CIPHER_key_length(const EVP_CIPH > > int EVP_CIPHER_CTX_key_length(const EVP_CIPHER_CTX *ctx) > { > - return ctx->cipher->key_len; > + return ctx->key_len; > } > > int EVP_CIPHER_nid(const EVP_CIPHER *cipher) Thanks Darren, that did it! I first tried with just adding the missing #include to cipher-bf1.c, but that didn't help. Only by applying the above patch to openssl-0.9.8e I could connect to the Linux box using openssh-4.5p1 with openssl-0.9.8d. So, the bottom line is, I have to release a patched version of openssl. Oh well. Thanks again, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From bpsr77 at hotmail.com Mon Mar 12 20:25:25 2007 From: bpsr77 at hotmail.com (olle ollesson) Date: Mon, 12 Mar 2007 10:25:25 +0100 Subject: max cmd. length in sftp? Message-ID: Hi, I've found by empirical methods that there is a limit to command in sftp. In fact the sftp client hangs after 256 characters of input. I've tested on the following two implementations: 1) OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005 2) SSH Version Sun_SSH_1.0.1, protocol versions 1.5/2.0. Both behave in the same manner. The reason I'm askin is that we're having problems in solaris which allows filenames longer than 256 chars long. It's not currently possible (without the use of wildcards) to fetch these files. Is this a client implementation limitation or a limitation in the sftp/ssh specification? Thanks in advance. _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From cjs at cynic.net Mon Mar 12 23:06:19 2007 From: cjs at cynic.net (Curt Sampson) Date: Mon, 12 Mar 2007 21:06:19 +0900 (JST) Subject: Redefinition of _res in getrrsetbyname.c Message-ID: I've been trying to figure out why I can't seem to use SSHFP fingerprints delivered via DNSSEC, which led me to try to figure out why OpenSSH won't use DNSSEC on my NetBSD-4-branch platform. It turns out that around line 70 in openbsd-compat/getrrsetbyname.c, we have the following: /* to avoid conflicts where a platform already has _res */ #ifdef _res # undef _res #endif #define _res _compat_res struct __res_state _res; This defines a global, _compat_res, used only by OpenSSH (at least on NetBSD), and makes _res be that instead of the "real" _res (however that might be defined on various platforms). _res is used only in the getrrsetbyname function, which never initializes it in any way, but tries to act as if it's using the real _res. So it calls init_res every time: if ((_resp->options & RES_INIT) == 0 && res_init() == -1) { and it never turns on DNSSEC, even when RES_USE_EDNS0 is set, since it's checking for it in the wrong place: if (_resp->options & RES_USE_EDNS0) _resp->options |= RES_USE_DNSSEC; So, what's the fix for this? The first thing that comes to my mind is to rip out the redefinition; despite the comment in the changelog, any platform for which just using _res directly for what getrrsetbyname is doing doesn't work would appear to me to be rather broken. Please ensure that responses are cc'd directly to me, since I'm not on this list. cjs -- Curt Sampson +81 90 7737 2974 The power of accurate observation is commonly called cynicism by those who have not got it. --George Bernard Shaw From rapier at psc.edu Tue Mar 13 05:37:10 2007 From: rapier at psc.edu (Chris Rapier) Date: Mon, 12 Mar 2007 14:37:10 -0400 Subject: HPN patch now available for OpenSSH 4.6 Message-ID: <45F59DD6.9020200@psc.edu> The HPN patch set has been updated to work with OpenSSH4.6. This patch can help improve performance of bulk data transfers when using SSH, SCP, or SFTP. Please see http://www.psc.edu/networking/projects/hpn-ssh for more information. The patch is available from the above address or directly with http://www.psc.edu/networking/projects/hpn-ssh/openssh-4.6p1-hpn12v16.diff.gz If you have any questions or comments please feel free to contact me directly. Chris Rapier Pittsburgh Supercomputing Center Network Applications Engineer From sxw at inf.ed.ac.uk Tue Mar 13 08:49:18 2007 From: sxw at inf.ed.ac.uk (Simon Wilkinson) Date: Mon, 12 Mar 2007 21:49:18 +0000 Subject: GSSAPI Key Exchange Patch for OpenSSH 4.6p1 Message-ID: <67AAD2C2-DFD0-4F21-9495-BF1A5DF0A178@inf.ed.ac.uk> Hi, I'm pleased to announce the availability of my GSSAPI Key Exchange patch for OpenSSH 4.6p1. This patch adds support for the RFC4462 GSSAPI key exchange mechanisms to OpenSSH, along with some minor fixes for the GSSAPI code that is already in the tree. The patch implements: *) gss-group1-sha1-*, gss-group14-sha1-* and gss-gex-sha1-* key exchange mechanisms. (#1242) *) Support for the null host key type (#1242) *) Support for CCAPI credentials caches on Mac OS X (#1245) *) Support for better error handling when an authentication exchange fails due to server misconfiguration (#1244) *) Better error reporting when using a GSSAPI library which supports multiple mechanisms (#1220) *) Support for GSSAPI connections to hosts behind a round-robin load balancer (#1008) *) Support for GSSAPI connections to multi-homed hosts, where each interface has a unique name (#928) *) Cleanup of GSSAPI code seperation between client and server. (#1225) (bugzilla.mindrot.org bug numbers are in brackets) The only change since the last release is a minor code fix. As usual, the code is available from http://www.sxw.org.uk/computing/patches/openssh.html Cheers, Simon. From dtucker at zip.com.au Tue Mar 13 21:25:41 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 13 Mar 2007 21:25:41 +1100 Subject: Announce: OpenSSH 4.6 released In-Reply-To: <20070309150015.GA27761@calimero.vinschen.de> References: <200703072310.l27NAMxP006468@cvs.openbsd.org> <20070308174130.GA23722@calimero.vinschen.de> <45F07132.3000909@zip.com.au> <20070308215747.GA13218@gate.dtucker.net> <20070309150015.GA27761@calimero.vinschen.de> Message-ID: <20070313102541.GA9891@gate.dtucker.net> On Fri, Mar 09, 2007 at 04:00:15PM +0100, Corinna Vinschen wrote: > On Mar 9 08:57, Darren Tucker wrote: [...] > > Index: crypto/evp/evp_lib.c > > =================================================================== > > RCS file: /home/dtucker/src/security/openssl/cvs/openssl-cvs/openssl/crypto/evp/evp_lib.c,v > > retrieving revision 1.10.2.1 > > diff -u -p -r1.10.2.1 evp_lib.c > > --- crypto/evp/evp_lib.c 29 Nov 2006 20:47:13 -0000 1.10.2.1 > > +++ crypto/evp/evp_lib.c 3 Mar 2007 23:54:00 -0000 > > @@ -225,7 +225,7 @@ int EVP_CIPHER_key_length(const EVP_CIPH > > > > int EVP_CIPHER_CTX_key_length(const EVP_CIPHER_CTX *ctx) > > { > > - return ctx->cipher->key_len; > > + return ctx->key_len; > > } > > > > int EVP_CIPHER_nid(const EVP_CIPHER *cipher) > > Thanks Darren, that did it! I first tried with just adding the missing > #include to cipher-bf1.c, but that didn't help. Only by applying the > above patch to openssl-0.9.8e I could connect to the Linux box using > openssh-4.5p1 with openssl-0.9.8d. > > So, the bottom line is, I have to release a patched version of openssl. > Oh well. For the record, Juan Gallego pointed out that this affects the 3des cipher and not blowfish, so the following patch will fix it. I'd still fix openssl, though, otherwise it may bite again (if it's any consolation, since it's now a real function and not a macro nothing else needs to be recompiled :-) Index: cipher-3des1.c =================================================================== RCS file: /var/cvs/openssh/cipher-3des1.c,v retrieving revision 1.8 diff -u -p -r1.8 cipher-3des1.c --- cipher-3des1.c 1 Sep 2006 05:38:36 -0000 1.8 +++ cipher-3des1.c 13 Mar 2007 07:47:36 -0000 @@ -35,9 +35,7 @@ #include "xmalloc.h" #include "log.h" -#if OPENSSL_VERSION_NUMBER < 0x00906000L -#define SSH_OLD_EVP -#endif +#include "openbsd-compat/openssl-compat.h" /* * This is used by SSH1: Index: cipher-bf1.c =================================================================== RCS file: /var/cvs/openssh/cipher-bf1.c,v retrieving revision 1.7 diff -u -p -r1.7 cipher-bf1.c --- cipher-bf1.c 1 Sep 2006 05:38:36 -0000 1.7 +++ cipher-bf1.c 13 Mar 2007 07:47:36 -0000 @@ -35,9 +35,7 @@ #include "xmalloc.h" #include "log.h" -#if OPENSSL_VERSION_NUMBER < 0x00906000L -#define SSH_OLD_EVP -#endif +#include "openbsd-compat/openssl-compat.h" /* * SSH1 uses a variation on Blowfish, all bytes must be swapped before -- 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 marcel.svitalsky at mpsv.cz Wed Mar 14 22:29:15 2007 From: marcel.svitalsky at mpsv.cz (=?UTF-8?B?TWFyY2VsIFN2aXRhbHNrw70=?=) Date: Wed, 14 Mar 2007 12:29:15 +0100 Subject: make tests fails Message-ID: <45F7DC8B.8050408@mpsv.cz> Hi, building openssh 4.6p1 from source I encountered this during make tests: """ run test agent.sh ... ssh_exchange_identification: Connection closed by remote host agent fwd proto 1 failed (exit code 0) ssh_exchange_identification: Connection closed by remote host agent fwd proto 2 failed (exit code 0) failed simple agent test make[1]: *** [t-exec] Error 1 make[1]: Leaving directory `/var/tmpmem/openssh-4.6p1/openssh-4.6p1/regress' make: *** [tests] Error 2 """ After removing the test "agent.sh" from the Makefile in the regress directory all other tests passed OK and instaled SSH works fine. With previous version 4.5p1 the test "agent.sh" passed OK. Build was made on RH7.3, kernel 2.4.20-28.7, gcc 3.4.6, OpenSSL 0.9.8e. It was configured with only prefix and sysconfdir set, everything else remained default. Marcel Svitalsk? -- GPG public key http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD98EC83A fingerprint: 3BEB 4658 A998 B9B3 3476 AD64 EF87 D0A5 D98E C83A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070314/a26296d3/attachment.bin From opensshbugs at fjarlq.com Thu Mar 15 05:53:09 2007 From: opensshbugs at fjarlq.com (Matt Day) Date: Wed, 14 Mar 2007 12:53:09 -0600 Subject: sshd gets stuck: select() in packet_read_seqnr waits indefinitely Message-ID: <20070314185309.GA40932@fjarlq.com> Dear OpenSSH Portable sshd developers, I'm having a problem where sshd login sessions are occasionally (as often as once a day) getting stuck indefinitely. I enabled debug messages and got a backtrace of a stuck sshd, and I think I've found the bug. I wanted to run it by the list once before filing. sshd version: OpenSSH_4.2p1 FreeBSD-20050903, OpenSSL 0.9.7e-p1 25 Oct 2004 Uncommented lines (ie. nondefault settings) in sshd_config: LogLevel DEBUG ClientAliveInterval 90 Subsystem sftp /usr/libexec/sftp-server SSH client: PuTTY version 0.58, default settings OS/HW: FreeBSD 6.1-RELEASE running on 64-bit x86 ("amd64" platform) Executive summary: The select() in packet_read_seqnr() waits indefinitely, resulting in stuck SSH sessions when networking problems interfere with key exchange. Would like to be able to set a timeout there, or send SSH keepalives during key exchange. Periodically (every 60 minutes) the SSH client initiates rekeying via key exchange. Here's an example of a successful rekeying: Mar 11 19:02:35 SSH2_MSG_KEXINIT received Mar 11 19:02:35 SSH2_MSG_KEXINIT sent Mar 11 19:02:35 kex: client->server aes256-ctr hmac-sha1 none Mar 11 19:02:35 kex: server->client aes256-ctr hmac-sha1 none Mar 11 19:02:35 SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received Mar 11 19:02:35 SSH2_MSG_KEX_DH_GEX_GROUP sent Mar 11 19:02:35 expecting SSH2_MSG_KEX_DH_GEX_INIT Mar 11 19:02:38 SSH2_MSG_KEX_DH_GEX_REPLY sent Mar 11 19:02:38 set_newkeys: rekeying Mar 11 19:02:38 SSH2_MSG_NEWKEYS sent Mar 11 19:02:38 expecting SSH2_MSG_NEWKEYS Mar 11 19:02:38 set_newkeys: rekeying Mar 11 19:02:38 SSH2_MSG_NEWKEYS received In the failure case, sshd gets stuck during key exchange. The SSH session had been going fine for many hours, and then these were the last messages it logged: Mar 11 20:02:38 SSH2_MSG_KEXINIT received Mar 11 20:02:38 SSH2_MSG_KEXINIT sent Mar 11 20:02:38 kex: client->server aes256-ctr hmac-sha1 none Mar 11 20:02:38 kex: server->client aes256-ctr hmac-sha1 none Mar 11 20:02:38 SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received Mar 11 20:02:38 SSH2_MSG_KEX_DH_GEX_GROUP sent Mar 11 20:02:38 expecting SSH2_MSG_KEX_DH_GEX_INIT The user was idle when this happened, but had a program running that was generating output. That program became tty-blocked after about 30 minutes, presumably because sshd wasn't draining its output, and that's when I noticed the user's sshd was stuck and got a backtrace: (gdb) where #0 0x.. in select () from /lib/libc.so.6 #1 0x.. in packet_read_seqnr () from /usr/lib/libssh.so.3 #2 0x.. in packet_read () from /usr/lib/libssh.so.3 #3 0x.. in packet_read_expect () from /usr/lib/libssh.so.3 #4 0x.. in kexgex_server (kex=0x538900) at kexgexs.c:99 #5 0x.. in kex_setup () from /usr/lib/libssh.so.3 #6 0x.. in kex_input_kexinit () from /usr/lib/libssh.so.3 #7 0x.. in dispatch_run () from /usr/lib/libssh.so.3 #8 0x.. in process_buffered_input_packets () at serverloop.c:475 #9 0x.. in server_loop2 (authctxt=0x4) at serverloop.c:760 #10 0x.. in do_authenticated2 (authctxt=0x4) at session.c:2456 #11 0x.. in do_authenticated (authctxt=0x53a400) at session.c:227 #12 0x.. in main at sshd.c:1749 This backtrace agrees with the debug messages: it's in kexgex_server(), calling packet_read_expect(SSH2_MSG_KEX_DH_GEX_INIT), which ultimately calls select() from packet_read_seqnr(). The select call in packet_read_seqnr passes NULL for a timeout, meaning it will wait forever. That explains why the comment above it says "Note that no other data is processed until this returns, so this function should not be used during the interactive session." But, this was an interactive session. I've set ClientAliveInterval in sshd_config so that SSH sessions die in a timely manner when networking problems arise, but the keepalive is apparently not sent during key exchange. The default TCP keepalive on FreeBSD is unhelpful here; it only kicks in after 2 hours, and I need stuck SSH sessions to die a lot sooner. I want to keep the FreeBSD TCP keepalive defaults. Would it be possible for the select() in packet_read_seqnr to use an optional timeout? Similarly, I believe the select() in packet_write_wait has the same problem. Upon timeout, it would be fine with me if the session died with an error logged. Alternatively, if SSH keepalives were sent during key exchange, that would suffice. Thanks for reading, and thanks for making OpenSSH. I've been a happy user for many years now! Matt Day From dtucker at zip.com.au Thu Mar 15 11:14:16 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 15 Mar 2007 11:14:16 +1100 Subject: sshd gets stuck: select() in packet_read_seqnr waits indefinitely In-Reply-To: <20070314185309.GA40932@fjarlq.com> References: <20070314185309.GA40932@fjarlq.com> Message-ID: <20070315001416.GA28880@gate.dtucker.net> On Wed, Mar 14, 2007 at 12:53:09PM -0600, Matt Day wrote: > Dear OpenSSH Portable sshd developers, > > I'm having a problem where sshd login sessions are occasionally > (as often as once a day) getting stuck indefinitely. I enabled debug > messages and got a backtrace of a stuck sshd, and I think I've found > the bug. I wanted to run it by the list once before filing. [...] > The select() in packet_read_seqnr() waits indefinitely, resulting > in stuck SSH sessions when networking problems interfere with > key exchange. Would like to be able to set a timeout there, or > send SSH keepalives during key exchange. [...] > The select call in packet_read_seqnr passes NULL for a timeout, > meaning it will wait forever. That explains why the comment above > it says "Note that no other data is processed until this returns, > so this function should not be used during the interactive session." > But, this was an interactive session. > > I've set ClientAliveInterval in sshd_config so that SSH sessions > die in a timely manner when networking problems arise, but the > keepalive is apparently not sent during key exchange. The default > TCP keepalive on FreeBSD is unhelpful here; it only kicks in after > 2 hours, and I need stuck SSH sessions to die a lot sooner. I want > to keep the FreeBSD TCP keepalive defaults. > > Would it be possible for the select() in packet_read_seqnr to use > an optional timeout? Similarly, I believe the select() in > packet_write_wait has the same problem. Upon timeout, it would be > fine with me if the session died with an error logged. You could try the attached patch. The timeout should perhaps be ClientAliveInterval * ClientAliveCountMax, (though you'd need to be wary of integer overflow). > Alternatively, > if SSH keepalives were sent during key exchange, that would suffice. You're not allowed to send most types of packets (this would include keepalives) once you've initiated a key exchange until it completes. Index: packet.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/packet.c,v retrieving revision 1.146 diff -u -p -r1.146 packet.c --- packet.c 17 Jan 2007 00:00:14 -0000 1.146 +++ packet.c 14 Mar 2007 23:48:23 -0000 @@ -136,6 +136,10 @@ static int server_side = 0; /* Set to true if we are authenticated. */ static int after_authentication = 0; +/* Set to the maximum time that we will wait for (or to send) a packet */ +static struct timeval packet_wait_tv; +static struct timeval *packet_wait_tvp = NULL; + /* Session key information for Encryption and MAC */ Newkeys *newkeys[MODE_MAX]; static struct packet_state { @@ -166,7 +170,7 @@ TAILQ_HEAD(, packet) outgoing; * packet_set_encryption_key is called. */ void -packet_set_connection(int fd_in, int fd_out) +packet_set_connection(int fd_in, int fd_out, int timeout) { Cipher *none = cipher_by_name("none"); @@ -187,6 +191,15 @@ packet_set_connection(int fd_in, int fd_ buffer_init(&incoming_packet); TAILQ_INIT(&outgoing); } + + if (timeout == 0) + packet_wait_tvp = NULL; + else { + packet_wait_tv.tv_sec = timeout; + packet_wait_tv.tv_usec = 0; + packet_wait_tvp = &packet_wait_tv; + } + } /* Returns 1 if remote host is connected via socket, 0 if not. */ @@ -923,7 +936,8 @@ packet_read_seqnr(u_int32_t *seqnr_p) FD_SET(connection_in, setp); /* Wait for some data to arrive. */ - while (select(connection_in + 1, setp, NULL, NULL, NULL) == -1 && + while (select(connection_in + 1, setp, NULL, NULL, + packet_wait_tvp) == -1 && (errno == EAGAIN || errno == EINTR)) ; @@ -1449,7 +1463,8 @@ packet_write_wait(void) memset(setp, 0, howmany(connection_out + 1, NFDBITS) * sizeof(fd_mask)); FD_SET(connection_out, setp); - while (select(connection_out + 1, NULL, setp, NULL, NULL) == -1 && + while (select(connection_out + 1, NULL, setp, NULL, + packet_wait_tvp) == -1 && (errno == EAGAIN || errno == EINTR)) ; packet_write_poll(); Index: packet.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/packet.h,v retrieving revision 1.47 diff -u -p -r1.47 packet.h --- packet.h 26 Mar 2006 03:30:02 -0000 1.47 +++ packet.h 14 Mar 2007 23:48:38 -0000 @@ -20,7 +20,7 @@ #include -void packet_set_connection(int, int); +void packet_set_connection(int, int, int); void packet_set_nonblocking(void); int packet_get_connection_in(void); int packet_get_connection_out(void); Index: ssh-keyscan.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/ssh-keyscan.c,v retrieving revision 1.91 diff -u -p -r1.91 ssh-keyscan.c --- ssh-keyscan.c 23 Oct 2006 17:01:16 -0000 1.91 +++ ssh-keyscan.c 14 Mar 2007 23:50:23 -0000 @@ -358,7 +358,7 @@ keygrab_ssh2(con *c) { int j; - packet_set_connection(c->c_fd, c->c_fd); + packet_set_connection(c->c_fd, c->c_fd, timeout); enable_compat20(); myproposal[PROPOSAL_SERVER_HOST_KEY_ALGS] = c->c_keytype == KT_DSA? "ssh-dss": "ssh-rsa"; Index: sshconnect.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/sshconnect.c,v retrieving revision 1.171 diff -u -p -r1.171 sshconnect.c --- sshconnect.c 23 Oct 2006 17:02:24 -0000 1.171 +++ sshconnect.c 14 Mar 2007 23:46:27 -0000 @@ -157,7 +157,7 @@ ssh_proxy_connect(const char *host, u_sh xfree(command_string); /* Set the connection file descriptors. */ - packet_set_connection(pout[0], pin[1]); + packet_set_connection(pout[0], pin[1], options.server_alive_interval); /* Indicate OK return */ return 0; @@ -385,7 +385,7 @@ ssh_connect(const char *host, struct soc error("setsockopt SO_KEEPALIVE: %.100s", strerror(errno)); /* Set the connection. */ - packet_set_connection(sock, sock); + packet_set_connection(sock, sock, options.server_alive_interval); return 0; } Index: sshd.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/sshd.c,v retrieving revision 1.362 diff -u -p -r1.362 sshd.c --- sshd.c 25 Feb 2007 09:37:22 -0000 1.362 +++ sshd.c 14 Mar 2007 23:45:09 -0000 @@ -1707,7 +1707,7 @@ main(int ac, char **av) * Register our connection. This turns encryption off because we do * not have a key. */ - packet_set_connection(sock_in, sock_out); + packet_set_connection(sock_in, sock_out, options.client_alive_interval); packet_set_server(); /* Set SO_KEEPALIVE if requested. */ -- 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 opensshbugs at fjarlq.com Thu Mar 15 12:12:09 2007 From: opensshbugs at fjarlq.com (Matt Day) Date: Wed, 14 Mar 2007 19:12:09 -0600 Subject: sshd gets stuck: select() in packet_read_seqnr waits indefinitely In-Reply-To: <20070315001416.GA28880@gate.dtucker.net> References: <20070314185309.GA40932@fjarlq.com> <20070315001416.GA28880@gate.dtucker.net> Message-ID: <20070315011208.GA48513@fjarlq.com> On Thu, Mar 15, 2007 at 11:14:16AM +1100, Darren Tucker wrote: > You could try the attached patch. Oh, cool...thanks for the fast response! I have a question about the patch. With it applied, packet_read_seqnr now reads: /* Wait for some data to arrive. */ while (select(connection_in + 1, setp, NULL, NULL, packet_wait_tvp) == -1 && (errno == EAGAIN || errno == EINTR)) ; /* Read data from the socket. */ len = read(connection_in, buf, sizeof(buf)); ... On FreeBSD, select() will return 0 upon timeout, so packet_read_seqnr would end up calling read() even though the descriptor isn't ready, so I think it would block. Similarly, I don't see how a select() timeout would cause packet_write_wait to abort. Instead it would call packet_write_poll (which calls write()) even though the descriptor isn't ready for writing. Am I missing something? Thanks, Matt From dtucker at zip.com.au Thu Mar 15 13:43:47 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 15 Mar 2007 13:43:47 +1100 Subject: sshd gets stuck: select() in packet_read_seqnr waits indefinitely In-Reply-To: <20070315011208.GA48513@fjarlq.com> References: <20070314185309.GA40932@fjarlq.com> <20070315001416.GA28880@gate.dtucker.net> <20070315011208.GA48513@fjarlq.com> Message-ID: <20070315024347.GA10841@gate.dtucker.net> On Wed, Mar 14, 2007 at 07:12:09PM -0600, Matt Day wrote: > On Thu, Mar 15, 2007 at 11:14:16AM +1100, Darren Tucker wrote: > > You could try the attached patch. > > Oh, cool...thanks for the fast response! > > I have a question about the patch. With it applied, packet_read_seqnr > now reads: > > /* Wait for some data to arrive. */ > while (select(connection_in + 1, setp, NULL, NULL, > packet_wait_tvp) == -1 && > (errno == EAGAIN || errno == EINTR)) > ; > > /* Read data from the socket. */ > len = read(connection_in, buf, sizeof(buf)); > ... > On FreeBSD, select() will return 0 upon timeout, so packet_read_seqnr > would end up calling read() even though the descriptor isn't ready, > so I think it would block. The descriptor is O_NONBLOCK (set by packet_set_nonblocking()), so the read() should return -1 with errno == EWOULDBLOCK or EAGAIN. > Similarly, I don't see how a select() timeout would cause packet_write_wait > to abort. Instead it would call packet_write_poll (which calls write()) > even though the descriptor isn't ready for writing. Am I missing something? The next couple of lines after the ones you quoted are: if (len == 0) { logit("Connection closed by %.200s", get_remote_ipaddr()); cleanup_exit(255); } if (len < 0) fatal("Read from socket failed: %.100s", strerror(errno)); len should be -1 in the case of a timeout, so that should kill the connection (I've not tested it). You could test for EWOULDBLOCK or EAGAIN and provide a more informative error message, though. -- 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 opensshbugs at fjarlq.com Thu Mar 15 13:59:04 2007 From: opensshbugs at fjarlq.com (Matt Day) Date: Wed, 14 Mar 2007 20:59:04 -0600 Subject: sshd gets stuck: select() in packet_read_seqnr waits indefinitely In-Reply-To: <20070315024347.GA10841@gate.dtucker.net> References: <20070314185309.GA40932@fjarlq.com> <20070315001416.GA28880@gate.dtucker.net> <20070315011208.GA48513@fjarlq.com> <20070315024347.GA10841@gate.dtucker.net> Message-ID: <20070315025904.GA50787@fjarlq.com> On Thu, Mar 15, 2007 at 01:43:47PM +1100, Darren Tucker wrote: > The descriptor is O_NONBLOCK (set by packet_set_nonblocking()), so the > read() should return -1 with errno == EWOULDBLOCK or EAGAIN. > > [..] > > You could test for EWOULDBLOCK or EAGAIN and provide a more informative > error message, though. OK, thanks, I didn't notice that. Yeah, it might be useful to log a debug message there. It would also seem safer and more clear to handle the timeout case explicitly. Or perhaps a comment documenting the O_NONBLOCK assumption. What about the timeout handling in packet_write_wait? Do you really want to proceed with the write() and then possibly loop back around to the select() call? Thanks, Matt From dtucker at zip.com.au Thu Mar 15 14:22:13 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 15 Mar 2007 14:22:13 +1100 Subject: sshd gets stuck: select() in packet_read_seqnr waits indefinitely In-Reply-To: <20070315025904.GA50787@fjarlq.com> References: <20070314185309.GA40932@fjarlq.com> <20070315001416.GA28880@gate.dtucker.net> <20070315011208.GA48513@fjarlq.com> <20070315024347.GA10841@gate.dtucker.net> <20070315025904.GA50787@fjarlq.com> Message-ID: <20070315032213.GA12369@gate.dtucker.net> On Wed, Mar 14, 2007 at 08:59:04PM -0600, Matt Day wrote: > What about the timeout handling in packet_write_wait? Do you really > want to proceed with the write() and then possibly loop back around > to the select() call? Yeah, that's a problem. On platforms that return EAGAIN rather than EWOULDBLOCK it'll just spin through packet_write_poll() repeatedly. Probably best to capture the return from select() explicitly test for a timeout. -- 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 Thu Mar 15 16:52:42 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 15 Mar 2007 16:52:42 +1100 Subject: sshd gets stuck: select() in packet_read_seqnr waits indefinitely In-Reply-To: <20070315032213.GA12369@gate.dtucker.net> References: <20070314185309.GA40932@fjarlq.com> <20070315001416.GA28880@gate.dtucker.net> <20070315011208.GA48513@fjarlq.com> <20070315024347.GA10841@gate.dtucker.net> <20070315025904.GA50787@fjarlq.com> <20070315032213.GA12369@gate.dtucker.net> Message-ID: <20070315055242.GA15006@gate.dtucker.net> On Thu, Mar 15, 2007 at 02:22:13PM +1100, Darren Tucker wrote: > On Wed, Mar 14, 2007 at 08:59:04PM -0600, Matt Day wrote: > > What about the timeout handling in packet_write_wait? Do you really > > want to proceed with the write() and then possibly loop back around > > to the select() call? > > Yeah, that's a problem. On platforms that return EAGAIN rather than > EWOULDBLOCK it'll just spin through packet_write_poll() repeatedly. > > Probably best to capture the return from select() explicitly test for > a timeout. Like so (still untested): Index: packet.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/packet.c,v retrieving revision 1.146 diff -u -p -r1.146 packet.c --- packet.c 17 Jan 2007 00:00:14 -0000 1.146 +++ packet.c 15 Mar 2007 05:51:19 -0000 @@ -136,6 +136,10 @@ static int server_side = 0; /* Set to true if we are authenticated. */ static int after_authentication = 0; +/* Set to the maximum time that we will wait to send or receive a packet */ +static struct timeval packet_wait_tv; +static struct timeval *packet_wait_tvp = NULL; + /* Session key information for Encryption and MAC */ Newkeys *newkeys[MODE_MAX]; static struct packet_state { @@ -189,6 +193,21 @@ packet_set_connection(int fd_in, int fd_ } } +void +packet_set_timeout(int timeout, int count) +{ + if (timeout == 0 && count == 0) { + packet_wait_tvp = NULL; + return; + } + if (LONG_MAX / count < timeout) + packet_wait_tv.tv_sec = LONG_MAX; + else + packet_wait_tv.tv_sec = timeout * count; + packet_wait_tv.tv_usec = 0; + packet_wait_tvp = &packet_wait_tv; +} + /* Returns 1 if remote host is connected via socket, 0 if not. */ int @@ -888,7 +907,7 @@ packet_send(void) int packet_read_seqnr(u_int32_t *seqnr_p) { - int type, len; + int type, len, ret; fd_set *setp; char buf[8192]; DBG(debug("packet_read()")); @@ -923,10 +942,15 @@ packet_read_seqnr(u_int32_t *seqnr_p) FD_SET(connection_in, setp); /* Wait for some data to arrive. */ - while (select(connection_in + 1, setp, NULL, NULL, NULL) == -1 && + while ((ret = select(connection_in + 1, setp, NULL, NULL, + packet_wait_tvp)) == -1 && (errno == EAGAIN || errno == EINTR)) ; - + if (ret == 0) { + logit("Connection to %.200s timed out", + get_remote_ipaddr()); + cleanup_exit(255); + } /* Read data from the socket. */ len = read(connection_in, buf, sizeof(buf)); if (len == 0) { @@ -1441,6 +1465,7 @@ void packet_write_wait(void) { fd_set *setp; + int ret; setp = (fd_set *)xcalloc(howmany(connection_out + 1, NFDBITS), sizeof(fd_mask)); @@ -1449,9 +1474,15 @@ packet_write_wait(void) memset(setp, 0, howmany(connection_out + 1, NFDBITS) * sizeof(fd_mask)); FD_SET(connection_out, setp); - while (select(connection_out + 1, NULL, setp, NULL, NULL) == -1 && + while ((ret = select(connection_out + 1, NULL, setp, NULL, + packet_wait_tvp)) == -1 && (errno == EAGAIN || errno == EINTR)) ; + if (ret == 0) { + logit("Connection to %.200s timed out", + get_remote_ipaddr()); + cleanup_exit(255); + } packet_write_poll(); } xfree(setp); Index: packet.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/packet.h,v retrieving revision 1.47 diff -u -p -r1.47 packet.h --- packet.h 26 Mar 2006 03:30:02 -0000 1.47 +++ packet.h 15 Mar 2007 04:01:39 -0000 @@ -21,6 +21,7 @@ #include void packet_set_connection(int, int); +void packet_set_timeout(int, int); void packet_set_nonblocking(void); int packet_get_connection_in(void); int packet_get_connection_out(void); Index: sshconnect.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/sshconnect.c,v retrieving revision 1.171 diff -u -p -r1.171 sshconnect.c --- sshconnect.c 23 Oct 2006 17:02:24 -0000 1.171 +++ sshconnect.c 15 Mar 2007 04:04:50 -0000 @@ -158,6 +158,8 @@ ssh_proxy_connect(const char *host, u_sh /* Set the connection file descriptors. */ packet_set_connection(pout[0], pin[1]); + packet_set_timeout(options.server_alive_interval, + options.server_alive_count_max); /* Indicate OK return */ return 0; @@ -386,6 +388,8 @@ ssh_connect(const char *host, struct soc /* Set the connection. */ packet_set_connection(sock, sock); + packet_set_timeout(options.server_alive_interval, + options.server_alive_count_max); return 0; } Index: sshd.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/sshd.c,v retrieving revision 1.362 diff -u -p -r1.362 sshd.c --- sshd.c 25 Feb 2007 09:37:22 -0000 1.362 +++ sshd.c 15 Mar 2007 03:58:53 -0000 @@ -1708,6 +1708,8 @@ main(int ac, char **av) * not have a key. */ packet_set_connection(sock_in, sock_out); + packet_set_timeout(options.client_alive_interval, + options.client_alive_count_max); packet_set_server(); /* Set SO_KEEPALIVE if requested. */ -- 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 opensshbugs at fjarlq.com Thu Mar 15 19:40:12 2007 From: opensshbugs at fjarlq.com (Matt Day) Date: Thu, 15 Mar 2007 02:40:12 -0600 Subject: sshd gets stuck: select() in packet_read_seqnr waits indefinitely In-Reply-To: <20070315055242.GA15006@gate.dtucker.net> References: <20070314185309.GA40932@fjarlq.com> <20070315001416.GA28880@gate.dtucker.net> <20070315011208.GA48513@fjarlq.com> <20070315024347.GA10841@gate.dtucker.net> <20070315025904.GA50787@fjarlq.com> <20070315032213.GA12369@gate.dtucker.net> <20070315055242.GA15006@gate.dtucker.net> Message-ID: <20070315084012.GA58996@fjarlq.com> On Thu, Mar 15, 2007 at 04:52:42PM +1100, Darren Tucker wrote: > Like so (still untested): > > [..] Awesome, thanks! I applied the patch and ran into one problem during testing: outbound ssh connections immediately received the new "timed out" error. The problem was in packet_set_timeout: packet_wait_tvp was only getting set to NULL when *both* timeout and count were 0. The default is interval=0 count=3, so it used the timeval with tv_sec = 0. I fixed that (use || instead of && in packet_set_timeout) and also made the two new "timed out" error messages unique. That might be handy someday if one is wondering if it timed out waiting to read or to write (which I found myself wondering while debugging this). I have installed these changes on my server and will let you know when I get confirmation in my logfile that the fix is working. Thank you very much! Matt =================================================================== diff -u -p packet.c.orig packet.c --- packet.c.orig Sun Sep 11 09:50:34 2005 +++ packet.c Thu Mar 15 01:08:22 2007 @@ -122,6 +122,10 @@ static int server_side = 0; /* Set to true if we are authenticated. */ static int after_authentication = 0; +/* Set to the maximum time that we will wait to send or receive a packet */ +static struct timeval packet_wait_tv; +static struct timeval *packet_wait_tvp = NULL; + /* Session key information for Encryption and MAC */ Newkeys *newkeys[MODE_MAX]; static struct packet_state { @@ -175,6 +179,21 @@ packet_set_connection(int fd_in, int fd_ } } +void +packet_set_timeout(int timeout, int count) +{ + if (timeout == 0 || count == 0) { + packet_wait_tvp = NULL; + return; + } + if (LONG_MAX / count < timeout) + packet_wait_tv.tv_sec = LONG_MAX; + else + packet_wait_tv.tv_sec = timeout * count; + packet_wait_tv.tv_usec = 0; + packet_wait_tvp = &packet_wait_tv; +} + /* Returns 1 if remote host is connected via socket, 0 if not. */ int @@ -863,7 +882,7 @@ packet_send(void) int packet_read_seqnr(u_int32_t *seqnr_p) { - int type, len; + int type, len, ret; fd_set *setp; char buf[8192]; DBG(debug("packet_read()")); @@ -898,10 +917,15 @@ packet_read_seqnr(u_int32_t *seqnr_p) FD_SET(connection_in, setp); /* Wait for some data to arrive. */ - while (select(connection_in + 1, setp, NULL, NULL, NULL) == -1 && + while ((ret = select(connection_in + 1, setp, NULL, NULL, + packet_wait_tvp)) == -1 && (errno == EAGAIN || errno == EINTR)) ; - + if (ret == 0) { + logit("Connection to %.200s timed out while waiting to read", + get_remote_ipaddr()); + cleanup_exit(255); + } /* Read data from the socket. */ len = read(connection_in, buf, sizeof(buf)); if (len == 0) { @@ -1411,6 +1435,7 @@ void packet_write_wait(void) { fd_set *setp; + int ret; setp = (fd_set *)xmalloc(howmany(connection_out + 1, NFDBITS) * sizeof(fd_mask)); @@ -1419,9 +1444,15 @@ packet_write_wait(void) memset(setp, 0, howmany(connection_out + 1, NFDBITS) * sizeof(fd_mask)); FD_SET(connection_out, setp); - while (select(connection_out + 1, NULL, setp, NULL, NULL) == -1 && + while ((ret = select(connection_out + 1, NULL, setp, NULL, + packet_wait_tvp)) == -1 && (errno == EAGAIN || errno == EINTR)) ; + if (ret == 0) { + logit("Connection to %.200s timed out while waiting to write", + get_remote_ipaddr()); + cleanup_exit(255); + } packet_write_poll(); } xfree(setp); =================================================================== diff -u -p packet.h.orig packet.h --- packet.h.orig Sun Sep 11 09:50:34 2005 +++ packet.h Thu Mar 15 00:05:29 2007 @@ -19,6 +19,7 @@ #include void packet_set_connection(int, int); +void packet_set_timeout(int, int); void packet_set_nonblocking(void); int packet_get_connection_in(void); int packet_get_connection_out(void); =================================================================== diff -u -p sshconnect.c.orig sshconnect.c --- sshconnect.c.orig Sun Sep 11 09:50:35 2005 +++ sshconnect.c Thu Mar 15 00:05:29 2007 @@ -139,6 +139,8 @@ ssh_proxy_connect(const char *host, u_sh /* Set the connection file descriptors. */ packet_set_connection(pout[0], pin[1]); + packet_set_timeout(options.server_alive_interval, + options.server_alive_count_max); /* Indicate OK return */ return 0; @@ -381,6 +383,8 @@ ssh_connect(const char *host, struct soc /* Set the connection. */ packet_set_connection(sock, sock); + packet_set_timeout(options.server_alive_interval, + options.server_alive_count_max); return 0; } =================================================================== diff -u -p sshd.c.orig sshd.c --- sshd.c.orig Sun Sep 11 09:50:35 2005 +++ sshd.c Thu Mar 15 00:05:29 2007 @@ -1643,6 +1643,8 @@ main(int ac, char **av) * not have a key. */ packet_set_connection(sock_in, sock_out); + packet_set_timeout(options.client_alive_interval, + options.client_alive_count_max); packet_set_server(); /* Set SO_KEEPALIVE if requested. */ From hazards at musc.edu Tue Mar 20 08:45:46 2007 From: hazards at musc.edu (Starr Hazard) Date: Mon, 19 Mar 2007 16:45:46 -0500 Subject: Security Update from MAC breaks ssh -X Message-ID: <22083437.1174322746@22gdellstarr.csb.musc.edu> Folks, This morning I downloaded and installed a security update for my MAC G5. I am running MAC OSX 10.3.9. Friday March 16 I was able to ssh -X me at targetcpu and launch my application this morning March 19 I get this error: X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 20 (X_GetProperty) Atom id in failed request: 0x25 Serial number of failed request: 309 Current serial number in output stream: 309 I can get an xclock window to open but the GUI for my application is not able to launch. I can work around this by setting xhost on the mac, ssh to remote machine, setenv DISPLAY and launching the application. Can you suggest some reasons why this current fix broke my ssh -X trick? Thanks, From dtucker at zip.com.au Tue Mar 20 09:25:49 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 20 Mar 2007 09:25:49 +1100 Subject: Security Update from MAC breaks ssh -X In-Reply-To: <22083437.1174322746@22gdellstarr.csb.musc.edu> References: <22083437.1174322746@22gdellstarr.csb.musc.edu> Message-ID: <45FF0DED.7090402@zip.com.au> Starr Hazard wrote: > Folks, > > This morning I downloaded and installed a security update for my MAC G5. I > am running MAC OSX 10.3.9. And that replaced which version of OpenSSH with which newer version of OpenSSH? > Friday March 16 I was able to > > ssh -X me at targetcpu > > and launch my application > > this morning March 19 I get this error: > > X Error of failed request: BadAtom (invalid Atom parameter) > Major opcode of failed request: 20 (X_GetProperty) > Atom id in failed request: 0x25 > Serial number of failed request: 309 > Current serial number in output stream: 309 From http://www.openssh.com/faq.html#3.13 [quote] 3.13 - I upgraded to OpenSSH 3.8 and some X11 programs stopped working. As documented in the 3.8 release notes, ssh will now use untrusted X11 cookies by default. The previous behaviour can be restored by setting ForwardX11Trusted yes in ssh_config. Possible symptoms include: BadWindow (invalid Window parameter) BadAccess (attempt to access private resource denied) X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 20 (X_GetProperty) [/quote] > I can get an xclock window to open but the GUI for my application is not > able to launch. > > I can work around this by setting xhost on the mac, ssh to remote > machine, setenv DISPLAY and launching the application. > > Can you suggest some reasons why this current fix broke my > > ssh -X trick? This has been the default for years, I don't know why you're only seeing problems now (unless Apple used to change the default in their packages and now don't?) -- 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 william at 25thandClement.com Tue Mar 20 10:26:48 2007 From: william at 25thandClement.com (William Ahern) Date: Mon, 19 Mar 2007 16:26:48 -0700 Subject: Security Update from MAC breaks ssh -X In-Reply-To: <45FF0DED.7090402@zip.com.au> References: <22083437.1174322746@22gdellstarr.csb.musc.edu> <45FF0DED.7090402@zip.com.au> Message-ID: <20070319232648.GA15156@wilbur.25thandClement.com> On Tue, Mar 20, 2007 at 09:25:49AM +1100, Darren Tucker wrote: > This has been the default for years, I don't know why you're only seeing > problems now (unless Apple used to change the default in their packages > and now don't?) For one thing, Apple hasn't updated their version of OpenSSH for years. Which patches they backport is anyone's guess. They certainly haven't backported control socket mastering. Likewise for OpenSSL. Basically, Apple ceased all Unix environment development the moment OS X shipped. Soon porting Unix apps to OS X will be as fun as to Microsoft's POSIX interface. From djm at mindrot.org Tue Mar 20 10:32:48 2007 From: djm at mindrot.org (Damien Miller) Date: Tue, 20 Mar 2007 10:32:48 +1100 (EST) Subject: Security Update from MAC breaks ssh -X In-Reply-To: <20070319232648.GA15156@wilbur.25thandClement.com> References: <22083437.1174322746@22gdellstarr.csb.musc.edu> <45FF0DED.7090402@zip.com.au> <20070319232648.GA15156@wilbur.25thandClement.com> Message-ID: On Mon, 19 Mar 2007, William Ahern wrote: > On Tue, Mar 20, 2007 at 09:25:49AM +1100, Darren Tucker wrote: > > This has been the default for years, I don't know why you're only seeing > > problems now (unless Apple used to change the default in their packages > > and now don't?) > > For one thing, Apple hasn't updated their version of OpenSSH for years. > Which patches they backport is anyone's guess. They certainly haven't > backported control socket mastering. ... and I don't recall them having contributed anything back either. Apple ship patches on top of OpenSSH that change its behaviour in other ways too. I just compile my own OpenSSH on for OS X and use that, this way I get a recent and well-behaved version. -d From tsi at ualberta.ca Tue Mar 20 11:37:53 2007 From: tsi at ualberta.ca (Marc Aurele La France) Date: Mon, 19 Mar 2007 18:37:53 -0600 (Mountain Daylight Time) Subject: Security Update from MAC breaks ssh -X In-Reply-To: <22083437.1174322746@22gdellstarr.csb.musc.edu> References: <22083437.1174322746@22gdellstarr.csb.musc.edu> Message-ID: On Mon, 19 Mar 2007, Starr Hazard wrote: > Folks, > This morning I downloaded and installed a security update for my MAC G5. I > am running MAC OSX 10.3.9. > Friday March 16 I was able to > ssh -X me at targetcpu > and launch my application > this morning March 19 I get this error: > X Error of failed request: BadAtom (invalid Atom parameter) > Major opcode of failed request: 20 (X_GetProperty) > Atom id in failed request: 0x25 > Serial number of failed request: 309 > Current serial number in output stream: 309 > I can get an xclock window to open but the GUI for my application is not > able to launch. > I can work around this by setting xhost on the mac, ssh to remote > machine, setenv DISPLAY and launching the application. > Can you suggest some reasons why this current fix broke my > ssh -X trick? Try `ssh -Y` instead. Marc. +----------------------------------+----------------------------------+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and | fax: 1-780-492-1729 | | Communications Technologies | email: tsi at ualberta.ca | | 352 General Services Building +----------------------------------+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply | | T6G 2H1 | | | CANADA | | +----------------------------------+----------------------------------+ XFree86 developer and VP. ATI driver and X server internals. From johnpell at gmail.com Tue Mar 20 11:30:18 2007 From: johnpell at gmail.com (John Davidorff Pell) Date: Mon, 19 Mar 2007 17:30:18 -0700 Subject: Security Update from MAC breaks ssh -X In-Reply-To: <20070319232648.GA15156@wilbur.25thandClement.com> References: <22083437.1174322746@22gdellstarr.csb.musc.edu> <45FF0DED.7090402@zip.com.au> <20070319232648.GA15156@wilbur.25thandClement.com> Message-ID: On Mar 19, 2007, at 4:26 PM, William Ahern wrote: > On Tue, Mar 20, 2007 at 09:25:49AM +1100, Darren Tucker wrote: >> This has been the default for years, I don't know why you're only >> seeing >> problems now (unless Apple used to change the default in their >> packages >> and now don't?) The original poster is running Mac OS X 10.3.9. 10.3 is 3 years old. > For one thing, Apple hasn't updated their version of OpenSSH for > years. > Which patches they backport is anyone's guess. They certainly haven't > backported control socket mastering. Apple doesn't backport much of anything in the open source projects, they just update the the latest release. At the same time, Apple doesn't update *any* software in Mac OS X unless there are security flaws or other bug fixes. Mac OS X is a commercial operating system that cannot afford the release-early-and-fix-often mentality. It has to work (well enough) the first time, and not break later. (Yes, I know that this doesn't always happen. Its /supposed/ to work this way.) > Likewise for OpenSSL. Basically, Apple ceased all Unix environment > development the moment OS X shipped. Soon porting Unix apps to OS X > will be > as fun as to Microsoft's POSIX interface. That's just not true. With each major release of Mac OS X, Apple syncs with the FreeBSD userland. Almost all commands that were shipping with FreeBSD 5.0 are the versions in Tiger. In some cases, Tiger versions have been updated due to security fixes or just bug fixes, as I mentioned above. That's not all that old. Specifically for OpenSSH. Apple updated to OpenSSH 3.8 (from 3.6) in a security update sometime after 10.4.6 (it might simply have been in 10.4.7, I don't remember). The latest security update came up to OpenSSH 4.5. The moral of the story: If you want Apple to update a working open source package in between major releases, then find and report [to Apple] a security flaw that is fixed in the version of the package that you want Apple to update to. ;-) JP -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2520 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070319/a26351c0/attachment.bin From nigelenki at comcast.net Thu Mar 22 08:14:50 2007 From: nigelenki at comcast.net (John Richard Moser) Date: Wed, 21 Mar 2007 17:14:50 -0400 Subject: [RFC]: OpenSSH vpn lists Message-ID: <4601A04A.6040302@comcast.net> I've got an idea for using OpenSSH to establish a sort of internal secure network, where everything going back and forth between certain services (i.e. MySQL, how horrid) is encrypted even if the application/server doesn't support launching the service over SSL. This has some issues; so I'm probing for ideas on a new feature that would resolve them and make this easier. Let's hypothesize that you have 100 database servers serving MySQL (TCP:3306) and MS SQL 2005 (TCP:1433). These are as follows: 10.10.30.[50-100]:3306 - MySQL 10.10.40.[75-125]:1433 - MS SQL 2000/2005 To deal with this, you set up on each machine 100 virtual network adapters that don't route outside: 192.168.30.[50-100] - 10.10.30.[50-100] mates 192.168.40.[75-125] - 10.10.40.[75-125] mates Now you run ssh as follows. In this example, the local IP is 10.10.10.20 (can probably omit -b). Also we use private key authentication so no pasword: i=50; while [ "$i" != "101" ]; do ssh -b 10.10.10.20 -L 192.168.30.${i}:3306:localhost:3306 & i=$(( $i + 1 )) done i=75; while [ "$i" != "126" ]; do ssh -b 10.10.10.20 -L 192.168.40.${i}:3306:localhost:1433 & i=$(( $i + 1 )) done The obvious problem here: We have some weird script bringing up 100 ssh clients with 100 connections. What if we could tell ssh to load a file and do it, where the file contained something like: # Set default authentication default auth=privkey:/home/sshfwd/.ssh/id_rsa user=sshfwd # listen (-L; listen-dynamic is -D) # nmap syntax for addresses (i.e. 192.168.1-20.35-123) # MySQL servers listen bind=10.10.10.20 listen-address=192.168.30.50-100 \ listen-port=3306 forward-address=localhost forward-port=3306 # MS SQL 2000 and 2005 servers listen bind=10.10.10.20 listen-address=192.168.40.75-125 \ listen-port=3306 forward-address=localhost forward-port=1433 This file would only contain "listen" and "listen-dynamic" lines; define the four parameters to -D or -L; a bind address (-b); and a remote user. default authentication is privkey, followed by gssapi; or specified on a 'default' line. Same with 'user='. Addresses and ports would be specified as they are in nmap, with comma-separated sets and hyphen-separated ranges. Another useful feature that would compliment this would be reverse binding, i.e. connecting out to a remote server and forwarding connections to an IP address on it to the local host; this would allow for a high-security server to have a privkey, connect out to servers with the pubkey, and then allow them to forward ports into it onto its local host. This is a thousand times better than putting the privkey freaking everywhere because one root-level compromise spells doom. This feature could have the policy listen-r, with the command switch "-L r:bind_addr:port:host:hostport" or some such craziness. Not sure.. anyone have any thoughts? -- We will enslave their women, eat their children and rape their cattle! -- Bosc, Evil alien overlord from the fifth dimension Anti-Spam: https://bugzilla.mozilla.org/show_bug.cgi?id=229686 From william at 25thandClement.com Thu Mar 22 17:30:06 2007 From: william at 25thandClement.com (William Ahern) Date: Wed, 21 Mar 2007 23:30:06 -0700 Subject: [RFC]: OpenSSH vpn lists In-Reply-To: <4601A04A.6040302@comcast.net> References: <4601A04A.6040302@comcast.net> Message-ID: <20070322063006.GA20125@wilbur.25thandClement.com> On Wed, Mar 21, 2007 at 05:14:50PM -0400, John Richard Moser wrote: > I've got an idea for using OpenSSH to establish a sort of internal > secure network, where everything going back and forth between certain > services (i.e. MySQL, how horrid) is encrypted even if the > application/server doesn't support launching the service over SSL. This > has some issues; so I'm probing for ideas on a new feature that would > resolve them and make this easier. > > Let's hypothesize that you have 100 database servers serving MySQL > (TCP:3306) and MS SQL 2005 (TCP:1433). These are as follows: > > 10.10.30.[50-100]:3306 - MySQL > 10.10.40.[75-125]:1433 - MS SQL 2000/2005 > > To deal with this, you set up on each machine 100 virtual network > adapters that don't route outside: Or, you simply patch OpenSSH to support domain socket forwarding. Then you can have meaningfully named tunnels which can be used by local applications in a more consistent and purposeful manner. > Not sure.. anyone have any thoughts? I do this extensively. I ruled juggling so many ports as out of the question entirely. Not only was it ugly and hard to follow, it was also very error prone. If for some reason you can bind to a particular port, then what? With domain sockets you can at least remove them/override them. - Bill From Jefferson.Ogata at noaa.gov Thu Mar 22 20:15:55 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Thu, 22 Mar 2007 05:15:55 -0400 Subject: [RFC]: OpenSSH vpn lists In-Reply-To: <20070322063006.GA20125@wilbur.25thandClement.com> References: <4601A04A.6040302@comcast.net> <20070322063006.GA20125@wilbur.25thandClement.com> Message-ID: <4602494B.1060604@noaa.gov> On 03/22/2007 02:30 AM, William Ahern wrote: > Or, you simply patch OpenSSH to support domain socket forwarding. Then you Not to disagree with you on your argument, but to clarify: what you are calling "domain sockets" are actually called "UNIX-domain sockets". The term "domain" refers to the protocol family, which is specified during creation of every socket. Among other things, the domain determines the namespace for the socket's binding--e.g. the UNIX domain (PF_UNIX) for paths in the UNIX filesystem, or the Internet domain (PF_INET) for IP + port. There are additional domains for other protocol families; see the PF_ definitions in . -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From dberezin at acs.rutgers.edu Fri Mar 23 02:12:33 2007 From: dberezin at acs.rutgers.edu (Dmitry Berezin) Date: Thu, 22 Mar 2007 11:12:33 -0400 Subject: ChallengeResponseAuthentication defaults to no? Message-ID: <0JFB00J698WZWCJ0@rulink.rutgers.edu> Hello, I have just installed OpenSSH 4.6p1 and it appears that ChallengeResponseAuthentication is not allowed unless I explicitly set it to "yes" in the sshd_config file. I am using the same config file as I did with 4.5p1 where it was allowed by default. Also, this is OpenSSH package from sunfreeware, but I believe that both versions were compiled with the same options. Is this the intended behavior? Thank you, -Dmitry. From dtucker at zip.com.au Fri Mar 23 06:41:02 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 23 Mar 2007 06:41:02 +1100 Subject: ChallengeResponseAuthentication defaults to no? In-Reply-To: <0JFB00J698WZWCJ0@rulink.rutgers.edu> References: <0JFB00J698WZWCJ0@rulink.rutgers.edu> Message-ID: <20070322194102.GA12806@gate.dtucker.net> On Thu, Mar 22, 2007 at 11:12:33AM -0400, Dmitry Berezin wrote: > I have just installed OpenSSH 4.6p1 and it appears that > ChallengeResponseAuthentication is not allowed unless I explicitly set > it to "yes" in the sshd_config file. I am using the same config file as > I did with 4.5p1 where it was allowed by default. Also, this is OpenSSH > package from sunfreeware, but I believe that both versions were compiled > with the same options. > > Is this the intended behavior? No, it was an unintended interaction with the Match code. The thing that was affected was Protocol 2 KbdInteractiveAuthentication when UsePrivilegeSeparation=yes. This is enabled if ChallengeResponseAuthentication is set, but it happens in the unprivileged child. The Match code overwrote this setting which had the effect of changing the default. The following patch (which will be in the next release) should fix it. Apologies for the inconvenience. Index: servconf.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/servconf.c,v retrieving revision 1.161 diff -u -p -r1.161 servconf.c --- servconf.c 1 Mar 2007 10:31:29 -0000 1.161 +++ servconf.c 22 Mar 2007 19:31:22 -0000 @@ -1,4 +1,4 @@ -/* $OpenBSD: servconf.c,v 1.170 2007/03/01 10:28:02 dtucker Exp $ */ +/* $OpenBSD: servconf.c,v 1.171 2007/03/09 05:20:06 dtucker Exp $ */ /* * Copyright (c) 1995 Tatu Ylonen , Espoo, Finland * All rights reserved @@ -1387,8 +1387,4 @@ parse_server_config(ServerOptions *optio if (bad_options > 0) fatal("%s: terminating, %d bad configuration options", filename, bad_options); - - /* challenge-response is implemented via keyboard interactive */ - if (options->challenge_response_authentication == 1) - options->kbd_interactive_authentication = 1; } Index: sshd.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/sshd.c,v retrieving revision 1.362 diff -u -p -r1.362 sshd.c --- sshd.c 25 Feb 2007 09:37:22 -0000 1.362 +++ sshd.c 22 Mar 2007 19:31:22 -0000 @@ -1,4 +1,4 @@ -/* $OpenBSD: sshd.c,v 1.349 2007/02/21 11:00:05 dtucker Exp $ */ +/* $OpenBSD: sshd.c,v 1.350 2007/03/09 05:20:06 dtucker Exp $ */ /* * Author: Tatu Ylonen * Copyright (c) 1995 Tatu Ylonen , Espoo, Finland @@ -1421,6 +1421,10 @@ main(int ac, char **av) /* Fill in default values for those options not explicitly set. */ fill_default_server_options(&options); + /* challenge-response is implemented via keyboard interactive */ + if (options.challenge_response_authentication) + options.kbd_interactive_authentication = 1; + /* set default channel AF */ channel_set_af(options.address_family); -- 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 g.fischer at ah-online.com Fri Mar 23 15:29:18 2007 From: g.fischer at ah-online.com (g.fischer at ah-online.com) Date: Fri, 23 Mar 2007 05:29:18 +0100 Subject: openssh 4.6p1 bug / IRIX Message-ID: <4603579E.9090101@ah-online.com> hello, little problem compiling openssh 4.6p1 on irix using mipspro 7.4.x. c99 -o sshd sshd.o auth-rhosts.o auth-passwd.o auth-rsa.o auth-rh-rsa.o sshpty.o sshlogin.o servconf.o serverloop.o auth.o auth1.o auth2.o auth-options.o session.o auth-chall.o auth2-chall.o groupaccess.o auth-skey.o auth-bsdauth.o auth2-hostbased.o auth2-kbdint.o auth2-none.o auth2-passwd.o auth2-pubkey.o monitor_mm.o monitor.o monitor_wrap.o kexdhs.o kexgexs.o auth-krb5.o auth2-gss.o gss-serv.o gss-serv-krb5.o loginrec.o auth-pam.o auth-shadow.o auth-sia.o md5crypt.o audit.o audit-bsm.o platform.o -L. -Lopenbsd-compat/ -L/usr/local/lib -L/usr/local2/lib -L/usr/nekoware/lib -L/usr/freeware/lib32 -lssh -lopenbsd-compat -liaf -lcrypto -lz -lgen ld32: ERROR 33 : Unresolved text symbol "set_id" -- 1st referenced by session.o. thanks in advance -- ah-consulting.net G?tz Fischer Senior Consultant Phone: +49(0)7225/98 98 79 Fax: +49(0)7225/28 64 eMail: g.fischer at ah-consulting.net http://www.ah-consulting.net http://www.ah-webhosting.com From dtucker at zip.com.au Fri Mar 23 16:39:54 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 23 Mar 2007 16:39:54 +1100 Subject: openssh 4.6p1 bug / IRIX In-Reply-To: <4603579E.9090101@ah-online.com> References: <4603579E.9090101@ah-online.com> Message-ID: <4603682A.9050407@zip.com.au> g.fischer at ah-online.com wrote: > hello, > > little problem compiling openssh 4.6p1 on irix using mipspro 7.4.x. > > c99 -o sshd sshd.o auth-rhosts.o auth-passwd.o auth-rsa.o auth-rh-rsa.o > sshpty.o sshlogin.o servconf.o serverloop.o auth.o auth1.o auth2.o > auth-options.o session.o auth-chall.o auth2-chall.o groupaccess.o > auth-skey.o auth-bsdauth.o auth2-hostbased.o auth2-kbdint.o auth2-none.o > auth2-passwd.o auth2-pubkey.o monitor_mm.o monitor.o monitor_wrap.o > kexdhs.o kexgexs.o auth-krb5.o auth2-gss.o gss-serv.o gss-serv-krb5.o > loginrec.o auth-pam.o auth-shadow.o auth-sia.o md5crypt.o audit.o > audit-bsm.o platform.o -L. -Lopenbsd-compat/ -L/usr/local/lib > -L/usr/local2/lib -L/usr/nekoware/lib -L/usr/freeware/lib32 -lssh > -lopenbsd-compat -liaf -lcrypto -lz -lgen > ld32: ERROR 33 : Unresolved text symbol "set_id" -- 1st referenced by > session.o. set_id is inside "HAVE_LIBIAF" which I believe is specific to SCO. (?) Maybe IRIX has something similar (or similarly named). Defining BROKEN_LIBIAF at build time (eg "./configure --with-cflags=-DBROKEN_LIBIAF") will probably get your build going. Looking at it, I think that configure should probably check for set_id explicitly and session.c should use HAVE_SET_ID in addition to HAVE_LIBAIF. -- 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 postmaster at nicola.com.br Fri Mar 23 22:12:49 2007 From: postmaster at nicola.com.br (Alerta de Anti-Virus) Date: 23 Mar 2007 11:12:49 -0000 Subject: problem encontrado na mensagem "Mail Delivery (failure cor.cpd@nicola.com.br)" Message-ID: Atencao: openssh-unix-dev at mindrot.org Um problem foi encontrado na mensagem que voce enviou. Este servidor interceptou esta mensagem e impediu que ela fosse entregue para seu destinatario. O problem foi reportado como sendo: Exploit.HTML.IFrame Por favor entre em contato com a area de TI de sua empresa ou com seu provedor de acesso a Internet para esclarecer alguma duvida com relacao a esta politica. Sua mensagem foi enviada com os seguintes dados: REMETENTE: openssh-unix-dev at mindrot.org DESTINATARIO: cor.cpd at nicola.com.br ... e com o seguinte cabecalho: ------------------------------------------------------------- MAILFROM: openssh-unix-dev at mindrot.org RCPTTO: cor.cpd at nicola.com.br IP-Addr: 200.171.70.204 Received: from unknown (HELO nicola.com.br) (200.171.70.204) by 0 with SMTP; 23 Mar 2007 11:12:42 -0000 Received-SPF: neutral (0: 200.171.70.204 is neither permitted nor denied by SPF record at mindrot.org) From: openssh-unix-dev at mindrot.org To: cor.cpd at nicola.com.br Subject: Mail Delivery (failure cor.cpd at nicola.com.br) Date: Fri, 23 Mar 2007 08:07:24 -0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_001B_01C0CA80.6B015D10" X-Priority: 3 X-MSMail-Priority: Normal ------------------------------------------------------------- From snalwuer at cip.informatik.uni-erlangen.de Sat Mar 24 02:29:34 2007 From: snalwuer at cip.informatik.uni-erlangen.de (Alexander Wuerstlein) Date: Fri, 23 Mar 2007 16:29:34 +0100 Subject: Permissions on the ssh-agent socket Message-ID: <20070323152934.GA954@cip.informatik.uni-erlangen.de> Hello, this may be a stupid question, but I'll ask anyways because I was unable to get a satisfying answer somwhere else. So feel free to simply point out my stupidity, if the problem lies only there. The question: If I start an ssh-agent, it creates a socket (/tmp/ssh-*/agent.*), with the socket's and the directory's permissions set to 600. However, if I now connect to a remote host with agent-forwarding enabled, the resulting socket on the remote host gets permissions 755 (the directory still gets 700). What bothers me is the go+rx part, is there any specific reason to that? If not, wouldn't it be better to be paranoid and use 600? The behaviour above applies to Linux (Debian testing, OpenSSH_4.3p2 Debian-9, OpenSSL 0.9.8c 05 Sep 2006), as well as Solaris (Solaris 10 06/06 x86, OpenSSH_4.5p1, OpenSSL 0.9.8d 28 Sep 2006) and FreeBSD (5.4, OpenSSH_3.6.1, SSH protocols 1.5/2.0, OpenSSL 0x0090804f). Unfortunately I have no OpenBSD box available to test that behaviour, so it could perhaps only affect portable OpenSSH. Ciao, Alexander Wuerstlein. From craig.bookwalter at gmail.com Sat Mar 24 05:03:17 2007 From: craig.bookwalter at gmail.com (Craig Bookwalter) Date: Fri, 23 Mar 2007 14:03:17 -0400 Subject: login shell not found "bug" Message-ID: <1e1d6d70703231103v29dcd906h433f871ee9cd5070@mail.gmail.com> Hello folks at OpenSSH, I recently encountered a behavior of your software (it doesn't really deserve the name of "bug") that may be so rare that it is not worth correcting--however, if it was corrected, it would have saved me many hours of anguish. I recently set up a new PC with Ubuntu 6.10 and connected to my office NIS domain. Unfortunately, when I tried to log in via SSH with my NIS login, I always had my password rejected. I spent a great deal of time trying to make sure that SSH had access to the NIS passwd file. It turned out that the problem was that my default login shell in the NIS passwd file was tcsh, and Ubuntu 6.10 does not come with tcsh installed by default. It would have been wonderful if SSH could have told me that the reason my login was failing was that my login shell didn't exist, rather than just rejecting my password. I realize this doesn't happen very often, so it may not be worth inserting, but I thought I would at least put it in your hands. In any case, thank you for writing a program that 99% of the time I don't notice because it works beautifully. Regards, Craig From jws at lindy.stanford.edu Sat Mar 24 09:54:46 2007 From: jws at lindy.stanford.edu (Jim Stosick) Date: Fri, 23 Mar 2007 15:54:46 -0700 Subject: 4.6p1 chan_read_failed error Message-ID: <46045AB6.6050903@lindy.stanford.edu> The 4.6p1 sshd is logging this error during remote commands or file transfers: error: channel 0: chan_read_failed for istate 3 Platform is Solaris 8, 4.6p1 + OpenSSL 0.9.8d. The commands and transfers work correctly, so the error message appears to be spurious. The error message does not appear when processing logins. Otherwise 4.6p1 is running without any apparent problems. This error did not occur running 4.5p1. Here is a trace: Accepted hostbased for jws from 171.64.11.11 port 64578 ssh2 debug1: Entering interactive session for SSH2. debug2: fd 4 setting O_NONBLOCK debug2: fd 5 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 131072 max 32768 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request exec reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req exec debug2: fd 3 setting TCP_NODELAY debug2: fd 7 setting O_NONBLOCK debug3: fd 7 is O_NONBLOCK debug2: fd 9 setting O_NONBLOCK debug2: channel 0: read 38 from efd 9 debug2: channel 0: rwin 131072 elen 38 euse 1 debug2: channel 0: sent ext data 38 debug2: channel 0: read 15 from efd 9 debug2: channel 0: rwin 131034 elen 15 euse 1 debug2: channel 0: sent ext data 15 debug2: channel 0: read 117 from efd 9 debug2: channel 0: rwin 131019 elen 117 euse 1 debug2: channel 0: sent ext data 117 debug2: channel 0: read 73 from efd 9 debug2: channel 0: rwin 130902 elen 73 euse 1 debug2: channel 0: sent ext data 73 debug2: channel 0: read 103 from efd 9 debug2: channel 0: rwin 130829 elen 103 euse 1 debug2: channel 0: sent ext data 103 debug2: channel 0: read<=0 rfd 7 len 0 debug2: channel 0: read failed debug2: channel 0: close_read debug2: channel 0: input open -> drain debug2: channel 0: ibuf_empty delayed efd 9/(0) debug2: channel 0: read 0 from efd 9 debug2: channel 0: closing read-efd 9 debug2: channel 0: ibuf empty debug2: channel 0: send eof debug2: channel 0: input drain -> closed debug2: notify_done: reading debug1: Received SIGCHLD. debug1: session_by_pid: pid 11033 debug1: session_exit_message: session 0 channel 0 pid 11033 debug2: channel 0: request exit-status confirm 0 debug1: session_exit_message: release channel 0 debug2: channel 0: write failed debug2: channel 0: close_write debug2: channel 0: output open -> closed debug2: channel 0: read<=0 rfd 7 len 0 debug2: channel 0: read failed channel 0: chan_read_failed for istate 3 debug2: channel 0: send close debug3: channel 0: will not send data after close debug2: channel 0: read<=0 rfd 7 len 0 debug2: channel 0: read failed channel 0: chan_read_failed for istate 3 debug2: channel 0: rcvd close debug3: channel 0: will not send data after close debug2: channel 0: is dead debug2: channel 0: gc: notify user debug1: session_by_channel: session 0 channel 0 debug1: session_close_by_channel: channel 0 child 0 debug1: session_close: session 0 pid 0 debug2: channel 0: gc: user detached debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: server-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 server-session (t4 r0 i3/0 o3/0 fd 7/7 cfd -1) debug3: channel 0: close_fds r 7 w 7 e -1 c -1 Connection closed by 171.64.11.11 debug1: do_cleanup Closing connection to 171.64.11.11 From bob at proulx.com Sat Mar 24 13:54:45 2007 From: bob at proulx.com (Bob Proulx) Date: Fri, 23 Mar 2007 20:54:45 -0600 Subject: login shell not found "bug" In-Reply-To: <1e1d6d70703231103v29dcd906h433f871ee9cd5070@mail.gmail.com> References: <1e1d6d70703231103v29dcd906h433f871ee9cd5070@mail.gmail.com> Message-ID: <20070324025445.GA22296@dementia.proulx.com> Craig Bookwalter wrote: > It turned out that the problem was that my default login shell in > the NIS passwd file was tcsh, and Ubuntu 6.10 does not come with > tcsh installed by default. It would have been wonderful if SSH could > have told me that the reason my login was failing was that my login > shell didn't exist, rather than just rejecting my password. I > realize this doesn't happen very often, so it may not be worth > inserting, but I thought I would at least put it in your hands. First let me say that I am not one of the OpenSSH developers. I am speaking for myself. Using a shell that is non-existent is a common way for admins to disable accounts. I don't know if sshd would have logged any information to the syslog about it or not but returning an indication to the user would probably be a security badness. Because then an attacker would learn something about the account, that the account existed but that the shell did not. That might give an attacker information that could be used to advantage in breaking into the system in another way. The usual wisdom is give no system information to an unauthorized user. Therefore probably sshd cannot actually say why the login is failing to the user logging into the system. Did any errors get logged to the syslog with this information? That would be the right place for it. This probably won't make you feel any better about it but perhaps it does explain the situation a little more. (And also that perhaps it is time to think about switching to a more standard shell. :-) Good Luck! Bob From David.Leonard at quest.com Sat Mar 24 14:47:45 2007 From: David.Leonard at quest.com (David Leonard) Date: Sat, 24 Mar 2007 13:47:45 +1000 Subject: login shell not found "bug" In-Reply-To: <20070324025445.GA22296@dementia.proulx.com> References: <1e1d6d70703231103v29dcd906h433f871ee9cd5070@mail.gmail.com> <20070324025445.GA22296@dementia.proulx.com> Message-ID: <46049F61.8040609@quest.com> Bob Proulx wrote: > Craig Bookwalter wrote: > >> It turned out that the problem was that my default login shell in >> the NIS passwd file was tcsh, and Ubuntu 6.10 does not come with >> tcsh installed by default. It would have been wonderful if SSH could >> have told me that the reason my login was failing was that my login >> shell didn't exist, rather than just rejecting my password. >> > Did any errors get logged to the syslog with this information? That > would be the right place for it. > There would have been this kind of entry in the server logs: Mar 24 09:59:16 somehost sshd[19155]: User testuser not allowed because shell /bin/doesntexist does not exist sshd's allowed_user() function is noticing that the shell doesn't exist, so it vetoes the authentication. (sshd(8)'s section on 'AUTHENTICATION' doesn't mention this check.) > > Using a shell that is non-existent is a common way for admins to > disable accounts. I don't know if sshd would have logged any > information to the syslog about it or not but returning an indication > to the user would probably be a security badness. Because then an > attacker would learn something about the account, that the account > existed but that the shell did not. That might give an attacker > information that could be used to advantage in breaking into the > system in another way. The usual wisdom is give no system information > to an unauthorized user. Therefore probably sshd cannot actually say > why the login is failing to the user logging into the system. > > If you believe that invalid shell = disabled account, the question here is then: how can sshd's allowed_user() function know if an account's shell is /intentionally/ invalid or not? Some systems provide an /etc/shells list. Perhaps sshd should scan that list and continue if pw_shell is in that list? Leaking an error message (/bin/tcsh: No such file or directory) is then bad. Maybe PAM is a better place for an invalid shell check. But I think invalid shell = disabled account is wrong wisdom. ('invalid' meaning that the shell doesn't exist or maybe isn't executable) I suspect that it is a widespread belief though. If you reject that belief, then printing "/bin/tcsh: No such file or directory" doesn't leaking any information. It also means that allowed_user() has no business looking at the pw_shell field. The existence of /sbin/nologin is an example where this won't work. I think it's a fallback for tools that bypass authentication (eg su). And in the case of FTP and other desirable non-shell network access, I think that PAM is a much better way to control access (instead of through pw_shell). So, if sshd's allowed_user()'s behaviour were changed to ignore pw_shell, then an account with an invalid shell would be allowed to do some non-session things, like port forwarding (this is currently the case when the shell is set to /sbin/nologin but the password is left valid). but the best part is that the authenticated user would get some information about why their session isn't working (/bin/tcsh: No such file or directory) This seems consistent to me. > This probably won't make you feel any better about it but perhaps it > does explain the situation a little more. (And also that perhaps it > is time to think about switching to a more standard shell. :-) > > My preferred shell is ksh .. I have hit the same problem on newly installed systems in an environment where invalid shell != disabled account, so I would benefit from a better error message because I am otherwise a properly authenticated user. d PS: I haven't found any definitive documentation, but on this topic, OpenBSD's passwd(5) says: By convention, accounts that are not intended to be logged in to (e.g. bin, daemon, sshd) have a star (`*') in the password field. [...and] usually have a shell of /sbin/nologin. and SuSE Linux passwd(5) says: If [the shell field is] set to a non-existing executable, the user will be unable to login through login(1). [...] If the encrypted password is set to a star, the user will be unable to login using login(1), but may still login using rlogin(1), run existing processes and initiate new ones through rsh(1), cron(1), at(1), or mail filters, etc. Trying to lock an account by simply changing the shell field yields the same result and additionally allows the use of su(1). From g.fischer at ah-online.com Sat Mar 24 19:19:43 2007 From: g.fischer at ah-online.com (g.fischer at ah-online.com) Date: Sat, 24 Mar 2007 09:19:43 +0100 Subject: openssh 4.6p1 bug / IRIX In-Reply-To: <4603682A.9050407@zip.com.au> References: <4603579E.9090101@ah-online.com> <4603682A.9050407@zip.com.au> Message-ID: <4604DF1F.1000408@ah-online.com> thanks for the hints. i got it done by hardcoding the solution you mentioned. not nice but worked. maybe the check for the libiaf should be refined. Darren Tucker wrote: > g.fischer at ah-online.com wrote: >> hello, >> >> little problem compiling openssh 4.6p1 on irix using mipspro 7.4.x. >> >> c99 -o sshd sshd.o auth-rhosts.o auth-passwd.o auth-rsa.o >> auth-rh-rsa.o sshpty.o sshlogin.o servconf.o serverloop.o auth.o >> auth1.o auth2.o auth-options.o session.o auth-chall.o auth2-chall.o >> groupaccess.o auth-skey.o auth-bsdauth.o auth2-hostbased.o >> auth2-kbdint.o auth2-none.o auth2-passwd.o auth2-pubkey.o >> monitor_mm.o monitor.o monitor_wrap.o kexdhs.o kexgexs.o auth-krb5.o >> auth2-gss.o gss-serv.o gss-serv-krb5.o loginrec.o auth-pam.o >> auth-shadow.o auth-sia.o md5crypt.o audit.o audit-bsm.o platform.o >> -L. -Lopenbsd-compat/ -L/usr/local/lib -L/usr/local2/lib >> -L/usr/nekoware/lib -L/usr/freeware/lib32 -lssh -lopenbsd-compat >> -liaf -lcrypto -lz -lgen >> ld32: ERROR 33 : Unresolved text symbol "set_id" -- 1st referenced >> by session.o. > > set_id is inside "HAVE_LIBIAF" which I believe is specific to SCO. (?) > Maybe IRIX has something similar (or similarly named). > > Defining BROKEN_LIBIAF at build time (eg "./configure > --with-cflags=-DBROKEN_LIBIAF") will probably get your build going. > > Looking at it, I think that configure should probably check for set_id > explicitly and session.c should use HAVE_SET_ID in addition to > HAVE_LIBAIF. > -- ah-consulting.net G?tz Fischer Senior Consultant Phone: +49(0)7225/98 98 79 Fax: +49(0)7225/28 64 eMail: g.fischer at ah-consulting.net http://www.ah-consulting.net http://www.ah-webhosting.com From dtucker at zip.com.au Sat Mar 24 21:04:27 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 24 Mar 2007 21:04:27 +1100 Subject: openssh 4.6p1 bug / IRIX In-Reply-To: <4604DF1F.1000408@ah-online.com> References: <4603579E.9090101@ah-online.com> <4603682A.9050407@zip.com.au> <4604DF1F.1000408@ah-online.com> Message-ID: <20070324100427.GA19780@gate.dtucker.net> On Sat, Mar 24, 2007 at 09:19:43AM +0100, g.fischer at ah-online.com wrote: > > thanks for the hints. > i got it done by hardcoding the solution you mentioned. not nice but worked. > > maybe the check for the libiaf should be refined. This diff ought to do it (you will need to run "autoreconf" to rebuild configure if you try this). It also prevents libiaf from being linked to anything other than sshd, and then only if it's used. Hopefully this still works on the platforms that have libiaf (according to the survey data, this includes UnixWare 2, 6 and 7). Tim? Index: auth.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/auth.c,v retrieving revision 1.124 diff -u -p -r1.124 auth.c --- auth.c 4 Dec 2006 22:08:55 -0000 1.124 +++ auth.c 24 Mar 2007 09:36:16 -0000 @@ -115,11 +115,11 @@ allowed_user(struct passwd * pw) /* grab passwd field for locked account check */ #ifdef USE_SHADOW if (spw != NULL) -#if defined(HAVE_LIBIAF) && !defined(BROKEN_LIBIAF) +#ifdef USE_LIBIAF passwd = get_iaf_password(pw); #else passwd = spw->sp_pwdp; -#endif /* HAVE_LIBIAF && !BROKEN_LIBIAF */ +#endif /* USE_LIBIAF */ #else passwd = pw->pw_passwd; #endif @@ -141,9 +141,9 @@ allowed_user(struct passwd * pw) if (strstr(passwd, LOCKED_PASSWD_SUBSTR)) locked = 1; #endif -#if defined(HAVE_LIBIAF) && !defined(BROKEN_LIBIAF) +#ifdef USE_LIBIAF free(passwd); -#endif /* HAVE_LIBIAF && !BROKEN_LIBIAF */ +#endif /* USE_LIBIAF */ if (locked) { logit("User %.100s not allowed because account is locked", pw->pw_name); Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/configure.ac,v retrieving revision 1.373 diff -u -p -r1.373 configure.ac --- configure.ac 21 Mar 2007 10:39:57 -0000 1.373 +++ configure.ac 24 Mar 2007 09:58:23 -0000 @@ -1978,7 +1978,11 @@ fi # Search for SHA256 support in libc and/or OpenSSL AC_CHECK_FUNCS(SHA256_Update EVP_sha256) -AC_CHECK_LIB(iaf, ia_openinfo) +saved_LIBS="$LIBS" +AC_CHECK_LIB(iaf, ia_openinfo, [ + AC_CHECK_FUNCS(set_id, [SSHDLIBS="$SSHDLIBS -liaf"]) +]) +LIBS="$saved_LIBS" ### Configure cryptographic random number support Index: defines.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/defines.h,v retrieving revision 1.138 diff -u -p -r1.138 defines.h --- defines.h 21 Sep 2006 13:13:30 -0000 1.138 +++ defines.h 24 Mar 2007 09:33:59 -0000 @@ -696,7 +696,8 @@ struct winsize { # define CUSTOM_SYS_AUTH_PASSWD 1 #endif -#ifdef HAVE_LIBIAF +#if defined(HAVE_LIBIAF) && defined(HAVE_SET_ID) && !defined(BROKEN_LIBIAF) +# define USE_LIBIAF # define CUSTOM_SYS_AUTH_PASSWD 1 #endif Index: session.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/session.c,v retrieving revision 1.350 diff -u -p -r1.350 session.c --- session.c 19 Feb 2007 11:10:25 -0000 1.350 +++ session.c 24 Mar 2007 09:35:07 -0000 @@ -1361,11 +1361,11 @@ do_setusercontext(struct passwd *pw) # ifdef _AIX aix_usrinfo(pw); # endif /* _AIX */ -#if defined(HAVE_LIBIAF) && !defined(BROKEN_LIBIAF) +#ifdef USE_LIBIAF if (set_id(pw->pw_name) != 0) { exit(1); } -#endif /* HAVE_LIBIAF && !BROKEN_LIBIAF */ +#endif /* USE_LIBIAF */ /* Permanently switch to the desired uid. */ permanently_set_uid(pw); #endif -- 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 Sat Mar 24 22:39:04 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 24 Mar 2007 22:39:04 +1100 Subject: configure/makefile cleanup: remove LIBSELINUX, LIBWRAP and LIBPAM Message-ID: <20070324113904.GA17916@gate.dtucker.net> Hi all. Now that we have SSHDLIBS for the libraries required by sshd only, it's possible to remove some of the single-purpose variables from Makefile. If this is worth doing, the next step would probably be to move the OpenSSL libs into CRYPTOLIBS since binaries such as scp and sftp don't need to be linked with libcrypto. Index: Makefile.in =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/Makefile.in,v retrieving revision 1.283 diff -u -p -r1.283 Makefile.in --- Makefile.in 23 Oct 2006 21:44:47 -0000 1.283 +++ Makefile.in 24 Mar 2007 10:49:45 -0000 @@ -44,11 +44,8 @@ LD=@LD@ CFLAGS=@CFLAGS@ CPPFLAGS=-I. -I$(srcdir) @CPPFLAGS@ $(PATHS) @DEFS@ LIBS=@LIBS@ -LIBSELINUX=@LIBSELINUX@ SSHDLIBS=@SSHDLIBS@ LIBEDIT=@LIBEDIT@ -LIBPAM=@LIBPAM@ -LIBWRAP=@LIBWRAP@ AR=@AR@ AWK=@AWK@ RANLIB=@RANLIB@ @@ -139,7 +136,7 @@ ssh$(EXEEXT): $(LIBCOMPAT) libssh.a $(SS $(LD) -o $@ $(SSHOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) sshd$(EXEEXT): libssh.a $(LIBCOMPAT) $(SSHDOBJS) - $(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBWRAP) $(LIBPAM) $(LIBSELINUX) $(SSHDLIBS) $(LIBS) + $(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(SSHDLIBS) $(LIBS) scp$(EXEEXT): $(LIBCOMPAT) libssh.a scp.o progressmeter.o $(LD) -o $@ scp.o progressmeter.o bufaux.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/configure.ac,v retrieving revision 1.373 diff -u -p -r1.373 configure.ac --- configure.ac 21 Mar 2007 10:39:57 -0000 1.373 +++ configure.ac 24 Mar 2007 11:31:56 -0000 @@ -1109,8 +1109,7 @@ AC_ARG_WITH(tcp-wrappers, CPPFLAGS="-I${withval} ${CPPFLAGS}" fi fi - LIBWRAP="-lwrap" - LIBS="$LIBWRAP $LIBS" + LIBS="-lwrap $LIBS" AC_MSG_CHECKING(for libwrap) AC_TRY_LINK( [ @@ -1126,7 +1125,7 @@ AC_ARG_WITH(tcp-wrappers, AC_DEFINE(LIBWRAP, 1, [Define if you want TCP Wrappers support]) - AC_SUBST(LIBWRAP) + SSHDLIBS="$SSHDLIBS -lwrap" TCPW_MSG="yes" ], [ @@ -2028,7 +2027,7 @@ AC_ARG_WITH(pam, PAM_MSG="yes" - LIBPAM="-lpam" + SSHDLIBS="$SSHDLIBS -lpam" AC_DEFINE(USE_PAM, 1, [Define if you want to enable PAM support]) @@ -2038,11 +2037,10 @@ AC_ARG_WITH(pam, # libdl already in LIBS ;; *) - LIBPAM="$LIBPAM -ldl" + SSHDLIBS="$SSHDLIBS -ldl" ;; esac fi - AC_SUBST(LIBPAM) fi ] ) @@ -3157,19 +3155,18 @@ LIBSELINUX="" AC_ARG_WITH(selinux, [ --with-selinux Enable SELinux support], [ if test "x$withval" != "xno" ; then + save_LIBS="$LIBS" AC_DEFINE(WITH_SELINUX,1,[Define if you want SELinux support.]) SELINUX_MSG="yes" AC_CHECK_HEADER([selinux/selinux.h], , AC_MSG_ERROR(SELinux support requires selinux.h header)) AC_CHECK_LIB(selinux, setexeccon, [ LIBSELINUX="-lselinux" ], AC_MSG_ERROR(SELinux support requires libselinux library)) - save_LIBS="$LIBS" - LIBS="$LIBS $LIBSELINUX" + SSHDLIBS="$SSHDLIBS $LIBSELINUX" AC_CHECK_FUNCS(getseuserbyname get_default_context_with_level) LIBS="$save_LIBS" fi ] ) -AC_SUBST(LIBSELINUX) # Check whether user wants Kerberos 5 support KRB5_MSG="no" @@ -4005,7 +4002,10 @@ echo " Compiler: ${CC}" echo " Compiler flags: ${CFLAGS}" echo "Preprocessor flags: ${CPPFLAGS}" echo " Linker flags: ${LDFLAGS}" -echo " Libraries: ${LIBWRAP} ${LIBPAM} ${LIBS}" +echo " Libraries: ${LIBS}" +if test ! -z "${SSHDLIBS}"; then +echo " +for sshd: ${SSHDLIBS}" +fi echo "" -- 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 Sat Mar 24 22:49:03 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 24 Mar 2007 22:49:03 +1100 Subject: 4.6p1 chan_read_failed error In-Reply-To: <46045AB6.6050903@lindy.stanford.edu> References: <46045AB6.6050903@lindy.stanford.edu> Message-ID: <20070324114902.GA8307@gate.dtucker.net> On Fri, Mar 23, 2007 at 03:54:46PM -0700, Jim Stosick wrote: > The 4.6p1 sshd is logging this error during remote commands or file > transfers: > > error: channel 0: chan_read_failed for istate 3 > > Platform is Solaris 8, 4.6p1 + OpenSSL 0.9.8d. > > The commands and transfers work correctly, so the error message appears > to be spurious. The error message does not appear when processing logins. > > Otherwise 4.6p1 is running without any apparent problems. This error > did not occur running 4.5p1. [...] I suspect this is related to the change for bug #52. You could try reverting the following patch ("patch -p1 -R") and see if the error messages stop. Index: openssh/channels.c diff -u openssh/channels.c:1.250 openssh/channels.c:1.251 --- openssh/channels.c:1.250 Fri Jan 5 16:30:16 2007 +++ openssh/channels.c Mon Jan 29 10:16:28 2007 @@ -1449,10 +1449,11 @@ int len; if (c->rfd != -1 && - FD_ISSET(c->rfd, readset)) { + (c->detach_close || FD_ISSET(c->rfd, readset))) { errno = 0; len = read(c->rfd, buf, sizeof(buf)); - if (len < 0 && (errno == EINTR || errno == EAGAIN)) + if (len < 0 && (errno == EINTR || + (errno == EAGAIN && !(c->isatty && c->detach_close)))) return 1; #ifndef PTY_ZEROREAD if (len <= 0) { @@ -1604,11 +1605,12 @@ c->local_consumed += len; } } else if (c->extended_usage == CHAN_EXTENDED_READ && - FD_ISSET(c->efd, readset)) { + (c->detach_close || FD_ISSET(c->efd, readset))) { len = read(c->efd, buf, sizeof(buf)); debug2("channel %d: read %d from efd %d", c->self, len, c->efd); - if (len < 0 && (errno == EINTR || errno == EAGAIN)) + if (len < 0 && (errno == EINTR || + (errno == EAGAIN && !c->detach_close))) return 1; if (len <= 0) { debug2("channel %d: closing read-efd %d", Index: openssh/serverloop.c diff -u openssh/serverloop.c:1.150 openssh/serverloop.c:1.151 --- openssh/serverloop.c:1.150 Tue Oct 24 03:02:41 2006 +++ openssh/serverloop.c Mon Jan 29 10:16:28 2007 @@ -280,6 +280,7 @@ struct timeval tv, *tvp; int ret; int client_alive_scheduled = 0; + int program_alive_scheduled = 0; /* * if using client_alive, set the max timeout accordingly, @@ -317,6 +318,7 @@ * the client, try to get some more data from the program. */ if (packet_not_very_much_data_to_write()) { + program_alive_scheduled = child_terminated; if (!fdout_eof) FD_SET(fdout, *readsetp); if (!fderr_eof) @@ -362,8 +364,16 @@ memset(*writesetp, 0, *nallocp); if (errno != EINTR) error("select: %.100s", strerror(errno)); - } else if (ret == 0 && client_alive_scheduled) - client_alive_check(); + } else { + if (ret == 0 && client_alive_scheduled) + client_alive_check(); + if (!compat20 && program_alive_scheduled && fdin_is_tty) { + if (!fdout_eof) + FD_SET(fdout, *readsetp); + if (!fderr_eof) + FD_SET(fderr, *readsetp); + } + } notify_done(*readsetp); } @@ -407,7 +417,8 @@ if (!fdout_eof && FD_ISSET(fdout, readset)) { errno = 0; len = read(fdout, buf, sizeof(buf)); - if (len < 0 && (errno == EINTR || errno == EAGAIN)) { + if (len < 0 && (errno == EINTR || + (errno == EAGAIN && !child_terminated))) { /* do nothing */ #ifndef PTY_ZEROREAD } else if (len <= 0) { @@ -425,7 +436,8 @@ if (!fderr_eof && FD_ISSET(fderr, readset)) { errno = 0; len = read(fderr, buf, sizeof(buf)); - if (len < 0 && (errno == EINTR || errno == EAGAIN)) { + if (len < 0 && (errno == EINTR || + (errno == EAGAIN && !child_terminated))) { /* do nothing */ #ifndef PTY_ZEROREAD } else if (len <= 0) { -- 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 Sat Mar 24 23:57:35 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 24 Mar 2007 23:57:35 +1100 Subject: Redefinition of _res in getrrsetbyname.c In-Reply-To: References: Message-ID: <20070324125735.GA26401@gate.dtucker.net> On Mon, Mar 12, 2007 at 09:06:19PM +0900, Curt Sampson wrote: > I've been trying to figure out why I can't seem to use SSHFP > fingerprints delivered via DNSSEC, which led me to try to figure out why > OpenSSH won't use DNSSEC on my NetBSD-4-branch platform. > > It turns out that around line 70 in openbsd-compat/getrrsetbyname.c, we > have the following: > > /* to avoid conflicts where a platform already has _res */ > #ifdef _res > # undef _res > #endif > #define _res _compat_res > > struct __res_state _res; [...] We could do this, which also apparently resolves the original problem that prompted the change above. Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/configure.ac,v retrieving revision 1.373 diff -u -p -r1.373 configure.ac --- configure.ac 21 Mar 2007 10:39:57 -0000 1.373 +++ configure.ac 24 Mar 2007 12:56:43 -0000 @@ -3151,6 +3151,25 @@ int main() [#include ]) ]) +AC_MSG_CHECKING(if struct __res_state _res is an extern) +AC_LINK_IFELSE([ +#include +#if HAVE_SYS_TYPES_H +# include +#endif +#include +#include +#include +extern struct __res_state _res; +int main() { return 0; } + ], + [AC_MSG_RESULT(yes) + AC_DEFINE(HAVE__RES_EXTERN, 1, + [Define if you have struct __res_state _res as an extern]) + ], + [ AC_MSG_RESULT(no) ] +) + # Check whether user wants SELinux support SELINUX_MSG="no" LIBSELINUX="" Index: openbsd-compat/getrrsetbyname.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/getrrsetbyname.c,v retrieving revision 1.23 diff -u -p -r1.23 getrrsetbyname.c --- openbsd-compat/getrrsetbyname.c 19 Feb 2007 11:56:56 -0000 1.23 +++ openbsd-compat/getrrsetbyname.c 24 Mar 2007 12:47:47 -0000 @@ -67,13 +67,9 @@ extern int h_errno; #endif #define _THREAD_PRIVATE(a,b,c) (c) -/* to avoid conflicts where a platform already has _res */ -#ifdef _res -# undef _res -#endif -#define _res _compat_res - +#ifndef HAVE__RES_EXTERN struct __res_state _res; +#endif /* Necessary functions and macros */ -- 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 pedz at easesoftware.com Sun Mar 25 02:32:55 2007 From: pedz at easesoftware.com (Perry Smith) Date: Sat, 24 Mar 2007 10:32:55 -0500 Subject: openpty() and AIX Message-ID: <1DF2A53F-57C1-4F4A-9249-F8DE09109FEA@easesoftware.com> I'm not on this mailing list so please make sure that I'm listed in any replies. There seems to be a basic flaw in either AIX pty's or many Linux applications and sshd falls into this category. sshd has a routine called openpty and it looks like ssh's version mimics the version in Linux. (I'm not sure where openpty comes from -- I'm assuming Linux.) The key to openpty is it opens both the slave and the master side of the pty. sshd calls openpty before the fork of the child so the parent has both file descriptors open. After the fork, it closes the file descriptor to the slave. The problem is that if the child generates output and exits before the parent can close its file descriptor to the slave then the parent's file descriptor becomes the last file descriptor to the slave. This implies that the close will go down to the device driver. On AIX, if there is data to be read on the ptc (the master side) of the pty, then the slave device driver will sleep in the close routine. It has been countless years since I have looked at the BSD code but I'm pretty sure this is what the BSD code did as well. I can't say if I have ever looked at the AT&T 5.4 code. AT&T prior to 5.4 did not have pty's (as I recall). To me, the BSD code defines how pty's work. There are also various Posix rules but they change so often I can't keep up with them. And, the behavior seems logical to me. The slave side of a pty is suppose to look just like a tty and a tty will not close until all of the data has drained out (assuming various other things like DCD is still high, etc). I see in at least some of the paths through the ssh code, the child opens the slave side of the pty -- which it needs to do in order to set up the process sessions. But what I can not tell with the short time I've looked at the code if the code always opens the slave side (when there is a pty involved at all). As far as I can tell, there are three basic paths to be concerned with: 1) just a normal ssh to a host 2) an ssh to a host that includes a command 3) an ssh to a host that includes a command and also uses the -t flag If the child always opens the slave side, then it should be possible to close the slaves fd in the parent before the fork. Utopia would be to never open the slave in the parent in the first place. That is where I'm somewhat confused. If all of the Linux applications like telnetd, rlogind, etc do the same thing, then it seems like they would all suffer from this problem. But, I assume that is not the case so maybe a change to the AIX pty code could be done (but I don't see how -- which is why I'm asking). So, my two basic questions are: 1) are the three paths through the code I listed above a complete list that I need to be looking at and 2) can anyone comment on how the Linux pty's work? Thank you, Perry Smith ( pedz at easesoftware.com ) Ease Software, Inc. ( http://www.easesoftware.com ) Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems From jacquejeremy at hotmail.com Sun Mar 25 21:49:02 2007 From: jacquejeremy at hotmail.com (Jeremy JACQUE) Date: Sun, 25 Mar 2007 13:49:02 +0200 Subject: Port Hopping in OpenSSH Message-ID: Hello, I'm student in a French college and trying to implement Port Hopping for OpenSSH. I already write some code (quite dirty you may say) that produce some big bugs !! So could you send me some advise on the implementation i wrote. You may find the patch here : http://jacque.homelinux.org/openssh-4.6p1_PH3.patch.gz Thanks a lot in advance. Have a nice day Jeremy JACQUE jacquejeremy at hotmail.com PS: this implementation is only working with IPv4 sockets and support no subsystem, so you will need to use sshd -4. You will find a file PORT_HOPPING_README with some explanations on how to compile and run the project. !! Be careful, you may have some bugs (for ex: if stay pushing "enter" on the client console , the server will send in an endless loop a port hopping request ??) A simple way to find the code i wrote in the source : grep -n modifier *.{c,h} One more time thanks _________________________________________________________________ Windows Live Spaces : cr?ez votre blog ? votre image ! http://www.windowslive.fr/spaces From Sergio.Gelato at astro.su.se Sun Mar 25 21:03:53 2007 From: Sergio.Gelato at astro.su.se (Sergio Gelato) Date: Sun, 25 Mar 2007 13:03:53 +0200 Subject: login shell not found "bug" In-Reply-To: <46049F61.8040609@quest.com> References: <1e1d6d70703231103v29dcd906h433f871ee9cd5070@mail.gmail.com> <20070324025445.GA22296@dementia.proulx.com> <46049F61.8040609@quest.com> Message-ID: <20070325110353.GA17832@astro.su.se> * David Leonard [2007-03-24 13:47:45 +1000]: > Bob Proulx wrote: > >Craig Bookwalter wrote: > > > >>It turned out that the problem was that my default login shell in > >>the NIS passwd file was tcsh, and Ubuntu 6.10 does not come with > >>tcsh installed by default. It would have been wonderful if SSH could > >>have told me that the reason my login was failing was that my login > >>shell didn't exist, rather than just rejecting my password. > > >Did any errors get logged to the syslog with this information? That > >would be the right place for it. I concur. Not least because installing /bin/tcsh is the sysadmin's, not the (remote) user's job. There is no point in disclosing the underlying details to the end user when (s)he can't fix the problem him/herself even with that knowledge. The sysadmin can and should read the syslog as a matter of course, so a message there is enough. > There would have been this kind of entry in the server logs: > Mar 24 09:59:16 somehost sshd[19155]: User testuser not allowed because > shell /bin/doesntexist does not exist A log message that means what it says. Excellent. > If you believe that invalid shell = disabled account, the question here > is then: how can sshd's allowed_user() function know if an account's > shell is /intentionally/ invalid or not? Some systems provide an > /etc/shells list. Perhaps sshd should scan that list and continue if > pw_shell is in that list? Leaking an error message (/bin/tcsh: No such > file or directory) is then bad. Even if the shell is invalid as a result of a configuration error (by the way, it's also not unheard of for sysadmins to misconfigure the contents of /etc/shells) only the sysadmin really needs to know that, not the end user. So sshd doesn't need to guess intentions (which is good, since mind-reading isn't particularly easy to program). > Maybe PAM is a better place for an invalid shell check. Maybe, but changing the shell in order to lock an account is common practice. And some operating systems don't have PAM, and some tools (e.g. OpenSSH with UsePAM=no) can bypass PAM even when it is available. > >This probably won't make you feel any better about it but perhaps it > >does explain the situation a little more. (And also that perhaps it > >is time to think about switching to a more standard shell. :-) At many sites, csh (or, more often these days, tcsh) *is* the standard shell. I give my users a choice of tcsh or bash, but that's mainly because I prefer bash myself; almost everybody else here uses tcsh. If you distribute the passwd database through a directory service (NIS, LDAP, or whatever) you probably have a documented procedure for configuring client systems (editing /etc/nsswitch.conf, etc.); make "apt-get install tcsh" a part of that procedure if tcsh is one of your supported shells. From dkg-openssh.com at fifthhorseman.net Mon Mar 26 02:43:10 2007 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 25 Mar 2007 12:43:10 -0400 Subject: Permissions on the ssh-agent socket In-Reply-To: <20070323152934.GA954@cip.informatik.uni-erlangen.de> (Alexander Wuerstlein's message of "Fri, 23 Mar 2007 16:29:34 +0100") References: <20070323152934.GA954@cip.informatik.uni-erlangen.de> Message-ID: <87ircpcm01.fsf@squeak.fifthhorseman.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri 2007-03-23 11:29:34 -0400, Alexander Wuerstlein wrote: > If I start an ssh-agent, it creates a socket (/tmp/ssh-*/agent.*), > with the socket's and the directory's permissions set to > 600. However, if I now connect to a remote host with > agent-forwarding enabled, the resulting socket on the remote host > gets permissions 755 (the directory still gets 700). > > What bothers me is the go+rx part, is there any specific reason to that? > If not, wouldn't it be better to be paranoid and use 600? I seem to recall that many Unices ignore permissions on sockets (i think linux does *not* ignore them), and usually rely on the parent directory for access control. I haven't been able to dig up a good authoritative reference for this, but here's a URL which implies the above. http://www.openldap.org/lists/openldap-software/200306/msg00106.html I think that setting the permissions restrictively would be wise (and consistent with the initial socket creation), but given the directory setup, it's not immediately critical. just my $0.02, --dkg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ iD8DBQFGBqaIiXTlFKVLY2URAi96AJ9yytiefpPhMbj+O7EWEqP3w20gIACePGC5 zKuTT1rMgGegru4j6Z2yE08= =LF+/ -----END PGP SIGNATURE----- From tim at multitalents.net Mon Mar 26 12:59:59 2007 From: tim at multitalents.net (Tim Rice) Date: Sun, 25 Mar 2007 19:59:59 -0700 (PDT) Subject: openssh 4.6p1 bug / IRIX In-Reply-To: <20070324100427.GA19780@gate.dtucker.net> References: <4603579E.9090101@ah-online.com> <4603682A.9050407@zip.com.au> <4604DF1F.1000408@ah-online.com> <20070324100427.GA19780@gate.dtucker.net> Message-ID: On Sat, 24 Mar 2007, Darren Tucker wrote: > On Sat, Mar 24, 2007 at 09:19:43AM +0100, g.fischer at ah-online.com wrote: > > > > thanks for the hints. > > i got it done by hardcoding the solution you mentioned. not nice but worked. > > > > maybe the check for the libiaf should be refined. > > This diff ought to do it (you will need to run "autoreconf" to rebuild > configure if you try this). It also prevents libiaf from being linked > to anything other than sshd, and then only if it's used. > > Hopefully this still works on the platforms that have libiaf (according > to the survey data, this includes UnixWare 2, 6 and 7). Tim? > > Index: auth.c auth.c bits are OK > Index: configure.ac Minor correction. ..... --- openssh/configure.ac.old 2007-03-24 15:23:31.521293001 -0700 +++ openssh/configure.ac 2007-03-25 19:26:00.029084007 -0700 @@ -1978,7 +1978,12 @@ # Search for SHA256 support in libc and/or OpenSSL AC_CHECK_FUNCS(SHA256_Update EVP_sha256) -AC_CHECK_LIB(iaf, ia_openinfo) +saved_LIBS="$LIBS" +AC_CHECK_LIB(iaf, ia_openinfo, [ + LIBS="$LIBS -liaf" + AC_CHECK_FUNCS(set_id, [SSHDLIBS="$SSHDLIBS -liaf"]) +]) +LIBS="$saved_LIBS" ### Configure cryptographic random number support ..... > Index: defines.h defines.h bits are OK > Index: session.c session.c bits are OK For completeness I think we should add these bits. .... --- openssh/openbsd-compat/port-uw.c.old 2006-09-06 14:33:55.391918000 -0700 +++ openssh/openbsd-compat/port-uw.c 2007-03-25 18:23:48.758604003 -0700 @@ -79,7 +79,7 @@ #endif /* UNIXWARE_LONG_PASSWORDS */ result = (strcmp(xcrypt(password, salt), pw_password) == 0); -#if !defined(BROKEN_LIBIAF) +#ifdef USE_LIBIAF if (authctxt->valid) free(pw_password); #endif @@ -127,7 +127,7 @@ functions that call shadow_pw() will need to free */ -#if !defined(BROKEN_LIBIAF) +#ifdef USE_LIBIAF char * get_iaf_password(struct passwd *pw) { @@ -144,6 +144,6 @@ else fatal("ia_openinfo: Unable to open the shadow passwd file"); } -#endif /* !BROKEN_LIBIAF */ +#endif /* USE_LIBIAF */ #endif /* HAVE_LIBIAF */ --- openssh/openbsd-compat/port-uw.h.old 2005-08-31 08:48:19.611180000 -0700 +++ openssh/openbsd-compat/port-uw.h 2007-03-25 18:24:10.148604002 -0700 @@ -24,7 +24,7 @@ #include "includes.h" -#if defined(HAVE_LIBIAF) && !defined(BROKEN_LIBIAF) +#ifdef USE_LIBIAF char * get_iaf_password(struct passwd *pw); #endif --- openssh/openbsd-compat/xcrypt.c.old 2006-09-06 14:33:55.971918000 -0700 +++ openssh/openbsd-compat/xcrypt.c 2007-03-25 18:24:25.728604004 -0700 @@ -98,7 +98,7 @@ pw_password = spw->sp_pwdp; # endif -#if defined(HAVE_LIBIAF) && !defined(BROKEN_LIBIAF) +#ifdef USE_LIBIAF return(get_iaf_password(pw)); #endif .... -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From jws at lindy.stanford.edu Tue Mar 27 08:39:43 2007 From: jws at lindy.stanford.edu (Jim Stosick) Date: Mon, 26 Mar 2007 15:39:43 -0700 Subject: 4.6p1 chan_read_failed error In-Reply-To: <20070324114902.GA8307@gate.dtucker.net> References: <46045AB6.6050903@lindy.stanford.edu> <20070324114902.GA8307@gate.dtucker.net> Message-ID: <46084BAF.2070601@lindy.stanford.edu> On 3/24/2007 4:49 AM, Darren Tucker wrote: > On Fri, Mar 23, 2007 at 03:54:46PM -0700, Jim Stosick wrote: >> The 4.6p1 sshd is logging this error during remote commands or file >> transfers: >> >> error: channel 0: chan_read_failed for istate 3 >> >> Platform is Solaris 8, 4.6p1 + OpenSSL 0.9.8d. > I suspect this is related to the change for bug #52. You could try > reverting the following patch ("patch -p1 -R") and see if the error > messages stop. Yes, that eliminates the chan_read_failed error messages. From snalwuer at cip.informatik.uni-erlangen.de Wed Mar 28 00:09:34 2007 From: snalwuer at cip.informatik.uni-erlangen.de (Alexander Wuerstlein) Date: Tue, 27 Mar 2007 16:09:34 +0200 Subject: Permissions on the ssh-agent socket In-Reply-To: <87ircpcm01.fsf@squeak.fifthhorseman.net> References: <20070323152934.GA954@cip.informatik.uni-erlangen.de> <87ircpcm01.fsf@squeak.fifthhorseman.net> Message-ID: <20070327140934.GD9752@cip.informatik.uni-erlangen.de> On 070325 18:44, Daniel Kahn Gillmor wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri 2007-03-23 11:29:34 -0400, Alexander Wuerstlein wrote: > > > If I start an ssh-agent, it creates a socket (/tmp/ssh-*/agent.*), > > with the socket's and the directory's permissions set to > > 600. However, if I now connect to a remote host with > > agent-forwarding enabled, the resulting socket on the remote host > > gets permissions 755 (the directory still gets 700). > > > > What bothers me is the go+rx part, is there any specific reason to that? > > If not, wouldn't it be better to be paranoid and use 600? > > I seem to recall that many Unices ignore permissions on sockets (i > think linux does *not* ignore them), and usually rely on the parent > directory for access control. > > I haven't been able to dig up a good authoritative reference for this, > but here's a URL which implies the above. > > http://www.openldap.org/lists/openldap-software/200306/msg00106.html > > I think that setting the permissions restrictively would be wise (and > consistent with the initial socket creation), but given the directory > setup, it's not immediately critical. I agree on the non-criticality, thanks for your opinion. Consider it a feature-request :) Ciao, Alexander Wuerstlein. From skeleten at shillest.net Wed Mar 28 12:46:18 2007 From: skeleten at shillest.net (Norihiko Murase) Date: Wed, 28 Mar 2007 11:46:18 +0900 Subject: (20070302) Warning messages on FreeBSD 4.11-RELEASE (Re: Call for release testing.) In-Reply-To: (Your message of "Sat, 03 Mar 2007 03:29:25 +0900") <20070303032925.69f425%skeleten@shillest.net> References: <45E6CCF6.2010501@zip.com.au> <20070303032925.69f425%skeleten@shillest.net> Message-ID: <20070328114618.5e58d5%skeleten@shillest.net> I did send the following message to this ML: http://lists.mindrot.org/pipermail/openssh-unix-dev/2007-March/025155.html From: Norihiko Murase Subject: (20070302) Warning messages on FreeBSD 4.11-RELEASE (Re: Call for release testing.) Message-ID: <20070303032925.69f425%skeleten at shillest.net> Date: Sat, 03 Mar 2007 03:29:25 +0900 These warning messages were displayed also when I built the snapshot 20070327. For the time being now, I applied the following patch: ----------(cut here)---------- --- defines.h.orig Thu Sep 21 22:13:30 2006 +++ defines.h Tue Mar 27 23:47:05 2007 @@ -48,5 +48,7 @@ # define IPTOS_RELIABILITY 0x04 # define IPTOS_LOWCOST 0x02 +#if 0 /* for FreeBSD 4.11-RELEASE */ # define IPTOS_MINCOST IPTOS_LOWCOST +#endif /* for FreeBSD 4.11-RELEASE */ #endif /* IPTOS_LOWDELAY */ @@ -69,7 +71,9 @@ #endif +#if 0 /* for FreeBSD 4.11-RELEASE */ #ifndef MAXSYMLINKS # define MAXSYMLINKS 5 #endif +#endif /* for FreeBSD 4.11-RELEASE */ #ifndef STDIN_FILENO @@ -336,7 +340,9 @@ #endif +#if 0 /* for FreeBSD 4.11-RELEASE */ #ifndef _PATH_STDPATH # define _PATH_STDPATH "/usr/bin:/bin:/usr/sbin:/sbin" #endif +#endif /* for FreeBSD 4.11-RELEASE */ #ifndef SUPERUSER_PATH @@ -356,11 +362,15 @@ #endif +#if 0 /* for FreeBSD 4.11-RELEASE */ #if !defined(_PATH_MAILDIR) && defined(MAILDIR) # define _PATH_MAILDIR MAILDIR #endif /* !defined(_PATH_MAILDIR) && defined(MAILDIR) */ +#endif /* for FreeBSD 4.11-RELEASE */ +#if 0 /* for FreeBSD 4.11-RELEASE */ #ifndef _PATH_NOLOGIN # define _PATH_NOLOGIN "/etc/nologin" #endif +#endif /* for FreeBSD 4.11-RELEASE */ /* Define this to be the path of the xauth program. */ @@ -488,7 +498,9 @@ #endif /* CMSG_FIRSTHDR */ +#if 0 /* for FreeBSD 4.11-RELEASE */ #ifndef offsetof # define offsetof(type, member) ((size_t) &((type *)0)->member) #endif +#endif /* for FreeBSD 4.11-RELEASE */ /* Set up BSD-style BYTE_ORDER definition if it isn't there already */ ----------(cut here)---------- I wonder what the best solution is... Thanks in advance, --- Norihiko Murase From dtucker at zip.com.au Wed Mar 28 15:13:07 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 28 Mar 2007 15:13:07 +1000 Subject: (20070302) Warning messages on FreeBSD 4.11-RELEASE (Re: Call for release testing.) In-Reply-To: <20070328114618.5e58d5%skeleten@shillest.net> References: <45E6CCF6.2010501@zip.com.au> <20070303032925.69f425%skeleten@shillest.net> <20070328114618.5e58d5%skeleten@shillest.net> Message-ID: <4609F963.6000900@zip.com.au> Norihiko Murase wrote: > I did send the following message to this ML: [...] Thanks for that, and apologies for not responding at the time. [...] > +#if 0 /* for FreeBSD 4.11-RELEASE */ > #ifndef MAXSYMLINKS > # define MAXSYMLINKS 5 > #endif > +#endif /* for FreeBSD 4.11-RELEASE */ [...] > I wonder what the best solution is... Now that we're trying to include headers once only from the .c file, the system includes where these are defined are no longer in includes.h and thus this kind of thing isn't defined when defines.h is read. They get defined in defines.h and again by the system headers, which generates the warning. One way I can see of dealing with these is to have configure check the settings at configure time and put them in config.h. An alternative would be to include "defines.h" after the system headers but before the compat headers. -- 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 Mar 28 22:02:40 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 28 Mar 2007 22:02:40 +1000 Subject: (20070302) Warning messages on FreeBSD 4.11-RELEASE (Re: Call for release testing.) In-Reply-To: <4609F963.6000900@zip.com.au> References: <45E6CCF6.2010501@zip.com.au> <20070303032925.69f425%skeleten@shillest.net> <20070328114618.5e58d5%skeleten@shillest.net> <4609F963.6000900@zip.com.au> Message-ID: <20070328120240.GA21541@gate.dtucker.net> On Wed, Mar 28, 2007 at 03:13:07PM +1000, Darren Tucker wrote: > Now that we're trying to include headers once only from the .c file, the > system includes where these are defined are no longer in includes.h > and thus this kind of thing isn't defined when defines.h is read. They > get defined in defines.h and again by the system headers, which > generates the warning. This is the kind of thing I meant. If you try it you will need to run "autoreconf" to rebuild configure, then rerun configure. Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/configure.ac,v retrieving revision 1.375 diff -u -p -r1.375 configure.ac --- configure.ac 26 Mar 2007 16:35:28 -0000 1.375 +++ configure.ac 28 Mar 2007 09:50:47 -0000 @@ -216,6 +216,7 @@ AC_CHECK_HEADERS( \ sys/mman.h \ sys/ndir.h \ sys/prctl.h \ + sys/param.h \ sys/pstat.h \ sys/select.h \ sys/stat.h \ @@ -1364,6 +1365,18 @@ AC_CHECK_DECLS(writev, , , [ #include ]) +AC_CHECK_DECLS(MAXSYMLINKS, , , [ +#include +#ifdef HAVE_SYS_PARAM_H +#include +#endif + ]) + +AC_CHECK_DECLS([_PATH_BSHELL, _PATH_CSHELL, _PATH_SHELLS, _PATH_STDPATH, + _PATH_DEVNULL, _PATH_NOLOGIN, _PATH_TTY], , , [ +#include + ]) + AC_CHECK_FUNCS(setresuid, [ dnl Some platorms have setresuid that isn't implemented, test for this AC_MSG_CHECKING(if setresuid seems to work) Index: defines.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/defines.h,v retrieving revision 1.139 diff -u -p -r1.139 defines.h --- defines.h 26 Mar 2007 16:35:28 -0000 1.139 +++ defines.h 28 Mar 2007 09:42:59 -0000 @@ -68,7 +68,7 @@ enum # endif #endif -#ifndef MAXSYMLINKS +#if HAVE_DECL_MAXSYMLINKS == 0 # define MAXSYMLINKS 5 #endif @@ -318,13 +318,13 @@ struct winsize { /* Paths */ -#ifndef _PATH_BSHELL +#if HAVE_DECL__PATH_BSHELL == 0 # define _PATH_BSHELL "/bin/sh" #endif -#ifndef _PATH_CSHELL +#if HAVE_DECL__PATH_CSHELL == 0 # define _PATH_CSHELL "/bin/csh" #endif -#ifndef _PATH_SHELLS +#if HAVE_DECL__PATH_SHELLS == 0 # define _PATH_SHELLS "/etc/shells" #endif @@ -335,7 +335,7 @@ struct winsize { # define _PATH_STDPATH USER_PATH #endif -#ifndef _PATH_STDPATH +#if HAVE_DECL__PATH_STDPATH == 0 # define _PATH_STDPATH "/usr/bin:/bin:/usr/sbin:/sbin" #endif @@ -343,7 +343,7 @@ struct winsize { # define SUPERUSER_PATH _PATH_STDPATH #endif -#ifndef _PATH_DEVNULL +#if HAVE_DECL__PATH_DEVNULL == 0 # define _PATH_DEVNULL "/dev/null" #endif @@ -359,7 +359,7 @@ struct winsize { # define _PATH_MAILDIR MAILDIR #endif /* !defined(_PATH_MAILDIR) && defined(MAILDIR) */ -#ifndef _PATH_NOLOGIN +#if HAVE_DECL__PATH_NOLOGIN == 0 # define _PATH_NOLOGIN "/etc/nologin" #endif @@ -378,7 +378,7 @@ struct winsize { #endif /* X_UNIX_PATH */ #define _PATH_UNIX_X X_UNIX_PATH -#ifndef _PATH_TTY +#if HAVE_DECL__PATH_TTY == 0 # define _PATH_TTY "/dev/tty" #endif -- 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 skeleten at shillest.net Thu Mar 29 19:08:03 2007 From: skeleten at shillest.net (Norihiko Murase) Date: Thu, 29 Mar 2007 18:08:03 +0900 Subject: (20070302) Warning messages on FreeBSD 4.11-RELEASE (Re: Call for release testing.) In-Reply-To: (Your message of "Wed, 28 Mar 2007 15:13:07 +1000") <4609F963.6000900@zip.com.au> References: <45E6CCF6.2010501@zip.com.au> <20070303032925.69f425%skeleten@shillest.net> <20070328114618.5e58d5%skeleten@shillest.net> <4609F963.6000900@zip.com.au> Message-ID: <20070329180803.6d61e4%skeleten@shillest.net> |From: Darren Tucker |Subject: (20070302) Warning messages on FreeBSD 4.11-RELEASE (Re: Call for release testing.) |Message-ID: <4609F963.6000900 at zip.com.au> |Date: Wed, 28 Mar 2007 15:13:07 +1000 | |>Thanks for that, and apologies for not responding at the time. Considering to release the new portable version for 4.6 ? :D~~ |>Now that we're trying to include headers once only from the .c file, the ...(snip)... |>generates the warning. Thank you very much for your explanation. You have given two solutions: ------------------------------------------------------------ (1) One way I can see of dealing with these is to have configure check the settings at configure time and put them in config.h. ------------------------------ (2) An alternative would be to include "defines.h" after the system headers but before the compat headers. ------------------------------------------------------------ I think * that the method (1) is really reliable but not elegant. * that the method (2) is elegant but dangerous, which might cause other kinds of trouble... When I checked includes.h and openbsd-compat/openbsd-compat.h, I noticed that these two headers do "#include" each other: ------------------------------------------------------------ %%%%% egrep -n '#include.*(includes|openbsd-compat)\.h' openbsd-compat/openbsd-compat.h includes.h openbsd-compat/openbsd-compat.h:32:#include "includes.h" includes.h:167:#include "openbsd-compat/openbsd-compat.h" %%%%% ------------------------------------------------------------ Is it done intentionally? Thanks, --- Norihiko Murase From skeleten at shillest.net Thu Mar 29 19:09:02 2007 From: skeleten at shillest.net (Norihiko Murase) Date: Thu, 29 Mar 2007 18:09:02 +0900 Subject: (20070302) Warning messages on FreeBSD 4.11-RELEASE (Re: Call for release testing.) In-Reply-To: (Your message of "Wed, 28 Mar 2007 22:02:40 +1000") <20070328120240.GA21541@gate.dtucker.net> References: <45E6CCF6.2010501@zip.com.au> <20070303032925.69f425%skeleten@shillest.net> <20070328114618.5e58d5%skeleten@shillest.net> <4609F963.6000900@zip.com.au> <20070328120240.GA21541@gate.dtucker.net> Message-ID: <20070329180902.6e47a0%skeleten@shillest.net> |From: Darren Tucker |Subject: (20070302) Warning messages on FreeBSD 4.11-RELEASE (Re: Call for release testing.) |Message-ID: <20070328120240.GA21541 at gate.dtucker.net> |Date: Wed, 28 Mar 2007 22:02:40 +1000 | |>This is the kind of thing I meant. If you try it you will need to run |>"autoreconf" to rebuild configure, then rerun configure. Ok, I am willing to test this. But, unfortunately I do NOT have Autoconf installed in the FreeBSD box I am using, so I would like you to send me the tarball which has the new configure script. Regards, --- Norihiko Murase From dtucker at zip.com.au Thu Mar 29 23:45:12 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 29 Mar 2007 23:45:12 +1000 Subject: (20070302) Warning messages on FreeBSD 4.11-RELEASE (Re: Call for release testing.) In-Reply-To: <20070329180902.6e47a0%skeleten@shillest.net> References: <45E6CCF6.2010501@zip.com.au> <20070303032925.69f425%skeleten@shillest.net> <20070328114618.5e58d5%skeleten@shillest.net> <4609F963.6000900@zip.com.au> <20070328120240.GA21541@gate.dtucker.net> <20070329180902.6e47a0%skeleten@shillest.net> Message-ID: <460BC2E8.80704@zip.com.au> Norihiko Murase wrote: > |From: Darren Tucker > |Subject: (20070302) Warning messages on FreeBSD 4.11-RELEASE (Re: Call for release testing.) > |Message-ID: <20070328120240.GA21541 at gate.dtucker.net> > |Date: Wed, 28 Mar 2007 22:02:40 +1000 > | > |>This is the kind of thing I meant. If you try it you will need to run > |>"autoreconf" to rebuild configure, then rerun configure. > > Ok, I am willing to test this. > > But, unfortunately I do NOT have Autoconf installed in the > FreeBSD box I am using, so I would like you to send me the > tarball which has the new configure script. I have put it up at: http://www.zip.com.au/~dtucker/tmp/openssh-defines.tar.gz Happy testing! -- 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 skeleten at shillest.net Sat Mar 31 01:48:12 2007 From: skeleten at shillest.net (Norihiko Murase) Date: Sat, 31 Mar 2007 00:48:12 +0900 Subject: (20070302) Warning messages on FreeBSD 4.11-RELEASE (Re: Call for release testing.) In-Reply-To: (Your message of "Thu, 29 Mar 2007 23:45:12 +1000") <460BC2E8.80704@zip.com.au> References: <45E6CCF6.2010501@zip.com.au> <20070303032925.69f425%skeleten@shillest.net> <20070328114618.5e58d5%skeleten@shillest.net> <4609F963.6000900@zip.com.au> <20070328120240.GA21541@gate.dtucker.net> <20070329180902.6e47a0%skeleten@shillest.net> <460BC2E8.80704@zip.com.au> Message-ID: <20070331004812.278b870%skeleten@shillest.net> |From: Darren Tucker |Subject: (20070302) Warning messages on FreeBSD 4.11-RELEASE (Re: Call for release testing.) |Message-ID: <460BC2E8.80704 at zip.com.au> |Date: Thu, 29 Mar 2007 23:45:12 +1000 | |>I have put it up at: |>http://www.zip.com.au/~dtucker/tmp/openssh-defines.tar.gz Thank you very much! I have tried building and have executed "make tests". As far as I have checked, some "macro-redefinition" warnings are still now displayed. I show you the detail with the summary of this problem. ------------------------------------------------------------ (0) I did find that two kinds of the warning messages were displayed when I tried building the snapshot 20070302 [M#01] and when I did the snapshot 20070327 [M#02]. These warning messages are as follows: warning: `**********' redefined warning: `__nonnull__' attribute directive ignored is "macro-redefinition" warnings that we mention. ---------- (1) Mr. Darren Tucker (dtucker) kindly created the patch for avoiding and put the tarball somewhere. [M#03] ---------- (2) I had tried building it from this tarball archive at 13:54 on Mar 30 (JST; GMT+0900) ---------- (3) I have noticed that some warnings are still now displayed. Compiler (/usr/bin/gcc) still now displays the warnings on the following macros: offsetof [openbsd-compat/bsd-closefrom.c authfile.c ssh.c ssh-keygen.c ssh-rand-helper.c] IPTOS_MINCOST [openbsd-compat/port-tun.c packet.c] _PATH_MAILDIR [readpass.c misc.c ssh.c clientloop.c sshconnect.c sshd.c sshpty.c auth.c session.c monitor.c loginrec.c ssh-keygen.c ssh-keysign.c ssh-agent.c sftp.c] and does the warnings. Happily, the warnings on the following macros are NOT displayed any longer: MAXSYMLINKS _PATH_STDPATH _PATH_NOLOGIN ------------------------------------------------------------ I attach the log file (compressed with bzip2), which includes * the information of the platform (% uname -a) * the options specified for the configure script * the result of "make" * the result of "make tests" I hope that it is useful for checking the detail. [M#01] http://lists.mindrot.org/pipermail/openssh-unix-dev/2007-March/025155.html From: Norihiko Murase Subject: (20070302) Warning messages on FreeBSD 4.11-RELEASE (Re: Call for release testing.) Message-ID: <20070303032925.69f425%skeleten at shillest.net> Date: Sat, 03 Mar 2007 03:29:25 +0900 [M#02] http://lists.mindrot.org/pipermail/openssh-unix-dev/2007-March/025229.html From: Norihiko Murase Subject: Re: (20070302) Warning messages on FreeBSD 4.11-RELEASE (Re: Call for release testing.) Message-Id: <20070328114618.5e58d5%skeleten at shillest.net> Date: Wed, 28 Mar 2007 11:46:18 +0900 [M#03] http://lists.mindrot.org/pipermail/openssh-unix-dev/2007-March/025234.html From: Darren Tucker Subject: Re: (20070302) Warning messages on FreeBSD 4.11-RELEASE (Re: Call for release testing.) Message-ID: <460BC2E8.80704 at zip.com.au> Date: Thu, 29 Mar 2007 23:45:12 +1000 Thank you very much, --- Norihiko Murase From skeleten at shillest.net Sat Mar 31 11:27:21 2007 From: skeleten at shillest.net (Norihiko Murase) Date: Sat, 31 Mar 2007 10:27:21 +0900 Subject: Log files In-Reply-To: (Your message of "Sat, 31 Mar 2007 00:48:12 +0900") <20070331004812.278b870%skeleten@shillest.net> References: <45E6CCF6.2010501@zip.com.au> <20070303032925.69f425%skeleten@shillest.net> <20070328114618.5e58d5%skeleten@shillest.net> <4609F963.6000900@zip.com.au> <20070328120240.GA21541@gate.dtucker.net> <20070329180902.6e47a0%skeleten@shillest.net> <460BC2E8.80704@zip.com.au> <20070331004812.278b870%skeleten@shillest.net> Message-ID: <20070331102721.ff573%skeleten@shillest.net> |From: Norihiko Murase |Subject: (20070302) Warning messages on FreeBSD 4.11-RELEASE (Re: Call for release testing.) |Message-ID: <20070331004812.278b870%skeleten at shillest.net> |Date: Sat, 31 Mar 2007 00:48:12 +0900 | |>I attach the log file (compressed with bzip2), which includes |> * the information of the platform (% uname -a) |> * the options specified for the configure script |> * the result of "make" |> * the result of "make tests" |>I hope that it is useful for checking the detail. Oops, I'm sorry that I've forgotten to attach this file. I do now. From skeleten at shillest.net Sat Mar 31 11:47:49 2007 From: skeleten at shillest.net (Norihiko Murase) Date: Sat, 31 Mar 2007 10:47:49 +0900 Subject: Log files In-Reply-To: (Your message of "Sat, 31 Mar 2007 10:27:21 +0900") <20070331102721.ff573%skeleten@shillest.net> References: <45E6CCF6.2010501@zip.com.au> <20070303032925.69f425%skeleten@shillest.net> <20070328114618.5e58d5%skeleten@shillest.net> <4609F963.6000900@zip.com.au> <20070328120240.GA21541@gate.dtucker.net> <20070329180902.6e47a0%skeleten@shillest.net> <460BC2E8.80704@zip.com.au> <20070331004812.278b870%skeleten@shillest.net> <20070331102721.ff573%skeleten@shillest.net> Message-ID: <20070331104749.22b466%skeleten@shillest.net> > Oops, I'm sorry that I've forgotten to attach this file. I do now. The file I attached might have been deleted... # "X-Content-Filtered-By: " I have put it up at: http://skeleten.shillest.net/test.log.bz2 N. Murase