From bugzilla-daemon at mindrot.org Sat Feb 1 05:13:12 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 1 Feb 2003 05:13:12 +1100 (EST) Subject: [Bug 482] New: token parsed at first space in path Message-ID: <20030131181312.2B34664894@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=482 Summary: token parsed at first space in path Product: Portable OpenSSH Version: 3.5p1 Platform: ix86 OS/Version: Cygwin on NT/2k Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: spaceacademy at hotmail.com If I modify my config to change Identityfile to something like: Identityfile /cygdrive/c/documents and settings/user/my documents/.ssh/id_rsa process_config_line() of readconf.c just calls strdelim() once so the path will be truncated at the first space. ssh fails with the error that there is garbage at the end of this line. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From phil at ipom.com Sat Feb 1 09:59:36 2003 From: phil at ipom.com (Phil Dibowitz) Date: Fri, 31 Jan 2003 14:59:36 -0800 Subject: [Semi-OT]: Mirroring openssh.org Message-ID: <3E3AFFD8.4050709@ipom.com> I figure this probably isn't the most appropriate place for this question, buuuuut, I can't seem to find the information I need on the [http|ftp] site. I'm responsible for a new Mirror site here at USC, and one of the many things we would like to mirror is the OpenSSH software. However, I can't seem to find the following information: - What is the prefered place to mirror from? - Who do I contact to inform them when the mirror is completed and available for public consumption - What is the preferred method for mirroring (we prefer rsync for obvious reasons, but are willing to use other means) - What are requirements and stipulations are there for being an 'official' mirror of OpenSSH? At USC we have pretty sweet connections to I2, Los Netos, and the like, so we can handle a pretty hefty chunk of bandwidth... Thanks, -- Phil Dibowitz phil at ipom.com Freeware and Technical Pages Insanity Palace of Metallica http://home.earthlink.net/~jaymzh666/ http://www.ipom.com/ "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin, 1759 From jpiszcz at lucidpixels.com Sat Feb 1 06:24:24 2003 From: jpiszcz at lucidpixels.com (jpiszcz) Date: Fri, 31 Jan 2003 14:24:24 -0500 Subject: OpenSSH & OpenSSL directory location problem. Message-ID: <3E3ACD68.7000208@lucidpixels.com> Problem: scp does not work with custom openssl library location OpenSSH & OpenSSL directory location problem. checking whether snprintf correctly terminates long strings... yes checking whether getpgrp requires zero arguments... yes checking OpenSSL header version... 90608f (OpenSSL 0.9.6h [engine] 5 Dec 2002) checking OpenSSL library version... 90608f (OpenSSL 0.9.6h [engine] 5 Dec 2002) checking whether OpenSSL's headers match the library... yes checking for crypt in -lcrypt... yes checking whether OpenSSL's PRNG is internally seeded... yes checking for ls... /bin/ls As you can see it finds it just fine by using the GCC variables below. Host: i686-pc-linux-gnu Compiler: gcc Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized Preprocessor flags: -I/vapp/include Linker flags: -L/vapp/lib Libraries: -lutil -lz -lnsl -lcrypto -lcrypt # GCC Variables (works with all programs, except OpenSSH. export C_INCLUDE_PATH=/vapp/include:/usr/X11R6/include export CPLUS_INCLUDE_PATH=/vapp/include:/usr/X11R6/include export LIBRARY_PATH=/vapp/lib # So, also included these: export LDFLAGS=-L/vapp/lib export CPPFLAGS=-I/vapp/include # Also tried this option. --without-rpath Disable auto-added -R linker paths # Yet, with every one of these, I get this error with SCP ONLY (SSH=FINE) $ scp war at p300:/home/war/ping6 . war at p300's password: scp: error while loading shared libraries: libcrypto.so.0.9.6: cannot open shared object file: No such file or directory Why is this? The daemon (sshd) works fine with no errors of the sort. Yet, when doing an SCP I get the error as defined above. [war at war war]$ ssh p300 war at p300's password: Last login: Fri Jan 31 13:39:58 2003 from 192.168.168.24 war at p300:~$ ( no problems ) control-d Connection to p300 closed. [war at war war]$ Connection to p300 closed. [war at war war]$ scp war at p300:/home/war/ping6 . war at p300's password: scp: error while loading shared libraries: libcrypto.so.0.9.6: cannot open shared object file: No such file or directory [war at war war]$ war at p300:~$ ldd `which sshd` libutil.so.1 => /lib/libutil.so.1 (0x40016000) libz.so.1 => /vapp/lib/libz.so.1 (0x40019000) libnsl.so.1 => /lib/libnsl.so.1 (0x40027000) libcrypto.so.0.9.6 => /vapp/lib/libcrypto.so.0.9.6 (0x4003c000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40109000) libc.so.6 => /lib/libc.so.6 (0x40136000) libdl.so.2 => /lib/libdl.so.2 (0x40259000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) war at p300:~$ war at p300:~$ ldd `which sshd` libutil.so.1 => /lib/libutil.so.1 (0x40016000) libz.so.1 => /vapp/lib/libz.so.1 (0x40019000) libnsl.so.1 => /lib/libnsl.so.1 (0x40027000) libcrypto.so.0.9.6 => /vapp/lib/libcrypto.so.0.9.6 (0x4003c000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40109000) libc.so.6 => /lib/libc.so.6 (0x40136000) libdl.so.2 => /lib/libdl.so.2 (0x40259000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) war at p300:~$ echo $PATH /vapp/bin:/vapp/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin war at p300:~$ echo $LD_LIBRARY_PATH /vapp/lib:/lib:/usr/lib:/usr/X11R6/lib war at p300:~$ So question = why does it work fine with sshd and not scp? From dtucker at zip.com.au Sat Feb 1 10:53:44 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 01 Feb 2003 10:53:44 +1100 Subject: OpenSSH & OpenSSL directory location problem. References: <3E3ACD68.7000208@lucidpixels.com> Message-ID: <3E3B0C88.254CACCE@zip.com.au> jpiszcz wrote: > war at p300's password: > scp: error while loading shared libraries: libcrypto.so.0.9.6: cannot > open shared object file: No such file or directory [snip] > So question = why does it work fine with sshd and not scp? The error is coming from the scp running at the other end of the ssh connection. Maybe LD_LIBRARY_PATH is different when logging on non-interactively? Try ssh user at host '/bin/echo $LD_LIBRARY_PATH' -- 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 jpiszcz at lucidpixels.com Sat Feb 1 11:36:12 2003 From: jpiszcz at lucidpixels.com (jpiszcz) Date: Fri, 31 Jan 2003 19:36:12 -0500 Subject: OpenSSH & OpenSSL directory location problem. References: <3E3ACD68.7000208@lucidpixels.com> <3E3B0C88.254CACCE@zip.com.au> Message-ID: <3E3B167C.80903@lucidpixels.com> [war at war war]$ ssh war at p300 '/bin/echo $LD_LIBRARY_PATH' war at p300's password: [war at war war]$ Possible bug in SSH? Darren Tucker wrote: >jpiszcz wrote: > > >>war at p300's password: >>scp: error while loading shared libraries: libcrypto.so.0.9.6: cannot >>open shared object file: No such file or directory >> >> >[snip] > > >>So question = why does it work fine with sshd and not scp? >> >> > >The error is coming from the scp running at the other end of the ssh >connection. Maybe LD_LIBRARY_PATH is different when logging on >non-interactively? > >Try ssh user at host '/bin/echo $LD_LIBRARY_PATH' > > > From mouring at etoh.eviladmin.org Sat Feb 1 11:48:11 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 31 Jan 2003 18:48:11 -0600 (CST) Subject: OpenSSH & OpenSSL directory location problem. In-Reply-To: <3E3B167C.80903@lucidpixels.com> Message-ID: No just means you didn't set the LD_LIBRARY_PATH in your non-interactive login shell path. Nothing to do with SSH. - Ben On Fri, 31 Jan 2003, jpiszcz wrote: > [war at war war]$ ssh war at p300 '/bin/echo $LD_LIBRARY_PATH' > war at p300's password: > > [war at war war]$ > > Possible bug in SSH? > > Darren Tucker wrote: > > >jpiszcz wrote: > > > > > >>war at p300's password: > >>scp: error while loading shared libraries: libcrypto.so.0.9.6: cannot > >>open shared object file: No such file or directory > >> > >> > >[snip] > > > > > >>So question = why does it work fine with sshd and not scp? > >> > >> > > > >The error is coming from the scp running at the other end of the ssh > >connection. Maybe LD_LIBRARY_PATH is different when logging on > >non-interactively? > > > >Try ssh user at host '/bin/echo $LD_LIBRARY_PATH' > > > > > > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From jpiszcz at lucidpixels.com Sat Feb 1 11:58:54 2003 From: jpiszcz at lucidpixels.com (jpiszcz) Date: Fri, 31 Jan 2003 19:58:54 -0500 Subject: OpenSSH & OpenSSL directory location problem. References: Message-ID: <3E3B1BCE.4040307@lucidpixels.com> I am aware of setting the LD_LIBRARY_PATH in an interactive shell: /etc/profile /etc/bashrc ~/.bashrc ~/.bash_profile ~/.profile How do you set the non-interactive one? Ben Lindstrom wrote: >No just means you didn't set the LD_LIBRARY_PATH in your non-interactive >login shell path. Nothing to do with SSH. > >- Ben > >On Fri, 31 Jan 2003, jpiszcz wrote: > > > >>[war at war war]$ ssh war at p300 '/bin/echo $LD_LIBRARY_PATH' >>war at p300's password: >> >>[war at war war]$ >> >>Possible bug in SSH? >> >>Darren Tucker wrote: >> >> >> >>>jpiszcz wrote: >>> >>> >>> >>> >>>>war at p300's password: >>>>scp: error while loading shared libraries: libcrypto.so.0.9.6: cannot >>>>open shared object file: No such file or directory >>>> >>>> >>>> >>>> >>>[snip] >>> >>> >>> >>> >>>>So question = why does it work fine with sshd and not scp? >>>> >>>> >>>> >>>> >>>The error is coming from the scp running at the other end of the ssh >>>connection. Maybe LD_LIBRARY_PATH is different when logging on >>>non-interactively? >>> >>>Try ssh user at host '/bin/echo $LD_LIBRARY_PATH' >>> >>> >>> >>> >>> >>_______________________________________________ >>openssh-unix-dev mailing list >>openssh-unix-dev at mindrot.org >>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >> >> >> > > > > > From bugzilla-daemon at mindrot.org Sat Feb 1 12:02:46 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 1 Feb 2003 12:02:46 +1100 (EST) Subject: [Bug 483] New: scp issues "invalid user name" for a user name containing a blank Message-ID: <20030201010246.9862F6454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=483 Summary: scp issues "invalid user name" for a user name containing a blank Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: lazanoff at nas.nasa.gov scp file "FirstName LastName"@domain.com: produces "invalid user name" but ssh "FirstName LastName"@domain.com works. I've seen this error with openssh 3.5p1, with Irix scp v3.4 and on Solaris scp v3.0.2p1. The presence of a space is sufficient to produce the "invalid user name" diagnostic. Sorry but PC users often have user names of this form and probably a few Mac users, too. scp.c contains function okname that issues the "invalid user name" but since it really doesn't check with the remote host, scp doesn't really know whether the name is OK anyway. Unless there's some other reason for doing this check, I recommend just doing away with this function. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Darren.Moffat at Sun.COM Sat Feb 1 12:33:29 2003 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Fri, 31 Jan 2003 17:33:29 -0800 (PST) Subject: OpenSSH & OpenSSL directory location problem. In-Reply-To: <3E3ACD68.7000208@lucidpixels.com> Message-ID: On Fri, 31 Jan 2003, jpiszcz wrote: > Problem: scp does not work with custom openssl library location > > As you can see it finds it just fine by using the GCC variables below. > > Host: i686-pc-linux-gnu > Compiler: gcc > Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized > Preprocessor flags: -I/vapp/include > Linker flags: -L/vapp/lib > Libraries: -lutil -lz -lnsl -lcrypto -lcrypt This isn't fine, there should be a -R/vapp/lib in the linker flags. Without -R you need to set LD_LIBRARY_PATH at run time. LD_LIBRARY_PATH is really a debug aid and should be avoided if at all possible. Adding a -L without a corresponding -R is probably a bug in the configure script - I don't know anything about autoconf so I don't know if it is autoconf or the template that has needs to be updated. Alternates on Linux are adding /vapp/lib to /etc/ld.so.config. On Solaris 8 use crle(1m). If you need to make the binaries relocatable and have the lib dir at a set location from the bin dir: eg ..../bin/scp and ..../lib/libcrypto.so then you can use the $ORIGIN variable for -R on Solaris (and I believe on Linux as well). -- Darren J Moffat From dtucker at zip.com.au Sat Feb 1 13:01:25 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 01 Feb 2003 13:01:25 +1100 Subject: Build errors on AIX 4.2.1: nanosleep Message-ID: <3E3B2A75.7C89B1BA@zip.com.au> Hi All. There are still build errors for scp on AIX 4.2.1 due to lack of nanosleep (which you can see them live and in colour at [1]). The attached patch fixes this by using the equivalent nsleep function on AIX if it exists and nanosleep doesn't. The patch is mostly the same as the AIX portion of the previous patch for the nanosleep issue, the major difference being that the #define is in port-aix.h. If this proves necessary for other platforms, it can be moved later (I'm not aware of any other platforms requiring it, though). -Daz. [1] http://dodgynet.dyndns.org/tinderbox/OpenSSH_Portable/status.html -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. -------------- next part -------------- Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v retrieving revision 1.104 diff -u -r1.104 configure.ac --- configure.ac 28 Jan 2003 00:33:44 -0000 1.104 +++ configure.ac 1 Feb 2003 01:49:04 -0000 @@ -388,7 +388,7 @@ rpc/types.h security/pam_appl.h shadow.h stddef.h stdint.h \ strings.h sys/bitypes.h sys/bsdtty.h sys/cdefs.h \ sys/mman.h sys/pstat.h sys/select.h sys/stat.h \ - sys/stropts.h sys/sysmacros.h sys/time.h \ + sys/stropts.h sys/sysmacros.h sys/time.h sys/timers.h \ sys/un.h time.h tmpdir.h ttyent.h usersec.h \ util.h utime.h utmp.h utmpx.h) @@ -604,8 +604,8 @@ clock fchmod fchown freeaddrinfo futimes gai_strerror \ getaddrinfo getcwd getgrouplist getnameinfo getopt getpeereid\ getrlimit getrusage getttyent glob inet_aton inet_ntoa \ - inet_ntop innetgr login_getcapbool md5_crypt memmove \ - mkdtemp mmap ngetaddrinfo openpty ogetaddrinfo pstat readpassphrase \ + inet_ntop innetgr login_getcapbool md5_crypt memmove mkdtemp \ + mmap ngetaddrinfo nsleep openpty ogetaddrinfo pstat readpassphrase \ realpath recvmsg rresvport_af sendmsg setdtablesize setegid \ setenv seteuid setgroups setlogin setproctitle setresgid setreuid \ setrlimit setsid setpcred setvbuf sigaction sigvec snprintf \ 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.6 diff -u -r1.6 port-aix.h --- openbsd-compat/port-aix.h 7 Jul 2002 02:17:36 -0000 1.6 +++ openbsd-compat/port-aix.h 1 Feb 2003 01:49:56 -0000 @@ -25,5 +25,16 @@ */ #ifdef _AIX + +/* AIX 4.2.x doesn't have nanosleep but does have nsleep which is equivalent */ +#if !defined(HAVE_NANOSLEEP) && defined(HAVE_NSLEEP) +# define nanosleep nsleep +#endif + +/* For struct timespec on AIX 4.2.x */ +#ifdef HAVE_SYS_TIMERS_H +# include +#endif + void aix_usrinfo(struct passwd *pw); #endif /* _AIX */ From mouring at etoh.eviladmin.org Sat Feb 1 13:23:48 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 31 Jan 2003 20:23:48 -0600 (CST) Subject: Build errors on AIX 4.2.1: nanosleep In-Reply-To: <3E3B2A75.7C89B1BA@zip.com.au> Message-ID: On Sat, 1 Feb 2003, Darren Tucker wrote: > Hi All. > There are still build errors for scp on AIX 4.2.1 due to lack of > nanosleep (which you can see them live and in colour at [1]). The > attached patch fixes this by using the equivalent nsleep function on AIX > if it exists and nanosleep doesn't. > [..] diff -u -r1.6 port-aix.h --- openbsd-compat/port-aix.h 7 Jul 2002 02:17:36 -0000 1.6 +++ openbsd-compat/port-aix.h 1 Feb 2003 01:49:56 -0000 @@ -25,5 +25,16 @@ */ #ifdef _AIX + +/* AIX 4.2.x doesn't have nanosleep but does have nsleep which is equivalent */ +#if !defined(HAVE_NANOSLEEP) && defined(HAVE_NSLEEP) +# define nanosleep nsleep +#endif + [..] Ok if I change it to: #define nanosleep(req, rem) nsleep(req, rem) I like to see function renaming at a glance. Plus it saves us from wierd bugs down the road (not that I see 'nanosleep' ever being used as a function call or structure =). - Ben From dtucker at zip.com.au Sat Feb 1 13:57:29 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 01 Feb 2003 13:57:29 +1100 Subject: Build errors on AIX 4.2.1: nanosleep References: Message-ID: <3E3B3799.C33CC894@zip.com.au> Ben Lindstrom wrote: > On Sat, 1 Feb 2003, Darren Tucker wrote: > >+# define nanosleep nsleep > > Ok if I change it to: > #define nanosleep(req, rem) nsleep(req, rem) > > I like to see function renaming at a glance. Plus it saves us from wierd > bugs down the road (not that I see 'nanosleep' ever being used as a > function call or structure =). Fine by me. That compiles OK with gcc and xlc. -- 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 jpiszcz at lucidpixels.com Sat Feb 1 14:00:36 2003 From: jpiszcz at lucidpixels.com (jpiszcz) Date: Fri, 31 Jan 2003 22:00:36 -0500 Subject: OpenSSH & OpenSSL directory location problem. References: Message-ID: <3E3B3854.7060305@lucidpixels.com> war at p300:~/openssh-3.5p1$ ./configure --prefix=/app/openssh-3.5p1 --with-md5-passwords --with-ssl --with-privsep-path=/app/openssh-3.5p1/var/empty --with-privsep-user=sshd ; make ; make install standard config as before, but added path to /etc/ld.so.conf, however I've never had to add a path to here to get a certain program/app to work before.. So the ld.so.conf provides the environment for applications which do not provide the environment by default.. Darren J Moffat wrote: >On Fri, 31 Jan 2003, jpiszcz wrote: > > > >>At the end of make: >>gcc: unrecognized option `-R/vapp/lib' >> >> > >I think the linker (ld) on Linux needs a space in between the -R and the / >so try: -R /vapp/lib. If that doesn't work try -rpath /vapp/lib instead. > > > From mouring at etoh.eviladmin.org Sat Feb 1 14:36:30 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 31 Jan 2003 21:36:30 -0600 (CST) Subject: Build errors on AIX 4.2.1: nanosleep In-Reply-To: <3E3B3799.C33CC894@zip.com.au> Message-ID: Umm.. would help if I cvs up before looking at patches. Damien already took care of this a few days ago. - Ben On Sat, 1 Feb 2003, Darren Tucker wrote: > Ben Lindstrom wrote: > > On Sat, 1 Feb 2003, Darren Tucker wrote: > > >+# define nanosleep nsleep > > > > Ok if I change it to: > > #define nanosleep(req, rem) nsleep(req, rem) > > > > I like to see function renaming at a glance. Plus it saves us from wierd > > bugs down the road (not that I see 'nanosleep' ever being used as a > > function call or structure =). > > Fine by me. That compiles OK with gcc and xlc. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From dtucker at zip.com.au Sat Feb 1 14:49:08 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 01 Feb 2003 14:49:08 +1100 Subject: Build errors on AIX 4.2.1: nanosleep References: Message-ID: <3E3B43B4.6A5C281@zip.com.au> Ben Lindstrom wrote: > Umm.. would help if I cvs up before looking at patches. Damien already > took care of this a few days ago. If you're referring to this: 200301028 - (djm) Search libposix4 and librt for nanosleep. From dtucker at zip.com.au and openssh-unix-dev at thewrittenword.com then that doesn't fix the problem I'm referring to (it's Solaris only as far as I know). If you're referring to something else, please let me know what and where. -- 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 mouring at etoh.eviladmin.org Sat Feb 1 15:44:08 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 31 Jan 2003 22:44:08 -0600 (CST) Subject: Build errors on AIX 4.2.1: nanosleep In-Reply-To: <3E3B43B4.6A5C281@zip.com.au> Message-ID: Ok.. Applied. Thanks. - Ben On Sat, 1 Feb 2003, Darren Tucker wrote: > Ben Lindstrom wrote: > > Umm.. would help if I cvs up before looking at patches. Damien already > > took care of this a few days ago. > > If you're referring to this: > > 200301028 > - (djm) Search libposix4 and librt for nanosleep. From > dtucker at zip.com.au > and openssh-unix-dev at thewrittenword.com > > then that doesn't fix the problem I'm referring to (it's Solaris only as > far as I know). > > If you're referring to something else, please let me know what and > where. > > -- > 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 f.illenberger at gmx.net Sat Feb 1 20:12:52 2003 From: f.illenberger at gmx.net (Frank Illenberger) Date: Sat, 1 Feb 2003 10:12:52 +0100 Subject: Feature request: Resuming sftp transfers (reget & reput) Message-ID: <57A617DA-35C5-11D7-AED5-003065CC516A@gmx.net> Dear openssh developers, is there any plan to include the reget & reput commands into the sftp client? The sftp-server seems to already support the needed offset parameters. Frank From bugzilla-daemon at mindrot.org Sat Feb 1 20:21:30 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 1 Feb 2003 20:21:30 +1100 (EST) Subject: [Bug 463] PrintLastLog doesn't work in privsep mode Message-ID: <20030201092130.3912B64552@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=463 ------- Additional Comments From dtucker at zip.com.au 2003-02-01 20:21 ------- AIX has a related problem with loginsuccess(), which generates the equivalent of the LastLogin message. At the moment it's only called for password authentication, so public-key logins don't get the messages or have the /etc/security/lastlog file updated. The patch I'm about to attach to bug #14 fixes this for AIX and PrintLastLog along with fixing #14, however if someone wants to merge this separately I'll split it. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Feb 1 20:38:32 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 1 Feb 2003 20:38:32 +1100 (EST) Subject: [Bug 14] Can't change expired /etc/shadow password without PAM Message-ID: <20030201093832.353B464559@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=14 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #205 is|0 |1 obsolete| | ------- Additional Comments From dtucker at zip.com.au 2003-02-01 20:38 ------- Created an attachment (id=215) --> (http://bugzilla.mindrot.org/attachment.cgi?id=215&action=view) passexpire15: removes privsep call, HP-UX support Adds /bin/passwd-in-session password expiration support. * configure finds passwd * supports /etc/shadow & AIX platforms * uses SIGUSR1 to reset forwarding flags after successful change * warns users of impending account/password expiry * generates and stores AIX & PrintLastLog messages before privsep split (this also fixes bug #463). Changes relative to previous patch: * remove invalid privsep call * remove HP-UX password expiry * detects over-expired AIX password (this will cause passwd to bomb without setting a failure code and thus let the user login) This patch is a cleanup, I don't intend making any further changes unless a flaw is discovered. If it gets in and there's sufficient interest I'll look at re-implementing the HP-UX support (which currently can only do expiry through PAM). The equivalent patch against 3.5p1 will be available at http://www.zip.com.au/~dtucker/openssh/openssh-3.5p1-passexpire15.patch I'd like to acknowledge that these patches are originally based on patches by Pablo Sor (psor at afip gov ar) and Mark Pitt (mark.pitt at ch ibm com) and the AIX loginsuccess() changes are based on work by Kevin Cawlfield (cawlfiel at austin ibm com). ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jpiszcz at lucidpixels.com Sat Feb 1 21:28:36 2003 From: jpiszcz at lucidpixels.com (jpiszcz) Date: Sat, 01 Feb 2003 05:28:36 -0500 Subject: OpenSSH & OpenSSL directory location problem. References: <3E3B3854.7060305@lucidpixels.com> Message-ID: <3E3BA154.7070604@lucidpixels.com> Thanks for the quick responses and help regarding this issue. jpiszcz wrote: > > war at p300:~/openssh-3.5p1$ ./configure --prefix=/app/openssh-3.5p1 > --with-md5-passwords --with-ssl > --with-privsep-path=/app/openssh-3.5p1/var/empty > --with-privsep-user=sshd ; make ; make install > > standard config as before, but added path to /etc/ld.so.conf, however > I've never had to add a path to here to get a certain program/app to > work before.. > > So the ld.so.conf provides the environment for applications which do > not provide the environment by default.. > > > Darren J Moffat wrote: > >> On Fri, 31 Jan 2003, jpiszcz wrote: >> >> >> >>> At the end of make: >>> gcc: unrecognized option `-R/vapp/lib' >>> >> >> >> I think the linker (ld) on Linux needs a space in between the -R and >> the / >> so try: -R /vapp/lib. If that doesn't work try -rpath /vapp/lib >> instead. >> >> >> > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > From bugzilla-daemon at mindrot.org Sun Feb 2 00:08:06 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 2 Feb 2003 00:08:06 +1100 (EST) Subject: [Bug 479] add description how to run a ssh tunnel without a full shell on the remote site Message-ID: <20030201130806.0F1236454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=479 ------- Additional Comments From markus at openbsd.org 2003-02-02 00:08 ------- i don't think this belongs to openssh perhaps you can send a patch for the faq? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Feb 2 00:11:07 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 2 Feb 2003 00:11:07 +1100 (EST) Subject: [Bug 480] extend the -l or -L option to mention the ssh-agent's pid Message-ID: <20030201131107.8E7F164552@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=480 ------- Additional Comments From markus at openbsd.org 2003-02-02 00:11 ------- this does not belong to the -L or -l option ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Feb 2 00:11:39 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 2 Feb 2003 00:11:39 +1100 (EST) Subject: [Bug 481] Extend man page with documentation Message-ID: <20030201131139.B71C064552@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=481 ------- Additional Comments From markus at openbsd.org 2003-02-02 00:11 ------- do you have a patch for the manpage? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From eau at phear.org Sun Feb 2 11:11:36 2003 From: eau at phear.org (Eric AUGE) Date: Sun, 2 Feb 2003 01:11:36 +0100 (CET) Subject: [PATCH] LDAP public key patch. Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, The following patch provide LDAP public key authentication instead of only ~/.ssh/authorized_keys. Allow you to centralize/control easily users authentication on a server farm. Patch: http://ldappubkey.gcu-squad.org/ldappubkey-ossh3.5-2.patch more informations on http://ldappubkey.gcu-squad.org/ Best Regards, - -- Eric. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+PGI7kDU4i9/ie9kRAvjIAJ9r8vEiz3VsTkt5fRz5FfN6cH7KjgCfXiEk YPUEBTQZFRutJIcxvTXLMUg= =5I38 -----END PGP SIGNATURE----- From bugzilla-daemon at mindrot.org Sun Feb 2 21:51:06 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 2 Feb 2003 21:51:06 +1100 (EST) Subject: [Bug 483] scp issues "invalid user name" for a user name containing a blank Message-ID: <20030202105106.D639D64552@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=483 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From markus at openbsd.org 2003-02-02 21:51 ------- fixed for non remote-remote copies. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Feb 2 21:51:48 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 2 Feb 2003 21:51:48 +1100 (EST) Subject: [Bug 472] scp won't accept 'hash' character in usernames, ssh will Message-ID: <20030202105148.C96766454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=472 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From markus at openbsd.org 2003-02-02 21:51 ------- fixed for non remote-remote copies ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From des at ofug.org Sun Feb 2 23:48:52 2003 From: des at ofug.org (Dag-Erling Smorgrav) Date: Sun, 02 Feb 2003 13:48:52 +0100 Subject: PAM merge from FreeBSD In-Reply-To: <20030109214943.A29970@google.com> (Frank Cusack's message of "Thu, 9 Jan 2003 21:49:43 -0800") References: <3E1E2593.3070204@mindrot.org> <20030109214943.A29970@google.com> Message-ID: A non-text attachment was scrubbed... Name: openssh.diff Type: text/x-patch Size: 26073 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030202/c5ce8def/attachment.bin From bugzilla-daemon at mindrot.org Sun Feb 2 23:52:03 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 2 Feb 2003 23:52:03 +1100 (EST) Subject: [Bug 148] Key Exchange Guesses not supported Message-ID: <20030202125203.9195F6454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=148 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From markus at openbsd.org 2003-02-02 23:52 ------- fixed in 3.6 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 3 04:12:52 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 3 Feb 2003 04:12:52 +1100 (EST) Subject: [Bug 480] extend the -l or -L option to mention the ssh-agent's pid Message-ID: <20030202171252.181216454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=480 ------- Additional Comments From hauser at acm.org 2003-02-03 04:12 ------- So what is your suggestion - add a new option? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djm at mindrot.org Mon Feb 3 11:23:41 2003 From: djm at mindrot.org (Damien Miller) Date: Mon, 03 Feb 2003 11:23:41 +1100 Subject: PAM merge from FreeBSD In-Reply-To: References: <3E1E2593.3070204@mindrot.org> <20030109214943.A29970@google.com> Message-ID: <3E3DB68D.2090105@mindrot.org> Dag-Erling Smorgrav wrote: > BTW, the patches Damien posted contain a bug which breaks ssh1 in some > cases. Was this the extra empty query in auth-chall.c? If so, I sent an updated patch which does: Index: auth-chall.c =================================================================== RCS file: /var/cvs/openssh/auth-chall.c,v retrieving revision 1.10 diff -u -r1.10 auth-chall.c --- auth-chall.c 5 Jun 2001 18:56:17 -0000 1.10 +++ auth-chall.c 3 Feb 2003 00:21:38 -0000 @@ -76,6 +76,31 @@ return 0; resp[0] = (char *)response; res = device->respond(authctxt->kbdintctxt, 1, resp); + + /* + * XXX - The PAM kbd-int module likes to postpone authentication, + * and complete it with an empty second query. Unfortunately protocol + * v1 doesn't allows postponement. Kludge around it by resubmitting + * a postponed response and retrying if it comes back with no prompts. + */ + if (res == 1) { + char *name, *instr, **prompts; + u_int *echo_on, nreq, i; + + if (device->query(authctxt->kbdintctxt, + &name, &instr, &nreq, &prompts, &echo_on)) + goto out; + /* v1 only allows a single prompt and we have already sent it */ + if (nreq == 0) + res = device->respond(authctxt->kbdintctxt, 0, resp); + for (i = 0; i < nreq; i++) + xfree(prompts[i]); + xfree(prompts); + xfree(echo_on); + xfree(name); + xfree(instr); + } +out: device->free_ctx(authctxt->kbdintctxt); authctxt->kbdintctxt = NULL; return res ? 0 : 1; From bugzilla-daemon at mindrot.org Mon Feb 3 14:13:10 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 3 Feb 2003 14:13:10 +1100 (EST) Subject: [Bug 479] add description how to run a ssh tunnel without a full shell on the remote site Message-ID: <20030203031310.3D35264552@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=479 ------- Additional Comments From hauser at acm.org 2003-02-03 14:13 ------- I am fine if you rather put it into http://www.openssh.org/faq.html than http://www.openssh.org/manual.html. i) Should the patch be on plain HTML or do you have some more sophisticated format I have to work on (e.g. xml?) ii) (since you are covering both the openssh and the openbsd site) is there maybe yet a better place on the openbsd website? Eg close to the paper reference by David in http://bugzilla.mozilla.org/show_bug.cgi?id=58251#c9 ? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 3 18:22:09 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 3 Feb 2003 18:22:09 +1100 (EST) Subject: [Bug 481] Extend man page with documentation Message-ID: <20030203072209.E84666454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=481 ------- Additional Comments From hauser at acm.org 2003-02-03 18:22 ------- Created an attachment (id=216) --> (http://bugzilla.mindrot.org/attachment.cgi?id=216&action=view) man.cgi.html patch Markus, as per your request. r. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 3 19:50:03 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 3 Feb 2003 19:50:03 +1100 (EST) Subject: [Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport Message-ID: <20030203085003.6D56C6454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=413 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From markus at openbsd.org 2003-02-03 19:50 ------- i'll look into this. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From des at ofug.org Mon Feb 3 20:21:54 2003 From: des at ofug.org (Dag-Erling Smorgrav) Date: Mon, 03 Feb 2003 10:21:54 +0100 Subject: PAM merge from FreeBSD In-Reply-To: <3E3DB68D.2090105@mindrot.org> (Damien Miller's message of "Mon, 03 Feb 2003 11:23:41 +1100") References: <3E1E2593.3070204@mindrot.org> <20030109214943.A29970@google.com> <3E3DB68D.2090105@mindrot.org> Message-ID: Damien Miller writes: > Dag-Erling Smorgrav wrote: > > BTW, the patches Damien posted contain a bug which breaks ssh1 in some > > cases. > Was this the extra empty query in auth-chall.c? If so, I sent an > updated patch which does: Not just that, there's a problem in the monitor code as well. Sometimes the monitor is not aware that authentication succeeded - although it's possible that the auth-chall.c patch hides this bug. I see your code is nearly identical to mine, except for variable names and the use of goto. Great minds think alike :) DES -- Dag-Erling Smorgrav - des at ofug.org From jpiszcz at lucidpixels.com Tue Feb 4 01:01:56 2003 From: jpiszcz at lucidpixels.com (jpiszcz) Date: Mon, 03 Feb 2003 09:01:56 -0500 Subject: No -b (bind) with SCP? Message-ID: <3E3E7654.7000105@lucidpixels.com> In man ssh: -b bind_address Specify the interface to transmit from on machines with multiple interfaces or aliased addresses. For ssh, but also looked in SCP manpage, didn't find anything, anyone know if this option will be supported in future versions of OpenSSH? $ scp -b scp: illegal option -- b usage: scp [-pqrvBC46] [-F config] [-S program] [-P port] [-c cipher] [-i identity] [-o option] [[user@]host1:]file1 [...] [[user@]host2:]file2 $ I have two IP's, one goes out cable, another DSL, ssh -b works fine for binding to either, but I would like to bind to a specific IP when I do SCP transfers. From chris at obelix.hedonism.cx Tue Feb 4 01:30:29 2003 From: chris at obelix.hedonism.cx (Christian Vogel) Date: Mon, 3 Feb 2003 15:30:29 +0100 Subject: No -b (bind) with SCP? In-Reply-To: <3E3E7654.7000105@lucidpixels.com> References: <3E3E7654.7000105@lucidpixels.com> Message-ID: <20030203143029.GA21074@emil.frop.org> Hi jpiszcz, > I have two IP's, one goes out cable, another DSL, ssh -b works fine for > binding to either, but I would like to bind to a specific IP when I do > SCP transfers. try -oBindAddress=YOUR_IPADDRESS. The options you can pass to ssh are documented in ssh-config(5), those are the same ones that you can write in your .ssh/config (or /etc/ssh_config). Chris Bind to the correct ip (not useful, I have only one on this machine)... emil:chris$ scp -oBindAddress=192.168.1.19 sec.txt obelix:delme.txt sec.txt 100% |*****************************| 25510 00:00 ...but you will get an error when you try to bind to the wrong one... emil:chris$ scp -oBindAddress=192.168.1.20 sec.txt obelix:delme.txt bind: 192.168.1.20: Cannot assign requested address -- Curiosity killed the cat. And, in fact, curiosity could kill Schr?dinger's Cat -- and quite often does -- 50% of the time. From jpiszcz at lucidpixels.com Tue Feb 4 01:36:15 2003 From: jpiszcz at lucidpixels.com (jpiszcz) Date: Mon, 03 Feb 2003 09:36:15 -0500 Subject: No -b (bind) with SCP? References: <3E3E7654.7000105@lucidpixels.com> <20030203143029.GA21074@emil.frop.org> Message-ID: <3E3E7E5F.1040601@lucidpixels.com> Ah, nice, thanks! Christian Vogel wrote: >Hi jpiszcz, > > > >>I have two IP's, one goes out cable, another DSL, ssh -b works fine for >>binding to either, but I would like to bind to a specific IP when I do >>SCP transfers. >> >> > >try -oBindAddress=YOUR_IPADDRESS. The options you can pass to ssh are >documented in ssh-config(5), those are the same ones that you can write >in your .ssh/config (or /etc/ssh_config). > > Chris > > >Bind to the correct ip (not useful, I have only one on this machine)... > >emil:chris$ scp -oBindAddress=192.168.1.19 sec.txt obelix:delme.txt >sec.txt 100% |*****************************| 25510 00:00 > >...but you will get an error when you try to bind to the wrong one... > >emil:chris$ scp -oBindAddress=192.168.1.20 sec.txt obelix:delme.txt >bind: 192.168.1.20: Cannot assign requested address > > > > From wknox at mitre.org Tue Feb 4 03:30:36 2003 From: wknox at mitre.org (William R. Knox) Date: Mon, 3 Feb 2003 11:30:36 -0500 (EST) Subject: From RISKS: secret scrubbing code removed by optimizers In-Reply-To: <3DCC5508.AB5EF6D5@zip.com.au> Message-ID: A very belated response, but... In addition, someone would want to scan /dev/kmem instead of replacing sshd because you may run Tripwire or an equivalent that will notify you of a modified sshd. It is a bit harder to notify you of a scan of /dev/kmem. Bill Knox Senior Operating Systems Programmer/Analyst The MITRE Corporation On Sat, 9 Nov 2002, Darren Tucker wrote: > Date: Sat, 09 Nov 2002 11:21:28 +1100 > From: Darren Tucker > To: Thomas Binder > Cc: OpenSSH Devel List > Subject: Re: From RISKS: secret scrubbing code removed by optimizers > > Thomas Binder wrote: > > The question is, though, why someone having access rights to read > > /dev/kmem or swap space wouldn't rather install a trojaned or > > otherwise modified sshd instead to snoop credentials. > > A couple of reasons: > > 1) Malloc doesn't clear memory. Some platforms clear the memory before > malloc gets it, but some don't. On the ones that don't an unprivileged > user can just keep malloc'ing memory and looking for something > interesting. > > 2) If I break into your box today, I could scan /dev/kmem and > potentially find a password you typed in last week. I might have to wait > weeks or months before you get bitten by a trojaned sshd. > > 3) In the worst case the memory containing the password could get > swapped out and remain on disk for *forever*. If I broke into your box > today I might find a password you entered last year. > > These are long shots, but are you willing to bet your password on it? > Every time you enter it? > > -- > 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 at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From des at ofug.org Tue Feb 4 05:31:09 2003 From: des at ofug.org (Dag-Erling Smorgrav) Date: Mon, 03 Feb 2003 19:31:09 +0100 Subject: PAM merge from FreeBSD In-Reply-To: (Dag-Erling Smorgrav's message of "Mon, 03 Feb 2003 10:21:54 +0100") References: <3E1E2593.3070204@mindrot.org> <20030109214943.A29970@google.com> <3E3DB68D.2090105@mindrot.org> Message-ID: A non-text attachment was scrubbed... Name: pam_conv.diff Type: text/x-patch Size: 1128 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030203/2a2cae6f/attachment.bin From adoline at scl.ameslab.gov Tue Feb 4 10:02:42 2003 From: adoline at scl.ameslab.gov (Adam Oline) Date: Mon, 03 Feb 2003 17:02:42 -0600 Subject: Connections over private network, Simon's GSSAPI patch Message-ID: <3E3EF512.3000404@scl.ameslab.gov> I'm sending this to both Simon and openssh-unix-dev because although the problem I'm having actually occurs in Simon's patch, it could be resolved with a change in the main code. We are using openssh-3.4p1 plus Simon's GSSAPI patch to support Kerberos V5 ticket forwarding over ssh protocol 2. We are using OpenAFS for user home directory space, and LDAP for user information, including home directory and password. libpam-openafs-session is used to get an AFS token from the forwarded Krb5 TGT after logging into a machine using openssh+patch. Everything is working fine when we ssh between two machines over a public IP connection. No passwords are needed, krb5 tickets are forwarded using either the external-keyx or gssapi authentication methods, and afs tokens are retrieved. The problem occurs when ssh'ing over the private network connection between two machines. We have a number of two-node clusters where each node has a public IP address, as well as any number of private IP addresses, one for each additional network interface. The additional network interfaces are connected back-to-back, and are used for benchmarking purposes, e.g. seeing how well two gigabit ethernet cards perform back-to-back in the same machine. These benchmarks may be done using raw tcp connections, or using a message passing library such as MPI. Some of the MPI libraries we use, including LAM and MP_Lite (implements a subset of the MPI specification), require the use of ssh as a means of connecting to a remote node and starting the user's executable. Ok, so now I'll finally describe the problem. If I do 'ssh ', the external-keyx and gssapi auth-methods fail, and I end up having to do password authentication, which is a pain. The external-keyx and gssapi methods essentially fail because the server is expecting kerberos credentials for the principal "host/@", but the client is trying to provide credentials for "host/@". Note that we were able to set up distinct kerberos entries for the private ip addresses by adding entries in /etc/hosts to resolve to .., and using the same "private" FQDN in the kerberos database. In order to get a kerberos entry for private IP addresses to work with openssh and Simon's patch, however, we would need to modify Simon's patch to try matching kerberos credentials against all of the kerberos host principals available for the machine, instead of just against the kerberos host principal for the public IP/domain name. This is certainly possible, I think, but our sysadmin has pointed out that it would be simpler on our end to only maintain one kerberos entry per machine, instead of 3 or 4, depending on how many additional interfaces we're testing at once. A somewhat simpler solution is a modification to the openssh code. Prior to doing key exchange and user authentication in ssh_login(), a check could be performed to determine whether the destination hostname corresponds to a public or private IP address. If private IP, then change it to the hostname corresponding to the public IP. Now the client code will use kerberos credentials for the public IP/domain name, and everything runs smoothly. My main concerns here are the security considerations, and whether this might break something, e.g. would the user ever *really* need to connect using a private IP/hostname for the destination rather than the public IP/hostname? I believe the network traffic is still actually going over the private link. On the other hand, the change to hostname could be made deeper inside, specifically in Simon's patch, by passing the modified hostname only to the kerberos code used to build the credentials that are passed to the ssh daemon. In that case, the main concerns are directed to Simon. I'm not sure whether this compromises the security from a Kerberos perspective. It seems to me that a host key is used to identify the *host*, or machine, and even though we're connecting through a different network interface, we're still connecting to the same machine. I apologize for my long-windedness. I hope I explained things clearly. I would appreciate feedback from anyone, especially if this topic has come up before and I've missed it. I tried googling for some relevant information but couldn't find any. I will gladly develop a patch to either the openssh code or openssh+Simon's patch if this seems like a reasonable thing to do. Adam -- Adam Oline Research Helper SCL, Ames Laboratory 515-231-0242 adoline at scl.ameslab.gov From egypt_cat at maktoob.com Tue Feb 4 10:23:10 2003 From: egypt_cat at maktoob.com (Travco Air) Date: Tue, 4 Feb 2003 01:23:10 +0200 Subject: Travco Air Message-ID: <338723609356208@maktoob.com> Your Email Client does not support MIME encoding. Please upgrade to MIME-enabled Email Client (almost every modern Email Client is MIME-capable). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030204/b58f2e0d/attachment.html From rasjidw at openminddev.net Tue Feb 4 23:53:33 2003 From: rasjidw at openminddev.net (Rasjid Wilcox) Date: Tue, 4 Feb 2003 23:53:33 +1100 Subject: Windows port Message-ID: <200302042353.33799.rasjidw@openminddev.net> Quite some time ago (March 98), Gordon Chaffee did a patch to port ssh 1.2.14 to windows. (See http://bmrc.berkeley.edu/people/chaffee/patches/patch-ssh-1.2.14). Has anything along these lines been attempted since, with a more recent version of the openssh client? Cheers, Rasjid. -- Rasjid Wilcox Canberra, Australia (UTC +10 hrs) http://www.openminddev.net From bugzilla-daemon at mindrot.org Wed Feb 5 00:57:33 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 5 Feb 2003 00:57:33 +1100 (EST) Subject: [Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport Message-ID: <20030204135733.5BE966454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=413 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #182 is|0 |1 obsolete| | ------- Additional Comments From dtucker at zip.com.au 2003-02-05 00:57 ------- Created an attachment (id=217) --> (http://bugzilla.mindrot.org/attachment.cgi?id=217&action=view) Implement optional address binding for port forwards (update) Updated based on some feedback from Markus: * re-added incorrectly removed code * simplified GatewayPorts/bindaddress handling * reduced code duplication of parse_forward() * use NULL or 127.0.0.1 instead of localhost ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From buckh at pobox.com Wed Feb 5 01:54:23 2003 From: buckh at pobox.com (Buck Huppmann) Date: Tue, 4 Feb 2003 09:54:23 -0500 Subject: [PATCH] openssh-3.5p1: restore SIGTTOU in readpassphrase() Message-ID: <20030204145422.GA1502@dsl-64-192-58-194.telocity.com> this line seemed to have been dropped somewhere b/w 3.1 and 3.5 --- openssh-3.5p1/openbsd-compat/readpassphrase.c.orig Tue Sep 10 20:29:13 2002 +++ openssh-3.5p1/openbsd-compat/readpassphrase.c Tue Feb 4 08:30:06 2003 @@ -152,6 +152,7 @@ (void)sigaction(SIGTERM, &saveterm, NULL); (void)sigaction(SIGTSTP, &savetstp, NULL); (void)sigaction(SIGTTIN, &savettin, NULL); + (void)sigaction(SIGTTOU, &savettou, NULL); if (input != STDIN_FILENO) (void)close(input); believe it or not, on Solaris 2.6 to 9 when running the csh, ssh never gets a SIGTTIN in readpassphrase() if it's in the background, so it needs to restore the SIGTTOU handler before it resends itself SIGTTOU in order to protect a user from himself if he does this: % ssh foo at bar blurfl & [1] 27315 % Password: Password: Password: Password: Password: Password: Password: Password: Password: Password: that's assuming it somehow manages to buy a SIGTTOU, which it does in our case. (i have no idea how, since i can't see that TOSTOP is set, no how) From carson at taltos.org Wed Feb 5 04:21:48 2003 From: carson at taltos.org (Carson Gaspar) Date: Tue, 04 Feb 2003 12:21:48 -0500 Subject: Connections over private network, Simon's GSSAPI patch In-Reply-To: <3E3EF512.3000404@scl.ameslab.gov> References: <3E3EF512.3000404@scl.ameslab.gov> Message-ID: <370780000.1044379308@belka.ny.ficc.gs.com> Stop shooting yourself in the foot. Run 2 sshd instances, one on the public interface, one on the private interface, and make sure they know their correct host names. The only other sane option I can think of is to add an option to ssh and/or sshd that lets you select which client and/or server kerberos principal(s) to use explicitly, instead of automagically determining them. And that's a lot more work. And belongs in the GSSAPI code. Something like: ssh -oClientPrincipal=carson.admin at taltos.org -oServerPrincipal=host/server.private at taltos.org server.private.taltos.org or (in sshd.conf): ServerPrincipal=host/server.private at taltos.org If your're feeling really studly, have the sshd option take a list of principals. -- Carson From bugzilla-daemon at mindrot.org Wed Feb 5 04:40:32 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 5 Feb 2003 04:40:32 +1100 (EST) Subject: [Bug 484] New: name space collision - log function Message-ID: <20030204174032.F2AE56454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=484 Summary: name space collision - log function Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: rusr at cup.hp.com The function log() (described in log.h) causes a name space collision with the math library function log(3m). If any library that is linked with ssh (or any component) should happen to call the math library log() function, problems will arise. For my own temporary workaround, I changed the name in log.h from log() to ssh_log() and added this statement at the end of log.h: #define log ssh_log ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From nectar at FreeBSD.org Wed Feb 5 04:45:07 2003 From: nectar at FreeBSD.org (Jacques A. Vidrine) Date: Tue, 4 Feb 2003 11:45:07 -0600 Subject: Connections over private network, Simon's GSSAPI patch In-Reply-To: <370780000.1044379308@belka.ny.ficc.gs.com> References: <3E3EF512.3000404@scl.ameslab.gov> <370780000.1044379308@belka.ny.ficc.gs.com> Message-ID: <20030204174506.GB32892@opus.celabo.org> On Tue, Feb 04, 2003 at 12:21:48PM -0500, Carson Gaspar wrote: > Stop shooting yourself in the foot. Run 2 sshd instances, one on the public > interface, one on the private interface, and make sure they know their > correct host names. This suggestion won't work, because Simon's OpenSSH+GSSAPI uses gethostname() to determine the GSSAPI host-based service name. > The only other sane option I can think of is to add an option to ssh and/or > sshd that lets you select which client and/or server kerberos principal(s) > to use explicitly, instead of automagically determining them. And that's a > lot more work. And belongs in the GSSAPI code. Something like: > > ssh -oClientPrincipal=carson.admin at taltos.org > -oServerPrincipal=host/server.private at taltos.org server.private.taltos.org > > or (in sshd.conf): > ServerPrincipal=host/server.private at taltos.org > > If your're feeling really studly, have the sshd option take a list of > principals. Actually, Simon's OpenSSH+GSSAPI acts differently than most other Kerberos (and GSSAPI) servers. Generally a server will use getsockname() in order to determine what service name to use. Cheers, -- Jacques A. Vidrine http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine at verio.net . nectar at FreeBSD.org . nectar at kth.se From bugzilla-daemon at mindrot.org Thu Feb 6 05:10:48 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 6 Feb 2003 05:10:48 +1100 (EST) Subject: [Bug 433] Allow "ProxyCommand none" in ssh_config Message-ID: <20030205181048.CA79C6454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=433 ------- Additional Comments From binder at arago.de 2003-02-06 05:10 ------- Created an attachment (id=218) --> (http://bugzilla.mindrot.org/attachment.cgi?id=218&action=view) Patch for ProxyCommand's description in ssh_config.5 I have to admit I've never edited nroff-files before, so here's my first attempt ... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From qweasd333 at 24i.net Wed Feb 5 23:21:46 2003 From: qweasd333 at 24i.net (master) Date: Wed, 05 Feb 2003 21:21:46 +0900 Subject: =?ISO-2022-JP?B?GyRCTCQ+NUJ6OS05cCIoJCo2YiEmTTs7cSEmOEJFWTNbGyhC?= =?ISO-2022-JP?B?GyRCJE8hJiEmISYbKEI=?= Message-ID: <20030205.1221450929@qweasd333-24i.net> ????qweasd333 at 24i.net ?????????????????????????? ?????????????3???50?????? ???????????????????????? ?????????????????????? ????????????????? ????????http://axes-f.com ?????????????????????????? ??????????? ???????????????????????????????????????? ????????????????????????????? ????????????????????????? qweasd333 at 24i.net From dot at dotat.at Thu Feb 6 06:26:04 2003 From: dot at dotat.at (Tony Finch) Date: Wed, 5 Feb 2003 19:26:04 +0000 Subject: Minor races in sftp-server.c Message-ID: <20030205192604.G24211@chiark.greenend.org.uk> There are a couple of races in sftp-server as this patch shows: --- sftp-server.c 28 Jan 2003 18:06:53 -0000 1.1.1.2 +++ sftp-server.c 5 Feb 2003 19:19:42 -0000 @@ -832,19 +832,22 @@ process_rename(void) { u_int32_t id; - struct stat st; char *oldpath, *newpath; - int ret, status = SSH2_FX_FAILURE; + int status; id = get_int(); oldpath = get_string(NULL); newpath = get_string(NULL); TRACE("rename id %u old %s new %s", id, oldpath, newpath); /* fail if 'newpath' exists */ - if (stat(newpath, &st) == -1) { - ret = rename(oldpath, newpath); - status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK; - } + if (link(oldpath, newpath) == -1) + status = errno_to_portable(errno); + else if (unlink(oldpath) == -1) { + status = errno_to_portable(errno); + /* clean spare link */ + unlink(newpath); + } else + status = SSH2_FX_OK; send_status(id, status); xfree(oldpath); xfree(newpath); @@ -878,19 +881,16 @@ process_symlink(void) { u_int32_t id; - struct stat st; char *oldpath, *newpath; - int ret, status = SSH2_FX_FAILURE; + int ret, status; id = get_int(); oldpath = get_string(NULL); newpath = get_string(NULL); TRACE("symlink id %u old %s new %s", id, oldpath, newpath); - /* fail if 'newpath' exists */ - if (stat(newpath, &st) == -1) { - ret = symlink(oldpath, newpath); - status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK; - } + /* this will fail if 'newpath' exists */ + ret = symlink(oldpath, newpath); + status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK; send_status(id, status); xfree(oldpath); xfree(newpath); Tony. -- f.a.n.finch http://dotat.at/ CAPE WRATH TO RATTRAY HEAD INCLUDING ORKNEY: WEST 4 BACKING SOUTH 5 TO 7 LOCALLY GALE 8, LATER VEERING WEST TO SOUTHWEST AND DECREASING 5 OR 6. RAIN SPREADING FROM THE WEST, CLEARING LATER. GOOD DECREASING MODERATE IN RAIN. SLIGHT TO MODERATE LOCALLY ROUGH. From jholland at cs.selu.edu Thu Feb 6 04:49:39 2003 From: jholland at cs.selu.edu (Jason P Holland) Date: Wed, 5 Feb 2003 11:49:39 -0600 (CST) Subject: openssh 3.5p1 hostbased authentication In-Reply-To: Message-ID: hello, i did some debugging today, here is the weird portion form sshd -d -d -d debug1: userauth-request for user jholland service ssh-connection method hostbased debug1: attempt 1 failures 1 debug2: input_userauth_request: try method hostbased debug1: userauth_hostbased: cuser jholland chost i2-0. pkalg ssh-dss slen 55 debug3: mm_key_allowed entering debug3: mm_request_send entering: type 20 debug3: monitor_read: checking request 20 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 0x6000000000022cd0 debug2: userauth_hostbased: chost i2-0. resolvedname i2-0 ipaddr 192.168.100.10 debug2: stripping trailing dot from chost i2-0. debug2: auth_rhosts2: clientuser jholland hostname i2-0 ipaddr 192.168.100.10 debug1: temporarily_use_uid: 500/100 (e=0/0) debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED debug3: mm_request_receive_expect entering: type 21 debug3: mm_request_receive entering debug1: restore_uid: 0/0 debug2: userauth_hostbased: access allowed by auth_rhosts2 debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug3: key_read: type mismatch debug1: temporarily_use_uid: 500/100 (e=0/0) debug3: check_host_in_hostfile: filename /home/jholland/.ssh/known_hosts debug3: key_read: type mismatch debug1: restore_uid: 0/0 debug2: check_key_in_hostfiles: key not found for i2-0 debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2 debug1: temporarily_use_uid: 500/100 (e=0/0) debug3: check_host_in_hostfile: filename /home/jholland/.ssh/known_hosts2 debug1: restore_uid: 0/0 debug2: check_key_in_hostfiles: key not found for i2-0 debug3: mm_answer_keyallowed: key 0x6000000000022cd0 is disallowed debug3: mm_append_debug: Appending debug messages for child debug3: mm_request_send entering: type 21 debug3: mm_request_receive entering debug3: mm_send_debug: Sending debug: Accepted for i2-0 [192.168.100.10] by /etc/hosts.equiv. debug2: userauth_hostbased: authenticated 0 Failed hostbased for jholland from 192.168.100.10 port 32965 ssh2 what in the world is the "key_read: type mismatch" all about? I'm using rsa pub key in my ssh_known_hosts file. can someone help me out? thanks jason > > hello all, > i know this question has been asked before, i have read the posts, but i > just cannot figure out how to get hostbased authentication working. i am > running openssh 3.5p1 on some redhat advanced workstation 2.1 for ia64 > architecture systems. i have enabled HostbasedAuthentication in both my > /etc/ssh/ssh_config file and /etc/ssh/sshd_config file. I have all my > known hosts listed in /etc/ssh/ssh_known_hosts. I also have my > /etc/ssh/shosts.equiv file setup as well. However, after all that, i'm > still prompted for a password. > > [root at i2-1 ssh]# ssh -v -v i2-0 > OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug1: Rhosts Authentication disabled, originating port will not be > trusted. > debug1: ssh_connect: needpriv 0 > debug1: Connecting to i2-0 [192.168.100.10] port 22. > debug1: Connection established. > debug1: read PEM private key done: type DSA > debug1: read PEM private key done: type RSA > debug1: identity file /root/.ssh/identity type -1 > debug1: identity file /root/.ssh/id_rsa type -1 > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug2: key_type_from_name: unknown key type '-----END' > debug1: identity file /root/.ssh/id_dsa type 2 > debug1: Remote protocol version 1.99, remote software version > OpenSSH_3.5p1 > debug1: match: OpenSSH_3.5p1 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_3.5p1 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug2: kex_parse_kexinit: > diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib > debug2: kex_parse_kexinit: none,zlib > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: kex_parse_kexinit: > diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib > debug2: kex_parse_kexinit: none,zlib > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: mac_init: found hmac-md5 > debug1: kex: server->client aes128-cbc hmac-md5 none > debug2: mac_init: found hmac-md5 > debug1: kex: client->server aes128-cbc hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP > debug1: dh_gen_key: priv key bits set: 137/256 > debug1: bits set: 1614/3191 > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug1: Host 'i2-0' is known and matches the RSA host key. > debug1: Found key in /etc/ssh/ssh_known_hosts:1 > debug1: bits set: 1587/3191 > debug1: ssh_rsa_verify: signature correct > debug1: kex_derive_keys > debug1: newkeys: mode 1 > debug1: SSH2_MSG_NEWKEYS sent > debug1: waiting for SSH2_MSG_NEWKEYS > debug1: newkeys: mode 0 > debug1: SSH2_MSG_NEWKEYS received > debug1: done: ssh_kex2. > debug1: send SSH2_MSG_SERVICE_REQUEST > debug1: service_accept: ssh-userauth > debug1: got SSH2_MSG_SERVICE_ACCEPT > debug1: authentications that can continue: > publickey,password,keyboard-interactive,hostbased > debug1: next auth method to try is hostbased > debug2: userauth_hostbased: chost i2-1. > debug2: we sent a hostbased packet, wait for reply > debug1: authentications that can continue: > publickey,password,keyboard-interactive,hostbased > debug2: userauth_hostbased: chost i2-1. > debug2: we sent a hostbased packet, wait for reply > debug1: authentications that can continue: > publickey,password,keyboard-interactive,hostbased > debug1: userauth_hostbased: no more client hostkeys > debug2: we did not send a packet, disable method > debug1: next auth method to try is publickey > debug1: try privkey: /root/.ssh/identity > debug1: try privkey: /root/.ssh/id_rsa > debug1: try pubkey: /root/.ssh/id_dsa > debug2: we sent a publickey packet, wait for reply > debug1: authentications that can continue: > publickey,password,keyboard-interactive,hostbased > debug2: we did not send a packet, disable method > debug1: next auth method to try is keyboard-interactive > debug2: userauth_kbdint > debug2: we sent a keyboard-interactive packet, wait for reply > debug1: authentications that can continue: > publickey,password,keyboard-interactive,hostbased > debug2: we did not send a packet, disable method > debug1: next auth method to try is password > root at i2-0's password: > > > seems like it is stuck waiting for a hostbased packet reply, but never > gets it. i have no clue where to go from here. there are no firewalls on > these machines either. and i have tried priveledge and unpriv ports. > any help would be greatly appreciated. thanks! > > Jason > > ps please cc me, i'm not subscribed to the list, thanks > > From jdennis at law.harvard.edu Thu Feb 6 08:25:23 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Wed, 05 Feb 2003 16:25:23 -0500 Subject: MAX_ALLOW_USERS Message-ID: <3E418143.70802@law.harvard.edu> Hey everyone, I have been using sftp for quite some time now and we have just hit 256 sftp users. Line 21 of servconf.h reads: #define MAX_ALLOW_USERS 256 /* Max # users on allow list. */ I am curious why this is in a header file and not something that is in sshd_config that can be changed without recompile? Thanks in advance! -- James Dennis Harvard Law School "Not everything that counts can be counted, and not everything that can be counted counts." From markus at openbsd.org Thu Feb 6 08:35:01 2003 From: markus at openbsd.org (Markus Friedl) Date: Wed, 5 Feb 2003 22:35:01 +0100 Subject: Minor races in sftp-server.c In-Reply-To: <20030205192604.G24211@chiark.greenend.org.uk> References: <20030205192604.G24211@chiark.greenend.org.uk> Message-ID: <20030205213501.GA30827@folly> On Wed, Feb 05, 2003 at 07:26:04PM +0000, Tony Finch wrote: > There are a couple of races in sftp-server as this patch shows: i think we can just remove the calls to stat. From mouring at etoh.eviladmin.org Thu Feb 6 09:31:41 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 5 Feb 2003 16:31:41 -0600 (CST) Subject: MAX_ALLOW_USERS In-Reply-To: <3E418143.70802@law.harvard.edu> Message-ID: > Hey everyone, > > I have been using sftp for quite some time now and we have just hit 256 > sftp users. Line 21 of servconf.h reads: > > #define MAX_ALLOW_USERS 256 /* Max # users on allow list. */ > > I am curious why this is in a header file and not something that is in > sshd_config that can be changed without recompile? > You have 256 users listed in AllowUser ?! Maybe you need to consider moveing to a denylist instead. - Ben > Thanks in advance! > > -- > James Dennis > Harvard Law School > > "Not everything that counts can be counted, > and not everything that can be counted counts." > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From jrzagar at cactus.org Thu Feb 6 09:49:00 2003 From: jrzagar at cactus.org (Randy Zagar) Date: Wed, 05 Feb 2003 16:49:00 -0600 Subject: MAX_ALLOW_USERS References: Message-ID: <3E4194DC.6030402@cactus.org> Or, even better, make AllowUser support netgroups. But I think, from an architecture perspective, that James is right... This kind of parameter should be in sshd_config unless there's a kernel-related limitation that can't be avoided. -RZ Ben Lindstrom wrote: > >>Hey everyone, >> >>I have been using sftp for quite some time now and we have just hit 256 >>sftp users. Line 21 of servconf.h reads: >> >>#define MAX_ALLOW_USERS 256 /* Max # users on allow list. */ >> >>I am curious why this is in a header file and not something that is in >>sshd_config that can be changed without recompile? >> > > > You have 256 users listed in AllowUser ?! Maybe you need to consider > moveing to a denylist instead. > > - Ben > > >>Thanks in advance! >> >>-- >>James Dennis >>Harvard Law School >> >>"Not everything that counts can be counted, >>and not everything that can be counted counts." >> >>_______________________________________________ >>openssh-unix-dev mailing list >>openssh-unix-dev at mindrot.org >>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >> > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From jmknoble at pobox.com Thu Feb 6 09:54:04 2003 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 5 Feb 2003 17:54:04 -0500 Subject: MAX_ALLOW_USERS In-Reply-To: <3E4194DC.6030402@cactus.org> References: <3E4194DC.6030402@cactus.org> Message-ID: <20030205225404.GB26346@crawfish.ais.com> Circa 2003-02-05 16:49:00 -0600 dixit Randy Zagar: : Or, even better, make AllowUser support netgroups. : : But I think, from an architecture perspective, that James is right... : This kind of parameter should be in sshd_config unless there's a : kernel-related limitation that can't be avoided. AllowGroup? -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) "I am non-refutable." --Enik the Altrusian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 256 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030205/d8d9ad30/attachment.bin From mouring at etoh.eviladmin.org Thu Feb 6 10:03:41 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 5 Feb 2003 17:03:41 -0600 (CST) Subject: MAX_ALLOW_USERS In-Reply-To: <3E4194DC.6030402@cactus.org> Message-ID: I think we need to discuss the usage of it before jumping the gun and changing it. WHY do do you have 256 AllowUser? Is it a case where you would be better off with 20 DenyUser lines? I'd rather see the code (which I think would not be too much of a problem) be dynamically allocated if it really needs to be upped, but I think we are running into the case of abuse of a feature without understanding it. - Ben On Wed, 5 Feb 2003, Randy Zagar wrote: > Or, even better, make AllowUser support netgroups. > > But I think, from an architecture perspective, that James is right... > This kind of parameter should be in sshd_config unless there's a > kernel-related limitation that can't be avoided. > > -RZ > > Ben Lindstrom wrote: > > > >>Hey everyone, > >> > >>I have been using sftp for quite some time now and we have just hit 256 > >>sftp users. Line 21 of servconf.h reads: > >> > >>#define MAX_ALLOW_USERS 256 /* Max # users on allow list. */ > >> > >>I am curious why this is in a header file and not something that is in > >>sshd_config that can be changed without recompile? > >> > > > > > > You have 256 users listed in AllowUser ?! Maybe you need to consider > > moveing to a denylist instead. > > > > - Ben > > > > > >>Thanks in advance! > >> > >>-- > >>James Dennis > >>Harvard Law School > >> > >>"Not everything that counts can be counted, > >>and not everything that can be counted counts." > >> > >>_______________________________________________ > >>openssh-unix-dev mailing list > >>openssh-unix-dev at mindrot.org > >>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > >> > > > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From carson at taltos.org Thu Feb 6 10:47:39 2003 From: carson at taltos.org (Carson Gaspar) Date: Wed, 05 Feb 2003 18:47:39 -0500 Subject: MAX_ALLOW_USERS In-Reply-To: References: Message-ID: <329920953.1044470859@[192.168.20.2]> --On Wednesday, February 05, 2003 5:03 PM -0600 Ben Lindstrom wrote: > > I think we need to discuss the usage of it before jumping the gun and > changing it. > > WHY do do you have 256 AllowUser? Is it a case where you would be better > off with 20 DenyUser lines? > > I'd rather see the code (which I think would not be too much of a problem) > be dynamically allocated if it really needs to be upped, but I think we > are running into the case of abuse of a feature without understanding it. DenyUser is almost always a bad idea. Explicit permits are much better than denies - denies fail to take account of new users, and fail open, rather than fail closed. -- Carson From dot at dotat.at Thu Feb 6 13:16:00 2003 From: dot at dotat.at (Tony Finch) Date: Thu, 6 Feb 2003 02:16:00 +0000 Subject: Minor races in sftp-server.c In-Reply-To: <20030205213501.GA30827@folly>; from markus@openbsd.org on Wed, Feb 05, 2003 at 10:35:01PM +0100 References: <20030205192604.G24211@chiark.greenend.org.uk> <20030205213501.GA30827@folly> Message-ID: <20030206021600.A23370@chiark.greenend.org.uk> On Wed, Feb 05, 2003 at 10:35:01PM +0100, Markus Friedl wrote: > On Wed, Feb 05, 2003 at 07:26:04PM +0000, Tony Finch wrote: > > There are a couple of races in sftp-server as this patch shows: > > i think we can just remove the calls to stat. No, that changes the semantics of the rename operation. symlink(2) returns EEXIST if the second argument exists, but rename(2) unlinks it silently. The current code tries to prevent the user from renaming A to B when B exists. This should be clear from the way my patch treats the two cases differently, whereas they are treated the same in the old code. Tony. -- f.a.n.finch http://dotat.at/ WIGHT PORTLAND PLYMOUTH: VARIABLE BECOMING SOUTHWESTERLY 3 OR 4, OCCASIONALLY 5. RAIN OR DRIZZLE. GOOD BECOMING MODERATE, OCCASIONALLY POOR. From markus at openbsd.org Thu Feb 6 20:23:43 2003 From: markus at openbsd.org (Markus Friedl) Date: Thu, 6 Feb 2003 10:23:43 +0100 Subject: Minor races in sftp-server.c In-Reply-To: <20030206021600.A23370@chiark.greenend.org.uk> References: <20030205192604.G24211@chiark.greenend.org.uk> <20030205213501.GA30827@folly> <20030206021600.A23370@chiark.greenend.org.uk> Message-ID: <20030206092343.GB753@folly> On Thu, Feb 06, 2003 at 02:16:00AM +0000, Tony Finch wrote: > On Wed, Feb 05, 2003 at 10:35:01PM +0100, Markus Friedl wrote: > > On Wed, Feb 05, 2003 at 07:26:04PM +0000, Tony Finch wrote: > > > There are a couple of races in sftp-server as this patch shows: > > > > i think we can just remove the calls to stat. > > No, that changes the semantics of the rename operation. yes, i checked again, the stat is there because the draft requires this behaviour, i'll include your patch. From ajith at noida.hcltech.com Thu Feb 6 20:44:46 2003 From: ajith at noida.hcltech.com (Ajit Yashwant Vaishampayan, Noida) Date: Thu, 6 Feb 2003 15:14:46 +0530 Subject: No struct cmsghdr - what to do ? Message-ID: Hi all, If any perticular OS does not have 'struct cmsghdr' in sys/socket.h and also it does not have access rights in 'struct msghdr', then how the compilation should be done ? Does anybody had similar problem earlier ? Regards, Ajit From jdennis at law.harvard.edu Fri Feb 7 01:32:09 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Thu, 06 Feb 2003 09:32:09 -0500 Subject: MAX_ALLOW_USERS In-Reply-To: References: Message-ID: <3E4271E9.3060302@law.harvard.edu> Hey everyone, I appreciate the input. The reason we have 256 AllowUser's is because we are (as stated before) explicitly allowing users to sftp to our systems and denying the rest. Because we use sftp as our main file transfer method, we of course have many users that need to be explicitly allowed. As Ben is always a source of good info, I'm curious why you would see this is an abuse? We're probably going to just double that number and recompile if it looks as though it's not an abuse. Hopefully I'll get time to whip up a patch to moves that number into sshd_config. -James Ben Lindstrom wrote: > I think we need to discuss the usage of it before jumping the gun and > changing it. > > WHY do do you have 256 AllowUser? Is it a case where you would be better > off with 20 DenyUser lines? > > I'd rather see the code (which I think would not be too much of a problem) > be dynamically allocated if it really needs to be upped, but I think we > are running into the case of abuse of a feature without understanding it. > > - Ben > > > > On Wed, 5 Feb 2003, Randy Zagar wrote: > > >>Or, even better, make AllowUser support netgroups. >> >>But I think, from an architecture perspective, that James is right... >>This kind of parameter should be in sshd_config unless there's a >>kernel-related limitation that can't be avoided. >> >>-RZ >> >>Ben Lindstrom wrote: >> >>>>Hey everyone, >>>> >>>>I have been using sftp for quite some time now and we have just hit 256 >>>>sftp users. Line 21 of servconf.h reads: >>>> >>>>#define MAX_ALLOW_USERS 256 /* Max # users on allow list. */ >>>> >>>>I am curious why this is in a header file and not something that is in >>>>sshd_config that can be changed without recompile? >>>> >>> >>> >>>You have 256 users listed in AllowUser ?! Maybe you need to consider >>>moveing to a denylist instead. >>> >>>- Ben >>> >>> >>> >>>>Thanks in advance! >>>> >>>>-- >>>>James Dennis >>>>Harvard Law School >>>> >>>>"Not everything that counts can be counted, >>>>and not everything that can be counted counts." >>>> >>>>_______________________________________________ >>>>openssh-unix-dev mailing list >>>>openssh-unix-dev at mindrot.org >>>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >>>> >>> >>> >>>_______________________________________________ >>>openssh-unix-dev mailing list >>>openssh-unix-dev at mindrot.org >>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >> >> >> >>_______________________________________________ >>openssh-unix-dev mailing list >>openssh-unix-dev at mindrot.org >>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >> > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- James Dennis Harvard Law School 617-596-7272 "Not everything that counts can be counted, and not everything that can be counted counts." From GILBERT.R.LOOMIS at saic.com Fri Feb 7 01:35:32 2003 From: GILBERT.R.LOOMIS at saic.com (Loomis, Rip) Date: Thu, 6 Feb 2003 09:35:32 -0500 Subject: MAX_ALLOW_USERS Message-ID: <4E25ECBBC03F874CBAD03399254ADFDE104A6B@US-Columbia-CIST.mail.saic.com> > > WHY do do you have 256 AllowUser? Is it a case where you > > would be better off with 20 DenyUser lines? > DenyUser is almost always a bad idea. Explicit permits are > much better than denies - denies fail to take account of new > users, and fail open, rather than fail closed. I strongly agree that "default deny, allow specific" is the better answer--and I suspect that's why the reporting site is doing things the way they are. As someone else already noted, though, it would appear that the right answer is to add support for AllowGroup. AllowUser is also not really something that can be a runtime configuration option, since there does need to be a maximum data structure size defined during compilation. If someone really needs more than 256 AllowUser lines in the short term, then they should modify that #define. -- Rip Loomis Brainbench MVP for Internet Security http://www.brainbench.com [Transcript 1923411] From pekkas at netcore.fi Fri Feb 7 01:45:11 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 6 Feb 2003 16:45:11 +0200 (EET) Subject: MAX_ALLOW_USERS In-Reply-To: <3E4271E9.3060302@law.harvard.edu> Message-ID: On Thu, 6 Feb 2003, James Dennis wrote: > I appreciate the input. The reason we have 256 AllowUser's is because we > are (as stated before) explicitly allowing users to sftp to our systems > and denying the rest. Because we use sftp as our main file transfer > method, we of course have many users that need to be explicitly allowed. > > As Ben is always a source of good info, I'm curious why you would see > this is an abuse? We're probably going to just double that number and > recompile if it looks as though it's not an abuse. Hopefully I'll get > time to whip up a patch to moves that number into sshd_config. I'd certainly just create a provisional group 'sftpusers' and add every user there.. > Ben Lindstrom wrote: > > I think we need to discuss the usage of it before jumping the gun and > > changing it. > > > > WHY do do you have 256 AllowUser? Is it a case where you would be better > > off with 20 DenyUser lines? > > > > I'd rather see the code (which I think would not be too much of a problem) > > be dynamically allocated if it really needs to be upped, but I think we > > are running into the case of abuse of a feature without understanding it. > > > > - Ben > > > > > > > > On Wed, 5 Feb 2003, Randy Zagar wrote: > > > > > >>Or, even better, make AllowUser support netgroups. > >> > >>But I think, from an architecture perspective, that James is right... > >>This kind of parameter should be in sshd_config unless there's a > >>kernel-related limitation that can't be avoided. > >> > >>-RZ > >> > >>Ben Lindstrom wrote: > >> > >>>>Hey everyone, > >>>> > >>>>I have been using sftp for quite some time now and we have just hit 256 > >>>>sftp users. Line 21 of servconf.h reads: > >>>> > >>>>#define MAX_ALLOW_USERS 256 /* Max # users on allow list. */ > >>>> > >>>>I am curious why this is in a header file and not something that is in > >>>>sshd_config that can be changed without recompile? > >>>> > >>> > >>> > >>>You have 256 users listed in AllowUser ?! Maybe you need to consider > >>>moveing to a denylist instead. > >>> > >>>- Ben > >>> > >>> > >>> > >>>>Thanks in advance! > >>>> > >>>>-- > >>>>James Dennis > >>>>Harvard Law School > >>>> > >>>>"Not everything that counts can be counted, > >>>>and not everything that can be counted counts." > >>>> > >>>>_______________________________________________ > >>>>openssh-unix-dev mailing list > >>>>openssh-unix-dev at mindrot.org > >>>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > >>>> > >>> > >>> > >>>_______________________________________________ > >>>openssh-unix-dev mailing list > >>>openssh-unix-dev at mindrot.org > >>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > >> > >> > >> > >>_______________________________________________ > >>openssh-unix-dev mailing list > >>openssh-unix-dev at mindrot.org > >>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > >> > > > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > -- 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 jdennis at law.harvard.edu Fri Feb 7 01:57:56 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Thu, 06 Feb 2003 09:57:56 -0500 Subject: MAX_ALLOW_USERS In-Reply-To: References: Message-ID: <3E4277F4.7060207@law.harvard.edu> Ah, excellent. Looks like I was caught up by the AllowUsers limit and didn't think to check for an AllowGroup directive. Is anyone still interested in moving this into a config file? -James Pekka Savola wrote: > On Thu, 6 Feb 2003, James Dennis wrote: > >>I appreciate the input. The reason we have 256 AllowUser's is because we >>are (as stated before) explicitly allowing users to sftp to our systems >>and denying the rest. Because we use sftp as our main file transfer >>method, we of course have many users that need to be explicitly allowed. >> >>As Ben is always a source of good info, I'm curious why you would see >>this is an abuse? We're probably going to just double that number and >>recompile if it looks as though it's not an abuse. Hopefully I'll get >>time to whip up a patch to moves that number into sshd_config. > > > I'd certainly just create a provisional group 'sftpusers' and add every > user there.. > > >>Ben Lindstrom wrote: >> >>>I think we need to discuss the usage of it before jumping the gun and >>>changing it. >>> >>>WHY do do you have 256 AllowUser? Is it a case where you would be better >>>off with 20 DenyUser lines? >>> >>>I'd rather see the code (which I think would not be too much of a problem) >>>be dynamically allocated if it really needs to be upped, but I think we >>>are running into the case of abuse of a feature without understanding it. >>> >>>- Ben >>> >>> >>> >>>On Wed, 5 Feb 2003, Randy Zagar wrote: >>> >>> >>> >>>>Or, even better, make AllowUser support netgroups. >>>> >>>>But I think, from an architecture perspective, that James is right... >>>>This kind of parameter should be in sshd_config unless there's a >>>>kernel-related limitation that can't be avoided. >>>> >>>>-RZ >>>> >>>>Ben Lindstrom wrote: >>>> >>>> >>>>>>Hey everyone, >>>>>> >>>>>>I have been using sftp for quite some time now and we have just hit 256 >>>>>>sftp users. Line 21 of servconf.h reads: >>>>>> >>>>>>#define MAX_ALLOW_USERS 256 /* Max # users on allow list. */ >>>>>> >>>>>>I am curious why this is in a header file and not something that is in >>>>>>sshd_config that can be changed without recompile? >>>>>> >>>>> >>>>> >>>>>You have 256 users listed in AllowUser ?! Maybe you need to consider >>>>>moveing to a denylist instead. >>>>> >>>>>- Ben >>>>> >>>>> >>>>> >>>>> >>>>>>Thanks in advance! >>>>>> >>>>>>-- >>>>>>James Dennis >>>>>>Harvard Law School >>>>>> >>>>>>"Not everything that counts can be counted, >>>>>>and not everything that can be counted counts." >>>>>> >>>>>>_______________________________________________ >>>>>>openssh-unix-dev mailing list >>>>>>openssh-unix-dev at mindrot.org >>>>>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >>>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>openssh-unix-dev mailing list >>>>>openssh-unix-dev at mindrot.org >>>>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >>>> >>>> >>>> >>>>_______________________________________________ >>>>openssh-unix-dev mailing list >>>>openssh-unix-dev at mindrot.org >>>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >>>> >>> >>> >>>_______________________________________________ >>>openssh-unix-dev mailing list >>>openssh-unix-dev at mindrot.org >>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >>> >> >> > -- James Dennis Harvard Law School 617-596-7272 "Not everything that counts can be counted, and not everything that can be counted counts." From bugzilla-daemon at mindrot.org Fri Feb 7 02:13:45 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 02:13:45 +1100 (EST) Subject: [Bug 485] New: scp doesn't preserve symbolic links Message-ID: <20030206151345.D29976450C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=485 Summary: scp doesn't preserve symbolic links Product: Portable OpenSSH Version: -current Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: jsk29 at cornell.edu I apologize if this has been reported in another bug report. I couldn't find it, though, which surprises me. I think this bug must have bitten a lot of people. scp does not follow symbolic links. I consider this a bug. I understand that some people consider this a feature, since rcp behaved the same way. However, I also consider it a bug in rcp. :) (Besides, what fraction of scp users actually ever used rcp? It must be very small.) It is currently extremely easy to get scp locked in an loop. I use scp to move input and output files from my simulations all day long, and symbolic links are present everywhere. I have to play a lot of games with tar to get things to work now. That's totally barbaric. :) Please, please, please fix this. Include a backwards compatibility switch if you like. scp rocks, but this one little bug drives me nutty. :) Thanks guys, John ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mouring at etoh.eviladmin.org Fri Feb 7 02:36:40 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 6 Feb 2003 09:36:40 -0600 (CST) Subject: MAX_ALLOW_USERS In-Reply-To: <3E4277F4.7060207@law.harvard.edu> Message-ID: I think Mr Miller is planning on making them dynamically allocated. But Pekka stole my point.=) I personally see AllowUsers required for adding small 'oddball' users (not saying the users themselves are oddballs. ) where {Allow/Deny}Groups is really what people should use for larger groups of common trait people. However, I suspect it will be moot in the future. - Ben On Thu, 6 Feb 2003, James Dennis wrote: > Ah, excellent. Looks like I was caught up by the AllowUsers limit and > didn't think to check for an AllowGroup directive. Is anyone still > interested in moving this into a config file? > > -James > > Pekka Savola wrote: > > On Thu, 6 Feb 2003, James Dennis wrote: > > > >>I appreciate the input. The reason we have 256 AllowUser's is because we > >>are (as stated before) explicitly allowing users to sftp to our systems > >>and denying the rest. Because we use sftp as our main file transfer > >>method, we of course have many users that need to be explicitly allowed. > >> > >>As Ben is always a source of good info, I'm curious why you would see > >>this is an abuse? We're probably going to just double that number and > >>recompile if it looks as though it's not an abuse. Hopefully I'll get > >>time to whip up a patch to moves that number into sshd_config. > > > > > > I'd certainly just create a provisional group 'sftpusers' and add every > > user there.. > > > > > >>Ben Lindstrom wrote: > >> > >>>I think we need to discuss the usage of it before jumping the gun and > >>>changing it. > >>> > >>>WHY do do you have 256 AllowUser? Is it a case where you would be better > >>>off with 20 DenyUser lines? > >>> > >>>I'd rather see the code (which I think would not be too much of a problem) > >>>be dynamically allocated if it really needs to be upped, but I think we > >>>are running into the case of abuse of a feature without understanding it. > >>> > >>>- Ben > >>> > >>> > >>> > >>>On Wed, 5 Feb 2003, Randy Zagar wrote: > >>> > >>> > >>> > >>>>Or, even better, make AllowUser support netgroups. > >>>> > >>>>But I think, from an architecture perspective, that James is right... > >>>>This kind of parameter should be in sshd_config unless there's a > >>>>kernel-related limitation that can't be avoided. > >>>> > >>>>-RZ > >>>> > >>>>Ben Lindstrom wrote: > >>>> > >>>> > >>>>>>Hey everyone, > >>>>>> > >>>>>>I have been using sftp for quite some time now and we have just hit 256 > >>>>>>sftp users. Line 21 of servconf.h reads: > >>>>>> > >>>>>>#define MAX_ALLOW_USERS 256 /* Max # users on allow list. */ > >>>>>> > >>>>>>I am curious why this is in a header file and not something that is in > >>>>>>sshd_config that can be changed without recompile? > >>>>>> > >>>>> > >>>>> > >>>>>You have 256 users listed in AllowUser ?! Maybe you need to consider > >>>>>moveing to a denylist instead. > >>>>> > >>>>>- Ben > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Thanks in advance! > >>>>>> > >>>>>>-- > >>>>>>James Dennis > >>>>>>Harvard Law School > >>>>>> > >>>>>>"Not everything that counts can be counted, > >>>>>>and not everything that can be counted counts." > >>>>>> > >>>>>>_______________________________________________ > >>>>>>openssh-unix-dev mailing list > >>>>>>openssh-unix-dev at mindrot.org > >>>>>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > >>>>>> > >>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>openssh-unix-dev mailing list > >>>>>openssh-unix-dev at mindrot.org > >>>>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>openssh-unix-dev mailing list > >>>>openssh-unix-dev at mindrot.org > >>>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > >>>> > >>> > >>> > >>>_______________________________________________ > >>>openssh-unix-dev mailing list > >>>openssh-unix-dev at mindrot.org > >>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > >>> > >> > >> > > > > -- > James Dennis > Harvard Law School > 617-596-7272 > > "Not everything that counts can be counted, > and not everything that can be counted counts." > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From bugzilla-daemon at mindrot.org Fri Feb 7 02:46:19 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 02:46:19 +1100 (EST) Subject: [Bug 486] New: "PermitRootLogin no" can implicitly reveal root password Message-ID: <20030206154619.C23E06450C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=486 Summary: "PermitRootLogin no" can implicitly reveal root password Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: Linux Status: NEW Severity: security Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: blizzy at blizzy.de With 3.5p1, when setting "PermitRootLogin no" in /etc/ssh/sshd_config, logging in as root is disabled, of course. However, when entering the correct password, ssh prints "Connection reset by peer" and exits immediately. When entering the wrong password, it will prompt you again. I think this qualifies as a security hole, since you can use brute-force tools to try to login as root. Of course you need to have/hack another account to actually have the possibility to become root (via su or other means), but at least you know the password. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jdennis at law.harvard.edu Fri Feb 7 02:49:02 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Thu, 06 Feb 2003 10:49:02 -0500 Subject: kex guess methods incorrect? Message-ID: <3E4283EE.2060607@law.harvard.edu> Hey guys, My second post in the last few days (boy I'm active! ;)). We've had a few issues with SSH Secure Shell version 3.2.0 (build 267) and sftp and while trying to figure it out I noticed something in the debug output that I think should be brought to OpenSSH's attention. Ssh2Transport/trcommon.c:1518: All versions of OpenSSH handle kex guesses incorrectly. Does anyone know what this is about? I can provide more info if necessary. -- James Dennis Harvard Law School 617-596-7272 "Not everything that counts can be counted, and not everything that can be counted counts." From cmadams at hiwaay.net Fri Feb 7 03:11:18 2003 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 6 Feb 2003 10:11:18 -0600 Subject: MAX_ALLOW_USERS In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Feb 06, 2003 at 09:36:40AM -0600 References: <3E4277F4.7060207@law.harvard.edu> Message-ID: <20030206101118.A531298@hiwaay.net> Once upon a time, Ben Lindstrom said: > I think Mr Miller is planning on making them dynamically allocated. But > Pekka stole my point.=) I personally see AllowUsers required for adding > small 'oddball' users (not saying the users themselves are oddballs. > ) where {Allow/Deny}Groups is really what people should use > for larger groups of common trait people. What would it take to make OpenSSH use PAM (on PAM platforms anyway) for service authorization? Then this could be done with a PAM module (which might be convenient, as the same users may be restricted in more than one way). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jdennis at law.harvard.edu Fri Feb 7 03:35:10 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Thu, 06 Feb 2003 11:35:10 -0500 Subject: MAX_ALLOW_USERS In-Reply-To: <20030206101118.A531298@hiwaay.net> References: <3E4277F4.7060207@law.harvard.edu> <20030206101118.A531298@hiwaay.net> Message-ID: <3E428EBE.8070201@law.harvard.edu> Quick answer: ./configure --with-pam -James Chris Adams wrote: > Once upon a time, Ben Lindstrom said: > >>I think Mr Miller is planning on making them dynamically allocated. But >>Pekka stole my point.=) I personally see AllowUsers required for adding >>small 'oddball' users (not saying the users themselves are oddballs. >>) where {Allow/Deny}Groups is really what people should use >>for larger groups of common trait people. > > > What would it take to make OpenSSH use PAM (on PAM platforms anyway) for > service authorization? Then this could be done with a PAM module (which > might be convenient, as the same users may be restricted in more than > one way). > -- James Dennis Harvard Law School 617-596-7272 "Not everything that counts can be counted, and not everything that can be counted counts." From cmadams at hiwaay.net Fri Feb 7 03:40:19 2003 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 6 Feb 2003 10:40:19 -0600 Subject: MAX_ALLOW_USERS In-Reply-To: <3E428EBE.8070201@law.harvard.edu>; from jdennis@law.harvard.edu on Thu, Feb 06, 2003 at 11:35:10AM -0500 References: <3E4277F4.7060207@law.harvard.edu> <20030206101118.A531298@hiwaay.net> <3E428EBE.8070201@law.harvard.edu> Message-ID: <20030206104019.B531298@hiwaay.net> Once upon a time, James Dennis said: > Quick answer: ./configure --with-pam That limits access to SSH or not as a whole. What I meant is for OpenSSH to use PAM for subsystem authorization. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From binder at arago.de Fri Feb 7 04:12:22 2003 From: binder at arago.de (Thomas Binder) Date: Thu, 6 Feb 2003 18:12:22 +0100 Subject: kex guess methods incorrect? In-Reply-To: <3E4283EE.2060607@law.harvard.edu> References: <3E4283EE.2060607@law.harvard.edu> Message-ID: <20030206171222.GA7905522@ohm.arago.de> Hi! On Thu, Feb 06, 2003 at 10:49:02AM -0500, James Dennis wrote: > Ssh2Transport/trcommon.c:1518: All versions of OpenSSH handle kex > guesses incorrectly. > > Does anyone know what this is about? I can provide more info if > necessary. See: http://bugzilla.mindrot.org/show_bug.cgi?id=148 Thus, the upcoming OpenSSH 3.6 should (correctly) handle kex guesses. Ciao Thomas From bugzilla-daemon at mindrot.org Fri Feb 7 06:32:24 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 06:32:24 +1100 (EST) Subject: [Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport Message-ID: <20030206193224.8DBA56450C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=413 ------- Additional Comments From rumen at skalasoft.com 2003-02-07 06:32 ------- Created an attachment (id=219) --> (http://bugzilla.mindrot.org/attachment.cgi?id=219&action=view) about attachment (id=217) About attachment (id=217) - ssh_config.5 should be updated too (options LocalForward and RemoteForward) - we should set GatewayPorts to yes in ssh config to use new forward shema. Created attachment: - fix segfault, when we use LocalForward and RemoteForward in ssh config. - make ssh option GatewayPorts obsolete (might this option is useless with new forward shema?). - correct forward messages in ssh.c What about readconf methods: void add_local_forward(Options *, const char *, u_short, const char *, u_short); void add_remote_forward(Options *, const char *, u_short, const char *, u_short); to be changed as follows: void add_local_forward(Options *, const Forward*); void add_remote_forward(Options *, const Forward*); In first case developer should read C file to see agriment meaning. Second case is more obvious. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Feb 7 06:34:03 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 06:34:03 +1100 (EST) Subject: [Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport Message-ID: <20030206193403.EA63E6450C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=413 rumen at skalasoft.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #219 is|0 |1 patch| | ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Fri Feb 7 04:53:48 2003 From: markus at openbsd.org (Markus Friedl) Date: Thu, 6 Feb 2003 18:53:48 +0100 Subject: kex guess methods incorrect? In-Reply-To: <3E4283EE.2060607@law.harvard.edu> References: <3E4283EE.2060607@law.harvard.edu> Message-ID: <20030206175347.GB6751@folly> On Thu, Feb 06, 2003 at 10:49:02AM -0500, James Dennis wrote: > Ssh2Transport/trcommon.c:1518: All versions of OpenSSH handle kex > guesses incorrectly. Versions of OpenSSH < 3.6 don't handle this at all. tell your vendor that OpenSSH 3.6 will probably handle this correctly. -m From bugzilla-daemon at mindrot.org Fri Feb 7 07:39:03 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 07:39:03 +1100 (EST) Subject: [Bug 433] Allow "ProxyCommand none" in ssh_config Message-ID: <20030206203903.2020C6450C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=433 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From markus at openbsd.org 2003-02-07 07:39 ------- similar patch commited. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Feb 7 07:44:44 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 07:44:44 +1100 (EST) Subject: [Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport Message-ID: <20030206204444.707FC6450C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=413 ------- Additional Comments From markus at openbsd.org 2003-02-07 07:44 ------- no, GatewayPorts should still default to 'no', but with -L local:port:target:port the listen address should be overwritten. without 'local:' we should still use GatewayPorts like before. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Feb 7 07:48:31 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 07:48:31 +1100 (EST) Subject: [Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport Message-ID: <20030206204831.DFA2864514@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=413 ------- Additional Comments From markus at openbsd.org 2003-02-07 07:48 ------- re attachment 219: 1. please don't use strncat (use strlcpy or snprintf instead). 2. i don't think the patch to ssh.c is correct. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Feb 7 07:51:38 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 07:51:38 +1100 (EST) Subject: [Bug 485] scp doesn't preserve symbolic links Message-ID: <20030206205138.EA50E6450C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=485 ------- Additional Comments From markus at openbsd.org 2003-02-07 07:51 ------- why don't you use sftp? i think skipping links is an option, but copying not. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Feb 7 07:51:59 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 07:51:59 +1100 (EST) Subject: [Bug 486] "PermitRootLogin no" can implicitly reveal root password Message-ID: <20030206205159.D7C926451A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=486 ------- Additional Comments From markus at openbsd.org 2003-02-07 07:51 ------- are you using PAM? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Feb 7 08:16:24 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 08:16:24 +1100 (EST) Subject: [Bug 387] command="" in authorized_keys fails when sshd_config has "PermitRootLogon forced-commands-only" Message-ID: <20030206211624.0C4606450C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=387 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From markus at openbsd.org 2003-02-07 08:16 ------- this 'fix' caused bug #486 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Feb 7 08:18:23 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 08:18:23 +1100 (EST) Subject: [Bug 387] command="" in authorized_keys fails when sshd_config has "PermitRootLogon forced-commands-only" Message-ID: <20030206211823.6CD456450C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=387 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |486 nThis| | ------- Additional Comments From markus at openbsd.org 2003-02-07 08:18 ------- i prefer this bug to #486 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Feb 7 08:18:25 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 08:18:25 +1100 (EST) Subject: [Bug 486] "PermitRootLogin no" can implicitly reveal root password Message-ID: <20030206211825.2DBCD6451A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=486 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |387 Bug 486 depends on bug 387, which changed state. Bug 387 Summary: command="" in authorized_keys fails when sshd_config has "PermitRootLogon forced-commands-only" http://bugzilla.mindrot.org/show_bug.cgi?id=387 What |Old Value |New Value ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Feb 7 08:20:35 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 08:20:35 +1100 (EST) Subject: [Bug 486] "PermitRootLogin no" can implicitly reveal root password Message-ID: <20030206212035.0DEBE64514@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=486 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From markus at openbsd.org 2003-02-07 08:20 ------- fixed in -current ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Feb 7 09:34:22 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 09:34:22 +1100 (EST) Subject: [Bug 487] New: Patches to fix ssh1 kerberos handling and some other items Message-ID: <20030206223422.6C2AD64538@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=487 Summary: Patches to fix ssh1 kerberos handling and some other items Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: smoogen at lanl.gov I am adding these patches to the list so that they might be applied to the tree at some point. They were written Dave Williams to clean up some documentation and a bug he found with ssh -k ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Feb 7 09:36:51 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 09:36:51 +1100 (EST) Subject: [Bug 487] Patches to fix ssh1 kerberos handling and some other items Message-ID: <20030206223651.4C0796450C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=487 ------- Additional Comments From smoogen at lanl.gov 2003-02-07 09:36 ------- Created an attachment (id=220) --> (http://bugzilla.mindrot.org/attachment.cgi?id=220&action=view) Patch for ssh_config man page Should change some wording. Written by Dave Williams ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Feb 7 09:37:52 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 09:37:52 +1100 (EST) Subject: [Bug 487] Patches to fix ssh1 kerberos handling and some other items Message-ID: <20030206223752.75E6564514@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=487 ------- Additional Comments From smoogen at lanl.gov 2003-02-07 09:37 ------- Created an attachment (id=221) --> (http://bugzilla.mindrot.org/attachment.cgi?id=221&action=view) Allow -k to work with GSSAPI This checks to see if GSSAPI is defined and turns on -k ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Feb 7 09:38:25 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 09:38:25 +1100 (EST) Subject: [Bug 487] Patches to fix ssh1 kerberos handling and some other items Message-ID: <20030206223825.C2CE964514@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=487 ------- Additional Comments From smoogen at lanl.gov 2003-02-07 09:38 ------- Created an attachment (id=222) --> (http://bugzilla.mindrot.org/attachment.cgi?id=222&action=view) Cleans ssh.1 man page ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Feb 7 09:38:56 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 09:38:56 +1100 (EST) Subject: [Bug 487] Patches to fix ssh1 kerberos handling and some other items Message-ID: <20030206223856.552656450C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=487 ------- Additional Comments From smoogen at lanl.gov 2003-02-07 09:38 ------- Created an attachment (id=223) --> (http://bugzilla.mindrot.org/attachment.cgi?id=223&action=view) Cleans sshd_config man page ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Feb 7 09:44:03 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 09:44:03 +1100 (EST) Subject: [Bug 488] New: Patch for kerberos in clusters Message-ID: <20030206224403.19D366451A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=488 Summary: Patch for kerberos in clusters Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: smoogen at lanl.gov Patch from one of LANL's clustering groups. This allows for openssh to deal with addressless tickets which seem to come up in areas with 1024+ nodes or so. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Feb 7 09:44:56 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 09:44:56 +1100 (EST) Subject: [Bug 488] Patch for kerberos in clusters Message-ID: <20030206224456.16B3264514@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=488 ------- Additional Comments From smoogen at lanl.gov 2003-02-07 09:44 ------- Created an attachment (id=224) --> (http://bugzilla.mindrot.org/attachment.cgi?id=224&action=view) Patch for addressless kerberos tickets From bugzilla-daemon at mindrot.org Fri Feb 7 19:49:05 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 19:49:05 +1100 (EST) Subject: [Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport Message-ID: <20030207084905.3E7126450B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=413 ------- Additional Comments From rumen at skalasoft.com 2003-02-07 19:49 ------- samples: LocalForward 10080 127.1.0.253:80 LocalForward *:10180 127.1.0.253:80 LocalForward 127.1.0.1:10280 127.1.0.253:80 LocalForward 10.0.0.1:10380 127.1.0.253:80 second line is equal to GatewayPorts=yes and -L port:target:port in unpached ssh. GatewayPorts in server must exist, but in client hmm. In patched version (patch 217+219) we can set forwards as above. It is easy to use only LocalForward (as show above), instead both GatewayPorts and LocalForward. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Feb 7 21:03:51 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 21:03:51 +1100 (EST) Subject: [Bug 454] SSH doesn't consider distinguish ports for host-key verification Message-ID: <20030207100351.77E6D64508@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=454 ------- Additional Comments From august at dce.chalmers.se 2003-02-07 21:03 ------- This feature would be useful for another issue as well: I have a dlink nat/gateway/switch/dhcp thingy, and a static IP. Behind it are about 3-5 machines. I can specify one IP on the inside that gets connections made to port 22 from the outside. But if I want to login to another machine from he outside, without going thru the designated one, I'm stuck, since the obvious solution (telling the sshd on the other internal boxen to listen for another port as well, and relaying that port to them in the NAT thingy) fails because the host keys are wrong. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Feb 7 21:58:44 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 21:58:44 +1100 (EST) Subject: [Bug 489] New: root login with PublicKeyAuthentication disabled Message-ID: <20030207105844.C8CE56450B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=489 Summary: root login with PublicKeyAuthentication disabled Product: Portable OpenSSH Version: 3.5p1 Platform: Alpha OS/Version: OSF/1 Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: jim.a.davidson at bt.com Dec Alpha system running OSF/1 5.1A in enhanced security mode and OpenSSH 3.5 with ptys entry in /etc/securettys. We fail to login to root account using PublicKeyAuthentication. If we switch security back to base mode then we can login ok. We can do this on all other Unix systems where access to root is restricted to the console so why not here? Thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Feb 7 23:45:28 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 7 Feb 2003 23:45:28 +1100 (EST) Subject: [Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport Message-ID: <20030207124528.F0E8264508@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=413 ------- Additional Comments From markus at openbsd.org 2003-02-07 23:45 ------- still we need to keep current -g behaviour for existing setups. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Feb 8 00:03:44 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 8 Feb 2003 00:03:44 +1100 (EST) Subject: [Bug 387] command="" in authorized_keys fails when sshd_config has "PermitRootLogon forced-commands-only" Message-ID: <20030207130344.1CA5A64508@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=387 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #139 is|0 |1 obsolete| | ------- Additional Comments From markus at openbsd.org 2003-02-08 00:03 ------- Created an attachment (id=225) --> (http://bugzilla.mindrot.org/attachment.cgi?id=225&action=view) ugly fix ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From vherva at niksula.hut.fi Sun Feb 9 21:11:53 2003 From: vherva at niksula.hut.fi (Ville Herva) Date: Sun, 9 Feb 2003 12:11:53 +0200 Subject: scp -l on man page? In-Reply-To: References: <20030127223347.GC5565@folly> Message-ID: <20030209101153.GB160739@niksula.cs.hut.fi> On Tue, Jan 28, 2003 at 12:09:19PM +0200, you [Pekka Savola] wrote: > On Mon, 27 Jan 2003, Markus Friedl wrote: > > On Mon, Jan 27, 2003 at 02:18:38PM +0200, Pekka Savola wrote: > > > From here and from OpenBSD CVSweb interface, I note that scp -l has not > > > been yet documented in scp.1 manpage. I assume that was forgotten? > > > > i've been lazy. please send a patch :) > > How about the attached? > > (Note: I haven't tested the feature, I just made it based on a quick look > at the source..) Nice! What about the transfer resume bits from http://groups.google.com/groups?q=%5BPATCH%5D:+scp+program+improved&hl=en&lr=&ie=UTF-8&oe=utf-8&selm=agotbg%24r89%241%40FreeBSD.csie.NCTU.edu.tw&rnum=1 ? I see you already revamped progress meter... -- v -- v at iki.fi From bugzilla-daemon at mindrot.org Mon Feb 10 00:16:23 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 10 Feb 2003 00:16:23 +1100 (EST) Subject: [Bug 490] New: ssh-add man page needs slight reference update Message-ID: <20030209131623.7B48964514@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=490 Summary: ssh-add man page needs slight reference update Product: Portable OpenSSH Version: 3.4p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: trivial Priority: P2 Component: Documentation AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: mark at summersault.com Hello, I have a slight tweak to the ssh-add man page to suggest. I was just reading this line: "-t life Set a maximum lifetime when adding identities to an agent. The lifetime may be specified in seconds or in a time format specified in sshd(8)." I wanted to know more about the time formats, so I looked at the sshd man page. They aren't documented there, though. I found them documented in the sshd_config man page. So I suggest updating the ssh-add man page to point directly there. Thanks for ssh-- I keep finding new and useful features! ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From ad at Dunkel.de Mon Feb 10 06:13:38 2003 From: ad at Dunkel.de (Axel Dunkel) Date: 9 Feb 2003 20:13:38 +0100 Subject: Logging of comments on keys Message-ID: <20030209201338.18152.qmail@darwin.dunkel.de> Hi, during our usual work I found it anoying that one can not easily see who logged in using public key authentication. In newer versions of SSH the fingerprint of the public key gets logged, but who can tell which key belongs to whom from his head? So I wrote a little ad-hoc patch (vs. 3.5.p1) so that the comment field on the keys in the authorized_keys[2] files get logged to make life easier. Also, the public key of all public-key-login-*attempts* are logged as well. I include the patch (only some lines of code). I would appreciate comments on this matter! Thanks, Axel Dunkel --- Systemberatung A. Dunkel GmbH, Gutenbergstr. 5, D-65830 Kriftel Tel.: +49-6192-9988-0, Fax: +49-6192-9988-99, E-Mail: ad at Dunkel.de -------------- next part -------------- *** auth2-pubkey.c.orig Sun Feb 9 12:48:09 2003 --- auth2-pubkey.c Sun Feb 9 19:57:09 2003 *************** *** 183,188 **** --- 183,193 ---- debug("trying public key file %s", file); + /* log public key */ + + fp = key_fingerprint(key, SSH_FP_MD5, SSH_FP_HEX); + verbose("Attempt public key authentication for %s with %s key: %s", pw->pw_name, key_type(key), fp); + /* Fail quietly if file does not exist */ if (stat(file, &st) < 0) { /* Restore the privileged uid. */ *************** *** 244,249 **** --- 249,255 ---- fp = key_fingerprint(found, SSH_FP_MD5, SSH_FP_HEX); verbose("Found matching %s key: %s", key_type(found), fp); + verbose("Comment on key: %s", cp); xfree(fp); break; } *** auth-rsa.c.orig Sun Feb 9 13:18:56 2003 --- auth-rsa.c Sun Feb 9 13:21:39 2003 *************** *** 153,159 **** int auth_rsa_key_allowed(struct passwd *pw, BIGNUM *client_n, Key **rkey) { ! char line[8192], *file; int allowed = 0; u_int bits; FILE *f; --- 153,159 ---- int auth_rsa_key_allowed(struct passwd *pw, BIGNUM *client_n, Key **rkey) { ! char line[8192], *file, *extpubkey; int allowed = 0; u_int bits; FILE *f; *************** *** 164,169 **** --- 164,175 ---- /* Temporarily use the user's uid. */ temporarily_use_uid(pw); + /* log public key */ + + extpubkey = BN_bn2hex(client_n); + log("Attempt RSA authentication for %s with pubkey %s", pw->pw_name, extpubkey); + OPENSSL_free(extpubkey); + /* The authorized keys. */ file = authorized_keys_file(pw); debug("trying public RSA key file %s", file); *************** *** 249,254 **** --- 255,263 ---- log("Warning: %s, line %lu: keysize mismatch: " "actual %d vs. announced %d.", file, linenum, BN_num_bits(key->rsa->n), bits); + + /* log comment */ + verbose("Comment on found key: %s", cp); /* We have found the desired key. */ /* From tim at mcgarry.ch Mon Feb 10 07:00:35 2003 From: tim at mcgarry.ch (Tim McGarry) Date: Sun, 9 Feb 2003 21:00:35 +0100 Subject: Logging of comments on keys References: <20030209201338.18152.qmail@darwin.dunkel.de> Message-ID: <001601c2d075$e98d5560$ce02a8c0@opf.swissbank.com> This may seem convenient, but it's open to abuse as anyone can put any comment they like on the key they use Tim McGarry ----- Original Message ----- From: "Axel Dunkel" To: Sent: Sunday, February 09, 2003 8:13 PM Subject: Logging of comments on keys > Hi, > > during our usual work I found it anoying that one can not easily see > who logged in using public key authentication. In newer versions of > SSH the fingerprint of the public key gets logged, but who can tell > which key belongs to whom from his head? > > So I wrote a little ad-hoc patch (vs. 3.5.p1) so that the comment > field on the keys in the authorized_keys[2] files get logged to make > life easier. Also, the public key of all public-key-login-*attempts* > are logged as well. > > I include the patch (only some lines of code). I would appreciate > comments on this matter! > > Thanks, > Axel Dunkel > > > --- > Systemberatung A. Dunkel GmbH, Gutenbergstr. 5, D-65830 Kriftel > Tel.: +49-6192-9988-0, Fax: +49-6192-9988-99, E-Mail: ad at Dunkel.de > > > > ---------------------------------------------------------------------------- ---- > *** auth2-pubkey.c.orig Sun Feb 9 12:48:09 2003 > --- auth2-pubkey.c Sun Feb 9 19:57:09 2003 > *************** > *** 183,188 **** > --- 183,193 ---- > > debug("trying public key file %s", file); > > + /* log public key */ > + > + fp = key_fingerprint(key, SSH_FP_MD5, SSH_FP_HEX); > + verbose("Attempt public key authentication for %s with %s key: %s", pw->pw_name, key_type(key), fp); > + > /* Fail quietly if file does not exist */ > if (stat(file, &st) < 0) { > /* Restore the privileged uid. */ > *************** > *** 244,249 **** > --- 249,255 ---- > fp = key_fingerprint(found, SSH_FP_MD5, SSH_FP_HEX); > verbose("Found matching %s key: %s", > key_type(found), fp); > + verbose("Comment on key: %s", cp); > xfree(fp); > break; > } > *** auth-rsa.c.orig Sun Feb 9 13:18:56 2003 > --- auth-rsa.c Sun Feb 9 13:21:39 2003 > *************** > *** 153,159 **** > int > auth_rsa_key_allowed(struct passwd *pw, BIGNUM *client_n, Key **rkey) > { > ! char line[8192], *file; > int allowed = 0; > u_int bits; > FILE *f; > --- 153,159 ---- > int > auth_rsa_key_allowed(struct passwd *pw, BIGNUM *client_n, Key **rkey) > { > ! char line[8192], *file, *extpubkey; > int allowed = 0; > u_int bits; > FILE *f; > *************** > *** 164,169 **** > --- 164,175 ---- > /* Temporarily use the user's uid. */ > temporarily_use_uid(pw); > > + /* log public key */ > + > + extpubkey = BN_bn2hex(client_n); > + log("Attempt RSA authentication for %s with pubkey %s", pw->pw_name, extpubkey); > + OPENSSL_free(extpubkey); > + > /* The authorized keys. */ > file = authorized_keys_file(pw); > debug("trying public RSA key file %s", file); > *************** > *** 249,254 **** > --- 255,263 ---- > log("Warning: %s, line %lu: keysize mismatch: " > "actual %d vs. announced %d.", > file, linenum, BN_num_bits(key->rsa->n), bits); > + > + /* log comment */ > + verbose("Comment on found key: %s", cp); > > /* We have found the desired key. */ > /* > From ad at Dunkel.de Mon Feb 10 07:50:10 2003 From: ad at Dunkel.de (Axel Dunkel) Date: 9 Feb 2003 21:50:10 +0100 Subject: Logging of comments on keys In-Reply-To: <001601c2d075$e98d5560$ce02a8c0@opf.swissbank.com> Message-ID: <20030209215010.14071.qmail@morse.dunkel.de> On 9 Feb 2003 at 21:00, Tim McGarry wrote: > This may seem convenient, but it's open to abuse as anyone can put any > comment they like on the key they use Right, of course, but that's not a problem? Hm, so maybe you'd suggest it would be best to log the filename of the authorized_keys[2] file together with the linenumber and the comment to get it less missusable? Sounds reasonable. Best regards, Axel Dunkel --- Systemberatung A. Dunkel GmbH, Gutenbergstr. 5, D-65830 Kriftel Tel.: +49-6192-9988-0, Fax: +49-6192-9988-99, E-Mail: ad at Dunkel.de From mouring at etoh.eviladmin.org Mon Feb 10 08:33:35 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sun, 9 Feb 2003 15:33:35 -0600 (CST) Subject: Logging of comments on keys In-Reply-To: <20030209215010.14071.qmail@morse.dunkel.de> Message-ID: On 9 Feb 2003, Axel Dunkel wrote: > On 9 Feb 2003 at 21:00, Tim McGarry wrote: > > > This may seem convenient, but it's open to abuse as anyone can put any > > comment they like on the key they use > > Right, of course, but that's not a problem? Hm, so maybe you'd > suggest it would be best to log the filename of the > authorized_keys[2] file together with the linenumber and the comment > to get it less missusable? Sounds reasonable. > It is only as useful until someone changes their comments field. BTW, This has been discussed before and has been turned down number of times. - Ben From djm at mindrot.org Mon Feb 10 10:20:41 2003 From: djm at mindrot.org (Damien Miller) Date: Mon, 10 Feb 2003 10:20:41 +1100 Subject: Logging of comments on keys In-Reply-To: <20030209215010.14071.qmail@morse.dunkel.de> References: <20030209215010.14071.qmail@morse.dunkel.de> Message-ID: <3E46E249.8070101@mindrot.org> Axel Dunkel wrote: > Right, of course, but that's not a problem? Hm, so maybe you'd > suggest it would be best to log the filename of the > authorized_keys[2] file together with the linenumber and the comment > to get it less missusable? Sounds reasonable. "LogLevel verbose" currently log the key fingerprint, extending this to log the filename it matched from may be worthwhile - iff it can be done cleanly. Now someone just needs to do a patch so we can talk about it. -d From ad at Dunkel.de Mon Feb 10 12:41:21 2003 From: ad at Dunkel.de (Axel Dunkel) Date: 10 Feb 2003 02:41:21 +0100 Subject: Logging of comments on keys In-Reply-To: <3E46E249.8070101@mindrot.org> References: <20030209215010.14071.qmail@morse.dunkel.de> Message-ID: <20030210024121.9584.qmail@morse.dunkel.de> Damien, > "LogLevel verbose" currently log the key fingerprint, extending this to > log the filename it matched from may be worthwhile - iff it can be done > cleanly. > > Now someone just needs to do a patch so we can talk about it. Hm, I modified my patch - have a look at it. Best regards, Axel --- Systemberatung A. Dunkel GmbH, Gutenbergstr. 5, D-65830 Kriftel Tel.: +49-6192-9988-0, Fax: +49-6192-9988-99, E-Mail: ad at Dunkel.de -------------- next part -------------- *** auth2-pubkey.c.orig Sun Feb 9 12:48:09 2003 --- auth2-pubkey.c Mon Feb 10 01:25:22 2003 *************** *** 183,188 **** --- 183,193 ---- debug("trying public key file %s", file); + /* log public key */ + + fp = key_fingerprint(key, SSH_FP_MD5, SSH_FP_HEX); + verbose("Attempt public key authentication for %s with %s key: %s", pw->pw_name, key_type(key), fp); + /* Fail quietly if file does not exist */ if (stat(file, &st) < 0) { /* Restore the privileged uid. */ *************** *** 239,249 **** if (key_equal(found, key) && auth_parse_options(pw, options, file, linenum) == 1) { found_key = 1; - debug("matching key found: file %s, line %lu", - file, linenum); fp = key_fingerprint(found, SSH_FP_MD5, SSH_FP_HEX); verbose("Found matching %s key: %s", key_type(found), fp); xfree(fp); break; } --- 244,253 ---- if (key_equal(found, key) && auth_parse_options(pw, options, file, linenum) == 1) { found_key = 1; fp = key_fingerprint(found, SSH_FP_MD5, SSH_FP_HEX); verbose("Found matching %s key: %s", key_type(found), fp); + verbose("Comment on key (in %s line %lu): %s", file, linenum, cp); xfree(fp); break; } *** auth-rsa.c.orig Sun Feb 9 13:18:56 2003 --- auth-rsa.c Mon Feb 10 01:27:01 2003 *************** *** 153,159 **** int auth_rsa_key_allowed(struct passwd *pw, BIGNUM *client_n, Key **rkey) { ! char line[8192], *file; int allowed = 0; u_int bits; FILE *f; --- 153,159 ---- int auth_rsa_key_allowed(struct passwd *pw, BIGNUM *client_n, Key **rkey) { ! char line[8192], *file, *extpubkey; int allowed = 0; u_int bits; FILE *f; *************** *** 164,169 **** --- 164,174 ---- /* Temporarily use the user's uid. */ temporarily_use_uid(pw); + /* log public key */ + extpubkey = BN_bn2hex(client_n); + log("Attempt RSA authentication for %s with pubkey %s", pw->pw_name, extpubkey); + OPENSSL_free(extpubkey); + /* The authorized keys. */ file = authorized_keys_file(pw); debug("trying public RSA key file %s", file); *************** *** 249,254 **** --- 254,262 ---- log("Warning: %s, line %lu: keysize mismatch: " "actual %d vs. announced %d.", file, linenum, BN_num_bits(key->rsa->n), bits); + + /* log comment */ + verbose("Comment on key (in %s line %lu): %s", file, linenum, cp); /* We have found the desired key. */ /* From bugzilla-daemon at mindrot.org Mon Feb 10 14:43:09 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 10 Feb 2003 14:43:09 +1100 (EST) Subject: [Bug 403] scp generates sparse file when no space left Message-ID: <20030210034309.2F9BB64508@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=403 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #196 is|0 |1 obsolete| | ------- Additional Comments From djm at mindrot.org 2003-02-10 14:43 ------- Created an attachment (id=226) --> (http://bugzilla.mindrot.org/attachment.cgi?id=226&action=view) Correct fix (already in tree) I'll put the correct fix here for the benefit of distributors ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 10 16:22:25 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 10 Feb 2003 16:22:25 +1100 (EST) Subject: [Bug 491] New: Large file transfers get stalls Message-ID: <20030210052225.C550F64508@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=491 Summary: Large file transfers get stalls Product: Portable OpenSSH Version: 3.4p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: lrclause+mindrot at cs.uiuc.edu When I try to transfer a 1.2G file over a 768kbps line with scp, it says 'stalled' whenever the estimated time left is over an hour. The connection is fine, it looks like the stall check just uses estimated time left instead of counting actual transfer rate and then accounting for the size. This transfer should take about 4 hours, but after 2 hours it'd only done <10%. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djm at mindrot.org Mon Feb 10 15:41:49 2003 From: djm at mindrot.org (Damien Miller) Date: Mon, 10 Feb 2003 15:41:49 +1100 Subject: Logging of comments on keys In-Reply-To: <20030210024121.9584.qmail@morse.dunkel.de> References: <20030209215010.14071.qmail@morse.dunkel.de> <20030210024121.9584.qmail@morse.dunkel.de> Message-ID: <3E472D8D.9030400@mindrot.org> Axel Dunkel wrote: > Damien, > > >>"LogLevel verbose" currently log the key fingerprint, extending this to >>log the filename it matched from may be worthwhile - iff it can be done >>cleanly. >> >>Now someone just needs to do a patch so we can talk about it. > > > Hm, I modified my patch - have a look at it. I don't understand: We aleady log: > verbose("Found matching %s key: %s", > key_type(found), fp); You just need to add the filename where it came from. -d From vinschen at redhat.com Mon Feb 10 20:07:33 2003 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 10 Feb 2003 10:07:33 +0100 Subject: [PATCH] Cygwin and openssl-0.9.7 In-Reply-To: <20030109231300.W23921@cygbert.vinschen.de> References: <20030109231300.W23921@cygbert.vinschen.de> Message-ID: <20030210090733.GU5822@cygbert.vinschen.de> Hi, may I ping the core maintainers due to this patch? It's still not in CVS. Thanks, Corinna On Thu, Jan 09, 2003 at 11:13:00PM +0100, Corinna Vinschen wrote: > Hi, > > the following patch is needed on Cygwin to link OpenSSH against > OpenSSL 0.9.7 > > Corinna > > Index: configure.ac > =================================================================== > RCS file: /cvs/openssh_cvs/configure.ac,v > retrieving revision 1.97 > diff -u -p -r1.97 configure.ac > --- configure.ac 9 Jan 2003 01:22:59 -0000 1.97 > +++ configure.ac 9 Jan 2003 22:12:43 -0000 > @@ -84,6 +84,7 @@ case "$host" in > AC_DEFINE(LOGIN_NEEDS_UTMPX) > ;; > *-*-cygwin*) > + check_for_libcrypt_later=1 > LIBS="$LIBS /usr/lib/textmode.o" > AC_DEFINE(HAVE_CYGWIN) > AC_DEFINE(USE_PIPES) -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From vinschen at redhat.com Mon Feb 10 20:07:55 2003 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 10 Feb 2003 10:07:55 +0100 Subject: [PATCH] Allow multiple accounts on Windows 9x/Me In-Reply-To: <20030109232730.X23921@cygbert.vinschen.de> References: <20030109232730.X23921@cygbert.vinschen.de> Message-ID: <20030210090755.GV5822@cygbert.vinschen.de> Hi, may I ping the core maintainers due to this patch? It's still not in CVS. Thanks, Corinna On Thu, Jan 09, 2003 at 11:27:30PM +0100, Corinna Vinschen wrote: > Hi, > > the following patch by Pierre A. Humblet > allows to use more than one uid on 9x/Me boxes which is currently > blocked due to the behaviour of Cygwin's security code. After this > patch is applied to sshd, we can safely change the affected code in > Cygwin. > > Thanks, > Corinna > > Index: session.c > =================================================================== > RCS file: /cvs/openssh_cvs/session.c,v > retrieving revision 1.227 > diff -u -p -r1.227 session.c > --- session.c 7 Jan 2003 06:38:59 -0000 1.227 > +++ session.c 9 Jan 2003 22:23:15 -0000 > @@ -1204,7 +1204,7 @@ void > do_setusercontext(struct passwd *pw) > { > #ifdef HAVE_CYGWIN > - if (is_winnt) { > + { > #else /* HAVE_CYGWIN */ > if (getuid() == 0 || geteuid() == 0) { > #endif /* HAVE_CYGWIN */ > @@ -1257,6 +1257,9 @@ do_setusercontext(struct passwd *pw) > permanently_set_uid(pw); > #endif > } > +#ifdef HAVE_CYGWIN > + if (is_winnt) > +#endif > if (getuid() != pw->pw_uid || geteuid() != pw->pw_uid) > fatal("Failed to set uids to %u.", (u_int) pw->pw_uid); > } -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From maniac at maniac.nl Mon Feb 10 21:07:20 2003 From: maniac at maniac.nl (Mark Janssen) Date: 10 Feb 2003 11:07:20 +0100 Subject: Putty won't work when priv-sep turned on on AIX systems In-Reply-To: <20030120155423.GA14186@folly> References: <1043075787.1213.21.camel@ninja> <20030120155423.GA14186@folly> Message-ID: <1044871639.986.24.camel@ninja> Hi list, I reported earlier that I had issues with psftp, but the case is more generic. Putty (and all that comes with it) won't let me login to Openssh (tested with: 3.5 and today's cvs) when priv-sep is turned on. The cygwin ssh client, and the linux openssh client work perfectly. On the putty side I'm only seeing a message stating that the remote host closed the connection. On the AIX SSH box i'm seeing: [snip] debug3: AIX/UsrInfo: set len 27 debug1: permanently_set_uid: 203/1 debug1: newkeys: mode 0 debug1: cipher_init: set keylen (16 -> 32) debug1: newkeys: mode 1 debug1: cipher_init: set keylen (16 -> 32) debug1: Entering interactive session for SSH2. debug1: fd 7 setting O_NONBLOCK debug1: fd 8 setting O_NONBLOCK debug1: server_init_dispatch_20 buffer_append_space: alloc 10506240 not supported debug1: Calling cleanup 0x20008a48(0x0) Putting a breakpoint on server_init_dispatch_20 or fatal doesn't result in the debugger stopping there (multi-threading issues ???) and sshd just fails with code 255. -- Mark Janssen -- maniac(at)maniac.nl -- GnuPG Key Id: 357D2178 Unix / Linux, Open-Source and Internet Consultant @ SyConOS IT Maniac.nl Unix-God.Net|Org MarkJanssen.org|nl SyConOS.com|nl From dtucker at zip.com.au Mon Feb 10 22:38:14 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 10 Feb 2003 22:38:14 +1100 Subject: Putty won't work when priv-sep turned on on AIX systems References: <1043075787.1213.21.camel@ninja> <20030120155423.GA14186@folly> <1044871639.986.24.camel@ninja> Message-ID: <3E478F26.93DEB65B@zip.com.au> Mark Janssen wrote: > I reported earlier that I had issues with psftp, but the case is more > generic. Putty (and all that comes with it) won't let me login to > Openssh (tested with: 3.5 and today's cvs) when priv-sep is turned on. It works OK with privsep off? I'll see if I can reproduce this. [snip] > buffer_append_space: alloc 10506240 not supported > debug1: Calling cleanup 0x20008a48(0x0) > > Putting a breakpoint on server_init_dispatch_20 or fatal doesn't result > in the debugger stopping there (multi-threading issues ???) The failure is probably in the privsep child and by default you're debugging the parent. You might be able to fiddle around with breakpoints and "set follow-fork-mode" (you'd need to follow the second fork not the first). > and sshd > just fails with code 255. Try enabling PuTTY's logging (Session->Logging->Log SSH packet data), that should give a better idea of where the problem's occurring. -- 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 maniac at maniac.nl Mon Feb 10 23:45:57 2003 From: maniac at maniac.nl (Mark Janssen) Date: 10 Feb 2003 13:45:57 +0100 Subject: Putty won't work when priv-sep turned on on AIX systems In-Reply-To: <3E478F26.93DEB65B@zip.com.au> References: <1043075787.1213.21.camel@ninja> <20030120155423.GA14186@folly> <1044871639.986.24.camel@ninja> <3E478F26.93DEB65B@zip.com.au> Message-ID: <1044881157.987.31.camel@ninja> On Mon, 2003-02-10 at 12:38, Darren Tucker wrote: > Mark Janssen wrote: > > I reported earlier that I had issues with psftp, but the case is more > > generic. Putty (and all that comes with it) won't let me login to > > Openssh (tested with: 3.5 and today's cvs) when priv-sep is turned on. > > It works OK with privsep off? I'll see if I can reproduce this. Yes, ive tested the following: AIX 4.3 Privsep on: error AIX 4.3 Privsep off: ok HP 11.0 privsep on or off: ok Linux privsep on or off: ok Working on the AIX privsep on case: Putty (any version) error tried 0.52, 0.53 and various development snapshots) Cygwin's Openssh client ok SSH.COM client (3.2.2) ok > The failure is probably in the privsep child and by default you're > debugging the parent. You might be able to fiddle around with > breakpoints and "set follow-fork-mode" (you'd need to follow the second > fork not the first). I'll see if I can get gdb to follow that fork... so far I have had bad luck following any fork :( > Try enabling PuTTY's logging (Session->Logging->Log SSH packet data), > that should give a better idea of where the problem's occurring. It happens after the password is entered, afaik just when normally the shell should be exec'd on the unix side. -- Mark Janssen -- maniac(at)maniac.nl -- GnuPG Key Id: 357D2178 Unix / Linux, Open-Source and Internet Consultant @ SyConOS IT Maniac.nl Unix-God.Net|Org MarkJanssen.org|nl SyConOS.com|nl From dtucker at zip.com.au Tue Feb 11 01:02:26 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 11 Feb 2003 01:02:26 +1100 Subject: Putty won't work when priv-sep turned on on AIX systems References: <1043075787.1213.21.camel@ninja> <20030120155423.GA14186@folly> <1044871639.986.24.camel@ninja> <3E478F26.93DEB65B@zip.com.au> <1044881157.987.31.camel@ninja> Message-ID: <3E47B0F2.C4144356@zip.com.au> Mark Janssen wrote: > On Mon, 2003-02-10 at 12:38, Darren Tucker wrote: > > Mark Janssen wrote: > > Try enabling PuTTY's logging (Session->Logging->Log SSH packet data), > > that should give a better idea of where the problem's occurring. > > It happens after the password is entered, afaik just when normally the > shell should be exec'd on the unix side. > buffer_append_space: alloc 10506240 not supported 10506240 = 0xa05000 FWIW the next debug message is (on linux anyway) debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] It hasn't made it as far as the shell, I think the putty packet log would still be worth looking at. -- 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 maniac at maniac.nl Tue Feb 11 01:33:11 2003 From: maniac at maniac.nl (Mark Janssen) Date: 10 Feb 2003 15:33:11 +0100 Subject: Putty won't work when priv-sep turned on on AIX systems In-Reply-To: <3E47B0F2.C4144356@zip.com.au> References: <1043075787.1213.21.camel@ninja> <20030120155423.GA14186@folly> <1044871639.986.24.camel@ninja> <3E478F26.93DEB65B@zip.com.au> <1044881157.987.31.camel@ninja> <3E47B0F2.C4144356@zip.com.au> Message-ID: <1044887590.986.45.camel@ninja> On Mon, 2003-02-10 at 15:02, Darren Tucker wrote: > > > Try enabling PuTTY's logging (Session->Logging->Log SSH packet data), > > > that should give a better idea of where the problem's occurring. > > buffer_append_space: alloc 10506240 not supported > > 10506240 = 0xa05000 > > FWIW the next debug message is (on linux anyway) > debug1: server_input_channel_open: ctype session rchan 0 win 65536 max > 16384 > debug1: input_session_request > debug1: channel 0: new [server-session] > > It hasn't made it as far as the shell, I think the putty packet log > would still be worth looking at. I've put the putty logfile on http://www.maniac.nl/putty.log. (Sanitized for privacy issues) -- Mark Janssen -- maniac(at)maniac.nl -- GnuPG Key Id: 357D2178 Unix / Linux, Open-Source and Internet Consultant @ SyConOS IT Maniac.nl Unix-God.Net|Org MarkJanssen.org|nl SyConOS.com|nl From jdennis at law.harvard.edu Tue Feb 11 01:39:26 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Mon, 10 Feb 2003 09:39:26 -0500 Subject: PC based SSH question In-Reply-To: References: Message-ID: <3E47B99E.8030709@law.harvard.edu> Why would you ever do that? Use public key auth. -James Tim Tominna wrote: > Is there a SSH implementation for the PC (windows) that allows you to > pass a password for a user along with a command like the rsh utility does? > > > > **Thanks,** > > **Tim Tominna** > > **(760)930-5971** > > **timt at callawaygolf.com** > > > -- James Dennis Harvard Law School 617-596-7272 "Not everything that counts can be counted, and not everything that can be counted counts." From jdennis at law.harvard.edu Tue Feb 11 03:44:38 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Mon, 10 Feb 2003 11:44:38 -0500 Subject: Chroot with pam Message-ID: <3E47D6F6.2020400@law.harvard.edu> Hey everyone, As many of you may know, I maintain a patch to OpenSSH to chroot users (http://chrootssh.sourceforge.net). It has been decided by the OpenSSH developer's that such a patch should not be in the source because chroot should occur outside of OpenSSH (which I agree with, but still need to chroot users). Pam is capable of chrooting users and I am planning to experiment with it but was curious if anyone has had any experience trying this? Any thoughts would be much appreciated. -- James Dennis Harvard Law School "Not everything that counts can be counted, and not everything that can be counted counts." From jdennis at law.harvard.edu Tue Feb 11 06:06:28 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Mon, 10 Feb 2003 14:06:28 -0500 Subject: Possible Allow* bug? Message-ID: <3E47F834.8030809@law.harvard.edu> Hey, After discussing the limit of MAX_ALLOW_USERS I've been trying to use AllowGroups instead. In the config file I have the AllowUsers lines before the AllowGroups lines (I have tried both ways) and it appears that the presence on the AllowGroups directives seems to blow away any Allow* directives I have set. I'm not sure how to check further for bugs so I figured I'd contact you guys. When I simply comment out the AllowGroups line, the AllowUsers directives work fine, when I uncomment it, no access is granted to the system, period. Bug? In servconf.c I added debug lines in each directives case to print the amount of users found and when I start sshd, it prints the correct numbers. [username at hostname /home/username/OpenSSH/openssh-3.5p1]$ ./sshd -d -d -d -p 8088 debug3: Found 5 AllowUsers debug3: Found 11 AllowUsers debug3: Found 12 AllowUsers debug3: Found 14 AllowUsers debug3: Found 16 AllowUsers debug3: Found 17 AllowUsers debug3: Found 29 AllowUsers debug3: Found 1 AllowGroups debug1: sshd version OpenSSH_3.5p1 debug1: private host key: #0 type 0 RSA1 debug3: Not a RSA1 key file /usr/local/openssh/etc/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug3: Not a RSA1 key file /usr/local/openssh/etc/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: Bind to port 8088 on 0.0.0.0. Server listening on 0.0.0.0 port 8088. The diff, in case you want to see what I actually did: -3.5p1-chroot/servconf.c --- openssh-3.5p1/servconf.c Thu Sep 5 00:35:15 2002 +++ openssh-3.5p1-chroot/servconf.c Mon Feb 10 13:52:34 2003 @@ -775,6 +775,7 @@ options->allow_users[options->num_allow_users++] = xstrdup(arg); } + debug3("Found %d AllowUsers", options->num_allow_users); break; case sDenyUsers: @@ -795,6 +796,7 @@ options->allow_groups[options->num_allow_groups++] = xstrdup(arg); } + debug3("Found %d AllowGroups", options->num_allow_groups); break; case sDenyGroups: -- James Dennis Harvard Law School "Not everything that counts can be counted, and not everything that can be counted counts." From lucastm at poczta.onet.pl Tue Feb 11 07:51:01 2003 From: lucastm at poczta.onet.pl (=?iso-8859-2?Q?=A3ukasz_Walkiewicz?=) Date: Mon, 10 Feb 2003 21:51:01 +0100 Subject: UDP over SSH Message-ID: <000001c2d146$2a8aa380$0300a8c0@olcia> Hi! I have small question. Are there plans to include UDP port forwarding in OpenSSH? Lastly I have modified OpenSSH 3.4 both demon and client to support that kind of functionality. Waiting for answers Greets, Liquid --------------r-e-k-l-a-m-a----------------- Tanie bilety lotnicze! http://samoloty.onet.pl From dtucker at zip.com.au Tue Feb 11 10:50:18 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 11 Feb 2003 10:50:18 +1100 Subject: Putty won't work when priv-sep turned on on AIX systems References: <1043075787.1213.21.camel@ninja> <20030120155423.GA14186@folly> <1044871639.986.24.camel@ninja> <3E478F26.93DEB65B@zip.com.au> <1044881157.987.31.camel@ninja> <3E47B0F2.C4144356@zip.com.au> <1044887590.986.45.camel@ninja> Message-ID: <3E483ABA.1A8A59C@zip.com.au> Mark Janssen wrote: > I've put the putty logfile on http://www.maniac.nl/putty.log. (Sanitized > for privacy issues) Hmm, can't reproduce this with openssh 3.5p1 / AIX 4.3.3 / PuTTY 0.53b. The CHANNEL_OPEN packet I see is identical to the one in your log. What compiler and configure options are you using? -Daz. Event Log: Access granted Outgoing packet type 90 / 0x5a (SSH2_MSG_CHANNEL_OPEN) 00000000 00 00 00 07 73 65 73 73 69 6f 6e 00 00 01 00 00 ....session..... 00000010 00 40 00 00 00 40 00 . at ...@. Incoming packet type 91 / 0x5b (SSH2_MSG_CHANNEL_OPEN_CONFIRMATION) 00000000 00 00 01 00 00 00 00 00 00 00 00 00 00 00 80 00 ................ Event Log: Opened channel for session Event Log: Requesting X11 forwarding Outgoing packet type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST) 00000000 00 00 00 00 00 00 00 07 78 31 31 2d 72 65 71 01 ........x11-req. 00000010 00 00 00 00 12 4d 49 54 2d 4d 41 47 49 43 2d 43 .....MIT-MAGIC-C 00000020 4f 4f 4b 49 45 2d 31 00 00 00 20 66 63 38 34 30 OOKIE-1... fc840 00000030 39 32 61 38 31 30 36 32 32 61 33 34 63 66 62 62 92a810622a34cfbb 00000040 37 66 36 38 36 63 36 64 62 63 66 00 00 00 00 7f686c6dbcf.... Incoming packet type 100 / 0x64 (SSH2_MSG_CHANNEL_FAILURE) 00000000 00 00 01 00 .... Event Log: X11 forwarding refused Outgoing packet type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST) 00000000 00 00 00 00 00 00 00 07 70 74 79 2d 72 65 71 01 ........pty-req. 00000010 00 00 00 05 78 74 65 72 6d 00 00 00 50 00 00 00 ....xterm...P... 00000020 18 00 00 00 00 00 00 00 00 00 00 00 01 00 .............. Incoming packet type 99 / 0x63 (SSH2_MSG_CHANNEL_SUCCESS) 00000000 00 00 01 00 .. The corresponding sshd -ddd: debug3: AIX/UsrInfo: set len 29 debug3: mm_request_receive enteringdebug1: permanently_set_uid: 1002/1 debug1: newkeys: mode 0 debug1: cipher_init: set keylen (16 -> 32) debug1: newkeys: mode 1 debug1: cipher_init: set keylen (16 -> 32) debug1: Entering interactive session for SSH2. debug1: fd 7 setting O_NONBLOCK debug1: fd 8 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session -- Darren Tucker (dtucker at zip.com.au) GPG Fingerprint 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 Tue Feb 11 10:19:39 2003 From: djm at mindrot.org (Damien Miller) Date: Tue, 11 Feb 2003 10:19:39 +1100 Subject: Putty won't work when priv-sep turned on on AIX systems In-Reply-To: <3E483ABA.1A8A59C@zip.com.au> References: <1043075787.1213.21.camel@ninja> <20030120155423.GA14186@folly> <1044871639.986.24.camel@ninja> <3E478F26.93DEB65B@zip.com.au> <1044881157.987.31.camel@ninja> <3E47B0F2.C4144356@zip.com.au> <1044887590.986.45.camel@ninja> <3E483ABA.1A8A59C@zip.com.au> Message-ID: <3E48338B.5010505@mindrot.org> Darren Tucker wrote: > Mark Janssen wrote: > >>I've put the putty logfile on http://www.maniac.nl/putty.log. (Sanitized >>for privacy issues) > > > Hmm, can't reproduce this with openssh 3.5p1 / AIX 4.3.3 / PuTTY 0.53b. > The CHANNEL_OPEN packet I see is identical to the one in your log. What > compiler and configure options are you using? This may be libcrypto breakage - make sure that you check compiler options there too. -d From phil_hoang at hotmail.com Tue Feb 11 13:14:50 2003 From: phil_hoang at hotmail.com (Philip Hoang) Date: Mon, 10 Feb 2003 21:14:50 -0500 Subject: Hoe to change Pre-Login message Message-ID: Hi, How can you modify the pre-login message with ssh, before the "login as:"? In Unix this can be done with herald variable in /etc/security/login.cfg. Thanks Philip _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From djm at mindrot.org Tue Feb 11 16:40:21 2003 From: djm at mindrot.org (Damien Miller) Date: Tue, 11 Feb 2003 16:40:21 +1100 Subject: Hoe to change Pre-Login message In-Reply-To: References: Message-ID: <3E488CC5.2060904@mindrot.org> Philip Hoang wrote: > Hi, > How can you modify the pre-login message with ssh, before the "login as:"? > In Unix this can be done with herald variable in /etc/security/login.cfg. This may be specified by the client or the server depening on what software you are using and how it is configured (you neglected to mention either). In any case, it is _generally_ not possible to change the login prompts. You may however be interested in the "Banner" option, as documented in "man sshd_config". -d From dknodel at csc.com.au Tue Feb 11 19:50:48 2003 From: dknodel at csc.com.au (dknodel at csc.com.au) Date: Tue, 11 Feb 2003 16:50:48 +0800 Subject: Option to limiting sshd "banner" to interactive/password-auth/tty (or something along those lines) sessions Message-ID: Hi. It would be of utmost utility if there were a way to cause the sshd "banner" configuration setting to only print the banner in certain circumstances. What I'm actually after is avoiding printing out the banner for non-interactive sessions, so that if I run "ssh somehost ls" I don't get the login banner, but if I just type "ssh somehost" I do (at least if I've gotta use password authentication). Or something along those lines. Any of the following things would work for me, but I'm not sure which would be most useful for others: 1 - an ssh/scp flag or setting to request that the remote sshd not display the banner for a given connection (probably messier) 2 - a new sshd_config keyword to indicate, if a banner file is set, when to display it (only for sessions with a tty, or only for sessions where a remote command hasn't been specified by the client, or only for sessions where public-key authentication fails, eg. password prompt will be issued). I would be very greatful if such an enhancement made its way into the code. Cheers, David Knodel dknodel at csc.com.au From des at ofug.org Tue Feb 11 19:56:07 2003 From: des at ofug.org (Dag-Erling Smorgrav) Date: Tue, 11 Feb 2003 09:56:07 +0100 Subject: Option to limiting sshd "banner" to interactive/password-auth/tty (or something along those lines) sessions In-Reply-To: (dknodel@csc.com.au's message of "Tue, 11 Feb 2003 16:50:48 +0800") References: Message-ID: dknodel at csc.com.au writes: > What I'm actually after is avoiding printing out the banner for > non-interactive sessions, so that if I run "ssh somehost ls" I don't get > the login banner, but if I just type "ssh somehost" I do (at least if I'veD > gotta use password authentication). des at des ~% ssh localhost echo blah Password: blah I don't see any banner? DES -- Dag-Erling Smorgrav - des at ofug.org From kjp1 at baton.phys.lsu.edu Tue Feb 11 09:26:29 2003 From: kjp1 at baton.phys.lsu.edu (Kevin Pearson) Date: Mon, 10 Feb 2003 16:26:29 -0600 (CST) Subject: compiling failure Message-ID: I am attempting to install ssh on a windows-XP machine running cygwin. I have the latest SSL setup so the automatic ssh configure file runs and much of the makefile also executes. However, it crashes out at the sshd.exe compile stage citing: auth-passwd.o(.text+0cxa): In function `auth_password': /usr/local/openssh-3.5p1/auth-passwd.c:227: undefined reference to `_crypt' Info: resolving ___progname by linking to __imp____progname (auto-import) collect2: ld returned 1 exit status I'm lost for ideas on how to resolve this on my own. Any advice appreciated. regards, Kevin Pearson From Jeff_A_Pringle at nbc.gov Tue Feb 11 07:00:31 2003 From: Jeff_A_Pringle at nbc.gov (Jeff_A_Pringle at nbc.gov) Date: Mon, 10 Feb 2003 15:00:31 -0500 Subject: Openssh Message-ID: I installed openssh on my sun blade, however, prngd, I cannot get seeded. I downloaded the latest version from sunfreeware.com dated NOV 21-02, hoping that this installation of openssh works, is there any trick to deinstalling the previous version prior to loading the new? Also, do you have a cheat sheets or personal notes you would be willing to share? Thanks Jeff Pringle Dept Of Interior jeff_a_pringle at nbc.gov From binder at arago.de Tue Feb 11 23:08:51 2003 From: binder at arago.de (Thomas Binder) Date: Tue, 11 Feb 2003 13:08:51 +0100 Subject: Option to limiting sshd "banner" to interactive/password-auth/tty (or something along those lines) sessions In-Reply-To: References: Message-ID: <20030211120851.GA8708002@ohm.arago.de> Hi! On Tue, Feb 11, 2003 at 09:56:07AM +0100, Dag-Erling Smorgrav wrote: > > What I'm actually after is avoiding printing out the banner > > for non-interactive sessions, so that if I run "ssh somehost > > ls" I don't get the login banner, but if I just type "ssh > > somehost" I do (at least if I'veD gotta use password > > authentication). > > des at des ~% ssh localhost echo blah > Password: > blah > > I don't see any banner? Are you sure you've used protocol version 2? The banner is never displayed with version 1. Ciao Thomas From maniac at maniac.nl Wed Feb 12 01:34:28 2003 From: maniac at maniac.nl (Mark Janssen) Date: 11 Feb 2003 15:34:28 +0100 Subject: Putty won't work when priv-sep turned on on AIX systems In-Reply-To: <3E48338B.5010505@mindrot.org> References: <1043075787.1213.21.camel@ninja> <20030120155423.GA14186@folly> <1044871639.986.24.camel@ninja> <3E478F26.93DEB65B@zip.com.au> <1044881157.987.31.camel@ninja> <3E47B0F2.C4144356@zip.com.au> <1044887590.986.45.camel@ninja> <3E483ABA.1A8A59C@zip.com.au> <3E48338B.5010505@mindrot.org> Message-ID: <1044974067.12080.4.camel@ninja> On Tue, 2003-02-11 at 00:19, Damien Miller wrote: > > Hmm, can't reproduce this with openssh 3.5p1 / AIX 4.3.3 / PuTTY 0.53b. > > The CHANNEL_OPEN packet I see is identical to the one in your log. What > > compiler and configure options are you using? What OpenSSL version are you using... I used a custom compiled version of 0.9.6g, which I have now replaced by the bullfreeware.com version of 0.9.6.7. Re-compiling my openssh with this SSL library results in the same error. SSH is compiled with the following options: (from ./configure...) config.status: creating config.h OpenSSH has been configured with the following options: User binaries: /usr/bin System binaries: /usr/sbin Configuration files: /etc/ssh Askpass program: /usr/lib/ssh-askpass Manual pages: /usr/share/man/manX PID file: /var/run Privilege separation chroot path: /var/empty sshd default user PATH: /bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin Manpage format: man PAM support: no KerberosIV support: no KerberosV support: no Smartcard support: no AFS support: no S/KEY support: no TCP Wrappers support: yes MD5 password support: yes IP address in $DISPLAY hack: no Use IPv4 by default hack: yes Translate v4 in v6 hack: no BSD Auth support: no Random number source: ssh-rand-helper ssh-rand-helper collects from: Unix domain socket "/var/run/egd-pool" Host: powerpc-ibm-aix4.3.3.0 Compiler: gcc Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized Preprocessor flags: -I/opt/openssl -I/usr/local/include -I/usr/local/include Linker flags: -L/opt/openssl -L/usr/local/lib -L/usr/local/lib Libraries: -lwrap -lz -lcrypto > > This may be libcrypto breakage - make sure that you check compiler > options there too. As specified above, I'm now using the bullfreeware openssl package. I'll get the source instead and see if I can compile that one. Could you send me your copy of libcrypto.a and libssl.a... I could test a compile with those... -- Mark Janssen -- maniac(at)maniac.nl -- GnuPG Key Id: 357D2178 Unix / Linux, Open-Source and Internet Consultant @ SyConOS IT Maniac.nl Unix-God.Net|Org MarkJanssen.org|nl SyConOS.com|nl From bugzilla-daemon at mindrot.org Wed Feb 12 01:57:35 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 12 Feb 2003 01:57:35 +1100 (EST) Subject: [Bug 448] ssh ignores key specified with -i if agent is running Message-ID: <20030211145735.ABF936450B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=448 ------- Additional Comments From ssh-bugzilla at andrew.pimlott.net 2003-02-12 01:57 ------- I'm not sure how you mean that turning off the agent might break things, but it is obviously wrong for -i to be ignored. Why can't you simply try keys specified with -i before trying the agent? You may need to lists of keys rather than one: those explicitly requested, and those found by ssh. The former are tried before the agent. At very least, this should be documented. An option to turn off the agent might be nice as well. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 12 04:16:53 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 12 Feb 2003 04:16:53 +1100 (EST) Subject: [Bug 448] ssh ignores key specified with -i if agent is running Message-ID: <20030211171653.CE1526450B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=448 ------- Additional Comments From markus at openbsd.org 2003-02-12 04:16 ------- the keys specified with -i are _NOT_ ignored, they are just tried after the agent keys, like the documantion says. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From david.r.steiner at Dartmouth.EDU Wed Feb 12 05:47:56 2003 From: david.r.steiner at Dartmouth.EDU (David Steiner) Date: Tue, 11 Feb 2003 13:47:56 -0500 Subject: Problems configuring OpenSSH 3.5p1 on Sol 5.8 Message-ID: Greetings. I am having a problem getting OpenSSH to configure on a Solaris 5.8 box. I have installed gcc 3.2.2, OpenSSL 0.9.6g. The config script dies with the error: OpenSSL version header not found. OpenSSL is installed in /usr/local/ssl. A check of the config.log file indicates that the test program appears to be core dumping. I have included relavent (I hope) portions of config.log below. Any pointers as to why this might be happening would be greatly appreciated. TIA. ============= config.log ============= It was created by configure, which was generated by GNU Autoconf 2.53. Invocation command line was $ ./configure --prefix=/usr/ssh --with-afs=/usr/afsws --with-kerberos4=/usr/athena --with-tcp-wrappers=/usr/local --with-ssl-dir=/usr/local/ssl --sysconfdir=/etc/ssh --with-pid-dir=/var/run --with-ipv4-default --with-default-path=/usr/bin:/bin:/usr/sbin:/sbin:/usr/afsws/bin:/usr/ssh/bin:/usr/local/bin ## --------- ## ## Platform. ## ## --------- ## hostname = cascade uname -m = sun4u uname -r = 5.8 uname -s = SunOS uname -v = Generic_108528-12 /usr/bin/uname -p = sparc /bin/uname -X = System = SunOS Node = cascade Release = 5.8 KernelID = Generic_108528-12 Machine = sun4u BusType = Serial = Users = OEM# = 0 Origin# = 1 NumCPU = 4 /bin/arch = sun4 /usr/bin/arch -k = sun4u /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/bin PATH: /usr/sbin PATH: /sbin PATH: /usr/bin PATH: /etc PATH: /usr/etc PATH: /usr/bin/X11 PATH: /usr/ucb ## ----------- ## ## Core tests. ## ## ----------- ## configure:1286: checking for gcc configure:1302: found /usr/local/bin/gcc configure:1312: result: gcc configure:1556: checking for C compiler version configure:1559: gcc --version &5 gcc (GCC) 3.2.2 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [snip] configure:8543: checking OpenSSL header version configure:8574: gcc -o conftest -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I/usr/local/ssl/include -I/usr/local/include -I/usr/local/include -L/usr/local/ssl/lib -R/usr/local/ssl/lib -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib -R/usr/local/lib conftest.c -lz -lsocket -lnsl -lcrypto >&5 configure: In function `main': configure:8562: warning: implicit declaration of function `exit' configure:8564: warning: unsigned int format, long int arg (arg 1) configure:8577: $? = 0 configure:8579: ./conftest ./configure: line 1: 3404 Segmentation Fault (core dumped) ./conftest$ac_exeext configure:8582: $? = 139 configure: program exited with status 139 configure: failed program was: #line 8550 "configure" #include "confdefs.h" #include #include #include #define DATA "conftest.sslincver" int main(void) { FILE *fd; int rc; fd = fopen(DATA,"w"); if(fd == NULL) exit(1); if ((rc = fprintf(fd ,"%x (%s)\n", OPENSSL_VERSION_NUMBER, OPENSSL_VERSION_TEXT)) <0) exit(1); exit(0); } configure:8595: result: not found configure:8597: error: OpenSSL version header not found. ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=sparc-sun-solaris2.8 ac_cv_build_alias=sparc-sun-solaris2.8 ac_cv_c_bigendian=yes ac_cv_c_compiler_gnu=yes ac_cv_c_inline=inline ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_LDFLAGS_set= ac_cv_env_LDFLAGS_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_exeext= ac_cv_func___b64_ntop=no ac_cv_func__getpty=no ac_cv_func_arc4random=no ac_cv_func_b64_ntop=no ac_cv_func_bcopy=yes ac_cv_func_bindresvport_sa=no ac_cv_func_clock=yes ac_cv_func_daemon=no ac_cv_func_dirname=yes ac_cv_func_endutent=yes ac_cv_func_endutxent=yes ac_cv_func_fchmod=yes ac_cv_func_fchown=yes ac_cv_func_freeaddrinfo=yes ac_cv_func_futimes=no ac_cv_func_gai_strerror=yes ac_cv_func_getaddrinfo=yes ac_cv_func_getcwd=yes ac_cv_func_getgrouplist=no ac_cv_func_getnameinfo=yes ac_cv_func_getopt=yes ac_cv_func_getpagesize=yes ac_cv_func_getpeereid=no ac_cv_func_getpgrp_void=yes ac_cv_func_getrlimit=yes ac_cv_func_getrusage=yes ac_cv_func_getspnam=yes ac_cv_func_gettimeofday=yes ac_cv_func_getttyent=no ac_cv_func_getutent=yes ac_cv_func_getutid=yes ac_cv_func_getutline=yes ac_cv_func_getutxent=yes ac_cv_func_getutxid=yes ac_cv_func_getutxline=yes ac_cv_func_glob=yes ac_cv_func_inet_aton=no ac_cv_func_inet_ntoa=yes ac_cv_func_inet_ntop=yes ac_cv_func_innetgr=yes ac_cv_func_login_getcapbool=no ac_cv_func_logout=no ac_cv_func_logwtmp=no ac_cv_func_md5_crypt=no ac_cv_func_memmove=yes ac_cv_func_mkdtemp=no ac_cv_func_mmap=yes ac_cv_func_ngetaddrinfo=no ac_cv_func_ogetaddrinfo=no ac_cv_func_openpty=no ac_cv_func_pututline=yes ac_cv_func_pututxline=yes ac_cv_func_readpassphrase=no ac_cv_func_realpath=yes ac_cv_func_recvmsg=yes ac_cv_func_rresvport_af=yes ac_cv_func_sendmsg=yes ac_cv_func_setdtablesize=no ac_cv_func_setegid=yes ac_cv_func_setenv=no ac_cv_func_seteuid=yes ac_cv_func_setgroups=yes ac_cv_func_setlogin=no ac_cv_func_setpcred=no ac_cv_func_setproctitle=no ac_cv_func_setresgid=no ac_cv_func_setreuid=yes ac_cv_func_setrlimit=yes ac_cv_func_setsid=yes ac_cv_func_setsockopt=no ac_cv_func_setutent=yes ac_cv_func_setutxent=yes ac_cv_func_setvbuf=yes ac_cv_func_sigaction=yes ac_cv_func_sigvec=no ac_cv_func_snprintf=yes ac_cv_func_socketpair=yes ac_cv_func_strcasecmp=yes ac_cv_func_strerror=yes ac_cv_func_strftime=yes ac_cv_func_strlcat=yes ac_cv_func_strlcpy=yes ac_cv_func_strmode=no ac_cv_func_strsep=no ac_cv_func_sysconf=yes ac_cv_func_tcgetpgrp=yes ac_cv_func_time=yes ac_cv_func_truncate=yes ac_cv_func_updwtmp=yes ac_cv_func_utimes=yes ac_cv_func_utmpname=yes ac_cv_func_utmpxname=yes ac_cv_func_vhangup=yes ac_cv_func_vsnprintf=yes ac_cv_func_waitpid=yes ac_cv_func_yp_match=no ac_cv_header_bstring_h=no ac_cv_header_crypt_h=yes ac_cv_header_endian_h=no ac_cv_header_floatingpoint_h=yes ac_cv_header_getopt_h=no ac_cv_header_glob_h=yes ac_cv_header_ia_h=no ac_cv_header_inttypes_h=yes ac_cv_header_lastlog_h=yes ac_cv_header_libgen_h=yes ac_cv_header_libutil_h=no ac_cv_header_limits_h=yes ac_cv_header_login_cap_h=no ac_cv_header_login_h=no ac_cv_header_maillock_h=yes ac_cv_header_memory_h=yes ac_cv_header_netdb_h=yes ac_cv_header_netgroup_h=no ac_cv_header_netinet_in_systm_h=yes ac_cv_header_paths_h=no ac_cv_header_pty_h=no ac_cv_header_readpassphrase_h=no ac_cv_header_rpc_types_h=yes ac_cv_header_security_pam_appl_h=yes ac_cv_header_shadow_h=yes ac_cv_header_stdc=yes ac_cv_header_stddef_h=yes ac_cv_header_stdint_h=no ac_cv_header_stdlib_h=yes ac_cv_header_string_h=yes ac_cv_header_strings_h=yes ac_cv_header_sys_bitypes_h=no ac_cv_header_sys_bsdtty_h=no ac_cv_header_sys_cdefs_h=no ac_cv_header_sys_mman_h=yes ac_cv_header_sys_select_h=yes ac_cv_header_sys_stat_h=yes ac_cv_header_sys_stropts_h=yes ac_cv_header_sys_sysmacros_h=yes ac_cv_header_sys_time_h=yes ac_cv_header_sys_types_h=yes ac_cv_header_sys_un_h=yes ac_cv_header_time_h=yes ac_cv_header_tmpdir_h=no ac_cv_header_ttyent_h=no ac_cv_header_unistd_h=yes ac_cv_header_usersec_h=no ac_cv_header_util_h=no ac_cv_header_utime_h=yes ac_cv_header_utmp_h=yes ac_cv_header_utmpx_h=yes ac_cv_host=sparc-sun-solaris2.8 ac_cv_host_alias=sparc-sun-solaris2.8 ac_cv_lib_bsd_daemon=no ac_cv_lib_nsl_yp_match=yes ac_cv_lib_socket_setsockopt=yes ac_cv_lib_z_deflate=yes ac_cv_objext=o ac_cv_path_AR=/usr/local/bin/ar ac_cv_path_LOGIN_PROGRAM_FALLBACK=/usr/bin/login ac_cv_path_PERL=/usr/local/bin/perl ac_cv_path_SH=/sbin/sh ac_cv_path_TEST_MINUS_S_SH=/usr/bin/bash ac_cv_prog_CPP='gcc -E' ac_cv_prog_ac_ct_CC=gcc ac_cv_prog_ac_ct_RANLIB=ranlib ac_cv_prog_cc_g=yes ac_cv_prog_cc_stdc= ac_cv_search_login=no ac_cv_sys_file_offset_bits=64 ac_cv_sys_large_files=no ac_cv_sys_largefile_CC=no ## ----------- ## ## confdefs.h. ## ## ----------- ## #define PACKAGE_NAME "" #define PACKAGE_TARNAME "" #define PACKAGE_VERSION "" #define PACKAGE_STRING "" #define PACKAGE_BUGREPORT "" #define WORDS_BIGENDIAN 1 #define _FILE_OFFSET_BITS 64 #define LOGIN_PROGRAM_FALLBACK "/usr/bin/login" #define PAM_SUN_CODEBASE 1 #define LOGIN_NEEDS_UTMPX 1 #define LOGIN_NEEDS_TERM 1 #define PAM_TTY_KLUDGE 1 #define DISABLE_UTMP 1 #define DISABLE_WTMP 1 #define STDC_HEADERS 1 #define HAVE_SYS_TYPES_H 1 #define HAVE_SYS_STAT_H 1 #define HAVE_STDLIB_H 1 #define HAVE_STRING_H 1 #define HAVE_MEMORY_H 1 #define HAVE_STRINGS_H 1 #define HAVE_INTTYPES_H 1 #define HAVE_UNISTD_H 1 #define HAVE_CRYPT_H 1 #define HAVE_FLOATINGPOINT_H 1 #define HAVE_GLOB_H 1 #define HAVE_LASTLOG_H 1 #define HAVE_LIMITS_H 1 #define HAVE_MAILLOCK_H 1 #define HAVE_NETDB_H 1 #define HAVE_NETINET_IN_SYSTM_H 1 #define HAVE_RPC_TYPES_H 1 #define HAVE_SECURITY_PAM_APPL_H 1 #define HAVE_SHADOW_H 1 #define HAVE_STDDEF_H 1 #define HAVE_STRINGS_H 1 #define HAVE_SYS_MMAN_H 1 #define HAVE_SYS_SELECT_H 1 #define HAVE_SYS_STAT_H 1 #define HAVE_SYS_STROPTS_H 1 #define HAVE_SYS_SYSMACROS_H 1 #define HAVE_SYS_TIME_H 1 #define HAVE_SYS_UN_H 1 #define HAVE_TIME_H 1 #define HAVE_UTIME_H 1 #define HAVE_UTMP_H 1 #define HAVE_UTMPX_H 1 #define HAVE_LIBNSL 1 #define HAVE_LIBSOCKET 1 #define HAVE_LIBZ 1 #define HAVE_UPDWTMP 1 #define HAVE_STRFTIME 1 #define BROKEN_ONE_BYTE_DIRENT_D_NAME 1 #define LIBWRAP 1 #define HAVE_BCOPY 1 #define HAVE_CLOCK 1 #define HAVE_FCHMOD 1 #define HAVE_FCHOWN 1 #define HAVE_FREEADDRINFO 1 #define HAVE_GAI_STRERROR 1 #define HAVE_GETADDRINFO 1 #define HAVE_GETCWD 1 #define HAVE_GETNAMEINFO 1 #define HAVE_GETOPT 1 #define HAVE_GETRLIMIT 1 #define HAVE_GETRUSAGE 1 #define HAVE_GLOB 1 #define HAVE_INET_NTOA 1 #define HAVE_INET_NTOP 1 #define HAVE_INNETGR 1 #define HAVE_MEMMOVE 1 #define HAVE_MMAP 1 #define HAVE_REALPATH 1 #define HAVE_RECVMSG 1 #define HAVE_RRESVPORT_AF 1 #define HAVE_SENDMSG 1 #define HAVE_SETEGID 1 #define HAVE_SETEUID 1 #define HAVE_SETGROUPS 1 #define HAVE_SETREUID 1 #define HAVE_SETRLIMIT 1 #define HAVE_SETSID 1 #define HAVE_SETVBUF 1 #define HAVE_SIGACTION 1 #define HAVE_SNPRINTF 1 #define HAVE_SOCKETPAIR 1 #define HAVE_STRERROR 1 #define HAVE_STRLCAT 1 #define HAVE_STRLCPY 1 #define HAVE_SYSCONF 1 #define HAVE_TCGETPGRP 1 #define HAVE_TRUNCATE 1 #define HAVE_UTIMES 1 #define HAVE_VHANGUP 1 #define HAVE_VSNPRINTF 1 #define HAVE_WAITPID 1 #define HAVE_DIRNAME 1 #define HAVE_LIBGEN_H 1 #define HAVE_GETTIMEOFDAY 1 #define HAVE_TIME 1 #define HAVE_ENDUTENT 1 #define HAVE_GETUTENT 1 #define HAVE_GETUTID 1 #define HAVE_GETUTLINE 1 #define HAVE_PUTUTLINE 1 #define HAVE_SETUTENT 1 #define HAVE_UTMPNAME 1 #define HAVE_ENDUTXENT 1 #define HAVE_GETUTXENT 1 #define HAVE_GETUTXID 1 #define HAVE_GETUTXLINE 1 #define HAVE_PUTUTXLINE 1 #define HAVE_SETUTXENT 1 #define HAVE_UTMPXNAME 1 #define HAVE_GETPAGESIZE 1 #define GETPGRP_VOID 1 #define HAVE_OPENSSL 1 configure: exit 1 -- David R. Steiner david.r.steiner at dartmouth.edu UNIX System Manager Phone: 603.646.3127 Dartmouth College Fax: 603.646.1041 From apembert at hq.nasa.gov Wed Feb 12 07:04:58 2003 From: apembert at hq.nasa.gov (Anne Pemberton) Date: Tue, 11 Feb 2003 15:04:58 -0500 Subject: Subscribe to list Message-ID: <4.3.2.7.2.20030211145859.02813390@mail.hq.nasa.gov> Remote users on external networks unable to connect to the host using F-Secure SSH from their workstations. The Host is installed with openssh-3.4p1 from IBM. Previously the host was installed with F-Secure 1.2.26 and there wasn't any problems. What can we do. I've checked in the sshd_config file and the AllowHosts and Allow Users tags are in there with the host ips and usernames that I wish to allow to the system. Any ideas. Maybe I should return to version 1.2.33 of the vanilla SSH. Please respond. Thanks. Anne Pemberton NASA HQ. From deengert at anl.gov Wed Feb 12 07:17:18 2003 From: deengert at anl.gov (Douglas E. Engert) Date: Tue, 11 Feb 2003 14:17:18 -0600 Subject: Subscribe to list References: <4.3.2.7.2.20030211145859.02813390@mail.hq.nasa.gov> Message-ID: <3E495A4E.EB97A206@anl.gov> Try using any debug options on f-secure to see what is happing. You can also start sshd using another port, and add the -d options. this will show what the server is seeing. Is f-Secure only using sshv1 and OpenSSH configures to use only sshv2? Look for: Protocol 2,1 in the sshd_config to say use both v1 and v2 Anne Pemberton wrote: > > Remote users on external networks unable to connect to the host using > F-Secure SSH from their workstations. The Host is installed with > openssh-3.4p1 from IBM. > Previously the host was installed with F-Secure 1.2.26 and there wasn't any > problems. > What can we do. > I've checked in the sshd_config file and the AllowHosts and Allow Users > tags are in there with the host ips and usernames that I wish to allow to > the system. > > Any ideas. Maybe I should return to version 1.2.33 of the vanilla SSH. No. > > Please respond. > Thanks. > Anne Pemberton > NASA HQ. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From robopenssh at hagopian.net Wed Feb 12 08:46:23 2003 From: robopenssh at hagopian.net (Rob Hagopian) Date: Tue, 11 Feb 2003 16:46:23 -0500 (EST) Subject: Logging of comments on keys In-Reply-To: Message-ID: If the authorized_keys file is owned by root (a common situation for some shared accounts we use) then users changing comments isn't an problem and logging the comment would be useful? -Rob On Sun, 9 Feb 2003, Ben Lindstrom wrote: > > > On 9 Feb 2003, Axel Dunkel wrote: > > > On 9 Feb 2003 at 21:00, Tim McGarry wrote: > > > > > This may seem convenient, but it's open to abuse as anyone can put any > > > comment they like on the key they use > > > > Right, of course, but that's not a problem? Hm, so maybe you'd > > suggest it would be best to log the filename of the > > authorized_keys[2] file together with the linenumber and the comment > > to get it less missusable? Sounds reasonable. > > > > It is only as useful until someone changes their comments field. BTW, > This has been discussed before and has been turned down number of times. > > - Ben > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From markus at openbsd.org Wed Feb 12 09:04:36 2003 From: markus at openbsd.org (Markus Friedl) Date: Tue, 11 Feb 2003 23:04:36 +0100 Subject: Logging of comments on keys In-Reply-To: References: Message-ID: <20030211220436.GA21852@folly> On Tue, Feb 11, 2003 at 04:46:23PM -0500, Rob Hagopian wrote: > If the authorized_keys file is owned by root (a common situation for some > shared accounts we use) then users changing comments isn't an problem and > logging the comment would be useful? i doubt that we will log comments if a file is owned by root. From bugzilla-daemon at mindrot.org Wed Feb 12 09:07:05 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 12 Feb 2003 09:07:05 +1100 (EST) Subject: [Bug 492] New: Spurious error message from loginrec when attempting to login in with the highest uid for the first time. Message-ID: <20030211220705.DB3E66450B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=492 Summary: Spurious error message from loginrec when attempting to login in with the highest uid for the first time. Product: Portable OpenSSH Version: 3.5p1 Platform: ix86 OS/Version: BSDI Status: NEW Severity: trivial Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: anissen at securecomputing.com In loginrec.c:lastlog_get_entry a lastlog_openseek is executed to open the LASTLOG and seek to the proper offset in the file. When a user logs in for the first time, if someone with a higher uid has not yet logged in, the lseek that is performed will seek beyond the end of the file. When an attempt is made to read the file a EOF is returned. Improper checking of the return value from atomicio causes the following call to be made: log("lastlog_get_entry: Error reading from %s: %s",LASTLOG_FILE, strerror(errno)); This is incorrect as we are getting an EOF and errno will not be set with any value of use. To recreate the problem: 1) Add user to the box with a uid higher then the highest uid that has logged into the box. 2) On the first login to the box with the new user, login through sshd. 3) In /var/log/messages see errors similar to: Feb 11 14:02:37 flamingo sshd[22098]: lastlog_get_entry: Error reading from /var/log/lastlog: Device not configured Feb 11 14:08:14 flamingo sshd[22379]: lastlog_get_entry: Error reading from /var/log/lastlog: Device not configured I suggest the following change or similar be made to loginrec.c anissen @ kings > diff -c ../openssh-3.5p1/loginrec.c loginrec.c *** ../openssh-3.5p1/loginrec.c Wed Sep 25 19:38:49 2002 --- loginrec.c Tue Feb 11 15:00:46 2003 *************** *** 1431,1437 **** --- 1431,1448 ---- /* find this uid's offset in the lastlog file */ offset = (off_t) ((long)li->uid * sizeof(struct lastlog)); + /* + * When opening lastlog for reading, seeking beyond the end of + * the file makes no sense. Just tell the caller (currently only + * lastlog_get_entry) that we could no perform the requested action. + */ + if ( filemode == O_RDONLY && (lseek(*fd, 0, SEEK_END) >= offset)){ + close(*fd); + return 0; + } + if ( lseek(*fd, offset, SEEK_SET) != offset ) { + close(*fd); log("lastlog_openseek: %s->lseek(): %s", lastlog_file, strerror(errno)); return 0; Note that another fix could be to check the return value from atomicio and not print out the error message if the value returned indicates EOF. This fix has been compiled and tested on a BSDI box. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From d_wllms at lanl.gov Wed Feb 12 11:17:00 2003 From: d_wllms at lanl.gov (David M. Williams) Date: Tue, 11 Feb 2003 17:17:00 -0700 Subject: Subscribe to list In-Reply-To: <4.3.2.7.2.20030211145859.02813390@mail.hq.nasa.gov> References: <4.3.2.7.2.20030211145859.02813390@mail.hq.nasa.gov> Message-ID: <3E49927C.3070006@lanl.gov> Anne, Is this a Kerberized environment?? If so then you _must_ use protocol 1 for the negotiation, as Doug suggested. Dave Anne Pemberton wrote: > Remote users on external networks unable to connect to the host using > F-Secure SSH from their workstations. The Host is installed with > openssh-3.4p1 from IBM. > Previously the host was installed with F-Secure 1.2.26 and there > wasn't any problems. > What can we do. > I've checked in the sshd_config file and the AllowHosts and Allow > Users tags are in there with the host ips and usernames that I wish to > allow to the system. > > Any ideas. Maybe I should return to version 1.2.33 of the vanilla SSH. > > Please respond. > Thanks. > Anne Pemberton > NASA HQ. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- David M. Williams, CISSP Phone: 505-665-8062 Systems Engineer, CCN-2 Fax: 505-667-7428 Los Alamos National Laboratory Email: d_wllms at lanl.gov From dtucker at zip.com.au Wed Feb 12 11:40:18 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 12 Feb 2003 11:40:18 +1100 Subject: Putty won't work when priv-sep turned on on AIX systems References: <1043075787.1213.21.camel@ninja> <20030120155423.GA14186@folly> <1044871639.986.24.camel@ninja> <3E478F26.93DEB65B@zip.com.au> <1044881157.987.31.camel@ninja> <3E47B0F2.C4144356@zip.com.au> <1044887590.986.45.camel@ninja> <3E483ABA.1A8A59C@zip.com.au> <3E48338B.5010505@mindrot.org> <1044974067.12080.4.camel@ninja> Message-ID: <3E4997F2.5C5A6943@zip.com.au> Mark Janssen wrote: > What OpenSSL version are you using... I used a custom compiled version > of 0.9.6g, which I have now replaced by the bullfreeware.com version of > 0.9.6.7. Re-compiling my openssh with this SSL library results in the > same error. I'm using "OpenSSL 0.9.6g 9 Aug 2002", compiled locally with gcc 3.2. In the past I've had crypto errors from openssl compiled with the gcc (2.9.?) supplied with AIX 5.1 (DSA didn't work). Did openssl pass "make test"? > SSH is compiled with the following options: (from ./configure...) [snip options] The only differences I could see were tcpwrappers and egd. > Could you send me your copy of libcrypto.a and libssl.a... I could test > a compile with those... On the way. -- Darren Tucker (dtucker at zip.com.au) GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From bugzilla-daemon at mindrot.org Wed Feb 12 11:58:44 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 12 Feb 2003 11:58:44 +1100 (EST) Subject: [Bug 492] Spurious error message from loginrec when attempting to login in with the highest uid for the first time. Message-ID: <20030212005844.A17F26450C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=492 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From djm at mindrot.org 2003-02-12 11:58 ------- Please check existing/closed bugs before submitting new ones. *** This bug has been marked as a duplicate of 110 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 12 11:58:46 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 12 Feb 2003 11:58:46 +1100 (EST) Subject: [Bug 110] bogus error messages in lastlog_get_entry() Message-ID: <20030212005846.56CF864515@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=110 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |anissen at securecomputing.com ------- Additional Comments From djm at mindrot.org 2003-02-12 11:58 ------- *** Bug 492 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Wed Feb 12 18:53:41 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 12 Feb 2003 18:53:41 +1100 Subject: Problems configuring OpenSSH 3.5p1 on Sol 5.8 References: Message-ID: <3E49FD84.FC8F2F4D@zip.com.au> David Steiner wrote: > I am having a problem getting OpenSSH to configure on a Solaris 5.8 box. > > I have installed gcc 3.2.2, OpenSSL 0.9.6g. Does openssl pass "make test"? > The config script dies with the error: > > OpenSSL version header not found. > > OpenSSL is installed in /usr/local/ssl. A check of the config.log > file indicates that the test program appears to be core dumping. I > have included relavent (I hope) portions of config.log below. > > Any pointers as to why this might be happening would be greatly appreciated. You can compile the test yourself (ie cut-and-paste it from the log and compile it with the options from the log), then run it under a debugger to find out why it's crashing. -- 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 bugzilla-daemon at mindrot.org Wed Feb 12 20:56:49 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 12 Feb 2003 20:56:49 +1100 (EST) Subject: [Bug 493] New: PATCH: session.c: Allow multiple accounts on Windows 9x/Me Message-ID: <20030212095649.22A4264517@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=493 Summary: PATCH: session.c: Allow multiple accounts on Windows 9x/Me Product: Portable OpenSSH Version: -current Platform: ix86 URL: http://cygbert.franken.de/session.patch OS/Version: Cygwin on 9X/ME Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: vinschen at redhat.com The following patch by Pierre A. Humblet allows to use more than one uid on 9x/Me boxes. The necessary Cygwin code to activate that capability is already in the current version of Cygwin (1.3.20). You can find the patch as http://cygbert.franken.de/session.patch Thanks, Corinna ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 12 21:00:09 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 12 Feb 2003 21:00:09 +1100 (EST) Subject: [Bug 494] New: PATCH: session.c: Allow multiple accounts on Windows 9x/Me Message-ID: <20030212100009.70DDB6451D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=494 Summary: PATCH: session.c: Allow multiple accounts on Windows 9x/Me Product: Portable OpenSSH Version: -current Platform: ix86 URL: http://cygbert.franken.de/session.patch OS/Version: Cygwin on 9X/ME Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: vinschen at redhat.com The following patch by Pierre A. Humblet allows to use more than one uid on 9x/Me boxes. The necessary Cygwin code to activate that capability is already in the current version of Cygwin (1.3.20). You can find the patch as http://cygbert.franken.de/session.patch Thanks, Corinna ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 12 21:03:36 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 12 Feb 2003 21:03:36 +1100 (EST) Subject: [Bug 494] PATCH: session.c: Allow multiple accounts on Windows 9x/Me Message-ID: <20030212100336.BA4AF64524@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=494 ------- Additional Comments From vinschen at redhat.com 2003-02-12 21:03 ------- Created an attachment (id=227) --> (http://bugzilla.mindrot.org/attachment.cgi?id=227&action=view) Hmm, attaching the patch is simpler, isn't it? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 12 21:04:11 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 12 Feb 2003 21:04:11 +1100 (EST) Subject: [Bug 494] PATCH: session.c: Allow multiple accounts on Windows 9x/Me Message-ID: <20030212100411.3B81864549@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=494 ------- Additional Comments From vinschen at redhat.com 2003-02-12 21:04 ------- Created an attachment (id=228) --> (http://bugzilla.mindrot.org/attachment.cgi?id=228&action=view) Hmm, attaching the patch is simpler, isn't it? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 12 21:36:15 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 12 Feb 2003 21:36:15 +1100 (EST) Subject: [Bug 493] PATCH: session.c: Allow multiple accounts on Windows 9x/Me Message-ID: <20030212103615.342976454F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=493 vinschen at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From vinschen at redhat.com 2003-02-12 21:36 ------- Sorry, I have no idea why this has been duplicated under another bug id while creating that entry :-( *** This bug has been marked as a duplicate of 494 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 12 21:36:16 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 12 Feb 2003 21:36:16 +1100 (EST) Subject: [Bug 494] PATCH: session.c: Allow multiple accounts on Windows 9x/Me Message-ID: <20030212103616.E887C64551@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=494 ------- Additional Comments From vinschen at redhat.com 2003-02-12 21:36 ------- *** Bug 493 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From ajith at noida.hcltech.com Wed Feb 12 21:41:13 2003 From: ajith at noida.hcltech.com (Ajit Yashwant Vaishampayan, Noida) Date: Wed, 12 Feb 2003 16:11:13 +0530 Subject: No struct cmsghdr - what to do ? Message-ID: Did anybody have any solution for this problem ? - Ajit -----Original Message----- From: Ajit Yashwant Vaishampayan, Noida Sent: Thursday, February 06, 2003 3:15 PM To: OpenSSH Development Subject: No struct cmsghdr - what to do ? Hi all, If any perticular OS does not have 'struct cmsghdr' in sys/socket.h and also it does not have access rights in 'struct msghdr', then how the compilation should be done ? Does anybody had similar problem earlier ? Regards, Ajit _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From bugzilla-daemon at mindrot.org Wed Feb 12 22:59:31 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 12 Feb 2003 22:59:31 +1100 (EST) Subject: [Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport Message-ID: <20030212115931.6C41464526@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=413 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #217 is|0 |1 obsolete| | Attachment #219 is|0 |1 obsolete| | ------- Additional Comments From dtucker at zip.com.au 2003-02-12 22:59 ------- Created an attachment (id=229) --> (http://bugzilla.mindrot.org/attachment.cgi?id=229&action=view) Implement optional address binding for port forwards (update 2) * merge bug fixes from Rumen (RemoteForward and LocalForward options). * replace strncat with snprintf as per Markus. Note: used a static buffer. * allow client to override GatewayPorts with a "*" listen address, also from Markus. Changing the arguments to add_local_forward() and add_remote_forward() will mean more code to populate the structs, I don't think it's worth it. Markus, could you please elaborate on "i don't think the patch to ssh.c is correct"? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From d_wllms at lanl.gov Thu Feb 13 00:31:58 2003 From: d_wllms at lanl.gov (David M. Williams) Date: Wed, 12 Feb 2003 06:31:58 -0700 Subject: No struct cmsghdr - what to do ? In-Reply-To: References: Message-ID: <3E4A4CCE.5050002@lanl.gov> Which OS are we talking about? If this is a new OS port of OpenSSH then you are going to have to do a couple of things: 1. patch configure.ac to recognize the OS and to pick up compatability code in openssh/openbsd-compat/. 2. write code to provide cmsghdr support for your OS. The files go in openbsd-compat/ and follow the naming convention bsd-.(c/h). If you want some descriptions of how this works search the archives for either Corinna Vinschen's or Wendy Palm's postings over the last 6 months or so. They both support unique OS's and have followed this model. Good Luck, Dave Ajit Yashwant Vaishampayan, Noida wrote: >Did anybody have any solution for this problem ? > >- Ajit > >-----Original Message----- >From: Ajit Yashwant Vaishampayan, Noida >Sent: Thursday, February 06, 2003 3:15 PM >To: OpenSSH Development >Subject: No struct cmsghdr - what to do ? > > >Hi all, > >If any perticular OS does not have 'struct cmsghdr' in sys/socket.h and also >it does not have access rights in 'struct msghdr', then how the compilation >should be done ? Does anybody had similar problem earlier ? > >Regards, >Ajit > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > -- David M. Williams, CISSP Phone: 505-665-8062 Systems Engineer, CCN-2 Fax: 505-667-7428 Los Alamos National Laboratory Email: d_wllms at lanl.gov From mstone at mathom.us Thu Feb 13 02:23:03 2003 From: mstone at mathom.us (Michael Stone) Date: Wed, 12 Feb 2003 10:23:03 -0500 Subject: New PAM kbd-int code In-Reply-To: <3E2F8925.2040600@mindrot.org> References: <3E2F8925.2040600@mindrot.org> Message-ID: <20030212152303.GH8235@osgiliath.ddts.net> On Thu, Jan 23, 2003 at 05:18:13PM +1100, Damien Miller wrote: >Please test this now kbd-interactive pam worked with privsep (first time in a while I've been able to use open pam module with ssh.) Unfortunately the session died before I could actually do something; it looks like it fails for any pam session module that tries to produce output? Mike Stone From jdennis at law.harvard.edu Thu Feb 13 07:05:20 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Wed, 12 Feb 2003 15:05:20 -0500 Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) Message-ID: <3E4AA900.6070400@law.harvard.edu> Hey everyone, After discussing the AllowGroups I think I've discovered a bug. The system is a solaris 8 system and the problem is that when I use AllowGroups with no AllowUsers args, the proper actions happen. Same with AllowUsers and no AllowGroups. When I try to combine the two, none of the Allow directives seem to take. Is it just me or maybe a bug? -James From pmilanese at nypl.org Thu Feb 13 07:29:41 2003 From: pmilanese at nypl.org (Peter J. Milanese) Date: Wed, 12 Feb 2003 12:29:41 -0800 Subject: Issues regarding multiple NAT'd ssh servers Message-ID: Greetings- I recall mention of this bug at some tim elast year, but do not know if anything yet has been done to address it or if it is in any plans... I have multiple servers behind a f/w. I have ports forwarded on the f/w which map to port 22 on the various servers. i.e. ssh -p1001 FIREWALL_IP ---> NON_ROUTEABLE:22 This is fine, but the hostkey negotiation obviously fails... Is there any sensible way to fix this, and will known_hosts include a port identity at some point in time? Any input would be greatly appreciated- P From jmknoble at pobox.com Thu Feb 13 08:12:32 2003 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 12 Feb 2003 16:12:32 -0500 Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: <3E4AA900.6070400@law.harvard.edu> References: <3E4AA900.6070400@law.harvard.edu> Message-ID: <20030212211232.GA9875@crawfish.ais.com> Circa 2003-02-12 15:05:20 -0500 dixit James Dennis: : Hey everyone, : : After discussing the AllowGroups I think I've discovered a bug. : : The system is a solaris 8 system and the problem is that when I use : AllowGroups with no AllowUsers args, the proper actions happen. Same : with AllowUsers and no AllowGroups. When I try to combine the two, none : of the Allow directives seem to take. : : Is it just me or maybe a bug? Maybe a little of both. Testing under OpenBSD-3.2: $ ssh -V OpenSSH_3.5, SSH protocols 1.5/2.0, OpenSSL 0x00907003 with the following users: # useradd -m -G users blah # useradd -m -G users haha # egrep '(blah|haha)' /etc/passwd /etc/group /etc/passwd:blah:*:1021:1021::/home/blah:/bin/ksh /etc/passwd:haha:*:1022:1022::/home/haha:/bin/ksh /etc/group:users:*:10:,blah,haha /etc/group:blah:*:1019:blah /etc/group:haha:*:1020:haha # gives the following results: Users successfully log in: Condition blah haha root no Allow* => yes yes yes AllowUsers blah => yes no no AllowUsers haha => no yes no AllowUsers root => no no yes AllowGroups users => yes yes no AllowGroups users, AllowUsers root => no no no The last one is what's surprising. Here's what the sshd log has to say (at LogLevel VERBOSE, with timestamps removed to conserve space): ---------------- Received SIGHUP; restarting. Server listening on :: port 22. Server listening on 0.0.0.0 port 22. Connection from 127.0.0.1 port 32492 User blah not allowed because not listed in AllowUsers input_userauth_request: illegal user blah Failed none for illegal user blah from 127.0.0.1 port 32492 ssh2 Failed publickey for illegal user blah from 127.0.0.1 port 32492 ssh2 [...] Failed password for illegal user blah from 127.0.0.1 port 32492 ssh2 [...] Disconnecting: Too many authentication failures for blah Connection from 127.0.0.1 port 40621 User haha not allowed because not listed in AllowUsers input_userauth_request: illegal user haha Failed none for illegal user haha from 127.0.0.1 port 40621 ssh2 Failed publickey for illegal user haha from 127.0.0.1 port 40621 ssh2 [...] Failed password for illegal user haha from 127.0.0.1 port 40621 ssh2 [...] Disconnecting: Too many authentication failures for haha Connection from 127.0.0.1 port 35381 User root not allowed because none of user's groups are listed in AllowGroups input_userauth_request: illegal user root Failed none for illegal user root from 127.0.0.1 port 35381 ssh2 Failed publickey for illegal user root from 127.0.0.1 port 35381 ssh2 [...] Failed password for illegal user root from 127.0.0.1 port 35381 ssh2 [...] Disconnecting: Too many authentication failures for root ---------------- Seems as if sshd requires that a user be in: AllowUsers AllowGroups instead of: AllowUsers AllowGroups in order not to be an "illegal user". That's certainly not what i expected. If i need to deny certain group members, i would expect to do the following: DenyUsers blah AllowGroups users [implicit DenyUsers *] or: DenyGroups wheel AllowGroups users [implicit DenyUsers *] I would also expect that: AllowUsers root AllowGroups users [implicit DenyUsers *] would allow all three of blah, haha, and root. That is, i expect a first-match allow/deny, in the order listed in the file, and that there is exactly one implicit 'DenyUsers *' (if any Allow* directives appear) or 'AllowUsers *' (if any Deny* directives appear, and no Allow* directives appear), which appears at the very bottom of the list. That is: DenyGroups users DenyUsers root [implicit AllowUsers *] or: DenyUsers root AllowGroups wheel staff [implicit DenyUsers *] Alternatively, if sshd were to do a last-match instead of a first-match, then the implicit 'AllowUsers *' or 'DenyUsers *' rule would go at the top, and the order would be reversed, e.g.: [implicit DenyUsers *] AllowGroups wheel staff DenyUsers root Either way would work better than the current surprising behavior (although i prefer first-match ACLs rather than last-match ones). Anyone else care to comment? -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) "I am non-refutable." --Enik the Altrusian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 256 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030212/9ab529ce/attachment.bin From krhovi at cc.hut.fi Thu Feb 13 11:36:27 2003 From: krhovi at cc.hut.fi (Kimmo Hovi) Date: Thu, 13 Feb 2003 02:36:27 +0200 (EET) Subject: openssh remote add user exploits? Message-ID: Hello. Recently I discovered some kind of exploit of openssh used against me. For configuration info, I am using Mandrake 8.2 with the openssh package openssh-3.1p1-1mdk. Fortunately, I was at least somewhat security-aware, and have an AllowUsers parameter in my sshd config file. I Used to allow only public key logins, but ditched that when I found myself needing access from multiple places. I was behind my provider's firewall until recently, when I decided to allow connections from the net (To host my own web site), so this might be an old one (And I'd guess, since I first opened up the firewall on Feb 4 2003. Anyway, The services I have (that is, had) running, are httpd (httpd and httpd-perl in mandrake), sshd, and xdm. (All default mandrake, no source builds). The following is a log snippet. What's going on?: ps, I am _NOT_ reading this list, so please cc: all replies to me. Thanks Feb 5 09:29:09 narnia adduser[15054]: new user: name=telnet, uid=0, gid=0, home=/usr/doc/, shell=/bin/bash Feb 5 09:29:48 narnia PAM_pwdb[15055]: new password not acceptable Feb 5 09:30:06 narnia sshd[15046]: Could not reverse map address 194.105.21.48. Feb 5 09:30:06 narnia sshd[15046]: User telnet not allowed because not listed in AllowUsers Feb 5 09:30:06 narnia sshd[15046]: input_userauth_request: illegal user telnet Feb 5 09:30:06 narnia sshd[15046]: Failed none for illegal user telnet from 194.105.21.48 port 1073 ssh2 Feb 5 09:30:07 narnia sshd[15046]: Failed keyboard-interactive for illegal user telnet from 194.105.21.48 port 1073 ssh 2 Feb 5 09:30:12 narnia sshd[15046]: Failed password for illegal user telnet from 194.105.21.48 port 1073 ssh2 Feb 5 09:30:13 narnia sshd[15046]: Failed none for illegal user telnet from 194.105.21.48 port 1073 ssh2 Feb 5 09:30:14 narnia sshd[15046]: Failed keyboard-interactive for illegal user telnet from 194.105.21.48 port 1073 ssh 2 Feb 5 09:30:19 narnia sshd[15046]: Connection closed by 194.105.21.48 Feb 5 09:32:19 narnia PAM_pwdb[15069]: password for (telnet/0) changed by ((null)/0) Feb 5 09:32:43 narnia adduser[15070]: new user: name=bash, uid=0, gid=0, home=/usr/doc/, shell=/bin/bash Feb 5 09:33:16 narnia PAM_pwdb[15071]: password for (bash/0) changed by ((null)/0) Feb 5 09:33:46 narnia sshd[15073]: User bash not allowed because not listed in AllowUsers Feb 5 09:33:46 narnia sshd[15073]: input_userauth_request: illegal user bash Feb 5 09:33:46 narnia sshd[15073]: Failed none for illegal user bash from 127.0.0.1 port 33853 ssh2 Feb 5 09:33:46 narnia sshd[15073]: Failed keyboard-interactive for illegal user bash from 127.0.0.1 port 33853 ssh2 Feb 5 09:35:55 narnia sshd[15073]: Failed password for illegal user bash from 127.0.0.1 port 33853 ssh2 Feb 5 09:36:24 narnia sshd[15073]: Failed password for illegal user bash from 127.0.0.1 port 33853 ssh2 From fcusack at fcusack.com Thu Feb 13 13:48:40 2003 From: fcusack at fcusack.com (Frank Cusack) Date: Wed, 12 Feb 2003 18:48:40 -0800 Subject: openssh remote add user exploits? In-Reply-To: ; from krhovi@cc.hut.fi on Thu, Feb 13, 2003 at 02:36:27AM +0200 References: Message-ID: <20030212184840.E9386@google.com> On Thu, Feb 13, 2003 at 02:36:27AM +0200, Kimmo Hovi wrote: > Hello. Recently I discovered some kind of exploit of openssh used against > me. For configuration info, I am using Mandrake 8.2 with the openssh > package openssh-3.1p1-1mdk. > Feb 5 09:29:09 narnia adduser[15054]: new user: name=telnet, uid=0, > gid=0, home=/usr/doc/, shell=/bin/bash > Feb 5 09:29:48 narnia PAM_pwdb[15055]: new password not acceptable > Feb 5 09:30:06 narnia sshd[15046]: Could not reverse map address > 194.105.21.48. > Feb 5 09:30:06 narnia sshd[15046]: User telnet not allowed because not > listed in AllowUsers I don't see how this is at all related to openssh having some kind of exploit. Someone locally added a user named 'telnet' and then tried to ssh as that user. Your machine is already compromised, it seems, in a way that only allows creation of new users, maybe? /fc From bob at proulx.com Thu Feb 13 16:06:51 2003 From: bob at proulx.com (Bob Proulx) Date: Wed, 12 Feb 2003 22:06:51 -0700 Subject: openssh remote add user exploits? In-Reply-To: <20030212184840.E9386@google.com> References: <20030212184840.E9386@google.com> Message-ID: <20030213050651.GB3806@misery.proulx.com> Frank Cusack wrote: > > Kimmo Hovi wrote: > > > > Hello. Recently I discovered some kind of exploit of openssh used against > > me. I saw no data in the syslog that indicated that ssh was involved in the _initial_ exploit. It only appeared after the crack appeared. In the timeline it appeared as if someone cracked first and then tried to use the tools on the system such as ssh later. > > Feb 5 09:29:09 narnia adduser[15054]: new user: name=telnet, uid=0, > > gid=0, home=/usr/doc/, shell=/bin/bash Was this the first indication of a compromise on the system? The logging of an adduser command? If so this indicates that your system was cracked at least at this point in time by *some* method. But without more information it is impossible to say where and how the crack was accomplished. Your logs showed activity over a seven minute time window. Which indicates to me a person interacting and not the speed of a program. Although it could be a program faking being interactive. > I don't see how this is at all related to openssh having some kind of > exploit. Someone locally added a user named 'telnet' and then tried > to ssh as that user. Agreed. > Your machine is already compromised, it seems, in a way that only allows > creation of new users, maybe? That would be bizarre, but possible if some network accessable sysadmin tool that managed user accounts were compromised. The normal advise is to take the disk offline and to examine the remains of the attack without actually running any of the programs from that disk. You can't trust them. Examine the files and programs as data. Because of the trail left in syslog this does not appear to be a sophisticated attack or you would never have been able to notice it. But as the advice goes, better safe than sorry. Meanwhile, back to the ranch where most people don't have the resources to completely analyze the remains of dead aliens. This might be you, I don't know. But if your machine has been cracked then you can't trust anything on it now. You are eventually going to have to recreate your system from clean sources, such as a new distribution installation. So you might as well poke the corpse a bit. Try to determine any other signature that might be able to identify the hole. Otherwise having learned nothing if you install the same system you had before on the disk again you will be vulnerable to the same attack again. You said you were running Mandrake and by all reports to me that is a fine distribution. If you were current on security patches you should have been as safe as it was possible to be. > I was behind my provider's firewall until recently, when I decided to > allow connections from the net (To host my own web site), so this > might be an old one (And I'd guess, since I first opened up the > firewall on Feb 4 2003. When you opened up the firewall did you open up only specific ports? Or did you route all traffic to your host? I am hoping just specific ports such as SSH and HTTP. That limits the exposure. But if all ports were opened then the possibilities are many. Bob From maniac at maniac.nl Thu Feb 13 22:19:18 2003 From: maniac at maniac.nl (Mark Janssen) Date: 13 Feb 2003 12:19:18 +0100 Subject: [SOLVED] Re: Putty won't work when priv-sep turned on on AIX systems In-Reply-To: <3E4997F2.5C5A6943@zip.com.au> References: <1043075787.1213.21.camel@ninja> <20030120155423.GA14186@folly> <1044871639.986.24.camel@ninja> <3E478F26.93DEB65B@zip.com.au> <1044881157.987.31.camel@ninja> <3E47B0F2.C4144356@zip.com.au> <1044887590.986.45.camel@ninja> <3E483ABA.1A8A59C@zip.com.au> <3E48338B.5010505@mindrot.org> <1044974067.12080.4.camel@ninja> <3E4997F2.5C5A6943@zip.com.au> Message-ID: <1045135158.1195.5.camel@ninja> On Wed, 2003-02-12 at 01:40, Darren Tucker wrote: > Mark Janssen wrote: [problems with putty connecting to openssh on aix] After a suggestion from Andrew Duggan this morning about possible problems regarding old/broken versions of libz. I knew I wasn't using the latest libz, so I looked into putty's settings and noticed that Compression was indeed turned on. When this was turned off it magically worked again. I'll see if I can get a newer libz and turn compression back on, but for now, my problems are solved. Thanks for the suggestions/hints -- Mark Janssen -- maniac(at)maniac.nl -- GnuPG Key Id: 357D2178 Unix / Linux, Open-Source and Internet Consultant @ SyConOS IT Maniac.nl Unix-God.Net|Org MarkJanssen.org|nl SyConOS.com|nl From jdennis at law.harvard.edu Fri Feb 14 01:44:32 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Thu, 13 Feb 2003 09:44:32 -0500 Subject: openssh remote add user exploits? In-Reply-To: References: Message-ID: <3E4BAF50.9030400@law.harvard.edu> Um.. your using openssh 3.1. That's been known to be vulnerable and has known exploits. You've been cracked buddy... -James Kimmo Hovi wrote: > Hello. Recently I discovered some kind of exploit of openssh used against > me. For configuration info, I am using Mandrake 8.2 with the openssh > package openssh-3.1p1-1mdk. > > Fortunately, I was at least somewhat security-aware, and have an > AllowUsers parameter in my sshd config file. I Used to allow only public > key logins, but ditched that when I found myself needing access from > multiple places. I was behind my provider's firewall until recently, when > I decided to allow connections from the net (To host my own web site), so > this might be an old one (And I'd guess, since I first opened up the > firewall on Feb 4 2003. > > Anyway, The services I have (that is, had) running, are httpd (httpd and > httpd-perl in mandrake), sshd, and xdm. (All default mandrake, no source > builds). The following is a log snippet. What's going on?: > > ps, I am _NOT_ reading this list, so please cc: all replies to me. Thanks > > Feb 5 09:29:09 narnia adduser[15054]: new user: name=telnet, uid=0, > gid=0, home=/usr/doc/, shell=/bin/bash > Feb 5 09:29:48 narnia PAM_pwdb[15055]: new password not acceptable > Feb 5 09:30:06 narnia sshd[15046]: Could not reverse map address > 194.105.21.48. > Feb 5 09:30:06 narnia sshd[15046]: User telnet not allowed because not > listed in AllowUsers > Feb 5 09:30:06 narnia sshd[15046]: input_userauth_request: illegal user > telnet > Feb 5 09:30:06 narnia sshd[15046]: Failed none for illegal user telnet > from 194.105.21.48 port 1073 ssh2 > Feb 5 09:30:07 narnia sshd[15046]: Failed keyboard-interactive for > illegal user telnet from 194.105.21.48 port 1073 ssh > 2 > Feb 5 09:30:12 narnia sshd[15046]: Failed password for illegal user > telnet from 194.105.21.48 port 1073 ssh2 > Feb 5 09:30:13 narnia sshd[15046]: Failed none for illegal user telnet > from 194.105.21.48 port 1073 ssh2 > Feb 5 09:30:14 narnia sshd[15046]: Failed keyboard-interactive for > illegal user telnet from 194.105.21.48 port 1073 ssh > 2 > Feb 5 09:30:19 narnia sshd[15046]: Connection closed by 194.105.21.48 > Feb 5 09:32:19 narnia PAM_pwdb[15069]: password for (telnet/0) changed by > ((null)/0) > Feb 5 09:32:43 narnia adduser[15070]: new user: name=bash, uid=0, gid=0, > home=/usr/doc/, shell=/bin/bash > Feb 5 09:33:16 narnia PAM_pwdb[15071]: password for (bash/0) changed by > ((null)/0) > Feb 5 09:33:46 narnia sshd[15073]: User bash not allowed because not > listed in AllowUsers > Feb 5 09:33:46 narnia sshd[15073]: input_userauth_request: illegal user > bash > Feb 5 09:33:46 narnia sshd[15073]: Failed none for illegal user bash from > 127.0.0.1 port 33853 ssh2 > Feb 5 09:33:46 narnia sshd[15073]: Failed keyboard-interactive for > illegal user bash from 127.0.0.1 port 33853 ssh2 > Feb 5 09:35:55 narnia sshd[15073]: Failed password for illegal user bash > from 127.0.0.1 port 33853 ssh2 > Feb 5 09:36:24 narnia sshd[15073]: Failed password for illegal user bash > from 127.0.0.1 port 33853 ssh2 > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- James Dennis Harvard Law School "Not everything that counts can be counted, and not everything that can be counted counts." From robopenssh at hagopian.net Fri Feb 14 03:06:49 2003 From: robopenssh at hagopian.net (Rob Hagopian) Date: Thu, 13 Feb 2003 11:06:49 -0500 (EST) Subject: Logging of comments on keys In-Reply-To: <20030211220436.GA21852@folly> Message-ID: Well, the original argument against logging the comment was that a user could go in and change their comment, my point was that this is not always the case (and it doesn't have the be owned by root, it could be owned by nobody or some other user). Since a user could just go in and change their key anyway if the authorized_keys file isn't chowned away, I don't see how logging the comment is that much different from logging the key fingerprint anyway? -Rob On Tue, 11 Feb 2003, Markus Friedl wrote: > On Tue, Feb 11, 2003 at 04:46:23PM -0500, Rob Hagopian wrote: > > If the authorized_keys file is owned by root (a common situation for some > > shared accounts we use) then users changing comments isn't an problem and > > logging the comment would be useful? > > i doubt that we will log comments if a file is owned by root. > From fcusack at fcusack.com Fri Feb 14 10:30:16 2003 From: fcusack at fcusack.com (Frank Cusack) Date: Thu, 13 Feb 2003 15:30:16 -0800 Subject: [SOLVED] Re: Putty won't work when priv-sep turned on on AIX systems In-Reply-To: <1045135158.1195.5.camel@ninja>; from maniac@maniac.nl on Thu, Feb 13, 2003 at 12:19:18PM +0100 References: <1044871639.986.24.camel@ninja> <3E478F26.93DEB65B@zip.com.au> <1044881157.987.31.camel@ninja> <3E47B0F2.C4144356@zip.com.au> <1044887590.986.45.camel@ninja> <3E483ABA.1A8A59C@zip.com.au> <3E48338B.5010505@mindrot.org> <1044974067.12080.4.camel@ninja> <3E4997F2.5C5A6943@zip.com.au> <1045135158.1195.5.camel@ninja> Message-ID: <20030213153016.B20660@google.com> On Thu, Feb 13, 2003 at 12:19:18PM +0100, Mark Janssen wrote: > On Wed, 2003-02-12 at 01:40, Darren Tucker wrote: > > Mark Janssen wrote: > [problems with putty connecting to openssh on aix] > > After a suggestion from Andrew Duggan this morning about possible > problems regarding old/broken versions of libz. I knew I wasn't using > the latest libz, so I looked into putty's settings and noticed that > Compression was indeed turned on. When this was turned off it magically > worked again. > > I'll see if I can get a newer libz and turn compression back on, but for > now, my problems are solved. Thanks for the suggestions/hints Weren't there known problems with privsep and compression? I don't recall seeing any resolution, nor any commentary that it was related to version of libz. But, I certainly did not follow that closely. /fc From tim at multitalents.net Fri Feb 14 13:26:07 2003 From: tim at multitalents.net (Tim Rice) Date: Thu, 13 Feb 2003 18:26:07 -0800 (PST) Subject: [SOLVED] Re: Putty won't work when priv-sep turned on on AIX systems In-Reply-To: <20030213153016.B20660@google.com> References: <1044871639.986.24.camel@ninja> <3E478F26.93DEB65B@zip.com.au> <1044881157.987.31.camel@ninja> <3E47B0F2.C4144356@zip.com.au> <1044887590.986.45.camel@ninja> <3E483ABA.1A8A59C@zip.com.au> <3E48338B.5010505@mindrot.org> <1044974067.12080.4.camel@ninja> <3E4997F2.5C5A6943@zip.com.au> <1045135158.1195.5.camel@ninja> <20030213153016.B20660@google.com> Message-ID: On Thu, 13 Feb 2003, Frank Cusack wrote: > On Thu, Feb 13, 2003 at 12:19:18PM +0100, Mark Janssen wrote: > > On Wed, 2003-02-12 at 01:40, Darren Tucker wrote: > > > Mark Janssen wrote: > > [problems with putty connecting to openssh on aix] > > > > After a suggestion from Andrew Duggan this morning about possible > > problems regarding old/broken versions of libz. I knew I wasn't using > > the latest libz, so I looked into putty's settings and noticed that > > Compression was indeed turned on. When this was turned off it magically > > worked again. > > > > I'll see if I can get a newer libz and turn compression back on, but for > > now, my problems are solved. Thanks for the suggestions/hints > > Weren't there known problems with privsep and compression? I don't recall > seeing any resolution, nor any commentary that it was related to version > of libz. But, I certainly did not follow that closely. > > /fc There was only a problem if the system had a broken (or didn't have) mmap. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From djm at mindrot.org Fri Feb 14 13:27:44 2003 From: djm at mindrot.org (Damien Miller) Date: Fri, 14 Feb 2003 13:27:44 +1100 Subject: [SOLVED] Re: Putty won't work when priv-sep turned on on AIX systems In-Reply-To: <20030213153016.B20660@google.com> References: <1044871639.986.24.camel@ninja> <3E478F26.93DEB65B@zip.com.au> <1044881157.987.31.camel@ninja> <3E47B0F2.C4144356@zip.com.au> <1044887590.986.45.camel@ninja> <3E483ABA.1A8A59C@zip.com.au> <3E48338B.5010505@mindrot.org> <1044974067.12080.4.camel@ninja> <3E4997F2.5C5A6943@zip.com.au> <1045135158.1195.5.camel@ninja> <20030213153016.B20660@google.com> Message-ID: <3E4C5420.5090002@mindrot.org> Frank Cusack wrote: > Weren't there known problems with privsep and compression? I don't recall > seeing any resolution, nor any commentary that it was related to version > of libz. But, I certainly did not follow that closely. We would disable compression if the OS lacked certain capabilities which privsep needed to support it - there were no reliability issues IIRC. -d From dtucker at zip.com.au Fri Feb 14 16:36:23 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 14 Feb 2003 16:36:23 +1100 Subject: Current CVS broken on AIX: conflicting types for =?iso-8859-1?Q?=60gai=5Fstrerror=B4?= Message-ID: <3E4C8057.FA4AEB6C@zip.com.au> Hi All, After finding out my AIX boxes haven't been updating their tinderbox[0] test trees (grr) and fixing that, I found that recent changes caused build errors on AIX 4.3.3 & 5.1. 4.2.1 appears OK. The error is: gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I../../openbsd-compat -I../../openbsd-compat/.. -I/usr/local/ssl/include -I/usr/local/include -DHAVE_CONFIG_H -c ../../openbsd-compat/bsd-arc4random.c In file included from ../../openbsd-compat/openbsd-compat.h:39, from ../../includes.h:169, from ../../openbsd-compat/bsd-arc4random.c:25: ../../openbsd-compat/fake-getaddrinfo.h:40: conflicting types for `gai_strerror? /usr/include/netdb.h:377: previous declaration of `gai_strerror? The fragment from fake-addrinfo.h is: #ifndef HAVE_GAI_STRERROR const char *gai_strerror(int ecode); #endif /* !HAVE_GAI_STRERROR */ Now on AIX (4.3.3 & 5.1, anyway), config.h defines HAVE_GAI_STRERROR, however defines.h turns around an undefs it: #if defined(BROKEN_GETADDRINFO) && defined(HAVE_GAI_STRERROR) # undef HAVE_GAI_STRERROR #endif Undef'ing BROKEN_GETADDRINFO in config.h seems to work OK in limited testing on 4.3.3, however I don't know if there is a good reason for it being there. It seems there should be distinct HAVE_GAI_STRERROR and USE_GAI_STRERROR defines. Comments anyone? [0] http://dodgynet.dyndns.org/tinderbox/OpenSSH_Portable/status.html -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From markus at openbsd.org Fri Feb 14 22:04:57 2003 From: markus at openbsd.org (Markus Friedl) Date: Fri, 14 Feb 2003 12:04:57 +0100 Subject: [SOLVED] Re: Putty won't work when priv-sep turned on on AIX systems In-Reply-To: <1045135158.1195.5.camel@ninja> References: <1044871639.986.24.camel@ninja> <3E478F26.93DEB65B@zip.com.au> <1044881157.987.31.camel@ninja> <3E47B0F2.C4144356@zip.com.au> <1044887590.986.45.camel@ninja> <3E483ABA.1A8A59C@zip.com.au> <3E48338B.5010505@mindrot.org> <1044974067.12080.4.camel@ninja> <3E4997F2.5C5A6943@zip.com.au> <1045135158.1195.5.camel@ninja> Message-ID: <20030214110457.GA32182@folly> could this problem be realated to this? -------------- next part -------------- An embedded message was scrubbed... From: "denis bider" Subject: ssh channel window size: before or after compression? Date: Fri, 14 Feb 2003 00:04:30 +0100 Size: 4177 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030214/58f0f478/attachment.mht From mikulic at natur.cuni.cz Fri Feb 14 22:42:41 2003 From: mikulic at natur.cuni.cz (Adam =?iso-8859-2?Q?Mikuli=E8?=) Date: 14 Feb 2003 12:42:41 +0100 Subject: patch for krb4 authentization in openssh-3.5p1 on RH 8.0 Message-ID: <1045222967.3074.3050.camel@cit2.natur.cuni.cz> Dear developers, recently I tried to compile kerberos4 authentization support in openssh-3.5p1 on Redhat 8.0, unfortunately autentization against kerberos server in a kerberos4 realm doesn't work well, probably due to the bug in auth-krb4.c. My colleague David Komanek wrote patch to this file solving the problem, so credits goes to him. I'm sending this here, believing that it can help somebody else. PROBLEM DESCRIPTION: SSH Daemon isn't able to authenticate user against kerberos4 server, although he accepts already authenticated ssh client user with a valid ticket (already authenticated client via 'kinit' command, supported only using ssh client with ssh protocol version 1). Daemon logs: "WARNING: bad ticket file /tmp/tkt500_22696" and "Couldn't initialize Kerberos ticket file for user!" - and goes to the next authentication method (local password). SOLUTION Problem lies in using the function mkstemp() in auth-krb4.c. We didn't test this on other linux distributions, but most probably changing some of libc library in Redhat 8.0 results in mkstemp() returning error. PATCH *** ../openssh-3.5p1/auth-krb4.c 2002-09-27 05:26:00.000000000 +0200 --- auth-krb4.c 2003-02-12 14:52:43.000000000 +0100 *************** *** 58,63 **** tkt_root = "/ticket/"; #endif /* AFS */ ! snprintf(authctxt->krb4_ticket_file, MAXPATHLEN, "%s%u_%ld", tkt_root, authctxt->pw->pw_uid, (long)getpid()); krb_set_tkt_string(authctxt->krb4_ticket_file); } --- 58,66 ---- tkt_root = "/ticket/"; #endif /* AFS */ ! char docasny[MAXPATHLEN + 1]; ! snprintf(docasny, MAXPATHLEN, "%s%u_%ld_XXXXXX", tkt_root, authctxt->pw->pw_uid, (long)getpid()); + snprintf(authctxt->krb4_ticket_file, MAXPATHLEN, "%s", mktemp(docasny)); + memset(docasny, '\0', MAXPATHLEN); krb_set_tkt_string(authctxt->krb4_ticket_file); } *************** *** 68,72 **** } /* Try to create our ticket file. */ ! if ((fd = mkstemp(authctxt->krb4_ticket_file)) != -1) { close(fd); return (1); --- 71,75 ---- } /* Try to create our ticket file. */ ! if ((fd = open(authctxt->krb4_ticket_file, O_RDWR | O_EXCL | O_CREAT)) >= 0) { close(fd); return (1); Adam Mikulic Faculty of Science, Charles University Prague From stevesk at pobox.com Sat Feb 15 04:36:10 2003 From: stevesk at pobox.com (Kevin Steves) Date: Fri, 14 Feb 2003 09:36:10 -0800 Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: <20030212211232.GA9875@crawfish.ais.com> References: <3E4AA900.6070400@law.harvard.edu> <20030212211232.GA9875@crawfish.ais.com> Message-ID: <20030214173610.GA14880@scott.crlsca.adelphia.net> On Wed, Feb 12, 2003 at 04:12:32PM -0500, Jim Knoble wrote: > with the following users: > > # useradd -m -G users blah > # useradd -m -G users haha > # egrep '(blah|haha)' /etc/passwd /etc/group > /etc/passwd:blah:*:1021:1021::/home/blah:/bin/ksh > /etc/passwd:haha:*:1022:1022::/home/haha:/bin/ksh > /etc/group:users:*:10:,blah,haha > /etc/group:blah:*:1019:blah > /etc/group:haha:*:1020:haha > # > > gives the following results: > > Users successfully log in: > Condition blah haha root > > no Allow* => yes yes yes > AllowUsers blah => yes no no > AllowUsers haha => no yes no > AllowUsers root => no no yes > AllowGroups users => yes yes no > AllowGroups users, AllowUsers root => no no no > > The last one is what's surprising. Here's what the sshd log has to say > (at LogLevel VERBOSE, with timestamps removed to conserve space): those are correct results for the current implementation, which is the same behaviour as 1.2.X but we added support for supplementary groups. we currently do: if user in denyusers deny if #allowusers > 0 and user not in allowusers deny if user group in deny groups deny if #allowgroups > 0 and user group not in allowgroups deny permit From mouring at etoh.eviladmin.org Sat Feb 15 05:07:34 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 14 Feb 2003 12:07:34 -0600 (CST) Subject: [SOLVED] Re: Putty won't work when priv-sep turned on on AIX systems In-Reply-To: <20030214110457.GA32182@folly> Message-ID: Don't see how it cause psftp/putty/pscp to fail on AIX all the time. With and without compression and never seen such a case. I've seen times where putty has refused to connect to a machine (normally older pre-3.1), but I tend to believe it is an odd combination of bugs being hit. On Fri, 14 Feb 2003, Markus Friedl wrote: > could this problem be realated to this? > From jdennis at law.harvard.edu Sat Feb 15 05:12:41 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Fri, 14 Feb 2003 13:12:41 -0500 Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: <20030214173610.GA14880@scott.crlsca.adelphia.net> References: <3E4AA900.6070400@law.harvard.edu> <20030212211232.GA9875@crawfish.ais.com> <20030214173610.GA14880@scott.crlsca.adelphia.net> Message-ID: <3E4D3199.2000800@law.harvard.edu> Kevin, I think the problem is the last line. >> Condition blah haha root >> AllowGroups users, AllowUsers root => no no no blah, haha, and root should all be able to login, but his table shows that they actually cannot. I'm pretty sure thats not intended by your description. > if user in denyusers > deny Shouldn't affect any of them. > if #allowusers > 0 and user not in allowusers > deny root is in AllowUsers so this shouldn't deny (Unless PermitRootLogin no?) > if user group in deny groups > deny Again, no deny directives so this shouldn't affect anyone. > if #allowgroups > 0 and user group not in allowgroups > deny blah and haha's group is in allow group so they shouldn't be denied. > > permit They should be, but aren't. -James Kevin Steves wrote: > On Wed, Feb 12, 2003 at 04:12:32PM -0500, Jim Knoble wrote: > >>with the following users: >> >> # useradd -m -G users blah >> # useradd -m -G users haha >> # egrep '(blah|haha)' /etc/passwd /etc/group >> /etc/passwd:blah:*:1021:1021::/home/blah:/bin/ksh >> /etc/passwd:haha:*:1022:1022::/home/haha:/bin/ksh >> /etc/group:users:*:10:,blah,haha >> /etc/group:blah:*:1019:blah >> /etc/group:haha:*:1020:haha >> # >> >>gives the following results: >> >> Users successfully log in: >> Condition blah haha root >> >> no Allow* => yes yes yes >> AllowUsers blah => yes no no >> AllowUsers haha => no yes no >> AllowUsers root => no no yes >> AllowGroups users => yes yes no >> AllowGroups users, AllowUsers root => no no no >> >>The last one is what's surprising. Here's what the sshd log has to say >>(at LogLevel VERBOSE, with timestamps removed to conserve space): > > > those are correct results for the current implementation, which is the > same behaviour as 1.2.X but we added support for supplementary groups. > > we currently do: > > if user in denyusers > deny > if #allowusers > 0 and user not in allowusers > deny > if user group in deny groups > deny > if #allowgroups > 0 and user group not in allowgroups > deny > > permit > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- James Dennis Harvard Law School "Not everything that counts can be counted, and not everything that can be counted counts." From stevesk at pobox.com Sat Feb 15 05:27:34 2003 From: stevesk at pobox.com (Kevin Steves) Date: Fri, 14 Feb 2003 10:27:34 -0800 Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: <3E4D3199.2000800@law.harvard.edu> References: <3E4AA900.6070400@law.harvard.edu> <20030212211232.GA9875@crawfish.ais.com> <20030214173610.GA14880@scott.crlsca.adelphia.net> <3E4D3199.2000800@law.harvard.edu> Message-ID: <20030214182734.GB14880@scott.crlsca.adelphia.net> On Fri, Feb 14, 2003 at 01:12:41PM -0500, James Dennis wrote: > Kevin, > > I think the problem is the last line. > > >> Condition blah haha root > >> AllowGroups users, AllowUsers root => no no no > > blah, haha, and root should all be able to login, but his table shows > that they actually cannot. I'm pretty sure thats not intended by your > description. > > > if user in denyusers > > deny > Shouldn't affect any of them. > > > if #allowusers > 0 and user not in allowusers > > deny > root is in AllowUsers so this shouldn't deny (Unless PermitRootLogin no?) blah and haha are denied here. > > if user group in deny groups > > deny > Again, no deny directives so this shouldn't affect anyone. > > > if #allowgroups > 0 and user group not in allowgroups > > deny > blah and haha's group is in allow group so they shouldn't be denied. root is denied here. From jdennis at law.harvard.edu Sat Feb 15 05:46:55 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Fri, 14 Feb 2003 13:46:55 -0500 Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: <20030214182734.GB14880@scott.crlsca.adelphia.net> References: <3E4AA900.6070400@law.harvard.edu> <20030212211232.GA9875@crawfish.ais.com> <20030214173610.GA14880@scott.crlsca.adelphia.net> <3E4D3199.2000800@law.harvard.edu> <20030214182734.GB14880@scott.crlsca.adelphia.net> Message-ID: <3E4D399F.4070301@law.harvard.edu> Well, thats correct functionally with the code, but it doesn't follow the intended use of the directive. It doesn't make sense to allow someone access, then deny it later because of another directive. I think instead of working towards denials, assuming a denial and working towards allows might make more sense to prevent the allow and deny directives from cancelling each other out. if user is in denyusers deny if user group is in deny groups deny if #allowusers > 0 and user is in allowusers put user on allow list if #allowgroups > 0 user group is in allowgroups put user on allow list You can deny everyone, but explicitly allow people to override the deny which is more ideal and more like expected functionality. -James Kevin Steves wrote: > On Fri, Feb 14, 2003 at 01:12:41PM -0500, James Dennis wrote: > >>Kevin, >> >>I think the problem is the last line. >> >> >>>> Condition blah haha root >>>> AllowGroups users, AllowUsers root => no no no >> >>blah, haha, and root should all be able to login, but his table shows >>that they actually cannot. I'm pretty sure thats not intended by your >>description. >> >> >>> if user in denyusers >>> deny >> >>Shouldn't affect any of them. >> >> >>> if #allowusers > 0 and user not in allowusers >>> deny >> >>root is in AllowUsers so this shouldn't deny (Unless PermitRootLogin no?) > > > blah and haha are denied here. > > >>> if user group in deny groups >>> deny >> >>Again, no deny directives so this shouldn't affect anyone. >> >> >>> if #allowgroups > 0 and user group not in allowgroups >>> deny >> >>blah and haha's group is in allow group so they shouldn't be denied. > > > root is denied here. > -- James Dennis Harvard Law School "Not everything that counts can be counted, and not everything that can be counted counts." From binder at arago.de Sat Feb 15 06:11:45 2003 From: binder at arago.de (Thomas Binder) Date: Fri, 14 Feb 2003 20:11:45 +0100 Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: <3E4D399F.4070301@law.harvard.edu> References: <3E4AA900.6070400@law.harvard.edu> <20030212211232.GA9875@crawfish.ais.com> <20030214173610.GA14880@scott.crlsca.adelphia.net> <3E4D3199.2000800@law.harvard.edu> <20030214182734.GB14880@scott.crlsca.adelphia.net> <3E4D399F.4070301@law.harvard. Message-ID: <20030214191144.GA9097386@ohm.arago.de> Hi! On Fri, Feb 14, 2003 at 01:46:55PM -0500, James Dennis wrote: > Well, thats correct functionally with the code, but it doesn't > follow the intended use of the directive. It doesn't make sense > to allow someone access, then deny it later because of another > directive. Maybe something like Apache's "Satisfy"-directive would be a solution (http://httpd.apache.org/docs/mod/core.html#satisfy), e.g. SatisfyAllow all -> user must be in both AllowGroup and AllowUsers SatisfyAllow any -> user must be in AllowGroup or AllowUsers or both I don't know if "either" as a third option would make sense, i.e. do not allow access if the user is in both AllowGroup and AllowUsers. "All" would be the default, providing the current behaviour. Ciao Thomas From djast at cs.toronto.edu Sat Feb 15 06:28:13 2003 From: djast at cs.toronto.edu (Dan Astoorian) Date: Fri, 14 Feb 2003 14:28:13 -0500 Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: Your message of "Fri, 14 Feb 2003 13:46:55 EST." <3E4D399F.4070301@law.harvard.edu> Message-ID: <03Feb14.142815edt.453169-13279@jane.cs.toronto.edu> On Fri, 14 Feb 2003 13:46:55 EST, James Dennis writes: > Well, thats correct functionally with the code, but it doesn't follow > the intended use of the directive. It doesn't make sense to allow > someone access, then deny it later because of another directive. That's not always the case. It might make sense to allow access to a group, then deny access to a particular member user in that group. It probably never makes sense to explicitly allow access to a user, then deny access because that user is in a particular group. It seems to me that the most explicit option should take precedence (AllowUsers in preference to AllowGroups); perhaps something like if user is in denyusers deny if user is in allowusers permit if user group is in denygroups deny if user group is in allowgroups permit if #allowusers > 0 or #allowgroups > 0 deny permit would make sense? Related question: should it be considered an error to supply both an AllowUsers and DenyUsers directive in the same configuration? If there are any AllowUsers directives, (I think) the only way a DenyUsers statement could have any effect at all would be if it named the same user as an AllowUsers, which would be silly. Likewise for AllowGroups and DenyGroups. If not an error, should a warning be issued if these conditions is detected? -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From jdennis at law.harvard.edu Sat Feb 15 06:51:00 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Fri, 14 Feb 2003 14:51:00 -0500 Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: <20030214191144.GA9097386@ohm.arago.de> References: <3E4AA900.6070400@law.harvard.edu> <20030212211232.GA9875@crawfish.ais.com> <20030214173610.GA14880@scott.crlsca.adelphia.net> <3E4D3199.2000800@law.harvard.edu> <20030214182734.GB14880@scott.crlsca.adelphia.net> <3E4D399F.4070301@law.harvard. <20030214191144.GA9097386@ohm.arago.de> Message-ID: <3E4D48A4.4000506@law.harvard.edu> > Maybe something like Apache's "Satisfy"-directive would be a > solution (http://httpd.apache.org/docs/mod/core.html#satisfy), > e.g. > > SatisfyAllow all -> user must be in both AllowGroup and AllowUsers > > SatisfyAllow any -> user must be in AllowGroup or AllowUsers or > both Great idea! What does everyone else think? > > I don't know if "either" as a third option would make sense, i.e. > do not allow access if the user is in both AllowGroup and > AllowUsers. Wouldn't either be the same as any? -- James Dennis Harvard Law School "Not everything that counts can be counted, and not everything that can be counted counts." From jdennis at law.harvard.edu Sat Feb 15 07:02:44 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Fri, 14 Feb 2003 15:02:44 -0500 Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: <03Feb14.142815edt.453169-13279@jane.cs.toronto.edu> References: <03Feb14.142815edt.453169-13279@jane.cs.toronto.edu> Message-ID: <3E4D4B64.4070608@law.harvard.edu> > That's not always the case. It might make sense to allow access to a > group, then deny access to a particular member user in that group. It > probably never makes sense to explicitly allow access to a user, then > deny access because that user is in a particular group. What if the user's group is denied for bad bahavior, but you trust a particular user in that group? Perhaps we should stop saying what probably *might* happen and accomodate accordingly assuming the strange cases probably *will* happen, for whatever reason. > It seems to me that the most explicit option should take precedence > (AllowUsers in preference to AllowGroups); perhaps something like > > if user is in denyusers > deny > if user is in allowusers > permit > if user group is in denygroups > deny > if user group is in allowgroups > permit > if #allowusers > 0 or #allowgroups > 0 > deny > permit > > would make sense? What if we rearrange things and try to think about how people set up rules. If I were to setup rules with permissions of ssh access I'd probably explicitly state groups and then users and let the user specification override groups if they came after groups, and likewise. If we do it in sequential order you can probably have more flexibility than by doing it by directive. Such as: DenyGroup: badpeople AllowUser: badperson # they're in badpeople, but can have access DenyGroup: badpeople # This will undo the allowuser above and re-deny everyone in badpeople Does that make sense at all? -- James Dennis Harvard Law School "Not everything that counts can be counted, and not everything that can be counted counts." From htodd at twofifty.com Sat Feb 15 07:09:59 2003 From: htodd at twofifty.com (Hisashi T Fujinaka) Date: Fri, 14 Feb 2003 12:09:59 -0800 (PST) Subject: Has anyone had success with openssh/skey on Solaris2.6? In-Reply-To: <3E4D48A4.4000506@law.harvard.edu> References: <3E4AA900.6070400@law.harvard.edu> <20030212211232.GA9875@crawfish.ais.com> <20030214173610.GA14880@scott.crlsca.adelphia.net> <3E4D3199.2000800@law.harvard.edu> <20030214182734.GB14880@scott.crlsca.adelphia.net> <3E4D399F.4070301@law.harvard. <20030214191144.GA9097386@ohm.arago.de> <3E4D48A4.4000506@law.harvard.edu> Message-ID: If so, can you give me some help? :) The docs are a bit spare. It took me some searching to find the skey sources as well. Thanks. -- Hisashi T Fujinaka - htodd at twofifty.com BSEE (6/86) + BSChem (3/95) + BAEnglish (8/95) + $2.50 = mocha latte From jdennis at law.harvard.edu Sat Feb 15 07:56:37 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Fri, 14 Feb 2003 15:56:37 -0500 Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: <3E4D4B64.4070608@law.harvard.edu> References: <03Feb14.142815edt.453169-13279@jane.cs.toronto.edu> <3E4D4B64.4070608@law.harvard.edu> Message-ID: <3E4D5805.1050808@law.harvard.edu> I've thought about this a bit more and have changed my mind. I think everything should just be kept very simple to avoid apache-like configuration madness. Maybe Thomas's idea? If user is in denyusers deny if user is in allowusers allow report error if user is in both if user's group is in denygroups check status of either/and flag either and is in allowusers allow and deny if user's group is in allowgroups check status of either/and flag either allow and is in allowusers allow else deny report error if group is in both -- James Dennis Harvard Law School "Not everything that counts can be counted, and not everything that can be counted counts." From mouring at etoh.eviladmin.org Sat Feb 15 08:48:30 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 14 Feb 2003 15:48:30 -0600 (CST) Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: <3E4D5805.1050808@law.harvard.edu> Message-ID: I think we are making this more complex than it really is. The only valid rules should be as such If PermitRootLogin then goto Accepted # Damn it, if I state root is allowed, it damn well better be honored. if DenyUser then goto Reject # don't pass go don't collect 200 if AllowUser then goto Accepted # If we state they are allowed, honor it If DenyGroup then goto Reject # If they are not allowed by AllowUser they are never If AllowGroup then goto Accepted # We are stated they are allowed directly if AllowUser > 0 || AllowGroup > 0 then goto Reject # We have either allowed groups or allowed users, and they didn't pass. Accepted: ... return; Rejected: ... return; There is no other sane way.. No stupid order issues (which sshd_config has none to start with). And allows for 'Reject by defualt, define allowed' view. Plus it allows for the other way around. 'Allow by default, reject if not' So it makes everyone happy. The way it currently stands I doubt anyone is using allow{group,user} at this moment. Besides, personally if I say Yes I want root for any reason to be allowed. It damn well better honor it. It implies 'AllowUser'. Deny{User,Group} needs to be honored first because I think anyone stupid enough to do: AllowUser Foo DenyUser Foo should be shot. I can see someone going.. "But this breaks DenyUser root". Well tought, if you don't want root, use the right option. - Ben On Fri, 14 Feb 2003, James Dennis wrote: > I've thought about this a bit more and have changed my mind. I think > everything should just be kept very simple to avoid apache-like > configuration madness. Maybe Thomas's idea? > > If user is in denyusers > deny > if user is in allowusers > allow > > report error if user is in both > > if user's group is in denygroups > check status of either/and flag > either and is in allowusers > allow > and > deny > if user's group is in allowgroups > check status of either/and flag > either > allow > and > is in allowusers > allow > else > deny > > report error if group is in both > > -- > James Dennis > Harvard Law School > > "Not everything that counts can be counted, > and not everything that can be counted counts." > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From jdennis at law.harvard.edu Sat Feb 15 09:04:08 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Fri, 14 Feb 2003 17:04:08 -0500 Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: References: Message-ID: <3E4D67D8.6080309@law.harvard.edu> Yes, agreed. Thanks Ben. If someone is in a group that is denyed, but should be allowed access to ssh, unix groups should handle that. Remove the user from the group and such. It's been a long day and I obviously went off on a tangent, but you've put words to what my last email was trying to say much better than I did. -James Ben Lindstrom wrote: > I think we are making this more complex than it really is. The only valid > rules should be as such > > If PermitRootLogin then > goto Accepted # Damn it, if I state root is allowed, it damn well > better be honored. > > if DenyUser then > goto Reject # don't pass go don't collect 200 > > if AllowUser then > goto Accepted # If we state they are allowed, honor it > > If DenyGroup then > goto Reject # If they are not allowed by AllowUser they are never > > If AllowGroup then > goto Accepted # We are stated they are allowed directly > > if AllowUser > 0 || AllowGroup > 0 then > goto Reject # We have either allowed groups or allowed users, and > they didn't pass. > > Accepted: > ... > return; > > Rejected: > ... > return; > > There is no other sane way.. No stupid order issues (which sshd_config has > none to start with). And allows for 'Reject by defualt, define allowed' > view. > > Plus it allows for the other way around. 'Allow by default, reject if > not' > > So it makes everyone happy. > > The way it currently stands I doubt anyone is using allow{group,user} > at this moment. Besides, personally if I say Yes I want root for any > reason to be allowed. It damn well better honor it. It implies > 'AllowUser'. > > Deny{User,Group} needs to be honored first because I think anyone stupid > enough to do: > > AllowUser Foo > DenyUser Foo > > should be shot. > > I can see someone going.. "But this breaks DenyUser root". Well tought, > if you don't want root, use the right option. > > - Ben > > > On Fri, 14 Feb 2003, James Dennis wrote: > > >>I've thought about this a bit more and have changed my mind. I think >>everything should just be kept very simple to avoid apache-like >>configuration madness. Maybe Thomas's idea? >> >>If user is in denyusers >> deny >>if user is in allowusers >> allow >> >>report error if user is in both >> >>if user's group is in denygroups >> check status of either/and flag >> either and is in allowusers >> allow >> and >> deny >>if user's group is in allowgroups >> check status of either/and flag >> either >> allow >> and >> is in allowusers >> allow >> else >> deny >> >>report error if group is in both >> >>-- >>James Dennis >>Harvard Law School >> >>"Not everything that counts can be counted, >>and not everything that can be counted counts." >> >>_______________________________________________ >>openssh-unix-dev mailing list >>openssh-unix-dev at mindrot.org >>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >> > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- James Dennis Harvard Law School "Not everything that counts can be counted, and not everything that can be counted counts." From djast at cs.toronto.edu Sat Feb 15 09:31:22 2003 From: djast at cs.toronto.edu (Dan Astoorian) Date: Fri, 14 Feb 2003 17:31:22 -0500 Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: Your message of "Fri, 14 Feb 2003 16:48:30 EST." Message-ID: <03Feb14.173123edt.453195-13279@jane.cs.toronto.edu> On Fri, 14 Feb 2003 16:48:30 EST, Ben Lindstrom writes: > > I think we are making this more complex than it really is. The only valid > rules should be as such > > If PermitRootLogin then > goto Accepted # Damn it, if I state root is allowed, it damn well > better be honored. I don't think I agree with this. I'd interpret "PermitRootLogin" in this case as being relevant to any user with uid=0, whereas AllowUsers and DenyUsers refer to specific entries in /etc/passwd. "PermitRootLogin no" is presumably intended to enforce the policy "no superuser account may ever connect via ssh," for the same reason many systems are configured to restrict root logins to a (presumably physically secure) console; I see no justification to infer that "PermitRootLogin yes" should circumvent any additional constraints, such as DenyUsers. Do PermitRootLogin=without-password or PermitRootLogin=forced-commands-only present any further considerations? Currently, PermitRootLogin is handled independently anyway. [snip remainder of algorithm, which appears to be identical to the one I suggested :-) ] > I can see someone going.. "But this breaks DenyUser root". Well tought, > if you don't want root, use the right option. What if I want AllowUsers shutdown where "shutdown" is a uid=0 account with a shell of /etc/shutdown, but I don't want to permit root to log in via ssh? -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From jmknoble at pobox.com Sat Feb 15 09:35:26 2003 From: jmknoble at pobox.com (Jim Knoble) Date: Fri, 14 Feb 2003 17:35:26 -0500 Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: <03Feb14.142815edt.453169-13279@jane.cs.toronto.edu> References: <3E4D399F.4070301@law.harvard.edu> <03Feb14.142815edt.453169-13279@jane.cs.toronto.edu> Message-ID: <20030214223526.GE16600@crawfish.ais.com> Circa 2003-02-14 14:28:13 -0500 dixit Dan Astoorian: : Related question: should it be considered an error to supply both an : AllowUsers and DenyUsers directive in the same configuration? If there : are any AllowUsers directives, (I think) the only way a DenyUsers : statement could have any effect at all would be if it named the same : user as an AllowUsers, which would be silly. : : Likewise for AllowGroups and DenyGroups. Not so for *Groups directives: /etc/group:users:*:10:blah,haha,heehee /etc/group:badusers:*:8675309:heehee AllowGroups users DenyGroups badusers -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) Stop the War on Freedom ... Start the War on Poverty! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 256 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030214/daf91698/attachment.bin From jmknoble at pobox.com Sat Feb 15 09:41:26 2003 From: jmknoble at pobox.com (Jim Knoble) Date: Fri, 14 Feb 2003 17:41:26 -0500 Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: References: <3E4D5805.1050808@law.harvard.edu> Message-ID: <20030214224126.GF16600@crawfish.ais.com> Circa 2003-02-14 15:48:30 -0600 dixit Ben Lindstrom: : I think we are making this more complex than it really is. The only valid : rules should be as such : : If PermitRootLogin then : goto Accepted # Damn it, if I state root is allowed, it damn well : better be honored. ->else if PermitRootLogin is "no" and user is root then goto Rejected : if DenyUser then : goto Reject # don't pass go don't collect 200 : : if AllowUser then : goto Accepted # If we state they are allowed, honor it : : If DenyGroup then : goto Reject # If they are not allowed by AllowUser they are never : : If AllowGroup then : goto Accepted # We are stated they are allowed directly : : if AllowUser > 0 || AllowGroup > 0 then : goto Reject # We have either allowed groups or allowed users, and : they didn't pass. : : Accepted: : ... : return; : : Rejected: : ... : return; : : There is no other sane way.. No stupid order issues (which sshd_config has : none to start with). And allows for 'Reject by defualt, define allowed' : view. Looks good to me, with the additional test i inserted above (implied by your description, but best to be explicit here). -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) Stop the War on Freedom ... Start the War on Poverty! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 256 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030214/01128439/attachment.bin From mouring at etoh.eviladmin.org Sat Feb 15 10:08:19 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 14 Feb 2003 17:08:19 -0600 (CST) Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: <03Feb14.173123edt.453195-13279@jane.cs.toronto.edu> Message-ID: On Fri, 14 Feb 2003, Dan Astoorian wrote: > On Fri, 14 Feb 2003 16:48:30 EST, Ben Lindstrom writes: > > > > I think we are making this more complex than it really is. The only valid > > rules should be as such > > > > If PermitRootLogin then > > goto Accepted # Damn it, if I state root is allowed, it damn well > > better be honored. > > I don't think I agree with this. > > I'd interpret "PermitRootLogin" in this case as being relevant to any > user with uid=0, whereas AllowUsers and DenyUsers refer to specific > entries in /etc/passwd. > IF you have multiple uid=0 users you are doing stupid things. I refuse to buy into the "But I want multiple uid=0 sers". It is a load of bullshit. > "PermitRootLogin no" is presumably intended to enforce the policy "no > superuser account may ever connect via ssh," for the same reason many > systems are configured to restrict root logins to a (presumably > physically secure) console; I see no justification to infer that > "PermitRootLogin yes" should circumvent any additional constraints, such > as DenyUsers. > There is only one 'superuser' account.. So it is acceptable and correct to bypass. > Do PermitRootLogin=without-password or PermitRootLogin=forced-commands-only > present any further considerations? > Any PermitRootLogin setting other than 'no'. > Currently, PermitRootLogin is handled independently anyway. > > [snip remainder of algorithm, which appears to be identical to the one I > suggested :-) ] > > > I can see someone going.. "But this breaks DenyUser root". Well tought, > > if you don't want root, use the right option. > > What if I want > AllowUsers shutdown > > where "shutdown" is a uid=0 account with a shell of /etc/shutdown, but I > don't want to permit root to log in via ssh? > See comment about about doing stupid things.. - Ben From mouring at etoh.eviladmin.org Sat Feb 15 10:10:41 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 14 Feb 2003 17:10:41 -0600 (CST) Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: <20030214224126.GF16600@crawfish.ais.com> Message-ID: On Fri, 14 Feb 2003, Jim Knoble wrote: > Circa 2003-02-14 15:48:30 -0600 dixit Ben Lindstrom: > > : I think we are making this more complex than it really is. The only valid > : rules should be as such > : > : If PermitRootLogin then > : goto Accepted # Damn it, if I state root is allowed, it damn well > : better be honored. > > ->else if PermitRootLogin is "no" and user is root then > goto Rejected > That is what I was implying.. As long as it is not 'no'. Sorry for not making it clear. - Ben From dtucker at zip.com.au Sat Feb 15 11:26:08 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 15 Feb 2003 11:26:08 +1100 Subject: [SOLVED] Re: Putty won't work when priv-sep turned on on AIXsystems References: Message-ID: <3E4D8920.E9E3E0EF@zip.com.au> Ben Lindstrom wrote: > On Fri, 14 Feb 2003, Markus Friedl wrote: > > > could this problem be realated to this? I don't think so, since the sequence of events is: 1) type username 2) type password 3) dies with buffer_append_space: alloc 10506240 not supported Unless Mark's password was 10MB before being compressed... > Don't see how it cause psftp/putty/pscp to fail on AIX all the time. With > and without compression and never seen such a case. It worked for him with compression off. -- 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 insecure at mail.od.ua Sun Feb 16 03:55:17 2003 From: insecure at mail.od.ua (insecure at mail.od.ua) Date: Sat, 15 Feb 2003 14:55:17 -0200 Subject: scp + .bashrc buglet Message-ID: <200302151455.17738."insecure@mail.od.ua"> Hi OpenSSH folks, Just a quick note: this is my .bashrc: # Executed by non-login interactive shell # # scp go wild when it see this #echo "<*> Executing ~/.bashrc from '$0'. Command line: '$*'" #ps -H e #echo "<*> Finished ~/.bashrc" Line 3 was added and subsequent lines commented out. Now scp works. Looks like a little scp bug for me. CC me, I'm not subscribed. Thanks for your attention. -- vda From chris at obelix.hedonism.cx Sun Feb 16 00:31:14 2003 From: chris at obelix.hedonism.cx (Christian Vogel) Date: Sat, 15 Feb 2003 14:31:14 +0100 Subject: scp + .bashrc buglet In-Reply-To: <200302151455.17738."insecure@mail.od.ua"> References: <200302151455.17738."insecure@mail.od.ua"> Message-ID: <20030215133114.GA1519@emil.frop.org> Hi, just check in your .bashrc if this shell is really a interactive one, for example like this, to avoid messing around with the output of e.g. shell-scripts...: --- .bashrc: --- case "$-" in *i*) # Interactive Shell! echo "Welcome on `hostname`!" # Hello /usr/games/fortune # Fortune ddate # Discordian Date PS1='\u@\h \w\$' # Fancy Prompt # check for mail # blah... ;; esac Chris On Sat, Feb 15, 2003 at 02:55:17PM -0200, insecure at mail.od.ua wrote: > Just a quick note: this is my .bashrc: (...) > Line 3 was added and subsequent lines commented out. > Now scp works. Looks like a little scp bug for me. -- "... being a Linux user is sort of like living in a house inhabited by a large family of carpenters and architects. Every morning when you wake up, the house is a little different. Maybe there is a new turret, or some walls have moved. Or perhaps someone has temporarily removed the floor under your bed." - Unix for Dummies, 2nd Edition -- found in the .sig of Rob Riggs, rriggs at tesser.com From dtucker at zip.com.au Sun Feb 16 00:44:27 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 16 Feb 2003 00:44:27 +1100 Subject: scp + .bashrc buglet References: <200302151455.17738."insecure@mail.od.ua"> Message-ID: <3E4E443B.E406C6AD@zip.com.au> "insecure at mail.od.ua" wrote: > Just a quick note: this is my .bashrc: > > # Executed by non-login interactive shell > # > # scp go wild when it see this > #echo "<*> Executing ~/.bashrc from '$0'. Command line: '$*'" > #ps -H e > #echo "<*> Finished ~/.bashrc" So don't do that, then. > Line 3 was added and subsequent lines commented out. > Now scp works. Looks like a little scp bug for me. Your non-interactive shell should not generate extraneous output as scp has no way of knowing how much of the output to ignore. You will also see similar problems with other software that uses ssh as a transport (eg rsync, cvs). This is not a bug, see http://www.openssh.com/faq.html#2.9 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Sun Feb 16 03:53:17 2003 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 15 Feb 2003 17:53:17 +0100 Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: References: <03Feb14.173123edt.453195-13279@jane.cs.toronto.edu> Message-ID: <20030215165317.GK5822@cygbert.vinschen.de> On Fri, Feb 14, 2003 at 05:08:19PM -0600, Ben Lindstrom wrote: > IF you have multiple uid=0 users you are doing stupid things. > > I refuse to buy into the "But I want multiple uid=0 sers". It is a load > of bullshit. > [...] > There is only one 'superuser' account.. So it is acceptable and correct to > bypass. Ben, you *know* that's not exactly true. On NT there's a superuser group ("Administrators" on english versions) and there's an arbitrary number of accounts which could be members of that group. Even this description doesn't completely cover the complexity of possible rules used in NT systems and regardless of my own opinion, this is *fact*. I don't think it's the correct way to deal with this by ignoring it. That's the reason I already asked at least twice for changing all if uid == 0 or similar to if is_root(uid) with is_superuser being system-dependent. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From insecure at mail.od.ua Sun Feb 16 11:43:31 2003 From: insecure at mail.od.ua (insecure at mail.od.ua) Date: Sat, 15 Feb 2003 22:43:31 -0200 Subject: scp + .bashrc buglet In-Reply-To: <3E4E443B.E406C6AD@zip.com.au> References: <200302151455.17738."insecure@mail.od.ua"> <3E4E443B.E406C6AD@zip.com.au> Message-ID: <200302152243.32103."insecure@mail.od.ua"> On Saturday 15 February 2003 11:44, Darren Tucker wrote: > "insecure at mail.od.ua" wrote: > > Just a quick note: this is my .bashrc: > > > > # Executed by non-login interactive shell > > # > > # scp go wild when it see this > > #echo "<*> Executing ~/.bashrc from '$0'. Command line: '$*'" > > #ps -H e > > #echo "<*> Finished ~/.bashrc" > > So don't do that, then. > > > Line 3 was added and subsequent lines commented out. > > Now scp works. Looks like a little scp bug for me. > > Your non-interactive shell should not generate extraneous output as scp > has no way of knowing how much of the output to ignore. You will also > see similar problems with other software that uses ssh as a transport > (eg rsync, cvs). > > This is not a bug, see http://www.openssh.com/faq.html#2.9 Thanks for the info. Sorry for the noise... -- vda From mouring at etoh.eviladmin.org Sun Feb 16 14:31:36 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 15 Feb 2003 21:31:36 -0600 (CST) Subject: AllowUsers Change Message-ID: Markus, ignore the other stuff I sent.. I need to go back to bed and stop trying to code.. For everone else.. Will this make everyone happy? This does the follow. it will always honor AllowUsers. If there is no Allow/DenyGroups it stated they are not in allowUsers. IF there are AllowDenyGroups it tries them. And then stated they are not in either AllowUsers nor AllowGroups since PErmitRootLogin is not handled in auth.c:allowed_users() I will not try to add that logic. I still believe it should be true. Diff against -ccurent BSD tree. - Ben Index: auth.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth.c,v retrieving revision 1.46 diff -u -r1.46 auth.c --- auth.c 4 Nov 2002 10:07:53 -0000 1.46 +++ auth.c 16 Feb 2003 03:27:42 -0000 @@ -105,15 +105,16 @@ return 0; } } - /* Return false if AllowUsers isn't empty and user isn't listed there */ + /* Return true if person in AllowUsers, otherwise try the group test */ if (options.num_allow_users > 0) { for (i = 0; i < options.num_allow_users; i++) if (match_user(pw->pw_name, hostname, ipaddr, options.allow_users[i])) - break; - /* i < options.num_allow_users iff we break for loop */ - if (i >= options.num_allow_users) { - log("User %.100s not allowed because not listed in AllowUsers", + goto success; + + if (options.num_deny_groups == 0 && + options.num_allow_groups == 0) { + log("User %.100s not allowed because not in AllowUsers", pw->pw_name); return 0; } @@ -136,20 +137,28 @@ return 0; } /* - * Return false if AllowGroups isn't empty and one of user's groups - * isn't listed there + * Return false if AllowGroups isn't empty and one of + * user's groups isn't listed there */ if (options.num_allow_groups > 0) if (!ga_match(options.allow_groups, options.num_allow_groups)) { ga_free(); - log("User %.100s not allowed because none of user's groups are listed in AllowGroups", + if (options.num_deny_users > 0 || + options.num_allow_users > 0) { + log("User %.100s not allowed because not in AllowUsers nor user's groups in AllowGroups", + pw->pw_name); + return 0; + } else { + log("User %.100s not allowed because none of user's groups are listed in AllowGroups", pw->pw_name); - return 0; + return 0; + } } ga_free(); } /* We found no reason not to let this user try to log on... */ +success: return 1; } From bugzilla-daemon at mindrot.org Mon Feb 17 01:34:33 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 17 Feb 2003 01:34:33 +1100 (EST) Subject: [Bug 430] Could add option to sftp-server to disable write access Message-ID: <20030216143433.BCBD264522@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=430 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 17 01:41:01 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 17 Feb 2003 01:41:01 +1100 (EST) Subject: [Bug 387] command="" in authorized_keys fails when sshd_config has "PermitRootLogon forced-commands-only" Message-ID: <20030216144101.E82926454F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=387 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #225 is|0 |1 obsolete| | ------- Additional Comments From markus at openbsd.org 2003-02-17 01:41 ------- Created an attachment (id=230) --> (http://bugzilla.mindrot.org/attachment.cgi?id=230&action=view) fix ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 17 04:40:50 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 17 Feb 2003 04:40:50 +1100 (EST) Subject: [Bug 486] "PermitRootLogin no" can implicitly reveal root password Message-ID: <20030216174050.EBFFE64551@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=486 Bug 486 depends on bug 387, which changed state. Bug 387 Summary: command="" in authorized_keys fails when sshd_config has "PermitRootLogon forced-commands-only" http://bugzilla.mindrot.org/show_bug.cgi?id=387 What |Old Value |New Value ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 17 04:40:48 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 17 Feb 2003 04:40:48 +1100 (EST) Subject: [Bug 387] command="" in authorized_keys fails when sshd_config has "PermitRootLogon forced-commands-only" Message-ID: <20030216174048.40DE96454A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=387 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From markus at openbsd.org 2003-02-17 04:40 ------- fixed for 3.6 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From stano at meduna.org Tue Feb 18 00:11:58 2003 From: stano at meduna.org (Stanislav Meduna) Date: Mon, 17 Feb 2003 14:11:58 +0100 Subject: Limit forwarding to specific ports Message-ID: <03Feb17.141404cet.117128@fwetm.etm-ag.com> Hello, We are using the AllowUsers feature of sshd and would like to control which users can ask for forwarding of which ports. E.g. when the user is foo, allow him to tunnel connections to bar:5678 and baz:7654, but no shell (or some dummy shell) and no other forwardings. Is such feature planned for the future? Would you accept such patch in the mainstream distribution? I would appreciate Cc: to mail - I am not subscribed to the list. Thanks -- Stano From markus at openbsd.org Tue Feb 18 01:44:02 2003 From: markus at openbsd.org (Markus Friedl) Date: Mon, 17 Feb 2003 15:44:02 +0100 Subject: Limit forwarding to specific ports In-Reply-To: <03Feb17.141404cet.117128@fwetm.etm-ag.com> References: <03Feb17.141404cet.117128@fwetm.etm-ag.com> Message-ID: <20030217144402.GB18808@folly> On Mon, Feb 17, 2003 at 02:11:58PM +0100, Stanislav Meduna wrote: > Is such feature planned for the future? Would you accept such patch > in the mainstream distribution? 1) no, it's not planned. 2) depends on patch size. From dot at dotat.at Tue Feb 18 05:49:32 2003 From: dot at dotat.at (Tony Finch) Date: Mon, 17 Feb 2003 18:49:32 +0000 Subject: Limit forwarding to specific ports In-Reply-To: <03Feb17.141404cet.117128@fwetm.etm-ag.com> Message-ID: "Stanislav Meduna" wrote: > >We are using the AllowUsers feature of sshd and would like to control >which users can ask for forwarding of which ports. E.g. when the >user is foo, allow him to tunnel connections to bar:5678 and baz:7654, >but no shell (or some dummy shell) and no other forwardings. I have a patch that is sort-of going in this direction, although it isn't as flexible as I would like. Part of it allows you to control which port forwardings are allowed; another part allows you to control which features are available for users with a restricted shell. I think the auth_restricted() hook that I added is a reasonable first step towards proper generalization. http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=104387691708672 Tony. -- f.a.n.finch http://dotat.at/ CAPE WRATH TO RATTRAY HEAD INCLUDING ORKNEY: SOUTH OR SOUTHEAST 5 TO 7, PERHAPS GALE 8 LATER AROUND ORKNEY. FAIR. MODERATE OR GOOD. MODERATE SHELTERED WATERS, OTHERWISE ROUGH PERHAPS VERY ROUGH IN EAST. From bugzilla-daemon at mindrot.org Tue Feb 18 08:00:45 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 18 Feb 2003 08:00:45 +1100 (EST) Subject: [Bug 495] New: local port forwards start before authentication is complete (password auth) Message-ID: <20030217210045.AB3186455F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=495 Summary: local port forwards start before authentication is complete (password auth) Product: Portable OpenSSH Version: 3.5p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: security Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: rhaig at hackboy.com when doing a local port forward (ssh www.foo.com -L8080:localhost:80) the forward becomes active before the authentication is complete. repeat by running the above command to your server that is running ssh and a web server, before entering the password (but after the password prompt appears), open the local end of the port forward, and observe it's operability (if it's a web server, "GET /"). This is without any keys in place or the password being entered. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Feb 18 09:17:13 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 18 Feb 2003 09:17:13 +1100 (EST) Subject: [Bug 496] New: add a timeout function to ssh-agent Message-ID: <20030217221713.1201764561@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=496 Summary: add a timeout function to ssh-agent Product: Portable OpenSSH Version: older versions Platform: All URL: http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-add OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: ssh-agent AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: hauser at acm.org ssh-agent and ssh-add have a lifetime function. ssh-add has the -c/SSH_ASKPASS feature. This appears to be useful, but deviating from the usual user experience as per Mozilla's personal security module (PSM), password-protected screen-locks, etc. Therefore, I suggest to enhance ssh-agent such that there is a timeout option that defaults to e.g. 15 minutes. If no key has been used through ssh-agent the timeout period, ssh-agent is temporarily disabled. Re-enabling could be done by popping up a password panel asking for the password for i) the first identity that was added ii) the default identity iii) the identity of the identity about to be used next. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Feb 18 10:37:17 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 18 Feb 2003 10:37:17 +1100 (EST) Subject: [Bug 495] local port forwards start before authentication is complete (password auth) Message-ID: <20030217233717.AF59C64567@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=495 ------- Additional Comments From djm at mindrot.org 2003-02-18 10:37 ------- I can't replicate this with 3.5p1. Please attach a debug trace from the server (run as "sshd -d -d -d") accepting a forward connection prior to password authentication. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 01:15:21 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 01:15:21 +1100 (EST) Subject: [Bug 496] add a timeout function to ssh-agent Message-ID: <20030218141521.623B36450B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=496 ------- Additional Comments From markus at openbsd.org 2003-02-19 01:15 ------- that's not too hard with the current code, and you could use the 'passwd' lock feature for something similar: specify timeout x and enter passwd on agent startup. after x seconds of activity the agent will 'autolock'. use ssh-add -X to unlock the agent. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 03:02:42 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 03:02:42 +1100 (EST) Subject: [Bug 480] extend the -l or -L option to mention the ssh-agent's pid Message-ID: <20030218160242.078A364515@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=480 ------- Additional Comments From hauser at acm.org 2003-02-19 03:02 ------- Or another option would be to have ssh-agent complain if it detects other instances of itself already running under the same userID? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 03:13:17 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 03:13:17 +1100 (EST) Subject: [Bug 496] add a timeout function to ssh-agent Message-ID: <20030218161317.12BA964520@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=496 ------- Additional Comments From hauser at acm.org 2003-02-19 03:13 ------- Just trying to understand assuming a 15 minutes timeout: so as per http://bugzilla.mindrot.org/show_bug.cgi?id=481, I do i) setenv SSH_ASKPASS tbd ii) eval `ssh-agent -c -t 900` #I don't see a passwd option here? iii) ssh-add -x #now a password is set iv) ssh-add identity-files v) ssh-add -X #unlock - probably immediately or only after 15 minutes? Questions: 1) wouldn't step iii) lock immediately and not only after 15 minutes? 2) what do you recommend under cygwin/win2k for the SSH_ASKPASS? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 03:18:39 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 03:18:39 +1100 (EST) Subject: [Bug 480] extend the -l or -L option to mention the ssh-agent's pid Message-ID: <20030218161839.2498E64561@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=480 ------- Additional Comments From markus at openbsd.org 2003-02-19 03:18 ------- perhaps have ssh-add -v print out the socket name. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 03:48:23 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 03:48:23 +1100 (EST) Subject: [Bug 480] extend the -l or -L option to mention the ssh-agent's pid Message-ID: <20030218164823.20FB264561@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=480 ------- Additional Comments From hauser at acm.org 2003-02-19 03:48 ------- sure, would be great if this additional option could be added... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 03:49:15 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 03:49:15 +1100 (EST) Subject: [Bug 496] add a timeout function to ssh-agent Message-ID: <20030218164915.0DBA064575@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=496 ------- Additional Comments From markus at openbsd.org 2003-02-19 03:49 ------- skip (iii). agent should ask in step (ii) (v) after 15 minutes. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 03:59:29 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 03:59:29 +1100 (EST) Subject: [Bug 495] local port forwards start before authentication is complete (password auth) Message-ID: <20030218165929.044D86457C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=495 rhaig at hackboy.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From rhaig at hackboy.com 2003-02-19 03:59 ------- now I can't reproduce. I guess I also discovered cold fusion. :) If I can reproduce at a later time, I'll be sure to take the debug trace requested. wow. I feel like a user. ick. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 04:46:52 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 04:46:52 +1100 (EST) Subject: [Bug 481] Extend man page with documentation Message-ID: <20030218174652.78AD46454B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=481 hauser at acm.org changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #216 is|0 |1 obsolete| | ------- Additional Comments From hauser at acm.org 2003-02-19 04:46 ------- Created an attachment (id=231) --> (http://bugzilla.mindrot.org/attachment.cgi?id=231&action=view) enhanced patch for ssh-agent's man.cgi.html now covers (corrected) eval statements and -t passwd as per http://bugzilla.mindrot.org/show_bug.cgi?id=496 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 04:53:08 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 04:53:08 +1100 (EST) Subject: [Bug 496] add a timeout function to ssh-agent Message-ID: <20030218175308.9D8A264580@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=496 ------- Additional Comments From hauser at acm.org 2003-02-19 04:53 ------- o.k., 1) So does this mean that the description of ssh-agent -t option could be amended as follows:<< With this option, a password will be asked at start-up. Once the lifetime is reached ssh-add -X allows you to run for another "lifetime" again.>> Patch http://bugzilla.mindrot.org/attachment.cgi?id=231&action=edit in http://bugzilla.mindrot.org/show_bug.cgi?id=481 2) I am using cygwin's openssh 3.5p1-3 and couldn't test it... rhauser at PC:/<3>rhauser/Desktop> eval `ssh-agent -c -t 900` ssh-agent: unknown option -- t Usage: ssh-agent [options] [command [args ...]] Options: -c Generate C-shell commands on stdout. -s Generate Bourne shell commands on stdout. -k Kill the current agent. -d Debug mode. -a socket Bind agent socket to given name. 3) Any recommendations on SSH_ASKPASS for win2k/cygwin? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 05:31:06 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 05:31:06 +1100 (EST) Subject: [Bug 496] add a timeout function to ssh-agent Message-ID: <20030218183106.BBD506454B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=496 ------- Additional Comments From jmknoble at pobox.com 2003-02-19 05:31 ------- > Any recommendations on SSH_ASKPASS for win2k/cygwin? Have you tried x11-ssh-askpass with XFree86 on cygwin? I've not received any feedback about whether it works there or not. http://www.pobox.com/~jmknoble/software/x11-ssh-askpass/ ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 08:08:01 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 08:08:01 +1100 (EST) Subject: [Bug 496] add a timeout function to ssh-agent Message-ID: <20030218210801.93A5164508@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=496 ------- Additional Comments From hauser at acm.org 2003-02-19 08:08 ------- Thanks for the hint - I also found some source code in cygwin (http://cygwin.com/cgi-bin2/package-cat.cgi?file=openssh/openssh-3.5p1-3-src&grep=ssh-askpass), but no binary. Do you have a binary of it? So far, I hoped not to have to compile programs for cygwin myself. Further questions: 1) Is there no way to get a password into ssh-agent short of major environments such as X, Gtk, gnome and alike ? 2) anybody aware of a binary other than the japanese http://www.mail-archive.com/cygwin-xfree at cygwin.com/msg02925.html (--> http://www.ganaware.jp/S/win-ssh-askpass/) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From vinschen at redhat.com Wed Feb 19 08:58:35 2003 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 18 Feb 2003 22:58:35 +0100 Subject: progressmeter.c fails to build on Cygwin Message-ID: <20030218215834.GQ5822@cygbert.vinschen.de> Hi, I didn't had the time to build portable OpenSSH from CVS for some weeks now. I was very surprised to see that it fails to build on Cygwin. It only fails in the new progressmeter.c file which has two flaws: First of all, libgen.h and basename() don't exist on Cygwin (and probably on other systems). I already implemented this function in the bsd-cygwin_util.c file but I'd think it could make sense to put it into some other file since it's probably needed for other systems, too. Does anybody know of other systems? Otherwise I'll send a patch which defines it only for Cygwin. But especially, I don't see a reason why the good old foregroundproc() function unconditionally uses ioctl(TIOCGPGRP) now instead of testing for HAVE_TCGETPGRP as before, when the function was in scp.c. Worse, the test for tcgetpgrp has been removed from configure.ac. This definitely is a showstopper for Cygwin. I reverted the patch in my local sandbox already and it builds again. I'd like to know if I should send the patch or if it's not needed. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From bugzilla-daemon at mindrot.org Wed Feb 19 09:03:34 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 09:03:34 +1100 (EST) Subject: [Bug 497] New: Cleanup of including compatibility headers Message-ID: <20030218220334.565D864581@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=497 Summary: Cleanup of including compatibility headers Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: vinschen at redhat.com While all headers in the openbsd-compat directory are included in openbsd-compat/openbsd-compat.h, there are two exceptions from that rule: openbsd-compat/bsd-cygwin_util.h and openbsd-compat/bsd-nextstep.h are included in includes.h which also includes openbsd-compat/openbsd-compat.h so there's no need for that exception. The attached patch cleans this situation up by including the affected header files in openbsd-compat/openbsd-compat.h. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 09:05:05 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 09:05:05 +1100 (EST) Subject: [Bug 497] Cleanup of including compatibility headers Message-ID: <20030218220505.30C1E64586@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=497 ------- Additional Comments From vinschen at redhat.com 2003-02-19 09:05 ------- Created an attachment (id=232) --> (http://bugzilla.mindrot.org/attachment.cgi?id=232&action=view) openbsd header patch ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 09:08:30 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 09:08:30 +1100 (EST) Subject: [Bug 496] add a timeout function to ssh-agent Message-ID: <20030218220830.C7C1F6458D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=496 ------- Additional Comments From jmknoble at pobox.com 2003-02-19 09:08 ------- > Do you have a binary of it? No, i don't; i don't have a Cygwin environment to build or test on. > 1) Is there no way to get a password into ssh-agent short of > major environments such as X, Gtk, gnome and alike ? Yes. x11-ssh-askpass uses a fairly simple "protocol" to get the passphrase to ssh-add. From the man page: If exactly one non-option argument is provided on the command line, it is displayed in the dialog instead of the default label. If the argument contains newline characters ('\n'), each line of text is displayed on a separate line in the dialog. ssh-add uses pipe(2)+fork(2)+dup(2)+exec(3) to run the ssh-askpass program with its standard output connected back to a file descriptor in ssh-add. When the passphrase is accepted (in the case of x11-ssh-askpass, when the 'OK' button is clicked, or when [Enter] is pressed), the passphrase is printed on on the standard output, followed by a newline ('\n'). If the passphrase dialog is cancelled, ssh-askpass prints nothing (not even a newline) and exits (thus closing stdout). I don't see why you couldn't write an ssh-askpass program that, for example, started in a command window under Win32. For that matter, it's probably not that difficult for an experienced Win32 programmer (which i am not) to write a Win32-native ssh-askpass. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 09:19:43 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 09:19:43 +1100 (EST) Subject: [Bug 498] New: ssh default identity broken? Message-ID: <20030218221943.3D72264585@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=498 Summary: ssh default identity broken? Product: Portable OpenSSH Version: 3.5p1 Platform: All URL: http://www.openbsd.org/cgi-bin/man.cgi?query=ssh OS/Version: All Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: hauser at acm.org my ssh under cygwin has no ~/.ssh/identity ~/.ssh/id_?sa and as per http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config no ~/.ssh/config nor /etc/ssh/ssh_config but for some odd reason, it goes to /rsync/.ssh/identity ??? (since I placed an identity file there without a password, before using -vvv, it was hard to find it...) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 09:29:19 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 09:29:19 +1100 (EST) Subject: [Bug 497] Cleanup of including compatibility headers Message-ID: <20030218222919.2D55564596@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=497 ------- Additional Comments From mouring at eviladmin.org 2003-02-19 09:29 ------- I don't know about Cygwin, but I originally put the NeXT stuff in that spot for a reason. Unless you have a NeXT 3.3 and 4.2 machines to verify that this patch does not further break that platform. I don't want it undone. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 18:49:18 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 18:49:18 +1100 (EST) Subject: [Bug 498] ssh default identity broken? Message-ID: <20030219074918.A72F264508@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=498 ------- Additional Comments From vinschen at redhat.com 2003-02-19 18:49 ------- Apparently you didn't read /usr/doc/Cygwin/openssh-3.5p1.README. Run ssh-host-config to create the host configuration files and keys and run ssh-user-config to create your personal keys in ~/.ssh. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 18:53:35 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 18:53:35 +1100 (EST) Subject: [Bug 497] Cleanup of including compatibility headers Message-ID: <20030219075335.64CE664534@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=497 ------- Additional Comments From vinschen at redhat.com 2003-02-19 18:53 ------- In that case it makes sense to move the Cygwin bit to the correct place at least. I don't have a Next box (never seen any) so I can't test that. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 19:10:58 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 19:10:58 +1100 (EST) Subject: [Bug 499] New: progressmeter.c doesn't build (at least) on Cygwin Message-ID: <20030219081058.345966451E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=499 Summary: progressmeter.c doesn't build (at least) on Cygwin Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Cygwin on NT/2k Status: NEW Severity: critical Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: vinschen at redhat.com Three bugs: - libgen.h doesn't exist on all platforms. - basename() doesn't exist on all platforms. - ioctl(TIOCGPGRP) doesn't exist on all platforms. This is a reintroduced problem since there was another method used on other platforms (calling tcgetpgrp()) when that code was still in scp.c The attached patch solves all three problems, the basename() problem only for Cygwin, the other problems generally by adding tests for libgen.h and tcgetpgrp() to configure.ac. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 19:13:09 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 19:13:09 +1100 (EST) Subject: [Bug 499] progressmeter.c doesn't build (at least) on Cygwin Message-ID: <20030219081309.A22B264542@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=499 ------- Additional Comments From vinschen at redhat.com 2003-02-19 19:13 ------- Created an attachment (id=233) --> (http://bugzilla.mindrot.org/attachment.cgi?id=233&action=view) Solves the progressmeter.c build problems ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 21:42:06 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 21:42:06 +1100 (EST) Subject: [Bug 498] ssh default identity broken? Message-ID: <20030219104206.D181164534@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=498 hauser at acm.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vinschen at redhat.com ------- Additional Comments From hauser at acm.org 2003-02-19 21:42 ------- O.K, I did it: <Man/cat1> ssh-user-config Configuration finished. Have fun!>> I thought I would now be asked something (why would I be able to specify a "-y" or "-n" option otherwise anyway? Conclusion, it still doesn't give a clue from which directory it did what... ====> Suggestion: add a "-v" option that tells in an end-user-intelligible way what happens. (sure, there is the "-d" option that eventually utters "+ [ ! -f /rsync/.ssh/identity ]" - but this appears to be development-team-internal...) P.S.: Especially when clicking on wincvs, it is not that obvious to find out why this happens ... see https://sourceforge.net/tracker/?func=detail&aid=689081&group_id=10072&atid=110072 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 21:54:18 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 21:54:18 +1100 (EST) Subject: [Bug 498] ssh default identity broken? Message-ID: <20030219105418.654A364547@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=498 ------- Additional Comments From vinschen at redhat.com 2003-02-19 21:54 ------- As I told you on the cygwin ML, check your home dir in /etc/passwd. Your description points to /rsync being set as your home dir in /etc/passwd. If you'd look into the ssh-user-config script you'd find that it uses your home dir from /etc/passwd same as ssh does. It does especially *NOT* use the value of $HOME, same as ssh. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Feb 19 22:46:10 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Feb 2003 22:46:10 +1100 (EST) Subject: [Bug 498] make ssh default identity configuration more user-friendly in cygwin Message-ID: <20030219114610.ACE8D64537@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=498 hauser at acm.org changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement Summary|ssh default identity broken?|make ssh default identity | |configuration more user- | |friendly in cygwin ------- Additional Comments From hauser at acm.org 2003-02-19 22:46 ------- Thx for the additional explanation. I change the title and now classify it as an enhancement request for an intelligible "-v". If this ssh-user-config business really only applies to cygwin, I would appreciate a pointer to a bug-tracking system of them in order to close it here and open it there. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Feb 20 00:08:19 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 20 Feb 2003 00:08:19 +1100 (EST) Subject: [Bug 481] Extend man page with documentation Message-ID: <20030219130819.B29F464567@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=481 ------- Additional Comments From markus at openbsd.org 2003-02-20 00:08 ------- please don't send patches for the html page, use the troff source instead. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Feb 20 00:33:42 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 20 Feb 2003 00:33:42 +1100 (EST) Subject: [Bug 481] Extend man page with documentation Message-ID: <20030219133342.0DE4F64596@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=481 ------- Additional Comments From hauser at acm.org 2003-02-20 00:33 ------- Sure, where could I easiest get it? http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh-agent/ wasn't it, http://www.openbsd.org/cgi-bin/cvsweb/www/openssh/ didn't look like it either, http://www.openbsd.org/cgi-bin/cvsweb/src/share/man/man1 neither... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Feb 20 00:37:09 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 20 Feb 2003 00:37:09 +1100 (EST) Subject: [Bug 500] New: show how to start-up ssh-agent by default... Message-ID: <20030219133709.BFF0A645AE@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=500 Summary: show how to start-up ssh-agent by default... Product: Portable OpenSSH Version: 3.5p1 Platform: All URL: http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-agent OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Documentation AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: hauser at acm.org An experienced user recommends to me: <> A hint to something similar like this in the manual probably wouldn't reduce ssh-agent adoption... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jdennis at law.harvard.edu Thu Feb 20 02:22:37 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Wed, 19 Feb 2003 10:22:37 -0500 Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: <20030215165317.GK5822@cygbert.vinschen.de> References: <03Feb14.173123edt.453195-13279@jane.cs.toronto.edu> <20030215165317.GK5822@cygbert.vinschen.de> Message-ID: <3E53A13D.2030500@law.harvard.edu> Hmm... I could've sworn OpenSSH was for Unix and ran under NT only in cygwin. Does it matter what NT is setup to do then? I suppose superuser could be system-dependent, but I think Ben is right. If you have multiple accounts with uid 0, you haven't set your system up correctly. > Ben, you *know* that's not exactly true. On NT there's a superuser > group ("Administrators" on english versions) and there's an arbitrary > number of accounts which could be members of that group. Even this > description doesn't completely cover the complexity of possible rules > used in NT systems and regardless of my own opinion, this is *fact*. > I don't think it's the correct way to deal with this by ignoring it. > > That's the reason I already asked at least twice for changing all > > if uid == 0 > > or similar to > > if is_root(uid) > > with is_superuser being system-dependent. > > Corinna > -James From vinschen at redhat.com Thu Feb 20 03:55:19 2003 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 19 Feb 2003 17:55:19 +0100 Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: <3E53A13D.2030500@law.harvard.edu> References: <03Feb14.173123edt.453195-13279@jane.cs.toronto.edu> <20030215165317.GK5822@cygbert.vinschen.de> <3E53A13D.2030500@law.harvard.edu> Message-ID: <20030219165519.GF12883@cygbert.vinschen.de> On Wed, Feb 19, 2003 at 10:22:37AM -0500, James Dennis wrote: > Hmm... > > I could've sworn OpenSSH was for Unix and ran under NT only in cygwin. > Does it matter what NT is setup to do then? I suppose superuser could be The point is not the uid 0. There isn't anything like uid 0 in a NT system. Cygwin is just a POSIXy environment on top of NT so we depend on the underlying OS. We can't change it, just use it's capabilities. > system-dependent, but I think Ben is right. If you have multiple > accounts with uid 0, you haven't set your system up correctly. The problem is that OpenSSH depends on uid 0 being *the* superuser. There are systems out there which don't have uid 0 being the one superuser but support several uids as being part of a superuser group. All I'm trying to say, it is system dependent but there's no support for that in OpenSSH. What I'm missing is something like an official statement. I'm willing to provide the necessary patches to OpenSSH to support a is_root() or is_superuser() call which would substitute any comparison of the uid with the fixed value 0. But I won't do that if there's no chance to get the fixes applied. AFAIK there isn't only Cygwin. Newer Solaris supports a similar concept, isn't it? Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From aplumb at westpac.com.au Thu Feb 20 09:15:35 2003 From: aplumb at westpac.com.au (aplumb at westpac.com.au) Date: Thu, 20 Feb 2003 09:15:35 +1100 Subject: newbie wants to compile SCP into his own application Message-ID: Hi all, I have seen in the OpenSSH source that the scp executable is built by compiling scp.c and linking with libopenbsd-compat.a and libssh.a. (Correct me here if I'm wrong) My question is, can I make this a module in my own application by using the scp.c source and ilnking the libraries mentioned above ? The reason is, I want to perform an SCP from my application, but I don't want to execute the external command line utility "scp". I want to be able to get a return value to indicate success or failure and handle this in my app. Thanks, Andrew Plumb. From dtucker at zip.com.au Thu Feb 20 09:45:55 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 20 Feb 2003 09:45:55 +1100 Subject: newbie wants to compile SCP into his own application References: Message-ID: <3E540923.5F676036@zip.com.au> aplumb at westpac.com.au wrote: > My question is, can I make this a module in my own application by using the > scp.c source and ilnking the libraries mentioned above ? The reason is, I > want to perform an SCP from my application, but I don't want to execute the > external command line utility "scp". I want to be able to get a return > value to indicate success or failure and handle this in my app. Probably, but it's likely to be much easier (and less maintenance too) to just fork/exec scp then wait() for completion and check the return code. Is determining success/failure the only reason you want to embed the code? I've got some example code that might serve as a starting point if you want it. -Daz. $ scp localhost:/bin/ls /tmp/ls $ echo $? 0 $ scp localhost:/no/such /tmp/ls scp: /no/such: No such file or directory $ echo $? 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 mouring at etoh.eviladmin.org Thu Feb 20 10:07:34 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 19 Feb 2003 17:07:34 -0600 (CST) Subject: newbie wants to compile SCP into his own application In-Reply-To: Message-ID: First off I suggest you look at sftp rather than scp. There are less integration issues and I believe you'll be more happy with the results. Second, you just can just add scp.c and libopenbsd-compat.a into your code and think you don't have nay more external dependances. Just keep in mind scp forks to call ssh (same is true with sftp). But in general, sftp code is much friendlier for integrating since it was designed for that reason. scp (for how wonderful it is) is really a hack on a hack on a hack.=) - Ben On Thu, 20 Feb 2003 aplumb at westpac.com.au wrote: > Hi all, > > I have seen in the OpenSSH source that the scp executable is built by > compiling scp.c and linking with libopenbsd-compat.a and libssh.a. (Correct > me here if I'm wrong) > > My question is, can I make this a module in my own application by using the > scp.c source and ilnking the libraries mentioned above ? The reason is, I > want to perform an SCP from my application, but I don't want to execute the > external command line utility "scp". I want to be able to get a return > value to indicate success or failure and handle this in my app. > > Thanks, > > Andrew Plumb. > > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From Frank.Beckmann at vodafone.com Thu Feb 20 19:48:00 2003 From: Frank.Beckmann at vodafone.com (Frank Beckmann) Date: Thu, 20 Feb 2003 09:48:00 +0100 Subject: SSH Bug 3.5p1 Expired Passwords In-Reply-To: <3DAD72E2.A237A41F@zip.com.au> References: <3DAD6781.40808@vodafone.com> <3DAD72E2.A237A41F@zip.com.au> Message-ID: <3E549640.9030705@vodafone.com> Hi :-) is this Problem Fix in a new Snapshot Version of Openssh ? The Fix has only run under Protokoll 1 not under Protokoll 2 :-( Greetings from Germany Frank Beckmann Darren Tucker wrote: > Frank Beckmann wrote: > >>in the new Openssh 3.5p1 is the sam Bug as in the 3.4p1 :-( >>When a User try to login with a expired Passwort, SSH denys the Acces to the System > > > In pam-auth.c, change > > #if 0 > case PAM_NEW_AUTHTOK_REQD: > > to > > #if 1 > case PAM_NEW_AUTHTOK_REQD: > > and set "UsePrivilegeSeparation no" in sshd_config. > > People have reported mixed success, so your milage may vary. > > Let the list know how it goes; one of the reasons this isn't enabled in > 3.5p1 is lack of testing. > -- Frank Beckmann Abt. TOIU Tel: 0211 533-5758 Fax: 0211 533-1451 Mail Frank.Beckmann at vodafone.com From dtucker at zip.com.au Thu Feb 20 20:43:45 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 20 Feb 2003 20:43:45 +1100 Subject: SSH Bug 3.5p1 Expired Passwords References: <3DAD6781.40808@vodafone.com> <3DAD72E2.A237A41F@zip.com.au> <3E549640.9030705@vodafone.com> Message-ID: <3E54A351.DBB0ED51@zip.com.au> Frank Beckmann wrote: > is this Problem Fix in a new Snapshot Version of Openssh ? > The Fix has only run under Protokoll 1 not under Protokoll 2 :-( [snip] > > #if 1 > > case PAM_NEW_AUTHTOK_REQD: No, to my knowledge there is no fix for this problem is in the current tree. You have a couple of new options, though. 1) Using PAM. This patch: http://bugzilla.mindrot.org/attachment.cgi?id=198&action=view (attached to this bug: http://bugzilla.mindrot.org/show_bug.cgi?id=423) will (should) allow PAM NEW_AUTHTOK_REQD to work with and without privsep. Althought it seems to work, this will probably never make it into the main tree because a) it makes a privsep call from the shell child process and b) Damien has been threatening to replace the existing PAM module. 2) Without PAM This patch http://www.zip.com.au/~dtucker/openssh/openssh-3.5p1-passexpire16.patch (more info: http://www.zip.com.au/~dtucker/openssh/ and http://bugzilla.mindrot.org/show_bug.cgi?id=14) will enable password expiration without PAM on AIX, Solaris and a few others. I'm hoping that this or something like it will make it to the main tree but there seems to be a lack of interest at the moment. The various patches have been downloaded from my page just under a thousand times. I've been able to resolve the half-dozen or so problems people have emailed me with, so it's probably working for some people (and, I note, IBM are now shipping AIX packages that do password expiry; I don't know if they're based on these). So how about, people? What needs to be done to it? -- 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 bugzilla-daemon at mindrot.org Thu Feb 20 20:51:19 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 20 Feb 2003 20:51:19 +1100 (EST) Subject: [Bug 14] Can't change expired /etc/shadow password without PAM Message-ID: <20030220095119.4EFBD645A5@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=14 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #215 is|0 |1 obsolete| | ------- Additional Comments From dtucker at zip.com.au 2003-02-20 20:51 ------- Created an attachment (id=234) --> (http://bugzilla.mindrot.org/attachment.cgi?id=234&action=view) passexpire16: AIX & /etc/shadow password expiry Equivalent patch against 3.5p1 at http://www.zip.com.au/~dtucker/openssh/openssh-3.5p1-passexpire16.patch. Eliminates double call of generate_login_message() when authentication is postponed. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From nampilaj at telecom.na Thu Feb 20 23:14:50 2003 From: nampilaj at telecom.na (Nampila Jacobina) Date: Thu, 20 Feb 2003 14:14:50 +0200 Subject: download OpenSSH Message-ID: Dear Sir or Madam I would like to download OpenSSH for our HP Unix server, where can I download it from OpenSSH website? Hope to hear from you soon. JM Nampila Ass. System Administrator Technology Telecom Namibia Tel: +264-61-2012812 Cell: +264811-222584 Fax: +26461-239412 *************************************************************************** The information contained in this e-mail is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not use, copy, distribute or disclose the e-mail or any part of its contents or take any action in reliance on it. If you have received this e-mail in error, please e-mail the sender by replying to this message. All reasonable precautions have been taken to ensure no viruses are present in this e-mail and the sender cannot accept responsibility for loss or damage arising from the use of this e-mail or attachments. *************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030220/d6abc3ed/attachment.html From maniac at maniac.nl Thu Feb 20 23:36:41 2003 From: maniac at maniac.nl (Mark Janssen) Date: 20 Feb 2003 13:36:41 +0100 Subject: download OpenSSH In-Reply-To: References: Message-ID: <1045744601.5975.35.camel@ninja> On Thu, 2003-02-20 at 13:14, Nampila Jacobina wrote: > I would like to download OpenSSH for our HP Unix server, where can I > download it from OpenSSH website? www.openssh.com click on 'HPUX', select a mirror, download... ftp://sunsite.dk/mirrors/openssh/portable/openssh-3.5p1.tar.gz -- Mark Janssen -- maniac(at)maniac.nl -- GnuPG Key Id: 357D2178 Unix / Linux, Open-Source and Internet Consultant @ SyConOS IT Maniac.nl Unix-God.Net|Org MarkJanssen.org|nl SyConOS.com|nl From john at surfutopia.net Fri Feb 21 03:18:37 2003 From: john at surfutopia.net (John Mendenhall) Date: Thu, 20 Feb 2003 08:18:37 -0800 Subject: OpenSSH_3.5p1 server, PC clients cannot connect Message-ID: <20030220161837.GA4764@calvin.surfutopia.net> I have setup an OpenSSH_3.5p1 ssh/sftp server on my SunOS 4.1.4 box. I can ssh to it just fine. The problem is SFTP from certain clients. I can SFTP to it using my OpenSSH_3.5p1 sftp client. I can SFTP to it from MacSFTP from MacSSH.org, version 1.0.5. However, I have several clients that cannot connect. I have had them try CuteFTP Pro v2, v3, WS_FTP Pro v7.62, PuTTy pSFTP. None are able to connect. WS_FTP Pro gives the error: Failed SSH Key Exchange PuTTy gives the error message: Fatal: unable to initialise SFTP: could not connect CuteFTP just seems to hang there. I have turned on DEBUG logging and they each appear to stop at different places. I did some searching and increased the Login time from 2 minutes to 5 minutes. No change. I turned off PrivSep. No apparent change. Compression is still on. I run the daemon with '-u0' to stop DNS lookups. I have included my config file below my signature. Does anyone have any idea what I could be doing wrong? I would really like this to work for my PC/Win clients. Please let me know if you need any additional information to diagnose these clients. Thank you very much in advance. JohnM -- John Mendenhall john at surfutopia.net surf utopia internet services ----- sshd_config ----- # $OpenBSD: sshd_config,v 1.59 2002/09/25 11:17:16 markus Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. #Port 22 #Protocol 2,1 Protocol 2 #ListenAddress 0.0.0.0 #ListenAddress :: # HostKey for protocol version 1 HostKey /usr/local/etc/ssh_host_key # HostKeys for protocol version 2 HostKey /usr/local/etc/ssh_host_rsa_key HostKey /usr/local/etc/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 3600 #ServerKeyBits 768 # Logging #obsoletes QuietMode and FascistLogging SyslogFacility AUTH #LogLevel INFO LogLevel DEBUG # Authentication: #LoginGraceTime 120 LoginGraceTime 300 #PermitRootLogin yes PermitRootLogin no #StrictModes yes #RSAAuthentication yes #RSAAuthentication no #PubkeyAuthentication yes #AuthorizedKeysFile .ssh/authorized_keys # rhosts authentication should not be used #RhostsAuthentication no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #AFSTokenPassing no # Kerberos TGT Passing only works with the AFS kaserver #KerberosTgtPassing no # Set this to 'yes' to enable PAM keyboard-interactive authentication # Warning: enabling this may bypass the setting of 'PasswordAuthentication' #PAMAuthenticationViaKbdInt no #X11Forwarding no #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #KeepAlive yes #UseLogin no # 20030219 jem turned off Privilege Separation for Putty pSFTP to work #UsePrivilegeSeparation yes UsePrivilegeSeparation no PermitUserEnvironment no #Compression yes #MaxStartups 10 # no default banner path #Banner /some/path #VerifyReverseMapping no # override default of no subsystems Subsystem sftp /usr/local/libexec/sftp-server From italo.migotto at proteus.com.br Fri Feb 21 04:00:19 2003 From: italo.migotto at proteus.com.br (Italo Antonio) Date: Thu, 20 Feb 2003 17:00:19 +0000 Subject: "if 0" in auth-pam.c Message-ID: <3E5509A3.2040401@proteus.com.br> Hi, I was doing some research on why new openssh-versions (3.4 and 3.5p1) doesnt ask you to change expired passwords (it just disconnects you) and found something curious. Line 259 of auth-pam.c has "#if 0" and then the code to set some vars (eg. password_change_required to true) followed by an "endif". Why is that? I'm not a C expert, but I think "if 0" is a non-possible situation, right? I then removed these conditions, and it worked just fine, changed my password as it should.. btw, yes, I removed "Privilege Separation" to do these tests. Here is the piece of code I'm talking about: switch (pam_retval) { case PAM_SUCCESS: /* This is what we want */ break; #if 0 case PAM_NEW_AUTHTOK_REQD: message_cat(&__pam_msg, use_privsep ? NEW_AUTHTOK_MSG_PRIVSEP : NEW_AUTHTOK_MSG); /* flag that password change is necessary */ password_change_required = 1; /* disallow other functionality for now */ no_port_forwarding_flag |= 2; no_agent_forwarding_flag |= 2; no_x11_forwarding_flag |= 2; break; #endif default: log("PAM rejected by account configuration[%d]: " "%.200s", pam_retval, PAM_STRERROR(__pamh, pam_retval)); return(0); } From bugzilla-daemon at mindrot.org Fri Feb 21 08:35:39 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 21 Feb 2003 08:35:39 +1100 (EST) Subject: [Bug 496] add a timeout function to ssh-agent Message-ID: <20030220213539.96ECA64516@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=496 ------- Additional Comments From hauser at acm.org 2003-02-21 08:35 ------- BTW, the japanes binaries are here http://matsu-www.is.titech.ac.jp/~sohda/cygwin/dist/packages/win-ssh-askpass/ And as per http://bugzilla.mindrot.org/show_bug.cgi?id=496#c4, cygwin apparently doesn't offer the -t option yet (see http://sources.redhat.com/ml/cygwin/2003-02/msg01491.html). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Darren.Moffat at Sun.COM Fri Feb 21 09:03:09 2003 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Thu, 20 Feb 2003 14:03:09 -0800 (PST) Subject: ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups)) In-Reply-To: <20030219165519.GF12883@cygbert.vinschen.de> Message-ID: On Wed, 19 Feb 2003, Corinna Vinschen wrote: > AFAIK there isn't only Cygwin. Newer Solaris supports a similar > concept, isn't it? I'm not very familiar with how the groups of admins concept works in NT. Solaris 8 (and Trusted Solaris all versions) have the concept of roles [described in rbac(5) for those with access to Solaris or those that care to look on http://docs.sun.com]. A role is an account that can not be logged into directly and may have elevated priveleges or restricted priveleges (including limiting it to a fixed set of programs that it can exec). Roles are assigned to Real users. You can not use sshd to get access to a role (the call to pam_acct_mgmt() enforces this during the processing of pam_roles.so)), you must use su(1) to "become" the role. It is possible to make the root account a role, this means that only users who have the password and have been assigned the role can use su(1) to become root. It also ensures that root can not login directly. Additional priveleges and authorisations can also be given directly to individulal users. However non of this changes the uid == 0 being all powerful in the kernel for Solaris 8 or 9. Trusted Solaris has fine grained privelge instead of uid == 0 checks in the kernel. -- Darren J Moffat From list_tom at yahoo.com Fri Feb 21 15:24:23 2003 From: list_tom at yahoo.com (Peter Richard) Date: Thu, 20 Feb 2003 20:24:23 -0800 (PST) Subject: SCP Log Info Message-ID: <20030221042423.14879.qmail@web13002.mail.yahoo.com> HI Everyone Iam a newbie to ssh and looking for a basic information on it.Some of the queries are:- 1)How can i get the maximum information of ssh daemon in the syslog file? 2)If i use scp for secure remote copying then in the syslog i see that the information in the syslog comes like this "Feb 20 10:24:27 sshd[15425]: Accepted password for sumit from 172.22.13.85 port 1374 ssh2" Now when i check the scp code i found that they use scp as a wrapper for ssh to copy files and inturn uses ssh commands only so it logs the information as ssh only. Is there any way by which i can exclusively check that on my ssh server that scp is used from the log info. Kindly help me out? Regrds Peter --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030220/3daf1c00/attachment.html From gnu_is_not_unix at wp.pl Sat Feb 22 00:35:58 2003 From: gnu_is_not_unix at wp.pl (gnu_is_not_unix at wp.pl) Date: Fri, 21 Feb 2003 14:35:58 +0100 Subject: openssh 3.5p1 with openssl-0.9.7a - long Message-ID: <3e562b3e5792b@wp.pl> Hi ! This is my first posting so HELLO to everybody ! I`m trying to install openssh 3.5 with newest version of openssl 0.9.7a on rh - i`m building rpms from spec included in openssl and openssh dist. All compilations went well, sshd, ssh is working but ... i can`t scp: [root at beer /root]# scp a.out root at dns:/root/ root at dns's password: scp: error while loading shared libraries: libcrypto.so.0.9.6: cannot open shared object file: No such file or directory lost connection [root at beer /root]# strace scp a.out root at dns:/root/ execve("/usr/bin/scp", ["scp", "a.out", "root at dns:/root/"], [/* 30 vars */]) = 0 uname({sys="Linux", node="beer", ...}) = 0 brk(0) = 0x804f74c open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=55610, ...}) = 0 old_mmap(NULL, 55610, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000 close(3) = 0 open("/lib/libresolv.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\'\0"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=261734, ...}) = 0 old_mmap(NULL, 71236, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40025000 mprotect(0x40033000, 13892, PROT_NONE) = 0 old_mmap(0x40033000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xd000) = 0x40033000 old_mmap(0x40034000, 9796, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40034000 close(3) = 0 open("/lib/libutil.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\r\0"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=47632, ...}) = 0 old_mmap(NULL, 10936, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40037000 mprotect(0x40039000, 2744, PROT_NONE) = 0 old_mmap(0x40039000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x40039000 close(3) = 0 open("/usr/lib/libz.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\30"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=61092, ...}) = 0 old_mmap(NULL, 56504, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4003a000 mprotect(0x40046000, 7352, PROT_NONE) = 0 old_mmap(0x40046000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xb000) = 0x40046000 close(3) = 0 open("/lib/libnsl.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200?\0"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=448433, ...}) = 0 old_mmap(NULL, 92000, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40048000 mprotect(0x4005b000, 14176, PROT_NONE) = 0 old_mmap(0x4005b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x12000) = 0x4005b000 old_mmap(0x4005d000, 5984, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4005d000 close(3) = 0 open("/usr/lib/libcrypto.so.0.9.7", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\277\2"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=1195382, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4005f000 old_mmap(NULL, 1019256, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40060000 mprotect(0x40144000, 85368, PROT_NONE) = 0 old_mmap(0x40144000, 73728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xe3000) = 0x40144000 old_mmap(0x40156000, 11640, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40156000 close(3) = 0 open("/usr/kerberos/lib/libkrb5.so.3", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\360"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=426149, ...}) = 0 old_mmap(NULL, 358176, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40159000 mprotect(0x401ae000, 10016, PROT_NONE) = 0 old_mmap(0x401ae000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x54000) = 0x401ae000 close(3) = 0 open("/usr/kerberos/lib/libk5crypto.so.3", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360 \0"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=78637, ...}) = 0 old_mmap(NULL, 68148, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x401b1000 mprotect(0x401c0000, 6708, PROT_NONE) = 0 old_mmap(0x401c0000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xe000) = 0x401c0000 close(3) = 0 open("/usr/kerberos/lib/libcom_err.so.3", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\t\0\000"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=8637, ...}) = 0 old_mmap(NULL, 8584, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x401c2000 mprotect(0x401c3000, 4488, PROT_NONE) = 0 old_mmap(0x401c3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x401c3000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\304\1"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=5723895, ...}) = 0 old_mmap(NULL, 1269096, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x401c5000 mprotect(0x402f2000, 36200, PROT_NONE) = 0 old_mmap(0x402f2000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x12c000) = 0x402f2000 old_mmap(0x402f7000, 15720, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x402f7000 close(3) = 0 open("/lib/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\35"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=65457, ...}) = 0 old_mmap(NULL, 12516, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x402fb000 mprotect(0x402fd000, 4324, PROT_NONE) = 0 old_mmap(0x402fd000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x402fd000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x402ff000 munmap(0x40017000, 55610) = 0 brk(0) = 0x804f74c brk(0x804f7e4) = 0x804f7e4 brk(0x8050000) = 0x8050000 getuid32() = 0 socket(PF_UNIX, SOCK_STREAM, 0) = 3 connect(3, {sin_family=AF_UNIX, path=" /var/run/.nscd_socket"}, 110) = -1 ENOENT (No such file or directory) close(3) = 0 open("/etc/nsswitch.conf", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=1782, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1782 brk(0x8051000) = 0x8051000 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40017000, 4096) = 0 0xbffff15f, 1) = ? ERESTARTSYS (To be restarted) --- SIGWINCH (Window changed) --- st_size=55610, ...}) = 0 read(7, (NULL, 55610, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000 close(3) = 0 open("/lib/libnss_files.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20!\0\000"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=256723, ...}) = 0 old_mmap(NULL, 41636, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40300000 mprotect(0x40309000, 4772, PROT_NONE) = 0 old_mmap(0x40309000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x8000) = 0x40309000 close(3) = 0 munmap(0x40017000, 55610) = 0 open("/etc/passwd", O_RDONLY) = 3 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=1899, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1899 close(3) = 0 munmap(0x40017000, 4096) = 0 (END) rt_sigaction(SIGPIPE, {0x804b8e0, [PIPE], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 pipe([3, 4]) = 0 pipe([5, 6]) = 0 pipe([7, 8]) = 0 close(3) = 0 close(4) = 0 fork() = 2219 close(5) = 0 close(8) = 0 read(7, root at dns's password: scp: error while loading shared libraries: libcrypto.so.0.9.6: cannot open shared object file: No such file or directory 0xbffff15f, 1) = ? ERESTARTSYS (To be restarted) --- SIGCHLD (Child exited) --- read(7, "", 1) = 0 write(2, "lost connection\n", 16lost connection ) = 16 _exit(1) = ? ---------------------------------------------------------------- Najwi?ksze Gwiazdy ?piewaj? piosenki aktorskie < www.ppa.wp.pl > From maniac at maniac.nl Sat Feb 22 01:03:06 2003 From: maniac at maniac.nl (Mark Janssen) Date: 21 Feb 2003 15:03:06 +0100 Subject: openssh 3.5p1 with openssl-0.9.7a In-Reply-To: <3e562b3e5792b@wp.pl> References: <3e562b3e5792b@wp.pl> Message-ID: <1045836185.879.7.camel@ninja> On Fri, 2003-02-21 at 14:35, gnu_is_not_unix at wp.pl wrote: [snip] > working but ... i can`t scp: > [root at beer /root]# scp a.out root at dns:/root/ > scp: error while loading shared libraries: libcrypto.so.0.9.6: > cannot open shared object file: No such file or directory I'd say your scp binary on the 'beer' system was linked to openssl 0.9.6, which it cannot find anymore. Either try symlinking /usr/lib/libcrypto.so.0.9.7 to libcrypto.so.0.9.6 and run ldconfig, or install a new version of scp (linked against 0.9.7a, and corresponding ssl libraries) on the system. -- Mark Janssen -- maniac(at)maniac.nl -- GnuPG Key Id: 357D2178 Unix / Linux, Open-Source and Internet Consultant @ SyConOS IT Maniac.nl Unix-God.Net|Org MarkJanssen.org|nl SyConOS.com|nl From mouring at etoh.eviladmin.org Sat Feb 22 01:27:37 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 21 Feb 2003 08:27:37 -0600 (CST) Subject: openssh 3.5p1 with openssl-0.9.7a - long In-Reply-To: <3e562b3e5792b@wp.pl> Message-ID: This is an issue with the scp on your remote side unable to find the library which is needs. You more than likely installed openssl 0.9.6 in a non-standard location and you need to update your /etc/ld.conf or similar concept on that remote machine. - Ben On Fri, 21 Feb 2003, gnu_is_not_unix at wp.pl wrote: > Hi ! > > > > > This is my first posting so HELLO to everybody ! > > > > > I`m trying to install openssh 3.5 with newest version of openssl > 0.9.7a on rh - i`m building rpms from spec included in openssl > and openssh dist. All compilations went well, sshd, ssh is > working but ... i can`t scp: > > > > > [root at beer /root]# scp a.out root at dns:/root/ > > > root at dns's password: > > > scp: error while loading shared libraries: libcrypto.so.0.9.6: > cannot open shared object file: No such file or directory > > > lost connection > > > > > [root at beer /root]# strace scp a.out root at dns:/root/ > > > execve("/usr/bin/scp", ["scp", "a.out", "root at dns:/root/"], [/* > 30 vars */]) = 0 > > > uname({sys="Linux", node="beer", ...}) = 0 > > > brk(0) = 0x804f74c > > > open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file > or directory) > > > open("/etc/ld.so.cache", O_RDONLY) = 3 > > > fstat64(3, {st_mode=S_IFREG|0644, st_size=55610, ...}) = 0 > > > old_mmap(NULL, 55610, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000 > > > close(3) = 0 > > > open("/lib/libresolv.so.2", O_RDONLY) = 3 > > > read(3, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\'\0"..., > 1024) = 1024 > > > fstat64(3, {st_mode=S_IFREG|0755, st_size=261734, ...}) = 0 > > > old_mmap(NULL, 71236, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = > 0x40025000 > > > mprotect(0x40033000, 13892, PROT_NONE) = 0 > > > old_mmap(0x40033000, 4096, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED, 3, 0xd000) = 0x40033000 > > > old_mmap(0x40034000, 9796, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40034000 > > > close(3) = 0 > > > open("/lib/libutil.so.1", O_RDONLY) = 3 > > > read(3, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\r\0"..., > 1024) = 1024 > > > fstat64(3, {st_mode=S_IFREG|0755, st_size=47632, ...}) = 0 > > > old_mmap(NULL, 10936, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = > 0x40037000 > > > mprotect(0x40039000, 2744, PROT_NONE) = 0 > > > old_mmap(0x40039000, 4096, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x40039000 > > > close(3) = 0 > > > open("/usr/lib/libz.so.1", O_RDONLY) = 3 > > > read(3, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\30"..., > 1024) = 1024 > > > fstat64(3, {st_mode=S_IFREG|0755, st_size=61092, ...}) = 0 > > > old_mmap(NULL, 56504, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = > 0x4003a000 > > > mprotect(0x40046000, 7352, PROT_NONE) = 0 > > > old_mmap(0x40046000, 8192, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED, 3, 0xb000) = 0x40046000 > > > close(3) = 0 > > > open("/lib/libnsl.so.1", O_RDONLY) = 3 > > > read(3, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200?\0"..., > 1024) = 1024 > > > fstat64(3, {st_mode=S_IFREG|0755, st_size=448433, ...}) = 0 > > > old_mmap(NULL, 92000, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = > 0x40048000 > > > mprotect(0x4005b000, 14176, PROT_NONE) = 0 > > > old_mmap(0x4005b000, 8192, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED, 3, 0x12000) = 0x4005b000 > > > old_mmap(0x4005d000, 5984, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4005d000 > > > close(3) = 0 > > > open("/usr/lib/libcrypto.so.0.9.7", O_RDONLY) = 3 > > > read(3, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\277\2"..., > 1024) = 1024 > > > fstat64(3, {st_mode=S_IFREG|0755, st_size=1195382, ...}) = 0 > > > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4005f000 > > > old_mmap(NULL, 1019256, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = > 0x40060000 > > > mprotect(0x40144000, 85368, PROT_NONE) = 0 > > > old_mmap(0x40144000, 73728, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED, 3, 0xe3000) = 0x40144000 > > > old_mmap(0x40156000, 11640, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40156000 > > > close(3) = 0 > > > open("/usr/kerberos/lib/libkrb5.so.3", O_RDONLY) = 3 > > > read(3, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\360"..., > 1024) = 1024 > > > fstat64(3, {st_mode=S_IFREG|0755, st_size=426149, ...}) = 0 > > > old_mmap(NULL, 358176, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = > 0x40159000 > > > mprotect(0x401ae000, 10016, PROT_NONE) = 0 > > > old_mmap(0x401ae000, 12288, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED, 3, 0x54000) = 0x401ae000 > > > close(3) = 0 > > > open("/usr/kerberos/lib/libk5crypto.so.3", O_RDONLY) = 3 > > > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360 > \0"..., 1024) = 1024 > > > fstat64(3, {st_mode=S_IFREG|0755, st_size=78637, ...}) = 0 > > > old_mmap(NULL, 68148, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = > 0x401b1000 > > > mprotect(0x401c0000, 6708, PROT_NONE) = 0 > > > old_mmap(0x401c0000, 8192, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED, 3, 0xe000) = 0x401c0000 > > > close(3) = 0 > > > open("/usr/kerberos/lib/libcom_err.so.3", O_RDONLY) = 3 > > > read(3, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\t\0\000"..., > 1024) = 1024 > > > fstat64(3, {st_mode=S_IFREG|0755, st_size=8637, ...}) = 0 > > > old_mmap(NULL, 8584, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = > 0x401c2000 > > > mprotect(0x401c3000, 4488, PROT_NONE) = 0 > > > old_mmap(0x401c3000, 8192, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x401c3000 > > > close(3) = 0 > > > open("/lib/libc.so.6", O_RDONLY) = 3 > > > read(3, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\304\1"..., > 1024) = 1024 > > > fstat64(3, {st_mode=S_IFREG|0755, st_size=5723895, ...}) = 0 > > > old_mmap(NULL, 1269096, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = > 0x401c5000 > > > mprotect(0x402f2000, 36200, PROT_NONE) = 0 > > > old_mmap(0x402f2000, 20480, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED, 3, 0x12c000) = 0x402f2000 > > > old_mmap(0x402f7000, 15720, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x402f7000 > > > close(3) = 0 > > > open("/lib/libdl.so.2", O_RDONLY) = 3 > > > read(3, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\35"..., > 1024) = 1024 > > > fstat64(3, {st_mode=S_IFREG|0755, st_size=65457, ...}) = 0 > > > old_mmap(NULL, 12516, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = > 0x402fb000 > > > mprotect(0x402fd000, 4324, PROT_NONE) = 0 > > > old_mmap(0x402fd000, 8192, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x402fd000 > > > close(3) = 0 > > > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x402ff000 > > > munmap(0x40017000, 55610) = 0 > > > brk(0) = 0x804f74c > > > brk(0x804f7e4) = 0x804f7e4 > > > brk(0x8050000) = 0x8050000 > > > getuid32() = 0 > > > socket(PF_UNIX, SOCK_STREAM, 0) = 3 > > > connect(3, {sin_family=AF_UNIX, path=" > > /var/run/.nscd_socket"}, 110) = -1 ENOENT (No such file or > directory) > > > close(3) = 0 > > > open("/etc/nsswitch.conf", O_RDONLY) = 3 > > > fstat64(3, {st_mode=S_IFREG|0644, st_size=1782, ...}) = 0 > > > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 > > > read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1782 > > > brk(0x8051000) = 0x8051000 > > > read(3, "", 4096) = 0 > > > close(3) = 0 > > > munmap(0x40017000, 4096) = 0 > > > 0xbffff15f, 1) = ? ERESTARTSYS (To be restarted) > > > --- SIGWINCH (Window changed) --- st_size=55610, ...}) = 0 > > > read(7, (NULL, 55610, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000 > > > close(3) = 0 > > > open("/lib/libnss_files.so.2", O_RDONLY) = 3 > > > read(3, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20!\0\000"..., > 1024) = 1024 > > > fstat64(3, {st_mode=S_IFREG|0755, st_size=256723, ...}) = 0 > > > old_mmap(NULL, 41636, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = > 0x40300000 > > > mprotect(0x40309000, 4772, PROT_NONE) = 0 > > > old_mmap(0x40309000, 8192, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED, 3, 0x8000) = 0x40309000 > > > close(3) = 0 > > > munmap(0x40017000, 55610) = 0 > > > open("/etc/passwd", O_RDONLY) = 3 > > > fcntl64(3, F_GETFD) = 0 > > > fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 > > > fstat64(3, {st_mode=S_IFREG|0644, st_size=1899, ...}) = 0 > > > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 > > > read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1899 > > > close(3) = 0 > > > munmap(0x40017000, 4096) = 0 > > > (END) > > > rt_sigaction(SIGPIPE, {0x804b8e0, [PIPE], SA_RESTART|0x4000000}, > {SIG_DFL}, 8) = 0 > > > pipe([3, 4]) = 0 > > > pipe([5, 6]) = 0 > > > pipe([7, 8]) = 0 > > > close(3) = 0 > > > close(4) = 0 > > > fork() = 2219 > > > close(5) = 0 > > > close(8) = 0 > > > read(7, root at dns's password: > > > scp: error while loading shared libraries: libcrypto.so.0.9.6: > cannot open shared object file: No such file or directory > > > 0xbffff15f, 1) = ? ERESTARTSYS (To be restarted) > > > --- SIGCHLD (Child exited) --- > > > read(7, "", 1) = 0 > > > write(2, "lost connection\n", 16lost connection > > > ) = 16 > > > _exit(1) = ? > > > ---------------------------------------------------------------- > Najwi?ksze Gwiazdy ?piewaj? piosenki aktorskie < www.ppa.wp.pl > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From wsk at norsik.no Sat Feb 22 01:57:52 2003 From: wsk at norsik.no (=?iso-8859-1?Q?Willy_Skj=E6veland?=) Date: Fri, 21 Feb 2003 15:57:52 +0100 Subject: (no subject) Message-ID: <78DD806978A95F4B90177B21921E96F92B132E@st-w11.app-login.net> An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030221/487fe0f3/attachment.html From dtucker at zip.com.au Sat Feb 22 11:41:03 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 22 Feb 2003 11:41:03 +1100 Subject: openssh 3.5p1 with openssl-0.9.7a References: <3e562b3e5792b@wp.pl> <1045836185.879.7.camel@ninja> Message-ID: <3E56C71E.36B2153B@zip.com.au> Mark Janssen wrote: > I'd say your scp binary on the 'beer' system was linked to openssl > 0.9.6, which it cannot find anymore. Either try symlinking > /usr/lib/libcrypto.so.0.9.7 to libcrypto.so.0.9.6 and run ldconfig, or > install a new version of scp (linked against 0.9.7a, and corresponding > ssl libraries) on the system. The symlinking may not work as openssl's ABI is not stable (and won't be until its 1.0 release, see the "Note on shared libraries" section of openssl's INSTALL file). What's worse is that "beer"'s sshd is probably also linked against the now-missing libcrypto.so, if so it will fail next time it's restarted. Try "sshd -t" to test this without killing the running sshd. Another good reason to link openssh against openssl static libraries... -- 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 bugzilla-daemon at mindrot.org Sat Feb 22 16:01:40 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 22 Feb 2003 16:01:40 +1100 (EST) Subject: [Bug 463] PrintLastLog doesn't work in privsep mode Message-ID: <20030222050140.E6B8664516@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=463 ------- Additional Comments From dtucker at zip.com.au 2003-02-22 16:01 ------- Created an attachment (id=235) --> (http://bugzilla.mindrot.org/attachment.cgi?id=235&action=view) Generate login message as part of login recording. This patch moves the generation of the generic last login message to sshlogin.c, the AIX loginsuccess call to loginrec.c and provides a monitor call to get the login message. (The AIX problem was that loginsuccess did not get called for non-password auth). The reason the monitor call is necessary is that on AIX, the last login message is generated as a side-effect of calling loginsuccess(). This needs root privs (as it does some logging too). Now if you have a postponed authentication, you can't safely call loginsuccess() before the post-auth privsep split (since the postponed authentication may not actually succeed). Hence, the only guaranteed safe place to call it is from the post-auth monitor, and therefore a monitor call is necessary to retrieve the login message). As a minor bonus (?) this also allows correct recording of ptys in the AIX login info. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Feb 22 16:28:15 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 22 Feb 2003 16:28:15 +1100 (EST) Subject: [Bug 501] New: -current broken on AIX: conflicting types for gai_strerror Message-ID: <20030222052815.9E30764520@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=501 Summary: -current broken on AIX: conflicting types for gai_strerror Product: Portable OpenSSH Version: -current Platform: Other OS/Version: AIX Status: NEW Severity: normal Priority: P2 Component: Miscellaneous AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dtucker at zip.com.au Recent additions to fake-getaddrinfo cause compile errors on AIX. The new code defines gai_strerror as returning "const char *". AIX 4.3.3 and 5.1 (and RFCs 2133 and 2553) define it returning "char *". This mismatch causes the following error. The definition of gai_strerror is buried in /usr/include/netdb.h, there doesn't seem to be any easy way of excluding it. gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I../../openbsd-compat -I../../openbsd-compat/.. -I/usr/local/ssl/include -I/usr/local/include -DHAVE_CONFIG_H -c ../../openbsd-compat/bsd-arc4random.c In file included from ../../openbsd-compat/openbsd-compat.h:39, from ../../includes.h:169, from ../../openbsd-compat/bsd-arc4random.c:25: ../../openbsd-compat/fake-getaddrinfo.h:40: conflicting types for `gai_strerror? /usr/include/netdb.h:377: previous declaration of `gai_strerror? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Feb 22 16:30:35 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 22 Feb 2003 16:30:35 +1100 (EST) Subject: [Bug 501] -current broken on AIX: conflicting types for gai_strerror Message-ID: <20030222053035.5185864549@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=501 ------- Additional Comments From dtucker at zip.com.au 2003-02-22 16:30 ------- Created an attachment (id=236) --> (http://bugzilla.mindrot.org/attachment.cgi?id=236&action=view) Define gai_strerror as "char *" as per RFC2133 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jason at devrandom.org Sat Feb 22 16:49:52 2003 From: jason at devrandom.org (Jason McCormick) Date: Sat, 22 Feb 2003 00:49:52 -0500 Subject: openssh 3.5p1 with openssl-0.9.7a - long In-Reply-To: References: Message-ID: <200302220049.52122.jason@devrandom.org> > > scp: error while loading shared libraries: libcrypto.so.0.9.6: > > cannot open shared object file: No such file or directory With RedHat systems, you have to be careful because many things are dependent (via RPM) on the base version of OpenSSL that came with the original setup of the system. If you look at the RedHat updates, there's usually several co-existant versions of OpenSSL to be installed. The "normal" one and ones that provides dependencies for binaries that are linked to older versions. For example in the current rawhide tree there's: openssl-0.9.7a-1.i386.rpm (current) openssl096b-0.9.6b-3.i386.rpm (depend provider) openssl096-0.9.6-15.i386.rpm (depend provider) You can install all of these together (they don't conflict) then you have the latest and greatest OpenSSL. Now, of course you're in the middle of RedHat's move to glibc 2.3 so rawhide may or may not work for you depending on where your system is, but you can always build from the SRPMS which works equally well. The update tree follows roughly the same setup and their 0.9.6b is patched up to the latest verion of OpenSSL even though it's called 'b' still. Anyway, this long-winded diatribe is how I've gotten around my SSL problems in my vast array of RH 7.0 through 8.0 servers. -- Jason McCormick jason at devrandom.org From jam at McQuil.Com Sun Feb 23 03:37:31 2003 From: jam at McQuil.Com (jam at McQuil.Com) Date: Sat, 22 Feb 2003 11:37:31 -0500 (EST) Subject: Patch for a port forwarding problem in serverloop.c Message-ID: Hello all, I encountered a problem when trying to setup a remote portforward using OpenSSH 3.5p1. If the port that I was trying to listen to on the remote side was already in use, a message 'cannot bind to port: 5000' was written to the syslog, but the connection still persisted. I had no way on the client side to know that the listening wasn't taking place. that is, the portforwarding of port 5000 failed, but the ssh connection on port 22 was still there. I found the spot in serverloop.c, where it seemed to be ignoring the return status from the 'channel_setup_remote_fwd_listener' call. The fix for me was a simple testing of the success, and calling fatal() to indicate that the port forwarding failed. Here is the patch: --- serverloop.c.orig Sat Feb 22 11:35:39 2003 +++ serverloop.c Sat Feb 22 11:19:29 2003 @@ -989,6 +989,9 @@ /* Start listening on the port */ success = channel_setup_remote_fwd_listener( listen_address, listen_port, options.gateway_ports); + if( !success ){ + fatal("Cannot bind to the remote port"); + } } xfree(listen_address); } And, here is the commandline that I used to initiate the connection: while :; do ssh -N -R 5000:localhost:5000 user at remotesystem sleep 10 done My patch is not terribly robust. I suppose that if you didn't use the '-N' option, you may not want the connection to disappear, but in my case, if the port forwarding fails, I really need the connection to drop, so I can go into a loop and retry it. The reason I need this, is that i'm setting up a forwarded port when I boot the client. If I reboot the client, the old connection lingers for a couple of minutes on the remote machine, before it realizes that the client has gone away. When the client comes back up, and tries to re-establish the forwarded port, it can't. So, now with my patch, the client will realize that the port forward request failed, and it will sit in a loop, and try every 10 seconds, until the connection succeeds. Anyway, thanks, and I hope you find my patch useful. Jim McQuillan jam at Ltsp.org -------------- next part -------------- --- serverloop.c.orig Sat Feb 22 11:35:39 2003 +++ serverloop.c Sat Feb 22 11:19:29 2003 @@ -989,6 +989,9 @@ /* Start listening on the port */ success = channel_setup_remote_fwd_listener( listen_address, listen_port, options.gateway_ports); + if( !success ){ + fatal("Cannot bind to the remote port"); + } } xfree(listen_address); } From markus at openbsd.org Sun Feb 23 04:16:24 2003 From: markus at openbsd.org (Markus Friedl) Date: Sat, 22 Feb 2003 18:16:24 +0100 Subject: Patch for a port forwarding problem in serverloop.c In-Reply-To: References: Message-ID: <20030222171624.GB2494@folly> hm, ssh protocol messages should be used and the client should close the connection, not the server. thanks! On Sat, Feb 22, 2003 at 11:37:31AM -0500, jam at McQuil.Com wrote: > Hello all, > > I encountered a problem when trying to setup a remote portforward > using OpenSSH 3.5p1. > > If the port that I was trying to listen to on the remote side > was already in use, a message 'cannot bind to port: 5000' was > written to the syslog, but the connection still persisted. > > I had no way on the client side to know that the listening > wasn't taking place. that is, the portforwarding of port 5000 > failed, but the ssh connection on port 22 was still there. > > I found the spot in serverloop.c, where it seemed to be > ignoring the return status from the 'channel_setup_remote_fwd_listener' > call. > > The fix for me was a simple testing of the success, and calling > fatal() to indicate that the port forwarding failed. > > Here is the patch: > > > --- serverloop.c.orig Sat Feb 22 11:35:39 2003 > +++ serverloop.c Sat Feb 22 11:19:29 2003 > @@ -989,6 +989,9 @@ > /* Start listening on the port */ > success = channel_setup_remote_fwd_listener( > listen_address, listen_port, options.gateway_ports); > + if( !success ){ > + fatal("Cannot bind to the remote port"); > + } > } > xfree(listen_address); > } > > > And, here is the commandline that I used to initiate the connection: > > > while :; do > > ssh -N -R 5000:localhost:5000 user at remotesystem > > sleep 10 > > done > > > My patch is not terribly robust. I suppose that if you didn't use > the '-N' option, you may not want the connection to disappear, but > in my case, if the port forwarding fails, I really need the > connection to drop, so I can go into a loop and retry it. > > The reason I need this, is that i'm setting up a forwarded port > when I boot the client. If I reboot the client, the old connection > lingers for a couple of minutes on the remote machine, before > it realizes that the client has gone away. When the client comes > back up, and tries to re-establish the forwarded port, it can't. > > So, now with my patch, the client will realize that the port forward > request failed, and it will sit in a loop, and try every 10 seconds, > until the connection succeeds. > > Anyway, thanks, and I hope you find my patch useful. > > Jim McQuillan > jam at Ltsp.org > --- serverloop.c.orig Sat Feb 22 11:35:39 2003 > +++ serverloop.c Sat Feb 22 11:19:29 2003 > @@ -989,6 +989,9 @@ > /* Start listening on the port */ > success = channel_setup_remote_fwd_listener( > listen_address, listen_port, options.gateway_ports); > + if( !success ){ > + fatal("Cannot bind to the remote port"); > + } > } > xfree(listen_address); > } From jason at devrandom.org Sun Feb 23 06:06:39 2003 From: jason at devrandom.org (Jason McCormick) Date: Sat, 22 Feb 2003 14:06:39 -0500 Subject: openssh 3.5p1 with openssl-0.9.7a - long In-Reply-To: <1202948099.20030222111904@wp.pl> References: <200302220049.52122.jason@devrandom.org> <1202948099.20030222111904@wp.pl> Message-ID: <200302221406.39073.jason@devrandom.org> On Saturday 22 February 2003 05:19, you wrote: > Hello Jason, > > Saturday, February 22, 2003, 6:49:52 AM, you wrote: > > Anyway, this long-winded diatribe is how I've gotten around my SSL > > problems in my vast array of RH 7.0 through 8.0 servers. > > This is real pain in the ass :-) > > ln -s will tell You the truth :-) ln -s will not always work. If you have a binary that's looking for a specific compiled-in version tag of OpenSSL then simply linking the right .so files will not work. This prevents the openssl libraries from being replaced by malicious code. Also, as was mentioned earlier, the API interface for openssl can change between versions. -- Jason McCormick jason at devrandom.org From jam at McQuil.Com Sun Feb 23 08:58:27 2003 From: jam at McQuil.Com (jam at McQuil.Com) Date: Sat, 22 Feb 2003 16:58:27 -0500 (EST) Subject: Patch for a port forwarding problem in serverloop.c In-Reply-To: <20030222171624.GB2494@folly> Message-ID: On Sat, 22 Feb 2003, Markus Friedl wrote: > hm, ssh protocol messages should be used and the > client should close the connection, not the server. Yes, that makes perfect sense, but how does the client know that the server is unable to bind to that port ? I see in the code, that the 'want_reply' is tested, and if true, it will send either a SUCCESS or FAILURE packet. But, the 'want-reply' is false. Well, at least it is when using a 3.1p1 client. I just tried it with a 3.4p1 and a 3.5p1 client, and they both set want_reply = 1. Seems good. Except... the client prints: 'Warning: remote port forwarding failed for listen port 5000' But doesn't exit. So, seems like a bug in the client. In my opinion, if you set '-N', to NOT get a tty, any failure like a port already in use, should cause the client to fail, rather than print a warning, and just hang there. I found in ssh.c, this snippet of code: if (type == SSH2_MSG_REQUEST_FAILURE) log("Warning: remote port forwarding failed for listen port %d", options.remote_forwards[i].port); Should it then check whether a tty was requested, and if NOT, call 'fatal()' instead of 'log()' ? What if multiple port forwarding requests are made ? Would it be Ok for the ssh client to exit if any one of them fail ? I have 2 goals here: 1) Get the thing working for a particular customer. Using my original patch does that. 2) Fix it the "right" way, which helps to make OpenSSH even better. For that, I need a bit of help. Thanks, Jim McQuillan jam at Ltsp.org > > thanks! > > On Sat, Feb 22, 2003 at 11:37:31AM -0500, jam at McQuil.Com wrote: > > Hello all, > > > > I encountered a problem when trying to setup a remote portforward > > using OpenSSH 3.5p1. > > > > If the port that I was trying to listen to on the remote side > > was already in use, a message 'cannot bind to port: 5000' was > > written to the syslog, but the connection still persisted. > > > > I had no way on the client side to know that the listening > > wasn't taking place. that is, the portforwarding of port 5000 > > failed, but the ssh connection on port 22 was still there. > > > > I found the spot in serverloop.c, where it seemed to be > > ignoring the return status from the 'channel_setup_remote_fwd_listener' > > call. > > > > The fix for me was a simple testing of the success, and calling > > fatal() to indicate that the port forwarding failed. > > > > Here is the patch: > > > > > > --- serverloop.c.orig Sat Feb 22 11:35:39 2003 > > +++ serverloop.c Sat Feb 22 11:19:29 2003 > > @@ -989,6 +989,9 @@ > > /* Start listening on the port */ > > success = channel_setup_remote_fwd_listener( > > listen_address, listen_port, options.gateway_ports); > > + if( !success ){ > > + fatal("Cannot bind to the remote port"); > > + } > > } > > xfree(listen_address); > > } > > > > > > And, here is the commandline that I used to initiate the connection: > > > > > > while :; do > > > > ssh -N -R 5000:localhost:5000 user at remotesystem > > > > sleep 10 > > > > done > > > > > > My patch is not terribly robust. I suppose that if you didn't use > > the '-N' option, you may not want the connection to disappear, but > > in my case, if the port forwarding fails, I really need the > > connection to drop, so I can go into a loop and retry it. > > > > The reason I need this, is that i'm setting up a forwarded port > > when I boot the client. If I reboot the client, the old connection > > lingers for a couple of minutes on the remote machine, before > > it realizes that the client has gone away. When the client comes > > back up, and tries to re-establish the forwarded port, it can't. > > > > So, now with my patch, the client will realize that the port forward > > request failed, and it will sit in a loop, and try every 10 seconds, > > until the connection succeeds. > > > > Anyway, thanks, and I hope you find my patch useful. > > > > Jim McQuillan > > jam at Ltsp.org > > > --- serverloop.c.orig Sat Feb 22 11:35:39 2003 > > +++ serverloop.c Sat Feb 22 11:19:29 2003 > > @@ -989,6 +989,9 @@ > > /* Start listening on the port */ > > success = channel_setup_remote_fwd_listener( > > listen_address, listen_port, options.gateway_ports); > > + if( !success ){ > > + fatal("Cannot bind to the remote port"); > > + } > > } > > xfree(listen_address); > > } > -- From fcusack at fcusack.com Sun Feb 23 12:33:29 2003 From: fcusack at fcusack.com (Frank Cusack) Date: Sat, 22 Feb 2003 17:33:29 -0800 Subject: [Bug 486] New: "PermitRootLogin no" can implicitly reveal root password In-Reply-To: <20030206154619.C23E06450C@shitei.mindrot.org>; from bugzilla-daemon@mindrot.org on Fri, Feb 07, 2003 at 02:46:19AM +1100 References: <20030206154619.C23E06450C@shitei.mindrot.org> Message-ID: <20030222173329.A12670@google.com> Can someone (Markus?) point me to the change which fixes this? Is there a publically available mailing list archive where CVS logs can be found? thx /fc On Fri, Feb 07, 2003 at 02:46:19AM +1100, bugzilla-daemon at mindrot.org wrote: > http://bugzilla.mindrot.org/show_bug.cgi?id=486 > > Summary: "PermitRootLogin no" can implicitly reveal root password > Product: Portable OpenSSH > Version: 3.5p1 > Platform: All > OS/Version: Linux > Status: NEW > Severity: security > Priority: P2 > Component: sshd > AssignedTo: openssh-unix-dev at mindrot.org > ReportedBy: blizzy at blizzy.de > > > With 3.5p1, when setting "PermitRootLogin no" in /etc/ssh/sshd_config, logging > in as root is disabled, of course. > > However, when entering the correct password, ssh prints "Connection reset by > peer" and exits immediately. When entering the wrong password, it will prompt > you again. > > I think this qualifies as a security hole, since you can use brute-force tools > to try to login as root. Of course you need to have/hack another account to > actually have the possibility to become root (via su or other means), but at > least you know the password. > > > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From markus at openbsd.org Sun Feb 23 22:26:30 2003 From: markus at openbsd.org (Markus Friedl) Date: Sun, 23 Feb 2003 12:26:30 +0100 Subject: Patch for a port forwarding problem in serverloop.c In-Reply-To: References: <20030222171624.GB2494@folly> Message-ID: <20030223112630.GA16769@folly> On Sat, Feb 22, 2003 at 04:58:27PM -0500, jam at McQuil.com wrote: > On Sat, 22 Feb 2003, Markus Friedl wrote: > > > hm, ssh protocol messages should be used and the > > client should close the connection, not the server. > > Yes, that makes perfect sense, but how does the client know that the > server is unable to bind to that port ? > > I see in the code, that the 'want_reply' is tested, and if > true, it will send either a SUCCESS or FAILURE packet. > > But, the 'want-reply' is false. Well, at least it is when > using a 3.1p1 client. > > I just tried it with a 3.4p1 and a 3.5p1 client, and they both > set want_reply = 1. Seems good. > > Except... the client prints: > > 'Warning: remote port forwarding failed for listen port 5000' > > But doesn't exit. > > So, seems like a bug in the client. i'm not sure about this. but there should be a client flag like 'exit if bind fails'. -m From markus at openbsd.org Sun Feb 23 22:28:50 2003 From: markus at openbsd.org (Markus Friedl) Date: Sun, 23 Feb 2003 12:28:50 +0100 Subject: [Bug 486] New: "PermitRootLogin no" can implicitly reveal root password In-Reply-To: <20030222173329.A12670@google.com> References: <20030206154619.C23E06450C@shitei.mindrot.org> <20030222173329.A12670@google.com> Message-ID: <20030223112850.GB16769@folly> On Sat, Feb 22, 2003 at 05:33:29PM -0800, Frank Cusack wrote: > Can someone (Markus?) point me to the change which fixes this? Is > there a publically available mailing list archive where CVS logs > can be found? i backed out the first patch from bug #387. From bugzilla-daemon at mindrot.org Sun Feb 23 22:53:19 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 23 Feb 2003 22:53:19 +1100 (EST) Subject: [Bug 442] sshd allows login via public-key when account locked Message-ID: <20030223115319.550D064561@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=442 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #183 is|0 |1 obsolete| | ------- Additional Comments From dtucker at zip.com.au 2003-02-23 22:53 ------- Created an attachment (id=237) --> (http://bugzilla.mindrot.org/attachment.cgi?id=237&action=view) Check for locked accounts, as specified by configure. Patch take 2. Regarding Damien's a) * the man pages (mostly) refer to "passwd -l" as "locking the account" * we respect locked accounts on some platforms (eg AIX, Tru64 w/SIA, PAM?) * ssh-1.2.33 does "*LK*" checking so there is some precedent Regarding b) see patch. It moves most of the platform-dependant stuff to configure. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From fcusack at fcusack.com Mon Feb 24 08:19:24 2003 From: fcusack at fcusack.com (Frank Cusack) Date: Sun, 23 Feb 2003 13:19:24 -0800 Subject: [Bug 486] New: "PermitRootLogin no" can implicitly reveal root password In-Reply-To: <20030223112850.GB16769@folly>; from markus@openbsd.org on Sun, Feb 23, 2003 at 12:28:50PM +0100 References: <20030206154619.C23E06450C@shitei.mindrot.org> <20030222173329.A12670@google.com> <20030223112850.GB16769@folly> Message-ID: <20030223131924.A23562@google.com> On Sun, Feb 23, 2003 at 12:28:50PM +0100, Markus Friedl wrote: > On Sat, Feb 22, 2003 at 05:33:29PM -0800, Frank Cusack wrote: > > Can someone (Markus?) point me to the change which fixes this? Is > > there a publically available mailing list archive where CVS logs > > can be found? > > i backed out the first patch from bug #387. That's not in CVS. (ie, the first patch from bug #387 is still applied). Do you mean the first "ugly fix"? I didn't think so since in #387 you say the fix is broken, before you added the "ugly fix". In any event, is it correct that this is only a problem when using privsep? thanks /fc From aplumb at westpac.com.au Mon Feb 24 12:19:39 2003 From: aplumb at westpac.com.au (aplumb at westpac.com.au) Date: Mon, 24 Feb 2003 12:19:39 +1100 Subject: newbie wants to compile SCP into his own application Message-ID: OK, I'll look into using sftp instead.... do you (or anyone else) have sample code for integrating sftp ? Andrew. Ben Lindstrom cc: openssh-unix-dev at mindrot.org Subject: Re: newbie wants to compile SCP into his own application 20/02/2003 10:07 First off I suggest you look at sftp rather than scp. There are less integration issues and I believe you'll be more happy with the results. Second, you just can just add scp.c and libopenbsd-compat.a into your code and think you don't have nay more external dependances. Just keep in mind scp forks to call ssh (same is true with sftp). But in general, sftp code is much friendlier for integrating since it was designed for that reason. scp (for how wonderful it is) is really a hack on a hack on a hack.=) - Ben On Thu, 20 Feb 2003 aplumb at westpac.com.au wrote: > Hi all, > > I have seen in the OpenSSH source that the scp executable is built by > compiling scp.c and linking with libopenbsd-compat.a and libssh.a. (Correct > me here if I'm wrong) > > My question is, can I make this a module in my own application by using the > scp.c source and ilnking the libraries mentioned above ? The reason is, I > want to perform an SCP from my application, but I don't want to execute the > external command line utility "scp". I want to be able to get a return > value to indicate success or failure and handle this in my app. > > Thanks, > > Andrew Plumb. > From mouring at etoh.eviladmin.org Mon Feb 24 12:24:15 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sun, 23 Feb 2003 19:24:15 -0600 (CST) Subject: newbie wants to compile SCP into his own application In-Reply-To: Message-ID: No clue.. but I think the code in the tree is pretty clear on the subject. - Ben On Mon, 24 Feb 2003 aplumb at westpac.com.au wrote: > > OK, I'll look into using sftp instead.... do you (or anyone else) have > sample code for integrating sftp ? > > > Andrew. > > > > > > Ben Lindstrom > admin.org> cc: openssh-unix-dev at mindrot.org > Subject: Re: newbie wants to compile SCP into his own application > 20/02/2003 10:07 > > > > > > > > First off I suggest you look at sftp rather than scp. There are less > integration issues and I believe you'll be more happy with the results. > > Second, you just can just add scp.c and libopenbsd-compat.a into your code > and think you don't have nay more external dependances. Just keep in mind > scp forks to call ssh (same is true with sftp). > > But in general, sftp code is much friendlier for integrating since it was > designed for that reason. scp (for how wonderful it is) is really a hack > on a hack on a hack.=) > > - Ben > > > > On Thu, 20 Feb 2003 aplumb at westpac.com.au wrote: > > > Hi all, > > > > I have seen in the OpenSSH source that the scp executable is built by > > compiling scp.c and linking with libopenbsd-compat.a and libssh.a. > (Correct > > me here if I'm wrong) > > > > My question is, can I make this a module in my own application by using > the > > scp.c source and ilnking the libraries mentioned above ? The reason is, I > > want to perform an SCP from my application, but I don't want to execute > the > > external command line utility "scp". I want to be able to get a return > > value to indicate success or failure and handle this in my app. > > > > Thanks, > > > > Andrew Plumb. > > > > > From bugzilla-daemon at mindrot.org Mon Feb 24 12:34:53 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Feb 2003 12:34:53 +1100 (EST) Subject: [Bug 501] -current broken on AIX: conflicting types for gai_strerror Message-ID: <20030224013453.63D6F64553@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=501 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-02-24 12:34 ------- Thanks, applied. This slipped in when I made it compile under Linux/glibc (which seems to ignore RFCs as a matter of whim) and I forgot to take the const back out. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 24 12:43:52 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Feb 2003 12:43:52 +1100 (EST) Subject: [Bug 500] show how to start-up ssh-agent by default... Message-ID: <20030224014352.A89E364553@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=500 ------- Additional Comments From djm at mindrot.org 2003-02-24 12:43 ------- I think that: [ -z "$SSH_AUTH_SOCK" ] && eval `ssh-agent -s` [ -z "$SSH_AGENT_PID" ] || ssh-add -l >/dev/null 2>&1 || ssh-add Is as effective and a lot more concise. On the other hand, fragile heuristics like: > export SSH_AUTH_SOCK=`ls /tmp/ssh-*/agent.$SSH_AUTH_PID` have no place in our documentation. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 24 12:56:13 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Feb 2003 12:56:13 +1100 (EST) Subject: [Bug 499] progressmeter.c doesn't build (at least) on Cygwin Message-ID: <20030224015613.BECA464555@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=499 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-02-24 12:56 ------- Mostly applied - thanks. I committed everything except for the basename() replacement. Instead, I took the implementation from OpenBSD libc and added it to openbsd-compat. Please test and reopen if I have further broken things :) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 24 12:57:37 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Feb 2003 12:57:37 +1100 (EST) Subject: [Bug 498] make ssh default identity configuration more user-friendly in cygwin Message-ID: <20030224015737.BB93B64555@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=498 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From djm at mindrot.org 2003-02-24 12:57 ------- Cygwin reports via http://cygwin.com/bugs.html, not here. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 24 13:04:31 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Feb 2003 13:04:31 +1100 (EST) Subject: [Bug 494] PATCH: session.c: Allow multiple accounts on Windows 9x/Me Message-ID: <20030224020431.227CA6457B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=494 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-02-24 13:04 ------- Similar fix applied - thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 24 13:06:39 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Feb 2003 13:06:39 +1100 (EST) Subject: [Bug 491] Large file transfers get stalls Message-ID: <20030224020639.2F32164587@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=491 ------- Additional Comments From djm at mindrot.org 2003-02-24 13:06 ------- Is your link high-latency? Try increasing STALLTIME in scp.c a little. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 24 13:10:06 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Feb 2003 13:10:06 +1100 (EST) Subject: [Bug 490] ssh-add man page needs slight reference update Message-ID: <20030224021006.DF8B46458B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=490 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-02-24 13:10 ------- This is fixed in -current. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 24 13:19:46 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Feb 2003 13:19:46 +1100 (EST) Subject: [Bug 485] scp doesn't preserve symbolic links Message-ID: <20030224021946.683FB64556@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=485 ------- Additional Comments From djm at mindrot.org 2003-02-24 13:19 ------- Created an attachment (id=238) --> (http://bugzilla.mindrot.org/attachment.cgi?id=238&action=view) Make scp skip symlinks Like this... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 24 13:23:33 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Feb 2003 13:23:33 +1100 (EST) Subject: [Bug 482] readconf doesn't accept paths with spaces in them Message-ID: <20030224022333.F3A5364594@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=482 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|token parsed at first space |readconf doesn't accept |in path |paths with spaces in them ------- Additional Comments From djm at mindrot.org 2003-02-24 13:23 ------- Can you use DOS-style paths as a workaround, e.g. /docume~1/ This is a bug in the parser though ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 24 13:24:29 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Feb 2003 13:24:29 +1100 (EST) Subject: [Bug 481] Extend man page with documentation Message-ID: <20030224022429.659FA64599@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=481 ------- Additional Comments From djm at mindrot.org 2003-02-24 13:24 ------- http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh-agent.1 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 24 13:25:59 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Feb 2003 13:25:59 +1100 (EST) Subject: [Bug 480] extend the -l or -L option to mention the ssh-agent's pid Message-ID: <20030224022559.C916E6459B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=480 ------- Additional Comments From djm at mindrot.org 2003-02-24 13:25 ------- I don't think that making "ssh-add -v" print the socket name would help much - you can do that yourself with "echo $SSH_AUTH_SOCK" ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 24 13:28:23 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Feb 2003 13:28:23 +1100 (EST) Subject: [Bug 478] add search function to website Message-ID: <20030224022823.D77496459B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=478 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2003-02-24 13:28 ------- I don't think so. Anyway - you already have the answer figured out :) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 24 14:20:03 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Feb 2003 14:20:03 +1100 (EST) Subject: [Bug 485] scp doesn't preserve symbolic links Message-ID: <20030224032003.D5A1064573@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=485 ------- Additional Comments From jsk29 at cornell.edu 2003-02-24 14:20 ------- I don't use sftp because the semantics of scp is exactly what I need. "cp -r" preserves symbolic links. scp should behave identically. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 24 15:46:15 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Feb 2003 15:46:15 +1100 (EST) Subject: [Bug 465] patches for NEC SX6 Message-ID: <20030224044615.05E5E64577@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=465 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-02-24 15:46 ------- Applied - thanks. Please, please, please attach patches in Unified (diff -u) format, they are much easier to read. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Mon Feb 24 16:42:05 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 24 Feb 2003 16:42:05 +1100 Subject: Compile errors on Solaris, early AIX and PAM platforms Message-ID: <3E59B0AD.B6B6D551@zip.com.au> Hi All. Damien merged a bunch of changes today which caused compile errors on a few platforms (which you can see live and in colour at [0]). a) Solaris, early AIX: ../crc32.c:100: `u_int32_t? undeclared (first use in this function) On these platforms u_int32_t is defined in defines.h which is not included by crc32.c. Fixed by attached patch. b) PAM platforms (Redhat, Solaris once a) is fixed, probably others) gcc -o sshd sshd.o [snip] auth2-kbdint.o: In function `userauth_kbdint?: /home/dtucker/openssh/openssh-tinderbox/Linux-2.4.18-24.8.0/../auth2-kbdint.c:54: undefined reference to `auth2_pam? collect2: ld returned 1 exit status Not sure about this one... -Daz. [0] http://dodgynet.dyndns.org/tinderbox/OpenSSH_Portable/status.html -- Darren Tucker (dtucker at zip.com.au) GPG Fingerprint 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: crc32.c =================================================================== RCS file: /cvs/openssh/crc32.c,v retrieving revision 1.7 diff -u -r1.7 crc32.c --- crc32.c 24 Feb 2003 01:02:13 -0000 1.7 +++ crc32.c 24 Feb 2003 05:24:49 -0000 @@ -24,6 +24,7 @@ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ +#include "includes.h" #include #include "crc32.h" From bugzilla-daemon at mindrot.org Mon Feb 24 18:14:24 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Feb 2003 18:14:24 +1100 (EST) Subject: [Bug 482] readconf doesn't accept paths with spaces in them Message-ID: <20030224071424.28FA2645AA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=482 ------- Additional Comments From spaceacademy at hotmail.com 2003-02-24 18:14 ------- DOS style pathing, /docume~1/ does work around the parsing of the token at the first space. sorry I haven't provided a patch. I have been too busy. I know. lame. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 24 19:23:06 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Feb 2003 19:23:06 +1100 (EST) Subject: [Bug 442] sshd allows login via public-key when account locked Message-ID: <20030224082306.648A0645B1@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=442 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #237 is|0 |1 obsolete| | ------- Additional Comments From dtucker at zip.com.au 2003-02-24 19:23 ------- Created an attachment (id=239) --> (http://bugzilla.mindrot.org/attachment.cgi?id=239&action=view) Fix PAM case and add configure defs for IRIX ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 24 19:23:18 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Feb 2003 19:23:18 +1100 (EST) Subject: [Bug 499] progressmeter.c doesn't build (at least) on Cygwin Message-ID: <20030224082318.58210645B2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=499 vinschen at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From vinschen at redhat.com 2003-02-24 19:23 ------- Looks good so far but... uhm... shouldn't that be: Index: openbsd-compat/basename.h =================================================================== RCS file: /cvs/openssh_cvs/openbsd-compat/basename.h,v retrieving revision 1.1 diff -p -u -r1.1 basename.h --- openbsd-compat/basename.h 24 Feb 2003 01:55:56 -0000 1.1 +++ openbsd-compat/basename.h 24 Feb 2003 08:17:42 -0000 @@ -6,7 +6,7 @@ #if !defined(HAVE_BASENAME) -char *getcwd(char *pt, size_t size); +char *basename(char *path); #endif /* !defined(HAVE_BASENAME) */ #endif /* _BASENAME_H */ ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Mon Feb 24 20:14:44 2003 From: markus at openbsd.org (Markus Friedl) Date: Mon, 24 Feb 2003 10:14:44 +0100 Subject: [Bug 486] New: "PermitRootLogin no" can implicitly reveal root password In-Reply-To: <20030223131924.A23562@google.com> References: <20030206154619.C23E06450C@shitei.mindrot.org> <20030222173329.A12670@google.com> <20030223112850.GB16769@folly> <20030223131924.A23562@google.com> Message-ID: <20030224091444.GA14627@folly> On Sun, Feb 23, 2003 at 01:19:24PM -0800, Frank Cusack wrote: > On Sun, Feb 23, 2003 at 12:28:50PM +0100, Markus Friedl wrote: > > On Sat, Feb 22, 2003 at 05:33:29PM -0800, Frank Cusack wrote: > > > Can someone (Markus?) point me to the change which fixes this? Is > > > there a publically available mailing list archive where CVS logs > > > can be found? > > > > i backed out the first patch from bug #387. > > That's not in CVS. (ie, the first patch from bug #387 is still applied). > Do you mean the first "ugly fix"? no. attachment #139 > I didn't think so since in #387 you > say the fix is broken, before you added the "ugly fix". > > In any event, is it correct that this is only a problem when using privsep? > > thanks > /fc > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From markus at openbsd.org Mon Feb 24 20:21:12 2003 From: markus at openbsd.org (Markus Friedl) Date: Mon, 24 Feb 2003 10:21:12 +0100 Subject: [Bug 486] New: "PermitRootLogin no" can implicitly reveal root password In-Reply-To: <20030223131924.A23562@google.com> References: <20030206154619.C23E06450C@shitei.mindrot.org> <20030222173329.A12670@google.com> <20030223112850.GB16769@folly> <20030223131924.A23562@google.com> Message-ID: <20030224092112.GA26578@folly> On Sun, Feb 23, 2003 at 01:19:24PM -0800, Frank Cusack wrote: > On Sun, Feb 23, 2003 at 12:28:50PM +0100, Markus Friedl wrote: > > On Sat, Feb 22, 2003 at 05:33:29PM -0800, Frank Cusack wrote: > > > Can someone (Markus?) point me to the change which fixes this? Is > > > there a publically available mailing list archive where CVS logs > > > can be found? > > > > i backed out the first patch from bug #387. > > That's not in CVS. (ie, the first patch from bug #387 is still applied). > Do you mean the first "ugly fix"? I didn't think so since in #387 you > say the fix is broken, before you added the "ugly fix". - markus at cvs.openbsd.org 2003/02/06 21:22:43 [auth1.c auth2.c] undo broken fix for #387, fixes #486 > In any event, is it correct that this is only a problem when using privsep? yes. From bugzilla-daemon at mindrot.org Mon Feb 24 22:36:34 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Feb 2003 22:36:34 +1100 (EST) Subject: [Bug 500] show how to start-up ssh-agent by default... Message-ID: <20030224113634.5166464514@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=500 ------- Additional Comments From openssh at roumenpetrov.info 2003-02-24 22:36 ------- man ssh-agent: NAME ssh-agent - authentication agent SYNOPSIS ssh-agent [-a bind_address] [-c | -s] [-d] [command [args ...]] [SNIP] run commands: mv .xsession .xsession-all echo 'ssh-agent $HOME/.xsession-all' > .xsession chmod +x .xsession or edit global Xsession. Tip:SuSe linux contain commented line like this: SSH_AGENT=/usr/bin/ssh-agent uncomment it and enjoy. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Feb 24 23:28:45 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Feb 2003 23:28:45 +1100 (EST) Subject: [Bug 500] show how to start-up ssh-agent by default... Message-ID: <20030224122845.E99B86455F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=500 hauser at acm.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |djm at mindrot.org ------- Additional Comments From hauser at acm.org 2003-02-24 23:28 ------- Damien, Thanks for your hint. I put this into my ~/.bashrc file. Unfortunately - being a cygwin user - variables set when opening my first cygwin shell window are not visible to the overall win2k system. ===> when starting a second window by the cygwin provided desktop shortcuts etc. (i.e. not out of the first cygwin window) a second ssh-agent will be started. What do you suggest as the most robust/concise way to safely handle this case? Thx Ralf ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From lucastm at poczta.onet.pl Tue Feb 25 03:29:27 2003 From: lucastm at poczta.onet.pl (=?iso-8859-2?Q?=A3ukasz_Walkiewicz?=) Date: Mon, 24 Feb 2003 17:29:27 +0100 Subject: UDP over SSH avalible Message-ID: <002101c2dc21$e6642730$24a71dc2@ia.pw.edu.pl> Hi! Greets to all of You. I placed sources of modified OpenSSH.3.4p1 for UDP port forwarding. It is not state of the art, but it should work. Waiting for comments... Lucas lucastm at poczta.onet.pl, lwalkiew at ia.pw.edu.pl --------------r-e-k-l-a-m-a----------------- Tanie bilety lotnicze! http://samoloty.onet.pl From aplumb at westpac.com.au Tue Feb 25 07:59:40 2003 From: aplumb at westpac.com.au (aplumb at westpac.com.au) Date: Tue, 25 Feb 2003 07:59:40 +1100 Subject: newbie wants to compile SCP into his own application Message-ID: Forgive my ignorance, but what is the tree ?? Andrew. Ben Lindstrom cc: openssh-unix-dev at mindrot.org Subject: Re: newbie wants to compile SCP into his own application 24/02/2003 12:24 No clue.. but I think the code in the tree is pretty clear on the subject. - Ben On Mon, 24 Feb 2003 aplumb at westpac.com.au wrote: > > OK, I'll look into using sftp instead.... do you (or anyone else) have > sample code for integrating sftp ? > > > Andrew. > From bugzilla-daemon at mindrot.org Tue Feb 25 08:38:36 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 25 Feb 2003 08:38:36 +1100 (EST) Subject: [Bug 500] show how to start-up ssh-agent by default... Message-ID: <20030224213836.5F2F264514@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=500 ------- Additional Comments From jmknoble at pobox.com 2003-02-25 08:38 ------- > when starting a second window by the cygwin provided desktop shortcuts etc. > [...] a second ssh-agent will be started. http://freshmeat.net/projects/keychain/ ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Feb 25 09:16:34 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 25 Feb 2003 09:16:34 +1100 (EST) Subject: [Bug 502] New: sshd fails when "Compression yes" set on HPUX Message-ID: <20030224221634.CFB1464514@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=502 Summary: sshd fails when "Compression yes" set on HPUX Product: Portable OpenSSH Version: 3.5p1 Platform: HPPA OS/Version: HP-UX Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dbrownell at dynix.com sshd fails each time when I set "Compression yes" in /usr/local/etc/sshd_config on an HPUX 10.20. OpenSSH version is OpenSSH_3.5p1 zlib version is 1.1.4 OpenSSL version is OpenSSL 0.9.6g 9 Aug 2002 The compiler is the HP C/ANSI C B.10.20.03 syslog on the sshd systems reports: Feb 24 12:46:32 als3 sshd[15645]: fatal: buffer_append_space: alloc 10506240 not supported I've tried recompiling zlib and openssh with different options to no effect. sshd -ddd shows: debug3: Seeding PRNG from /usr/local/libexec/ssh-rand-helper debug1: sshd version OpenSSH_3.5p1 debug1: private host key: #0 type 0 RSA1 debug3: Not a RSA1 key file /usr/local/etc/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug3: Not a RSA1 key file /usr/local/etc/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 12.168.109.200 port 35213 debug1: Client protocol version 2.0; client software version OpenSSH_3.4p1 debug1: match: OpenSSH_3.4p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_3.5p1 debug2: Network child is on pid 22200 debug3: preauth child monitor started debug3: entering debug3: privsep user:group 74:74 debug1: permanently_set_uid: 74/74 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: zlib debug2: kex_parse_kexinit: zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 zlib debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 zlib debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug3: entering: type 0 debug3: : waiting for MONITOR_ANS_MODULI debug3: : checking request 0debug3: entering: type 1 debug3: entering debug3: : got parameters: 1024 2048 8192 debug3: entering: type 1 debug2: : 0 used once, disabling now debug3: : remaining 0 debug3: entering debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: dh_gen_key: priv key bits set: 128/256 debug1: bits set: 1575/3191 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 1553/3191 debug3: entering debug3: entering: type 4 debug3: : waiting for MONITOR_ANS_SIGN debug3: entering: type 5 debug3: entering debug3: : checking request 4 debug3: debug3: : signature 4002f878(143) debug3: entering: type 5 debug2: : 4 used once, disabling now debug1: SSH2_MSG_KEX_DH_GEX_REPLY sentdebug3: entering debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: Enabling compression at level 6. debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user root service ssh-connection method none debug1: attempt 0 failures 0 debug3: entering debug3: entering: type 6 debug3: : waiting for MONITOR_ANS_PWNAM debug3: : checking request 6debug3: entering: type 7 debug3: entering debug3: debug3: : sending MONITOR_ANS_PWNAM: 1 debug3: entering: type 7 debug2: : 6 used once, disabling nowdebug2: input_userauth_request: setting up authctxt for root debug3: entering debug3: entering debug3: entering: type 3 debug2: input_userauth_request: try method nonedebug3: : checking request 3 debug3: : service=ssh-connection, style= debug3: entering debug2: : 3 used once, disabling now debug3: entering: type 10 debug3: entering debug3: : waiting for MONITOR_ANS_AUTHPASSWORD debug3: entering: type 11 debug3: : checking request 10 debug3: enteringdebug3: : sending result 0 debug3: entering: type 11 debug3: : user not authenticatedFailed none for root from 12.168.109.200 port 35213 ssh2 debug3: entering Failed none for root from 12.168.109.200 port 35213 ssh2 debug1: userauth-request for user root service ssh-connection method publickey debug1: attempt 1 failures 1 debug2: input_userauth_request: try method publickey debug1: test whether pkalg/pkblob are acceptable debug3: entering debug3: entering: type 20 debug3: : waiting for MONITOR_ANS_KEYALLOWED debug3: : checking request 20debug3: entering: type 21 debug3: entering debug3: entering debug3: : key_from_blob: 4002f8a0 debug1: temporarily_use_uid: 0/3 (e=0/3) debug1: trying public key file //.ssh/authorized_keys debug1: restore_uid: 0/3 debug1: temporarily_use_uid: 0/3 (e=0/3) debug1: trying public key file //.ssh/authorized_keys2 debug3: secure_filename: checking '/.ssh' debug3: secure_filename: checking '/' debug3: secure_filename: terminating check at '/' debug1: matching key found: file //.ssh/authorized_keys2, line 1 Found matching DSA key: be:ca:c4:c5:ad:b3:4a:7c:42:c1:2d:3e:7e:30:91:e5 debug1: restore_uid: 0/3 debug3: : key 4002f8a0 is allowed debug3: entering: type 21 debug3: entering debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss Postponed publickey for root from 12.168.109.200 port 35213 ssh2 debug1: userauth-request for user root service ssh-connection method publickey debug1: attempt 2 failures 1 debug2: input_userauth_request: try method publickey debug3: entering debug3: entering: type 20 debug3: : waiting for MONITOR_ANS_KEYALLOWED debug3: entering: type 21 debug3: : checking request 20debug3: entering debug3: entering debug3: : key_from_blob: 4002f8c0 debug1: temporarily_use_uid: 0/3 (e=0/3) debug1: trying public key file //.ssh/authorized_keys debug1: restore_uid: 0/3 debug1: temporarily_use_uid: 0/3 (e=0/3) debug1: trying public key file //.ssh/authorized_keys2 debug3: secure_filename: checking '/.ssh' debug3: secure_filename: checking '/' debug3: secure_filename: terminating check at '/' debug1: matching key found: file //.ssh/authorized_keys2, line 1 Found matching DSA key: be:ca:c4:c5:ad:b3:4a:7c:42:c1:2d:3e:7e:30:91:e5 debug1: restore_uid: 0/3 debug3: : key 4002f8c0 is allowed debug3: entering: type 21 debug3: entering debug3: entering debug3: entering: type 22 debug3: : waiting for MONITOR_ANS_KEYVERIFY debug3: : checking request 22debug3: entering: type 23 debug3: entering debug1: ssh_dss_verify: signature correct debug3: : key 4002f8f0 signature verified debug3: entering: type 23 debug2: userauth_pubkey: authenticated 1 pkalg ssh-dss Accepted publickey for root from 12.168.109.200 port 35213 ssh2 debug3: : Sending new keys: 40030e08 40030d88 debug3: : converting 40030e08 debug3: : converting 40030d88 debug3: : New keys have been sent debug3: : Sending compression state debug3: entering: type 24 debug3: : Finished sending state Accepted publickey for root from 12.168.109.200 port 35213 ssh2 debug1: : root has been authenticated by privileged process debug3: : Waiting for new keys debug3: entering: type 24 debug3: entering debug3: : 4002fba0(118) debug2: mac_init: found hmac-md5 debug3: : Waiting for second key debug3: : 4002fba0(118) debug2: mac_init: found hmac-md5 debug3: : Getting compression state debug3: : Getting Network I/O buffers debug3: : Share sync debug3: : Share sync end debug1: newkeys: mode 0 debug1: newkeys: mode 1 debug1: Entering interactive session for SSH2. debug1: fd 3 setting O_NONBLOCK debug1: fd 7 setting O_NONBLOCK debug1: server_init_dispatch_20 buffer_append_space: alloc 10506240 not supported debug1: Calling cleanup 0x4001f72a(0x0) David Brownell ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Feb 25 09:56:21 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 25 Feb 2003 09:56:21 +1100 (EST) Subject: [Bug 500] show how to start-up ssh-agent by default... Message-ID: <20030224225621.AA65464588@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=500 ------- Additional Comments From djm at mindrot.org 2003-02-25 09:56 ------- As I mentioned on the mailing list: use a single socket in a well-known place (ssh-agent -a /path/to/socket). You could probably do something like: SSH_AUTH_SOCK=/path/to/whereever export SSH_AUTH_SOCK [ -S $SSH_AUTH_SOCK ] || eval `ssh-agent -sa $SSH_AUTH_SOCK` Then the first shell will start an agent which all others will use. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Feb 25 09:56:54 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 25 Feb 2003 09:56:54 +1100 (EST) Subject: [Bug 500] show how to start-up ssh-agent by default... Message-ID: <20030224225654.EDE0364588@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=500 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From djm at mindrot.org 2003-02-25 09:56 ------- I must mention that these help requests have no place in a bug tracking system. Please direct further discussion to the mailing list openssh-unix-dev at mindrot.org ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Leonyi at osd.pentagon.mil Tue Feb 25 10:53:56 2003 From: Leonyi at osd.pentagon.mil (Leon, Yanet I,,DMDCWEST) Date: Mon, 24 Feb 2003 18:53:56 -0500 Subject: openssh password aging/expiration on Solaris 8 Message-ID: Hello there, We have several Solaris 8 systems. We recently and successfully configured and installed Openssh3.5. However, we haven't been able to set up password aging/expiration on these boxes. Users are not being notified when their passwords are approaching expiration nor they are able to change their passwords when password expiration is forced on their next login. When password expiration is enabled they get an access denied error. Could you guide me to the right place to get a patch and the appropriate steps to apply it? Please, let me know if there is indeed a patch for Solaris 8. Your prompt response will be highly appreciated. Yanet I. Leon Unix System Administrator Email: leonyi at osd.pentagon.mil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030224/f8eca195/attachment.html From maniac at maniac.nl Tue Feb 25 10:59:26 2003 From: maniac at maniac.nl (Mark Janssen) Date: 25 Feb 2003 00:59:26 +0100 Subject: [Bug 502] New: sshd fails when "Compression yes" set on HPUX In-Reply-To: <20030224221634.CFB1464514@shitei.mindrot.org> References: <20030224221634.CFB1464514@shitei.mindrot.org> Message-ID: <1046131165.819.5.camel@ninja> On Mon, 2003-02-24 at 23:16, bugzilla-daemon at mindrot.org wrote: > http://bugzilla.mindrot.org/show_bug.cgi?id=502 > > Summary: sshd fails when "Compression yes" set on HPUX [snip] > debug1: newkeys: mode 1 > debug1: Entering interactive session for SSH2. > debug1: fd 3 setting O_NONBLOCK > debug1: fd 7 setting O_NONBLOCK > debug1: server_init_dispatch_20 > buffer_append_space: alloc 10506240 not supported > debug1: Calling cleanup 0x4001f72a(0x0) Try getting a new zlib and recompiling openssh against that... that worked for me with this error. -- Mark Janssen -- maniac(at)maniac.nl -- GnuPG Key Id: 357D2178 Unix / Linux, Open-Source and Internet Consultant @ SyConOS IT Maniac.nl Unix-God.Net|Org MarkJanssen.org|nl SyConOS.com|nl From jason at devrandom.org Tue Feb 25 11:42:55 2003 From: jason at devrandom.org (Jason McCormick) Date: Mon, 24 Feb 2003 19:42:55 -0500 Subject: OpenSSH question, please!! :) In-Reply-To: References: Message-ID: <200302241942.55589.jason@devrandom.org> Devin, I've CC-ed the list so this gets archived. > when trying to run ssh, I get: > > OpenSSL version mismatch: Built against 90602f, you have 90701f This is what I was saying before http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=104589343318200&w=2 . The binary packages provided by RedHat have many things compiled against them. If you don't follow the upgrade path recommended by RedHat (i.e. they keep everything at 0.9.6b as an internal version number) then you run into instances like this. > I wonder if this is something simple, but I > am really confused as to why the latest version of SSH would be > giving me these mismatch problems. This is a security precaution. If it would happen that someone replaced the libraries of OpenSSL with a hacked version or a compromised replacement it would be caught. Obviously not a foolproof method but is definitely a help. > Failed Dependencies: > openssh = 3.4p1-2 is needed by (installed) openssh-server-3.4p1-2 > openssh = 3.4p1-2 is needed by (installed) openssh-clients-3.4p1-2 > openssh = 3.4p1-2 is needed by (installed) openssh-askpass3.4p1-2 RPM isn't always clear with its dependencies. When dealing with RedHat there's 5 packages for OpenSSH - openssh, openssh-server, openssh-client, openssh-askpass and openssh-askpass-gnome. You need to upgrade all of those at the same time. > So basically I am stumped as to how to fix > this. Should I try and compile from source? I'd love to learn how to > use RPMS instead though, especially for items like SSH which I wont > need to recompile often. What you should do is go to Rawhide (my favorite mirror is ftp.dulug.duke.edu) and go to the SRPMS tree (ftp.redhat.com/pub/redhat/linux/rawhide/SRPMS/SRPMS) and get openssh-3.5p1-6.src.rpm. This is the source RPM for RedHat's openssh packages. If you're on RH8.0 you'll want to do an 'rpmbuild --rebuild openssh-3.5p1-6.src.rpm'. This will make the 5 packages you need in /usr/src/redhat/RPMS/i386. You can then install them from there and should resolve your depedences. On a side note, while I use many RedHat servers in a production release, I would not consider 8.0 "production ready" just yet. They're working out a lot of bugs that'll be fixed in 8.1. If you continue to have problems, please e-mail me back but please make sure to CC openssh-unix-dev at mindrot.org so other can benefit. Thanks. -- Jason McCormick jason at devrandom.org From dtucker at zip.com.au Tue Feb 25 13:08:11 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 25 Feb 2003 13:08:11 +1100 Subject: openssh password aging/expiration on Solaris 8 References: Message-ID: <3E5AD00B.F5CB70A2@zip.com.au> > "Leon, Yanet I,,DMDCWEST" wrote: > Could you guide me to the right place to get a patch and the > appropriate steps to apply it? Please, let me know if there is indeed > a patch for Solaris 8. Your prompt response will be highly > appreciated. See http://www.zip.com.au/~dtucker/openssh/. The patch and directions for non-PAM configurations are there, as well as a pointer to the PAM patch. -- Darren Tucker (dtucker at zip.com.au) GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From jmknoble at pobox.com Tue Feb 25 13:30:58 2003 From: jmknoble at pobox.com (Jim Knoble) Date: Mon, 24 Feb 2003 21:30:58 -0500 Subject: OpenSSH question, please!! :) In-Reply-To: <200302241942.55589.jason@devrandom.org> References: <200302241942.55589.jason@devrandom.org> Message-ID: <20030225023058.GA25700@crawfish.ais.com> Circa 2003-02-24 19:42:55 -0500 dixit Jason McCormick: : > OpenSSL version mismatch: Built against 90602f, you have 90701f : : This is what I was saying before : http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=104589343318200&w=2 : . The binary packages provided by RedHat have many things compiled : against them. If you don't follow the upgrade path recommended by : RedHat (i.e. they keep everything at 0.9.6b as an internal version : number) then you run into instances like this. Of course, another option is to build packages of OpenSSL such that more than one is able to be installed at a time, as i've recently described on the RPM mailing list: http://www.redhat.com/mailing-lists/rpm-list/msg18062.html Then it's possible to rebuild each package that depends on OpenSSL without having to stop the service, uninstall the package, rebuild, install, and finally restart the service again. : This is a security precaution. If it would happen that someone replaced : the libraries of OpenSSL with a hacked version or a compromised : replacement it would be caught. Obviously not a foolproof method but : is definitely a help. It's not remotely a security measure. It's there because the OpenSSL maintainers do not guarantee that either the OpenSSL API or the ABI will be stable until OpenSSL v1.0. The only possible way this could be connected with security is to keep OpenSSH from using an OpenSSL shared library that may have a different API or ABI than OpenSSH expects, giving rise to potential, hypothetical problems (for example, if the libcrypto API were to change such that OpenSSH failed to call a newly required initialization function, causing OpenSSH to send out unencrypted or weakly encrypted data). It's much more likely that OpenSSH would simply crash unexpectedly due to a strange pointer in a slightly incompatible ABI, and you wouldn't be able to get OpenSSH running again. As it is, when you run 'sshd -t' after installing your new, potentially incompatible OpenSSL library, OpenSSH complains immediately, instead of crashing later. It's more of a reliability measure than a security measure. If you want to protect against the replacement of shared libraries (or any other files, for that matter, such as /etc/ssh/sshd_config), you should use a combination of immutable attributes, securelevels, and offline SHA-1 hashes or the equivalent. Anything else is just fooling yourself. : > Failed Dependencies: [...] : RPM isn't always clear with its dependencies. When dealing with RedHat : there's 5 packages for OpenSSH - openssh, openssh-server, : openssh-client, openssh-askpass and openssh-askpass-gnome. You need to : upgrade all of those at the same time. (or remove them first, or, if you *really* know what you're doing, uninstall the required package using 'rpm --erase --nodeps'). : What you should do is go to Rawhide (my favorite mirror is : ftp.dulug.duke.edu) and go to the SRPMS tree : (ftp.redhat.com/pub/redhat/linux/rawhide/SRPMS/SRPMS) and get : openssh-3.5p1-6.src.rpm. This is the source RPM for RedHat's openssh : packages. If you're on RH8.0 you'll want to do an 'rpmbuild --rebuild : openssh-3.5p1-6.src.rpm'. This will make the 5 packages you need in : /usr/src/redhat/RPMS/i386. You can then install them from there and : should resolve your depedences. Note that current Red Hat Rawhide uses rpm-4.2, which contains some additions to specfile syntax (notable a %check section). Consequently, some Rawhide RPMs may not to rebuild properly under systems using earlier versions of RPM. Caveat utilisor. If you're going to install RPMs of OpenSSH, why not simply use the ones from ftp://ftp.openssh.com/pub/OpenBSD/OpenSSH/portable/rpm/ ? Or even from the specfile in the openssh-3.5p1 source tarball? That way you don't have any of the sort of cross-platform incompatibility: http://cr.yp.to/compatibility.html that continues to plague Unix, Linux, and other "compatible" operating platforms. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) Stop the War on Freedom ... Start the War on Poverty! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 256 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030224/d03ecebf/attachment.bin From jason at devrandom.org Tue Feb 25 14:05:06 2003 From: jason at devrandom.org (Jason McCormick) Date: Mon, 24 Feb 2003 22:05:06 -0500 Subject: OpenSSH question, please!! :) In-Reply-To: <20030225023058.GA25700@crawfish.ais.com> References: <200302241942.55589.jason@devrandom.org> <20030225023058.GA25700@crawfish.ais.com> Message-ID: <200302242205.06217.jason@devrandom.org> > It's not remotely a security measure. Hrmm.. I'd always thought it was. I stand corrected. -- Jason McCormick jason at devrandom.org From tim at multitalents.net Wed Feb 26 13:39:27 2003 From: tim at multitalents.net (Tim Rice) Date: Tue, 25 Feb 2003 18:39:27 -0800 (PST) Subject: nanosleep Message-ID: Could someone familear with the OpenBSD tree please point me to nanoslep. scp.c now uses it and it's not in all plattorms so we'll ethier have to add one to openbsd-compat or ifdef that chunk. Thanks. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From jmknoble at pobox.com Wed Feb 26 16:22:57 2003 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 26 Feb 2003 00:22:57 -0500 Subject: nanosleep In-Reply-To: References: Message-ID: <20030226052257.GH25700@crawfish.ais.com> Circa 2003-02-25 18:39:27 -0800 dixit Tim Rice: : Could someone familear with the OpenBSD tree please point me to : nanoslep. scp.c now uses it and it's not in all plattorms so we'll : ethier have to add one to openbsd-compat or ifdef that chunk. nanosleep() is a system call under OpenBSD. Perhaps it could be defined in terms of usleep(), with a slight loss of precision? http://www.openbsd.org/cgi-bin/man.cgi?query=nanosleep -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) Stop the War on Freedom ... Start the War on Poverty! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 256 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030226/c5d0d7b8/attachment.bin From dtucker at zip.com.au Wed Feb 26 17:53:07 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 26 Feb 2003 17:53:07 +1100 Subject: nanosleep References: <20030226052257.GH25700@crawfish.ais.com> Message-ID: <3E5C6453.FD96A50A@zip.com.au> Jim Knoble wrote:q > nanosleep() is a system call under OpenBSD. Perhaps it could be > defined in terms of usleep(), with a slight loss of precision? If you're going to build a nanosleep replacement shouldn't you use select()? It's already used in openssh so it's guaranteed to be on any currently working platform. -- 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 jmknoble at pobox.com Wed Feb 26 18:24:58 2003 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 26 Feb 2003 02:24:58 -0500 Subject: nanosleep In-Reply-To: <3E5C6453.FD96A50A@zip.com.au> References: <20030226052257.GH25700@crawfish.ais.com> <3E5C6453.FD96A50A@zip.com.au> Message-ID: <20030226072458.GK25700@crawfish.ais.com> Circa 2003-02-26 17:53:07 +1100 dixit Darren Tucker: : Jim Knoble wrote:q : > nanosleep() is a system call under OpenBSD. Perhaps it could be : > defined in terms of usleep() [...]? : : If you're going to build a nanosleep replacement shouldn't you use : select()? It's already used in openssh so it's guaranteed to be on any : currently working platform. Even better. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) Stop the War on Freedom ... Start the War on Poverty! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 256 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030226/2382a655/attachment.bin From openssh-dev at oscarminus.de Wed Feb 26 21:31:53 2003 From: openssh-dev at oscarminus.de (Michael Schwarz) Date: Wed, 26 Feb 2003 11:31:53 +0100 Subject: IPv6 support? Message-ID: <20030226103153.GA1550@bumpern.de> Hello! I hope this is the right mailinglist ;) At the moment, I use IPv6 for IRC only, because of too less software wich provides IPv6. It would be very nice if OpenSSH would support IPv6. AFAIK isn't it yet implemented, so it would be nice if someone could implement this. Please send a copy of your answers to openssh-dev at oscarminus.de too, because I'm not subscriped on this mailinglist. Best regards Michael From yoshfuji at linux-ipv6.org Wed Feb 26 21:46:21 2003 From: yoshfuji at linux-ipv6.org (YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) Date: Wed, 26 Feb 2003 19:46:21 +0900 (JST) Subject: IPv6 support? In-Reply-To: <20030226103153.GA1550@bumpern.de> References: <20030226103153.GA1550@bumpern.de> Message-ID: <20030226.194621.02024697.yoshfuji@linux-ipv6.org> In article <20030226103153.GA1550 at bumpern.de> (at Wed, 26 Feb 2003 11:31:53 +0100), Michael Schwarz says: > AFAIK isn't it yet implemented, so it would be nice if someone could > implement this. It IS implemented for long time. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From gert at greenie.muc.de Wed Feb 26 22:20:17 2003 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 26 Feb 2003 12:20:17 +0100 Subject: IPv6 support? In-Reply-To: <20030226103153.GA1550@bumpern.de>; from openssh-dev@oscarminus.de on Wed, Feb 26, 2003 at 11:31:53AM +0100 References: <20030226103153.GA1550@bumpern.de> Message-ID: <20030226122017.J13800@greenie.muc.de> Hi, On Wed, Feb 26, 2003 at 11:31:53AM +0100, Michael Schwarz wrote: > I hope this is the right mailinglist ;) > > At the moment, I use IPv6 for IRC only, because of too less software > wich provides IPv6. It would be very nice if OpenSSH would support IPv6. > > AFAIK isn't it yet implemented, so it would be nice if someone could > implement this. Uh? Openssh is about the software with the best IPv6 support that I have seen so far... I use it every day over v6 (at work) and it just works as expected. Just make sure you don't use a package that was built with "v4 only" (like the MacOS X people do *sigh*). 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.doering at physik.tu-muenchen.de From me at oscarminus.de Wed Feb 26 22:47:02 2003 From: me at oscarminus.de (Michael Schwarz) Date: Wed, 26 Feb 2003 12:47:02 +0100 Subject: IPv6 support? In-Reply-To: <20030226122017.J13800@greenie.muc.de> References: <20030226103153.GA1550@bumpern.de> <20030226122017.J13800@greenie.muc.de> Message-ID: <20030226114702.GA1922@bumpern.de> Gert Doering wrote: > Just make sure you don't use a package that was built with "v4 only" > (like the MacOS X people do *sigh*). Well, it was my fault. Ok, not really. It seems that the version which comes with debian-woody is compiled without v6. I'm trying for about three hours to get it work. On Debian-Sid everything works fine. I think i will recompile that package. Greetings Michael From maniac at maniac.nl Wed Feb 26 23:19:57 2003 From: maniac at maniac.nl (Mark Janssen) Date: 26 Feb 2003 13:19:57 +0100 Subject: IPv6 support? In-Reply-To: <20030226114702.GA1922@bumpern.de> References: <20030226103153.GA1550@bumpern.de> <20030226122017.J13800@greenie.muc.de> <20030226114702.GA1922@bumpern.de> Message-ID: <1046261997.806.0.camel@ninja> On Wed, 2003-02-26 at 12:47, Michael Schwarz wrote: > Gert Doering wrote: > > Just make sure you don't use a package that was built with "v4 only" > > (like the MacOS X people do *sigh*). > > Well, it was my fault. Ok, not really. It seems that the version which > comes with debian-woody is compiled without v6. I'm trying for about > three hours to get it work. On Debian-Sid everything works fine. > > I think i will recompile that package. Put this in your sources.list All debian ipv6 packages ;) # IPv6 #deb http://people.debian.org/~kitame/ipv6 ipv6 unstable deb http://ftp.nl.debian.org/debian-ipv6 sid ipv6 -- Mark Janssen -- maniac(at)maniac.nl -- GnuPG Key Id: 357D2178 Unix / Linux, Open-Source and Internet Consultant @ SyConOS IT Maniac.nl Unix-God.Net|Org MarkJanssen.org|nl SyConOS.com|nl From yoshfuji at wide.ad.jp Thu Feb 27 00:06:02 2003 From: yoshfuji at wide.ad.jp (YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) Date: Wed, 26 Feb 2003 22:06:02 +0900 (JST) Subject: IPv6 support? In-Reply-To: <20030226114702.GA1922@bumpern.de> References: <20030226103153.GA1550@bumpern.de> <20030226122017.J13800@greenie.muc.de> <20030226114702.GA1922@bumpern.de> Message-ID: <20030226.220602.88604265.yoshfuji@wide.ad.jp> In article <20030226114702.GA1922 at bumpern.de> (at Wed, 26 Feb 2003 12:47:02 +0100), Michael Schwarz says: > Well, it was my fault. Ok, not really. It seems that the version which > comes with debian-woody is compiled without v6. I'm trying for about > three hours to get it work. On Debian-Sid everything works fine. woody is compiled with ipv6 but ipv4 by default. Try -6 option. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From fcusack at fcusack.com Thu Feb 27 03:26:22 2003 From: fcusack at fcusack.com (Frank Cusack) Date: Wed, 26 Feb 2003 08:26:22 -0800 Subject: PAM merge from FreeBSD In-Reply-To: ; from des@ofug.org on Sun, Feb 02, 2003 at 01:48:52PM +0100 References: <3E1E2593.3070204@mindrot.org> <20030109214943.A29970@google.com> Message-ID: <20030226082622.A6086@google.com> On Sun, Feb 02, 2003 at 01:48:52PM +0100, Dag-Erling Smorgrav wrote: > My code runs the PAM authentication in a separate thread or process to > avoid calling the main loop from the conversation function (which > won't work with privsep anyway). Modules like pam_krb5 where the > session management stage uses information stored by the authentication > stage only work when using threads, because threads can share a PAM > handle but processes can't. Here are my initial thoughts. The PAM stuff runs in the priv part. You communicate to the unpriv part via a socket. Why bother with threads? The thread is just an added complication. OK, it avoids having to grab control of the main loop from within the conversation function, but I just wonder if there's another way to do this. I mean, you're still stuck in the conv. function until the info response comes back, anyway. How do (will) you handle restarting the authentication (client sends USERAUTH_REQUEST instead of USERAUTH_INFO_RESPONSE)? In auth-pam.c:sshpam_thread_conv(), line 148, the two cases ECHO_OFF and ECHO_ON should be combined into a single case, as should the ERROR_MSG and TEXT_INFO cases; just as you do in sshpam_query(). The code as a whole /is/ far cleaner than what exists currently, so that is a big plus. I dislike that kbdint is run via auth2_challenge() and all the refs to "challenge". It's not necessarily a challenge. /fc From bugzilla-daemon at mindrot.org Thu Feb 27 05:42:50 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 27 Feb 2003 05:42:50 +1100 (EST) Subject: [Bug 341] Return Code unpredictable Message-ID: <20030226184250.0FB456454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=341 gq at cs.msu.su changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From gq at cs.msu.su 2003-02-27 05:42 ------- I have the same problem with OpenSSH_3.5p1 Debian 1:3.5p1-4, SSH protocols 1.5/2.0, OpenSSL 0x0090701f when I'm trying connect to non-exist host from the shell it returns 0 on one pc and 1 on another one. But when I do it on the first pc from the script it returns 1. Anyway it looking strange. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mouring at etoh.eviladmin.org Thu Feb 27 05:46:44 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 26 Feb 2003 12:46:44 -0600 (CST) Subject: AllowUsers Change In-Reply-To: Message-ID: No comments either means no one cares or no one has tested. Let me know quickly or I won't push for including it into 3.6. We are getting close to a tree lock people. - Ben On Sat, 15 Feb 2003, Ben Lindstrom wrote: > > Markus, ignore the other stuff I sent.. I need to go back to bed and stop > trying to code.. > > For everone else.. Will this make everyone happy? > > This does the follow. > > it will always honor AllowUsers. > > If there is no Allow/DenyGroups it stated they are not in allowUsers. IF > there are AllowDenyGroups it tries them. And then stated they are not in > either AllowUsers nor AllowGroups > > since PErmitRootLogin is not handled in auth.c:allowed_users() I will not > try to add that logic. I still believe it should be true. > > Diff against -ccurent BSD tree. > > - Ben > > Index: auth.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/auth.c,v > retrieving revision 1.46 > diff -u -r1.46 auth.c > --- auth.c 4 Nov 2002 10:07:53 -0000 1.46 > +++ auth.c 16 Feb 2003 03:27:42 -0000 > @@ -105,15 +105,16 @@ > return 0; > } > } > - /* Return false if AllowUsers isn't empty and user isn't listed there */ > + /* Return true if person in AllowUsers, otherwise try the group test */ > if (options.num_allow_users > 0) { > for (i = 0; i < options.num_allow_users; i++) > if (match_user(pw->pw_name, hostname, ipaddr, > options.allow_users[i])) > - break; > - /* i < options.num_allow_users iff we break for loop */ > - if (i >= options.num_allow_users) { > - log("User %.100s not allowed because not listed in AllowUsers", > + goto success; > + > + if (options.num_deny_groups == 0 && > + options.num_allow_groups == 0) { > + log("User %.100s not allowed because not in AllowUsers", > pw->pw_name); > return 0; > } > @@ -136,20 +137,28 @@ > return 0; > } > /* > - * Return false if AllowGroups isn't empty and one of user's groups > - * isn't listed there > + * Return false if AllowGroups isn't empty and one of > + * user's groups isn't listed there > */ > if (options.num_allow_groups > 0) > if (!ga_match(options.allow_groups, > options.num_allow_groups)) { > ga_free(); > - log("User %.100s not allowed because none of user's groups are listed in AllowGroups", > + if (options.num_deny_users > 0 || > + options.num_allow_users > 0) { > + log("User %.100s not allowed because not in AllowUsers nor user's groups in AllowGroups", > + pw->pw_name); > + return 0; > + } else { > + log("User %.100s not allowed because none of user's groups are listed in AllowGroups", > pw->pw_name); > - return 0; > + return 0; > + } > } > ga_free(); > } > /* We found no reason not to let this user try to log on... */ > +success: > return 1; > } > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From jdennis at law.harvard.edu Thu Feb 27 06:04:06 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Wed, 26 Feb 2003 14:04:06 -0500 Subject: SSH keys different Message-ID: <3E5D0FA6.5030704@law.harvard.edu> Hey guys, Today a co-worker asked me why OpenSSH's keys are different from commercial SSH's keys and I didn't know what to tell him. I poked around online a bit too but couldn't find much. Could someone point me to a URL or maybe just give a quick reason why they're different? -- James Dennis Harvard Law School "Not everything that counts can be counted, and not everything that can be counted counts." From jdennis at law.harvard.edu Thu Feb 27 06:38:38 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Wed, 26 Feb 2003 14:38:38 -0500 Subject: AllowUsers Change In-Reply-To: References: Message-ID: <3E5D17BE.2040903@law.harvard.edu> Hey Ben, The patch appears to be working just fine. I would very much like to see it in 3.6 if possible, as I'd like to use AllowGroups ftponly instead of AllowUsers [250 usernames]... Thanks! -James PS. My apologies for not responding as I'm the one who brought this up originally, things have quite busy lately. Ben Lindstrom wrote: > No comments either means no one cares or no one has tested. Let me know > quickly or I won't push for including it into 3.6. We are getting close > to a tree lock people. > > - Ben > > > On Sat, 15 Feb 2003, Ben Lindstrom wrote: > > >>Markus, ignore the other stuff I sent.. I need to go back to bed and stop >>trying to code.. >> >>For everone else.. Will this make everyone happy? >> >>This does the follow. >> >>it will always honor AllowUsers. >> >>If there is no Allow/DenyGroups it stated they are not in allowUsers. IF >>there are AllowDenyGroups it tries them. And then stated they are not in >>either AllowUsers nor AllowGroups >> >>since PErmitRootLogin is not handled in auth.c:allowed_users() I will not >>try to add that logic. I still believe it should be true. >> >>Diff against -ccurent BSD tree. >> >>- Ben >> >>Index: auth.c >>=================================================================== >>RCS file: /cvs/src/usr.bin/ssh/auth.c,v >>retrieving revision 1.46 >>diff -u -r1.46 auth.c >>--- auth.c 4 Nov 2002 10:07:53 -0000 1.46 >>+++ auth.c 16 Feb 2003 03:27:42 -0000 >>@@ -105,15 +105,16 @@ >> return 0; >> } >> } >>- /* Return false if AllowUsers isn't empty and user isn't listed there */ >>+ /* Return true if person in AllowUsers, otherwise try the group test */ >> if (options.num_allow_users > 0) { >> for (i = 0; i < options.num_allow_users; i++) >> if (match_user(pw->pw_name, hostname, ipaddr, >> options.allow_users[i])) >>- break; >>- /* i < options.num_allow_users iff we break for loop */ >>- if (i >= options.num_allow_users) { >>- log("User %.100s not allowed because not listed in AllowUsers", >>+ goto success; >>+ >>+ if (options.num_deny_groups == 0 && >>+ options.num_allow_groups == 0) { >>+ log("User %.100s not allowed because not in AllowUsers", >> pw->pw_name); >> return 0; >> } >>@@ -136,20 +137,28 @@ >> return 0; >> } >> /* >>- * Return false if AllowGroups isn't empty and one of user's groups >>- * isn't listed there >>+ * Return false if AllowGroups isn't empty and one of >>+ * user's groups isn't listed there >> */ >> if (options.num_allow_groups > 0) >> if (!ga_match(options.allow_groups, >> options.num_allow_groups)) { >> ga_free(); >>- log("User %.100s not allowed because none of user's groups are listed in AllowGroups", >>+ if (options.num_deny_users > 0 || >>+ options.num_allow_users > 0) { >>+ log("User %.100s not allowed because not in AllowUsers nor user's groups in AllowGroups", >>+ pw->pw_name); >>+ return 0; >>+ } else { >>+ log("User %.100s not allowed because none of user's groups are listed in AllowGroups", >> pw->pw_name); >>- return 0; >>+ return 0; >>+ } >> } >> ga_free(); >> } >> /* We found no reason not to let this user try to log on... */ >>+success: >> return 1; >> } >> >> >>_______________________________________________ >>openssh-unix-dev mailing list >>openssh-unix-dev at mindrot.org >>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >> > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- James Dennis Harvard Law School "Not everything that counts can be counted, and not everything that can be counted counts." From des at ofug.org Thu Feb 27 06:42:49 2003 From: des at ofug.org (Dag-Erling Smorgrav) Date: Wed, 26 Feb 2003 20:42:49 +0100 Subject: PAM merge from FreeBSD In-Reply-To: <20030226082622.A6086@google.com> (Frank Cusack's message of "Wed, 26 Feb 2003 08:26:22 -0800") References: <3E1E2593.3070204@mindrot.org> <20030109214943.A29970@google.com> <20030226082622.A6086@google.com> Message-ID: Frank Cusack writes: > The PAM stuff runs in the priv part. You communicate to the unpriv part > via a socket. Why bother with threads? The thread is just an added > complication. OK, it avoids having to grab control of the main loop > from within the conversation function, but I just wonder if there's > another way to do this. There is no other way with privsep (BTW, the code can use a separate process instead of threads, but then you lose context sharing which may prevent some modules from working) > I mean, you're still stuck in the conv. > function until the info response comes back, anyway. How do (will) > you handle restarting the authentication (client sends USERAUTH_REQUEST > instead of USERAUTH_INFO_RESPONSE)? That is a separate issue which neither the old nor the new code address. DES -- Dag-Erling Smorgrav - des at ofug.org From jdennis at law.harvard.edu Thu Feb 27 06:51:58 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Wed, 26 Feb 2003 14:51:58 -0500 Subject: AllowUsers Change Message-ID: <3E5D1ADE.2070201@law.harvard.edu> Just in case anyone wants Ben's patch for OpenSSH's 3.5 release instead of current, here it is. diff -uNr openssh-3.5p1/auth.c openssh-3.5p1-allowfix/auth.c --- openssh-3.5p1/auth.c Sat Sep 21 11:26:53 2002 +++ openssh-3.5p1-allowfix/auth.c Wed Feb 26 14:28:00 2003 @@ -156,15 +156,16 @@ return 0; } } - /* Return false if AllowUsers isn't empty and user isn't listed there */ + /* Return true if person in AllowUsers, otherwise try the group test */ if (options.num_allow_users > 0) { for (i = 0; i < options.num_allow_users; i++) if (match_user(pw->pw_name, hostname, ipaddr, options.allow_users[i])) - break; - /* i < options.num_allow_users iff we break for loop */ - if (i >= options.num_allow_users) { - log("User %.100s not allowed because not listed in AllowUsers", + goto success; + + if (options.num_deny_groups == 0 && + options.num_allow_groups == 0) { + log("User %.100s not allowed because not in AllowUsers", pw->pw_name); return 0; } @@ -194,9 +195,16 @@ if (!ga_match(options.allow_groups, options.num_allow_groups)) { ga_free(); - log("User %.100s not allowed because none of user's groups are listed in AllowGroups", - pw->pw_name); - return 0; + if (options.num_deny_users > 0 || + options.num_allow_users > 0) { + log("User %.100s not allowed because not in AllowUsers nor user's groups in AllowGroups", + pw->pw_name); + return 0; + } else { + log("User %.100s not allow because none of user's groups are listed in AllowGroups", + pw->pw_name); + return 0; + } } ga_free(); } @@ -219,6 +227,7 @@ #endif /* WITH_AIXAUTHENTICATE */ /* We found no reason not to let this user try to log on... */ +success: return 1; } -- James Dennis Harvard Law School "Not everything that counts can be counted, and not everything that can be counted counts." From Nicolas.Williams at sun.com Thu Feb 27 06:55:42 2003 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 26 Feb 2003 11:55:42 -0800 Subject: PAM merge from FreeBSD Message-ID: <20030226115542.A5240@binky.central.sun.com> A few things to keep in mind: - kbd-int should call pam_authenticate(), acct_mgmt(), chauthtok(), if required, setcred(PAM_ESTABLISH_CRED) and open_session() ALL during kbd-int so that modules in each of those PAM stacks can prompt the user (pam_open_session(), for example, may prompt a user with an informational message akin to the last login message) - all userauth methods should call pam_acct_mgmt() and force kbd-int, via partial userauth failure, if pam_acct_mgmt() returns PAM_NEW_AUTHTOK_REQD (password expired) - pam_setcred(PAM_ESTABLISH_CRED) and pam_open_session() should be called by the end of userauth, regardless of which method(s) is(are) tried by the client and completed successfully. (NOTE: there's no tty at that point, nor any way to know if the client will want a tty session) - userauth methods other than kbd-int should have a null conversation function (either NULL, literally, or a function that returns PAM_CONV_ERR if any echo on/off prompts are issued) - all of those PAM calls have to be done in a process which is an ancestor to the user's actual session processes and those user processes should not be created before calling PAM either - preferably the process that calls pam_open_session() should be the one to call pam_close_session(), on the same PAM handle on which pam_open_session() was called - no concurrence (threads) is needed for any of this, but because of the way PAM conversations work - the event loop must be nested (yes, this is workable, and 3.5p1 does nest the event loop in kbd-int userauth w/ PAM) OR - the PAM calls must be performed on alternative stacks (i.e., in a different co-process) OR - the server must packet_disconnect() rather than allow kbd-int to be abandoned or restarted As Frank points out, multi-round-trip userauth methods can be "abandoned" or "restarted" by the client; for kbd-int userauth this means that multiple PAM conversations may be active, waiting for responses, concurrently (but only the last one started can succeed - the others must be either fail or be left waiting for responses that will never come). Cheers, Nico -- On Wednesday, February 26, 2003, Frank Cusack wrote: > On Sun, Feb 02, 2003 at 01:48:52PM +0100, Dag-Erling Smorgrav wrote: > > My code runs the PAM authentication in a separate thread or process to > > avoid calling the main loop from the conversation function (which > > won't work with privsep anyway). Modules like pam_krb5 where the > > session management stage uses information stored by the authentication > > stage only work when using threads, because threads can share a PAM > > handle but processes can't. > > Here are my initial thoughts. > > The PAM stuff runs in the priv part. You communicate to the unpriv part > via a socket. Why bother with threads? The thread is just an added > complication. OK, it avoids having to grab control of the main loop > from within the conversation function, but I just wonder if there's > another way to do this. I mean, you're still stuck in the conv. > function until the info response comes back, anyway. How do (will) > you handle restarting the authentication (client sends USERAUTH_REQUEST > instead of USERAUTH_INFO_RESPONSE)? > > In auth-pam.c:sshpam_thread_conv(), line 148, the two cases ECHO_OFF and > ECHO_ON should be combined into a single case, as should the ERROR_MSG > and TEXT_INFO cases; just as you do in sshpam_query(). > > The code as a whole /is/ far cleaner than what exists currently, so that > is a big plus. > > I dislike that kbdint is run via auth2_challenge() and all the refs > to "challenge". It's not necessarily a challenge. > > /fc From sridharb at satyam.com Thu Feb 27 08:12:57 2003 From: sridharb at satyam.com (Sreedhar_Baddigam) Date: Thu, 27 Feb 2003 02:42:57 +0530 Subject: OpenSSH 3.4p1 hostbased authentication Message-ID: Hi, We want to use Hostbased Authentication in OpenSSH 3.4p1 completely based on rhosts or shosts. Don't want to have any keys exchange between server and client. Created /etc/ssh/sshd_config on OpenSSH server with: RhostsAuthentication yes IgnoreRhosts no HostbasedAuthentication yes Created /etc/ssh/ssh_config on client with: Host * HostbasedAuthentication yes Created /etc/rhosts.equiv, /etc/shosts.equiv, /etc/ssh/shosts.equiv on server with: Hostbased authentication is failing giving the following message on client side: debug1: authentications that can continue: publickey,password,keyboard-interactive,hostbased debug1: next auth method to try is hostbased get_socket_ipaddr: getnameinfo 8 failed userauth_hostbased: cannot get local ipaddr/name debug1: next auth method to try is password root at server01's password: What special settings are to be done to make it work? Please help. thanks and regards, Sreedhar. ************************************************************************** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. ************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030227/305b1db1/attachment.html From tim at multitalents.net Thu Feb 27 09:09:59 2003 From: tim at multitalents.net (Tim Rice) Date: Wed, 26 Feb 2003 14:09:59 -0800 (PST) Subject: OpenSSH 3.4p1 hostbased authentication In-Reply-To: References: Message-ID: On Thu, 27 Feb 2003, Sreedhar_Baddigam wrote: > Hi, > > We want to use Hostbased Authentication in OpenSSH 3.4p1 completely based on > rhosts or shosts. Don't want to have any keys exchange between server and > client. [snip] You will need to populate ssh_known_hosts with the other server's public keys for Hostbased Authentication to work. For further discussion check the archives around Jul 2002 with Subject: Re: OpenSSH 3.4p1 hostbased auth - howto? -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From fcusack at fcusack.com Thu Feb 27 10:13:25 2003 From: fcusack at fcusack.com (Frank Cusack) Date: Wed, 26 Feb 2003 15:13:25 -0800 Subject: PAM merge from FreeBSD In-Reply-To: ; from des@ofug.org on Wed, Feb 26, 2003 at 08:42:49PM +0100 References: <3E1E2593.3070204@mindrot.org> <20030109214943.A29970@google.com> <20030226082622.A6086@google.com> Message-ID: <20030226151325.B6826@google.com> On Wed, Feb 26, 2003 at 08:42:49PM +0100, Dag-Erling Smorgrav wrote: > Frank Cusack writes: > > I mean, you're still stuck in the conv. > > function until the info response comes back, anyway. How do (will) > > you handle restarting the authentication (client sends USERAUTH_REQUEST > > instead of USERAUTH_INFO_RESPONSE)? > > That is a separate issue which neither the old nor the new code address. I submitted a patch for this, against the old code, on 2002-01-11. Not very pretty, but it does get the job done. When I say "submitted" I just mean to the mailing list. /fc From des at ofug.org Thu Feb 27 10:26:19 2003 From: des at ofug.org (Dag-Erling Smorgrav) Date: Thu, 27 Feb 2003 00:26:19 +0100 Subject: PAM merge from FreeBSD In-Reply-To: <20030226151325.B6826@google.com> (Frank Cusack's message of "Wed, 26 Feb 2003 15:13:25 -0800") References: <3E1E2593.3070204@mindrot.org> <20030109214943.A29970@google.com> <20030226082622.A6086@google.com> <20030226151325.B6826@google.com> Message-ID: Frank Cusack writes: > I submitted a patch for this, against the old code, on 2002-01-11. > Not very pretty, but it does get the job done. When I say "submitted" > I just mean to the mailing list. Please mail me a copy off-list. DES -- Dag-Erling Smorgrav - des at ofug.org From bugzilla-daemon at mindrot.org Thu Feb 27 11:20:34 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 27 Feb 2003 11:20:34 +1100 (EST) Subject: [Bug 341] Return Code unpredictable Message-ID: <20030227002034.05B44645FC@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=341 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-02-27 11:20 ------- It is certainly fixed in -current: [djm at xenon djm]$ for x in 1 2 3 4 5 6 7 8 9 10 ; do ssh djm at localhost exit $x ; echo $? ; done 1 2 3 4 5 6 7 8 9 10 It is also in the regress tests. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From cmadams at hiwaay.net Thu Feb 27 13:03:41 2003 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 26 Feb 2003 20:03:41 -0600 Subject: Update for Tru64 Unix Message-ID: <20030227020341.GA559011@hiwaay.net> Here is a long-overdue (sorry about that) patch for Tru64. It is pretty minor mostly (minor formatting and removal of a couple of unneeded calls), and it disables post-auth privsep (so that OpenSSH will work "out of the box" on Tru64, avoiding the many questions). I'm also looking at getting setproctitle working. For Tru64 4.x, it isn't a big deal (normal PS_USE_CLOBBER_ARGV will work), but Tru64 5.x aligns the argv elements on 64 bit boundaries, making them look non-contiguous, when in fact they are (and overwriting the bits in between really does show up). I'll work on that and try to get a patch out soon (it'll more-or-less be based on the FFR code in sendmail that was based on what I sent them). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. diff -urN openssh-SNAP-20030226/README.privsep openssh/README.privsep --- openssh-SNAP-20030226/README.privsep Tue Jun 25 19:43:57 2002 +++ openssh/README.privsep Wed Feb 26 19:48:37 2003 @@ -43,6 +43,10 @@ configuration. PAMAuthenticationViaKbdInt does not function with privsep. +On Compaq Tru64 Unix, only the pre-authentication part of privsep is +supported. Post-authentication privsep is disabled automatically (so +you won't see the additional process mentioned below). + Note that for a normal interactive login with a shell, enabling privsep will require 1 additional process per login session. diff -urN openssh-SNAP-20030226/auth-sia.c openssh/auth-sia.c --- openssh-SNAP-20030226/auth-sia.c Tue Jan 21 22:42:27 2003 +++ openssh/auth-sia.c Wed Feb 26 19:46:17 2003 @@ -45,27 +45,25 @@ extern int saved_argc; extern char **saved_argv; -extern int errno; - int auth_sia_password(Authctxt *authctxt, char *pass) { int ret; SIAENTITY *ent = NULL; const char *host; - char *user = authctxt->user; host = get_canonical_hostname(options.verify_reverse_mapping); - if (pass[0] == '\0') + if (!authctxt->user || !pass || pass[0] == '\0') return(0); - if (sia_ses_init(&ent, saved_argc, saved_argv, host, user, NULL, 0, - NULL) != SIASUCCESS) + if (sia_ses_init(&ent, saved_argc, saved_argv, host, authctxt->user, + NULL, 0, NULL) != SIASUCCESS) return(0); if ((ret = sia_ses_authent(NULL, pass, ent)) != SIASUCCESS) { - error("Couldn't authenticate %s from %s", user, host); + error("Couldn't authenticate %s from %s", authctxt->user, + host); if (ret & SIASTOP) sia_ses_release(&ent); return(0); @@ -77,48 +75,35 @@ } void -session_setup_sia(char *user, char *tty) +session_setup_sia(struct passwd *pw, char *tty) { - struct passwd *pw; SIAENTITY *ent = NULL; const char *host; - host = get_canonical_hostname (options.verify_reverse_mapping); + host = get_canonical_hostname(options.verify_reverse_mapping); - if (sia_ses_init(&ent, saved_argc, saved_argv, host, user, tty, 0, - NULL) != SIASUCCESS) { + if (sia_ses_init(&ent, saved_argc, saved_argv, host, pw->pw_name, tty, + 0, NULL) != SIASUCCESS) fatal("sia_ses_init failed"); - } - if ((pw = getpwnam(user)) == NULL) { - sia_ses_release(&ent); - fatal("getpwnam: no user: %s", user); - } if (sia_make_entity_pwd(pw, ent) != SIASUCCESS) { sia_ses_release(&ent); fatal("sia_make_entity_pwd failed"); } ent->authtype = SIA_A_NONE; - if (sia_ses_estab(sia_collect_trm, ent) != SIASUCCESS) { - fatal("Couldn't establish session for %s from %s", user, - host); - } - - if (setpriority(PRIO_PROCESS, 0, 0) == -1) { - sia_ses_release(&ent); - fatal("setpriority: %s", strerror (errno)); - } + if (sia_ses_estab(sia_collect_trm, ent) != SIASUCCESS) + fatal("Couldn't establish session for %s from %s", + pw->pw_name, host); - if (sia_ses_launch(sia_collect_trm, ent) != SIASUCCESS) { - fatal("Couldn't launch session for %s from %s", user, host); - } + if (sia_ses_launch(sia_collect_trm, ent) != SIASUCCESS) + fatal("Couldn't launch session for %s from %s", pw->pw_name, + host); sia_ses_release(&ent); - if (setreuid(geteuid(), geteuid()) < 0) { + if (setreuid(geteuid(), geteuid()) < 0) fatal("setreuid: %s", strerror(errno)); - } } #endif /* HAVE_OSF_SIA */ diff -urN openssh-SNAP-20030226/auth-sia.h openssh/auth-sia.h --- openssh-SNAP-20030226/auth-sia.h Fri Apr 12 10:36:08 2002 +++ openssh/auth-sia.h Wed Feb 26 19:43:34 2003 @@ -27,6 +27,6 @@ #ifdef HAVE_OSF_SIA int auth_sia_password(Authctxt *authctxt, char *pass); -void session_setup_sia(char *user, char *tty); +void session_setup_sia(struct passwd *pw, char *tty); #endif /* HAVE_OSF_SIA */ diff -urN openssh-SNAP-20030226/configure.ac openssh/configure.ac --- openssh-SNAP-20030226/configure.ac Sun Feb 23 22:45:43 2003 +++ openssh/configure.ac Wed Feb 26 19:43:34 2003 @@ -330,6 +330,7 @@ AC_MSG_RESULT(yes) AC_DEFINE(HAVE_OSF_SIA) AC_DEFINE(DISABLE_LOGIN) + AC_DEFINE(DISABLE_FD_PASSING) LIBS="$LIBS -lsecurity -ldb -lm -laud" else AC_MSG_RESULT(no) diff -urN openssh-SNAP-20030226/session.c openssh/session.c --- openssh-SNAP-20030226/session.c Sun Feb 23 20:04:02 2003 +++ openssh/session.c Wed Feb 26 19:43:34 2003 @@ -1320,7 +1320,7 @@ */ if (!options.use_login) { #ifdef HAVE_OSF_SIA - session_setup_sia(pw->pw_name, s->ttyfd == -1 ? NULL : s->tty); + session_setup_sia(pw, s->ttyfd == -1 ? NULL : s->tty); if (!check_quietlogin(s, command)) do_motd(); #else /* HAVE_OSF_SIA */ From sfrost at snowman.net Thu Feb 27 14:26:21 2003 From: sfrost at snowman.net (Stephen Frost) Date: Wed, 26 Feb 2003 22:26:21 -0500 Subject: PAM account failure, funny ssh error Message-ID: <20030227032621.GC3989@ns.snowman.net> Hey all, I'm getting a weird error from sshd: Feb 16 11:32:49 syslog at snowman sshd[28740]: fatal: monitor_read: unsupported request: 32 I'm running sshd with Simon's GSSAPI patch but I don't think that's the problem. The issue appears to be with how ssh reacts to a failure in the PAM account section. As in, when the PAM account modules return a failure, I get the message above instead of something more intelligent. I'm trying to set things up in such a way that authentication is done via Kerberos (or unix shadow if Kerberos fails) but authorization is done via LDAP (or unix shadow if LDAP fails), and I'm doing the LDAP portion in the 'account' PAM section. Any thoughts? Thanks, Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030226/1b261854/attachment.bin From dtucker at zip.com.au Thu Feb 27 23:32:22 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 27 Feb 2003 23:32:22 +1100 Subject: PAM account failure, funny ssh error References: <20030227032621.GC3989@ns.snowman.net> Message-ID: <3E5E0556.803F06C5@zip.com.au> Stephen Frost wrote: > Feb 16 11:32:49 syslog at snowman sshd[28740]: fatal: monitor_read: unsupported request: 32 I've seen similar errors caused by accounts with expired passwords, that might be worth checking. -- 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 sridharb at satyam.com Fri Feb 28 01:59:49 2003 From: sridharb at satyam.com (Sreedhar_Baddigam) Date: Thu, 27 Feb 2003 20:29:49 +0530 Subject: OpenSSH 3.4p1 hostbased authentication Message-ID: Hi Tim, Thanks for the information. I have gone through few posts in the archive as per your suggestion. I understand from them that populating ssh_known_hosts file with public key of client pcs comes under RhostsRSAAuthentication. We are looking to have openssh remote authentication work just with rhosts or shosts entries. Is it not possible to do that for any reason? Please correct me if I understood the concept of openssh communication wrong. best regards, Sreedhar. > ---------- > From: Tim Rice[SMTP:tim at multitalents.net] > Sent: Thursday, February 27, 2003 03:39 > To: Sreedhar_Baddigam > Cc: openssh-unix-dev at mindrot.org > Subject: Re: OpenSSH 3.4p1 hostbased authentication > > On Thu, 27 Feb 2003, Sreedhar_Baddigam wrote: > > > Hi, > > > > We want to use Hostbased Authentication in OpenSSH 3.4p1 completely > based on > > rhosts or shosts. Don't want to have any keys exchange between server > and > > client. > [snip] > > You will need to populate ssh_known_hosts with the other server's > public keys for Hostbased Authentication to work. > > For further discussion check the archives around Jul 2002 > with Subject: Re: OpenSSH 3.4p1 hostbased auth - howto? > > -- > Tim Rice Multitalents (707) 887-1469 > tim at multitalents.net > ************************************************************************** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. ************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030227/f6686929/attachment.html From abostick at mydoconline.com Fri Feb 28 04:57:35 2003 From: abostick at mydoconline.com (Aaron Bostick) Date: 27 Feb 2003 11:57:35 -0600 Subject: Unwanted reverse mapping of ip addresses Message-ID: <1046368655.2498.39.camel@bouki.mydoconline.com> Hi SSH developers, I am wondering if someone could help explain a behavior of sshd. From canohost.c, get_remote_hostname(), it seems sshd will always try to reverse lookup the ip address of any client that attaches to it. The verify_reverse_mapping flag just turns off the forward lookup through DNS of the clients hostname, once the hostname has been determined. I am using Solaris 8 with ssh 3.4p1, and this piece of code: debug3("Trying to reverse map address %.100s.", ntop); /* Map the IP address to a host name. */ if (getnameinfo((struct sockaddr *)&from, fromlen, name, sizeof(name), NULL, 0, NI_NAMEREQD) != 0) { /* Host name not found. Use ip address. */ log("Could not reverse map address %.100s.", ntop); return xstrdup(ntop); takes like 30 to 60 seconds to run if you have dns listed in your nsswitch.conf, which in many cases is needed. My question is, is this really necessary? Couldn't the verify_reverse_mapping flag turn off the above code as well? I compiled my own daemon to do so and my ssh prompt comes up immediately now with DNS turned on. I have read elsewhere that this may be a problem with a broken arp on solaris, but even on my mandrake 8.2 linux box, the sshd takes 5 to 10 seconds to run through this code before I get a login prompt? Is there any reason not to make this conditional on the verify_reverse_mapping flag or perhaps a flag of its own in sshd_config? Thanks a bunch for the help and please CC me on any reply as I do not subscribe to this list. -- Aaron Bostick Sr Network Architect CISSP #21728, CCIE #7988 Mydoconline.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/20030227/14a69731/attachment.bin From mouring at etoh.eviladmin.org Fri Feb 28 05:13:47 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 27 Feb 2003 12:13:47 -0600 (CST) Subject: OpenSSH 3.4p1 hostbased authentication In-Reply-To: Message-ID: My impression (skiming the manpages) that .rhosts/.shosts v1 only. So you may want to force the code into v1 mode for testing. - Ben On Thu, 27 Feb 2003, Sreedhar_Baddigam wrote: > Hi Tim, > > Thanks for the information. I have gone through few posts in the archive as > per your suggestion. I understand from them that populating ssh_known_hosts > file with public key of client pcs comes under RhostsRSAAuthentication. We > are looking to have openssh remote authentication work just with rhosts or > shosts entries. Is it not possible to do that for any reason? > > Please correct me if I understood the concept of openssh communication > wrong. > > best regards, > Sreedhar. > > > ---------- > > From: Tim Rice[SMTP:tim at multitalents.net] > > Sent: Thursday, February 27, 2003 03:39 > > To: Sreedhar_Baddigam > > Cc: openssh-unix-dev at mindrot.org > > Subject: Re: OpenSSH 3.4p1 hostbased authentication > > > > On Thu, 27 Feb 2003, Sreedhar_Baddigam wrote: > > > > > Hi, > > > > > > We want to use Hostbased Authentication in OpenSSH 3.4p1 completely > > based on > > > rhosts or shosts. Don't want to have any keys exchange between server > > and > > > client. > > [snip] > > > > You will need to populate ssh_known_hosts with the other server's > > public keys for Hostbased Authentication to work. > > > > For further discussion check the archives around Jul 2002 > > with Subject: Re: OpenSSH 3.4p1 hostbased auth - howto? > > > > -- > > Tim Rice Multitalents (707) 887-1469 > > tim at multitalents.net > > > ************************************************************************** > This email (including any attachments) is intended for the sole use of the > intended recipient/s and may contain material that is CONFIDENTIAL AND > PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or > distribution or forwarding of any or all of the contents in this message is > STRICTLY PROHIBITED. If you are not the intended recipient, please contact > the sender by email and delete all copies; your cooperation in this regard > is appreciated. > ************************************************************************** > From binder at arago.de Fri Feb 28 05:12:30 2003 From: binder at arago.de (Thomas Binder) Date: Thu, 27 Feb 2003 19:12:30 +0100 Subject: Unwanted reverse mapping of ip addresses In-Reply-To: <1046368655.2498.39.camel@bouki.mydoconline.com> References: <1046368655.2498.39.camel@bouki.mydoconline.com> Message-ID: <20030227181230.GA13789295@ohm.arago.de> Hi! On Thu, Feb 27, 2003 at 11:57:35AM -0600, Aaron Bostick wrote: > I am using Solaris 8 with ssh 3.4p1, and this piece of code: > > debug3("Trying to reverse map address %.100s.", ntop); > /* Map the IP address to a host name. */ > if (getnameinfo((struct sockaddr *)&from, fromlen, name, > sizeof(name), > NULL, 0, NI_NAMEREQD) != 0) { > /* Host name not found. Use ip address. */ > log("Could not reverse map address %.100s.", ntop); > return xstrdup(ntop); > > takes like 30 to 60 seconds to run if you have dns listed in your > nsswitch.conf, which in many cases is needed. It only takes that long if you've configured nameservers in /etc/resolv.conf that do not respond to queries. First check that everything's set up properly. If you still insist on sshd not making nameserver lookups, take a look at sshd's manpage, option '-u' in particular. Ciao Thomas From abostick at mydoconline.com Fri Feb 28 07:58:51 2003 From: abostick at mydoconline.com (Aaron Bostick) Date: 27 Feb 2003 14:58:51 -0600 Subject: Unwanted reverse mapping of ip addresses In-Reply-To: <20030227181230.GA13789295@ohm.arago.de> References: <1046368655.2498.39.camel@bouki.mydoconline.com> <20030227181230.GA13789295@ohm.arago.de> Message-ID: <1046379531.2498.42.camel@bouki.mydoconline.com> Thomas, Thanks for the pointer! That -u0 was hidden in the man page but it works great! To think I recompiled and built my own package when all I had to do was change the startup script...hehe Aaron On Thu, 2003-02-27 at 12:12, Thomas Binder wrote: > Hi! > > On Thu, Feb 27, 2003 at 11:57:35AM -0600, Aaron Bostick wrote: > > I am using Solaris 8 with ssh 3.4p1, and this piece of code: > > > > debug3("Trying to reverse map address %.100s.", ntop); > > /* Map the IP address to a host name. */ > > if (getnameinfo((struct sockaddr *)&from, fromlen, name, > > sizeof(name), > > NULL, 0, NI_NAMEREQD) != 0) { > > /* Host name not found. Use ip address. */ > > log("Could not reverse map address %.100s.", ntop); > > return xstrdup(ntop); > > > > takes like 30 to 60 seconds to run if you have dns listed in your > > nsswitch.conf, which in many cases is needed. > > It only takes that long if you've configured nameservers in > /etc/resolv.conf that do not respond to queries. First check that > everything's set up properly. > > If you still insist on sshd not making nameserver lookups, take a > look at sshd's manpage, option '-u' in particular. > > > Ciao > > Thomas -- Aaron Bostick Sr Network Architect CISSP #21728, CCIE #7988 Mydoconline.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/20030227/5339b4ae/attachment.bin From markus at openbsd.org Fri Feb 28 08:10:37 2003 From: markus at openbsd.org (Markus Friedl) Date: Thu, 27 Feb 2003 22:10:37 +0100 Subject: OpenSSH 3.4p1 hostbased authentication In-Reply-To: References: Message-ID: <20030227211037.GC1943@folly> On Thu, Feb 27, 2003 at 12:13:47PM -0600, Ben Lindstrom wrote: > My impression (skiming the manpages) that .rhosts/.shosts v1 only. no, it's for both protocols. there should be no difference. From mouring at etoh.eviladmin.org Fri Feb 28 08:28:40 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 27 Feb 2003 15:28:40 -0600 (CST) Subject: OpenSSH 3.4p1 hostbased authentication In-Reply-To: <20030227211037.GC1943@folly> Message-ID: On Thu, 27 Feb 2003, Markus Friedl wrote: > On Thu, Feb 27, 2003 at 12:13:47PM -0600, Ben Lindstrom wrote: > > My impression (skiming the manpages) that .rhosts/.shosts v1 only. > > no, it's for both protocols. there should be no difference. > So other than RhostsIgnore. I as an admin have no control to stop rhost/shosts usage on my servers for v2? You sure Markus? RhostsAuthentication Specifies whether authentication using rhosts or /etc/hosts.equiv files is sufficient. Normally, this method should not be permit- ted because it is insecure. RhostsRSAAuthentication should be used instead, because it performs RSA-based host authentication in addition to normal rhosts or /etc/hosts.equiv authentication. The default is ``no''. This option applies to protocol version 1 only. RhostsRSAAuthentication Specifies whether rhosts or /etc/hosts.equiv authentication to- gether with successful RSA host authentication is allowed. The default is ``no''. This option applies to protocol version 1 on- ly. From djm at mindrot.org Fri Feb 28 09:32:48 2003 From: djm at mindrot.org (Damien Miller) Date: Fri, 28 Feb 2003 09:32:48 +1100 Subject: PAM account failure, funny ssh error In-Reply-To: <3E5E0556.803F06C5@zip.com.au> References: <20030227032621.GC3989@ns.snowman.net> <3E5E0556.803F06C5@zip.com.au> Message-ID: <3E5E9210.8020003@mindrot.org> Darren Tucker wrote: > Stephen Frost wrote: > >>Feb 16 11:32:49 syslog at snowman sshd[28740]: fatal: monitor_read: unsupported request: 32 > > > I've seen similar errors caused by accounts with expired passwords, that > might be worth checking. I think that this was related to: - markus at cvs.openbsd.org 2003/02/06 21:22:43 [auth1.c auth2.c] undo broken fix for #387, fixes #486 which is fixed in CVS -current From dtucker at zip.com.au Fri Feb 28 12:17:50 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 28 Feb 2003 12:17:50 +1100 Subject: PAM account failure, funny ssh error References: <20030227032621.GC3989@ns.snowman.net> <3E5E0556.803F06C5@zip.com.au> <3E5E9210.8020003@mindrot.org> Message-ID: <3E5EB8BE.AB16E90A@zip.com.au> Damien Miller wrote: > Darren Tucker wrote: > > I've seen similar errors caused by accounts with expired passwords, that > > might be worth checking. > > I think that this was related to: > > - markus at cvs.openbsd.org 2003/02/06 21:22:43 > [auth1.c auth2.c] > undo broken fix for #387, fixes #486 Doesn't appear to be, I get the same failure with -current right now (Solaris 8, --with-pam). Someone reported this problem while testing the password expiry patches. I reproduced it (different monitor request #, but otherwise the same) but didn't bother following it up because the PAM stuff was shortly to be replaced. Is it going to survive long enough to warrant tracking this down? -Daz. debug1: PAM Password authentication accepted for user "testuser" debug3: mm_answer_authpassword: sending result 1 debug3: mm_request_send entering: type 11 debug2: pam_acct_mgmt() = 17 PAM rejected by account configuration[17]: User account has expired Failed password for testuser from 127.0.0.1 port 34410 ssh2 debug3: mm_request_receive entering debug3: mm_auth_password: user authenticated Accepted password for testuser from 127.0.0.1 port 34410 ssh2 debug3: mm_send_keystate: Sending new keys: 114df0 11bec8 debug3: mm_newkeys_to_blob: converting 114df0 debug3: mm_newkeys_to_blob: converting 11bec8 debug3: mm_send_keystate: New keys have been sent debug3: mm_send_keystate: Sending compression state debug3: mm_request_send entering: type 24 debug3: mm_send_keystate: Finished sending state debug3: monitor_read: checking request 24 monitor_read: unsupported request: 24 debug1: Calling cleanup 0x3df58(0x0) -- Darren Tucker (dtucker at zip.com.au) GPG Fingerprint 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 Feb 28 19:41:16 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 28 Feb 2003 19:41:16 +1100 Subject: [PATCH] Clean up failed login logging. Message-ID: <3E5F20AC.7FF1164C@zip.com.au> Hi All. As noted in a previous post, the logging of failed user logins is somewhat spread out. This patch creates a record_failed_login() function in sshlogin.c and moves the AIX and UNICOS code to it, eliminating 3 #ifdefs from the main code. It also provides an obvious place to add the code for any other platforms that support this. I've tested this on AIX 4.3.3. Wendy Palm was kind enough to test it on UNICOS (this patch includes the cast required to placate the Cray compiler). Note: this will call record_failed_login() in the case of a login attempt by a non-existant user. This is good for AIX (loginfailed replaces the username with UNKNOWN_USER). I'm not sure if that's the right thing on UNICOS or not. -- 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: auth.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth.c,v retrieving revision 1.67 diff -u -r1.67 auth.c --- auth.c 18 Jan 2003 05:24:06 -0000 1.67 +++ auth.c 25 Feb 2003 09:52:31 -0000 @@ -268,13 +268,10 @@ get_remote_port(), info); -#ifdef WITH_AIXAUTHENTICATE if (authenticated == 0 && strcmp(method, "password") == 0) - loginfailed(authctxt->user, - get_canonical_hostname(options.verify_reverse_mapping), - "ssh"); -#endif /* WITH_AIXAUTHENTICATE */ - + record_failed_login(authctxt->user, + get_canonical_hostname(options.verify_reverse_mapping), + "ssh"); } /* @@ -496,11 +493,9 @@ if (pw == NULL) { log("Illegal user %.100s from %.100s", user, get_remote_ipaddr()); -#ifdef WITH_AIXAUTHENTICATE - loginfailed(user, + record_failed_login(user, get_canonical_hostname(options.verify_reverse_mapping), "ssh"); -#endif return (NULL); } if (!allowed_user(pw)) Index: auth1.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth1.c,v retrieving revision 1.79 diff -u -r1.79 auth1.c --- auth1.c 24 Feb 2003 00:59:27 -0000 1.79 +++ auth1.c 25 Feb 2003 09:45:10 -0000 @@ -311,8 +311,6 @@ authctxt->user); #ifdef _UNICOS - if (type == SSH_CMSG_AUTH_PASSWORD && !authenticated) - cray_login_failure(authctxt->user, IA_UDBERR); if (authenticated && cray_access_denied(authctxt->user)) { authenticated = 0; fatal("Access denied for user %s.",authctxt->user); Index: auth2.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth2.c,v retrieving revision 1.112 diff -u -r1.112 auth2.c --- auth2.c 24 Feb 2003 00:59:27 -0000 1.112 +++ auth2.c 25 Feb 2003 09:45:10 -0000 @@ -241,10 +241,6 @@ if (authctxt->failures++ > AUTH_FAIL_MAX) { packet_disconnect(AUTH_FAIL_MSG, authctxt->user); } -#ifdef _UNICOS - if (strcmp(method, "password") == 0) - cray_login_failure(authctxt->user, IA_UDBERR); -#endif /* _UNICOS */ methods = authmethods_get(); packet_start(SSH2_MSG_USERAUTH_FAILURE); packet_put_cstring(methods); Index: sshlogin.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/sshlogin.c,v retrieving revision 1.9 diff -u -r1.9 sshlogin.c --- sshlogin.c 1 Jan 2003 23:43:56 -0000 1.9 +++ sshlogin.c 28 Feb 2003 08:01:49 -0000 @@ -99,3 +99,15 @@ login_logout(li); login_free_entry(li); } + +/* Record a failed login attempt. */ +void +record_failed_login(const char *user, const char *host, const char *ttyname) +{ +#ifdef WITH_AIXAUTHENTICATE + loginfailed(user, host, ttyname); +#endif +#ifdef _UNICOS + cray_login_failure((char *)user, IA_UDBERR); +#endif /* _UNICOS */ +}