From bugzilla-daemon at mindrot.org Wed Jan 1 02:26:44 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 1 Jan 2003 02:26:44 +1100 (EST) Subject: [Bug 461] New: ssh-copy-id is messy when invoked with no arguments Message-ID: <20021231152644.D522D6451F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=461 Summary: ssh-copy-id is messy when invoked with no arguments Product: Portable OpenSSH Version: -current Platform: All URL: http://bugs.debian.org/71376 OS/Version: Linux Status: NEW Severity: minor Priority: P2 Component: Miscellaneous AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: cjwatson at debian.org $ ssh-copy-id Pseudo-terminal will not be allocated because stdin is not a terminal. ssh: umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys: Name or service not known Now try logging into the machine, with "ssh ''", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting. I'll attach a patch in a moment to make it display usage output instead when invoked 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 Wed Jan 1 02:28:23 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 1 Jan 2003 02:28:23 +1100 (EST) Subject: [Bug 461] ssh-copy-id is messy when invoked with no arguments Message-ID: <20021231152823.4F6C864538@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=461 ------- Additional Comments From cjwatson at debian.org 2003-01-01 02:28 ------- Created an attachment (id=188) --> (http://bugzilla.mindrot.org/attachment.cgi?id=188&action=view) Output usage message if invoked with no arguments or "help"-like arguments ------- 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 Jan 1 03:40:35 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 1 Jan 2003 03:40:35 +1100 (EST) Subject: [Bug 459] ssh-keygen doesn't know how to export private keys Message-ID: <20021231164035.B3C8364519@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=459 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From markus at openbsd.org 2003-01-01 03:40 ------- yes, but the manpage says that a PUBLIC key will be printed. ------- 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 Jan 1 03:43:51 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 1 Jan 2003 03:43:51 +1100 (EST) Subject: [Bug 459] ssh-keygen doesn't know how to export private keys Message-ID: <20021231164351.13EE66451E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=459 ------- Additional Comments From markus at openbsd.org 2003-01-01 03:43 ------- you can however try to port putty's code for reading/writing ssh.com private key files. also note that the manpage says: .Sq SECSH Public Key File Format and there is no matching definition for _private_ keys. ------- 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 Jan 1 04:46:06 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 1 Jan 2003 04:46:06 +1100 (EST) Subject: [Bug 459] ssh-keygen doesn't know how to export private keys Message-ID: <20021231174606.140856451E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=459 ------- Additional Comments From cjwatson at debian.org 2003-01-01 04:46 ------- It does say that something will be printed in a public key format (although I wasn't sure that the name of the format might not simply have been badly worded), but the statement that it will read private OpenSSH key files is quite confusing in this context. In fact, at least in the SSH2 case, it reads the private key file, realizes it can't do anything with it, and then finds and reads the public key file instead. I'll have a look at the PuTTY code, or possibly just talk to Simon. :) I see sshcom_write() here. Thanks. Would you consider allowing this to be left open as an enhancement request? The original bug reporter (Tomasz Cichecki ) said that he wanted to try out an ssh.com server without disturbing existing use, but was unable to do so because he couldn't export the private key. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bryanh at giraffe-data.com Wed Jan 1 05:47:07 2003 From: bryanh at giraffe-data.com (Bryan Henderson) Date: Tue, 31 Dec 2002 18:47:07 +0000 Subject: Inheriting environment - sshd server to shell child Message-ID: This was mysteriously bounced from the list when I sent it last week, so here's another try. The context is that I am suggesting that there be an option to allow shells spawned by sshd to inherit the environment of the sshd process. Today, Sshd does this for the special case of Cygwin, but starts the environment fresh on every other platform. >All critical variables should be in your /etc/profile or your csh/tcsh >equiv. I disagree. I know that is traditionally where these variables are set, but it isn't the logical place to do it, which is why I don't have my system set up that way. /etc/profile and other shell profiles are the appropriate place to set variables that pertain to the (interactive) use of that shell. But some environment variable settings apply to any program running anywhere, under any shell or not involving a shell at all. Some variables could conceivably be necessary in order to start up the shell and run its profile. Going back to when the traditional roles of Init, login programs, shells, shell profiles, and such were invented, the parameters of system-wide scope were compiled in to every program installed on the system. That's still true of most of them. But the modern trend is toward more binary portability, and I follow that. I prefer, for example, not to have any file paths compiled into programs I run. I use the environment variables they provide to give path information. So I maintain environment variables. Init sets them via initscript in every process it spawns. A few are even set via kernel boot parameters and inherited by all of Init's progeny. Traditional logins work fine because I use the -p option on Login ("preserve environment"). Ssh via Openssh defeats the plan, though. Openssh would have me set those environment variables one place for every process _except_ shells spawned by sshd, but in each shell profile for shells spawned by sshd. My particular system, of course, is not the issue. I'll run the sshd that works for me. The issue is that there is more logic in retaining the environment than in discarding it, and I believe the Cygwin requirement is based in the basic rightness of that, not any fundamental difference between Cygwin and real Unix. -- Bryan Henderson Phone 408-621-2000 San Jose, California From szukw000 at students.uni-mainz.de Wed Jan 1 08:49:57 2003 From: szukw000 at students.uni-mainz.de (winfried szukalski) Date: Tue, 31 Dec 2002 21:49:57 +0000 Subject: openssh-3.5p1 && heimdal Message-ID: <20021231214957.GA14703@localhost> I had compiled and installed heimdal-0.5.1 . Then I wanted to compile openssh-3.5p1. These should be my options: flags=CFLAGS='-Wall -O2 -march=athlon -mcpu=athlon' do_prelude: chown -R root.root * $(flags) ./configure --prefix=/usr \ --mandir=/usr/share/man \ --infodir=/usr/share/info \ --sysconfdir=/etc/ssh \ --libexecdir=/usr/lib/ssh \ --with-tcp-wrappers \ --with-pam \ --with-kerberos5=/usr/local/heimdal \ --with-ssl-dir=/usr \ --with-mantype=man \ --with-md5-passwords \ --with-shadow \ --with-ipv4-default But I had to remove the kerberos5 option: /usr/local/heimdal/lib/libroken.a(getprogname.o): In function `get_progname': getprogname.o(.text+0x10): multiple definition of `get_progname' /usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14. openbsd-compat//libopenbsd-compat.a(bsd-misc.o):/home/net/SSH/openssh-3.5p1/openbsd-compat/bsd-misc.c:30: first defined here /usr/bin/ld: Warning: size of symbol `get_progname' changed from 10 to 9 in getprogname.o collect2: ld returned 1 exit status make: *** [ssh] Error 1 Why do you allow kerberos5 support? winfried From bugzilla-daemon at mindrot.org Wed Jan 1 23:15:12 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 1 Jan 2003 23:15:12 +1100 (EST) Subject: [Bug 459] ssh-keygen doesn't know how to export private keys Message-ID: <20030101121512.A220364508@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=459 ------- Additional Comments From markus at openbsd.org 2003-01-01 23:15 ------- it's still possible to convert a private ssh.com key to openssh format, but not vice versa. we don't intend to provide support for migrating waway _from_ openssh ------- 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 Jan 2 03:28:07 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 2 Jan 2003 03:28:07 +1100 (EST) Subject: [Bug 462] New: compile failure with openssl 0.9.7 Message-ID: <20030101162807.61ED564518@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=462 Summary: compile failure with openssl 0.9.7 Product: Portable OpenSSH Version: 3.5p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: madhon at madhon.co.uk on slackware-current with openssl 0.9.7 the build fails to make as follows make[1]: Entering directory `/tmp/openssh-3.5p1/openbsd-compat' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/tmp/openssh-3.5p1/openbsd-compat' i386-slackware-linux-gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o -L. -Lopenbsd-compat/ -lssh -lopenbsd-compat - lutil -lz -lnsl -lcrypto -lcrypt ./libssh.a(rsa.o)(.text+0x2a4): In funcion `rsa_generate_additional_parameters' : : undefined reference to `BN_mod' ./libssh.a(rsa.o)(.text+0x2a6): In funcion `rsa_generate_additional_parameters' : : undefined reference to `BN_mod' collect2: ld returned 1 exit status make: *** [ssh[ Error 1 configured as follows CFLAGS="-O2 -march=i386 -mcpu=i686 -Wall" ./configure --prefix=/usr \ --sysconfdir=/etc/ssh \ --without-pam \ --with-md5-passwords \ --with-tcp-wrappers \ --with-default- path=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin \ --with-ipv4-default \ i386-slackware-linux OpenSSH has been configured with the following options: User binaries: /usr/bin System binaries: /usr/sbin Configuration files: /etc/ssh Askpass program: /usr/libexec/ssh-askpass Manual pages: /usr/man/manX PID file: /var/run Privilege separation chroot path: /var/empty sshd default user PATH: /usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin Manpage format: doc 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: yes BSD Auth support: no Random number source: OpenSSL internal ONLY Host: i386-slackware-linux-gnu Compiler: i386-slackware-linux-gcc Compiler flags: -O2 -march=i386 -mcpu=i686 -Wall -Wall -Wpointer-arith -Wno- uninitialized Preprocessor flags: Linker flags: Libraries: -lwrap -lutil -lz -lnsl -lcrypto -lcrypt ------- 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 Jan 2 04:04:46 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 2 Jan 2003 04:04:46 +1100 (EST) Subject: [Bug 462] compile failure with openssl 0.9.7 Message-ID: <20030101170446.6B5976453B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=462 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From markus at openbsd.org 2003-01-02 04:04 ------- i think your openssl header files and libaries are not matching ------- 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 Jan 2 06:22:50 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 2 Jan 2003 06:22:50 +1100 (EST) Subject: [Bug 462] compile failure with openssl 0.9.7 Message-ID: <20030101192250.A7A876453B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=462 madhon at madhon.co.uk changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Additional Comments From madhon at madhon.co.uk 2003-01-02 06:22 ------- just removed all traces of openssl, recompiled and installed it, and still the same error. if what you say is true wouldnt it also stop me from compiling anything else that uses openssl (apache 2, php, curl, sasl to name just a few that ive recompiled using the new openssl fine) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From stevesk at pobox.com Thu Jan 2 10:42:12 2003 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 1 Jan 2003 15:42:12 -0800 Subject: sshd doesn't log hostname into utmp correctly [resend] In-Reply-To: References: <20020819211902.GA27268@scott.crlsca.adelphia.net> <20020820142757.GB28367@scott.crlsca.adelphia.net> <20020820152020.GC28367@scott.crlsca.adelphia.net> <20021227203233.GF7647@scott.crlsca.adelphia.net> Message-ID: <20030101234212.GA3204@scott.crlsca.adelphia.net> On Tue, Dec 31, 2002 at 12:55:03AM +0900, Hajimu UMEMOTO wrote: > stevesk> is that the only missing piece? i thought there was more? > stevesk> record_utmp_only()? > > Yup, it was the missing piece only for utmp part. There is still > missing piece for utmpx part. Since FreeBSD doesn't have utmpx yet, > at least it was sufficient for FreeBSD. > I attached the full missing piece in this mail. looks good, thank you. i will commit that. From bugzilla-daemon at mindrot.org Thu Jan 2 10:47:32 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 2 Jan 2003 10:47:32 +1100 (EST) Subject: [Bug 462] compile failure with openssl 0.9.7 Message-ID: <20030101234732.B6B496455F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=462 ------- Additional Comments From dtucker at zip.com.au 2003-01-02 10:47 ------- Try running the "findssl.sh" script from http://www.zip.com.au/~dtucker/openssh/ to see if there's any libraries or headers you missed. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From stevesk at pobox.com Thu Jan 2 11:04:53 2003 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 1 Jan 2003 16:04:53 -0800 Subject: [PATCH] Password expiry with Privsep and PAM In-Reply-To: <3DF5E344.E1CAE31D@zip.com.au> References: <3DF5E344.E1CAE31D@zip.com.au> Message-ID: <20030102000453.GB3204@scott.crlsca.adelphia.net> On Tue, Dec 10, 2002 at 11:51:16PM +1100, Darren Tucker wrote: > I used some parts of Michael Steffens' patch (bugid #423) to make it > work on HP-UX. > > +/* HP-UX doesn't like credentials to be deleted. Skip and rely on pam_end() */ > +#ifndef __hpux > if (__pamh && creds_set) { > pam_retval = pam_setcred(__pamh, PAM_DELETE_CRED); > if (pam_retval != PAM_SUCCESS) > debug("Cannot delete credentials[%d]: %.200s", > pam_retval, PAM_STRERROR(__pamh, pam_retval)); > } > +#endif this is a long-standing and for the most part non-issue that also effects certain Solaris PAM versions (HP PAM started with a Sun codebase). a search of the archives will show a lot of discussion. however, we don't need to #ifndef __hpux, as that's just a debug, and it shouldn't make anything not work. From bugzilla-daemon at mindrot.org Thu Jan 2 11:53:00 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 2 Jan 2003 11:53:00 +1100 (EST) Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20030102005300.C864064516@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From stevesk at pobox.com 2003-01-02 11:52 ------- regarding log() clash, shouldn't the HP libsec log() be static or renamed or ? ------- 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 Jan 2 11:58:59 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 2 Jan 2003 11:58:59 +1100 (EST) Subject: [Bug 459] ssh-keygen doesn't know how to export private keys Message-ID: <20030102005859.94C986451A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=459 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED ------- Additional Comments From djm at mindrot.org 2003-01-02 11:58 ------- That being said - OpenSSH's protocol 2 keys are in a standard PEM format which you can dump out using "openssl rsa -noout -text -in .ssh/id_rsa" ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From stevesk at pobox.com Thu Jan 2 12:56:07 2003 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 1 Jan 2003 17:56:07 -0800 Subject: [PATCH] PAM chauthtok + Privsep In-Reply-To: <3E045A58.285069C2@zip.com.au> References: <3E045A58.285069C2@zip.com.au> Message-ID: <20030102015607.GD3204@scott.crlsca.adelphia.net> On Sat, Dec 21, 2002 at 11:11:04PM +1100, Darren Tucker wrote: > Index: session.c > =================================================================== > RCS file: /cvs/openssh/session.c,v > retrieving revision 1.222 > diff -u -r1.222 session.c > --- session.c 26 Sep 2002 00:38:50 -0000 1.222 > +++ session.c 21 Dec 2002 11:39:07 -0000 > @@ -454,7 +454,6 @@ > session_proctitle(s); > > #if defined(USE_PAM) > - do_pam_session(s->pw->pw_name, NULL); > do_pam_setcred(1); > if (is_pam_password_change_required()) > packet_disconnect("Password change required but no " > if (check_quietlogin(s, command)) > return; > @@ -1238,6 +1242,12 @@ > * Reestablish them here. > */ > do_pam_setcred(0); > + > + /* > + * We need to open the session here because PAM on HP-UX does not > + * work after the call to permanently_set_uid. > + */ > + do_pam_session(pw->pw_name,NULL); > # endif /* USE_PAM */ > # if defined(WITH_IRIX_PROJECT) || defined(WITH_IRIX_JOBS) || defined(WITH_IRIX_ARRAY) > irix_setusercontext(pw); this should be separated out as it's addressing a different problem: running session modules as root. i think we have agreement that a system service like sshd really needs to run PAM modules as root, since there is no mechanism in the API for a module to indicate privilege requirements to a consumer, or a mechanism for a consumer to determine the highest privilege required of all configured service modules. on hp-ux, in the trusted case, the pam_unix session module needs root because it wants to write in /tcb. so, we want to do this, but i am not sure this is the "correct" way to do this. i'm not saying it's wrong, i want to make sure it is correct. we want to be very careful moving this stuff around. From stevesk at pobox.com Thu Jan 2 13:04:46 2003 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 1 Jan 2003 18:04:46 -0800 Subject: Inheriting environment - sshd server to shell child In-Reply-To: References: Message-ID: <20030102020446.GE3204@scott.crlsca.adelphia.net> On Tue, Dec 31, 2002 at 06:47:07PM +0000, Bryan Henderson wrote: > So I maintain environment variables. Init sets them via initscript in > every process it spawns. A few are even set via kernel boot > parameters and inherited by all of Init's progeny. Traditional logins > work fine because I use the -p option on Login ("preserve > environment"). Ssh via Openssh defeats the plan, though. Openssh > would have me set those environment variables one place for every > process _except_ shells spawned by sshd, but in each shell profile for > shells spawned by sshd. you are asking for a sshd login -p equivalent? obviously, right now the default deny behaviour used for the environment is correct. From stevesk at pobox.com Thu Jan 2 13:36:03 2003 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 1 Jan 2003 18:36:03 -0800 Subject: [PATCH] Password expiry with Privsep and PAM In-Reply-To: <20021210201900.GA6600@foo.birdnet.se> References: <3DF6458C.41915B51@zip.com.au> <20021210201900.GA6600@foo.birdnet.se> Message-ID: <20030102023603.GF3204@scott.crlsca.adelphia.net> On Tue, Dec 10, 2002 at 09:19:01PM +0100, Peter Stuge wrote: > On Wed, Dec 11, 2002 at 06:50:36AM +1100, Darren Tucker wrote: > > As Ben said, using /bin/passwd in v2's (pre-session) PASSWD_CHANGEREQ > > requires writing expect-like functionality that would be very hard to > > get right across all platforms. > > Would it really? Remember that this project has a lot of good people coming > from different platforms. Also keep in mind that the PASSWD_CHANGEREQ > protocol is the single smallest denominator, severly limiting what needs to > be supported. I'm thinking all that can be expected is for sshd to handle > cases where passwd wants either the old or the new password, sshd doesn't > have any other information at that time and no real way to get any either, > unless the protocol is extended, right? i think it would be ugly. > Two scenarios become possible: > > 1. openssh implements all neccessary local password changing stuff - PITA > overhead but when done a lot lower "instance" overhead, the PASSWD_CHANGEREQ > becomes more lightweight. However, openssh might have to deal with vendor > quux's broken system yet another time. this is what tatu ssh did and ssh.com does. PASSWD_CHANGEREQ fits nicely with this. but it's ugly and a maintenance nightmare too. > 2. openssh uses passwd because of law of least resistance, this is the > simplest path to go. When vendor xyzzy ends up having a passwd that > requires more capabilities than sshd has while in PASSWD_CHANGEREQ they can > either fix their passwd or try to convince us that we should switch to (1). > > Set up an easy scheme to add support for platforms with (2) and I think it'd > happen pretty quickly. i don't see it as easy, but if it can be done simply it would be nice. i do really like the idea of using passwd. i also like PAM support, and i think darren is close on that. From stevesk at pobox.com Thu Jan 2 13:51:26 2003 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 1 Jan 2003 18:51:26 -0800 Subject: [PATCH] Password expiry with Privsep and PAM In-Reply-To: References: <20021210160142.A6523@ii.uib.no> Message-ID: <20030102025126.GG3204@scott.crlsca.adelphia.net> On Tue, Dec 10, 2002 at 11:11:01AM -0600, Ben Lindstrom wrote: > I know Darren wrote one to use /bin/passwd but after we both looked at it > we pretty much decided it was not something we wanted to handle, but the > more I think about this.. the more I'm starting to agree with Markus. No > matter the additional risks of changing passwords after the tty for v1 and > v2 has been open it should be done that way. This is just getting way to > complex to even manage in my head. yes, i agree. if we can implement password change after authentication securely, then i think we can change the spec. complexity is the issue, we can ignore a MUST for now if it weighs on the side of security. From bugzilla-daemon at mindrot.org Thu Jan 2 13:59:04 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 2 Jan 2003 13:59:04 +1100 (EST) Subject: [Bug 282] ttymodes sent can be invalid Message-ID: <20030102025904.C20A864574@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=282 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER ------- Additional Comments From stevesk at pobox.com 2003-01-02 13:59 ------- no linux person cares to investigate so we close this. re-open if you have an answer. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From code at pizzashack.org Thu Jan 2 17:13:08 2003 From: code at pizzashack.org (Derek Martin) Date: Thu, 2 Jan 2003 01:13:08 -0500 Subject: rssh 1.0.4 released Message-ID: <20030102061308.GO10629@sophic.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks, Today I released rssh 1.0.4. rssh is a small replacement shell that provides the ability for system administrators to give specific users access to a given system via scp or sftp only. For downloads or more information, visit the rssh homepage: http://www.pizzashack.org/rssh This release fixes a stupid bug caused by a failure to properly check the return value of a function call. - -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+E9h0djdlQoHP510RApw5AJ0SD9GPJErR6DZemSoE3Gpv/hAdtQCgkM4f DgdyMZ2by7UYdOHy2pnRfXY= =Jo5T -----END PGP SIGNATURE----- From dtucker at zip.com.au Thu Jan 2 21:36:56 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 02 Jan 2003 21:36:56 +1100 Subject: [PATCH] Password expiry with Privsep and PAM References: <3DF6458C.41915B51@zip.com.au> <20021210201900.GA6600@foo.birdnet.se> <20030102023603.GF3204@scott.crlsca.adelphia.net> Message-ID: <3E141648.404CAA9C@zip.com.au> Kevin Steves wrote: > i do really like the idea of using passwd. Originally I didn't but having tried a bunch of other ways I do now :-) As Jan-Frode Myklebust pointed out, using /bin/passwd also makes sure you obey whatever password complexity rules are set up (eg /etc/default/passwd on Solaris or /etc/security/user on AIX). Otherwise, you need a bunch of additional platform-specific code to enforce that. -- 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 Thu Jan 2 21:41:59 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 02 Jan 2003 21:41:59 +1100 Subject: [PATCH] PAM chauthtok + Privsep References: <3E045A58.285069C2@zip.com.au> <20030102015607.GD3204@scott.crlsca.adelphia.net> Message-ID: <3E141777.7FBEFD53@zip.com.au> Kevin Steves wrote: > this should be separated out as it's addressing a different problem: > running session modules as root. OK, point taken. They're there because I wanted to make sure what I was trying worked on Trusted HP-UX. I'll remove those bits and re-post the patch in a day or two. -- 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 ajith at noida.hcltech.com Thu Jan 2 23:29:33 2003 From: ajith at noida.hcltech.com (Ajit Yashwant Vaishampayan, Noida) Date: Thu, 2 Jan 2003 17:59:33 +0530 Subject: Bad packet length problem with "aes128-cbc" and openssh3.1p1 Message-ID: The problem is still there in OpenSSH 3.5p1 version too. We tried it with 3.5p1 on both client and sever. Also we tried it with client as 3.1p1 and sever (SUPER-UX) as 3.5p1. But didn't work. Please help. Thanks, Ajit -----Original Message----- From: Ajit Yashwant Vaishampayan, Noida Sent: Thursday, December 26, 2002 4:23 PM To: openssh-unix-dev at mindrot.org Cc: 'Markus Friedl' Subject: RE: Bad packet length problem with "aes128-cbc" and openssh3.1p1 Hi, Here is some information about the problem. > when does this happen? what plattform? When I try to connect to a 64-bit bigendian machine from a 32-bit little endian machine or even from a 64 bit big endian machine using ssh. Server (sshd) is running on SUPER-UX running on SX-6 and client (ssh) is running on P - II with Red Hat 7.1 or vice versa. > what versions of openssh? openssh-3.1p1 on both client and server, compiled and installed locally. > are other implementations of ssh involved? I am having the same ssh, ssl, zlib installed on both client and server. ssl: openssl-0.9.6b zlib: zlib-1.1.4 > does this happen on the client or server? When running in debug mode, the bad packet is recognized at the server side first and then the message is sent to client. The debug output is appended below. Server side: - ---------------------------------------------------------------------- # uname -a SUPER-UX unix 12.2 SX-6 # ./sshd -d -p 12020 -f /usr/local/etc/sshd_config debug1: sshd version OpenSSH_3.1p1 debug1: private host key: #0 type 0 RSA1 debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: Bind to port 12020 on 0.0.0.0. Server listening on 0.0.0.0 port 12020. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from a.b.c.d port 3814 debug1: Client protocol version 2.0; client software version OpenSSH_3.1p1 debug1: match: OpenSSH_3.1p1 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_3.1p1 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: send2: outgoing packet before cipher_crypt: 0000 01e4 0914 e2a0 5798 041b 6d8a 8a4a 73d1 a66e 9da1 0000 003d 6469 6666 6965 ... debug1: send2: outgoing packet after cipher_crypt: 0000 01e4 0914 e2a0 5798 041b 6d8a 8a4a 73d1 a66e 9da1 0000 003d 6469 6666 6965 ... debug1: SSH2_MSG_KEXINIT sent debug1: poll2: incoming packet before cipher_crypt: 0000 0000 0000 0000 debug1: poll2: incoming packet after cipher_crypt: 0000 01dc 0b14 1296 debug1: SSH2_MSG_KEXINIT received debug1: kex: client->server aes128-cbc hmac-md5 none debug1: kex: server->client aes128-cbc hmac-md5 none debug1: poll2: incoming packet before cipher_crypt: 0000 01dc 0b14 1296 debug1: poll2: incoming packet after cipher_crypt: 0000 0014 0622 0000 debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: send2: outgoing packet before cipher_crypt: 0000 01a4 0a1f 0000 018f 669b a3ed 661f 226a 090b e564 4a2b b420 9371 b78f c3e6 ... debug1: send2: outgoing packet after cipher_crypt: 0000 01a4 0a1f 0000 018f 669b a3ed 661f 226a 090b e564 4a2b b420 9371 b78f c3e6 ... debug1: dh_gen_key: priv key bits set: 135/256 debug1: bits set: 1563/3191 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: poll2: incoming packet before cipher_crypt: 0000 0014 0622 0000 debug1: poll2: incoming packet after cipher_crypt: 0000 019c 0720 0000 debug1: bits set: 1602/3191 debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: send2: outgoing packet before cipher_crypt: 0000 02cc 0b21 0000 0095 0000 0007 7373 682d 7273 6100 0000 0123 0000 0081 00ba ... debug1: send2: outgoing packet after cipher_crypt: 0000 02cc 0b21 0000 0095 0000 0007 7373 682d 7273 6100 0000 0123 0000 0081 00ba ... debug1: kex_derive_keys debug1: send2: outgoing packet before cipher_crypt: 0000 000c 0a15 0000 0000 0000 0000 0000 debug1: send2: outgoing packet after cipher_crypt: 0000 000c 0a15 0000 0000 0000 0000 0000 debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: poll2: incoming packet before cipher_crypt: 0000 019c 0720 0000 debug1: poll2: incoming packet after cipher_crypt: 0000 000c 0a15 0000 debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: dispatch_run debug1: poll2: incoming packet before cipher_crypt: 0000 000c 0a15 0000 0000 0000 0000 0000 debug1: poll2: incoming packet after cipher_crypt: a95d 0c23 e308 4167 8849 9458 684e e068 a95d 0c23 e308 4167 8849 9458 684e e068 debug1: send2: outgoing packet before cipher_crypt: 0000 003c 0d01 0000 0002 0000 0021 706f 6c6c 3220 4261 6420 7061 636b 6574 206c 656e 6774 6820 6139 3564 3063 3233 2e00 0000 0028 9ff6 483e 1c57 d8d7 2379 4cb9 debug1: send2: outgoing packet after cipher_crypt: 0000 003c 0d01 0000 0002 0000 0021 706f 6c6c 3220 4261 6420 7061 636b 6574 206c 656e 6774 6820 6139 3564 3063 3233 2e00 0000 0028 9ff6 483e 1c57 d8d7 2379 4cb9 Disconnecting: poll2 Bad packet length a95d0c23. debug1: Calling cleanup 0x4000b3e98(0x0) ----------------------------------------------------------------- Client side: - ---------------------------------------------------------------------- $ uname -a SUPER-UX unix 12.2 SX-6 $ ./ssh -p 12020 -v -v -v -l ajith sx6i OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f debug1: Reading configuration data /usr/local/etc/ssh_config debug3: Seeing PRNG from /usr/local/libexec/ssh-rand-helper debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 106 geteuid 106 anon 1 debug1: Connecting to sx6i [a.b.c.d] port 12020. debug1: temporarily_use_uid: 106/102 (e=106) debug1: restore_uid debug1: temporarily_use_uid: 106/102 (e=106) debug1: restore_uid debug1: Connection established. debug1: identity file /home/ajith/.ssh/identity type -1 debug1: identity file /home/ajith/.ssh/id_rsa type -1 debug1: identity file /home/ajith/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.1p1 debug1: match: OpenSSH_3.1p1 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.1p1 debug1: send2: outgoing packet before cipher_crypt: 0000 01dc 0b14 1296 3983 bf61 f319 7740 bd01 e53e d51a 0000 003d 6469 6666 6965 ... debug1: send2: outgoing packet after cipher_crypt: 0000 01dc 0b14 1296 3983 bf61 f319 7740 bd01 e53e d51a 0000 003d 6469 6666 6965 ... debug1: SSH2_MSG_KEXINIT sent debug1: poll2: incoming packet before cipher_crypt: 0000 0000 0000 0000 debug1: poll2: incoming packet after cipher_crypt: 0000 01e4 0914 e2a0 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 debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm ac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm ac-md5-96 debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: none 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 debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm ac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm ac-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: send2: outgoing packet before cipher_crypt: 0000 0014 0622 0000 0400 0000 0800 0000 2000 0000 0000 0000 debug1: send2: outgoing packet after cipher_crypt: 0000 0014 0622 0000 0400 0000 0800 0000 2000 0000 0000 0000 debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: poll2: incoming packet before cipher_crypt: 0000 01e4 0914 e2a0 debug1: poll2: incoming packet after cipher_crypt: 0000 01a4 0a1f 0000 debug1: dh_gen_key: priv key bits set: 118/256 debug1: bits set: 1602/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: send2: outgoing packet before cipher_crypt: 0000 019c 0720 0000 018f 5a03 7ac0 e60e c2e0 2186 8ab9 522b c61f 5876 c887 db28 ... debug1: send2: outgoing packet after cipher_crypt: 0000 019c 0720 0000 018f 5a03 7ac0 e60e c2e0 2186 8ab9 522b c61f 5876 c887 db28 ... debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: poll2: incoming packet before cipher_crypt: 0000 01a4 0a1f 0000 debug1: poll2: incoming packet after cipher_crypt: 0000 02cc 0b21 0000 debug3: check_host_in_hostfile: filename /home/ajith/.ssh/known_hosts debug3: check_host_in_hostfile: match line 2 debug3: check_host_in_hostfile: filename /home/ajith/.ssh/known_hosts debug3: check_host_in_hostfile: match line 2 debug1: Host 'sx6i' is known and matches the RSA host key. debug1: Found key in /home/ajith/.ssh/known_hosts:2 debug1: bits set: 1563/3191 debug1: ssh_rsa_verify: signature correct debug1: kex_derive_keys debug1: send2: outgoing packet before cipher_crypt: 0000 000c 0a15 0000 0000 0000 0000 0000 debug1: send2: outgoing packet after cipher_crypt: 0000 000c 0a15 0000 0000 0000 0000 0000 debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: poll2: incoming packet before cipher_crypt: 0000 02cc 0b21 0000 debug1: poll2: incoming packet after cipher_crypt: 0000 000c 0a15 0000 debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: send2: outgoing packet before cipher_crypt: 0000 001c 0a05 0000 000c 7373 682d 7573 6572 6175 7468 af31 35ee ef1a 8e54 496a debug1: send2: outgoing packet after cipher_crypt: 0000 001c 0a05 0000 000c 7373 682d 7573 6572 6175 7468 af31 35ee ef1a 8e54 496a debug1: poll2: incoming packet before cipher_crypt: 0000 000c 0a15 0000 0000 0000 0000 0000 debug1: poll2: incoming packet after cipher_crypt: 0000 003c 0d01 0000 0002 0000 0021 706f Received disconnect from a.b.c.d: 2: poll2 Bad packet length a95d0c23. debug1: Calling cleanup 0x40009a198(0x0) ------------------------------------------------------------- > does this happen with newer releases? I have not tried with any other versions. > please provide more details. > > thx, -m > Thanks & Regards Ajit From ajith at noida.hcltech.com Thu Jan 2 23:30:40 2003 From: ajith at noida.hcltech.com (Ajit Yashwant Vaishampayan, Noida) Date: Thu, 2 Jan 2003 18:00:40 +0530 Subject: Problem while exiting sftp on SX-6... Message-ID: The problem is still there in OpenSSH 3.5p1 version too. We tried it with 3.5p1 on both client and sever. Also we tried it with client as 3.1p1 and sever (SUPER-UX) as 3.5p1. Please suggest. thanks, Ajit -----Original Message----- From: Manish Kumar Srivastava, Noida Sent: Tuesday, December 31, 2002 11:28 AM To: Ajit Vaishampayan (E-mail) Subject: FW: Problem while exiting sftp on SX-6... > -----Original Message----- > From: Peter Stuge [mailto:stuge-openssh-unix-dev at cdy.org] > Sent: Tuesday, December 31, 2002 1:35 AM > To: Manish Kumar Srivastava, Noida > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Problem while exiting sftp on SX-6... > > > On Mon, Dec 30, 2002 at 06:19:53PM +0530, Manish Kumar > Srivastava, Noida wrote: > > Hi, > > > > I am trying to run sftp on SX-6 and it is giving me problem when > > I try to exit from sftp. On pressing ^D or entering "bye" on > > sftp prompt, sftp hangs. And I have to press ^C to quit. > > > > The versions are: - > > 1. openssh-3.1p1 on both client and server. > > If at all possible, please retry this with the latest version > of openssh, > currently 3.5p1, or even a recent snapshot or current CVS. > > The problem you are experiencing may already have been fixed in newer > versions of the software, 3.1p1 is quite old. > > On another note, I think it's very good that you are testing > openssh on this > SX-6 platform, which I didn't even know existed before your > emails. :) > > > //Peter > From bugzilla-daemon at mindrot.org Thu Jan 2 23:54:00 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 2 Jan 2003 23:54:00 +1100 (EST) Subject: [Bug 462] compile failure with openssl 0.9.7 Message-ID: <20030102125400.66C5264566@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=462 ------- Additional Comments From madhon at madhon.co.uk 2003-01-02 23:53 ------- heres the output from findssl.sh, i think it speaks for itself Searching for OpenSSL header files. 0x0090700fL /usr/include/openssl/opensslv.h Searching for OpenSSL shared library files. 0x0090700fL /usr/lib/libcrypto.so.0.9.7 0x0090700fL /usr/lib/libcrypto.so 0x0090700fL /usr/lib/libcrypto.so.0 0x0090700fL /usr/lib/libcrypto.so.0.9.6 Searching for OpenSSL static library files. 0x0090700fL /usr/lib/libcrypto.a ------- 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 Jan 3 01:00:32 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 01:00:32 +1100 (EST) Subject: [Bug 462] compile failure with openssl 0.9.7 Message-ID: <20030102140032.4BC3264518@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=462 ------- Additional Comments From sunkan at zappa.cx 2003-01-03 01:00 ------- Created an attachment (id=189) --> (http://bugzilla.mindrot.org/attachment.cgi?id=189&action=view) Change BN_mod( . . . ) to BN_div(NULL, . . . .) ------- 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 Jan 3 01:19:48 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 01:19:48 +1100 (EST) Subject: [Bug 462] compile failure with openssl 0.9.7 Message-ID: <20030102141948.102D764508@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=462 ------- Additional Comments From markus at openbsd.org 2003-01-03 01:19 ------- 0x0090700fL /usr/lib/libcrypto.so.0.9.6 this looks very much like a broken openssl setup to me. ------- 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 Jan 3 01:32:09 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 01:32:09 +1100 (EST) Subject: [Bug 462] compile failure with openssl 0.9.7 Message-ID: <20030102143209.8012364508@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=462 ------- Additional Comments From markus at openbsd.org 2003-01-03 01:32 ------- openssl 0.9.7 defines #define BN_mod(rem,m,d,ctx) BN_div(NULL,(rem),(m),(d),(ctx)) in and openssh's rsa.c includes rsa.h which includes so i don't see why this is a problem in OpenSSH... ------- 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 Jan 3 01:53:27 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 01:53:27 +1100 (EST) Subject: [Bug 462] compile failure with openssl 0.9.7 Message-ID: <20030102145327.E9BB96452B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=462 ------- Additional Comments From markus at openbsd.org 2003-01-03 01:53 ------- "Change BN_mod( . . . ) to BN_div(NULL, . . . .)" this should not be necessary, since bn.h is included and bn.h should do this.... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bryanh at giraffe-data.com Fri Jan 3 02:27:58 2003 From: bryanh at giraffe-data.com (Bryan Henderson) Date: Thu, 02 Jan 2003 15:27:58 +0000 Subject: Inheriting environment - sshd server to shell child In-Reply-To: <20030102020446.GE3204@scott.crlsca.adelphia.net> (stevesk@pobox.com) References: <20030102020446.GE3204@scott.crlsca.adelphia.net> Message-ID: >You are asking for a sshd login -p equivalent? Obviously, right now >the default deny behaviour used for the environment is correct. That's right. -- Bryan Henderson Phone 408-621-2000 San Jose, California From bugzilla-daemon at mindrot.org Fri Jan 3 02:42:46 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 02:42:46 +1100 (EST) Subject: [Bug 354] sshd with privsep doesn't do pam session setup properly Message-ID: <20030102154246.E6ED16453E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=354 ------- Additional Comments From cjwatson at debian.org 2003-01-03 02:42 ------- Alternatively, perhaps sshd could be configured to setrlimit() everything up to RLIM_INFINITY after forking but before giving up root privileges. It could then rely on pam_limits to set limits back down if the administrator wants that, which would work even with session modules run as non-root. ------- 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 Jan 3 02:43:38 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 02:43:38 +1100 (EST) Subject: [Bug 462] compile failure with openssl 0.9.7 Message-ID: <20030102154338.A1E1C6453E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=462 ------- Additional Comments From madhon at madhon.co.uk 2003-01-03 02:43 ------- "0x0090700fL /usr/lib/libcrypto.so.0.9.6 this looks very much like a broken openssl setup to me" thats just a sym link to libcrypto.so.0.9.7 ------- 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 Jan 3 02:43:01 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 02:43:01 +1100 (EST) Subject: [Bug 462] compile failure with openssl 0.9.7 Message-ID: <20030102154301.8FF6364555@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=462 ------- Additional Comments From madhon at madhon.co.uk 2003-01-03 02:43 ------- "0x0090700fL /usr/lib/libcrypto.so.0.9.6 this looks very much like a broken openssl setup to me" thats just a sym link to libcrypto.so.9.9.7 ------- 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 Jan 3 03:10:26 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 03:10:26 +1100 (EST) Subject: [Bug 462] compile failure with openssl 0.9.7 Message-ID: <20030102161026.7081164538@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=462 madhon at madhon.co.uk changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From madhon at madhon.co.uk 2003-01-03 03:10 ------- the patch from Andreas Sundstrom worked ok, still a bit strange as to why it needed to be changed even though bn.h defines bn_mod ------- 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 Jan 3 03:27:48 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 03:27:48 +1100 (EST) Subject: [Bug 462] compile failure with openssl 0.9.7 Message-ID: <20030102162748.1E56D6454F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=462 ------- Additional Comments From sunkan at zappa.cx 2003-01-03 03:27 ------- My comment wasn't added, but here goes: I don't know why the #define statement in bn.h has no effect, the patch is just what I did to be able to compile this for now.. Until someone who has more C knowledge than me can fix whatever should be fixed.. /Andreas ------- 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 Jan 3 14:34:24 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 14:34:24 +1100 (EST) Subject: [Bug 461] ssh-copy-id is messy when invoked with no arguments Message-ID: <20030103033424.308FC6451B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=461 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-03 14:34 ------- 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 Fri Jan 3 14:42:42 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 14:42:42 +1100 (EST) Subject: [Bug 460] ut_addr_v6 not used Message-ID: <20030103034242.6D73464535@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=460 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-03 14:42 ------- FYI: patches are best attached to a bug, rather than copied into comments. 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 Fri Jan 3 14:43:15 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 14:43:15 +1100 (EST) Subject: [Bug 455] Krb5 ticket forwarding is tryied even if krb5 authentication failed Message-ID: <20030103034315.4B8A864555@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=455 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From djm at mindrot.org 2003-01-03 14:43 ------- *** This bug has been marked as a duplicate of 456 *** ------- 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 Jan 3 14:43:16 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 14:43:16 +1100 (EST) Subject: [Bug 456] Krb5 ticket forwarding is tryied even if krb5 authentication failed Message-ID: <20030103034316.ECAB26455A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=456 ------- Additional Comments From djm at mindrot.org 2003-01-03 14:43 ------- *** Bug 455 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 bugzilla-daemon at mindrot.org Fri Jan 3 14:46:19 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 14:46:19 +1100 (EST) Subject: [Bug 451] new config-Option: IPv4or6 Message-ID: <20030103034619.96DBE64578@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=451 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2003-01-03 14:46 ------- You can do this by explitictly specifying an v4 or v6 addr in "HostName xxx" - I don't think we need another 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 Fri Jan 3 14:48:20 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 14:48:20 +1100 (EST) Subject: [Bug 450] sftp crashes when trying to upload a file which doesn't exist Message-ID: <20030103034820.AA63C64584@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=450 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From djm at mindrot.org 2003-01-03 14:48 ------- FreeBSD glob has had problems in the past - I suspect that is the problem. I would recommend using the in-tree OpenSSH for FreeBSD. Please report if that breaks. ------- 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 Jan 3 14:49:41 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 14:49:41 +1100 (EST) Subject: [Bug 447] Invalid parsing for user@hostname in scp.c and ssh.c Message-ID: <20030103034941.F33AD64589@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=447 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-03 14:49 ------- Markus fixed this in November ------- 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 Jan 3 14:53:09 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 14:53:09 +1100 (EST) Subject: [Bug 446] $LOGIN not set by openssh under AIX Message-ID: <20030103035309.3165964590@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=446 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-03 14:53 ------- 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 Fri Jan 3 14:58:11 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 14:58:11 +1100 (EST) Subject: [Bug 443] Ability to set KeepAlive time Message-ID: <20030103035811.0C1E66451B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=443 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2003-01-03 14:58 ------- As mentioned, TCP keepalives are a system-wide setting. On linux you can tweak them using "sysctl -w net.ipv4.tcp_keepalive_time=xxx" or through /proc/sys Adding protocol-level keepalives to the client (they are already in the server) is a separate issue (and bug). ------- 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 Jan 3 15:02:29 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 15:02:29 +1100 (EST) Subject: [Bug 438] SFTP does not work for users with RSH shells Message-ID: <20030103040229.E13F364598@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=438 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From djm at mindrot.org 2003-01-03 15:02 ------- This is an rsh problem, not a ssh problem ------- 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 Jan 3 15:06:33 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 15:06:33 +1100 (EST) Subject: [Bug 434] ssh-add doesn't always add all identities to ssh-agent Message-ID: <20030103040633.6CF1364541@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=434 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From djm at mindrot.org 2003-01-03 15:06 ------- Can't replicate - please retry with the most recent version (reopen this bus if necessary). ------- 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 Jan 3 15:12:17 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 15:12:17 +1100 (EST) Subject: [Bug 426] sftp adds write permission when doing get -p Message-ID: <20030103041217.B2E0D64591@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=426 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #166 is|0 |1 obsolete| | ------- Additional Comments From djm at mindrot.org 2003-01-03 15:12 ------- Created an attachment (id=190) --> (http://bugzilla.mindrot.org/attachment.cgi?id=190&action=view) Fix permissions on download shorter 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 Fri Jan 3 15:14:42 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 15:14:42 +1100 (EST) Subject: [Bug 427] sftp does not preserve uid/gid on fetch Message-ID: <20030103041442.646ED64559@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=427 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2003-01-03 15:14 ------- This is almost useless to most people, as there will be no correspondance between remote [ug]ids and local ones. Future versions of the filexfer draft will add support for sending the user and group names, which we'll support when we support that version of the protocol. ------- 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 Jan 3 15:16:21 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 15:16:21 +1100 (EST) Subject: [Bug 424] scp mishandles files with spaces in names Message-ID: <20030103041621.E665D645A7@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=424 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2003-01-03 15:16 ------- Known, and unfixable, problem with the rcp protocol. A workaround is to double-quote spaces: scp "foo\ bar" foo: We can't fix a 20+ year old, deployed protocol. ------- 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 Jan 3 15:18:16 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 15:18:16 +1100 (EST) Subject: [Bug 422] /bin/sh: ./ssh-keygen: file or directory not found Message-ID: <20030103041816.226FF645AA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=422 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From djm at mindrot.org 2003-01-03 15:18 ------- This bug report does not contain enough information to diagnose ------- 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 Jan 3 15:26:23 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 15:26:23 +1100 (EST) Subject: [Bug 408] sshd[25790]: error: socket: Protocol not supported Message-ID: <20030103042623.4093F64585@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=408 ------- Additional Comments From djm at mindrot.org 2003-01-03 15:26 ------- Created an attachment (id=191) --> (http://bugzilla.mindrot.org/attachment.cgi?id=191&action=view) Suppress protocol errors ------- 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 Jan 3 15:27:44 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 15:27:44 +1100 (EST) Subject: [Bug 407] Build openssh-3.1p1 fails, Mac OS X v1.2 Message-ID: <20030103042744.8B49964568@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=407 ------- Additional Comments From djm at mindrot.org 2003-01-03 15:27 ------- Please retest with the latest OpenSSH (3.5p1) ------- 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 Jan 3 16:05:50 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 Jan 2003 16:05:50 +1100 (EST) Subject: [Bug 460] ut_addr_v6 not used Message-ID: <20030103050550.CAC2464560@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=460 ------- Additional Comments From cjwatson at debian.org 2003-01-03 16:05 ------- Noted for the future. Thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From pekkas at netcore.fi Fri Jan 3 18:48:20 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 3 Jan 2003 09:48:20 +0200 (EET) Subject: [Bug 408] sshd[25790]: error: socket: Protocol not supported In-Reply-To: <20030103042623.4093F64585@shitei.mindrot.org> Message-ID: On Fri, 3 Jan 2003 bugzilla-daemon at mindrot.org wrote: > http://bugzilla.mindrot.org/show_bug.cgi?id=408 > > ------- Additional Comments From djm at mindrot.org 2003-01-03 15:26 ------- > Created an attachment (id=191) > --> (http://bugzilla.mindrot.org/attachment.cgi?id=191&action=view) > Suppress protocol errors I haven't been minding the errors myself, but I take it's also possible to get EAFNOSUPPORT error ? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From nicklange at wi.rr.com Sat Jan 4 00:44:07 2003 From: nicklange at wi.rr.com (Nick Lange) Date: Fri, 03 Jan 2003 05:44:07 -0800 Subject: [patch] chroot support for openssh-3.5p1 Message-ID: <3E1593A7.7020905@wi.rr.com> Good Morning All, Attached is a full patch [or so I hope] enabling chroot support for sshd. I know varied opinions about chroot exist among the masses; however, I continue to believe that until something far outside the scope of openssh tackles the sandbox issue, the role of enforcer will continue to be with the daemon. This patch is based on a previous work by John Furman as well as Eric Johnson. I've been sitting on this for a month or two and have been running it sucessfully for about the same amount of time. This patch assumes: The ~username/chome directory exists with owner uid=root,gid=root [the directory name is configurable via sshd_config]. A proper jail has been setup underneath. Unfortunately, syslogin_perform_logout is broken, as I'm not sure how to handle this [securely] as after the chroot, the file is no longer accessible. This patch does work with privilege separation. This patch requires a binary for scp/sftp-server to be in the proper locations in each jail as well. You can chrootAll with exceptions or chroot none with a list of chroot'ed users. If your're concerned with scp/sftp only rssh is still your solution. [http://www.pizzashack.org/rssh] A web page with the patch is also available: http://majikal.dyn.dhs.org/projekts/openssh_chroot_patch/ Problems/Complaints/Suggestions/Additions can be sent to me at this address. Cheers, nick -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: chroot.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030103/6ef03ef4/attachment.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 250 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030103/6ef03ef4/attachment.bin From djm at mindrot.org Fri Jan 3 23:08:32 2003 From: djm at mindrot.org (Damien Miller) Date: Fri, 03 Jan 2003 23:08:32 +1100 Subject: [Bug 408] sshd[25790]: error: socket: Protocol not supported In-Reply-To: References: Message-ID: <3E157D40.8040805@mindrot.org> Pekka Savola wrote: > On Fri, 3 Jan 2003 bugzilla-daemon at mindrot.org wrote: > >>http://bugzilla.mindrot.org/show_bug.cgi?id=408 >> >>------- Additional Comments From djm at mindrot.org 2003-01-03 15:26 ------- >>Created an attachment (id=191) >> --> (http://bugzilla.mindrot.org/attachment.cgi?id=191&action=view) >>Suppress protocol errors > > > I haven't been minding the errors myself, but I take it's also possible to > get EAFNOSUPPORT error ? Perhaps - it also looks like we could get EINVAL as well. Here is a different patch. -d -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: channels.diff Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030103/7783b304/attachment.ksh From cjwatson at debian.org Sat Jan 4 05:25:28 2003 From: cjwatson at debian.org (Colin Watson) Date: Fri, 3 Jan 2003 18:25:28 +0000 Subject: RSA1 fingerprinting and privsep Message-ID: <20030103182528.GA29948@riva.ucam.org> I was looking through the RSA fingerprinting code from a few releases back, with an eye to being able to close . While it works fine with SSH2, the fingerprint log message goes missing with SSH1. I eventually realized that this is because auth_rsa() is called in the unprivileged child, and so can't write syslog messages. Am I right that auth_rsa()'s fingerprint logging needs to be split into a separate function which can be called through the monitor functions? If so, I will try to produce a patch. Thanks, -- Colin Watson [cjwatson at flatline.org.uk] From kittroidkat at hotmail.com Sat Jan 4 05:56:57 2003 From: kittroidkat at hotmail.com (Jaime C. Jordan) Date: Fri, 3 Jan 2003 11:56:57 -0700 Subject: (no subject) Message-ID: From bugzilla-daemon at mindrot.org Sat Jan 4 06:29:52 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 4 Jan 2003 06:29:52 +1100 (EST) Subject: [Bug 125] with BSM auditing, cron editing thru ssh session causes cron jobs to fail Message-ID: <20030103192952.B8A686451D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=125 ------- Additional Comments From jrj at purdue.edu 2003-01-04 06:29 ------- The following attachment updates the suggested patch to 3.5p1. The attachment is a gzip'd tar file. Once you download it, ungzip it and then untar it into a temp directory (or use the 'z' option of GNU tar). Then look at the README for more information. ------- 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 Jan 4 06:32:16 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 4 Jan 2003 06:32:16 +1100 (EST) Subject: [Bug 125] with BSM auditing, cron editing thru ssh session causes cron jobs to fail Message-ID: <20030103193216.8F1BC6451D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=125 jrj at purdue.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #131 is|0 |1 obsolete| | ------- Additional Comments From jrj at purdue.edu 2003-01-04 06:32 ------- Created an attachment (id=192) --> (http://bugzilla.mindrot.org/attachment.cgi?id=192&action=view) Gzip'd tar file with 3.4p1 and 3.5p1 versions of the patch ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Jeff.Koenig at experian.com Sat Jan 4 10:30:08 2003 From: Jeff.Koenig at experian.com (Jeff Koenig) Date: Fri, 03 Jan 2003 17:30:08 -0600 Subject: OpenSSH, Solaris 8, and BSM works with BSM patch, but must disable privilege separation Message-ID: To get BSM working on Solaris 8 with OpenSSH, I did this: Download John R. Jackson's OpenSSH 3.5p1 BSM patch here, and save as "patch.tar.gz": http://bugzilla.mindrot.org/show_bug.cgi?id=125 (NOTE TO OpenSSH DEVELOPERS, can you incorporate this patch into the next version of OpenSSH?) Installing the OpenSSH 3.5p1 BSM patch: ?-------------------------------------- Turning on Sun BSM auditing requires you to: Apply the OpenSSH 3.5p1 BSM patch Disable privilege separation in OpenSSH /usr/local/etc/sshd_config file You need these applications installed prior to the patch install (you can get the packages from sunfreeware.com): autoconf 2.53 (SMCautoc) m4 1.4 (SMCm4) patch 2.5.4 (SMCpatch) Perl 5.00503 or higher (SMCperl) cp openssh-3.5p1.tar.gz /tmp cp patch.tar.gz /tmp cd /tmp gunzip patch.tar.gz tar xvf patch.tar gunzip openssh-3.5p1.tar.gz tar xvf openssh-3.5p1.tar cd openssh-3.5p1 /usr/local/bin/patch -p0 < ../openssh-vs-bsm/patch-bs-3.5p1 rm -f configure autoheader autoconf ./configure --with-pam make make install # Set privilege separation to "no" in /usr/local/etc/sshd_config # Example: UsePrivilegeSeparation no # restart sshd NOTE: The following output is "normal" during the patching process: patching file INSTALL patching file Makefile.in patching file auth1.c patching file auth2-kbdint.c patching file auth2-passwd.c patching file auth2-pubkey.c patching file auth2.c patching file bsmaudit.c patching file bsmaudit.h patching file configure.ac patching file contrib/solaris/buildpkg.sh patching file contrib/solaris/postinstall patching file includes.h patching file servconf.c patching file session.c patching file sshd.c patching file sshlogin.c WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. autoheader: `config.h.in' is updated NOTE: This is "normal" during compile: bsmaudit.h:30: warning: ignoring pragma: "@(#)bsmaudit.h 1.1 01/09/17 SMI From mouring at etoh.eviladmin.org Sat Jan 4 05:44:08 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 3 Jan 2003 12:44:08 -0600 (CST) Subject: OpenSSH, Solaris 8, and BSM works with BSM patch, but must disable privilege separation In-Reply-To: Message-ID: Is there any reason why Cygwin code is being changed? I don't agree with random changes without having someone from that camp agree that those are correct changes. Also, Privsep should never be turned off unless the user sets it off. Hard error. - Ben On Fri, 3 Jan 2003, Jeff Koenig wrote: > To get BSM working on Solaris 8 with OpenSSH, I did this: > > Download John R. Jackson's OpenSSH 3.5p1 BSM patch here, and save as "patch.tar.gz": > http://bugzilla.mindrot.org/show_bug.cgi?id=125 > (NOTE TO OpenSSH DEVELOPERS, can you incorporate this patch into the next version of OpenSSH?) > > Installing the OpenSSH 3.5p1 BSM patch: > ?-------------------------------------- > Turning on Sun BSM auditing requires you to: > Apply the OpenSSH 3.5p1 BSM patch > Disable privilege separation in OpenSSH /usr/local/etc/sshd_config file > > You need these applications installed prior to the patch install (you can get the packages from sunfreeware.com): > autoconf 2.53 (SMCautoc) > m4 1.4 (SMCm4) > patch 2.5.4 (SMCpatch) > Perl 5.00503 or higher (SMCperl) > > cp openssh-3.5p1.tar.gz /tmp > cp patch.tar.gz /tmp > cd /tmp > gunzip patch.tar.gz > tar xvf patch.tar > gunzip openssh-3.5p1.tar.gz > tar xvf openssh-3.5p1.tar > cd openssh-3.5p1 > /usr/local/bin/patch -p0 < ../openssh-vs-bsm/patch-bs-3.5p1 > rm -f configure > autoheader > autoconf > ./configure --with-pam > make > make install > > # Set privilege separation to "no" in /usr/local/etc/sshd_config > # Example: > UsePrivilegeSeparation no > > # restart sshd > > NOTE: > The following output is "normal" during the patching process: > patching file INSTALL > patching file Makefile.in > patching file auth1.c > patching file auth2-kbdint.c > patching file auth2-passwd.c > patching file auth2-pubkey.c > patching file auth2.c > patching file bsmaudit.c > patching file bsmaudit.h > patching file configure.ac > patching file contrib/solaris/buildpkg.sh > patching file contrib/solaris/postinstall > patching file includes.h > patching file servconf.c > patching file session.c > patching file sshd.c > patching file sshlogin.c > WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' > WARNING: and `config.h.top', to define templates for `config.h.in' > WARNING: is deprecated and discouraged. > > WARNING: Using the third argument of `AC_DEFINE' and > WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without > WARNING: `acconfig.h': > > WARNING: AC_DEFINE([NEED_MAIN], 1, > WARNING: [Define if a function `main' is needed.]) > > WARNING: More sophisticated templates can also be produced, see the > WARNING: documentation. > autoheader: `config.h.in' is updated > > NOTE: > This is "normal" during compile: > bsmaudit.h:30: warning: ignoring pragma: "@(#)bsmaudit.h 1.1 01/09/17 SMI > > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From jmknoble at pobox.com Sat Jan 4 12:55:19 2003 From: jmknoble at pobox.com (Jim Knoble) Date: Fri, 3 Jan 2003 20:55:19 -0500 Subject: patch for openssh3.5p1 - adds logging option In-Reply-To: <20021230015119.GA2487@scott.crlsca.adelphia.net> References: <20021228075145.GF464@scott.crlsca.adelphia.net> <20021228140337.Y27889-100000@true.fiberpimp.net> <20021230015119.GA2487@scott.crlsca.adelphia.net> Message-ID: <20030104015519.GF6195@crawfish.ais.com> Circa 2002-12-29 17:51:19 -0800 dixit Kevin Steves: : On Sat, Dec 28, 2002 at 02:06:29PM -0500, galt at fiberpimp.net wrote: : > > On Fri, Dec 27, 2002 at 03:46:41PM -0500, galt at fiberpimp.net wrote: : > > > > other than the timestamp, why is sshd -e 2>foo not sufficient? : > > > : > > > its more appealing to me to have a config file option than to redirect : > > > stderr. : > > : > > we try to avoid more options. : > > i don't see a reason to add this. : > : > whats your opinion on adding a timestamp to the regular stderr logging? : : i don't have a problem adding timestamp for -e. Why not use multilog if you want timestamps: http://cr.yp.to/daemontools/multilog.html It's designed to handle stdout or stderr-style logging by adding Y2038-compliant timestamps, automatic logfile rotation, etc. -- 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/20030103/46ea7f94/attachment.bin From bugzilla-daemon at mindrot.org Sat Jan 4 19:21:50 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 4 Jan 2003 19:21:50 +1100 (EST) Subject: [Bug 462] compile failure with openssl 0.9.7 Message-ID: <20030104082150.D6CDE64508@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=462 ------- Additional Comments From igvk at despammed.com 2003-01-04 19:21 ------- I had the same problem, and it was because of old header file generated by gcc's fixincludes, namely /usr/lib/gcc-lib/.../openssl/bh.h. I just removed the whole directory openssl there. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Sat Jan 4 23:34:38 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 04 Jan 2003 23:34:38 +1100 Subject: [PATCH] PAM chauthtok + Privsep References: <3E045A58.285069C2@zip.com.au> <20030102015607.GD3204@scott.crlsca.adelphia.net> <3E141777.7FBEFD53@zip.com.au> Message-ID: <3E16D4DE.9B93F5AB@zip.com.au> Darren Tucker wrote: > Kevin Steves wrote: > > this should be separated out as it's addressing a different problem: > > running session modules as root. > > I'll remove those bits and re-post the patch in a day or two. Here it is. Tested on Solaris 8 and Redhat 8. Changes relative to previous patch: * removed all HP-UX PAM changes * doesn't rely on the monitor's child getting a controlling tty * sends a SIGUSR1 to parent to restore port forwarding flags Notes: The controlling tty stuff proved unreliable on Linux. Not sure why, but it seems that when the monitor child exits the pty closes (ie generates a zero-length read from the pty). I think using a signal to restore the port forward flags should be safe. In the non-privsep case, both parent and child are running as root. In the privsep case, they're both running as the user, but the user can't fake the signal unless they're already logged on. It might make sense to have do_pam_chauthtok return an int and not throw a fatal. It would mean a little less reliance on globals and make things a little tidier. You could also allow multiple attempts at password change with something like: while (!do_pam_chauthtok()); -- 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-pam.c =================================================================== RCS file: /cvs/openssh/auth-pam.c,v retrieving revision 1.54 diff -u -r1.54 auth-pam.c --- auth-pam.c 28 Jul 2002 20:24:08 -0000 1.54 +++ auth-pam.c 4 Jan 2003 12:11:31 -0000 @@ -33,17 +33,18 @@ #include "servconf.h" #include "canohost.h" #include "readpass.h" +#include "channels.h" +#include "misc.h" extern char *__progname; extern int use_privsep; +extern ServerOptions options; RCSID("$Id: auth-pam.c,v 1.54 2002/07/28 20:24:08 stevesk Exp $"); #define NEW_AUTHTOK_MSG \ "Warning: Your password has expired, please change it now." -#define NEW_AUTHTOK_MSG_PRIVSEP \ - "Your password has expired, the session cannot proceed." static int do_pam_conversation(int num_msg, const struct pam_message **msg, struct pam_response **resp, void *appdata_ptr); @@ -204,7 +205,6 @@ /* Attempt password authentation using PAM */ int auth_pam_password(Authctxt *authctxt, const char *password) { - extern ServerOptions options; int pam_retval; struct passwd *pw = authctxt->pw; @@ -256,18 +256,17 @@ 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); + message_cat(&__pam_msg, 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; + /* set signal handler to restore flags */ + mysignal(SIGUSR1, password_change_successful_handler); break; -#endif default: log("PAM rejected by account configuration[%d]: " "%.200s", pam_retval, PAM_STRERROR(__pamh, @@ -344,26 +343,32 @@ do_pam_set_conv(&conv); if (password_change_required) { - if (use_privsep) - fatal("Password changing is currently unsupported" - " with privilege separation"); pamstate = OTHER; pam_retval = pam_chauthtok(__pamh, PAM_CHANGE_EXPIRED_AUTHTOK); if (pam_retval != PAM_SUCCESS) fatal("PAM pam_chauthtok failed[%d]: %.200s", pam_retval, PAM_STRERROR(__pamh, pam_retval)); -#if 0 - /* XXX: This would need to be done in the parent process, - * but there's currently no way to pass such request. */ - no_port_forwarding_flag &= ~2; - no_agent_forwarding_flag &= ~2; - no_x11_forwarding_flag &= ~2; - if (!no_port_forwarding_flag && options.allow_tcp_forwarding) - channel_permit_all_opens(); -#endif + password_change_required = 0; } } +/* + * Because do_pam_chauthtok is called after forking to exec the user's + * shell, restoring the port forwarding flags is done by sending a + * USR1 signal after the password is changed successfully. + */ +void password_change_successful_handler(int sig) +{ + debug("%s: restoring port forwarding flags", __func__); + mysignal(SIGUSR1, SIG_DFL); /* unset handler */ + password_change_required = 0; + no_port_forwarding_flag &= ~2; + no_agent_forwarding_flag &= ~2; + no_x11_forwarding_flag &= ~2; + if (!no_port_forwarding_flag && options.allow_tcp_forwarding) + channel_permit_all_opens(); +} + /* Cleanly shutdown PAM */ void finish_pam(void) { @@ -375,7 +380,6 @@ void start_pam(const char *user) { int pam_retval; - extern ServerOptions options; extern u_int utmp_len; const char *rhost; Index: auth-pam.h =================================================================== RCS file: /cvs/openssh/auth-pam.h,v retrieving revision 1.16 diff -u -r1.16 auth-pam.h --- auth-pam.h 23 Jul 2002 00:44:07 -0000 1.16 +++ auth-pam.h 4 Jan 2003 12:11:31 -0000 @@ -43,6 +43,7 @@ void print_pam_messages(void); int is_pam_password_change_required(void); void do_pam_chauthtok(void); +void password_change_successful_handler(int); void do_pam_set_conv(struct pam_conv *); void message_cat(char **p, const char *a); Index: monitor.c =================================================================== RCS file: /cvs/openssh/monitor.c,v retrieving revision 1.33 diff -u -r1.33 monitor.c --- monitor.c 9 Nov 2002 15:47:49 -0000 1.33 +++ monitor.c 4 Jan 2003 12:11:32 -0000 @@ -118,6 +118,7 @@ #ifdef USE_PAM int mm_answer_pam_start(int, Buffer *); +int mm_answer_pam_chauthtok(int, Buffer *); #endif #ifdef KRB4 @@ -183,6 +184,9 @@ {MONITOR_REQ_PTY, 0, mm_answer_pty}, {MONITOR_REQ_PTYCLEANUP, 0, mm_answer_pty_cleanup}, {MONITOR_REQ_TERM, 0, mm_answer_term}, +#ifdef USE_PAM + {MONITOR_REQ_PAM_CHAUTHTOK, 0, mm_answer_pam_chauthtok}, +#endif {0, 0, NULL} }; @@ -219,6 +223,9 @@ {MONITOR_REQ_PTY, MON_ONCE, mm_answer_pty}, {MONITOR_REQ_PTYCLEANUP, MON_ONCE, mm_answer_pty_cleanup}, {MONITOR_REQ_TERM, 0, mm_answer_term}, +#ifdef USE_PAM + {MONITOR_REQ_PAM_CHAUTHTOK, 0, mm_answer_pam_chauthtok}, +#endif {0, 0, NULL} }; @@ -328,6 +335,7 @@ if (!no_pty_flag) { monitor_permit(mon_dispatch, MONITOR_REQ_PTY, 1); monitor_permit(mon_dispatch, MONITOR_REQ_PTYCLEANUP, 1); + monitor_permit(mon_dispatch, MONITOR_REQ_PAM_CHAUTHTOK, 1); } for (;;) @@ -746,6 +754,56 @@ xfree(user); return (0); +} + +int +mm_answer_pam_chauthtok(int socket, Buffer *m) +{ + pid_t pid; + int ttyfd, status; + mysig_t old_signal; + + old_signal = mysignal(SIGCHLD, SIG_DFL); + + ttyfd = mm_receive_fd(socket); + debug3("%s: ttyfd %d, ttyname %s", __func__, ttyfd, ttyname(ttyfd)); + + if ((pid = fork()) == 0) { + fatal_remove_all_cleanups(); + + /* set up stdin, stdout and stderr */ + if (dup2(ttyfd, 0) < 0) + error("dup2 stdin: %s", strerror(errno)); + if (dup2(ttyfd, 1) < 0) + error("dup2 stdout: %s", strerror(errno)); + if (dup2(ttyfd, 2) < 0) + error("dup2 stderr: %s", strerror(errno)); + + /* call PAM chauthtok and return status to parent */ + do_pam_chauthtok(); + + if(is_pam_password_change_required()) + exit(1); /* failed */ + else + exit(0); /* success */ + } + + close(ttyfd); + + if (waitpid(pid, &status, 0) == -1) + fatal("Couldn't wait for child: %s", strerror(errno)); + debug("chauthtok child returned %d", status); + + if (WIFEXITED(status) && (WEXITSTATUS(status) == 0)) + debug("password changed sucessfully"); + else + fatal("do_pam_chauthtok() failed, child returned %d", status); + + mysignal(SIGCHLD, old_signal); + + mm_request_send(socket, MONITOR_ANS_PAM_CHAUTHTOK, m); + + return 1; } #endif Index: monitor.h =================================================================== RCS file: /cvs/openssh/monitor.h,v retrieving revision 1.10 diff -u -r1.10 monitor.h --- monitor.h 27 Sep 2002 03:26:02 -0000 1.10 +++ monitor.h 4 Jan 2003 12:11:32 -0000 @@ -52,6 +52,7 @@ MONITOR_REQ_KRB4, MONITOR_ANS_KRB4, MONITOR_REQ_KRB5, MONITOR_ANS_KRB5, MONITOR_REQ_PAM_START, + MONITOR_REQ_PAM_CHAUTHTOK, MONITOR_ANS_PAM_CHAUTHTOK, MONITOR_REQ_TERM }; Index: monitor_wrap.c =================================================================== RCS file: /cvs/openssh/monitor_wrap.c,v retrieving revision 1.21 diff -u -r1.21 monitor_wrap.c --- monitor_wrap.c 23 Dec 2002 02:06:20 -0000 1.21 +++ monitor_wrap.c 4 Jan 2003 12:11:33 -0000 @@ -663,6 +663,27 @@ buffer_free(&m); } + +/* + * Privsep chauthtok works by passing a descriptor to the session's + * stdin/stdout to the monitor, which then sets up a child with this + * descriptor as stdin, stdout then calls do_pam_chauthtok + */ + +void +mm_do_pam_chauthtok(void) +{ + Buffer m; + + debug3("%s entering", __func__); + + buffer_init(&m); + mm_request_send(pmonitor->m_recvfd, MONITOR_REQ_PAM_CHAUTHTOK, &m); + mm_send_fd(pmonitor->m_recvfd, STDIN_FILENO); + mm_request_receive_expect(pmonitor->m_recvfd, MONITOR_ANS_PAM_CHAUTHTOK, &m); + + buffer_free(&m); +} #endif /* USE_PAM */ /* Request process termination */ Index: monitor_wrap.h =================================================================== RCS file: /cvs/openssh/monitor_wrap.h,v retrieving revision 1.9 diff -u -r1.9 monitor_wrap.h --- monitor_wrap.h 27 Sep 2002 03:26:04 -0000 1.9 +++ monitor_wrap.h 4 Jan 2003 12:11:33 -0000 @@ -57,6 +57,7 @@ #ifdef USE_PAM void mm_start_pam(char *); +void mm_do_pam_chauthtok(void); #endif void mm_terminate(void); Index: session.c =================================================================== RCS file: /cvs/openssh/session.c,v retrieving revision 1.226 diff -u -r1.226 session.c --- session.c 3 Jan 2003 03:52:54 -0000 1.226 +++ session.c 4 Jan 2003 12:11:34 -0000 @@ -753,7 +753,10 @@ */ if (is_pam_password_change_required()) { print_pam_messages(); - do_pam_chauthtok(); + PRIVSEP(do_pam_chauthtok()); + /* change successful, tell parent to restore port + * forwarding flags */ + kill(getppid(), SIGUSR1); } #endif Index: openbsd-compat/readpassphrase.c =================================================================== RCS file: /cvs/openssh/openbsd-compat/readpassphrase.c,v retrieving revision 1.9 diff -u -r1.9 readpassphrase.c --- openbsd-compat/readpassphrase.c 11 Sep 2002 00:29:13 -0000 1.9 +++ openbsd-compat/readpassphrase.c 4 Jan 2003 12:11:36 -0000 @@ -85,6 +85,15 @@ output = STDERR_FILENO; } + /* + * Odd case where stdin is a tty but /dev/tty is not + * available. Used for passed file descriptor during privsep. + */ + if (isatty(STDIN_FILENO)) { + input = dup(STDIN_FILENO); + output = dup(STDERR_FILENO); + } + /* * Catch signals that would otherwise cause the user to end * up with echo turned off in the shell. Don't worry about From bugzilla-daemon at mindrot.org Sun Jan 5 09:56:56 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 5 Jan 2003 09:56:56 +1100 (EST) Subject: [Bug 459] ssh-keygen doesn't know how to export private keys Message-ID: <20030104225656.3AE7364514@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=459 ------- Additional Comments From aet at cc.hut.fi 2003-01-05 09:56 ------- Created an attachment (id=193) --> (http://bugzilla.mindrot.org/attachment.cgi?id=193&action=view) A quick hack to export unencrypted private keys I noticed the lack of exporting private keys a few months ago and therefore created the following patch to do the job. Should work for all unencrypted RSA/DSA private keys. I don't care if the patch ever goes to the main source tree, there's still people who probably need the functionality in ssh-keygen, so I might just as well share 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 Mon Jan 6 12:20:41 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 6 Jan 2003 12:20:41 +1100 (EST) Subject: [Bug 401] ipv4 mapped address (ipv4 in ipv6) and ipv6 support fix Message-ID: <20030106012041.3FC6664513@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=401 ------- Additional Comments From yoshfuji at linux-ipv6.org 2003-01-06 12:20 ------- Created an attachment (id=194) --> (http://bugzilla.mindrot.org/attachment.cgi?id=194&action=view) patch to run openssh-3.5p1 on linux-2.2 & glibc-2.2(or later) This is modified patch for openssh-3.5p1. Patch is simplified. ------- 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 Jan 6 12:29:08 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 6 Jan 2003 12:29:08 +1100 (EST) Subject: [Bug 401] ipv4 mapped address (ipv4 in ipv6) and ipv6 support fix Message-ID: <20030106012908.F093A6453D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=401 cjwatson at debian.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cjwatson at debian.org ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From zhang at csee.wvu.edu Mon Jan 6 14:12:45 2003 From: zhang at csee.wvu.edu (zhang at csee.wvu.edu) Date: Sun, 5 Jan 2003 22:12:45 -0500 (EST) Subject: Is sftp-server's stdout redirected to client ? Message-ID: <1373.64.196.144.10.1041822765.squirrel@torvalds.csee.wvu.edu> Hello everyone, I added some code to sftp, which would be useful for me. I add a command "run", which can run any command on the remote shell, in the mean time I want the server send the standard output back. for example, when I : sftp> run ls I want to see the result locally. I thought the stdout of sftp-server has been redirected to the client. But I get "message too long" error. When I check the received buffer, it do have part of the server's standard output, but it is messed up. How do I fix it? Thanks, Hanzhou From sshdev at rednu.com Mon Jan 6 09:41:02 2003 From: sshdev at rednu.com (sshdev at rednu.com) Date: Sun, 05 Jan 2003 16:41:02 -0600 Subject: SSH v3 specs? Message-ID: Has any thought toward a v3 protocol spec been discussed elsewhere, and if so what enhancements are being looked at. Is it too early to consider such things, or should we open the door to the new features a protocol update would bring? More specifically I have been investigating working toward a more enterprise-friendly hierichical authentication scheme, but I have quickly realized the magnitude of such a change. I have worked with LDAP/PAM, but there are parts of ssh that are not very interoperable with LDAP, such as pub/priv keypairs. These can be stored in a directory, but it is quite a kludge to do so at this point. Thoughts and comments appreciated. Thanks, Ryan From godot at ulyssis.org Mon Jan 6 16:07:12 2003 From: godot at ulyssis.org (Danny De Cock) Date: Mon, 6 Jan 2003 06:07:12 +0100 (CET) Subject: SSH v3 specs? In-Reply-To: Message-ID: hi, I would be very interested in an ssh protocol which supports certificate validation. what I mean is this: if one uses a smartcard to perform the digital signature generation, the ssh client currently requires the presence of a certificate in that card, but the certificate itself is not used where it is designed for: the ssh server fetches the reference value of the smartcard's private key's public key from its authorized_keys file, but that's it. I would be very happy if the user's certificate could be stored in the authorized_keys file (or a similar file), and if the ssh server checked the digital signature on the challenge during the client's authentication using that certificate, and granting access to the user only if the certificate itself has been found to be valid... the ssh server could offer different validation mechanisms of the certificate: using a local set of trusted (possibly self-signed) certificates, fetching a certificate revocation list if necessary, presenting the certificate to an external certificate validation service (e.g., ocsp responder), etc. the easiest way for the ssh server to obtain the client's certificate could consist of the authorized_keys file, or the ssh client could push it to the server after having it fetched from a local repository (such as the user's smartcard)... does this sound reasonable to you, or pure nonsense? :)) cu, danny. On Sun, 5 Jan 2003 sshdev at rednu.com wrote: > Has any thought toward a v3 protocol spec been discussed elsewhere, > and if so what enhancements are being looked at. Is it too early to > consider such things, or should we open the door to the new features a > protocol update would bring? > > More specifically I have been investigating working toward a more > enterprise-friendly hierichical authentication scheme, but I have > quickly realized the magnitude of such a change. I have worked with > LDAP/PAM, but there are parts of ssh that are not very interoperable > with LDAP, such as pub/priv keypairs. These can be stored in a > directory, but it is quite a kludge to do so at this point. > > Thoughts and comments appreciated. > > Thanks, > > Ryan From avenkatesh79 at rediffmail.com Mon Jan 6 17:47:33 2003 From: avenkatesh79 at rediffmail.com (venki) Date: Mon, 6 Jan 2003 12:17:33 +0530 Subject: certificate in openssh Message-ID: <200301061217.33872.avenkatesh79@rediffmail.com> hi, we have been looking for ways to implement digital certificate authentication in openssh. Pointers to similar kind of ongoing work will be more appreciated. Thanks. From markus at openbsd.org Mon Jan 6 20:45:59 2003 From: markus at openbsd.org (Markus Friedl) Date: Mon, 6 Jan 2003 10:45:59 +0100 Subject: Is sftp-server's stdout redirected to client ? In-Reply-To: <1373.64.196.144.10.1041822765.squirrel@torvalds.csee.wvu.edu> References: <1373.64.196.144.10.1041822765.squirrel@torvalds.csee.wvu.edu> Message-ID: <20030106094559.GC13803@folly> this won't work. you need to extend the sftp protocol. sftp-server prints the messages to stdout and expencts the requests from the client on stdin. i don't think this change makes sense. On Sun, Jan 05, 2003 at 10:12:45PM -0500, zhang at csee.wvu.edu wrote: > Hello everyone, > > I added some code to sftp, which would be useful for me. I add a > command "run", which can run any command on the remote shell, in the mean > time I want the server send the standard output back. for example, when I : > > sftp> run ls > > I want to see the result locally. > > I thought the stdout of sftp-server has been redirected to the client. But > I get "message too long" error. When I check the received buffer, it do > have part of the server's standard output, but it is messed up. > > How do I fix it? Thanks, > > Hanzhou > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From markus at openbsd.org Mon Jan 6 20:48:21 2003 From: markus at openbsd.org (Markus Friedl) Date: Mon, 6 Jan 2003 10:48:21 +0100 Subject: SSH v3 specs? In-Reply-To: References: Message-ID: <20030106094821.GD13803@folly> On Mon, Jan 06, 2003 at 06:07:12AM +0100, Danny De Cock wrote: > I would be very interested in an ssh protocol which supports certificate > validation. how is this related to the ssh protocol? have you checked draft-ietf-secsh-transport-xx.txt ? the protocol already supports certificates. From markus at openbsd.org Mon Jan 6 20:49:57 2003 From: markus at openbsd.org (Markus Friedl) Date: Mon, 6 Jan 2003 10:49:57 +0100 Subject: SSH v3 specs? In-Reply-To: References: Message-ID: <20030106094957.GE13803@folly> On Sun, Jan 05, 2003 at 04:41:02PM -0600, sshdev at rednu.com wrote: > Has any thought toward a v3 protocol spec been discussed > elsewhere, and if so what enhancements are being looked > at. Is it too early to consider such things, or should we > open the door to the new features a protocol update would > bring? where is ssh v3 beeing discussed? > > More specifically I have been investigating working toward > a more enterprise-friendly hierichical authentication > scheme, but I have quickly realized the magnitude of such > a change. I have worked with LDAP/PAM, but there are > parts of ssh that are not very interoperable with LDAP, > such as pub/priv keypairs. These can be stored in a > directory, but it is quite a kludge to do so at this > point. storing the private keys in LDAP makes no sense, but why is storing the public keys a problem? From markus at openbsd.org Mon Jan 6 20:50:57 2003 From: markus at openbsd.org (Markus Friedl) Date: Mon, 6 Jan 2003 10:50:57 +0100 Subject: SSH v3 specs? In-Reply-To: References: Message-ID: <20030106095057.GF13803@folly> On Sun, Jan 05, 2003 at 04:41:02PM -0600, sshdev at rednu.com wrote: > More specifically I have been investigating working toward > a more enterprise-friendly hierichical authentication > scheme, but I have quickly realized the magnitude of such > a change. i don't think you need a new protocol versions if you want to do this. you can take what's already there. From godot at ulyssis.org Mon Jan 6 22:53:53 2003 From: godot at ulyssis.org (Danny De Cock) Date: Mon, 6 Jan 2003 12:53:53 +0100 (CET) Subject: SSH v3 specs? In-Reply-To: <20030106094821.GD13803@folly> Message-ID: On Mon, 6 Jan 2003, Markus Friedl wrote: > On Mon, Jan 06, 2003 at 06:07:12AM +0100, Danny De Cock wrote: > > I would be very interested in an ssh protocol which supports certificate > > validation. > > how is this related to the ssh protocol? it is true that the validation itself is not related to certificate validation, but the user's certificate might have to be pushed to the server during the user authentication step... > have you checked draft-ietf-secsh-transport-xx.txt ? not yet ];-) cu, danny. > the protocol already supports certificates. From mks at noida.hcltech.com Tue Jan 7 01:03:33 2003 From: mks at noida.hcltech.com (Manish Kumar Srivastava, Noida) Date: Mon, 6 Jan 2003 19:33:33 +0530 Subject: ssh 3.1p1 problems on SX-6... Message-ID: Hello, We are porting openssh-3.1p1 onto SX-6 running on SuperUX. We landed into problem when we started running sshd with the default encryption settings. As you would have already seen on this mailing list. Basically we are facing two problems (both client and servers run on SX):- 1) If the we use the default encryption algorithm aes128-cbc then we get a Bad Packet length problem on server side. 2) If we run the sshd after setting encryption algorithm to say 3des-cbc or aes192-cbc, then everything works fine except for sftp. When we exit from sftp then it hangs in select() called from server_loop2(). Both the problems are posted on the mailing list and both recur with the latest version of openssh i.e. 3.5p1 with openssl 0.9.6b. Kindly suggest something. We want to fix the problems. Best Regards Manish From maf at appgate.com Tue Jan 7 02:25:15 2003 From: maf at appgate.com (maf at appgate.com) Date: Mon, 6 Jan 2003 16:25:15 +0100 (CET) Subject: SSH v3 specs? Message-ID: <20030106152542.DF2036C7C2@shala.firedoor.se> On 5 Jan, sshdev at rednu.com wrote: > Has any thought toward a v3 protocol spec been discussed > elsewhere, and if so what enhancements are being looked > at. Is it too early to consider such things, or should we > open the door to the new features a protocol update would > bring? I am not aware of any such discussion and I do not see any need for it either. The ssh protocol is quite flexible and new authentication methods can be defined without moving to a new protocol version (IMHO a very good thing:-). > More specifically I have been investigating working toward > a more enterprise-friendly hierichical authentication > scheme, but I have quickly realized the magnitude of such > a change. I have worked with LDAP/PAM, but there are > parts of ssh that are not very interoperable with LDAP, > such as pub/priv keypairs. These can be stored in a > directory, but it is quite a kludge to do so at this > point. I agree that the normal pub/priv keyparts do not operate very well with LDAP but why should they? You can always use certificates instead of the current pub/priv keypairs, and that can work well with LDAP. Our product, AppGate, which uses ssh also supports certificate authentication and that without any protocol modifications whatsoever. /MaF -- Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From mouring at etoh.eviladmin.org Mon Jan 6 21:22:43 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 6 Jan 2003 04:22:43 -0600 (CST) Subject: ssh 3.1p1 problems on SX-6... In-Reply-To: Message-ID: On Mon, 6 Jan 2003, Manish Kumar Srivastava, Noida wrote: > Hello, > > We are porting openssh-3.1p1 onto SX-6 running on SuperUX. > We landed into problem when we started running sshd with > the default encryption settings. As you would have already > seen on this mailing list. > First off.. I have no clue what SX-6 is.. Nor what hardware it runs on. Nor how old it may be. So it would be nice to be clued in on that. Maybe even what branch of the UNIX tree it was formed from. > Basically we are facing two problems (both client and servers > run on SX):- > > 1) If the we use the default encryption algorithm aes128-cbc > then we get a Bad Packet length problem on server side. > Don't know. Most of the time I've seen 'Bad Packet length' it was a broken OpenSSL. IIRC in the OpenSSL tree there is a 'make test' that allows you to see if everything passes. > 2) If we run the sshd after setting encryption algorithm > to say 3des-cbc or aes192-cbc, then everything works fine > except for sftp. When we exit from sftp then it hangs in > select() called from server_loop2(). > My tired and befuddled brain wants to say scream out 'race condition', but even after skimming your last emails. I really am not sure off hand. I know AIX has oddities under some releases for select(). > Both the problems are posted on the mailing list and both > recur with the latest version of openssh i.e. 3.5p1 with > openssl 0.9.6b. Kindly suggest something. We want to fix > the problems. > I wish I could give you more direct help, but at this point. I'm not sure what to even suggest for a starting point. - Ben From markus at openbsd.org Tue Jan 7 02:56:23 2003 From: markus at openbsd.org (Markus Friedl) Date: Mon, 6 Jan 2003 16:56:23 +0100 Subject: ssh 3.1p1 problems on SX-6... In-Reply-To: References: Message-ID: <20030106155623.GD9618@folly> On Mon, Jan 06, 2003 at 07:33:33PM +0530, Manish Kumar Srivastava, Noida wrote: > Hello, > > We are porting openssh-3.1p1 onto SX-6 running on SuperUX. > We landed into problem when we started running sshd with > the default encryption settings. As you would have already > seen on this mailing list. > > Basically we are facing two problems (both client and servers > run on SX):- > > 1) If the we use the default encryption algorithm aes128-cbc > then we get a Bad Packet length problem on server side. when does this happen exactly? please turn on all debugging and include the error messages. you could also recompile packet.c with debugging enabled. From tim at multitalents.net Tue Jan 7 03:49:10 2003 From: tim at multitalents.net (Tim Rice) Date: Mon, 6 Jan 2003 08:49:10 -0800 (PST) Subject: ssh 3.1p1 problems on SX-6... In-Reply-To: References: Message-ID: On Mon, 6 Jan 2003, Manish Kumar Srivastava, Noida wrote: > Both the problems are posted on the mailing list and both > recur with the latest version of openssh i.e. 3.5p1 with > openssl 0.9.6b. Kindly suggest something. We want to fix > the problems. openssl 0.9.6b is quite old. Do you still have problems if you use openssl 0.9.6h ? -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From Jeff.Layton at bellhowell.com Tue Jan 7 03:52:57 2003 From: Jeff.Layton at bellhowell.com (Jeffrey Layton) Date: 06 Jan 2003 11:52:57 -0500 Subject: ownership permissions on files replaced via scp -- bug or feature? Message-ID: <1041871977.1036.51.camel@tesla> I've noticed the following behavior on files that are overwritten with an scp command and I can't decide if this is intended behavior or a bug? Can someone with a little more insight please share the reasoning for this (if any)? I've tested this with a mix of 3.4p1 and 3.5p1 hosts. Suppose we have 2 files on different hosts, with different group ownership and permissions. user1 is not a member of either group foo or group bar: user at host1:/tmp% ls -l /tmp/testfile -rw-r--r-- 1 user1 foo 5 Jan 6 11:14 /tmp/testfile user at host2:~% ls -l /tmp/testfile -rw-rw-r-- 1 user1 bar 6 Jan 6 11:37 /tmp/testfile If I then scp this file from host1 to host2: laytonj at host1:/tmp% scp testfile host2:/tmp The contents of testfile on host2 are overwritten, but permissions and ownership are preserved. user at host2:~% ls -l /tmp/testfile -rw-rw-r-- 1 user1 bar 5 Jan 6 11:39 /tmp/testfile The same rule applies as long as the user has write permission to the file. sshd seems to preserve permissions on any file that is replaced, whether the user making the copy is a member of that group or not. It seems to me that the permissions should be set as if the user were creating a new file here unless for instance, the -p flag is used, and the user is capable of setting permissions on the resulting file to match the source file. Is this also potentially a security hole? A malicious user with the ability to write to a file might be able to upload a trojaned binary here or some such mischief. -- Jeffrey Layton Bell & Howell MMT -------------- 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/20030106/4b29e38c/attachment.bin From markus at openbsd.org Tue Jan 7 05:41:26 2003 From: markus at openbsd.org (Markus Friedl) Date: Mon, 6 Jan 2003 19:41:26 +0100 Subject: ownership permissions on files replaced via scp -- bug or feature? In-Reply-To: <1041871977.1036.51.camel@tesla> References: <1041871977.1036.51.camel@tesla> Message-ID: <20030106184126.GD30206@folly> ihmo, the ownership of the target file should only be changed if -p is given on the command line. From wendyp at cray.com Tue Jan 7 07:07:20 2003 From: wendyp at cray.com (Wendy Palm) Date: Mon, 06 Jan 2003 14:07:20 -0600 Subject: ssh 3.1p1 problems on SX-6... References: Message-ID: <3E19E1F8.8000100@cray.com> SX-6 is the NEC machine followon to the SX-5. SuperUX is the OS. Cray Inc currently provides support for some of these machines in the US and i have a openssh port of 3.4p1 that runs on one. we haven't run into this particular problem, so our port must be more complete than manish's. be a bit patient and i'll update it to 3.5 and provide our patches for manish to try. Ben Lindstrom wrote: > > On Mon, 6 Jan 2003, Manish Kumar Srivastava, Noida wrote: > > >>Hello, >> >>We are porting openssh-3.1p1 onto SX-6 running on SuperUX. >>We landed into problem when we started running sshd with >>the default encryption settings. As you would have already >>seen on this mailing list. >> > > First off.. I have no clue what SX-6 is.. Nor what hardware it runs on. > Nor how old it may be. So it would be nice to be clued in on that. Maybe > even what branch of the UNIX tree it was formed from. > > >>Basically we are facing two problems (both client and servers >>run on SX):- >> >>1) If the we use the default encryption algorithm aes128-cbc >> then we get a Bad Packet length problem on server side. >> >> > > Don't know. Most of the time I've seen 'Bad Packet length' it was a > broken OpenSSL. IIRC in the OpenSSL tree there is a 'make test' that > allows you to see if everything passes. > > > >>2) If we run the sshd after setting encryption algorithm >> to say 3des-cbc or aes192-cbc, then everything works fine >> except for sftp. When we exit from sftp then it hangs in >> select() called from server_loop2(). >> >> > > My tired and befuddled brain wants to say scream out 'race condition', but > even after skimming your last emails. I really am not sure off hand. I > know AIX has oddities under some releases for select(). > > >>Both the problems are posted on the mailing list and both >>recur with the latest version of openssh i.e. 3.5p1 with >>openssl 0.9.6b. Kindly suggest something. We want to fix >>the problems. >> >> > > I wish I could give you more direct help, but at this point. I'm not sure > what to even suggest for a starting point. > > - Ben > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From pdbarnes at llnl.gov Tue Jan 7 09:49:15 2003 From: pdbarnes at llnl.gov (Peter D. Barnes, Jr.) Date: Mon, 6 Jan 2003 14:49:15 -0800 Subject: OpenSSH-3.5p1 with Kerberos on Mac OS X.2 Message-ID: I've advanced three patches: Simon Wilkinson's patch, Steven Michaud's patch, Alexandra Ellwood's fix for the krb5_init_ets linker error from OpenSSH-3.4p1 to OpenSSH-3.5p1 as a single patch, available at http://home.fnal.gov/~pdbarnes/openSSH.html Enjoy, Peter From djm at mindrot.org Tue Jan 7 10:14:52 2003 From: djm at mindrot.org (Damien Miller) Date: Tue, 07 Jan 2003 10:14:52 +1100 Subject: SSH v3 specs? In-Reply-To: References: Message-ID: <3E1A0DEC.2080508@mindrot.org> sshdev at rednu.com wrote: > Has any thought toward a v3 protocol spec been discussed elsewhere, and > if so what enhancements are being looked at. Is it too early to > consider such things, or should we open the door to the new features a > protocol update would bring? What can't you do with the existing protocol? It is very flexible and extensible... -d From bugzilla-daemon at mindrot.org Tue Jan 7 10:21:29 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 10:21:29 +1100 (EST) Subject: [Bug 401] ipv4 mapped address (ipv4 in ipv6) and ipv6 support fix Message-ID: <20030106232129.9DCDC64538@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=401 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #148 is|0 |1 obsolete| | Attachment #194 is|0 |1 obsolete| | ------- Additional Comments From djm at mindrot.org 2003-01-07 10:21 ------- Created an attachment (id=195) --> (http://bugzilla.mindrot.org/attachment.cgi?id=195&action=view) More simple patch This patch should be OK for all platforms without evil #ifdefs ------- 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 Jan 7 10:48:36 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 10:48:36 +1100 (EST) Subject: [Bug 426] sftp adds write permission when doing get -p Message-ID: <20030106234836.4699264570@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=426 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-07 10:48 ------- 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 Tue Jan 7 10:51:45 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 10:51:45 +1100 (EST) Subject: [Bug 401] ipv4 mapped address (ipv4 in ipv6) and ipv6 support fix Message-ID: <20030106235145.91B6164577@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=401 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-07 10:51 ------- Applied - this should be neutral to other platforms. ------- 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 Jan 7 10:57:47 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 10:57:47 +1100 (EST) Subject: [Bug 408] sshd[25790]: error: socket: Protocol not supported Message-ID: <20030106235747.939396457F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=408 ------- Additional Comments From djm at mindrot.org 2003-01-07 10:57 ------- Workaround: Use "-L 3100:127.0.0.1:3128" if you don't have IPv6 on your hosts ------- 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 Jan 7 11:07:14 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 11:07:14 +1100 (EST) Subject: [Bug 403] scp generates sparse file when no space left Message-ID: <20030107000714.2CECA64535@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=403 ------- Additional Comments From djm at mindrot.org 2003-01-07 11:07 ------- Created an attachment (id=196) --> (http://bugzilla.mindrot.org/attachment.cgi?id=196&action=view) Shorter fix Here is a shorter fix (rcp needs it too) ------- 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 Jan 7 11:07:35 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 11:07:35 +1100 (EST) Subject: [Bug 403] scp generates sparse file when no space left Message-ID: <20030107000735.4825264573@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=403 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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 Jan 7 11:08:11 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 11:08:11 +1100 (EST) Subject: [Bug 404] getnameinfo failed Message-ID: <20030107000811.45B4A64589@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=404 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- 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 Jan 7 11:08:59 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 11:08:59 +1100 (EST) Subject: [Bug 407] Build openssh-3.1p1 fails, Mac OS X v1.2 Message-ID: <20030107000859.9A17864589@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=407 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- 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 Jan 7 11:09:12 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 11:09:12 +1100 (EST) Subject: [Bug 408] sshd[25790]: error: socket: Protocol not supported Message-ID: <20030107000912.8377464594@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=408 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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 Jan 7 12:19:42 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 12:19:42 +1100 (EST) Subject: [Bug 442] sshd allows login via public-key when account locked Message-ID: <20030107011942.519C164545@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=442 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-07 12:19 ------- 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 Tue Jan 7 12:20:39 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 12:20:39 +1100 (EST) Subject: [Bug 445] User DCE Credentials do not get forwarded to child session Message-ID: <20030107012039.A576764526@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=445 ------- Additional Comments From djm at mindrot.org 2003-01-07 12:20 ------- The attached patch has been corrupted - please attach it (in "diff -u" format) to the bug using the "Create Attachment" link ------- 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 Jan 7 14:49:26 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 14:49:26 +1100 (EST) Subject: [Bug 452] sftp does not abort when commands given via -b fail Message-ID: <20030107034926.662A064526@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=452 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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 Jan 7 15:03:51 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 15:03:51 +1100 (EST) Subject: [Bug 26] ssh setting O_NONBLOCK on stderr can upset CVS Message-ID: <20030107040351.E450D64579@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=26 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2003-01-07 15:03 ------- ssh can't afford for its stderr to ever block, as this would freeze all sessions and port-forwardings. We therefore can't remove the nonblock from stderr. ------- 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 Jan 7 15:18:50 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 15:18:50 +1100 (EST) Subject: [Bug 44] Can't pass KRB4 TGT on RH7.2 due to glibc mkstemp Message-ID: <20030107041850.94C5864579@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=44 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-07 15:18 ------- Applied - thanks. I have no idea why it too me so long... ------- 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 Jan 7 15:32:10 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 15:32:10 +1100 (EST) Subject: [Bug 46] patches between portability revisions Message-ID: <20030107043210.0070664545@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=46 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2003-01-07 15:32 ------- Maybe someone in the community could provide these - I'm too busy. ------- 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 Jan 7 15:33:27 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 15:33:27 +1100 (EST) Subject: [Bug 65] TCP Wrappers support does not log successful connections Message-ID: <20030107043327.E5EC26453A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=65 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2003-01-07 15:33 ------- You can do this by setting LogLevel verbose ------- 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 Jan 7 15:34:06 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 15:34:06 +1100 (EST) Subject: [Bug 69] Generalize SSH_ASKPASS Message-ID: <20030107043406.02794645A7@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=69 ------- Additional Comments From djm at mindrot.org 2003-01-07 15:34 ------- hmmm, alternately you can fake it by setting "DISPLAY=foo" ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From andreas at arescon.com Tue Jan 7 15:44:42 2003 From: andreas at arescon.com (andreas at arescon.com) Date: Mon, 6 Jan 2003 20:44:42 -0800 (PST) Subject: Bug in Ossh3.5p1 Message-ID: <200301070444.h074igS04883@geolin6.arescon.com> We use OpenSSH 3.5p1 on an embedded system. OpenSSH is configured to not permit password logins, /etc/ssh/sshd_config: ... PasswordAuthentication no ... At the same time, since there is no console and no way to "log in" other than by ssh, /etc/passwd has an "open" root account: root::0:0:root:/root:/bin/sh nobody:x:65534:65534:nobody:/tmp:/usr/bin/bash Apparently OpenSSH3.5p1 ignores "PasswordAuthentication no" whenever sombody comes from a root account on some_host: ----------------------------------------------------------------- root at somehost:~# ssh -2 -v OpenSSH_2.9.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Seeding random number generator debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 0 geteuid 0 anon 1 debug1: Connecting to [] port 22. debug1: temporarily_use_uid: 0/0 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 0/0 (e=0) debug1: restore_uid debug1: Connection established. debug1: read PEM private key done: type DSA debug1: read PEM private key done: type RSA debug1: identity file /root/.ssh/id_rsa type -1 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 Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_2.9.9p2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none 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: 113/256 debug1: bits set: 1613/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host '' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:43 debug1: bits set: 1597/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: ssh-userauth2 successful: method none debug1: channel 0: new [client-session] debug1: send channel open 0 debug1: Entering interactive session. debug1: ssh_session2_setup: id 0 debug1: Requesting X11 forwarding with authentication spoofing. debug1: channel request 0: shell debug1: channel 0: open confirm rwindow 0 rmax 32768 Last login: Tue Jan 7 03:20:25 2003 from bash# --------------------------------------------------------------- Bang, I'm in with: "ssh-userauth2 successful: method none". No keys necessary. The same does NOT work with ssh -1 ... --------------------------------------------------------------- root at somehost:~# ssh -1 -v root@ OpenSSH_2.5.2p2, SSH protocols 1.5/2.0, OpenSSL 0x0090600f debug1: Seeding random number generator debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: ssh_connect: getuid 0 geteuid 0 anon 1 debug1: Connecting to [] port 22. debug1: Connection established. debug1: identity file /root/.ssh/identity type 0 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1 debug1: match: OpenSSH_3.5p1 pat ^OpenSSH debug1: Local version string SSH-1.5-OpenSSH_2.5.2p2 debug1: Waiting for server public key. debug1: Received server public key (768 bits) and host key (1024 bits). debug1: Host 'some ip-number' is known and matches the RSA1 host key. debug1: Found key in /root/.ssh/known_hosts:2 debug1: Encryption type: 3des debug1: Sent encrypted session key. debug1: Installing crc compensation attack detector. debug1: Received encrypted confirmation. debug1: Trying RSA authentication with key 'root at somehost' debug1: Server refused our key. Permission denied. debug1: Calling cleanup 0x8061610(0x0) -------------------------------------------------------------- If /etc/passwd has the root account x-ed out: root:x:0:0:root:/root:/bin/sh ssh -2 also rejects the connection. Am I right to consider this a bug and a potential security problem, since protocol version 1 seems to behave as expected, while version 2 appears to look at the password file despite "PasswordAuthentication no" in the config file ? Or am I just missing something important ? I'm not a regular subscriber, I'd appreciate comments to rosenberger at pgc.nrcan.gc.ca or andreas at arescon.com -- ___________________________________________________________________ a. rosenberger arescon ltd. andreas at arescon.com 9706 First St. www.arescon.com Sidney, B.C. Canada V8L 3C7 ___________________________________________________________________ From bugzilla-daemon at mindrot.org Tue Jan 7 16:45:02 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 16:45:02 +1100 (EST) Subject: [Bug 463] New: PrintLastLog doesn't work in privsep mode Message-ID: <20030107054502.AD78C64535@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=463 Summary: PrintLastLog doesn't work in privsep mode Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: djm at mindrot.org The call to get_last_login_time() in session.c happens in the child without being wrapped in the monitor. Only root gets the lastlog time printed if the lastlog file isn't world-readable. ------- 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 Jan 7 16:47:10 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 16:47:10 +1100 (EST) Subject: [Bug 110] bogus error messages in lastlog_get_entry() Message-ID: <20030107054710.9E6566455E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=110 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-07 16:47 ------- 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 Tue Jan 7 17:05:48 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 17:05:48 +1100 (EST) Subject: [Bug 111] sshd syslogs raw untrusted data Message-ID: <20030107060548.330F864562@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=111 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-07 17:05 ------- Patch applied. I don't think there should be header file clashes with graphviz, but please file separate bug reports if there are. ------- 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 Jan 7 17:13:11 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 17:13:11 +1100 (EST) Subject: [Bug 127] PAM with ssh authentication and pam_krb5 doesn't work properly Message-ID: <20030107061311.4462264568@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=127 ------- Additional Comments From djm at mindrot.org 2003-01-07 17:13 ------- This fix is incorrect - the creds (which are often supplemental groups) need to be restablished after initgroups(), which we call elsewhere. Does the PAM module not support restablishing credentials? ------- 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 Jan 7 17:18:45 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 17:18:45 +1100 (EST) Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20030107061845.338F6645C2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |b_smith44 at hotmail.com ------- Additional Comments From djm at mindrot.org 2003-01-07 17:18 ------- *** Bug 129 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 bugzilla-daemon at mindrot.org Tue Jan 7 17:28:05 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 17:28:05 +1100 (EST) Subject: [Bug 143] Add reference to "rsync" in FAQ and documentation. Message-ID: <20030107062805.D114E645C8@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=143 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2003-01-07 17:28 ------- wontfix ------- 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 Jan 7 17:30:56 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 17:30:56 +1100 (EST) Subject: [Bug 161] Cannot build afs support on Solaris platform Message-ID: <20030107063056.5747F645CC@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=161 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2003-01-07 17:30 ------- It is up to the system to provide compatible AFS libs ------- 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 Jan 7 17:39:10 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 17:39:10 +1100 (EST) Subject: [Bug 178] Content of /etc/nologin isn't shown to users, fix triggers probably AIX bug Message-ID: <20030107063910.82D7D645D3@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=178 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-07 17:39 ------- 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 Tue Jan 7 17:40:35 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 17:40:35 +1100 (EST) Subject: [Bug 189] pam_setcred() failures should not be treated as fatal Message-ID: <20030107064035.D05A5645D7@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=189 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-07 17:40 ------- 9 months, no followup == no bug ------- 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 Jan 7 17:40:48 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 17:40:48 +1100 (EST) Subject: [Bug 189] pam_setcred() failures should not be treated as fatal Message-ID: <20030107064048.7AE5B645D9@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=189 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |INVALID ------- Additional Comments From djm at mindrot.org 2003-01-07 17:40 ------- 9 months, no followup == no bug ------- 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 Jan 7 17:41:15 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 17:41:15 +1100 (EST) Subject: [Bug 193] sshd: error: select: Bad file number Message-ID: <20030107064115.63008645E1@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=193 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From djm at mindrot.org 2003-01-07 17:41 ------- 9 months, no followup == no bug ------- 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 Jan 7 17:49:46 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 17:49:46 +1100 (EST) Subject: [Bug 202] scp/ssh hangs Message-ID: <20030107064946.64E636455D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=202 ------- Additional Comments From djm at mindrot.org 2003-01-07 17:49 ------- Is anyone seeing this with 3.5p1? If so, please report the software and versions of client and server. ------- 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 Jan 7 17:52:57 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 17:52:57 +1100 (EST) Subject: [Bug 210] can't prevent port forwarding on a per-user basis Message-ID: <20030107065257.407E56459A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=210 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From djm at mindrot.org 2003-01-07 17:52 ------- I should rewrite the keynote stuff with privsep in mind (i.e do checking in child) ------- 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 Jan 7 17:54:15 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 17:54:15 +1100 (EST) Subject: [Bug 211] ssh-keygen aborts if passphrase <= 4 bytes for RSA/DSA private key Message-ID: <20030107065415.E93706455D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=211 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2003-01-07 17:54 ------- Don't blame us - this check happens in openssl :) ------- 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 Jan 7 17:55:27 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 17:55:27 +1100 (EST) Subject: [Bug 212] Add netgroup support to ssh-keyscan Message-ID: <20030107065527.A8192645F8@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=212 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2003-01-07 17:55 ------- Fix would be a standalone program, if anyone could be bothered writing 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 Tue Jan 7 17:58:29 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 17:58:29 +1100 (EST) Subject: [Bug 128] PAM with ssh authentication and pam_krb5 doesn't work properly Message-ID: <20030107065829.117B6645C2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=128 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From djm at mindrot.org 2003-01-07 17:58 ------- Bug #127 can be the catchall "pam_krb5 is busted" bug *** This bug has been marked as a duplicate of 127 *** ------- 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 Jan 7 17:58:30 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 17:58:30 +1100 (EST) Subject: [Bug 127] PAM with ssh authentication and pam_krb5 doesn't work properly Message-ID: <20030107065830.C72D2645FB@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=127 ------- Additional Comments From djm at mindrot.org 2003-01-07 17:58 ------- *** Bug 128 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 bugzilla-daemon at mindrot.org Tue Jan 7 17:58:53 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 17:58:53 +1100 (EST) Subject: [Bug 228] pam_krb5 on Solaris creates credentials with wrong owner Message-ID: <20030107065853.76A42645C2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=228 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From djm at mindrot.org 2003-01-07 17:58 ------- This seems to be a better description of Bug #127 *** This bug has been marked as a duplicate of 127 *** ------- 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 Jan 7 17:58:55 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 17:58:55 +1100 (EST) Subject: [Bug 127] PAM with ssh authentication and pam_krb5 doesn't work properly Message-ID: <20030107065855.27F08645FF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=127 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gunnar at Astrogator.SE ------- Additional Comments From djm at mindrot.org 2003-01-07 17:58 ------- *** Bug 228 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 bugzilla-daemon at mindrot.org Tue Jan 7 17:59:58 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 17:59:58 +1100 (EST) Subject: [Bug 238] sshd.pid file written AFTER key generation causes race condition Message-ID: <20030107065958.898C8645C2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=238 ------- Additional Comments From djm at mindrot.org 2003-01-07 17:59 ------- What if the ephemeral key generation fails (e.g. not enough entropy, etc) ------- 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 Jan 7 18:03:19 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 18:03:19 +1100 (EST) Subject: [Bug 240] ssh fails to handle errno == EHOSTUNREACH properly Message-ID: <20030107070319.A4603645C2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=240 ------- Additional Comments From djm at mindrot.org 2003-01-07 18:03 ------- When are you seeing EHOSTUNREACH? Not on write()... ------- 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 Jan 7 18:04:41 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 18:04:41 +1100 (EST) Subject: [Bug 244] Remote port forwarding on solaris 8x86 doesn't work Message-ID: <20030107070441.5669B64619@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=244 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-07 18:04 ------- Six months, no confirmation == no bug (it looks like an ip config or ipv4 vs ipv6 config problem) ------- 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 Jan 7 18:07:45 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 18:07:45 +1100 (EST) Subject: [Bug 252] Patch for use of /etc/default/login Message-ID: <20030107070745.DC82564618@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=252 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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 Jan 7 18:08:11 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 18:08:11 +1100 (EST) Subject: [Bug 253] Patch to write process ID to a file when ssh sets itself into daemon mode Message-ID: <20030107070811.E74E764618@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=253 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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 Jan 7 18:10:51 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 18:10:51 +1100 (EST) Subject: [Bug 262] ssh fails when run by cron. Message-ID: <20030107071051.47719645E1@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=262 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From djm at mindrot.org 2003-01-07 18:10 ------- 6 months, no followup == no bug ------- 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 Jan 7 18:13:10 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 18:13:10 +1100 (EST) Subject: [Bug 271] SSHD should unblock SIGCHLD - POSIX signal blocks survive exec() Message-ID: <20030107071310.28C646462A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=271 ------- Additional Comments From djm at mindrot.org 2003-01-07 18:13 ------- We already reset SIGCHLD to SIG_DFL in main(), maybe we don't do it early enough... ------- 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 Jan 7 18:14:08 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 18:14:08 +1100 (EST) Subject: [Bug 273] sshd hangs on shell exit if user spawned child with /bin/nohup Message-ID: <20030107071408.4E3746462D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=273 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From djm at mindrot.org 2003-01-07 18:14 ------- This is a variant of the infamous hang-on-exit bug *** This bug has been marked as a duplicate of 52 *** ------- 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 Jan 7 18:14:10 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 18:14:10 +1100 (EST) Subject: [Bug 52] ssh hangs on exit Message-ID: <20030107071410.1FBC564630@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=52 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kerry.schwab at wnco.com ------- Additional Comments From djm at mindrot.org 2003-01-07 18:14 ------- *** Bug 273 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 bugzilla-daemon at mindrot.org Tue Jan 7 18:15:23 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 18:15:23 +1100 (EST) Subject: [Bug 281] unable to authorize with local shadow password Message-ID: <20030107071523.DAE8564639@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=281 ------- Additional Comments From djm at mindrot.org 2003-01-07 18:15 ------- does "ssh -oKerberosAuthentication=no host" work? ------- 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 Jan 7 18:18:25 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 18:18:25 +1100 (EST) Subject: [Bug 310] sshd reporting ai_socktype errors when using ssh -X to server Message-ID: <20030107071825.BFFFD6463E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=310 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary| sshd reporting ai_socktype |sshd reporting ai_socktype |errors when using ssh -X to |errors when using ssh -X to |server |server ------- Additional Comments From djm at mindrot.org 2003-01-07 18:18 ------- Could you please attach the output of a ./configure run? ------- 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 Jan 7 18:20:29 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 18:20:29 +1100 (EST) Subject: [Bug 311] Compile fails on MIPS Linux (Cobalt Raq2) - SCM_RIGHTS undeclared Message-ID: <20030107072029.C89F264564@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=311 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From djm at mindrot.org 2003-01-07 18:20 ------- (closing, as this is a busted glibc problem) Please note that the workaround patch cannot be applied to openssh - you really need to bug your vendor about getting fixed headers. ------- 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 Jan 7 18:21:40 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 18:21:40 +1100 (EST) Subject: [Bug 318] Install failure creating ssh_prng_cmds Message-ID: <20030107072140.ED33D64646@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=318 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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 Jan 7 18:23:59 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 18:23:59 +1100 (EST) Subject: [Bug 331] ssh w/o privilege separation does not work for non-root users Message-ID: <20030107072359.677EE64564@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=331 ------- Additional Comments From djm at mindrot.org 2003-01-07 18:23 ------- 3 months, no followup == no bug ------- 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 Jan 7 18:24:13 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 18:24:13 +1100 (EST) Subject: [Bug 331] ssh w/o privilege separation does not work for non-root users Message-ID: <20030107072413.C7EAB64564@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=331 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From djm at mindrot.org 2003-01-07 18:24 ------- 3 months, no followup == no bug ------- 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 Jan 7 18:26:51 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 18:26:51 +1100 (EST) Subject: [Bug 341] Return Code unpredictable Message-ID: <20030107072651.795DD645F9@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=341 ------- Additional Comments From djm at mindrot.org 2003-01-07 18:26 ------- Please verify that this is still the case with 3.5p1 (2.9 is ooold) ------- 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 Jan 7 18:31:24 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 18:31:24 +1100 (EST) Subject: [Bug 83] PAM limits applied incorrectly (pam_session being called as non-root) Message-ID: <20030107073124.0AE74645FF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=83 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rudolph at getsystems.com ------- Additional Comments From djm at mindrot.org 2003-01-07 18:31 ------- *** Bug 354 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 bugzilla-daemon at mindrot.org Tue Jan 7 18:31:22 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 18:31:22 +1100 (EST) Subject: [Bug 354] sshd with privsep doesn't do pam session setup properly Message-ID: <20030107073122.B8CF6645F9@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=354 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From djm at mindrot.org 2003-01-07 18:31 ------- *** This bug has been marked as a duplicate of 83 *** ------- 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 Jan 7 18:32:14 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 18:32:14 +1100 (EST) Subject: [Bug 358] password authentication fails Message-ID: <20030107073214.2B6B964663@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=358 ------- Additional Comments From djm at mindrot.org 2003-01-07 18:32 ------- Please supply detailed server output "sshd -d -d -d" ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From avraham.fraenkel at commatch.com Tue Jan 7 19:10:43 2003 From: avraham.fraenkel at commatch.com (Avraham Fraenkel - Commatch) Date: Tue, 7 Jan 2003 10:10:43 +0200 Subject: Is sftp-server's stdout redirected to client ? Message-ID: Hello, Another suggestion - redirect the command output to stderr, this will go to the sftp-client stderr and (in openssh client) will showed on the screen. (The syntax depend on the shell on the server). In the sftp protocol there is no way to send data to the client in any other way. -- Avraham --------------------------------------- Markus Friedl Wrote: this won't work. you need to extend the sftp protocol. sftp-server prints the messages to stdout and expencts the requests from the client on stdin. i don't think this change makes sense. On Sun, Jan 05, 2003 at 10:12:45PM -0500, zhang at csee.wvu.edu wrote: > Hello everyone, > > I added some code to sftp, which would be useful for me. I add a > command "run", which can run any command on the remote shell, in the mean > time I want the server send the standard output back. for example, when I : > > sftp> run ls > > I want to see the result locally. > > I thought the stdout of sftp-server has been redirected to the client. But > I get "message too long" error. When I check the received buffer, it do > have part of the server's standard output, but it is messed up. > > How do I fix it? Thanks, > > Hanzhou > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From bugzilla-daemon at mindrot.org Tue Jan 7 20:28:31 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 20:28:31 +1100 (EST) Subject: [Bug 46] patches between portability revisions Message-ID: <20030107092831.A28C664534@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=46 ------- Additional Comments From dtucker at zip.com.au 2003-01-07 20:28 ------- I'll volunteer to do this for now. Diffs can be found at http://www.zip.com.au/~dtucker/openssh/diffs/ Please report any problems directly to me. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bob at proulx.com Tue Jan 7 21:04:06 2003 From: bob at proulx.com (Bob Proulx) Date: Tue, 7 Jan 2003 03:04:06 -0700 Subject: ownership permissions on files replaced via scp -- bug or feature? In-Reply-To: <1041871977.1036.51.camel@tesla> References: <1041871977.1036.51.camel@tesla> Message-ID: <20030107100406.GA1241@misery.proulx.com> Jeffrey Layton [2003-01-06 11:52:57 -0500]: > I've noticed the following behavior on files that are overwritten with > an scp command and I can't decide if this is intended behavior or a bug? I am sure the original UNIX behavior evolved as a natural consequence of the filesystem model. It was the default behavior of cp when the target file is a previously existing file. Now after 30 years of usage, it certainly is the expected behavior for cp. Since scp is modeled after cp it follows that scp should behave similarly to cp. It does not have to follow it exactly. But in the cases that it does not there should be good reason to depart from accepted practice. > Can someone with a little more insight please share the reasoning for > this (if any)? I've tested this with a mix of 3.4p1 and 3.5p1 hosts. You might want to look at the behavior of 'cp' in this regard. Or 'cat src > dst' for that matter. You will find them to be the same. This is not something new and unique to scp but common program behavior. > The contents of testfile on host2 are overwritten, but permissions and > ownership are preserved. > > user at host2:~% ls -l /tmp/testfile > -rw-rw-r-- 1 user1 bar 5 Jan 6 11:39 /tmp/testfile > > The same rule applies as long as the user has write permission to the > file. sshd seems to preserve permissions on any file that is replaced, > whether the user making the copy is a member of that group or not. You used the word 'overwrite' most of the time in the message. But then here you say 'replaced'. Saying overwrite is more accurate since the file is previously existing it is getting overwritten with new file contents. The inode and therefore the owner, group, mode, is not changing. > It seems to me that the permissions should be set as if the user were > creating a new file here unless for instance, the -p flag is used, and > the user is capable of setting permissions on the resulting file to > match the source file. If this bothers you then you could always use 'rsync -e ssh' which behaves this way only because it always creates a temporary file on the side and then moves the new file into place instead of overwriting existing files. > Is this also potentially a security hole? A malicious user with the > ability to write to a file might be able to upload a trojaned binary > here or some such mischief. I can tell you are excited but there is no security hole here. I am also sure many people count on setting the permission on a file in a specific configuration and then updating the file with scp without it changing the owner, group, mode of the file from the previous value. If that were to change then many people's scripts and programs would be broken without good reason. Bob -------------- 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/20030107/d5177880/attachment.bin From bugzilla-daemon at mindrot.org Tue Jan 7 21:20:27 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 21:20:27 +1100 (EST) Subject: [Bug 371] OpenSSH fails to build on Alpha True64 in cipher.c Message-ID: <20030107102027.5E09B645AB@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=371 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From djm at mindrot.org 2003-01-07 21:20 ------- 4 months, no followup == no bug ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djm at mindrot.org Tue Jan 7 21:12:04 2003 From: djm at mindrot.org (Damien Miller) Date: Tue, 07 Jan 2003 21:12:04 +1100 Subject: Is sftp-server's stdout redirected to client ? In-Reply-To: References: Message-ID: <3E1AA7F4.6050000@mindrot.org> Avraham Fraenkel - Commatch wrote: > Hello, > Another suggestion - redirect the command output to stderr, this will go > to the sftp-client stderr and (in openssh client) will showed on the > screen. > (The syntax depend on the shell on the server). > In the sftp protocol there is no way to send data to the client in any > other way. That wouldn't be standard sftp (draft-secsh-filexfer) anymore then. You really need to use one of the protocol extension mechanisms to define a new request and corresponding answers. -d From bugzilla-daemon at mindrot.org Tue Jan 7 21:17:17 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 21:17:17 +1100 (EST) Subject: [Bug 360] PrivilegeSeperation does not work with LDAP authentication through PAM Message-ID: <20030107101717.6BA44645C7@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=360 ------- Additional Comments From djm at mindrot.org 2003-01-07 21:17 ------- Please attach a trace from the server "sshd -d -d -d" ------- 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 Jan 7 21:35:53 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 21:35:53 +1100 (EST) Subject: [Bug 399] Environment size over ~3K char prevents ssh logins Message-ID: <20030107103553.A13106459D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=399 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From djm at mindrot.org 2003-01-07 21:35 ------- Another one... 3 months, no followup == no bug ------- 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 Jan 7 21:26:41 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 21:26:41 +1100 (EST) Subject: [Bug 377] Reduce compiler warnings. Use unsigned args to the ctype.h is*() macros. Message-ID: <20030107102641.172A26466F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=377 ------- Additional Comments From djm at mindrot.org 2003-01-07 21:26 ------- FYI: please attach patches rather than pasting them in comment fields (which corrupt them) Markus has fixed some of the signed subscripts in a int/u_int cleanup ------- 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 Jan 7 21:34:07 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 21:34:07 +1100 (EST) Subject: [Bug 391] ssh -n returning 255 status code Message-ID: <20030107103407.800FF64672@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=391 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From djm at mindrot.org 2003-01-07 21:34 ------- 4 months, no followup == no bug ------- 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 Jan 7 21:35:00 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 21:35:00 +1100 (EST) Subject: [Bug 396] sshd orphans processes when no pty allocated Message-ID: <20030107103500.8A82B64522@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=396 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Tue Jan 7 22:01:47 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 07 Jan 2003 22:01:47 +1100 Subject: Test for locked account in auth.c (bug #442). Message-ID: <3E1AB39B.463D1531@zip.com.au> Hi Damien, I noticed you merged a couple of ifdefs in the fix for bug #442. The cvs comment says "Fix Bug #442 for PAM case". The code is now roughly: #if !defined(USE_PAM) && defined(HAVE_SHADOW_H) && \ !defined(DISABLE_SHADOW) && defined(HAS_SHADOW_EXPIRE) spw = getspnam(pw->pw_name); passwd = spw->sp_pwdp; #else passwd = pw->pw_passwd; #endif [test for locked passwd entry] If the platform is using PAM, /etc/passwd is checked regardless of whether or not it actually has /etc/shadow. If the platform has /etc/shadow but doesn't have shadow expiry then the /etc/passwd entry will be checked rather than the /etc/shadow one. Is this correct or have I overlooked something? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Tue Jan 7 22:43:31 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 07 Jan 2003 22:43:31 +1100 Subject: Test for locked account in auth.c (bug #442). References: <3E1AB39B.463D1531@zip.com.au> <3E1AB7BE.3030104@mindrot.org> Message-ID: <3E1ABD63.CDCEC09F@zip.com.au> Damien Miller wrote: [snip] > You are right, my fix introduced a new bug (though one could argue that > it is PAM's responsibility to do this...). Yeah, in fact some people might not want sshd to do this check at all when using PAM. > How does the following look: [snip] Ah I get it now, spw wasn't populated if USE_PAM is defined. Proposed change looks OK to me. -- 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 Tue Jan 7 23:31:17 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 23:31:17 +1100 (EST) Subject: [Bug 238] sshd.pid file written AFTER key generation causes race condition Message-ID: <20030107123117.4A986646B3@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=238 ------- Additional Comments From libove at felines.org 2003-01-07 23:31 ------- There always exists the possibility that something will cause a daemon to fail to complete its startup, or to fail after it has started successfully. This seems to boil down to the question: is it more important to ensure that every service starts successfully, or is it more important to get the system up and running so that other services can be offered? I am uncertain how I feel about this question regarding SSH. SSH is a critical system service from an administrative point of view, and for systems which have interactive users other than administrators. For systems which provide application services but do not have users logging in directly, SSH is not critical. Generally, I think I have seen a preference to daemons starting up as asynchronously as possible during system boot. Also, if key generation fails due to lack of entropy, it indicates either a misconfiguration or a rare problem on that particular server. The current state (write .pid file after key generation) creates a problem for many more systems. So, I still prefer to have the .pid file written before key generation rather than after. Thanks for considering the request. Which way will you go with it? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jeff.layton at bellhowell.com Wed Jan 8 00:01:43 2003 From: jeff.layton at bellhowell.com (Jeff Layton) Date: 07 Jan 2003 08:01:43 -0500 Subject: ownership permissions on files replaced via scp -- bug or fea ture? In-Reply-To: <20030107100406.GA1241@misery.proulx.com> References: <20030107100406.GA1241@misery.proulx.com> Message-ID: <1041944503.920.9.camel@tleilax> Got it -- that does make sense. Thanks for help from all on the list! -- Jeff Layton From mks at noida.hcltech.com Tue Jan 7 23:44:40 2003 From: mks at noida.hcltech.com (Manish Kumar Srivastava, Noida) Date: Tue, 7 Jan 2003 18:14:40 +0530 Subject: ssh 3.1p1 problems on SX-6... Message-ID: In continuation to my previous mail, I am attaching the debug outputs of trying to connect an SX machine using ssh. We experienced "Bad packet length" problem in this case with openssh-3.1p1 and openssl-0.9.6b. packet.c was recompiled with PACKET_DEBUG defined and during execution debug level was 3. Regards Manish > -----Original Message----- > From: Markus Friedl [mailto:markus at openbsd.org] > Sent: Monday, January 06, 2003 9:26 PM > To: Manish Kumar Srivastava, Noida > Cc: openssh-unix-dev at mindrot.org; Ajit Yashwant Vaishampayan, Noida > Subject: Re: ssh 3.1p1 problems on SX-6... > > > On Mon, Jan 06, 2003 at 07:33:33PM +0530, Manish Kumar > Srivastava, Noida wrote: > > Hello, > > > > We are porting openssh-3.1p1 onto SX-6 running on SuperUX. > > We landed into problem when we started running sshd with > > the default encryption settings. As you would have already > > seen on this mailing list. > > > > Basically we are facing two problems (both client and servers > > run on SX):- > > > > 1) If the we use the default encryption algorithm aes128-cbc > > then we get a Bad Packet length problem on server side. > > when does this happen exactly? please turn on all > debugging and include the error messages. you could > also recompile packet.c with debugging enabled. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sshd_output.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030107/e7b1d305/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ssh_output.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030107/e7b1d305/attachment-0001.txt From djm at mindrot.org Tue Jan 7 22:19:26 2003 From: djm at mindrot.org (Damien Miller) Date: Tue, 07 Jan 2003 22:19:26 +1100 Subject: Test for locked account in auth.c (bug #442). In-Reply-To: <3E1AB39B.463D1531@zip.com.au> References: <3E1AB39B.463D1531@zip.com.au> Message-ID: <3E1AB7BE.3030104@mindrot.org> Darren Tucker wrote: > Hi Damien, > I noticed you merged a couple of ifdefs in the fix for bug #442. The > cvs comment says "Fix Bug #442 for PAM case". The code is now roughly: > > #if !defined(USE_PAM) && defined(HAVE_SHADOW_H) && \ > !defined(DISABLE_SHADOW) && defined(HAS_SHADOW_EXPIRE) > spw = getspnam(pw->pw_name); > passwd = spw->sp_pwdp; > #else > passwd = pw->pw_passwd; > #endif > [test for locked passwd entry] > > If the platform is using PAM, /etc/passwd is checked regardless of > whether or not it actually has /etc/shadow. > > If the platform has /etc/shadow but doesn't have shadow expiry then the > /etc/passwd entry will be checked rather than the /etc/shadow one. > > Is this correct or have I overlooked something? You are right, my fix introduced a new bug (though one could argue that it is PAM's responsibility to do this...). How does the following look: int allowed_user(struct passwd * pw) { struct stat st; const char *hostname = NULL, *ipaddr = NULL, *passwd; char *shell; int i; #ifdef WITH_AIXAUTHENTICATE char *loginmsg; #endif /* WITH_AIXAUTHENTICATE */ #if defined(HAVE_SHADOW_H) && !defined(DISABLE_SHADOW) struct spwd *spw; #endif /* Shouldn't be called if pw is NULL, but better safe than sorry... */ if (!pw || !pw->pw_name) return 0; /* Grab the password for locked account checking */ #if defined(HAVE_SHADOW_H) && !defined(DISABLE_SHADOW) spw = getspnam(pw->pw_name); if (!spw) return 0; passwd = spw->sp_pwdp; #else passwd = pw->pw_passwd; #endif /* check for locked account */ if (strcmp(passwd, "*LK*") == 0 || passwd[0] == '!') { log("User %.100s not allowed because account is locked", pw->pw_name); return 0; } #if !defined(USE_PAM) && defined(HAVE_SHADOW_H) && \ !defined(DISABLE_SHADOW) && defined(HAS_SHADOW_EXPIRE) #define DAY (24L * 60 * 60) /* 1 day in seconds */ time_t today = time(NULL) / DAY; debug3("allowed_user: today %d sp_expire %d sp_lstchg %d" " sp_max %d", (int)today, (int)spw->sp_expire, (int)spw->sp_lstchg, (int)spw->sp_max); /* * We assume account and password expiration occurs the * day after the day specified. */ if (spw->sp_expire != -1 && today > spw->sp_expire) { log("Account %.100s has expired", pw->pw_name); return 0; } if (spw->sp_lstchg == 0) { log("User %.100s password has expired (root forced)", pw->pw_name); return 0; } if (spw->sp_max != -1 && today > spw->sp_lstchg + spw->sp_max) { log("User %.100s password has expired (password aged)", pw->pw_name); return 0; } #endif /* * Get the shell from the password data. An empty shell field is * legal, and means /bin/sh. */ shell = (pw->pw_shell[0] == '\0') ? _PATH_BSHELL : pw->pw_shell; /* deny if shell does not exists or is not executable */ if (stat(shell, &st) != 0) { log("User %.100s not allowed because shell %.100s does not exist", pw->pw_name, shell); return 0; } if (S_ISREG(st.st_mode) == 0 || (st.st_mode & (S_IXOTH|S_IXUSR|S_IXGRP)) == 0) { log("User %.100s not allowed because shell %.100s is not executable", pw->pw_name, shell); return 0; } (...) From bugzilla-daemon at mindrot.org Tue Jan 7 23:43:01 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 7 Jan 2003 23:43:01 +1100 (EST) Subject: [Bug 463] PrintLastLog doesn't work in privsep mode Message-ID: <20030107124301.F1D47646BC@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=463 ------- Additional Comments From dtucker at zip.com.au 2003-01-07 23:43 ------- Generate the message earlier in the login process and store for display after session startup? Rather than another variable for this (eg aixloginmsg, maybe __pam_msg), what about using a single Buffer for storing all of the messages to be displayed after login? I've started doing something like this (see http://www.zip.com.au/~dtucker/openssh/openssh-passexpire9.patch) and a (as yet unpublished) update to this makes things neater (eg the patch removes 3 #ifdefs). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Wed Jan 8 01:13:51 2003 From: markus at openbsd.org (Markus Friedl) Date: Tue, 7 Jan 2003 15:13:51 +0100 Subject: ssh 3.1p1 problems on SX-6... In-Reply-To: References: Message-ID: <20030107141351.GA2240@folly> On Tue, Jan 07, 2003 at 06:03:25PM +0530, Manish Kumar Srivastava, Noida wrote: > In the openssl-0.9.7 changelog, it was written that the crypto/rijndael > is moved to crypto/aes but we couldn't find the implementation of > rijndael in openssl-0.9.6[bh]. I think this may not be the appropriate > place to ask a question about openssl, still... openssl 0.9.6* does not contain AES, so we use our own implementation of AES. for 0.9.7 we use openssl's AES. the way we integrate AES into openssl 0.9.6 might be broken. you could probably check ciphers.c From quellyn at lanl.gov Wed Jan 8 01:48:41 2003 From: quellyn at lanl.gov (Quellyn Snead) Date: 07 Jan 2003 07:48:41 -0700 Subject: Confirm OpenSSH3.5p1 for Irix Message-ID: <1041950922.12042.56.camel@gallifrey.lanl.gov> Platform: Irix 6.5.16 OpenSSH 3.5p1 built with MIT Kerb5 v. 1.2.6, OpenSSL 0.9.6g Everything (privsep, ticket forwarding, etc) so far works like a charm. You guys do great work. -- ******************************************************* Quellyn L. Snead CCN-2 Enterprise Software Management Team Los Alamos National Laboratory Schedule B (505) 667-4185 ******************************************************* From bugzilla-daemon at mindrot.org Wed Jan 8 01:50:03 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 8 Jan 2003 01:50:03 +1100 (EST) Subject: [Bug 445] User DCE Credentials do not get forwarded to child session Message-ID: <20030107145003.E8A7B646A3@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=445 ------- Additional Comments From kmy at ornl.gov 2003-01-08 01:50 ------- Created an attachment (id=197) --> (http://bugzilla.mindrot.org/attachment.cgi?id=197&action=view) diff -u session.c session.c.orig Output of "diff -u" attached as requested. -- Ken Matney, Sr. ------- 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 Jan 8 04:35:12 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 8 Jan 2003 04:35:12 +1100 (EST) Subject: [Bug 341] Return Code unpredictable Message-ID: <20030107173512.A6F17645BE@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=341 john.osell at telus.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From john.osell at telus.com 2003-01-08 04:35 ------- It appears to be fixed with the latest versions, I've tested this with OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090605f ------- 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 Jan 8 20:16:11 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 8 Jan 2003 20:16:11 +1100 (EST) Subject: [Bug 281] unable to authorize with local shadow password Message-ID: <20030108091611.CCA2864508@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=281 komanek at natur.cuni.cz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED Version|-current |older versions ------- Additional Comments From komanek at natur.cuni.cz 2003-01-08 20:16 ------- Hm, I have reported this years ago :-) Now I have no chance to reproduce it again, because I have no Irix 6.2 anymore. On Irix 6.5 and more current OpenSSH versions it seems to work fine. ------- 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 Jan 8 20:27:23 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 08 Jan 2003 20:27:23 +1100 Subject: Trivial patch: update README about AIX port status Message-ID: <3E1BEEFB.A060DC8E@zip.com.au> Hi All. As of now, openssh on AIX passes all regressions tests (and, yes, I just checked!), works with privsep, bugzilla has zero open AIX-specific bugs and IBM ship it essentially unmodified as a supported product. I think it's beyond "support underway" :-) -Daz. -- 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: README =================================================================== RCS file: /cvs/openssh/README,v retrieving revision 1.50 diff -u -r1.50 README --- README 24 Dec 2001 03:17:21 -0000 1.50 +++ README 8 Jan 2003 08:28:38 -0000 @@ -15,8 +15,8 @@ This port consists of the re-introduction of autoconf support, PAM support (for Linux and Solaris), EGD[1]/PRNGD[2] support and replacements for OpenBSD library functions that are (regrettably) absent from other -unices. This port has been best tested on Linux, Solaris, HP-UX, NetBSD -and Irix. Support for AIX, SCO, NeXT and other Unices is underway. +unices. This port has been best tested on Linux, Solaris, HP-UX, NetBSD, +Irix and AIX. Support for SCO, NeXT and other Unices is underway. This version actively tracks changes in the OpenBSD CVS repository. The PAM support is now more functional than the popular packages of From dtucker at zip.com.au Wed Jan 8 21:12:57 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 08 Jan 2003 21:12:57 +1100 Subject: Test for locked account in auth.c (bug #442). References: <3E1AB39B.463D1531@zip.com.au> <3E1AB7BE.3030104@mindrot.org> <3E1ABD63.CDCEC09F@zip.com.au> Message-ID: <3E1BF9A9.D7CE8DE9@zip.com.au> Darren Tucker wrote: > Damien Miller wrote: > > How does the following look: > Proposed change looks OK to me. Hmm, HP-UX (in non-trusted configuration) uses exactly "*" to denote a locked password. The attached patch catches this and also adds a paragraph to sshd.8 explaining what's going on. There may be other passwd entries that need to be added for other platforms. -Daz. -- 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: /cvs/openssh/auth.c,v retrieving revision 1.65 diff -u -r1.65 auth.c --- auth.c 7 Jan 2003 12:56:00 -0000 1.65 +++ auth.c 8 Jan 2003 10:01:41 -0000 @@ -97,7 +97,9 @@ #endif /* check for locked account */ - if (strcmp(passwd, "*LK*") == 0 || passwd[0] == '!') { + if (strcmp(passwd, "*LK*") == 0 || /* Solaris */ + strcmp(passwd, "*") == 0 || /* HP-UX */ + passwd[0] == '!') { /* Redhat */ log("User %.100s not allowed because account is locked", pw->pw_name); return 0; Index: sshd.8 =================================================================== RCS file: /cvs/openssh/sshd.8,v retrieving revision 1.150 diff -u -r1.150 sshd.8 --- sshd.8 25 Sep 2002 02:20:54 -0000 1.150 +++ sshd.8 8 Jan 2003 10:01:42 -0000 @@ -112,6 +112,26 @@ authentication, RSA challenge-response authentication, or password based authentication. .Pp +Regardless of the authentication type, the account is checked to +ensure that it is accessible. An account is not accessible if it is +locked, listed in +.Cm DenyUsers +or its group is listed in +.Cm DenyGroups +\&. An account is considered locked if the passwd entry equals +.Ql \&*LK\&* +or +.Ql \&* +, or has a leading +.Ql \&! +character. If there is a requirement to disable password authentication +for the account while allowing still public-key, then the passwd field +should be set to something other than these values (eg +.Ql NP +or +.Ql \&*NP\&* +). +.Pp Rhosts authentication is normally disabled because it is fundamentally insecure, but can be enabled in the server configuration file if desired. From mmokrejs at natur.cuni.cz Wed Jan 8 21:29:36 2003 From: mmokrejs at natur.cuni.cz (=?iso-8859-2?Q?Martin_MOKREJ=A9?=) Date: Wed, 8 Jan 2003 11:29:36 +0100 (CET) Subject: Test for locked account in auth.c (bug #442). In-Reply-To: <3E1BF9A9.D7CE8DE9@zip.com.au> References: <3E1AB39B.463D1531@zip.com.au> <3E1AB7BE.3030104@mindrot.org> <3E1ABD63.CDCEC09F@zip.com.au> <3E1BF9A9.D7CE8DE9@zip.com.au> Message-ID: On Wed, 8 Jan 2003, Darren Tucker wrote: > Darren Tucker wrote: > > Damien Miller wrote: > > > How does the following look: > > Proposed change looks OK to me. > > Hmm, HP-UX (in non-trusted configuration) uses exactly "*" to denote a > locked password. The attached patch catches this and also adds a > paragraph to sshd.8 explaining what's going on. > > There may be other passwd entries that need to be added for other > platforms. For example OSF1 3.2 == DU4.0 == Tru64-5.X use :*: :*gfcXdf83E: :*Nologin: :Nologin*: :Nologin: in the password filed to denoted locked account. This also applies partly to C2 security on those systems (when account is locked manually by admin), it will be detected using this way too. However, the so called protected password database has special fields to mark locked acconts, locked them based number of unsuccessfull logins etc. Those cases of course cannot be detected using any logic interpreting passwd file. -- Martin Mokrejs , PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs MIPS / Institute for Bioinformatics GSF - National Research Center for Environment and Health Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany tel.: +49-89-3187 3683 , fax:?+49-89-3187 3585 From dtucker at zip.com.au Wed Jan 8 22:04:20 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 08 Jan 2003 22:04:20 +1100 Subject: Test for locked account in auth.c (bug #442). References: <3E1AB39B.463D1531@zip.com.au> <3E1AB7BE.3030104@mindrot.org> <3E1ABD63.CDCEC09F@zip.com.au> <3E1BF9A9.D7CE8DE9@zip.com.au> Message-ID: <3E1C05B4.BF16C9B0@zip.com.au> Martin MOKREJ? wrote: [locked accounts] > For example OSF1 3.2 == DU4.0 == Tru64-5.X use > :*:, :*gfcXdf83E:, :*Nologin:, :Nologin*:, :Nologin: > in the password filed to denoted locked account. This also applies partly > to C2 security on those systems (when account is locked manually by > admin), it will be detected using this way too. I'm only interested in whatever "passwd -l" or its equivalent does to the passwd entry, so when an admin locks the account, it really is locked. Any admin that hand-hacks /etc/passwd or equivalent is on their own. System accounts shouldn't ever have a $HOME/.ssh/authorized_keys file so they don't matter. > However, the so called > protected password database has special fields to mark locked accounts, > locked them based number of unsuccessful logins etc. Those cases of > course cannot be detected using any logic interpreting passwd file. Trusted HP-UX has those too (in /tcb) but the only sane way to use them seems to be via PAM. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From mmokrejs at natur.cuni.cz Wed Jan 8 22:12:35 2003 From: mmokrejs at natur.cuni.cz (=?iso-8859-2?Q?Martin_MOKREJ=A9?=) Date: Wed, 8 Jan 2003 12:12:35 +0100 (CET) Subject: Test for locked account in auth.c (bug #442). In-Reply-To: <3E1C05B4.BF16C9B0@zip.com.au> References: <3E1AB39B.463D1531@zip.com.au> <3E1AB7BE.3030104@mindrot.org> <3E1ABD63.CDCEC09F@zip.com.au> <3E1BF9A9.D7CE8DE9@zip.com.au> <3E1C05B4.BF16C9B0@zip.com.au> Message-ID: On Wed, 8 Jan 2003, Darren Tucker wrote: > Martin MOKREJ? wrote: > [locked accounts] > > For example OSF1 3.2 == DU4.0 == Tru64-5.X use > > :*:, :*gfcXdf83E:, :*Nologin:, :Nologin*:, :Nologin: > > in the password filed to denoted locked account. This also applies partly > > to C2 security on those systems (when account is locked manually by > > admin), it will be detected using this way too. > > I'm only interested in whatever "passwd -l" or its equivalent does to > the passwd entry, so when an admin locks the account, it really is > locked. Any admin that hand-hacks /etc/passwd or equivalent is on their > own. I did not mean with "manually" hand-hacked. I meant more "by intention using standand tools". Those examples and not hand-introduced locks. For example, the :*Nologin: and :Nologin*: even fools DEC engineers, so the account manager gui used to show lock icon on an account name only in one of these two cases. I've checked the manpage and it still descscribes onlu "*", but in EXAMPLES section is :Nologin:. It's just incomplete. The above is a summary of real life cases. > System accounts shouldn't ever have a $HOME/.ssh/authorized_keys file so > they don't matter. > > > However, the so called > > protected password database has special fields to mark locked accounts, > > locked them based number of unsuccessful logins etc. Those cases of > > course cannot be detected using any logic interpreting passwd file. > > Trusted HP-UX has those too (in /tcb) but the only sane way to use them > seems to be via PAM. Sure. Or use commandline utils. What about using them too? ;) -- Martin Mokrejs , PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs MIPS / Institute for Bioinformatics GSF - National Research Center for Environment and Health Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany tel.: +49-89-3187 3683 , fax:?+49-89-3187 3585 From bugzilla-daemon at mindrot.org Wed Jan 8 22:18:00 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 8 Jan 2003 22:18:00 +1100 (EST) Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20030108111800.C27F964524@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From dtucker at zip.com.au 2003-01-08 22:17 ------- Created an attachment (id=198) --> (http://bugzilla.mindrot.org/attachment.cgi?id=198&action=view) Add privsep'ed do_pam_chauthtok() Implements do_pam_chauthtok() in the monitor via a passed file descriptor. Resets forwarding flags in slave by trapping a SIGUSR from the child forked to run the shell. This should be safe because to spoof a reset of the forwarding flags you would already need to be logged in anyway and could install your own forwarders. This is the same patch I posted to the openssh-devel list earlier but it belongs to this bug. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From pekkas at netcore.fi Thu Jan 9 00:54:55 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 8 Jan 2003 15:54:55 +0200 (EET) Subject: OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS (fwd) Message-ID: There has not been any mention of this, so.. I'm having hard time trying to figure out whether this is for real or just a joke. (Anyway, I don't use those possibly vulnerable features myself.) Any analysis yet? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ---------- Forwarded message ---------- Date: Sat, 4 Jan 2003 19:37:03 -0800 From: mmhs at hushmail.com To: bugtraq at securityfocus.com Subject: OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS -----BEGIN PGP SIGNED MESSAGE----- *********** OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS *********** MICKEY MOUSE HACKING SQUADRON ADVISORY #2 DISCLAIMER - ---------- The nation's zeroth private security intelligence firm, Mickey Mouse Hacking Squadron uniquely addresses the challenges faced by both public- and private-sector organizations in protecting critical information assets. Our intelligence is timely, delivered 24 x 7, 365 (*) days per year; relevant, fully customizable, and actionable intelligence is only valuable if it makes a difference. (*) in the case of a leap year, we of course provide a 24 x 7, 366 days premier service. TECHNICAL BACKGROUND - -------------------- The following advisory is based on the excellent advisory published by Global InterSec LLC *six months ago*: http://www.globalintersec.com/adv/openssh-2002062801.txt After more than six months of intensive underground research, our ISO 31337 certified security department evidenced that the bug (an integer overflow, resulting in a heap overflow) described in the aforementioned advisory still exists in OpenSSH 3.5p1 and 3.4p1, and remains trivially exploitable. All existing PAM enabled versions of OpenSSH (3.5p1, 3.4p1 and below) are therefore affected. Due to various advisories posted to various fora by unnamed security companies, this bug was supposed to be nonexistent or nonexploitable. Fortunately, Global InterSec LLC shed some light on the whole affair and revealed the malignant nature of the oversight to the world. Their results were applied to the latest OpenSSH versions by privately trained Mickey Mouse Hacking Squadron security specialists and revealed that the exploitation techniques developed by Global InterSec LLC are still applicable to the newest OpenSSH. PROOF OF CONCEPT - ---------------- The following proof of concept is reproducing Global InterSec LLC findings, enhanced with the patented research performed by Mickey Mouse Hacking Squadron against OpenSSH 3.5p1. First of all, the OpenSSH 3.5p1 server has to be built (with PAM support enabled): $ tar xzf openssh-3.5p1.tar.gz $ cd openssh-3.5p1 $ configure --with-pam [...] $ make sshd [...] Before the SSH server is actually executed, the sshd_config file should be modified in order to enable PAM ("PAMAuthenticationViaKbdInt yes"). # sshd In order to reveal the nature of the OpenSSH vulnerability, the next step is to connect to the SSH server: $ ssh werewolf.research.mmhs.com Password: Thanks to the "Password:" prompt, it is clear that PAM is actually enabled (otherwise, the prompt would have been "user at host's password:"). This unique fingerprinting technique was investigated by Mickey Mouse Hacking Squadron, and is already present in the latest version of the Mickey Mouse Hacking Squadron award winning network vulnerability assessment tool. After the previous command was executed, the freshly spawned sshd process has to be examined with a debugger, in order to set the correct breakpoints within the input_userauth_info_response_pam() function of OpenSSH, as demonstrated in the Global InterSec LLC advisory: # gdb sshd 6552 (gdb) disassemble input_userauth_info_response_pam [...] 0x80531bc : push %esi 0x80531bd : call 0x807306c [...] (gdb) break *0x80531bd Breakpoint 1 at 0x80531bd: file auth2-pam.c, line 158. (gdb) continue Continuing. Now that the buggy call to xfree() can be intercepted, the SSH client should trigger the integer overlow and the resulting heap overflow: $ ssh werewolf.research.mmhs.com Password: After that, the xfree() breakpoint is reached, and the next call to free() should therefore be intercepted in order to comply with the technique developed by Global InterSec LLC: Breakpoint 1, 0x080531bd in input_userauth_info_response_pam (type=61, seqnr=7, ctxt=0x809c050) at auth2-pam.c:158 158 xfree(resp); (gdb) disassemble xfree [...] 0x807308e : call 0x804ba14 [...] (gdb) break *0x807308e Breakpoint 2 at 0x807308e: file xmalloc.c, line 55. (gdb) continue Continuing. Breakpoint 2, 0x0807308e in xfree (ptr=0x809dfb8) at xmalloc.c:55 55 free(ptr); (gdb) x /10x 0x809dfb8 0x809dfb8: 0x41414141 0x41414141 0x41414141 0x41414141 0x809dfc8: 0x41414141 0x41414141 0x41414141 0x41414141 0x809dfd8: 0x41414141 0x41414141 >From here on, as demonstrated by Global InterSec LLC, exploitation becomes trivial. For more information on exploiting calls to free() see the excellent Phrack article "Once upon a free()" [2]. WORK AROUND - ----------- As mentioned in http://www.openssh.com/txt/preauth.adv, and as demonstrated by noir in http://www.phrack.org/phrack/60/p60-0x06.txt, "you can prevent privilege escalation if you enable UsePrivilegeSeparation in sshd_config." Love, - -- Mickey Mouse Hacking Squadron -----BEGIN PGP SIGNATURE----- Version: Hush 2.2 (Java) Note: This signature can be verified at https://www.hushtools.com/verify wlkEARECABkFAj4XqFwSHG1taHNAaHVzaG1haWwuY29tAAoJEMZ9fu0iAPxbgYEAoL0W 0oGQQvqwwZAGADonQ2TOUjNmAJ4zuUfANSpju97UjXdD65bkCy6M1A== =YvOU -----END PGP SIGNATURE----- Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Big $$$ to be made with the HushMail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 From linux at lapd.cj.edu.ro Thu Jan 9 01:03:01 2003 From: linux at lapd.cj.edu.ro (Lists (lst)) Date: Wed, 8 Jan 2003 16:03:01 +0200 (EET) Subject: OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS (fwd) In-Reply-To: References: Message-ID: On Wed, 8 Jan 2003, Pekka Savola wrote: > There has not been any mention of this, so.. > > I'm having hard time trying to figure out whether this is for real or just > a joke. (Anyway, I don't use those possibly vulnerable features myself.) > > Any analysis yet? Was a fake ... Cosmin From d_wllms at lanl.gov Thu Jan 9 01:07:47 2003 From: d_wllms at lanl.gov (David M. Williams) Date: Wed, 08 Jan 2003 07:07:47 -0700 Subject: [Fwd: Re: OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS] Message-ID: <3E1C30B3.6070102@lanl.gov> According to the authors of the original advisory, this is _definitely_ a hoax. -------- Original Message -------- Subject: Re: OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS Date: Mon, 06 Jan 2003 20:05:32 +0000 From: Global InterSec Research To: bugtraq at securityfocus.com As some may have gathered, the advisory recently posted by mmhs at hushmail.com was indeed a fake, intended to highlight several unclear statements made in GIS2002062801. The advisory in question is currently being updated with more detailed information and will be re-posted at: http://www.globalintersec.com/adv/openssh-2002062801.txt as soon as it becomes available. Note that the kbd-init flaw described in GIS2002062801 was proven to be exploitable in our lab although not all evidence to demonstrate this was provided in the original advisory. A mistake was made in the original advisory draft, where chunk content data was shown, rather than the entire corrupted malloc chunk. This will be amended in the revision. Also note that to our knowledge there are currently no known, exploitable flaws in OpenSSH 3.5p1, due to its use of PAM as suggested by mmhs at hushmail.com. It is almost certain that the posted bogus advisory was also intended to cause alarm amongst communities using OpenSSH, through miss-information. Global InterSec LLC. -- 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 bugzilla-daemon at mindrot.org Thu Jan 9 01:11:46 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 9 Jan 2003 01:11:46 +1100 (EST) Subject: [Bug 464] New: sshd seems to corrupt the wtmpx Message-ID: <20030108141146.AA8026453B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=464 Summary: sshd seems to corrupt the wtmpx Product: Portable OpenSSH Version: 3.5p1 Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: minor Priority: P4 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: pas50 at cam.ac.uk Starting with an empty wtmpx. I ssh to the machine. I then do last and get pas pts/6 Thu Jan 1 01:00 still logged in Using fwtmp to convert the wtmp file to asci I get pas ts/6 pts/6 1886 7 0000 0000 0 1042034068 0 0 Thu Jan 1 01:00:00 1970 If I log in using ssh or on the console then these do not appear in last. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Thu Jan 9 01:32:09 2003 From: markus at openbsd.org (Markus Friedl) Date: Wed, 8 Jan 2003 15:32:09 +0100 Subject: OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS (fwd) In-Reply-To: References: Message-ID: <20030108143209.GA6258@folly> On Wed, Jan 08, 2003 at 03:54:55PM +0200, Pekka Savola wrote: > There has not been any mention of this, so.. it's fake. there was a followup on bugtraq, too. From pekkas at netcore.fi Thu Jan 9 01:43:15 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 8 Jan 2003 16:43:15 +0200 (EET) Subject: OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS (fwd) In-Reply-To: <20030108143209.GA6258@folly> Message-ID: On Wed, 8 Jan 2003, Markus Friedl wrote: > On Wed, Jan 08, 2003 at 03:54:55PM +0200, Pekka Savola wrote: > > There has not been any mention of this, so.. > > it's fake. there was a followup on bugtraq, too. Oh sorry, my followup seems to have gotten dev-nulled in spam protections. Thanks. -- 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 bugzilla-daemon at mindrot.org Thu Jan 9 02:11:51 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 9 Jan 2003 02:11:51 +1100 (EST) Subject: [Bug 464] sshd seems to corrupt the wtmpx Message-ID: <20030108151151.7DF486453E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=464 ------- Additional Comments From pas50 at cam.ac.uk 2003-01-09 02:11 ------- This is apparently a bug with compiling in 64 bit. David foster saw this. http://www.sunmanagers.org/pipermail/summaries/2002-October/004018.html ------- 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 Jan 9 04:07:35 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 9 Jan 2003 04:07:35 +1100 (EST) Subject: [Bug 464] sshd seems to corrupt the wtmpx Message-ID: <20030108170735.D402E6454A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=464 ------- Additional Comments From pas50 at cam.ac.uk 2003-01-09 04:07 ------- Checked against latest snapshot.Problem is still 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 Jan 9 04:46:58 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 9 Jan 2003 04:46:58 +1100 (EST) Subject: [Bug 464] sshd seems to corrupt the wtmpx Message-ID: <20030108174658.CC32664549@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=464 ------- Additional Comments From mouring at eviladmin.org 2003-01-09 04:46 ------- I really want to know why people are compiling software in 64bit when there is zero logical reason. Nor any physical gain. A lot of 64bit platforms have issues with their [uw]tmp[.] files while crossing from 32bit to 64bit due to alignments and such. However, no one has bother to give me a good reason why the code should be #ifdef/#endif to hell to support a behavior. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From carson at taltos.org Thu Jan 9 07:46:50 2003 From: carson at taltos.org (Carson Gaspar) Date: Wed, 08 Jan 2003 15:46:50 -0500 Subject: [Bug 464] sshd seems to corrupt the wtmpx In-Reply-To: <20030108174658.CC32664549@shitei.mindrot.org> References: <20030108174658.CC32664549@shitei.mindrot.org> Message-ID: <211830000.1042058810@belka.ny.ficc.gs.com> --On Thursday, January 09, 2003 04:46:58 +1100 bugzilla-daemon at mindrot.org wrote: > ------- Additional Comments From mouring at eviladmin.org 2003-01-09 04:46 > ------- I really want to know why people are compiling software in 64bit > when there is zero logical reason. Nor any physical gain. A lot of > 64bit platforms have issues with their [uw]tmp[.] files while crossing > from 32bit to 64bit due to alignments and such. However, no one has > bother to give me a good reason why the code should be #ifdef/#endif to > hell to support a behavior. OpenSSL is significantly faster when compiled 64-bit. In order to use this faster library, ssh must be compiled 64-bit. -- Carson From gert at greenie.muc.de Thu Jan 9 07:50:12 2003 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 8 Jan 2003 21:50:12 +0100 Subject: Trivial patch: update README about AIX port status In-Reply-To: <3E1BEEFB.A060DC8E@zip.com.au>; from dtucker@zip.com.au on Wed, Jan 08, 2003 at 08:27:23PM +1100 References: <3E1BEEFB.A060DC8E@zip.com.au> Message-ID: <20030108215012.G24559@greenie.muc.de> Hi, On Wed, Jan 08, 2003 at 08:27:23PM +1100, Darren Tucker wrote: > Hi All. > As of now, openssh on AIX passes all regressions tests (and, yes, I > just checked!), works with privsep, bugzilla has zero open AIX-specific > bugs and IBM ship it essentially unmodified as a supported product. Could you elaborate on the last part? Is it included in recent AIX releases, or is a separate package? How to get the "official" product? (I'm currently rolling my own packages for our AIX machines, but using official versions would reduce my work load, which is always welcome :) ) 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 mouring at etoh.eviladmin.org Thu Jan 9 03:02:05 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 8 Jan 2003 10:02:05 -0600 (CST) Subject: [Bug 464] sshd seems to corrupt the wtmpx In-Reply-To: <211830000.1042058810@belka.ny.ficc.gs.com> Message-ID: Some how I find this to be very suspect. Do you have any documentation to back this up in general? - Ben On Wed, 8 Jan 2003, Carson Gaspar wrote: > > > --On Thursday, January 09, 2003 04:46:58 +1100 bugzilla-daemon at mindrot.org > wrote: > > > ------- Additional Comments From mouring at eviladmin.org 2003-01-09 04:46 > > ------- I really want to know why people are compiling software in 64bit > > when there is zero logical reason. Nor any physical gain. A lot of > > 64bit platforms have issues with their [uw]tmp[.] files while crossing > > from 32bit to 64bit due to alignments and such. However, no one has > > bother to give me a good reason why the code should be #ifdef/#endif to > > hell to support a behavior. > > OpenSSL is significantly faster when compiled 64-bit. In order to use this > faster library, ssh must be compiled 64-bit. > > -- > Carson > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From appro at fy.chalmers.se Thu Jan 9 08:27:56 2003 From: appro at fy.chalmers.se (Andy Polyakov) Date: Wed, 08 Jan 2003 22:27:56 +0100 Subject: [Bug 464] sshd seems to corrupt the wtmpx References: <20030108174658.CC32664549@shitei.mindrot.org> <211830000.1042058810@belka.ny.ficc.gs.com> Message-ID: <3E1C97DC.48DD3C37@fy.chalmers.se> > > when there is zero logical reason. Nor any physical gain. A lot of > > 64bit platforms have issues with their [uw]tmp[.] files while crossing > > from 32bit to 64bit due to alignments and such. However, no one has > > bother to give me a good reason why the code should be #ifdef/#endif to > > hell to support a behavior. > > OpenSSL is significantly faster when compiled 64-bit. In order to use this > faster library, This is not true. If properly configured 32-bit build provides equivalent (if not better performance) than 64-bit builds on most platforms. Probably the only exclusion is x86_64 and only when it comes to PKI operations. If you feel like challenging my statement, define "significantly," "faster" and specify platform. A. From dtucker at zip.com.au Thu Jan 9 09:22:16 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 09 Jan 2003 09:22:16 +1100 Subject: Trivial patch: update README about AIX port status References: <3E1BEEFB.A060DC8E@zip.com.au> <20030108215012.G24559@greenie.muc.de> Message-ID: <3E1CA498.55CD63B2@zip.com.au> Gert Doering wrote: > > IBM ship it essentially unmodified as a supported product. > > Could you elaborate on the last part? Is it included in recent AIX > releases, or is a separate package? How to get the "official" product? http://oss.software.ibm.com/developerworks/projects/opensshi/ It's for AIX 5.1 and 5.2. No official packages for AIX <5 that I'm aware of. A version based on 2.9.9p2 ships on the 5.1 Bonus Pack CD. (Not sure what version shipped with AIX 5.2 if any as I don't have it). -Daz. -- 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 Thu Jan 9 09:55:55 2003 From: maniac at maniac.nl (Mark Janssen) Date: 08 Jan 2003 23:55:55 +0100 Subject: Trivial patch: update README about AIX port status In-Reply-To: <20030108215012.G24559@greenie.muc.de> References: <3E1BEEFB.A060DC8E@zip.com.au> <20030108215012.G24559@greenie.muc.de> Message-ID: <1042066555.1934.7.camel@shuttle> On Wed, 2003-01-08 at 21:50, Gert Doering wrote: [snip about AIX support status] > Could you elaborate on the last part? Is it included in recent AIX > releases, or is a separate package? How to get the "official" product? > > (I'm currently rolling my own packages for our AIX machines, but using > official versions would reduce my work load, which is always welcome :) If you want I can make my own packages available. I regularty build packages for AIX-4.3.3 (and HPUX 11/11i) Current included patches/features are: - Based on 3.5p1 - TCP Wrappers - PRNGD (0.9.26 + custom built package) - OpenSSL (0.9.6g custom package) - Zlib (1.1.4 custom package) - Darrens patches for AIX authenticate / password expiry - Post-install generated keys + config files if required - Installs as a SRC (startsrc/stopsrc) - Proctitle patch - Privsep on, AllowUserEnv off -- Mark Janssen Saiko Internet Technologies From bugzilla-daemon at mindrot.org Thu Jan 9 10:51:31 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 9 Jan 2003 10:51:31 +1100 (EST) Subject: [Bug 452] sftp does not abort when commands given via -b fail Message-ID: <20030108235131.DF1D964568@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=452 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-09 10:51 ------- Fixed in CVS. Any error in any command will now be considered a fatal error, unless you prefix the command with a '-' sign. E.g. put /tmp/existing -put /tmp/nonexisting put /tmp/existing2 will run to completion ------- 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 Jan 9 11:22:33 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 9 Jan 2003 11:22:33 +1100 (EST) Subject: [Bug 236] No setproctitle() replacement for many unices Message-ID: <20030109002233.65C5764571@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=236 ------- Additional Comments From djm at mindrot.org 2003-01-09 11:22 ------- This seems to work on Linux and I have had reports of it working on other platforms too. Please test this patch and report here or on the list. I'd like to get this in for the next version. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tim at multitalents.net Thu Jan 9 16:20:29 2003 From: tim at multitalents.net (Tim Rice) Date: Wed, 8 Jan 2003 21:20:29 -0800 (PST) Subject: Building without perl In-Reply-To: <20021210202009.GB6600@foo.birdnet.se> References: <20021207131207.GA6325@foo.birdnet.se> <20021208201642.GA27732@foo.birdnet.se> <20021210202009.GB6600@foo.birdnet.se> Message-ID: On Tue, 10 Dec 2002, Peter Stuge wrote: > On Sun, Dec 08, 2002 at 09:16:42PM +0100, Peter Stuge wrote: > > On Sat, Dec 07, 2002 at 09:47:21AM -0600, Ben Lindstrom wrote: > > > Of course I'll reserve judgement until I see it work on every platform > > > without adding 3rd party software. > > > > Ok, here we go. Attached is an awk version of mdoc2man.pl. Please test it > > everywhere you can. Runs fine here, using GNU awk with or without --posix. > > So, is it working or not? And how about that documentation format? It works on SCO OpenServer and UnixWare. I also works on Solaris 8 if you use nawk. > > > //Peter -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bugzilla-daemon at mindrot.org Thu Jan 9 16:19:55 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 9 Jan 2003 16:19:55 +1100 (EST) Subject: [Bug 236] No setproctitle() replacement for many unices Message-ID: <20030109051955.0620364576@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=236 ------- Additional Comments From dtucker at zip.com.au 2003-01-09 16:19 ------- Patch id 93 works on AIX (tested 4.2.1, 4.3.3 & 5.1). It does not work on Solaris (tested 7, 8). sshd still works, but ps still shows the original arguments. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Thu Jan 9 17:30:51 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 09 Jan 2003 17:30:51 +1100 Subject: Trivial patch: update README about AIX port status References: <3E1BEEFB.A060DC8E@zip.com.au> <20030108215012.G24559@greenie.muc.de> <1042066555.1934.7.camel@shuttle> Message-ID: <3E1D171B.2AFA5173@zip.com.au> Mark Janssen wrote: > If you want I can make my own packages available. I regularly build > packages for AIX-4.3.3 (and HPUX 11/11i) > > Current included patches/features are: > - Based on 3.5p1 > - TCP Wrappers > - PRNGD (0.9.26 + custom built package) > - OpenSSL (0.9.6g custom package) > - Zlib (1.1.4 custom package) > - Darrens patches for AIX authenticate / password expiry > - Post-install generated keys + config files if required > - Installs as a SRC (startsrc/stopsrc) > - Proctitle patch > - Privsep on, AllowUserEnv off You're using a password expiry patch? Which one and how's it working out? Are you generating your packages yourself or using the shipped package builder? BTW, I already publish my packages which have the above minus PRNGD and proctitle. -- 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 maf at appgate.com Thu Jan 9 18:13:55 2003 From: maf at appgate.com (maf at appgate.com) Date: Thu, 9 Jan 2003 08:13:55 +0100 (CET) Subject: certificate in openssh Message-ID: <20030109071402.E768C317CE@pelee.firedoor.se> On 6 Jan, venki wrote: > we have been looking for ways to implement digital certificate authentication > in openssh. Pointers to similar kind of ongoing work will be more > appreciated. Thanks. We have implemented it in our product which among other things uses openssh. Unfortunately I can not share any meaningful code since it relies heavily on other parts of our infrastructure. But I should at least be able to answer questions about it. But it is relatively straightforward to implement. x509v3-sign-rsa and x509v3-sign-dss are defined public key algorithm names. The most interesting decision is how to determine if a give certificate gives access to a certain account. The easiest solution is to use something like the authorized_keys file, but other more interesting solutions are possible. /MaF -- Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From bugzilla-daemon at mindrot.org Thu Jan 9 19:29:05 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 9 Jan 2003 19:29:05 +1100 (EST) Subject: [Bug 464] sshd seems to corrupt the wtmpx Message-ID: <20030109082905.85C4764515@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=464 ------- Additional Comments From pas50 at cam.ac.uk 2003-01-09 19:29 ------- It is simple laziness. We have applications that require 64 bit. We therefor have to have to libraries compiled in 64 bit. Rather than build two copies of all the libraries we build everything in 64 bit. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mmokrejs at natur.cuni.cz Thu Jan 9 19:43:25 2003 From: mmokrejs at natur.cuni.cz (=?iso-8859-2?Q?Martin_MOKREJ=A9?=) Date: Thu, 9 Jan 2003 09:43:25 +0100 (CET) Subject: Building openssh-3.5p1 with new DES functions In-Reply-To: <20021213.082445.84364140.levitte@stacken.kth.se> References: <20021210.141346.112850185.levitte@stacken.kth.se> <20021213.082445.84364140.levitte@stacken.kth.se> Message-ID: Hi, I've installed openssl-0.9.7 and now am testing current openssh-cvs. The kerberosIV installation has it's own libdes.a. I'm quite please openssh built successfully, congratulations! Unfortunately, kerberos autentication is not tried at all. As far as I remeber, Ja Iven who wrote some patch, which as he said got into 3.5p1 also removed the ifdef's that --with-privsep no longer disable kerberos. Was this reverted recently? As a feedback, I'd like to send you the warning I got, I think few of them might be really important: OpenSSH has been configured with the following options: User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /usr/local/etc Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/man/manX PID file: /var/run Privilege separation chroot path: /var/empty sshd default user PATH: /usr/bin:/bin:/sbin:/usr/local/bin:/usr/local/sbin:/software/@sys/usr/bin:/software/@sys/usr/sbin:/usr/bin/X11:/usr/afs/bin:/usr/athena/bin:/usr/local/openssl/bin:/usr/opt/svr4/bin:/usr/opt/svr4/sbin Manpage format: man PAM support: no KerberosIV support: yes KerberosV support: no Smartcard support: no AFS support: yes S/KEY support: no TCP Wrappers support: yes MD5 password support: no IP address in $DISPLAY hack: no Use IPv4 by default hack: no Translate v4 in v6 hack: no BSD Auth support: no Random number source: OpenSSL internal ONLY Host: alphaev67-dec-osf5.1 Compiler: cc Compiler flags: -O2 -arch ev6 Preprocessor flags: -I/usr/local/openssl/include -Iyes -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2 -I/usr/athena/include -I/usr/afsws/include Linker flags: -L/usr/local/openssl/lib -Lyes -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -L/usr/athena/lib -L/usr/afsws/lib Libraries: -lwrap -lkafs -lresolv -ldes -lkrb -lz -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -lsecurity -ldb -lm -laud -lcrypto -ldes bash-2.05b# ls -la /usr/athena/lib total 1593 drwxr-xr-x 2 root system 8192 Dec 8 04:03 . drwxr-xr-x 9 root system 8192 Dec 8 04:03 .. -rw-r--r-- 1 root system 17312 Dec 8 04:03 libacl.a -rwxr-xr-x 1 root system 781 Dec 8 04:03 libacl.la -rw-r--r-- 1 root system 9924 Dec 8 04:03 libcom_err.a -rwxr-xr-x 1 root system 741 Dec 8 04:03 libcom_err.la -rw-r--r-- 1 root system 140506 Dec 8 04:03 libdes.a -rwxr-xr-x 1 root system 729 Dec 8 04:03 libdes.la -rw-r--r-- 1 root system 67610 Dec 8 04:03 libeditline.a -rwxr-xr-x 1 root system 744 Dec 8 04:03 libeditline.la -rw-r--r-- 1 root system 48882 Dec 8 04:03 libkadm.a -rwxr-xr-x 1 root system 815 Dec 8 04:03 libkadm.la -rw-r--r-- 1 root system 47690 Dec 8 04:03 libkafs.a -rwxr-xr-x 1 root system 817 Dec 8 04:03 libkafs.la -rw-r--r-- 1 root system 55244 Dec 8 04:03 libkdb.a -rwxr-xr-x 1 root system 782 Dec 8 04:03 libkdb.la -rw-r--r-- 1 root system 368800 Dec 8 04:03 libkrb.a -rwxr-xr-x 1 root system 755 Dec 8 04:03 libkrb.la -rw-r--r-- 1 root system 209950 Dec 8 04:03 libotp.a -rwxr-xr-x 1 root system 788 Dec 8 04:03 libotp.la -rw-r--r-- 1 root system 276378 Dec 8 04:03 libroken.a -rwxr-xr-x 1 root system 741 Dec 8 04:03 libroken.la -rw-r--r-- 1 root system 260128 Dec 8 04:03 libsia_krb4.so -rw-r--r-- 1 root system 31926 Dec 8 04:03 libsl.a -rwxr-xr-x 1 root system 767 Dec 8 04:03 libsl.la -rw-r--r-- 1 root system 38928 Dec 8 04:03 libss.a -rwxr-xr-x 1 root system 797 Dec 8 04:03 libss.la bash-2.05b# make [...] cc -O2 -arch ev6 -I. -I.. -I. -I./.. -I/usr/local/openssl/include -Iyes -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2 -I/usr/athena/include -I/usr/afsws/include -DHAVE_CONFIG_H -c bsd-cray.c cc: Warning: bsd-cray.c, line 797: Source file does not contain any declarations. (emptyfile) #endif ------^ [...] cc -O2 -arch ev6 -I. -I. -I/usr/local/openssl/include -Iyes -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2 -I/usr/athena/include -I/usr/afsws/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c packet.c cc: Warning: packet.c, line 142: In this statement, the referenced type of the pointer value """" is "char", which is not compatible with "const unsigned char" because they differ by signed/unsigned attribute. (ptrmismatch1) cipher_init(&send_context, none, "", 0, NULL, 0, CIPHER_ENCRYPT); -----------------------------------------^ cc: Warning: packet.c, line 143: In this statement, the referenced type of the pointer value """" is "char", which is not compatible with "const unsigned char" because they differ by signed/unsigned attribute. (ptrmismatch1) cipher_init(&receive_context, none, "", 0, NULL, 0, CIPHER_DECRYPT); --------------------------------------------^ [...] cc -O2 -arch ev6 -I. -I. -I/usr/local/openssl/include -Iyes -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2 -I/usr/athena/include -I/usr/afsws/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c monitor_wrap.c cc: Info: /usr/athena/include/krb-protos.h, line 175: The type "struct des_ks_struct" has been declared within and is limited to a function prototype scope. It will not be compatible with an identical type declared in another scope. This might not be what you intended. (protoscope) krb_check_auth __P(( ---------------^ cc: Info: /usr/athena/include/krb-protos.h, line 456: The type "struct des_ks_struct" has been declared within and is limited to a function prototype scope. It will not be compatible with an identical type declared in another scope. This might not be what you intended. (protoscope) krb_mk_priv __P(( ------------^ cc: Info: /usr/athena/include/krb-protos.h, line 540: The type "struct des_ks_struct" has been declared within and is limited to a function prototype scope. It will not be compatible with an identical type declared in another scope. This might not be what you intended. (protoscope) krb_rd_priv __P(( ------------^ cc: Info: /usr/athena/include/krb-protos.h, line 576: The type "struct des_ks_struct" has been declared within and is limited to a function prototype scope. It will not be compatible with an identical type declared in another scope. This might not be what you intended. (protoscope) krb_recvauth __P(( -------------^ cc: Info: /usr/athena/include/krb-protos.h, line 590: The type "struct des_ks_struct" has been declared within and is limited to a function prototype scope. It will not be compatible with an identical type declared in another scope. This might not be what you intended. (protoscope) krb_sendauth __P(( -------------^ [...] cc -O2 -arch ev6 -I. -I. -I/usr/local/openssl/include -Iyes -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2 -I/usr/athena/include -I/usr/afsws/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c sshconnect1.c cc: Warning: /usr/local/openssl/include/openssl/des.h, line 104: The redefinition of the macro "DES_KEY_SZ" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. (macroredef) #define DES_KEY_SZ (sizeof(DES_cblock)) --------------------------------^ cc: Warning: /usr/local/openssl/include/openssl/des.h, line 105: The redefinition of the macro "DES_SCHEDULE_SZ" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. (macroredef) #define DES_SCHEDULE_SZ (sizeof(DES_key_schedule)) --------------------------------^ [...] cc -O2 -arch ev6 -I. -I. -I/usr/local/openssl/include -Iyes -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2 -I/usr/athena/include -I/usr/afsws/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c sshd.c cc: Info: /usr/athena/include/krb-protos.h, line 175: The type "struct des_ks_struct" has been declared within and is limited to a function prototype scope. It will not be compatible with an identical type declared in another scope. This might not be what you intended. (protoscope) krb_check_auth __P(( ---------------^ cc: Info: /usr/athena/include/krb-protos.h, line 456: The type "struct des_ks_struct" has been declared within and is limited to a function prototype scope. It will not be compatible with an identical type declared in another scope. This might not be what you intended. (protoscope) krb_mk_priv __P(( ------------^ cc: Info: /usr/athena/include/krb-protos.h, line 540: The type "struct des_ks_struct" has been declared within and is limited to a function prototype scope. It will not be compatible with an identical type declared in another scope. This might not be what you intended. (protoscope) krb_rd_priv __P(( ------------^ cc: Info: /usr/athena/include/krb-protos.h, line 576: The type "struct des_ks_struct" has been declared within and is limited to a function prototype scope. It will not be compatible with an identical type declared in another scope. This might not be what you intended. (protoscope) krb_recvauth __P(( -------------^ cc: Info: /usr/athena/include/krb-protos.h, line 590: The type "struct des_ks_struct" has been declared within and is limited to a function prototype scope. It will not be compatible with an identical type declared in another scope. This might not be what you intended. (protoscope) krb_sendauth __P(( -------------^ [...] cc -O2 -arch ev6 -I. -I. -I/usr/local/openssl/include -Iyes -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2 -I/usr/athena/include -I/usr/afsws/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c auth-rhosts.c cc: Warning: auth-rhosts.c, line 116: In this statement, the referenced type of the pointer value "hostname" is const, but the referenced type of the target of this assignment is not. (notconstqual) if (!innetgr(host + 1, hostname, NULL, NULL) && -----------------------------------------------^ cc: Warning: auth-rhosts.c, line 117: In this statement, the referenced type of the pointer value "ipaddr" is const, but the referenced type of the target of this assignment is not. (notconstqual) !innetgr(host + 1, ipaddr, NULL, NULL)) -----------------------------------------------^ cc: Warning: auth-rhosts.c, line 124: In this statement, the referenced type of the pointer value "client_user" is const, but the referenced type of the target of this assignment is not. (notconstqual) if (!innetgr(user + 1, NULL, client_user, NULL)) -----------------------------------------------------^ [...] cc -O2 -arch ev6 -I. -I. -I/usr/local/openssl/include -Iyes -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2 -I/usr/athena/include -I/usr/afsws/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c auth-sia.c cc: Warning: auth-sia.c, line 63: In this statement, the referenced type of the pointer value "host" is const, but the referenced type of the target of this assignment is not. (notconstqual) if (sia_ses_init(&ent, saved_argc, saved_argv, host, user, NULL, 0, -------------------------------------------------------^ cc: Warning: auth-sia.c, line 88: In this statement, the referenced type of the pointer value "host" is const, but the referenced type of the target of this assignment is not. (notconstqual) if (sia_ses_init(&ent, saved_argc, saved_argv, host, user, tty, 0, -------------------------------------------------------^ [...] cc -O2 -arch ev6 -I. -I. -I/usr/local/openssl/include -Iyes -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2 -I/usr/athena/include -I/usr/afsws/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c servconf.c cc: Warning: /usr/local/openssl/include/openssl/des.h, line 104: The redefinition of the macro "DES_KEY_SZ" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. (macroredef) #define DES_KEY_SZ (sizeof(DES_cblock)) --------------------------------^ cc: Warning: /usr/local/openssl/include/openssl/des.h, line 105: The redefinition of the macro "DES_SCHEDULE_SZ" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. (macroredef) #define DES_SCHEDULE_SZ (sizeof(DES_key_schedule)) --------------------------------^ cc -O2 -arch ev6 -I. -I. -I/usr/local/openssl/include -Iyes -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2 -I/usr/athena/include -I/usr/afsws/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c serverloop.c cc: Warning: /usr/local/openssl/include/openssl/des.h, line 104: The redefinition of the macro "DES_KEY_SZ" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. (macroredef) #define DES_KEY_SZ (sizeof(DES_cblock)) --------------------------------^ cc: Warning: /usr/local/openssl/include/openssl/des.h, line 105: The redefinition of the macro "DES_SCHEDULE_SZ" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. (macroredef) #define DES_SCHEDULE_SZ (sizeof(DES_key_schedule)) --------------------------------^ [...] cc -O2 -arch ev6 -I. -I. -I/usr/local/openssl/include -Iyes -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2 -I/usr/athena/include -I/usr/afsws/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c monitor.c cc: Warning: /usr/local/openssl/include/openssl/des.h, line 104: The redefinition of the macro "DES_KEY_SZ" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. (macroredef) #define DES_KEY_SZ (sizeof(DES_cblock)) --------------------------------^ cc: Warning: /usr/local/openssl/include/openssl/des.h, line 105: The redefinition of the macro "DES_SCHEDULE_SZ" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. (macroredef) #define DES_SCHEDULE_SZ (sizeof(DES_key_schedule)) --------------------------------^ cc: Warning: monitor.c, line 1377: Non-void function "mm_answer_term" does not contain a return statement. (missingreturn) int ^ [...] cc -o ssh-keygen ssh-keygen.o -L. -Lopenbsd-compat/ -L/usr/local/openssl/lib -Lyes -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -L/usr/athena/lib -L/usr/afsws/lib -lssh -lopenbsd-compat -lkafs -lresolv -ldes -lkrb -lz -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -lsecurity -ldb -lm -laud -lcrypto -ldes cc -O2 -arch ev6 -I. -I. -I/usr/local/openssl/include -Iyes -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2 -I/usr/athena/include -I/usr/afsws/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c ssh-keyscan.c cc: Warning: ssh-keyscan.c, line 324: Non-void function "hostjump" does not contain a return statement. (missingreturn) static int ^ [...] --------------------------------------------------------------- I tried to configure openssh without privsep, but then configure failed to detect kerberos!: [...] checking whether getopt has optreset support... no checking if libc defines sys_errlist... yes checking if libc defines sys_nerr... yes configure: WARNING: AFS requires Kerberos IV support, build may fail checking for "/dev/ptmx"... yes [...] OpenSSH has been configured with the following options: User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /usr/local/etc Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/man/manX PID file: /var/run Privilege separation chroot path: /var/empty sshd default user PATH: /usr/bin:/bin:/sbin:/usr/local/bin:/usr/local/sbin:/software/@sys/usr/bin:/software/@sys/usr/sbin:/usr/bin/X11:/usr/afs/bin:/usr/athena/bin:/usr/local/openssl/bin:/usr/opt/svr4/bin:/usr/opt/svr4/sbin Manpage format: man PAM support: no KerberosIV support: no KerberosV support: no Smartcard support: no AFS support: yes S/KEY support: no TCP Wrappers support: yes MD5 password support: no IP address in $DISPLAY hack: no Use IPv4 by default hack: no Translate v4 in v6 hack: no BSD Auth support: no Random number source: OpenSSL internal ONLY Host: alphaev67-dec-osf5.1 Compiler: cc Compiler flags: -O2 -arch ev6 Preprocessor flags: -I/usr/local/openssl/include -Iyes -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2 -I/usr/afsws/include Linker flags: -L/usr/local/openssl/lib -Lyes -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -L/usr/afsws/lib Libraries: -lwrap -lkafs -lz -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -lsecurity -ldb -lm -laud -lcrypto config.log says: configure:15304: checking if libc defines sys_errlist configure:15327: cc -o conftest -O2 -arch ev6 -I/usr/local/openssl/include -Iyes -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2 -L/usr/local/openssl/lib -Lyes -L/usr/local/lib -L/software/@sy s/usr/lib -L/usr/local/openssl/lib -L/usr/lib conftest.c -lz -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/ usr/lib -lsecurity -ldb -lm -laud -lcrypto >&5 configure:15330: $? = 0 configure:15333: test -s conftest configure:15336: $? = 0 configure:15349: result: yes configure:15359: checking if libc defines sys_nerr configure:15382: cc -o conftest -O2 -arch ev6 -I/usr/local/openssl/include -Iyes -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2 -L/usr/local/openssl/lib -Lyes -L/usr/local/lib -L/software/@sy s/usr/lib -L/usr/local/openssl/lib -L/usr/lib conftest.c -lz -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/ usr/lib -lsecurity -ldb -lm -laud -lcrypto >&5 configure:15385: $? = 0 configure:15388: test -s conftest configure:15391: $? = 0 configure:15404: result: yes configure:16398: WARNING: AFS requires Kerberos IV support, build may fail configure:16518: checking for "/dev/ptmx" configure:16533: result: yes configure:16548: checking for "/dev/ptc" configure:16563: result: no configure:16602: checking for nroff configure:16620: found /usr/bin/nroff configure:16632: result: /usr/bin/nroff I've decided to compile anyway and specify kerberos headers and libs manually on each command-line after the build fails because of missing kerberos headers or libs. Unfortunately, in thisrd cases it did not help much: cc -O2 -arch ev6 -I. -I. -I/usr/local/openssl/include -Iyes -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include -I/usr/athena/include -I/usr/afsws/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c sshconnect1.c cc: Error: radix.h, line 27: Error parsing parameter list. Found "*" when expecting one of: ",", ")". (notexpecting) int creds_to_radix(CREDENTIALS *, u_char *, size_t); ------------------------------------^ cc: Error: radix.h, line 28: Ill-formed parameter type list. (parmtyplist) int radix_to_creds(const char *, CREDENTIALS *); --------------------------------------^ cc: Error: sshconnect1.c, line 786: In this declaration, "CREDENTIALS" must specify a type. (badparsedecl) CREDENTIALS creds; --------^ cc: Error: sshconnect1.c, line 736: In this statement, "CREDENTIALS" is not declared. (undeclared) CREDENTIALS *creds; --------^ cc: Error: sshconnect1.c, line 736: In this statement, "creds" is not declared. (undeclared) CREDENTIALS *creds; ---------------------^ cc: Error: sshconnect1.c, line 738: In the declaration of "pname", "ANAME_SZ" is not declared. (undeclared) char buffer[4096], pname[ANAME_SZ], pinst[INST_SZ], prealm[REALM_SZ]; ---------------------------------^ cc: Error: sshconnect1.c, line 738: In the declaration of "pinst", "INST_SZ" is not declared. (undeclared) char buffer[4096], pname[ANAME_SZ], pinst[INST_SZ], prealm[REALM_SZ]; --------------------------------------------------^ cc: Error: sshconnect1.c, line 738: In the declaration of "prealm", "REALM_SZ" is not declared. (undeclared) char buffer[4096], pname[ANAME_SZ], pinst[INST_SZ], prealm[REALM_SZ]; -------------------------------------------------------------------^ cc: Warning: sshconnect1.c, line 742: In this statement, "tkt_string(...)" of type "int", is being converted to "pointer to const char". (cvtdiftypes) if (stat(tkt_string(), &st) < 0) -----------------^ cc: Error: sshconnect1.c, line 747: In this statement, "TKT_FILE" is not declared. (undeclared) problem = krb_get_tf_fullname(TKT_FILE, pname, pinst, prealm); --------------------------------------^ cc: Error: sshconnect1.c, line 756: In this statement, "RD_AP_EXP" is not declared. (undeclared) problem = RD_AP_EXP; --------------------------^ cc: Error: sshconnect1.c, line 779: In this statement, "krb_err_txt" is not declared. (undeclared) debug("Kerberos v4 TGT passing failed: %s", krb_err_txt[problem]); ----------------------------------------------------^ cc: Error: sshconnect1.c, line 804: In this statement, "creds" is not declared. (undeclared) memcpy(&creds.ticket_st.length, p, sizeof(u_int)); ------------------------^ cc: Error: sshconnect1.c, line 805: In this statement, "MAX_KTXT_LEN" is not declared. (undeclared) if (creds.ticket_st.length > MAX_KTXT_LEN) ---------------------------------------------^ cc: Error: sshconnect1.c, line 824: In this statement, "REALM_SZ" is not declared. (undeclared) strlcpy(creds.realm, server_cell, REALM_SZ); --------------------------------------------------^ Tested on Tru64 Unix 5.1A, kerberos-1.2.1 configured with --without-openssl option. -- Martin Mokrejs , PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs MIPS / Institute for Bioinformatics GSF - National Research Center for Environment and Health Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany tel.: +49-89-3187 3683 , fax:?+49-89-3187 3585 From markus at openbsd.org Thu Jan 9 20:53:44 2003 From: markus at openbsd.org (Markus Friedl) Date: Thu, 9 Jan 2003 10:53:44 +0100 Subject: certificate in openssh In-Reply-To: <200301061217.33872.avenkatesh79@rediffmail.com> References: <200301061217.33872.avenkatesh79@rediffmail.com> Message-ID: <20030109095344.GB15981@folly> On Mon, Jan 06, 2003 at 12:17:33PM +0530, venki wrote: > we have been looking for ways to implement digital certificate authentication > in openssh. Pointers to similar kind of ongoing work will be more > appreciated. Thanks. check http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=101247582424495&w=2 From bugzilla-daemon at mindrot.org Thu Jan 9 22:03:01 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 9 Jan 2003 22:03:01 +1100 (EST) Subject: [Bug 236] No setproctitle() replacement for many unices Message-ID: <20030109110301.B6B396451A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=236 ------- Additional Comments From maniac-openssh at maniac.nl 2003-01-09 22:03 ------- I'm using this patch for AIX 4.3.3 and it works perfectly. I'm also using it on HPUX 10 and 11 (will try 11i soon) but I need to make some modifications in config.h after running configure. (add a define for HAVE_SYS_PSTAT_H) and make sure HAVE_PSTAT is set in some way (my way is not really clean) otherwise support will still be disabled. ------- 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 Jan 9 22:05:21 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 9 Jan 2003 22:05:21 +1100 (EST) Subject: [Bug 341] Return Code unpredictable Message-ID: <20030109110521.8904764520@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=341 ------- Additional Comments From norbert.weuster at mgi.de 2003-01-09 22:05 ------- IBM provides the "aix toolbox for linux apps" only with the versions openssh-3.4p1-5.aix4.3.ppc.rpm openssh-server-3.4p1-5.aix4.3.ppc.rpm openssh-clients-3.4p1-5.aix4.3.ppc.rpm openssl-0.9.6e-2.aix4.3.ppc.rpm so I tested these versions and I cannot reproduce the bug again. best regards Norbert Weuster ------- 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 Jan 9 22:08:53 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 9 Jan 2003 22:08:53 +1100 (EST) Subject: [Bug 381] unable to access expired accounts using PAM with openssh-3.4P1 Message-ID: <20030109110853.6CD8164528@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=381 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From dtucker at zip.com.au 2003-01-09 22:08 ------- *** This bug has been marked as a duplicate of 423 *** ------- 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 Jan 9 22:08:55 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 9 Jan 2003 22:08:55 +1100 (EST) Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20030109110855.3502C6452B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |don.sudom at dahlt.com ------- Additional Comments From dtucker at zip.com.au 2003-01-09 22:08 ------- *** Bug 381 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 bugzilla-daemon at mindrot.org Thu Jan 9 23:17:20 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 9 Jan 2003 23:17:20 +1100 (EST) Subject: [Bug 14] Can't change expired /etc/shadow password without PAM Message-ID: <20030109121720.DEDDE6452B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=14 ------- Additional Comments From dtucker at zip.com.au 2003-01-09 23:17 ------- Created an attachment (id=199) --> (http://bugzilla.mindrot.org/attachment.cgi?id=199&action=view) Implement password change via /bin/passwd in session. openssh-passexpire10.patch: * Implementes shadow and AIX password expiry. * Adds general expire_message and login_message Buffers to replace platform-specific variables. * Implements PasswordExpireWarningDays and ForcedPasswdChange options. * Uses SIGUSR1 to reset password change flag. * Net reduction in #ifdefs. Tested on AIX, Solaris and Redhat. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at mindrot.org Thu Jan 9 23:37:45 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 9 Jan 2003 23:37:45 +1100 (EST) Subject: [Bug 14] Can't change expired /etc/shadow password without PAM Message-ID: <20030109123745.3F46564533@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=14 ------- Additional Comments From djm at mindrot.org 2003-01-09 23:37 ------- I have had a quick look over the patch. It looks good, though I am unsure about the extra options (can't we always get these from shadow?). It is very tempting to ignore PAM password changing (for the non-kbdint case) and just use this method - on a PAM enabled system, passwd should be PAM enabled too. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at mindrot.org Fri Jan 10 00:30:54 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 10 Jan 2003 00:30:54 +1100 (EST) Subject: [Bug 14] Can't change expired /etc/shadow password without PAM Message-ID: <20030109133054.148DF64533@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=14 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- OS/Version|other |All ------- Additional Comments From dtucker at zip.com.au 2003-01-10 00:30 ------- I had seen those options in a man page for ssh-1.2.something and assumed that they would be needed. For PasswordExpireWarningDays, you're right, I missed the sp_warn field in spwd. AIX doesn't need it either, its warning messages are generated by passwdexpired(). Not sure about ForcedPasswdChange, should the admin have this option? (if you don't want password expiry then don't turn it on) The last time someone suggested PAM-chauthtok-via-passwd the objection was that passwd used the "passwd" PAM service and sshd used the "sshd" service and they might do different things (although normally they don't). Is this a PAM-purist thing? (Changed platform to "All", this bug covers a lot of them). ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at mindrot.org Fri Jan 10 01:06:17 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 10 Jan 2003 01:06:17 +1100 (EST) Subject: [Bug 14] Can't change expired /etc/shadow password without PAM Message-ID: <20030109140617.6B74964533@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=14 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #199 is|0 |1 obsolete| | ------- Additional Comments From dtucker at zip.com.au 2003-01-10 01:06 ------- Created an attachment (id=200) --> (http://bugzilla.mindrot.org/attachment.cgi?id=200&action=view) passexpire-11: Put back shadow expiry and delete options openssh-passexpire-11: I screwed up the last merge from cvs and the shadow stuff wasn't there. This one adds it back in, uses spw->sp_warn and removes the options. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at mindrot.org Fri Jan 10 05:38:59 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 10 Jan 2003 05:38:59 +1100 (EST) Subject: [Bug 421] compile error on Debian slink Message-ID: <20030109183859.2C6FA6451A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=421 ------- Additional Comments From carl at chage.com 2003-01-10 05:38 ------- I noticed the same problem with a compile error where ucred is undefined in SUSE Linux 6.1. The problem is the test for SO_PEERCRED-- the feature is not available even though the define is present. In my linux/socket.h there is a "#define SCM_CREDENTIALS" next to the ucred definition, so the change from #if defined(SO_PEERCRED) to #if defined(SO_PEERCRED) && defined(SCM_CREDENTIALS) solves the compile problem, but I don't know which other distributions have the same. It may be SCM_CREDS or SCM_RIGHTS. Perhaps the only good way to check is with a new autoconfigure variable. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From vinschen at redhat.com Fri Jan 10 09:13:00 2003 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 9 Jan 2003 23:13:00 +0100 Subject: [PATCH] Cygwin and openssl-0.9.7 Message-ID: <20030109231300.W23921@cygbert.vinschen.de> 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 Fri Jan 10 09:27:30 2003 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 9 Jan 2003 23:27:30 +0100 Subject: [PATCH] Allow multiple accounts on Windows 9x/Me Message-ID: <20030109232730.X23921@cygbert.vinschen.de> 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 bugzilla-daemon at mindrot.org Fri Jan 10 09:54:54 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 10 Jan 2003 09:54:54 +1100 (EST) Subject: [Bug 236] No setproctitle() replacement for many unices Message-ID: <20030109225454.4254B6451A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=236 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-10 09:54 ------- I have committed this - it will switch on For Linux, AIX and HP/UX (If I got the configure logic correct). Switching it on for other platforms is simply a matter of editing openbsd-compat/setproctitle.c and twiddling the #ifdef maze ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djm at mindrot.org Fri Jan 10 12:44:51 2003 From: djm at mindrot.org (Damien Miller) Date: Fri, 10 Jan 2003 12:44:51 +1100 Subject: PAM merge from FreeBSD Message-ID: <3E1E2593.3070204@mindrot.org> Hi, The attached patch is a merge of Dag-Erling Smorgrav's PAM support for OpenSSH (from FreeBSD). IMO it is a good deal cleaner than the existing PAM code and I'd like to see it imported soon. The code removes the existing PAM password authentication in favor of doing it all via keyboard-interactive. The diff therefore removes the PAMAuthenticationViaKbdInt config item. It also has support for POSIX threads, which is needed (I'm told) for modules like pam_krb5. I have tested this with my basic PAM config, but the patch doesn't include the configure glue to make it work. Since this is a disruptive change, I'd like to get some testing and feedback before committing. Please give the attached patch a try on as many platforms as possible (as many PAM configs as possible too). FYI to those who want to read, but not apply the patch: the file auth-pam.c is completely replaced and is therefore pretty unreadable in the diff. The new version is also attached for your perusal. -d -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-pam.diff Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030110/38632072/attachment.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: auth-pam.c Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030110/38632072/attachment.c From mks at noida.hcltech.com Tue Jan 7 23:33:25 2003 From: mks at noida.hcltech.com (Manish Kumar Srivastava, Noida) Date: Tue, 7 Jan 2003 18:03:25 +0530 Subject: ssh 3.1p1 problems on SX-6... Message-ID: Hi, Thanks a lot for your responses. The "bad packet length" problem occurs when we try to connect to an SX machine using ssh from any other machine (including the same SX machine on which sshd is running). We immediately get the "Bad Packet Length" message. From our logs we could identify that the bad packet is recognized first at server side. Probably our logs sent in previous posts would be helpful in recognizing the place. But we had a break thru today when we tried different versions of openssl at our side with openssh-3.1p1 openssl-0.9.6b - aes128-cbc fails (Bad Packet length problem) openssl-0.9.6h - aes128-cbc fails (Bad packet length problem) openssl-0.9.7 - PASSES (no bad packet length problem) In the openssl-0.9.7 changelog, it was written that the crypto/rijndael is moved to crypto/aes but we couldn't find the implementation of rijndael in openssl-0.9.6[bh]. I think this may not be the appropriate place to ask a question about openssl, still... And our second problem of sftp hanging on exit, is *still* there with all versions of openssl and openssh (we have tried 3.1p1 and 3.5p1). I am attaching two log files one for sftp client side debug output and another with sftp server side debug output, both having PACKET_DEBUG defined. I hope the lists accepts attachments. Please suggest. > > SX-6 is the NEC machine followon to the SX-5. SuperUX is the OS. > Cray Inc currently provides support for some of these machines in the > US and i have a openssh port of 3.4p1 that runs on one. > we haven't run into this particular problem, so our port must be more > complete than manish's. > > be a bit patient and i'll update it to 3.5 and provide our > patches for manish to try. Thanks a lot for this information. We would be eagerly waiting for the patches. Regards Manish > > > Ben Lindstrom wrote: > > > > > On Mon, 6 Jan 2003, Manish Kumar Srivastava, Noida wrote: > > > > > >>Hello, > >> > >>We are porting openssh-3.1p1 onto SX-6 running on SuperUX. > >>We landed into problem when we started running sshd with > >>the default encryption settings. As you would have already > >>seen on this mailing list. > >> > > > > First off.. I have no clue what SX-6 is.. Nor what hardware > it runs on. > > Nor how old it may be. So it would be nice to be clued in > on that. Maybe > > even what branch of the UNIX tree it was formed from. > > > > > >>Basically we are facing two problems (both client and servers > >>run on SX):- > >> > >>1) If the we use the default encryption algorithm aes128-cbc > >> then we get a Bad Packet length problem on server side. > >> > >> > > > > Don't know. Most of the time I've seen 'Bad Packet length' it was a > > broken OpenSSL. IIRC in the OpenSSL tree there is a 'make > test' that > > allows you to see if everything passes. > > > > > > > >>2) If we run the sshd after setting encryption algorithm > >> to say 3des-cbc or aes192-cbc, then everything works fine > >> except for sftp. When we exit from sftp then it hangs in > >> select() called from server_loop2(). > >> > >> > > > > My tired and befuddled brain wants to say scream out 'race > condition', but > > even after skimming your last emails. I really am not sure > off hand. I > > know AIX has oddities under some releases for select(). > > > > > >>Both the problems are posted on the mailing list and both > >>recur with the latest version of openssh i.e. 3.5p1 with > >>openssl 0.9.6b. Kindly suggest something. We want to fix > >>the problems. > >> > >> > > > > I wish I could give you more direct help, but at this > point. I'm not sure > > what to even suggest for a starting point. > > > > - Ben > > > > _______________________________________________ > > openssh-unix-dev at mindrot.org mailing list > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > -- > wendy palm > Cray OS Sustaining Engineering, Cray Inc. > wendyp at cray.com, 651-605-9154 > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sftp_output.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030107/82f3507a/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sftp_sshd_output.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030107/82f3507a/attachment-0001.txt From bugzilla-daemon at mindrot.org Fri Jan 10 13:57:10 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 10 Jan 2003 13:57:10 +1100 (EST) Subject: [Bug 421] compile error on Debian slink Message-ID: <20030110025710.C0E6364513@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=421 ------- Additional Comments From fong at pigtail.net 2003-01-10 13:57 ------- #if defined(SO_PEERCRED) && defined(SCM_CREDENTIALS) also works with Debian Slink. ------- 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 Jan 10 09:50:43 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 9 Jan 2003 16:50:43 -0600 (CST) Subject: ssh 3.1p1 problems on SX-6... In-Reply-To: Message-ID: On Tue, 7 Jan 2003, Manish Kumar Srivastava, Noida wrote: [..] > But we had a break thru today when we tried different versions > of openssl at our side with openssh-3.1p1 > > openssl-0.9.6b - aes128-cbc fails (Bad Packet length problem) > openssl-0.9.6h - aes128-cbc fails (Bad packet length problem) > openssl-0.9.7 - PASSES (no bad packet length problem) > > In the openssl-0.9.7 changelog, it was written that the crypto/rijndael > is moved to crypto/aes but we couldn't find the implementation of > rijndael in openssl-0.9.6[bh]. I think this may not be the appropriate > place to ask a question about openssl, still... > Markus already answered this. 0.9.6 did not have AES. It was implemented within OpenSSH tree. When 0.9.7 betas came out we moved to a new way of supporting the OpenSSL API. As a result we have seen a few cases where aes has failed, but it is not consistant over every platform. - Ben From djm at mindrot.org Fri Jan 10 15:59:03 2003 From: djm at mindrot.org (Damien Miller) Date: Fri, 10 Jan 2003 15:59:03 +1100 Subject: Test, please ignore Message-ID: <3E1E5317.6050404@mindrot.org> Testing some new spam filtering. Please ignore. -d From fcusack at fcusack.com Fri Jan 10 16:49:43 2003 From: fcusack at fcusack.com (Frank Cusack) Date: Thu, 9 Jan 2003 21:49:43 -0800 Subject: PAM merge from FreeBSD In-Reply-To: <3E1E2593.3070204@mindrot.org>; from djm@mindrot.org on Fri, Jan 10, 2003 at 12:44:51PM +1100 References: <3E1E2593.3070204@mindrot.org> Message-ID: <20030109214943.A29970@google.com> On Fri, Jan 10, 2003 at 12:44:51PM +1100, Damien Miller wrote: > It also has support for POSIX threads, which is needed (I'm told) for > modules like pam_krb5. I have tested this with my basic PAM config, but > the patch doesn't include the configure glue to make it work. Having written a pam_krb5 myself, I find this hard to believe. The krb5 libs themselves do not have any thread support are not thread-safe. The PAM library itself does not even support threads (each thread must have it's own PAM handle). Besides, sshd is single-threaded. Having not looked at the patch, though, I shouldn't be so quick to slam it. I like the idea of only doing PAM via kbdint, but that's not going to work for a very large number of people. /fc From djm at mindrot.org Fri Jan 10 16:57:01 2003 From: djm at mindrot.org (Damien Miller) Date: Fri, 10 Jan 2003 16:57:01 +1100 Subject: PAM merge from FreeBSD In-Reply-To: <20030109214943.A29970@google.com> References: <3E1E2593.3070204@mindrot.org> <20030109214943.A29970@google.com> Message-ID: <3E1E60AD.9050500@mindrot.org> Frank Cusack wrote: > I like the idea of only doing PAM via kbdint, but that's not going to work > for a very large number of people. Why is that? From dubu0874 at uidaho.edu Fri Jan 10 19:11:11 2003 From: dubu0874 at uidaho.edu (dubu0874 at uidaho.edu) Date: Fri, 10 Jan 2003 00:11:11 -0800 Subject: Cipher Text per Packet Message-ID: <1be95159ef.159ef1be95@uidaho.edu> I am trying to do some analysis and modification on the cipher text in per packet increments. Having a bit of trouble getting the cipher text per packet. I believe I am getting the correct sent cipher text (from inside packet_send2 - compared it to a packet capture to be sure) but not certain about getting the recieving stream of cipher text. I have, of coarse, determined that packet_read_poll2 is where I need to look. The problem lies in that packets seem to be continiously coming in and being constructed (of coarse) and from what I can tell they are actively being decrypted? Am I missing something or is it with the current architecture one is unable to get at an entire packets worth of cipher text from the incoming stream? Any help would be greatly appriciated. I hope I don't get too many RTFM's... but if I do, then could someone please reference me to a good manual :-) Thomas DuBuisson From MPak at dotsconnect.com Fri Jan 10 20:10:00 2003 From: MPak at dotsconnect.com (MPak at dotsconnect.com) Date: Fri, 10 Jan 2003 04:10:00 -0500 Subject: [PATCH] PAM chauthtok + Privsep Message-ID: Could somebody give me a hint on how to use the patch for password expiration? I am about to start "./configure" OpenSSH35p1. I have downloaded Darren Tucker's id#200, openssh-passwordpatch.11. This patch has sections like "Index: acconfig.h" and "Index: auth-pam.c". Do I need to append these sections to appropriate files in the openssh-3.5.p1 directory? I have searched the net but could not find an explanation on its usage for non-developers like myself. Also I am doing this to fix my first 3.5.p1 build which has a password expiration problem. Is there any work around, other than rebuilding package and reinstalling it on servers? Thank you. Mesut Pak Darren Tucker To: OpenSSH Devel List Sent by: cc: openssh-unix-dev-admin@ Subject: [PATCH] PAM chauthtok + Privsep mindrot.org 12/21/2002 07:11 AM Hello All. Attached is an update to my previous patch to make do_pam_chauthtok and privsep play nicely together. First, a question: does anybody care about these or the password expiration patches? Anyway, the "PRIVSEP(do_pam_hauthtok())" has been moved to just after the pty has been allocated but before it's made the controlling tty. This allows the child running chauthtok to acquire a controlling tty so the PAM conversation function works without modification. The child then runs to completion so the slave can acquire its controlling tty and continue as normal. Description from previous patch: Attached is a patch that implements password expiry with PAM and privsep. It works by passing a descriptor to the tty to the monitor, which sets up a child with that tty as stdin/stdout/stderr, then runs chauthtok(). No setuid helpers. -- 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.Index: auth-pam.c =================================================================== RCS file: /cvs/openssh/auth-pam.c,v retrieving revision 1.54 diff -u -r1.54 auth-pam.c --- auth-pam.c 28 Jul 2002 20:24:08 -0000 1.54 +++ auth-pam.c 21 Dec 2002 11:39:05 -0000 @@ -42,8 +42,6 @@ #define NEW_AUTHTOK_MSG \ "Warning: Your password has expired, please change it now." -#define NEW_AUTHTOK_MSG_PRIVSEP \ - "Your password has expired, the session cannot proceed." static int do_pam_conversation(int num_msg, const struct pam_message **msg, struct pam_response **resp, void *appdata_ptr); @@ -186,12 +184,15 @@ pam_retval, PAM_STRERROR(__pamh, pam_retval)); } +/* HP-UX doesn't like credentials to be deleted. Skip and rely on pam_end () */ +#ifndef __hpux if (__pamh && creds_set) { pam_retval = pam_setcred(__pamh, PAM_DELETE_CRED); if (pam_retval != PAM_SUCCESS) debug("Cannot delete credentials[%d]: %.200s", pam_retval, PAM_STRERROR(__pamh, pam_retval)); } +#endif if (__pamh) { pam_retval = pam_end(__pamh, pam_retval); @@ -256,10 +257,8 @@ 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); + message_cat(&__pam_msg, NEW_AUTHTOK_MSG); /* flag that password change is necessary */ password_change_required = 1; /* disallow other functionality for now */ @@ -267,7 +266,6 @@ 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, @@ -301,6 +299,18 @@ session_opened = 1; } +/* Set the TTY after session is open */ +void do_pam_set_tty(const char *ttyname) { + int pam_retval; + if (ttyname != NULL) { + debug("PAM setting tty to \"%.200s\"", ttyname); + pam_retval = pam_set_item(__pamh, PAM_TTY, ttyname); + if (pam_retval != PAM_SUCCESS) + fatal("PAM set tty failed[%d]: %.200s", + pam_retval, PAM_STRERROR(__pamh, pam_retval)); + } +} + /* Set PAM credentials */ void do_pam_setcred(int init) { @@ -344,17 +354,15 @@ do_pam_set_conv(&conv); if (password_change_required) { - if (use_privsep) - fatal("Password changing is currently unsupported" - " with privilege separation"); pamstate = OTHER; pam_retval = pam_chauthtok(__pamh, PAM_CHANGE_EXPIRED_AUTHTOK); if (pam_retval != PAM_SUCCESS) fatal("PAM pam_chauthtok failed[%d]: %.200s", pam_retval, PAM_STRERROR(__pamh, pam_retval)); -#if 0 /* XXX: This would need to be done in the parent process, * but there's currently no way to pass such request. */ + password_change_required = 0; +#if 0 no_port_forwarding_flag &= ~2; no_agent_forwarding_flag &= ~2; no_x11_forwarding_flag &= ~2; Index: auth-pam.h =================================================================== RCS file: /cvs/openssh/auth-pam.h,v retrieving revision 1.16 diff -u -r1.16 auth-pam.h --- auth-pam.h 23 Jul 2002 00:44:07 -0000 1.16 +++ auth-pam.h 21 Dec 2002 11:39:05 -0000 @@ -25,6 +25,8 @@ */ #include "includes.h" +#include "channels.h" +#include "session.h" #ifdef USE_PAM #if !defined(SSHD_PAM_SERVICE) Index: monitor.c =================================================================== RCS file: /cvs/openssh/monitor.c,v retrieving revision 1.33 diff -u -r1.33 monitor.c --- monitor.c 9 Nov 2002 15:47:49 -0000 1.33 +++ monitor.c 21 Dec 2002 11:39:06 -0000 @@ -118,6 +118,7 @@ #ifdef USE_PAM int mm_answer_pam_start(int, Buffer *); +int mm_answer_pam_chauthtok(int, Buffer *); #endif #ifdef KRB4 @@ -183,6 +184,9 @@ {MONITOR_REQ_PTY, 0, mm_answer_pty}, {MONITOR_REQ_PTYCLEANUP, 0, mm_answer_pty_cleanup}, {MONITOR_REQ_TERM, 0, mm_answer_term}, +#ifdef USE_PAM + {MONITOR_REQ_PAM_CHAUTHTOK, 0, mm_answer_pam_chauthtok}, +#endif {0, 0, NULL} }; @@ -219,6 +223,9 @@ {MONITOR_REQ_PTY, MON_ONCE, mm_answer_pty}, {MONITOR_REQ_PTYCLEANUP, MON_ONCE, mm_answer_pty_cleanup}, {MONITOR_REQ_TERM, 0, mm_answer_term}, +#ifdef USE_PAM + {MONITOR_REQ_PAM_CHAUTHTOK, 0, mm_answer_pam_chauthtok}, +#endif {0, 0, NULL} }; @@ -328,6 +335,7 @@ if (!no_pty_flag) { monitor_permit(mon_dispatch, MONITOR_REQ_PTY, 1); monitor_permit(mon_dispatch, MONITOR_REQ_PTYCLEANUP, 1); + monitor_permit(mon_dispatch, MONITOR_REQ_PAM_CHAUTHTOK, 1); } for (;;) @@ -746,6 +754,56 @@ xfree(user); return (0); +} + +int +mm_answer_pam_chauthtok(int socket, Buffer *m) +{ + pid_t pid; + int ttyfd, status; + mysig_t old_signal; + + old_signal = mysignal(SIGCHLD, SIG_DFL); + + ttyfd = mm_receive_fd(socket); + debug3("%s: ttyfd=%d, ttyname=%s", __func__, ttyfd, ttyname(ttyfd)); + + if ((pid = fork()) == 0) { + /* acquire controlling tty */ + pty_make_controlling_tty(ttyfd, ttyname(ttyfd)); + + /* set up stdin, stdout and stderr */ + if (dup2(ttyfd, 0) < 0) + error("dup2 stdin: %s", strerror(errno)); + if (dup2(ttyfd, 1) < 0) + error("dup2 stdout: %s", strerror(errno)); + if (dup2(ttyfd, 2) < 0) + error("dup2 stderr: %s", strerror(errno)); + + /* close extra descriptors */ + close(socket); + close(ttyfd); + + /* call PAM chauthtok and return status to parent */ + do_pam_chauthtok(); + if(is_pam_password_change_required()) + exit(1); /* failed */ + else + exit(0); /* success */ + } + close(ttyfd); + + if (waitpid(pid, &status, 0) == -1) + fatal("Couldn't wait for child: %s", strerror(errno)); + + if (WEXITSTATUS(status)) + fatal("do_pam_chauthtok() failed, child returned %d", status); + + mysignal(SIGCHLD, old_signal); + + mm_request_send(socket, MONITOR_ANS_PAM_CHAUTHTOK, m); + + return 1; } #endif Index: monitor.h =================================================================== RCS file: /cvs/openssh/monitor.h,v retrieving revision 1.10 diff -u -r1.10 monitor.h --- monitor.h 27 Sep 2002 03:26:02 -0000 1.10 +++ monitor.h 21 Dec 2002 11:39:06 -0000 @@ -52,6 +52,7 @@ MONITOR_REQ_KRB4, MONITOR_ANS_KRB4, MONITOR_REQ_KRB5, MONITOR_ANS_KRB5, MONITOR_REQ_PAM_START, + MONITOR_REQ_PAM_CHAUTHTOK, MONITOR_ANS_PAM_CHAUTHTOK, MONITOR_REQ_TERM }; Index: monitor_wrap.c =================================================================== RCS file: /cvs/openssh/monitor_wrap.c,v retrieving revision 1.20 diff -u -r1.20 monitor_wrap.c --- monitor_wrap.c 27 Sep 2002 03:26:03 -0000 1.20 +++ monitor_wrap.c 21 Dec 2002 11:39:06 -0000 @@ -663,6 +663,31 @@ buffer_free(&m); } + +/* + * Privsep chauthtok works by passing a descriptor to the session's + * stdin/stdout to the monitor, which then sets up a child with this + * descriptor as stdin, stdout and controlling terminal, then calls + * chauthtok() + * + * This MUST be called before the session has acquired its controlling + * tty or the chauthtok child will not be able to acquire it and + * will fail. + */ + +void +mm_do_pam_chauthtok(void) +{ + int result; + Buffer m; + + buffer_init(&m); + mm_request_send(pmonitor->m_recvfd, MONITOR_REQ_PAM_CHAUTHTOK, &m); + mm_send_fd(pmonitor->m_recvfd, STDIN_FILENO); + mm_request_receive_expect(pmonitor->m_recvfd, MONITOR_ANS_PAM_CHAUTHTOK, &m); + + buffer_free(&m); +} #endif /* USE_PAM */ /* Request process termination */ Index: monitor_wrap.h =================================================================== RCS file: /cvs/openssh/monitor_wrap.h,v retrieving revision 1.9 diff -u -r1.9 monitor_wrap.h --- monitor_wrap.h 27 Sep 2002 03:26:04 -0000 1.9 +++ monitor_wrap.h 21 Dec 2002 11:39:06 -0000 @@ -57,6 +57,7 @@ #ifdef USE_PAM void mm_start_pam(char *); +void mm_pam_chauthtok(void); #endif void mm_terminate(void); Index: session.c =================================================================== RCS file: /cvs/openssh/session.c,v retrieving revision 1.222 diff -u -r1.222 session.c --- session.c 26 Sep 2002 00:38:50 -0000 1.222 +++ session.c 21 Dec 2002 11:39:07 -0000 @@ -454,7 +454,6 @@ session_proctitle(s); #if defined(USE_PAM) - do_pam_session(s->pw->pw_name, NULL); do_pam_setcred(1); if (is_pam_password_change_required()) packet_disconnect("Password change required but no " @@ -581,7 +580,7 @@ ttyfd = s->ttyfd; #if defined(USE_PAM) - do_pam_session(s->pw->pw_name, s->tty); + do_pam_set_tty(s->tty); do_pam_setcred(1); #endif @@ -594,9 +593,6 @@ /* Close the master side of the pseudo tty. */ close(ptyfd); - /* Make the pseudo tty our controlling tty. */ - pty_make_controlling_tty(&ttyfd, s->tty); - /* Redirect stdin/stdout/stderr from the pseudo tty. */ if (dup2(ttyfd, 0) < 0) error("dup2 stdin: %s", strerror(errno)); @@ -608,6 +604,24 @@ /* Close the extra descriptor for the pseudo tty. */ close(ttyfd); +#ifdef USE_PAM + /* + * If password change is needed, do it now. + * For privsep, this needs to occur before we acquire a + * controlling tty. + */ + print_pam_messages(); + if (use_privsep && is_pam_password_change_required()) + PRIVSEP(do_pam_chauthtok()); +#endif + /* Make the pseudo tty our controlling tty. */ + pty_make_controlling_tty(&ttyfd, s->tty); + + /* without privsep, chauthtok requires a controlling tty */ + if (!use_privsep) + do_pam_chauthtok(); + + /* record login, etc. similar to login(1) */ #ifndef HAVE_OSF_SIA if (!(options.use_login && command == NULL)) { @@ -746,16 +760,6 @@ options.verify_reverse_mapping), (struct sockaddr *)&from, fromlen); -#ifdef USE_PAM - /* - * If password change is needed, do it now. - * This needs to occur before the ~/.hushlogin check. - */ - if (is_pam_password_change_required()) { - print_pam_messages(); - do_pam_chauthtok(); - } -#endif if (check_quietlogin(s, command)) return; @@ -1238,6 +1242,12 @@ * Reestablish them here. */ do_pam_setcred(0); + + /* + * We need to open the session here because PAM on HP-UX does not + * work after the call to permanently_set_uid. + */ + do_pam_session(pw->pw_name,NULL); # endif /* USE_PAM */ # if defined(WITH_IRIX_PROJECT) || defined(WITH_IRIX_JOBS) || defined(WITH_IRIX_ARRAY) irix_setusercontext(pw); From markus at openbsd.org Fri Jan 10 20:44:56 2003 From: markus at openbsd.org (Markus Friedl) Date: Fri, 10 Jan 2003 10:44:56 +0100 Subject: Cipher Text per Packet In-Reply-To: <1be95159ef.159ef1be95@uidaho.edu> References: <1be95159ef.159ef1be95@uidaho.edu> Message-ID: <20030110094456.GE22495@folly> since (for protocol 2) the packet length is encrypted a single packet is decryted in 2 steps in packet_read_poll2. From bugzilla-daemon at mindrot.org Fri Jan 10 20:56:49 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 10 Jan 2003 20:56:49 +1100 (EST) Subject: [Bug 14] Can't change expired /etc/shadow password without PAM Message-ID: <20030110095649.7537A64555@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=14 ------- Additional Comments From dtucker at zip.com.au 2003-01-10 20:56 ------- passexpire-11 is broken (doesn't correctly check for change), please ignore. I'm working on a fix. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From dtucker at zip.com.au Fri Jan 10 20:59:53 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 10 Jan 2003 20:59:53 +1100 Subject: [PATCH] PAM chauthtok + Privsep References: Message-ID: <3E1E9999.E361F75E@zip.com.au> MPak at dotsconnect.com wrote: > Could somebody give me a hint on how to use the patch for password > expiration? > I am about to start "./configure" OpenSSH35p1. I have downloaded Darren > Tucker's id#200, openssh-passwordpatch.11. Please don't use patches 10 or 11, I've just found that they don't correctly check for successful password change. I'm working on it now. > This patch has sections like "Index: acconfig.h" and "Index: auth-pam.c". > Do I need to append these sections to appropriate files in the > openssh-3.5.p1 directory? > I have searched the net but could not find an explanation on its usage for > non-developers like myself. > > Also I am doing this to fix my first 3.5.p1 build which has a password > expiration problem. Is there any work around, other than rebuilding package > and reinstalling it on servers? Patches 9 and up are against the current CVS tree and not 3.5p1 and won't apply cleanly (ie you'll need to fix conflicts yourself). What platform are you using? There are a couple of patches that apply to 3.5p1 but the one to use depends on your 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 bugzilla-daemon at mindrot.org Fri Jan 10 21:25:21 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 10 Jan 2003 21:25:21 +1100 (EST) Subject: [Bug 403] scp generates sparse file when no space left Message-ID: <20030110102521.60B916454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=403 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-10 21:25 ------- Fix committed to CVS. 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 Jan 10 21:28:38 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 10 Jan 2003 21:28:38 +1100 (EST) Subject: [Bug 408] sshd[25790]: error: socket: Protocol not supported Message-ID: <20030110102838.8E91264554@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=408 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-10 21:28 ------- Fix committed. 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 Jan 10 21:29:14 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 10 Jan 2003 21:29:14 +1100 (EST) Subject: [Bug 310] sshd reporting ai_socktype errors when using ssh -X to server Message-ID: <20030110102914.B6E7764555@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=310 ------- Additional Comments From djm at mindrot.org 2003-01-10 21:29 ------- Please try tomorrow's snapshot - the fix for bug #408 may also fix this. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Fri Jan 10 22:10:01 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 10 Jan 2003 22:10:01 +1100 Subject: Core dump from sshd fatal_cleanup() Message-ID: <3E1EAA09.1E766B74@zip.com.au> Hi All. While working on something I noticed core dumps from sshd. They don't seem to be related to what I was working on. It's from the process forked to run the shell. Just after the fork, fatal_remove_all_cleanups() is called, which looks like: fatal_remove_all_cleanups(void) { struct fatal_cleanup *cu, *next_cu; for (cu = fatal_cleanups; cu; cu = next_cu) { next_cu = cu->next; xfree(cu); } } It runs through free'ing the structs, but it leaves the global fatal_cleanups pointing to the first struct. If called later, fatal_cleanup() attempts to deref the whatever happens to be at that location, falls over, goes boom. -Daz. # gdb -q ./sshd /var/core/core.sshd.27549 [snip] #0 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x0003ccb4 in fatal_cleanup () at ../log.c:254 #2 0x00038988 in fatal (fmt=0xf0c00 "") at ../fatal.c:39 #3 0x00023400 in do_tty_change_password (pw=0x10e690) at ../auth-passwd.c:300 #4 0x00029884 in do_login (s=0x101b4c, command=0x0) at ../session.c:764 #5 0x00029518 in do_exec_pty (s=0x101b4c, command=0x0) at ../session.c:617 #6 0x000296c0 in do_exec (s=0x101b4c, command=0x0) at ../session.c:710 #7 0x0002b1b0 in session_shell_req (s=0x101b4c) at ../session.c:1729 #8 0x0002b358 in session_input_channel_req (c=0x110cd8, rtype=0x10f750 "shell") at ../session.c:1780 #9 0x00028790 in server_input_channel_req (type=1111888, seq=13, ctxt=0x10d018) at ../serverloop.c:1021 #10 0x00038930 in dispatch_run (mode=1, done=0x0, ctxt=0x10d018) at ../dispatch.c:93 #11 0x00027f5c in server_loop2 (authctxt=0xff800) at ../serverloop.c:764 #12 0x00028d18 in do_authenticated (authctxt=0x109230) at ../session.c:218 #13 0x0001d84c in main (ac=7868, av=0x6) at ../sshd.c:1536 (gdb) frame 1 #1 0x0003ccb4 in fatal_cleanup () at ../log.c:254 254 (*cu->proc) (cu->context); (gdb) print cu $1 = (struct fatal_cleanup *) 0x1097e0 (gdb) print *cu $2 = {next = 0x10, proc = 0, context = 0x109840} -- 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: log.c =================================================================== RCS file: /cvs/openssh/log.c,v retrieving revision 1.26 diff -u -r1.26 log.c --- log.c 7 Jan 2003 06:04:18 -0000 1.26 +++ log.c 10 Jan 2003 10:55:16 -0000 @@ -233,6 +233,7 @@ next_cu = cu->next; xfree(cu); } + fatal_cleanups = NULL; } /* Cleanup and exit */ From fcusack at fcusack.com Fri Jan 10 22:15:04 2003 From: fcusack at fcusack.com (Frank Cusack) Date: Fri, 10 Jan 2003 03:15:04 -0800 Subject: PAM merge from FreeBSD In-Reply-To: <3E1E60AD.9050500@mindrot.org>; from djm@mindrot.org on Fri, Jan 10, 2003 at 04:57:01PM +1100 References: <3E1E2593.3070204@mindrot.org> <20030109214943.A29970@google.com> <3E1E60AD.9050500@mindrot.org> Message-ID: <20030110031504.C30868@google.com> On Fri, Jan 10, 2003 at 04:57:01PM +1100, Damien Miller wrote: > Frank Cusack wrote: > > > I like the idea of only doing PAM via kbdint, but that's not going to work > > for a very large number of people. > > Why is that? It means you can only use PAM for clients that support kbdint. /fc From djm at mindrot.org Fri Jan 10 23:45:27 2003 From: djm at mindrot.org (Damien Miller) Date: Fri, 10 Jan 2003 23:45:27 +1100 Subject: PAM merge from FreeBSD In-Reply-To: <20030110031504.C30868@google.com> References: <3E1E2593.3070204@mindrot.org> <20030109214943.A29970@google.com> <3E1E60AD.9050500@mindrot.org> <20030110031504.C30868@google.com> Message-ID: <3E1EC067.2010206@mindrot.org> Frank Cusack wrote: > On Fri, Jan 10, 2003 at 04:57:01PM +1100, Damien Miller wrote: > >>Frank Cusack wrote: >> >>>I like the idea of only doing PAM via kbdint, but that's not going to work >>>for a very large number of people. >> >>Why is that? > > It means you can only use PAM for clients that support kbdint. Just about everyone supports kbdint these days (OpenSSH has for two years), most of who don't are ssh1 only - which are supported through TIS auth anyway. -d From MPak at dotsconnect.com Sat Jan 11 00:24:10 2003 From: MPak at dotsconnect.com (MPak at dotsconnect.com) Date: Fri, 10 Jan 2003 08:24:10 -0500 Subject: [PATCH] PAM chauthtok + Privsep Message-ID: Thank you for the response. Platform is Sparc Solaris 8, with 2 or 3 Solaris 7s. Darren Tucker cc: openssh-unix-dev at mindrot.org 01/10/2003 Subject: Re: [PATCH] PAM chauthtok + Privsep 04:59 AM MPak at dotsconnect.com wrote: > Could somebody give me a hint on how to use the patch for password > expiration? > I am about to start "./configure" OpenSSH35p1. I have downloaded Darren > Tucker's id#200, openssh-passwordpatch.11. Please don't use patches 10 or 11, I've just found that they don't correctly check for successful password change. I'm working on it now. > This patch has sections like "Index: acconfig.h" and "Index: auth-pam.c". > Do I need to append these sections to appropriate files in the > openssh-3.5.p1 directory? > I have searched the net but could not find an explanation on its usage for > non-developers like myself. > > Also I am doing this to fix my first 3.5.p1 build which has a password > expiration problem. Is there any work around, other than rebuilding package > and reinstalling it on servers? Patches 9 and up are against the current CVS tree and not 3.5p1 and won't apply cleanly (ie you'll need to fix conflicts yourself). What platform are you using? There are a couple of patches that apply to 3.5p1 but the one to use depends on your 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 fcusack at fcusack.com Sat Jan 11 00:47:32 2003 From: fcusack at fcusack.com (Frank Cusack) Date: Fri, 10 Jan 2003 05:47:32 -0800 Subject: PAM merge from FreeBSD In-Reply-To: <3E1EC067.2010206@mindrot.org>; from djm@mindrot.org on Fri, Jan 10, 2003 at 11:45:27PM +1100 References: <3E1E2593.3070204@mindrot.org> <20030109214943.A29970@google.com> <3E1E60AD.9050500@mindrot.org> <20030110031504.C30868@google.com> <3E1EC067.2010206@mindrot.org> Message-ID: <20030110054732.A31687@google.com> On Fri, Jan 10, 2003 at 11:45:27PM +1100, Damien Miller wrote: > Frank Cusack wrote: > > On Fri, Jan 10, 2003 at 04:57:01PM +1100, Damien Miller wrote: > > > >>Frank Cusack wrote: > >> > >>>I like the idea of only doing PAM via kbdint, but that's not going to work > >>>for a very large number of people. > >> > >>Why is that? > > > > It means you can only use PAM for clients that support kbdint. > > Just about everyone supports kbdint these days (OpenSSH has for two > years), most of who don't are ssh1 only - which are supported through > TIS auth anyway. I wasn't aware that kbdint was so widespread. TIS auth doesn't support PAM correctly. - can't pass info messages (although this isn't done correctly by openssh anyway) - can't pass the echo/don't echo flag - can't have multiple exchanges As a server admin, I would never use TIS for PAM unless I was strictly doing challenge/response. I would assume that the client is going to echo the "response" entry. /fc From djm at mindrot.org Sat Jan 11 01:08:15 2003 From: djm at mindrot.org (Damien Miller) Date: Sat, 11 Jan 2003 01:08:15 +1100 Subject: PAM merge from FreeBSD In-Reply-To: <20030110054732.A31687@google.com> References: <3E1E2593.3070204@mindrot.org> <20030109214943.A29970@google.com> <3E1E60AD.9050500@mindrot.org> <20030110031504.C30868@google.com> <3E1EC067.2010206@mindrot.org> <20030110054732.A31687@google.com> Message-ID: <3E1ED3CF.3020109@mindrot.org> Frank Cusack wrote: > TIS auth doesn't support PAM correctly. > - can't pass info messages (although this isn't done correctly by openssh > anyway) > - can't pass the echo/don't echo flag > - can't have multiple exchanges I don't think we do any of these properly at the moment with privsep (maybe "echo on"). The new code allows for echo/don't echo and the possibility of multiple exchanges. > As a server admin, I would never use TIS for PAM unless I was strictly doing > challenge/response. I would assume that the client is going to echo the > "response" entry. The TIS support in the new patch defaults to echo off. -d From fcusack at fcusack.com Sat Jan 11 05:03:25 2003 From: fcusack at fcusack.com (Frank Cusack) Date: Fri, 10 Jan 2003 10:03:25 -0800 Subject: PAM merge from FreeBSD In-Reply-To: <3E1ED3CF.3020109@mindrot.org>; from djm@mindrot.org on Sat, Jan 11, 2003 at 01:08:15AM +1100 References: <3E1E2593.3070204@mindrot.org> <20030109214943.A29970@google.com> <3E1E60AD.9050500@mindrot.org> <20030110031504.C30868@google.com> <3E1EC067.2010206@mindrot.org> <20030110054732.A31687@google.com> <3E1ED3CF.3020109@mindrot.org> Message-ID: <20030110100325.H31910@google.com> On Sat, Jan 11, 2003 at 01:08:15AM +1100, Damien Miller wrote: > Frank Cusack wrote: > > As a server admin, I would never use TIS for PAM unless I was strictly doing > > challenge/response. I would assume that the client is going to echo the > > "response" entry. > > The TIS support in the new patch defaults to echo off. In openssh, sure. Again, as a server admin, I would not trust that the client is going to "work". Echo on is actually the correct and better behavior. /fc From fcusack at fcusack.com Sat Jan 11 05:20:22 2003 From: fcusack at fcusack.com (Frank Cusack) Date: Fri, 10 Jan 2003 10:20:22 -0800 Subject: PAM merge from FreeBSD In-Reply-To: <3E1ED3CF.3020109@mindrot.org>; from djm@mindrot.org on Sat, Jan 11, 2003 at 01:08:15AM +1100 References: <3E1E2593.3070204@mindrot.org> <20030109214943.A29970@google.com> <3E1E60AD.9050500@mindrot.org> <20030110031504.C30868@google.com> <3E1EC067.2010206@mindrot.org> <20030110054732.A31687@google.com> <3E1ED3CF.3020109@mindrot.org> Message-ID: <20030110102022.M31910@google.com> On Sat, Jan 11, 2003 at 01:08:15AM +1100, Damien Miller wrote: > Frank Cusack wrote: > > TIS auth doesn't support PAM correctly. > > - can't pass info messages (although this isn't done correctly by openssh > > anyway) > > - can't pass the echo/don't echo flag > > - can't have multiple exchanges > > I don't think we do any of these properly at the moment with privsep > (maybe "echo on"). The new code allows for echo/don't echo and the > possibility of multiple exchanges. Anyone that's using protocol 1 is probably using an older client that doesn't have these updates. To be clear: I *like* removing PAM from all but kbdint; the other auth methods cannot support it properly. But I think you will sacrifice too much in backwards compatibility. I certainly could not support such a setup. I wish anyone else on this list who would have problems with this would chime in ... If none, it might be safe to assume it's not an issue after all. /fc From wendyp at cray.com Sat Jan 11 07:58:31 2003 From: wendyp at cray.com (Wendy Palm) Date: Fri, 10 Jan 2003 14:58:31 -0600 Subject: SX-6 port of openssh, configure problems References: <3E19E1F8.8000100@cray.com> Message-ID: <3E1F33F7.8040800@cray.com> ok, i could use a little advice here. NEC SX6 has a couple of unusual configure problems. configure figures out that it has b64_ntop function (and it may, but i can't find it) so configure defines HAVE_B64_NTOP, but it doesn't have b64_pton, so then it has an unresolved symbol of b64_pton() and fails to link. if i #undef HAVE_B64_NTOP in config.h everything works fine. do we need another flag of HAVE_B64_PTON, or how do i force an #undef? configure also defines HAVE_INTXX_T based on whether int8_t && int16_t && int32_t is defined in sys/types.h. the SX6 has int32_t defined, but none of the others. however, i don't think int8_t and int16_t are needed on this machine, as it builds and works just fine when i hand edit config.h to define HAVE_INTXX_T. so, currently, i'm defining HAVE_INTXX_T in configure, but was wondering if that was the best thing to do, or if i might be causing myself problems i hadn't really seen yet. cray provides support to some SX sites, which is why i'm working on this, but if there's a real NEC person on this list, that would be great. thanks for the ear(s). wendy Wendy Palm wrote: > SX-6 is the NEC machine followon to the SX-5. SuperUX is the OS. > Cray Inc currently provides support for some of these machines in the > US and i have a openssh port of 3.4p1 that runs on one. > we haven't run into this particular problem, so our port must be more > complete than manish's. > > be a bit patient and i'll update it to 3.5 and provide our patches for > manish to try. > > -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From rick_jones2 at hp.com Sat Jan 11 08:33:17 2003 From: rick_jones2 at hp.com (Rick Jones) Date: Fri, 10 Jan 2003 13:33:17 -0800 Subject: SX-6 port of openssh, configure problems References: <3E19E1F8.8000100@cray.com> <3E1F33F7.8040800@cray.com> Message-ID: <3E1F3C1D.E2A2AA8A@hp.com> You aren't by any chance using "higher" optiization levels are you? I've been messing about with the 2002/12/17 snapshot of bind 9.3.0 on HP-UX 11.22, and when I tried to do 'CFLAGS="+O3" ./configure' , configure would think that functions were present which were not. As some clever people figured-out and told me, the code generated by the AC_TRY_LINK autoconf macro was broken - it would assign a function pointer to the value of the function of interest, but then would do nothing with it. The compiler (correctly) detects this as dead code, and eliminates it, thus eliminating the reference to the function of interest. So, the link in configure would work. The workaround is to either not use the higher optimization levels, or to edit the configure script to have it return the value of the function pointer. I am told that the fix is in the very latest autoconf bits, where it changes the return value based on the value of the function pointer. rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... From wendyp at cray.com Sat Jan 11 09:04:47 2003 From: wendyp at cray.com (Wendy Palm) Date: Fri, 10 Jan 2003 16:04:47 -0600 Subject: SX-6 port of openssh, configure problems References: <3E19E1F8.8000100@cray.com> <3E1F33F7.8040800@cray.com> <3E1F3C1D.E2A2AA8A@hp.com> Message-ID: <3E1F437F.203@cray.com> Rick Jones wrote: > You aren't by any chance using "higher" optiization levels are you? I've > been messing about with the 2002/12/17 snapshot of bind 9.3.0 on HP-UX > 11.22, and when I tried to do 'CFLAGS="+O3" ./configure' , configure > would think that functions were present which were not. good idea, but nope, that's not it. running with 0 optimization. i found that the b64_ntop function truly does exist (libc.a) but b64_pton truly doesn't. -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From jmknoble at pobox.com Sat Jan 11 09:32:21 2003 From: jmknoble at pobox.com (Jim Knoble) Date: Fri, 10 Jan 2003 17:32:21 -0500 Subject: SX-6 port of openssh, configure problems In-Reply-To: <3E1F437F.203@cray.com> References: <3E19E1F8.8000100@cray.com> <3E1F33F7.8040800@cray.com> <3E1F3C1D.E2A2AA8A@hp.com> <3E1F437F.203@cray.com> Message-ID: <20030110223221.GA16514@crawfish.ais.com> Circa 2003-01-10 16:04:47 -0600 dixit Wendy Palm: : i found that the b64_ntop function truly does exist (libc.a) : but b64_pton truly doesn't. Is there a replacement function in the OpenSSH tree? If so, it sounds to me as if configure ought to look for both of them, and not use either function unless both are present natively---otherwise, use the replacement functions. -- 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/20030110/603c7ad5/attachment.bin From djm at mindrot.org Sat Jan 11 09:35:30 2003 From: djm at mindrot.org (Damien Miller) Date: Sat, 11 Jan 2003 09:35:30 +1100 Subject: PAM merge from FreeBSD In-Reply-To: <20030110102022.M31910@google.com> References: <3E1E2593.3070204@mindrot.org> <20030109214943.A29970@google.com> <3E1E60AD.9050500@mindrot.org> <20030110031504.C30868@google.com> <3E1EC067.2010206@mindrot.org> <20030110054732.A31687@google.com> <3E1ED3CF.3020109@mindrot.org> <20030110102022.M31910@google.com> Message-ID: <3E1F4AB2.6010502@mindrot.org> Frank Cusack wrote: >>I don't think we do any of these properly at the moment with privsep >>(maybe "echo on"). The new code allows for echo/don't echo and the >>possibility of multiple exchanges. > > Anyone that's using protocol 1 is probably using an older client that doesn't > have these updates. I don't understand - the vast majority of people will be using a client with the necessary support. This includes (at least) OpenSSH, SSH.COM, PuTTY, MindTerm and F-Secure. (The first two alone have over 94% market share). Those who don't have a client which supports kbdint can fallback to password auth, uograde their client or not upgrade the which ever version includes PAM via kbdint. -d From wendyp at cray.com Sat Jan 11 09:43:39 2003 From: wendyp at cray.com (Wendy Palm) Date: Fri, 10 Jan 2003 16:43:39 -0600 Subject: SX-6 port of openssh, configure problems References: <3E19E1F8.8000100@cray.com> <3E1F33F7.8040800@cray.com> <3E1F3C1D.E2A2AA8A@hp.com> <3E1F437F.203@cray.com> <20030110223221.GA16514@crawfish.ais.com> Message-ID: <3E1F4C9B.90506@cray.com> yes, openbsd-compat/base64.c uses #if !defined(HAVE_B64_NTOP) && !defined(HAVE___B64_NTOP) to define both b64_ntop() and b64_pton() functions. i'll write up the patches to check for both functions. hmm, should we use a native function if it exists, whether or not the other does? (i.e. in this case, should we use native b64_ntop()?) Jim Knoble wrote: > Circa 2003-01-10 16:04:47 -0600 dixit Wendy Palm: > > : i found that the b64_ntop function truly does exist (libc.a) > : but b64_pton truly doesn't. > > Is there a replacement function in the OpenSSH tree? If so, it sounds > to me as if configure ought to look for both of them, and not use > either function unless both are present natively---otherwise, use the > replacement functions. > > -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From bugzilla-daemon at mindrot.org Sat Jan 11 10:06:17 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 11 Jan 2003 10:06:17 +1100 (EST) Subject: [Bug 14] Can't change expired /etc/shadow password without PAM Message-ID: <20030110230617.0054E64535@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=14 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #200 is|0 |1 obsolete| | ------- Additional Comments From dtucker at zip.com.au 2003-01-11 10:06 ------- Created an attachment (id=201) --> (http://bugzilla.mindrot.org/attachment.cgi?id=201&action=view) passexpire12: password expiry via /bin/passwd in session Now (correctly I hope!) checks that the password is changed successfully. Adds is_password_change_required() and privsep wrapper. This re-tests the account and resets the change flag. This is necessary because passwd sometimes does not return a failure exit code (eg AIX in the "your password has been expired too long and only the admin can change it" case). Tested on AIX 4.3.3, Solaris 8 and Redhat 8. Should work on any platform with /etc/shadow and any version of AIX 4 (unsure about previous versions). The equivalent patch against the 3.5p1 release is at http://www.zip.com.au/~dtucker/openssh/openssh-3.5p1-passexpire12.patch. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From djm at mindrot.org Sun Jan 12 11:38:33 2003 From: djm at mindrot.org (Damien Miller) Date: Sun, 12 Jan 2003 11:38:33 +1100 Subject: Testing 1...2..3.. Message-ID: <3E20B909.7090106@mindrot.org> Testing to see whether the list is back up. From djm at mindrot.org Sun Jan 12 11:46:27 2003 From: djm at mindrot.org (Damien Miller) Date: Sun, 12 Jan 2003 11:46:27 +1100 Subject: Administrivia: List restored Message-ID: <3E20BAE3.9010608@mindrot.org> Some time last night, the mailing list server corrupted its databases. I have restored the list membership information, but Mailman will have reset your passwords and any options you may have set on your account. If you want to reset these, please visit: http://www.mindrot.org/mailman/listinfo/openssh-unix-dev If you sent anything to the list which hasn't appeared, please resend it. Apologies for any inconvenience. Regards, Damien Miller From nicklange at wi.rr.com Sun Jan 12 14:27:51 2003 From: nicklange at wi.rr.com (Nick Lange) Date: Sat, 11 Jan 2003 19:27:51 -0800 Subject: Dynamic Link Library for SSH Protocol? Message-ID: <3E20E0B7.1080909@wi.rr.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, While not 100% on topic, I was wondering if anyone had tried making any of the openssh client protocol exportable as loadable modules? If this could be accomplished, perhaps it would easier to migrate existing ftp [read: gui] applications over to utilizing ssh/sftp.... Just a thought. cheers, nick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+IOC6UpjBJywc+asRAp8lAKDOzUI/rbZtVEgeFNcK770+wnmbrACePk/o REZhbKRnyw2RGHyulG/zqkY= =5z0I -----END PGP SIGNATURE----- From dtucker at zip.com.au Sun Jan 12 12:40:29 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 12 Jan 2003 12:40:29 +1100 Subject: [PATCH] PAM chauthtok + Privsep References: Message-ID: <3E20C78D.97EC562E@zip.com.au> [This is a re-send, the previous message bounced] MPak at dotsconnect.com wrote: > Could somebody give me a hint on how to use the patch for password > expiration? Grab the following patch (against the 3.5p1 release): http://www.zip.com.au/~dtucker/openssh/openssh-3.5p1-passexpire12.patch Untar the openssh-3.5p1 tarball. patch -p0 <3E1AB7BE.3030104@mindrot.org> <3E1ABD63.CDCEC09F@zip.com.au> <3E1BF9A9.D7CE8DE9@zip.com.au> <3E1C05B4.BF16C9B0@zip.com.au> Message-ID: <3E20CD75.80E8DA1@zip.com.au> Martin MOKREJ? wrote: > On Wed, 8 Jan 2003, Darren Tucker wrote: > > I'm only interested in whatever "passwd -l" or its equivalent does to > > the passwd entry, so when an admin locks the account, it really is > > locked. Any admin that hand-hacks /etc/passwd or equivalent is on their > > own. > > I did not mean with "manually" hand-hacked. I meant more "by intention > using standand tools". Those examples and not hand-introduced locks. > For example, the :*Nologin: and :Nologin*: even fools DEC engineers, so > the account manager gui used to show lock icon on an account name only in one > of these two cases. I've checked the manpage and it still descscribes onlu > "*", but in EXAMPLES section is :Nologin:. It's just incomplete. The above > is a summary of real life cases. Ew. Gotta love consistency. This patch adds handling of those cases (and takes into account the IRIX cases as described by Herbert Lewis) and adds a paragraph to sshd.8 describing what happens. Before anyone reads the comments and says "but Redhat has * too", they only reflect the results of an admin locking the account. Unfortunately there is some overlap (eg Redhat uses "*" for system accounts, while HP-UX uses "*" for passwd -l). -- 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: /cvs/openssh/auth.c,v retrieving revision 1.66 diff -u -r1.66 auth.c --- auth.c 9 Jan 2003 04:04:28 -0000 1.66 +++ auth.c 12 Jan 2003 01:47:06 -0000 @@ -100,7 +100,14 @@ #endif /* check for locked account */ - if (strcmp(passwd, "*LK*") == 0 || passwd[0] == '!') { + if (strcmp(passwd, "*LK*") == 0 || /* Solaris,IRIX */ + strcmp(passwd, "*") == 0 || /* HP-UX,Tru64 */ + strstr(passwd, "Nologin") || /* Tru64 */ +#ifdef __osf + /* Tru64 but we also want to allow "passwordless" accounts */ + (passwd[0] == '*' && strcmp(passwd, "*NP*") != 0) +#endif + passwd[0] == '!') { /* Redhat */ log("User %.100s not allowed because account is locked", pw->pw_name); return 0; Index: sshd.8 =================================================================== RCS file: /cvs/openssh/sshd.8,v retrieving revision 1.150 diff -u -r1.150 sshd.8 --- sshd.8 25 Sep 2002 02:20:54 -0000 1.150 +++ sshd.8 12 Jan 2003 01:47:07 -0000 @@ -112,6 +112,30 @@ authentication, RSA challenge-response authentication, or password based authentication. .Pp +Regardless of the authentication type, the account is checked to +ensure that it is accessible. An account is not accessible if it is +locked, listed in +.Cm DenyUsers +or its group is listed in +.Cm DenyGroups +\&. An account is considered locked if the passwd entry equals +.Ql \&*LK\&* +or +.Ql \&* +, contains the string +.Ql Nologin +, or has a leading +.Ql \&! +(or, on Tru64, a +.Ql \&* +) character. If there is a requirement to disable password authentication +for the account while allowing still public-key, then the passwd field +should be set to something other than these values (eg +.Ql NP +or +.Ql \&*NP\&* +). +.Pp Rhosts authentication is normally disabled because it is fundamentally insecure, but can be enabled in the server configuration file if desired. From dtucker at zip.com.au Sun Jan 12 21:59:52 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 12 Jan 2003 21:59:52 +1100 Subject: Test for locked account in auth.c (bug #442). References: <3E1AB39B.463D1531@zip.com.au> <3E1AB7BE.3030104@mindrot.org> <3E1ABD63.CDCEC09F@zip.com.au> <3E1BF9A9.D7CE8DE9@zip.com.au> <3E1C05B4.BF16C9B0@zip.com.au> <3E20CD75.80E8DA1@zip.com.au> Message-ID: <3E214AA8.A7809BE7@zip.com.au> Darren Tucker wrote: > This patch adds handling of those cases (and takes into account the IRIX > cases as described by Herbert Lewis) and adds a paragraph to sshd.8 > describing what happens. Hi All. Peter Stuge pointed out a missing "||" in the previous patch and I found that the regression tests no longer run on Solaris (using shadow support). This probably applies to any shadow platform. The regression failure is when the tests are not running as root. Previously, the shadow expiry tests were: spw = getspwnam(pw->pw_name); if (spw != NULL) { [expiry tests] so if sshd was not running as root, getspwnam failed and the tests were skipped. Now, it's spw = getspnam(pw->pw_name); if (!spw) return 0; so allowed_user fails rather that just skipping the tests. The new locked account tests have a similar problem. -- 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: /cvs/openssh/auth.c,v retrieving revision 1.66 diff -u -r1.66 auth.c --- auth.c 9 Jan 2003 04:04:28 -0000 1.66 +++ auth.c 12 Jan 2003 10:45:52 -0000 @@ -72,7 +72,7 @@ allowed_user(struct passwd * pw) { struct stat st; - const char *hostname = NULL, *ipaddr = NULL, *passwd; + const char *hostname = NULL, *ipaddr = NULL, *passwd = NULL; char *shell; int i; #ifdef WITH_AIXAUTHENTICATE @@ -92,15 +92,21 @@ /* Grab the password for locked account checking */ #if defined(HAVE_SHADOW_H) && !defined(DISABLE_SHADOW) spw = getspnam(pw->pw_name); - if (!spw) - return 0; - passwd = spw->sp_pwdp; + if (spw) + passwd = spw->sp_pwdp; #else passwd = pw->pw_passwd; #endif /* check for locked account */ - if (strcmp(passwd, "*LK*") == 0 || passwd[0] == '!') { + if (passwd && (strcmp(passwd, "*LK*") == 0 || /* Solaris,IRIX */ + strcmp(passwd, "*") == 0 || /* HP-UX,Tru64 */ + strstr(passwd, "Nologin") || /* Tru64 */ +#ifdef __osf + /* Tru64 but we also want to allow "passwordless" accounts */ + (passwd[0] == '*' && strcmp(passwd, "*NP*") != 0) || +#endif + passwd[0] == '!')) { /* Redhat */ log("User %.100s not allowed because account is locked", pw->pw_name); return 0; @@ -109,31 +115,33 @@ #if !defined(USE_PAM) && defined(HAVE_SHADOW_H) && \ !defined(DISABLE_SHADOW) && defined(HAS_SHADOW_EXPIRE) #define DAY (24L * 60 * 60) /* 1 day in seconds */ - today = time(NULL) / DAY; - debug3("allowed_user: today %d sp_expire %d sp_lstchg %d" - " sp_max %d", (int)today, (int)spw->sp_expire, - (int)spw->sp_lstchg, (int)spw->sp_max); - - /* - * We assume account and password expiration occurs the - * day after the day specified. - */ - if (spw->sp_expire != -1 && today > spw->sp_expire) { - log("Account %.100s has expired", pw->pw_name); - return 0; - } - - if (spw->sp_lstchg == 0) { - log("User %.100s password has expired (root forced)", - pw->pw_name); - return 0; - } - - if (spw->sp_max != -1 && - today > spw->sp_lstchg + spw->sp_max) { - log("User %.100s password has expired (password aged)", - pw->pw_name); - return 0; + if (spw) { + today = time(NULL) / DAY; + debug3("allowed_user: today %d sp_expire %d sp_lstchg %d" + " sp_max %d", (int)today, (int)spw->sp_expire, + (int)spw->sp_lstchg, (int)spw->sp_max); + + /* + * We assume account and password expiration occurs the + * day after the day specified. + */ + if (spw->sp_expire != -1 && today > spw->sp_expire) { + log("Account %.100s has expired", pw->pw_name); + return 0; + } + + if (spw->sp_lstchg == 0) { + log("User %.100s password has expired (root forced)", + pw->pw_name); + return 0; + } + + if (spw->sp_max != -1 && + today > spw->sp_lstchg + spw->sp_max) { + log("User %.100s password has expired (password aged)", + pw->pw_name); + return 0; + } } #endif Index: sshd.8 =================================================================== RCS file: /cvs/openssh/sshd.8,v retrieving revision 1.150 diff -u -r1.150 sshd.8 --- sshd.8 25 Sep 2002 02:20:54 -0000 1.150 +++ sshd.8 12 Jan 2003 10:45:53 -0000 @@ -112,6 +112,30 @@ authentication, RSA challenge-response authentication, or password based authentication. .Pp +Regardless of the authentication type, the account is checked to +ensure that it is accessible. An account is not accessible if it is +locked, listed in +.Cm DenyUsers +or its group is listed in +.Cm DenyGroups +\&. An account is considered locked if the passwd entry equals +.Ql \&*LK\&* +or +.Ql \&* +, contains the string +.Ql Nologin +, or has a leading +.Ql \&! +(or, on Tru64, a +.Ql \&* +) character. If there is a requirement to disable password authentication +for the account while allowing still public-key, then the passwd field +should be set to something other than these values (eg +.Ql NP +or +.Ql \&*NP\&* +). +.Pp Rhosts authentication is normally disabled because it is fundamentally insecure, but can be enabled in the server configuration file if desired. From bugzilla-daemon at mindrot.org Mon Jan 13 00:51:33 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 Jan 2003 00:51:33 +1100 (EST) Subject: [Bug 466] New: stfp cmds[] array conflicts with libc Message-ID: <20030112135133.6C8376454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=466 Summary: stfp cmds[] array conflicts with libc Product: Portable OpenSSH Version: 3.5p1 Platform: ix86 OS/Version: BSDI Status: NEW Severity: normal Priority: P2 Component: sftp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: mdev at idg.nl Also discussed in #146, but still unresolved. The cmds[] array is also used in libc, which conflicts, unless protected by either renaming or using it statically. ------- 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 Jan 13 00:53:53 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 Jan 2003 00:53:53 +1100 (EST) Subject: [Bug 466] stfp cmds[] array conflicts with libc Message-ID: <20030112135353.366B36454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=466 ------- Additional Comments From mdev at idg.nl 2003-01-13 00:53 ------- Created an attachment (id=203) --> (http://bugzilla.mindrot.org/attachment.cgi?id=203&action=view) Patch for stftp-int.c ------- 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 Jan 13 01:01:43 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 Jan 2003 01:01:43 +1100 (EST) Subject: [Bug 467] New: Feature request: --disable-strip Message-ID: <20030112140143.46EFB6454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=467 Summary: Feature request: --disable-strip Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: mdev at idg.nl While trying to resolve a bug, which turned out to be in my config and the openssl library, it was very tiresome, to manually copy the binaries, so one could get a debugable version. The patch, attached will provide the option '--disable-strip', to the configure options and act accordingly. ------- 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 Jan 13 01:03:04 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 Jan 2003 01:03:04 +1100 (EST) Subject: [Bug 467] Feature request: --disable-strip Message-ID: <20030112140304.3284264552@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=467 ------- Additional Comments From mdev at idg.nl 2003-01-13 01:03 ------- Created an attachment (id=204) --> (http://bugzilla.mindrot.org/attachment.cgi?id=204&action=view) Enter --disable-strip option ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Mon Jan 13 03:58:47 2003 From: markus at openbsd.org (Markus Friedl) Date: Sun, 12 Jan 2003 17:58:47 +0100 Subject: Dynamic Link Library for SSH Protocol? In-Reply-To: <3E20E0B7.1080909@wi.rr.com> References: <3E20E0B7.1080909@wi.rr.com> Message-ID: <20030112165847.GE15765@folly> the ssh code is not ready for that. for sftp it's not hard if you can exec ssh from your code. you can also share lots of code with our sftp client. On Sat, Jan 11, 2003 at 07:27:51PM -0800, Nick Lange wrote: > > Hi everyone, > > While not 100% on topic, I was wondering if anyone had tried making any of the openssh client protocol exportable as > loadable modules? > If this could be accomplished, perhaps it would easier to migrate existing ftp [read: gui] applications over to > utilizing ssh/sftp.... > > Just a thought. > cheers, > nick > > _______________________________________________ > 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 Mon Jan 13 05:00:57 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 Jan 2003 05:00:57 +1100 (EST) Subject: [Bug 236] No setproctitle() replacement for many unices Message-ID: <20030112180057.877F264552@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=236 ------- Additional Comments From stevesk at pobox.com 2003-01-13 05:00 ------- how does one munge process string in solaris? also, i think it would be better to set method per-platform in configure.ac rather than growing the ifdef maze: AC_DEFINE(SPT_TYPE,PS_USE_CLOBBER_ARGV) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From stevesk at pobox.com Mon Jan 13 05:14:29 2003 From: stevesk at pobox.com (Kevin Steves) Date: Sun, 12 Jan 2003 10:14:29 -0800 Subject: Test for locked account in auth.c (bug #442). In-Reply-To: <3E214AA8.A7809BE7@zip.com.au> References: <3E1AB39B.463D1531@zip.com.au> <3E1AB7BE.3030104@mindrot.org> <3E1ABD63.CDCEC09F@zip.com.au> <3E1BF9A9.D7CE8DE9@zip.com.au> <3E1C05B4.BF16C9B0@zip.com.au> <3E20CD75.80E8DA1@zip.com.au> <3E214AA8.A7809BE7@zip.com.au> Message-ID: <20030112181429.GB4292@scott.crlsca.adelphia.net> On Sun, Jan 12, 2003 at 09:59:52PM +1100, Darren Tucker wrote: > /* check for locked account */ > - if (strcmp(passwd, "*LK*") == 0 || passwd[0] == '!') { > + if (passwd && (strcmp(passwd, "*LK*") == 0 || /* Solaris,IRIX */ > + strcmp(passwd, "*") == 0 || /* HP-UX,Tru64 */ > + strstr(passwd, "Nologin") || /* Tru64 */ > +#ifdef __osf > + /* Tru64 but we also want to allow "passwordless" accounts */ > + (passwd[0] == '*' && strcmp(passwd, "*NP*") != 0) || > +#endif > + passwd[0] == '!')) { /* Redhat */ > log("User %.100s not allowed because account is locked", > pw->pw_name); > return 0; i just wonder if we really want to attempt all these checks. if you lock a user's password but leave the authorized_keys file permitting access is the account locked? there's a split in opinion on that i think. also, it may be simpler to check for strlen(passwd) < 13, as it may be safe to always consider that an invalid password. maybe. From leakin at japh.itg.ti.com Mon Jan 13 06:11:54 2003 From: leakin at japh.itg.ti.com (Lee Eakin) Date: Sun, 12 Jan 2003 13:11:54 -0600 Subject: Test for locked account in auth.c (bug #442). In-Reply-To: <20030112181429.GB4292@scott.crlsca.adelphia.net> References: <3E1AB39B.463D1531@zip.com.au> <3E1AB7BE.3030104@mindrot.org> <3E1ABD63.CDCEC09F@zip.com.au> <3E1BF9A9.D7CE8DE9@zip.com.au> <3E1C05B4.BF16C9B0@zip.com.au> <3E20CD75.80E8DA1@zip.com.au> <3E214AA8.A7809BE7@zip.com.au> <20030112181429.GB4292@scott.crlsca.adelphia.net> Message-ID: <20030112191153.GA14293@japh.itg.ti.com> > From: Kevin Steves > On Sun, Jan 12, 2003 at 09:59:52PM +1100, Darren Tucker wrote: > > /* check for locked account */ > > - if (strcmp(passwd, "*LK*") == 0 || passwd[0] == '!') { > > + if (passwd && (strcmp(passwd, "*LK*") == 0 || /* Solaris,IRIX */ > > + strcmp(passwd, "*") == 0 || /* HP-UX,Tru64 */ > > + strstr(passwd, "Nologin") || /* Tru64 */ > > +#ifdef __osf > > + /* Tru64 but we also want to allow "passwordless" accounts */ > > + (passwd[0] == '*' && strcmp(passwd, "*NP*") != 0) || > > +#endif > > + passwd[0] == '!')) { /* Redhat */ > > log("User %.100s not allowed because account is locked", > > pw->pw_name); > > return 0; > > i just wonder if we really want to attempt all these checks. if you > lock a user's password but leave the authorized_keys file permitting > access is the account locked? there's a split in opinion on that i > think. > > also, it may be simpler to check for strlen(passwd) < 13, as it may be > safe to always consider that an invalid password. maybe. If we simplify to the point of 'strlen(passwd) < 13' then we would need a sshd_config option to revert to current behavior (allowing shell of /bin/false or similar to disable). I have many key-only accounts in combination with command= and other key restrictions for security reasons. It allows me to set up special purpose accounts only accessible thru ssh. Of course, now that I think about it, defining a password of '*' * 13 or similar might be a workaround, but I don't know if that might cause strange behavior in other programs? -- Lee Eakin - leakin at ti.com - Internet/Naming Services, Texas Instruments LAWS OF COMPUTER PROGRAMMING: III. If a program is useful, it will have to be changed. From mouring at etoh.eviladmin.org Mon Jan 13 01:50:01 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sun, 12 Jan 2003 08:50:01 -0600 (CST) Subject: Test for locked account in auth.c (bug #442). In-Reply-To: <20030112181429.GB4292@scott.crlsca.adelphia.net> Message-ID: On Sun, 12 Jan 2003, Kevin Steves wrote: > On Sun, Jan 12, 2003 at 09:59:52PM +1100, Darren Tucker wrote: > > /* check for locked account */ > > - if (strcmp(passwd, "*LK*") == 0 || passwd[0] == '!') { > > + if (passwd && (strcmp(passwd, "*LK*") == 0 || /* Solaris,IRIX */ > > + strcmp(passwd, "*") == 0 || /* HP-UX,Tru64 */ > > + strstr(passwd, "Nologin") || /* Tru64 */ > > +#ifdef __osf > > + /* Tru64 but we also want to allow "passwordless" accounts */ > > + (passwd[0] == '*' && strcmp(passwd, "*NP*") != 0) || > > +#endif > > + passwd[0] == '!')) { /* Redhat */ > > log("User %.100s not allowed because account is locked", > > pw->pw_name); > > return 0; > > i just wonder if we really want to attempt all these checks. if you > lock a user's password but leave the authorized_keys file permitting > access is the account locked? there's a split in opinion on that i > think. > > also, it may be simpler to check for strlen(passwd) < 13, as it may be > safe to always consider that an invalid password. maybe. > Is blowfish, md5, etc all the same length hash? And are we going to have the same issues knowing when to use the correct size for locking the password? - Ben From defa at tyrell.s.bawue.de.com Mon Jan 13 09:11:58 2003 From: defa at tyrell.s.bawue.de.com (kiani ) Date: Sun, 12 Jan 2003 22:11:58 GMT Subject: Increase Size Message-ID: 100% Money Back Guarantee! Permanent Larger Erections http://www.shaggweb.com/enlargement/index.html From djm at mindrot.org Mon Jan 13 09:39:43 2003 From: djm at mindrot.org (Damien Miller) Date: Mon, 13 Jan 2003 09:39:43 +1100 Subject: Test for locked account in auth.c (bug #442). In-Reply-To: <20030112181429.GB4292@scott.crlsca.adelphia.net> References: <3E1AB39B.463D1531@zip.com.au> <3E1AB7BE.3030104@mindrot.org> <3E1ABD63.CDCEC09F@zip.com.au> <3E1BF9A9.D7CE8DE9@zip.com.au> <3E1C05B4.BF16C9B0@zip.com.au> <3E20CD75.80E8DA1@zip.com.au> <3E214AA8.A7809BE7@zip.com.au> <20030112181429.GB4292@scott.crlsca.adelphia.net> Message-ID: <3E21EEAF.1090805@mindrot.org> Kevin Steves wrote: > i just wonder if we really want to attempt all these checks. if you > lock a user's password but leave the authorized_keys file permitting > access is the account locked? there's a split in opinion on that i > think. I am beginning to agree - the change is much less attractive now than when I merged it. This change also moves us away from the OpenBSD behaviour, which is something we shouldn't do. -d From bugzilla-daemon at mindrot.org Mon Jan 13 10:07:17 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 Jan 2003 10:07:17 +1100 (EST) Subject: [Bug 236] No setproctitle() replacement for many unices Message-ID: <20030112230717.398596454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=236 ------- Additional Comments From djm at mindrot.org 2003-01-13 10:07 ------- The original source said to use argv clobbering for Solaris, but that didn't seem to work (see Comment #3) so I just disabled it. I have moved all the platform selection to configure.ac - it is a better place for it. If you don't define a SETPROCTITLE_STRATEGY (and optionally a SETPROCTITLE_PS_PADDING), it will switch off setproctitle emulation. ------- 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 Jan 13 16:55:46 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 Jan 2003 16:55:46 +1100 (EST) Subject: [Bug 467] Feature request: --disable-strip Message-ID: <20030113055546.D567C6454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=467 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-13 16:55 ------- Applied - thanks ------- 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 Jan 13 20:59:17 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 13 Jan 2003 20:59:17 +1100 Subject: Test for locked account in auth.c (bug #442). References: <3E1AB39B.463D1531@zip.com.au> <3E1AB7BE.3030104@mindrot.org> <3E1ABD63.CDCEC09F@zip.com.au> <3E1BF9A9.D7CE8DE9@zip.com.au> <3E1C05B4.BF16C9B0@zip.com.au> <3E20CD75.80E8DA1@zip.com.au> <3E214AA8.A7809BE7@zip.com.au> <20030112181429.GB4292@scott.crlsca.adelphia.net> <3E21EEAF.1090805@mindrot.org> Message-ID: <3E228DF5.69E008E6@zip.com.au> Lee Eakin wrote: > If we simplify to the point of 'strlen(passwd) < 13' That is precisely what I was trying to avoid as it would stop valid use of public-key only authentication via existing no-password strings (eg "NP" on Solaris). Damien Miller wrote: > Kevin Steves wrote: > > i just wonder if we really want to attempt all these checks. if you > > lock a user's password but leave the authorized_keys file permitting > > access is the account locked? there's a split in opinion on that i > > think. That's the crux of the issue. I recently had to disable an account (normally we just delete 'em) and I realized that sshd would probably still allow public-key auth. I had to check the code to be sure, hence the bug and patch. Anyway, here's what a few man pages say about locking accounts: Redhat passwd -l "This option is used to lock the specified account" Solaris passwd -l "Locks password entry for name." Solaris shadow passwd entry "a lock string to indicate that the login is not accessible" HP-UX passwd -l "Lock user account" AIX chuser account_locked=yes "Indicates if the user account is locked." Actually, the AIX example is irrelevant for the code being discussed since it will be enforced by loginrestrictions(), it's just included for comparison. Depending on which platform and which man page you read, you might reasonably expect that the account will be rendered unusable even via public-key authentication. > I am beginning to agree - the change is much less attractive now than > when I merged it. This change also moves us away from the OpenBSD > behaviour, which is something we shouldn't do. OpenBSD doesn't have a concept of a "locked account", does it? (I couldn't find one in the man pages, anyway.) I think the code can be made less ugly by moving the checks into a separate function (see attached patch). The question is: should it be, or should it be backed out? -Daz. -- 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: /cvs/openssh/auth.c,v retrieving revision 1.66 diff -u -r1.66 auth.c --- auth.c 9 Jan 2003 04:04:28 -0000 1.66 +++ auth.c 13 Jan 2003 08:44:10 -0000 @@ -60,6 +60,38 @@ int auth_debug_init; /* + * check for locked account + */ +int +locked_account(const char * passwd) +{ + /* Solaris, IRIX */ + if (strcmp(passwd, "*LK*") == 0) + return 1; + + /* HP-UX, Tru64 */ + if (strcmp(passwd, "*") == 0) + return 1; + + /* Redhat */ + if (passwd[0] == '!' && passwd[1] == '!') + return 1; + +#ifdef __osf + /* Tru64 */ + if (strstr(passwd, "Nologin")) + return 1; + + /* we also want to allow "passwordless" accounts */ + if (passwd[0] == '*' && strcmp(passwd, "*NP*") != 0) + return 1; +#endif + + /* found no reason to think account is locked */ + return 0; +} + +/* * Check if the user is allowed to log in via ssh. If user is listed * in DenyUsers or one of user's groups is listed in DenyGroups, false * will be returned. If AllowUsers isn't empty and user isn't listed @@ -72,7 +104,7 @@ allowed_user(struct passwd * pw) { struct stat st; - const char *hostname = NULL, *ipaddr = NULL, *passwd; + const char *hostname = NULL, *ipaddr = NULL, *passwd = NULL; char *shell; int i; #ifdef WITH_AIXAUTHENTICATE @@ -92,15 +124,14 @@ /* Grab the password for locked account checking */ #if defined(HAVE_SHADOW_H) && !defined(DISABLE_SHADOW) spw = getspnam(pw->pw_name); - if (!spw) - return 0; - passwd = spw->sp_pwdp; + if (spw) + passwd = spw->sp_pwdp; #else passwd = pw->pw_passwd; #endif /* check for locked account */ - if (strcmp(passwd, "*LK*") == 0 || passwd[0] == '!') { + if (passwd && locked_account(passwd)) { log("User %.100s not allowed because account is locked", pw->pw_name); return 0; @@ -109,31 +140,33 @@ #if !defined(USE_PAM) && defined(HAVE_SHADOW_H) && \ !defined(DISABLE_SHADOW) && defined(HAS_SHADOW_EXPIRE) #define DAY (24L * 60 * 60) /* 1 day in seconds */ - today = time(NULL) / DAY; - debug3("allowed_user: today %d sp_expire %d sp_lstchg %d" - " sp_max %d", (int)today, (int)spw->sp_expire, - (int)spw->sp_lstchg, (int)spw->sp_max); - - /* - * We assume account and password expiration occurs the - * day after the day specified. - */ - if (spw->sp_expire != -1 && today > spw->sp_expire) { - log("Account %.100s has expired", pw->pw_name); - return 0; - } - - if (spw->sp_lstchg == 0) { - log("User %.100s password has expired (root forced)", - pw->pw_name); - return 0; - } - - if (spw->sp_max != -1 && - today > spw->sp_lstchg + spw->sp_max) { - log("User %.100s password has expired (password aged)", - pw->pw_name); - return 0; + if (spw) { + today = time(NULL) / DAY; + debug3("allowed_user: today %d sp_expire %d sp_lstchg %d" + " sp_max %d", (int)today, (int)spw->sp_expire, + (int)spw->sp_lstchg, (int)spw->sp_max); + + /* + * We assume account and password expiration occurs the + * day after the day specified. + */ + if (spw->sp_expire != -1 && today > spw->sp_expire) { + log("Account %.100s has expired", pw->pw_name); + return 0; + } + + if (spw->sp_lstchg == 0) { + log("User %.100s password has expired (root forced)", + pw->pw_name); + return 0; + } + + if (spw->sp_max != -1 && + today > spw->sp_lstchg + spw->sp_max) { + log("User %.100s password has expired (password aged)", + pw->pw_name); + return 0; + } } #endif Index: sshd.8 =================================================================== RCS file: /cvs/openssh/sshd.8,v retrieving revision 1.150 diff -u -r1.150 sshd.8 --- sshd.8 25 Sep 2002 02:20:54 -0000 1.150 +++ sshd.8 13 Jan 2003 08:44:11 -0000 @@ -112,6 +112,30 @@ authentication, RSA challenge-response authentication, or password based authentication. .Pp +Regardless of the authentication type, the account is checked to +ensure that it is accessible. An account is not accessible if it is +locked, listed in +.Cm DenyUsers +or its group is listed in +.Cm DenyGroups +\&. An account is considered locked if the passwd entry equals +.Ql \&*LK\&* +or +.Ql \&* +, contains the string +.Ql Nologin +, or has a leading +.Ql \&! +(or, on Tru64, a +.Ql \&* +) character. If there is a requirement to disable password authentication +for the account while allowing still public-key, then the passwd field +should be set to something other than these values (eg +.Ql NP +or +.Ql \&*NP\&* +). +.Pp Rhosts authentication is normally disabled because it is fundamentally insecure, but can be enabled in the server configuration file if desired. From bugzilla-daemon at mindrot.org Mon Jan 13 21:15:21 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 Jan 2003 21:15:21 +1100 (EST) Subject: [Bug 236] No setproctitle() replacement for many unices Message-ID: <20030113101521.C0C716454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=236 ------- Additional Comments From dtucker at zip.com.au 2003-01-13 21:15 ------- Further info on Solaris: /usr/bin/ps apparently won't display the modified arguments while /usr/ucb/ps will. I knew they were different but I didn't know about that particular difference. I haven't been able to get it working on Solaris after adding "#define SETPROCTITLE_STRATEGY PS_USE_CLOBBER_ARGV" (it core dumps) but I suspect I'm doing something dumb. ------- 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 Jan 13 21:58:51 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 Jan 2003 21:58:51 +1100 (EST) Subject: [Bug 466] stfp cmds[] array conflicts with libc Message-ID: <20030113105851.02C446454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=466 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-13 21:58 ------- 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 Jan 13 22:00:22 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 Jan 2003 22:00:22 +1100 (EST) Subject: [Bug 236] No setproctitle() replacement for many unices Message-ID: <20030113110022.5A9186454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=236 ------- Additional Comments From djm at mindrot.org 2003-01-13 22:00 ------- You might want to set SETPROCTITLE_PS_PADDING as well (see the linux section in configure.ac). I suggest that you file a new bug for Solaris, so we can stop flogging this one :) ------- 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 Jan 13 22:20:19 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 Jan 2003 22:20:19 +1100 (EST) Subject: [Bug 236] No setproctitle() replacement for many unices Message-ID: <20030113112019.F0C6864555@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=236 ------- Additional Comments From dtucker at zip.com.au 2003-01-13 22:20 ------- I tried both ' ' and '\0' but didn't want to clutter this bug. I'll file a new bug when I'm convinced I'm not doing something wrong (I've had *really* strange problems since upgrading to openssl-0.9.7 which I'm still trying to figure out). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From ajith at noida.hcltech.com Mon Jan 13 23:05:27 2003 From: ajith at noida.hcltech.com (Ajit Yashwant Vaishampayan, Noida) Date: Mon, 13 Jan 2003 17:35:27 +0530 Subject: SX-6 port of openssh, configure problems Message-ID: When we were porting OpenSSH on SX, we had similar problem. And when we did #undef HAVE_B64_NTOP in config.h, we faced linking problem as b64_pton() multiply defined, in base64.c and in libc.a. So we modified configure to check both the functions b64_pton() and b64_ntop(). But we gave priority to native function if available. Following are the diffs of three files we changed 1. configure (line modified) 5949c5949 < for ac_func in arc4random atexit b64_ntop bcopy bindresvport_sa \ --- > for ac_func in arc4random atexit b64_ntop b64_pton bcopy bindresvport_sa \ 2. config.h.in (Following lines added) 337a337,339 > > /* Define if you have the `b64_pton' function. */ > #undef HAVE_B64_PTON 3. openbsd-compat/base64.c (Used the HAVE_B64_PTON in this file) 47c47 < #if !defined(HAVE_B64_NTOP) && !defined(HAVE___B64_NTOP) --- > #if (!defined(HAVE_B64_NTOP) && !defined(HAVE___B64_NTOP)) || !defined(HAVE_B64_PTON) 131a132 > #if !defined(HAVE_B64_NTOP) && !defined(HAVE___B64_NTOP) 197a199 > #endif /* !defined(HAVE_B64_NTOP) && !defined(HAVE___B64_NTOP) */ 198a201 > #if !defined(HAVE_B64_PTON) 314a318 > #endif /*!defined(HAVE_B64_PTON)*/ 316c320 < #endif /* !defined(HAVE_B64_NTOP) && !defined(HAVE___B64_NTOP) */ --- > #endif /*(!defined(HAVE_B64_NTOP) && !defined(HAVE___B64_NTOP)) || !defined(HAVE_B64_PTON)*/ Hope this will be useful. Regards, Ajit -----Original Message----- From: Wendy Palm [mailto:wendyp at cray.com] Sent: Saturday, January 11, 2003 4:14 AM To: Jim Knoble Cc: OpenSSH Development Subject: Re: SX-6 port of openssh, configure problems yes, openbsd-compat/base64.c uses #if !defined(HAVE_B64_NTOP) && !defined(HAVE___B64_NTOP) to define both b64_ntop() and b64_pton() functions. i'll write up the patches to check for both functions. hmm, should we use a native function if it exists, whether or not the other does? (i.e. in this case, should we use native b64_ntop()?) Jim Knoble wrote: > Circa 2003-01-10 16:04:47 -0600 dixit Wendy Palm: > > : i found that the b64_ntop function truly does exist (libc.a) > : but b64_pton truly doesn't. > > Is there a replacement function in the OpenSSH tree? If so, it sounds > to me as if configure ought to look for both of them, and not use > either function unless both are present natively---otherwise, use the > replacement functions. > > -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From mouring at etoh.eviladmin.org Mon Jan 13 19:55:18 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 13 Jan 2003 02:55:18 -0600 (CST) Subject: Test for locked account in auth.c (bug #442). In-Reply-To: <3E228DF5.69E008E6@zip.com.au> Message-ID: On Mon, 13 Jan 2003, Darren Tucker wrote: > Lee Eakin wrote: > > If we simplify to the point of 'strlen(passwd) < 13' > > That is precisely what I was trying to avoid as it would stop valid use > of public-key only authentication via existing no-password strings (eg > "NP" on Solaris). > > Damien Miller wrote: > > Kevin Steves wrote: > > > i just wonder if we really want to attempt all these checks. if you > > > lock a user's password but leave the authorized_keys file permitting > > > access is the account locked? there's a split in opinion on that i > > > think. > > That's the crux of the issue. I recently had to disable an account > (normally we just delete 'em) and I realized that sshd would probably > still allow public-key auth. I had to check the code to be sure, hence > the bug and patch. > I think password disabling via expired passwords would be a better way. OpenBSD by default supports this behavior so it is consistant and I know shadow and PAM systems support it. - Ben From dtucker at zip.com.au Tue Jan 14 09:25:25 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 14 Jan 2003 09:25:25 +1100 Subject: Test for locked account in auth.c (bug #442). References: Message-ID: <3E233CD5.818EFC06@zip.com.au> Ben Lindstrom wrote: > On Mon, 13 Jan 2003, Darren Tucker wrote: > > Damien Miller wrote: > > > Kevin Steves wrote: > > > > i just wonder if we really want to attempt all these checks. if you > > > > lock a user's password but leave the authorized_keys file permitting > > > > access is the account locked? there's a split in opinion on that i > > > > think. > > > > That's the crux of the issue. I recently had to disable an account > > (normally we just delete 'em) and I realized that sshd would probably > > still allow public-key auth. I had to check the code to be sure, hence > > the bug and patch. > > I think password disabling via expired passwords would be a better way. > OpenBSD by default supports this behavior so it is consistant and I know > shadow and PAM systems support it. You mean account disabling via expired account? If you use an expired password to lock an account you won't be able to use password expiry for, well, making people change their passwords. Some platforms (eg HP-UX in non-trusted mode) have a concept of locked accounts but don't have password aging or account expiry. It boils down to "does passwd -l lock the account or the password?" From the man pages I've checked the ratio is 2 (account) to 1 (password). So you can default to allowing locked entries (permissive by default) or not allowing them (secure by default[0]). Martin MOKREJ? has kindly supplied some info about Tru64's -lauthenticate functions so we could drop the ugliest Tru64 cases and have another section at the end of allowed_user() like WITH_AIXAUTHENTICATE. Then it would look something like int allowed_user(... /* check for locked account * "*LK*" Solaris, IRIX * "*" HP-UX, Tru64 * leading "!" Redhat */ if (passwd && (strcmp(passwd, "*LK*") == 0 || strcmp(passwd, "*") == 0 || passwd[0] == '!')) { log("User %.100s not allowed because account is locked", pw->pw_name); return 0; } [0] Hey, they almost sounds like a motto. -- 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 Tue Jan 14 04:22:24 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 13 Jan 2003 11:22:24 -0600 (CST) Subject: Test for locked account in auth.c (bug #442). In-Reply-To: <3E233CD5.818EFC06@zip.com.au> Message-ID: On Tue, 14 Jan 2003, Darren Tucker wrote: > Ben Lindstrom wrote: > > On Mon, 13 Jan 2003, Darren Tucker wrote: > > > Damien Miller wrote: > > > > Kevin Steves wrote: > > > > > i just wonder if we really want to attempt all these checks. if you > > > > > lock a user's password but leave the authorized_keys file permitting > > > > > access is the account locked? there's a split in opinion on that i > > > > > think. > > > > > > That's the crux of the issue. I recently had to disable an account > > > (normally we just delete 'em) and I realized that sshd would probably > > > still allow public-key auth. I had to check the code to be sure, hence > > > the bug and patch. > > > > I think password disabling via expired passwords would be a better way. > > OpenBSD by default supports this behavior so it is consistant and I know > > shadow and PAM systems support it. > > You mean account disabling via expired account? If you use an expired > password to lock an account you won't be able to use password expiry > for, well, making people change their passwords. > Password expiring should have two settings (works under OpenBSD with a few hacks). Expired by still valid account, and expired and locked. The latter normally is set by saying 'person has not changed their password for 4 days. Therefor the account is now locked until the admin unlocks it'. So locking an account is just setting the expiried beyond the latter date. > Some platforms (eg HP-UX in non-trusted mode) have a concept of locked > accounts but don't have password aging or account expiry. > > It boils down to "does passwd -l lock the account or the password?" From > the man pages I've checked the ratio is 2 (account) to 1 (password). > > So you can default to allowing locked entries (permissive by default) or > not allowing them (secure by default[0]). > > Martin MOKREJ? has kindly supplied some info about Tru64's > -lauthenticate functions so we could drop the ugliest Tru64 cases and > have another section at the end of allowed_user() like > WITH_AIXAUTHENTICATE. Then it would look something like > > int allowed_user(... > /* check for locked account > * "*LK*" Solaris, IRIX > * "*" HP-UX, Tru64 > * leading "!" Redhat > */ > if (passwd && (strcmp(passwd, "*LK*") == 0 || > strcmp(passwd, "*") == 0 || passwd[0] == '!')) { > log("User %.100s not allowed because account is locked", > pw->pw_name); > return 0; > } > > > [0] Hey, they almost sounds like a motto. > Still the question is we don't current support such code in OpenBSD tree. Which is a change in how the application works. NetBSD/FreeBSD/OpenBSD does not support 'passwd -l' style locking. It is just an expiration vs valid password test. I can't track down my BSD/OS contact (she is more than likely held up doing kernel stuff) so I don't know of BSD/OS is the same way. - Ben From djm at mindrot.org Tue Jan 14 10:55:33 2003 From: djm at mindrot.org (Damien Miller) Date: Tue, 14 Jan 2003 10:55:33 +1100 Subject: Test for locked account in auth.c (bug #442). In-Reply-To: <3E233CD5.818EFC06@zip.com.au> References: <3E233CD5.818EFC06@zip.com.au> Message-ID: <3E2351F5.8050603@mindrot.org> Darren Tucker wrote: >>I think password disabling via expired passwords would be a better way. >>OpenBSD by default supports this behavior so it is consistant and I know >>shadow and PAM systems support it. > > You mean account disabling via expired account? If you use an expired > password to lock an account you won't be able to use password expiry > for, well, making people change their passwords. I think Ben means the shadow sp_expire field, which I understand means "account expiry" rather than "password expiry". This would be IMO a nicer way of doing things. > Some platforms (eg HP-UX in non-trusted mode) have a concept of locked > accounts but don't have password aging or account expiry. > > It boils down to "does passwd -l lock the account or the password?" From > the man pages I've checked the ratio is 2 (account) to 1 (password). > > So you can default to allowing locked entries (permissive by default) or > not allowing them (secure by default[0]). That argument would carry more weight for me, but for the fact that (AFAIK) SSH has never honored locked passwords as locking pubkey access. This could lead to a whole lot of people who have used locked accounts + pubkey access suddenly finding that they can no longer access their systems post-upgrade. The way out of that would be to add a preference to determine the behaviour - but I don't want to add more portable-specific options (In fact I want to get rid of the one that is there). > Martin MOKREJ? has kindly supplied some info about Tru64's > -lauthenticate functions so we could drop the ugliest Tru64 cases and > have another section at the end of allowed_user() like > WITH_AIXAUTHENTICATE. Then it would look something like Shouldn't this be done for Tru64 using SIA anyway? -d From stevesk at pobox.com Tue Jan 14 13:08:55 2003 From: stevesk at pobox.com (Kevin Steves) Date: Mon, 13 Jan 2003 18:08:55 -0800 Subject: Test for locked account in auth.c (bug #442). In-Reply-To: <3E228DF5.69E008E6@zip.com.au> References: <3E1ABD63.CDCEC09F@zip.com.au> <3E1BF9A9.D7CE8DE9@zip.com.au> <3E1C05B4.BF16C9B0@zip.com.au> <3E20CD75.80E8DA1@zip.com.au> <3E214AA8.A7809BE7@zip.com.au> <20030112181429.GB4292@scott.crlsca.adelphia.net> <3E21EEAF.1090805@mindrot.org> <3E228DF5.69E008E6@zip.com.au> Message-ID: <20030114020855.GC13122@scott.crlsca.adelphia.net> On Mon, Jan 13, 2003 at 08:59:17PM +1100, Darren Tucker wrote: > > If we simplify to the point of 'strlen(passwd) < 13' > > That is precisely what I was trying to avoid as it would stop valid use > of public-key only authentication via existing no-password strings (eg > "NP" on Solaris). ah, i somehow missed that. i'm not sure that differentiation is worth the effort. in the solaris case, ``passwd -sa'' displays both cases as ``LK''. From cmadams at hiwaay.net Tue Jan 14 13:16:35 2003 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 13 Jan 2003 20:16:35 -0600 Subject: Test for locked account in auth.c (bug #442). In-Reply-To: <3E2351F5.8050603@mindrot.org>; from djm@mindrot.org on Tue, Jan 14, 2003 at 10:55:33AM +1100 References: <3E233CD5.818EFC06@zip.com.au> <3E2351F5.8050603@mindrot.org> Message-ID: <20030113201635.E504466@hiwaay.net> Once upon a time, Damien Miller said: > > Martin MOKREJ? has kindly supplied some info about Tru64's > > -lauthenticate functions so we could drop the ugliest Tru64 cases and > > have another section at the end of allowed_user() like > > WITH_AIXAUTHENTICATE. Then it would look something like > > Shouldn't this be done for Tru64 using SIA anyway? Yup, and it already does (although I've only tested enhanced security mode; I don't think basic security mode has a "lock" function). In enhanced security mode, the sia_ses_estab() call will fail for an account with "administrative_lock_applied=1". -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From stevesk at pobox.com Tue Jan 14 13:22:17 2003 From: stevesk at pobox.com (Kevin Steves) Date: Mon, 13 Jan 2003 18:22:17 -0800 Subject: Test for locked account in auth.c (bug #442). In-Reply-To: <3E233CD5.818EFC06@zip.com.au> References: <3E233CD5.818EFC06@zip.com.au> Message-ID: <20030114022217.GD13122@scott.crlsca.adelphia.net> On Tue, Jan 14, 2003 at 09:25:25AM +1100, Darren Tucker wrote: > Some platforms (eg HP-UX in non-trusted mode) have a concept of locked > accounts but don't have password aging or account expiry. HP-UX actually does support password aging via the old-style aging field (after a comma in the encrypted password field). at least up-to 11.11. > It boils down to "does passwd -l lock the account or the password?" From > the man pages I've checked the ratio is 2 (account) to 1 (password). > > So you can default to allowing locked entries (permissive by default) or > not allowing them (secure by default[0]). that is the core issue. From big at boss.com Mon Jan 13 18:29:47 2003 From: big at boss.com (big at boss.com) Date: Mon, 13 Jan 2003 18:29:47 --0800 Subject: Here is that sample Message-ID: <20030114022345.C7B5A64552@shitei.mindrot.org> Attached file: From Darren.Moffat at Sun.COM Tue Jan 14 15:34:51 2003 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Mon, 13 Jan 2003 20:34:51 -0800 (PST) Subject: Test for locked account in auth.c (bug #442).Z In-Reply-To: <20030114020855.GC13122@scott.crlsca.adelphia.net> Message-ID: On Mon, 13 Jan 2003, Kevin Steves wrote: > On Mon, Jan 13, 2003 at 08:59:17PM +1100, Darren Tucker wrote: > > > If we simplify to the point of 'strlen(passwd) < 13' > > > > That is precisely what I was trying to avoid as it would stop valid use > > of public-key only authentication via existing no-password strings (eg > > "NP" on Solaris). > > ah, i somehow missed that. i'm not sure that differentiation is worth > the effort. in the solaris case, ``passwd -sa'' displays both cases > as ``LK''. That is because the code for passwd -sa uses strlen(passwd) < 13 as the check. IMO that is a bug in passwd -sa output, in fact I've been trying to find the time to fix this in passwd but haven't yet come up with a better algorithm. As many people have noticed Solaris replaces the password with *LK* when running passwd -l. However the default /etc/shadow file has some accounts with "NP" meaning no password. There is another special string which is "*NP*", the only way you get this is if you are running NIS+ with very strick passwd.org_dir table permissions, such that you require the user to first authenticate with the AUTH_DH RPC keys (if that fails you get back "*NP*". -- Darren J Moffat From dtucker at zip.com.au Tue Jan 14 18:10:21 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 14 Jan 2003 18:10:21 +1100 Subject: Test for locked account in auth.c (bug #442). References: <3E233CD5.818EFC06@zip.com.au> <20030114022217.GD13122@scott.crlsca.adelphia.net> Message-ID: <3E23B7DD.FFB2E88@zip.com.au> Kevin Steves wrote: > On Tue, Jan 14, 2003 at 09:25:25AM +1100, Darren Tucker wrote: > > Some platforms (eg HP-UX in non-trusted mode) have a concept of locked > > accounts but don't have password aging or account expiry. > > HP-UX actually does support password aging via the old-style aging > field (after a comma in the encrypted password field). I didn't know that and I stand corrected on password aging. I think the statement about account expiry is still correct (and I re-read "man 4 passwd" before posting this) but I'm prepared to be corrected again :-) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Tue Jan 14 18:13:34 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 14 Jan 2003 18:13:34 +1100 Subject: Test for locked account in auth.c (bug #442). References: <3E233CD5.818EFC06@zip.com.au> <3E2351F5.8050603@mindrot.org> Message-ID: <3E23B89E.94791013@zip.com.au> Damien Miller wrote: > Darren Tucker wrote: > I think Ben means the shadow sp_expire field, which I understand means > "account expiry" rather than "password expiry". This would be IMO a > nicer way of doing things. Assuming it has one and ignoring the platform's native account lock? > > It boils down to "does passwd -l lock the account or the password?" From > > the man pages I've checked the ratio is 2 (account) to 1 (password). > > > > So you can default to allowing locked entries (permissive by default) or > > not allowing them (secure by default[0]). > > That argument would carry more weight for me, but for the fact that > (AFAIK) SSH has never honored locked passwords as locking pubkey access. If you s/passwords/accounts/ (see previous messages about how the man pages describe what we're talking about), and consider the fact some platforms use the password field as a platform-specific implementation detail: * openssh has on AIX since at least 2.2.0p1 via the loginrestrictions() function. * ssh-1.2.33 does for AIX, Trusted HP-UX and anything with a password string equal to "*LK*". I don't know about later versions. > This could lead to a whole lot of people who have used locked accounts + > pubkey access suddenly finding that they can no longer access their > systems post-upgrade. > > The way out of that would be to add a preference to determine the > behaviour - but I don't want to add more portable-specific options (In > fact I want to get rid of the one that is there). Agreed, I'd rather see it backed out than clutter sshd_config further, but I still think denying the login is the right thing to do. > > Martin MOKREJ? has kindly supplied some info about Tru64's > > -lauthenticate functions so we could drop the ugliest Tru64 cases and > > have another section at the end of allowed_user() like > > WITH_AIXAUTHENTICATE. Then it would look something like > > Shouldn't this be done for Tru64 using SIA anyway? Maybe, I'm not sure. I haven't used Tru64 since it was called OSF/1. (That should be -lsecurity, BTW). -- 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 Tue Jan 14 23:26:22 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 14 Jan 2003 23:26:22 +1100 (EST) Subject: [Bug 14] Can't change expired /etc/shadow password without PAM Message-ID: <20030114122622.AADD864555@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=14 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #201 is|0 |1 obsolete| | ------- Additional Comments From dtucker at zip.com.au 2003-01-14 23:26 ------- Created an attachment (id=205) --> (http://bugzilla.mindrot.org/attachment.cgi?id=205&action=view) passexpire13: add support for comma-in-passwd expiry This patch against the cvs tree adds support for comma-in-password-type password expiry, in addition to AIX and /etc/shadow support. This requires pw_age in struct passwd and includes a configure test for this. Also include cosmetic changes (eg "1 days left" -> "1 day left"). Tested on HP-UX 11.00 non-trusted config. It should be possible to support trusted config without PAM via getprpwnam and friends, but this has not been written yet. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at mindrot.org Wed Jan 15 07:02:08 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 15 Jan 2003 07:02:08 +1100 (EST) Subject: [Bug 468] New: 3.5p1 authentication error on Solaris 8 Message-ID: <20030114200208.548BB6454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=468 Summary: 3.5p1 authentication error on Solaris 8 Product: Portable OpenSSH Version: 3.5p1 Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: cbar44 at tsg.cbot.com OpenSSH 3.5p1 conflicts with the Solaris 8 cron patch 109007-08. Installing -08 generates the authenication error when doing a cron command: ld.so.1: crontab: fatal: relocation error: file crontab: symbol audit_crontab_not_allowed: referenced symbol not found Killed The Sun engineer I spoke with believes that this is an authentication/auditing mismatch between OpenSsh and Sun. Backing the patch down to rev -07 fixes the issue temporarily. ------- 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 Jan 15 07:36:24 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 15 Jan 2003 07:36:24 +1100 (EST) Subject: [Bug 468] 3.5p1 authentication error on Solaris 8 Message-ID: <20030114203624.84DD76454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=468 ------- Additional Comments From wknox at mitre.org 2003-01-15 07:36 ------- I'm not seeing this behavior on my Solaris 8 systems - latest patch cluster (1/8/03), including patch 109007-08. ------- 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 Jan 15 07:58:45 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 15 Jan 2003 07:58:45 +1100 (EST) Subject: [Bug 468] 3.5p1 authentication error on Solaris 8 Message-ID: <20030114205845.0B44F6454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=468 ------- Additional Comments From cbar44 at tsg.cbot.com 2003-01-15 07:58 ------- On both a SS5 andd a V880. both running Solaris 8, with patch 109007-07, crontab -l is just fine. With patch 109007-08, crontab -l returns ld.so.1: crontab: fatal: relocation error: file crontab: symbol audit_crontab_not_allowed: referenced symbol not found Killed What version of SSH are you running? What platform are you running? I only have the sun engineer's word that this is even related to 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 Jan 15 08:07:58 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 15 Jan 2003 08:07:58 +1100 (EST) Subject: [Bug 468] 3.5p1 authentication error on Solaris 8 Message-ID: <20030114210758.3354664552@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=468 ------- Additional Comments From wknox at mitre.org 2003-01-15 08:07 ------- Multiple platforms (all sun4u, including a V880) and OpenSSH 3.5p1 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From VBrimhall at novell.com Wed Jan 15 08:46:48 2003 From: VBrimhall at novell.com (Vince Brimhall) Date: Tue, 14 Jan 2003 14:46:48 -0700 Subject: Use of OpenSSH name? Message-ID: I recently completed porting OpenSSH 3.5p1 for inclusion in the next major release of NetWare. When refering to the OpenSSH product in documentation and during installation, Novell would like to use the name "OpenSSH on NetWare". I could not find any reference on www.openssh.com concerning the use of the OpenSSH name when included with base OS installations. I am looking to see if there are any restrictions when using the OpenSSH name and if so where I can find a description of those limitations. Any assistance in this matter is greatly appreciated. Vince Brimhall Novell, Inc. 1800 Novell Place Provo, UT 84606 801-861-1724 vbrimhall at novell.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030114/858cd345/attachment.html From bugzilla-daemon at mindrot.org Wed Jan 15 10:18:30 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 15 Jan 2003 10:18:30 +1100 (EST) Subject: [Bug 468] 3.5p1 authentication error on Solaris 8 Message-ID: <20030114231830.295016454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=468 ------- Additional Comments From djm at mindrot.org 2003-01-15 10:18 ------- How is OpenSSH involved here? Do you get the error when logging in from the console? This looks like a shared library issue which has nothing to do with OpenSSH. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From stevesk at pobox.com Wed Jan 15 15:41:14 2003 From: stevesk at pobox.com (Kevin Steves) Date: Tue, 14 Jan 2003 20:41:14 -0800 Subject: Test for locked account in auth.c (bug #442). In-Reply-To: <3E23B7DD.FFB2E88@zip.com.au> References: <3E233CD5.818EFC06@zip.com.au> <20030114022217.GD13122@scott.crlsca.adelphia.net> <3E23B7DD.FFB2E88@zip.com.au> Message-ID: <20030115044114.GB13606@scott.crlsca.adelphia.net> On Tue, Jan 14, 2003 at 06:10:21PM +1100, Darren Tucker wrote: > Kevin Steves wrote: > > HP-UX actually does support password aging via the old-style aging > > field (after a comma in the encrypted password field). > > I didn't know that and I stand corrected on password aging. > > I think the statement about account expiry is still correct (and I > re-read "man 4 passwd" before posting this) but I'm prepared to be > corrected again :-) i don't know how to do account expire without SecureWare-style trusted (which was introduced at 10.0), but there's maybe something that i am not remembering. i see with 11i 1.6 there's a way to do /etc/shadow which adds another mode. http://devrsrc1.external.hp.com/STK/impacts/i833.html From dtucker at zip.com.au Wed Jan 15 16:30:41 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 15 Jan 2003 16:30:41 +1100 Subject: Test for locked account in auth.c (bug #442). References: <3E233CD5.818EFC06@zip.com.au> <20030114022217.GD13122@scott.crlsca.adelphia.net> <3E23B7DD.FFB2E88@zip.com.au> <20030115044114.GB13606@scott.crlsca.adelphia.net> Message-ID: <3E24F200.ACB414BE@zip.com.au> Kevin Steves wrote: > i see with 11i 1.6 there's a way to do /etc/shadow which adds another > mode. > http://devrsrc1.external.hp.com/STK/impacts/i833.html I had a quick read that and I think that case is covered by the existing getspnam() call in the shadow expiry handling. The thing I'm currently puzzling over is: is it sane to support multiple expiry schemes in a single binary? Example: HP-UX 11.00 box, you need to use passwd->pw_age or pr_passwd->ufld.fd_* depending on whether or not the system is in trusted mode (ie depending on what iscomsec() returns). In fact, I think the way to do it is just check the result of the call (eg getspnam/getprpwnam) and ignore it if if fails. It would be nice if the sshd just did the right thing no matter what mode the box is in (but that means linking with -lsec all the time, is that a big deal?). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Thu Jan 16 12:51:54 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 16 Jan 2003 12:51:54 +1100 Subject: Core dump in sftp from CVS Message-ID: <3E26103A.FF559984@zip.com.au> Hi All. As I mentioned earlier, I've been having weird failures with both sshd and sftp. The sshd one turned out the be my fault (misplaced "}", grr) but the sftp one doesn't appear to be. The sftp regression tests fail on the current portable tree on Solaris and AIX (with my own mods to auth.c and regress/, but I don't think that's related). The test that fails is: $ ./sftp -P sftp-server -B 5 -R 1 -b ./batch Attaching to sftp-server... sftp> version SFTP protocol version 3 sftp> get /bin/ls ./copy.1 sftp> put /bin/ls ./copy.2 Segmentation Fault (core dumped) The cause appears to be sftp-int.c line 508: 506 /* Only one match, dst may be file, directory or unspecified */ 507 if (g.gl_pathv[0] && g.gl_matchc == 1) { 508 if (!is_reg(g.gl_pathv[i])) { ^^^ The variable "i" is uninitialized at this point. The code is the same in OpenBSD and portable. Attached patch passes regression on Solaris 8. -- 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: sftp-int.c =================================================================== RCS file: /cvs/openssh/sftp-int.c,v retrieving revision 1.44 diff -u -r1.44 sftp-int.c --- sftp-int.c 14 Jan 2003 11:24:47 -0000 1.44 +++ sftp-int.c 16 Jan 2003 01:22:21 -0000 @@ -505,7 +505,7 @@ /* Only one match, dst may be file, directory or unspecified */ if (g.gl_pathv[0] && g.gl_matchc == 1) { - if (!is_reg(g.gl_pathv[i])) { + if (!is_reg(g.gl_pathv[0])) { error("Can't upload %s: not a regular file", g.gl_pathv[0]); err = 1; From djm at mindrot.org Thu Jan 16 14:37:41 2003 From: djm at mindrot.org (Damien Miller) Date: Thu, 16 Jan 2003 14:37:41 +1100 Subject: Core dump in sftp from CVS In-Reply-To: <3E26103A.FF559984@zip.com.au> References: <3E26103A.FF559984@zip.com.au> Message-ID: <3E262905.4070308@mindrot.org> Darren Tucker wrote: > Hi All. > As I mentioned earlier, I've been having weird failures with both sshd > and sftp. The sshd one turned out the be my fault (misplaced "}", grr) > but the sftp one doesn't appear to be. hmm. The code is wrong, but I don't think it should segv - automatic variables should be initialised to zero no? We have seen this before with Sun's compiler. -d From dtucker at zip.com.au Thu Jan 16 15:23:38 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 16 Jan 2003 15:23:38 +1100 Subject: Core dump in sftp from CVS References: <3E26103A.FF559984@zip.com.au> <3E262905.4070308@mindrot.org> Message-ID: <3E2633CA.D8B02B21@zip.com.au> Damien Miller wrote: > hmm. The code is wrong, but I don't think it should segv - automatic > variables should be initialised to zero no? I thought they were undefined and could contain whatever happened to be on the stack (although a platform could choose to zero it, zero being just as undefined as any other value). In one of my cases, i was 14. [google] http://www.eskimo.com/~scs/C-faq/q1.30.html static (global, static local) == zeroed. automatic (local) == undefined. > We have seen this before with Sun's compiler. This was gcc 3.2 and 3.2.1. -- 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 Thu Jan 16 15:34:06 2003 From: djm at mindrot.org (Damien Miller) Date: Thu, 16 Jan 2003 15:34:06 +1100 Subject: Core dump in sftp from CVS In-Reply-To: <3E2633CA.D8B02B21@zip.com.au> References: <3E26103A.FF559984@zip.com.au> <3E262905.4070308@mindrot.org> <3E2633CA.D8B02B21@zip.com.au> Message-ID: <3E26363E.6020402@mindrot.org> Darren Tucker wrote: > Damien Miller wrote: > >>hmm. The code is wrong, but I don't think it should segv - automatic >>variables should be initialised to zero no? > > > I thought they were undefined and could contain whatever happened to be > on the stack (although a platform could choose to zero it, zero being > just as undefined as any other value). In one of my cases, i was 14. In any case - I have already commited the fix to the OpenBSD tree. It will end up in portable soon. -d From djm at mindrot.org Thu Jan 16 15:38:29 2003 From: djm at mindrot.org (Damien Miller) Date: Thu, 16 Jan 2003 15:38:29 +1100 Subject: Core dump in sftp from CVS In-Reply-To: <3E262905.4070308@mindrot.org> References: <3E26103A.FF559984@zip.com.au> <3E262905.4070308@mindrot.org> Message-ID: <3E263745.2000102@mindrot.org> Damien Miller wrote: > hmm. The code is wrong, but I don't think it should segv - automatic > variables should be initialised to zero no? > > We have seen this before with Sun's compiler. Actually this too was a similar, but different bug - global data (which should be in bss) was not initialised. Wrong twice in one email :( -d From dtucker at zip.com.au Thu Jan 16 15:58:05 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 16 Jan 2003 15:58:05 +1100 Subject: Portable regression tests? (was: Core dump in sftp from CVS) References: <3E26103A.FF559984@zip.com.au> <3E262905.4070308@mindrot.org> <3E2633CA.D8B02B21@zip.com.au> <3E26363E.6020402@mindrot.org> Message-ID: <3E263BDD.4AD4FA9B@zip.com.au> Damien Miller wrote: > In any case - I have already commited the fix to the OpenBSD tree. It > will end up in portable soon. Cool. On another subject, any chance of making the regression tests in portable, well, portable? Ben suggested portabilizing the OpenBSD native tests (which is quite doable[0] and consists mostly of changes like "grep -q" -> "grep >/dev/null") then using them as-is in portable. Failing that, they could be periodically synced like the rest of the package. [0] http://www.zip.com.au/~dtucker/openssh/regress/ -- 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 Thu Jan 16 16:33:48 2003 From: djm at mindrot.org (Damien Miller) Date: Thu, 16 Jan 2003 16:33:48 +1100 Subject: Portable regression tests? (was: Core dump in sftp from CVS) In-Reply-To: <3E263BDD.4AD4FA9B@zip.com.au> References: <3E26103A.FF559984@zip.com.au> <3E262905.4070308@mindrot.org> <3E2633CA.D8B02B21@zip.com.au> <3E26363E.6020402@mindrot.org> <3E263BDD.4AD4FA9B@zip.com.au> Message-ID: <3E26443C.2090809@mindrot.org> Darren Tucker wrote: > Damien Miller wrote: > >>In any case - I have already commited the fix to the OpenBSD tree. It >>will end up in portable soon. > > > Cool. On another subject, any chance of making the regression tests in > portable, well, portable? > > Ben suggested portabilizing the OpenBSD native tests (which is quite > doable[0] and consists mostly of changes like "grep -q" -> "grep "grep -q" is pretty well standardised[0]. I'll take a look at the others later. >>/dev/null") then using them as-is in portable. Failing that, they could be >> periodically synced like the rest of the package. Yes - this is on my TODO list. -d [0] It's in SUSv2: http://www.opengroup.org/onlinepubs/007908799/xcu/grep.html From bugzilla-daemon at mindrot.org Fri Jan 17 10:31:50 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 17 Jan 2003 10:31:50 +1100 (EST) Subject: [Bug 470] make fails for OSX Message-ID: <20030116233150.C02A66488C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=470 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-17 10:31 ------- Applied - thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dsa0000 at hotmail.com Fri Jan 17 11:41:59 2003 From: dsa0000 at hotmail.com (dsa main) Date: Fri, 17 Jan 2003 00:41:59 +0000 Subject: Guessing in key exchange Message-ID: Hi, I was using F-Secure SSH V2.0 client to connect openssh server. Here the relevant part of the client log. ----------------------------------------------------- local ip = 172.168.29.8, local port = 4870 remote ip = 172.168.29.7, remote port = 22 remote hostname is "172.168.29.7". Wrapping... Remote version: SSH-2.0-OpenSSH_3.2.2p1 CBVersionCheck: remote version 'SSH-2.0-OpenSSH_3.2.2p1' Major: 3 Minor: 2 Revision: 2 Remote version has rekey incompatibility bug. <------- ???? Remote version is OpenSSH, KEX guesses disabled. ------------------------------------------------------- It shows that openssh rekey incompatibility bug.. Whether it means that guessing in key exchange is not supported correctly in Openssh. Regards DSA _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus From djm at mindrot.org Fri Jan 17 15:26:33 2003 From: djm at mindrot.org (Damien Miller) Date: Fri, 17 Jan 2003 15:26:33 +1100 Subject: Guessing in key exchange In-Reply-To: References: Message-ID: <3E2785F9.4030704@mindrot.org> dsa main wrote: > Hi, > > I was using F-Secure SSH V2.0 client to connect openssh server. > > Here the relevant part of the client log. > ----------------------------------------------------- > local ip = 172.168.29.8, local port = 4870 > remote ip = 172.168.29.7, remote port = 22 > remote hostname is "172.168.29.7". > Wrapping... > Remote version: SSH-2.0-OpenSSH_3.2.2p1 > CBVersionCheck: remote version 'SSH-2.0-OpenSSH_3.2.2p1' > Major: 3 Minor: 2 Revision: 2 > Remote version has rekey incompatibility bug. <------- ???? > Remote version is OpenSSH, KEX guesses disabled. > ------------------------------------------------------- I don't know what the "rekey incompatibility bug" incompatibility bug is, but KEX guesses are not (yet) implemented: http://bugzilla.mindrot.org/show_bug.cgi?id=148 -d From mouring at etoh.eviladmin.org Fri Jan 17 10:13:30 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 16 Jan 2003 17:13:30 -0600 (CST) Subject: Guessing in key exchange In-Reply-To: Message-ID: 3.5p1 is the current release. - Ben On Fri, 17 Jan 2003, dsa main wrote: > Hi, > > I was using F-Secure SSH V2.0 client to connect openssh server. > > Here the relevant part of the client log. > ----------------------------------------------------- > local ip = 172.168.29.8, local port = 4870 > remote ip = 172.168.29.7, remote port = 22 > remote hostname is "172.168.29.7". > Wrapping... > Remote version: SSH-2.0-OpenSSH_3.2.2p1 > CBVersionCheck: remote version 'SSH-2.0-OpenSSH_3.2.2p1' > Major: 3 Minor: 2 Revision: 2 > Remote version has rekey incompatibility bug. <------- ???? > Remote version is OpenSSH, KEX guesses disabled. > ------------------------------------------------------- > > It shows that openssh rekey incompatibility bug.. > Whether it means that guessing in key exchange > is not supported correctly in Openssh. > > Regards > DSA > > > > > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From wangkai at ncs.com.sg Fri Jan 17 20:30:01 2003 From: wangkai at ncs.com.sg (Wang Kai) Date: Fri, 17 Jan 2003 17:30:01 +0800 Subject: Open SSH BugID 370 Message-ID: Hi, Dear Madam/Sir Can you check for me whether the Openssh bugID 370 has been resolved or not. If so, can you provide me the solution? Looking forward to your reply. Thank you very much. Regards Wang Kai From maniac at maniac.nl Fri Jan 17 20:53:21 2003 From: maniac at maniac.nl (Mark Janssen) Date: 17 Jan 2003 10:53:21 +0100 Subject: Open SSH BugID 370 In-Reply-To: References: Message-ID: <1042797200.1023.2.camel@ninja> On Fri, 2003-01-17 at 10:30, Wang Kai wrote: > Hi, Dear Madam/Sir > Can you check for me whether the Openssh bugID 370 has been resolved or > not. If so, can you provide me the solution? > Looking forward to your reply. Thank you very much. See: http://bugzilla.mindrot.org/show_bug.cgi?id=370 -- Mark Janssen Saiko Internet Technologies From markus at openbsd.org Fri Jan 17 22:09:32 2003 From: markus at openbsd.org (Markus Friedl) Date: Fri, 17 Jan 2003 12:09:32 +0100 Subject: Guessing in key exchange In-Reply-To: <3E2785F9.4030704@mindrot.org> References: <3E2785F9.4030704@mindrot.org> Message-ID: <20030117110932.GB19069@folly> On Fri, Jan 17, 2003 at 03:26:33PM +1100, Damien Miller wrote: > I don't know what the "rekey incompatibility bug" incompatibility bug rekeying was not supported in openssh < 2.9.9 From wendyp at cray.com Sat Jan 18 12:11:26 2003 From: wendyp at cray.com (Wendy Palm) Date: Fri, 17 Jan 2003 19:11:26 -0600 Subject: [Bug 367] patches for Cray port Message-ID: <3E28A9BE.3090202@cray.com> memset has apparently been fixed in unicos afterall, or else the current code straightened out whatever was going wrong. i'm not sure what happened, but deattack.c changes are no longer necessary. i'm not going to look a gift horse in the mouth.... crays run great straight out of the box for 3.5p1 as released. sorry for the long delay in replying. porting my product to our new machine took more time than i anticipated. thanks for your time, wendy bugzilla-daemon at mindrot.org wrote: > http://bugzilla.mindrot.org/show_bug.cgi?id=367 > > > > > > ------- Additional Comments From mouring at eviladmin.org 2002-11-10 03:34 ------- > Everything was applied to 3.5 but deattack.c. Changes talked about on the list > will be accepted if they are submitted in patch form. > > > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From bugzilla-daemon at mindrot.org Sat Jan 18 16:25:10 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 Jan 2003 16:25:10 +1100 (EST) Subject: [Bug 442] sshd allows login via public-key when account locked Message-ID: <20030118052510.51DCB64552@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=442 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From djm at mindrot.org 2003-01-18 16:25 ------- I have reverted the patch, until we can work out a) if we really want it and b) how best to implement it. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From openssh-list at grax.com Sun Jan 19 09:10:24 2003 From: openssh-list at grax.com (David Walker) Date: Sat, 18 Jan 2003 16:10:24 -0600 Subject: GeoIP support - DenyCountry Message-ID: <200301181610.24203@grx> First time subscriber/poster My attached patch allows GeoIP support for the free GeoIP database and C api from http://www.maxmind.com/ Install GeoIP before compiling and it should work. It adds 2 options to sshd_config DenyCountry Deny access from a specific country based on GeoIP lookup. Use multiple DenyCountry entries to deny access from multiple countries. DenyCountry takes precedence over AllowCountry AllowCountry Allow access from a specific country based on GeoIP lookup. Use multiple AllowCountry entries to allow access from multiple countries. I hardcoded the configure script part of it. ideally it should either detect when GeoIP is installed or accept a --with-geoip parameter or both but I am not too familiar with configure testing. -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh.geoip.patch Type: text/x-diff Size: 8027 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030118/98e3323b/attachment.bin From jakob at crt.se Sun Jan 19 10:09:30 2003 From: jakob at crt.se (Jakob Schlyter) Date: Sun, 19 Jan 2003 00:09:30 +0100 (CET) Subject: GeoIP support - DenyCountry In-Reply-To: <200301181610.24203@grx> References: <200301181610.24203@grx> Message-ID: I strongly recommend that this patch is rejected and not integrated in nor distributed with openssh. the whole idea behind - as a security mechanism - is totally bogus. jakob From openssh-list at grax.com Sun Jan 19 10:26:23 2003 From: openssh-list at grax.com (David Walker) Date: Sat, 18 Jan 2003 17:26:23 -0600 Subject: GeoIP support - DenyCountry In-Reply-To: References: <200301181610.24203@grx> Message-ID: <200301181726.23830@grx> It is not a security mechanism as such. It is a scan reduction tool. It is useful for my network in that all of my users are based in the United States. Any connection from outside the United States is automatically known to be bogus and there is no reason to allow it to continue. Granted there are plenty of bogus users within the United States but there is no reason in my mind to add the rest of the world to that. A significant portion of the scans that reach my network are from outside the United States while nothing in my network (at the current time) offers any benefit to a non-US user. On Saturday 18 January 2003 05:09 pm, Jakob Schlyter wrote: > I strongly recommend that this patch is rejected and not integrated in nor > distributed with openssh. the whole idea behind - as a security mechanism > - is totally bogus. > > jakob From bob at proulx.com Sun Jan 19 10:40:51 2003 From: bob at proulx.com (Bob Proulx) Date: Sat, 18 Jan 2003 16:40:51 -0700 Subject: GeoIP support - DenyCountry In-Reply-To: <200301181726.23830@grx> References: <200301181610.24203@grx> <200301181726.23830@grx> Message-ID: <20030118234051.GB17803@misery.proulx.com> David Walker wrote: > It is not a security mechanism as such. It is a scan reduction tool. > > It is useful for my network in that all of my users are based in the > United States. Any connection from outside the United States is > automatically known to be bogus and there is no reason to allow it > to continue. That functionality more rightly belongs in a firewall than in ssh. You can always place a firewall between ssh and the network. In fact that is probably a good thing regardless. I also do not think that this feature belongs in ssh. Bob From kamath at geekoids.com Sun Jan 19 10:44:37 2003 From: kamath at geekoids.com (Sean Kamath) Date: Sat, 18 Jan 2003 15:44:37 -0800 Subject: GeoIP support - DenyCountry In-Reply-To: Your message of "Sat, 18 Jan 2003 17:26:23 CST." <200301181726.23830@grx> Message-ID: <200301182344.h0INicsF009153@fridge.south.geekoids.com> Perhaps I'm missing something, but wouldn't it make more sense to use tcpwrappers with SSH? That way, you could basically deny all connections to any ports sourced outside the US. . . Just a thought. . . Sean [In a message on Sat, 18 Jan 2003 17:26:23 CST, David Walker wrote:] >It is not a security mechanism as such. It is a scan reduction tool. > >It is useful for my network in that all of my users are based in the United >States. Any connection from outside the United States is automatically known >to be bogus and there is no reason to allow it to continue. > >Granted there are plenty of bogus users within the United States but there is >no reason in my mind to add the rest of the world to that. A significant >portion of the scans that reach my network are from outside the United States >while nothing in my network (at the current time) offers any benefit to a >non-US user. > >On Saturday 18 January 2003 05:09 pm, Jakob Schlyter wrote: >> I strongly recommend that this patch is rejected and not integrated in nor >> distributed with openssh. the whole idea behind - as a security mechanism >> - is totally bogus. >> >> jakob > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From bowman at math.ualberta.ca Sun Jan 19 10:51:57 2003 From: bowman at math.ualberta.ca (John Bowman) Date: 18 Jan 2003 16:51:57 -0700 Subject: [Patch] User-dependent IdentityFile Message-ID: <20030118235157.28485.qmail@wizard.math.ualberta.ca> Here is the user-dependent IdentityFile patch for openssh3.5 (BSD version), which allows private key files to be placed system wide (for all users) in a secure (non-NFS) mounted location. This addresses an important security hole on systems where home directories are NFS mounted, particularly if there are users who use blank passphrases (or when lpd is tunneled through ssh on systems running lpd as user lp) instead of ssh-agent. IdentityFile now accepts the same %u, %h, %% options that AuthorizedKeysFile accepts. For example, one can specify a user-dependent IdentityFile in ssh_config: IdentityFile /ssh/%u/id_rsa This version of the IdentityFile patch modifies ssh-keygen to use the directory part of the first local host IdentityFile entry as the default key location (which may then be overridden). Note: Useful commands for moving existing key files system wide to the new secure directory (e.g. /ssh) are available at http://www.math.ualberta.ca/imaging/snfs/openssh.html diff -ru ssh/auth.c sshJ/auth.c --- ssh/auth.c Fri Sep 20 12:41:29 2002 +++ sshJ/auth.c Sat Jan 18 16:20:41 2003 @@ -35,7 +35,6 @@ #include "auth.h" #include "auth-options.h" #include "canohost.h" -#include "buffer.h" #include "bufaux.h" #include "uidswap.h" #include "tildexpand.h" @@ -214,62 +213,6 @@ return 0; } - -/* - * Given a template and a passwd structure, build a filename - * by substituting % tokenised options. Currently, %% becomes '%', - * %h becomes the home directory and %u the username. - * - * This returns a buffer allocated by xmalloc. - */ -char * -expand_filename(const char *filename, struct passwd *pw) -{ - Buffer buffer; - char *file; - const char *cp; - - /* - * Build the filename string in the buffer by making the appropriate - * substitutions to the given file name. - */ - buffer_init(&buffer); - for (cp = filename; *cp; cp++) { - if (cp[0] == '%' && cp[1] == '%') { - buffer_append(&buffer, "%", 1); - cp++; - continue; - } - if (cp[0] == '%' && cp[1] == 'h') { - buffer_append(&buffer, pw->pw_dir, strlen(pw->pw_dir)); - cp++; - continue; - } - if (cp[0] == '%' && cp[1] == 'u') { - buffer_append(&buffer, pw->pw_name, - strlen(pw->pw_name)); - cp++; - continue; - } - buffer_append(&buffer, cp, 1); - } - buffer_append(&buffer, "\0", 1); - - /* - * Ensure that filename starts anchored. If not, be backward - * compatible and prepend the '%h/' - */ - file = xmalloc(MAXPATHLEN); - cp = buffer_ptr(&buffer); - if (*cp != '/') - snprintf(file, MAXPATHLEN, "%s/%s", pw->pw_dir, cp); - else - strlcpy(file, cp, MAXPATHLEN); - - buffer_free(&buffer); - return file; -} - char * authorized_keys_file(struct passwd *pw) { diff -ru ssh/auth.h sshJ/auth.h --- ssh/auth.h Thu Sep 26 05:38:43 2002 +++ sshJ/auth.h Sat Jan 18 16:20:41 2003 @@ -159,7 +159,6 @@ struct passwd * auth_get_user(void); -char *expand_filename(const char *, struct passwd *); char *authorized_keys_file(struct passwd *); char *authorized_keys_file2(struct passwd *); diff -ru ssh/ssh-keygen/Makefile sshJ/ssh-keygen/Makefile --- ssh/ssh-keygen/Makefile Wed Jun 27 13:29:16 2001 +++ sshJ/ssh-keygen/Makefile Thu Oct 31 09:46:47 2002 @@ -10,7 +10,7 @@ BINDIR= /usr/bin MAN= ssh-keygen.1 -SRCS= ssh-keygen.c +SRCS= ssh-keygen.c readconf.c .include diff -ru ssh/ssh-keygen.c sshJ/ssh-keygen.c --- ssh/ssh-keygen.c Sun Jun 23 03:39:55 2002 +++ sshJ/ssh-keygen.c Sat Jan 18 16:20:41 2003 @@ -27,6 +27,9 @@ #include "pathnames.h" #include "log.h" #include "readpass.h" +#include "ssh.h" +#include "readconf.h" +#include "tildexpand.h" #ifdef SMARTCARD #include "scard.h" @@ -78,6 +81,13 @@ char hostname[MAXHOSTNAMELEN]; +/* + * General data structure for command line options and options configurable + * in configuration files. See readconf.h. + */ +Options options; +uid_t original_real_uid; + static void ask_filename(struct passwd *pw, const char *prompt) { @@ -103,7 +113,28 @@ break; } - snprintf(identity_file, sizeof(identity_file), "%s/%s", pw->pw_dir, name); + + if(options.num_identity_files > 0) { + char *file=NULL; + char *p=strrchr(name,'/'); + if(p) file = p+1; + + name = tilde_expand_filename(options.identity_files[0], + original_real_uid); + name = expand_filename(name,pw); + p=strrchr(name,'/'); + if(p) *p=0; + + if(file && *file) { + snprintf(identity_file, sizeof(identity_file), "%s/%s", name,file); + } + else { + snprintf(identity_file, sizeof(identity_file), "%s", name); + } + } else { + snprintf(identity_file, sizeof(identity_file), "%s/%s", pw->pw_dir, + name); + } fprintf(stderr, "%s (%s): ", prompt, identity_file); fflush(stderr); if (fgets(buf, sizeof(buf), stdin) == NULL) @@ -750,6 +781,7 @@ struct stat st; int opt, type, fd, download = 0; FILE *f; + char buf[256]; extern int optind; extern char *optarg; @@ -767,6 +799,13 @@ exit(1); } + snprintf(buf, sizeof buf, "%.100s/%.100s", pw->pw_dir, + _PATH_SSH_USER_CONFFILE); + (void)read_config_file(buf, hostname, &options); + + /* Read systemwide configuration file after user config. */ + (void)read_config_file(_PATH_HOST_CONFIG_FILE, hostname, &options); + while ((opt = getopt(ac, av, "deiqpclBRxXyb:f:t:U:D:P:N:C:")) != -1) { switch (opt) { case 'b': diff -ru ssh/ssh.c sshJ/ssh.c --- ssh/ssh.c Wed Sep 18 19:58:18 2002 +++ sshJ/ssh.c Sat Jan 18 16:20:41 2003 @@ -1165,9 +1165,13 @@ xfree(keys); } #endif /* SMARTCARD */ + struct passwd *pw; + pw=getpwuid(original_real_uid); + if (!pw) fatal("Unknown user id: %d", original_real_uid); for (; i < options.num_identity_files; i++) { filename = tilde_expand_filename(options.identity_files[i], original_real_uid); + filename = expand_filename(filename,pw); public = key_load_public(filename, NULL); debug("identity file %s type %d", filename, public ? public->type : -1); diff -ru ssh/tildexpand.c sshJ/tildexpand.c --- ssh/tildexpand.c Sat Jun 22 21:25:50 2002 +++ sshJ/tildexpand.c Sat Jan 18 16:20:41 2003 @@ -16,6 +16,7 @@ #include "xmalloc.h" #include "log.h" #include "tildexpand.h" +#include "buffer.h" /* * Expands tildes in the file name. Returns data allocated by xmalloc. @@ -47,7 +48,7 @@ if (userlen == 0) pw = getpwuid(my_uid); /* Own home directory. */ else { - /* Tilde refers to someone elses home directory. */ + /* Tilde refers to someone else's home directory. */ if (userlen > sizeof(user) - 1) fatal("User name after tilde too long."); memcpy(user, filename, userlen); @@ -71,3 +72,58 @@ strcmp(pw->pw_dir, "/") ? "/" : "", cp + 1); return expanded; } + +/* + * Given a template and a passwd structure, build a filename + * by substituting % tokenised options. Currently, %% becomes '%', + * %h becomes the home directory and %u the username. + * + * This returns a buffer allocated by xmalloc. + */ +char * +expand_filename(const char *filename, struct passwd *pw) +{ + Buffer buffer; + char *file; + const char *cp; + + /* + * Build the filename string in the buffer by making the appropriate + * substitutions to the given file name. + */ + buffer_init(&buffer); + for (cp = filename; *cp; cp++) { + if (cp[0] == '%' && cp[1] == '%') { + buffer_append(&buffer, "%", 1); + cp++; + continue; + } + if (cp[0] == '%' && cp[1] == 'h') { + buffer_append(&buffer, pw->pw_dir, strlen(pw->pw_dir)); + cp++; + continue; + } + if (cp[0] == '%' && cp[1] == 'u') { + buffer_append(&buffer, pw->pw_name, + strlen(pw->pw_name)); + cp++; + continue; + } + buffer_append(&buffer, cp, 1); + } + buffer_append(&buffer, "\0", 1); + + /* + * Ensure that filename starts anchored. If not, be backward + * compatible and prepend the '%h/' + */ + file = xmalloc(MAXPATHLEN); + cp = buffer_ptr(&buffer); + if (*cp != '/') + snprintf(file, MAXPATHLEN, "%s/%s", pw->pw_dir, cp); + else + strlcpy(file, cp, MAXPATHLEN); + + buffer_free(&buffer); + return file; +} diff -ru ssh/tildexpand.h sshJ/tildexpand.h --- ssh/tildexpand.h Tue Jun 26 11:27:25 2001 +++ sshJ/tildexpand.h Sat Jan 18 16:20:41 2003 @@ -13,3 +13,4 @@ */ char *tilde_expand_filename(const char *, uid_t); +char *expand_filename(const char *, struct passwd *); From openssh-list at grax.com Sun Jan 19 11:09:32 2003 From: openssh-list at grax.com (David Walker) Date: Sat, 18 Jan 2003 18:09:32 -0600 Subject: GeoIP support - DenyCountry In-Reply-To: <200301182344.h0INicsF009153@fridge.south.geekoids.com> References: <200301182344.h0INicsF009153@fridge.south.geekoids.com> Message-ID: <200301181809.32638@grx> Without GeoIP I have no way of knowing where the user is coming from. So if I want to use tcpwrappers I would have to put a GeoIP patch into tcpwrappers. Reverse DNS does not count. Administrators do not have to set up reverse DNS or they can set it to whatever they like. On Saturday 18 January 2003 05:44 pm, Sean Kamath wrote: > Perhaps I'm missing something, but wouldn't it make more sense to > use tcpwrappers with SSH? That way, you could basically deny all > connections to any ports sourced outside the US. . . > > Just a thought. . . > > Sean > > > [In a message on Sat, 18 Jan 2003 17:26:23 CST, > David Walker wrote:] > > >It is not a security mechanism as such. It is a scan reduction tool. > > > >It is useful for my network in that all of my users are based in the > > United States. Any connection from outside the United States is > > automatically known to be bogus and there is no reason to allow it to > > continue. > > > >Granted there are plenty of bogus users within the United States but there > > is no reason in my mind to add the rest of the world to that. A > > significant portion of the scans that reach my network are from outside > > the United States while nothing in my network (at the current time) > > offers any benefit to a non-US user. > > > >On Saturday 18 January 2003 05:09 pm, Jakob Schlyter wrote: > >> I strongly recommend that this patch is rejected and not integrated in > >> nor distributed with openssh. the whole idea behind - as a security > >> mechanism - is totally bogus. > >> > >> jakob > > > >_______________________________________________ > >openssh-unix-dev mailing list > >openssh-unix-dev at mindrot.org > >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From mouring at etoh.eviladmin.org Sun Jan 19 06:18:51 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 18 Jan 2003 13:18:51 -0600 (CST) Subject: GeoIP support - DenyCountry In-Reply-To: <200301181809.32638@grx> Message-ID: On Sat, 18 Jan 2003, David Walker wrote: > Without GeoIP I have no way of knowing where the user is coming from. > So if I want to use tcpwrappers I would have to put a GeoIP patch into > tcpwrappers. > That would make much more sense to me. - Ben > Reverse DNS does not count. Administrators do not have to set up reverse DNS > or they can set it to whatever they like. > > On Saturday 18 January 2003 05:44 pm, Sean Kamath wrote: > > Perhaps I'm missing something, but wouldn't it make more sense to > > use tcpwrappers with SSH? That way, you could basically deny all > > connections to any ports sourced outside the US. . . > > > > Just a thought. . . > > > > Sean > > > > > > [In a message on Sat, 18 Jan 2003 17:26:23 CST, > > David Walker wrote:] > > > > >It is not a security mechanism as such. It is a scan reduction tool. > > > > > >It is useful for my network in that all of my users are based in the > > > United States. Any connection from outside the United States is > > > automatically known to be bogus and there is no reason to allow it to > > > continue. > > > > > >Granted there are plenty of bogus users within the United States but there > > > is no reason in my mind to add the rest of the world to that. A > > > significant portion of the scans that reach my network are from outside > > > the United States while nothing in my network (at the current time) > > > offers any benefit to a non-US user. > > > > > >On Saturday 18 January 2003 05:09 pm, Jakob Schlyter wrote: > > >> I strongly recommend that this patch is rejected and not integrated in > > >> nor distributed with openssh. the whole idea behind - as a security > > >> mechanism - is totally bogus. > > >> > > >> jakob > > > > > >_______________________________________________ > > >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 dtucker at zip.com.au Sun Jan 19 11:51:24 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 19 Jan 2003 11:51:24 +1100 Subject: OpenSSH Portable Tinderbox available to test. Message-ID: <3E29F68C.41AFF03@zip.com.au> Hi All. After one false start, I now have a Tinderbox up and running for the OpenSSH portable tree. For those not familiar with it, Tinderbox is a tool for automatically displaying the status of builds and tests. At the moment, I do 1 update and 4 builds hourly. It's not fully functional yet but the basics work. It can be found at http://dodgynet.dyndns.org/tinderbox/OpenSSH_Portable/ (I recommend starting with the "status" view). Please give it a try. If anyone is interested in running the tests on their own platform, please let me know. The machine will need to be able to "cvs update" and send email. For more info on Tinderbox, see http://mozilla.org/tinderbox.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 dtucker at zip.com.au Sun Jan 19 12:11:09 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 19 Jan 2003 12:11:09 +1100 Subject: OpenSSH build failure on NetBSD 1.5.2 Message-ID: <3E29FB2D.FD72AA7@zip.com.au> Hi All. The recent setproctitle changes don't seem to work on NetBSD. Some of the variables are still used when the definitions are #ifdef'ed out. Attached patch fixes it, but I'm not sure it does it the right way. -Daz. gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I../../openbsd-compat -I../../openbsd-compat/.. -DHAVE_CONFIG_H -c ../../openbsd-compat/setproctitle.c ../../openbsd-compat/setproctitle.c: In function `compat_init_setproctitle': ../../openbsd-compat/setproctitle.c:196: `save_argc' undeclared (first use in this function) ../../openbsd-compat/setproctitle.c:196: (Each undeclared identifier is reported only once ../../openbsd-compat/setproctitle.c:196: for each function it appears in.) ../../openbsd-compat/setproctitle.c:197: `save_argv' undeclared (first use in this function) ../../openbsd-compat/setproctitle.c:215: `ps_buffer' undeclared (first use in this function) ../../openbsd-compat/setproctitle.c:216: `ps_buffer_size' undeclared (first use in this function) ../../openbsd-compat/setproctitle.c:223: `environ' undeclared (first use in this function) *** Error code 1 $ grep SETPROCTITLE config.h /* #undef SETPROCTITLE_STRATEGY */ /* #undef SETPROCTITLE_PS_PADD #define HAVE_SETPROCTITLE 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. -------------- next part -------------- Index: openbsd-compat/setproctitle.c =================================================================== RCS file: /cvs/openssh/openbsd-compat/setproctitle.c,v retrieving revision 1.4 diff -u -r1.4 setproctitle.c --- openbsd-compat/setproctitle.c 12 Jan 2003 23:04:59 -0000 1.4 +++ openbsd-compat/setproctitle.c 17 Jan 2003 11:10:34 -0000 @@ -51,8 +51,6 @@ #include #endif -extern char **environ; - /*------ * Alternative ways of updating ps display: * @@ -86,6 +84,9 @@ #ifndef SETPROCTITLE_PS_PADDING # define SETPROCTITLE_PS_PADDING ' ' #endif +#endif /* HAVE_SETPROCTITLE */ + +extern char **environ; /* * argv clobbering uses existing argv space, all other methods need a buffer @@ -104,6 +105,7 @@ extern char *__progname; +#ifndef HAVE_SETPROCTITLE /* * Call this to update the ps status display to a fixed prefix plus an * indication of what you're currently doing passed in the argument. From ymnk at jcraft.com Sun Jan 19 17:12:39 2003 From: ymnk at jcraft.com (Atsuhiko Yamanaka) Date: Sun, 19 Jan 2003 15:12:39 +0900 Subject: signal forwarding support Message-ID: <200301190612.PAA18673@jcraft.com> Hi, I have a question about signal forwarding support in sshd of OpenSSH. http://www.openssh.org/txt/draft-ietf-secsh-connect-15.txt says that |4.9 Signals | | A signal can be delivered to the remote process/service using the | following message. Some systems may not implement signals, in which | case they SHOULD ignore this message. | | byte SSH_MSG_CHANNEL_REQUEST | uint32 recipient channel | string "signal" | boolean FALSE | string signal name without the "SIG" prefix. and it seems to me that sshd of OpenSSH has ignored this request. Is my recognition correct? If so, is there a plat to implement it? I'm implementing SSH2 client in pure Java and I wonder how we can kill a remote process in smart way and I added signal request support to my stuff experimentally. I will never request to implement it and I just want to know the current status and future plan. If there is no plan, I will drop that request support. Thanks, -- ymnk From bugzilla-daemon at mindrot.org Sun Jan 19 17:49:17 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 19 Jan 2003 17:49:17 +1100 (EST) Subject: [Bug 471] New: Misleading error message if /dev/tty permissions wrong Message-ID: <20030119064917.5110F6454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=471 Summary: Misleading error message if /dev/tty permissions wrong Product: Portable OpenSSH Version: 3.4p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: ssh-bugzilla at veggiechinese.net If a user doesn't have read / write permissions to /dev/tty with OpenSSH 3.4p1 on Linux, the error message given is "Host key verification failed"; this error message is misleading and confusing IMHO. dali% ssh -V OpenSSH_3.4p1 Debian 1:3.4p1-1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f dali% ssh jazz.hq.newdream.net Host key verification failed. dali% strace ssh jazz.hq.newdream.net [...] read(4, "jareth,jareth.dreamhost.com,66.3"..., 4096) = 251 read(4, "", 4096) = 0 close(4) = 0 munmap(0x124000, 4096) = 0 open("/dev/tty", O_RDWR|O_LARGEFILE) = -1 EACCES (Permission denied) open("/dev/tty", O_RDWR|O_LARGEFILE) = -1 EACCES (Permission denied) write(2, "Host key verification failed.\r\n", 31Host key verification failed. ) = 31 shutdown(3, 2 /* send and receive */) = 0 close(3) = 0 _exit(255) = ? Changing permissions on /dev/tty seems to fix this problem. ------- 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 Jan 19 18:45:43 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 19 Jan 2003 18:45:43 +1100 (EST) Subject: [Bug 471] Misleading error message if /dev/tty permissions wrong Message-ID: <20030119074543.AB90D6454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=471 ------- Additional Comments From djm at mindrot.org 2003-01-19 18:45 ------- What happened when you fixed the permissions of /dev/tty? I bet you were asked to confirm a new host key... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Sun Jan 19 20:40:39 2003 From: markus at openbsd.org (Markus Friedl) Date: Sun, 19 Jan 2003 10:40:39 +0100 Subject: OpenSSH Portable Tinderbox available to test. In-Reply-To: <3E29F68C.41AFF03@zip.com.au> References: <3E29F68C.41AFF03@zip.com.au> Message-ID: <20030119094039.GD1622@folly> On Sun, Jan 19, 2003 at 11:51:24AM +1100, Darren Tucker wrote: > Hi All. > After one false start, I now have a Tinderbox up and running for the > OpenSSH portable tree. For those not familiar with it, Tinderbox is a > tool for automatically displaying the status of builds and tests. At > the moment, I do 1 update and 4 builds hourly. > > It's not fully functional yet but the basics work. It can be found at > http://dodgynet.dyndns.org/tinderbox/OpenSSH_Portable/ (I recommend > starting with the "status" view). Please give it a try. > > If anyone is interested in running the tests on their own platform, > please let me know. The machine will need to be able to "cvs update" > and send email. > > For more info on Tinderbox, see http://mozilla.org/tinderbox.html. hm, this seems to be similar to http://www.lysator.liu.se/xenofarm/download.xml http://www.lysator.liu.se/~nisse/xeno-lsh/latest.html -m From markus at openbsd.org Sun Jan 19 20:42:15 2003 From: markus at openbsd.org (Markus Friedl) Date: Sun, 19 Jan 2003 10:42:15 +0100 Subject: signal forwarding support In-Reply-To: <200301190612.PAA18673@jcraft.com> References: <200301190612.PAA18673@jcraft.com> Message-ID: <20030119094215.GE1622@folly> On Sun, Jan 19, 2003 at 03:12:39PM +0900, Atsuhiko Yamanaka wrote: > Hi, > > I have a question about signal forwarding support in sshd of OpenSSH. > > http://www.openssh.org/txt/draft-ietf-secsh-connect-15.txt says that > |4.9 Signals > | > | A signal can be delivered to the remote process/service using the > | following message. Some systems may not implement signals, in which > | case they SHOULD ignore this message. > | > | byte SSH_MSG_CHANNEL_REQUEST > | uint32 recipient channel > | string "signal" > | boolean FALSE > | string signal name without the "SIG" prefix. > > and it seems to me that sshd of OpenSSH has ignored this request. no, sshd no longer ignore this. From ymnk at jcraft.com Sun Jan 19 20:57:55 2003 From: ymnk at jcraft.com (Atsuhiko Yamanaka) Date: Sun, 19 Jan 2003 18:57:55 +0900 Subject: signal forwarding support In-Reply-To: <20030119094215.GE1622@folly> (message from Markus Friedl on Sun, 19 Jan 2003 10:42:15 +0100) References: <200301190612.PAA18673@jcraft.com> <20030119094215.GE1622@folly> Message-ID: <200301190957.SAA19084@jcraft.com> Hi, Thank you for replying to me. +-From: Markus Friedl | Date: Sun, 19 Jan 2003 10:42:15 +0100 | |On Sun, Jan 19, 2003 at 03:12:39PM +0900, Atsuhiko Yamanaka wrote: >> Hi, >> >> I have a question about signal forwarding support in sshd of >> OpenSSH. ... >> and it seems to me that sshd of OpenSSH has ignored this >> request. |no, sshd no longer ignore this. According to CVSWeb on www.openssh.org, http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/session.c?rev=1.152 the function 'session_input_channel_req' in 'session.c' has not checked the case for "signal". So, I thought that request has been ignored. Has the newest version already supported it? That sounds great! Thanks, -- ymnk From dtucker at zip.com.au Sun Jan 19 21:19:49 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 19 Jan 2003 21:19:49 +1100 Subject: OpenSSH Portable Tinderbox available to test. References: <3E29F68C.41AFF03@zip.com.au> <20030119094039.GD1622@folly> Message-ID: <3E2A7BC5.47FC84DF@zip.com.au> Markus Friedl wrote: > On Sun, Jan 19, 2003 at 11:51:24AM +1100, Darren Tucker wrote: > > For more info on Tinderbox, see http://mozilla.org/tinderbox.html. > > hm, this seems to be similar to > http://www.lysator.liu.se/xenofarm/download.xml > http://www.lysator.liu.se/~nisse/xeno-lsh/latest.html Apparently so. According to the info, Xenofarm is a rewrite of AutoBuild, which was inspired by Tinderbox. Is there a xenofarm for OpenSSH? (If there is, google doen't know about 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 markus at openbsd.org Sun Jan 19 21:14:36 2003 From: markus at openbsd.org (Markus Friedl) Date: Sun, 19 Jan 2003 11:14:36 +0100 Subject: signal forwarding support In-Reply-To: <200301190612.PAA18673@jcraft.com> References: <200301190612.PAA18673@jcraft.com> Message-ID: <20030119101436.GA2664@folly> oops, i'm wrong. signal request support never made it into a release. i'm not sure when/whether this will happen. -m From bugzilla-daemon at mindrot.org Mon Jan 20 05:45:06 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 20 Jan 2003 05:45:06 +1100 (EST) Subject: [Bug 471] Misleading error message if /dev/tty permissions wrong Message-ID: <20030119184506.D64106454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=471 ------- Additional Comments From ssh-bugzilla at veggiechinese.net 2003-01-20 05:45 ------- True - if the key is present already, I get: Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,password,keyboard-interactive). It still is quite confusing to have it immediately say "Host key verification failed." - I don't know if it's possible to make the error clearer though. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Mon Jan 20 07:20:01 2003 From: markus at openbsd.org (Markus Friedl) Date: Sun, 19 Jan 2003 21:20:01 +0100 Subject: signal forwarding support In-Reply-To: <200301190957.SAA19084@jcraft.com> References: <200301190612.PAA18673@jcraft.com> <20030119094215.GE1622@folly> <200301190957.SAA19084@jcraft.com> Message-ID: <20030119202001.GA18527@folly> On Sun, Jan 19, 2003 at 06:57:55PM +0900, Atsuhiko Yamanaka wrote: > Has the newest version already supported it? That sounds great! ok, here's a patch. Index: session.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/session.c,v retrieving revision 1.152 diff -u -r1.152 session.c --- session.c 10 Dec 2002 08:56:00 -0000 1.152 +++ session.c 19 Jan 2003 20:15:52 -0000 @@ -1502,6 +1502,51 @@ } static int +name2sig(char *name) +{ +#define SSH_SIG(x) if (strcmp(name, #x) == 0) return SIG ## x + SSH_SIG(ABRT); + SSH_SIG(ALRM); + SSH_SIG(FPE); + SSH_SIG(HUP); + SSH_SIG(ILL); + SSH_SIG(INT); + SSH_SIG(KILL); + SSH_SIG(PIPE); + SSH_SIG(QUIT); + SSH_SIG(SEGV); + SSH_SIG(TERM); + SSH_SIG(USR1); + SSH_SIG(USR2); +#undef SSH_SIG + return -1; +} + +static int +session_signal_req(Session *s) +{ + char *signame; + int sig; + + signame = packet_get_string(NULL); + sig = name2sig(signame); + xfree(signame); + packet_check_eom(); + + if (sig >= 0 && s->pid > 0) { + debug("session_signal_req: killpg(%d, %d)", + s->pid, sig); + temporarily_use_uid(s->pw); + if (killpg(s->pid, sig) < 0) + error("session_signal_req: killpg(%d, %d): %s", + s->pid, sig, strerror(errno)); + restore_uid(); + } + return 0; +} + + +static int session_auth_agent_req(Session *s) { static int called = 0; @@ -1552,6 +1597,8 @@ } if (strcmp(rtype, "window-change") == 0) { success = session_window_change_req(s); + } else if (strcmp(rtype, "signal") == 0) { + success = session_signal_req(s); } return success; } From djm at mindrot.org Mon Jan 20 13:41:28 2003 From: djm at mindrot.org (Damien Miller) Date: Mon, 20 Jan 2003 13:41:28 +1100 Subject: OpenSSH build failure on NetBSD 1.5.2 In-Reply-To: <3E29FB2D.FD72AA7@zip.com.au> References: <3E29FB2D.FD72AA7@zip.com.au> Message-ID: <3E2B61D8.7030302@mindrot.org> Darren Tucker wrote: > Hi All. > The recent setproctitle changes don't seem to work on NetBSD. Some of > the variables are still used when the definitions are #ifdef'ed out. > Attached patch fixes it, but I'm not sure it does it the right way. Applied - thanks. -d From ymnk at jcraft.com Mon Jan 20 14:05:13 2003 From: ymnk at jcraft.com (Atsuhiko Yamanaka) Date: Mon, 20 Jan 2003 12:05:13 +0900 Subject: signal forwarding support In-Reply-To: <20030119202001.GA18527@folly> (message from Markus Friedl on Sun, 19 Jan 2003 21:20:01 +0100) References: <200301190612.PAA18673@jcraft.com> <20030119094215.GE1622@folly> <200301190957.SAA19084@jcraft.com> <20030119202001.GA18527@folly> Message-ID: <200301200305.MAA20898@jcraft.com> Hi, +-From: Markus Friedl __ |_Date: Sun, 19 Jan 2003 21:20:01 +0100 _____ | |On Sun, Jan 19, 2003 at 06:57:55PM +0900, Atsuhiko Yamanaka wrote: >> Has the newest version already supported it? That sounds >> great! |ok, here's a patch. .... I applied this patch to openssh-3.1p1 and tried it on RedHat 7.3 box. It worked! For example, I did the following on my java stuff, establishing an encrypted connection. while(true){ invoking a remote process by send "exec" request Thread.sleep(1000); sending "KILL" signal by "signal" request. } Remote precess were killed successfully and it is nice that sshd sent to client 'SSH_MSG_CHANNEL_EOF' and 'SSH_MSG_CHANNEL_CLOSE' requests after each death of remote process. It is perfect! I don't know that patch will be merged into a release or not, but I will keep this sending signal functionality in my stuff. Thanks a lot, -- ymnk From Eric.Ladner at chevrontexaco.com Tue Jan 21 00:32:18 2003 From: Eric.Ladner at chevrontexaco.com (Ladner, Eric (Eric.Ladner)) Date: Mon, 20 Jan 2003 07:32:18 -0600 Subject: HP-UX 11.11 question Message-ID: <53D65D67C6AA694284F7584E25ADD3546CD86B@nor935nte2k1.nor935.chevrontexaco.net> I recently compiled 3.5p1 on a HP-UX 11.11 box. Any time I use ssh (either locally or connecting from remote) I get a Memory fault. The backtrace in gdb looks something like this (from memory): Libc (free()) Libc (something else) Libnss (something related to DNS) Libc Ssh (get_connect()) I think it's the get_connect or get_connection in ssh where the called function is failing. This seems like a libc/libnss bug on HP-UX. I can try to get an actual backtrace later if necessary - I don't have access to the box at the moment. I was just hoping this would jog somebody's memory. I've changed around the nsswitch.conf file some to see if it was bad options in the file causing some of the nss functions to bomb, but nothing has helped. Has anyone else had similar problems? Thanks, Eric From maniac at maniac.nl Tue Jan 21 02:16:28 2003 From: maniac at maniac.nl (Mark Janssen) Date: 20 Jan 2003 16:16:28 +0100 Subject: Possible bug: Putty's psftp doesn't work when priv-sep is turned on Message-ID: <1043075787.1213.21.camel@ninja> Hi List(s) A customer of mine reported that sftp didn't work for them. It seems to work just fine for me on that system, and after checking into it I noticed that the customer used psftp, while I use sftp from either cygwin or the linux version from openssh. The openssh version of sftp works in all cases, priv-sep on or off. However, the putty psftp breaks as soon as I turn on priv-sep (which is on by default on openssh3.5). I've tried this on 3.5 and today's snapshot of openssh. I've tried with versions of putty from 0.52 to today's snapshot On the unix system (i've tested aix433 and linux) the sshd reports the following (sshd -D -d -d -d) Jan 20 14:41:59 dhu1_boot sshd[9580]: Server listening on 0.0.0.0 port 22. Jan 20 14:42:11 dhu1_boot sshd[15502]: Accepted password for maniac from 10.x.y.z port 2972 ssh2 Jan 20 14:42:12 dhu1_boot sshd[16546]: fatal: buffer_append_space: alloc 10506240 not supported On the putty side I get the following message after entering the password or passphrase when connecting to a server with priv-sep turned on: Fatal: unable to initialise SFTP: could not connect -- Mark Janssen Saiko Internet Technologies From markus at openbsd.org Tue Jan 21 02:54:23 2003 From: markus at openbsd.org (Markus Friedl) Date: Mon, 20 Jan 2003 16:54:23 +0100 Subject: Possible bug: Putty's psftp doesn't work when priv-sep is turned on In-Reply-To: <1043075787.1213.21.camel@ninja> References: <1043075787.1213.21.camel@ninja> Message-ID: <20030120155423.GA14186@folly> On Mon, Jan 20, 2003 at 04:16:28PM +0100, Mark Janssen wrote: > Jan 20 14:42:11 dhu1_boot sshd[15502]: Accepted password for maniac from > 10.x.y.z port 2972 ssh2 > Jan 20 14:42:12 dhu1_boot sshd[16546]: fatal: buffer_append_space: alloc > 10506240 not supported hm, do you have a stacktrace for this call to fatal? e.g. start sshd and set breakpoint to fatal()? From bradley at bellevueaccountingsolutions.com.au Mon Jan 20 22:07:56 2003 From: bradley at bellevueaccountingsolutions.com.au (Bradley Schatz) Date: 20 Jan 2003 21:07:56 +1000 Subject: Creating statically linked sshd binary Message-ID: <1043060811.3337.48.camel@localhost.localdomain> Is there an easy way to do this? thanks bradley From luc at suryo.com Tue Jan 21 17:20:44 2003 From: luc at suryo.com (Luc I. Suryo) Date: Tue, 21 Jan 2003 00:20:44 -0600 Subject: Creating statically linked sshd binary In-Reply-To: <1043060811.3337.48.camel@localhost.localdomain> References: <1043060811.3337.48.camel@localhost.localdomain> Message-ID: <20030121062044.GB2031@nc1701.suryo.com> > Is there an easy way to do this? hmm sure .. except there will be some system library that always will be dynamic, nothing you can do about that! a) compile zlib static , or move/delete the shared libs so the compiler will not find them! b) compile openssk static , or move/delete the shared libs so the compiler will not find them! c) compile openssh on my system i have static linked sshd/ssh: ldd sshd libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 ldd ssh libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 As you can see no other then system libs is needed, this is on a Sun Sparc system but can be done with linux too ... just need to be handy with configure :) have fun! btw e-mail to your e-mail bounced!!! -- Kind regards, Luc Suryo From nicklange at wi.rr.com Wed Jan 22 03:02:55 2003 From: nicklange at wi.rr.com (Nick Lange) Date: Tue, 21 Jan 2003 10:02:55 -0600 Subject: GeoIP support - DenyCountry In-Reply-To: <200301181809.32638@grx> References: <200301182344.h0INicsF009153@fridge.south.geekoids.com> <200301181809.32638@grx> Message-ID: <3E2D6F2F.2030008@wi.rr.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Quick response, While I hope this patch does not get accepted into openssh, I do think it's a nice idea in concept; however, a priori, relying on a commercial vendor in free software is a bad idea. Not to mention that this code belongs in a netfilter module if you want to deploy this system wide. Furthermore, realize that by this point in the code the connection has already occurred, which I think is the opposite of what you want. BUT, you're code seems to affect a small enough section of the code that it should be maintainable between versions w/o too much work [if any?]. So why not set up a webpage with your patch on it that people can hit? And lastly, why not parse the countries in a delimited list? that way only one line is necessary in the configuration? Cheers, nick David Walker a ?crit: > Without GeoIP I have no way of knowing where the user is coming from. > So if I want to use tcpwrappers I would have to put a GeoIP patch into > tcpwrappers. > > Reverse DNS does not count. Administrators do not have to set up reverse DNS > or they can set it to whatever they like. > > On Saturday 18 January 2003 05:44 pm, Sean Kamath wrote: > >>Perhaps I'm missing something, but wouldn't it make more sense to >>use tcpwrappers with SSH? That way, you could basically deny all >>connections to any ports sourced outside the US. . . >> >>Just a thought. . . >> >>Sean >> >> >>[In a message on Sat, 18 Jan 2003 17:26:23 CST, >> David Walker wrote:] >> >> >>>It is not a security mechanism as such. It is a scan reduction tool. >>> >>>It is useful for my network in that all of my users are based in the >>>United States. Any connection from outside the United States is >>>automatically known to be bogus and there is no reason to allow it to >>>continue. >>> >>>Granted there are plenty of bogus users within the United States but there >>>is no reason in my mind to add the rest of the world to that. A >>>significant portion of the scans that reach my network are from outside >>>the United States while nothing in my network (at the current time) >>>offers any benefit to a non-US user. >>> >>>On Saturday 18 January 2003 05:09 pm, Jakob Schlyter wrote: >>> >>>>I strongly recommend that this patch is rejected and not integrated in >>>>nor distributed with openssh. the whole idea behind - as a security >>>>mechanism - is totally bogus. >>>> >>>> jakob >>> >>>_______________________________________________ >>>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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+LW8zUpjBJywc+asRAjx0AKCJVEZ4ZJeIFxfRd5oaaTkP8BWgtgCfd1jk mIPVsMVDKYrg2shnZo1IegE= =oAdL -----END PGP SIGNATURE----- From openssh-list at grax.com Wed Jan 22 04:42:10 2003 From: openssh-list at grax.com (David Walker) Date: Tue, 21 Jan 2003 11:42:10 -0600 Subject: GeoIP support - DenyCountry In-Reply-To: <3E2D6F2F.2030008@wi.rr.com> References: <200301182344.h0INicsF009153@fridge.south.geekoids.com> <200301181809.32638@grx> <3E2D6F2F.2030008@wi.rr.com> Message-ID: <200301211142.10478@grx> On Tuesday 21 January 2003 10:02 am, Nick Lange wrote: > Quick response, > While I hope this patch does not get accepted into openssh, I do think > it's a nice idea in concept; however, a priori, relying on a commercial > vendor in free software is a bad idea. Not to mention that this code > belongs in a netfilter module if you want to deploy this system wide. > Furthermore, realize that by this point in the code the connection has > already occurred, which I think is the opposite of what you want. I am working on a userspace implementation with netfilter and libipq but that will have to wait til I get more free time. Since the connection has occured by the time this code is called this code is more useful with a non-standard ssh port as it reveals an open port but not what app is running. I am not sure if you can make a port appear closed from within an application which means that netfilter integration is much preferred. > > BUT, you're code seems to affect a small enough section of the code that > it should be maintainable between versions w/o too much work [if any?]. So > why not set up a webpage with your patch on it that people can hit? So far I am the only one I am aware of that is interested in this. > > And lastly, why not parse the countries in a delimited list? that way only > one line is necessary in the configuration? I don't really have a preference. When I was writing it the multiline thing seemed easier to write. > > Cheers, > nick > > David Walker a ?crit: > > Without GeoIP I have no way of knowing where the user is coming from. > > So if I want to use tcpwrappers I would have to put a GeoIP patch into > > tcpwrappers. > > > > Reverse DNS does not count. Administrators do not have to set up reverse > > DNS or they can set it to whatever they like. > > > > On Saturday 18 January 2003 05:44 pm, Sean Kamath wrote: > >>Perhaps I'm missing something, but wouldn't it make more sense to > >>use tcpwrappers with SSH? That way, you could basically deny all > >>connections to any ports sourced outside the US. . . > >> > >>Just a thought. . . > >> > >>Sean > >> > >> > >>[In a message on Sat, 18 Jan 2003 17:26:23 CST, > >> David Walker wrote:] > >> > >>>It is not a security mechanism as such. It is a scan reduction tool. > >>> > >>>It is useful for my network in that all of my users are based in the > >>>United States. Any connection from outside the United States is > >>>automatically known to be bogus and there is no reason to allow it to > >>>continue. > >>> > >>>Granted there are plenty of bogus users within the United States but > >>> there is no reason in my mind to add the rest of the world to that. A > >>> significant portion of the scans that reach my network are from outside > >>> the United States while nothing in my network (at the current time) > >>> offers any benefit to a non-US user. > >>> > >>>On Saturday 18 January 2003 05:09 pm, Jakob Schlyter wrote: > >>>>I strongly recommend that this patch is rejected and not integrated in > >>>>nor distributed with openssh. the whole idea behind - as a security > >>>>mechanism - is totally bogus. > >>>> > >>>> jakob > >>> > >>>_______________________________________________ > >>>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 download at ahpcc.unm.edu Wed Jan 22 09:31:45 2003 From: download at ahpcc.unm.edu (Jim Prewett) Date: Tue, 21 Jan 2003 15:31:45 -0700 (MST) Subject: X11 forwarding problem -- openssh-3.5p1 -- redhat 8.0 -- linux 2.4.18 Message-ID: All, I'm working on upgrading a machine from RH 6.2 to RH 8.0. I've encountered one major (for me) snag in that I cannot get X11 forwarding to work anymore. I've been google-ing the error messages all morning, with no luck. Here is debugging output from the server (client debugging output sent upon request... I don't feel it is relevant). What I feel is interesting is at the bottom of the following text block: # sshd -ddd -p 222 debug1: sshd version OpenSSH_3.5p1 debug1: private host key: #0 type 0 RSA1 debug3: Not a RSA1 key file /etc/ssh/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 /etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: Bind to port 222 on 0.0.0.0. Server listening on 0.0.0.0 port 222. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 129.24.246.132 port 1179 debug1: Client protocol version 2.0; client software version OpenSSH_3.4p1 FreeBSD-20020702 debug1: match: OpenSSH_3.4p1 FreeBSD-20020702 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 32411 debug3: preauth child monitor started debug3: mm_request_receive 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-dss,ssh-rsa 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 debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: 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 none debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug3: mm_request_send entering: type 0 debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI debug3: monitor_read: checking request 0 debug3: mm_answer_moduli: got parameters: 1024 2048 8192 debug3: mm_request_receive_expect entering: type 1 debug3: mm_request_receive entering debug3: mm_request_send entering: type 1 debug2: monitor_read: 0 used once, disabling now debug3: mm_request_receive entering debug3: mm_choose_dh: remaining 0 debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: dh_gen_key: priv key bits set: 121/256 debug1: bits set: 1612/3191 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 1595/3191 debug3: mm_key_sign entering debug3: mm_request_send entering: type 4 debug3: monitor_read: checking request 4 debug3: mm_answer_sign debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN debug3: mm_request_receive_expect entering: type 5 debug3: mm_request_receive entering debug3: mm_answer_sign: signature 0x809f278(55) debug3: mm_request_send entering: type 5 debug2: monitor_read: 4 used once, disabling now debug3: mm_request_receive entering debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent 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: KEX done debug1: userauth-request for user download service ssh-connection method none debug1: attempt 0 failures 0 debug3: mm_getpwnamallow entering debug3: mm_request_send entering: type 6 debug3: monitor_read: checking request 6 debug3: mm_answer_pwnamallow debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM debug3: mm_request_receive_expect entering: type 7 debug3: mm_request_receive entering debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 debug3: mm_request_send entering: type 7 debug2: monitor_read: 6 used once, disabling now debug3: mm_request_receive entering debug2: input_userauth_request: setting up authctxt for download debug3: mm_start_pam entering debug3: mm_request_send entering: type 41 debug3: mm_inform_authserv entering debug3: monitor_read: checking request 41 debug1: Starting up PAM with username "download" debug3: mm_request_send entering: type 3 debug2: input_userauth_request: try method none debug3: mm_auth_password entering debug3: mm_request_send entering: type 10 debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: mm_request_receive_expect entering: type 11 debug3: mm_request_receive entering debug3: Trying to reverse map address 129.24.246.132. debug1: PAM setting rhost to "dhcp132.ahpcc.unm.edu" debug2: monitor_read: 41 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 3 debug3: mm_answer_authserv: service=ssh-connection, style= debug2: monitor_read: 3 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 10 debug3: mm_answer_authpassword: sending result 0 debug3: mm_request_send entering: type 11 Failed none for download from 129.24.246.132 port 1179 ssh2 debug3: mm_request_receive entering debug3: mm_auth_password: user not authenticated Failed none for download from 129.24.246.132 port 1179 ssh2 debug1: userauth-request for user download service ssh-connection method keyboard-interactive debug1: attempt 1 failures 1 debug2: input_userauth_request: try method keyboard-interactive debug1: keyboard-interactive devs debug1: auth2_challenge: user=download devs= debug1: kbdint_alloc: devices '' debug2: auth2_challenge_start: devices Failed keyboard-interactive for download from 129.24.246.132 port 1179 ssh2 debug1: userauth-request for user download service ssh-connection method password debug1: attempt 2 failures 2 debug2: input_userauth_request: try method password debug3: mm_auth_password entering debug3: mm_request_send entering: type 10 debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: mm_request_receive_expect entering: type 11 debug3: mm_request_receive entering debug3: monitor_read: checking request 10 debug1: PAM Password authentication accepted for user "download" debug3: mm_answer_authpassword: sending result 1 debug3: mm_request_send entering: type 11 debug3: mm_auth_password: user authenticated Accepted password for download from 129.24.246.132 port 1179 ssh2 debug3: mm_send_keystate: Sending new keys: 0x809e408 0x809d4b0 debug3: mm_newkeys_to_blob: converting 0x809e408 debug3: mm_newkeys_to_blob: converting 0x809d4b0 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 debug2: pam_acct_mgmt() = 0 Accepted password for download from 129.24.246.132 port 1179 ssh2 debug1: monitor_child_preauth: download has been authenticated by privileged process debug3: mm_get_keystate: Waiting for new keys debug3: mm_request_receive_expect entering: type 24 debug3: mm_request_receive entering debug3: mm_newkeys_from_blob: 0x80a97c0(118) debug2: mac_init: found hmac-md5 debug3: mm_get_keystate: Waiting for second key debug3: mm_newkeys_from_blob: 0x80a97c0(118) debug2: mac_init: found hmac-md5 debug3: mm_get_keystate: Getting compression state debug3: mm_get_keystate: Getting Network I/O buffers debug3: mm_share_sync: Share sync debug3: mm_share_sync: Share sync end debug2: User child is on pid 32412 debug3: mm_request_receive entering debug1: PAM establishing creds debug1: permanently_set_uid: 31618/100 debug1: newkeys: mode 0 debug1: newkeys: mode 1 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 0 win 65536 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 debug1: server_input_channel_req: channel 0 request pty-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: lastlog_openseek: Couldn't open /var/log/lastlog: Permission denied debug1: Allocating pty. debug3: mm_request_send entering: type 25 debug3: monitor_read: checking request 25 debug3: mm_answer_pty entering debug1: session_new: init debug1: session_new: session 0 debug3: mm_request_send entering: type 26 debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY debug3: mm_request_receive_expect entering: type 26 debug3: mm_request_receive entering debug1: session_pty_req: session 0 alloc /dev/pts/4 debug3: mm_answer_pty: tty /dev/pts/4 ptyfd 3 debug3: mm_request_receive entering debug3: tty_parse_modes: SSH2 n_bytes 251 debug3: tty_parse_modes: ospeed 38400 debug3: tty_parse_modes: ispeed 38400 debug3: tty_parse_modes: 1 3 debug3: tty_parse_modes: 2 28 debug3: tty_parse_modes: 3 8 debug3: tty_parse_modes: 4 21 debug3: tty_parse_modes: 5 4 debug3: tty_parse_modes: 6 255 debug3: tty_parse_modes: 7 255 debug3: tty_parse_modes: 8 17 debug3: tty_parse_modes: 9 19 debug3: tty_parse_modes: 10 26 debug1: Ignoring unsupported tty mode opcode 11 (0xb) debug3: tty_parse_modes: 12 18 debug3: tty_parse_modes: 13 23 debug3: tty_parse_modes: 14 22 debug1: Ignoring unsupported tty mode opcode 17 (0x11) debug3: tty_parse_modes: 18 15 debug3: tty_parse_modes: 30 0 debug3: tty_parse_modes: 31 0 debug3: tty_parse_modes: 32 0 debug3: tty_parse_modes: 33 0 debug3: tty_parse_modes: 34 0 debug3: tty_parse_modes: 35 0 debug3: tty_parse_modes: 36 1 debug3: tty_parse_modes: 38 1 debug3: tty_parse_modes: 39 1 debug3: tty_parse_modes: 40 0 debug3: tty_parse_modes: 41 1 debug3: tty_parse_modes: 50 1 debug3: tty_parse_modes: 51 1 debug3: tty_parse_modes: 53 1 debug3: tty_parse_modes: 54 1 debug3: tty_parse_modes: 55 1 debug3: tty_parse_modes: 56 0 debug3: tty_parse_modes: 57 0 debug3: tty_parse_modes: 58 0 debug3: tty_parse_modes: 59 1 debug3: tty_parse_modes: 60 1 debug3: tty_parse_modes: 61 1 debug3: tty_parse_modes: 62 1 debug3: tty_parse_modes: 70 1 debug3: tty_parse_modes: 72 1 debug3: tty_parse_modes: 73 0 debug3: tty_parse_modes: 74 0 debug3: tty_parse_modes: 75 0 debug3: tty_parse_modes: 90 1 debug3: tty_parse_modes: 91 1 debug3: tty_parse_modes: 92 0 debug3: tty_parse_modes: 93 0 debug1: server_input_channel_req: channel 0 request x11-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req x11-req debug1: bind port 6010: Cannot assign requested address debug1: bind port 6011: Cannot assign requested address debug1: bind port 6998: Cannot assign requested address debug1: bind port 6999: Cannot assign requested address Failed to allocate internet-domain X11 display socket. debug1: x11_create_display_inet failed. debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: PAM setting tty to "/dev/pts/4" debug1: PAM establishing creds debug1: fd 4 setting TCP_NODELAY debug1: channel 0: rfd 10 isatty debug1: fd 10 setting O_NONBLOCK debug2: fd 9 is O_NONBLOCK debug1: Setting controlling tty using TIOCSCTTY. My configuration (defaults and blanks stripped): # awk '!/^$|^#/ {print}' /etc/ssh/sshd_config HostKey /etc/ssh/ssh_host_key HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key SyslogFacility AUTHPRIV X11Forwarding yes X11DisplayOffset 10 UsePrivilegeSeparation yes Subsystem sftp /usr/libexec/openssh/sftp-server This is built from a source rpm from redhat (http://ftp.redhat.com/pub/redhat/linux/rawhide/SRPMS/SRPMS/openssh-3.5p1-3.src.rpm) I modified the openssh.spec file slightly: # diff -u openssh.spec openssh.spec.orig --- openssh.spec 2003-01-21 11:31:15.000000000 -0700 +++ openssh.spec.orig 2003-01-21 11:30:34.000000000 -0700 @@ -9,7 +9,7 @@ %define no_x11_askpass 0 # Do we want to disable building of gnome-askpass? (1=yes 0=no) -%define no_gnome_askpass 1 +%define no_gnome_askpass 0 # Do we want to link against a static libcrypto? (1=yes 0=no) %define static_libcrypto 0 @@ -24,10 +24,10 @@ %define build6x 0 # Disable IPv6 (avoids DNS hangs on some glibc versions) -%define noip6 1 +%define noip6 0 # Do we want kerberos5 support (1=yes 0=no) -%define kerberos5 0 +%define kerberos5 1 # Whether or not /sbin/nologin exists. %define nologin 1 Also, I saw some stuff in the archives about IPV6 causing some problems. I'm not using IPV6: grep IPV6 /usr/src/linux/.config # CONFIG_IPV6 is not set I've also tried passing -4 to both the client and the server to ensure they don't get confused about v4 vs. v6. Please let me know if additional information would be helpful. I'll be more than happy to provide it. Any help would be greatly appreciated, Jim From Eric.Ladner at chevrontexaco.com Wed Jan 22 09:54:19 2003 From: Eric.Ladner at chevrontexaco.com (Ladner, Eric (Eric.Ladner)) Date: Tue, 21 Jan 2003 16:54:19 -0600 Subject: X11 forwarding problem -- openssh-3.5p1 -- redhat 8.0 -- linux 2.4.18 Message-ID: <53D65D67C6AA694284F7584E25ADD3546CD8AC@nor935nte2k1.nor935.chevrontexaco.net> You've checked 'iptables -L' to see if those ports are being REJECTEd on the RH 8.0 box? Eric -----Original Message----- From: Jim Prewett [mailto:download at ahpcc.unm.edu] Sent: Tuesday, January 21, 2003 4:32 PM To: openssh-unix-dev at mindrot.org Subject: X11 forwarding problem -- openssh-3.5p1 -- redhat 8.0 -- linux 2.4.18 All, I'm working on upgrading a machine from RH 6.2 to RH 8.0. I've encountered one major (for me) snag in that I cannot get X11 forwarding to work anymore. I've been google-ing the error messages all morning, with no luck. Here is debugging output from the server (client debugging output sent upon request... I don't feel it is relevant). What I feel is interesting is at the bottom of the following text block: # sshd -ddd -p 222 debug1: sshd version OpenSSH_3.5p1 debug1: private host key: #0 type 0 RSA1 debug3: Not a RSA1 key file /etc/ssh/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 /etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: Bind to port 222 on 0.0.0.0. Server listening on 0.0.0.0 port 222. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 129.24.246.132 port 1179 debug1: Client protocol version 2.0; client software version OpenSSH_3.4p1 FreeBSD-20020702 debug1: match: OpenSSH_3.4p1 FreeBSD-20020702 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 32411 debug3: preauth child monitor started debug3: mm_request_receive 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-c bc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,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-dss,ssh-rsa debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,hmac-md5-96 debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: 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 none debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug3: mm_request_send entering: type 0 debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI debug3: monitor_read: checking request 0 debug3: mm_answer_moduli: got parameters: 1024 2048 8192 debug3: mm_request_receive_expect entering: type 1 debug3: mm_request_receive entering debug3: mm_request_send entering: type 1 debug2: monitor_read: 0 used once, disabling now debug3: mm_request_receive entering debug3: mm_choose_dh: remaining 0 debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: dh_gen_key: priv key bits set: 121/256 debug1: bits set: 1612/3191 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 1595/3191 debug3: mm_key_sign entering debug3: mm_request_send entering: type 4 debug3: monitor_read: checking request 4 debug3: mm_answer_sign debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN debug3: mm_request_receive_expect entering: type 5 debug3: mm_request_receive entering debug3: mm_answer_sign: signature 0x809f278(55) debug3: mm_request_send entering: type 5 debug2: monitor_read: 4 used once, disabling now debug3: mm_request_receive entering debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent 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: KEX done debug1: userauth-request for user download service ssh-connection method none debug1: attempt 0 failures 0 debug3: mm_getpwnamallow entering debug3: mm_request_send entering: type 6 debug3: monitor_read: checking request 6 debug3: mm_answer_pwnamallow debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM debug3: mm_request_receive_expect entering: type 7 debug3: mm_request_receive entering debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 debug3: mm_request_send entering: type 7 debug2: monitor_read: 6 used once, disabling now debug3: mm_request_receive entering debug2: input_userauth_request: setting up authctxt for download debug3: mm_start_pam entering debug3: mm_request_send entering: type 41 debug3: mm_inform_authserv entering debug3: monitor_read: checking request 41 debug1: Starting up PAM with username "download" debug3: mm_request_send entering: type 3 debug2: input_userauth_request: try method none debug3: mm_auth_password entering debug3: mm_request_send entering: type 10 debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: mm_request_receive_expect entering: type 11 debug3: mm_request_receive entering debug3: Trying to reverse map address 129.24.246.132. debug1: PAM setting rhost to "dhcp132.ahpcc.unm.edu" debug2: monitor_read: 41 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 3 debug3: mm_answer_authserv: service=ssh-connection, style= debug2: monitor_read: 3 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 10 debug3: mm_answer_authpassword: sending result 0 debug3: mm_request_send entering: type 11 Failed none for download from 129.24.246.132 port 1179 ssh2 debug3: mm_request_receive entering debug3: mm_auth_password: user not authenticated Failed none for download from 129.24.246.132 port 1179 ssh2 debug1: userauth-request for user download service ssh-connection method keyboard-interactive debug1: attempt 1 failures 1 debug2: input_userauth_request: try method keyboard-interactive debug1: keyboard-interactive devs debug1: auth2_challenge: user=download devs= debug1: kbdint_alloc: devices '' debug2: auth2_challenge_start: devices Failed keyboard-interactive for download from 129.24.246.132 port 1179 ssh2 debug1: userauth-request for user download service ssh-connection method password debug1: attempt 2 failures 2 debug2: input_userauth_request: try method password debug3: mm_auth_password entering debug3: mm_request_send entering: type 10 debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: mm_request_receive_expect entering: type 11 debug3: mm_request_receive entering debug3: monitor_read: checking request 10 debug1: PAM Password authentication accepted for user "download" debug3: mm_answer_authpassword: sending result 1 debug3: mm_request_send entering: type 11 debug3: mm_auth_password: user authenticated Accepted password for download from 129.24.246.132 port 1179 ssh2 debug3: mm_send_keystate: Sending new keys: 0x809e408 0x809d4b0 debug3: mm_newkeys_to_blob: converting 0x809e408 debug3: mm_newkeys_to_blob: converting 0x809d4b0 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 debug2: pam_acct_mgmt() = 0 Accepted password for download from 129.24.246.132 port 1179 ssh2 debug1: monitor_child_preauth: download has been authenticated by privileged process debug3: mm_get_keystate: Waiting for new keys debug3: mm_request_receive_expect entering: type 24 debug3: mm_request_receive entering debug3: mm_newkeys_from_blob: 0x80a97c0(118) debug2: mac_init: found hmac-md5 debug3: mm_get_keystate: Waiting for second key debug3: mm_newkeys_from_blob: 0x80a97c0(118) debug2: mac_init: found hmac-md5 debug3: mm_get_keystate: Getting compression state debug3: mm_get_keystate: Getting Network I/O buffers debug3: mm_share_sync: Share sync debug3: mm_share_sync: Share sync end debug2: User child is on pid 32412 debug3: mm_request_receive entering debug1: PAM establishing creds debug1: permanently_set_uid: 31618/100 debug1: newkeys: mode 0 debug1: newkeys: mode 1 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 0 win 65536 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 debug1: server_input_channel_req: channel 0 request pty-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: lastlog_openseek: Couldn't open /var/log/lastlog: Permission denied debug1: Allocating pty. debug3: mm_request_send entering: type 25 debug3: monitor_read: checking request 25 debug3: mm_answer_pty entering debug1: session_new: init debug1: session_new: session 0 debug3: mm_request_send entering: type 26 debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY debug3: mm_request_receive_expect entering: type 26 debug3: mm_request_receive entering debug1: session_pty_req: session 0 alloc /dev/pts/4 debug3: mm_answer_pty: tty /dev/pts/4 ptyfd 3 debug3: mm_request_receive entering debug3: tty_parse_modes: SSH2 n_bytes 251 debug3: tty_parse_modes: ospeed 38400 debug3: tty_parse_modes: ispeed 38400 debug3: tty_parse_modes: 1 3 debug3: tty_parse_modes: 2 28 debug3: tty_parse_modes: 3 8 debug3: tty_parse_modes: 4 21 debug3: tty_parse_modes: 5 4 debug3: tty_parse_modes: 6 255 debug3: tty_parse_modes: 7 255 debug3: tty_parse_modes: 8 17 debug3: tty_parse_modes: 9 19 debug3: tty_parse_modes: 10 26 debug1: Ignoring unsupported tty mode opcode 11 (0xb) debug3: tty_parse_modes: 12 18 debug3: tty_parse_modes: 13 23 debug3: tty_parse_modes: 14 22 debug1: Ignoring unsupported tty mode opcode 17 (0x11) debug3: tty_parse_modes: 18 15 debug3: tty_parse_modes: 30 0 debug3: tty_parse_modes: 31 0 debug3: tty_parse_modes: 32 0 debug3: tty_parse_modes: 33 0 debug3: tty_parse_modes: 34 0 debug3: tty_parse_modes: 35 0 debug3: tty_parse_modes: 36 1 debug3: tty_parse_modes: 38 1 debug3: tty_parse_modes: 39 1 debug3: tty_parse_modes: 40 0 debug3: tty_parse_modes: 41 1 debug3: tty_parse_modes: 50 1 debug3: tty_parse_modes: 51 1 debug3: tty_parse_modes: 53 1 debug3: tty_parse_modes: 54 1 debug3: tty_parse_modes: 55 1 debug3: tty_parse_modes: 56 0 debug3: tty_parse_modes: 57 0 debug3: tty_parse_modes: 58 0 debug3: tty_parse_modes: 59 1 debug3: tty_parse_modes: 60 1 debug3: tty_parse_modes: 61 1 debug3: tty_parse_modes: 62 1 debug3: tty_parse_modes: 70 1 debug3: tty_parse_modes: 72 1 debug3: tty_parse_modes: 73 0 debug3: tty_parse_modes: 74 0 debug3: tty_parse_modes: 75 0 debug3: tty_parse_modes: 90 1 debug3: tty_parse_modes: 91 1 debug3: tty_parse_modes: 92 0 debug3: tty_parse_modes: 93 0 debug1: server_input_channel_req: channel 0 request x11-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req x11-req debug1: bind port 6010: Cannot assign requested address debug1: bind port 6011: Cannot assign requested address debug1: bind port 6998: Cannot assign requested address debug1: bind port 6999: Cannot assign requested address Failed to allocate internet-domain X11 display socket. debug1: x11_create_display_inet failed. debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: PAM setting tty to "/dev/pts/4" debug1: PAM establishing creds debug1: fd 4 setting TCP_NODELAY debug1: channel 0: rfd 10 isatty debug1: fd 10 setting O_NONBLOCK debug2: fd 9 is O_NONBLOCK debug1: Setting controlling tty using TIOCSCTTY. My configuration (defaults and blanks stripped): # awk '!/^$|^#/ {print}' /etc/ssh/sshd_config HostKey /etc/ssh/ssh_host_key HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key SyslogFacility AUTHPRIV X11Forwarding yes X11DisplayOffset 10 UsePrivilegeSeparation yes Subsystem sftp /usr/libexec/openssh/sftp-server This is built from a source rpm from redhat (http://ftp.redhat.com/pub/redhat/linux/rawhide/SRPMS/SRPMS/openssh-3.5p 1-3.src.rpm) I modified the openssh.spec file slightly: # diff -u openssh.spec openssh.spec.orig --- openssh.spec 2003-01-21 11:31:15.000000000 -0700 +++ openssh.spec.orig 2003-01-21 11:30:34.000000000 -0700 @@ -9,7 +9,7 @@ %define no_x11_askpass 0 # Do we want to disable building of gnome-askpass? (1=yes 0=no) -%define no_gnome_askpass 1 +%define no_gnome_askpass 0 # Do we want to link against a static libcrypto? (1=yes 0=no) %define static_libcrypto 0 @@ -24,10 +24,10 @@ %define build6x 0 # Disable IPv6 (avoids DNS hangs on some glibc versions) -%define noip6 1 +%define noip6 0 # Do we want kerberos5 support (1=yes 0=no) -%define kerberos5 0 +%define kerberos5 1 # Whether or not /sbin/nologin exists. %define nologin 1 Also, I saw some stuff in the archives about IPV6 causing some problems. I'm not using IPV6: grep IPV6 /usr/src/linux/.config # CONFIG_IPV6 is not set I've also tried passing -4 to both the client and the server to ensure they don't get confused about v4 vs. v6. Please let me know if additional information would be helpful. I'll be more than happy to provide it. Any help would be greatly appreciated, Jim _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From download at ahpcc.unm.edu Wed Jan 22 09:58:49 2003 From: download at ahpcc.unm.edu (Jim Prewett) Date: Tue, 21 Jan 2003 15:58:49 -0700 (MST) Subject: X11 forwarding problem -- openssh-3.5p1 -- redhat 8.0 -- linux 2.4.18 In-Reply-To: <53D65D67C6AA694284F7584E25ADD3546CD8AC@nor935nte2k1.nor935.chevrontexaco.net> Message-ID: Yes, but I was too lame to remember to include that. I decided to take iptables out of the mix by doing /etc/rc.d/init.d/iptables stop (which makes all chains go to ACCEPT). iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Thanks, Jim On Tue, 21 Jan 2003, Ladner, Eric (Eric.Ladner) wrote: > You've checked 'iptables -L' to see if those ports are being REJECTEd on > the RH 8.0 box? > > Eric > > -----Original Message----- > From: Jim Prewett [mailto:download at ahpcc.unm.edu] > Sent: Tuesday, January 21, 2003 4:32 PM > To: openssh-unix-dev at mindrot.org > Subject: X11 forwarding problem -- openssh-3.5p1 -- redhat 8.0 -- linux > 2.4.18 > > > All, > I'm working on upgrading a machine from RH 6.2 to RH 8.0. I've > encountered one major (for me) snag in that I cannot get X11 forwarding > to work anymore. > > I've been google-ing the error messages all morning, with no luck. > > Here is debugging output from the server (client debugging output sent > upon request... I don't feel it is relevant). What I feel is > interesting is at the bottom of the following text block: > > # sshd -ddd -p 222 > debug1: sshd version OpenSSH_3.5p1 > debug1: private host key: #0 type 0 RSA1 > debug3: Not a RSA1 key file /etc/ssh/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 /etc/ssh/ssh_host_dsa_key. > debug1: read PEM private key done: type DSA > debug1: private host key: #2 type 2 DSA > debug1: Bind to port 222 on 0.0.0.0. > Server listening on 0.0.0.0 port 222. > Generating 768 bit RSA key. > RSA key generation complete. > debug1: Server will not fork when running in debugging mode. Connection > from 129.24.246.132 port 1179 > debug1: Client protocol version 2.0; client software version > OpenSSH_3.4p1 FreeBSD-20020702 > debug1: match: OpenSSH_3.4p1 FreeBSD-20020702 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 32411 > debug3: preauth child monitor started > debug3: mm_request_receive 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-c > bc,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c > bc,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 > 6,hmac-md5-96 > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 > 6,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-dss,ssh-rsa > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c > bc,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c > bc,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 > 6,hmac-md5-96 > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 > 6,hmac-md5-96 > debug2: kex_parse_kexinit: none > debug2: kex_parse_kexinit: none > debug2: kex_parse_kexinit: > 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 none > debug2: mac_init: found hmac-md5 > debug1: kex: server->client aes128-cbc hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received > debug3: mm_request_send entering: type 0 > debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI > debug3: monitor_read: checking request 0 > debug3: mm_answer_moduli: got parameters: 1024 2048 8192 > debug3: mm_request_receive_expect entering: type 1 > debug3: mm_request_receive entering > debug3: mm_request_send entering: type 1 > debug2: monitor_read: 0 used once, disabling now > debug3: mm_request_receive entering > debug3: mm_choose_dh: remaining 0 > debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent > debug1: dh_gen_key: priv key bits set: 121/256 > debug1: bits set: 1612/3191 > debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT > debug1: bits set: 1595/3191 > debug3: mm_key_sign entering > debug3: mm_request_send entering: type 4 > debug3: monitor_read: checking request 4 > debug3: mm_answer_sign > debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN > debug3: mm_request_receive_expect entering: type 5 > debug3: mm_request_receive entering > debug3: mm_answer_sign: signature 0x809f278(55) > debug3: mm_request_send entering: type 5 > debug2: monitor_read: 4 used once, disabling now > debug3: mm_request_receive entering > debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent > 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: KEX done > debug1: userauth-request for user download service ssh-connection method > none > debug1: attempt 0 failures 0 > debug3: mm_getpwnamallow entering > debug3: mm_request_send entering: type 6 > debug3: monitor_read: checking request 6 > debug3: mm_answer_pwnamallow > debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM > debug3: mm_request_receive_expect entering: type 7 > debug3: mm_request_receive entering > debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 > debug3: mm_request_send entering: type 7 > debug2: monitor_read: 6 used once, disabling now > debug3: mm_request_receive entering > debug2: input_userauth_request: setting up authctxt for download > debug3: mm_start_pam entering > debug3: mm_request_send entering: type 41 > debug3: mm_inform_authserv entering > debug3: monitor_read: checking request 41 > debug1: Starting up PAM with username "download" > debug3: mm_request_send entering: type 3 > debug2: input_userauth_request: try method none > debug3: mm_auth_password entering > debug3: mm_request_send entering: type 10 > debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD > debug3: mm_request_receive_expect entering: type 11 > debug3: mm_request_receive entering > debug3: Trying to reverse map address 129.24.246.132. > debug1: PAM setting rhost to "dhcp132.ahpcc.unm.edu" > debug2: monitor_read: 41 used once, disabling now > debug3: mm_request_receive entering > debug3: monitor_read: checking request 3 > debug3: mm_answer_authserv: service=ssh-connection, style= > debug2: monitor_read: 3 used once, disabling now > debug3: mm_request_receive entering > debug3: monitor_read: checking request 10 > debug3: mm_answer_authpassword: sending result 0 > debug3: mm_request_send entering: type 11 > Failed none for download from 129.24.246.132 port 1179 ssh2 > debug3: mm_request_receive entering > debug3: mm_auth_password: user not authenticated > Failed none for download from 129.24.246.132 port 1179 ssh2 > debug1: userauth-request for user download service ssh-connection method > keyboard-interactive > debug1: attempt 1 failures 1 > debug2: input_userauth_request: try method keyboard-interactive > debug1: keyboard-interactive devs > debug1: auth2_challenge: user=download devs= > debug1: kbdint_alloc: devices '' > debug2: auth2_challenge_start: devices > Failed keyboard-interactive for download from 129.24.246.132 port 1179 > ssh2 > debug1: userauth-request for user download service ssh-connection method > password > debug1: attempt 2 failures 2 > debug2: input_userauth_request: try method password > debug3: mm_auth_password entering > debug3: mm_request_send entering: type 10 > debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD > debug3: mm_request_receive_expect entering: type 11 > debug3: mm_request_receive entering > debug3: monitor_read: checking request 10 > debug1: PAM Password authentication accepted for user "download" > debug3: mm_answer_authpassword: sending result 1 > debug3: mm_request_send entering: type 11 > debug3: mm_auth_password: user authenticated > Accepted password for download from 129.24.246.132 port 1179 ssh2 > debug3: mm_send_keystate: Sending new keys: 0x809e408 0x809d4b0 > debug3: mm_newkeys_to_blob: converting 0x809e408 > debug3: mm_newkeys_to_blob: converting 0x809d4b0 > 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 > debug2: pam_acct_mgmt() = 0 > Accepted password for download from 129.24.246.132 port 1179 ssh2 > debug1: monitor_child_preauth: download has been authenticated by > privileged process > debug3: mm_get_keystate: Waiting for new keys > debug3: mm_request_receive_expect entering: type 24 > debug3: mm_request_receive entering > debug3: mm_newkeys_from_blob: 0x80a97c0(118) > debug2: mac_init: found hmac-md5 > debug3: mm_get_keystate: Waiting for second key > debug3: mm_newkeys_from_blob: 0x80a97c0(118) > debug2: mac_init: found hmac-md5 > debug3: mm_get_keystate: Getting compression state > debug3: mm_get_keystate: Getting Network I/O buffers > debug3: mm_share_sync: Share sync > debug3: mm_share_sync: Share sync end > debug2: User child is on pid 32412 > debug3: mm_request_receive entering > debug1: PAM establishing creds > debug1: permanently_set_uid: 31618/100 > debug1: newkeys: mode 0 > debug1: newkeys: mode 1 > 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 0 win 65536 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 > debug1: server_input_channel_req: channel 0 request pty-req reply 0 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req pty-req > debug1: lastlog_openseek: Couldn't open /var/log/lastlog: Permission > denied > debug1: Allocating pty. > debug3: mm_request_send entering: type 25 > debug3: monitor_read: checking request 25 > debug3: mm_answer_pty entering > debug1: session_new: init > debug1: session_new: session 0 > debug3: mm_request_send entering: type 26 > debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY > debug3: mm_request_receive_expect entering: type 26 > debug3: mm_request_receive entering > debug1: session_pty_req: session 0 alloc /dev/pts/4 > debug3: mm_answer_pty: tty /dev/pts/4 ptyfd 3 > debug3: mm_request_receive entering > debug3: tty_parse_modes: SSH2 n_bytes 251 > debug3: tty_parse_modes: ospeed 38400 > debug3: tty_parse_modes: ispeed 38400 > debug3: tty_parse_modes: 1 3 > debug3: tty_parse_modes: 2 28 > debug3: tty_parse_modes: 3 8 > debug3: tty_parse_modes: 4 21 > debug3: tty_parse_modes: 5 4 > debug3: tty_parse_modes: 6 255 > debug3: tty_parse_modes: 7 255 > debug3: tty_parse_modes: 8 17 > debug3: tty_parse_modes: 9 19 > debug3: tty_parse_modes: 10 26 > debug1: Ignoring unsupported tty mode opcode 11 (0xb) > debug3: tty_parse_modes: 12 18 > debug3: tty_parse_modes: 13 23 > debug3: tty_parse_modes: 14 22 > debug1: Ignoring unsupported tty mode opcode 17 (0x11) > debug3: tty_parse_modes: 18 15 > debug3: tty_parse_modes: 30 0 > debug3: tty_parse_modes: 31 0 > debug3: tty_parse_modes: 32 0 > debug3: tty_parse_modes: 33 0 > debug3: tty_parse_modes: 34 0 > debug3: tty_parse_modes: 35 0 > debug3: tty_parse_modes: 36 1 > debug3: tty_parse_modes: 38 1 > debug3: tty_parse_modes: 39 1 > debug3: tty_parse_modes: 40 0 > debug3: tty_parse_modes: 41 1 > debug3: tty_parse_modes: 50 1 > debug3: tty_parse_modes: 51 1 > debug3: tty_parse_modes: 53 1 > debug3: tty_parse_modes: 54 1 > debug3: tty_parse_modes: 55 1 > debug3: tty_parse_modes: 56 0 > debug3: tty_parse_modes: 57 0 > debug3: tty_parse_modes: 58 0 > debug3: tty_parse_modes: 59 1 > debug3: tty_parse_modes: 60 1 > debug3: tty_parse_modes: 61 1 > debug3: tty_parse_modes: 62 1 > debug3: tty_parse_modes: 70 1 > debug3: tty_parse_modes: 72 1 > debug3: tty_parse_modes: 73 0 > debug3: tty_parse_modes: 74 0 > debug3: tty_parse_modes: 75 0 > debug3: tty_parse_modes: 90 1 > debug3: tty_parse_modes: 91 1 > debug3: tty_parse_modes: 92 0 > debug3: tty_parse_modes: 93 0 > debug1: server_input_channel_req: channel 0 request x11-req reply 0 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req x11-req > debug1: bind port 6010: Cannot assign requested address > debug1: bind port 6011: Cannot assign requested address > > from 6010 to 6999.> > > debug1: bind port 6998: Cannot assign requested address > debug1: bind port 6999: Cannot assign requested address > Failed to allocate internet-domain X11 display socket. > debug1: x11_create_display_inet failed. > debug1: server_input_channel_req: channel 0 request shell reply 0 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req shell > debug1: PAM setting tty to "/dev/pts/4" > debug1: PAM establishing creds > debug1: fd 4 setting TCP_NODELAY > debug1: channel 0: rfd 10 isatty > debug1: fd 10 setting O_NONBLOCK > debug2: fd 9 is O_NONBLOCK > debug1: Setting controlling tty using TIOCSCTTY. > > My configuration (defaults and blanks stripped): > # awk '!/^$|^#/ {print}' /etc/ssh/sshd_config > HostKey /etc/ssh/ssh_host_key > HostKey /etc/ssh/ssh_host_rsa_key > HostKey /etc/ssh/ssh_host_dsa_key > SyslogFacility AUTHPRIV > X11Forwarding yes > X11DisplayOffset 10 > UsePrivilegeSeparation yes > Subsystem sftp /usr/libexec/openssh/sftp-server > > > This is built from a source rpm from redhat > (http://ftp.redhat.com/pub/redhat/linux/rawhide/SRPMS/SRPMS/openssh-3.5p > 1-3.src.rpm) > > I modified the openssh.spec file slightly: > # diff -u openssh.spec openssh.spec.orig > --- openssh.spec 2003-01-21 11:31:15.000000000 -0700 > +++ openssh.spec.orig 2003-01-21 11:30:34.000000000 -0700 > @@ -9,7 +9,7 @@ > %define no_x11_askpass 0 > > # Do we want to disable building of gnome-askpass? (1=yes 0=no) > -%define no_gnome_askpass 1 > +%define no_gnome_askpass 0 > > # Do we want to link against a static libcrypto? (1=yes 0=no) %define > static_libcrypto 0 @@ -24,10 +24,10 @@ %define build6x 0 > > # Disable IPv6 (avoids DNS hangs on some glibc versions) -%define noip6 > 1 > +%define noip6 0 > > # Do we want kerberos5 support (1=yes 0=no) > -%define kerberos5 0 > +%define kerberos5 1 > > # Whether or not /sbin/nologin exists. > %define nologin 1 > > > Also, I saw some stuff in the archives about IPV6 causing some problems. > I'm not using IPV6: grep IPV6 /usr/src/linux/.config # CONFIG_IPV6 is > not set > > I've also tried passing -4 to both the client and the server to ensure > they don't get confused about v4 vs. v6. > > Please let me know if additional information would be helpful. I'll be > more than happy to provide it. > > Any help would be greatly appreciated, > Jim > > > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > From download at ahpcc.unm.edu Wed Jan 22 10:10:23 2003 From: download at ahpcc.unm.edu (Jim Prewett) Date: Tue, 21 Jan 2003 16:10:23 -0700 (MST) Subject: X11 forwarding problem -- openssh-3.5p1 -- redhat 8.0 -- linux 2.4.18 In-Reply-To: <53D65D67C6AA694284F7584E25ADD3546CD8AC@nor935nte2k1.nor935.chevrontexaco.net> Message-ID: Oh yeah, one more thing, I *can* bind to those ports using another program (in this case nc). # nc -l -p 6010 hello Jim On Tue, 21 Jan 2003, Ladner, Eric (Eric.Ladner) wrote: > You've checked 'iptables -L' to see if those ports are being REJECTEd on > the RH 8.0 box? > > Eric > > -----Original Message----- > From: Jim Prewett [mailto:download at ahpcc.unm.edu] > Sent: Tuesday, January 21, 2003 4:32 PM > To: openssh-unix-dev at mindrot.org > Subject: X11 forwarding problem -- openssh-3.5p1 -- redhat 8.0 -- linux > 2.4.18 > > > All, > I'm working on upgrading a machine from RH 6.2 to RH 8.0. I've > encountered one major (for me) snag in that I cannot get X11 forwarding > to work anymore. > > I've been google-ing the error messages all morning, with no luck. > > Here is debugging output from the server (client debugging output sent > upon request... I don't feel it is relevant). What I feel is > interesting is at the bottom of the following text block: > > # sshd -ddd -p 222 > debug1: sshd version OpenSSH_3.5p1 > debug1: private host key: #0 type 0 RSA1 > debug3: Not a RSA1 key file /etc/ssh/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 /etc/ssh/ssh_host_dsa_key. > debug1: read PEM private key done: type DSA > debug1: private host key: #2 type 2 DSA > debug1: Bind to port 222 on 0.0.0.0. > Server listening on 0.0.0.0 port 222. > Generating 768 bit RSA key. > RSA key generation complete. > debug1: Server will not fork when running in debugging mode. Connection > from 129.24.246.132 port 1179 > debug1: Client protocol version 2.0; client software version > OpenSSH_3.4p1 FreeBSD-20020702 > debug1: match: OpenSSH_3.4p1 FreeBSD-20020702 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 32411 > debug3: preauth child monitor started > debug3: mm_request_receive 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-c > bc,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c > bc,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 > 6,hmac-md5-96 > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 > 6,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-dss,ssh-rsa > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c > bc,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c > bc,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 > 6,hmac-md5-96 > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 > 6,hmac-md5-96 > debug2: kex_parse_kexinit: none > debug2: kex_parse_kexinit: none > debug2: kex_parse_kexinit: > 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 none > debug2: mac_init: found hmac-md5 > debug1: kex: server->client aes128-cbc hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received > debug3: mm_request_send entering: type 0 > debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI > debug3: monitor_read: checking request 0 > debug3: mm_answer_moduli: got parameters: 1024 2048 8192 > debug3: mm_request_receive_expect entering: type 1 > debug3: mm_request_receive entering > debug3: mm_request_send entering: type 1 > debug2: monitor_read: 0 used once, disabling now > debug3: mm_request_receive entering > debug3: mm_choose_dh: remaining 0 > debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent > debug1: dh_gen_key: priv key bits set: 121/256 > debug1: bits set: 1612/3191 > debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT > debug1: bits set: 1595/3191 > debug3: mm_key_sign entering > debug3: mm_request_send entering: type 4 > debug3: monitor_read: checking request 4 > debug3: mm_answer_sign > debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN > debug3: mm_request_receive_expect entering: type 5 > debug3: mm_request_receive entering > debug3: mm_answer_sign: signature 0x809f278(55) > debug3: mm_request_send entering: type 5 > debug2: monitor_read: 4 used once, disabling now > debug3: mm_request_receive entering > debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent > 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: KEX done > debug1: userauth-request for user download service ssh-connection method > none > debug1: attempt 0 failures 0 > debug3: mm_getpwnamallow entering > debug3: mm_request_send entering: type 6 > debug3: monitor_read: checking request 6 > debug3: mm_answer_pwnamallow > debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM > debug3: mm_request_receive_expect entering: type 7 > debug3: mm_request_receive entering > debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 > debug3: mm_request_send entering: type 7 > debug2: monitor_read: 6 used once, disabling now > debug3: mm_request_receive entering > debug2: input_userauth_request: setting up authctxt for download > debug3: mm_start_pam entering > debug3: mm_request_send entering: type 41 > debug3: mm_inform_authserv entering > debug3: monitor_read: checking request 41 > debug1: Starting up PAM with username "download" > debug3: mm_request_send entering: type 3 > debug2: input_userauth_request: try method none > debug3: mm_auth_password entering > debug3: mm_request_send entering: type 10 > debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD > debug3: mm_request_receive_expect entering: type 11 > debug3: mm_request_receive entering > debug3: Trying to reverse map address 129.24.246.132. > debug1: PAM setting rhost to "dhcp132.ahpcc.unm.edu" > debug2: monitor_read: 41 used once, disabling now > debug3: mm_request_receive entering > debug3: monitor_read: checking request 3 > debug3: mm_answer_authserv: service=ssh-connection, style= > debug2: monitor_read: 3 used once, disabling now > debug3: mm_request_receive entering > debug3: monitor_read: checking request 10 > debug3: mm_answer_authpassword: sending result 0 > debug3: mm_request_send entering: type 11 > Failed none for download from 129.24.246.132 port 1179 ssh2 > debug3: mm_request_receive entering > debug3: mm_auth_password: user not authenticated > Failed none for download from 129.24.246.132 port 1179 ssh2 > debug1: userauth-request for user download service ssh-connection method > keyboard-interactive > debug1: attempt 1 failures 1 > debug2: input_userauth_request: try method keyboard-interactive > debug1: keyboard-interactive devs > debug1: auth2_challenge: user=download devs= > debug1: kbdint_alloc: devices '' > debug2: auth2_challenge_start: devices > Failed keyboard-interactive for download from 129.24.246.132 port 1179 > ssh2 > debug1: userauth-request for user download service ssh-connection method > password > debug1: attempt 2 failures 2 > debug2: input_userauth_request: try method password > debug3: mm_auth_password entering > debug3: mm_request_send entering: type 10 > debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD > debug3: mm_request_receive_expect entering: type 11 > debug3: mm_request_receive entering > debug3: monitor_read: checking request 10 > debug1: PAM Password authentication accepted for user "download" > debug3: mm_answer_authpassword: sending result 1 > debug3: mm_request_send entering: type 11 > debug3: mm_auth_password: user authenticated > Accepted password for download from 129.24.246.132 port 1179 ssh2 > debug3: mm_send_keystate: Sending new keys: 0x809e408 0x809d4b0 > debug3: mm_newkeys_to_blob: converting 0x809e408 > debug3: mm_newkeys_to_blob: converting 0x809d4b0 > 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 > debug2: pam_acct_mgmt() = 0 > Accepted password for download from 129.24.246.132 port 1179 ssh2 > debug1: monitor_child_preauth: download has been authenticated by > privileged process > debug3: mm_get_keystate: Waiting for new keys > debug3: mm_request_receive_expect entering: type 24 > debug3: mm_request_receive entering > debug3: mm_newkeys_from_blob: 0x80a97c0(118) > debug2: mac_init: found hmac-md5 > debug3: mm_get_keystate: Waiting for second key > debug3: mm_newkeys_from_blob: 0x80a97c0(118) > debug2: mac_init: found hmac-md5 > debug3: mm_get_keystate: Getting compression state > debug3: mm_get_keystate: Getting Network I/O buffers > debug3: mm_share_sync: Share sync > debug3: mm_share_sync: Share sync end > debug2: User child is on pid 32412 > debug3: mm_request_receive entering > debug1: PAM establishing creds > debug1: permanently_set_uid: 31618/100 > debug1: newkeys: mode 0 > debug1: newkeys: mode 1 > 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 0 win 65536 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 > debug1: server_input_channel_req: channel 0 request pty-req reply 0 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req pty-req > debug1: lastlog_openseek: Couldn't open /var/log/lastlog: Permission > denied > debug1: Allocating pty. > debug3: mm_request_send entering: type 25 > debug3: monitor_read: checking request 25 > debug3: mm_answer_pty entering > debug1: session_new: init > debug1: session_new: session 0 > debug3: mm_request_send entering: type 26 > debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY > debug3: mm_request_receive_expect entering: type 26 > debug3: mm_request_receive entering > debug1: session_pty_req: session 0 alloc /dev/pts/4 > debug3: mm_answer_pty: tty /dev/pts/4 ptyfd 3 > debug3: mm_request_receive entering > debug3: tty_parse_modes: SSH2 n_bytes 251 > debug3: tty_parse_modes: ospeed 38400 > debug3: tty_parse_modes: ispeed 38400 > debug3: tty_parse_modes: 1 3 > debug3: tty_parse_modes: 2 28 > debug3: tty_parse_modes: 3 8 > debug3: tty_parse_modes: 4 21 > debug3: tty_parse_modes: 5 4 > debug3: tty_parse_modes: 6 255 > debug3: tty_parse_modes: 7 255 > debug3: tty_parse_modes: 8 17 > debug3: tty_parse_modes: 9 19 > debug3: tty_parse_modes: 10 26 > debug1: Ignoring unsupported tty mode opcode 11 (0xb) > debug3: tty_parse_modes: 12 18 > debug3: tty_parse_modes: 13 23 > debug3: tty_parse_modes: 14 22 > debug1: Ignoring unsupported tty mode opcode 17 (0x11) > debug3: tty_parse_modes: 18 15 > debug3: tty_parse_modes: 30 0 > debug3: tty_parse_modes: 31 0 > debug3: tty_parse_modes: 32 0 > debug3: tty_parse_modes: 33 0 > debug3: tty_parse_modes: 34 0 > debug3: tty_parse_modes: 35 0 > debug3: tty_parse_modes: 36 1 > debug3: tty_parse_modes: 38 1 > debug3: tty_parse_modes: 39 1 > debug3: tty_parse_modes: 40 0 > debug3: tty_parse_modes: 41 1 > debug3: tty_parse_modes: 50 1 > debug3: tty_parse_modes: 51 1 > debug3: tty_parse_modes: 53 1 > debug3: tty_parse_modes: 54 1 > debug3: tty_parse_modes: 55 1 > debug3: tty_parse_modes: 56 0 > debug3: tty_parse_modes: 57 0 > debug3: tty_parse_modes: 58 0 > debug3: tty_parse_modes: 59 1 > debug3: tty_parse_modes: 60 1 > debug3: tty_parse_modes: 61 1 > debug3: tty_parse_modes: 62 1 > debug3: tty_parse_modes: 70 1 > debug3: tty_parse_modes: 72 1 > debug3: tty_parse_modes: 73 0 > debug3: tty_parse_modes: 74 0 > debug3: tty_parse_modes: 75 0 > debug3: tty_parse_modes: 90 1 > debug3: tty_parse_modes: 91 1 > debug3: tty_parse_modes: 92 0 > debug3: tty_parse_modes: 93 0 > debug1: server_input_channel_req: channel 0 request x11-req reply 0 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req x11-req > debug1: bind port 6010: Cannot assign requested address > debug1: bind port 6011: Cannot assign requested address > > from 6010 to 6999.> > > debug1: bind port 6998: Cannot assign requested address > debug1: bind port 6999: Cannot assign requested address > Failed to allocate internet-domain X11 display socket. > debug1: x11_create_display_inet failed. > debug1: server_input_channel_req: channel 0 request shell reply 0 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req shell > debug1: PAM setting tty to "/dev/pts/4" > debug1: PAM establishing creds > debug1: fd 4 setting TCP_NODELAY > debug1: channel 0: rfd 10 isatty > debug1: fd 10 setting O_NONBLOCK > debug2: fd 9 is O_NONBLOCK > debug1: Setting controlling tty using TIOCSCTTY. > > My configuration (defaults and blanks stripped): > # awk '!/^$|^#/ {print}' /etc/ssh/sshd_config > HostKey /etc/ssh/ssh_host_key > HostKey /etc/ssh/ssh_host_rsa_key > HostKey /etc/ssh/ssh_host_dsa_key > SyslogFacility AUTHPRIV > X11Forwarding yes > X11DisplayOffset 10 > UsePrivilegeSeparation yes > Subsystem sftp /usr/libexec/openssh/sftp-server > > > This is built from a source rpm from redhat > (http://ftp.redhat.com/pub/redhat/linux/rawhide/SRPMS/SRPMS/openssh-3.5p > 1-3.src.rpm) > > I modified the openssh.spec file slightly: > # diff -u openssh.spec openssh.spec.orig > --- openssh.spec 2003-01-21 11:31:15.000000000 -0700 > +++ openssh.spec.orig 2003-01-21 11:30:34.000000000 -0700 > @@ -9,7 +9,7 @@ > %define no_x11_askpass 0 > > # Do we want to disable building of gnome-askpass? (1=yes 0=no) > -%define no_gnome_askpass 1 > +%define no_gnome_askpass 0 > > # Do we want to link against a static libcrypto? (1=yes 0=no) %define > static_libcrypto 0 @@ -24,10 +24,10 @@ %define build6x 0 > > # Disable IPv6 (avoids DNS hangs on some glibc versions) -%define noip6 > 1 > +%define noip6 0 > > # Do we want kerberos5 support (1=yes 0=no) > -%define kerberos5 0 > +%define kerberos5 1 > > # Whether or not /sbin/nologin exists. > %define nologin 1 > > > Also, I saw some stuff in the archives about IPV6 causing some problems. > I'm not using IPV6: grep IPV6 /usr/src/linux/.config # CONFIG_IPV6 is > not set > > I've also tried passing -4 to both the client and the server to ensure > they don't get confused about v4 vs. v6. > > Please let me know if additional information would be helpful. I'll be > more than happy to provide it. > > Any help would be greatly appreciated, > Jim > > > > > > _______________________________________________ > 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 Wed Jan 22 10:14:11 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 22 Jan 2003 10:14:11 +1100 Subject: X11 forwarding problem -- openssh-3.5p1 -- redhat 8.0 -- linux 2.4.18 References: Message-ID: <3E2DD443.139A86A6@zip.com.au> Jim Prewett wrote: > I'm working on upgrading a machine from RH 6.2 to RH 8.0. I've > encountered one major (for me) snag in that I cannot get X11 forwarding to > work anymore. Make sure your hosts file contains "127.0.0.1 localhost" or equivalent, or set "X11UseLocalhost no" in sshd_config. Recent version of sshd will attempt to bind to "localhost" and it may not be able to resolve that. If that doesn't help, try stracing sshd to find out why the find() fails. -- 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 download at ahpcc.unm.edu Wed Jan 22 11:06:10 2003 From: download at ahpcc.unm.edu (Jim Prewett) Date: Tue, 21 Jan 2003 17:06:10 -0700 (MST) Subject: X11 forwarding problem -- openssh-3.5p1 -- redhat 8.0 -- linux 2.4.18 In-Reply-To: <3E2DD443.139A86A6@zip.com.au> Message-ID: THANK YOU DARREN! I've tried several things in my /etc/hosts file just to "assure" myself that that wasn't the problem (one of the incarnations of that file was exactly what Darren sent). But, i'm now thinking that it may somehow be related (or that name resolution may be somehow involved). I added: X11UseLocalhost no to my sshd_config file and now everything works like a charm! I'm still puzzled (so i'll note this for posterity). The RH 8.0 install is almoast identical to the old 6.2 install. They share name servers, nis servers (same nsswitch.conf too), etc. Most of the filesystems are shared. sshd shares a configuration, etc. The versions of ssh are the same. Yet, on the 8.0 side, I can't forward X11 (without specifying X11UseLocalhost no) whereas on the 6.2 side, X11 forwarding works fine (even without X11UseLocalhost no). Many thanks to all who helped!, Jim ------------------------------------------------------------------------------- \x83\xec\x0c\x31\xc0\x31\xd2\x68\x2f\x73\x68\x21\x68\x2f\x62\x69\x6e\x89\xe3 \x88\x43\x07\x50\x50\x53\x53\xb0\x3b\xcd\x80\x89\xf6 Don't forget FreeBSD! ------------------------------------------------------------------------------- Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html On Wed, 22 Jan 2003, Darren Tucker wrote: > Jim Prewett wrote: > > I'm working on upgrading a machine from RH 6.2 to RH 8.0. I've > > encountered one major (for me) snag in that I cannot get X11 forwarding to > > work anymore. > > Make sure your hosts file contains "127.0.0.1 localhost" or equivalent, > or set "X11UseLocalhost no" in sshd_config. Recent version of sshd will > attempt to bind to "localhost" and it may not be able to resolve that. > > If that doesn't help, try stracing sshd to find out why the find() > fails. > > -- > 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. > > _______________________________________________ > 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 Wed Jan 22 12:07:56 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 22 Jan 2003 12:07:56 +1100 Subject: X11 forwarding problem -- openssh-3.5p1 -- redhat 8.0 -- linux2.4.18 References: Message-ID: <3E2DEEEB.E363F2AD@zip.com.au> Jim Prewett wrote: > I've tried several things in my /etc/hosts file just to "assure" myself > that that wasn't the problem (one of the incarnations of that file was > exactly what Darren sent). But, i'm now thinking that it may somehow be > related (or that name resolution may be somehow involved). Check /etc/nsswitch.conf and make sure you're using the hosts file, eg hosts: files dns Also try "nslookup localhost", maybe your DNS is returning bogus data. -- 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 avraham.fraenkel at commatch.com Wed Jan 22 23:41:37 2003 From: avraham.fraenkel at commatch.com (Avraham Fraenkel - Commatch) Date: Wed, 22 Jan 2003 14:41:37 +0200 Subject: ssh channel window and adjustment Message-ID: 1) I think you should mail to: openssh-unix-dev at mindrot.org 2) I think that you have some miss-understood: the client and server count the window independtly. It mean: concerning data sent from client to the server: the SERVER set it initial window size and whenever he ready to get more data he sent adjust. such data can be a user command which generate a lot of output in the other directotion. concerning data sent from server to the client the CLIENT set his initial window size and after he have place to process more data he send adjust to the server, so the server can proceed to send the output to the client. The openssh sends adjust to the server if the client succeed to process half the max window size. it is not depend about how much data he sent to the server. it depend how much data he send to the stdout of the client!!! -- Avraham (mailto:avhf at alum.cs.huji.ac.il) -----Original Message----- From: Sombody Somewhere [mailto:koda_e at yahoo.com] Sent: Wednesday, January 22, 2003 2:20 PM To: ietf-ssh at netbsd.org Subject: Re: ssh channel window and adjustment Hi all! Thank you for your replies. Basicly your opinions confirmed my theory about the implementations and standards ;). Recently I investigated the OpenSSH client behaviour. It seems to me that OpenSSH client sends SSH_MSG_CHANNEL_WINDOW_ADJUST, when it writes more than the half of its own channel window size(the initial channel window size it is sending to its peer,when opening new channel). I think that this behaviuor may be quite incorrect. Here is an example of such situation: let's say the user using OpenSSH client sends commands to th SSH server and if we suppose these commands have big console output, then OpenSSH client's channel window may be filled much faster than the server's channel window space,but the server is obliged no to write its output untill the client sends it adjust message. This way the server is obliged to allocate great amount of data and keep it allocated untill the the amount of data written by the client exceeds the half of its own channel. Just then the server will recieve adjust. In my opinion the adjust message sneding has to be dependent on amount of data read not written. I would appreciate any comments on my opinion and thank you again for your attention :) P.S. I am afraid that this posting maybe treated as out of topic but I think that people developing the OpenSSH are reading this mail list and also I think that if my opinion is generally wrong(having in mind the drafts) this is the place to be corrected ;) __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From koda_e at yahoo.com Thu Jan 23 00:34:47 2003 From: koda_e at yahoo.com (Sombody Somewhere) Date: Wed, 22 Jan 2003 05:34:47 -0800 (PST) Subject: ssh channel window and adjustment In-Reply-To: <1043241959.13221.6.camel@prak> Message-ID: <20030122133447.22642.qmail@web40304.mail.yahoo.com> Hi Jon! I checked the code and I saw that I made a mistake - sorry for the wrong post :( Thank you very much for the reply! __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From download at ahpcc.unm.edu Thu Jan 23 06:25:19 2003 From: download at ahpcc.unm.edu (Jim Prewett) Date: Wed, 22 Jan 2003 12:25:19 -0700 (MST) Subject: changing domain name -- what will break? Message-ID: All, I'm just about to change my domain name. I'm wondering what problems to expect related to openssh. I want to change as little as possible (no new keys, etc.) So far, I've seen that I'll need to modify my system-wide ssh_known_hosts[2] files and my users known_hosts[2] files (I'm planning on providing them a simple shell script that basically runs something like sed 's/olddomain.edu/newdomain.edu/g' and encouraging them to run it). In the ssh_configs, I may have to change any of the Host declarations. Again a little sed (like above) seems like it would work. In my experience, the user's keys are independant of the host on which they were generated. What (if anything) am I missing? Am I just being overly paranoid? I can find no mention of this in the FAQ nor the list archives. Thanks, Jim From djm at mindrot.org Thu Jan 23 17:18:13 2003 From: djm at mindrot.org (Damien Miller) Date: Thu, 23 Jan 2003 17:18:13 +1100 Subject: New PAM kbd-int code Message-ID: <3E2F8925.2040600@mindrot.org> http://www.mindrot.org/~djm/openssh/openssh-newpam-20030123.tar.gz Is a snapshot of the new PAM-via-KbdInt authentication support from FreeBSD's OpenSSH tree. Please test this now. I can only surmise by the silence that has greeted my previous requests for testing that the code works perfectly. -d From bugzilla-daemon at mindrot.org Thu Jan 23 17:14:22 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 23 Jan 2003 17:14:22 +1100 (EST) Subject: [Bug 472] New: scp won't accept 'hash' character in usernames, ssh will Message-ID: <20030123061422.7666364875@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=472 Summary: scp won't accept 'hash' character in usernames, ssh will Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: chuzwuzza at optusnet.com.au I have a web server with which the only method of uploading my files to is scp. It uses a system called Ensim, which creates virtual unix accounts (or somethign) so my username which I ssh and scp with ends up being username#domainname.com ssh lets me log in fine with this name, and other windows scp clients let me use it as well. The unix scp openssh client unfortunately does not. I would attach a (one-liner) patch I have to fix this, but I can't see anywhere to attach it... Anyway, it just involves changing the if statement on line 1016 of scp.c to add && c != '#' to 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 Thu Jan 23 17:15:22 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 23 Jan 2003 17:15:22 +1100 (EST) Subject: [Bug 472] scp won't accept 'hash' character in usernames, ssh will Message-ID: <20030123061522.C52E264879@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=472 ------- Additional Comments From chuzwuzza at optusnet.com.au 2003-01-23 17:15 ------- Created an attachment (id=207) --> (http://bugzilla.mindrot.org/attachment.cgi?id=207&action=view) Patch to allow 'hash' character in scp usernames ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Thu Jan 23 19:08:28 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 23 Jan 2003 19:08:28 +1100 Subject: New PAM kbd-int code References: <3E2F8925.2040600@mindrot.org> Message-ID: <3E2FA2FC.7A73CD63@zip.com.au> Damien Miller wrote: > http://www.mindrot.org/~djm/openssh/openssh-newpam-20030123.tar.gz > Is a snapshot of the new PAM-via-KbdInt authentication support from > FreeBSD's OpenSSH tree. I've just caught up with the regress/ update from yesterday [1]. I've also added PAM configurations to the tinderbox [2]. The patch applies cleanly to the snapshot, so if you're game you can run the regression suite as follows: $ cd openssh-newpam-20030123 $ patch -p0 Please test this now. I can only surmise by the silence that has greeted > my previous requests for testing that the code works perfectly. Wow, that's, err, optimistic :-) FWIW, I get the following results: Redhat 8.0: * can log in via keyboard-interactive * passes regression tests * CHANGE_EXPIRED_AUTHTOK doesn't seem to work with or w/out privsep. W/out privsep, sshd gives: Postponed keyboard-interactive for testuser from 192.168.1.1 port 2068 ssh2 debug2: PAM: sshpam_respond debug3: ssh_msg_send: type 6 debug3: ssh_msg_recv entering debug3: ssh_msg_send: type 3 debug3: ssh_msg_send: type 7 debug3: ssh_msg_recv entering PAM: Authentication token is no longer valid; new one required. debug2: auth2_challenge_start: devices Failed keyboard-interactive/pam for testuser from 192.168.1.1 port 2068 ssh2 debug1: userauth-request for user testuser service ssh-connection method keyboard-interactive debug1: attempt 7 failures 7 HP-UX 11.00: * sshd core dumps on login [3] Solaris 8: * can log in via keyboard-interactive * passes regression tests * CHANGE_EXPIRED_AUTHTOK doesn't seem to work (same messages as redhat) Refs. [1] http://www.zip.com.au/~dtucker/openssh/regress/openssh-regressport2.patch [2] http://dodgynet.dyndns.org/tinderbox/OpenSSH_Portable/status.html [3] http://www.zip.com.au/~dtucker/openssh/regress/hpux11-newpam-sshd.log -- 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 janfrode at parallab.no Fri Jan 24 02:34:11 2003 From: janfrode at parallab.no (Jan-Frode Myklebust) Date: Thu, 23 Jan 2003 16:34:11 +0100 Subject: status of /bin/passwd expiry patch? Message-ID: <20030123163411.A10471@ii.uib.no> Hi! What's the status of your password expiry patch for AIX? Do you have a working one using /bin/passwd and privsep? -jf From jdennis at law.harvard.edu Fri Jan 24 06:35:14 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Thu, 23 Jan 2003 14:35:14 -0500 Subject: patched tarballs Message-ID: <3E3043F2.8020107@law.harvard.edu> Hello everyone, As some of you may know, I maintain a patch that puts a '.' chroot hack into OpenSSH. Unfortunately users seem to have had trouble applying the patch. This is because I use gnu's patch and diff and many systems come with a patch and diff that doesn't seem to understand -u or -N. Anyway... the point of this email is to ask if anyone had any objections to me posting a patched source tarball on the same site I distribute the patch on. I know it's ok as far as the license goes thanks to lines 196-214 of the license, but as I really like the work you guys/gals do I'd rather make sure you guys were ok with it too. -- James Dennis Harvard Law School "Not everything that counts can be counted, and not everything that can be counted counts." From jmknoble at pobox.com Fri Jan 24 07:27:24 2003 From: jmknoble at pobox.com (Jim Knoble) Date: Thu, 23 Jan 2003 15:27:24 -0500 Subject: patched tarballs In-Reply-To: <3E3043F2.8020107@law.harvard.edu> References: <3E3043F2.8020107@law.harvard.edu> Message-ID: <20030123202724.GB12421@crawfish.ais.com> Circa 2003-01-23 14:35:14 -0500 dixit James Dennis: : As some of you may know, I maintain a patch that puts a '.' chroot hack : into OpenSSH. Unfortunately users seem to have had trouble applying the : patch. This is because I use gnu's patch and diff and many systems come : with a patch and diff that doesn't seem to understand -u or -N. : : Anyway... the point of this email is to ask if anyone had any objections : to me posting a patched source tarball on the same site I distribute the : patch on. I know it's ok as far as the license goes thanks to lines : 196-214 of the license, but as I really like the work you guys/gals do : I'd rather make sure you guys were ok with it too. IMHO, there's no excuse for anyone not to install GNU diffutils and GNU patch on any system where software is compiled. Others' opinions may differ. -- 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/20030123/5ce8bf47/attachment.bin From dtucker at zip.com.au Fri Jan 24 08:23:27 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 24 Jan 2003 08:23:27 +1100 Subject: status of /bin/passwd expiry patch? References: <20030123163411.A10471@ii.uib.no> Message-ID: <3E305D4F.5AC4BB2A@zip.com.au> Jan-Frode Myklebust wrote: > What's the status of your password expiry patch for AIX? Do you have a > working one using /bin/passwd and privsep? Yes. See http://bugzilla.mindrot.org/show_bug.cgi?id=14 for a diff against the CVS tree or http://www.zip.com.au/~dtucker/openssh/openssh-3.5p1-passexpire12.patch for a diff against the 3.5p1 release. Patch 12 works with AIX and /etc/shadow platforms, 13 adds HP-UX non-trusted configuration and I have an unpublished one that does HP-UX trusted config too (the same binary will work on both trusted and non-trusted), but it's a lot of code. I'm about to do one last cleanup of the patch (deleting the HP-UX support) with the aim of getting the diff size down and getting it merged. If that patch gets in, I'll do another patch to generalize the expiry support and put HP-UX back. It's trickier than it sounds because selection of the expiry method can happen at compile time or run time in some cases. -Daz. From download at ahpcc.unm.edu Fri Jan 24 11:45:21 2003 From: download at ahpcc.unm.edu (Jim Prewett) Date: Thu, 23 Jan 2003 17:45:21 -0700 (MST) Subject: SOLVED! Re: X11 forwarding problem -- openssh-3.5p1 -- redhat 8.0 -- linux 2.4.18 In-Reply-To: Message-ID: Ok, I'm an idiot! The solution was to configure the loopback interface on that host (D'oh!). I've *NEVER* encountered a situation in which it was not set to 127.0.0.1 before now. I didn't even think to check. Quite frankly, i'm amazed that more things didn't break. Many thanks to all who helped! Apologies for wasting everyone's time, Jim On Tue, 21 Jan 2003, Jim Prewett wrote: > All, > I'm working on upgrading a machine from RH 6.2 to RH 8.0. I've > encountered one major (for me) snag in that I cannot get X11 forwarding to > work anymore. > > I've been google-ing the error messages all morning, with no luck. > > Here is debugging output from the server (client debugging output sent > upon request... I don't feel it is relevant). What I feel is interesting > is at the bottom of the following text block: > > # sshd -ddd -p 222 > debug1: sshd version OpenSSH_3.5p1 > debug1: private host key: #0 type 0 RSA1 > debug3: Not a RSA1 key file /etc/ssh/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 /etc/ssh/ssh_host_dsa_key. > debug1: read PEM private key done: type DSA > debug1: private host key: #2 type 2 DSA > debug1: Bind to port 222 on 0.0.0.0. > Server listening on 0.0.0.0 port 222. > Generating 768 bit RSA key. > RSA key generation complete. > debug1: Server will not fork when running in debugging mode. > Connection from 129.24.246.132 port 1179 > debug1: Client protocol version 2.0; client software version OpenSSH_3.4p1 > FreeBSD-20020702 > debug1: match: OpenSSH_3.4p1 FreeBSD-20020702 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 32411 > debug3: preauth child monitor started > debug3: mm_request_receive 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-dss,ssh-rsa > 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 > debug2: kex_parse_kexinit: none > debug2: kex_parse_kexinit: > 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 none > debug2: mac_init: found hmac-md5 > debug1: kex: server->client aes128-cbc hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received > debug3: mm_request_send entering: type 0 > debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI > debug3: monitor_read: checking request 0 > debug3: mm_answer_moduli: got parameters: 1024 2048 8192 > debug3: mm_request_receive_expect entering: type 1 > debug3: mm_request_receive entering > debug3: mm_request_send entering: type 1 > debug2: monitor_read: 0 used once, disabling now > debug3: mm_request_receive entering > debug3: mm_choose_dh: remaining 0 > debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent > debug1: dh_gen_key: priv key bits set: 121/256 > debug1: bits set: 1612/3191 > debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT > debug1: bits set: 1595/3191 > debug3: mm_key_sign entering > debug3: mm_request_send entering: type 4 > debug3: monitor_read: checking request 4 > debug3: mm_answer_sign > debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN > debug3: mm_request_receive_expect entering: type 5 > debug3: mm_request_receive entering > debug3: mm_answer_sign: signature 0x809f278(55) > debug3: mm_request_send entering: type 5 > debug2: monitor_read: 4 used once, disabling now > debug3: mm_request_receive entering > debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent > 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: KEX done > debug1: userauth-request for user download service ssh-connection method > none > debug1: attempt 0 failures 0 > debug3: mm_getpwnamallow entering > debug3: mm_request_send entering: type 6 > debug3: monitor_read: checking request 6 > debug3: mm_answer_pwnamallow > debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM > debug3: mm_request_receive_expect entering: type 7 > debug3: mm_request_receive entering > debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 > debug3: mm_request_send entering: type 7 > debug2: monitor_read: 6 used once, disabling now > debug3: mm_request_receive entering > debug2: input_userauth_request: setting up authctxt for download > debug3: mm_start_pam entering > debug3: mm_request_send entering: type 41 > debug3: mm_inform_authserv entering > debug3: monitor_read: checking request 41 > debug1: Starting up PAM with username "download" > debug3: mm_request_send entering: type 3 > debug2: input_userauth_request: try method none > debug3: mm_auth_password entering > debug3: mm_request_send entering: type 10 > debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD > debug3: mm_request_receive_expect entering: type 11 > debug3: mm_request_receive entering > debug3: Trying to reverse map address 129.24.246.132. > debug1: PAM setting rhost to "dhcp132.ahpcc.unm.edu" > debug2: monitor_read: 41 used once, disabling now > debug3: mm_request_receive entering > debug3: monitor_read: checking request 3 > debug3: mm_answer_authserv: service=ssh-connection, style= > debug2: monitor_read: 3 used once, disabling now > debug3: mm_request_receive entering > debug3: monitor_read: checking request 10 > debug3: mm_answer_authpassword: sending result 0 > debug3: mm_request_send entering: type 11 > Failed none for download from 129.24.246.132 port 1179 ssh2 > debug3: mm_request_receive entering > debug3: mm_auth_password: user not authenticated > Failed none for download from 129.24.246.132 port 1179 ssh2 > debug1: userauth-request for user download service ssh-connection method > keyboard-interactive > debug1: attempt 1 failures 1 > debug2: input_userauth_request: try method keyboard-interactive > debug1: keyboard-interactive devs > debug1: auth2_challenge: user=download devs= > debug1: kbdint_alloc: devices '' > debug2: auth2_challenge_start: devices > Failed keyboard-interactive for download from 129.24.246.132 port 1179 > ssh2 > debug1: userauth-request for user download service ssh-connection method > password > debug1: attempt 2 failures 2 > debug2: input_userauth_request: try method password > debug3: mm_auth_password entering > debug3: mm_request_send entering: type 10 > debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD > debug3: mm_request_receive_expect entering: type 11 > debug3: mm_request_receive entering > debug3: monitor_read: checking request 10 > debug1: PAM Password authentication accepted for user "download" > debug3: mm_answer_authpassword: sending result 1 > debug3: mm_request_send entering: type 11 > debug3: mm_auth_password: user authenticated > Accepted password for download from 129.24.246.132 port 1179 ssh2 > debug3: mm_send_keystate: Sending new keys: 0x809e408 0x809d4b0 > debug3: mm_newkeys_to_blob: converting 0x809e408 > debug3: mm_newkeys_to_blob: converting 0x809d4b0 > 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 > debug2: pam_acct_mgmt() = 0 > Accepted password for download from 129.24.246.132 port 1179 ssh2 > debug1: monitor_child_preauth: download has been authenticated by > privileged process > debug3: mm_get_keystate: Waiting for new keys > debug3: mm_request_receive_expect entering: type 24 > debug3: mm_request_receive entering > debug3: mm_newkeys_from_blob: 0x80a97c0(118) > debug2: mac_init: found hmac-md5 > debug3: mm_get_keystate: Waiting for second key > debug3: mm_newkeys_from_blob: 0x80a97c0(118) > debug2: mac_init: found hmac-md5 > debug3: mm_get_keystate: Getting compression state > debug3: mm_get_keystate: Getting Network I/O buffers > debug3: mm_share_sync: Share sync > debug3: mm_share_sync: Share sync end > debug2: User child is on pid 32412 > debug3: mm_request_receive entering > debug1: PAM establishing creds > debug1: permanently_set_uid: 31618/100 > debug1: newkeys: mode 0 > debug1: newkeys: mode 1 > 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 0 win 65536 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 > debug1: server_input_channel_req: channel 0 request pty-req reply 0 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req pty-req > debug1: lastlog_openseek: Couldn't open /var/log/lastlog: Permission > denied > debug1: Allocating pty. > debug3: mm_request_send entering: type 25 > debug3: monitor_read: checking request 25 > debug3: mm_answer_pty entering > debug1: session_new: init > debug1: session_new: session 0 > debug3: mm_request_send entering: type 26 > debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY > debug3: mm_request_receive_expect entering: type 26 > debug3: mm_request_receive entering > debug1: session_pty_req: session 0 alloc /dev/pts/4 > debug3: mm_answer_pty: tty /dev/pts/4 ptyfd 3 > debug3: mm_request_receive entering > debug3: tty_parse_modes: SSH2 n_bytes 251 > debug3: tty_parse_modes: ospeed 38400 > debug3: tty_parse_modes: ispeed 38400 > debug3: tty_parse_modes: 1 3 > debug3: tty_parse_modes: 2 28 > debug3: tty_parse_modes: 3 8 > debug3: tty_parse_modes: 4 21 > debug3: tty_parse_modes: 5 4 > debug3: tty_parse_modes: 6 255 > debug3: tty_parse_modes: 7 255 > debug3: tty_parse_modes: 8 17 > debug3: tty_parse_modes: 9 19 > debug3: tty_parse_modes: 10 26 > debug1: Ignoring unsupported tty mode opcode 11 (0xb) > debug3: tty_parse_modes: 12 18 > debug3: tty_parse_modes: 13 23 > debug3: tty_parse_modes: 14 22 > debug1: Ignoring unsupported tty mode opcode 17 (0x11) > debug3: tty_parse_modes: 18 15 > debug3: tty_parse_modes: 30 0 > debug3: tty_parse_modes: 31 0 > debug3: tty_parse_modes: 32 0 > debug3: tty_parse_modes: 33 0 > debug3: tty_parse_modes: 34 0 > debug3: tty_parse_modes: 35 0 > debug3: tty_parse_modes: 36 1 > debug3: tty_parse_modes: 38 1 > debug3: tty_parse_modes: 39 1 > debug3: tty_parse_modes: 40 0 > debug3: tty_parse_modes: 41 1 > debug3: tty_parse_modes: 50 1 > debug3: tty_parse_modes: 51 1 > debug3: tty_parse_modes: 53 1 > debug3: tty_parse_modes: 54 1 > debug3: tty_parse_modes: 55 1 > debug3: tty_parse_modes: 56 0 > debug3: tty_parse_modes: 57 0 > debug3: tty_parse_modes: 58 0 > debug3: tty_parse_modes: 59 1 > debug3: tty_parse_modes: 60 1 > debug3: tty_parse_modes: 61 1 > debug3: tty_parse_modes: 62 1 > debug3: tty_parse_modes: 70 1 > debug3: tty_parse_modes: 72 1 > debug3: tty_parse_modes: 73 0 > debug3: tty_parse_modes: 74 0 > debug3: tty_parse_modes: 75 0 > debug3: tty_parse_modes: 90 1 > debug3: tty_parse_modes: 91 1 > debug3: tty_parse_modes: 92 0 > debug3: tty_parse_modes: 93 0 > debug1: server_input_channel_req: channel 0 request x11-req reply 0 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req x11-req > debug1: bind port 6010: Cannot assign requested address > debug1: bind port 6011: Cannot assign requested address > > from 6010 to 6999.> > > debug1: bind port 6998: Cannot assign requested address > debug1: bind port 6999: Cannot assign requested address > Failed to allocate internet-domain X11 display socket. > debug1: x11_create_display_inet failed. > debug1: server_input_channel_req: channel 0 request shell reply 0 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req shell > debug1: PAM setting tty to "/dev/pts/4" > debug1: PAM establishing creds > debug1: fd 4 setting TCP_NODELAY > debug1: channel 0: rfd 10 isatty > debug1: fd 10 setting O_NONBLOCK > debug2: fd 9 is O_NONBLOCK > debug1: Setting controlling tty using TIOCSCTTY. > > My configuration (defaults and blanks stripped): > # awk '!/^$|^#/ {print}' /etc/ssh/sshd_config > HostKey /etc/ssh/ssh_host_key > HostKey /etc/ssh/ssh_host_rsa_key > HostKey /etc/ssh/ssh_host_dsa_key > SyslogFacility AUTHPRIV > X11Forwarding yes > X11DisplayOffset 10 > UsePrivilegeSeparation yes > Subsystem sftp /usr/libexec/openssh/sftp-server > > > This is built from a source rpm from redhat > (http://ftp.redhat.com/pub/redhat/linux/rawhide/SRPMS/SRPMS/openssh-3.5p1-3.src.rpm) > > I modified the openssh.spec file slightly: > # diff -u openssh.spec openssh.spec.orig > --- openssh.spec 2003-01-21 11:31:15.000000000 -0700 > +++ openssh.spec.orig 2003-01-21 11:30:34.000000000 -0700 > @@ -9,7 +9,7 @@ > %define no_x11_askpass 0 > > # Do we want to disable building of gnome-askpass? (1=yes 0=no) > -%define no_gnome_askpass 1 > +%define no_gnome_askpass 0 > > # Do we want to link against a static libcrypto? (1=yes 0=no) > %define static_libcrypto 0 > @@ -24,10 +24,10 @@ > %define build6x 0 > > # Disable IPv6 (avoids DNS hangs on some glibc versions) > -%define noip6 1 > +%define noip6 0 > > # Do we want kerberos5 support (1=yes 0=no) > -%define kerberos5 0 > +%define kerberos5 1 > > # Whether or not /sbin/nologin exists. > %define nologin 1 > > > Also, I saw some stuff in the archives about IPV6 causing some > problems. I'm not using IPV6: > grep IPV6 /usr/src/linux/.config > # CONFIG_IPV6 is not set > > I've also tried passing -4 to both the client and the server to ensure > they don't get confused about v4 vs. v6. > > Please let me know if additional information would be helpful. I'll be > more than happy to provide it. > > Any help would be greatly appreciated, > Jim > > > > > > From janfrode at parallab.no Fri Jan 24 19:29:42 2003 From: janfrode at parallab.no (Jan-Frode Myklebust) Date: Fri, 24 Jan 2003 09:29:42 +0100 Subject: status of /bin/passwd expiry patch? In-Reply-To: <3E305D4F.5AC4BB2A@zip.com.au>; from dtucker@zip.com.au on Fri, Jan 24, 2003 at 08:23:27AM +1100 References: <20030123163411.A10471@ii.uib.no> <3E305D4F.5AC4BB2A@zip.com.au> Message-ID: <20030124092942.A13779@ii.uib.no> On Fri, Jan 24, 2003 at 08:23:27AM +1100, Darren Tucker wrote: > > Yes. See http://bugzilla.mindrot.org/show_bug.cgi?id=14 for a diff > against the CVS tree or > http://www.zip.com.au/~dtucker/openssh/openssh-3.5p1-passexpire12.patch > for a diff against the 3.5p1 release. Great, thanks! I just built it on AIX 5.1, and it seems to be working fine both with protocol 1 and 2. Only problem I've seen so far is that with protocol 1 X11 and agent forwarding gets disabled if I have to change my passsword. This is probably expected behaviour.. > > I'm about to do one last cleanup of the patch (deleting the HP-UX > support) with the aim of getting the diff size down and getting it > merged. Crossing my fingers hoping this gets in.. -jf From cucinotta at sssup.it Sat Jan 25 03:14:47 2003 From: cucinotta at sssup.it (Tommaso Cucinotta) Date: Fri, 24 Jan 2003 17:14:47 +0100 Subject: OpenSSH-MuscleCard-3.5p1 Released Message-ID: <3E316677.D77EB383@sssup.it> Hi all, a new OpenSSH-MCard package has been released, by integrating latest OpenSSH package for Linux (3.5p1) with latest PCSC-Lite / MuscleCard smart card middleware (v1.1.1), within the SmartSign project. It can be downloaded at the URL: http://smartsign.sourceforge.net Differences with previous release include: -) update to latest MuscleCard and Applet -) ability to use more keys onto a same card -) ability to specify the key numbers at run-time, by providing optional command-line options to ssh-add and ssh-keygen -) URI-like syntax in ssh-add allows mixed loading of file-keys and card-keys -) better separation of the MuscleCard support with respect to the original OpenSSH package -) compiled on FreeBSD-4.7 Further details follow at the bottom of this message. Please, try out the package and post comments to the Smart Sign mailing lists: mailto:smartsign-users at lists.sourceforge.net mailto:smartsign-devel at lists.sourceforge.net Bye, Tommaso. -- ,------------------------------------------------. | Dr. Tommaso Cucinotta | >------------------------------------------------< ! Scuola Superiore di Studi Universitari ! ! e Perfezionamento S.Anna ! ! Pisa Italy ! `------------------------------------------------' From bugzilla-daemon at mindrot.org Sat Jan 25 03:40:51 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 25 Jan 2003 03:40:51 +1100 (EST) Subject: [Bug 2] sshd should have BSM auditing on Solaris Message-ID: <20030124164051.D7C1D64875@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=2 Michael.Gerdts at med.ge.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|Michael.Gerdts at alcatel.com |Michael.Gerdts at med.ge.com ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dubu0874 at uidaho.edu Sat Jan 25 07:20:02 2003 From: dubu0874 at uidaho.edu (dubu0874 at uidaho.edu) Date: Fri, 24 Jan 2003 12:20:02 -0800 Subject: Question on Architecture Message-ID: <13f28613e5cf.13e5cf13f286@uidaho.edu> I have recently been trying to recipher the data being sent by openssh and have a few questions ment to smooth the road some. I am able to send and recieve data up till the password is sent. Once the password is entered the client gets the oh so loved: "Disconnecting: Bad packet length ########." I have added my recipher scheme to work on the streams at packet_read_seqnr and packet_write_poll. Is there a section in the code specifically made to handle the sending of the password that I am not accounting for? Can anyone think of another area data is send or recieved that I will need to had my cipher scheme to? Thanks to all help in advance. Thomas M. DuBuisson Assistant Researcher Center for Secure and Dependable Systems From bugzilla-daemon at mindrot.org Sat Jan 25 08:44:31 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 25 Jan 2003 08:44:31 +1100 (EST) Subject: [Bug 473] New: cannot update password using PAM on HP-UX system that has been tsconverted Message-ID: <20030124214431.E822464875@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=473 Summary: cannot update password using PAM on HP-UX system that has been tsconverted Product: Portable OpenSSH Version: older versions Platform: All OS/Version: HP-UX Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: rusr at cup.hp.com With OpenSSH3.1p1 using PAM, there is a problem logging in if the password is expired and the server system has been converted to use commercial security mode with the /etc/tsconvert command. Problem description: If a user has an expired password, they can not login using ssh. When they attempt to login, the system detects the expired password and forces the user to change it before they can complete the login. However, if you have converted to comsec, HP's pam_unix checks the UID (must be the uid of the user logging in) and the EUID (must be 0, aka root) before allowing the password update to proceed. However, sshd always has UID == EUID == 0, so the password change fails and the user is logged out, effectively locking the user out of the system (unless they use some other method of logging in, such as rlogin or telnet). A possible fix for this involves passing the user's password entry from session.c to do_pam_chauthtok(). do_pam_chauthtok() then changes the RUID to the user's uid, call pam_chauthtok(), and changes it back after the call. I am including some diffs of the fix as I made it - the official version may wish to have it enclosed in #ifdef's. diff auth-pam.h /extra/openssh-3.1p1/auth-pam.h | more 1c1 < /* $Id: auth-pam.h,v 1.3 2002/05/14 16:35:43 cvsuser Exp $ */ --- > /* $Id: auth-pam.h,v 1.11 2001/03/27 06:12:24 djm Exp $ */ 18c18 < void do_pam_chauthtok(struct passwd *pw); --- > void do_pam_chauthtok(void); diff auth-pam.c /extra/openssh-3.1p1/auth-pam.c | more 38c38 < RCSID("$Id: auth-pam.c,v 1.3 2002/05/14 16:35:43 cvsuser Exp $"); --- > RCSID("$Id: auth-pam.c,v 1.42 2002/02/05 01:40:47 djm Exp $"); 146d145 < 326c325 < void do_pam_chauthtok(struct passwd *pw) --- > void do_pam_chauthtok(void) 329,331d327 < uid_t current_uid; < uid_t current_euid; < int uid_set = 0; 337,340d332 < if ((geteuid() == 0) && (current_uid = getuid()) == 0) { < setreuid(pw->pw_uid, -1); < uid_set = 1; < } 342,344d333 < if (uid_set == 1) { < setuid(0); < } diff session.c /extra/openssh-3.1p1/session.c | more 718c718 < do_pam_chauthtok(pw); --- > do_pam_chauthtok(); ------- 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 Jan 25 09:20:20 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 25 Jan 2003 09:20:20 +1100 (EST) Subject: [Bug 473] cannot update password using PAM on HP-UX system that has been tsconverted Message-ID: <20030124222020.E76C464875@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=473 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From dtucker at zip.com.au 2003-01-25 09:20 ------- See also bug #423 attachment #198 for one way to make this work with privsep enabled. *** This bug has been marked as a duplicate of 423 *** ------- 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 Jan 25 09:20:22 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 25 Jan 2003 09:20:22 +1100 (EST) Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20030124222022.ADA2664877@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rusr at cup.hp.com ------- Additional Comments From dtucker at zip.com.au 2003-01-25 09:20 ------- *** Bug 473 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 Sat Jan 25 18:47:38 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 25 Jan 2003 18:47:38 +1100 Subject: Build failures: nanosleep on Solaris and AIX 4.2.x Message-ID: <3E32411A.AE6D9335@zip.com.au> Hi All. The recent changes to scp caused build failures on Solaris and AIX 4.2 which showed up on the tinderbox[1]. I mentioned the first to djm in email yesterday but I'm posting after finding the second, in case anyone else has seen similar problems. Solaris' nanosleep is in librt (or libposix4 in older versions) which is not linked. Adding them to configure works fine, however ldd show most of the binaries linked to librt.so (which is part of the core libraries package). I don't think this is a big deal (right?) AIX 4.2.1 does not have nanosleep but has an equivalent (nsleep). AIX 4.3.3 has nanosleep, I don't know about versions in between. The attached patch fixes both with one combined nanosleep test in configure and a couple of #defines. [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: acconfig.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/acconfig.h,v retrieving revision 1.147 diff -u -r1.147 acconfig.h --- acconfig.h 12 Jan 2003 23:04:59 -0000 1.147 +++ acconfig.h 25 Jan 2003 05:20:54 -0000 @@ -371,6 +371,9 @@ #undef SETPROCTITLE_STRATEGY #undef SETPROCTITLE_PS_PADDING +/* Have nanosleep() */ +#undef HAVE_NANOSLEEP + @BOTTOM@ /* ******************* Shouldn't need to edit below this line ************** */ Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v retrieving revision 1.102 diff -u -r1.102 configure.ac --- configure.ac 20 Jan 2003 04:20:25 -0000 1.102 +++ configure.ac 25 Jan 2003 06:48:20 -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,7 +604,7 @@ 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 \ + inet_ntop innetgr login_getcapbool md5_crypt memmove nsleep \ mkdtemp mmap ngetaddrinfo openpty ogetaddrinfo pstat readpassphrase \ realpath recvmsg rresvport_af sendmsg setdtablesize setegid \ setenv seteuid setgroups setlogin setproctitle setresgid setreuid \ @@ -615,6 +615,11 @@ dnl Make sure strsep prototype is defined before defining HAVE_STRSEP AC_CHECK_DECL(strsep, [AC_CHECK_FUNCS(strsep)]) + +AC_CHECK_FUNC(nanosleep, + AC_DEFINE(HAVE_NANOSLEEP), + AC_SEARCH_LIBS(nanosleep, rt posix4, AC_DEFINE(HAVE_NANOSLEEP)) +) dnl IRIX and Solaris 2.5.1 have dirname() in libgen AC_CHECK_FUNCS(dirname, [AC_CHECK_HEADERS(libgen.h)] ,[ Index: includes.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/includes.h,v retrieving revision 1.61 diff -u -r1.61 includes.h --- includes.h 21 Oct 2002 00:50:26 -0000 1.61 +++ includes.h 25 Jan 2003 07:18:36 -0000 @@ -104,6 +104,9 @@ #ifdef HAVE_SYS_TIME_H # include /* For timersub */ #endif +#ifdef HAVE_SYS_TIMERS_H +# include /* For struct timespec on AIX 4.2.x */ +#endif #include #ifdef HAVE_SYS_SELECT_H # include 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 25 Jan 2003 06:45:24 -0000 @@ -26,4 +26,12 @@ #ifdef _AIX void aix_usrinfo(struct passwd *pw); + +/* + * 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 + #endif /* _AIX */ From bugzilla-daemon at mindrot.org Sun Jan 26 01:03:16 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 26 Jan 2003 01:03:16 +1100 (EST) Subject: [Bug 85] ssh -2 localhost od /bin/ls | true ignore SIGPIPE Message-ID: <20030125140316.04BD664875@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=85 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|markus at openbsd.org |openssh-unix-dev at mindrot.org Status|ASSIGNED |NEW ------- Additional Comments From markus at openbsd.org 2003-01-26 01:03 ------- i think SIGPIPE can happen in x11-fwding and should not lead to exit(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 Sun Jan 26 05:27:56 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 26 Jan 2003 05:27:56 +1100 (EST) Subject: [Bug 474] New: sftp should provide logging Message-ID: <20030125182756.51DEB64875@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=474 Summary: sftp should provide logging Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: Solaris Status: NEW Severity: enhancement Priority: P2 Component: sftp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: kodis at mail630.gsfc.nasa.gov In a comparison between OpenSSH and the ssh.com version, a poster noted the logging provided by the ssh.com sftp daemon as a reason to prefer the ssh.com release. This seems like a worthy (and relatively simple) addition. From: "Ric Anderson" Newsgroups: comp.unix.solaris,comp.security.ssh Subject: Re: OpenSSH3.5p1 vs. Commercial SSH 3.2 I would add (Speaking only of ssh.com 3.2 vs. OpenSSH 3.5p1 using protocol 2): 3. ssh.com's product provides good logging for sftp transfers where OpenSSH provides none. ------- 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 Jan 26 05:31:37 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 26 Jan 2003 05:31:37 +1100 (EST) Subject: [Bug 475] New: sshd should source /etc/default/login Message-ID: <20030125183137.DFB1164875@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=475 Summary: sshd should source /etc/default/login Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: Solaris Status: NEW Severity: enhancement Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: kodis at mail630.gsfc.nasa.gov 4. ssh.com's product properly supports /etc/default/login on systems that have that file for setting initial values for PATH, etc. OpenSSH ignores the file. ------- 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 Jan 26 08:25:09 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 26 Jan 2003 08:25:09 +1100 (EST) Subject: [Bug 475] sshd should source /etc/default/login Message-ID: <20030125212509.2DD0364875@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=475 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From dtucker at zip.com.au 2003-01-26 08:25 ------- *** This bug has been marked as a duplicate of 252 *** ------- 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 Jan 26 08:25:10 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 26 Jan 2003 08:25:10 +1100 (EST) Subject: [Bug 252] Patch for use of /etc/default/login Message-ID: <20030125212510.E28BF64877@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=252 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kodis at mail630.gsfc.nasa.gov ------- Additional Comments From dtucker at zip.com.au 2003-01-26 08:25 ------- *** Bug 475 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 bugzilla-daemon at mindrot.org Sun Jan 26 22:19:25 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 26 Jan 2003 22:19:25 +1100 (EST) Subject: [Bug 474] sftp should provide logging Message-ID: <20030126111925.C6B5E64876@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=474 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Solaris |All Priority|P2 |P5 Version|3.5p1 |-current ------- Additional Comments From markus at openbsd.org 2003-01-26 22:19 ------- logging in sftp-server is useless, since it runs as the user. if you want sftp-server to log, recompile with -DTRACE=log ------- 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 Jan 26 22:37:56 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 26 Jan 2003 22:37:56 +1100 (EST) Subject: [Bug 472] scp won't accept 'hash' character in usernames, ssh will Message-ID: <20030126113756.6F8F464875@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=472 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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 Jan 26 22:39:51 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 26 Jan 2003 22:39:51 +1100 (EST) Subject: [Bug 469] Password field shows contents when running SQLPLUS in SSH shell Message-ID: <20030126113951.27E7664875@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=469 ------- Additional Comments From markus at openbsd.org 2003-01-26 22:39 ------- sorry, what exactly are you doing? ------- 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 Jan 26 22:42:14 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 26 Jan 2003 22:42:14 +1100 (EST) Subject: [Bug 112] Using host key fingerprint instead of "yes" Message-ID: <20030126114214.E8EF264878@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=112 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WONTFIX ------- Additional Comments From markus at openbsd.org 2003-01-26 22:42 ------- nice idea, but i don't think this will happen. ------- 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 Jan 26 22:45:17 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 26 Jan 2003 22:45:17 +1100 (EST) Subject: [Bug 132] connects to 1.2.2? vintage sshd sometimes gets "Server lies" about host key size off by 1 bit Message-ID: <20030126114517.5F9BE64875@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=132 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|markus at openbsd.org |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 bugzilla-daemon at mindrot.org Sun Jan 26 22:45:19 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 26 Jan 2003 22:45:19 +1100 (EST) Subject: [Bug 148] Key Exchange Guesses not supported Message-ID: <20030126114519.37A3B6487A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=148 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|markus at openbsd.org |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 bugzilla-daemon at mindrot.org Sun Jan 26 22:46:57 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 26 Jan 2003 22:46:57 +1100 (EST) Subject: [Bug 132] connects to 1.2.2? vintage sshd sometimes gets "Server lies" about host key size off by 1 bit Message-ID: <20030126114657.724266487E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=132 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From markus at openbsd.org 2003-01-26 22:46 ------- it's unlikely that this gets changed in the near future. these keys are IMHO broken. ------- 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 Jan 27 11:39:17 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 27 Jan 2003 11:39:17 +1100 (EST) Subject: [Bug 375] sshd core dumping with msg "Cannot delete credentials" Message-ID: <20030127003917.4655B64877@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=375 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From dtucker at zip.com.au 2003-01-27 11:39 ------- Assuming it's the fatal_cleanup() thing (there's no information to disprove this and it certainly looks like it), this is now fixed. 20030114 - markus at cvs.openbsd.org 2003/01/11 18:29:43 [log.c] set fatal_cleanups to NULL in fatal_remove_all_cleanups(); ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From openssh-unix-dev at thewrittenword.com Mon Jan 27 17:15:10 2003 From: openssh-unix-dev at thewrittenword.com (Albert Chin) Date: Mon, 27 Jan 2003 00:15:10 -0600 Subject: Build failures: nanosleep on Solaris and AIX 4.2.x In-Reply-To: <3E32411A.AE6D9335@zip.com.au> References: <3E32411A.AE6D9335@zip.com.au> Message-ID: <20030127061510.GA53617@spuckler.il.thewrittenword.com> On Sat, Jan 25, 2003 at 06:47:38PM +1100, Darren Tucker wrote: > Index: configure.ac > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v > retrieving revision 1.102 > diff -u -r1.102 configure.ac > --- configure.ac 20 Jan 2003 04:20:25 -0000 1.102 > +++ configure.ac 25 Jan 2003 06:48:20 -0000 > @@ -615,6 +615,11 @@ > > dnl Make sure strsep prototype is defined before defining HAVE_STRSEP > AC_CHECK_DECL(strsep, [AC_CHECK_FUNCS(strsep)]) > + > +AC_CHECK_FUNC(nanosleep, > + AC_DEFINE(HAVE_NANOSLEEP), > + AC_SEARCH_LIBS(nanosleep, rt posix4, AC_DEFINE(HAVE_NANOSLEEP)) > +) This is the same as: AC_SEARCH_LIBS(nanosleep, rt posix4, AC_DEFINE(HAVE_NANOSLEEP)) AC_SEARCH_LIBS will first search for nanosleep() with no libraries linked in, then iterate through -lrt and then -lposix4. Also, acconfig.h is deprecated. With the following, you don't need a HAVE_NANOSLEEP entry in acconfig.h: AC_SEARCH_LIBS(nanosleep, rt posix4, AC_DEFINE(HAVE_NANOSLEEP, 1, [If nanosleep() is available])) -- albert chin (china at thewrittenword.com) From bugzilla-daemon at mindrot.org Mon Jan 27 20:11:58 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 27 Jan 2003 20:11:58 +1100 (EST) Subject: [Bug 148] Key Exchange Guesses not supported Message-ID: <20030127091158.3964E64877@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=148 ------- Additional Comments From markus at openbsd.org 2003-01-27 20:11 ------- Created an attachment (id=208) --> (http://bugzilla.mindrot.org/attachment.cgi?id=208&action=view) new patch you need to make sure that the ',' from my[] and peer[] are replaced with \0 ------- 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 Jan 27 20:14:45 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 27 Jan 2003 20:14:45 +1100 (EST) Subject: [Bug 148] Key Exchange Guesses not supported Message-ID: <20030127091445.7A37464876@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=148 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From markus at openbsd.org 2003-01-27 20:14 ------- please check the lasted patch. this patch will probably included 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 Jan 27 20:27:19 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 27 Jan 2003 20:27:19 +1100 (EST) Subject: [Bug 463] PrintLastLog doesn't work in privsep mode Message-ID: <20030127092719.4030564876@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=463 ------- Additional Comments From markus at openbsd.org 2003-01-27 20:27 ------- hm, yes, this would make sense. something like Buffer loginmsg; ------- 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 Jan 27 20:29:59 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 27 Jan 2003 20:29:59 +1100 (EST) Subject: [Bug 476] New: Privsep directory error could be improved Message-ID: <20030127092959.D320264878@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=476 Summary: Privsep directory error could be improved Product: Portable OpenSSH Version: -current Platform: All OS/Version: Linux Status: NEW Severity: minor Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: maf at appgate.com I recentry tried the cvs-version of portable openssh, but it refused to run since the privsep directory had bad owner or mode. I had to check teh code to see which owner and mode it should have. How about modifying the error to provide this information. I will attach a patch which fixes 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 Jan 27 20:30:59 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 27 Jan 2003 20:30:59 +1100 (EST) Subject: [Bug 476] Privsep directory error could be improved Message-ID: <20030127093059.5E0F264876@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=476 ------- Additional Comments From maf at appgate.com 2003-01-27 20:30 ------- Created an attachment (id=209) --> (http://bugzilla.mindrot.org/attachment.cgi?id=209&action=view) Improves the error message ------- 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 Jan 27 21:06:21 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 27 Jan 2003 21:06:21 +1100 (EST) Subject: [Bug 476] Privsep directory error could be improved Message-ID: <20030127100621.1E76D64877@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=476 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From markus at openbsd.org 2003-01-27 21:06 ------- there's no need to check the source, sshd(8) should have all necessary information. but i'll add the message from the manpage to sshd.c ------- 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 Jan 27 21:09:46 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 27 Jan 2003 21:09:46 +1100 (EST) Subject: [Bug 148] Key Exchange Guesses not supported Message-ID: <20030127100946.5FA9864878@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=148 ------- Additional Comments From avraham.fraenkel at commatch.com 2003-01-27 21:09 ------- You shood check only PROPOSAL_KEX_ALGS and PROPOSAL_SERVER_HOST_KEY_ALGS Only for them it is written that o the kex algorithm and/or the host key algorithm is guessed wrong (server and client have different preferred algorithm). ========== For the other parts of the proposal you will find the mismatch in the choose_enc/mac/comp functions. There is no need that the first option will be a right guess: o if any of the other algorithms cannot be agreed upon. ====== -- Avraham ------- 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 Jan 27 22:31:14 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 27 Jan 2003 22:31:14 +1100 (EST) Subject: [Bug 148] Key Exchange Guesses not supported Message-ID: <20030127113114.8029364876@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=148 ------- Additional Comments From markus at openbsd.org 2003-01-27 22:31 ------- Created an attachment (id=210) --> (http://bugzilla.mindrot.org/attachment.cgi?id=210&action=view) update ok, this only check the kex algs and the host key types. ------- 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 Jan 27 22:33:45 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 27 Jan 2003 22:33:45 +1100 (EST) Subject: [Bug 148] Key Exchange Guesses not supported Message-ID: <20030127113345.467CD64876@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=148 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #208 is|0 |1 obsolete| | ------- 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 Jan 27 22:34:08 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 27 Jan 2003 22:34:08 +1100 (EST) Subject: [Bug 148] Key Exchange Guesses not supported Message-ID: <20030127113408.1CA9564876@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=148 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #161 is|0 |1 obsolete| | ------- 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 Jan 27 23:01:04 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 27 Jan 2003 23:01:04 +1100 Subject: [PATCH] Creation of record_failed_login() in sshlogin.c Message-ID: <3E351F80.558E15F6@zip.com.au> Hi All, I've been poking around various parts of the auth code for a while. Some platforms support failed login counters and it occurs to me that there's as few too many instances of: #ifdef [PLATFORM] if (authenticated == 0 && strcmp(method, "password") == 0) some_login_failure_func(); #endif The attached patch creates a record_failed_login() function in sshlogin.c to go along with record_login(). This new function holds the platform-specific code. At the moment, this is AIX and UNICOS, but it will provide an obvious place for any other platforms that support this type of thing. auth_log() is called from do_authloop (proto 1) or userauth_finish (proto 2) and calls record_failed_login() for each failed password authentication. The next question is should this function get called for public-key authentications and, if so, under what circumstances? My best guess is that it should be called once if one or more public-key authentications was attempted and the user was not eventually authenticated. Thoughts? -- 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 27 Jan 2003 11:39:07 -0000 @@ -268,13 +268,11 @@ 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 */ - + if (geteuid() == 0 && authenticated == 0 && + strcmp(method, "password") == 0) + record_failed_login(authctxt->user, + get_canonical_hostname(options.verify_reverse_mapping), + "ssh"); } /* @@ -496,11 +494,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.78 diff -u -r1.78 auth1.c --- auth1.c 23 Jan 2003 06:41:20 -0000 1.78 +++ auth1.c 27 Jan 2003 10:51:39 -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.111 diff -u -r1.111 auth2.c --- auth2.c 26 Sep 2002 00:38:49 -0000 1.111 +++ auth2.c 27 Jan 2003 11:38:03 -0000 @@ -242,10 +242,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 27 Jan 2003 11:47:18 -0000 @@ -42,6 +42,7 @@ RCSID("$OpenBSD: sshlogin.c,v 1.5 2002/08/29 15:57:25 stevesk Exp $"); #include "loginrec.h" +#include "log.h" /* * Returns the time when the user last logged in. Returns 0 if the @@ -98,4 +99,20 @@ li = login_alloc_entry(pid, user, NULL, ttyname); 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) +{ + debug3("%s user %s host %s tty %s", __func__, user, host, ttyname); + +#ifdef WITH_AIXAUTHENTICATE + loginfailed(user, host, ttyname); +#endif + +#ifdef _UNICOS + cray_login_failure(authctxt->user, IA_UDBERR); +#endif /* _UNICOS */ } From bugzilla-daemon at mindrot.org Mon Jan 27 23:00:45 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 27 Jan 2003 23:00:45 +1100 (EST) Subject: [Bug 148] Key Exchange Guesses not supported Message-ID: <20030127120045.461FC64878@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=148 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #210 is|0 |1 obsolete| | ------- Additional Comments From markus at openbsd.org 2003-01-27 23:00 ------- Created an attachment (id=211) --> (http://bugzilla.mindrot.org/attachment.cgi?id=211&action=view) update #3 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From pekkas at netcore.fi Mon Jan 27 23:18:38 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 27 Jan 2003 14:18:38 +0200 (EET) Subject: scp -l on man page? Message-ID: Hello, I noticed: 20030124 - (djm) OpenBSD CVS Sync - markus at cvs.openbsd.org 2003/01/23 14:01:53 [scp.c] bandwidth limitation patch (scp -l) from niels@; ok todd@, deraadt@ [...] From dtucker at zip.com.au Mon Jan 27 23:38:14 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 27 Jan 2003 23:38:14 +1100 Subject: [PATCH] Creation of record_failed_login() in sshlogin.c References: <3E351F80.558E15F6@zip.com.au> Message-ID: <3E352836.31DB023A@zip.com.au> Darren Tucker wrote: > +record_failed_login(const char *user, const char *host, const char *ttyname) [snip] > +#ifdef _UNICOS > + cray_login_failure(authctxt->user, IA_UDBERR); > +#endif /* _UNICOS */ Damn. Make that "cray_login_failure(user, IA_UDBERR);". My excuse is I don't have a Cray to try it on :-). -- 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 Tue Jan 28 04:02:27 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 28 Jan 2003 04:02:27 +1100 (EST) Subject: [Bug 476] Privsep directory error could be improved Message-ID: <20030127170227.224EF64877@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=476 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From markus at openbsd.org 2003-01-28 04:02 ------- thanks, similar fix applied ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From wendyp at cray.com Tue Jan 28 05:18:51 2003 From: wendyp at cray.com (Wendy Palm) Date: Mon, 27 Jan 2003 12:18:51 -0600 Subject: [PATCH] Creation of record_failed_login() in sshlogin.c References: <3E351F80.558E15F6@zip.com.au> <3E352836.31DB023A@zip.com.au> Message-ID: <3E35780B.5070101@cray.com> such a lame excuse..... :) i tested it out and while it works, it introduces compiler warnings about the "const" in the call line. record_failed_login(const char *user, const char *host, const char *ttyname) all the functions called in cray_login_failure() spit when user is a const char *. can you change it to record_failed_login(char *user, const char *host, const char *ttyname) diff -c sshlogin.c.orig sshlogin.c *** sshlogin.c.orig Mon Jan 27 11:54:28 2003 --- sshlogin.c Mon Jan 27 12:17:20 2003 *************** *** 42,47 **** --- 42,48 ---- RCSID("$OpenBSD: sshlogin.c,v 1.5 2002/08/29 15:57:25 stevesk Exp $"); #include "loginrec.h" + #include "log.h" /* * Returns the time when the user last logged in. Returns 0 if the *************** *** 99,101 **** --- 100,117 ---- login_logout(li); login_free_entry(li); } + + /* Record a failed login attempt. */ + void + record_failed_login(char *user, const char *host, const char *ttyname) + { + debug3("%s user %s host %s tty %s", __func__, user, host, ttyname); + + #ifdef WITH_AIXAUTHENTICATE + loginfailed(user, host, ttyname); + #endif + + #ifdef _UNICOS + cray_login_failure(user, IA_UDBERR); + #endif /* _UNICOS */ + } Darren Tucker wrote: > Darren Tucker wrote: > >>+record_failed_login(const char *user, const char *host, const char *ttyname) >> > [snip] > >>+#ifdef _UNICOS >>+ cray_login_failure(authctxt->user, IA_UDBERR); >>+#endif /* _UNICOS */ >> > > Damn. Make that "cray_login_failure(user, IA_UDBERR);". My excuse is I > don't have a Cray to try it on :-). > > -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From bugzilla-daemon at mindrot.org Tue Jan 28 06:06:48 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 28 Jan 2003 06:06:48 +1100 (EST) Subject: [Bug 477] New: progressmeter.c problem requires openbsd-compat/bsd-cray.h change Message-ID: <20030127190648.6A57364877@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=477 Summary: progressmeter.c problem requires openbsd-compat/bsd- cray.h change Product: Portable OpenSSH Version: 3.5p1 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: wendyp at cray.com when foregroundproc() got put into progressmeter.c, the return line got changed from #ifdef HAVE_TCGETPGRP return ((ctty_pgrp = tcgetpgrp(STDOUT_FILENO)) != -1 && ctty_pgrp == pgrp); #else return ((ioctl(STDOUT_FILENO, TIOCGPGRP, &ctty_pgrp) != -1 && ctty_pgrp == pgrp)); #endif to return ((ioctl(STDOUT_FILENO, TIOCGPGRP, &ctty_pgrp) != -1 && ctty_pgrp == pgrp)); and the crays stopped being able to compile because TIOCGPGRP isn't set on them. i'm not sure why the #ifdef HAVE_TCGETPGRP got deleted, but if that part is not going to be used, i need the following patch added to openbsd-compat/bsd-cray.h diff -c openbsd-compat/bsd-cray.h.orig openbsd-compat/bsd-cray.h *** openbsd-compat/bsd-cray.h.orig Mon Jan 27 11:42:17 2003 --- openbsd-compat/bsd-cray.h Mon Jan 27 11:52:07 2003 *************** *** 49,54 **** --- 49,56 ---- #ifndef MAXHOSTNAMELEN #define MAXHOSTNAMELEN 64 #endif + #include + #define TIOCGPGRP (tIOC|20) #endif #endif /* _BSD_CRAY_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 Tue Jan 28 08:16:33 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 28 Jan 2003 08:16:33 +1100 (EST) Subject: [Bug 477] progressmeter.c problem requires openbsd-compat/bsd-cray.h change Message-ID: <20030127211633.10CAA64878@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=477 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From mouring at eviladmin.org 2003-01-28 08:16 ------- Thanks, applied. Also removed check for tcgetpgrp() since that was the only place it was used. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Tue Jan 28 08:55:42 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 28 Jan 2003 08:55:42 +1100 Subject: [PATCH] Creation of record_failed_login() in sshlogin.c References: <3E351F80.558E15F6@zip.com.au> <3E352836.31DB023A@zip.com.au> <3E35780B.5070101@cray.com> Message-ID: <3E35AADE.36FEF455@zip.com.au> Wendy Palm wrote: > Darren Tucker wrote: > > My excuse is I don't have a Cray to try it on :-). > such a lame excuse..... Heh. It's already warm in here because of the 2 SPARCs and 1 HPPA running the tinderbox builds and I don't have 3-phase power. > i tested it out and while it works, it introduces compiler warnings about the "const" > in the call line. Does casting the type keep the compiler happy? That way you don't lose the tiny bit of safety on the platforms that don't warn. cray_login_failure((char *)user, IA_UDBERR); -- 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 wendyp at cray.com Tue Jan 28 09:06:37 2003 From: wendyp at cray.com (Wendy Palm) Date: Mon, 27 Jan 2003 16:06:37 -0600 Subject: [PATCH] Creation of record_failed_login() in sshlogin.c References: <3E351F80.558E15F6@zip.com.au> <3E352836.31DB023A@zip.com.au> <3E35780B.5070101@cray.com> <3E35AADE.36FEF455@zip.com.au> Message-ID: <3E35AD6D.8030201@cray.com> Darren Tucker wrote: > Wendy Palm wrote: > >>Darren Tucker wrote: >> >>>My excuse is I don't have a Cray to try it on :-). >>> >>such a lame excuse..... >> > > Heh. It's already warm in here because of the 2 SPARCs and 1 HPPA > running the tinderbox builds and I don't have 3-phase power. excuses, excuses... >>i tested it out and while it works, it introduces compiler warnings about the "const" >>in the call line. >> > > Does casting the type keep the compiler happy? That way you don't lose > the tiny bit of safety on the platforms that don't warn. > > cray_login_failure((char *)user, IA_UDBERR); > yep, i figured that's what you'd want to do :) it works fine. -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From markus at openbsd.org Tue Jan 28 09:33:47 2003 From: markus at openbsd.org (Markus Friedl) Date: Mon, 27 Jan 2003 23:33:47 +0100 Subject: scp -l on man page? In-Reply-To: References: Message-ID: <20030127223347.GC5565@folly> 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 :) From pekkas at netcore.fi Tue Jan 28 21:09:19 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 28 Jan 2003 12:09:19 +0200 (EET) Subject: scp -l on man page? In-Reply-To: <20030127223347.GC5565@folly> Message-ID: 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..) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------- next part -------------- Index: scp.1 =================================================================== RCS file: /cvs/openssh/scp.1,v retrieving revision 1.23 diff -u -r1.23 scp.1 --- scp.1 24 Jan 2003 00:37:38 -0000 1.23 +++ scp.1 28 Jan 2003 10:08:10 -0000 @@ -25,6 +25,7 @@ .Op Fl P Ar port .Op Fl c Ar cipher .Op Fl i Ar identity_file +.Op Fl l Ar limit .Op Fl o Ar ssh_option .Sm off .Oo @@ -68,6 +69,9 @@ authentication is read. This option is directly passed to .Xr ssh 1 . +.It Fl l Ar limit +Limits the used bandwidth, +specified in kilobytes per second. .It Fl p Preserves modification times, access times, and modes from the original file. From bugzilla-daemon at mindrot.org Tue Jan 28 23:54:31 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 28 Jan 2003 23:54:31 +1100 (EST) Subject: [Bug 252] Patch for use of /etc/default/login Message-ID: <20030128125431.7C85564876@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=252 Robert.Dahlem at siemens.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #98 is|0 |1 obsolete| | ------- Additional Comments From Robert.Dahlem at siemens.com 2003-01-28 23:54 ------- Created an attachment (id=212) --> (http://bugzilla.mindrot.org/attachment.cgi?id=212&action=view) Updated patch for 3.5p1 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From rene.klootwijk at quinse.nl Wed Jan 29 00:39:09 2003 From: rene.klootwijk at quinse.nl (Rene Klootwijk) Date: Tue, 28 Jan 2003 14:39:09 +0100 (CET) Subject: Not only pam chauthtok problems in privsep mode Message-ID: <1147.192.168.1.254.1043761149.squirrel@192.168.1.1> Without giving a solution, I want to mention the following problem: Not only changing expired passwords when privilege separation is enabled in combination with PAM is not working (although the current patches seem to solve this one). Also some PAM session modules do not work the way they are supposed to. For instance, the pam_lastlog module. This module gets and updates the last successful login attempt for a specific user in /var/log/lastlog. When privilege separation mode is enabled, not enough privileges are available to read and update lastlog (root:root 0640). Changing the permissions to 0666 (obviously not something you want to do) makes it work again. When privilege separation is disabled, everything works OK. One alternative could be to use the PrintLastLog option of OpenSSH, however see bug 463, also this does not solve the real problem and might leave us with the same problem with other PAM modules. Regards, Rene. From info at arelax.net Wed Jan 29 05:14:28 2003 From: info at arelax.net (Arelax.NET-AD) Date: Wed, 29 Jan 2003 03:14:28 +0900 Subject: =?ISO-2022-JP?B?GyRCTCQ+NUJ6OS05cCIoIVojMSMwIzVMPk1NJEslVyVsGyhC?= =?ISO-2022-JP?B?GyRCJTwlcyVIIVshISVtITwlOiVSJUMlV0I+JUAlJCUoJUMlSD4mGyhC?= =?ISO-2022-JP?B?GyRCSUokchsoQiAbJEIkSSRJIUEkcyRIQW1AKhsoQjEwNRskQkw+GyhC?= =?ISO-2022-JP?B?GyRCTU0kSyEqGyhC?= Message-ID: <20030129.0314280327.babaq@info-arelax.net> ??????????? ??an ???? ????????????2-8-97 http://www.rakuten.co.jp/vivian/ tokutoku at b-vivian.com ?????????????????????info at arelax.net ??????????? ????????????????????????????????? ????????????????????????????????? ????????????????????????????????? ????????????????????????? ?? ?????an ???????????????????? ?? ??????????????????????????????? ???? ?????????????????? ? ???? ???an ???? ?? ????????????????????????????????? ???????????????????????????????? ?????????????????????????????????? ???? ??an WebShop ???? ? ???http://www.rakuten.co.jp/vivian/ ??????an?????????????????????????? ??????????????????????????? ????????URL???????????????????? ???? ?????????????????? ? ???? ?????????????? ?? ????????????????????????????? ??? ?????????????????????? ????????????????????????? ????????????????????????????? ?????????????????100%??????????????? ???????30g?????300?? ????????????????????????????? ??? ?????????????????????????? ??????????????????? ????????????????????????????? ????????????????????????????????? ???????45??????8,800?? ????????????????????????????? ??? ??????????????????????? ???????????????????????? ????????????????????????????? ????????????????????????????????? ???????120??????15,000?? ????????????????????????????? ??? ???????????????????????? ????????????????????? ????????????????????????????? ????????????????????????????????? ???????30??????9,800?? ???? ?????????????????? ? ???? ?????????? ?? ????????2003?1?23????2003?2?26? ???????????????????????? ???????????????????????????????? ??????????????????????????????? ???????? ?????????????????????????? ????????2003?3?2????? ????????????????????????????????? ??????????????????????????????? ???????? ????????????????????????????????? ????????????????????????????? ???????? ????????????????????????????????? ??????????????????????????? ?????????????? ????????????????????????????????? ????????????????????????????? ?????????????????????????????? ???? ?????????????????? ? ???? ??????? ?? ??????????URL??????????????????? ??????????????????????????? ???????????????????????? ??????????????????????????? ???????????OK??????? ????????????????????????????????? ?????????????????????? ???????????????????????????? ?? ??????????????????????????????? ?? ?? ???????????URL???????? ????????? ?? ??????????????????????????????? ? ?????http://www.rakuten.co.jp/vivian/468274/472362/486997/ ???? ????????????????????????????? ? ?????????????????????? ?????????????????????? ???an ????? ??????????? ??an ??556-0011 ?????????2?8?97 ?(TEL) 06-6629-3535 (FAX)06-6630-1311 ?(URL) http://www.rakuten.co.jp/vivian/ ?(E-mail)tokutoku at b-vivian.com ================================================================== ?????????????????????????info at arelax.net ???????????? ???????????????????????? tokutoku at b-vivian.com????????? ??????info at arelax.net?? ??????????????????????????????????? ?????????????????????????????????? ?????????????????????????????????? ??????????????????????????????? ================================================================== From william at 25thandClement.com Wed Jan 29 07:21:56 2003 From: william at 25thandClement.com (William Ahern) Date: Tue, 28 Jan 2003 12:21:56 -0800 Subject: ibutton Message-ID: <20030128202156.GA685@25thandClement.com> has anybody worked with support for the ibutton? i've come across keymgr (http://www.rcpt.to/keymgr/), but it seems to be dead (or playing possum). i've also come across ramblings about integrating ibutton support into openssl, but i dunno how pertinent that is, or even whether the work still exists. i just want to get rid of my passwds (or lock them up in a safe), and the ibutton seems to be the perfect tool. note that i'm not using windows, as i've come across many windows ssh clients that support the ibutton. i'm not averse to hacking the keymgr code myself. i just want to hear what's up in this space. please Cc: me. thanx, Bill From mouring at etoh.eviladmin.org Wed Jan 29 11:26:57 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 28 Jan 2003 18:26:57 -0600 (CST) Subject: ibutton In-Reply-To: <20030128202156.GA685@25thandClement.com> Message-ID: I think you'd be better off using a card reading system where your private key never leaves the card. I think that ibutton is overkill compared to throwing putty and your private key on a USB key. And ibutton definitely looks just as unsecure as doing so. USB 32meg keys are dirty cheap and fit nicely on keyrings. - Ben On Tue, 28 Jan 2003, William Ahern wrote: > has anybody worked with support for the ibutton? i've come across keymgr > (http://www.rcpt.to/keymgr/), but it seems to be dead (or playing possum). i've > also come across ramblings about integrating ibutton support into openssl, but > i dunno how pertinent that is, or even whether the work still exists. > > i just want to get rid of my passwds (or lock them up in a safe), and the > ibutton seems to be the perfect tool. note that i'm not using windows, as > i've come across many windows ssh clients that support the ibutton. > > i'm not averse to hacking the keymgr code myself. i just want to hear what's > up in this space. > > please Cc: me. > > thanx, > > Bill > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From william at 25thandClement.com Wed Jan 29 14:44:03 2003 From: william at 25thandClement.com (William Ahern) Date: Tue, 28 Jan 2003 19:44:03 -0800 Subject: ibutton In-Reply-To: References: <20030128202156.GA685@25thandClement.com> Message-ID: <20030129034403.GA21106@25thandClement.com> the [java] crypto ibutton is such a card reading system. the private key needn't leave it; it can sign data itself. and the ibutton doesn't cost an arm-and-a-leg and require hefty implementation and service contracts. plus, the ibutton doesn't need a pcmcia slot or bulky card reader. it can fit on a ring, and plug-in via usb w/ little key-fob attachments. On Tue, Jan 28, 2003 at 06:26:57PM -0600, Ben Lindstrom wrote: > > I think you'd be better off using a card reading system where your private > key never leaves the card. > > I think that ibutton is overkill compared to throwing putty and your > private key on a USB key. And ibutton definitely looks just as unsecure > as doing so. USB 32meg keys are dirty cheap and fit nicely on keyrings. > > - Ben > > On Tue, 28 Jan 2003, William Ahern wrote: > > > has anybody worked with support for the ibutton? i've come across keymgr > > (http://www.rcpt.to/keymgr/), but it seems to be dead (or playing possum). i've > > also come across ramblings about integrating ibutton support into openssl, but > > i dunno how pertinent that is, or even whether the work still exists. > > > > i just want to get rid of my passwds (or lock them up in a safe), and the > > ibutton seems to be the perfect tool. note that i'm not using windows, as > > i've come across many windows ssh clients that support the ibutton. > > > > i'm not averse to hacking the keymgr code myself. i just want to hear what's > > up in this space. > > > > please Cc: me. > > > > thanx, > > > > Bill > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > From mouring at etoh.eviladmin.org Wed Jan 29 15:51:05 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 28 Jan 2003 22:51:05 -0600 (CST) Subject: ibutton In-Reply-To: <20030129034403.GA21106@25thandClement.com> Message-ID: Nor is their development freely accessible. If you want to extend the card reader support that may be your best solution. Otherwise, I doubt it will be supported any other way. - Ben On Tue, 28 Jan 2003, William Ahern wrote: > the [java] crypto ibutton is such a card reading system. the private key > needn't leave it; it can sign data itself. and the ibutton doesn't cost an > arm-and-a-leg and require hefty implementation and service contracts. > > plus, the ibutton doesn't need a pcmcia slot or bulky card reader. it can > fit on a ring, and plug-in via usb w/ little key-fob attachments. > > On Tue, Jan 28, 2003 at 06:26:57PM -0600, Ben Lindstrom wrote: > > > > I think you'd be better off using a card reading system where your private > > key never leaves the card. > > > > I think that ibutton is overkill compared to throwing putty and your > > private key on a USB key. And ibutton definitely looks just as unsecure > > as doing so. USB 32meg keys are dirty cheap and fit nicely on keyrings. > > > > - Ben > > > > On Tue, 28 Jan 2003, William Ahern wrote: > > > > > has anybody worked with support for the ibutton? i've come across keymgr > > > (http://www.rcpt.to/keymgr/), but it seems to be dead (or playing possum). i've > > > also come across ramblings about integrating ibutton support into openssl, but > > > i dunno how pertinent that is, or even whether the work still exists. > > > > > > i just want to get rid of my passwds (or lock them up in a safe), and the > > > ibutton seems to be the perfect tool. note that i'm not using windows, as > > > i've come across many windows ssh clients that support the ibutton. > > > > > > i'm not averse to hacking the keymgr code myself. i just want to hear what's > > > up in this space. > > > > > > please Cc: me. > > > > > > thanx, > > > > > > Bill > > > > > > _______________________________________________ > > > 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 dtucker at zip.com.au Wed Jan 29 18:24:12 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 29 Jan 2003 18:24:12 +1100 Subject: Privsep question: can the slave's child make monitor calls? Message-ID: <3E37819C.8A829FFE@zip.com.au> Hi all. I have a question regarding privsep. Firstly, the following is my understanding of what happens when privsep is enabled: The sshd daemon is running as root listing on 22(a). When a connection is accepted, a child is forked to handle the connection, this child becomes the monitor(b). The monitor forks the pre-auth privsep slave(c), which sheds it privs and hides in its chroot jail. If the user is authenticated, the pre-auth slave exits and the post-auth slave(d) is forked. This slave sets its uid to the user's, does some prep work, then forks a process to exec the shell(e). This process sets up its descriptors then execs the shell. The question is about (e). Because it's a child of the post-auth slave, it inherits the descriptor that talks to the monitor so it *can* make monitor calls, but it should it? Isn't that a potential race condition if the slave and its child make monitor calls at the same time? The reason I ask is that one of my patches does this to check for successful password change. This (or some other solution) is needed because in some instances /bin/passwd does not set a failing return code. -- 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 Wed Jan 29 22:49:22 2003 From: markus at openbsd.org (Markus Friedl) Date: Wed, 29 Jan 2003 12:49:22 +0100 Subject: Privsep question: can the slave's child make monitor calls? In-Reply-To: <3E37819C.8A829FFE@zip.com.au> References: <3E37819C.8A829FFE@zip.com.au> Message-ID: <20030129114922.GA23171@folly> On Wed, Jan 29, 2003 at 06:24:12PM +1100, Darren Tucker wrote: > Hi all. > I have a question regarding privsep. Firstly, the following is my > understanding of what happens when privsep is enabled: > > The sshd daemon is running as root listing on 22(a). When a connection > is accepted, a child is forked to handle the connection, this child > becomes the monitor(b). The monitor forks the pre-auth privsep > slave(c), which sheds it privs and hides in its chroot jail. If the > user is authenticated, the pre-auth slave exits and the post-auth > slave(d) is forked. This slave sets its uid to the user's, does some > prep work, then forks a process to exec the shell(e). This process sets > up its descriptors then execs the shell. > > The question is about (e). Because it's a child of the post-auth > slave, it inherits the descriptor that talks to the monitor so it *can* > make monitor calls, but it should it? no, i think (e) should _not_ talk to the monitor. From dtucker at zip.com.au Thu Jan 30 00:06:22 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 30 Jan 2003 00:06:22 +1100 Subject: PermitRootLogin=yes no longer lets root login Message-ID: <3E37D1CE.39D02604@zip.com.au> Hi All, While testing another patch, I found that I could not longer log in as root, even if PermitRootLogin was yes. It seems to be the following code in auth_password: $ cvs diff -r1.48 -r1.49 auth-passwd.c [snip] #ifndef HAVE_CYGWIN - if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES) + if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_NO_PASSWD) return 0; #endif [snip] Was this intentional? -Daz. -- 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 sbade at austin.ibm.com Thu Jan 30 01:48:06 2003 From: sbade at austin.ibm.com (Steven Bade) Date: Wed, 29 Jan 2003 08:48:06 -0600 Subject: ibutton References: Message-ID: <3E37E9A6.2050800@austin.ibm.com> If I remember (and these days that;s a BIG if) correctly the iButton was a Fips140-1 level 3 certified device. Ben Lindstrom wrote: > I think you'd be better off using a card reading system where your private > key never leaves the card. > > I think that ibutton is overkill compared to throwing putty and your > private key on a USB key. And ibutton definitely looks just as unsecure > as doing so. USB 32meg keys are dirty cheap and fit nicely on keyrings. > > - Ben > > On Tue, 28 Jan 2003, William Ahern wrote: > > >>has anybody worked with support for the ibutton? i've come across keymgr >>(http://www.rcpt.to/keymgr/), but it seems to be dead (or playing possum). i've >>also come across ramblings about integrating ibutton support into openssl, but >>i dunno how pertinent that is, or even whether the work still exists. >> >>i just want to get rid of my passwds (or lock them up in a safe), and the >>ibutton seems to be the perfect tool. note that i'm not using windows, as >>i've come across many windows ssh clients that support the ibutton. >> >>i'm not averse to hacking the keymgr code myself. i just want to hear what's >>up in this space. >> >>please Cc: me. >> >>thanx, >> >>Bill >> >>_______________________________________________ >>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 provos at citi.umich.edu Thu Jan 30 02:19:29 2003 From: provos at citi.umich.edu (Niels Provos) Date: Wed, 29 Jan 2003 10:19:29 -0500 Subject: Privsep question: can the slave's child make monitor calls? In-Reply-To: <20030129114922.GA23171@folly> References: <3E37819C.8A829FFE@zip.com.au> <20030129114922.GA23171@folly> Message-ID: <20030129151929.GE9858@citi.citi.umich.edu> On Wed, Jan 29, 2003 at 12:49:22PM +0100, Markus Friedl wrote: > no, i think (e) should _not_ talk to the monitor. Those descriptors are all close on exec. Niels. From dtucker at zip.com.au Thu Jan 30 07:29:21 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 30 Jan 2003 07:29:21 +1100 Subject: Privsep question: can the slave's child make monitor calls? References: <3E37819C.8A829FFE@zip.com.au> <20030129114922.GA23171@folly> <20030129151929.GE9858@citi.citi.umich.edu> Message-ID: <3E3839A1.37DEDB9B@zip.com.au> Niels Provos wrote: > On Wed, Jan 29, 2003 at 12:49:22PM +0100, Markus Friedl wrote: > > no, i think (e) should _not_ talk to the monitor. > Those descriptors are all close on exec. The situation I was describing was sshd deliberately calling a monitor function after the fork but before the exec. I suspect Markus is right and I shouldn't do that, in which case I need to figure out another way to solve my problem. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Thu Jan 30 07:37:58 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 30 Jan 2003 07:37:58 +1100 Subject: Snapshots not updating? Message-ID: <3E383BA6.1FADF3BF@zip.com.au> Is there a problem with the snapshots? The newest one on ftp.ca.openbsd.org is a week old. -Daz. -- 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 dot at dotat.at Thu Jan 30 08:40:20 2003 From: dot at dotat.at (Tony Finch) Date: Wed, 29 Jan 2003 21:40:20 +0000 Subject: [PATCH] features for restricted shell environments Message-ID: The patch below implements a couple of features which are useful in an environment where users do not have a regular shell login. It allows you to selectively disable certain features on a system-wide level for users with a certain shell; it also allows you to control and audit TCP forwarding in more detail. Our system is an email server with a menu for the login shell; we selectively allow port forwarding for users to connect to the IMAP server etc. and prevent users from escaping via ~/.ssh/rc. This patch may also be useful with secure CVS servers. Tony. -- f.a.n.finch http://dotat.at/ FISHER GERMAN BIGHT: NORTHWESTERLY 6 OR 7, OCCASIONALLY GALE 8 IN WEST, VEERING NORTHEASTERLY 5 LATER. WINTRY SHOWERS. GOOD. --- auth-options.c 28 Jan 2003 18:06:50 -0000 1.1.1.2 +++ auth-options.c 29 Jan 2003 20:39:19 -0000 1.7 @@ -133,7 +135,7 @@ goto next_option; } cp = "environment=\""; - if (options.permit_user_env && + if (!auth_restricted(RESTRICT_ENV, pw) && strncasecmp(opts, cp, strlen(cp)) == 0) { char *s; struct envstring *new_envstring; @@ -217,8 +219,6 @@ } cp = "permitopen=\""; if (strncasecmp(opts, cp, strlen(cp)) == 0) { - char host[256], sport[6]; - u_short port; char *patterns = xmalloc(strlen(opts) + 1); opts += strlen(cp); @@ -243,8 +243,7 @@ } patterns[i] = 0; opts++; - if (sscanf(patterns, "%255[^:]:%5[0-9]", host, sport) != 2 && - sscanf(patterns, "%255[^/]/%5[0-9]", host, sport) != 2) { + if (channel_add_permitted_opens(patterns) < 0) { debug("%.100s, line %lu: Bad permitopen specification " "<%.100s>", file, linenum, patterns); auth_debug_add("%.100s, line %lu: " @@ -252,16 +251,6 @@ xfree(patterns); goto bad_option; } - if ((port = a2port(sport)) == 0) { - debug("%.100s, line %lu: Bad permitopen port <%.100s>", - file, linenum, sport); - auth_debug_add("%.100s, line %lu: " - "Bad permitopen port", file, linenum); - xfree(patterns); - goto bad_option; - } - if (options.allow_tcp_forwarding) - channel_add_permitted_opens(host, port); xfree(patterns); goto next_option; } --- auth-pam.c 28 Jan 2003 18:06:51 -0000 1.1.1.2 +++ auth-pam.c 29 Jan 2003 20:39:19 -0000 1.2 @@ -358,7 +360,7 @@ no_port_forwarding_flag &= ~2; no_agent_forwarding_flag &= ~2; no_x11_forwarding_flag &= ~2; - if (!no_port_forwarding_flag && options.allow_tcp_forwarding) + if (!auth_restricted(RESTRICT_TCP, auth_get_user())) channel_permit_all_opens(); #endif } --- auth.c 28 Jan 2003 18:06:51 -0000 1.1.1.2 +++ auth.c 29 Jan 2003 21:26:11 -0000 1.4 @@ -291,6 +293,31 @@ return 0; } +/* + * Is the user subject to this restriction? + */ +int +auth_restricted(int restriction, struct passwd *pw) +{ + debug2("user shell is %s", pw->pw_shell); + if ((options.restrictions & restriction) && + options.restricted_shell != NULL && + strcmp(options.restricted_shell, pw->pw_shell) == 0) { + debug("Restricted shell (%d)", restriction); + return 1; + } else if ((restriction & RESTRICT_AGENT) && no_agent_forwarding_flag) + return 1; + else if ((restriction & RESTRICT_ENV) && !options.permit_user_env) + return 1; + else if ((restriction & RESTRICT_TCP) && + (!options.allow_tcp_forwarding || no_port_forwarding_flag)) + return 1; + else if ((restriction & RESTRICT_X11) && + (!options.x11_forwarding || no_x11_forwarding_flag)) + return 1; + else + return 0; +} /* * Given a template and a passwd structure, build a filename --- auth.h 28 Jan 2003 18:06:51 -0000 1.1.1.2 +++ auth.h 29 Jan 2003 20:39:19 -0000 1.3 @@ -142,6 +143,7 @@ void auth_log(Authctxt *, int, char *, char *); void userauth_finish(Authctxt *, int, char *); int auth_root_allowed(char *); +int auth_restricted(int, struct passwd *); char *auth2_read_banner(void); --- channels.c 28 Jan 2003 18:06:51 -0000 1.1.1.2 +++ channels.c 28 Jan 2003 19:06:35 -0000 1.4 @@ -96,6 +98,10 @@ /* Number of permitted host/port pairs in the array. */ static int num_permitted_opens = 0; + +/* Don't allow any more to be added. */ +static int fix_permitted_opens = 0; + /* * If this is true, all opens are permitted. This is the case on the server * on which we have to trust the client anyway, and the user could do @@ -1972,7 +1978,7 @@ } void -channel_input_port_open(int type, u_int32_t seq, void *ctxt) +channel_input_port_open(int type, u_int32_t seq, void *ctxt, int loud) { Channel *c = NULL; u_short host_port; @@ -1989,6 +1995,8 @@ originator_string = xstrdup("unknown (remote did not supply name)"); } packet_check_eom(); + if (loud) + log("TCP forwarding connection to %s port %d", host, host_port); sock = channel_connect_to(host, host_port); if (sock != -1) { c = channel_new("connected socket", @@ -2004,6 +2012,18 @@ xfree(host); } +void +channel_input_port_open_quiet(int type, u_int32_t seq, void *ctxt) +{ + channel_input_port_open(type, seq, ctxt, 0); +} + +void +channel_input_port_open_loud(int type, u_int32_t seq, void *ctxt) +{ + channel_input_port_open(type, seq, ctxt, 1); +} + /* -- tcp forwarding */ @@ -2209,6 +2229,8 @@ port); #endif /* Initiate forwarding */ + log("TCP forwarding listening on port %d %s", port, + gateway_ports ? "open" : "private"); channel_setup_local_fwd_listener(port, hostname, host_port, gateway_ports); /* Free the argument string. */ @@ -2227,10 +2249,31 @@ all_opens_permitted = 1; } +/* + * If the server-wide configuration specifies some permitted_opens + * then don't allow users to add to them. + */ void -channel_add_permitted_opens(char *host, int port) +channel_fix_permitted_opens(void) { - if (num_permitted_opens >= SSH_MAX_FORWARDS_PER_DIRECTION) + if (num_permitted_opens != 0) + fix_permitted_opens = 1; +} + +int +channel_add_permitted_opens(char *hostport) +{ + char host[256], sport[6]; + u_short port; + + if (sscanf(hostport, "%255[^:]:%5[0-9]", host, sport) != 2 && + sscanf(hostport, "%255[^/]/%5[0-9]", host, sport) != 2) + return -1; + if ((port = a2port(sport)) == 0) + return -1; + + if (num_permitted_opens >= SSH_MAX_FORWARDS_PER_DIRECTION || + fix_permitted_opens) fatal("channel_request_remote_forwarding: too many forwards"); debug("allow port forwarding to host %s port %d", host, port); @@ -2239,6 +2282,7 @@ num_permitted_opens++; all_opens_permitted = 0; + return 0; } void @@ -2246,6 +2290,8 @@ { int i; + if (fix_permitted_opens) + return; for (i = 0; i < num_permitted_opens; i++) xfree(permitted_opens[i].host_to_connect); num_permitted_opens = 0; @@ -2448,6 +2494,7 @@ 0, xstrdup("X11 inet listener"), 1); nc->single_connection = single_connection; } + log("X11 forwarding listening on port %d", 6000+display_number); /* Return the display number for the DISPLAY environment variable. */ *display_numberp = display_number; --- channels.h 28 Jan 2003 18:06:51 -0000 1.1.1.2 +++ channels.h 28 Jan 2003 19:06:35 -0000 1.4 @@ -176,7 +177,9 @@ void channel_input_oclose(int, u_int32_t, void *); void channel_input_open_confirmation(int, u_int32_t, void *); void channel_input_open_failure(int, u_int32_t, void *); -void channel_input_port_open(int, u_int32_t, void *); +void channel_input_port_open(int, u_int32_t, void *, int); +void channel_input_port_open_loud(int, u_int32_t, void *); +void channel_input_port_open_quiet(int, u_int32_t, void *); void channel_input_window_adjust(int, u_int32_t, void *); /* file descriptor handling (read/write) */ @@ -194,7 +197,8 @@ /* tcp forwarding */ void channel_set_af(int af); void channel_permit_all_opens(void); -void channel_add_permitted_opens(char *, int); +void channel_fix_permitted_opens(void); +int channel_add_permitted_opens(char *); void channel_clear_permitted_opens(void); void channel_input_port_forward_request(int, int); int channel_connect_to(const char *, u_short); --- clientloop.c 28 Jan 2003 18:06:51 -0000 1.1.1.2 +++ clientloop.c 28 Jan 2003 19:06:35 -0000 1.3 @@ -1342,7 +1344,7 @@ dispatch_set(SSH_MSG_CHANNEL_DATA, &channel_input_data); dispatch_set(SSH_MSG_CHANNEL_OPEN_CONFIRMATION, &channel_input_open_confirmation); dispatch_set(SSH_MSG_CHANNEL_OPEN_FAILURE, &channel_input_open_failure); - dispatch_set(SSH_MSG_PORT_OPEN, &channel_input_port_open); + dispatch_set(SSH_MSG_PORT_OPEN, &channel_input_port_open_quiet); dispatch_set(SSH_SMSG_EXITSTATUS, &client_input_exit_status); dispatch_set(SSH_SMSG_STDERR_DATA, &client_input_stderr_data); dispatch_set(SSH_SMSG_STDOUT_DATA, &client_input_stdout_data); --- servconf.c 28 Jan 2003 18:06:52 -0000 1.1.1.2 +++ servconf.c 29 Jan 2003 21:26:11 -0000 1.8 @@ -39,6 +41,7 @@ #include "cipher.h" #include "kex.h" #include "mac.h" +#include "channels.h" static void add_listen_addr(ServerOptions *, char *, u_short); static void add_one_listen_addr(ServerOptions *, char *, u_short); @@ -102,6 +105,9 @@ options->challenge_response_authentication = -1; options->permit_empty_passwd = -1; options->permit_user_env = -1; + options->permit_tcp_listen = -1; + options->restricted_shell = NULL; + options->restrictions = -1; options->use_login = -1; options->compression = -1; options->allow_tcp_forwarding = -1; @@ -226,6 +232,10 @@ options->permit_empty_passwd = 0; if (options->permit_user_env == -1) options->permit_user_env = 0; + if (options->permit_tcp_listen == -1) + options->permit_tcp_listen = 1; + if (options->restrictions == -1) + options->restrictions = 0; if (options->use_login == -1) options->use_login = 0; if (options->compression == -1) @@ -234,6 +244,7 @@ options->allow_tcp_forwarding = 1; if (options->gateway_ports == -1) options->gateway_ports = 0; + channel_fix_permitted_opens(); if (options->max_startups == -1) options->max_startups = 10; if (options->max_startups_rate == -1) @@ -294,6 +305,7 @@ sPrintMotd, sPrintLastLog, sIgnoreRhosts, sX11Forwarding, sX11DisplayOffset, sX11UseLocalhost, sStrictModes, sEmptyPasswd, sKeepAlives, + sPermitTcpConnect, sPermitTcpListen, sRestrictedShell, sPermitUserEnvironment, sUseLogin, sAllowTcpForwarding, sCompression, sAllowUsers, sDenyUsers, sAllowGroups, sDenyGroups, sIgnoreUserKnownHosts, sCiphers, sMacs, sProtocol, sPidFile, @@ -355,6 +367,7 @@ { "x11displayoffset", sX11DisplayOffset }, { "x11uselocalhost", sX11UseLocalhost }, { "xauthlocation", sXAuthLocation }, + { "restrictedshell", sRestrictedShell }, { "strictmodes", sStrictModes }, { "permitemptypasswords", sEmptyPasswd }, { "permituserenvironment", sPermitUserEnvironment }, @@ -362,6 +375,8 @@ { "compression", sCompression }, { "keepalive", sKeepAlives }, { "allowtcpforwarding", sAllowTcpForwarding }, + { "permittcpconnect", sPermitTcpConnect }, + { "permittcplisten", sPermitTcpListen }, { "allowusers", sAllowUsers }, { "denyusers", sDenyUsers }, { "allowgroups", sAllowGroups }, @@ -705,6 +720,30 @@ charptr = &options->xauth_location; goto parse_filename; + case sRestrictedShell: + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: missing restrictions.", + filename, linenum); + options->restrictions = 0; + while ((p = strsep(&arg, ",")) != NULL) { + if (strcasecmp(p, "agent") == 0) + options->restrictions |= RESTRICT_AGENT; + else if (strcasecmp(p, "env") == 0) + options->restrictions |= RESTRICT_ENV; + else if (strcasecmp(p, "rc") == 0) + options->restrictions |= RESTRICT_RC; + else if (strcasecmp(p, "tcp") == 0) + options->restrictions |= RESTRICT_TCP; + else if (strcasecmp(p, "x11") == 0) + options->restrictions |= RESTRICT_X11; + else + fatal("%s line %d: unknown restriction %s.", + filename, linenum, p); + } + charptr = &options->restricted_shell; + goto parse_filename; + case sStrictModes: intptr = &options->strict_modes; goto parse_flag; @@ -761,6 +800,22 @@ case sAllowTcpForwarding: intptr = &options->allow_tcp_forwarding; + goto parse_flag; + + case sPermitTcpConnect: + arg = strdelim(&cp); + p = NULL; + if (!arg || *arg == '\0') + p = "missing"; + if (channel_add_permitted_opens(arg) < 0) + p = "bad"; + if (p != NULL) + fatal("%.200s, line %d: %s inet addr:port.", + filename, linenum, p); + break; + + case sPermitTcpListen: + intptr = &options->permit_tcp_listen; goto parse_flag; case sUsePrivilegeSeparation: --- servconf.h 28 Jan 2003 18:06:52 -0000 1.1.1.2 +++ servconf.h 29 Jan 2003 21:26:12 -0000 1.7 @@ -32,6 +33,13 @@ #define PERMIT_NO_PASSWD 2 #define PERMIT_YES 3 +/* restrictions */ +#define RESTRICT_AGENT 1 +#define RESTRICT_ENV 2 +#define RESTRICT_RC 4 +#define RESTRICT_TCP 8 +#define RESTRICT_X11 16 + typedef struct { u_int num_ports; @@ -98,6 +106,9 @@ int permit_empty_passwd; /* If false, do not permit empty * passwords. */ int permit_user_env; /* If true, read ~/.ssh/environment */ + int permit_tcp_listen; /* If true allow -R forwarding */ + char *restricted_shell; /* Restrict users with this shell */ + int restrictions; /* How they are restricted */ int use_login; /* If true, login(1) is used */ int compression; /* If true, compression is allowed */ int allow_tcp_forwarding; --- serverloop.c 28 Jan 2003 18:06:52 -0000 1.1.1.2 +++ serverloop.c 29 Jan 2003 21:26:12 -0000 1.5 @@ -863,8 +865,7 @@ originator_port = packet_get_int(); packet_check_eom(); - debug("server_request_direct_tcpip: originator %s port %d, target %s port %d", - originator, originator_port, target, target_port); + log("TCP forwarding connection to %s port %d", target, target_port); /* XXX check permission */ sock = channel_connect_to(target, target_port); @@ -973,12 +974,10 @@ fatal("server_input_global_request: no user"); listen_address = packet_get_string(NULL); /* XXX currently ignored */ listen_port = (u_short)packet_get_int(); - debug("server_input_global_request: tcpip-forward listen %s port %d", - listen_address, listen_port); /* check permissions */ - if (!options.allow_tcp_forwarding || - no_port_forwarding_flag + if (!options.permit_tcp_listen || + auth_restricted(RESTRICT_TCP, pw) #ifndef NO_IPPORT_RESERVED_CONCEPT || (listen_port < IPPORT_RESERVED && pw->pw_uid != 0) #endif @@ -987,6 +986,8 @@ packet_send_debug("Server has disabled port forwarding."); } else { /* Start listening on the port */ + log("TCP forwarding listening on %s port %d", + listen_address, listen_port); success = channel_setup_remote_fwd_listener( listen_address, listen_port, options.gateway_ports); } @@ -1061,7 +1062,7 @@ dispatch_set(SSH_MSG_CHANNEL_DATA, &channel_input_data); dispatch_set(SSH_MSG_CHANNEL_OPEN_CONFIRMATION, &channel_input_open_confirmation); dispatch_set(SSH_MSG_CHANNEL_OPEN_FAILURE, &channel_input_open_failure); - dispatch_set(SSH_MSG_PORT_OPEN, &channel_input_port_open); + dispatch_set(SSH_MSG_PORT_OPEN, &channel_input_port_open_loud); } static void server_init_dispatch_15(void) --- session.c 28 Jan 2003 18:06:52 -0000 1.1.1.2 +++ session.c 29 Jan 2003 20:39:20 -0000 1.7 @@ -212,7 +214,7 @@ } /* setup the channel layer */ - if (!no_port_forwarding_flag && options.allow_tcp_forwarding) + if (!auth_restricted(RESTRICT_TCP, authctxt->pw)) channel_permit_all_opens(); if (compat20) @@ -312,7 +314,7 @@ break; case SSH_CMSG_AGENT_REQUEST_FORWARDING: - if (no_agent_forwarding_flag || compat13) { + if (auth_restricted(RESTRICT_AGENT, s->pw) || compat13) { debug("Authentication agent forwarding not permitted for this authentication."); break; } @@ -321,11 +323,7 @@ break; case SSH_CMSG_PORT_FORWARD_REQUEST: - if (no_port_forwarding_flag) { - debug("Port forwarding not permitted for this authentication."); - break; - } - if (!options.allow_tcp_forwarding) { + if (auth_restricted(RESTRICT_TCP, s->pw)) { debug("Port forwarding not permitted."); break; } @@ -1085,7 +1083,7 @@ auth_sock_name); /* read $HOME/.ssh/environment. */ - if (options.permit_user_env && !options.use_login) { + if (!options.use_login && !auth_restricted(RESTRICT_ENV, pw)) { snprintf(buf, sizeof buf, "%.200s/.ssh/environment", strcmp(pw->pw_dir, "/") ? pw->pw_dir : ""); read_environment_file(&env, &envsize, buf); @@ -1102,6 +1100,10 @@ /* * Run $HOME/.ssh/rc, /etc/ssh/sshrc, or xauth (whichever is found * first in this order). + * + * A properly-implemented restricted shell doesn't need the + * restriction tests, but they're useful for reducing the + * amount of noise in the process accounting logs. */ static void do_rc_files(Session *s, const char *shell) @@ -1111,11 +1113,12 @@ int do_xauth; struct stat st; - do_xauth = + do_xauth = !auth_restricted(RESTRICT_X11, s->pw) && s->display != NULL && s->auth_proto != NULL && s->auth_data != NULL; /* ignore _PATH_SSH_USER_RC for subsystems */ - if (!s->is_subsystem && (stat(_PATH_SSH_USER_RC, &st) >= 0)) { + if (!s->is_subsystem && !auth_restricted(RESTRICT_RC, s->pw) && + (stat(_PATH_SSH_USER_RC, &st) >= 0)) { snprintf(cmd, sizeof cmd, "%s -c '%s %s'", shell, _PATH_BSHELL, _PATH_SSH_USER_RC); if (debug_flag) @@ -1723,8 +1726,8 @@ { static int called = 0; packet_check_eom(); - if (no_agent_forwarding_flag) { - debug("session_auth_agent_req: no_agent_forwarding_flag"); + if (auth_restricted(RESTRICT_AGENT, s->pw)) { + debug("session_auth_agent_req: agent forwarding disabled"); return 0; } if (called) { @@ -2019,12 +2022,8 @@ char display[512], auth_display[512]; char hostname[MAXHOSTNAMELEN]; - if (no_x11_forwarding_flag) { - packet_send_debug("X11 forwarding disabled in user configuration file."); - return 0; - } - if (!options.x11_forwarding) { - debug("X11 forwarding disabled in server configuration file."); + if (auth_restricted(RESTRICT_X11, s->pw)) { + packet_send_debug("X11 forwarding disabled."); return 0; } if (!options.xauth_location || --- sshd_config.5 28 Jan 2003 18:06:53 -0000 1.1.1.2 +++ sshd_config.5 29 Jan 2003 21:26:12 -0000 1.8 @@ -465,6 +466,35 @@ If this option is set to .Dq no root is not allowed to login. +.It Cm PermitTcpConnect +Restricts TCP forwarding from the client so that +only certain connection destinations are permitted. +In the absence of any +.Cm PermitTcpConnect +options, any outgoing connection is permitted +(although per-key restrictions may be imposed by +.Cm permitopen="" +options in +.Pa authorized_keys +files). +If +.Cm PermitTcpConnect +options are present then +.Nm sshd +will only allow connections to the +.Ar host Ns : Ns Ar port +pairs that are specified. +Multiple permitted destinations may be specified using multiple +.Cm PermitTcpConnect +options. +IPv6 addresses may be specified using the syntax +.Ar host Ns / Ns Ar port +for the argument instead of +.Ar host Ns : Ns Ar port . +.It Cm PermitTcpListen +Specifies whether TCP forwarding to the client is allowed. +The default is +.Dq yes . .It Cm PermitUserEnvironment Specifies whether .Pa ~/.ssh/environment @@ -533,6 +563,29 @@ The default is .Dq yes . Note that this option applies to protocol version 2 only. +.It Cm RestrictedShell +This option selectively turns off various features +for users with the shell specified in the second argument. +The first argument is a comma-separated list, as follows. +If +.Dq agent +is specified then agent forwarding is disabled. +If +.Dq env +is specified then +.Cm PermitUserEnvironment +is turned off. +If +.Dq rc +is specified then +.Pa ~/.ssh/rc +is not run. +If +.Dq tcp +is specified then TCP port forwarding is disabled. +If +.Dq x11 +is specified then X11 fowarding is disabled. .It Cm RhostsAuthentication Specifies whether authentication using rhosts or /etc/hosts.equiv files is sufficient. From djm at mindrot.org Thu Jan 30 10:25:14 2003 From: djm at mindrot.org (Damien Miller) Date: Thu, 30 Jan 2003 10:25:14 +1100 Subject: PermitRootLogin=yes no longer lets root login In-Reply-To: <3E37D1CE.39D02604@zip.com.au> References: <3E37D1CE.39D02604@zip.com.au> Message-ID: <3E3862DA.5020503@mindrot.org> Darren Tucker wrote: > - if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES) > + if (pw->pw_uid == 0 && options.permit_root_login != oops, my bad. Fixed. -d From bugzilla-daemon at mindrot.org Thu Jan 30 20:35:00 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 30 Jan 2003 20:35:00 +1100 (EST) Subject: [Bug 478] New: add search function to website Message-ID: <20030130093500.190E66454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=478 Summary: add search function to website Product: Portable OpenSSH Version: older versions Platform: All URL: http://ant.apache.org OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Documentation AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: hauser at acm.org or at least use google to do it for you: http://www.google.ch/search?q=yourSearchTerm+site%3Awww.openssh.org for a nice placement of this, see the above reference ant website. ------- 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 Jan 30 20:46:31 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 30 Jan 2003 20:46:31 +1100 (EST) Subject: [Bug 479] New: add description how to run a ssh tunnel without a full shell on the remote site Message-ID: <20030130094631.3A91D64552@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=479 Summary: add description how to run a ssh tunnel without a full shell on the remote site Product: Portable OpenSSH Version: older versions Platform: All URL: http://www.openssh.org/manual.html OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Documentation AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: hauser at acm.org Application example: Shared hosting of a cvs repository. In http://www.cvshome.org/docs/ddSSHGuideCygwin.html, there is a good description, how to tunnel in general, but this requires a shell on the server-side. For security reasons, hosting providers who are willing to run a cvs for you may well not like you having full shell access on a shared server and thus don't like that. I have heard that there are approaches to do without a full shell? Or maybe as an additional question to: http://www.openssh.org/faq.html ? ------- 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 Jan 30 21:15:50 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 30 Jan 2003 21:15:50 +1100 (EST) Subject: [Bug 480] New: extend the -l or -L option to mention the ssh-agent's pid Message-ID: <20030130101550.24FA764552@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=480 Summary: extend the -l or -L option to mention the ssh-agent's pid 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: P5 Component: ssh-add AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: hauser at acm.org I have multiple ssh-agent's running, but I don't know which one is accessed by my ssh-add command. If with -*extra*l, I could find out, this would be helpful! ------- 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 Jan 30 21:27:24 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 30 Jan 2003 21:27:24 +1100 (EST) Subject: [Bug 481] New: Extend man page with documentation Message-ID: <20030130102724.9E9C164553@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=481 Summary: Extend man page with documentation Product: Portable OpenSSH Version: older versions Platform: All URL: http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-agent OS/Version: All Status: NEW Severity: normal Priority: P2 Component: ssh-agent AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: hauser at acm.org I am normally using tcsh. From bugzilla-daemon at mindrot.org Fri Jan 31 02:59:03 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 31 Jan 2003 02:59:03 +1100 (EST) Subject: [Bug 479] add description how to run a ssh tunnel without a full shell on the remote site Message-ID: <20030130155903.6B4DE6454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=479 ------- Additional Comments From hauser at acm.org 2003-01-31 02:59 ------- Created an attachment (id=213) --> (http://bugzilla.mindrot.org/attachment.cgi?id=213&action=view) scvs - a perl script Server-side installation steps as per steiner at acm.org: (1) create one (UNIX) login account with zzh as its login shell. (2) install the ssh public-keys for all CVS users of this account in .ssh (or .ssh2, depending on the ssh implementation) (3) in CVSROOT/passwd create aliases for the (CVS) accounts mapped on the UNIX account created in (1). --- second attachment also needed. ------- 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 Jan 31 03:02:49 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 31 Jan 2003 03:02:49 +1100 (EST) Subject: [Bug 479] add description how to run a ssh tunnel without a full shell on the remote site Message-ID: <20030130160249.E138E6454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=479 ------- Additional Comments From hauser at acm.org 2003-01-31 03:02 ------- Created an attachment (id=214) --> (http://bugzilla.mindrot.org/attachment.cgi?id=214&action=view) zzh.c - a minimum server-side shell by symlinking ~/bin/cvs ~/bin/scvs it also works in emacs (PCL-CVS) ------- 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 Jan 31 03:10:02 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 31 Jan 2003 03:10:02 +1100 (EST) Subject: [Bug 479] add description how to run a ssh tunnel without a full shell on the remote site Message-ID: <20030130161002.1DB3C6454C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=479 ------- Additional Comments From hauser at acm.org 2003-01-31 03:10 ------- Could perhaps also be done with rsync (win BAT file): http://bugzilla.privasphere.com/attachment.cgi?id=3&action=view Hopefully, such documentation will also go into cvshome! (see http://ccvs.cvshome.org/issues/show_bug.cgi?id=93) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Roumen.Petrov at skalasoft.com Fri Jan 31 04:58:04 2003 From: Roumen.Petrov at skalasoft.com (Roumen.Petrov at skalasoft.com) Date: Thu, 30 Jan 2003 19:58:04 +0200 Subject: X.509 certificates support in OpenSSH - version f is ready Message-ID: <3E3967AC.5080105@skalasoft.com> Hi all, I have pleasure to announce new version f of "X.509 certificates support in OpenSSH" Please to update your bookmarks/favorites with new location: http://roumenpetrov.info/openssh Old location is available too: http://satva.skalasoft.com/~rumen/openssh What's new: * support "Certificate Revocation Lists" (CRLs) * ssh-keyscan can show hostkey with certificates * information about X.509 certificates support added to all necessary manual pages * Distinguished name/Subject in RFC2253 format and item order is not important * script to create CRL used in tests * test scripts for ssh-agent and CRLs Note that version f has following preference of host key algorithms: "x509v3-sign-rsa,x509v3-sign-dss,ssh-rsa,ssh-dss" With this version development stage of "X.509 certificate support in OpenSSH" is finished and enter into maintenance phase. From des at ofug.org Fri Jan 31 21:57:50 2003 From: des at ofug.org (Dag-Erling Smorgrav) Date: Fri, 31 Jan 2003 11:57:50 +0100 Subject: verify_response() patch Message-ID: A non-text attachment was scrubbed... Name: auth-chall.diff Type: text/x-patch Size: 981 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030131/3bbba852/attachment.bin