From rac at tenzing.org Fri Sep 1 00:12:57 2006 From: rac at tenzing.org (Roger Cornelius) Date: Thu, 31 Aug 2006 10:12:57 -0400 Subject: Testing for the 4.4p1 release In-Reply-To: References: <20060830214416.GA7373@tenzing.org> Message-ID: <20060831141257.GA17008@tenzing.org> [4.4p1 on SCO OSR6 w/MP2] Thanks. The build now completes but 'make tests' fails at: run test login-timeout.sh ... /u1/src/rac/openssh/openssh/regress/login-timeout.sh: warning: line 18: `...` ob solete, use $(...) ssh_exchange_identification: Connection closed by remote host^M ssh connect after login grace timeout failed with privsep failed connect after login grace timeout make[1]: *** [t-exec] Error 1 make[1]: Leaving directory `/u1/src/rac/openssh/openssh/regress' make: *** [tests] Error 2 I won't be able to look into why it's failing until possibly tomorrow. I'll also need to test that updwtmpx() works correctly. 4.3p1 required me to build with -DBROKEN_WTMPX (which I didn't report), and I see it is not defined by configure for this platform. On 08/31/2006 12:04, Damien Miller wrote: > On Wed, 30 Aug 2006, Roger Cornelius wrote: > > > Build fails at port-uw.c: > > Thanks for the test. Could you please try this (big) diff? [diff deleted] -- Roger Cornelius rac at tenzing.org From imorgan at nas.nasa.gov Fri Sep 1 03:40:23 2006 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 31 Aug 2006 10:40:23 -0700 (PDT) Subject: Testing for the 4.4p1 release Message-ID: <200608311740.k7VHeNQs014197@ganymede.nas.nasa.gov> Sometime ago, Damien Miller wrote: [...] > Testing on suitable non-production systems is also appreciated. Please send > reports of success or failure to openssh-unix-dev at mindrot.org, including > details of your platform, compiler and configure options. > Configures, builds and tests OK on Solaris 9 with Sun Forte 7 C 5.4 compiler. However, there are a lot of warnings. A breakdown of the warnings follows: 162 "/usr/include/netinet/in.h", line 455: warning: macro redefined: IN6_IS_ADDR_V4MAPPED 162 "/usr/include/netinet/in.h", line 274: warning: macro redefined: INADDR_LOOPBACK 4 "/usr/include/iso/stddef_iso.h", line 73: warning: macro redefined: offsetof 1 "sftp-client.c", line 81: warning: assignment type mismatch: 1 "sftp-client.c", line 1066: warning: argument #3 is incompatible with prototype: 1 "serverloop.c", line 831: warning: argument #4 is incompatible with prototype: 1 "monitor.c", line 1306: warning: implicit function declaration: close 1 "loginrec.c", line 1609: warning: statement not reached 1 "hostfile.c", line 91: warning: argument #2 is incompatible with prototype: 1 "hostfile.c", line 134: warning: argument #1 is incompatible with prototype: 1 "hostfile.c", line 133: warning: argument #1 is incompatible with prototype: 1 "hostfile.c", line 130: warning: argument #2 is incompatible with prototype: 1 "hostfile.c", line 129: warning: argument #2 is incompatible with prototype: 1 "bsd-cray.c", line 818: warning: empty translation unit -- Iain Morgan From gert at greenie.muc.de Fri Sep 1 04:43:40 2006 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 31 Aug 2006 20:43:40 +0200 Subject: Testing for the 4.4p1 release In-Reply-To: References: Message-ID: <20060831184340.GA1140@greenie.muc.de> Hi, On Wed, Aug 30, 2006 at 11:41:53PM +1000, Damien Miller wrote: > The 4.4p1 release is approaching now, so we are now asking people to > actively test snapshots or CVS and report back to the mailing list. Tested CVS as of "Thu Aug 31 15:22:40 CEST 2006" on Host: sparc64-unknown-netbsd2.0.3. Compiler: gcc Compiler flags: -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare - configures and compiles just fine - "make tests" runs through without errors 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 rapier at psc.edu Fri Sep 1 05:25:49 2006 From: rapier at psc.edu (Chris Rapier) Date: Thu, 31 Aug 2006 15:25:49 -0400 Subject: Testing for the 4.4p1 release In-Reply-To: References: Message-ID: <44F737BD.100@psc.edu> OS X 10.4.7 Using: openssh-SNAP-20060901.tar.gz Config: No options Overview: Host: powerpc-apple-darwin8.7.0 Compiler: gcc Compiler flags: -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wno-pointer-sign Preprocessor flags: Linker flags: Libraries: -lcrypto -lz Warnings: servconf.c: In function 'process_server_config_line': servconf.c:624: warning: 'value' may be used uninitialized in this function servconf.c:626: warning: 'port' may be used uninitialized in this function readconf.c: In function 'process_config_line': readconf.c:327: warning: 'scale' may be used uninitialized in this function readconf.c:327: warning: 'value' may be used uninitialized in this function kexdhc.c: In function 'kexdh_client': kexdhc.c:48: warning: 'dh' may be used uninitialized in this function sftp.c: In function 'sdirent_comp': sftp.c:679: warning: control reaches end of non-void function Tests: Passed all tests From dtucker at zip.com.au Fri Sep 1 13:31:35 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 1 Sep 2006 13:31:35 +1000 Subject: Testing for the 4.4p1 release In-Reply-To: <20060830163521.GO20467@calimero.vinschen.de> References: <20060830163521.GO20467@calimero.vinschen.de> Message-ID: <20060901033135.GA17231@gate.dtucker.net> On Wed, Aug 30, 2006 at 06:35:21PM +0200, Corinna Vinschen wrote: > Cygwin 1.5.21, OpenSSL 0.9.8b Thanks for testing. [...] > Actually, OpenSSH didn't use Cygwin's glob() implementation before > (which is a relatively old NetBSD derived implementation), because the > configure test for gl_matchc failed up to 4.3p2. The AC_EGREP_CPP > autoconf test failed, while the new AC_TRY_COMPILE test in 4.4p1 now > works, so starting with 4.4p1, OpenSSH uses Cygwin's glob function. > > But why does it core dump? The reason is that the old glob implementation > in Cygwin doesn't know about the GLOB_NOMATCH return code. In case there's > no match, it returns 0, with gl_matchc set to 0 and gl_pathv set to NULL. I'm wondering if we should test for GLOB_NOMATCH in configure and use the glob in openbsd-compat if it's not found. This would avoid having to carry additional diffs in -portable. Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v retrieving revision 1.356 diff -u -p -r1.356 configure.ac --- configure.ac 30 Aug 2006 17:24:41 -0000 1.356 +++ configure.ac 1 Sep 2006 00:59:14 -0000 @@ -982,6 +982,8 @@ AC_TRY_COMPILE( ] ) +AC_CHECK_DECLS(GLOB_NOMATCH, , , [#include ]) + AC_MSG_CHECKING([whether struct dirent allocates space for d_name]) AC_RUN_IFELSE( [AC_LANG_SOURCE([[ Index: openbsd-compat/glob.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/glob.c,v retrieving revision 1.22 diff -u -p -r1.22 glob.c --- openbsd-compat/glob.c 6 Aug 2006 11:25:25 -0000 1.22 +++ openbsd-compat/glob.c 1 Sep 2006 00:59:14 -0000 @@ -47,7 +47,8 @@ #include #if !defined(HAVE_GLOB) || !defined(GLOB_HAS_ALTDIRFUNC) || \ - !defined(GLOB_HAS_GL_MATCHC) + !defined(GLOB_HAS_GL_MATCHC) || \ + !defined(HAVE_DECL_GLOB_NOMATCH) || HAVE_DECL_GLOB_NOMATCH == 0 static long get_arg_max(void) Index: openbsd-compat/glob.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/glob.h,v retrieving revision 1.8 diff -u -p -r1.8 glob.h --- openbsd-compat/glob.h 10 Nov 2005 06:03:23 -0000 1.8 +++ openbsd-compat/glob.h 1 Sep 2006 00:59:14 -0000 @@ -38,7 +38,8 @@ /* OPENBSD ORIGINAL: include/glob.h */ #if !defined(HAVE_GLOB_H) || !defined(GLOB_HAS_ALTDIRFUNC) || \ - !defined(GLOB_HAS_GL_MATCHC) + !defined(GLOB_HAS_GL_MATCHC) || \ + !defined(HAVE_DECL_GLOB_NOMATCH) || HAVE_DECL_GLOB_NOMATCH == 0 #ifndef _GLOB_H_ #define _GLOB_H_ -- 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 Fri Sep 1 15:42:38 2006 From: djm at mindrot.org (Damien Miller) Date: Fri, 1 Sep 2006 15:42:38 +1000 (EST) Subject: Testing for the 4.4p1 release In-Reply-To: <021c01c6ccf4$f6d99920$2d0110ac@samco> References: <021c01c6ccf4$f6d99920$2d0110ac@samco> Message-ID: On Thu, 31 Aug 2006, santhi wrote: > /usr/ccs/bin/ld: Unsatisfied symbols: > ntohl (first referenced in sshconnect.o) (code) > ntohs (first referenced in ssh.o) (code) > htonl (first referenced in sshconnect.o) (code) > htons (first referenced in > openbsd-compat//libopenbsd-compat.a(rresvport.o)) (code) > *** Error exit code 1 > > Stop. > > Problem Description: > ---------------------- > * The ntohl, ntohs, htonl, htons routines are defined as macros instead of > functions in , linker raises "functions" not found error. > > Fix: > ----- > Including the in includes.h file may fix this problem Thanks for the report - does the following diff help? Index: openbsd-compat/bindresvport.c =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/bindresvport.c,v retrieving revision 1.7 diff -u -p -r1.7 bindresvport.c --- openbsd-compat/bindresvport.c 24 Jul 2006 04:51:01 -0000 1.7 +++ openbsd-compat/bindresvport.c 1 Sep 2006 05:41:51 -0000 @@ -33,8 +33,10 @@ #include "includes.h" #ifndef HAVE_BINDRESVPORT_SA +#include +#include -#include "includes.h" +#include #include #include Index: openbsd-compat/rresvport.c =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/rresvport.c,v retrieving revision 1.10 diff -u -p -r1.10 rresvport.c --- openbsd-compat/rresvport.c 24 Aug 2006 09:53:41 -0000 1.10 +++ openbsd-compat/rresvport.c 1 Sep 2006 05:40:41 -0000 @@ -35,6 +35,11 @@ #ifndef HAVE_RRESVPORT_AF +#include +#include + +#include + #include #include #include From djm at mindrot.org Fri Sep 1 15:49:30 2006 From: djm at mindrot.org (Damien Miller) Date: Fri, 1 Sep 2006 15:49:30 +1000 (EST) Subject: Testing for the 4.4p1 release In-Reply-To: <200608311740.k7VHeNQs014197@ganymede.nas.nasa.gov> References: <200608311740.k7VHeNQs014197@ganymede.nas.nasa.gov> Message-ID: On Thu, 31 Aug 2006, Iain Morgan wrote: > Sometime ago, Damien Miller wrote: > [...] > > Testing on suitable non-production systems is also appreciated. Please send > > reports of success or failure to openssh-unix-dev at mindrot.org, including > > details of your platform, compiler and configure options. > > > > Configures, builds and tests OK on Solaris 9 with Sun Forte 7 C 5.4 > compiler. However, there are a lot of warnings. A breakdown of the > warnings follows: Thanks for the report - could you please try tonight's (20060902) snapshot? These should be fixed. -d From santhi.amirta at gmail.com Fri Sep 1 17:01:22 2006 From: santhi.amirta at gmail.com (santhi) Date: Fri, 1 Sep 2006 12:31:22 +0530 Subject: Testing for the 4.4p1 release References: <021c01c6ccf4$f6d99920$2d0110ac@samco> Message-ID: <018a01c6cd94$7cf51c10$2d0110ac@samco> > On Thu, 31 Aug 2006, santhi wrote: > > > /usr/ccs/bin/ld: Unsatisfied symbols: > > ntohl (first referenced in sshconnect.o) (code) > > ntohs (first referenced in ssh.o) (code) > > htonl (first referenced in sshconnect.o) (code) > > htons (first referenced in > > openbsd-compat//libopenbsd-compat.a(rresvport.o)) (code) > > *** Error exit code 1 > > > > Stop. > > > > Problem Description: > > ---------------------- > > * The ntohl, ntohs, htonl, htons routines are defined as macros instead of > > functions in , linker raises "functions" not found error. > > > > Fix: > > ----- > > Including the in includes.h file may fix this problem > > Thanks for the report - does the following diff help? > > Index: openbsd-compat/bindresvport.c > =================================================================== > RCS file: /var/cvs/openssh/openbsd-compat/bindresvport.c,v > retrieving revision 1.7 > diff -u -p -r1.7 bindresvport.c > --- openbsd-compat/bindresvport.c 24 Jul 2006 04:51:01 -0000 1.7 > +++ openbsd-compat/bindresvport.c 1 Sep 2006 05:41:51 -0000 > @@ -33,8 +33,10 @@ > #include "includes.h" > > #ifndef HAVE_BINDRESVPORT_SA > +#include > +#include > > -#include "includes.h" > +#include > > #include > #include > Index: openbsd-compat/rresvport.c > =================================================================== > RCS file: /var/cvs/openssh/openbsd-compat/rresvport.c,v > retrieving revision 1.10 > diff -u -p -r1.10 rresvport.c > --- openbsd-compat/rresvport.c 24 Aug 2006 09:53:41 -0000 1.10 > +++ openbsd-compat/rresvport.c 1 Sep 2006 05:40:41 -0000 > @@ -35,6 +35,11 @@ > > #ifndef HAVE_RRESVPORT_AF > > +#include > +#include > + > +#include > + > #include > #include > #include Affected files are 01) channels.c 02) ssh.c 03) openbsd-compat/bindresvport.c 04) openbsd-compat/fake-rfc2553.c 05) openbsd-compat/getrrsetbyname.c 06) openbsd-compat/rresvport.c 07) sshconnect.c 08) openbsd-compat/port-tun.c 09) ssh-rand-helper.c 10) ssh-keyscan.c 11) openbsd-compat/bsd-cray.c 12) openbsd-compat/inet_aton.c Among the above files, the patch is applied to "bindresvport.c" and "rresvport.c". But we get the same linker error, while we compile other files. Any suggestions? Note: We found that file is missing in includes.h file. Thanks, Santhi. From vinschen at redhat.com Fri Sep 1 18:44:17 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 1 Sep 2006 10:44:17 +0200 Subject: Testing for the 4.4p1 release In-Reply-To: <20060901033135.GA17231@gate.dtucker.net> References: <20060830163521.GO20467@calimero.vinschen.de> <20060901033135.GA17231@gate.dtucker.net> Message-ID: <20060901084417.GA18993@calimero.vinschen.de> On Sep 1 13:31, Darren Tucker wrote: > On Wed, Aug 30, 2006 at 06:35:21PM +0200, Corinna Vinschen wrote: > > Cygwin 1.5.21, OpenSSL 0.9.8b > > Thanks for testing. > > [...] > > Actually, OpenSSH didn't use Cygwin's glob() implementation before > > (which is a relatively old NetBSD derived implementation), because the > > configure test for gl_matchc failed up to 4.3p2. The AC_EGREP_CPP > > autoconf test failed, while the new AC_TRY_COMPILE test in 4.4p1 now > > works, so starting with 4.4p1, OpenSSH uses Cygwin's glob function. > > > > But why does it core dump? The reason is that the old glob implementation > > in Cygwin doesn't know about the GLOB_NOMATCH return code. In case there's > > no match, it returns 0, with gl_matchc set to 0 and gl_pathv set to NULL. > > I'm wondering if we should test for GLOB_NOMATCH in configure and use > the glob in openbsd-compat if it's not found. This would avoid having > to carry additional diffs in -portable. Good idea! I tested your patch and it works, if another glob related expression is changed in includes.h: Index: includes.h =================================================================== RCS file: /cvs/openssh/includes.h,v retrieving revision 1.125 diff -p -u -r1.125 includes.h --- includes.h 1 Sep 2006 05:48:19 -0000 1.125 +++ includes.h 1 Sep 2006 08:42:22 -0000 @@ -30,7 +30,8 @@ # include #endif #if defined(HAVE_GLOB_H) && defined(GLOB_HAS_ALTDIRFUNC) && \ - defined(GLOB_HAS_GL_MATCHC) + defined(GLOB_HAS_GL_MATCHC) && \ + defined(HAVE_DECL_GLOB_NOMATCH) && HAVE_DECL_GLOB_NOMATCH != 0 # include #endif #ifdef HAVE_ENDIAN_H Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vinschen at redhat.com Fri Sep 1 19:10:56 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 1 Sep 2006 11:10:56 +0200 Subject: [PATCH] Cygwin: Avoid implicit declaration warnings Message-ID: <20060901091056.GB18993@calimero.vinschen.de> Hi, I have left this slip through already too long. When compiling openbsd-compat/bsd-cygwin_util.c, the following warnings appear: openbsd-compat/bsd-cygwin_util.c: In function `binary_open': openbsd-compat/bsd-cygwin_util.c:67: warning: implicit declaration of function `open' openbsd-compat/bsd-cygwin_util.c: In function `binary_pipe': openbsd-compat/bsd-cygwin_util.c:73: warning: implicit declaration of function `pipe' The below patch fixes that. Index: openbsd-compat/bsd-cygwin_util.c =================================================================== RCS file: /cvs/openssh/openbsd-compat/bsd-cygwin_util.c,v retrieving revision 1.18 diff -p -u -r1.18 bsd-cygwin_util.c --- openbsd-compat/bsd-cygwin_util.c 5 Aug 2006 09:08:17 -0000 1.18 +++ openbsd-compat/bsd-cygwin_util.c 1 Sep 2006 08:42:22 -0000 @@ -31,6 +31,13 @@ #ifdef HAVE_CYGWIN +#if defined(open) && open == binary_open +# undef open +#endif +#if defined(pipe) && open == binary_pipe +# undef pipe +#endif + #include #include #include @@ -47,13 +54,6 @@ #define ntsec_on(c) ((c) && strstr((c),"ntsec") && !strstr((c),"nontsec")) #define ntsec_off(c) ((c) && strstr((c),"nontsec")) #define ntea_on(c) ((c) && strstr((c),"ntea") && !strstr((c),"nontea")) - -#if defined(open) && open == binary_open -# undef open -#endif -#if defined(pipe) && open == binary_pipe -# undef pipe -#endif int binary_open(const char *filename, int flags, ...) Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From imorgan at nas.nasa.gov Sat Sep 2 03:19:59 2006 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 1 Sep 2006 10:19:59 -0700 (PDT) Subject: Testing for the 4.4p1 release In-Reply-To: from Damien Miller at "Sep 1, 2006 03:49:30 pm" Message-ID: <200609011720.k81HK0wr012626@ganymede.nas.nasa.gov> Sometime ago, Damien Miller wrote: > On Thu, 31 Aug 2006, Iain Morgan wrote: > > > Sometime ago, Damien Miller wrote: > > [...] > > > Testing on suitable non-production systems is also appreciated. Please send > > > reports of success or failure to openssh-unix-dev at mindrot.org, including > > > details of your platform, compiler and configure options. > > > > > > > Configures, builds and tests OK on Solaris 9 with Sun Forte 7 C 5.4 > > compiler. However, there are a lot of warnings. A breakdown of the > > warnings follows: > > Thanks for the report - could you please try tonight's (20060902) > snapshot? These should be fixed. > I just tried the 0902 snapshot. The vast majority of the warnigns are now fixed. There are still 14 warnings, but I can live with that. Thanks. "bsd-cray.c", line 819: warning: empty translation unit "/usr/include/iso/stddef_iso.h", line 73: warning: macro redefined: offsetof "hostfile.c", line 92: warning: argument #2 is incompatible with prototype: "hostfile.c", line 130: warning: argument #2 is incompatible with prototype: "hostfile.c", line 131: warning: argument #2 is incompatible with prototype: "hostfile.c", line 134: warning: argument #1 is incompatible with prototype: "hostfile.c", line 135: warning: argument #1 is incompatible with prototype: "/usr/include/iso/stddef_iso.h", line 73: warning: macro redefined: offsetof "serverloop.c", line 831: warning: argument #4 is incompatible with prototype: "loginrec.c", line 1610: warning: statement not reached "/usr/include/iso/stddef_iso.h", line 73: warning: macro redefined: offsetof "/usr/include/iso/stddef_iso.h", line 73: warning: macro redefined: offsetof "sftp-client.c", line 81: warning: assignment type mismatch: "sftp-client.c", line 1066: warning: argument #3 is incompatible with prototype: -- Iain Morgan From imorgan at nas.nasa.gov Sat Sep 2 05:14:49 2006 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 1 Sep 2006 12:14:49 -0700 (PDT) Subject: Testing for the 4.4p1 release In-Reply-To: <200608302305.k7UN5CoD015796@ganymede.nas.nasa.gov> from Iain Morgan at "Aug 30, 2006 04:05:12 pm" Message-ID: <200609011914.k81JEnMi031660@ganymede.nas.nasa.gov> Sometime ago, Iain Morgan wrote: > Sometime ago, Damien Miller wrote: > [...] > > Testing on suitable non-production systems is also appreciated. Please send > > reports of success or failure to openssh-unix-dev at mindrot.org, including > > details of your platform, compiler and configure options. > > > > The 20060830 snapshot configures, but fails to build on IRIX 6.5.29 > usign the MIPSpro 7.4 compilers. > > > export CC=c99 > export CFLAGS="-g -O3 -mips3 -r14000" > > PREFIX=/usr/prg/pkg/openssh/4.4p1 > OPENSSL=$HOME/build > ZLIB=$HOME/build > > ./configure --prefix=$PREFIX \ > --sysconfdir=/usr/prg/etc \ > --with-ssl-dir=$OPENSSL \ > --with-zlib=$ZLIB \ > --with-tcp-wrappers=/usr/local \ > --with-md5-passwords \ > --with-pam > > There are numberous warnings, but here's the part that causes the > compile to fail: > Adding to the headers included in port-irix.c allows the build to complete. Using c99, there are only 92 warnings, whereas using cc there are 251. A reasonable number of the 92 warnings are due to macro redefinition: 14 Macro "_PATH_MAILDIR" (declared at line 359 of "defines.h") has an 14 Macro "_PATH_BSHELL" (declared at line 322 of "defines.h") has an incompatible 5 Macro "offsetof" (declared at line 491 of "defines.h") has an incompatible 1 Macro "offsetof" (declared at line 491 of "../defines.h") has an incompatible Also, moving -lgen from LIBS to SSHDLIBS would eliminate 10 additional warnings. I haven't had time to deal with the regression tests yet. The protocol 1 tests always seem to be a problem with IRIX. (I reported this once quite a while ago, but did not have the time to investigate.) In the past, I've hacked the scripts to only test protocol 2, in which case everything (that we care about) is fine. -- Iain Morgan From rac at tenzing.org Sat Sep 2 09:45:19 2006 From: rac at tenzing.org (Roger Cornelius) Date: Fri, 1 Sep 2006 19:45:19 -0400 Subject: Testing for the 4.4p1 release In-Reply-To: <20060831141257.GA17008@tenzing.org> References: <20060830214416.GA7373@tenzing.org> <20060831141257.GA17008@tenzing.org> Message-ID: <20060901234519.GA20849@tenzing.org> [ SCO OSR6 w/mp2 using system compiler, SNAP-20060902 ] On 08/31/2006 10:12, Roger Cornelius wrote: > [4.4p1 on SCO OSR6 w/MP2] > > Thanks. The build now completes but 'make tests' fails at: > > run test login-timeout.sh ... > /u1/src/rac/openssh/openssh/regress/login-timeout.sh: warning: line 18: `...` ob > solete, use $(...) > ssh_exchange_identification: Connection closed by remote host^M > ssh connect after login grace timeout failed with privsep > failed connect after login grace timeout > make[1]: *** [t-exec] Error 1 > make[1]: Leaving directory `/u1/src/rac/openssh/openssh/regress' > make: *** [tests] Error 2 > > I won't be able to look into why it's failing until possibly tomorrow. > I'll also need to test that updwtmpx() works correctly. 4.3p1 required > me to build with -DBROKEN_WTMPX (which I didn't report), and I see it is > not defined by configure for this platform. OK, I apparently have a dns issue that is causing regress/login-timout.sh to timeout and fail. 'make tests' completes without error after increasing the duration of the sleeps in that script (I've noticed for the last week or so that connecting to this system with ssh takes an unusually long time). OSR6 does need BROKEN_UPDWTMP defined. Otherwise wtmp gets trashed when someone connects via ssh. This can be seen by running /bin/last after a ssh login. Here's an example of last output after a ssh connection (I didn't save a pre-4.4p1 example of last output but it was valid): User Line Device PID Login time Elapsed Time Comments rac s007 pts007 12911 Wed Jul 8 21:48-1169-9:-21 rac s006 pts006 12893 Sun Nov 3 20:52 1783320:20 rac s006 pts006 12882 Mon Feb 11 04:48 7568d11:56 rac s006 pts006 12871 Sun Feb 26 02:08-1609-19:-7 rac s006 pts006 12849 Thu Jun 1 09:43-1680-17:-40 rac s004 pts004 10957 Tue Nov 29 04:34 -1178-9:-4 rac c01 tty01 3449 Mon Dec 31 19:04 2215823:23 logged in root c01 tty01 2034 Wed Sep 5 05:51-1412-9:-46 ?? rac s005 pts005 7158 Sun Sep 6 09:48 1153607:23 rac s005 pts005 24076 Fri Nov 22 06:46 8368d17:38 Here is a list of the warnings generated by make: cc -I /u/include -I. -I.. -I. -I./.. -I/u/etc/openssl/include -DHAVE_CONFIG_H -c bsd-closefrom.c UX:acomp: WARNING: "/usr/include/stddef.h", line 39: macro redefined: offsetof cc -I /u/include -I. -I.. -I. -I./.. -I/u/etc/openssl/include -DHAVE_CONFIG_H -c bsd-cray.c UX:acomp: WARNING: "bsd-cray.c", line 820: empty translation unit cc -I /u/include -I. -I.. -I. -I./.. -I/u/etc/openssl/include -DHAVE_CONFIG_H -c glob.c UX:acomp: WARNING: "glob.c", line 619: assignment type mismatch cc -I /u/include -I. -I. -I/u/etc/openssl/include -DSSHDIR=\"/u/etc/openssh-4.4p1\" -D_PATH_SSH_PROGRAM=\"/u/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/u/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/u/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/u/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/u/etc/openssh-4.4p1\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/u/var/empty\" -DSSH_RAND_HELPER=\"/u/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c authfile.c UX:acomp: WARNING: "/usr/include/stddef.h", line 39: macro redefined: offsetof cc -I /u/include -I. -I. -I/u/etc/openssl/include -DSSHDIR=\"/u/etc/openssh-4.4p1\" -D_PATH_SSH_PROGRAM=\"/u/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/u/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/u/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/u/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/u/etc/openssh-4.4p1\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/u/var/empty\" -DSSH_RAND_HELPER=\"/u/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c hostfile.c UX:acomp: WARNING: "hostfile.c", line 92: argument #2 incompatible with prototype: b64_pton() UX:acomp: WARNING: "hostfile.c", line 130: argument #2 incompatible with prototype: HMAC_Update() UX:acomp: WARNING: "hostfile.c", line 131: argument #2 incompatible with prototype: HMAC_Final() UX:acomp: WARNING: "hostfile.c", line 134: argument #1 incompatible with prototype: b64_ntop() UX:acomp: WARNING: "hostfile.c", line 135: argument #1 incompatible with prototype: b64_ntop() cc -I /u/include -I. -I. -I/u/etc/openssl/include -DSSHDIR=\"/u/etc/openssh-4.4p1\" -D_PATH_SSH_PROGRAM=\"/u/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/u/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/u/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/u/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/u/etc/openssh-4.4p1\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/u/var/empty\" -DSSH_RAND_HELPER=\"/u/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c ssh.c UX:acomp: WARNING: "/usr/include/stddef.h", line 39: macro redefined: offsetof cc -I /u/include -I. -I. -I/u/etc/openssl/include -DSSHDIR=\"/u/etc/openssh-4.4p1\" -D_PATH_SSH_PROGRAM=\"/u/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/u/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/u/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/u/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/u/etc/openssh-4.4p1\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/u/var/empty\" -DSSH_RAND_HELPER=\"/u/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c auth-rhosts.c UX:acomp: WARNING: "auth-rhosts.c", line 131: argument #2 incompatible with prototype: innetgr() UX:acomp: WARNING: "auth-rhosts.c", line 132: argument #2 incompatible with prototype: innetgr() UX:acomp: WARNING: "auth-rhosts.c", line 139: argument #3 incompatible with prototype: innetgr() cc -I /u/include -I. -I. -I/u/etc/openssl/include -DSSHDIR=\"/u/etc/openssh-4.4p1\" -D_PATH_SSH_PROGRAM=\"/u/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/u/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/u/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/u/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/u/etc/openssh-4.4p1\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/u/var/empty\" -DSSH_RAND_HELPER=\"/u/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c serverloop.c UX:acomp: WARNING: "serverloop.c", line 831: argument #4 incompatible with prototype: wait_until_can_do_something() cc -I /u/include -I. -I. -I/u/etc/openssl/include -DSSHDIR=\"/u/etc/openssh-4.4p1\" -D_PATH_SSH_PROGRAM=\"/u/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/u/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/u/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/u/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/u/etc/openssh-4.4p1\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/u/var/empty\" -DSSH_RAND_HELPER=\"/u/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c ssh-keygen.c UX:acomp: WARNING: "/usr/include/stddef.h", line 39: macro redefined: offsetof cc -I /u/include -I. -I. -I/u/etc/openssl/include -DSSHDIR=\"/u/etc/openssh-4.4p1\" -D_PATH_SSH_PROGRAM=\"/u/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/u/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/u/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/u/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/u/etc/openssh-4.4p1\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/u/var/empty\" -DSSH_RAND_HELPER=\"/u/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c ssh-rand-helper.c UX:acomp: WARNING: "/usr/include/stddef.h", line 39: macro redefined: offsetof cc -I /u/include -I. -I. -I/u/etc/openssl/include -DSSHDIR=\"/u/etc/openssh-4.4p1\" -D_PATH_SSH_PROGRAM=\"/u/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/u/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/u/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/u/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/u/etc/openssh-4.4p1\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/u/var/empty\" -DSSH_RAND_HELPER=\"/u/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c sftp-client.c UX:acomp: WARNING: "sftp-client.c", line 1066: argument #3 incompatible with prototype: start_progress_meter() cc -I /u/include -I. -I. -I/u/etc/openssl/include -DSSHDIR=\"/u/etc/openssh-4.4p1\" -D_PATH_SSH_PROGRAM=\"/u/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/u/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/u/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/u/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/u/etc/openssh-4.4p1\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/u/var/empty\" -DSSH_RAND_HELPER=\"/u/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c sftp-glob.c UX:acomp: WARNING: "sftp-glob.c", line 140: assignment type mismatch -- Roger Cornelius rac at tenzing.org From david-bronder at uiowa.edu Sat Sep 2 11:14:51 2006 From: david-bronder at uiowa.edu (David Bronder) Date: Fri, 1 Sep 2006 20:14:51 -0500 (CDT) Subject: [openssh-unix-dev] Testing for the 4.4p1 release In-Reply-To: from "Damien Miller" at Aug 30, 2006 11:41:53 PM Message-ID: <200609020114.k821Epjn089336@fire.its.uiowa.edu> Damien Miller wrote: > > The 4.4p1 release is approaching now, so we are now asking people to > actively test snapshots or CVS and report back to the mailing list. [AIX 5.1 ML5, IBM VAC 6 compiler, openssh-SNAP-20060902] Fails to build. See below for details. Same result with a stripped down configure line (just adding --with-zlib=/usr/local). ----- $ ./configure --libexecdir='${exec_prefix}/bin' --sysconfdir=/etc/ssh --with-pid-dir=/etc/ssh --with-privsep-path=/var/empty/sshd --with-tcp-wrappers=/local/admin --with-zlib=/usr/local --with-xauth=/usr/bin/X11/xauth --with-cflags="-O3 -qstrict" OpenSSH has been configured with the following options: User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /etc/ssh Askpass program: /usr/local/bin/ssh-askpass Manual pages: /usr/local/share/man/manX PID file: /etc/ssh Privilege separation chroot path: /var/empty/sshd sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin Manpage format: man PAM support: no OSF SIA support: no KerberosV support: no SELinux support: no Smartcard support: no S/KEY support: no TCP Wrappers support: yes MD5 password support: no libedit support: no Solaris process contract support: no IP address in $DISPLAY hack: no Translate v4 in v6 hack: no BSD Auth support: no Random number source: OpenSSL internal ONLY Host: powerpc-ibm-aix5.1.0.0 Compiler: cc -qlanglvl=ansi Compiler flags: -g -O3 -qstrict Preprocessor flags: -I/local/admin/include -I/usr/local/include Linker flags: -L/local/admin/lib -L/usr/local/lib -blibpath:/usr/lib:/lib Libraries: -lwrap -lcrypto -lz WARNING: the operating system that you are using does not appear to support either the getpeereid() API nor the SO_PEERCRED getsockopt() option. These facilities are used to enforce security checks to prevent unauthorised connections to ssh-agent. Their absence increases the risk that a malicious user can connect to your agent. ----- I can provide full compile log, but didn't want to mail it to the list. Here are some highlights. Lots of the following warnings: "/usr/include/usersec.h", line 625.32: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. "/usr/include/usersec.h", line 626.34: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. Then for the last two files before failing: cc -qlanglvl=ansi -g -O3 -qstrict -I. -I. -I/local/admin/include -I/usr/local/include -DSSHDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/bin/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/bin/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/bin/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/etc/ssh\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty/sshd\" -DSSH_RAND_HELPER=\"/usr/local/bin/ssh-rand-helper\" -DHAVE_CONFIG_H -c packet.c "/usr/include/usersec.h", line 625.32: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. "/usr/include/usersec.h", line 626.34: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. "packet.c", line 162.12: 1506-010 (E) Macro TAILQ_HEAD invoked with a null argument for parameter name. cc -qlanglvl=ansi -g -O3 -qstrict -I. -I. -I/local/admin/include -I/usr/local/include -DSSHDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/bin/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/bin/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/bin/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/etc/ssh\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty/sshd\" -DSSH_RAND_HELPER=\"/usr/local/bin/ssh-rand-helper\" -DHAVE_CONFIG_H -c readpass.c "/usr/include/usersec.h", line 625.32: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. "/usr/include/usersec.h", line 626.34: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. "/usr/include/paths.h", line 50.9: 1506-213 (S) Macro name _PATH_BSHELL cannot be redefined. "/usr/include/paths.h", line 50.9: 1506-358 (I) "_PATH_BSHELL" is defined on line 322 of defines.h. "/usr/include/paths.h", line 52.9: 1506-213 (S) Macro name _PATH_CSHELL cannot be redefined. "/usr/include/paths.h", line 52.9: 1506-358 (I) "_PATH_CSHELL" is defined on line 325 of defines.h. "/usr/include/paths.h", line 57.9: 1506-213 (S) Macro name _PATH_MAILDIR cannot be redefined. "/usr/include/paths.h", line 57.9: 1506-358 (I) "_PATH_MAILDIR" is defined on line 359 of defines.h. make: The error code from the last command is 1. Stop. -- Hello World. David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bronder at uiowa.edu From david-bronder at uiowa.edu Sat Sep 2 10:42:26 2006 From: david-bronder at uiowa.edu (David Bronder) Date: Fri, 1 Sep 2006 19:42:26 -0500 (CDT) Subject: [openssh-unix-dev] Testing for the 4.4p1 release In-Reply-To: from "Damien Miller" at Aug 30, 2006 11:41:53 PM Message-ID: <200609020042.k820gQUN070068@fire.its.uiowa.edu> Damien Miller wrote: > > The 4.4p1 release is approaching now, so we are now asking people to > actively test snapshots or CVS and report back to the mailing list. [AIX 5.2 ML4, IBM VAC 6 compiler, openssh-SNAP-20060902] Builds (with some warnings) and tests OK (some exceptions). See below for details. $ ./configure --libexecdir='${exec_prefix}/bin' --sysconfdir=/etc/ssh --with-pid-dir=/etc/ssh --with-privsep-path=/var/empty/sshd --with-tcp-wrappers=/local/admin --with-zlib=/usr/local --with-xauth=/usr/bin/X11/xauth --with-cflags="-O3 -qstrict" OpenSSH has been configured with the following options: User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /etc/ssh Askpass program: /usr/local/bin/ssh-askpass Manual pages: /usr/local/share/man/manX PID file: /etc/ssh Privilege separation chroot path: /var/empty/sshd sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin Manpage format: man PAM support: no OSF SIA support: no KerberosV support: no SELinux support: no Smartcard support: no S/KEY support: no TCP Wrappers support: yes MD5 password support: no libedit support: no Solaris process contract support: no IP address in $DISPLAY hack: no Translate v4 in v6 hack: no BSD Auth support: no Random number source: OpenSSL internal ONLY Host: powerpc-ibm-aix5.2.0.0 Compiler: cc -qlanglvl=extc89 Compiler flags: -g -O3 -qstrict Preprocessor flags: -I/local/admin/include -I/usr/local/include Linker flags: -L/local/admin/lib -L/usr/local/lib -blibpath:/usr/lib:/lib Libraries: -lwrap -lcrypto -lz At compile time, most (all) files produce the following warnings: "/usr/include/syms.h", line 288.9: 1506-236 (W) Macro name T_NULL has been redefined. "/usr/include/syms.h", line 288.9: 1506-358 (I) "T_NULL" is defined on line 150 of /usr/include/arpa/onameser_compat.h. And some files also produce: "/usr/include/paths.h", line 50.9: 1506-236 (W) Macro name _PATH_BSHELL has been redefined. "/usr/include/paths.h", line 50.9: 1506-358 (I) "_PATH_BSHELL" is defined on line 322 of defines.h. "/usr/include/paths.h", line 52.9: 1506-236 (W) Macro name _PATH_CSHELL has been redefined. "/usr/include/paths.h", line 52.9: 1506-358 (I) "_PATH_CSHELL" is defined on line 325 of defines.h. "/usr/include/paths.h", line 57.9: 1506-236 (W) Macro name _PATH_MAILDIR has been redefined. "/usr/include/paths.h", line 57.9: 1506-358 (I) "_PATH_MAILDIR" is defined on line 359 of defines.h. All tests OK except for: agent-getpeereid.sh [skipped: need SUDO to switch to uid nobody] agent-ptrace.sh [skipped (not supported on this platform)] dynamic-forward.sh [skipped (no suitable ProxyCommand found)] I can provide full compile log, but didn't want to mail it to the list. -- Hello World. David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bronder at uiowa.edu From dtucker at zip.com.au Sat Sep 2 12:21:28 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 02 Sep 2006 12:21:28 +1000 Subject: Testing for the 4.4p1 release In-Reply-To: <20060901234519.GA20849@tenzing.org> References: <20060830214416.GA7373@tenzing.org> <20060831141257.GA17008@tenzing.org> <20060901234519.GA20849@tenzing.org> Message-ID: <44F8EAA8.6010103@zip.com.au> Roger Cornelius wrote: > [ SCO OSR6 w/mp2 using system compiler, SNAP-20060902 ] [...] > OSR6 does need BROKEN_UPDWTMP defined. Otherwise wtmp gets trashed when > someone connects via ssh. This can be seen by running /bin/last > after a ssh login. Here's an example of last output after a ssh > connection (I didn't save a pre-4.4p1 example of last output but it > was valid): Hi and thanks. What does ./config.guess report that platform to be, so we can add BROKEN_UPDWTMP to configure? -- 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 Sep 2 13:03:24 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 02 Sep 2006 13:03:24 +1000 Subject: Testing for the 4.4p1 release In-Reply-To: <200609011914.k81JEnMi031660@ganymede.nas.nasa.gov> References: <200609011914.k81JEnMi031660@ganymede.nas.nasa.gov> Message-ID: <44F8F47C.9010508@zip.com.au> Hi, and thanks for testing. Iain Morgan wrote: > Sometime ago, Iain Morgan wrote: >> The 20060830 snapshot configures, but fails to build on IRIX 6.5.29 >> usign the MIPSpro 7.4 compilers. [...] > Adding to the headers included in port-irix.c allows the build > to complete. This has been added, thanks. > Using c99, there are only 92 warnings, whereas using cc there are 251. > A reasonable number of the 92 warnings are due to macro redefinition: > > 14 Macro "_PATH_MAILDIR" (declared at line 359 of "defines.h") has an > 14 Macro "_PATH_BSHELL" (declared at line 322 of "defines.h") has an > incompatible These are defined in /usr/include/paths.h, right? I think we should put that back into includes.h or maybe defines.h, because the ones we default to in defines.h may not be right. > 5 Macro "offsetof" (declared at line 491 of "defines.h") has an > incompatible > 1 Macro "offsetof" (declared at line 491 of "../defines.h") has an > incompatible Which system header defines that? > Also, moving -lgen from LIBS to SSHDLIBS would eliminate 10 additional > warnings. If it's not a critical problem I'd prefer to wait until after the release to do any library reshuffles, but there is definitely some room for improvement. > I haven't had time to deal with the regression tests yet. The protocol 1 > tests always seem to be a problem with IRIX. (I reported this once quite > a while ago, but did not have the time to investigate.) In the past, > I've hacked the scripts to only test protocol 2, in which case > everything (that we care about) is fine. The only time I've ever seen protocol 1 specifically fail regress tests is on Solaris 10 with the bundled OpenSSL, and that's because any crypto with a key length >128bit had been crippled including the blowfish cipher that protocol 1 uses. (It also included the AES functions, but OpenSSH has its own implementation of those and now uses them if it finds the native ones don't work.) When I'm trying to debug regress tests (which, I'll admit, isn't easy) I do something like the attached patch, which stops immediately after the failure without cleaning up. I then rerun the failing command with extra debugging (usually ssh -vvv [lots of args]) which can help shed some light on the failure. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-regress-debug.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20060902/d9a8ba1b/attachment.ksh From rac at tenzing.org Sat Sep 2 13:13:51 2006 From: rac at tenzing.org (Roger Cornelius) Date: Fri, 1 Sep 2006 23:13:51 -0400 Subject: Testing for the 4.4p1 release In-Reply-To: <44F8EAA8.6010103@zip.com.au> References: <20060830214416.GA7373@tenzing.org> <20060831141257.GA17008@tenzing.org> <20060901234519.GA20849@tenzing.org> <44F8EAA8.6010103@zip.com.au> Message-ID: <20060902031351.GA21682@tenzing.org> On 09/02/2006 12:21, Darren Tucker wrote: > Roger Cornelius wrote: > > [ SCO OSR6 w/mp2 using system compiler, SNAP-20060902 ] > [...] > > OSR6 does need BROKEN_UPDWTMP defined. Otherwise wtmp gets trashed when > > someone connects via ssh. This can be seen by running /bin/last > > after a ssh login. Here's an example of last output after a ssh > > connection (I didn't save a pre-4.4p1 example of last output but it > > was valid): > > Hi and thanks. > > What does ./config.guess report that platform to be, so we can add > BROKEN_UPDWTMP to configure? i686-unknown-sysv5SCO_SV6.0.0 -- Roger Cornelius rac at tenzing.org From dtucker at zip.com.au Sat Sep 2 13:26:36 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 2 Sep 2006 13:26:36 +1000 Subject: Testing for the 4.4p1 release In-Reply-To: <20060902031351.GA21682@tenzing.org> References: <20060830214416.GA7373@tenzing.org> <20060831141257.GA17008@tenzing.org> <20060901234519.GA20849@tenzing.org> <44F8EAA8.6010103@zip.com.au> <20060902031351.GA21682@tenzing.org> Message-ID: <20060902032636.GA16388@gate.dtucker.net> On Fri, Sep 01, 2006 at 11:13:51PM -0400, Roger Cornelius wrote: > On 09/02/2006 12:21, Darren Tucker wrote: > > Roger Cornelius wrote: > > > [ SCO OSR6 w/mp2 using system compiler, SNAP-20060902 ] [...] > > What does ./config.guess report that platform to be, so we can add > > BROKEN_UPDWTMP to configure? > > i686-unknown-sysv5SCO_SV6.0.0 OK, then it would appear that the place to put this is below, which is inside a case that matches "*-*-sysv5SCO_SV*) # SCO OpenServer 6.x" Tim? Are you around? Index: configure.ac =================================================================== RCS file: /var/cvs/openssh/configure.ac,v retrieving revision 1.357 diff -u -p -r1.357 configure.ac --- configure.ac 1 Sep 2006 10:29:11 -0000 1.357 +++ configure.ac 2 Sep 2006 03:18:07 -0000 @@ -512,6 +512,8 @@ mips-sony-bsd|mips-sony-newsos4) TEST_SHELL=/u95/bin/sh AC_DEFINE(BROKEN_LIBIAF, 1, [ia_uinfo routines not supported by OS yet]) + AC_DEFINES(BROKEN_UPDWTMP, 1, + [using updwtmp will corrupt wtmp entries]) ;; *) AC_DEFINE(LOCKED_PASSWD_STRING, "*LK*") ;; -- 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 Sep 2 14:02:57 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 02 Sep 2006 14:02:57 +1000 Subject: Testing for the 4.4p1 release In-Reply-To: <44F8F47C.9010508@zip.com.au> References: <200609011914.k81JEnMi031660@ganymede.nas.nasa.gov> <44F8F47C.9010508@zip.com.au> Message-ID: <44F90271.7010701@zip.com.au> Darren Tucker wrote: > Iain Morgan wrote: >> 14 Macro "_PATH_MAILDIR" (declared at line 359 of "defines.h") has an >> 14 Macro "_PATH_BSHELL" (declared at line 322 of "defines.h") has an >> incompatible > > These are defined in /usr/include/paths.h, right? I think we should put > that back into includes.h or maybe defines.h, because the ones we > default to in defines.h may not be right. Actually I got it backward: paths.h is still in includes.h but it's the "#include " in *.c files that's causing these warnings, so they would be annoying but harmless. In the future we could test explicitly for them in configure to prevent the warnings. -- 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 Sep 2 14:52:27 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 02 Sep 2006 14:52:27 +1000 Subject: Testing for the 4.4p1 release In-Reply-To: <018a01c6cd94$7cf51c10$2d0110ac@samco> References: <021c01c6ccf4$f6d99920$2d0110ac@samco> <018a01c6cd94$7cf51c10$2d0110ac@samco> Message-ID: <44F90E0B.6070805@zip.com.au> santhi wrote: >> On Thu, 31 Aug 2006, santhi wrote: >> >>> /usr/ccs/bin/ld: Unsatisfied symbols: >>> ntohl (first referenced in sshconnect.o) (code) >>> ntohs (first referenced in ssh.o) (code) >>> htonl (first referenced in sshconnect.o) (code) >>> htons (first referenced in >>> openbsd-compat//libopenbsd-compat.a(rresvport.o)) (code) >>> *** Error exit code 1 [...] > Affected files are > > 01) channels.c > 02) ssh.c > 03) openbsd-compat/bindresvport.c > 04) openbsd-compat/fake-rfc2553.c > 05) openbsd-compat/getrrsetbyname.c > 06) openbsd-compat/rresvport.c > 07) sshconnect.c > 08) openbsd-compat/port-tun.c > 09) ssh-rand-helper.c > 10) ssh-keyscan.c > 11) openbsd-compat/bsd-cray.c > 12) openbsd-compat/inet_aton.c > > Among the above files, the patch is applied to "bindresvport.c" and > "rresvport.c". But we get the same linker error, > while we compile other files. Any suggestions? Thanks for the report. Looking at the headers on HP-UX, htonl and friends are in arpa/inet.h (if _XOPEN_SOURCE_EXTENDED is defined) or netinet/in.h (if XOPEN_SOURCE_EXTENDED is *not* defined). So, since we define _XOPEN_SOURCE_EXTENDED, basically any place where we include netinet/in.h for the htonl macros we also need to include arpa/inet.h. I'll go through your list of affected files. I'm not sure why I've not seen that problem on HP-UX with gcc, though. > Note: We found that file is missing in includes.h file. We're trying to move away from a one-includes-fits-all approach and put the headers in the .c files where they're required. Reducing the scope of the includes should reduce the chance of unexpected interactions between them. -- 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 Sep 2 15:59:52 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 2 Sep 2006 15:59:52 +1000 Subject: [openssh-unix-dev] Testing for the 4.4p1 release In-Reply-To: <200609020114.k821Epjn089336@fire.its.uiowa.edu> References: <200609020114.k821Epjn089336@fire.its.uiowa.edu> Message-ID: <20060902055952.GA18140@gate.dtucker.net> On Fri, Sep 01, 2006 at 08:14:51PM -0500, David Bronder wrote: > Damien Miller wrote: > > > > The 4.4p1 release is approaching now, so we are now asking people to > > actively test snapshots or CVS and report back to the mailing list. > > [AIX 5.1 ML5, IBM VAC 6 compiler, openssh-SNAP-20060902] Thanks for testing. > Fails to build. See below for details. Same result with a stripped > down configure line (just adding --with-zlib=/usr/local). [...] > Compiler: cc -qlanglvl=ansi I noticed that in your other report in which it worked, you had "cc -qlanglvl=extc89" instead. Does this make a difference to the TAILQ_HEAD error below? (It appears that this line of the code has not changed for years.) > "/usr/include/usersec.h", line 625.32: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. The patch below should fix those. [...] > "packet.c", line 162.12: 1506-010 (E) Macro TAILQ_HEAD invoked with a null argument for parameter name. Please see my query above about compiler flags. > "/usr/include/paths.h", line 50.9: 1506-213 (S) Macro name _PATH_BSHELL cannot be redefined. > "/usr/include/paths.h", line 50.9: 1506-358 (I) "_PATH_BSHELL" is defined on line 322 of defines.h. Hmm, the "cannot be redefined" sounds like we need to fix those before the release. Index: openbsd-compat/port-aix.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/port-aix.h,v retrieving revision 1.26 diff -u -p -r1.26 port-aix.h --- openbsd-compat/port-aix.h 28 May 2005 10:28:40 -0000 1.26 +++ openbsd-compat/port-aix.h 2 Sep 2006 03:13:36 -0000 @@ -38,7 +38,7 @@ #ifdef WITH_AIXAUTHENTICATE # include # include -# if defined(HAVE_SYS_AUDIT_H) && defined(AIX_LOGINFAILED_4ARG) +# if defined(HAVE_SYS_AUDIT_H) # include # endif # include -- 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 Sun Sep 3 20:49:04 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 3 Sep 2006 20:49:04 +1000 Subject: Testing for the 4.4p1 release In-Reply-To: References: Message-ID: <20060903104904.GA15809@gate.dtucker.net> On Wed, Aug 30, 2006 at 11:41:53PM +1000, Damien Miller wrote: > The 4.4p1 release is approaching now, so we are now asking people to > actively test snapshots or CVS and report back to the mailing list. It seems that *really* old systems that don't declare writev will not build because the function can't be passed as an argument to atomiciov. The patch below fixes this, and while I don't think it would affect any other platforms I'm not sure it's worth putting in at this point. Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v retrieving revision 1.357 diff -u -p -r1.357 configure.ac --- configure.ac 1 Sep 2006 10:29:11 -0000 1.357 +++ configure.ac 3 Sep 2006 08:41:34 -0000 @@ -1328,6 +1328,11 @@ AC_CHECK_DECLS(O_NONBLOCK, , , #endif ]) +AC_CHECK_DECLS(writev, , , [ +#include +#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: openbsd-compat/openbsd-compat.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/openbsd-compat.h,v retrieving revision 1.41 diff -u -p -r1.41 openbsd-compat.h --- openbsd-compat/openbsd-compat.h 30 Aug 2006 17:24:42 -0000 1.41 +++ openbsd-compat/openbsd-compat.h 2 Sep 2006 13:18:16 -0000 @@ -131,6 +131,11 @@ int getgrouplist(const char *, gid_t, gi int BSDgetopt(int argc, char * const *argv, const char *opts); #endif +#if defined(HAVE_DECL_WRITEV) && HAVE_DECL_WRITEV == 0 +# include +# include +int writev(int, struct iovec *, int); +#endif /* Home grown routines */ #include "bsd-misc.h" -- 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 flavien-ssh at lebarbe.net Mon Sep 4 06:15:09 2006 From: flavien-ssh at lebarbe.net (Flavien Lebarbe) Date: Sun, 3 Sep 2006 22:15:09 +0200 Subject: Testing for the 4.4p1 release In-Reply-To: <20060831012003.GA10947@lebarbe.net> References: <20060831012003.GA10947@lebarbe.net> Message-ID: <20060903201509.GA12600@lebarbe.net> Hi, I followed Darren & Kirill advices, and upgraded netcat to RELENG_5. Now "make tests" run fine on FreeBSD 5.4. Thanks ! Flavien. > > "make tests" fails in dynamic-forward.sh on FreeBSD here. I just > retried 4.3p2, "make tests" runs ok with this version, including > dynamic-forward.sh > > Hope this helps, > > > Flavien. > --- > System : FreeBSD 5.4-STABLE i386 > Version tested : openssh-SNAP-20060830.tar.gz > GCC version : gcc (GCC) 3.4.2 [FreeBSD] 20040728 > > $ ./configure --without-zlib-version-check && make tests > [...] > OpenSSH has been configured with the following options: > User binaries: /usr/local/bin > System binaries: /usr/local/sbin > Configuration files: /usr/local/etc > Askpass program: /usr/local/libexec/ssh-askpass > Manual pages: /usr/local/share/man/manX > PID file: /var/run > Privilege separation chroot path: /var/empty > At runtime, sshd will use the path defined in /etc/login.conf > Make sure the path to scp is present, otherwise scp will not work > Manpage format: doc > PAM support: no > KerberosV support: no > SELinux support: no > Smartcard support: no > S/KEY support: no > TCP Wrappers support: no > MD5 password support: no > libedit support: no > IP address in $DISPLAY hack: no > Translate v4 in v6 hack: no > BSD Auth support: no > Random number source: OpenSSL internal ONLY > > Host: i386-unknown-freebsd5.4 > Compiler: gcc > Compiler flags: -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare > Preprocessor flags: > Linker flags: > Libraries: -lcrypto -lutil -lz -lcrypt > > [...] > run test sftp-glob.sh ... > sftp glob: ls file > sftp glob: ls dir > ok sftp glob > run test reconfigure.sh ... > ok simple connect after reconfigure > run test dynamic-forward.sh ... > nc: unexpected reply size 31 (expected 10) > ssh_exchange_identification: Connection closed by remote host > cmp: EOF on /usr/home/flavien/src/openssh/regress/ls.copy > corrupted copy of /bin/ls > nc: unexpected reply size 31 (expected 10) > ssh_exchange_identification: Connection closed by remote host > cmp: EOF on /usr/home/flavien/src/openssh/regress/ls.copy > corrupted copy of /bin/ls > failed dynamic forwarding > *** Error code 1 > > Stop in /usr/home/flavien/src/openssh/regress. > *** Error code 1 From openssh at roumenpetrov.info Mon Sep 4 05:17:54 2006 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Sun, 03 Sep 2006 22:17:54 +0300 Subject: Testing for the 4.4p1 release In-Reply-To: References: Message-ID: <44FB2A62.6080804@roumenpetrov.info> Damien Miller wrote: > Hi, > > The 4.4p1 release is approaching now, so we are now asking people to > actively test snapshots or CVS and report back to the mailing list. > scp manual page: make -f Makefile.in distprep scp.1 -> scp.0 mdoc error: .Ex defunct, use .D1 (#202) ... Roumen From jmc at kerhand.co.uk Mon Sep 4 19:15:06 2006 From: jmc at kerhand.co.uk (Jason McIntyre) Date: Mon, 4 Sep 2006 10:15:06 +0100 Subject: Testing for the 4.4p1 release In-Reply-To: <44FB2A62.6080804@roumenpetrov.info> References: <44FB2A62.6080804@roumenpetrov.info> Message-ID: <20060904091529.GB19459@tinker.kerhand.co.uk> On Sun, Sep 03, 2006 at 10:17:54PM +0300, Roumen Petrov wrote: > Damien Miller wrote: > >Hi, > > > >The 4.4p1 release is approaching now, so we are now asking people to > >actively test snapshots or CVS and report back to the mailing list. > > > > scp manual page: > > make -f Makefile.in distprep > scp.1 -> scp.0 > mdoc error: .Ex defunct, use .D1 (#202) > ... > what exactly are you using that does not recognise ".Ex"? jmc From dtucker at zip.com.au Mon Sep 4 22:43:40 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 4 Sep 2006 22:43:40 +1000 Subject: Testing for the 4.4p1 release In-Reply-To: <20060902031351.GA21682@tenzing.org> References: <20060830214416.GA7373@tenzing.org> <20060831141257.GA17008@tenzing.org> <20060901234519.GA20849@tenzing.org> <44F8EAA8.6010103@zip.com.au> <20060902031351.GA21682@tenzing.org> Message-ID: <20060904124340.GA15075@gate.dtucker.net> On Fri, Sep 01, 2006 at 11:13:51PM -0400, Roger Cornelius wrote: > On 09/02/2006 12:21, Darren Tucker wrote: > > Roger Cornelius wrote: > > > [ SCO OSR6 w/mp2 using system compiler, SNAP-20060902 ] > > [...] > > > OSR6 does need BROKEN_UPDWTMP defined. Otherwise wtmp gets trashed when > > > someone connects via ssh. This can be seen by running /bin/last > > > after a ssh login. Here's an example of last output after a ssh > > > connection (I didn't save a pre-4.4p1 example of last output but it > > > was valid): > > > > Hi and thanks. > > > > What does ./config.guess report that platform to be, so we can add > > BROKEN_UPDWTMP to configure? > > i686-unknown-sysv5SCO_SV6.0.0 Thanks, BROKEN_UPDWTMP has been added to configure *-*-sysv5SCO_SV* platforms (which is hopefully right, a nearby comment indicates that it is) so this should be resolved for the 4.4p1 release. It will be in tomorrow's snapshot. -- 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 openssh at roumenpetrov.info Tue Sep 5 04:37:53 2006 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Mon, 04 Sep 2006 21:37:53 +0300 Subject: Testing for the 4.4p1 release In-Reply-To: <20060904091529.GB19459@tinker.kerhand.co.uk> References: <44FB2A62.6080804@roumenpetrov.info> <20060904091529.GB19459@tinker.kerhand.co.uk> Message-ID: <44FC7281.60909@roumenpetrov.info> Jason McIntyre wrote: > On Sun, Sep 03, 2006 at 10:17:54PM +0300, Roumen Petrov wrote: > >>Damien Miller wrote: >> >>>Hi, >>> >>>The 4.4p1 release is approaching now, so we are now asking people to >>>actively test snapshots or CVS and report back to the mailing list. >>> >> >>scp manual page: >> >>make -f Makefile.in distprep >>scp.1 -> scp.0 >>mdoc error: .Ex defunct, use .D1 (#202) >>... >> > > > what exactly are you using that does not recognise ".Ex"? > jmc > This should be from GNU troff - defined in "doc-old.tmac": ........ .de Ex .tm Ex defunct, Use .Dl: \\$1 \\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8 \\$9 ........ web access to groff cvs: http://savannah.gnu.org/cvs/?group=groff It seems that .Ex in groff is different from OpenBSD. Roumen From jmc at kerhand.co.uk Tue Sep 5 06:36:41 2006 From: jmc at kerhand.co.uk (Jason McIntyre) Date: Mon, 4 Sep 2006 21:35:41 +0059 Subject: Testing for the 4.4p1 release In-Reply-To: <44FC7281.60909@roumenpetrov.info> References: <44FB2A62.6080804@roumenpetrov.info> <20060904091529.GB19459@tinker.kerhand.co.uk> <44FC7281.60909@roumenpetrov.info> Message-ID: <20060904203604.GD11375@tinker.kerhand.co.uk> On Mon, Sep 04, 2006 at 09:37:53PM +0300, Roumen Petrov wrote: > > This should be from GNU troff - defined in "doc-old.tmac": > ........ > .de Ex > .tm Ex defunct, Use .Dl: \\$1 \\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8 \\$9 > ........ > > > web access to groff cvs: http://savannah.gnu.org/cvs/?group=groff > > It seems that .Ex in groff is different from OpenBSD. > > Roumen ok. the groff package definitely supports .Ex. it's in the groff_mdoc(7) manual page of newer groff releases. some things i can think of: - you are using a very old groff package - you are not formatting using -mdoc or -mandoc jmc From imorgan at nas.nasa.gov Wed Sep 6 02:54:16 2006 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 5 Sep 2006 09:54:16 -0700 (PDT) Subject: Testing for the 4.4p1 release In-Reply-To: <44F8F47C.9010508@zip.com.au> from Darren Tucker at "Sep 2, 2006 01:03:24 pm" Message-ID: <200609051654.k85GsGYC016908@ganymede.nas.nasa.gov> Sometime ago, Darren Tucker wrote: > Hi, and thanks for testing. [...] > > 5 Macro "offsetof" (declared at line 491 of "defines.h") has an > > incompatible > > 1 Macro "offsetof" (declared at line 491 of "../defines.h") has an > > incompatible > > Which system header defines that? It's defined by including . > > > Also, moving -lgen from LIBS to SSHDLIBS would eliminate 10 additional > > warnings. > > If it's not a critical problem I'd prefer to wait until after the > release to do any library reshuffles, but there is definitely some room > for improvement. > That's fine by me. > > I haven't had time to deal with the regression tests yet. The protocol 1 > > tests always seem to be a problem with IRIX. (I reported this once quite > > a while ago, but did not have the time to investigate.) In the past, > > I've hacked the scripts to only test protocol 2, in which case > > everything (that we care about) is fine. > > The only time I've ever seen protocol 1 specifically fail regress tests > is on Solaris 10 with the bundled OpenSSL, and that's because any crypto > with a key length >128bit had been crippled including the blowfish > cipher that protocol 1 uses. (It also included the AES functions, but > OpenSSH has its own implementation of those and now uses them if it > finds the native ones don't work.) > Yeah, the problem I see is that the fingerprint of the server key never seems to match, so it appears to be a man-in-the-middle situation. At first glance, it's as if a previous instance of the daemon were running, but other than the failure there's no evidence that that is actually what's going on. > When I'm trying to debug regress tests (which, I'll admit, isn't easy) I > do something like the attached patch, which stops immediately after the > failure without cleaning up. I then rerun the failing command with > extra debugging (usually ssh -vvv [lots of args]) which can help shed > some light on the failure. > Thanks for the tip. I'll give it a try, but it's probably going to be a while before I can make time to do a real job of it. -- Iain Morgan From santhi.amirta at gmail.com Wed Sep 6 22:08:00 2006 From: santhi.amirta at gmail.com (santhi) Date: Wed, 6 Sep 2006 17:38:00 +0530 Subject: Is there any impact? Message-ID: <010c01c6d1ad$1e702050$2d0110ac@samco> Hi All, Is there any impact in OpenSSH build with OpenSSL 0.9.7j as OpenSSL is affected by the following vulnerability http://www.openssl.org/news/secadv_20060905.txt ? Thanks & Regards, Santhi. From david-bronder at uiowa.edu Thu Sep 7 06:58:47 2006 From: david-bronder at uiowa.edu (David Bronder) Date: Wed, 6 Sep 2006 15:58:47 -0500 (CDT) Subject: Testing for the 4.4p1 release In-Reply-To: <20060902055952.GA18140@gate.dtucker.net> from "Darren Tucker" at Sep 02, 2006 03:59:52 PM Message-ID: <200609062058.k86KwlGW020994@fire.its.uiowa.edu> Darren Tucker wrote: > > On Fri, Sep 01, 2006 at 08:14:51PM -0500, David Bronder wrote: > > Damien Miller wrote: > > > > > > The 4.4p1 release is approaching now, so we are now asking people to > > > actively test snapshots or CVS and report back to the mailing list. > > > > [AIX 5.1 ML5, IBM VAC 6 compiler, openssh-SNAP-20060902] I switched to openssh-SNAP-20060906 for the next attempt. > > Fails to build. See below for details. Same result with a stripped > > down configure line (just adding --with-zlib=/usr/local). > [...] > > Compiler: cc -qlanglvl=ansi > > I noticed that in your other report in which it worked, you had "cc > -qlanglvl=extc89" instead. Does this make a difference to the TAILQ_HEAD > error below? (It appears that this line of the code has not changed > for years.) Yes, if I manually change the "langlvl" value from "ansi" to "extc89" in the relevant Makefiles, it builds and tests cleanly (with the expected skipped tests). Looking at the config.log, configure didn't use "extc89" because of this error: configure:2734: cc -qlanglvl=extc89 -c -g conftest.c >&5 "conftest.c", line 43.19: 1506-195 (S) Integral constant expression with a value greater than zero is required. The line in question is in a section of the test program specifically checking some IBM C 6 for AIX behavior. > > "/usr/include/usersec.h", line 625.32: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. > > The patch below should fix those. Switching "langlvl" to "extc89" fixed these without applying the patch to port-aix.h. > [...] > > "packet.c", line 162.12: 1506-010 (E) Macro TAILQ_HEAD invoked with a null argument for parameter name. > > Please see my query above about compiler flags. Yeah, the "langlvl" change fixed this, too. > > "/usr/include/paths.h", line 50.9: 1506-213 (S) Macro name _PATH_BSHELL cannot be redefined. > > "/usr/include/paths.h", line 50.9: 1506-358 (I) "_PATH_BSHELL" is defined on line 322 of defines.h. > > Hmm, the "cannot be redefined" sounds like we need to fix those before the > release. Still had these with openssh-SNAP-20060906 and "langlvl=extc89". =Dave -- Hello World. David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bronder at uiowa.edu From djm at mindrot.org Thu Sep 7 08:08:08 2006 From: djm at mindrot.org (Damien Miller) Date: Thu, 7 Sep 2006 08:08:08 +1000 (EST) Subject: Is there any impact? In-Reply-To: <010c01c6d1ad$1e702050$2d0110ac@samco> References: <010c01c6d1ad$1e702050$2d0110ac@samco> Message-ID: On Wed, 6 Sep 2006, santhi wrote: > Hi All, > > Is there any impact in OpenSSH build with OpenSSL 0.9.7j as OpenSSL is > affected by the following vulnerability > http://www.openssl.org/news/secadv_20060905.txt ? No, OpenSSH performs its own RSA verification which has always checked that the signature is not overly long. See ssh-rsa.c for details. -d From djm at mindrot.org Thu Sep 7 10:01:32 2006 From: djm at mindrot.org (Damien Miller) Date: Thu, 7 Sep 2006 10:01:32 +1000 (EST) Subject: Is there any impact? In-Reply-To: References: <010c01c6d1ad$1e702050$2d0110ac@samco> Message-ID: On Thu, 7 Sep 2006, Damien Miller wrote: > > Is there any impact in OpenSSH build with OpenSSL 0.9.7j as OpenSSL is > > affected by the following vulnerability > > http://www.openssl.org/news/secadv_20060905.txt ? > > No, OpenSSH performs its own RSA verification which has always checked > that the signature is not overly long. See ssh-rsa.c for details. I should also add: OpenSSH ssh-keygen has never generated RSA keys with exponent == 3 (we always use 35), so Bleichenbacher's new attack won't work for our keys even if one of the endpoints suffers from the bug. -d From dtucker at zip.com.au Thu Sep 7 10:53:29 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 07 Sep 2006 10:53:29 +1000 Subject: Testing for the 4.4p1 release In-Reply-To: <200609062058.k86KwlGW020994@fire.its.uiowa.edu> References: <200609062058.k86KwlGW020994@fire.its.uiowa.edu> Message-ID: <44FF6D89.8030801@zip.com.au> David Bronder wrote: [...] > Yes, if I manually change the "langlvl" value from "ansi" to "extc89" in > the relevant Makefiles, it builds and tests cleanly (with the expected > skipped tests). Looking at the config.log, configure didn't use "extc89" > because of this error: > > configure:2734: cc -qlanglvl=extc89 -c -g conftest.c >&5 > "conftest.c", line 43.19: 1506-195 (S) Integral constant expression with a value > greater than zero is required. > > The line in question is in a section of the test program specifically > checking some IBM C 6 for AIX behavior. OK, I see that in configure (it's put there by autoconf not explicitly by our configuration). Could you please send me the output from "./configure && make -k" and plus a copy of the config.log file (just to me please, they'll be big and there's no need to fill the list members' inboxes :-) >>> "/usr/include/usersec.h", line 625.32: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. >> The patch below should fix those. > > Switching "langlvl" to "extc89" fixed these without applying the patch > to port-aix.h. OK, I think this means that the configure test for AIX_LOGINFAILED_4ARG fails with langlvl=ansi for some reason. You can use extc89 at configure time with: CC="cc -qlanglvl=extc89" ./configure but it would be nice to figure out how to make VAC6 work out of the box. >> [...] >>> "packet.c", line 162.12: 1506-010 (E) Macro TAILQ_HEAD invoked with a null argument for parameter name. >> Please see my query above about compiler flags. > > Yeah, the "langlvl" change fixed this, too. > > >>> "/usr/include/paths.h", line 50.9: 1506-213 (S) Macro name _PATH_BSHELL cannot be redefined. >>> "/usr/include/paths.h", line 50.9: 1506-358 (I) "_PATH_BSHELL" is defined on line 322 of defines.h. >> Hmm, the "cannot be redefined" sounds like we need to fix those before the >> release. > > Still had these with openssh-SNAP-20060906 and "langlvl=extc89". Was that both warnings or just the "is defined on line xxx"? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From tim at multitalents.net Thu Sep 7 11:04:47 2006 From: tim at multitalents.net (Tim Rice) Date: Wed, 6 Sep 2006 18:04:47 -0700 (PDT) Subject: Testing for the 4.4p1 release In-Reply-To: <20060902032636.GA16388@gate.dtucker.net> References: <20060830214416.GA7373@tenzing.org> <20060831141257.GA17008@tenzing.org> <20060901234519.GA20849@tenzing.org> <44F8EAA8.6010103@zip.com.au> <20060902031351.GA21682@tenzing.org> <20060902032636.GA16388@gate.dtucker.net> Message-ID: On Sat, 2 Sep 2006, Darren Tucker wrote: > On Fri, Sep 01, 2006 at 11:13:51PM -0400, Roger Cornelius wrote: > > On 09/02/2006 12:21, Darren Tucker wrote: > > > Roger Cornelius wrote: > > > > [ SCO OSR6 w/mp2 using system compiler, SNAP-20060902 ] > [...] > > > What does ./config.guess report that platform to be, so we can add > > > BROKEN_UPDWTMP to configure? > > > > i686-unknown-sysv5SCO_SV6.0.0 > > OK, then it would appear that the place to put this is below, which is > inside a case that matches "*-*-sysv5SCO_SV*) # SCO OpenServer 6.x" > > Tim? Are you around? Just got back (and found my ISDN line down). Back up now. Correct placmement, but wrong one. Needs to be BROKEN_UPDWTMPX I'll commit the fix shortly. > > Index: configure.ac > =================================================================== > RCS file: /var/cvs/openssh/configure.ac,v > retrieving revision 1.357 > diff -u -p -r1.357 configure.ac > --- configure.ac 1 Sep 2006 10:29:11 -0000 1.357 > +++ configure.ac 2 Sep 2006 03:18:07 -0000 > @@ -512,6 +512,8 @@ mips-sony-bsd|mips-sony-newsos4) > TEST_SHELL=/u95/bin/sh > AC_DEFINE(BROKEN_LIBIAF, 1, > [ia_uinfo routines not supported by OS yet]) > + AC_DEFINES(BROKEN_UPDWTMP, 1, > + [using updwtmp will corrupt wtmp entries]) > ;; > *) AC_DEFINE(LOCKED_PASSWD_STRING, "*LK*") > ;; > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From david-bronder at uiowa.edu Thu Sep 7 11:12:01 2006 From: david-bronder at uiowa.edu (David Bronder) Date: Wed, 6 Sep 2006 20:12:01 -0500 (CDT) Subject: [openssh-unix-dev] Testing for the 4.4p1 release In-Reply-To: <44FF6D89.8030801@zip.com.au> from "Darren Tucker" at Sep 07, 2006 10:53:29 AM Message-ID: <200609070112.k871C1oM079308@fire.its.uiowa.edu> Darren Tucker wrote: > > David Bronder wrote: > [...] > > > > Could you please send me the output from "./configure && make -k" and > plus a copy of the config.log file (just to me please, they'll be big > and there's no need to fill the list members' inboxes :-) I'll run it again and send you the output. > You can use extc89 at configure time with: > > CC="cc -qlanglvl=extc89" ./configure Tried that first, but the configure test program still failed, so it ended up setting CC="cc -qlanglvl=extc89 -qlanglevel=ansi" and the compiler used the last one specified. > but it would be nice to figure out how to make VAC6 work out of the box. Indeed. :) > >>> "/usr/include/paths.h", line 50.9: 1506-213 (S) Macro name _PATH_BSHELL cannot be redefined. > >>> "/usr/include/paths.h", line 50.9: 1506-358 (I) "_PATH_BSHELL" is defined on line 322 of defines.h. > >> Hmm, the "cannot be redefined" sounds like we need to fix those before the > >> release. > > > > Still had these with openssh-SNAP-20060906 and "langlvl=extc89". > > Was that both warnings or just the "is defined on line xxx"? I'll have to run the build again with "langlvl=extc89" and look more closely. I think there were still two warnings per macro, but the first may have been a notice that the macro _was_ redefined instead of that it cannot be redefined (similar to "langlvl=extc89" on AIX 5.2). -- Hello World. David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bronder at uiowa.edu From dtucker at zip.com.au Thu Sep 7 20:22:22 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 7 Sep 2006 20:22:22 +1000 Subject: [openssh-unix-dev] Testing for the 4.4p1 release In-Reply-To: <200609020114.k821Epjn089336@fire.its.uiowa.edu> References: <200609020114.k821Epjn089336@fire.its.uiowa.edu> Message-ID: <20060907102222.GA30077@gate.dtucker.net> On Fri, Sep 01, 2006 at 08:14:51PM -0500, David Bronder wrote: [...] > Compiler: cc -qlanglvl=ansi [..] > "packet.c", line 162.12: 1506-010 (E) Macro TAILQ_HEAD invoked with a null argument for parameter name. It would appear the autoconf 2.60 pretty much insists on using -qlanglvl=ansi in this case. I think this will work around it. You will need to run "autoreconf" from autoconf-2.60 to rebuild the configure. If you don't have it handy, you can download a prebuilt one here: http://www.zip.com.au/~dtucker/tmp/configure-aix-vac6.gz Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v retrieving revision 1.361 diff -u -p -r1.361 configure.ac --- configure.ac 7 Sep 2006 01:11:29 -0000 1.361 +++ configure.ac 7 Sep 2006 07:24:16 -0000 @@ -134,6 +134,22 @@ SPC_MSG="no" # Check for some target-specific stuff case "$host" in *-*-aix*) + # Some versions of VAC won't allow empty macro argements with + # -qlanglevel=ansi, and autoconf 2.60 sometimes insists on using that + AC_MSG_CHECKING(if compiler allows null arguments in macros) + AC_COMPILE_IFELSE( + [AC_LANG_SOURCE([[ +#define testmacro(a,b) +int main(void) { int a; testmacro(,a); } + ]])], + [ AC_MSG_RESULT(yes) ], + [ AC_MSG_RESULT(no) + CC="`echo $CC | sed 's/langlvl\=ansi/langlvl=extc89/g'`" + CFLAGS="`echo $CFLAGS | sed 's/langlvl\=ansi/langlvl=extc89/g'`" + CPPFLAGS="`echo $CPPFLAGS | sed 's/langlvl\=ansi/langlvl=extc89/g'`" + ] + ) + AC_MSG_CHECKING([how to specify blibpath for linker ($LD)]) if (test -z "$blibpath"); then blibpath="/usr/lib:/lib" -- 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 Sep 7 20:48:24 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 7 Sep 2006 20:48:24 +1000 Subject: [openssh-unix-dev] Testing for the 4.4p1 release In-Reply-To: <200609020042.k820gQUN070068@fire.its.uiowa.edu> References: <200609020042.k820gQUN070068@fire.its.uiowa.edu> Message-ID: <20060907104824.GA32342@gate.dtucker.net> On Fri, Sep 01, 2006 at 07:42:26PM -0500, David Bronder wrote: > [AIX 5.2 ML4, IBM VAC 6 compiler, openssh-SNAP-20060902] > > Builds (with some warnings) and tests OK (some exceptions). See below > for details. [...] > "/usr/include/paths.h", line 50.9: 1506-236 (W) Macro name _PATH_BSHELL has been redefined. > "/usr/include/paths.h", line 50.9: 1506-358 (I) "_PATH_BSHELL" is defined on line 322 of defines.h. > "/usr/include/paths.h", line 52.9: 1506-236 (W) Macro name _PATH_CSHELL has been redefined. > "/usr/include/paths.h", line 52.9: 1506-358 (I) "_PATH_CSHELL" is defined on line 325 of defines.h. > "/usr/include/paths.h", line 57.9: 1506-236 (W) Macro name _PATH_MAILDIR has been redefined. > "/usr/include/paths.h", line 57.9: 1506-358 (I) "_PATH_MAILDIR" is defined on line 359 of defines.h. Below is one way to fix these. I'm not sure now is the right time to make this kind of change, though. (Again, you will need to run autoreconf to rebuild configure.) > agent-getpeereid.sh [skipped: need SUDO to switch to uid nobody] > agent-ptrace.sh [skipped (not supported on this platform)] > dynamic-forward.sh [skipped (no suitable ProxyCommand found)] These are all normal, btw. Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v retrieving revision 1.361 diff -u -p -r1.361 configure.ac --- configure.ac 7 Sep 2006 01:11:29 -0000 1.361 +++ configure.ac 7 Sep 2006 05:01:49 -0000 @@ -3283,6 +3283,33 @@ else AC_SUBST(XAUTH_PATH) fi + +AC_CHECK_DECL(_PATH_BSHELL, , + AC_DEFINE_UNQUOTED(_PATH_BSHELL, "/bin/sh", + [Define to your C shell if not defined in paths.h]) + [ #include ] +) + +AC_CHECK_DECL(_PATH_CSHELL, , + AC_DEFINE_UNQUOTED(_PATH_CSHELL, "/bin/csh", + [Define to your Bourne shell if not defined in paths.h]) + [ #include ] +) + +AC_CHECK_DECL(_PATH_SHELLS, , + AC_DEFINE_UNQUOTED(_PATH_BSHELL, "/etc/shells", + [Define to your shells file if not defined in paths.h]) + [ #include ] +) + +# if _PATH_MAILDIR is in paths.h then we won't go hunting for it. +AC_CHECK_DECL(_PATH_MAILDIR, + AC_DEFINE(PATH_MAILDIR_IN_PATHS_H, 1, + [Define if _PATH_MAILDIR is in paths.h]), + , + [ #include ] +) + # Check for mail directory (last resort if we cannot get it from headers) if test ! -z "$MAIL" ; then maildir=`dirname $MAIL` Index: defines.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/defines.h,v retrieving revision 1.137 diff -u -p -r1.137 defines.h --- defines.h 18 Aug 2006 22:38:24 -0000 1.137 +++ defines.h 7 Sep 2006 05:00:52 -0000 @@ -318,16 +318,6 @@ struct winsize { /* Paths */ -#ifndef _PATH_BSHELL -# define _PATH_BSHELL "/bin/sh" -#endif -#ifndef _PATH_CSHELL -# define _PATH_CSHELL "/bin/csh" -#endif -#ifndef _PATH_SHELLS -# define _PATH_SHELLS "/etc/shells" -#endif - #ifdef USER_PATH # ifdef _PATH_STDPATH # undef _PATH_STDPATH @@ -347,6 +337,8 @@ struct winsize { # define _PATH_DEVNULL "/dev/null" #endif +#ifndef PATH_MAILDIR_IN_PATHS_H + #ifndef MAIL_DIRECTORY # define MAIL_DIRECTORY "/var/spool/mail" #endif @@ -359,6 +351,8 @@ struct winsize { # define _PATH_MAILDIR MAILDIR #endif /* !defined(_PATH_MAILDIR) && defined(MAILDIR) */ +#endif /* PATH_MAILDIR_IN_PATHS_H */ + #ifndef _PATH_NOLOGIN # define _PATH_NOLOGIN "/etc/nologin" #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 Dan.Goldburt at dowjones.com Fri Sep 8 05:55:29 2006 From: Dan.Goldburt at dowjones.com (Goldburt, Dan) Date: Thu, 7 Sep 2006 15:55:29 -0400 Subject: Multiple (multiplexed) simultaneous ssh connections - Cygwin bug? Message-ID: <57E557D9D8FCEB4DB0B8DB430C6DBD08069040F4@SBKE2KMB03.win.dowjones.net> Hello, ? I need to make many (>50) ssh connections from linux to cygwin at the same time. Using Windows 2000 Server (OpenSSH_4.3p2, OpenSSL 0.9.8b and updated cygwin) and Linux RHEL4 (OpenSSH_3.9p1, OpenSSL 0.9.7a). ? It's been difficult to optimize many simultaneous connections. Here were some issues: 1.?????? On Windows XP/Professional, Microsoft intentionally cripples the TCP/IP stack. Official word (http://support.microsoft.com/kb/Q127144) is that the backlog queue limit on a listen socket is 5 (200 when Server), so you can't accept() more than 5 new connections concurrently. 2.?????? Using a master connection that is shared, the sshd_config variable MaxStartups has no effect. This is because we are not opening lots of ssh connections, but are opening multiple sessions within a single connection. The parameter that needs to be changed is MAX_SESSIONS, which is hardcoded in sessions.c at 10. Request: add "MAX_SESSIONS" as a configuration parameter in sshd_config. (also, you should mention in INSTALL documentation that by default, compiled binaries are quite a bit larger than usual. Do you use strip -strip-debug? ? Finally, I'm able to make many connections most of the time. But then, sshd errors: ? fcntl(223, F_GETFL, 0): Bad file descriptor and sometimes: [sig] bash 3720 _cygtls::handle_threadlist_exception and then loops spitting out "select: Bad file descriptor" and taking up 100% CPU. I have not done a stack trace or increased sshd debug output because the error comes up when about 100 connections are made, so it would be difficult to track down. If this isn't enough information to go on, I will post it. ? Is this because on Cygwin, the "fd_set" arrays, used with select(), can contain file descriptors (FD) from 0 to 63 (the fd_set array is 8-byte long). On Linux, this is 0 to 1023? From: http://www.ipflow.utc.fr/blog/?p=34 and http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=105321853321894&w=3 ? I also found a post http://www.cygwin.com/ml/cygwin/2005-06/msg00511.html where Corinna said "Using a master/slave connection requires the ability to exchange file descriptors over AF_UNIX sockets.? That's not possible in Cygwin." I assume this has been addressed with USE_PIPES, since I AM able to use multiplexed connections most of the time? ? Lastly, if security is not the biggest concern, should I even use ssh? I just need to be able to execute many remote shell commands in a short interval and return the output. ? Thanks, Dan From david-bronder at uiowa.edu Fri Sep 8 07:41:56 2006 From: david-bronder at uiowa.edu (David Bronder) Date: Thu, 7 Sep 2006 16:41:56 -0500 (CDT) Subject: Testing for the 4.4p1 release In-Reply-To: <20060907104824.GA32342@gate.dtucker.net> from "Darren Tucker" at Sep 07, 2006 08:48:24 PM Message-ID: <200609072141.k87Lfusa078980@fire.its.uiowa.edu> Darren Tucker wrote: > > On Fri, Sep 01, 2006 at 07:42:26PM -0500, David Bronder wrote: > > [AIX 5.2 ML4, IBM VAC 6 compiler, openssh-SNAP-20060902] > > > > Builds (with some warnings) and tests OK (some exceptions). See below > > for details. > [...] > > "/usr/include/paths.h", line 50.9: 1506-236 (W) Macro name _PATH_BSHELL has been redefined. > > "/usr/include/paths.h", line 50.9: 1506-358 (I) "_PATH_BSHELL" is defined on line 322 of defines.h. > > "/usr/include/paths.h", line 52.9: 1506-236 (W) Macro name _PATH_CSHELL has been redefined. > > "/usr/include/paths.h", line 52.9: 1506-358 (I) "_PATH_CSHELL" is defined on line 325 of defines.h. > > "/usr/include/paths.h", line 57.9: 1506-236 (W) Macro name _PATH_MAILDIR has been redefined. > > "/usr/include/paths.h", line 57.9: 1506-358 (I) "_PATH_MAILDIR" is defined on line 359 of defines.h. > > Below is one way to fix these. I'm not sure now is the right time to make > this kind of change, though. (Again, you will need to run autoreconf to > rebuild configure.) I'm not that worried about these warnings for now, so I didn't bother testing the patch. I can try it after the 4.4 release if you'd like. > > agent-getpeereid.sh [skipped: need SUDO to switch to uid nobody] > > agent-ptrace.sh [skipped (not supported on this platform)] > > dynamic-forward.sh [skipped (no suitable ProxyCommand found)] > > These are all normal, btw. Yeah, I just noted them for completeness. :) -- Hello World. David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bronder at uiowa.edu From cmadams at hiwaay.net Fri Sep 8 06:50:33 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 7 Sep 2006 15:50:33 -0500 Subject: Testing for the 4.4p1 release In-Reply-To: References: Message-ID: <20060907205033.GD1010014@hiwaay.net> Once upon a time, Damien Miller said: > The 4.4p1 release is approaching now, so we are now asking people to > actively test snapshots or CVS and report back to the mailing list. I tested SNAP-20060906 on Tru64. The attached patch is required for compilation. Also, the check in regress/multiplex.sh for DISABLE_FD_PASSING is incorrect. DISABLE_FD_PASSING is defined on Tru64 with SIA enabled (to skip post-auth privsep), but multiplexing works fine (commenting out that test in multiplex.sh allows it run okay). FD passing works fine as well on Tru64. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -------------- next part -------------- diff -urN openssh-SNAP-20060906/auth-sia.c openssh/auth-sia.c --- openssh-SNAP-20060906/auth-sia.c Thu Sep 7 15:27:59 2006 +++ openssh/auth-sia.c Thu Sep 7 15:28:19 2006 @@ -36,6 +36,8 @@ #include #include "ssh.h" +#include "key.h" +#include "hostfile.h" #include "auth.h" #include "auth-sia.h" #include "log.h" From david-bronder at uiowa.edu Fri Sep 8 07:49:45 2006 From: david-bronder at uiowa.edu (David Bronder) Date: Thu, 7 Sep 2006 16:49:45 -0500 (CDT) Subject: Testing for the 4.4p1 release In-Reply-To: <20060907102222.GA30077@gate.dtucker.net> from "Darren Tucker" at Sep 07, 2006 08:22:22 PM Message-ID: <200609072149.k87LnjTC065872@fire.its.uiowa.edu> Darren Tucker wrote: > > On Fri, Sep 01, 2006 at 08:14:51PM -0500, David Bronder wrote: > [...] > > Compiler: cc -qlanglvl=ansi > [..] > > "packet.c", line 162.12: 1506-010 (E) Macro TAILQ_HEAD invoked with a null argument for parameter name. > > It would appear the autoconf 2.60 pretty much insists on using -qlanglvl=ansi > in this case. > > I think this will work around it. You will need to run "autoreconf" from > autoconf-2.60 to rebuild the configure. If you don't have it handy, you > can download a prebuilt one here: Gave it a go (using the prebuilt configure; my autoconf is 2.53), but it still used -qlanglvl=ansi and failed in the same place. I can send you the config.log separately if you want it. > Index: configure.ac > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v > retrieving revision 1.361 > diff -u -p -r1.361 configure.ac > --- configure.ac 7 Sep 2006 01:11:29 -0000 1.361 > +++ configure.ac 7 Sep 2006 07:24:16 -0000 > @@ -134,6 +134,22 @@ SPC_MSG="no" > # Check for some target-specific stuff > case "$host" in > *-*-aix*) > + # Some versions of VAC won't allow empty macro argements with > + # -qlanglevel=ansi, and autoconf 2.60 sometimes insists on using that > + AC_MSG_CHECKING(if compiler allows null arguments in macros) > + AC_COMPILE_IFELSE( > + [AC_LANG_SOURCE([[ > +#define testmacro(a,b) > +int main(void) { int a; testmacro(,a); } > + ]])], > + [ AC_MSG_RESULT(yes) ], > + [ AC_MSG_RESULT(no) > + CC="`echo $CC | sed 's/langlvl\=ansi/langlvl=extc89/g'`" > + CFLAGS="`echo $CFLAGS | sed 's/langlvl\=ansi/langlvl=extc89/g'`" > + CPPFLAGS="`echo $CPPFLAGS | sed 's/langlvl\=ansi/langlvl=extc89/g'`" > + ] > + ) > + > AC_MSG_CHECKING([how to specify blibpath for linker ($LD)]) > if (test -z "$blibpath"); then > blibpath="/usr/lib:/lib" > -- Hello World. David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bronder at uiowa.edu From Dan.Goldburt at dowjones.com Sat Sep 9 01:27:00 2006 From: Dan.Goldburt at dowjones.com (Goldburt, Dan) Date: Fri, 8 Sep 2006 11:27:00 -0400 Subject: Multiple (multiplexed) simultaneous ssh connections - Cygwin bug? Message-ID: <57E557D9D8FCEB4DB0B8DB430C6DBD08069040F6@SBKE2KMB03.win.dowjones.net> Here is the sshd log: debug1: server_input_channel_open: ctype session rchan 1 win 131072 max 32768 debug1: input_session_request debug1: channel 1: new [server-session] debug1: session_new: session 1 debug1: session_open: channel 1 debug1: session_open: session 1: link with channel 1 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 1 request pty-req reply 0 debug1: session_by_channel: session 1 channel 1 debug1: session_input_channel_req: session 1 req pty-req debug1: Allocating pty. debug1: session_pty_req: session 1 alloc /dev/tty6 debug3: tty_parse_modes: SSH2 n_bytes 256 debug3: tty_parse_modes: ospeed 38400 debug3: tty_parse_modes: ispeed 38400 debug3: tty_parse_modes: 1 3 debug3: tty_parse_modes: 2 28 debug3: tty_parse_modes: 3 127 debug3: tty_parse_modes: 4 21 debug3: tty_parse_modes: 5 4 debug3: tty_parse_modes: 6 0 debug3: tty_parse_modes: 7 0 debug3: tty_parse_modes: 8 17 debug3: tty_parse_modes: 9 19 debug3: tty_parse_modes: 10 26 debug3: tty_parse_modes: 12 18 debug3: tty_parse_modes: 13 23 debug3: tty_parse_modes: 14 22 debug3: tty_parse_modes: 18 15 debug3: tty_parse_modes: 30 0 debug3: tty_parse_modes: 31 0 debug3: tty_parse_modes: 32 0 debug3: tty_parse_modes: 33 0 debug3: tty_parse_modes: 34 0 debug3: tty_parse_modes: 35 0 debug3: tty_parse_modes: 36 1 debug3: tty_parse_modes: 37 0 debug3: tty_parse_modes: 38 1 debug3: tty_parse_modes: 39 0 debug3: tty_parse_modes: 40 0 debug3: tty_parse_modes: 41 0 debug3: tty_parse_modes: 50 1 debug3: tty_parse_modes: 51 1 debug1: Ignoring unsupported tty mode opcode 52 (0x34) debug3: tty_parse_modes: 53 1 debug3: tty_parse_modes: 54 1 debug3: tty_parse_modes: 55 1 debug3: tty_parse_modes: 56 0 debug3: tty_parse_modes: 57 0 debug3: tty_parse_modes: 58 0 debug3: tty_parse_modes: 59 1 debug3: tty_parse_modes: 60 1 debug3: tty_parse_modes: 61 1 debug1: Ignoring unsupported tty mode opcode 62 (0x3e) debug3: tty_parse_modes: 70 1 debug3: tty_parse_modes: 71 0 debug3: tty_parse_modes: 72 1 debug3: tty_parse_modes: 73 0 debug3: tty_parse_modes: 74 0 debug3: tty_parse_modes: 75 0 debug3: tty_parse_modes: 90 1 debug3: tty_parse_modes: 91 1 debug3: tty_parse_modes: 92 0 debug3: tty_parse_modes: 93 0 debug1: server_input_channel_req: channel 1 request shell reply 0 debug1: session_by_channel: session 1 channel 1 debug1: session_input_channel_req: session 1 req shell debug2: channel 1: rfd 10 isatty debug2: fd 10 setting O_NONBLOCK debug2: fd 9 setting O_NONBLOCK debug2: channel 1: read<=0 rfd 10 len 0 debug2: channel 1: read failed debug2: channel 1: close_read debug2: channel 1: input open -> drain debug2: channel 1: ibuf empty debug2: channel 1: send eof debug2: channel 1: input drain -> closed debug1: Received SIGCHLD. debug1: session_by_pid: pid 2636 debug1: session_exit_message: session 1 channel 1 pid 2636 debug2: channel 1: request exit-status confirm 0 debug1: session_exit_message: release channel 1 debug2: channel 1: write failed debug2: channel 1: close_write debug2: channel 1: output open -> closed debug1: session_pty_cleanup: session 1 release /dev/tty6 debug2: channel 1: send close debug3: channel 1: will not send data after close debug2: notify_done: reading debug3: channel 1: will not send data after close debug2: channel 1: rcvd close debug3: channel 1: will not send data after close debug2: channel 1: is dead debug2: channel 1: gc: notify user debug1: session_by_channel: session 1 channel 1 debug1: session_close_by_channel: channel 1 child 0 debug1: session_close: session 1 pid 0 debug2: channel 1: gc: user detached debug2: channel 1: is dead debug2: channel 1: garbage collecting debug1: channel 1: free: server-session, nchannels 2 debug3: channel 1: status: The following connections are open: #0 server-session (t4 r0 i0/0 o0/0 fd 7/6 cfd -1) #1 server-session (t4 r1 i3/0 o3/0 fd -1/-1 cfd -1) debug3: channel 1: close_fds r -1 w -1 e -1 c -1 debug1: server_input_channel_open: ctype session rchan 1 win 131072 max 32768 debug1: input_session_request debug1: channel 1: new [server-session] debug1: session_new: session 1 debug1: session_open: channel 1 debug1: session_open: session 1: link with channel 1 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 1 request exec reply 0 debug1: session_by_channel: session 1 channel 1 debug1: session_input_channel_req: session 1 req exec debug2: fd 11 setting O_NONBLOCK debug2: fd 10 setting O_NONBLOCK debug2: fd 13 setting O_NONBLOCK debug1: server_input_channel_open: ctype session rchan 2 win 131072 max 32768 debug1: input_session_request debug1: channel 2: new [server-session] debug1: session_new: session 2 debug1: session_open: channel 2 debug1: session_open: session 2: link with channel 2 debug1: server_input_channel_open: confirm session debug1: server_input_channel_open: ctype session rchan 3 win 131072 max 32768 debug1: input_session_request debug1: channel 3: new [server-session] debug1: session_new: session 3 debug1: session_open: channel 3 debug1: session_open: session 3: link with channel 3 debug1: server_input_channel_open: confirm session debug1: server_input_channel_open: ctype session rchan 4 win 131072 max 32768 debug1: input_session_request debug1: channel 4: new [server-session] debug1: session_new: session 4 debug1: session_open: channel 4 debug1: session_open: session 4: link with channel 4 debug1: server_input_channel_open: confirm session debug1: server_input_channel_open: ctype session rchan 5 win 131072 max 32768 debug1: input_session_request debug1: channel 5: new [server-session] debug1: session_new: session 5 debug1: session_open: channel 5 debug1: session_open: session 5: link with channel 5 debug1: server_input_channel_open: confirm session debug1: server_input_channel_open: ctype session rchan 6 win 131072 max 32768 debug1: input_session_request debug1: channel 6: new [server-session] debug1: session_new: session 6 debug1: session_open: channel 6 debug1: session_open: session 6: link with channel 6 debug1: server_input_channel_open: confirm session debug1: server_input_channel_open: ctype session rchan 7 win 131072 max 32768 debug1: input_session_request debug1: channel 7: new [server-session] debug1: session_new: session 7 debug1: session_open: channel 7 debug1: session_open: session 7: link with channel 7 debug1: server_input_channel_open: confirm session debug1: server_input_channel_open: ctype session rchan 8 win 131072 max 32768 debug1: input_session_request debug1: channel 8: new [server-session] debug1: session_new: session 8 debug1: session_open: channel 8 debug1: session_open: session 8: link with channel 8 debug1: server_input_channel_open: confirm session debug1: server_input_channel_open: ctype session rchan 9 win 131072 max 32768 debug1: input_session_request debug1: channel 9: new [server-session] debug1: session_new: session 9 debug1: session_open: channel 9 debug1: session_open: session 9: link with channel 9 debug1: server_input_channel_open: confirm session debug1: server_input_channel_open: ctype session rchan 10 win 131072 max 32768 debug1: input_session_request debug2: channel: expanding 20 debug1: channel 10: new [server-session] debug1: session_new: session 10 debug1: session_open: channel 10 debug1: session_open: session 10: link with channel 10 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 2 request exec reply 0 debug1: session_by_channel: session 2 channel 2 debug1: session_input_channel_req: session 2 req exec debug2: fd 14 setting O_NONBLOCK debug2: fd 12 setting O_NONBLOCK debug2: fd 16 setting O_NONBLOCK debug1: server_input_channel_req: channel 3 request exec reply 0 debug1: session_by_channel: session 3 channel 3 debug1: session_input_channel_req: session 3 req exec debug2: fd 17 setting O_NONBLOCK debug2: fd 15 setting O_NONBLOCK debug2: fd 19 setting O_NONBLOCK debug1: server_input_channel_req: channel 4 request exec reply 0 debug1: session_by_channel: session 4 channel 4 debug1: session_input_channel_req: session 4 req exec debug2: fd 20 setting O_NONBLOCK debug2: fd 18 setting O_NONBLOCK debug2: fd 22 setting O_NONBLOCK debug1: server_input_channel_req: channel 5 request exec reply 0 debug1: session_by_channel: session 5 channel 5 debug1: session_input_channel_req: session 5 req exec debug1: Received SIGCHLD. debug1: Received SIGCHLD. debug2: fd 23 setting O_NONBLOCK debug2: fd 21 setting O_NONBLOCK debug2: fd 25 setting O_NONBLOCK debug1: server_input_channel_req: channel 6 request exec reply 0 debug1: session_by_channel: session 6 channel 6 debug1: session_input_channel_req: session 6 req exec debug1: Received SIGCHLD. debug1: Received SIGCHLD. debug2: fd 26 setting O_NONBLOCK debug2: fd 24 setting O_NONBLOCK debug2: fd 28 setting O_NONBLOCK debug1: server_input_channel_req: channel 7 request exec reply 0 debug1: session_by_channel: session 7 channel 7 debug1: session_input_channel_req: session 7 req exec debug2: fd 29 setting O_NONBLOCK debug2: fd 27 setting O_NONBLOCK fcntl(31, F_GETFL, 0): Bad file descriptor select: Bad file descriptor debug1: session_by_pid: pid 3792 debug1: session_exit_message: session 1 channel 1 pid 3792 debug2: channel 1: request exit-status confirm 0 debug1: session_exit_message: release channel 1 debug2: channel 1: write failed debug2: channel 1: close_write debug2: channel 1: output open -> closed debug1: session_by_pid: pid 576 debug1: session_exit_message: session 2 channel 2 pid 576 debug2: channel 2: request exit-status confirm 0 debug1: session_exit_message: release channel 2 debug2: channel 2: write failed debug2: channel 2: close_write debug2: channel 2: output open -> closed debug1: session_by_pid: pid 3520 debug1: session_exit_message: session 3 channel 3 pid 3520 debug2: channel 3: request exit-status confirm 0 debug1: session_exit_message: release channel 3 debug2: channel 3: write failed debug2: channel 3: close_write debug2: channel 3: output open -> closed debug1: session_by_pid: pid 3972 debug1: session_exit_message: session 4 channel 4 pid 3972 debug2: channel 4: request exit-status confirm 0 debug1: session_exit_message: release channel 4 debug2: channel 4: write failed debug2: channel 4: close_write debug2: channel 4: output open -> closed select: Bad file descriptor select: Bad file descriptor . . (50 times) . . select: Bad file descriptor select: Bad file descriptor debug1: Received SIGCHLD. debug1: session_by_pid: pid 3592 debug1: session_exit_message: session 5 channel 5 pid 3592 debug2: channel 5: request exit-status confirm 0 debug1: session_exit_message: release channel 5 debug2: channel 5: write failed debug2: channel 5: close_write debug2: channel 5: output open -> closed select: Bad file descriptor select: Bad file descriptor select: Bad file descriptor select: Bad file descriptor select: Bad file descriptor select: Bad file descriptor . . (9000 times) . . select: Bad file descriptor select: Bad file descriptor select: Bad file descriptor select: Bad file descriptor select: Bad file descriptor select: Bad file descriptor select: Bad file descriptor Exiting on signal 15 debug1: do_cleanup debug1: session_pty_cleanup: session 0 release /dev/tty5 From nivv at cs.bgu.ac.il Sat Sep 9 18:36:41 2006 From: nivv at cs.bgu.ac.il (Niv) Date: Sat, 09 Sep 2006 11:36:41 +0300 Subject: cygwin ssh goes heavy cpu uasage Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I noticed that if I install cygwin ssh on a laptop , the cpu usage goes to 80-90% when not all the network adaptors are connected. how may I assist in reporting this bug better? can some one pls point me to a version compilied with the debug flag? how can I use gdb on windows to report this? Niv -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFAn0ZkwazfG0MmCYRAvWEAJ0ZCooIMCdagD7rhmEV7bFbM4pcpQCgswOO DMGUcy2ZKxkZ449nwCQv6hY= =zR+R -----END PGP SIGNATURE----- _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From gzjimfan at gmail.com Sun Sep 10 11:35:48 2006 From: gzjimfan at gmail.com (Jim Fan) Date: Sat, 9 Sep 2006 18:35:48 -0700 Subject: Corrupted MAC problem on PSOS platform Message-ID: Hi Group, I am porting openSSH to an embedded platform running pSOS. I am able to setup a connection with the server but after I disconnect and reconnect, I always get the following error message and client won't establish connection with the server. debug: Enabling compatibility mode for protocol 2.0 debug: SSH2_MSG_KEXINIT sent debug: kex: client->server aes256-cbc hmac-sha1 none debug: kex: server->client aes256-cbc hmac-sha1 none debug: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received debug: SSH2_MSG_KEX_DH_GEX_GROUP sent debug: expecting SSH2_MSG_KEX_DH_GEX_INIT debug: SSH2_MSG_KEX_DH_GEX_REPLY sent debug: kex_derive_keys........................ debug: newkeys[1]=0xfd4868 debug: SSH2_MSG_NEWKEYS sent debug: expecting SSH2_MSG_NEWKEYS debug: newkeys[0]=0xfd4748 debug: SSH2_MSG_NEWKEYS received debug: userauth-request for user terter service ssh-connection method none debug: attempt 0 failures 0 debug: userauth-request for user terter service ssh-connection method keyboard-interactive debug: attempt 1 failures 1 debug: keyboard-interactive devs debug: auth2_challenge: user=terter devs= debug: kbdint_alloc: devices '' debug: userauth-request for user terter service ssh-connection method password debug: attempt 2 failures 2 Accepted password for terter from 172.23.1.174 port 1331 ssh2 Accepted password for terter from 172.23.1.174 port 1331 ssh2 debug: Entering interactive session for SSH2. debug: server_init_dispatch_20 debug: server_input_channel_open: ctype session rchan 256 win 16384 max 16384 debug: input_session_request debug: channel 0: new [server-session] debug: session_new: init debug: session_new: session 0 debug: session_open: channel 0 debug: session_open: session 0: link with channel 0 debug: server_input_channel_open: confirm session debug: server_input_channel_req: channel 0 request pty-req reply 1 debug: session_by_channel: session 0 channel 0 debug: session_input_channel_req: session 0 req pty-req debug: Allocating pty. debug: session_pty_req: session 0 alloc debug: server_input_channel_req: channel 0 request shell reply 1 debug: session_by_channel: session 0 channel 0 debug: session_input_channel_req: session 0 req shell Secure shell client connected Secure shell client disconnected debug: channel 0: free: server-session, nchannels 1 debug: session_close: session 0 pid 0 000110.999|SSHD |3|01|Closing connection to 172.23.1.174 debug: Enabling compatibility mode for protocol 2.0 debug: SSH2_MSG_KEXINIT sent debug: kex: client->server aes256-cbc hmac-sha1 none debug: kex: server->client aes256-cbc hmac-sha1 none debug: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received debug: SSH2_MSG_KEX_DH_GEX_GROUP sent debug: expecting SSH2_MSG_KEX_DH_GEX_INIT debug: SSH2_MSG_KEX_DH_GEX_REPLY sent debug: kex_derive_keys........................ debug: newkeys[1]=0x1024898 debug: SSH2_MSG_NEWKEYS sent debug: expecting SSH2_MSG_NEWKEYS debug: newkeys[0]=0x1024778 debug: SSH2_MSG_NEWKEYS received macbuf------------------------------20 5d38305c8b399a79c644d9e021be0d2247d1124 input------------------------------- 3b50 7e58 d759 5dfc dbe5 6c3f 46df 7297 a0cf d748 Disconnecting: Corrupted MAC on input. Disconnecting: Corrupted MAC on input. I checked key exchanges in both connections and they all looked ok. Any ideas why MAC check would fail on second connection attempt? Best Regards, Jim _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Sun Sep 10 13:05:01 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 10 Sep 2006 13:05:01 +1000 Subject: Make Install Failed for 4.4p1 on FC4 Message-ID: pwasik at optonline.net wrote: > I tried to build the CVS snapshot for OpenSSH 4.4p1 dated 9/08/06. Make install failed on Fedora Core 4 system with the following errors: [...] > make[1]: *** No rule to make target `Ssh.bin', needed by `install'. Stop. > make[1]: Leaving directory `/usr/local/openssh/scard' > make: *** [scard-install] Error 2 Try: $ cd scard && make -f Makefile.in distprep > My platform is Fedora Core 4 with latest updates You will need uudecode installed, which is probably in the "sharutils" rpm. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Sun Sep 10 13:15:53 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 10 Sep 2006 13:15:53 +1000 Subject: cygwin ssh goes heavy cpu uasage Message-ID: Niv wrote: > I noticed that if I install cygwin ssh on a laptop , the cpu usage goes > to 80-90% when not all the network adaptors are connected. Which process is using the CPU, ssh or sshd? If it's sshd, does setting ListenAddress in sshd_config to listen only on the address that's live and restarting sshd make any difference? > how may I assist in reporting this bug better? can some one pls point me > to a version compilied with the debug flag? how can I use gdb on windows > to report this? gdb is probably not going to help much here, instead trace attaching strace to the process: run "ps -eaf" and pick out the pid of the process, then run "strace -p [pid]" on that particular process (be aware that it will probably generate a lot of output). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Sun Sep 10 14:42:54 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 10 Sep 2006 14:42:54 +1000 Subject: Corrupted MAC problem on PSOS platform Message-ID: Jim Fan wrote: > Hi Group, > I am porting openSSH to an embedded platform running pSOS. I am able > to setup a connection with the server but after I disconnect and > reconnect, I always get the following error message and client won't > establish connection with the server. [...] > Disconnecting: Corrupted MAC on input. > Disconnecting: Corrupted MAC on input. What's on the network between client and server? Some network devices (eg certain firmware revs of Linksys routers) have been reported to cause this. The possible causes we know about are documented here: http://bugzilla.mindrot.org/show_bug.cgi?id=510 http://bugzilla.mindrot.org/show_bug.cgi?id=845 Failing that, I would try compiling everything (zlib, openssl and openssh) without any optimization and seeing if that makes a difference. > I checked key exchanges in both connections and they all looked ok. > Any ideas why MAC check would fail on second connection attempt? Maybe the different DH parameters negotiated in the DH GEX has some effect? Try removing the moduli file on the server and it will fall back to group1 or group14. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Sun Sep 10 15:12:17 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 10 Sep 2006 15:12:17 +1000 Subject: Testing for the 4.4p1 release Message-ID: On Thu, Aug 31, 2006 at 08:50:04AM +0300, Pekka Savola wrote: > On Wed, 30 Aug 2006, Damien Miller wrote: > > Running the regression tests supplied with Portable does not require > > installation, just run: > > > > $ ./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, including > > details of your platform, compiler and configure options. Thanks for testing and sorry it took so long to get back to you. > On RHL73 with gcc 2.96, 'make tests' doesn't finish and appears to get > stuck (strace shows the process is in wait()). There were a number of > compilation warnings. The ones coming from ciphers and macs appear to > be old, but these are new and at least implicit decls should be easily > fixable: > > warning: __nonnull__' attribute directive ignored (50+ times) We could do something like the patch below. > uidswap.c: In function Permanently_drop_suid': > uidswap.c:142: warning: implicit declaration of function Setresuid' > uidswap.c: In function Permanently_set_uid': > uidswap.c:224: warning: implicit declaration of function Setresgid' Last time I looked, setresuid and setresgid were not defined in any system header on old Linuxes. > md5crypt.c: In function To64': > md5crypt.c:31: warning: implicit declaration of function Memset' > md5crypt.c: In function s_md5_salt': > md5crypt.c:43: warning: implicit declaration of function Strncmp' > md5crypt.c:43: warning: implicit declaration of function Strlen' > md5crypt.c: In function Md5_crypt': > md5crypt.c:73: warning: implicit declaration of function Memcpy' These have been fixed by including string.h. [...] > from 127.0.0.1 port 44319 (t4 r26 i0/0 o0/0 fd 27/27 cfd -1) > [[ almost 10 minute timeout ]] > ssh_exchange_identification: Connection closed by remote host > cmp: EOF on /home/pekkas/op/openssh/regress/ls.copy > corrupted copy of /bin/ls > bind: Address already in use > [[ about 5 minute timeout ]] Now this I'm not sure about. Index: defines.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/defines.h,v retrieving revision 1.137 diff -u -p -r1.137 defines.h --- defines.h 18 Aug 2006 22:38:24 -0000 1.137 +++ defines.h 10 Sep 2006 05:04:31 -0000 @@ -449,6 +449,10 @@ struct winsize { # define __bounded__(x, y, z) #endif +#ifndef __nonnull__ +# define __nonnull__ +#endif + /* *-*-nto-qnx doesn't define this macro in the system headers */ #ifdef MISSING_HOWMANY # define howmany(x,y) (((x)+((y)-1))/(y)) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From serzan at hellug.gr Mon Sep 11 07:26:00 2006 From: serzan at hellug.gr (Serafeim Zanikolas) Date: Sun, 10 Sep 2006 22:26:00 +0100 Subject: non-informative error message Message-ID: Hello, The openssh client terminates with the following error message when unable to resolve a username: "You don't exist, go away!" Leaving aside style and tone, the message is not informative. Please consider changing it to something more appropriate and helpful, such as "Unable to resolve username". (The message appears in the files ssh-keygen.c and ssh.c, as of version openssh-4.2p1) Thanks, Serafeim ps. please CC me as I'm not subscribed _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From bob at proulx.com Mon Sep 11 09:53:38 2006 From: bob at proulx.com (Bob Proulx) Date: Sun, 10 Sep 2006 17:53:38 -0600 Subject: non-informative error message Message-ID: Serafeim Zanikolas wrote: > ps. please CC me as I'm not subscribed > The openssh client terminates with the following error message when > unable to resolve a username: "You don't exist, go away!" A traditional styled message. Try 'who' in that same "impossible" situation. It will print out "Intruder Alert!". Did you actually receive this error message? What was the circumstance? How likely is this error to occur? > Leaving aside style and tone, the message is not informative. Please > consider changing it to something more appropriate and helpful, such > as "Unable to resolve username". The message is in the traditional style of a message in an "impossible" situation. Obviously it is possible but it shouldn't be. It can only happen if a previous system error has occurred. How can a user exist on a system when the user is not defined for the system? (Yes, obviously there are ways, that is not my point.) I am not an ssh developer but as a system user these things are part of the culture and often make the system more enjoyable to live and work on than if it were only dry messages, even if perhaps more accurate. I would not be opposed to adding additional error text, but I would hate to see the culture become too bland, like food designed to offend no one, which then often pleases no one either. Bob _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From vsync at quadium.net Mon Sep 11 10:39:56 2006 From: vsync at quadium.net (Tim Howe) Date: Sun, 10 Sep 2006 18:39:56 -0600 Subject: non-informative error message Message-ID: Serafeim Zanikolas writes: > The openssh client terminates with the following error message when unable to > resolve a username: "You don't exist, go away!" > > Leaving aside style and tone, the message is not informative. Please consider > changing it to something more appropriate and helpful, such as "Unable to > resolve username". I request that this message stay the same and that users consider gaining a sense of humor and a cultural understanding of the systems in use. -- vsync http://quadium.net/ If addiction is judged by how long a dumb animal will sit pressing a lever to get a "fix" of something, to its own detriment, then I would conclude that netnews is far more addictive than cocaine. -- Rob Stampfli _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From pekkas at netcore.fi Mon Sep 11 16:16:24 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 11 Sep 2006 09:16:24 +0300 (EEST) Subject: Testing for the 4.4p1 release Message-ID: On Sun, 10 Sep 2006, Darren Tucker wrote: >> On RHL73 with gcc 2.96, 'make tests' doesn't finish and appears to get >> stuck (strace shows the process is in wait()). There were a number of >> compilation warnings. The ones coming from ciphers and macs appear to >> be old, but these are new and at least implicit decls should be easily >> fixable: >> >> warning: __nonnull__' attribute directive ignored (50+ times) > > We could do something like the patch below. I retried with the latest snapshot and the patch. The patch doesn't work, it results in a a compilation error: In file included from bsd-misc.c:31: ../xmalloc.h:26: parse error before (' >> uidswap.c: In function Permanently_drop_suid': >> uidswap.c:142: warning: implicit declaration of function Setresuid' >> uidswap.c: In function Permanently_set_uid': >> uidswap.c:224: warning: implicit declaration of function Setresgid' > > Last time I looked, setresuid and setresgid were not defined in any system > header on old Linuxes. True, I don't see them myself either.. > These have been fixed by including string.h. cipher-aes.c also seems to need it, or some other relevant .h include, as it complains about memcpy and memset. > [...] >> from 127.0.0.1 port 44319 (t4 r26 i0/0 o0/0 fd 27/27 cfd -1) >> [[ almost 10 minute timeout ]] >> ssh_exchange_identification: Connection closed by remote host >> cmp: EOF on /home/pekkas/op/openssh/regress/ls.copy >> corrupted copy of /bin/ls >> bind: Address already in use >> [[ about 5 minute timeout ]] > > Now this I'm not sure about. This is still the same. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From ken at hero.com Mon Sep 11 16:34:54 2006 From: ken at hero.com (Kenneth Berland) Date: Sun, 10 Sep 2006 23:34:54 -0700 (PDT) Subject: openssh-4.3p2: setsockopt() problem Message-ID: List, I'm behind a dlink DSL-G604T wireless router. ssh client was hanging at: debug1: Entering interactive session. Telnet was having a similar problem to port 22, however a simple client.c I compiled was not. My java ssh client was also working. After some investigation, I noticed that the hang was after the system call: setsockopt(3, SOL_IP, IP_TOS, [16], 4) = 0 I noticed also that telnet was hanging the same way. I commented all the setsockopt() calls out of the ssh client code (because I was in a hurry) and now it works. Anyway, I figured I should document the problem somewhere. -Ken _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From serzan at hellug.gr Mon Sep 11 20:26:57 2006 From: serzan at hellug.gr (Serafeim Zanikolas) Date: Mon, 11 Sep 2006 11:26:57 +0100 Subject: non-informative error message Message-ID: On Monday 11 September 2006 01:39, Tim wrote: > I request that this message stay the same and that users consider > gaining a sense of humor and a cultural understanding of the systems in > use. OK, it did give me a good laugh the first couple of times, but after a while it just gets annoying. Perhaps you could consider changing the message to something witty _and_ informative (eg, bash under the same circumstances says "I have no name!"). But then again, I'd rather not be though of as an exterminator of your cultural heritage :) (For the history, the error arises because I'm authenticated by a NIS server behind a faulty-soon-to-be-replaced switch that causes occasional timeouts) Cheers, Serafeim _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Mon Sep 11 20:59:05 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 11 Sep 2006 20:59:05 +1000 Subject: Testing for the 4.4p1 release Message-ID: On Mon, Sep 11, 2006 at 09:16:24AM +0300, Pekka Savola wrote: > On Sun, 10 Sep 2006, Darren Tucker wrote: > >> On RHL73 with gcc 2.96, 'make tests' doesn't finish and appears to get > >> stuck (strace shows the process is in wait()). There were a number of > >> compilation warnings. The ones coming from ciphers and macs appear to > >> be old, but these are new and at least implicit decls should be easily > >> fixable: > >> > >> warning: __nonnull__' attribute directive ignored (50+ times) > > > > We could do something like the patch below. > > I retried with the latest snapshot and the patch. Thanks. > The patch doesn't work, it results in a a compilation error: > In file included from bsd-misc.c:31: > ../xmalloc.h:26: parse error before (' Yeah, that patch is a bad idea, so I think we'll probably leave this alone for now. I can't think of a way to reliably detect which __attribute__ 's are supported. [...] > > These have been fixed by including string.h. > > cipher-aes.c also seems to need it, or some other relevant .h include, > as it complains about memcpy and memset. Indeed it does, however it's only obvious with older OpenSSL version where that code is compiled in. Fixed, thanks. > > [...] > >> from 127.0.0.1 port 44319 (t4 r26 i0/0 o0/0 fd 27/27 cfd -1) > >> [[ almost 10 minute timeout ]] > >> ssh_exchange_identification: Connection closed by remote host > >> cmp: EOF on /home/pekkas/op/openssh/regress/ls.copy > >> corrupted copy of /bin/ls > >> bind: Address already in use > >> [[ about 5 minute timeout ]] > > > > Now this I'm not sure about. > > This is still the same. During the timeout phase, is there a defunct process in the process list, and if so what process does its ppid correspond to? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From pekkas at netcore.fi Mon Sep 11 21:19:35 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 11 Sep 2006 14:19:35 +0300 (EEST) Subject: Testing for the 4.4p1 release Message-ID: On Mon, 11 Sep 2006, Darren Tucker wrote: >>> [...] >>>> from 127.0.0.1 port 44319 (t4 r26 i0/0 o0/0 fd 27/27 cfd -1) >>>> [[ almost 10 minute timeout ]] >>>> ssh_exchange_identification: Connection closed by remote host >>>> cmp: EOF on /home/pekkas/op/openssh/regress/ls.copy >>>> corrupted copy of /bin/ls >>>> bind: Address already in use >>>> [[ about 5 minute timeout ]] >>> >>> Now this I'm not sure about. >> >> This is still the same. > > During the timeout phase, is there a defunct process in the process list, > and if so what process does its ppid correspond to? During the timeout, the processes look something like this: pekkas 11767 8459 0 14:10 pts/4 00:00:00 sh /home/pekkas/o/openssh/regres pekkas 11798 1 0 14:10 ? 00:00:00 /home/pekkas/o/openssh/sshd -f / pekkas 11826 1 0 14:10 ? 00:00:00 /home/pekkas/o/openssh/ssh -1 -F pekkas 11827 11767 0 14:10 pts/4 00:00:00 /home/pekkas/o/openssh/ssh -2 -F PPID=1 looks odd, and indeed if I kill them the timeout stops, but the compilation result is the same error. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From Dan.Goldburt at dowjones.com Mon Sep 11 22:22:36 2006 From: Dan.Goldburt at dowjones.com (Goldburt, Dan) Date: Mon, 11 Sep 2006 08:22:36 -0400 Subject: Multiple (multiplexed) simultaneous ssh connections - Cygwin bug? Message-ID: Hi, Ok, so I'm thinking about taking Darren's suggestion: > It's not pretty but you could run multiple sshd's on several ports. But before I do, I was hoping to get some help in optimizing the fix. 1. What does the cygwin limitation bound my max sessions to? Is it: a) 30 > You'll have the stdout and stderr descriptors in the > select's readset, > which for FD_SETSIZE=64 puts the limit at around 30 > connections or so > (assuming you're not port forwarding or something too). b) 20 > Thinking about it, that's wrong (I was thinking of poll). > Since select > uses bitmasks it doesn't matter how many are in each of > the readset and > writeset so the limit would be around 20 concurrent. or c) 10 > I think I'm definitely overrunning the fd_set. Running the > test again with a just started sshd instance, I get the > error fcntl(31, F_GETFL, 0). So the limit seems to be 30 > fds, or 10 connections (3 fd per connection). 2. I need to make sure if I do still accidentally overrun the fd_set, I will not crash sshd. Right now it goes into an infinite loop spitting out "select: Bad file descriptor" and taking up 100% CPU. Surely this is a bug that needs to be patched? 3. Any chance I can overcome the limitation from inside sshd? How do I implement the following: > To make this work, you would probably need to break the > select into FD_SETSIZE chunks somehow. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From kuenne at rentec.com Tue Sep 12 00:27:40 2006 From: kuenne at rentec.com (Karsten [iso-8859-1] Künne) Date: Mon, 11 Sep 2006 10:27:40 -0400 Subject: non-informative error message Message-ID: On Sunday 10 September 2006 20:39, Tim Howe wrote: > Serafeim Zanikolas writes: > > The openssh client terminates with the following error message when > > unable to resolve a username: "You don't exist, go away!" > > > > Leaving aside style and tone, the message is not informative. Please > > consider changing it to something more appropriate and helpful, such as > > "Unable to resolve username". > > I request that this message stay the same and that users consider > gaining a sense of humor and a cultural understanding of the systems in > use. Full Ack! Leave it as it is! Karsten. -- People who claim they don't let little things bother them have never slept in a room with a single mosquito. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From hir3npatel at gmail.com Tue Sep 12 01:28:25 2006 From: hir3npatel at gmail.com (Hiren Patel) Date: Mon, 11 Sep 2006 17:28:25 +0200 Subject: scp files with ':' in filename Message-ID: greetings, would it be a good idea to include within the scp man pages, how one would use scp to copy files which have the ' : ' character in the filename? a friend struggled a little trying to do this, discovered the answer on google, i thought it might be usefull to have in the man pages too. the solution was to use the files' full path so that scp recognised it as a file. please cc me on any replys as im not subcribed to the list. thanks. -- Hiren Patel Why is it that we rejoice at a birth and grieve at a funeral? It is because we are not the person involved. -- Mark Twain _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From gert at greenie.muc.de Tue Sep 12 06:52:08 2006 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 11 Sep 2006 22:52:08 +0200 Subject: openssh-4.3p2: setsockopt() problem Message-ID: Hi, On Sun, Sep 10, 2006 at 11:34:54PM -0700, Kenneth Berland wrote: > I'm behind a dlink DSL-G604T wireless router. ssh client was hanging at: > > debug1: Entering interactive session. This happens if you have a NAT implementation that cannot handle connections that change their ToS (Type of Service) flags "in flight". I don't have a good idea how to work around those, though (well, when I ran into this first time, I just tried using putty, which worked, because it doesn't modify the ToS bits). 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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Tue Sep 12 08:21:55 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 12 Sep 2006 08:21:55 +1000 Subject: Multiple (multiplexed) simultaneous ssh connections - Cygwin bug? Message-ID: Goldburt, Dan wrote: > Hi, > > Ok, so I'm thinking about taking Darren's suggestion: >> It's not pretty but you could run multiple sshd's on several ports. > > But before I do, I was hoping to get some help in optimizing the fix. > > 1. What does the cygwin limitation bound my max sessions to? > Is it: > a) 30 >> You'll have the stdout and stderr descriptors in the >> select's readset, >> which for FD_SETSIZE=64 puts the limit at around 30 >> connections or so >> (assuming you're not port forwarding or something too). > b) 20 >> Thinking about it, that's wrong (I was thinking of poll). >> Since select >> uses bitmasks it doesn't matter how many are in each of >> the readset and >> writeset so the limit would be around 20 concurrent. > or c) 10 >> I think I'm definitely overrunning the fd_set. Running the >> test again with a just started sshd instance, I get the >> error fcntl(31, F_GETFL, 0). So the limit seems to be 30 >> fds, or 10 connections (3 fd per connection). I'm not sure, actually. You seem to be hitting some limit at 31 descriptors before the fd_set one, which should be at 64 (3 per session = ~20 concurrent). What does "ulimit -n" report the descriptor limit as, and do you have some local processes using some of them? > 2. I need to make sure if I do still accidentally overrun the fd_set, I > will not crash sshd. Right now it goes into an infinite loop spitting > out "select: Bad file descriptor" and taking up 100% CPU. Surely this is > a bug that needs to be patched? Maybe, but it only occurs with modified code, right? > 3. Any chance I can overcome the limitation from inside sshd? How do I > implement the following: >> To make this work, you would probably need to break the >> select into FD_SETSIZE chunks somehow. I was thinking of overloading select an associated macros in the compat library but it's probably not trivial. Damien said that the fd_sets were dynamically allocated but I'm not sure how that helps in the case where there's more than FD_SETSIZE descriptors. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From ark at eltex.net Tue Sep 12 21:02:26 2006 From: ark at eltex.net (ArkanoiD) Date: Tue, 12 Sep 2006 15:02:26 +0400 Subject: openssh (OpenBSD) , bsdauth and tis authsrv Message-ID: nuqneH, I've tried using TIS authsrv authentication via bsd auth and found it quite limited. The most important restriction it does not log ip and fqdn of the remote peer, nor the application name, to the authentication server. It does not matter much for TIS authsrv, but since other applications do provide such information, our authsrv version uses it for extra authentication restrictions. And - as tcp loopback interface is hardly considered secure - we use unix domain sockets to talk to it instead. I tried Mark Roth's patch, but it suffers from the similar problems and does not support privsep api. So i made my own, it is not very good yet (it does not take advantage of init_ctx) but i hope i will fix that soon if you people will give me good advices. [ Part 2, Text/PLAIN (charset: KOI8-R "Latin & Russian") 914 ] [ lines. ] [ Unable to print this part. ] [ Part 3: "Attached Text" ] _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From Dan.Goldburt at dowjones.com Wed Sep 13 00:38:36 2006 From: Dan.Goldburt at dowjones.com (Goldburt, Dan) Date: Tue, 12 Sep 2006 10:38:36 -0400 Subject: Multiple (multiplexed) simultaneous ssh connections - Cygwin bug? Message-ID: > Darren Tucker wrote: > > Goldburt, Dan wrote: > > > > 1. What does the cygwin limitation bound my max sessions > to? > > I'm not sure, actually. You seem to be hitting some limit > at 31 > descriptors before the fd_set one, which should be at 64 > (3 per session > = ~20 concurrent). What does "ulimit -n" report the > descriptor limit > as, and do you have some local processes using some of > them? ulimit -n on cygwin reports 256 open files max. Is there a per-process limit? I'm thinking specifically about setdtablesize() (see http://sourceware.org/ml/cygwin/2000-09/msg00286.html) > > 2. I need to make sure if I do still accidentally > overrun the fd_set, I > > will not crash sshd. Right now it goes into an infinite > loop spitting > > out "select: Bad file descriptor" and taking up 100% > CPU. Surely this is > > a bug that needs to be patched? > > Maybe, but it only occurs with modified code, right? Not necessarily. The only modification was to increase MAX_SESSIONS per connection from 10 to 128. But even without the change, let's say I have one multiplexed connection that is hosting 10 sessions. I can also simultaneously open 15 regular ssh connections to have 25 sessions opening up, and there is a good chance I will overrun the fd_set. > > 3. Any chance I can overcome the limitation from inside > sshd? How do I > > implement the following: > >> To make this work, you would probably need to break the > >> select into FD_SETSIZE chunks somehow. > > I was thinking of overloading select an associated macros > in the compat > library but it's probably not trivial. Kudos to anyone who attempts that. It would make for a very robust solution, IMHO. Even better would be for this change to be made in the Cygwin select() code (that is what sshd is using, correct? Also, there seems to be some confusion whether winsock's select() implementation is being used in cygwin or not - see http://sourceware.org/ml/cygwin/1999-12/msg00149.html). > Damien said that > the fd_sets > were dynamically allocated but I'm not sure how that helps > in the case > where there's more than FD_SETSIZE descriptors. I'm not sure either. What does he mean by dynamically allocated? I see in serverloop.c (lines 638 - 642): > max_fd = MAX(connection_in, connection_out); > max_fd = MAX(max_fd, fdin); > max_fd = MAX(max_fd, fdout); > max_fd = MAX(max_fd, fderr); > max_fd = MAX(max_fd, notify_pipe[0]); which dynamically increments the number of file descriptors to select on. The next lines (655 and 645) use this value: > /* Sleep in select() until we can do something. */ > wait_until_can_do_something(&readset, &writeset, &max_fd, > &nalloc, max_time_milliseconds); and this is where (I think/haven't proved) the bug lives. As soon as max_fd exceeds FD_SETSIZE, we try to select on a fd outside of the cygwin supported array size. This accounts for the "select: Bad file descriptor" error, but more importantly since the fd we are actually interested in lies outside of the selectable range, the returned bitmask will never change and we will never break out of the "sleep in select loop". (see http://sourceware.org/ml/cygwin/1999-11/msg00451.html) I think this is a serious bug on, can somebody please vet my analysis? As far as I can tell, max_fd should be bounded to FD_SETSIZE under cygwin. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Wed Sep 13 00:49:35 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 13 Sep 2006 00:49:35 +1000 Subject: Multiple (multiplexed) simultaneous ssh connections - Cygwin bug? Message-ID: On Tue, Sep 12, 2006 at 10:38:36AM -0400, Goldburt, Dan wrote: > Not necessarily. The only modification was to increase MAX_SESSIONS per > connection from 10 to 128. But even without the change, let's say I have > one multiplexed connection that is hosting 10 sessions. I can also > simultaneously open 15 regular ssh connections to have 25 sessions > opening up, and there is a good chance I will overrun the fd_set. No, the file descriptor table (and thus fd_set) is per-process and each SSH connection has its own sshd process handling it. (It's a bit late here to go into the rest of your mail, sorry.) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From vc.Scott.F.Strickler at Lowes.com Wed Sep 13 00:37:58 2006 From: vc.Scott.F.Strickler at Lowes.com (Strickler, Scott - Scott F) Date: Tue, 12 Sep 2006 10:37:58 -0400 Subject: Weird TZ Behavior in 4.1p1 and 4.3p2 on AIX Message-ID: Hi, I am using PAM authentication on 3.8p1. In my PAM auth module I can turn on debug logging that includes a timestamp in the form "mm/dd/yy hh:mm:ss". Life is good. I want to upgrade from 3.8p1 so I can use PAM for PasswordAuthentication in addition to keyboard-interactive. I have compiled both 4.1p1 and 4.3p2 and the PAM authentication for both methods works fine in both releases, but I have a weird annoyance in the logging. The timestamp code appears to be ignoring the TZ setting. Here is a snippet from the logfile where I changed back and forth from 3.8p1 and 4.1p1 as I logged in ~ 9:30 this morning: 09/12/06 09:34:52 username hostname.xxxxx.com 09/12/06 09:35:02 username authenticating locally 09/12/06 09:35:02 username local authentication succeeded 09/12/06 13:35:21 username hostname.xxxxx.com 09/12/06 13:35:25 username authenticating locally 09/12/06 13:35:25 username local authentication succeeded 09/12/06 09:36:07 username hostname.xxxxx.com 09/12/06 09:36:12 username authenticating locally I found that commenting out "environ[0] = NULL;" in pam-auth.c fixed the TZ problem, but created others. Any suggestions? Scott Strickler ***** Please note: The Sender of this email is either a Contractor or Vendor of Lowe's Companies, Inc. and is not an employee or agent of Lowe's Companies Inc. ***** _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Wed Sep 13 08:17:33 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 13 Sep 2006 08:17:33 +1000 Subject: Weird TZ Behavior in 4.1p1 and 4.3p2 on AIX Message-ID: On Tue, Sep 12, 2006 at 10:37:58AM -0400, Strickler, Scott - Scott F wrote: > I want to upgrade from 3.8p1 so I can use PAM for PasswordAuthentication > in addition to keyboard-interactive. I have compiled both 4.1p1 and > 4.3p2 and the PAM authentication for both methods works fine in both > releases, but I have a weird annoyance in the logging. The timestamp > code appears to be ignoring the TZ setting. Here is a snippet from the > logfile where I changed back and forth from 3.8p1 and 4.1p1 as I logged > in ~ 9:30 this morning: Maybe we should save and restore TZ, like the following? (untested) Index: auth-pam.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/auth-pam.c,v retrieving revision 1.140 diff -u -p -r1.140 auth-pam.c --- auth-pam.c 1 Sep 2006 05:38:36 -0000 1.140 +++ auth-pam.c 12 Sep 2006 22:13:49 -0000 @@ -437,10 +437,16 @@ sshpam_thread(void *ctxtp) u_int i; const char *pam_user; const char **ptr_pam_user = &pam_user; + char *tz = getenv("TZ"); pam_get_item(sshpam_handle, PAM_USER, (sshpam_const void **)ptr_pam_user); + environ[0] = NULL; + if (tz != NULL) + if (putenv("TZ", tz) == -1) + error("PAM: could not set TZ environment: %s", + strerror(errno)); if (sshpam_authctxt != NULL) { setproctitle("%s [pam]", -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From rapier at psc.edu Thu Sep 14 00:53:46 2006 From: rapier at psc.edu (Chris Rapier) Date: Wed, 13 Sep 2006 10:53:46 -0400 Subject: openssh-4.3p2: setsockopt() problem Message-ID: This is likely due to the router and how it is handling header information. If it's rewriting portions of the header after the syn is sent I could see a connections hanging. Getting a tcpdump of a connection on both sides would probably let you figure out exactly where the badness is taking place. Kenneth Berland wrote: > List, > > I'm behind a dlink DSL-G604T wireless router. ssh client was hanging at: > > debug1: Entering interactive session. > > Telnet was having a similar problem to port 22, however a simple client.c > I compiled was not. My java ssh client was also working. After some > investigation, I noticed that the hang was after the system call: > > setsockopt(3, SOL_IP, IP_TOS, [16], 4) = 0 > > I noticed also that telnet was hanging the same way. I commented all the > setsockopt() calls out of the ssh client code (because I was in a hurry) > and now it works. Anyway, I figured I should document the problem > somewhere. > > -Ken > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From Dan.Goldburt at dowjones.com Thu Sep 14 08:17:28 2006 From: Dan.Goldburt at dowjones.com (Goldburt, Dan) Date: Wed, 13 Sep 2006 18:17:28 -0400 Subject: Multiple (multiplexed) simultaneous ssh connections - Cygwin bug? Message-ID: Hi, To recap, I'm establishing one master ssh connection and am opening many session through that one master connection. Often I get "select: Bad file descriptor errors" and the server thrashes at 100% CPU. The symptoms are very similar to those in this post: http://sourceware.org/ml/cygwin/2001-09/msg01217.html But the solution there doesn't work for OpenSSH. Initially I believed that the number of file descriptors being opened were overrunning the fd_set. But it doesn't seem like I'm overrunning the FD_SETSIZE. On the server, ulimit -n return 256, and I also tried the following. Darren Tucker wrote: > BTW did you try bumping FD_SETSIZE when configuring > OpenSSH with your > increased MAX_SESSIONS? > eg: ./configure --with-cflags=-DFD_SETSIZE=256 > I'm getting select() errors randomly, sometimes selecting up to file descriptor 31, sometimes up to 38, sometimes up to 191, but sometimes I don't get any errors (even for over 80 simultaneous sessions.) But once it happens once, every subsequent select will fail (looping and thrashing the server). This seems to me to be a serious bug. Yes, I did increase MAX_SESSIONS from 10 to 128, but that just made it easier to generate the error. You can also reproduce it if you install sshd to listen on several ports (start it with multiple -p arguments), and on each port establish a multiplexed connection with many sessions. In any case, shouldn't OpenSSH somehow handle the EBADF? The offending code is in serverloop.c, line 332: ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp); I tried setting *maxfdp to FD_SETSIZE (as suggested in the post above), but then I would get EBADF every single time. I also tried setting *maxfdp to something small like 30, but then select would always come back with 0 because the fd it was interested in was greater than 30. The unix manpage defines "EBADF: One or more of the file descriptor sets specified a file descriptor that is not a valid open file descriptor." (http://www.scit.wlv.ac.uk/cgi-bin/mansec?3C+FD_SET). I modified the code to handle the EBADF error. An example of what I'm printing right now is "select: EBADF (bad file descriptor), maxfdp=38 FD_SETSIZE=256 readsetp=4 writesetp=4". Here is the code following the select: ret = select(..); if (ret == -1) { memset(*readsetp, 0, *nallocp); memset(*writesetp, 0, *nallocp); if (errno == EBADF) { error("select: EBADF (bad file descriptor), maxfdp=%d FD_SETSIZE=%d readsetp=%d writesetp=%d", (*maxfdp), FD_SETSIZE, sizeof(*readsetp), sizeof(*writesetp)); fatal("Bad file descriptor loop"); } else if (errno != EINTR) { error("select: %.100s", strerror(errno)); } } . . How can I print something to best debug the problem? Anybody have a best guess why I'm getting EBADF? Was a file descriptor unexpectedly closed but we are still trying to select on it? _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From aet at cc.hut.fi Thu Sep 14 21:20:03 2006 From: aet at cc.hut.fi (Antti Tapaninen) Date: Thu, 14 Sep 2006 14:20:03 +0300 (EEST) Subject: [PATCH] PermitRootLogin woes Message-ID: Hi all, among other things, we provide shell access to various unix based platforms for our students and university staff. Recently, there has been increasing number of root login attacks on one particular Tru64 machine running OpenSSH. The host is configured with "PermitRootLogin no" but every once in a while SIA auth with TCB enhanced security locks the root account. I suppose the problem could be solved at two separate levels, for SIA only in auth-sia.c, or for any password using auth method in auth-passwd.c. I'd prefer a fix just for auth-passwd.c, are there any reasons to try out auth_krb5_password, sshpam_auth_passwd or sys_auth_passwd if variable "ok" is set to zero already? Cheers, -Antti Index: auth-passwd.c =================================================================== RCS file: /openssh/openssh_cvs/auth-passwd.c,v retrieving revision 1.86 diff -u -r1.86 auth-passwd.c --- auth-passwd.c 5 Aug 2006 02:39:39 -0000 1.86 +++ auth-passwd.c 14 Sep 2006 10:54:12 -0000 @@ -88,7 +88,7 @@ #ifndef HAVE_CYGWIN if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES) - ok = 0; + return 0; #endif if (*password == '\0' && options.permit_empty_passwd == 0) return 0; Index: auth-sia.c =================================================================== RCS file: /openssh/openssh_cvs/auth-sia.c,v retrieving revision 1.18 diff -u -r1.18 auth-sia.c --- auth-sia.c 7 Sep 2006 23:54:41 -0000 1.18 +++ auth-sia.c 14 Sep 2006 10:54:12 -0000 @@ -55,12 +55,14 @@ int ret; SIAENTITY *ent = NULL; const char *host; + struct passwd * pw = authctxt->pw; - host = get_canonical_hostname(options.use_dns); - + if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES) + return (0); if (!authctxt->user || pass == NULL || pass[0] == '\0') return (0); + host = get_canonical_hostname(options.use_dns); if (sia_ses_init(&ent, saved_argc, saved_argv, host, authctxt->user, NULL, 0, NULL) != SIASUCCESS) return (0); _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Thu Sep 14 22:27:41 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 14 Sep 2006 22:27:41 +1000 Subject: [PATCH] PermitRootLogin woes Message-ID: On Thu, Sep 14, 2006 at 02:20:03PM +0300, Antti Tapaninen wrote: > > Hi all, > > among other things, we provide shell access to various unix based > platforms for our students and university staff. Recently, there has been > increasing number of root login attacks on one particular Tru64 machine > running OpenSSH. > > The host is configured with "PermitRootLogin no" but every once in a while > SIA auth with TCB enhanced security locks the root account. > > I suppose the problem could be solved at two separate levels, for SIA only > in auth-sia.c, or for any password using auth method in auth-passwd.c. > > I'd prefer a fix just for auth-passwd.c, are there any reasons to try out > auth_krb5_password, sshpam_auth_passwd or sys_auth_passwd if variable "ok" > is set to zero already? On platforms where a failed login attempt is noticable by the time it takes, shortcutting the "ok" check leaks information about what is and is not permitted. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From aet at cc.hut.fi Fri Sep 15 02:40:54 2006 From: aet at cc.hut.fi (Antti Tapaninen) Date: Thu, 14 Sep 2006 19:40:54 +0300 (EEST) Subject: [PATCH] PermitRootLogin woes Message-ID: On Thu, 14 Sep 2006, Darren Tucker wrote: > On platforms where a failed login attempt is noticable by the time it takes, > shortcutting the "ok" check leaks information about what is and is not > permitted. I'm not following, sorry. What do you mean by noticable and leaking information about what is and is not permitted? As for noticing or monitoring failed authentications, auth_log() does a pretty good job informing about user authentications failed and where they came from. I fail to see how it's reasonable to allow anyone attack and even lock root accounts, even though PermitRootLogin sounds like a perfect solution against it. Using auth layers (pam, sia, kdc, something other not so lightweight) for nothing. Thanks, -Antti _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From rmarshall at solidodesign.com Fri Sep 15 05:24:13 2006 From: rmarshall at solidodesign.com (Ross Marshall) Date: Thu, 14 Sep 2006 13:24:13 -0600 Subject: openSSH 4.3p2 Message-ID: I have compiled the latest version to test out, installed into /opt so as not to break my old version, and have not been able to log in, I am trying to ssh into the local machine... rmarshall at Sam:/opt/bin$ ./ssh sam -v OpenSSH_4.3p2, OpenSSL 0.9.7g 11 Apr 2005 debug1: Reading configuration data /opt/etc/ssh/ssh_config debug1: Connecting to sam [127.0.0.1] port 22. debug1: Connection established. debug1: identity file /home/rmarshall/.ssh/identity type 0 debug1: identity file /home/rmarshall/.ssh/id_rsa type 1 debug1: identity file /home/rmarshall/.ssh/id_dsa type 2 ssh_exchange_identification: Connection closed by remote host My hosts.allow is: ssh: 0.0.0.0/0.0.0.0 I am allowing both protocols 1 and 2 Have generated the keys (I don't get any error messages when I start the daemon). When I do a: rmarshall at Sam:/opt/bin$ ./ssh sam -vvv OpenSSH_4.3p2, OpenSSL 0.9.7g 11 Apr 2005 debug1: Reading configuration data /opt/etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to sam [127.0.0.1] port 22. debug1: Connection established. debug1: identity file /home/rmarshall/.ssh/identity type 0 debug3: Not a RSA1 key file /home/rmarshall/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /home/rmarshall/.ssh/id_rsa type 1 debug3: Not a RSA1 key file /home/rmarshall/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /home/rmarshall/.ssh/id_dsa type 2 ssh_exchange_identification: Connection closed by remote host I have googled until I can't google no more, can anyone help? marros _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Fri Sep 15 14:27:27 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 15 Sep 2006 14:27:27 +1000 Subject: openSSH 4.3p2 Message-ID: On Thu, Sep 14, 2006 at 01:24:13PM -0600, Ross Marshall wrote: > I have compiled the latest version to test out, installed into /opt so > as not to break my old version, and have not been able to log in, I am > trying to ssh into the local machine... [...] > ssh_exchange_identification: Connection closed by remote host That's often caused by tcpwrappers... > My hosts.allow is: ssh: 0.0.0.0/0.0.0.0 tcpwrappers expects the name of the process doing the check (ie "sshd") not the protocol. If you chage the "ssh" to "sshd" it should be ok. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From jhb at freebsd.org Fri Sep 15 06:41:20 2006 From: jhb at freebsd.org (John Baldwin) Date: Thu, 14 Sep 2006 16:41:20 -0400 Subject: sshd audit not happy with ssh1 and scp Message-ID: I think I've found a bug with sshd handling audit events for commands (like scp) over ssh1 connections. Specifically, after updating to a recent FreeBSD 6.x with audit support, I'm getting log messages like these when using scp over ssh1: Sep 12 14:13:16 bm55 sshd[12335]: Accepted rsa for xxx from A.B.C.D port 2981 Sep 12 14:13:16 bm55 sshd[12335]: fatal: monitor_read: unpermitted request 57 Sep 12 14:13:16 bm55 kernel: Sep 12 14:13:16 bm55 sshd[12335]: fatal: monitor_read: unpermitted request 57 Sep 12 14:13:16 bm55 sshd[12337]: fatal: mm_request_send: write: Broken pipe Sep 12 14:13:16 bm55 kernel: Sep 12 14:13:16 bm55 sshd[12337]: fatal: mm_request_send: write: Broken pipe I tracked these down to the audit event handling for ssh1. Changing ssh1 to use MON_PERMIT instead of MON_ONCE (ssh2 uses MON_PERMIT) for REQ_AUDIT_COMMAND fixes it (well, shuts up the warnings): ==== //depot/yahoo/ybsd_6/src/crypto/openssh/monitor.c#4 (text+ko) ==== @@ -272,7 +272,7 @@ {MONITOR_REQ_TERM, 0, mm_answer_term}, #ifdef SSH_AUDIT_EVENTS {MONITOR_REQ_AUDIT_EVENT, MON_PERMIT, mm_answer_audit_event}, - {MONITOR_REQ_AUDIT_COMMAND, MON_ONCE, mm_answer_audit_command}, + {MONITOR_REQ_AUDIT_COMMAND, MON_PERMIT, mm_answer_audit_command}, #endif {0, 0, NULL} }; I notice that early on it tries to enable MONITOR_REQ_AUDIT_COMMAND in mm_answer_pwnamallow(). However, this doesn't actually work as it tries to enable it in the monitor_dispatch table (which doesn't even have a REQ_AUDIT_COMMAND in either version 1.5 or 2.0) when it needs to be enabled in the monitor_postauth table instead. So, you can either make it MON_PERMIT like above or you can fix it to not do the monitor_permit() on the passed in table, but do it on the appropriate postauth table instead. I'm using the above patch for now, but if you fix openssh I'll go with the vendor's fix once it makes it into FreeBSD of course. I don't know if the better fix is the patch above to get ssh1 in sync with ssh2 (in which case th monitor_permit() in mm_answer_pwnameallow() should probably be removed), or to fix mm_answer_pwnameallow() to perform the monitor_permit() on the correct dispatch table. -- John Baldwin _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Sat Sep 16 19:23:02 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 16 Sep 2006 19:23:02 +1000 Subject: sshd audit not happy with ssh1 and scp Message-ID: On Thu, Sep 14, 2006 at 04:41:20PM -0400, John Baldwin wrote: > I think I've found a bug with sshd handling audit events for commands (like > scp) over ssh1 connections. Specifically, after updating to a recent FreeBSD > 6.x with audit support, I'm getting log messages like these when using scp > over ssh1: > > Sep 12 14:13:16 bm55 sshd[12335]: Accepted rsa for xxx from > A.B.C.D port 2981 > Sep 12 14:13:16 bm55 sshd[12335]: fatal: monitor_read: unpermitted Thanks for the report. FreeBSD is using audit support now? Is it the debug driver, or are you using OpenBSM or something? [...] > - {MONITOR_REQ_AUDIT_COMMAND, MON_ONCE, mm_answer_audit_command}, > + {MONITOR_REQ_AUDIT_COMMAND, MON_PERMIT, mm_answer_audit_command}, Since SSH protocol 1 can only support a single command per session, the intent was to only allow the monitor call once, although it probably doesn't matter much. > I notice that early on it tries to enable MONITOR_REQ_AUDIT_COMMAND in > mm_answer_pwnamallow(). However, this doesn't actually work as it tries > to enable it in the monitor_dispatch table (which doesn't even have a > REQ_AUDIT_COMMAND in either version 1.5 or 2.0) when it needs to be enabled > in the monitor_postauth table instead. You're right. I think that should be probably be removed. Does the following patch also resolve the problem for you? Index: monitor.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/monitor.c,v retrieving revision 1.119 diff -u -p -r1.119 monitor.c --- monitor.c 1 Sep 2006 05:48:19 -0000 1.119 +++ monitor.c 16 Sep 2006 09:15:53 -0000 @@ -286,7 +286,7 @@ struct mon_table mon_dispatch_postauth15 {MONITOR_REQ_TERM, 0, mm_answer_term}, #ifdef SSH_AUDIT_EVENTS {MONITOR_REQ_AUDIT_EVENT, MON_PERMIT, mm_answer_audit_event}, - {MONITOR_REQ_AUDIT_COMMAND, MON_ONCE, mm_answer_audit_command}, + {MONITOR_REQ_AUDIT_COMMAND, MON_PERMIT|MON_ONCE, mm_answer_audit_command}, #endif {0, 0, NULL} }; @@ -660,9 +660,6 @@ mm_answer_pwnamallow(int sock, Buffer *m if (options.use_pam) monitor_permit(mon_dispatch, MONITOR_REQ_PAM_START, 1); #endif -#ifdef SSH_AUDIT_EVENTS - monitor_permit(mon_dispatch, MONITOR_REQ_AUDIT_COMMAND, 1); -#endif return (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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From jhb at freebsd.org Sat Sep 16 23:31:37 2006 From: jhb at freebsd.org (John Baldwin) Date: Sat, 16 Sep 2006 09:31:37 -0400 Subject: sshd audit not happy with ssh1 and scp Message-ID: On Saturday 16 September 2006 05:23, Darren Tucker wrote: > On Thu, Sep 14, 2006 at 04:41:20PM -0400, John Baldwin wrote: > > I think I've found a bug with sshd handling audit events for commands (like > > scp) over ssh1 connections. Specifically, after updating to a recent FreeBSD > > 6.x with audit support, I'm getting log messages like these when using scp > > over ssh1: > > > > Sep 12 14:13:16 bm55 sshd[12335]: Accepted rsa for xxx from > > A.B.C.D port 2981 > > Sep 12 14:13:16 bm55 sshd[12335]: fatal: monitor_read: unpermitted > > Thanks for the report. FreeBSD is using audit support now? Is it the > debug driver, or are you using OpenBSM or something? OpenBSM. It's now in FreeBSD 6.x and BSM_AUDIT is enabled by default. > [...] > > - {MONITOR_REQ_AUDIT_COMMAND, MON_ONCE, mm_answer_audit_command}, > > + {MONITOR_REQ_AUDIT_COMMAND, MON_PERMIT, mm_answer_audit_command}, > > Since SSH protocol 1 can only support a single command per session, the > intent was to only allow the monitor call once, although it probably > doesn't matter much. Ok. > > I notice that early on it tries to enable MONITOR_REQ_AUDIT_COMMAND in > > mm_answer_pwnamallow(). However, this doesn't actually work as it tries > > to enable it in the monitor_dispatch table (which doesn't even have a > > REQ_AUDIT_COMMAND in either version 1.5 or 2.0) when it needs to be enabled > > in the monitor_postauth table instead. > > You're right. I think that should be probably be removed. > > Does the following patch also resolve the problem for you? Yes, the patch works great. Thanks! I assume you are going to commit that to OpenSSH? DES, can you import this as a vendor fix on the vendor branch? > Index: monitor.c > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh/monitor.c,v > retrieving revision 1.119 > diff -u -p -r1.119 monitor.c > --- monitor.c 1 Sep 2006 05:48:19 -0000 1.119 > +++ monitor.c 16 Sep 2006 09:15:53 -0000 > @@ -286,7 +286,7 @@ struct mon_table mon_dispatch_postauth15 > {MONITOR_REQ_TERM, 0, mm_answer_term}, > #ifdef SSH_AUDIT_EVENTS > {MONITOR_REQ_AUDIT_EVENT, MON_PERMIT, mm_answer_audit_event}, > - {MONITOR_REQ_AUDIT_COMMAND, MON_ONCE, mm_answer_audit_command}, > + {MONITOR_REQ_AUDIT_COMMAND, MON_PERMIT|MON_ONCE, mm_answer_audit_command}, > #endif > {0, 0, NULL} > }; > @@ -660,9 +660,6 @@ mm_answer_pwnamallow(int sock, Buffer *m > if (options.use_pam) > monitor_permit(mon_dispatch, MONITOR_REQ_PAM_START, 1); > #endif > -#ifdef SSH_AUDIT_EVENTS > - monitor_permit(mon_dispatch, MONITOR_REQ_AUDIT_COMMAND, 1); > -#endif > > return (0); > } > -- John Baldwin _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From jam_man at sbcglobal.net Sun Sep 17 06:18:51 2006 From: jam_man at sbcglobal.net (James Maniotis) Date: Sat, 16 Sep 2006 15:18:51 -0500 Subject: Forcing encryption algorithms on server side Message-ID: As the man pages say, you can force an encryption algorithm from the server side by use of the "Cipher" command. How would one verify this is working? Thanks. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Sun Sep 17 10:33:56 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 17 Sep 2006 10:33:56 +1000 Subject: Forcing encryption algorithms on server side Message-ID: James Maniotis wrote: > As the man pages say, you can force an encryption algorithm from the > server side by use of the "Cipher" command. On the server side it's "Ciphers". Be aware that it applies only to Protocol 2. > How would one verify this is working? Thanks. Run the client in debug mode (eg "ssh -vv yourserver"). Amongst the output, you will see something like this: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,[...] debug2: kex_parse_kexinit: 3des-cbc,arcfour debug2: kex_parse_kexinit: 3des-cbc,arcfour The lines after the "reserved" one are the key exchange methods, signature and ciphers offered by the server. and a bit further down you will see something like this, which indicates which cipher, MAC and compression were selected: debug2: mac_init: found hmac-md5 debug1: kex: client->server arcfour hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: server->client arcfour hmac-md5 none In this example, the server offered the 3des-cbc and arcfour ciphers, and the client picked arcfour. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Sun Sep 17 12:02:07 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 17 Sep 2006 12:02:07 +1000 Subject: sshd audit not happy with ssh1 and scp Message-ID: On Sat, Sep 16, 2006 at 09:31:37AM -0400, John Baldwin wrote: > On Saturday 16 September 2006 05:23, Darren Tucker wrote: > > Thanks for the report. FreeBSD is using audit support now? Is it the > > debug driver, or are you using OpenBSM or something? > > OpenBSM. It's now in FreeBSD 6.x and BSM_AUDIT is enabled by default. Cool. Out of curiousity, did you have to modify the audit support in sshd, or did it work out of the box? > > You're right. I think that should be probably be removed. > > > > Does the following patch also resolve the problem for you? > > Yes, the patch works great. Thanks! I assume you are going to commit > that to OpenSSH? DES, can you import this as a vendor fix on the > vendor branch? Yes, it has been committed and will be in 4.4p1. Thanks again. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From jhb at freebsd.org Sun Sep 17 12:45:27 2006 From: jhb at freebsd.org (John Baldwin) Date: Sat, 16 Sep 2006 22:45:27 -0400 Subject: sshd audit not happy with ssh1 and scp Message-ID: On Saturday 16 September 2006 22:02, Darren Tucker wrote: > On Sat, Sep 16, 2006 at 09:31:37AM -0400, John Baldwin wrote: > > On Saturday 16 September 2006 05:23, Darren Tucker wrote: > > > Thanks for the report. FreeBSD is using audit support now? Is it the > > > debug driver, or are you using OpenBSM or something? > > > > OpenBSM. It's now in FreeBSD 6.x and BSM_AUDIT is enabled by default. > > Cool. Out of curiousity, did you have to modify the audit support in > sshd, or did it work out of the box? I have no idea. I just upgraded to newer FreeBSD 6.x and started getting the error messages in my logs. :) Probably a better person to ask about anything OpenBSM related in FreeBSD is rwatson at FreeBSD.org or csjp at FreeBSD.org. > > > You're right. I think that should be probably be removed. > > > > > > Does the following patch also resolve the problem for you? > > > > Yes, the patch works great. Thanks! I assume you are going to commit > > that to OpenSSH? DES, can you import this as a vendor fix on the > > vendor branch? > > Yes, it has been committed and will be in 4.4p1. > > Thanks again. Thanks for the review and fix. -- John Baldwin _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From bob at proulx.com Sun Sep 17 13:37:25 2006 From: bob at proulx.com (Bob Proulx) Date: Sat, 16 Sep 2006 21:37:25 -0600 Subject: wishlist: option to cause /bin/sh to be used instead of user's shell Message-ID: SSH, like RSH before it, invokes a command using the user's shell as specified in the passwd file. In a mixed shell environment with some logins csh-like and some sh-like that is sometimes very difficult to handle. (No, I am not fond of csh.) If I could force a single shell everywhere of course that would be preferable but sometimes I have no control over it. I have often wanted an option that would force ssh to invoke the command using /bin/sh regardless of the user's configured shell. The best that I can do right now is to pipe the commands into shell. echo echo some command | ssh example.com /bin/sh That works very well when I don't need to also use the stdin for something else. But if I do need stdin for something else then this workaround breaks down. Is there any possibility of getting an option added to ssh such that it will use a standard shell on all platforms regardless of the user's configured shell? ssh -oCommandShell=/bin/sh example.com "my command here" But maybe there is already a way to do this and I just have not been able to figure it out? This problem finally caused me enough trouble that I decided I would need to ask for help. Thanks Bob -- Bob Proulx http://www.proulx.com/~bob/ _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dkg-openssh.com at fifthhorseman.net Sun Sep 17 14:03:19 2006 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 17 Sep 2006 00:03:19 -0400 Subject: wishlist: option to cause /bin/sh to be used instead of user's shell Message-ID: On September 16, bob at proulx.com said: > I have often wanted an option that would force ssh to invoke the > command using /bin/sh regardless of the user's configured shell. The > best that I can do right now is to pipe the commands into shell. > > echo echo some command | ssh example.com /bin/sh > > That works very well when I don't need to also use the stdin for > something else. But if I do need stdin for something else then this > workaround breaks down. when i have this situation, i often use: ssh example.com "/bin/sh -c 'some command'" which i can pipe stdin to without trouble. If stdin really needs to be coming from a pseudoterminal, i use: ssh -t example.com "/bin/sh -c 'some command'" In either case, the quoting can become a little bit hairy if the command is large, but for simplish commands, it works without much trouble. I'm sure someone else can produce a more reasonable quoting style. hth, --dkg _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From des at des.no Sun Sep 17 19:13:46 2006 From: des at des.no (Dag-Erling [iso-8859-1] Smørgrav) Date: Sun, 17 Sep 2006 11:13:46 +0200 Subject: sshd audit not happy with ssh1 and scp Message-ID: Darren Tucker writes: > Cool. Out of curiousity, did you have to modify the audit support in > sshd, or did it work out of the box? It works right out of the box. DES -- Dag-Erling Sm?rgrav - des at des.no _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From hashproduct at gmail.com Mon Sep 18 01:47:49 2006 From: hashproduct at gmail.com (Matt McCutchen) Date: Sun, 17 Sep 2006 11:47:49 -0400 Subject: Proposed enhancement: forward controlling terminal Message-ID: Dear OpenSSH people, It would be nice if SSH could forward the client's controlling terminal to the remote process in addition to the client's stdin and stdout. This way, if the user wants to run a process through sudo on the remote machine while redirecting stdin and stdout locally (ssh B sudo foo out), sudo would be able to read a password from the user. Ditto if the process is invoked through two steps of SSH (ssh B ssh C foo out). Similarly, rsync over SSH would work properly with --rsync-path="sudo rsync" or --rsh="ssh B ssh". See this thread on the rsync mailing list: http://lists.samba.org/archive/rsync/2006-September/016284.html Matt _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From bob at proulx.com Mon Sep 18 03:05:07 2006 From: bob at proulx.com (Bob Proulx) Date: Sun, 17 Sep 2006 11:05:07 -0600 Subject: wishlist: option to cause /bin/sh to be used instead of user's shell Message-ID: Daniel Kahn Gillmor wrote: > when i have this situation, i often use: > ssh example.com "/bin/sh -c 'some command'" > ... > In either case, the quoting can become a little bit hairy if the > command is large, but for simplish commands, it works without much > trouble. I'm sure someone else can produce a more reasonable quoting > style. Thank you for that suggestion. And another kind person also made that suggestion offlist. That *almost* works. The problem is that if the login shell quoting rules are different than a sh-like shell's quoting rules (which are tedious enough) then you still have to know the rules for that particular shell to wrap everything in the first layer of non-standard shell quoting for that host to eventually make it into the standard shell. Primarily I am talking about /bin/tcsh versus /bin/bash and /bin/ksh in my environment. Off the top of my head thinking of csh string quoting I think I can quote everything sufficiently to make it work in both of those shells. But I find this to still be quite hard to get right in practice. In fact, I am not sure that I ever have been completely successful when used by my clever users. They are more clever than I am. Even if the shell is a standard /bin/sh everywhere the quoting rules are complex. For example using single-quotes means that you cannot ever have a single-quote in the argument list because sh-like shells do not allow a single-quote to be escaped by any method inside a single-quoted string. Therefore I prefer to use double-quotes because it is possible to escape embedded double-quotes within a double-quoted string. It is also possible to programmatically escape shell characters with things like perl/ruby modules[1]. When I don't need stdin just piping the commands to be run to the remote shell is easiest. cat <<'EOF' | ssh example.com /bin/sh export foo=bar echo $foo EOF bar My best method right now when I need stdin available is to use a temporary file. For your amusement here is an example. SERVER=example.com trap 'rm -f $TMPFILE; test -n "$RTMPFILE" && ssh -oBatchMode=yes -q -n $SERVER rm -f $RTMPFILE' EXIT TMPFILE=$(mktemp /tmp/foo.XXXXXX) || exit 1 RTMPFILE=$(ssh -oBatchMode=yes -q -n -T $SERVER mktemp /tmp/foo.XXXXXX) || exit 1 cat >$TMPFILE <<'EOF' echo "O'Hare" EOF scp -oBatchMode=yes -q $TMPFILE $SERVER:$RTMPFILE < /dev/null || exit 1 ssh -oBatchMode=yes -q $SERVER sh $RTMPFILE exit $? That works pretty well. The biggest real issue my users saw with this is that it is slower because of the multiple ssh invocations to the remote host. When I started on this problem ssh 3.8 was current and there was no ssh connection sharing available. Now that 4.2 has nice connection sharing features I might be able to make the performance with a temporary file good enough. That still requires a persistent connection however. And at this moment in time many stable distributions have yet to release again and so they still have the older ssh 3.x without connection sharing until their next release. Just the same let me suggest, wouldn't it be nice to have an option to always be able to use a standard shell on the remote system? :-) Thanks Bob [1] See perl's String::ShellQuote for one possibility. But I think this is still very tedious. An attempt at printing O'Hare's $s: perl -MString::ShellQuote -le "print shell_quote(\"O'Hare's \\\$s\");" 'O'\''Hare'\''s $s' perl -MString::ShellQuote -le 'print shell_quote("O'"'"'Hare'"'"'s \$s");' 'O'\''Hare'\''s $s' Trying to use this process to quote something for remote execution can make scripts quite hard to read. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Mon Sep 18 09:53:07 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 18 Sep 2006 09:53:07 +1000 Subject: Proposed enhancement: forward controlling terminal Message-ID: Matt McCutchen wrote: > Dear OpenSSH people, > > It would be nice if SSH could forward the client's controlling > terminal to the remote process in addition to the client's stdin and > stdout. This way, if the user wants to run a process through sudo on > the remote machine while redirecting stdin and stdout locally (ssh B > sudo foo out), sudo would be able to read a password from the > user. Ditto if the process is invoked through two steps of SSH (ssh B > ssh C foo out). Similarly, rsync over SSH would work properly > with --rsync-path="sudo rsync" or --rsh="ssh B ssh". See this thread > on the rsync mailing list: How would that be different from "ssh -t server" and "ssh -tt server" that have been in ssh(1) for a quite some time? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From hashproduct at gmail.com Mon Sep 18 10:12:19 2006 From: hashproduct at gmail.com (Matt McCutchen) Date: Sun, 17 Sep 2006 20:12:19 -0400 Subject: Proposed enhancement: forward controlling terminal Message-ID: On 9/17/06, Darren Tucker wrote: > How would that be different from "ssh -t server" and "ssh -tt server" > that have been in ssh(1) for a quite some time? I should see "foo" on my terminal when I run the following: ssh (options) localhost 'echo foo >/dev/tty' /dev/null But I get: $ ssh localhost 'echo foo >/dev/tty' /dev/null bash: /dev/tty: No such device or address $ ssh -t localhost 'echo foo >/dev/tty' /dev/null Pseudo-terminal will not be allocated because stdin is not a terminal. bash: /dev/tty: No such device or address $ ssh -tt localhost 'echo foo >/dev/tty' /dev/null tcgetattr: Inappropriate ioctl for device Connection to localhost closed. I'm using Fedora Core 5's openssh-4.3p2-4 . Matt _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From sfk1 at bigfoot.com Mon Sep 18 21:14:28 2006 From: sfk1 at bigfoot.com (Stefan Krah) Date: Mon, 18 Sep 2006 13:14:28 +0200 Subject: BSD Auth: set child environment variables requested by login script [PATCH] Message-ID: Hello, in the BSD Authentication system the login script can request environment variables to be set/unset. The call to auth_close() in auth-passwd.c does change the current environment, but those changes are lost for the child environment. It would be really useful to add some kind of mechanism to get those changes into the child environment. I've added two possible solutions. Both solutions only deal with setenv requests. Please tell me what you think and if there's a chance of adding the feature. Stefan Krah ###################################### Easy way to prepare for testing: ###################################### Index: libexec/login_passwd/login.c =================================================================== RCS file: /cvs/src/libexec/login_passwd/login.c,v retrieving revision 1.8 diff -u -r1.8 login.c --- libexec/login_passwd/login.c 14 Apr 2005 18:33:42 -0000 1.8 +++ libexec/login_passwd/login.c 18 Sep 2006 10:32:00 -0000 @@ -107,6 +107,9 @@ exit(1); } + fprintf(back, BI_SETENV " X_BSD_AUTH_SOME_RESOURCE %d\n", 1024); + fprintf(back, BI_SETENV " TESTVAR %s\n", "bar"); + /* * Read password, either as from the terminal or if the * response mode is active from the caller program. ###################################### Solution 1: ###################################### This is a minimal fix that just whitelists variables starting with X_BSD_AUTH: Index: usr.bin/ssh/auth-bsdauth.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth-bsdauth.c,v retrieving revision 1.10 diff -u -r1.10 auth-bsdauth.c --- usr.bin/ssh/auth-bsdauth.c 3 Aug 2006 03:34:41 -0000 1.10 +++ usr.bin/ssh/auth-bsdauth.c 18 Sep 2006 09:32:20 -0000 @@ -24,6 +24,7 @@ */ #include +#include #ifdef BSD_AUTH #include "xmalloc.h" @@ -32,10 +33,36 @@ #include "auth.h" #include "log.h" #include "buffer.h" +#include "channels.h" +#include "session.h" #ifdef GSSAPI #include "ssh-gss.h" #endif #include "monitor_wrap.h" + +/* + * Set child environment variables starting with "X_BSD_AUTH". + * After the call to auth_close(), these variables are in the + * current environment if the login script has requested them. + */ +void +bsdauth_child_set_env(char ***envp, u_int *envsizep) +{ + extern char **environ; + char name[8*1024]; /* MAXSPOOLSIZE in auth_session_t */ + char *value; + u_int i, namelen; + + for (i = 0; environ[i] != NULL; i++) { + namelen = strcspn(environ[i], "="); + if (namelen + 1 > sizeof(name)) + continue; + snprintf(name, namelen + 1, "%s", environ[i]); + value = environ[i] + namelen + 1; + if (strncmp(name, "X_BSD_AUTH", 10) == 0) + child_set_env(envp, envsizep, name, value); + } +} static void * bsdauth_init_ctx(Authctxt *authctxt) Index: usr.bin/ssh/auth.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth.h,v retrieving revision 1.58 diff -u -r1.58 auth.h --- usr.bin/ssh/auth.h 18 Aug 2006 09:15:20 -0000 1.58 +++ usr.bin/ssh/auth.h 18 Sep 2006 09:32:23 -0000 @@ -123,6 +123,10 @@ void krb5_cleanup_proc(Authctxt *authctxt); #endif /* KRB5 */ +#ifdef BSD_AUTH +void bsdauth_child_set_env(char ***envp, u_int *envsizep); +#endif + void do_authentication(Authctxt *); void do_authentication2(Authctxt *); Index: usr.bin/ssh/session.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/session.c,v retrieving revision 1.219 diff -u -r1.219 session.c --- usr.bin/ssh/session.c 29 Aug 2006 10:40:19 -0000 1.219 +++ usr.bin/ssh/session.c 18 Sep 2006 09:32:57 -0000 @@ -844,6 +844,9 @@ child_set_env(&env, &envsize, "KRB5CCNAME", s->authctxt->krb5_ticket_file); #endif +#ifdef BSD_AUTH + bsdauth_child_set_env(&env, &envsize); +#endif if (auth_sock_name != NULL) child_set_env(&env, &envsize, SSH_AUTHSOCKET_ENV_NAME, auth_sock_name); ###################################### Solution 2: ###################################### This one saves the current environment and lets auth_close() do the changes on an empty environment. All setenv requests are honored, unsetenv requests are lost. Index: usr.bin/ssh/auth-bsdauth.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth-bsdauth.c,v retrieving revision 1.10 diff -u -r1.10 auth-bsdauth.c --- usr.bin/ssh/auth-bsdauth.c 2006/08/03 03:34:41 1.10 +++ usr.bin/ssh/auth-bsdauth.c 2006/09/18 09:35:52 @@ -24,6 +24,7 @@ */ #include +#include #ifdef BSD_AUTH #include "xmalloc.h" @@ -32,10 +33,96 @@ #include "auth.h" #include "log.h" #include "buffer.h" +#include "channels.h" +#include "session.h" #ifdef GSSAPI #include "ssh-gss.h" #endif #include "monitor_wrap.h" + +/* copy the current environment. */ +static char ** +bsdauth_env_copy(void) +{ + extern char **environ; + char **copy, *x; + u_int i, len; + + for (i = 0; environ[i] != NULL; i++) + ; + copy = xmalloc((i + 1) * sizeof(char *)); + + for (i = 0; environ[i] != NULL; i++) { + len = strlen(environ[i]); + x = xmalloc(len + 1); + strncpy(x, environ[i], len + 1); + copy[i] = x; + } + copy[i] = NULL; + + return copy; +} + +/* free the copy. */ +void +bsdauth_env_free(Authctxt *authctxt, char **env) +{ + u_int i; + + if (env != NULL && authctxt->auth_env_mod != NULL) { + for (i = 0; env[i] != NULL; i++) + xfree(env[i]); + xfree(env); + } +} + +/* + * Wrapper around auth_close(): auth_close() changes the current environment + * as requested by the login script. To catch the setenv requests, we save + * the current environment and let auth_close() do the changes on an empty + * environment. unsetenv requests are lost. + */ +int +auth_close_do_env(Authctxt *authctxt, auth_session_t *as) +{ + extern char **environ; + char **env_orig; + int ret; + + env_orig = bsdauth_env_copy(); + environ[0] = NULL; + + ret = auth_close(as); + + /* environ now contains all setenv changes done by auth_close(). */ + authctxt->auth_env_mod = environ; + environ = env_orig; + + return ret; +} + +/* modify the child environment according to login script requests. */ +void +bsdauth_child_mod_env(Authctxt *authctxt, char ***envp, u_int *envsizep) +{ + char **env_mod; + char name[8*1024]; /* MAXSPOOLSIZE in auth_session_t */ + char *value; + u_int i, namelen; + + env_mod = authctxt->auth_env_mod; + + if (env_mod != NULL) { + for (i = 0; env_mod[i] != NULL; i++) { + namelen = strcspn(env_mod[i], "="); + if (namelen + 1 > sizeof(name)) + continue; + snprintf(name, namelen + 1, "%s", env_mod[i]); + value = env_mod[i] + namelen + 1; + child_set_env(envp, envsizep, name, value); + } + } +} static void * bsdauth_init_ctx(Authctxt *authctxt) Index: usr.bin/ssh/auth-passwd.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth-passwd.c,v retrieving revision 1.40 diff -u -r1.40 auth-passwd.c --- usr.bin/ssh/auth-passwd.c 2006/08/03 03:34:41 1.40 +++ usr.bin/ssh/auth-passwd.c 2006/09/18 09:35:52 @@ -144,7 +144,7 @@ if (as == NULL) return (0); if (auth_getstate(as) & AUTH_PWEXPIRED) { - auth_close(as); + auth_close_do_env(authctxt, as); disable_forwarding(); authctxt->force_pwchange = 1; return (1); @@ -153,7 +153,7 @@ expire_checked = 1; warn_expiry(authctxt, as); } - return (auth_close(as)); + return (auth_close_do_env(authctxt, as)); } } #else Index: usr.bin/ssh/auth.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth.h,v retrieving revision 1.58 diff -u -r1.58 auth.h --- usr.bin/ssh/auth.h 2006/08/18 09:15:20 1.58 +++ usr.bin/ssh/auth.h 2006/09/18 09:35:53 @@ -61,6 +61,7 @@ void *kbdintctxt; #ifdef BSD_AUTH auth_session_t *as; + char **auth_env_mod; /* env changes requested by login script */ #endif #ifdef KRB5 krb5_context krb5_ctx; @@ -122,6 +123,12 @@ int auth_krb5_password(Authctxt *authctxt, const char *password); void krb5_cleanup_proc(Authctxt *authctxt); #endif /* KRB5 */ + +#ifdef BSD_AUTH +int auth_close_do_env(Authctxt *authctxt, auth_session_t *as); +void bsdauth_env_free(Authctxt *authctxt, char **env); +void bsdauth_child_mod_env(Authctxt *authctxt, char ***envp, u_int *envsizep); +#endif void do_authentication(Authctxt *); void do_authentication2(Authctxt *); Index: usr.bin/ssh/session.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/session.c,v retrieving revision 1.219 diff -u -r1.219 session.c --- usr.bin/ssh/session.c 2006/08/29 10:40:19 1.219 +++ usr.bin/ssh/session.c 2006/09/18 09:35:56 @@ -844,6 +844,9 @@ child_set_env(&env, &envsize, "KRB5CCNAME", s->authctxt->krb5_ticket_file); #endif +#ifdef BSD_AUTH + bsdauth_child_mod_env(s->authctxt, &env, &envsize); +#endif if (auth_sock_name != NULL) child_set_env(&env, &envsize, SSH_AUTHSOCKET_ENV_NAME, auth_sock_name); @@ -1128,6 +1131,10 @@ * Must take new environment into use so that .ssh/rc, * /etc/ssh/sshrc and xauth are run in the proper environment. */ +#ifdef BSD_AUTH + /* environ points to xmalloc'd memory. */ + bsdauth_env_free(s->authctxt, environ); +#endif environ = env; #ifdef KRB5 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Tue Sep 19 00:14:35 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 19 Sep 2006 00:14:35 +1000 Subject: [openssh-unix-dev] Testing for the 4.4p1 release Message-ID: Hi again. David Bronder wrote: > Damien Miller wrote: >> The 4.4p1 release is approaching now, so we are now asking people to >> actively test snapshots or CVS and report back to the mailing list. > > [AIX 5.1 ML5, IBM VAC 6 compiler, openssh-SNAP-20060902] > > Fails to build. See below for details. Same result with a stripped > down configure line (just adding --with-zlib=/usr/local). [...] > I can provide full compile log, but didn't want to mail it to the list. > Here are some highlights. > > Lots of the following warnings: > > "/usr/include/usersec.h", line 625.32: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. > "/usr/include/usersec.h", line 626.34: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. > > Then for the last two files before failing: > > cc -qlanglvl=ansi -g -O3 -qstrict -I. -I. -I/local/admin/include -I/usr/local/include -DSSHDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/bin/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/bin/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/bin/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/etc/ssh\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty/sshd\" -DSSH_RAND_HELPER=\"/usr/local/bin/ssh-rand-helper\" -DHAVE_CONFIG_H -c packet.c > "/usr/include/usersec.h", line 625.32: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. > "/usr/include/usersec.h", line 626.34: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. > "packet.c", line 162.12: 1506-010 (E) Macro TAILQ_HEAD invoked with a null argument for parameter name. > cc -qlanglvl=ansi -g -O3 -qstrict -I. -I. -I/local/admin/include -I/usr/local/include -DSSHDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/bin/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/bin/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/bin/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/etc/ssh\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty/sshd\" -DSSH_RAND_HELPER=\"/usr/local/bin/ssh-rand-helper\" -DHAVE_CONFIG_H -c readpass.c > "/usr/include/usersec.h", line 625.32: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. > "/usr/include/usersec.h", line 626.34: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. I have just committed a change to configure that should work around that by removing the "-qlanglvl=ansi" if it finds the compiler won't let macros be redefined. (Not ideal, but it should work.) The changes will be in snap 20060919 and later. I think the "struct aud_rec" ones were a side effect of the compiler flags, but if you see them again (they'll only appear in port-aix.c now) then please let me know. > "/usr/include/paths.h", line 50.9: 1506-213 (S) Macro name _PATH_BSHELL cannot be redefined. > "/usr/include/paths.h", line 50.9: 1506-358 (I) "_PATH_BSHELL" is defined on line 322 of defines.h. > "/usr/include/paths.h", line 52.9: 1506-213 (S) Macro name _PATH_CSHELL cannot be redefined. > "/usr/include/paths.h", line 52.9: 1506-358 (I) "_PATH_CSHELL" is defined on line 325 of defines.h. > "/usr/include/paths.h", line 57.9: 1506-213 (S) Macro name _PATH_MAILDIR cannot be redefined. > "/usr/include/paths.h", line 57.9: 1506-358 (I) "_PATH_MAILDIR" is defined on line 359 of defines.h. Those will probably still be there but as warnings. We'll see what we can do to clean those up after the release. 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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From david-bronder at uiowa.edu Tue Sep 19 08:57:38 2006 From: david-bronder at uiowa.edu (David Bronder) Date: Mon, 18 Sep 2006 17:57:38 -0500 (CDT) Subject: Testing for the 4.4p1 release Message-ID: Darren Tucker wrote: > > David Bronder wrote: > > Damien Miller wrote: > >> The 4.4p1 release is approaching now, so we are now asking people to > >> actively test snapshots or CVS and report back to the mailing list. > > > > [AIX 5.1 ML5, IBM VAC 6 compiler, openssh-SNAP-20060902] > > > > Fails to build. See below for details. Same result with a stripped > > down configure line (just adding --with-zlib=/usr/local). > [...] > > I have just committed a change to configure that should work around that > by removing the "-qlanglvl=ansi" if it finds the compiler won't let > macros be redefined. (Not ideal, but it should work.) > > The changes will be in snap 20060919 and later. I think the "struct > aud_rec" ones were a side effect of the compiler flags, but if you see > them again (they'll only appear in port-aix.c now) then please let me know. Just gave it another spin with openssh-SNAP-20060919 and it looks OK. The "struct aud_rec" messages are gone, and the regression tests passed. > > "/usr/include/paths.h", line 50.9: 1506-213 (S) Macro name _PATH_BSHELL cannot be redefined. > > "/usr/include/paths.h", line 50.9: 1506-358 (I) "_PATH_BSHELL" is defined on line 322 of defines.h. > > "/usr/include/paths.h", line 52.9: 1506-213 (S) Macro name _PATH_CSHELL cannot be redefined. > > "/usr/include/paths.h", line 52.9: 1506-358 (I) "_PATH_CSHELL" is defined on line 325 of defines.h. > > "/usr/include/paths.h", line 57.9: 1506-213 (S) Macro name _PATH_MAILDIR cannot be redefined. > > "/usr/include/paths.h", line 57.9: 1506-358 (I) "_PATH_MAILDIR" is defined on line 359 of defines.h. > > Those will probably still be there but as warnings. We'll see what we > can do to clean those up after the release. The macro warnings were still there, but as you said, just indicating the macros had been redefined (rather than not being able to redefine them). Thanks again! -- Hello World. David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bronder at uiowa.edu _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From girish1729 at gmail.com Tue Sep 19 11:15:29 2006 From: girish1729 at gmail.com (Girish Venkatachalam) Date: Tue, 19 Sep 2006 06:45:29 +0530 Subject: weird DH problems Message-ID: Dear Damien and Darren, I recently ran into a really weird and spooky ssh problem. My brain is going to mad trying to explain that it is a hardware issue since on two machines, one of which is a Celeon 2.8 Ghz with 1 GB RAM, another is a Xeon 4 CPU box with 3 Gig RAM and I guess 3 Ghz or something, both of which are running FreeBSD 6.1 with latest version of OpenSSH bundled with it. The version string is SSH-2.0-OpenSSH_4.2p1 FreeBSD-2005090 I did a ssh -vvv to them and the problem occurs in kex. And it is absolutely random. Here is some sample output. 1) debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS Write failed: Broken pipe 2) debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent Read from socket failed: Connection reset by peer 3) debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4 debug1: SSH2_MSG_KEXINIT sent Read from socket failed: Connection reset by peer At the same time sometimes I am able to connect. I tried this from my Debian, FreeBSD and OpenBSD boxes with different SSH versions. I looked at the code and I can see certain fatal() calls in the kex code which I believe is shared bet server and client. What is causing the server to die? What is the real issue? Thanks. regards, Girish -- Whenever people agree with me I always feel I am wrong. - Oscar Wilde _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Tue Sep 19 14:21:33 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 19 Sep 2006 14:21:33 +1000 Subject: weird DH problems Message-ID: Girish Venkatachalam wrote: > Dear Damien and Darren, > > I recently ran into a really weird and spooky ssh problem. My brain > is going to mad trying to explain that it is a hardware issue since on two > machines, one of which is a Celeon 2.8 Ghz with 1 GB RAM, another is a > Xeon 4 CPU box with 3 Gig RAM and I guess 3 Ghz or something, both of > which are running FreeBSD 6.1 with latest version of OpenSSH bundled > with it. The version string is > SSH-2.0-OpenSSH_4.2p1 FreeBSD-2005090 > > I did a ssh -vvv to them and the problem occurs in kex. And it is > absolutely random. Here is some sample output. > > 1) debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > Write failed: Broken pipe It's not clear from you're describing the client(s) or server(s) above, but the server in this case doesn't happen to be an UltraSPARC does it? If so, what version of OpenSSL does it have? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Tue Sep 19 15:02:07 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 19 Sep 2006 15:02:07 +1000 Subject: weird DH problems Message-ID: Girish Venkatachalam wrote: [...] > Sorry Darren for the confusion. Both machines running FreeBSD are the > servers and the sshd on the server side is dying. I have mentioned > above the architectures, none of them are UltraSparc. > > Is there something wrong with /dev/*random? Dunno, but I suspect not. > I have tried connecting from FreeBSD itself, OpenBSD and Debian > GNU/linux asssh clients. And all of them have problems at different > times. And these clients of course are running at my home and they are > old crappy i386 boxes. I dont think there is any problem with the > client part. You really need to see what's happening on the server side (normally I'd suggest running the server in debug mode, but since it's intermittent you would probably need to bump up the LogLevel and grep out the relevant session from the log). Does the problem occur with a vanilla OpenSSH built from the source on openssh.com? I'm pretty sure FreeBSD make a number of changes but I don't know what they are. They should be the first point of call for problems with the binaries they supply. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From girish1729 at gmail.com Tue Sep 19 14:47:47 2006 From: girish1729 at gmail.com (Girish Venkatachalam) Date: Tue, 19 Sep 2006 10:17:47 +0530 Subject: weird DH problems Message-ID: On Tue, Sep 19, 2006 at 02:21:33PM +1000, Darren Tucker wrote: |Girish Venkatachalam wrote: |>Dear Damien and Darren, |> |>I recently ran into a really weird and spooky ssh problem. My brain |>is going to mad trying to explain that it is a hardware issue since on two |>machines, one of which is a Celeon 2.8 Ghz with 1 GB RAM, another is a |>Xeon 4 CPU box with 3 Gig RAM and I guess 3 Ghz or something, both of |>which are running FreeBSD 6.1 with latest version of OpenSSH bundled |>with it. The version string is |>SSH-2.0-OpenSSH_4.2p1 FreeBSD-2005090 |> |>I did a ssh -vvv to them and the problem occurs in kex. And it is |>absolutely random. Here is some sample output. |> |>1) debug1: SSH2_MSG_NEWKEYS sent |>debug1: expecting SSH2_MSG_NEWKEYS |>Write failed: Broken pipe | |It's not clear from you're describing the client(s) or server(s) above, |but the server in this case doesn't happen to be an UltraSPARC does it? | If so, what version of OpenSSL does it have? | Sorry Darren for the confusion. Both machines running FreeBSD are the servers and the sshd on the server side is dying. I have mentioned above the architectures, none of them are UltraSparc. Is there something wrong with /dev/*random? I have tried connecting from FreeBSD itself, OpenBSD and Debian GNU/linux asssh clients. And all of them have problems at different times. And these clients of course are running at my home and they are old crappy i386 boxes. I dont think there is any problem with the client part. I would have loved u to actually take a look at it urself but the machines do not actually belong to me and that is the reason I am not able to make them available to you. However if you insist I can give you the IPs and you can try connecting. What could be the problem? Any clues? Please tell me if this is fixable at all. I wonder what more I can do. :-) Oh OpenSSL was my first suspicion. ldd /usr/bin/ssh /usr/bin/ssh: libcrypto.so.4 => /lib/libcrypto.so.4 (0x280a7000) libutil.so.5 => /lib/libutil.so.5 (0x28199000) libz.so.3 => /lib/libz.so.3 (0x281a5000) libcrypt.so.3 => /lib/libcrypt.so.3 (0x281b5000) libc.so.6 => /lib/libc.so.6 (0x281cd000) I assure you my fullest cooperation in clearing this up. regards, Girish _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From girish1729 at gmail.com Tue Sep 19 15:57:58 2006 From: girish1729 at gmail.com (Girish Venkatachalam) Date: Tue, 19 Sep 2006 11:27:58 +0530 Subject: weird DH problems Message-ID: On Tue, Sep 19, 2006 at 03:02:07PM +1000, Darren Tucker wrote: |Girish Venkatachalam wrote: |[...] |>Sorry Darren for the confusion. Both machines running FreeBSD are the |>servers and the sshd on the server side is dying. I have mentioned |>above the architectures, none of them are UltraSparc. |> |> Is there something wrong with /dev/*random? | |Dunno, but I suspect not. | |> I have tried connecting from FreeBSD itself, OpenBSD and Debian |> GNU/linux asssh clients. And all of them have problems at different |> times. And these clients of course are running at my home and they are |> old crappy i386 boxes. I dont think there is any problem with the |> client part. | |You really need to see what's happening on the server side (normally I'd |suggest running the server in debug mode, but since it's intermittent |you would probably need to bump up the LogLevel and grep out the |relevant session from the log). | |Does the problem occur with a vanilla OpenSSH built from the source on |openssh.com? I'm pretty sure FreeBSD make a number of changes but I |don't know what they are. They should be the first point of call for |problems with the binaries they supply. In that case let us just move on. I could not run sshd in debug mode since I tried something and ended up killing it and getting myself locked out. Since it is not my machine I am also scared to just hack things. You are right in the stance that FreeBSD owes an explanation. But I wouldnt think they would diddle around with DH fields and stuff. Remote chance. I have not tried with vanilla OpenSSH. If nothing comes to your mind, then let us just leave it and move on. This will be one of those unsolved Sherlock Holmes mysteries. :-) regards, Girish -- Whenever people agree with me I always feel I am wrong. - Oscar Wilde _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From Dan.Goldburt at dowjones.com Sat Sep 9 02:16:42 2006 From: Dan.Goldburt at dowjones.com (Goldburt, Dan) Date: Fri, 8 Sep 2006 12:16:42 -0400 Subject: Multiple (multiplexed) simultaneous ssh connections - Cygwin bug? Message-ID: <57E557D9D8FCEB4DB0B8DB430C6DBD08069040F7@SBKE2KMB03.win.dowjones.net> >debug1: server_input_channel_req: channel 7 request exec reply 0 >debug1: session_by_channel: session 7 channel 7 >debug1: session_input_channel_req: session 7 req exec >debug2: fd 29 setting O_NONBLOCK >debug2: fd 27 setting O_NONBLOCK >fcntl(31, F_GETFL, 0): Bad file descriptor >select: Bad file descriptor Hi, Ok so I think I tracked this down a bit more. What gave it away was that it had trouble opening fd number 31. I mentioned that I increased MAX_SESSIONS in session.c (line 107). Before I did this, sshd was only getting up to fd 30 (10 sessions * 3 fd per session - stdin, stdout, stderr). So I'm wondering if there is another dependant variable that I need to change? Perhaps somewhere where memory is allocated for the fd? Thanks, Dan From dtucker at zip.com.au Sat Sep 9 02:20:02 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 09 Sep 2006 02:20:02 +1000 Subject: Multiple (multiplexed) simultaneous ssh connections - Cygwin bug? In-Reply-To: <57E557D9D8FCEB4DB0B8DB430C6DBD08069040F4@SBKE2KMB03.win.dowjones.net> References: <57E557D9D8FCEB4DB0B8DB430C6DBD08069040F4@SBKE2KMB03.win.dowjones.net> Message-ID: <45019832.9070201@zip.com.au> Goldburt, Dan wrote: > Hello, > > I need to make many (>50) ssh connections from linux to cygwin at the > same time. Using Windows 2000 Server (OpenSSH_4.3p2, OpenSSL 0.9.8b > and updated cygwin) and Linux RHEL4 (OpenSSH_3.9p1, OpenSSL 0.9.7a). It's not pretty but you could run multiple sshd's on several ports. > It's been difficult to optimize many simultaneous connections. Here > were some issues: > 1. On Windows XP/Professional, Microsoft > intentionally cripples the TCP/IP stack. Official word > (http://support.microsoft.com/kb/Q127144) is that the backlog queue > limit on a listen socket is 5 (200 when Server), so you can't > accept() more than 5 new connections concurrently. > 2. Using a master connection that is shared, the sshd_config variable > MaxStartups has no effect. This is because we are not opening lots > of ssh connections, but are opening multiple sessions within a single > connection. The parameter that needs to be changed is MAX_SESSIONS, > which is hardcoded in sessions.c at 10. Request: add "MAX_SESSIONS" > as a configuration parameter in sshd_config. Maybe. It's certainly too late for the upcoming release, though. > (also, you should > mention in INSTALL documentation that by default, compiled binaries > are quite a bit larger than usual. Do you use strip -strip-debug? We use whatever "install -s" uses on your platform. If you're using the bundled install-sh script then it just calls "strip". > Finally, I'm able to make many connections most of the time. But > then, sshd errors: > > fcntl(223, F_GETFL, 0): Bad file descriptor and sometimes: [sig] bash > 3720 _cygtls::handle_threadlist_exception and then loops spitting out > "select: Bad file descriptor" and taking up 100% CPU. I have not done > a stack trace or increased sshd debug output because the error comes > up when about 100 connections are made, so it would be difficult to > track down. If this isn't enough information to go on, I will post > it. Now this I'm not sure about. You'll have the stdout and stderr descriptors in the select's readset, which for FD_SETSIZE=64 puts the limit at around 30 connections or so (assuming you're not port forwarding or something too). What did you bump MAX_SESSIONS to? It might be overrunning the fd_set. To make this work, you would probably need to break the select into FD_SETSIZE chunks somehow. > Is this because on Cygwin, the "fd_set" arrays, used with select(), > can contain file descriptors (FD) from 0 to 63 (the fd_set array is > 8-byte long). On Linux, this is 0 to 1023? From: > http://www.ipflow.utc.fr/blog/?p=34 and > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=105321853321894&w=3 > I also found a post > http://www.cygwin.com/ml/cygwin/2005-06/msg00511.html where Corinna > said "Using a master/slave connection requires the ability to > exchange file descriptors over AF_UNIX sockets. That's not possible > in Cygwin." I assume this has been addressed with USE_PIPES, since I > AM able to use multiplexed connections most of the time? That refers to the multiplexing (ControlMaster/ControlPath) functionality in the client, not the server side. > Lastly, if security is not the biggest concern, should I even use > ssh? I just need to be able to execute many remote shell commands in > a short interval and return the output. That's a local policy decision, but you're probably not going to get an unbiased opinion on this list :-) -- 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 Sep 9 02:30:00 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 09 Sep 2006 02:30:00 +1000 Subject: Multiple (multiplexed) simultaneous ssh connections - Cygwin bug? In-Reply-To: <45019832.9070201@zip.com.au> References: <57E557D9D8FCEB4DB0B8DB430C6DBD08069040F4@SBKE2KMB03.win.dowjones.net> <45019832.9070201@zip.com.au> Message-ID: <45019A88.7090009@zip.com.au> Darren Tucker wrote: > You'll have the stdout and stderr descriptors in the select's readset, > which for FD_SETSIZE=64 puts the limit at around 30 connections or so > (assuming you're not port forwarding or something too). What did you > bump MAX_SESSIONS to? It might be overrunning the fd_set. Thinking about it, that's wrong (I was thinking of poll). Since select uses bitmasks it doesn't matter how many are in each of the readset and writeset so the limit would be around 20 concurrent. -- 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 Dan.Goldburt at dowjones.com Sat Sep 9 02:42:46 2006 From: Dan.Goldburt at dowjones.com (Goldburt, Dan) Date: Fri, 8 Sep 2006 12:42:46 -0400 Subject: Multiple (multiplexed) simultaneous ssh connections - Cygwin bug? Message-ID: <57E557D9D8FCEB4DB0B8DB430C6DBD08068583D4@SBKE2KMB03.win.dowjones.net> Tucker, Darren wrote: > > You'll have the stdout and stderr descriptors in the > select's readset, > which for FD_SETSIZE=64 puts the limit at around 30 > connections or so > (assuming you're not port forwarding or something too). > What did you > bump MAX_SESSIONS to? It might be overrunning the fd_set. I set MAX_SESSIONS to 128. I think I'm definitely overrunning the fd_set. Running the test again with a just started sshd instance, I get the error fcntl(31, F_GETFL, 0). So the limit seems to be 30 fds, or 10 connections (3 fd per connection). Where is FD_SETSIZE set in cygwin? Any chance this can be bumped up? > > To make this work, you would probably need to break the > select into > FD_SETSIZE chunks somehow. > I'm in over my head! How do I do that? Is this something that can be changed in the sshd code? As far as I can tell, sshd calls fcntl(fd, F_GETFL, 0), not select() directly. To be honest I have little idea as to how file descriptors work, and what the fd_set that I am over-running is. I'm going to do some research. From djm at mindrot.org Sat Sep 9 09:43:05 2006 From: djm at mindrot.org (Damien Miller) Date: Sat, 9 Sep 2006 09:43:05 +1000 (EST) Subject: Multiple (multiplexed) simultaneous ssh connections - Cygwin bug? In-Reply-To: <57E557D9D8FCEB4DB0B8DB430C6DBD08068583D4@SBKE2KMB03.win.dowjones.net> References: <57E557D9D8FCEB4DB0B8DB430C6DBD08068583D4@SBKE2KMB03.win.dowjones.net> Message-ID: On Fri, 8 Sep 2006, Goldburt, Dan wrote: > I set MAX_SESSIONS to 128. > I think I'm definitely overrunning the fd_set. Running the test again > with a just started sshd instance, I get the error fcntl(31, F_GETFL, > 0). So the limit seems to be 30 fds, or 10 connections (3 fd per > connection). > > Where is FD_SETSIZE set in cygwin? Any chance this can be bumped up? OpenSSH dynamically allocates its fd_sets, so using more file descriptors than can be represented in a single fd_set is OK as long as the platform's select() implementation supports it. You might be running into a Cygwin limitation. -d From nivv at cs.bgu.ac.il Sat Sep 9 18:36:41 2006 From: nivv at cs.bgu.ac.il (Niv) Date: Sat, 09 Sep 2006 11:36:41 +0300 Subject: cygwin ssh goes heavy cpu uasage Message-ID: <45027D19.8060008@cs.bgu.ac.il> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I noticed that if I install cygwin ssh on a laptop , the cpu usage goes to 80-90% when not all the network adaptors are connected. how may I assist in reporting this bug better? can some one pls point me to a version compilied with the debug flag? how can I use gdb on windows to report this? Niv -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFAn0ZkwazfG0MmCYRAvWEAJ0ZCooIMCdagD7rhmEV7bFbM4pcpQCgswOO DMGUcy2ZKxkZ449nwCQv6hY= =zR+R -----END PGP SIGNATURE----- From pwasik at optonline.net Sun Sep 10 00:21:28 2006 From: pwasik at optonline.net (pwasik at optonline.net) Date: Sat, 09 Sep 2006 14:21:28 +0000 (GMT) Subject: Make Install Failed for 4.4p1 on FC4 Message-ID: Hi, I tried to build the CVS snapshot for OpenSSH 4.4p1 dated 9/08/06. Make install failed on Fedora Core 4 system with the following errors: [root at fedora4 openssh]# make install \if test ! -z ""; then \ /usr/bin/perl ./fixprogs ssh_prng_cmds ; \ fi (cd openbsd-compat && make) make[1]: Entering directory `/usr/local/openssh/openbsd-compat' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/local/openssh/openbsd-compat' (cd scard && make DESTDIR= install) make[1]: Entering directory `/usr/local/openssh/scard' make[1]: *** No rule to make target `Ssh.bin', needed by `install'. Stop. make[1]: Leaving directory `/usr/local/openssh/scard' make: *** [scard-install] Error 2 My platform is Fedora Core 4 with latest updates I used the gcc-4.0.2-8.fc4 compiler My configure options were --with-pam and --with-selinux Regards, Paul From gzjimfan at gmail.com Sun Sep 10 11:35:48 2006 From: gzjimfan at gmail.com (Jim Fan) Date: Sat, 9 Sep 2006 18:35:48 -0700 Subject: Corrupted MAC problem on PSOS platform Message-ID: <9a78cfe90609091835n5e37dc56xfe7578aa2a9ae03b@mail.gmail.com> Hi Group, I am porting openSSH to an embedded platform running pSOS. I am able to setup a connection with the server but after I disconnect and reconnect, I always get the following error message and client won't establish connection with the server. debug: Enabling compatibility mode for protocol 2.0 debug: SSH2_MSG_KEXINIT sent debug: kex: client->server aes256-cbc hmac-sha1 none debug: kex: server->client aes256-cbc hmac-sha1 none debug: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received debug: SSH2_MSG_KEX_DH_GEX_GROUP sent debug: expecting SSH2_MSG_KEX_DH_GEX_INIT debug: SSH2_MSG_KEX_DH_GEX_REPLY sent debug: kex_derive_keys........................ debug: newkeys[1]=0xfd4868 debug: SSH2_MSG_NEWKEYS sent debug: expecting SSH2_MSG_NEWKEYS debug: newkeys[0]=0xfd4748 debug: SSH2_MSG_NEWKEYS received debug: userauth-request for user terter service ssh-connection method none debug: attempt 0 failures 0 debug: userauth-request for user terter service ssh-connection method keyboard-interactive debug: attempt 1 failures 1 debug: keyboard-interactive devs debug: auth2_challenge: user=terter devs= debug: kbdint_alloc: devices '' debug: userauth-request for user terter service ssh-connection method password debug: attempt 2 failures 2 Accepted password for terter from 172.23.1.174 port 1331 ssh2 Accepted password for terter from 172.23.1.174 port 1331 ssh2 debug: Entering interactive session for SSH2. debug: server_init_dispatch_20 debug: server_input_channel_open: ctype session rchan 256 win 16384 max 16384 debug: input_session_request debug: channel 0: new [server-session] debug: session_new: init debug: session_new: session 0 debug: session_open: channel 0 debug: session_open: session 0: link with channel 0 debug: server_input_channel_open: confirm session debug: server_input_channel_req: channel 0 request pty-req reply 1 debug: session_by_channel: session 0 channel 0 debug: session_input_channel_req: session 0 req pty-req debug: Allocating pty. debug: session_pty_req: session 0 alloc debug: server_input_channel_req: channel 0 request shell reply 1 debug: session_by_channel: session 0 channel 0 debug: session_input_channel_req: session 0 req shell Secure shell client connected Secure shell client disconnected debug: channel 0: free: server-session, nchannels 1 debug: session_close: session 0 pid 0 000110.999|SSHD |3|01|Closing connection to 172.23.1.174 debug: Enabling compatibility mode for protocol 2.0 debug: SSH2_MSG_KEXINIT sent debug: kex: client->server aes256-cbc hmac-sha1 none debug: kex: server->client aes256-cbc hmac-sha1 none debug: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received debug: SSH2_MSG_KEX_DH_GEX_GROUP sent debug: expecting SSH2_MSG_KEX_DH_GEX_INIT debug: SSH2_MSG_KEX_DH_GEX_REPLY sent debug: kex_derive_keys........................ debug: newkeys[1]=0x1024898 debug: SSH2_MSG_NEWKEYS sent debug: expecting SSH2_MSG_NEWKEYS debug: newkeys[0]=0x1024778 debug: SSH2_MSG_NEWKEYS received macbuf------------------------------20 5d38305c8b399a79c644d9e021be0d2247d1124 input------------------------------- 3b50 7e58 d759 5dfc dbe5 6c3f 46df 7297 a0cf d748 Disconnecting: Corrupted MAC on input. Disconnecting: Corrupted MAC on input. I checked key exchanges in both connections and they all looked ok. Any ideas why MAC check would fail on second connection attempt? Best Regards, Jim From dtucker at zip.com.au Sun Sep 10 13:05:01 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 10 Sep 2006 13:05:01 +1000 Subject: Make Install Failed for 4.4p1 on FC4 In-Reply-To: References: Message-ID: <450380DD.5050005@zip.com.au> pwasik at optonline.net wrote: > I tried to build the CVS snapshot for OpenSSH 4.4p1 dated 9/08/06. Make install failed on Fedora Core 4 system with the following errors: [...] > make[1]: *** No rule to make target `Ssh.bin', needed by `install'. Stop. > make[1]: Leaving directory `/usr/local/openssh/scard' > make: *** [scard-install] Error 2 Try: $ cd scard && make -f Makefile.in distprep > My platform is Fedora Core 4 with latest updates You will need uudecode installed, which is probably in the "sharutils" rpm. -- 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 Sun Sep 10 13:15:53 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 10 Sep 2006 13:15:53 +1000 Subject: cygwin ssh goes heavy cpu uasage In-Reply-To: <45027D19.8060008@cs.bgu.ac.il> References: <45027D19.8060008@cs.bgu.ac.il> Message-ID: <45038369.7050901@zip.com.au> Niv wrote: > I noticed that if I install cygwin ssh on a laptop , the cpu usage goes > to 80-90% when not all the network adaptors are connected. Which process is using the CPU, ssh or sshd? If it's sshd, does setting ListenAddress in sshd_config to listen only on the address that's live and restarting sshd make any difference? > how may I assist in reporting this bug better? can some one pls point me > to a version compilied with the debug flag? how can I use gdb on windows > to report this? gdb is probably not going to help much here, instead trace attaching strace to the process: run "ps -eaf" and pick out the pid of the process, then run "strace -p [pid]" on that particular process (be aware that it will probably generate a lot of output). -- 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 Sun Sep 10 14:42:54 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 10 Sep 2006 14:42:54 +1000 Subject: Corrupted MAC problem on PSOS platform In-Reply-To: <9a78cfe90609091835n5e37dc56xfe7578aa2a9ae03b@mail.gmail.com> References: <9a78cfe90609091835n5e37dc56xfe7578aa2a9ae03b@mail.gmail.com> Message-ID: <450397CE.2020909@zip.com.au> Jim Fan wrote: > Hi Group, > I am porting openSSH to an embedded platform running pSOS. I am able > to setup a connection with the server but after I disconnect and > reconnect, I always get the following error message and client won't > establish connection with the server. [...] > Disconnecting: Corrupted MAC on input. > Disconnecting: Corrupted MAC on input. What's on the network between client and server? Some network devices (eg certain firmware revs of Linksys routers) have been reported to cause this. The possible causes we know about are documented here: http://bugzilla.mindrot.org/show_bug.cgi?id=510 http://bugzilla.mindrot.org/show_bug.cgi?id=845 Failing that, I would try compiling everything (zlib, openssl and openssh) without any optimization and seeing if that makes a difference. > I checked key exchanges in both connections and they all looked ok. > Any ideas why MAC check would fail on second connection attempt? Maybe the different DH parameters negotiated in the DH GEX has some effect? Try removing the moduli file on the server and it will fall back to group1 or group14. -- 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 Sun Sep 10 15:12:17 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 10 Sep 2006 15:12:17 +1000 Subject: Testing for the 4.4p1 release In-Reply-To: References: Message-ID: <20060910051217.GA3812@gate.dtucker.net> On Thu, Aug 31, 2006 at 08:50:04AM +0300, Pekka Savola wrote: > On Wed, 30 Aug 2006, Damien Miller wrote: > > Running the regression tests supplied with Portable does not require > > installation, just run: > > > > $ ./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, including > > details of your platform, compiler and configure options. Thanks for testing and sorry it took so long to get back to you. > On RHL73 with gcc 2.96, 'make tests' doesn't finish and appears to get > stuck (strace shows the process is in wait()). There were a number of > compilation warnings. The ones coming from ciphers and macs appear to > be old, but these are new and at least implicit decls should be easily > fixable: > > warning: __nonnull__' attribute directive ignored (50+ times) We could do something like the patch below. > uidswap.c: In function Permanently_drop_suid': > uidswap.c:142: warning: implicit declaration of function Setresuid' > uidswap.c: In function Permanently_set_uid': > uidswap.c:224: warning: implicit declaration of function Setresgid' Last time I looked, setresuid and setresgid were not defined in any system header on old Linuxes. > md5crypt.c: In function To64': > md5crypt.c:31: warning: implicit declaration of function Memset' > md5crypt.c: In function s_md5_salt': > md5crypt.c:43: warning: implicit declaration of function Strncmp' > md5crypt.c:43: warning: implicit declaration of function Strlen' > md5crypt.c: In function Md5_crypt': > md5crypt.c:73: warning: implicit declaration of function Memcpy' These have been fixed by including string.h. [...] > from 127.0.0.1 port 44319 (t4 r26 i0/0 o0/0 fd 27/27 cfd -1) > [[ almost 10 minute timeout ]] > ssh_exchange_identification: Connection closed by remote host > cmp: EOF on /home/pekkas/op/openssh/regress/ls.copy > corrupted copy of /bin/ls > bind: Address already in use > [[ about 5 minute timeout ]] Now this I'm not sure about. Index: defines.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/defines.h,v retrieving revision 1.137 diff -u -p -r1.137 defines.h --- defines.h 18 Aug 2006 22:38:24 -0000 1.137 +++ defines.h 10 Sep 2006 05:04:31 -0000 @@ -449,6 +449,10 @@ struct winsize { # define __bounded__(x, y, z) #endif +#ifndef __nonnull__ +# define __nonnull__ +#endif + /* *-*-nto-qnx doesn't define this macro in the system headers */ #ifdef MISSING_HOWMANY # define howmany(x,y) (((x)+((y)-1))/(y)) -- 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 serzan at hellug.gr Mon Sep 11 07:26:00 2006 From: serzan at hellug.gr (Serafeim Zanikolas) Date: Sun, 10 Sep 2006 22:26:00 +0100 Subject: non-informative error message Message-ID: <200609102226.03026.serzan@hellug.gr> Hello, The openssh client terminates with the following error message when unable to resolve a username: "You don't exist, go away!" Leaving aside style and tone, the message is not informative. Please consider changing it to something more appropriate and helpful, such as "Unable to resolve username". (The message appears in the files ssh-keygen.c and ssh.c, as of version openssh-4.2p1) Thanks, Serafeim ps. please CC me as I'm not subscribed From bob at proulx.com Mon Sep 11 09:53:38 2006 From: bob at proulx.com (Bob Proulx) Date: Sun, 10 Sep 2006 17:53:38 -0600 Subject: non-informative error message In-Reply-To: <200609102226.03026.serzan@hellug.gr> References: <200609102226.03026.serzan@hellug.gr> Message-ID: <20060910235338.GA20133@dementia.proulx.com> Serafeim Zanikolas wrote: > ps. please CC me as I'm not subscribed > The openssh client terminates with the following error message when > unable to resolve a username: "You don't exist, go away!" A traditional styled message. Try 'who' in that same "impossible" situation. It will print out "Intruder Alert!". Did you actually receive this error message? What was the circumstance? How likely is this error to occur? > Leaving aside style and tone, the message is not informative. Please > consider changing it to something more appropriate and helpful, such > as "Unable to resolve username". The message is in the traditional style of a message in an "impossible" situation. Obviously it is possible but it shouldn't be. It can only happen if a previous system error has occurred. How can a user exist on a system when the user is not defined for the system? (Yes, obviously there are ways, that is not my point.) I am not an ssh developer but as a system user these things are part of the culture and often make the system more enjoyable to live and work on than if it were only dry messages, even if perhaps more accurate. I would not be opposed to adding additional error text, but I would hate to see the culture become too bland, like food designed to offend no one, which then often pleases no one either. Bob From vsync at quadium.net Mon Sep 11 10:39:56 2006 From: vsync at quadium.net (Tim Howe) Date: Sun, 10 Sep 2006 18:39:56 -0600 Subject: non-informative error message In-Reply-To: <200609102226.03026.serzan@hellug.gr> (Serafeim Zanikolas's message of "Sun, 10 Sep 2006 22:26:00 +0100") References: <200609102226.03026.serzan@hellug.gr> Message-ID: <87bqpnjkwz.fsf@piro.quadium.net> Serafeim Zanikolas writes: > The openssh client terminates with the following error message when unable to > resolve a username: "You don't exist, go away!" > > Leaving aside style and tone, the message is not informative. Please consider > changing it to something more appropriate and helpful, such as "Unable to > resolve username". I request that this message stay the same and that users consider gaining a sense of humor and a cultural understanding of the systems in use. -- vsync http://quadium.net/ If addiction is judged by how long a dumb animal will sit pressing a lever to get a "fix" of something, to its own detriment, then I would conclude that netnews is far more addictive than cocaine. -- Rob Stampfli From pekkas at netcore.fi Mon Sep 11 16:16:24 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 11 Sep 2006 09:16:24 +0300 (EEST) Subject: Testing for the 4.4p1 release In-Reply-To: <20060910051217.GA3812@gate.dtucker.net> References: <20060910051217.GA3812@gate.dtucker.net> Message-ID: On Sun, 10 Sep 2006, Darren Tucker wrote: >> On RHL73 with gcc 2.96, 'make tests' doesn't finish and appears to get >> stuck (strace shows the process is in wait()). There were a number of >> compilation warnings. The ones coming from ciphers and macs appear to >> be old, but these are new and at least implicit decls should be easily >> fixable: >> >> warning: __nonnull__' attribute directive ignored (50+ times) > > We could do something like the patch below. I retried with the latest snapshot and the patch. The patch doesn't work, it results in a a compilation error: In file included from bsd-misc.c:31: ../xmalloc.h:26: parse error before (' >> uidswap.c: In function Permanently_drop_suid': >> uidswap.c:142: warning: implicit declaration of function Setresuid' >> uidswap.c: In function Permanently_set_uid': >> uidswap.c:224: warning: implicit declaration of function Setresgid' > > Last time I looked, setresuid and setresgid were not defined in any system > header on old Linuxes. True, I don't see them myself either.. > These have been fixed by including string.h. cipher-aes.c also seems to need it, or some other relevant .h include, as it complains about memcpy and memset. > [...] >> from 127.0.0.1 port 44319 (t4 r26 i0/0 o0/0 fd 27/27 cfd -1) >> [[ almost 10 minute timeout ]] >> ssh_exchange_identification: Connection closed by remote host >> cmp: EOF on /home/pekkas/op/openssh/regress/ls.copy >> corrupted copy of /bin/ls >> bind: Address already in use >> [[ about 5 minute timeout ]] > > Now this I'm not sure about. This is still the same. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From ken at hero.com Mon Sep 11 16:34:54 2006 From: ken at hero.com (Kenneth Berland) Date: Sun, 10 Sep 2006 23:34:54 -0700 (PDT) Subject: openssh-4.3p2: setsockopt() problem Message-ID: List, I'm behind a dlink DSL-G604T wireless router. ssh client was hanging at: debug1: Entering interactive session. Telnet was having a similar problem to port 22, however a simple client.c I compiled was not. My java ssh client was also working. After some investigation, I noticed that the hang was after the system call: setsockopt(3, SOL_IP, IP_TOS, [16], 4) = 0 I noticed also that telnet was hanging the same way. I commented all the setsockopt() calls out of the ssh client code (because I was in a hurry) and now it works. Anyway, I figured I should document the problem somewhere. -Ken From serzan at hellug.gr Mon Sep 11 20:26:57 2006 From: serzan at hellug.gr (Serafeim Zanikolas) Date: Mon, 11 Sep 2006 11:26:57 +0100 Subject: non-informative error message In-Reply-To: <87bqpnjkwz.fsf@piro.quadium.net> References: <200609102226.03026.serzan@hellug.gr> <87bqpnjkwz.fsf@piro.quadium.net> Message-ID: <200609111126.57578.serzan@hellug.gr> On Monday 11 September 2006 01:39, Tim wrote: > I request that this message stay the same and that users consider > gaining a sense of humor and a cultural understanding of the systems in > use. OK, it did give me a good laugh the first couple of times, but after a while it just gets annoying. Perhaps you could consider changing the message to something witty _and_ informative (eg, bash under the same circumstances says "I have no name!"). But then again, I'd rather not be though of as an exterminator of your cultural heritage :) (For the history, the error arises because I'm authenticated by a NIS server behind a faulty-soon-to-be-replaced switch that causes occasional timeouts) Cheers, Serafeim From dtucker at zip.com.au Mon Sep 11 20:59:05 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 11 Sep 2006 20:59:05 +1000 Subject: Testing for the 4.4p1 release In-Reply-To: References: <20060910051217.GA3812@gate.dtucker.net> Message-ID: <20060911105905.GA13469@gate.dtucker.net> On Mon, Sep 11, 2006 at 09:16:24AM +0300, Pekka Savola wrote: > On Sun, 10 Sep 2006, Darren Tucker wrote: > >> On RHL73 with gcc 2.96, 'make tests' doesn't finish and appears to get > >> stuck (strace shows the process is in wait()). There were a number of > >> compilation warnings. The ones coming from ciphers and macs appear to > >> be old, but these are new and at least implicit decls should be easily > >> fixable: > >> > >> warning: __nonnull__' attribute directive ignored (50+ times) > > > > We could do something like the patch below. > > I retried with the latest snapshot and the patch. Thanks. > The patch doesn't work, it results in a a compilation error: > In file included from bsd-misc.c:31: > ../xmalloc.h:26: parse error before (' Yeah, that patch is a bad idea, so I think we'll probably leave this alone for now. I can't think of a way to reliably detect which __attribute__ 's are supported. [...] > > These have been fixed by including string.h. > > cipher-aes.c also seems to need it, or some other relevant .h include, > as it complains about memcpy and memset. Indeed it does, however it's only obvious with older OpenSSL version where that code is compiled in. Fixed, thanks. > > [...] > >> from 127.0.0.1 port 44319 (t4 r26 i0/0 o0/0 fd 27/27 cfd -1) > >> [[ almost 10 minute timeout ]] > >> ssh_exchange_identification: Connection closed by remote host > >> cmp: EOF on /home/pekkas/op/openssh/regress/ls.copy > >> corrupted copy of /bin/ls > >> bind: Address already in use > >> [[ about 5 minute timeout ]] > > > > Now this I'm not sure about. > > This is still the same. During the timeout phase, is there a defunct process in the process list, and if so what process does its ppid correspond to? -- 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 pekkas at netcore.fi Mon Sep 11 21:19:35 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 11 Sep 2006 14:19:35 +0300 (EEST) Subject: Testing for the 4.4p1 release In-Reply-To: <20060911105905.GA13469@gate.dtucker.net> References: <20060910051217.GA3812@gate.dtucker.net> <20060911105905.GA13469@gate.dtucker.net> Message-ID: On Mon, 11 Sep 2006, Darren Tucker wrote: >>> [...] >>>> from 127.0.0.1 port 44319 (t4 r26 i0/0 o0/0 fd 27/27 cfd -1) >>>> [[ almost 10 minute timeout ]] >>>> ssh_exchange_identification: Connection closed by remote host >>>> cmp: EOF on /home/pekkas/op/openssh/regress/ls.copy >>>> corrupted copy of /bin/ls >>>> bind: Address already in use >>>> [[ about 5 minute timeout ]] >>> >>> Now this I'm not sure about. >> >> This is still the same. > > During the timeout phase, is there a defunct process in the process list, > and if so what process does its ppid correspond to? During the timeout, the processes look something like this: pekkas 11767 8459 0 14:10 pts/4 00:00:00 sh /home/pekkas/o/openssh/regres pekkas 11798 1 0 14:10 ? 00:00:00 /home/pekkas/o/openssh/sshd -f / pekkas 11826 1 0 14:10 ? 00:00:00 /home/pekkas/o/openssh/ssh -1 -F pekkas 11827 11767 0 14:10 pts/4 00:00:00 /home/pekkas/o/openssh/ssh -2 -F PPID=1 looks odd, and indeed if I kill them the timeout stops, but the compilation result is the same error. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From Dan.Goldburt at dowjones.com Mon Sep 11 22:22:36 2006 From: Dan.Goldburt at dowjones.com (Goldburt, Dan) Date: Mon, 11 Sep 2006 08:22:36 -0400 Subject: Multiple (multiplexed) simultaneous ssh connections - Cygwin bug? Message-ID: <57E557D9D8FCEB4DB0B8DB430C6DBD08069040FA@SBKE2KMB03.win.dowjones.net> Hi, Ok, so I'm thinking about taking Darren's suggestion: > It's not pretty but you could run multiple sshd's on several ports. But before I do, I was hoping to get some help in optimizing the fix. 1. What does the cygwin limitation bound my max sessions to? Is it: a) 30 > You'll have the stdout and stderr descriptors in the > select's readset, > which for FD_SETSIZE=64 puts the limit at around 30 > connections or so > (assuming you're not port forwarding or something too). b) 20 > Thinking about it, that's wrong (I was thinking of poll). > Since select > uses bitmasks it doesn't matter how many are in each of > the readset and > writeset so the limit would be around 20 concurrent. or c) 10 > I think I'm definitely overrunning the fd_set. Running the > test again with a just started sshd instance, I get the > error fcntl(31, F_GETFL, 0). So the limit seems to be 30 > fds, or 10 connections (3 fd per connection). 2. I need to make sure if I do still accidentally overrun the fd_set, I will not crash sshd. Right now it goes into an infinite loop spitting out "select: Bad file descriptor" and taking up 100% CPU. Surely this is a bug that needs to be patched? 3. Any chance I can overcome the limitation from inside sshd? How do I implement the following: > To make this work, you would probably need to break the > select into FD_SETSIZE chunks somehow. From kuenne at rentec.com Tue Sep 12 00:27:40 2006 From: kuenne at rentec.com (Karsten =?iso-8859-1?q?K=FCnne?=) Date: Mon, 11 Sep 2006 10:27:40 -0400 Subject: non-informative error message In-Reply-To: <87bqpnjkwz.fsf@piro.quadium.net> References: <200609102226.03026.serzan@hellug.gr> <87bqpnjkwz.fsf@piro.quadium.net> Message-ID: <200609111027.40936.kuenne@rentec.com> On Sunday 10 September 2006 20:39, Tim Howe wrote: > Serafeim Zanikolas writes: > > The openssh client terminates with the following error message when > > unable to resolve a username: "You don't exist, go away!" > > > > Leaving aside style and tone, the message is not informative. Please > > consider changing it to something more appropriate and helpful, such as > > "Unable to resolve username". > > I request that this message stay the same and that users consider > gaining a sense of humor and a cultural understanding of the systems in > use. Full Ack! Leave it as it is! Karsten. -- People who claim they don't let little things bother them have never slept in a room with a single mosquito. From hir3npatel at gmail.com Tue Sep 12 01:28:25 2006 From: hir3npatel at gmail.com (Hiren Patel) Date: Mon, 11 Sep 2006 17:28:25 +0200 Subject: scp files with ':' in filename Message-ID: <874b9a8f0609110828p1962e7c9yfae8c145037701e8@mail.gmail.com> greetings, would it be a good idea to include within the scp man pages, how one would use scp to copy files which have the ' : ' character in the filename? a friend struggled a little trying to do this, discovered the answer on google, i thought it might be usefull to have in the man pages too. the solution was to use the files' full path so that scp recognised it as a file. please cc me on any replys as im not subcribed to the list. thanks. -- Hiren Patel Why is it that we rejoice at a birth and grieve at a funeral? It is because we are not the person involved. -- Mark Twain From gert at greenie.muc.de Tue Sep 12 06:52:08 2006 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 11 Sep 2006 22:52:08 +0200 Subject: openssh-4.3p2: setsockopt() problem In-Reply-To: References: Message-ID: <20060911205208.GQ1140@greenie.muc.de> Hi, On Sun, Sep 10, 2006 at 11:34:54PM -0700, Kenneth Berland wrote: > I'm behind a dlink DSL-G604T wireless router. ssh client was hanging at: > > debug1: Entering interactive session. This happens if you have a NAT implementation that cannot handle connections that change their ToS (Type of Service) flags "in flight". I don't have a good idea how to work around those, though (well, when I ran into this first time, I just tried using putty, which worked, because it doesn't modify the ToS bits). 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 dtucker at zip.com.au Tue Sep 12 08:21:55 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 12 Sep 2006 08:21:55 +1000 Subject: Multiple (multiplexed) simultaneous ssh connections - Cygwin bug? In-Reply-To: <57E557D9D8FCEB4DB0B8DB430C6DBD08069040FA@SBKE2KMB03.win.dowjones.net> References: <57E557D9D8FCEB4DB0B8DB430C6DBD08069040FA@SBKE2KMB03.win.dowjones.net> Message-ID: <4505E183.5060206@zip.com.au> Goldburt, Dan wrote: > Hi, > > Ok, so I'm thinking about taking Darren's suggestion: >> It's not pretty but you could run multiple sshd's on several ports. > > But before I do, I was hoping to get some help in optimizing the fix. > > 1. What does the cygwin limitation bound my max sessions to? > Is it: > a) 30 >> You'll have the stdout and stderr descriptors in the >> select's readset, >> which for FD_SETSIZE=64 puts the limit at around 30 >> connections or so >> (assuming you're not port forwarding or something too). > b) 20 >> Thinking about it, that's wrong (I was thinking of poll). >> Since select >> uses bitmasks it doesn't matter how many are in each of >> the readset and >> writeset so the limit would be around 20 concurrent. > or c) 10 >> I think I'm definitely overrunning the fd_set. Running the >> test again with a just started sshd instance, I get the >> error fcntl(31, F_GETFL, 0). So the limit seems to be 30 >> fds, or 10 connections (3 fd per connection). I'm not sure, actually. You seem to be hitting some limit at 31 descriptors before the fd_set one, which should be at 64 (3 per session = ~20 concurrent). What does "ulimit -n" report the descriptor limit as, and do you have some local processes using some of them? > 2. I need to make sure if I do still accidentally overrun the fd_set, I > will not crash sshd. Right now it goes into an infinite loop spitting > out "select: Bad file descriptor" and taking up 100% CPU. Surely this is > a bug that needs to be patched? Maybe, but it only occurs with modified code, right? > 3. Any chance I can overcome the limitation from inside sshd? How do I > implement the following: >> To make this work, you would probably need to break the >> select into FD_SETSIZE chunks somehow. I was thinking of overloading select an associated macros in the compat library but it's probably not trivial. Damien said that the fd_sets were dynamically allocated but I'm not sure how that helps in the case where there's more than FD_SETSIZE descriptors. -- 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 ark at eltex.net Tue Sep 12 21:02:26 2006 From: ark at eltex.net (ArkanoiD) Date: Tue, 12 Sep 2006 15:02:26 +0400 Subject: openssh (OpenBSD) , bsdauth and tis authsrv Message-ID: <20060912110226.GA25624@eltex.net> nuqneH, I've tried using TIS authsrv authentication via bsd auth and found it quite limited. The most important restriction it does not log ip and fqdn of the remote peer, nor the application name, to the authentication server. It does not matter much for TIS authsrv, but since other applications do provide such information, our authsrv version uses it for extra authentication restrictions. And - as tcp loopback interface is hardly considered secure - we use unix domain sockets to talk to it instead. I tried Mark Roth's patch, but it suffers from the similar problems and does not support privsep api. So i made my own, it is not very good yet (it does not take advantage of init_ctx) but i hope i will fix that soon if you people will give me good advices. -------------- next part -------------- diff -crP ssh/auth-tis.c ssh.my2/auth-tis.c *** ssh/auth-tis.c Thu Jan 1 03:00:00 1970 --- ssh.my2/auth-tis.c Tue Sep 12 14:15:57 2006 *************** *** 0 **** --- 1,598 ---- + /* + ** Copyright 2006 ArkanoiD, Pitek Software Labs + ** Based on Mark D. Roth's module, original copyrights follow + */ + /* + ** Copyright 2001-2003 University of Illinois Board of Trustees + ** Copyright 2001-2003 Mark D. Roth + ** All rights reserved. + ** + ** TIS authentication module for OpenSSH + ** + ** Mark D. Roth + ** Campus Information Technologies and Educational Services + ** University of Illinois at Urbana-Champaign + */ + + #include "includes.h" + + #include + + #include "xmalloc.h" + #include "auth.h" + #include + #include + #include + #include + #include + #include "auth-tis.h" + #include "monitor_wrap.h" + #include "log.h" + #include "servconf.h" + + static ssize_t tis_recv(struct tis_connection *, u_char *, size_t); + static ssize_t tis_send(struct tis_connection *, u_char *, size_t); + static void send_fd(struct tis_connection *, int); + static void tis_getconf(struct tis_connection *, char *); + static ssize_t tis_decode(u_char *, size_t); + static ssize_t tis_encode(u_char *, size_t, size_t); + static int tis_getkey(struct tis_connection *); + static int tis_open(struct tis_connection *, const char *, char *); + static int tis_verify(struct tis_connection *, const char *, char *); + + extern char *__progname; + extern ServerOptions options; + + static struct tis_connection tc = { -1, TIS_DEFTIMEOUT, TIS_KEY, TIS_DEFPORT, + TIS_DEFSERVER, TIS_DEFALTSERVER, NULL }; + + + void * + tis_init_ctx(Authctxt *authctxt) + { + return authctxt; + } + + int + tis_query(void *ctx, char **name, char **infotxt, + u_int* numprompts, char ***prompts, u_int **echo_on) + { + Authctxt *authctxt = ctx; + static char challenge[1024]; + char buf1[256], buf2[256]; + char *cp; + FILE *f; + + *name = xstrdup(""); + *infotxt = xstrdup(""); + *numprompts = 1; + *prompts = xmalloc(*numprompts * sizeof(char*)); + *echo_on = xmalloc(*numprompts * sizeof(u_int)); + (*echo_on)[0] = 0; + + /* fake it if no account */ + if (authctxt->pw == NULL) + { + (*prompts)[0] = "Password: "; + return 0; + } + + /* connect to the authsrv */ + if (tc.keyfile != NULL && tis_getkey(&tc) != 0) { + error("cannot read key file"); + return -1; + } + if (tc.fd == -1) + { + tis_getconf(&tc, authctxt->pw->pw_class); + if (tc.keyfile != NULL && tis_getkey(&tc) != 0) + error("cannot read encryption key"); + debug2("main server %s, alternate %s", tc.server, tc.altserver); + if (tis_open(&tc, tc.server, buf1) == -1 && (tc.altserver && + tis_open(&tc, tc.altserver, buf1) == -1)) { + error("unable to connect to authsrv: %s", + buf1); + return -1; + } + } + + /* send authsrv username */ + snprintf(buf2, sizeof(buf2), "authorize %.100s 'openssh %.128s/%.128s'", + authctxt->user,get_canonical_hostname(options.use_dns), + get_remote_ipaddr()); + debug2("TIS get_challenge: sending to authsrv: %s", buf2); + if (tis_send(&tc,buf2,strlen(buf2)) != strlen(buf2)) + { + logit("TIS authentication: tis_send() failed"); + close(tc.fd); + tc.fd = -1; + return -1; + } + + /* read challenge */ + if (tis_recv(&tc, buf1, sizeof(buf1)) <= 0) + { + logit("TIS authentication: auth_recv() failed"); + close(tc.fd); + tc.fd = -1; + return -1; + } + + debug2("TIS get_challenge: received from authsrv: %s", buf1); + if (strncmp(buf1, "challenge ", 10) == 0 || + strncmp(buf1, "chalnecho ", 10) == 0) + { + debug2("TIS authentication: authsrv challenge: %.100s", buf1 + 10); + strlcpy(challenge, buf1 + 10, sizeof(challenge)); + (*prompts)[0] = xstrdup(challenge); + return 0; + } + else if (strncmp(buf1, "password", 8) == 0) + { + logit("TIS authentication: authsrv requests user password"); + (*prompts)[0] = "Password: "; + return 0; + } + else + logit("TIS authentication: unknown authsrv user"); + + return -1; + } + + int + tis_respond(void *ctx, u_int numresponses, char **responses) + { + Authctxt *authctxt = ctx; + char buf1[256]; + + /* fail if no account */ + if (authctxt->pw == NULL || !authctxt->valid || numresponses != 1) + return -1; + + /* send response to authsrv */ + snprintf(buf1, sizeof(buf1), "response '%.100s'", responses[0]); + debug2("TIS verify_response: sending to authsrv: %s", buf1); + if (tis_send(&tc, buf1, strlen(buf1)) != strlen(buf1)) + { + logit("TIS authentication: auth_send() failed"); + close(tc.fd); + tc.fd = -1; + return -1; + } + + /* get reaction from authsrv */ + if (tis_recv(&tc, buf1, sizeof(buf1)) <= 0) + { + logit("TIS authentication: auth_recv() failed"); + close(tc.fd); + tc.fd = -1; + return -1; + } + debug2("TIS verify_response: received from authsrv: %.100s", buf1); + + /* determine outcome */ + if (strncmp(buf1, "ok", 2) == 0) + { + close(tc.fd); + tc.fd = -1; + return 0; + } + + return -1; + } + + void + tis_free_ctx(void *ctx) + { + close(tc.fd); + tc.fd = -1; + } + + KbdintDevice tis_device = { + "tis", + tis_init_ctx, + tis_query, + tis_respond, + tis_free_ctx + }; + + KbdintDevice mm_tis_device = { + "tis", + tis_init_ctx, + mm_tis_query, + mm_tis_respond, + tis_free_ctx + }; + + + /* + * Send the file descriptor in struct tis_connection over a socketpair + * to the parent process to keep the connection to authsrv open. + */ + void + send_fd(struct tis_connection *tc, int sock) + { + struct msghdr msg; + struct cmsghdr *cmp; + char cmsgbuf[CMSG_SPACE(sizeof(int))]; + + memset(&msg, 0, sizeof(msg)); + msg.msg_control = cmsgbuf; + msg.msg_controllen = CMSG_LEN(sizeof(int)); + + cmp = CMSG_FIRSTHDR(&msg); + cmp->cmsg_len = CMSG_LEN(sizeof(int)); + cmp->cmsg_level = SOL_SOCKET; + cmp->cmsg_type = SCM_RIGHTS; + + *(int *)CMSG_DATA(cmp) = tc->fd; + + if (sendmsg(sock, &msg, 0) < 0) + logit("sendmsg: %m"); + } + + /* + * Look up the given login class and populate struct tis_connection. + */ + void + tis_getconf(struct tis_connection *tc, char *class) + { + extern login_cap_t *lc; + + if ((lc = login_getclass(class)) == NULL) { + tc->port = TIS_DEFPORT; + tc->timeout = TIS_DEFTIMEOUT; + tc->server = TIS_DEFSERVER; + tc->altserver = TIS_DEFALTSERVER; + tc->keyfile = NULL; + return; + } + + tc->port = login_getcapstr(lc, "tis-port", TIS_DEFPORT, TIS_DEFPORT); + tc->timeout = login_getcapnum(lc, "tis-timeout", TIS_DEFTIMEOUT, + TIS_DEFTIMEOUT); + tc->server = login_getcapstr(lc, "tis-server", TIS_DEFSERVER, + TIS_DEFSERVER); + tc->altserver = login_getcapstr(lc, "tis-server-alt", TIS_DEFALTSERVER, TIS_DEFALTSERVER); + tc->keyfile = login_getcapstr(lc, "tis-keyfile", NULL, NULL); + } + + /* + * Read an ASCII string from a file and convert it to a DES key. + */ + int + tis_getkey(struct tis_connection *tc) + { + size_t len; + struct stat sb; + des_cblock cblock; + char *key, *tbuf = NULL; + FILE *fp; + int error; + + if ((fp = fopen(tc->keyfile, "r")) == NULL) { + logit("%s: %m", tc->keyfile); + return (-1); + } + if (fstat(fileno(fp), &sb) == -1) { + logit("%s: %m", tc->keyfile); + fclose(fp); + return (-1); + } + if (sb.st_uid != 0) { + logit("%s: not owned by root", tc->keyfile); + fclose(fp); + return (-1); + } + if (!S_ISREG(sb.st_mode)) { + logit("%s: not a regular file", tc->keyfile); + fclose(fp); + return (-1); + } + if (sb.st_mode & (S_IRWXG|S_IRWXO)) { + logit("%s: readable or writable by non-owner", + tc->keyfile); + fclose(fp); + return (-1); + } + if ((key = fgetln(fp, &len)) == NULL || (len == 1 && key[0] == '\n')) { + if (ferror(fp)) + logit("%s: %m", tc->keyfile); + else + logit("%s: empty key file", tc->keyfile); + fclose(fp); + return (-1); + } + fclose(fp); + if (key[len - 1] == '\n') + key[--len] = '\0'; + else { + if ((tbuf = malloc(len + 1)) == NULL) { + logit("%s: %m", tc->keyfile); + return (-1); + } + memcpy(tbuf, key, len); + tbuf[len] = '\0'; + key = tbuf; + } + des_string_to_key(key, &cblock); + error = des_set_key(&cblock, tc->keysched); + memset(key, 0, len); + memset(&cblock, 0, sizeof(cblock)); + if (tbuf) free(tbuf); + return (error); + } + + /* + * Open a connection to authsrv and read the welcom banner. + * Returns the file descriptor on success and -1 on error + * or unrecognized welcome banner. + */ + int + tis_open(struct tis_connection *tc, const char *server, char *ebuf) + { + char buf[TIS_BUFSIZ]; + int error; + + ebuf[0] = '\0'; + if (strncasecmp(server, "unix:", strlen("unix:"))) { + struct addrinfo hints, *res, *res0; + memset(&hints, 0, sizeof(hints)); + hints.ai_socktype = SOCK_STREAM; + hints.ai_family = PF_UNSPEC; + hints.ai_flags = 0; + debug("talking to authsrv server %s port %s",server, tc->port); + error = getaddrinfo(server, tc->port, &hints, &res0); + if (error) { + strlcpy(ebuf, gai_strerror(error), TIS_BUFSIZ); + freeaddrinfo(res0); + return (-1); + } + + /* connect to the first address that succeeds */ + for (res = res0; res != NULL; res = res->ai_next) { + tc->fd = socket(res->ai_family, res->ai_socktype, + res->ai_protocol); + if (tc->fd != -1) { + if (connect(tc->fd, res->ai_addr, res->ai_addrlen) == 0) + break; + close(tc->fd); + tc->fd = -1; + } + } + if (res == NULL) { + strlcpy(ebuf, strerror(errno), TIS_BUFSIZ); + freeaddrinfo(res0); + tc->fd = -1; + return (-1); + } + freeaddrinfo(res0); + debug("TIS authsrv inet connection success"); + } else { + struct sockaddr_un sa; + tc->fd = socket(PF_UNIX, SOCK_STREAM, 0); + if (tc->fd != -1) { + strncpy(sa.sun_path, server + strlen("unix:"), + sizeof(sa.sun_path)); + sa.sun_family = AF_UNIX; + if (connect(tc->fd, + (struct sockaddr *)&sa, sizeof(sa)) < 0 ) { + close(tc->fd); + tc->fd = -1; + debug2("unix socket connection fail"); + return (-1); + } + } + debug("TIS authsrv unix connection success"); + } + + + /* read welcome banner */ + if (tis_recv(tc, buf, sizeof(buf)) == -1) { + strlcpy(ebuf, strerror(errno), TIS_BUFSIZ); + close(tc->fd); + tc->fd = -1; + return (-1); + } + if (strncmp(buf, "Authsrv ready", 13) != 0) { + strlcpy(ebuf, buf, TIS_BUFSIZ); + close(tc->fd); + tc->fd = -1; + return (-1); + } + debug("TIS authsrv connection setup success"); + + return (tc->fd); + } + + /* + * Read a one-line response from authsrv. + * On success, returns 0. On error, returns non-zero and calls syslog(). + */ + ssize_t + tis_recv(struct tis_connection *tc, u_char *buf, size_t bufsiz) + { + des_key_schedule ks; + des_cblock iv; + ssize_t len; + u_char *cp, *ep, tbuf[TIS_BUFSIZ]; + + for (cp = buf, ep = buf + bufsiz; cp < ep; cp++) { + alarm(tc->timeout); + len = read(tc->fd, cp, 1); + alarm(0); + if (len != 1) { + if (len == -1) + logit("error reading data from authsrv: %m"); + else + logit("EOF reading data from authsrv"); + return (-1); + } + if (*cp == '\n') + break; + } + if (*cp != '\n') { + logit("server response too large"); + return (-1); + } + *cp = '\0'; + len = cp - buf; + + if (tc->keyfile != NULL) { + if ((len = tis_decode(buf, len)) < 0) { + logit("improperly encoded data from authsrv"); + return (-1); + } + if (len > sizeof(tbuf)) { + logit("encrypted data too large to store"); + return (-1); + } + memcpy(ks, tc->keysched, sizeof(ks)); + memset(iv, 0, sizeof(iv)); + des_ncbc_encrypt((des_cblock *)buf, (des_cblock *)tbuf, + len, ks, &iv, DES_DECRYPT); + if (strlcpy(buf, tbuf, bufsiz) >= bufsiz) { + logit("unencrypted data too large to store"); + memset(tbuf, 0, sizeof(tbuf)); + return (-1); + } + memset(tbuf, 0, sizeof(tbuf)); + } + return (len); + } + + /* + * Send a line to authsrv. + * On success, returns 0. On error, returns non-zero and calls syslog(). + */ + ssize_t + tis_send(struct tis_connection *tc, u_char *buf, size_t len) + { + struct iovec iov[2]; + des_key_schedule ks; + des_cblock iv; + ssize_t nwritten; + size_t n; + u_char cbuf[TIS_BUFSIZ]; + + if (tc->keyfile != NULL) { + memcpy(ks, tc->keysched, sizeof(ks)); + memset(iv, 0, sizeof(iv)); + + len++; /* we need to encrypt the NUL */ + if ((n = len % 8) != 0) + len += 8 - n; /* make multiple of 8 bytes */ + if (len * 2 > sizeof(cbuf)) { + logit("encoded data too large to store"); + return (-1); + } + des_ncbc_encrypt((des_cblock *)buf, (des_cblock *)cbuf, len, + ks, &iv, DES_ENCRYPT); + len = tis_encode(cbuf, len, sizeof(cbuf)); + buf = cbuf; + } + iov[0].iov_base = buf; + iov[0].iov_len = len; + iov[1].iov_base = "\n"; + iov[1].iov_len = 1; + + alarm(tc->timeout); + nwritten = writev(tc->fd, iov, 2); + alarm(0); + if (nwritten != len + 1) { + if (nwritten < 0) + logit("error writing to authsrv: %m"); + else + logit("short write sending to authsrv"); + return (-1); + } + return (nwritten - 1); /* don't include the newline */ + } + + /* + * Convert a stream of bytes hex digits to hex octects in place. + * The passed in buffer must have space for len*2 bytes + * plus a NUL. + */ + ssize_t + tis_encode(u_char *buf, size_t inlen, size_t bufsiz) + { + u_char *in, *out; + size_t outlen; + const static char hextab[] = "0123456789ABCDEF"; + + outlen = inlen * 2; + if (bufsiz <= outlen) + return (-1); + + /* convert from the end -> beginning so we can do it in place */ + for (in = &buf[inlen - 1], out = &buf[outlen - 1]; in >= buf; in--) { + *out-- = hextab[*in & 0x0f]; + *out-- = hextab[*in >> 4]; + } + buf[outlen] = '\0'; + + return (outlen); + } + + /* + * Convert a stream of hex digits to bytes in place. + */ + ssize_t + tis_decode(u_char *buf, size_t len) + { + u_char *end, *in, *out; + int byte; + + if (len & 1) + return (-1); /* len must be even */ + + for (in = out = buf, end = buf + len; in < end; in += 2) { + if (in[1] >= 'A' && in[1] <= 'F') + byte = in[1] - 'A' + 10; + else + byte = in[1] - '0'; + if (in[0] >= 'A' && in[0] <= 'F') + byte += (in[0] - 'A' + 10) * 16; + else + byte += (in[0] - '0') * 16; + if (byte > 0xff || byte < 0) + return (-1); + *out++ = byte; + } + *out = '\0'; + return (out - buf); + } + + /* + * Send a response string to authsrv and check the result. + * Returns the type of response, and an error buffer. + */ + int + tis_verify(struct tis_connection *tc, const char *response, char *ebuf) + { + u_char buf[TIS_BUFSIZ]; + int len; + + ebuf[0] = '\0'; + len = snprintf(buf, sizeof(buf), "response '%s'", response); + if (len == -1 || len >= sizeof(buf)) { + logit("response too large"); + return (-1); + } + if (tis_send(tc, buf, len) < 0) + return (-1); + if (tis_recv(tc, buf, sizeof(buf)) < 0) + return (-1); + if (strncmp(buf, "ok", 2) == 0) { + if (buf[2] != '\0') + strlcpy(ebuf, buf + 3, TIS_BUFSIZ); + memset(buf, 0, sizeof(buf)); + return (0); + } + strlcpy(ebuf, buf, TIS_BUFSIZ); + memset(buf, 0, sizeof(buf)); + return (-1); + } + + #endif /* TIS */ diff -crP ssh/auth-tis.h ssh.my2/auth-tis.h *** ssh/auth-tis.h Thu Jan 1 03:00:00 1970 --- ssh.my2/auth-tis.h Tue Sep 12 13:53:39 2006 *************** *** 0 **** --- 1,39 ---- + /* $OpenBSD: login_tis.h,v 1.1 2004/09/28 15:02:01 millert Exp $ */ + + /* + * Copyright (c) 2004 Todd C. Miller + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + + #define TIS_BUFSIZ 512 /* max size of authsrv reply */ + /* XXX - only 128 for most */ + + #define TIS_PASSWD_TIMEOUT 120 /* password prompt timeout */ + + /* default values for login.conf variables */ + #define TIS_DEFPORT "7777" /* default port to use */ + #define TIS_KEY NULL /* default keyfile */ + #define TIS_DEFSERVER "unix:/var/empty/authsrv.sock" /* default server to contact */ + #define TIS_DEFALTSERVER "localhost" /* default alt server to contact */ + #define TIS_DEFTIMEOUT 15 /* default communications timeout */ + + struct tis_connection { + int fd; + int timeout; + char *keyfile; + char *port; + char *server; + char *altserver; + des_key_schedule keysched; + }; diff -crP ssh/auth2-chall.c ssh.my2/auth2-chall.c *** ssh/auth2-chall.c Sun Jul 17 11:17:54 2005 --- ssh.my2/auth2-chall.c Fri Sep 8 15:10:49 2006 *************** *** 44,49 **** --- 44,52 ---- extern KbdintDevice skey_device; #endif #endif + #ifdef TIS + extern KbdintDevice tis_device; + #endif KbdintDevice *devices[] = { #ifdef BSD_AUTH *************** *** 53,58 **** --- 56,64 ---- &skey_device, #endif #endif + #ifdef TIS + &tis_device, + #endif NULL }; *************** *** 319,330 **** --- 325,343 ---- #ifdef SKEY extern KbdintDevice mm_skey_device; #endif + #ifdef TIS + extern KbdintDevice mm_tis_device; + #endif /* As long as SSHv1 has devices[0] hard coded this is fine */ #ifdef BSD_AUTH devices[0] = &mm_bsdauth_device; #else #ifdef SKEY devices[0] = &mm_skey_device; + #else + #ifdef TIS + devices[0] = &mm_tis_device; + #endif #endif #endif } diff -crP ssh/monitor.c ssh.my2/monitor.c *** ssh/monitor.c Mon Feb 20 20:02:44 2006 --- ssh.my2/monitor.c Mon Sep 11 15:24:09 2006 *************** *** 116,121 **** --- 116,123 ---- int mm_answer_bsdauthrespond(int, Buffer *); int mm_answer_skeyquery(int, Buffer *); int mm_answer_skeyrespond(int, Buffer *); + int mm_answer_tisquery(int, Buffer *); + int mm_answer_tisrespond(int, Buffer *); int mm_answer_keyallowed(int, Buffer *); int mm_answer_keyverify(int, Buffer *); int mm_answer_pty(int, Buffer *); *************** *** 134,139 **** --- 136,143 ---- int mm_answer_gss_checkmic(int, Buffer *); #endif + extern u_int tis_query(); + extern u_int tis_respond(); static Authctxt *authctxt; static BIGNUM *ssh1_challenge = NULL; /* used for ssh1 rsa auth */ *************** *** 177,182 **** --- 181,190 ---- {MONITOR_REQ_SKEYQUERY, MON_ISAUTH, mm_answer_skeyquery}, {MONITOR_REQ_SKEYRESPOND, MON_AUTH, mm_answer_skeyrespond}, #endif + #ifdef TIS + {MONITOR_REQ_TISQUERY, MON_ISAUTH, mm_answer_tisquery}, + {MONITOR_REQ_TISRESPOND, MON_AUTH, mm_answer_tisrespond}, + #endif {MONITOR_REQ_KEYALLOWED, MON_ISAUTH, mm_answer_keyallowed}, {MONITOR_REQ_KEYVERIFY, MON_AUTH, mm_answer_keyverify}, #ifdef GSSAPI *************** *** 214,219 **** --- 222,231 ---- {MONITOR_REQ_SKEYQUERY, MON_ISAUTH, mm_answer_skeyquery}, {MONITOR_REQ_SKEYRESPOND, MON_AUTH, mm_answer_skeyrespond}, #endif + #ifdef TIS + {MONITOR_REQ_TISQUERY, MON_ISAUTH, mm_answer_tisquery}, + {MONITOR_REQ_TISRESPOND, MON_AUTH, mm_answer_tisrespond}, + #endif {0, 0, NULL} }; *************** *** 736,741 **** --- 748,808 ---- mm_request_send(sock, MONITOR_ANS_SKEYRESPOND, m); auth_method = "skey"; + + return (authok != 0); + } + #endif + + #ifdef TIS + int + mm_answer_tisquery(int sock, Buffer *m) + { + char *name, *infotxt; + u_int numprompts; + u_int *echo_on; + char **prompts; + u_int success; + + success = tis_query(authctxt, &name, &infotxt, &numprompts, + &prompts, &echo_on) < 0 ? 0 : 1; + + buffer_clear(m); + buffer_put_int(m, success); + if (success) + buffer_put_cstring(m, prompts[0]); + + debug3("%s: sending challenge success: %u", __func__, success); + mm_request_send(sock, MONITOR_ANS_TISQUERY, m); + + if (success) { + xfree(name); + xfree(infotxt); + xfree(prompts); + xfree(echo_on); + } + + return (0); + } + + int + mm_answer_tisrespond(int sock, Buffer *m) + { + char *response; + int authok; + + response = buffer_get_string(m, NULL); + authok = options.challenge_response_authentication && + (tis_respond(authctxt, 1, &response) == 0); + debug3("%s: <%s> = <%d>", __func__, response, authok); + xfree(response); + + buffer_clear(m); + buffer_put_int(m, authok); + + debug3("%s: sending authenticated: %d", __func__, authok); + mm_request_send(sock, MONITOR_ANS_TISRESPOND, m); + + auth_method = "tis"; return (authok != 0); } diff -crP ssh/monitor.h ssh.my2/monitor.h *** ssh/monitor.h Mon Nov 17 14:06:07 2003 --- ssh.my2/monitor.h Fri Sep 8 15:34:26 2006 *************** *** 39,44 **** --- 39,46 ---- MONITOR_REQ_BSDAUTHRESPOND, MONITOR_ANS_BSDAUTHRESPOND, MONITOR_REQ_SKEYQUERY, MONITOR_ANS_SKEYQUERY, MONITOR_REQ_SKEYRESPOND, MONITOR_ANS_SKEYRESPOND, + MONITOR_REQ_TISQUERY, MONITOR_ANS_TISQUERY, + MONITOR_REQ_TISRESPOND, MONITOR_ANS_TISRESPOND, MONITOR_REQ_KEYALLOWED, MONITOR_ANS_KEYALLOWED, MONITOR_REQ_KEYVERIFY, MONITOR_ANS_KEYVERIFY, MONITOR_REQ_KEYEXPORT, diff -crP ssh/monitor_wrap.c ssh.my2/monitor_wrap.c *** ssh/monitor_wrap.c Tue May 24 21:32:43 2005 --- ssh.my2/monitor_wrap.c Fri Sep 8 15:45:37 2006 *************** *** 849,854 **** --- 849,913 ---- } #endif /* SKEY */ + #ifdef TIS + int + mm_tis_query(void *ctx, char **name, char **infotxt, + u_int *numprompts, char ***prompts, u_int **echo_on) + { + Buffer m; + int len; + u_int success; + char *p, *challenge; + + debug3("%s: entering", __func__); + + buffer_init(&m); + mm_request_send(pmonitor->m_recvfd, MONITOR_REQ_TISQUERY, &m); + + mm_request_receive_expect(pmonitor->m_recvfd, MONITOR_ANS_TISQUERY, + &m); + success = buffer_get_int(&m); + if (success == 0) { + debug3("%s: no challenge", __func__); + buffer_free(&m); + return (-1); + } + /* Get the challenge, and format the response */ + challenge = buffer_get_string(&m, NULL); + buffer_free(&m); + + mm_chall_setup(name, infotxt, numprompts, prompts, echo_on); + (*prompts)[0] = challenge; + + debug3("%s: received challenge: %s", __func__, challenge); + + return (0); + } + + int + mm_tis_respond(void *ctx, u_int numresponses, char **responses) + { + Buffer m; + int authok; + + debug3("%s: entering", __func__); + if (numresponses != 1) + return (-1); + + buffer_init(&m); + buffer_put_cstring(&m, responses[0]); + mm_request_send(pmonitor->m_recvfd, MONITOR_REQ_TISRESPOND, &m); + + mm_request_receive_expect(pmonitor->m_recvfd, + MONITOR_ANS_TISRESPOND, &m); + + authok = buffer_get_int(&m); + buffer_free(&m); + + return ((authok == 0) ? -1 : 0); + } + #endif /* TIS */ + void mm_ssh1_session_id(u_char session_id[16]) { diff -crP ssh/monitor_wrap.h ssh.my2/monitor_wrap.h *** ssh/monitor_wrap.h Mon Jun 21 21:36:31 2004 --- ssh.my2/monitor_wrap.h Fri Sep 8 15:36:21 2006 *************** *** 90,95 **** --- 90,99 ---- int mm_skey_query(void *, char **, char **, u_int *, char ***, u_int **); int mm_skey_respond(void *, u_int, char **); + /* tis */ + int mm_tis_query(void *, char **, char **, u_int *, char ***, u_int **); + int mm_tis_respond(void *, u_int, char **); + /* zlib allocation hooks */ void *mm_zalloc(struct mm_master *, u_int, u_int); From Dan.Goldburt at dowjones.com Wed Sep 13 00:38:36 2006 From: Dan.Goldburt at dowjones.com (Goldburt, Dan) Date: Tue, 12 Sep 2006 10:38:36 -0400 Subject: Multiple (multiplexed) simultaneous ssh connections - Cygwin bug? Message-ID: <57E557D9D8FCEB4DB0B8DB430C6DBD08069040FD@SBKE2KMB03.win.dowjones.net> > Darren Tucker wrote: > > Goldburt, Dan wrote: > > > > 1. What does the cygwin limitation bound my max sessions > to? > > I'm not sure, actually. You seem to be hitting some limit > at 31 > descriptors before the fd_set one, which should be at 64 > (3 per session > = ~20 concurrent). What does "ulimit -n" report the > descriptor limit > as, and do you have some local processes using some of > them? ulimit -n on cygwin reports 256 open files max. Is there a per-process limit? I'm thinking specifically about setdtablesize() (see http://sourceware.org/ml/cygwin/2000-09/msg00286.html) > > 2. I need to make sure if I do still accidentally > overrun the fd_set, I > > will not crash sshd. Right now it goes into an infinite > loop spitting > > out "select: Bad file descriptor" and taking up 100% > CPU. Surely this is > > a bug that needs to be patched? > > Maybe, but it only occurs with modified code, right? Not necessarily. The only modification was to increase MAX_SESSIONS per connection from 10 to 128. But even without the change, let's say I have one multiplexed connection that is hosting 10 sessions. I can also simultaneously open 15 regular ssh connections to have 25 sessions opening up, and there is a good chance I will overrun the fd_set. > > 3. Any chance I can overcome the limitation from inside > sshd? How do I > > implement the following: > >> To make this work, you would probably need to break the > >> select into FD_SETSIZE chunks somehow. > > I was thinking of overloading select an associated macros > in the compat > library but it's probably not trivial. Kudos to anyone who attempts that. It would make for a very robust solution, IMHO. Even better would be for this change to be made in the Cygwin select() code (that is what sshd is using, correct? Also, there seems to be some confusion whether winsock's select() implementation is being used in cygwin or not - see http://sourceware.org/ml/cygwin/1999-12/msg00149.html). > Damien said that > the fd_sets > were dynamically allocated but I'm not sure how that helps > in the case > where there's more than FD_SETSIZE descriptors. I'm not sure either. What does he mean by dynamically allocated? I see in serverloop.c (lines 638 - 642): > max_fd = MAX(connection_in, connection_out); > max_fd = MAX(max_fd, fdin); > max_fd = MAX(max_fd, fdout); > max_fd = MAX(max_fd, fderr); > max_fd = MAX(max_fd, notify_pipe[0]); which dynamically increments the number of file descriptors to select on. The next lines (655 and 645) use this value: > /* Sleep in select() until we can do something. */ > wait_until_can_do_something(&readset, &writeset, &max_fd, > &nalloc, max_time_milliseconds); and this is where (I think/haven't proved) the bug lives. As soon as max_fd exceeds FD_SETSIZE, we try to select on a fd outside of the cygwin supported array size. This accounts for the "select: Bad file descriptor" error, but more importantly since the fd we are actually interested in lies outside of the selectable range, the returned bitmask will never change and we will never break out of the "sleep in select loop". (see http://sourceware.org/ml/cygwin/1999-11/msg00451.html) I think this is a serious bug on, can somebody please vet my analysis? As far as I can tell, max_fd should be bounded to FD_SETSIZE under cygwin. From dtucker at zip.com.au Wed Sep 13 00:49:35 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 13 Sep 2006 00:49:35 +1000 Subject: Multiple (multiplexed) simultaneous ssh connections - Cygwin bug? In-Reply-To: <57E557D9D8FCEB4DB0B8DB430C6DBD08069040FD@SBKE2KMB03.win.dowjones.net> References: <57E557D9D8FCEB4DB0B8DB430C6DBD08069040FD@SBKE2KMB03.win.dowjones.net> Message-ID: <20060912144935.GA11097@gate.dtucker.net> On Tue, Sep 12, 2006 at 10:38:36AM -0400, Goldburt, Dan wrote: > Not necessarily. The only modification was to increase MAX_SESSIONS per > connection from 10 to 128. But even without the change, let's say I have > one multiplexed connection that is hosting 10 sessions. I can also > simultaneously open 15 regular ssh connections to have 25 sessions > opening up, and there is a good chance I will overrun the fd_set. No, the file descriptor table (and thus fd_set) is per-process and each SSH connection has its own sshd process handling it. (It's a bit late here to go into the rest of your mail, sorry.) -- 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 vc.Scott.F.Strickler at Lowes.com Wed Sep 13 00:37:58 2006 From: vc.Scott.F.Strickler at Lowes.com (Strickler, Scott - Scott F) Date: Tue, 12 Sep 2006 10:37:58 -0400 Subject: Weird TZ Behavior in 4.1p1 and 4.3p2 on AIX Message-ID: <6934966A0A38FD458F86472243E538BC1A7C9F@msexchdb04.lowes.com> Hi, I am using PAM authentication on 3.8p1. In my PAM auth module I can turn on debug logging that includes a timestamp in the form "mm/dd/yy hh:mm:ss". Life is good. I want to upgrade from 3.8p1 so I can use PAM for PasswordAuthentication in addition to keyboard-interactive. I have compiled both 4.1p1 and 4.3p2 and the PAM authentication for both methods works fine in both releases, but I have a weird annoyance in the logging. The timestamp code appears to be ignoring the TZ setting. Here is a snippet from the logfile where I changed back and forth from 3.8p1 and 4.1p1 as I logged in ~ 9:30 this morning: 09/12/06 09:34:52 username hostname.xxxxx.com 09/12/06 09:35:02 username authenticating locally 09/12/06 09:35:02 username local authentication succeeded 09/12/06 13:35:21 username hostname.xxxxx.com 09/12/06 13:35:25 username authenticating locally 09/12/06 13:35:25 username local authentication succeeded 09/12/06 09:36:07 username hostname.xxxxx.com 09/12/06 09:36:12 username authenticating locally I found that commenting out "environ[0] = NULL;" in pam-auth.c fixed the TZ problem, but created others. Any suggestions? Scott Strickler ***** Please note: The Sender of this email is either a Contractor or Vendor of Lowe's Companies, Inc. and is not an employee or agent of Lowe's Companies Inc. ***** From dtucker at zip.com.au Wed Sep 13 08:17:33 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 13 Sep 2006 08:17:33 +1000 Subject: Weird TZ Behavior in 4.1p1 and 4.3p2 on AIX In-Reply-To: <6934966A0A38FD458F86472243E538BC1A7C9F@msexchdb04.lowes.com> References: <6934966A0A38FD458F86472243E538BC1A7C9F@msexchdb04.lowes.com> Message-ID: <20060912221733.GA2827@gate.dtucker.net> On Tue, Sep 12, 2006 at 10:37:58AM -0400, Strickler, Scott - Scott F wrote: > I want to upgrade from 3.8p1 so I can use PAM for PasswordAuthentication > in addition to keyboard-interactive. I have compiled both 4.1p1 and > 4.3p2 and the PAM authentication for both methods works fine in both > releases, but I have a weird annoyance in the logging. The timestamp > code appears to be ignoring the TZ setting. Here is a snippet from the > logfile where I changed back and forth from 3.8p1 and 4.1p1 as I logged > in ~ 9:30 this morning: Maybe we should save and restore TZ, like the following? (untested) Index: auth-pam.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/auth-pam.c,v retrieving revision 1.140 diff -u -p -r1.140 auth-pam.c --- auth-pam.c 1 Sep 2006 05:38:36 -0000 1.140 +++ auth-pam.c 12 Sep 2006 22:13:49 -0000 @@ -437,10 +437,16 @@ sshpam_thread(void *ctxtp) u_int i; const char *pam_user; const char **ptr_pam_user = &pam_user; + char *tz = getenv("TZ"); pam_get_item(sshpam_handle, PAM_USER, (sshpam_const void **)ptr_pam_user); + environ[0] = NULL; + if (tz != NULL) + if (putenv("TZ", tz) == -1) + error("PAM: could not set TZ environment: %s", + strerror(errno)); if (sshpam_authctxt != NULL) { setproctitle("%s [pam]", -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From rapier at psc.edu Thu Sep 14 00:53:46 2006 From: rapier at psc.edu (Chris Rapier) Date: Wed, 13 Sep 2006 10:53:46 -0400 Subject: openssh-4.3p2: setsockopt() problem In-Reply-To: References: Message-ID: <45081B7A.8050403@psc.edu> This is likely due to the router and how it is handling header information. If it's rewriting portions of the header after the syn is sent I could see a connections hanging. Getting a tcpdump of a connection on both sides would probably let you figure out exactly where the badness is taking place. Kenneth Berland wrote: > List, > > I'm behind a dlink DSL-G604T wireless router. ssh client was hanging at: > > debug1: Entering interactive session. > > Telnet was having a similar problem to port 22, however a simple client.c > I compiled was not. My java ssh client was also working. After some > investigation, I noticed that the hang was after the system call: > > setsockopt(3, SOL_IP, IP_TOS, [16], 4) = 0 > > I noticed also that telnet was hanging the same way. I commented all the > setsockopt() calls out of the ssh client code (because I was in a hurry) > and now it works. Anyway, I figured I should document the problem > somewhere. > > -Ken > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From Dan.Goldburt at dowjones.com Thu Sep 14 08:17:28 2006 From: Dan.Goldburt at dowjones.com (Goldburt, Dan) Date: Wed, 13 Sep 2006 18:17:28 -0400 Subject: Multiple (multiplexed) simultaneous ssh connections - Cygwin bug? Message-ID: <57E557D9D8FCEB4DB0B8DB430C6DBD08069040FF@SBKE2KMB03.win.dowjones.net> Hi, To recap, I'm establishing one master ssh connection and am opening many session through that one master connection. Often I get "select: Bad file descriptor errors" and the server thrashes at 100% CPU. The symptoms are very similar to those in this post: http://sourceware.org/ml/cygwin/2001-09/msg01217.html But the solution there doesn't work for OpenSSH. Initially I believed that the number of file descriptors being opened were overrunning the fd_set. But it doesn't seem like I'm overrunning the FD_SETSIZE. On the server, ulimit -n return 256, and I also tried the following. Darren Tucker wrote: > BTW did you try bumping FD_SETSIZE when configuring > OpenSSH with your > increased MAX_SESSIONS? > eg: ./configure --with-cflags=-DFD_SETSIZE=256 > I'm getting select() errors randomly, sometimes selecting up to file descriptor 31, sometimes up to 38, sometimes up to 191, but sometimes I don't get any errors (even for over 80 simultaneous sessions.) But once it happens once, every subsequent select will fail (looping and thrashing the server). This seems to me to be a serious bug. Yes, I did increase MAX_SESSIONS from 10 to 128, but that just made it easier to generate the error. You can also reproduce it if you install sshd to listen on several ports (start it with multiple -p arguments), and on each port establish a multiplexed connection with many sessions. In any case, shouldn't OpenSSH somehow handle the EBADF? The offending code is in serverloop.c, line 332: ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp); I tried setting *maxfdp to FD_SETSIZE (as suggested in the post above), but then I would get EBADF every single time. I also tried setting *maxfdp to something small like 30, but then select would always come back with 0 because the fd it was interested in was greater than 30. The unix manpage defines "EBADF: One or more of the file descriptor sets specified a file descriptor that is not a valid open file descriptor." (http://www.scit.wlv.ac.uk/cgi-bin/mansec?3C+FD_SET). I modified the code to handle the EBADF error. An example of what I'm printing right now is "select: EBADF (bad file descriptor), maxfdp=38 FD_SETSIZE=256 readsetp=4 writesetp=4". Here is the code following the select: ret = select(..); if (ret == -1) { memset(*readsetp, 0, *nallocp); memset(*writesetp, 0, *nallocp); if (errno == EBADF) { error("select: EBADF (bad file descriptor), maxfdp=%d FD_SETSIZE=%d readsetp=%d writesetp=%d", (*maxfdp), FD_SETSIZE, sizeof(*readsetp), sizeof(*writesetp)); fatal("Bad file descriptor loop"); } else if (errno != EINTR) { error("select: %.100s", strerror(errno)); } } . . How can I print something to best debug the problem? Anybody have a best guess why I'm getting EBADF? Was a file descriptor unexpectedly closed but we are still trying to select on it? From aet at cc.hut.fi Thu Sep 14 21:20:03 2006 From: aet at cc.hut.fi (Antti Tapaninen) Date: Thu, 14 Sep 2006 14:20:03 +0300 (EEST) Subject: [PATCH] PermitRootLogin woes Message-ID: Hi all, among other things, we provide shell access to various unix based platforms for our students and university staff. Recently, there has been increasing number of root login attacks on one particular Tru64 machine running OpenSSH. The host is configured with "PermitRootLogin no" but every once in a while SIA auth with TCB enhanced security locks the root account. I suppose the problem could be solved at two separate levels, for SIA only in auth-sia.c, or for any password using auth method in auth-passwd.c. I'd prefer a fix just for auth-passwd.c, are there any reasons to try out auth_krb5_password, sshpam_auth_passwd or sys_auth_passwd if variable "ok" is set to zero already? Cheers, -Antti Index: auth-passwd.c =================================================================== RCS file: /openssh/openssh_cvs/auth-passwd.c,v retrieving revision 1.86 diff -u -r1.86 auth-passwd.c --- auth-passwd.c 5 Aug 2006 02:39:39 -0000 1.86 +++ auth-passwd.c 14 Sep 2006 10:54:12 -0000 @@ -88,7 +88,7 @@ #ifndef HAVE_CYGWIN if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES) - ok = 0; + return 0; #endif if (*password == '\0' && options.permit_empty_passwd == 0) return 0; Index: auth-sia.c =================================================================== RCS file: /openssh/openssh_cvs/auth-sia.c,v retrieving revision 1.18 diff -u -r1.18 auth-sia.c --- auth-sia.c 7 Sep 2006 23:54:41 -0000 1.18 +++ auth-sia.c 14 Sep 2006 10:54:12 -0000 @@ -55,12 +55,14 @@ int ret; SIAENTITY *ent = NULL; const char *host; + struct passwd * pw = authctxt->pw; - host = get_canonical_hostname(options.use_dns); - + if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES) + return (0); if (!authctxt->user || pass == NULL || pass[0] == '\0') return (0); + host = get_canonical_hostname(options.use_dns); if (sia_ses_init(&ent, saved_argc, saved_argv, host, authctxt->user, NULL, 0, NULL) != SIASUCCESS) return (0); From dtucker at zip.com.au Thu Sep 14 22:27:41 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 14 Sep 2006 22:27:41 +1000 Subject: [PATCH] PermitRootLogin woes In-Reply-To: References: Message-ID: <20060914122741.GA2611@gate.dtucker.net> On Thu, Sep 14, 2006 at 02:20:03PM +0300, Antti Tapaninen wrote: > > Hi all, > > among other things, we provide shell access to various unix based > platforms for our students and university staff. Recently, there has been > increasing number of root login attacks on one particular Tru64 machine > running OpenSSH. > > The host is configured with "PermitRootLogin no" but every once in a while > SIA auth with TCB enhanced security locks the root account. > > I suppose the problem could be solved at two separate levels, for SIA only > in auth-sia.c, or for any password using auth method in auth-passwd.c. > > I'd prefer a fix just for auth-passwd.c, are there any reasons to try out > auth_krb5_password, sshpam_auth_passwd or sys_auth_passwd if variable "ok" > is set to zero already? On platforms where a failed login attempt is noticable by the time it takes, shortcutting the "ok" check leaks information about what is and is not permitted. -- 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 aet at cc.hut.fi Fri Sep 15 02:40:54 2006 From: aet at cc.hut.fi (Antti Tapaninen) Date: Thu, 14 Sep 2006 19:40:54 +0300 (EEST) Subject: [PATCH] PermitRootLogin woes In-Reply-To: <20060914122741.GA2611@gate.dtucker.net> References: <20060914122741.GA2611@gate.dtucker.net> Message-ID: On Thu, 14 Sep 2006, Darren Tucker wrote: > On platforms where a failed login attempt is noticable by the time it takes, > shortcutting the "ok" check leaks information about what is and is not > permitted. I'm not following, sorry. What do you mean by noticable and leaking information about what is and is not permitted? As for noticing or monitoring failed authentications, auth_log() does a pretty good job informing about user authentications failed and where they came from. I fail to see how it's reasonable to allow anyone attack and even lock root accounts, even though PermitRootLogin sounds like a perfect solution against it. Using auth layers (pam, sia, kdc, something other not so lightweight) for nothing. Thanks, -Antti From rmarshall at solidodesign.com Fri Sep 15 05:24:13 2006 From: rmarshall at solidodesign.com (Ross Marshall) Date: Thu, 14 Sep 2006 13:24:13 -0600 Subject: openSSH 4.3p2 Message-ID: <1158261853.22038.18.camel@localhost.localdomain> I have compiled the latest version to test out, installed into /opt so as not to break my old version, and have not been able to log in, I am trying to ssh into the local machine... rmarshall at Sam:/opt/bin$ ./ssh sam -v OpenSSH_4.3p2, OpenSSL 0.9.7g 11 Apr 2005 debug1: Reading configuration data /opt/etc/ssh/ssh_config debug1: Connecting to sam [127.0.0.1] port 22. debug1: Connection established. debug1: identity file /home/rmarshall/.ssh/identity type 0 debug1: identity file /home/rmarshall/.ssh/id_rsa type 1 debug1: identity file /home/rmarshall/.ssh/id_dsa type 2 ssh_exchange_identification: Connection closed by remote host My hosts.allow is: ssh: 0.0.0.0/0.0.0.0 I am allowing both protocols 1 and 2 Have generated the keys (I don't get any error messages when I start the daemon). When I do a: rmarshall at Sam:/opt/bin$ ./ssh sam -vvv OpenSSH_4.3p2, OpenSSL 0.9.7g 11 Apr 2005 debug1: Reading configuration data /opt/etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to sam [127.0.0.1] port 22. debug1: Connection established. debug1: identity file /home/rmarshall/.ssh/identity type 0 debug3: Not a RSA1 key file /home/rmarshall/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /home/rmarshall/.ssh/id_rsa type 1 debug3: Not a RSA1 key file /home/rmarshall/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /home/rmarshall/.ssh/id_dsa type 2 ssh_exchange_identification: Connection closed by remote host I have googled until I can't google no more, can anyone help? marros From dtucker at zip.com.au Fri Sep 15 14:27:27 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 15 Sep 2006 14:27:27 +1000 Subject: openSSH 4.3p2 In-Reply-To: <1158261853.22038.18.camel@localhost.localdomain> References: <1158261853.22038.18.camel@localhost.localdomain> Message-ID: <20060915042727.GA32073@gate.dtucker.net> On Thu, Sep 14, 2006 at 01:24:13PM -0600, Ross Marshall wrote: > I have compiled the latest version to test out, installed into /opt so > as not to break my old version, and have not been able to log in, I am > trying to ssh into the local machine... [...] > ssh_exchange_identification: Connection closed by remote host That's often caused by tcpwrappers... > My hosts.allow is: ssh: 0.0.0.0/0.0.0.0 tcpwrappers expects the name of the process doing the check (ie "sshd") not the protocol. If you chage the "ssh" to "sshd" it should be ok. -- 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 jhb at freebsd.org Fri Sep 15 06:41:20 2006 From: jhb at freebsd.org (John Baldwin) Date: Thu, 14 Sep 2006 16:41:20 -0400 Subject: sshd audit not happy with ssh1 and scp Message-ID: <200609141641.21243.jhb@freebsd.org> I think I've found a bug with sshd handling audit events for commands (like scp) over ssh1 connections. Specifically, after updating to a recent FreeBSD 6.x with audit support, I'm getting log messages like these when using scp over ssh1: Sep 12 14:13:16 bm55 sshd[12335]: Accepted rsa for xxx from A.B.C.D port 2981 Sep 12 14:13:16 bm55 sshd[12335]: fatal: monitor_read: unpermitted request 57 Sep 12 14:13:16 bm55 kernel: Sep 12 14:13:16 bm55 sshd[12335]: fatal: monitor_read: unpermitted request 57 Sep 12 14:13:16 bm55 sshd[12337]: fatal: mm_request_send: write: Broken pipe Sep 12 14:13:16 bm55 kernel: Sep 12 14:13:16 bm55 sshd[12337]: fatal: mm_request_send: write: Broken pipe I tracked these down to the audit event handling for ssh1. Changing ssh1 to use MON_PERMIT instead of MON_ONCE (ssh2 uses MON_PERMIT) for REQ_AUDIT_COMMAND fixes it (well, shuts up the warnings): ==== //depot/yahoo/ybsd_6/src/crypto/openssh/monitor.c#4 (text+ko) ==== @@ -272,7 +272,7 @@ {MONITOR_REQ_TERM, 0, mm_answer_term}, #ifdef SSH_AUDIT_EVENTS {MONITOR_REQ_AUDIT_EVENT, MON_PERMIT, mm_answer_audit_event}, - {MONITOR_REQ_AUDIT_COMMAND, MON_ONCE, mm_answer_audit_command}, + {MONITOR_REQ_AUDIT_COMMAND, MON_PERMIT, mm_answer_audit_command}, #endif {0, 0, NULL} }; I notice that early on it tries to enable MONITOR_REQ_AUDIT_COMMAND in mm_answer_pwnamallow(). However, this doesn't actually work as it tries to enable it in the monitor_dispatch table (which doesn't even have a REQ_AUDIT_COMMAND in either version 1.5 or 2.0) when it needs to be enabled in the monitor_postauth table instead. So, you can either make it MON_PERMIT like above or you can fix it to not do the monitor_permit() on the passed in table, but do it on the appropriate postauth table instead. I'm using the above patch for now, but if you fix openssh I'll go with the vendor's fix once it makes it into FreeBSD of course. I don't know if the better fix is the patch above to get ssh1 in sync with ssh2 (in which case th monitor_permit() in mm_answer_pwnameallow() should probably be removed), or to fix mm_answer_pwnameallow() to perform the monitor_permit() on the correct dispatch table. -- John Baldwin From dtucker at zip.com.au Sat Sep 16 19:23:02 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 16 Sep 2006 19:23:02 +1000 Subject: sshd audit not happy with ssh1 and scp In-Reply-To: <200609141641.21243.jhb@freebsd.org> References: <200609141641.21243.jhb@freebsd.org> Message-ID: <20060916092302.GA13871@gate.dtucker.net> On Thu, Sep 14, 2006 at 04:41:20PM -0400, John Baldwin wrote: > I think I've found a bug with sshd handling audit events for commands (like > scp) over ssh1 connections. Specifically, after updating to a recent FreeBSD > 6.x with audit support, I'm getting log messages like these when using scp > over ssh1: > > Sep 12 14:13:16 bm55 sshd[12335]: Accepted rsa for xxx from > A.B.C.D port 2981 > Sep 12 14:13:16 bm55 sshd[12335]: fatal: monitor_read: unpermitted Thanks for the report. FreeBSD is using audit support now? Is it the debug driver, or are you using OpenBSM or something? [...] > - {MONITOR_REQ_AUDIT_COMMAND, MON_ONCE, mm_answer_audit_command}, > + {MONITOR_REQ_AUDIT_COMMAND, MON_PERMIT, mm_answer_audit_command}, Since SSH protocol 1 can only support a single command per session, the intent was to only allow the monitor call once, although it probably doesn't matter much. > I notice that early on it tries to enable MONITOR_REQ_AUDIT_COMMAND in > mm_answer_pwnamallow(). However, this doesn't actually work as it tries > to enable it in the monitor_dispatch table (which doesn't even have a > REQ_AUDIT_COMMAND in either version 1.5 or 2.0) when it needs to be enabled > in the monitor_postauth table instead. You're right. I think that should be probably be removed. Does the following patch also resolve the problem for you? Index: monitor.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/monitor.c,v retrieving revision 1.119 diff -u -p -r1.119 monitor.c --- monitor.c 1 Sep 2006 05:48:19 -0000 1.119 +++ monitor.c 16 Sep 2006 09:15:53 -0000 @@ -286,7 +286,7 @@ struct mon_table mon_dispatch_postauth15 {MONITOR_REQ_TERM, 0, mm_answer_term}, #ifdef SSH_AUDIT_EVENTS {MONITOR_REQ_AUDIT_EVENT, MON_PERMIT, mm_answer_audit_event}, - {MONITOR_REQ_AUDIT_COMMAND, MON_ONCE, mm_answer_audit_command}, + {MONITOR_REQ_AUDIT_COMMAND, MON_PERMIT|MON_ONCE, mm_answer_audit_command}, #endif {0, 0, NULL} }; @@ -660,9 +660,6 @@ mm_answer_pwnamallow(int sock, Buffer *m if (options.use_pam) monitor_permit(mon_dispatch, MONITOR_REQ_PAM_START, 1); #endif -#ifdef SSH_AUDIT_EVENTS - monitor_permit(mon_dispatch, MONITOR_REQ_AUDIT_COMMAND, 1); -#endif return (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 jhb at freebsd.org Sat Sep 16 23:31:37 2006 From: jhb at freebsd.org (John Baldwin) Date: Sat, 16 Sep 2006 09:31:37 -0400 Subject: sshd audit not happy with ssh1 and scp In-Reply-To: <20060916092302.GA13871@gate.dtucker.net> References: <200609141641.21243.jhb@freebsd.org> <20060916092302.GA13871@gate.dtucker.net> Message-ID: <200609160931.38065.jhb@freebsd.org> On Saturday 16 September 2006 05:23, Darren Tucker wrote: > On Thu, Sep 14, 2006 at 04:41:20PM -0400, John Baldwin wrote: > > I think I've found a bug with sshd handling audit events for commands (like > > scp) over ssh1 connections. Specifically, after updating to a recent FreeBSD > > 6.x with audit support, I'm getting log messages like these when using scp > > over ssh1: > > > > Sep 12 14:13:16 bm55 sshd[12335]: Accepted rsa for xxx from > > A.B.C.D port 2981 > > Sep 12 14:13:16 bm55 sshd[12335]: fatal: monitor_read: unpermitted > > Thanks for the report. FreeBSD is using audit support now? Is it the > debug driver, or are you using OpenBSM or something? OpenBSM. It's now in FreeBSD 6.x and BSM_AUDIT is enabled by default. > [...] > > - {MONITOR_REQ_AUDIT_COMMAND, MON_ONCE, mm_answer_audit_command}, > > + {MONITOR_REQ_AUDIT_COMMAND, MON_PERMIT, mm_answer_audit_command}, > > Since SSH protocol 1 can only support a single command per session, the > intent was to only allow the monitor call once, although it probably > doesn't matter much. Ok. > > I notice that early on it tries to enable MONITOR_REQ_AUDIT_COMMAND in > > mm_answer_pwnamallow(). However, this doesn't actually work as it tries > > to enable it in the monitor_dispatch table (which doesn't even have a > > REQ_AUDIT_COMMAND in either version 1.5 or 2.0) when it needs to be enabled > > in the monitor_postauth table instead. > > You're right. I think that should be probably be removed. > > Does the following patch also resolve the problem for you? Yes, the patch works great. Thanks! I assume you are going to commit that to OpenSSH? DES, can you import this as a vendor fix on the vendor branch? > Index: monitor.c > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh/monitor.c,v > retrieving revision 1.119 > diff -u -p -r1.119 monitor.c > --- monitor.c 1 Sep 2006 05:48:19 -0000 1.119 > +++ monitor.c 16 Sep 2006 09:15:53 -0000 > @@ -286,7 +286,7 @@ struct mon_table mon_dispatch_postauth15 > {MONITOR_REQ_TERM, 0, mm_answer_term}, > #ifdef SSH_AUDIT_EVENTS > {MONITOR_REQ_AUDIT_EVENT, MON_PERMIT, mm_answer_audit_event}, > - {MONITOR_REQ_AUDIT_COMMAND, MON_ONCE, mm_answer_audit_command}, > + {MONITOR_REQ_AUDIT_COMMAND, MON_PERMIT|MON_ONCE, mm_answer_audit_command}, > #endif > {0, 0, NULL} > }; > @@ -660,9 +660,6 @@ mm_answer_pwnamallow(int sock, Buffer *m > if (options.use_pam) > monitor_permit(mon_dispatch, MONITOR_REQ_PAM_START, 1); > #endif > -#ifdef SSH_AUDIT_EVENTS > - monitor_permit(mon_dispatch, MONITOR_REQ_AUDIT_COMMAND, 1); > -#endif > > return (0); > } > -- John Baldwin From jam_man at sbcglobal.net Sun Sep 17 06:18:51 2006 From: jam_man at sbcglobal.net (James Maniotis) Date: Sat, 16 Sep 2006 15:18:51 -0500 Subject: Forcing encryption algorithms on server side Message-ID: <450C5C2B.1060106@sbcglobal.net> As the man pages say, you can force an encryption algorithm from the server side by use of the "Cipher" command. How would one verify this is working? Thanks. From dtucker at zip.com.au Sun Sep 17 10:33:56 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 17 Sep 2006 10:33:56 +1000 Subject: Forcing encryption algorithms on server side In-Reply-To: <450C5C2B.1060106@sbcglobal.net> References: <450C5C2B.1060106@sbcglobal.net> Message-ID: <450C97F4.60606@zip.com.au> James Maniotis wrote: > As the man pages say, you can force an encryption algorithm from the > server side by use of the "Cipher" command. On the server side it's "Ciphers". Be aware that it applies only to Protocol 2. > How would one verify this is working? Thanks. Run the client in debug mode (eg "ssh -vv yourserver"). Amongst the output, you will see something like this: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,[...] debug2: kex_parse_kexinit: 3des-cbc,arcfour debug2: kex_parse_kexinit: 3des-cbc,arcfour The lines after the "reserved" one are the key exchange methods, signature and ciphers offered by the server. and a bit further down you will see something like this, which indicates which cipher, MAC and compression were selected: debug2: mac_init: found hmac-md5 debug1: kex: client->server arcfour hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: server->client arcfour hmac-md5 none In this example, the server offered the 3des-cbc and arcfour ciphers, and the client picked arcfour. -- 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 Sun Sep 17 12:02:07 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 17 Sep 2006 12:02:07 +1000 Subject: sshd audit not happy with ssh1 and scp In-Reply-To: <200609160931.38065.jhb@freebsd.org> References: <200609141641.21243.jhb@freebsd.org> <20060916092302.GA13871@gate.dtucker.net> <200609160931.38065.jhb@freebsd.org> Message-ID: <20060917020207.GA31665@gate.dtucker.net> On Sat, Sep 16, 2006 at 09:31:37AM -0400, John Baldwin wrote: > On Saturday 16 September 2006 05:23, Darren Tucker wrote: > > Thanks for the report. FreeBSD is using audit support now? Is it the > > debug driver, or are you using OpenBSM or something? > > OpenBSM. It's now in FreeBSD 6.x and BSM_AUDIT is enabled by default. Cool. Out of curiousity, did you have to modify the audit support in sshd, or did it work out of the box? > > You're right. I think that should be probably be removed. > > > > Does the following patch also resolve the problem for you? > > Yes, the patch works great. Thanks! I assume you are going to commit > that to OpenSSH? DES, can you import this as a vendor fix on the > vendor branch? Yes, it has been committed and will be in 4.4p1. Thanks again. -- 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 jhb at freebsd.org Sun Sep 17 12:45:27 2006 From: jhb at freebsd.org (John Baldwin) Date: Sat, 16 Sep 2006 22:45:27 -0400 Subject: sshd audit not happy with ssh1 and scp In-Reply-To: <20060917020207.GA31665@gate.dtucker.net> References: <200609141641.21243.jhb@freebsd.org> <200609160931.38065.jhb@freebsd.org> <20060917020207.GA31665@gate.dtucker.net> Message-ID: <200609162245.28258.jhb@freebsd.org> On Saturday 16 September 2006 22:02, Darren Tucker wrote: > On Sat, Sep 16, 2006 at 09:31:37AM -0400, John Baldwin wrote: > > On Saturday 16 September 2006 05:23, Darren Tucker wrote: > > > Thanks for the report. FreeBSD is using audit support now? Is it the > > > debug driver, or are you using OpenBSM or something? > > > > OpenBSM. It's now in FreeBSD 6.x and BSM_AUDIT is enabled by default. > > Cool. Out of curiousity, did you have to modify the audit support in > sshd, or did it work out of the box? I have no idea. I just upgraded to newer FreeBSD 6.x and started getting the error messages in my logs. :) Probably a better person to ask about anything OpenBSM related in FreeBSD is rwatson at FreeBSD.org or csjp at FreeBSD.org. > > > You're right. I think that should be probably be removed. > > > > > > Does the following patch also resolve the problem for you? > > > > Yes, the patch works great. Thanks! I assume you are going to commit > > that to OpenSSH? DES, can you import this as a vendor fix on the > > vendor branch? > > Yes, it has been committed and will be in 4.4p1. > > Thanks again. Thanks for the review and fix. -- John Baldwin From bob at proulx.com Sun Sep 17 13:37:25 2006 From: bob at proulx.com (Bob Proulx) Date: Sat, 16 Sep 2006 21:37:25 -0600 Subject: wishlist: option to cause /bin/sh to be used instead of user's shell Message-ID: <20060917033725.GA5512@dementia.proulx.com> SSH, like RSH before it, invokes a command using the user's shell as specified in the passwd file. In a mixed shell environment with some logins csh-like and some sh-like that is sometimes very difficult to handle. (No, I am not fond of csh.) If I could force a single shell everywhere of course that would be preferable but sometimes I have no control over it. I have often wanted an option that would force ssh to invoke the command using /bin/sh regardless of the user's configured shell. The best that I can do right now is to pipe the commands into shell. echo echo some command | ssh example.com /bin/sh That works very well when I don't need to also use the stdin for something else. But if I do need stdin for something else then this workaround breaks down. Is there any possibility of getting an option added to ssh such that it will use a standard shell on all platforms regardless of the user's configured shell? ssh -oCommandShell=/bin/sh example.com "my command here" But maybe there is already a way to do this and I just have not been able to figure it out? This problem finally caused me enough trouble that I decided I would need to ask for help. Thanks Bob -- Bob Proulx http://www.proulx.com/~bob/ From dkg-openssh.com at fifthhorseman.net Sun Sep 17 14:03:19 2006 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 17 Sep 2006 00:03:19 -0400 Subject: wishlist: option to cause /bin/sh to be used instead of user's shell In-Reply-To: <20060917033725.GA5512@dementia.proulx.com> References: <20060917033725.GA5512@dementia.proulx.com> Message-ID: <17676.51463.98765.673728@squeak.fifthhorseman.net> On September 16, bob at proulx.com said: > I have often wanted an option that would force ssh to invoke the > command using /bin/sh regardless of the user's configured shell. The > best that I can do right now is to pipe the commands into shell. > > echo echo some command | ssh example.com /bin/sh > > That works very well when I don't need to also use the stdin for > something else. But if I do need stdin for something else then this > workaround breaks down. when i have this situation, i often use: ssh example.com "/bin/sh -c 'some command'" which i can pipe stdin to without trouble. If stdin really needs to be coming from a pseudoterminal, i use: ssh -t example.com "/bin/sh -c 'some command'" In either case, the quoting can become a little bit hairy if the command is large, but for simplish commands, it works without much trouble. I'm sure someone else can produce a more reasonable quoting style. hth, --dkg From des at des.no Sun Sep 17 19:13:46 2006 From: des at des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Sun, 17 Sep 2006 11:13:46 +0200 Subject: sshd audit not happy with ssh1 and scp In-Reply-To: <20060917020207.GA31665@gate.dtucker.net> (Darren Tucker's message of "Sun, 17 Sep 2006 12:02:07 +1000") References: <200609141641.21243.jhb@freebsd.org> <20060916092302.GA13871@gate.dtucker.net> <200609160931.38065.jhb@freebsd.org> <20060917020207.GA31665@gate.dtucker.net> Message-ID: <86hcz6ua7p.fsf@dwp.des.no> Darren Tucker writes: > Cool. Out of curiousity, did you have to modify the audit support in > sshd, or did it work out of the box? It works right out of the box. DES -- Dag-Erling Sm?rgrav - des at des.no From hashproduct at gmail.com Mon Sep 18 01:47:49 2006 From: hashproduct at gmail.com (Matt McCutchen) Date: Sun, 17 Sep 2006 11:47:49 -0400 Subject: Proposed enhancement: forward controlling terminal Message-ID: <3bbc18d20609170847s52873070qecedadf2ac2882b7@mail.gmail.com> Dear OpenSSH people, It would be nice if SSH could forward the client's controlling terminal to the remote process in addition to the client's stdin and stdout. This way, if the user wants to run a process through sudo on the remote machine while redirecting stdin and stdout locally (ssh B sudo foo out), sudo would be able to read a password from the user. Ditto if the process is invoked through two steps of SSH (ssh B ssh C foo out). Similarly, rsync over SSH would work properly with --rsync-path="sudo rsync" or --rsh="ssh B ssh". See this thread on the rsync mailing list: http://lists.samba.org/archive/rsync/2006-September/016284.html Matt From bob at proulx.com Mon Sep 18 03:05:07 2006 From: bob at proulx.com (Bob Proulx) Date: Sun, 17 Sep 2006 11:05:07 -0600 Subject: wishlist: option to cause /bin/sh to be used instead of user's shell In-Reply-To: <17676.51463.98765.673728@squeak.fifthhorseman.net> References: <20060917033725.GA5512@dementia.proulx.com> <17676.51463.98765.673728@squeak.fifthhorseman.net> Message-ID: <20060917170507.GA5218@dementia.proulx.com> Daniel Kahn Gillmor wrote: > when i have this situation, i often use: > ssh example.com "/bin/sh -c 'some command'" > ... > In either case, the quoting can become a little bit hairy if the > command is large, but for simplish commands, it works without much > trouble. I'm sure someone else can produce a more reasonable quoting > style. Thank you for that suggestion. And another kind person also made that suggestion offlist. That *almost* works. The problem is that if the login shell quoting rules are different than a sh-like shell's quoting rules (which are tedious enough) then you still have to know the rules for that particular shell to wrap everything in the first layer of non-standard shell quoting for that host to eventually make it into the standard shell. Primarily I am talking about /bin/tcsh versus /bin/bash and /bin/ksh in my environment. Off the top of my head thinking of csh string quoting I think I can quote everything sufficiently to make it work in both of those shells. But I find this to still be quite hard to get right in practice. In fact, I am not sure that I ever have been completely successful when used by my clever users. They are more clever than I am. Even if the shell is a standard /bin/sh everywhere the quoting rules are complex. For example using single-quotes means that you cannot ever have a single-quote in the argument list because sh-like shells do not allow a single-quote to be escaped by any method inside a single-quoted string. Therefore I prefer to use double-quotes because it is possible to escape embedded double-quotes within a double-quoted string. It is also possible to programmatically escape shell characters with things like perl/ruby modules[1]. When I don't need stdin just piping the commands to be run to the remote shell is easiest. cat <<'EOF' | ssh example.com /bin/sh export foo=bar echo $foo EOF bar My best method right now when I need stdin available is to use a temporary file. For your amusement here is an example. SERVER=example.com trap 'rm -f $TMPFILE; test -n "$RTMPFILE" && ssh -oBatchMode=yes -q -n $SERVER rm -f $RTMPFILE' EXIT TMPFILE=$(mktemp /tmp/foo.XXXXXX) || exit 1 RTMPFILE=$(ssh -oBatchMode=yes -q -n -T $SERVER mktemp /tmp/foo.XXXXXX) || exit 1 cat >$TMPFILE <<'EOF' echo "O'Hare" EOF scp -oBatchMode=yes -q $TMPFILE $SERVER:$RTMPFILE < /dev/null || exit 1 ssh -oBatchMode=yes -q $SERVER sh $RTMPFILE exit $? That works pretty well. The biggest real issue my users saw with this is that it is slower because of the multiple ssh invocations to the remote host. When I started on this problem ssh 3.8 was current and there was no ssh connection sharing available. Now that 4.2 has nice connection sharing features I might be able to make the performance with a temporary file good enough. That still requires a persistent connection however. And at this moment in time many stable distributions have yet to release again and so they still have the older ssh 3.x without connection sharing until their next release. Just the same let me suggest, wouldn't it be nice to have an option to always be able to use a standard shell on the remote system? :-) Thanks Bob [1] See perl's String::ShellQuote for one possibility. But I think this is still very tedious. An attempt at printing O'Hare's $s: perl -MString::ShellQuote -le "print shell_quote(\"O'Hare's \\\$s\");" 'O'\''Hare'\''s $s' perl -MString::ShellQuote -le 'print shell_quote("O'"'"'Hare'"'"'s \$s");' 'O'\''Hare'\''s $s' Trying to use this process to quote something for remote execution can make scripts quite hard to read. From dtucker at zip.com.au Mon Sep 18 09:53:07 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 18 Sep 2006 09:53:07 +1000 Subject: Proposed enhancement: forward controlling terminal In-Reply-To: <3bbc18d20609170847s52873070qecedadf2ac2882b7@mail.gmail.com> References: <3bbc18d20609170847s52873070qecedadf2ac2882b7@mail.gmail.com> Message-ID: <450DDFE3.3010201@zip.com.au> Matt McCutchen wrote: > Dear OpenSSH people, > > It would be nice if SSH could forward the client's controlling > terminal to the remote process in addition to the client's stdin and > stdout. This way, if the user wants to run a process through sudo on > the remote machine while redirecting stdin and stdout locally (ssh B > sudo foo out), sudo would be able to read a password from the > user. Ditto if the process is invoked through two steps of SSH (ssh B > ssh C foo out). Similarly, rsync over SSH would work properly > with --rsync-path="sudo rsync" or --rsh="ssh B ssh". See this thread > on the rsync mailing list: How would that be different from "ssh -t server" and "ssh -tt server" that have been in ssh(1) for a quite some time? -- 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 hashproduct at gmail.com Mon Sep 18 10:12:19 2006 From: hashproduct at gmail.com (Matt McCutchen) Date: Sun, 17 Sep 2006 20:12:19 -0400 Subject: Proposed enhancement: forward controlling terminal In-Reply-To: <450DDFE3.3010201@zip.com.au> References: <3bbc18d20609170847s52873070qecedadf2ac2882b7@mail.gmail.com> <450DDFE3.3010201@zip.com.au> Message-ID: <3bbc18d20609171712pcec3241k615be03fa275b340@mail.gmail.com> On 9/17/06, Darren Tucker wrote: > How would that be different from "ssh -t server" and "ssh -tt server" > that have been in ssh(1) for a quite some time? I should see "foo" on my terminal when I run the following: ssh (options) localhost 'echo foo >/dev/tty' /dev/null But I get: $ ssh localhost 'echo foo >/dev/tty' /dev/null bash: /dev/tty: No such device or address $ ssh -t localhost 'echo foo >/dev/tty' /dev/null Pseudo-terminal will not be allocated because stdin is not a terminal. bash: /dev/tty: No such device or address $ ssh -tt localhost 'echo foo >/dev/tty' /dev/null tcgetattr: Inappropriate ioctl for device Connection to localhost closed. I'm using Fedora Core 5's openssh-4.3p2-4 . Matt From sfk1 at bigfoot.com Mon Sep 18 21:14:28 2006 From: sfk1 at bigfoot.com (Stefan Krah) Date: Mon, 18 Sep 2006 13:14:28 +0200 Subject: BSD Auth: set child environment variables requested by login script [PATCH] Message-ID: <20060918111428.GA328@mail.bytereef.org> Hello, in the BSD Authentication system the login script can request environment variables to be set/unset. The call to auth_close() in auth-passwd.c does change the current environment, but those changes are lost for the child environment. It would be really useful to add some kind of mechanism to get those changes into the child environment. I've added two possible solutions. Both solutions only deal with setenv requests. Please tell me what you think and if there's a chance of adding the feature. Stefan Krah ###################################### Easy way to prepare for testing: ###################################### Index: libexec/login_passwd/login.c =================================================================== RCS file: /cvs/src/libexec/login_passwd/login.c,v retrieving revision 1.8 diff -u -r1.8 login.c --- libexec/login_passwd/login.c 14 Apr 2005 18:33:42 -0000 1.8 +++ libexec/login_passwd/login.c 18 Sep 2006 10:32:00 -0000 @@ -107,6 +107,9 @@ exit(1); } + fprintf(back, BI_SETENV " X_BSD_AUTH_SOME_RESOURCE %d\n", 1024); + fprintf(back, BI_SETENV " TESTVAR %s\n", "bar"); + /* * Read password, either as from the terminal or if the * response mode is active from the caller program. ###################################### Solution 1: ###################################### This is a minimal fix that just whitelists variables starting with X_BSD_AUTH: Index: usr.bin/ssh/auth-bsdauth.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth-bsdauth.c,v retrieving revision 1.10 diff -u -r1.10 auth-bsdauth.c --- usr.bin/ssh/auth-bsdauth.c 3 Aug 2006 03:34:41 -0000 1.10 +++ usr.bin/ssh/auth-bsdauth.c 18 Sep 2006 09:32:20 -0000 @@ -24,6 +24,7 @@ */ #include +#include #ifdef BSD_AUTH #include "xmalloc.h" @@ -32,10 +33,36 @@ #include "auth.h" #include "log.h" #include "buffer.h" +#include "channels.h" +#include "session.h" #ifdef GSSAPI #include "ssh-gss.h" #endif #include "monitor_wrap.h" + +/* + * Set child environment variables starting with "X_BSD_AUTH". + * After the call to auth_close(), these variables are in the + * current environment if the login script has requested them. + */ +void +bsdauth_child_set_env(char ***envp, u_int *envsizep) +{ + extern char **environ; + char name[8*1024]; /* MAXSPOOLSIZE in auth_session_t */ + char *value; + u_int i, namelen; + + for (i = 0; environ[i] != NULL; i++) { + namelen = strcspn(environ[i], "="); + if (namelen + 1 > sizeof(name)) + continue; + snprintf(name, namelen + 1, "%s", environ[i]); + value = environ[i] + namelen + 1; + if (strncmp(name, "X_BSD_AUTH", 10) == 0) + child_set_env(envp, envsizep, name, value); + } +} static void * bsdauth_init_ctx(Authctxt *authctxt) Index: usr.bin/ssh/auth.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth.h,v retrieving revision 1.58 diff -u -r1.58 auth.h --- usr.bin/ssh/auth.h 18 Aug 2006 09:15:20 -0000 1.58 +++ usr.bin/ssh/auth.h 18 Sep 2006 09:32:23 -0000 @@ -123,6 +123,10 @@ void krb5_cleanup_proc(Authctxt *authctxt); #endif /* KRB5 */ +#ifdef BSD_AUTH +void bsdauth_child_set_env(char ***envp, u_int *envsizep); +#endif + void do_authentication(Authctxt *); void do_authentication2(Authctxt *); Index: usr.bin/ssh/session.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/session.c,v retrieving revision 1.219 diff -u -r1.219 session.c --- usr.bin/ssh/session.c 29 Aug 2006 10:40:19 -0000 1.219 +++ usr.bin/ssh/session.c 18 Sep 2006 09:32:57 -0000 @@ -844,6 +844,9 @@ child_set_env(&env, &envsize, "KRB5CCNAME", s->authctxt->krb5_ticket_file); #endif +#ifdef BSD_AUTH + bsdauth_child_set_env(&env, &envsize); +#endif if (auth_sock_name != NULL) child_set_env(&env, &envsize, SSH_AUTHSOCKET_ENV_NAME, auth_sock_name); ###################################### Solution 2: ###################################### This one saves the current environment and lets auth_close() do the changes on an empty environment. All setenv requests are honored, unsetenv requests are lost. Index: usr.bin/ssh/auth-bsdauth.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth-bsdauth.c,v retrieving revision 1.10 diff -u -r1.10 auth-bsdauth.c --- usr.bin/ssh/auth-bsdauth.c 2006/08/03 03:34:41 1.10 +++ usr.bin/ssh/auth-bsdauth.c 2006/09/18 09:35:52 @@ -24,6 +24,7 @@ */ #include +#include #ifdef BSD_AUTH #include "xmalloc.h" @@ -32,10 +33,96 @@ #include "auth.h" #include "log.h" #include "buffer.h" +#include "channels.h" +#include "session.h" #ifdef GSSAPI #include "ssh-gss.h" #endif #include "monitor_wrap.h" + +/* copy the current environment. */ +static char ** +bsdauth_env_copy(void) +{ + extern char **environ; + char **copy, *x; + u_int i, len; + + for (i = 0; environ[i] != NULL; i++) + ; + copy = xmalloc((i + 1) * sizeof(char *)); + + for (i = 0; environ[i] != NULL; i++) { + len = strlen(environ[i]); + x = xmalloc(len + 1); + strncpy(x, environ[i], len + 1); + copy[i] = x; + } + copy[i] = NULL; + + return copy; +} + +/* free the copy. */ +void +bsdauth_env_free(Authctxt *authctxt, char **env) +{ + u_int i; + + if (env != NULL && authctxt->auth_env_mod != NULL) { + for (i = 0; env[i] != NULL; i++) + xfree(env[i]); + xfree(env); + } +} + +/* + * Wrapper around auth_close(): auth_close() changes the current environment + * as requested by the login script. To catch the setenv requests, we save + * the current environment and let auth_close() do the changes on an empty + * environment. unsetenv requests are lost. + */ +int +auth_close_do_env(Authctxt *authctxt, auth_session_t *as) +{ + extern char **environ; + char **env_orig; + int ret; + + env_orig = bsdauth_env_copy(); + environ[0] = NULL; + + ret = auth_close(as); + + /* environ now contains all setenv changes done by auth_close(). */ + authctxt->auth_env_mod = environ; + environ = env_orig; + + return ret; +} + +/* modify the child environment according to login script requests. */ +void +bsdauth_child_mod_env(Authctxt *authctxt, char ***envp, u_int *envsizep) +{ + char **env_mod; + char name[8*1024]; /* MAXSPOOLSIZE in auth_session_t */ + char *value; + u_int i, namelen; + + env_mod = authctxt->auth_env_mod; + + if (env_mod != NULL) { + for (i = 0; env_mod[i] != NULL; i++) { + namelen = strcspn(env_mod[i], "="); + if (namelen + 1 > sizeof(name)) + continue; + snprintf(name, namelen + 1, "%s", env_mod[i]); + value = env_mod[i] + namelen + 1; + child_set_env(envp, envsizep, name, value); + } + } +} static void * bsdauth_init_ctx(Authctxt *authctxt) Index: usr.bin/ssh/auth-passwd.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth-passwd.c,v retrieving revision 1.40 diff -u -r1.40 auth-passwd.c --- usr.bin/ssh/auth-passwd.c 2006/08/03 03:34:41 1.40 +++ usr.bin/ssh/auth-passwd.c 2006/09/18 09:35:52 @@ -144,7 +144,7 @@ if (as == NULL) return (0); if (auth_getstate(as) & AUTH_PWEXPIRED) { - auth_close(as); + auth_close_do_env(authctxt, as); disable_forwarding(); authctxt->force_pwchange = 1; return (1); @@ -153,7 +153,7 @@ expire_checked = 1; warn_expiry(authctxt, as); } - return (auth_close(as)); + return (auth_close_do_env(authctxt, as)); } } #else Index: usr.bin/ssh/auth.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth.h,v retrieving revision 1.58 diff -u -r1.58 auth.h --- usr.bin/ssh/auth.h 2006/08/18 09:15:20 1.58 +++ usr.bin/ssh/auth.h 2006/09/18 09:35:53 @@ -61,6 +61,7 @@ void *kbdintctxt; #ifdef BSD_AUTH auth_session_t *as; + char **auth_env_mod; /* env changes requested by login script */ #endif #ifdef KRB5 krb5_context krb5_ctx; @@ -122,6 +123,12 @@ int auth_krb5_password(Authctxt *authctxt, const char *password); void krb5_cleanup_proc(Authctxt *authctxt); #endif /* KRB5 */ + +#ifdef BSD_AUTH +int auth_close_do_env(Authctxt *authctxt, auth_session_t *as); +void bsdauth_env_free(Authctxt *authctxt, char **env); +void bsdauth_child_mod_env(Authctxt *authctxt, char ***envp, u_int *envsizep); +#endif void do_authentication(Authctxt *); void do_authentication2(Authctxt *); Index: usr.bin/ssh/session.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/session.c,v retrieving revision 1.219 diff -u -r1.219 session.c --- usr.bin/ssh/session.c 2006/08/29 10:40:19 1.219 +++ usr.bin/ssh/session.c 2006/09/18 09:35:56 @@ -844,6 +844,9 @@ child_set_env(&env, &envsize, "KRB5CCNAME", s->authctxt->krb5_ticket_file); #endif +#ifdef BSD_AUTH + bsdauth_child_mod_env(s->authctxt, &env, &envsize); +#endif if (auth_sock_name != NULL) child_set_env(&env, &envsize, SSH_AUTHSOCKET_ENV_NAME, auth_sock_name); @@ -1128,6 +1131,10 @@ * Must take new environment into use so that .ssh/rc, * /etc/ssh/sshrc and xauth are run in the proper environment. */ +#ifdef BSD_AUTH + /* environ points to xmalloc'd memory. */ + bsdauth_env_free(s->authctxt, environ); +#endif environ = env; #ifdef KRB5 From dtucker at zip.com.au Tue Sep 19 00:14:35 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 19 Sep 2006 00:14:35 +1000 Subject: [openssh-unix-dev] Testing for the 4.4p1 release In-Reply-To: <200609020114.k821Epjn089336@fire.its.uiowa.edu> References: <200609020114.k821Epjn089336@fire.its.uiowa.edu> Message-ID: <450EA9CB.2060103@zip.com.au> Hi again. David Bronder wrote: > Damien Miller wrote: >> The 4.4p1 release is approaching now, so we are now asking people to >> actively test snapshots or CVS and report back to the mailing list. > > [AIX 5.1 ML5, IBM VAC 6 compiler, openssh-SNAP-20060902] > > Fails to build. See below for details. Same result with a stripped > down configure line (just adding --with-zlib=/usr/local). [...] > I can provide full compile log, but didn't want to mail it to the list. > Here are some highlights. > > Lots of the following warnings: > > "/usr/include/usersec.h", line 625.32: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. > "/usr/include/usersec.h", line 626.34: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. > > Then for the last two files before failing: > > cc -qlanglvl=ansi -g -O3 -qstrict -I. -I. -I/local/admin/include -I/usr/local/include -DSSHDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/bin/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/bin/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/bin/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/etc/ssh\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty/sshd\" -DSSH_RAND_HELPER=\"/usr/local/bin/ssh-rand-helper\" -DHAVE_CONFIG_H -c packet.c > "/usr/include/usersec.h", line 625.32: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. > "/usr/include/usersec.h", line 626.34: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. > "packet.c", line 162.12: 1506-010 (E) Macro TAILQ_HEAD invoked with a null argument for parameter name. > cc -qlanglvl=ansi -g -O3 -qstrict -I. -I. -I/local/admin/include -I/usr/local/include -DSSHDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/bin/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/bin/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/bin/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/etc/ssh\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty/sshd\" -DSSH_RAND_HELPER=\"/usr/local/bin/ssh-rand-helper\" -DHAVE_CONFIG_H -c readpass.c > "/usr/include/usersec.h", line 625.32: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. > "/usr/include/usersec.h", line 626.34: 1506-310 (I) The type "struct aud_rec" was introduced in a parameter list, and will go out of scope at the end of the function declaration or definition. I have just committed a change to configure that should work around that by removing the "-qlanglvl=ansi" if it finds the compiler won't let macros be redefined. (Not ideal, but it should work.) The changes will be in snap 20060919 and later. I think the "struct aud_rec" ones were a side effect of the compiler flags, but if you see them again (they'll only appear in port-aix.c now) then please let me know. > "/usr/include/paths.h", line 50.9: 1506-213 (S) Macro name _PATH_BSHELL cannot be redefined. > "/usr/include/paths.h", line 50.9: 1506-358 (I) "_PATH_BSHELL" is defined on line 322 of defines.h. > "/usr/include/paths.h", line 52.9: 1506-213 (S) Macro name _PATH_CSHELL cannot be redefined. > "/usr/include/paths.h", line 52.9: 1506-358 (I) "_PATH_CSHELL" is defined on line 325 of defines.h. > "/usr/include/paths.h", line 57.9: 1506-213 (S) Macro name _PATH_MAILDIR cannot be redefined. > "/usr/include/paths.h", line 57.9: 1506-358 (I) "_PATH_MAILDIR" is defined on line 359 of defines.h. Those will probably still be there but as warnings. We'll see what we can do to clean those up after the release. 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 david-bronder at uiowa.edu Tue Sep 19 08:57:38 2006 From: david-bronder at uiowa.edu (David Bronder) Date: Mon, 18 Sep 2006 17:57:38 -0500 (CDT) Subject: Testing for the 4.4p1 release In-Reply-To: <450EA9CB.2060103@zip.com.au> from "Darren Tucker" at Sep 19, 2006 12:14:35 AM Message-ID: <200609182257.k8IMvc4q099364@fire.its.uiowa.edu> Darren Tucker wrote: > > David Bronder wrote: > > Damien Miller wrote: > >> The 4.4p1 release is approaching now, so we are now asking people to > >> actively test snapshots or CVS and report back to the mailing list. > > > > [AIX 5.1 ML5, IBM VAC 6 compiler, openssh-SNAP-20060902] > > > > Fails to build. See below for details. Same result with a stripped > > down configure line (just adding --with-zlib=/usr/local). > [...] > > I have just committed a change to configure that should work around that > by removing the "-qlanglvl=ansi" if it finds the compiler won't let > macros be redefined. (Not ideal, but it should work.) > > The changes will be in snap 20060919 and later. I think the "struct > aud_rec" ones were a side effect of the compiler flags, but if you see > them again (they'll only appear in port-aix.c now) then please let me know. Just gave it another spin with openssh-SNAP-20060919 and it looks OK. The "struct aud_rec" messages are gone, and the regression tests passed. > > "/usr/include/paths.h", line 50.9: 1506-213 (S) Macro name _PATH_BSHELL cannot be redefined. > > "/usr/include/paths.h", line 50.9: 1506-358 (I) "_PATH_BSHELL" is defined on line 322 of defines.h. > > "/usr/include/paths.h", line 52.9: 1506-213 (S) Macro name _PATH_CSHELL cannot be redefined. > > "/usr/include/paths.h", line 52.9: 1506-358 (I) "_PATH_CSHELL" is defined on line 325 of defines.h. > > "/usr/include/paths.h", line 57.9: 1506-213 (S) Macro name _PATH_MAILDIR cannot be redefined. > > "/usr/include/paths.h", line 57.9: 1506-358 (I) "_PATH_MAILDIR" is defined on line 359 of defines.h. > > Those will probably still be there but as warnings. We'll see what we > can do to clean those up after the release. The macro warnings were still there, but as you said, just indicating the macros had been redefined (rather than not being able to redefine them). Thanks again! -- Hello World. David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bronder at uiowa.edu From girish1729 at gmail.com Tue Sep 19 11:15:29 2006 From: girish1729 at gmail.com (Girish Venkatachalam) Date: Tue, 19 Sep 2006 06:45:29 +0530 Subject: weird DH problems Message-ID: <20060919011529.GB27552@lakshmi.susmita.org> Dear Damien and Darren, I recently ran into a really weird and spooky ssh problem. My brain is going to mad trying to explain that it is a hardware issue since on two machines, one of which is a Celeon 2.8 Ghz with 1 GB RAM, another is a Xeon 4 CPU box with 3 Gig RAM and I guess 3 Ghz or something, both of which are running FreeBSD 6.1 with latest version of OpenSSH bundled with it. The version string is SSH-2.0-OpenSSH_4.2p1 FreeBSD-2005090 I did a ssh -vvv to them and the problem occurs in kex. And it is absolutely random. Here is some sample output. 1) debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS Write failed: Broken pipe 2) debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent Read from socket failed: Connection reset by peer 3) debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4 debug1: SSH2_MSG_KEXINIT sent Read from socket failed: Connection reset by peer At the same time sometimes I am able to connect. I tried this from my Debian, FreeBSD and OpenBSD boxes with different SSH versions. I looked at the code and I can see certain fatal() calls in the kex code which I believe is shared bet server and client. What is causing the server to die? What is the real issue? Thanks. regards, Girish -- Whenever people agree with me I always feel I am wrong. - Oscar Wilde From dtucker at zip.com.au Tue Sep 19 14:21:33 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 19 Sep 2006 14:21:33 +1000 Subject: weird DH problems In-Reply-To: <20060919011529.GB27552@lakshmi.susmita.org> References: <20060919011529.GB27552@lakshmi.susmita.org> Message-ID: <450F704D.2080508@zip.com.au> Girish Venkatachalam wrote: > Dear Damien and Darren, > > I recently ran into a really weird and spooky ssh problem. My brain > is going to mad trying to explain that it is a hardware issue since on two > machines, one of which is a Celeon 2.8 Ghz with 1 GB RAM, another is a > Xeon 4 CPU box with 3 Gig RAM and I guess 3 Ghz or something, both of > which are running FreeBSD 6.1 with latest version of OpenSSH bundled > with it. The version string is > SSH-2.0-OpenSSH_4.2p1 FreeBSD-2005090 > > I did a ssh -vvv to them and the problem occurs in kex. And it is > absolutely random. Here is some sample output. > > 1) debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > Write failed: Broken pipe It's not clear from you're describing the client(s) or server(s) above, but the server in this case doesn't happen to be an UltraSPARC does it? If so, what version of OpenSSL does it have? -- 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 Tue Sep 19 15:02:07 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 19 Sep 2006 15:02:07 +1000 Subject: weird DH problems In-Reply-To: <20060919044747.GA31524@lakshmi.susmita.org> References: <20060919011529.GB27552@lakshmi.susmita.org> <450F704D.2080508@zip.com.au> <20060919044747.GA31524@lakshmi.susmita.org> Message-ID: <450F79CF.4040008@zip.com.au> Girish Venkatachalam wrote: [...] > Sorry Darren for the confusion. Both machines running FreeBSD are the > servers and the sshd on the server side is dying. I have mentioned > above the architectures, none of them are UltraSparc. > > Is there something wrong with /dev/*random? Dunno, but I suspect not. > I have tried connecting from FreeBSD itself, OpenBSD and Debian > GNU/linux asssh clients. And all of them have problems at different > times. And these clients of course are running at my home and they are > old crappy i386 boxes. I dont think there is any problem with the > client part. You really need to see what's happening on the server side (normally I'd suggest running the server in debug mode, but since it's intermittent you would probably need to bump up the LogLevel and grep out the relevant session from the log). Does the problem occur with a vanilla OpenSSH built from the source on openssh.com? I'm pretty sure FreeBSD make a number of changes but I don't know what they are. They should be the first point of call for problems with the binaries they supply. -- 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 girish1729 at gmail.com Tue Sep 19 14:47:47 2006 From: girish1729 at gmail.com (Girish Venkatachalam) Date: Tue, 19 Sep 2006 10:17:47 +0530 Subject: weird DH problems In-Reply-To: <450F704D.2080508@zip.com.au> References: <20060919011529.GB27552@lakshmi.susmita.org> <450F704D.2080508@zip.com.au> Message-ID: <20060919044747.GA31524@lakshmi.susmita.org> On Tue, Sep 19, 2006 at 02:21:33PM +1000, Darren Tucker wrote: |Girish Venkatachalam wrote: |>Dear Damien and Darren, |> |>I recently ran into a really weird and spooky ssh problem. My brain |>is going to mad trying to explain that it is a hardware issue since on two |>machines, one of which is a Celeon 2.8 Ghz with 1 GB RAM, another is a |>Xeon 4 CPU box with 3 Gig RAM and I guess 3 Ghz or something, both of |>which are running FreeBSD 6.1 with latest version of OpenSSH bundled |>with it. The version string is |>SSH-2.0-OpenSSH_4.2p1 FreeBSD-2005090 |> |>I did a ssh -vvv to them and the problem occurs in kex. And it is |>absolutely random. Here is some sample output. |> |>1) debug1: SSH2_MSG_NEWKEYS sent |>debug1: expecting SSH2_MSG_NEWKEYS |>Write failed: Broken pipe | |It's not clear from you're describing the client(s) or server(s) above, |but the server in this case doesn't happen to be an UltraSPARC does it? | If so, what version of OpenSSL does it have? | Sorry Darren for the confusion. Both machines running FreeBSD are the servers and the sshd on the server side is dying. I have mentioned above the architectures, none of them are UltraSparc. Is there something wrong with /dev/*random? I have tried connecting from FreeBSD itself, OpenBSD and Debian GNU/linux asssh clients. And all of them have problems at different times. And these clients of course are running at my home and they are old crappy i386 boxes. I dont think there is any problem with the client part. I would have loved u to actually take a look at it urself but the machines do not actually belong to me and that is the reason I am not able to make them available to you. However if you insist I can give you the IPs and you can try connecting. What could be the problem? Any clues? Please tell me if this is fixable at all. I wonder what more I can do. :-) Oh OpenSSL was my first suspicion. ldd /usr/bin/ssh /usr/bin/ssh: libcrypto.so.4 => /lib/libcrypto.so.4 (0x280a7000) libutil.so.5 => /lib/libutil.so.5 (0x28199000) libz.so.3 => /lib/libz.so.3 (0x281a5000) libcrypt.so.3 => /lib/libcrypt.so.3 (0x281b5000) libc.so.6 => /lib/libc.so.6 (0x281cd000) I assure you my fullest cooperation in clearing this up. regards, Girish From girish1729 at gmail.com Tue Sep 19 15:57:58 2006 From: girish1729 at gmail.com (Girish Venkatachalam) Date: Tue, 19 Sep 2006 11:27:58 +0530 Subject: weird DH problems In-Reply-To: <450F79CF.4040008@zip.com.au> References: <20060919011529.GB27552@lakshmi.susmita.org> <450F704D.2080508@zip.com.au> <20060919044747.GA31524@lakshmi.susmita.org> <450F79CF.4040008@zip.com.au> Message-ID: <20060919055758.GA8475@lakshmi.susmita.org> On Tue, Sep 19, 2006 at 03:02:07PM +1000, Darren Tucker wrote: |Girish Venkatachalam wrote: |[...] |>Sorry Darren for the confusion. Both machines running FreeBSD are the |>servers and the sshd on the server side is dying. I have mentioned |>above the architectures, none of them are UltraSparc. |> |> Is there something wrong with /dev/*random? | |Dunno, but I suspect not. | |> I have tried connecting from FreeBSD itself, OpenBSD and Debian |> GNU/linux asssh clients. And all of them have problems at different |> times. And these clients of course are running at my home and they are |> old crappy i386 boxes. I dont think there is any problem with the |> client part. | |You really need to see what's happening on the server side (normally I'd |suggest running the server in debug mode, but since it's intermittent |you would probably need to bump up the LogLevel and grep out the |relevant session from the log). | |Does the problem occur with a vanilla OpenSSH built from the source on |openssh.com? I'm pretty sure FreeBSD make a number of changes but I |don't know what they are. They should be the first point of call for |problems with the binaries they supply. In that case let us just move on. I could not run sshd in debug mode since I tried something and ended up killing it and getting myself locked out. Since it is not my machine I am also scared to just hack things. You are right in the stance that FreeBSD owes an explanation. But I wouldnt think they would diddle around with DH fields and stuff. Remote chance. I have not tried with vanilla OpenSSH. If nothing comes to your mind, then let us just leave it and move on. This will be one of those unsolved Sherlock Holmes mysteries. :-) regards, Girish -- Whenever people agree with me I always feel I am wrong. - Oscar Wilde From dtucker at zip.com.au Tue Sep 19 16:56:10 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 19 Sep 2006 16:56:10 +1000 Subject: weird DH problems In-Reply-To: <20060919055758.GA8475@lakshmi.susmita.org> References: <20060919011529.GB27552@lakshmi.susmita.org> <450F704D.2080508@zip.com.au> <20060919044747.GA31524@lakshmi.susmita.org> <450F79CF.4040008@zip.com.au> <20060919055758.GA8475@lakshmi.susmita.org> Message-ID: <450F948A.8080806@zip.com.au> Girish Venkatachalam wrote: > On Tue, Sep 19, 2006 at 03:02:07PM +1000, Darren Tucker wrote: [...] > |Does the problem occur with a vanilla OpenSSH built from the source on > |openssh.com? I'm pretty sure FreeBSD make a number of changes but I > |don't know what they are. They should be the first point of call for > |problems with the binaries they supply. > > In that case let us just move on. I could not run sshd in debug mode > since I tried something and ended up killing it and getting myself > locked out. Since it is not my machine I am also scared to just hack things. Did sshd on the server log anything when the connection died, or leave a core dump? You can run sshd on another port without affecting the production one on port 22 (eg "/path/to/sshd -p 222"). You can also bump the debug level while leaving it running as a daemon as long as you're careful (use sshd -t to check your config, then send the running master sshd process a SIGHUP). [...] > But I wouldnt think they would diddle around with DH fields and > stuff. Remote chance. It might be something only loosely related to ssh. Last time I saw symptoms such as you describe, the root cause was a problem in OpenSSL's SPARC bignum assembler routine that caused intermittent segfaults (hence my questions earlier about what the platform was). In that particular case, rebuilding OpenSSL without assembler optimization resolved the problem. Another somewhat similar ocurrence during kbdint was caused by glibc attempting to write to a segment mapped read-only when a process tried to do a name lookup in a chroot and there was no "lib" directory in the chroot. In these e [from earlier] > You are right in the stance that FreeBSD owes an explanation. It's not that they owe you anything (indeed, unless you're paying them for support they don't) but they are in a much better position to be able to track down and/or reproduce this than we are. If you or they have indications that it really is a problem with OpenSSH then we'll do what we can to help. -- 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 svos at tellumat.com Wed Sep 20 18:21:13 2006 From: svos at tellumat.com (Stephan Vos) Date: Wed, 20 Sep 2006 10:21:13 +0200 Subject: Portability of OPENSSH to non-Linux ARM platform Message-ID: <433D65C238E6744E899F015203CA472F03B1AA15@frodo.tellumat.co.za> I am investigating options for our project to add SSH support to our ARM7 platform running UCOSII embedded OS (non-Linux). Would porting be possible? How difficult would it be? ********************************************************************** Relevant company disclaimers are available at the following addresses: Tellumat (Pty) Ltd e-mail: mailto:disclaimer at tellumat.com?Subject=Tellumat_Disclaimer Web: http://www.tellumat.com/email.aspx ********************************************************************** From carson at taltos.org Wed Sep 20 19:18:59 2006 From: carson at taltos.org (Carson Gaspar) Date: Wed, 20 Sep 2006 02:18:59 -0700 Subject: Portability of OPENSSH to non-Linux ARM platform In-Reply-To: <433D65C238E6744E899F015203CA472F03B1AA15@frodo.tellumat.co.za> References: <433D65C238E6744E899F015203CA472F03B1AA15@frodo.tellumat.co.za> Message-ID: <174A4F5A4E6CAB1E8756DC82@[192.168.1.160]> --On Wednesday, September 20, 2006 10:21 AM +0200 Stephan Vos wrote: > I am investigating options for our project to add SSH support to our > ARM7 platform running UCOSII embedded OS (non-Linux). > > Would porting be possible? > How difficult would it be? It looks like this doesn't have anything like a POSIX API, so porting OpenSSH would probably be _very_ difficult. -- Carson From bpsr77 at hotmail.com Thu Sep 21 23:50:59 2006 From: bpsr77 at hotmail.com (olle ollesson) Date: Thu, 21 Sep 2006 15:50:59 +0200 Subject: TimeZone in ls -lna listings Message-ID: Hi, I have a strange situation where when I get different timestamps depending on if a use ls -l or ls -ln: --------------- sftp> ls -l -rw-rw-rw- 1 0 0 39649 Sep 20 11:30 C20060920.1115-20060920.1130 sftp> ls -ln -rw------- 0 0 0 39649 Sep 20 13:30 C20060920.1115-20060920.1130 -------------- The machine is in timezone UTC+2. According to the sftp draft timestamps should be in UTC time (draft-ietf-secsh-filexfer-13.txt chapter 7.7). After looking in the code I found the difference that the when doing a numeric listin, the openssh client constructs the string shown while otherwise it is the server that builds up this string. My question is, when the OpenSSH sftp client constructs that string, does it compensate for the timezone difference, i.e. does it show the UTC time sent by the server or does it convert it to client local time. Or is it undefined? Apprarently, it is wery confusing to get see different listing depending on the flags to ls. Disclaimer, the server is a F-Secure implemenation. I haven't ruled out the possibility of an error in the server implementation. It might the case that the server is sending timestamps in local time rather than UTC time. 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 openmacnews at gmail.com Thu Sep 21 23:56:59 2006 From: openmacnews at gmail.com (OpenMacNews) Date: Thu, 21 Sep 2006 06:56:59 -0700 Subject: bug(let): openssh v4.3p2 'ok' out-of-box; 'configure' does not survive 'autoreconf' Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, building OPENSSH v4.3p2 on OSX 10.4.7, all's fine (config, nake, install, exec) out-of-the-box. so, to be clear, this is NOT a blocker, by any stretch ... that said, however ... if, instead of a don't-monkey-with-it build, prior to ./configure, i: autoreconf -i -f then, a subsequent: ./configure \ --prefix=/usr/local/openssh \ --sysconfdir=/var/security/ssh_homedir \ --mandir=/usr/local/man \ --with-pid-dir=/var/run \ --with-mantype=man \ --with-privsep-user=nobody \ --disable-suid-ssh \ --with-pam \ --with-random=/dev/urandom \ --with-md5-passwords \ --with-zlib=/usr/local \ --with-ssl-dir=/usr/local/ssl \ --with-default-path="/usr/local/openssh/bin:/usr/local/openssh/sbin:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin" \ --with-tcp-wrappers \ --with-4in6 fails at: ... checking for daemon... yes checking for getpagesize... yes checking whether snprintf correctly terminates long strings... yes checking whether snprintf can declare const char *fmt... yes checking for (overly) strict mkstemp... no ./configure: line 16377: syntax error near unexpected token `]]' ./configure: line 16377: `]])' checking in 'configure': ... 16373 else 16374 { { echo "$as_me:$LINENO: error: cannot run test program while cross compiling 16375 See \`config.log' for more details." >&5 16376 echo "$as_me: error: cannot run test program while cross compiling 16377 See \`config.log' for more details." >&2;} 16378 { (exit 1); exit 1; }; } 16379 fi 16380 ]]) ... stems from, in 'configure.ac': 1406 dnl see whether mkstemp() requires XXXXXX 1407 if test "x$ac_cv_func_mkdtemp" = "xyes" ; then 1408 AC_MSG_CHECKING([for (overly) strict mkstemp]) 1409 AC_RUN_IFELSE( 1410 [AC_LANG_SOURCE([[ 1411 #include 1412 main() { char template[]="conftest.mkstemp-test"; 1413 if (mkstemp(template) == -1) 1414 exit(1); 1415 unlink(template); exit(0); 1416 } - -> 1417 ]])], 1418 [ 1419 AC_MSG_RESULT(no) 1420 ], fyi, re: relevant (all?) my env: % autoreconf --version autoreconf (GNU Autoconf) 2.60 % glibtoolize --version libtoolize (GNU libtool) 1.5.22 % aclocal --version aclocal (GNU automake) 1.9.6 % automake --version automake (GNU automake) 1.9.6 % sed --version GNU sed version 4.1.5 % gcc -v Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5363.obj~28/src/configure - --disable-checking -enable-werror --prefix=/usr --mandir=/share/man - --enable-languages=c,objc,c++,obj-c++ - --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ - --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib - --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 - --target=powerpc-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5363) cheers, richard - -- /"\ \ / ASCII Ribbon Campaign X against HTML email, vCards / \ & micro$oft attachments [GPG] OpenMacNews at gmail dot com fingerprint: 50C9 1C46 2F8F DE42 2EDB D460 95F7 DDBD 3671 08C6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iEYEARECAAYFAkUSmi0ACgkQlffdvTZxCMaOcgCfQggj9JCFPbYw8Bh2lkNNyk5d t/kAoIRm11Ipxt3zOJBI6ND61mnT3gp7 =x/TY -----END PGP SIGNATURE----- From dtucker at zip.com.au Fri Sep 22 00:06:53 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 22 Sep 2006 00:06:53 +1000 Subject: bug(let): openssh v4.3p2 'ok' out-of-box; 'configure' does not survive 'autoreconf' In-Reply-To: References: Message-ID: <20060921140653.GA19901@gate.dtucker.net> On Thu, Sep 21, 2006 at 06:56:59AM -0700, OpenMacNews wrote: > building OPENSSH v4.3p2 on OSX 10.4.7, all's fine (config, nake, > install, exec) out-of-the-box. so, to be clear, this is NOT a blocker, > by any stretch ... > > that said, however ... > > if, instead of a don't-monkey-with-it build, prior to ./configure, i: > > autoreconf -i -f [...] > stems from, in 'configure.ac': > > 1406 dnl see whether mkstemp() requires XXXXXX > 1407 if test "x$ac_cv_func_mkdtemp" = "xyes" ; then > 1408 AC_MSG_CHECKING([for (overly) strict mkstemp]) > 1409 AC_RUN_IFELSE( > 1410 [AC_LANG_SOURCE([[ > 1411 #include > 1412 main() { char template[]="conftest.mkstemp-test"; > 1413 if (mkstemp(template) == -1) > 1414 exit(1); > 1415 unlink(template); exit(0); > 1416 } > - -> 1417 ]])], > 1418 [ > 1419 AC_MSG_RESULT(no) > 1420 ], Thanks, I believe this was caused by a missing bracket elsewhere that has already been fixed (configure.ac rev 1.343). Autoconf 2.59 didn't care but 2.60 does. Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/configure.ac,v retrieving revision 1.342 retrieving revision 1.343 diff -u -p -r1.342 -r1.343 --- configure.ac 24 Jun 2006 02:10:07 -0000 1.342 +++ configure.ac 27 Jun 2006 01:20:29 -0000 1.343 @@ -1623,6 +1623,7 @@ main(void) AC_MSG_RESULT(no) AC_DEFINE(BROKEN_GETADDRINFO) ], + [ AC_MSG_RESULT(cross-compiling, assuming no) ] ) -- 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 Sep 22 00:20:58 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 22 Sep 2006 00:20:58 +1000 Subject: Testing for the 4.4p1 release, round 2 Message-ID: <20060921142058.GA19334@gate.dtucker.net> Hi all. As most of you know, we are preparing OpenSSH 4.4p1 for release. We have had one round of testing and I would like to thank all who responded. We believe that most of the problems reported have been resolved. If you are so inclined, we would appreciate a quick retest to ensure that the fixed ones remain fixed and the working ones remain working. Of the problems identitified, I am only aware of two reported that I do not believe have been resolved: regress hangs on Redhat 7.3, reason unknown (maybe IPv6 related?): http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=115700350117023 regress failure on IRIX w/mipspro compiler (SSH protocol 1 only): http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=115716627223333 I believe the first is new, but the latter is not. Unfortunately we are not able to reproduce either. And now, a rerun of the earlier message with the details: Snapshots are available from http://www.mindrot.org/openssh_snap or from any of the mirrors listed on http://www.openssh.org/portable.html The latter page also includes instructions for checking out portable OpenSSH via anonymous CVS. This release contains many bugfixes and feature improvements. Here are some highlights: - Implemented conditional configuration in sshd_config(5) using the "Match" directive. This allows some configuration options to be selectively overridden if specific criteria (based on user, group, hostname and/or address) are met. So far a useful subset of post- authentication options are supported and more are expected to be added in future releases. - Added a "ForceCommand" directive to sshd_config(5). Similar to the command="..." option accepted in ~/.ssh/authorized_keys, this forces the execution of the specified command regardless of what the user requested. This is very useful in conjunction with the new "Match" option. - Add a "PermitOpen" directive to sshd_config(5). This mirrors the permitopen="..." authorized_keys option, allowing fine-grained control over the port-forwardings that a user is allowed to establish. - Add optional logging of transactions to sftp-server(8). - ssh(1) will now record port numbers for hosts stored in ~/.ssh/authorized_keys when a non-standard port has been requested. - Add an "ExitOnForwardFailure" options to cause ssh(1) to exit (with a non-zero exit code) when requested port forwardings could not be established. - Extend the sshd_config(5) "SubSystem" directive to allow the specification of commandline arguments. - Add optional support for SELinux, controlled using the --with-selinux configure option (experimental) - Add optional support for Solaris process contracts, enabled using the --with-solaris-contracts configure option (experimental) - Add support for Diffie-Hellman group exchange key agreement with a final hash of SHA256. - Fixed a lot of bugs. See http://bugzilla.mindrot.org/show_bug.cgi?id=1155 for an incomplete list (more in the ChangeLog) - Lots of manpage fixes and improvements - Many code cleanups, including: - Switching to safer memory allocation functions that avoid integer overflows when allocating arrays - Cleanups of header file usage (ongoing) - Fixes to leaks reported by the Coverity static analysis tool Running the regression tests supplied with Portable does not require installation, just run: $ ./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, including details of your platform, compiler and configure options. 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 gert at greenie.muc.de Fri Sep 22 01:20:46 2006 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 21 Sep 2006 17:20:46 +0200 Subject: Testing for the 4.4p1 release, round 2 In-Reply-To: <20060921142058.GA19334@gate.dtucker.net> References: <20060921142058.GA19334@gate.dtucker.net> Message-ID: <20060921152045.GD1140@greenie.muc.de> Hi, On Fri, Sep 22, 2006 at 12:20:58AM +1000, Darren Tucker wrote: > We believe that most of the problems reported have been resolved. > If you are so inclined, we would appreciate a quick retest to ensure > that the fixed ones remain fixed and the working ones remain working. NetBSD 2.0.3_STABLE, Sparc64, CVS as of "just now": everything works. 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 openmacnews at gmail.com Fri Sep 22 01:25:25 2006 From: openmacnews at gmail.com (OpenMacNews) Date: Thu, 21 Sep 2006 08:25:25 -0700 Subject: bug(let): openssh v4.3p2 'ok' out-of-box; 'configure' does not survive 'autoreconf' Message-ID: <3CCD6A0F4D88B021251C6E6F@F74D39FA044AA309EAEA14B9> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi darren, - -- On September 22, 2006 12:06:53 AM +1000 Darren Tucker wrote: >> autoreconf -i -f > [...] >> stems from, in 'configure.ac': ... >> - -> 1417 ]])], > Thanks, I believe this was caused by a missing bracket elsewhere that > has already been fixed (configure.ac rev 1.343). Autoconf 2.59 > didn't care but 2.60 does. 1st, yes i _have_ upgraded recently from autoconf 2.59 -> 2.60. 2nd, i can confirm that the fix '@@ -1623,6 +1623,7', per prior post, does the trick: openssh 4.3p2+autoconf2.60's configure/make/install/exec are, now, 'OK'. > BTW we're currently preparing for the 4.4 release, so it would probably be > better to test a snapshot and, building: SNAP-20060921 on OSX 10.4.7 (per my earlier post of env ...) *with*: autoreconf -i -f results in an error-free build of: ssh -V OpenSSH_4.4p1-snap20060921, OpenSSL 0.9.8c 05 Sep 2006 which, so far, seems to be 'behaving itself' ... thx! cheers, richard - -- /"\ \ / ASCII Ribbon Campaign X against HTML email, vCards / \ & micro$oft attachments [GPG] OpenMacNews at gmail dot com fingerprint: 50C9 1C46 2F8F DE42 2EDB D460 95F7 DDBD 3671 08C6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iEYEARECAAYFAkUSruUACgkQlffdvTZxCMaNJACdFPcNn9gQit7nPS5HfKgoEW/C vU8AniyWdulIDyGeSyojI535bZJQTuRK =4jwv -----END PGP SIGNATURE----- From rac at tenzing.org Fri Sep 22 03:36:08 2006 From: rac at tenzing.org (Roger Cornelius) Date: Thu, 21 Sep 2006 13:36:08 -0400 Subject: Testing for the 4.4p1 release, round 2 In-Reply-To: <20060921142058.GA19334@gate.dtucker.net> References: <20060921142058.GA19334@gate.dtucker.net> Message-ID: <20060921173608.GA4174@tenzing.org> On 09/22/2006 00:20, Darren Tucker wrote: > Hi all. > > As most of you know, we are preparing OpenSSH 4.4p1 for release. We have > had one round of testing and I would like to thank all who responded. > > We believe that most of the problems reported have been resolved. > If you are so inclined, we would appreciate a quick retest to ensure > that the fixed ones remain fixed and the working ones remain working. Builds and passes regressions on SCO OSR6 using native compiler. Builds and passes regressions on SCO OSR507 using gcc 3.4.4. On OSR507 w/native compiler, fails during configure with: "OpenSSH requires int64_t support. Contact your vendor or install an alternative compiler (I.E., GCC) before continuing." But I believe this is expected. -- Roger Cornelius rac at tenzing.org From dtucker at zip.com.au Fri Sep 22 09:27:42 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 22 Sep 2006 09:27:42 +1000 Subject: Testing for the 4.4p1 release, round 2 In-Reply-To: <20060921173608.GA4174@tenzing.org> References: <20060921142058.GA19334@gate.dtucker.net> <20060921173608.GA4174@tenzing.org> Message-ID: <20060921232742.GB10874@gate.dtucker.net> On Thu, Sep 21, 2006 at 01:36:08PM -0400, Roger Cornelius wrote: > On 09/22/2006 00:20, Darren Tucker wrote: > > Hi all. > > > > As most of you know, we are preparing OpenSSH 4.4p1 for release. We have > > had one round of testing and I would like to thank all who responded. > > > > We believe that most of the problems reported have been resolved. > > If you are so inclined, we would appreciate a quick retest to ensure > > that the fixed ones remain fixed and the working ones remain working. > > > Builds and passes regressions on SCO OSR6 using native compiler. > Builds and passes regressions on SCO OSR507 using gcc 3.4.4. Thanks. > On OSR507 w/native compiler, fails during configure with: > > "OpenSSH requires int64_t support. Contact your vendor or install > an alternative compiler (I.E., GCC) before continuing." > > But I believe this is expected. Yes, OpenSSH requires a native 64 bit type such as the "long" on LP64 systems or a 64 bit "long long" such as provided by most modern (and some not-so-modern) compilers. Without either of those, you will see that message and the build will fail. -- 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 santhi.amirta at gmail.com Fri Sep 22 19:04:43 2006 From: santhi.amirta at gmail.com (santhi) Date: Fri, 22 Sep 2006 14:34:43 +0530 Subject: Testing for the 4.4p1 release, round 2 References: <20060921142058.GA19334@gate.dtucker.net> Message-ID: <006b01c6de26$2be8abf0$2d0110ac@samco> Hi All, I have tested the openssh-SNAP-20060922 in the following HP-UX machines: 11.11 PA-RISC: ----------------- Configure and compile successfully. 11.23 IPF: ----------- Configure and compile successfully. HP-UX 11.00 PA-RISC: -------------------------- Configures successfully. But the compilation ends with the following error: cc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o -L. -Lopenbsd-compat/ -L/usr/local/SSH-LIBS-42/openssl-0.9.7i/ ssl-2.0/lib -L/usr/local/SSH-LIBS-42/tcp_wrappers_7.6/tcp_wrappers-2.0 -L/us r/local/SSH-LIBS-42/zlib-1.2.3/zlib-2.0/lib -L/usr/local/lib -lssh -lopenbs d-compat -lcrypto -lz -lnsl -lxnet -lsec -lgssapi_krb5 -lkrb5 -lk5crypto -l com_err /usr/ccs/bin/ld: Unsatisfied symbols: htonl (first referenced in ./libssh.a(canohost.o)) (code) *** Error exit code 1 Stop. Fix: ---- Include in canohost.c Again the compilation ends with the following error: cc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o -L. -Lopenbsd-compat/ -L/usr/local/SSH-LIBS-42/openssl-0.9.7i/ ssl-2.0/lib -L/usr/local/SSH-LIBS-42/tcp_wrappers_7.6/tcp_wrappers-2.0 -L/us r/local/SSH-LIBS-42/zlib-1.2.3/zlib-2.0/lib -L/usr/local/lib -lssh -lopenbs d-compat -lcrypto -lz -lnsl -lxnet -lsec -lgssapi_krb5 -lkrb5 -lk5crypto -l com_err /usr/ccs/bin/ld: Unsatisfied symbols: htonl (first referenced in ./libssh.a(packet.o)) (code) *** Error exit code 1 Stop Fix: ---- Include in packet.c Thanks, Santhi. ----- Original Message ----- From: "Darren Tucker" To: Sent: Thursday, September 21, 2006 7:50 PM Subject: Testing for the 4.4p1 release, round 2 > Hi all. > > As most of you know, we are preparing OpenSSH 4.4p1 for release. We have > had one round of testing and I would like to thank all who responded. > > We believe that most of the problems reported have been resolved. > If you are so inclined, we would appreciate a quick retest to ensure > that the fixed ones remain fixed and the working ones remain working. > > Of the problems identitified, I am only aware of two reported that I do > not believe have been resolved: > > regress hangs on Redhat 7.3, reason unknown (maybe IPv6 related?): > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=115700350117023 > > regress failure on IRIX w/mipspro compiler (SSH protocol 1 only): > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=115716627223333 > > I believe the first is new, but the latter is not. Unfortunately we are > not able to reproduce either. > > And now, a rerun of the earlier message with the details: > > Snapshots are available from http://www.mindrot.org/openssh_snap or > from any of the mirrors listed on http://www.openssh.org/portable.html > The latter page also includes instructions for checking out portable > OpenSSH via anonymous CVS. > > This release contains many bugfixes and feature improvements. Here > are some highlights: > > - Implemented conditional configuration in sshd_config(5) using the > "Match" directive. This allows some configuration options to be > selectively overridden if specific criteria (based on user, group, > hostname and/or address) are met. So far a useful subset of post- > authentication options are supported and more are expected to be > added in future releases. > - Added a "ForceCommand" directive to sshd_config(5). Similar to the > command="..." option accepted in ~/.ssh/authorized_keys, this forces > the execution of the specified command regardless of what the user > requested. This is very useful in conjunction with the new "Match" > option. > - Add a "PermitOpen" directive to sshd_config(5). This mirrors the > permitopen="..." authorized_keys option, allowing fine-grained > control over the port-forwardings that a user is allowed to > establish. > - Add optional logging of transactions to sftp-server(8). > - ssh(1) will now record port numbers for hosts stored in > ~/.ssh/authorized_keys when a non-standard port has been requested. > - Add an "ExitOnForwardFailure" options to cause ssh(1) to exit (with > a non-zero exit code) when requested port forwardings could not be > established. > - Extend the sshd_config(5) "SubSystem" directive to allow the > specification of commandline arguments. > - Add optional support for SELinux, controlled using the --with-selinux > configure option (experimental) > - Add optional support for Solaris process contracts, enabled using the > --with-solaris-contracts configure option (experimental) > - Add support for Diffie-Hellman group exchange key agreement with a > final hash of SHA256. > - Fixed a lot of bugs. See > http://bugzilla.mindrot.org/show_bug.cgi?id=1155 for an incomplete > list (more in the ChangeLog) > - Lots of manpage fixes and improvements > - Many code cleanups, including: > - Switching to safer memory allocation functions that avoid integer > overflows when allocating arrays > - Cleanups of header file usage (ongoing) > - Fixes to leaks reported by the Coverity static analysis tool > > Running the regression tests supplied with Portable does not require > installation, just run: > > $ ./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, including > details of your platform, compiler and configure options. > > 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. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From dtucker at zip.com.au Fri Sep 22 19:24:06 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 22 Sep 2006 19:24:06 +1000 Subject: Testing for the 4.4p1 release, round 2 In-Reply-To: <006b01c6de26$2be8abf0$2d0110ac@samco> References: <20060921142058.GA19334@gate.dtucker.net> <006b01c6de26$2be8abf0$2d0110ac@samco> Message-ID: <20060922092406.GA20311@gate.dtucker.net> On Fri, Sep 22, 2006 at 02:34:43PM +0530, santhi wrote: > Hi All, > > I have tested the openssh-SNAP-20060922 in the following HP-UX machines: Thanks. > HP-UX 11.00 PA-RISC: > -------------------------- > Configures successfully. But the compilation ends with the following error: [...] > /usr/ccs/bin/ld: Unsatisfied symbols: > htonl (first referenced in ./libssh.a(canohost.o)) (code) > > Fix: > ---- > Include in canohost.c [...] > Include in packet.c Both now fixed, thanks. Index: canohost.c =================================================================== RCS file: /var/cvs/openssh/canohost.c,v retrieving revision 1.70 diff -u -p -r1.70 canohost.c --- canohost.c 5 Aug 2006 02:39:39 -0000 1.70 +++ canohost.c 22 Sep 2006 09:21:46 -0000 @@ -18,6 +18,7 @@ #include #include +#include #include #include Index: packet.c =================================================================== RCS file: /var/cvs/openssh/packet.c,v retrieving revision 1.144 diff -u -p -r1.144 packet.c --- packet.c 21 Sep 2006 03:00:25 -0000 1.144 +++ packet.c 22 Sep 2006 09:21:46 -0000 @@ -50,6 +50,7 @@ #include #include #include +#include #include #include -- 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 Sep 23 09:14:00 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 23 Sep 2006 09:14:00 +1000 Subject: Testing for the 4.4p1 release In-Reply-To: <200609011914.k81JEnMi031660@ganymede.nas.nasa.gov> References: <200608302305.k7UN5CoD015796@ganymede.nas.nasa.gov> <200609011914.k81JEnMi031660@ganymede.nas.nasa.gov> Message-ID: <20060922231400.GA12917@gate.dtucker.net> On Fri, Sep 01, 2006 at 12:14:49PM -0700, Iain Morgan wrote: > I haven't had time to deal with the regression tests yet. The protocol 1 > tests always seem to be a problem with IRIX. (I reported this once quite > a while ago, but did not have the time to investigate.) In the past, > I've hacked the scripts to only test protocol 2, in which case > everything (that we care about) is fine. Hi. This is a long shot, but when you attempt to use Protocol 1, does the known_hosts file entry consist mainly of zeros? eg, If so, if you build OpenSSL 0.9.7k with the attached patch, does OpenSSL's "make tests" pass? If they don't, then it's probably some kind of problem with OpenSSL (rt #1395). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. -------------- next part -------------- Index: bntest.c =================================================================== RCS file: /home/dtucker/src/security/openssl/cvs/openssl-cvs/openssl/crypto/bn/bntest.c,v retrieving revision 1.55.2.5 diff -u -p -r1.55.2.5 bntest.c --- bntest.c 16 May 2005 01:26:02 -0000 1.55.2.5 +++ bntest.c 22 Sep 2006 13:07:38 -0000 @@ -230,6 +230,10 @@ int main(int argc, char *argv[]) if (!test_sqrt(out,ctx)) goto err; BIO_flush(out); + message(out,"BN_bn2dec"); + if (!test_bn2dec(out,ctx)) goto err; + BIO_flush(out); + BN_CTX_free(ctx); BIO_free(out); @@ -1096,6 +1100,28 @@ int test_sqrt(BIO *bp, BN_CTX *ctx) return ret; } +int test_bn2dec(BIO *bp, BN_CTX *ctx) + { + BIGNUM *a; + char buf[1024], *buf2; + int i, ret = 1; + + a = BN_new(); + for (i = -1000; i <= 1000; i++) { + sprintf(buf, "%d", i); + BN_dec2bn(&a, buf); + buf2 = BN_bn2dec(a); + if (strcmp(buf, buf2) != 0) { + fprintf(stderr,"bn2dec failed: '%s' '%s'!\n",buf,buf2); + OPENSSL_free(buf2); + return 0; + } + OPENSSL_free(buf2); + } + BN_free(a); + return 1; + } + int test_lshift(BIO *bp,BN_CTX *ctx,BIGNUM *a_) { BIGNUM *a,*b,*c,*d; From imorgan at nas.nasa.gov Sat Sep 23 10:15:57 2006 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 22 Sep 2006 17:15:57 -0700 (PDT) Subject: Testing for the 4.4p1 release In-Reply-To: <20060922231400.GA12917@gate.dtucker.net> from Darren Tucker at "Sep 23, 2006 09:14:00 am" Message-ID: <200609230015.k8N0FvcM010207@ganymede.nas.nasa.gov> Sometime ago, Darren Tucker wrote: > On Fri, Sep 01, 2006 at 12:14:49PM -0700, Iain Morgan wrote: > > I haven't had time to deal with the regression tests yet. The protocol 1 > > tests always seem to be a problem with IRIX. (I reported this once quite > > a while ago, but did not have the time to investigate.) In the past, > > I've hacked the scripts to only test protocol 2, in which case > > everything (that we care about) is fine. > > Hi. > > This is a long shot, but when you attempt to use Protocol 1, does the > known_hosts file entry consist mainly of zeros? eg, Yes! I guess I never took a close look at the entry, but it has several long sequneces of 0's in it. > > If so, if you build OpenSSL 0.9.7k with the attached patch, does > OpenSSL's "make tests" pass? If they don't, then it's probably some > kind of problem with OpenSSL (rt #1395). > > -- > 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. [Attachment, skipping...] Unfortunately, I have to leave in a few minutes and have not had a chance to test this. I'll get to it early on Monday and let you know. -- Iain Morgan From dtucker at zip.com.au Sat Sep 23 10:43:20 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 23 Sep 2006 10:43:20 +1000 Subject: Testing for the 4.4p1 release In-Reply-To: <200609230015.k8N0FvcM010207@ganymede.nas.nasa.gov> References: <20060922231400.GA12917@gate.dtucker.net> <200609230015.k8N0FvcM010207@ganymede.nas.nasa.gov> Message-ID: <20060923004320.GA14564@gate.dtucker.net> On Fri, Sep 22, 2006 at 05:15:57PM -0700, Iain Morgan wrote: > Sometime ago, Darren Tucker wrote: [...] > > This is a long shot, but when you attempt to use Protocol 1, does the > > known_hosts file entry consist mainly of zeros? eg, > > Yes! I guess I never took a close look at the entry, but it has several > long sequneces of 0's in it. Thanks. I have seen this reported on HP-UX and have now been able to reproduce it. I suspected it to be a problem with either OpenSSL or the compiler, and if you are able to reproduce it on another platform with another compiler then it makes OpenSSL much more likely as the culprit. I'll update the OpenSSL bug report. -- 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 alon.barlev at gmail.com Sun Sep 24 08:54:04 2006 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sun, 24 Sep 2006 01:54:04 +0300 Subject: [PATCH] Re: PKCS#11 support in OpenSSH 4.3p2 In-Reply-To: <1159049772.4021.84.camel@amy.samba4.abartlet.net> References: <447861A3.1080105@gmail.com> <1159049772.4021.84.camel@amy.samba4.abartlet.net> Message-ID: <200609240154.04880.alon.barlev@gmail.com> On Sunday 24 September 2006 01:16, Andrew Bartlett wrote: > On Sat, 2006-05-27 at 17:26 +0300, Alon Bar-Lev wrote: > > Hello, > > > > The version 0.11 of "PKCS#11 support in OpenSSH" is published. > > I cam across this patch recently, and I thought I might give you > some feedback, because I would like to see it integrated into > OpenSSH (I think it looks very useful in combination with > pam_pkcs11 system logins). Great! I am happy to receive any feed-back. I've been waiting to Damien Miller to have some free time. > > A valid X.509 certificate should exist on the token, without > > X.509 support it is exported as regular RSA key. There is a > > simple utility Timo Felbinger wrote > > (http://www.timof.qipc.org/x509toOpenSSH.c) that extracts > > ssh public key from X.509 certificate. > > Is there a reason that this isn't integrated into the patch? One reason is that I am not the author of this code. Another reason is that my OpenSSH developers did not comment on this patch, and since they did not, I don't know what to pack yet. > or does the ssh-keygen -D command 'do the right thing'? When the PKCS#11 support will be integrated, one of the command-line utilities will have this functionality, also none daemon implementation will be added. And I hope that the ssh-agent protocol will be modified to allow using the agent in none-gui environment. > > If you like X.509 support apply the X.509 (>=5.4) patch > > *AFTER* the PKCS#11 patch. > > I'm puzzled by how much X.509 code there is in this patch. It > seems that this could be broken into two patches, one initial > patch, and another to be applied with the X.509 patch. (I've > removed the X509 hook from the attached patch) This is the only difference: #if defined(SSH_PKCS11_X509_DISABLED) (*sshkey)->type = KEY_RSA; #else (*sshkey)->type = KEY_X509_RSA; (*sshkey)->x509 = x509; x509 = NULL; #endif There is no reason to remove anything. The patch will work with or without X.509 as expected. > That said, I think the handling of X.509 or ssh-rsa should be > better arranged. The documentation implies that I must set '-o > PubkeyAlgorithms=ssh-rsa' if I want to do 'normal' RSA > authentication if the X.509 patch is supported in the client. > Surely both should be offered, and it should be for the server to > decline? Not exactly. Roumen Petrov explained to me that there is somekind of limit in the negotiation stage. So the user should specify if he wishes downgrade. > Have you looked at how this integrates with pam_pkcs11? Is it > practical to have some of this inherit the fact that PAM has chosen > a certificate to log in with, and have this be the default cert? I think pam_pkcs11 is much too complex for users... And I don't like defaults... They tend to not work for most of people. I have a script that add my identities into the agent... It runs on logon, it is very nice... > Also, it seems to duplicate a lot of the smatcard code: Should > this be configured under SMARTCARD instead, and provide the > sc_open() etc interface? I think that all smartcard related code (opensc and javacard) be considered to be removed after a standard PKCS#11 implementation is added. > The same would apply for the user interface: I know we might need > to specify the provider, but should the user see the gory details, > when they just want to put in their smartcard? At least share that > with the existing smartcard support, please. I don't understand. > On matters of code, I note: > > The patch patches autogenerated files (ususally I would just advise > users that they need to re-run autoconf and autoheader). Most of the users do not know how to use these tools... Since the auto stuff is located at the formal package, I patch it. > The use of _DISABLED macros seems odd. I've tried to change this > to be in line with the existing SMARTCARD support as much as > possible. Since this code adds no external dependency, such as opensc, there is no need for default disabled. > In ssh-agent.c, the pkcs11_terminate() call is right after the > while(1) without a break, and just below the /* NOTREACHED */ > comment. I presume this call belongs in the cleanup_handler() and > cleanup_socket(). True... Well... I kind of hope that a cleaner exit will be applied in the future into ssh-agent. > The code seems to include a lot of what I would have expected to be > system library code. Is there a suitable, widely > deployed/available system library that can (at least optionally) > handle some of this? I don't understand... Please explain. > On licencing, I note the licence on cryptoki.h has the advertising > clause. You did the right thing by adding it to LICENCE, but I'm > not sure if it is accepted by OpenSSH in general. (I understand > the other advertising clause, in the Regents of UC licence of > loginrec.c is inoperative, having been repealed by the regents, > just not updated in code). We will wait and see... The answer should be provided by OpenSSH developers. > I've built the patch against current OpenSSH (updated patch > attached, for most of my comments above), and as soon as I get a > soft token working I'll give it a spin. Thanks. It is not applied cleanly. Which version did you use? But as I said... the PKCS#11 should be default on, the modification of the pre-compiler constant will be decided when merging occurs, Why did you add all these string.h, errno.h #include directive? Did you have some problem? Nobody reported such... yet. Thanks for the feed-back! Best Regards, Alon Bar-Lev. From abartlet at samba.org Sun Sep 24 09:41:23 2006 From: abartlet at samba.org (Andrew Bartlett) Date: Sat, 23 Sep 2006 16:41:23 -0700 Subject: [PATCH] Re: PKCS#11 support in OpenSSH 4.3p2 In-Reply-To: <200609240154.04880.alon.barlev@gmail.com> References: <447861A3.1080105@gmail.com> <1159049772.4021.84.camel@amy.samba4.abartlet.net> <200609240154.04880.alon.barlev@gmail.com> Message-ID: <1159054883.28543.18.camel@amy.samba4.abartlet.net> On Sun, 2006-09-24 at 01:54 +0300, Alon Bar-Lev wrote: > On Sunday 24 September 2006 01:16, Andrew Bartlett wrote: > > On Sat, 2006-05-27 at 17:26 +0300, Alon Bar-Lev wrote: > > > Hello, > > > > > > The version 0.11 of "PKCS#11 support in OpenSSH" is published. > > > > I cam across this patch recently, and I thought I might give you > > some feedback, because I would like to see it integrated into > > OpenSSH (I think it looks very useful in combination with > > pam_pkcs11 system logins). > > Great! > I am happy to receive any feed-back. > I've been waiting to Damien Miller to have some free time. It is always a challenge. That's why I wanted to get the review process started, with some easy stuff ;-) > > > A valid X.509 certificate should exist on the token, without > > > X.509 support it is exported as regular RSA key. There is a > > > simple utility Timo Felbinger wrote > > > (http://www.timof.qipc.org/x509toOpenSSH.c) that extracts > > > ssh public key from X.509 certificate. > > > > Is there a reason that this isn't integrated into the patch? > > One reason is that I am not the author of this code. > Another reason is that my OpenSSH developers did not comment on this > patch, and since they did not, I don't know what to pack yet. That's one approach. Another is to clean things up really well, and target the changes well, so that the developer feels that they simply can't object to the patch :-). > > or does the ssh-keygen -D command 'do the right thing'? > > When the PKCS#11 support will be integrated, one of the command-line > utilities will have this functionality, also none daemon > implementation will be added. And I hope that the ssh-agent protocol > will be modified to allow using the agent in none-gui environment. I use ssh-agent without a gui all the time. Why can't ssh-add prompt for a pin just like it prompts for passphrases? > > > If you like X.509 support apply the X.509 (>=5.4) patch > > > *AFTER* the PKCS#11 patch. > > > > I'm puzzled by how much X.509 code there is in this patch. It > > seems that this could be broken into two patches, one initial > > patch, and another to be applied with the X.509 patch. (I've > > removed the X509 hook from the attached patch) > > This is the only difference: > #if defined(SSH_PKCS11_X509_DISABLED) > (*sshkey)->type = KEY_RSA; > #else > (*sshkey)->type = KEY_X509_RSA; > (*sshkey)->x509 = x509; > x509 = NULL; > #endif > > There is no reason to remove anything. The patch will work with or > without X.509 as expected. Yeah, I think i wrote that comment before I finished my patch hacking session. My apologies. Still, the less you mention X509 in terms of the SSH end, and present this in terms of simply smartcards, the less red flags the OpenSSH developers need to consider. Fight the X.509 battle another day :-) > > That said, I think the handling of X.509 or ssh-rsa should be > > better arranged. The documentation implies that I must set '-o > > PubkeyAlgorithms=ssh-rsa' if I want to do 'normal' RSA > > authentication if the X.509 patch is supported in the client. > > Surely both should be offered, and it should be for the server to > > decline? > > Not exactly. > Roumen Petrov explained to me that there is somekind of limit in the > negotiation stage. So the user should specify if he wishes downgrade. What a pity. This should be looked into very carefully, as it would drastically limit the usefulness of X.509 certs. > > Have you looked at how this integrates with pam_pkcs11? Is it > > practical to have some of this inherit the fact that PAM has chosen > > a certificate to log in with, and have this be the default cert? > > I think pam_pkcs11 is much too complex for users... And I don't like > defaults... They tend to not work for most of people. > I have a script that add my identities into the agent... It runs on > logon, it is very nice... But if (as on Fedora Core 6, and RHEL5 betas) pam_pkcs11 is functional, can we make use of it? They seem to have it down to 'tick a box' for smartcard login... > > Also, it seems to duplicate a lot of the smatcard code: Should > > this be configured under SMARTCARD instead, and provide the > > sc_open() etc interface? > > I think that all smartcard related code (opensc and javacard) be > considered to be removed after a standard PKCS#11 implementation is > added. That's a rather large step, and in any case, the old UI will need to be preserved. > > The same would apply for the user interface: I know we might need > > to specify the provider, but should the user see the gory details, > > when they just want to put in their smartcard? At least share that > > with the existing smartcard support, please. > > I don't understand. Looking at the ssh-agent code, your pkcs_11 mode shares no options in common with the other smartcard code. If that code is to be replaced with yours, then users with scripts etc will break. If the smartcard code is not replaced, manpages get bigger to list both, and users become confused 'which smartcard do I have?'. > > On matters of code, I note: > > > > The patch patches autogenerated files (ususally I would just advise > > users that they need to re-run autoconf and autoheader). > > Most of the users do not know how to use these tools... Since the auto > stuff is located at the formal package, I patch it. > > > The use of _DISABLED macros seems odd. I've tried to change this > > to be in line with the existing SMARTCARD support as much as > > possible. > > Since this code adds no external dependency, such as opensc, there is > no need for default disabled. It is a very large lump of code, but I'll leave that judgement to the OpenSSH crew. > > In ssh-agent.c, the pkcs11_terminate() call is right after the > > while(1) without a break, and just below the /* NOTREACHED */ > > comment. I presume this call belongs in the cleanup_handler() and > > cleanup_socket(). > > True... > Well... I kind of hope that a cleaner exit will be applied in the > future into ssh-agent. Why? ssh-agent, like many other programs, needs to deal gracefully with abnormal termination. What happens if that _terminate isn't called? (Because the process was killed in a nasty way?). > > The code seems to include a lot of what I would have expected to be > > system library code. Is there a suitable, widely > > deployed/available system library that can (at least optionally) > > handle some of this? > > I don't understand... Please explain. I'm saying that pkcs11_helper.c and basicly everything outside pkinit.c feel like they belong elsewhere. It is just a gut feeling that 'surely the system should provide this'. > > On licencing, I note the licence on cryptoki.h has the advertising > > clause. You did the right thing by adding it to LICENCE, but I'm > > not sure if it is accepted by OpenSSH in general. (I understand > > the other advertising clause, in the Regents of UC licence of > > loginrec.c is inoperative, having been repealed by the regents, > > just not updated in code). > > We will wait and see... The answer should be provided by OpenSSH > developers. > > > I've built the patch against current OpenSSH (updated patch > > attached, for most of my comments above), and as soon as I get a > > soft token working I'll give it a spin. > > Thanks. > It is not applied cleanly. Which version did you use? Current Portable CVS. > But as I said... the PKCS#11 should be default on, the modification of > the pre-compiler constant will be decided when merging occurs, > Why did you add all these string.h, errno.h #include directive? Did > you have some problem? Nobody reported such... yet. Yes, I needed these headers to compile on Fedora Core 5. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20060923/f8658a3d/attachment.bin From alon.barlev at gmail.com Sun Sep 24 09:58:26 2006 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sun, 24 Sep 2006 02:58:26 +0300 Subject: [PATCH] Re: PKCS#11 support in OpenSSH 4.3p2 In-Reply-To: <1159054883.28543.18.camel@amy.samba4.abartlet.net> References: <447861A3.1080105@gmail.com> <200609240154.04880.alon.barlev@gmail.com> <1159054883.28543.18.camel@amy.samba4.abartlet.net> Message-ID: <200609240258.26089.alon.barlev@gmail.com> On Sunday 24 September 2006 02:41, Andrew Bartlett wrote: > > One reason is that I am not the author of this code. > > Another reason is that my OpenSSH developers did not comment on > > this patch, and since they did not, I don't know what to pack > > yet. > > That's one approach. Another is to clean things up really well, > and target the changes well, so that the developer feels that they > simply can't object to the patch :-). From my experience, it does not go this way. There are a lot of issues to discuss before merging. > I use ssh-agent without a gui all the time. Why can't ssh-add > prompt for a pin just like it prompts for passphrases? Because the ssh-agent should challenge ssh back for passphrase when card session expired, or card is removed/inserted. Current protocol does not support his. This is one issue to be discussed... > > There is no reason to remove anything. The patch will work with > > or without X.509 as expected. > > Yeah, I think i wrote that comment before I finished my patch > hacking session. My apologies. > > Still, the less you mention X509 in terms of the SSH end, and > present this in terms of simply smartcards, the less red flags the > OpenSSH developers need to consider. Fight the X.509 battle > another day :-) If this patch is merged, then the X.509 support will be provided by the X.509 patch. > > Not exactly. > > Roumen Petrov explained to me that there is somekind of limit in > > the negotiation stage. So the user should specify if he wishes > > downgrade. > > What a pity. This should be looked into very carefully, as it > would drastically limit the usefulness of X.509 certs. Current implementation is the most usable one. I had a long discussion regarding that. And the last version is offering a good alternative. > But if (as on Fedora Core 6, and RHEL5 betas) pam_pkcs11 is > functional, can we make use of it? They seem to have it down to > 'tick a box' for smartcard login... pam_pkcs11 a bad implementation, please stop refering to it, unless you review its code, and find it acceptable. The pkcs11-helper library is used in OpenVPN (merged), OpenSSH (patch), QCA (merged), GnuPG (external daemon), I also have xsupplicant and some more. I've written the pkcs11-helper after I've found that there is no valid PKCS#11 usage among open-source projects. pkcs11-helper works with many cards, includeing OpenSC, Aladdin, Athena, Siemens, openCryptoki, Rainbow, ARX, Datakey. If you wish, pam_pkcs11 can use pkcs11-helper in order to provide a better service. > > I think that all smartcard related code (opensc and javacard) be > > considered to be removed after a standard PKCS#11 implementation > > is added. > > That's a rather large step, and in any case, the old UI will need > to be preserved. As I said, the ssh-agent protocol needs also be revised. > Looking at the ssh-agent code, your pkcs_11 mode shares no options > in common with the other smartcard code. If that code is to be > replaced with yours, then users with scripts etc will break. If > the smartcard code is not replaced, manpages get bigger to list > both, and users become confused 'which smartcard do I have?'. Current smartcard support is invalid, because of this I written this new one. It adds all certificates into the agent, it does not support removal and insert of cards, it does not support session timeout, multi providers and more. > > True... > > Well... I kind of hope that a cleaner exit will be applied in the > > future into ssh-agent. > > Why? ssh-agent, like many other programs, needs to deal gracefully > with abnormal termination. What happens if that _terminate isn't > called? (Because the process was killed in a nasty way?). Nothing happens. But I like the signal code informs the main to perform a clean exit, and not exit from the signal handler. > I'm saying that pkcs11_helper.c and basicly everything outside > pkinit.c feel like they belong elsewhere. It is just a gut feeling > that 'surely the system should provide this'. system? which system? I can make the pkcs11-helper a standalone library... But I find it much easier to merge without external dependencies. > Current Portable CVS. Well... You make it difficult for me to review this patch... But I got the mainline comment. > > But as I said... the PKCS#11 should be default on, the > > modification of the pre-compiler constant will be decided when > > merging occurs, Why did you add all these string.h, errno.h > > #include directive? Did you have some problem? Nobody reported > > such... yet. > > Yes, I needed these headers to compile on Fedora Core 5. Strange... I will modify next version. Best Regards, Alon Bar-Lev. From abartlet at samba.org Sun Sep 24 11:09:53 2006 From: abartlet at samba.org (Andrew Bartlett) Date: Sat, 23 Sep 2006 18:09:53 -0700 Subject: [PATCH] Re: PKCS#11 support in OpenSSH 4.3p2 In-Reply-To: <200609240258.26089.alon.barlev@gmail.com> References: <447861A3.1080105@gmail.com> <200609240154.04880.alon.barlev@gmail.com> <1159054883.28543.18.camel@amy.samba4.abartlet.net> <200609240258.26089.alon.barlev@gmail.com> Message-ID: <1159060193.28543.50.camel@amy.samba4.abartlet.net> On Sun, 2006-09-24 at 02:58 +0300, Alon Bar-Lev wrote: > On Sunday 24 September 2006 02:41, Andrew Bartlett wrote: > > I use ssh-agent without a gui all the time. Why can't ssh-add > > prompt for a pin just like it prompts for passphrases? > > Because the ssh-agent should challenge ssh back for passphrase when > card session expired, or card is removed/inserted. > Current protocol does not support his. > This is one issue to be discussed... In a command-line environment, requiring the user to re-run ssh-add doesn't seem unreasonable. But I'm not familiar with that code, so I'll happily agree that there may be a need for further discussion. How does the existing smart-card code get around this? > > But if (as on Fedora Core 6, and RHEL5 betas) pam_pkcs11 is > > functional, can we make use of it? They seem to have it down to > > 'tick a box' for smartcard login... > > pam_pkcs11 a bad implementation, please stop refering to it, unless > you review its code, and find it acceptable. I've not looked at that code yet, so I simply don't know. I do understand that this is what the Red Hat built their smart card login solution on. While I spend my day hacking Samba, I'm part of that group at RedHat. I'm impressed with what they have achieved, and wanted to be able to make the case to the others in my group of: you make smartcard login simple, wouldn't it be great if it 'just worked' for moving off the box with SSH too? (I'm sick of typing a password and then a long pass-phrase twice each time I log into the laptop). My naive assumption was that 'just works' smartcard logins would provide some information to the session (such as how to access the now unlocked smartcard), so that subsequent operations would not require a PIN. That was the reason for my pam_pkcs11 reference. Perhaps I need to spend more time with some of developers here to understand the pieces better. > The pkcs11-helper library is used in OpenVPN (merged), OpenSSH > (patch), QCA (merged), GnuPG (external daemon), I also have > xsupplicant and some more. For GnuPG is that the p11scd? I'm also very interested in trying to GPG sign mail with a PKCS#11 smartcard. > I've written the pkcs11-helper after I've found that there is no valid > PKCS#11 usage among open-source projects. That's why I was asking the 'system library' question. It looked like shared code, so why is it pasted into each project? > pkcs11-helper works with many cards, includeing OpenSC, Aladdin, > Athena, Siemens, openCryptoki, Rainbow, ARX, Datakey. > > If you wish, pam_pkcs11 can use pkcs11-helper in order to provide a > better service. I'm sure that would be very interesting. As I said, I've not looked at that code yet. > > Looking at the ssh-agent code, your pkcs_11 mode shares no options > > in common with the other smartcard code. If that code is to be > > replaced with yours, then users with scripts etc will break. If > > the smartcard code is not replaced, manpages get bigger to list > > both, and users become confused 'which smartcard do I have?'. > > Current smartcard support is invalid, because of this I written this > new one. > It adds all certificates into the agent, it does not support removal > and insert of cards, it does not support session timeout, multi > providers and more. These sounds like great new features! When users/deployments become comfortable with your new, better code, then I'm sure they will want to be able to migrate to it. I'm suggesting that you should make that migration as painless as possible, by reusing options. Likewise in the code, it seems that there is already an established pattern of smartcard subsystems, why don't you use them? (and extend the interface if required). > > > True... > > > Well... I kind of hope that a cleaner exit will be applied in the > > > future into ssh-agent. > > > > Why? ssh-agent, like many other programs, needs to deal gracefully > > with abnormal termination. What happens if that _terminate isn't > > called? (Because the process was killed in a nasty way?). > > Nothing happens. If nothing happens, then why ever call _terminate()? Well-written code should cope with an abnormal exit, and not have any unclean shared state, but I presume this function exists for a reason. > But I like the signal code informs the main to perform a clean exit, > and not exit from the signal handler. Is it unsafe to call these functions from the signal handler? Perhaps the next version of your patch needs to find a way (sometimes difficult in my experience of other apps) to return to that loop. > > I'm saying that pkcs11_helper.c and basicly everything outside > > pkinit.c feel like they belong elsewhere. It is just a gut feeling > > that 'surely the system should provide this'. > > system? which system? > I can make the pkcs11-helper a standalone library... But I find it > much easier to merge without external dependencies. It certainly is easier once. But in the Samba project we are currently running around trying to rationalise code like this, because we got bitten. Lots of small, different fixes and different bugs in the different versions. > > Current Portable CVS. > > Well... > You make it difficult for me to review this patch... > But I got the mainline comment. I actually hoped it would make it easier, particularly for any potential merge. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20060923/fbf95710/attachment.bin From alon.barlev at gmail.com Sun Sep 24 19:58:16 2006 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sun, 24 Sep 2006 12:58:16 +0300 Subject: [PATCH] Re: PKCS#11 support in OpenSSH 4.3p2 In-Reply-To: <1159060193.28543.50.camel@amy.samba4.abartlet.net> References: <447861A3.1080105@gmail.com> <200609240258.26089.alon.barlev@gmail.com> <1159060193.28543.50.camel@amy.samba4.abartlet.net> Message-ID: <200609241258.16737.alon.barlev@gmail.com> On Sunday 24 September 2006 04:09, Andrew Bartlett wrote: > In a command-line environment, requiring the user to re-run ssh-add > doesn't seem unreasonable. But I'm not familiar with that code, so > I'll happily agree that there may be a need for further discussion. What?!?!? Let's say your smartcard uses also in order to open your office door... So you must take it whereever you go... Every time you come back, and insert your card, entering the PIN for the pam_pkcs11, you need to re-run ssh-add before you ssh?!?!? And when smartcard session expires, run another ssh-add? Every hour or so?!?!? From a user point of view, the user should be prompted when he is runs ssh for (optionally) insert his card and (optionally) PIN, that's it. Only once the user should load his identities into the ssh-agent. > How does the existing smart-card code get around this? It doesn't, once you added identity into the daemon, it stays there... Even if the card is removed and inserted... It also remembers the PIN... > I've not looked at that code yet, so I simply don't know. I do > understand that this is what the Red Hat built their smart card > login solution on. While I spend my day hacking Samba, I'm part of > that group at RedHat. I'm impressed with what they have achieved, > and wanted to be able to make the case to the others in my group > of: you make smartcard login simple, wouldn't it be great if it > 'just worked' for moving off the box with SSH too? 1. pam_pkcs11 is not of RedHat, they just used it... As they can use more components that uses smartcards. I don't understand why you thing they achieved anything. 2. Standard smartcard for OpenSSH is also simple... Just use my patch... :) > My naive assumption was that 'just works' smartcard logins would > provide some information to the session (such as how to access the > now unlocked smartcard), so that subsequent operations would not > require a PIN. That was the reason for my pam_pkcs11 reference. Oh... This is something different! The OpenSC project raised an option to write a generic smartcard agent... But I think that it is wrong from security point of view. Since not all applications on your system may access your credentials. There is nothing wrong in entering the PIN in several applications, this is how you approve the use of your private key. Remember: Smartcards are used in order to enforce security, and not as a gadgets. And because smartcards are locked after N retries, the PIN may be much simpler than a password. > For GnuPG is that the p11scd? I'm also very interested in trying > to GPG sign mail with a PKCS#11 smartcard. This is a work in progress. http://alon.barlev.googlepages.com/gnupg-pkcs11 You can try it out, and send feedback... I don't know if it work with GUI application, but gpgm works. > > I've written the pkcs11-helper after I've found that there is no > > valid PKCS#11 usage among open-source projects. > > That's why I was asking the 'system library' question. It looked > like shared code, so why is it pasted into each project? I need to make it more generic first. After about 5 large projects will use the same code, I will consider doing that. > Likewise in the code, it seems that there is already an established > pattern of smartcard subsystems, why don't you use them? (and > extend the interface if required). PKCS#11 is the subsystem we integrate into. > Is it unsafe to call these functions from the signal handler? > Perhaps the next version of your patch needs to find a way > (sometimes difficult in my experience of other apps) to return to > that loop. This is part of none- PKCS#11 improvements. When I will work on merging, I might do such modifications. > I actually hoped it would make it easier, particularly for any > potential merge. We have long way to go... So I only patch release versions. I am waiting for some kind of discussion with core OpenSSH developers. I will do anything required in order to see OpenSSH allows people to improve their security by using standard smartcards. Best Regards, Alon Bar-Lev. From tim at multitalents.net Mon Sep 25 02:26:56 2006 From: tim at multitalents.net (Tim Rice) Date: Sun, 24 Sep 2006 09:26:56 -0700 (PDT) Subject: [PATCH] Re: PKCS#11 support in OpenSSH 4.3p2 In-Reply-To: <200609240258.26089.alon.barlev@gmail.com> References: <447861A3.1080105@gmail.com> <200609240154.04880.alon.barlev@gmail.com> <1159054883.28543.18.camel@amy.samba4.abartlet.net> <200609240258.26089.alon.barlev@gmail.com> Message-ID: On Sun, 24 Sep 2006, Alon Bar-Lev wrote: > On Sunday 24 September 2006 02:41, Andrew Bartlett wrote: > > Current Portable CVS. > > > > merging occurs, Why did you add all these string.h, errno.h > > > #include directive? Did you have some problem? Nobody reported > > > such... yet. > > > > Yes, I needed these headers to compile on Fedora Core 5. > > Strange... Many includes have been moved out of includes.h and into the files that need them. Do a grep "move #include" on ChangeLog -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From alon.barlev at gmail.com Mon Sep 25 02:29:33 2006 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sun, 24 Sep 2006 19:29:33 +0300 Subject: [PATCH] Re: PKCS#11 support in OpenSSH 4.3p2 In-Reply-To: References: <447861A3.1080105@gmail.com> <200609240154.04880.alon.barlev@gmail.com> <1159054883.28543.18.camel@amy.samba4.abartlet.net> <200609240258.26089.alon.barlev@gmail.com> Message-ID: <9e0cf0bf0609240929y15986eb7vbd3f08f6cb86af65@mail.gmail.com> On 9/24/06, Tim Rice wrote: > On Sun, 24 Sep 2006, Alon Bar-Lev wrote: > > > On Sunday 24 September 2006 02:41, Andrew Bartlett wrote: > > > Current Portable CVS. > > > > > > merging occurs, Why did you add all these string.h, errno.h > > > > #include directive? Did you have some problem? Nobody reported > > > > such... yet. > > > > > > Yes, I needed these headers to compile on Fedora Core 5. > > > > Strange... > > Many includes have been moved out of includes.h and into the files > that need them. Do a grep "move #include" on ChangeLog Thanks! I was not aware that Andrew has used the CVS version and not the release... I will fix that at next release. Best Regards, Alon Bar-Lev. From Jan.Pechanec at Sun.COM Tue Sep 26 01:38:04 2006 From: Jan.Pechanec at Sun.COM (Jan Pechanec) Date: Mon, 25 Sep 2006 17:38:04 +0200 (CEST) Subject: [PATCH] implementation of getpeereid() for Solaris Message-ID: hi, Solaris doesn't have getpeereid() or SO_PEERCRED. However, getpeerucred() is perfectly usable for that; and it's in Solaris 10 and OpenSolaris. So, ssh-agent(1) security there so far depends only on permissions of the socket directory and with this patch it checks peer's credentials, too. I patched following files using a snapshot from 20060921: openssh/config.h.in openssh/configure.ac openssh/includes.h openssh/openbsd-compat/bsd-getpeereid.c openssh/regress/agent-getpeereid.sh which implements getpeereid() function in OpenSSH with getpeerucred() in case that ucred.h and getpeerucred() are present. I then generated new configure script via autoconf, configured and built on Solaris and FreeBSD. It seems fine. I changed regress/agent-getpeereid.sh to accept existence of HAVE_GETPEERUCRED and added missing check for HAVE_SO_PEERCRED. I also suggest this change: < /dev/null ${SUDO} -S -u ${UNPRIV} ssh-add -l > /dev/null 2>&1 r=$? - if [ $r -lt 2 ]; then + if [ $r -le 2 ]; then fail "ssh-add did not fail for ${UNPRIV}: $r < 2" fi -> ie. to change less-then to less-or-equal. Reason behind that is if a user running regression tests uses 0700 umask then agent-getpeereid.sh test can PASS even if getpeereid() functionality wasn't checked at all because the path to socket is unreachable which means 2 is returned. Or it could be changed to greater-then 128. proposed change is already present in OpenSolaris. regards, Jan. -- Jan Pechanec -------------- next part -------------- diff -ur openssh/config.h.in openssh-SNAP-20060921-patched//config.h.in --- openssh/config.h.in Wed Sep 20 16:30:40 2006 +++ openssh-SNAP-20060921-patched//config.h.in Mon Sep 25 11:49:06 2006 @@ -354,6 +354,9 @@ /* Define to 1 if you have the `getpeereid' function. */ #undef HAVE_GETPEEREID +/* Define to 1 if you have the `getpeerucred' function. */ +#define HAVE_GETPEERUCRED + /* Define to 1 if you have the `getpwanam' function. */ #undef HAVE_GETPWANAM @@ -375,6 +378,9 @@ /* Define to 1 if you have the `getttyent' function. */ #undef HAVE_GETTTYENT +/* Define to 1 if you have the header file. */ +#define HAVE_UCRED_H + /* Define to 1 if you have the `getutent' function. */ #undef HAVE_GETUTENT diff -ur openssh/configure.ac openssh-SNAP-20060921-patched//configure.ac --- openssh/configure.ac Mon Sep 18 15:17:41 2006 +++ openssh-SNAP-20060921-patched//configure.ac Mon Sep 25 11:58:41 2006 @@ -1242,6 +1242,7 @@ getnameinfo \ getopt \ getpeereid \ + getpeerucred \ _getpty \ getrlimit \ getttyent \ @@ -1490,7 +1491,7 @@ # Check for missing getpeereid (or equiv) support NO_PEERCHECK="" -if test "x$ac_cv_func_getpeereid" != "xyes" ; then +if test "x$ac_cv_func_getpeereid" != "xyes" -a "x$ac_cv_func_getpeerucred" != "xyes"; then AC_MSG_CHECKING([whether system supports SO_PEERCRED getsockopt]) AC_TRY_COMPILE( [#include @@ -4011,12 +4012,12 @@ fi if test ! -z "$NO_PEERCHECK" ; then - echo "WARNING: the operating system that you are using does not " - echo "appear to support either the getpeereid() API nor the " - echo "SO_PEERCRED getsockopt() option. These facilities are used to " - echo "enforce security checks to prevent unauthorised connections to " - echo "ssh-agent. Their absence increases the risk that a malicious " - echo "user can connect to your agent. " + echo "WARNING: the operating system that you are using does not" + echo "appear to support either the getpeereid() or getpeerucred() API" + echo "nor the SO_PEERCRED getsockopt() option. These facilities are" + echo "used to enforce security checks to prevent unauthorised" + echo "connections to ssh-agent. Their absence increases the risk that" + echo "a malicious user can connect to your agent." echo "" fi diff -ur openssh/includes.h openssh-SNAP-20060921-patched//includes.h --- openssh/includes.h Fri Sep 1 12:29:11 2006 +++ openssh-SNAP-20060921-patched//includes.h Mon Sep 25 11:50:02 2006 @@ -63,6 +63,10 @@ # include #endif +#ifdef HAVE_UCRED_H +# include +#endif + #ifdef HAVE_UTMP_H # include #endif diff -ur openssh/openbsd-compat/bsd-getpeereid.c openssh-SNAP-20060921-patched//openbsd-compat/bsd-getpeereid.c --- openssh/openbsd-compat/bsd-getpeereid.c Mon Aug 7 03:26:38 2006 +++ openssh-SNAP-20060921-patched//openbsd-compat/bsd-getpeereid.c Mon Sep 25 11:54:31 2006 @@ -37,6 +37,23 @@ return (0); } +#elif defined(HAVE_GETPEERUCRED) +int +getpeereid(int s, uid_t *euid, gid_t *gid) +{ + ucred_t *ucred = NULL; + + if (getpeerucred(s, &ucred) == -1) + return (-1); + if ((*euid = ucred_geteuid(ucred)) == -1) + return (-1); + if ((*gid = ucred_getrgid(ucred)) == -1) + return (-1); + + ucred_free(ucred); + + return (0); +} #else int getpeereid(int s, uid_t *euid, gid_t *gid) diff -ur openssh/regress/agent-getpeereid.sh openssh-SNAP-20060921-patched//regress/agent-getpeereid.sh --- openssh/regress/agent-getpeereid.sh Mon Jul 24 07:31:42 2006 +++ openssh-SNAP-20060921-patched//regress/agent-getpeereid.sh Mon Sep 25 12:33:47 2006 @@ -7,7 +7,9 @@ ASOCK=${OBJ}/agent SSH_AUTH_SOCK=/nonexistant -if grep "#undef.*HAVE_GETPEEREID" ${BUILDDIR}/config.h >/dev/null 2>&1 +if grep "#undef.*HAVE_GETPEEREID" ${BUILDDIR}/config.h >/dev/null 2>&1 && \ + grep "#undef.*HAVE_GETPEERUCRED" ${BUILDDIR}/config.h >/dev/null && \ + grep "#undef.*HAVE_SO_PEERCRED" ${BUILDDIR}/config.h >/dev/null then echo "skipped (not supported on this platform)" exit 0 @@ -34,7 +36,7 @@ < /dev/null ${SUDO} -S -u ${UNPRIV} ssh-add -l > /dev/null 2>&1 r=$? - if [ $r -lt 2 ]; then + if [ $r -le 2 ]; then fail "ssh-add did not fail for ${UNPRIV}: $r < 2" fi @@ -42,4 +44,4 @@ ${SSHAGENT} -k > /dev/null fi -rm -f ${OBJ}/agent +rm -f $ASOCK From imorgan at nas.nasa.gov Tue Sep 26 05:05:39 2006 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 25 Sep 2006 12:05:39 -0700 (PDT) Subject: Testing for the 4.4p1 release In-Reply-To: <20060923004320.GA14564@gate.dtucker.net> from Darren Tucker at "Sep 23, 2006 10:43:20 am" Message-ID: <200609251905.k8PJ5dgS001828@ganymede.nas.nasa.gov> Sometime ago, Darren Tucker wrote: > On Fri, Sep 22, 2006 at 05:15:57PM -0700, Iain Morgan wrote: > > Sometime ago, Darren Tucker wrote: > [...] > > > This is a long shot, but when you attempt to use Protocol 1, does the > > > known_hosts file entry consist mainly of zeros? eg, > > > > Yes! I guess I never took a close look at the entry, but it has several > > long sequneces of 0's in it. > > Thanks. > > I have seen this reported on HP-UX and have now been able to reproduce > it. I suspected it to be a problem with either OpenSSL or the compiler, > and if you are able to reproduce it on another platform with another > compiler then it makes OpenSSL much more likely as the culprit. > > I'll update the OpenSSL bug report. > After applying the patch, I see the following errors during 'make test' test sslv2 with server authentication server authentication Initial proxy rights = C depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1 Certificate proxy rights = AB, resulting proxy rights = none Proxy rights check with condition 'A' proved invalid ERROR in CLIENT 1812436:error:1407E086:SSL routines:SSL2_SET_CERTIFICATE:certificate verify failed:s2_clnt.c:1066: SSLv2, cipher (NONE) (NONE) test sslv2 SSLv2, cipher SSLv2 DES-CBC3-MD5, 512 bit RSA test sslv2 with server authentication server authentication Initial proxy rights = C depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1 Certificate proxy rights = AB, resulting proxy rights = none Proxy rights check with condition 'B' proved invalid ERROR in CLIENT 5313357:error:1407E086:SSL routines:SSL2_SET_CERTIFICATE:certificate verify failed:s2_clnt.c:1066: SSLv2, cipher (NONE) (NONE) test sslv2 This happens with both irix-mips3-cc and irix64-mips4-cc. In both cases, there appear to be 22 errors. -- Iain Morgan From dtucker at zip.com.au Tue Sep 26 06:58:55 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 26 Sep 2006 06:58:55 +1000 Subject: Testing for the 4.4p1 release In-Reply-To: <200609251905.k8PJ5dgS001828@ganymede.nas.nasa.gov> References: <200609251905.k8PJ5dgS001828@ganymede.nas.nasa.gov> Message-ID: <4518430F.5020905@zip.com.au> Iain Morgan wrote: > Sometime ago, Darren Tucker wrote: >> On Fri, Sep 22, 2006 at 05:15:57PM -0700, Iain Morgan wrote: >>> Sometime ago, Darren Tucker wrote: >> [...] >>>> This is a long shot, but when you attempt to use Protocol 1, does the >>>> known_hosts file entry consist mainly of zeros? eg, >>> Yes! I guess I never took a close look at the entry, but it has several >>> long sequneces of 0's in it. >> Thanks. >> >> I have seen this reported on HP-UX and have now been able to reproduce >> it. I suspected it to be a problem with either OpenSSL or the compiler, >> and if you are able to reproduce it on another platform with another >> compiler then it makes OpenSSL much more likely as the culprit. >> >> I'll update the OpenSSL bug report. >> > > After applying the patch, I see the following errors during 'make test' > > test sslv2 with server authentication > server authentication > Initial proxy rights = C > depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA > depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 > depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1 > Certificate proxy rights = AB, resulting proxy rights = none > Proxy rights check with condition 'A' proved invalid > ERROR in CLIENT > 1812436:error:1407E086:SSL routines:SSL2_SET_CERTIFICATE:certificate > verify failed:s2_clnt.c:1066: > SSLv2, cipher (NONE) (NONE) > test sslv2 > SSLv2, cipher SSLv2 DES-CBC3-MD5, 512 bit RSA > test sslv2 with server authentication > server authentication > Initial proxy rights = C > depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA > depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 > depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1 > Certificate proxy rights = AB, resulting proxy rights = none > Proxy rights check with condition 'B' proved invalid > ERROR in CLIENT > 5313357:error:1407E086:SSL routines:SSL2_SET_CERTIFICATE:certificate > verify failed:s2_clnt.c:1066: > SSLv2, cipher (NONE) (NONE) > test sslv2 > > This happens with both irix-mips3-cc and irix64-mips4-cc. In both cases, > there appear to be 22 errors. Well that's an error, but not the one I was expecting. I suspect you will see it without my patch too. Could you please run "test/bntest" manually? That will exercise the code in my patch. -- 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 tcagle at abcsinc.com Tue Sep 26 06:19:43 2006 From: tcagle at abcsinc.com (Tim Cagle) Date: Mon, 25 Sep 2006 15:19:43 -0500 Subject: Is this normal? Message-ID: <451839DF.5030109@abcsinc.com> [tim at javadev1 tim]$ scp opteron:/tmp/tim2 boomshakalaka:/tmp ssh: boomshakalaka: Name or service not known lost connection [tim at javadev1 tim]$ echo $? 0 And if so why given that the man page says: "DIAGNOSTICS scp exits with 0 on success or >0 if an error occurred." I've tried to search the archives to no avail BTW. Sorry if I am asking the wrong question in the wrong forum but I did not know what else to do. From dtucker at zip.com.au Tue Sep 26 09:49:38 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 26 Sep 2006 09:49:38 +1000 Subject: Is this normal? In-Reply-To: <451839DF.5030109@abcsinc.com> References: <451839DF.5030109@abcsinc.com> Message-ID: <45186B12.9050100@zip.com.au> Tim Cagle wrote: > [tim at javadev1 tim]$ scp opteron:/tmp/tim2 boomshakalaka:/tmp > ssh: boomshakalaka: Name or service not known > lost connection > [tim at javadev1 tim]$ echo $? > 0 > > And if so why given that the man page says: > > "DIAGNOSTICS > scp exits with 0 on success or >0 if an error occurred." > > I've tried to search the archives to no avail BTW. > Sorry if I am asking the wrong question in the wrong > forum but I did not know what else to do. Which version of OpenSSH is that? There were some changes in 4.3x that fixed up the exit codes for ssh(1) for certain error conditions. The soon-to-be-current version also seems ok: $ ssh -V OpenSSH_4.4p1, OpenSSL 0.9.7f 22 Mar 2005 $ scp /tmp/foo nosuch:/tmnp/foo2; echo $? ssh: nosuch: Name or service not known lost connection 1 -- 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 imorgan at nas.nasa.gov Tue Sep 26 10:02:57 2006 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 25 Sep 2006 17:02:57 -0700 (PDT) Subject: Testing for the 4.4p1 release In-Reply-To: <4518430F.5020905@zip.com.au> from Darren Tucker at "Sep 26, 2006 06:58:55 am" Message-ID: <200609260002.k8Q02v8V012302@ganymede.nas.nasa.gov> Sometime ago, Darren Tucker wrote: > Iain Morgan wrote: > > Sometime ago, Darren Tucker wrote: > >> On Fri, Sep 22, 2006 at 05:15:57PM -0700, Iain Morgan wrote: > >>> Sometime ago, Darren Tucker wrote: > >> [...] > >>>> This is a long shot, but when you attempt to use Protocol 1, does the > >>>> known_hosts file entry consist mainly of zeros? eg, > >>> Yes! I guess I never took a close look at the entry, but it has several > >>> long sequneces of 0's in it. > >> Thanks. > >> > >> I have seen this reported on HP-UX and have now been able to reproduce > >> it. I suspected it to be a problem with either OpenSSL or the compiler, > >> and if you are able to reproduce it on another platform with another > >> compiler then it makes OpenSSL much more likely as the culprit. > >> > >> I'll update the OpenSSL bug report. > >> > > > > After applying the patch, I see the following errors during 'make test' > > > > test sslv2 with server authentication > > server authentication > > Initial proxy rights = C > > depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA > > depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 > > depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1 > > Certificate proxy rights = AB, resulting proxy rights = none > > Proxy rights check with condition 'A' proved invalid > > ERROR in CLIENT > > 1812436:error:1407E086:SSL routines:SSL2_SET_CERTIFICATE:certificate > > verify failed:s2_clnt.c:1066: > > SSLv2, cipher (NONE) (NONE) > > test sslv2 > > SSLv2, cipher SSLv2 DES-CBC3-MD5, 512 bit RSA > > test sslv2 with server authentication > > server authentication > > Initial proxy rights = C > > depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA > > depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 > > depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1 > > Certificate proxy rights = AB, resulting proxy rights = none > > Proxy rights check with condition 'B' proved invalid > > ERROR in CLIENT > > 5313357:error:1407E086:SSL routines:SSL2_SET_CERTIFICATE:certificate > > verify failed:s2_clnt.c:1066: > > SSLv2, cipher (NONE) (NONE) > > test sslv2 > > > > This happens with both irix-mips3-cc and irix64-mips4-cc. In both cases, > > there appear to be 22 errors. > > Well that's an error, but not the one I was expecting. I suspect you > will see it without my patch too. > Sorry about. I should have done a baseline against the unmodified versions and shouldn't have simply sent the first error I saw. > Could you please run "test/bntest" manually? That will exercise the > code in my patch. > OK. Running test/bntest gives a lot of output. Based on the patch, I assume you're only interested in the bn2dec test. That appears to be OK. $ tail bntest.out ..... .................++++++++++++ ..... ...........++++++++++++ ..... test BN_bn2dec print "test BN_bn2dec\n" lou.imorgan> exit script done on Mon Sep 25 16:02:09 2006 $ -- Iain Morgan From dtucker at zip.com.au Tue Sep 26 10:34:34 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 26 Sep 2006 10:34:34 +1000 Subject: Testing for the 4.4p1 release In-Reply-To: <200609260002.k8Q02v8V012302@ganymede.nas.nasa.gov> References: <200609260002.k8Q02v8V012302@ganymede.nas.nasa.gov> Message-ID: <4518759A.9090501@zip.com.au> Iain Morgan wrote: > Sometime ago, Darren Tucker wrote: >> Could you please run "test/bntest" manually? That will exercise the >> code in my patch. > > OK. Running test/bntest gives a lot of output. Based on the patch, I > assume you're only interested in the bn2dec test. That appears to be OK. Alright, that passes the test cases I added for bn2dec (which admittedly are a very small subset of the possible inputs it could encounter, and much smaller than some of the inputs ssh would give it). I'm tempted to generate a bunch of really big numbers at and test with those too, but I don't much like the idea of nondeterministic regression tests. Based on the other failure you reported, I still suspect you have some problem in OpenSSL although it's not exactly the same as the one I was describing on HP-UX. I found that using less aggressive compiler options for OpenSSL stopped the problem from occurring, perhaps the same would be the case here? -- 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 imorgan at nas.nasa.gov Tue Sep 26 11:06:44 2006 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 25 Sep 2006 18:06:44 -0700 (PDT) Subject: Testing for the 4.4p1 release In-Reply-To: <4518759A.9090501@zip.com.au> from Darren Tucker at "Sep 26, 2006 10:34:34 am" Message-ID: <200609260106.k8Q16iRk003145@ganymede.nas.nasa.gov> Sometime ago, Darren Tucker wrote: > Iain Morgan wrote: > > Sometime ago, Darren Tucker wrote: > >> Could you please run "test/bntest" manually? That will exercise the > >> code in my patch. > > > > OK. Running test/bntest gives a lot of output. Based on the patch, I > > assume you're only interested in the bn2dec test. That appears to be OK. > > Alright, that passes the test cases I added for bn2dec (which admittedly > are a very small subset of the possible inputs it could encounter, and > much smaller than some of the inputs ssh would give it). > > I'm tempted to generate a bunch of really big numbers at and test with > those too, but I don't much like the idea of nondeterministic regression > tests. > > Based on the other failure you reported, I still suspect you have some > problem in OpenSSL although it's not exactly the same as the one I was > describing on HP-UX. I found that using less aggressive compiler > options for OpenSSL stopped the problem from occurring, perhaps the same > would be the case here? > Agreed. I don't recall the OpenSSL regression tests encountering errors with previous versions that I've built, but I suppose I could have overlooked them. Trying less aggressive optimization is certainly worthwhile. Thanks for the help. -- Iain Morgan From dtucker at zip.com.au Tue Sep 26 22:54:50 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 26 Sep 2006 22:54:50 +1000 Subject: [PATCH] implementation of getpeereid() for Solaris In-Reply-To: References: Message-ID: <4519231A.3050500@zip.com.au> Jan Pechanec wrote: > hi, Solaris doesn't have getpeereid() or SO_PEERCRED. However, > getpeerucred() is perfectly usable for that; and it's in Solaris 10 and > OpenSolaris. [...] > [patch] which implements getpeereid() function in OpenSSH with > getpeerucred() in case that ucred.h and getpeerucred() are present. Thanks. We will probably apply this (with a couple of minor tweaks, like moving the #include into bsd-getpeereid.c) but unfortunately it arrived too late for 4.4p1, so it will not be until the following release. > -rm -f ${OBJ}/agent > +rm -f $ASOCK Out of curiosity, why this change? -- 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 Tue Sep 26 22:58:22 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 26 Sep 2006 22:58:22 +1000 Subject: Testing for the 4.4p1 release In-Reply-To: References: <20060910051217.GA3812@gate.dtucker.net> Message-ID: <451923EE.8030707@zip.com.au> Hi. Pekka Savola wrote: [regress hang on Redhat 7.2 w/ipv6] >>> from 127.0.0.1 port 44319 (t4 r26 i0/0 o0/0 fd 27/27 cfd -1) >>> [[ almost 10 minute timeout ]] >>> ssh_exchange_identification: Connection closed by remote host >>> cmp: EOF on /home/pekkas/op/openssh/regress/ls.copy >>> corrupted copy of /bin/ls >>> bind: Address already in use I've spent some time puzzling over this one, but I don't know what else to look at or suggest. I even installed RH72 in a VM to attempt to reproduce it without success. -- 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 Jan.Pechanec at Sun.COM Tue Sep 26 23:51:06 2006 From: Jan.Pechanec at Sun.COM (Jan Pechanec) Date: Tue, 26 Sep 2006 15:51:06 +0200 (CEST) Subject: [PATCH] implementation of getpeereid() for Solaris In-Reply-To: <4519231A.3050500@zip.com.au> References: <4519231A.3050500@zip.com.au> Message-ID: On Tue, 26 Sep 2006, Darren Tucker wrote: > Jan Pechanec wrote: >> hi, Solaris doesn't have getpeereid() or SO_PEERCRED. However, >> getpeerucred() is perfectly usable for that; and it's in Solaris 10 and >> OpenSolaris. [...] >> [patch] which implements getpeereid() function in OpenSSH with >> getpeerucred() in case that ucred.h and getpeerucred() are present. > > Thanks. > > We will probably apply this (with a couple of minor tweaks, like moving the > #include into bsd-getpeereid.c) but unfortunately it arrived too late for > 4.4p1, so it will not be until the following release. cool. I think there are some minor problems I found in other regression tests, I will send patch, too. > >> -rm -f ${OBJ}/agent >> +rm -f $ASOCK > > Out of curiosity, why this change? there is "ASOCK=${OBJ}/agent" on line 7. Just from good programming practise I would expect that by changing contents of ASOCK variable I'm done if I want to change that socket name. However, the contents ${OBJ}/agent is used somewhere else literally. It's just a suggestion, code would be cleaner. cheers, Jan. -- Jan Pechanec From pekkas at netcore.fi Wed Sep 27 03:35:34 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 26 Sep 2006 20:35:34 +0300 (EEST) Subject: Testing for the 4.4p1 release In-Reply-To: <451923EE.8030707@zip.com.au> References: <20060910051217.GA3812@gate.dtucker.net> <451923EE.8030707@zip.com.au> Message-ID: On Tue, 26 Sep 2006, Darren Tucker wrote: > Pekka Savola wrote: > [regress hang on Redhat 7.2 w/ipv6] >>>> from 127.0.0.1 port 44319 (t4 r26 i0/0 o0/0 fd 27/27 cfd -1) >>>> [[ almost 10 minute timeout ]] >>>> ssh_exchange_identification: Connection closed by remote host >>>> cmp: EOF on /home/pekkas/op/openssh/regress/ls.copy >>>> corrupted copy of /bin/ls >>>> bind: Address already in use > > I've spent some time puzzling over this one, but I don't know what else > to look at or suggest. I even installed RH72 in a VM to attempt to > reproduce it without success. Did you have IPv6 enabled (with global addresses)? I don't know about corrupted copy of /bin/ls but I suspect some bind() errors may have been due to v6 mapped addresses. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From dtucker at zip.com.au Wed Sep 27 07:52:05 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 27 Sep 2006 07:52:05 +1000 Subject: Testing for the 4.4p1 release In-Reply-To: References: <20060910051217.GA3812@gate.dtucker.net> <451923EE.8030707@zip.com.au> Message-ID: <4519A105.1060207@zip.com.au> Pekka Savola wrote: > On Tue, 26 Sep 2006, Darren Tucker wrote: >> I've spent some time puzzling over this one, but I don't know what else >> to look at or suggest. I even installed RH72 in a VM to attempt to >> reproduce it without success. > > Did you have IPv6 enabled Yes. > (with global addresses)? No, host and link scope only. > I don't know about > corrupted copy of /bin/ls but I suspect some bind() errors may have been > due to v6 mapped addresses. The "corrupted copy of /bin/ls" is because one of the things the regress test does is runs an scp over the tunnel to test it, so that just indicates that the test failed. -- 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 Wed Sep 27 10:09:16 2006 From: william at 25thandClement.com (William Ahern) Date: Tue, 26 Sep 2006 17:09:16 -0700 Subject: ExitOnForwardFailure and Protocol 2.0 Message-ID: <20060927000916.GA31752@orville.25thandClement.com> I'm merging my "streamlocal" unix domain socket forwarding patch into 4.4p1 (or rather 20060926 SNAP) and I gather that the ExitOnForwardFailure capability only works for protocol 1.0. Am I misreading things? I was really looking forward to that feature. I noticed when I began fixing a merge reject in channel_request_remote_forwarding(). - Bill From dtucker at zip.com.au Wed Sep 27 10:45:54 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 27 Sep 2006 10:45:54 +1000 Subject: ExitOnForwardFailure and Protocol 2.0 In-Reply-To: <20060927000916.GA31752@orville.25thandClement.com> References: <20060927000916.GA31752@orville.25thandClement.com> Message-ID: <4519C9C2.1070006@zip.com.au> William Ahern wrote: > I'm merging my "streamlocal" unix domain socket forwarding patch into 4.4p1 > (or rather 20060926 SNAP) and I gather that the ExitOnForwardFailure > capability only works for protocol 1.0. > > Am I misreading things? I was really looking forward to that feature. I think so, I use ExitOnForwardFailure with protocol 2 all the time. $ ssh -2 -o exitonforwardfailure=yes -R 22:127.0.0.1:22 localhost Error: remote port forwarding failed for listen port 22 $ ssh -V OpenSSH_4.4p1, OpenSSL 0.9.7f 22 Mar 2005 Can you give an example of it not working? -- 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 Wed Sep 27 11:07:24 2006 From: william at 25thandClement.com (William Ahern) Date: Tue, 26 Sep 2006 18:07:24 -0700 Subject: ExitOnForwardFailure and Protocol 2.0 In-Reply-To: <4519C9C2.1070006@zip.com.au> References: <20060927000916.GA31752@orville.25thandClement.com> <4519C9C2.1070006@zip.com.au> Message-ID: <20060927010724.GA548@orville.25thandClement.com> On Wed, Sep 27, 2006 at 10:45:54AM +1000, Darren Tucker wrote: > William Ahern wrote: > >I'm merging my "streamlocal" unix domain socket forwarding patch into 4.4p1 > >(or rather 20060926 SNAP) and I gather that the ExitOnForwardFailure > >capability only works for protocol 1.0. > > > >Am I misreading things? I was really looking forward to that feature. > > I think so, I use ExitOnForwardFailure with protocol 2 all the time. > > $ ssh -2 -o exitonforwardfailure=yes -R 22:127.0.0.1:22 localhost > Error: remote port forwarding failed for listen port 22 > $ ssh -V > OpenSSH_4.4p1, OpenSSL 0.9.7f 22 Mar 2005 > > Can you give an example of it not working? > Interesting. Then line 2543 of channels.c is confusing me: packet_start(SSH2_MSG_GLOBAL_REQUEST); packet_put_cstring("tcpip-forward"); packet_put_char(1); /* boolean: want reply */ packet_put_cstring(address_to_bind); packet_put_int(listen_port); packet_send(); packet_write_wait(); /* Assume that server accepts the request */ success = 1; From dtucker at zip.com.au Wed Sep 27 11:29:26 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 27 Sep 2006 11:29:26 +1000 Subject: ExitOnForwardFailure and Protocol 2.0 In-Reply-To: <20060927010724.GA548@orville.25thandClement.com> References: <20060927000916.GA31752@orville.25thandClement.com> <4519C9C2.1070006@zip.com.au> <20060927010724.GA548@orville.25thandClement.com> Message-ID: <4519D3F6.6040704@zip.com.au> William Ahern wrote: > On Wed, Sep 27, 2006 at 10:45:54AM +1000, Darren Tucker wrote: >> William Ahern wrote: >>> I'm merging my "streamlocal" unix domain socket forwarding patch into 4.4p1 >>> (or rather 20060926 SNAP) and I gather that the ExitOnForwardFailure >>> capability only works for protocol 1.0. >>> >>> Am I misreading things? I was really looking forward to that feature. >> I think so, I use ExitOnForwardFailure with protocol 2 all the time. [...] > Interesting. Then line 2543 of channels.c is confusing me: > > packet_start(SSH2_MSG_GLOBAL_REQUEST); > packet_put_cstring("tcpip-forward"); > packet_put_char(1); /* boolean: want reply */ > packet_put_cstring(address_to_bind); > packet_put_int(listen_port); > packet_send(); > packet_write_wait(); > /* Assume that server accepts the request */ > success = 1; The client sets "want reply", so if the server rejects the request then the client will find out about it when the reply comes back. This is handled in ssh.c:client_global_request_reply_fwd(). -- 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 Wed Sep 27 11:49:47 2006 From: william at 25thandClement.com (William Ahern) Date: Tue, 26 Sep 2006 18:49:47 -0700 Subject: ExitOnForwardFailure and Protocol 2.0 In-Reply-To: <4519D3F6.6040704@zip.com.au> References: <20060927000916.GA31752@orville.25thandClement.com> <4519C9C2.1070006@zip.com.au> <20060927010724.GA548@orville.25thandClement.com> <4519D3F6.6040704@zip.com.au> Message-ID: <20060927014947.GA24920@orville.25thandClement.com> On Wed, Sep 27, 2006 at 11:29:26AM +1000, Darren Tucker wrote: > The client sets "want reply", so if the server rejects the request then > the client will find out about it when the reply comes back. This is > handled in ssh.c:client_global_request_reply_fwd(). > D'oh. I suspected that, and I even grep'd for exit_on_forward_failure to track it down and somehow I missed it. Thank you, BTW. Diving back into the code after a 6 month hiatus is disorienting ;) From rd at rd1.net Wed Sep 27 23:25:48 2006 From: rd at rd1.net (Ralf Durkee) Date: Wed, 27 Sep 2006 09:25:48 -0400 Subject: umask and logging in openssh Message-ID: <451A7BDC.8030908@rd1.net> I looked through the FAQ and archive and haven't seen an mention of this. Has it been considered making the sftp logging patch maintain by Michael Martinez at sftplogging.sourceforge.net a part of the main stream sftp-server? Being able to configure the default umask for sftp users who don't run a shell, and providing ftp level logging functionality typically available in other ftp servers to be important security features that openssh should provide by default. Is there any history on this that I'm not aware of? Thanks, -- Ralf Durkee, CISSP, GSEC, GCIH, GSNA Principal Security Consultant http://rd1.net From djm at cvs.openbsd.org Thu Sep 28 07:08:47 2006 From: djm at cvs.openbsd.org (Damien Miller) Date: Wed, 27 Sep 2006 15:08:47 -0600 (MDT) Subject: Announce: OpenSSH 4.4 released Message-ID: <200609272108.k8RL8l0x012236@cvs.openbsd.org> OpenSSH 4.4 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.3: ============================ Security bugs resolved in this release: * Fix a pre-authentication denial of service found by Tavis Ormandy, that would cause sshd(8) to spin until the login grace time expired. * Fix an unsafe signal hander reported by Mark Dowd. The signal handler was vulnerable to a race condition that could be exploited to perform a pre-authentication denial of service. On portable OpenSSH, this vulnerability could theoretically lead to pre-authentication remote code execution if GSSAPI authentication is enabled, but the likelihood of successful exploitation appears remote. * On portable OpenSSH, fix a GSSAPI authentication abort that could be used to determine the validity of usernames on some platforms. This release includes the following new functionality and fixes: * Implemented conditional configuration in sshd_config(5) using the "Match" directive. This allows some configuration options to be selectively overridden if specific criteria (based on user, group, hostname and/or address) are met. So far a useful subset of post- authentication options are supported and more are expected to be added in future releases. * Add support for Diffie-Hellman group exchange key agreement with a final hash of SHA256. * Added a "ForceCommand" directive to sshd_config(5). Similar to the command="..." option accepted in ~/.ssh/authorized_keys, this forces the execution of the specified command regardless of what the user requested. This is very useful in conjunction with the new "Match" option. * Add a "PermitOpen" directive to sshd_config(5). This mirrors the permitopen="..." authorized_keys option, allowing fine-grained control over the port-forwardings that a user is allowed to establish. * Add optional logging of transactions to sftp-server(8). * ssh(1) will now record port numbers for hosts stored in ~/.ssh/authorized_keys when a non-standard port has been requested. * Add an "ExitOnForwardFailure" option to cause ssh(1) to exit (with a non-zero exit code) when requested port forwardings could not be established. * Extend sshd_config(5) "SubSystem" declarations to allow the specification of command-line arguments. * Replacement of all integer overflow susceptible invocations of malloc(3) and realloc(3) with overflow-checking equivalents. * Many manpage fixes and improvements * New portable OpenSSH-specific features: - Add optional support for SELinux, controlled using the --with-selinux configure option (experimental) - Add optional support for Solaris process contracts, enabled using the --with-solaris-contracts configure option (experimental) This option will also include SMF metadata in Solaris packages built using the "make package" target - Add optional support for OpenSSL hardware accelerators (engines), enabled using the --with-ssl-engine configure option. * Bugs from http://bugzilla.mindrot.org fixed: #482 - readconf doesn't accept paths with spaces in them. #906 - syslog messages from sshd [net] lost. #975 - Kerberos authentication timing can leak information about account validity. #981 - Flow stop in SSH2. #1102 - C program 'write' with zero length hangs. #1129 - sshd hangs for command-only invocations due to fork/child signals. #1131 - error "buffer_append_space:alloc not supported" #1138 - Passphrase asked for (but ignored) if key file permissions too liberal.. #1156 - Closes connection after C-c is pressed on QNX. #1157 - ssh-keygen doesn't handle DOS line breaks. #1159 - %u and %h not handled in IdentityFile. #1161 - scp -r fails. #1162 - Inappropriate sequence of syslog messages. #1166 - openssh-4.3p1 has some issues compiling. #1171 - configure can't always figure out LLONG_MAX.. #1173 - scp reports lost connection for very large files. #1177 - Incorrect sshrc file location in Makefile.in. #1179 - sshd incorrectly rejects connections due to IP options. #1181 - configure should detect when openssl-0.9.8x needs -ldl. #1186 - ssh tries multiple times to open unprotected keys. #1188 - keyboard-interactive should not allow retry after pam_acct_mgmt fails. #1193 - Open ssh will not allow changing of passwords on usernames greater than 8 characters.. #1201 - Bind address information is not specified in command line help messages. #1203 - configure.ac is missing an open [. #1207 - sshd does not clear unsuccessful login count on non-interactive logins. #1218 - GSSAPI client code permits SPNEGO usage. #1221 - Banner only suppressed at log level = QUIET (used to be at log level < INFO). * Fixes to memory and file descriptor leaks reported by the Coverity static analysis tool * Fixes to inconsistent pointer checks reported by the Stanford SATURN tool Thanks to everyone who has contributed patches, reported bugs and tested releases. Checksums: ========== - SHA1 (openssh-4.4.tar.gz) = 2294b5e5a591420aa05ff607c1890ab622ace878 - SHA1 (openssh-4.4p1.tar.gz) = 6a52b1dee1c2c9862923c0008d201d98a7fd9d6c 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 Greg.Dunkel at mail.cuny.edu Fri Sep 29 04:24:55 2006 From: Greg.Dunkel at mail.cuny.edu (Greg.Dunkel at mail.cuny.edu) Date: Thu, 28 Sep 2006 14:24:55 -0400 Subject: compiling openssh 4.3.2p on Solaris 10 Message-ID: I used Sun's version of gcc, which is in two packages: SUNW0gccfss and SUNW0scgfss. (Sun also has backported its version of gcc to Solaris 9). These is the compiler that was used to build Open Solaris. Before I tried compiling openssh, I built tcp_wrappers, zlib-1.2.3 and openssl-0.9.8c. My configuration line was ./configure --with-tcp-wrappers=... --with-ssl-dir=... --with-zlib=... --with-pid-dir=... No trouble with configure and openssh built with just a few warnings on the first try. But the command make tests terminated with a fatal error until I added 127.0. to /etc/hosts.allow which is a nice confirmation of tcp_wrappers support. Now figuring out how to modify S10's startup process to accpet openssh is my next adventure, but not relevant to this discussion list. Depending on how our introduction/migration to S10 goes, I will either install Openssh 4.3 or put the new and improved version of Openssh 4.4 on the servers. /greg From Tejeswar.Pichuka at tellabs.com Fri Sep 29 08:52:00 2006 From: Tejeswar.Pichuka at tellabs.com (Pichuka, Tejeswar) Date: Thu, 28 Sep 2006 15:52:00 -0700 Subject: Corrupted check bytes on input with SSH1 - OpenSSH-4.3 and OpenSSL-0.9.6b Message-ID: <03B46B096F6ABD4D854385A7B28C2362D8DA85@USPAEX1.tellabs-west.tellabsinc.net> I am getting the error "Corrupted check bytes on input" from the SSH server when I try to connect using SSH1 protocol. The same OpenSSL-4.3 and OpenSSL-0.9.6b work just fine when I try to connect using SSH2. Has any one heard of any incompatibility issue with ciphers of the OpenSSL version mentioned in the subject? I have found that there was an issue like this (URL below) at one time but with OpenSSL-0.9.5a and earlier. And, OpenSSH-4.3 seems to have those fixes. http://bugzilla.mindrot.org/show_bug.cgi?id=138 Any pointers are very much appreciated. Thanks Tejeswar ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ From tim at multitalents.net Fri Sep 29 13:07:26 2006 From: tim at multitalents.net (Tim Rice) Date: Thu, 28 Sep 2006 20:07:26 -0700 (PDT) Subject: compiling openssh 4.3.2p on Solaris 10 In-Reply-To: References: Message-ID: On Thu, 28 Sep 2006, Greg.Dunkel at domino1.cuny.edu wrote: > Now figuring out how to modify S10's startup process to accpet openssh is > my next adventure, but not relevant to this discussion list. Depending on Check out --with-solaris-contracts in 4.4p1 > how our introduction/migration to S10 goes, I will either install Openssh > 4.3 or put the new and improved version of Openssh 4.4 on the servers. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From marius173 at mchsi.com Fri Sep 29 12:20:23 2006 From: marius173 at mchsi.com (Marius Schamschula) Date: Thu, 28 Sep 2006 21:20:23 -0500 Subject: OpenSSH 4.4p1 under Mac OS X 10.3.9 Message-ID: <0BDACA35-FC68-4FDB-BEEE-27574B169147@mchsi.com> Hi there, I've run into a strange problem. I have just finished building OpenSSH 4.4p1 against openssl 0.9.8d under Mac OS X 10.3.9 and 10.4.7. Both were installed as updates to OpenSSH 4.3p2/openssl 0.9.8c (not Apple's obsolete versions which are bypassed). The 10.4.7 build works as expected, whereas the 10.3.9 build throws Disconnecting: Bad packet length 2477450673. when I try to connect to the machine. I googled this and found that this may be a protocol mismatch (unlikely, since 4.3p2 should have shown the same problem), but also saw a mention of a compile problem. I downgraded to the previous version and can again connect to the machine. This does not fix the security problems, however. Any ideas? Marius -- Marius Schamschula Webmaster The Huntsville Macintosh Users Group www.hmug.org webmaster at hmug dot org marius at schamschula dot com From dtucker at zip.com.au Fri Sep 29 20:15:29 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 29 Sep 2006 20:15:29 +1000 Subject: OpenSSH 4.4p1 under Mac OS X 10.3.9 In-Reply-To: <0BDACA35-FC68-4FDB-BEEE-27574B169147@mchsi.com> References: <0BDACA35-FC68-4FDB-BEEE-27574B169147@mchsi.com> Message-ID: <451CF241.90609@zip.com.au> Marius Schamschula wrote: > Hi there, > > I've run into a strange problem. I have just finished building > OpenSSH 4.4p1 against openssl 0.9.8d under Mac OS X 10.3.9 and > 10.4.7. Both were installed as updates to OpenSSH 4.3p2/openssl > 0.9.8c (not Apple's obsolete versions which are bypassed). The 10.4.7 > build works as expected, whereas the 10.3.9 build throws > > Disconnecting: Bad packet length 2477450673. When you built openssl 0.9.8d, did you run its tests ("make tests")? Did it pass or fail? -- 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 Sep 29 22:15:48 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 29 Sep 2006 22:15:48 +1000 Subject: OpenSSH 4.4p1 under Mac OS X 10.3.9 In-Reply-To: <5A3002EA-00B9-4DA7-A00C-5DA8E8252985@mchsi.com> References: <0BDACA35-FC68-4FDB-BEEE-27574B169147@mchsi.com> <451CF241.90609@zip.com.au> <5A3002EA-00B9-4DA7-A00C-5DA8E8252985@mchsi.com> Message-ID: <20060929121548.GA8131@gate.dtucker.net> (cc:'ed the list, someone else may have some suggestions) On Fri, Sep 29, 2006 at 06:13:16AM -0500, Marius Schamschula wrote: > Darren, > > openssl 0.9.8d passed all tests. OK that's useful. (Not definitive, I have recently found one problem that the tests don't catch.) > A bit more information in this matter: > > I built openssh 4.4.p1 against both openssl 0.9.8d and then 0.9.8c. > Neither version worked. > I then rebuilt 4.3.p2 against openssl 0.9.8d and it works. OK, in summary to make sure I have this right: OS X 10.4.7, openssl 0.9.8d: openssh 4.3p2 and 4.4p1 both work OS X 10.3.9, openssl 0.9.8c: openssh 4.3p2 works, 4.4p1 doesn't OS X 10.3.9, openssl 0.9.8d: openssh 4.3p2 works, 4.4p1 doesn't Presumably the 10.3.9 builds were against the exact same binaries of OpenSSL? Could you please provide a client debug trace (ssh -vvv server) to show where it's blowing up? -- 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 R.Sokoll at intershop.de Sat Sep 30 01:14:18 2006 From: R.Sokoll at intershop.de (Rainer Sokoll) Date: Fri, 29 Sep 2006 17:14:18 +0200 Subject: Problem with openssh-4.4p1 Message-ID: <20060929151417.GS14616@jitsol10-3.intershop.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, FYI: I had to add #include to entropy.c to get ssh compiled. My configure was: ./configure --prefix=/usr/local/openssh-4.4p1 \ - --with-ssl-dir=/usr/local/openssl-0.9.8d \ - --with-zlib=/usr/local/zlib-1.2.3 --with-rand-helper \ - --with-prngd-socket=/var/run/prng_sock Cheers, Rainer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (SunOS) iD8DBQFFHThIkREbzwaW4XMRAnPSAJ9gPCEt4YSpgaFcu5BeRX+mIhWW9ACfVikL CzPD2ONCbUuRfRTGViWosLI= =zxnE -----END PGP SIGNATURE----- From rapier at psc.edu Sat Sep 30 07:17:03 2006 From: rapier at psc.edu (Chris Rapier) Date: Fri, 29 Sep 2006 17:17:03 -0400 Subject: HPN-SSH for OpenSSH 4.4p1 Available Message-ID: <451D8D4F.2090008@psc.edu> This is a preliminary release and as such should be used at your own risk. In my testing the application builds under OS X and Linux, passes the regression tests, and file transfer tests on our test connections exhibited a 1600% increase in performance (1.4MB/s versus 20.9MB/s 46ms RTT). This patch (hpn12v10) is available from http://www.psc.edu/networking/projects/hpn-ssh/openssh-4.4p1-hpn.diff.gz This patch is not linked off of the main web page as of yet. I want to run some more usage tests on it and get some feedback from people. I'm also trying to figure out a non-horrific way of passing an additional value to some of the buffer_* functions. :) If you do install it please let me know what your experiences are. Please make sure your system send and receive buffers are properly tuned (http://www.psc.edu/networking/projects/tcptune). Thanks! Chris Rapier From des at des.no Sat Sep 30 22:31:53 2006 From: des at des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Sat, 30 Sep 2006 14:31:53 +0200 Subject: on FreeBSD Message-ID: <868xk1leme.fsf@dwp.des.no> FreeBSD's requires u_char to be defined: checking net/if_tap.h usability... no checking net/if_tap.h presence... yes configure: WARNING: net/if_tap.h: present but cannot be compiled configure: WARNING: net/if_tap.h: check for missing prerequisite headers? configure: WARNING: net/if_tap.h: see the Autoconf documentation configure: WARNING: net/if_tap.h: section "Present But Cannot Be Compiled" configure: WARNING: net/if_tap.h: proceeding with the preprocessor's result configure: WARNING: net/if_tap.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## checking for net/if_tap.h... yes from config.log: configure:6422: checking net/if_tap.h usability configure:6434: gcc -c -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compa re conftest.c >&5 In file included from conftest.c:47: /usr/include/net/if_tap.h:49: error: syntax error before "u_char" configure:6440: $? = 1 DES -- Dag-Erling Sm?rgrav - des at des.no From des at des.no Sat Sep 30 23:14:02 2006 From: des at des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Sat, 30 Sep 2006 15:14:02 +0200 Subject: audit-bsm.c lacks Message-ID: <864puplco5.fsf@dwp.des.no> #include was removed from includes.h in July: ---------------------------- revision 1.113 date: 2006/07/12 12:22:46; author: dtucker; state: Exp; lines: +1 -2 - stevesk at cvs.openbsd.org 2006/07/11 20:07:25 [scp.c auth.c monitor.c serverloop.c sftp-server.c sshpty.c readpass.c sshd.c monitor_wrap.c monitor_fdpass.c ssh-agent.c ttymodes.c atomicio.c includes.h session.c sshlogin.c monitor_mm.c packet.c sshconnect2.c sftp-client.c nchan.c clientloop.c sftp.c misc.c canohost.c channels.c ssh-keygen.c progressmeter.c uidswap.c msg.c readconf.c sshconnect.c] move #include out of includes.h; ok markus@ ---------------------------- However, it was never added to audit-bsm.c, which references errno twice: cc -O2 -pipe -march=pentium4 -I/usr/src/secure/usr.sbin/sshd/../../../crypto/openssh -include ssh_namespace.h -DUSE_BSM_AUDIT -DGSSAPI -DHAVE_GSSAPI_GSSAPI_H=1 -DKRB5 -DHEIMDAL -DXAUTH_PATH=\"/usr/X11R6/bin/xauth\" -DNO_IDEA -g -c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/audit-bsm.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/audit-bsm.c: In function `bsm_audit_record': /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/audit-bsm.c:175: error: `errno' undeclared (first use in this function) /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/audit-bsm.c:175: error: (Each undeclared identifier is reported only once /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/audit-bsm.c:175: error: for each function it appears in.) /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/audit-bsm.c: In function `bsm_audit_session_setup': /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/audit-bsm.c:208: error: `errno' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/secure/usr.sbin/sshd. *** Error code 1 Stop in /usr/src/secure/usr.sbin. *** Error code 1 Stop in /usr/src/secure. DES -- Dag-Erling Sm?rgrav - des at des.no