From dtucker at zip.com.au Wed Feb 1 00:01:49 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 1 Feb 2006 00:01:49 +1100 Subject: badpw[] = "\b\n\r\177INCORRECT" In-Reply-To: References: Message-ID: <20060131130149.GB8478@gate.dtucker.net> On Tue, Jan 31, 2006 at 11:22:38AM -0000, Le Gal Philippe wrote: > Thank you for your prompt answer Darren, > > Unfortunately, it seems that nss_radius project looks like a dead-end > as I can't find any module already written for it. I'm failty new to > all this and I don't want to spend my time writing a nss_radius module. > > Do you know if such a module exists somewhere ? Sorry, no. I've seen references to it but not the code itself. It may not be publicly available (if it even exists). The other alternative is to modify sshd so that it does not require the user to be resolvable via getpwnam() (ie the "invalid user" check and still attempts to authenticate the user anyway. If you do this you will need to figure out how you'll map the RADIUS user to a Unix uid (all to one uid, from the RADIUS DV, generated on the fly, or some other scheme). Yhe things to watch for are a) which uid do you use for, eg, public-key authentication checks since you don't know a Unix uid for the user in question during authentication, and b) that (AFAIK) PAM_USER may change at any point during the authentication process. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Wed Feb 1 00:13:00 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 1 Feb 2006 00:13:00 +1100 Subject: badpw[] = "\b\n\r\177INCORRECT" In-Reply-To: <20060131130149.GB8478@gate.dtucker.net> References: <20060131130149.GB8478@gate.dtucker.net> Message-ID: <20060131131300.GA9235@gate.dtucker.net> On Wed, Feb 01, 2006 at 12:01:49AM +1100, Darren Tucker wrote: > that (AFAIK) PAM_USER may change at any point during the authentication > process. There's an old diff for this bit in the list archives: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=103073560705609&w=2 You would also need to change the getpwnam() test in auth.c (at the start of getpwnamallow()). I'm not sure how much work it would be to update that diff. I wouldn't mind looking at it but I'm unlikely to have much time in the immediate future. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From imorgan at nas.nasa.gov Wed Feb 1 04:11:19 2006 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 31 Jan 2006 09:11:19 -0800 (PST) Subject: ownership of authorized_keys In-Reply-To: <1138663041.23965.52.camel@localhost.localdomain> from "David Woodhouse" at Jan 31, 2006 10:17:20 AM Message-ID: <200601311711.k0VHBK0j001749@sun601.nas.nasa.gov> On Mon Jan 30 15:17:20 2006, David Woodhouse wrote: > > On Thu, 2006-01-19 at 09:09 -0800, Iain Morgan wrote: > > That's already the case. The files can be owned by root, but they must > > be readable by the user. Either use a per-user group or POSIX ACLs to > > allow the user to read the contents. > > Or just allow them to be world-readable, of course. These are _public_ > keys we're talking about, after all. > > -- True. However in the case of command-restricted keys, it may not be desirable to divulge the command associated with a particular key to arbitrary users. Essentially it's the standard axiom of least privileges. -- Iain Morgan From rr_itcsec at t-online.de Wed Feb 1 07:47:36 2006 From: rr_itcsec at t-online.de (RR_ITCSEC) Date: Tue, 31 Jan 2006 21:47:36 +0100 Subject: External port forwarding control mechanism Message-ID: <001901c626a7$91ecd890$02fea8c0@silentium> Hi, I'm looking for the best way to include an external decision mechanism into OpenSSH, which allows it to restrict port forwarding only to destination ports which are defined in a special external control file for the authenticated session. The authenticated ssh user should only be allowed to connect to this dedicated port to tunnel a VNC session through ssh. So the server side has to decide if the received client data in the ssh channel could be forwarded or not. Does there already exist a solution for the current OpenSSH version? Last year I read in a mailing list, that such behavior was included in earlier versions of OpenSSH. Regards, Roland From f_mohr at yahoo.de Wed Feb 1 20:06:08 2006 From: f_mohr at yahoo.de (Frank Mohr) Date: Wed, 01 Feb 2006 10:06:08 +0100 Subject: External port forwarding control mechanism In-Reply-To: <001901c626a7$91ecd890$02fea8c0@silentium> References: <001901c626a7$91ecd890$02fea8c0@silentium> Message-ID: <43E07A00.7030107@yahoo.de> RR_ITCSEC wrote: > Hi, > > I'm looking for the best way to include an external decision mechanism into > OpenSSH, which allows it to restrict port forwarding only to destination > ports which are defined in a special external control file for the > authenticated session. The authenticated ssh user should only be allowed to > connect to this dedicated port to tunnel a VNC session through ssh. So the > server side has to decide if the received client data in the ssh channel > could be forwarded or not. > Does there already exist a solution for the current OpenSSH version? > > Last year I read in a mailing list, that such behavior was included in > earlier versions of OpenSSH. you can add permitopen= to the keys: permitopen="host:port" Limit local ``ssh -L'' port forwarding such that it may only con- nect to the specified host and port. IPv6 addresses can be spec- ified with an alternative syntax: host/port. Multiple permitopen options may be applied separated by commas. No pattern matching is performed on the specified hostnames, they must be literal domains or addresses. frank ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de From Tinvir.Maula at barclaycard.co.uk Wed Feb 1 22:02:32 2006 From: Tinvir.Maula at barclaycard.co.uk (Maula Tinvir) Date: Wed, 1 Feb 2006 11:02:32 -0000 Subject: Bugtrag 16369 Message-ID: <4F94825D124F9446A408D09A6928F6660248750B@ELLEN.cardservices.cardcorp.net> Hi, I have a some questions about bugtrag 16369 (OpenSSH local SCP Shell Command Execution Vulnerability). How exactly can this vulnerability be exploited by a local user (I know it can lead to elevated privileges)? Is there a patch available for this yet? I would appreciate any help you can provide. Kind Regrets Tinvir(Unix Security). Legal Disclaimer:- Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. From djm at cvs.openbsd.org Wed Feb 1 23:30:32 2006 From: djm at cvs.openbsd.org (Damien Miller) Date: Wed, 1 Feb 2006 05:30:32 -0700 (MST) Subject: Announce: OpenSSH 4.3 released Message-ID: <200602011230.k11CUWxH028580@cvs.openbsd.org> OpenSSH 4.3 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We have also recently completed another Internet SSH usage scan, the results of which may be found at http://www.openssh.com/usage.html Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots and purchased T-shirts or posters. T-shirt, poster and CD sales directly support the project. Pictures and more information can be found at: http://www.openbsd.org/tshirts.html and http://www.openbsd.org/orders.html For international orders use http://https.openbsd.org/cgi-bin/order and for European orders, use http://https.openbsd.org/cgi-bin/order.eu Changes since OpenSSH 4.2: ============================ Security bugs resolved in this release: * CVE-2006-0225: scp (as does rcp, on which it is based) invoked a subshell to perform local to local, and remote to remote copy operations. This subshell exposed filenames to shell expansion twice; allowing a local attacker to create filenames containing shell metacharacters that, if matched by a wildcard, could lead to execution of attacker-specified commands with the privilege of the user running scp (Bugzilla #1094) This is primarily a bug-fix release, only one new feature has been added: * Add support for tunneling arbitrary network packets over a connection between an OpenSSH client and server via tun(4) virtual network interfaces. This allows the use of OpenSSH (4.3+) to create a true VPN between the client and server providing real network connectivity at layer 2 or 3. This feature is experimental and is currently supported on OpenBSD, Linux, NetBSD (IPv4 only) and FreeBSD. Other operating systems with tun/tap interface capability may be added in future portable OpenSSH releases. Please refer to the README.tun file in the source distribution for further details and usage examples. Some of the other bugs resolved and internal improvements are: * Reduce default key length for new DSA keys generated by ssh-keygen back to 1024 bits. DSA is not specified for longer lengths and does not fully benefit from simply making keys longer. As per FIPS 186-2 Change Notice 1, ssh-keygen will refuse to generate a new DSA key smaller or larger than 1024 bits * Fixed X forwarding failing to start when a the X11 client is executed in background at the time of session exit (Bugzilla #1086) * Change ssh-keygen to generate a protocol 2 RSA key when invoked without arguments (Bugzilla #1064) * Fix timing variance for valid vs. invalid accounts when attempting Kerberos authentication (Bugzilla #975) * Ensure that ssh always returns code 255 on internal error (Bugzilla #1137) * Cleanup wtmp files on SIGTERM when not using privsep (Bugzilla #1029) * Set SO_REUSEADDR on X11 listeners to avoid problems caused by lingering sockets from previous session (X11 applications can sometimes not connect to 127.0.0.1:60xx) (Bugzilla #1076) * Ensure that fds 0, 1 and 2 are always attached in all programs, by duping /dev/null to them if necessary. * Xauth list invocation had bogus "." argument (Bugzilla #1082) * Remove internal assumptions on key exchange hash algorithm and output length, preparing OpenSSH for KEX methods with alternate hashes. * Ignore junk sent by a server before it sends the "SSH-" banner (Bugzilla #1067) * The manpages has been significantly improves and rearranged, in addition to other specific manpage fixes: #1037 - Man page entries for -L and -R should mention -g. #1077 - Descriptions for "ssh -D" and DynamicForward should mention they can specify "bind_address" optionally. #1088 - Incorrect descriptions in ssh_config man page for ControlMaster=no. #1121 - Several corrections for ssh_agent manpages * Lots of cleanups, including fixes to memory leaks on error paths (Bugzilla #1109, #1110, #1111 and more) and possible crashes (#1092) * Portable OpenSSH-specific fixes: - Pass random seed during re-exec for each connection: speeds up processing of new connections on platforms using the OpenSSH's builtin entropy collector (ssh-rand-helper) - PAM fixes and improvements: #1045 - Missing option for ignoring the /etc/nologin file #1087 - Show PAM password expiry message from LDAP on login #1028 - Forward final non-query conversations to client #1126 - Prevent user from being forced to change an expired password repeatedly on AIX in some PAM configurations. #1045 - Do not check /etc/nologin when PAM is enabled, instead allow PAM to handle it. Note that on platforms using PAM, the pam_nologin module should be used in sshd's session stack in order to maintain past behaviour - Portability-related fixes: #989 - Fix multiplexing regress test on Solaris #1097 - Cross-compile fixes. #1096 - ssh-keygen broken on HPUX. #1098 - $MAIL being set incorrectly for HPUX server login. #1104 - Compile error on Tru64 Unix 4.0f #1106 - Updated .spec file and startup for SuSE. #1122 - Use _GNU_SOURCE define in favor of __USE_GNU, fixing compilation problems on glibc 2.4 Thanks to everyone who has contributed patches, reported bugs or test releases. Checksums: ========== - SHA1 (openssh-4.3.tar.gz) = 0cb66e56805d66b51511455423bab88aa58a1455 - SHA1 (openssh-4.3p1.tar.gz) = b1f379127829e7e820955b2825130edd1601ba59 Reporting Bugs: =============== - please read http://www.openssh.com/report.html and http://bugzilla.mindrot.org/ OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From simon at sxw.org.uk Wed Feb 1 23:53:03 2006 From: simon at sxw.org.uk (Simon Wilkinson) Date: Wed, 01 Feb 2006 12:53:03 +0000 Subject: Anonymous CVS access? Message-ID: <43E0AF2F.6030309@sxw.org.uk> The openssh website still lists anoncvs.at.openbsd.org as being the place to go for anonymous CVS access to the portable sources. However, that site appears to be down (and no longer in the DNS), and has been removed from the OpenBSD list of mirrors. Is there another location offering anonymous CVS access? Thanks, Simon. From rapier at psc.edu Thu Feb 2 06:38:26 2006 From: rapier at psc.edu (Chris Rapier) Date: Wed, 01 Feb 2006 14:38:26 -0500 Subject: HPN patch for OpenSSH 4.3 released Message-ID: <43E10E32.9050204@psc.edu> http://www.psc.edu/networking/projects/hpn-ssh There have been some changes to the command line switches which are detailed on the website. This is more of a stop gap release than anything else. This is still in the HPN-11 cycle of patches. We hope to have an update to HPN-12 out sometime in March (when I can get some freetime). This will conform more closely to the OpenSSH nomenclature and argument structure. Basic functionality has been tested. We're still getting a 20x to 30x performance improvement for bulk data transfer on paths with high BDP. I don't think we've broken any of the new functionality but if someone does find a problem please let me know ASAP. Also, if anyone here is using the GSI patch (Grid Security Infrastructure) a new version has been released from NCSA which incorporates the HPN patch. http://www.cmu.edu/PR/releases06/060125_gsi.html and http://grid.ncsa.uiuc.edu/ssh/ Thanks! Chris Rapier Pittsburgh Supercomputing Center From dtucker at zip.com.au Thu Feb 2 18:20:57 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 2 Feb 2006 18:20:57 +1100 Subject: Anonymous CVS access? In-Reply-To: <43E0AF2F.6030309@sxw.org.uk> References: <43E0AF2F.6030309@sxw.org.uk> Message-ID: <20060202072057.GA6103@gate.dtucker.net> On Wed, Feb 01, 2006 at 12:53:03PM +0000, Simon Wilkinson wrote: > The openssh website still lists anoncvs.at.openbsd.org as being the > place to go for anonymous CVS access to the portable sources. However, > that site appears to be down (and no longer in the DNS), and has been > removed from the OpenBSD list of mirrors. The problems will apparently be resolved eventually, but it may be a month or two. > Is there another location offering anonymous CVS access? None that I know of. If there's enough demand, I may be able to set up an alternative on a temporary basis. -- 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 Feb 2 18:28:27 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 2 Feb 2006 18:28:27 +1100 Subject: Bugtrag 16369 In-Reply-To: <4F94825D124F9446A408D09A6928F6660248750B@ELLEN.cardservices.cardcorp.net> References: <4F94825D124F9446A408D09A6928F6660248750B@ELLEN.cardservices.cardcorp.net> Message-ID: <20060202072827.GB6103@gate.dtucker.net> On Wed, Feb 01, 2006 at 11:02:32AM -0000, Maula Tinvir wrote: > I have a some questions about bugtrag 16369 (OpenSSH local SCP Shell > Command Execution Vulnerability). How exactly can this vulnerability be > exploited by a local user (I know it can lead to elevated privileges)? Assuming that's CVE-2006-0225, it seems that a malicious user must create a file and then cause (or wait for) the victim to attempt to copy it. > Is there a patch available for this yet? The fix is in the just-released OpenSSH 4.3p1, and the patch is over in the bug: http://bugzilla.mindrot.org/show_bug.cgi?id=1094 -- 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 Feb 2 20:34:28 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 2 Feb 2006 20:34:28 +1100 Subject: Red: PAM auth with disabled user In-Reply-To: References: Message-ID: <20060202093428.GB7603@gate.dtucker.net> On Wed, Feb 01, 2006 at 05:28:40PM -0800, Peter Michalek wrote: > The patch you suggested works OK, I tried it on the snapshot of 1/28/06 > using a user authenticated via GSSAPI/Kerberos, with this result, which > I think is acceptable: [...] It's not clear to me from the output, but does the connection close after the PAM account check failed? > Could we make this part of the openssh sourcebase? I think so, once it's clear that it's doing what it is intended, which is to make the behaviour more consistent with the different auth methods. (Damien?) -- 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 Christian.Pelissier at onera.fr Thu Feb 2 21:23:07 2006 From: Christian.Pelissier at onera.fr (Christian PELISSIER) Date: Thu, 02 Feb 2006 11:23:07 +0100 Subject: Report of some warning during openssh 4.3 configure Message-ID: <1138875787.8880.527.camel@styx> Host: sparc-sun-solaris2.9 ./configure --prefix=/usr/local/openssh --with-skey=/usr/local/skey \ > --with-ssl-dir=/usr/local/openssl CC=cc CFLAGS=-O \ > LDFLAGS="-L /usr/local/skey/lib -R /usr/local/skey/lib" checking lastlog.h presence... yes configure: WARNING: lastlog.h: present but cannot be compiled configure: WARNING: lastlog.h: check for missing prerequisite headers? configure: WARNING: lastlog.h: see the Autoconf documentation configure: WARNING: lastlog.h: section "Present But Cannot Be Compiled" configure: WARNING: lastlog.h: proceeding with the preprocessor's result configure: WARNING: lastlog.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## checking for lastlog.h... yes ... checking net/if.h usability... no checking net/if.h presence... yes configure: WARNING: net/if.h: present but cannot be compiled configure: WARNING: net/if.h: check for missing prerequisite headers? configure: WARNING: net/if.h: see the Autoconf documentation configure: WARNING: net/if.h: section "Present But Cannot Be Compiled" configure: WARNING: net/if.h: proceeding with the preprocessor's result configure: WARNING: net/if.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## checking for net/if.h... yes .... checking netinet/in_systm.h usability... no checking netinet/in_systm.h presence... yes configure: WARNING: netinet/in_systm.h: present but cannot be compiled configure: WARNING: netinet/in_systm.h: check for missing prerequisite headers? configure: WARNING: netinet/in_systm.h: see the Autoconf documentation configure: WARNING: netinet/in_systm.h: section "Present But Cannot Be Compiled" configure: WARNING: netinet/in_systm.h: proceeding with the preprocessor's result configure: WARNING: netinet/in_systm.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## -- Christian P?lissier Office National d'?tudes et de Recherches A?rospatiales BP 72 92322 Chatillon Tel: 33 1 46 73 44 19, Fax: 33 1 46 73 41 50 From Tob_Sch at gmx.de Fri Feb 3 03:03:13 2006 From: Tob_Sch at gmx.de (Tob_Sch at gmx.de) Date: Thu, 2 Feb 2006 17:03:13 +0100 (MET) Subject: Make error durring compilation of OpenSSH 4.3p1 on HP-UX 11.00 Message-ID: <10782.1138896193@www020.gmx.net> Hi, compilation of OpenSSH 4.2p1 / OpenSSL 0.9.8a / zlib 1.2.3 worked fine on Linux i386 / x86_64, SunOS, AIX and HP-UX. Compilation of OpenSSH 4.3p1 / OpenSSL 0.9.8a / zlib 1.2.3 works fine now only on Linux i386 / x86_64, SunOS, AIX. But on HP-UX 11.00 (gcc 3.3.2), "make" produces following... (cd openbsd-compat && make) gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o -L. -Lopenbsd-compat/ -L/tmp/openssl-0.9.8a -L/tmp/zlib-1.2.3 -lssh -lopenbsd-compat -lcrypto -lz -lnsl -lxnet -ldld -lsec /usr/ccs/bin/ld: Unsatisfied symbols: _U_Qfneg (first referenced in openbsd-compat//libopenbsd-compat.a(bsd-arc4random.o)) (code) collect2: ld returned 1 exit status *** Error exit code 1 Stop. Thanks in advance for help. -- DSL-Aktion wegen gro?er Nachfrage bis 28.2.2006 verl?ngert: GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl From goebel at emunix.emich.edu Fri Feb 3 04:07:54 2006 From: goebel at emunix.emich.edu (Matt Goebel) Date: Thu, 2 Feb 2006 12:07:54 -0500 (EST) Subject: OpenSSH_4.3p1, OpenSSL 0.9.8a 11 Oct 2005 on solaris 8/9 Message-ID: <200602021707.k12H7sTR018686@poe.emich.edu> Howdy, Not sure, but it appears that OpenSSH_4.3p1 on solaris creates bad wtmpx entries during login? mgoebel pts/5 Wed Dec 31 19:00 still logged in It is creating entries for Dec 31st 1969. Thanks, Matt -- Matthew Goebel : goebel at emunix.emich.edu : Unix Jockey @ EMU : Hail Eris Neo-Student, Net Lurker, Donut consumer, and procrastinating Furry Fan. "Always with the negative waves, Moriarty" - Oddball "Comfort the troubled, and trouble the comfortable." - Dietrich Bonhoeffer From peter.michalek at centrify.com Fri Feb 3 04:06:33 2006 From: peter.michalek at centrify.com (Peter Michalek) Date: Thu, 2 Feb 2006 09:06:33 -0800 Subject: PAM auth with disabled user Message-ID: Here is a complete screenshot. After failing in Kerberos "keybord-interactive", authentication falls to the local "password authentication" (this would happen both before and after modifications, the only difference is the extra message indicating the account is locked). ssh fred.dref at rhel3-host Red Hat Enterprise Linux ES release 3 (Taroon Update 2) Kernel \r on an \m Password: Account cannot be accessed at this time. Please contact your system administrator Password: Account cannot be accessed at this time. Please contact your system administrator Password: Account cannot be accessed at this time. Please contact your system administrator fred.dref at rhel3-host's password: Permission denied, please try again. fred.dref at rhel3-host's password: Received disconnect from 192.168.175.50: 2: Too many authentication failures for fred.dref ---------- Without the changes, this is what would happens: ssh fred.dref at rhel3-host Red Hat Enterprise Linux ES release 3 (Taroon Update 2) Kernel \r on an \m Password: Password: Password: fred.dref at rhel3-host's password: Permission denied, please try again. fred.dref at rhel3-host's password: Received disconnect from 192.168.175.50: 2: Too many authentication failures for fred.dref -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Thursday, February 02, 2006 1:34 AM To: Peter Michalek Cc: openssh-unix-dev at mindrot.org; Paul Moore Subject: Re: Red: PAM auth with disabled user On Wed, Feb 01, 2006 at 05:28:40PM -0800, Peter Michalek wrote: > The patch you suggested works OK, I tried it on the snapshot of 1/28/06 > using a user authenticated via GSSAPI/Kerberos, with this result, which > I think is acceptable: [...] It's not clear to me from the output, but does the connection close after the PAM account check failed? > Could we make this part of the openssh sourcebase? I think so, once it's clear that it's doing what it is intended, which is to make the behaviour more consistent with the different auth methods. (Damien?) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From Bill.Fischer at qwest.com Fri Feb 3 06:40:05 2006 From: Bill.Fischer at qwest.com (Fischer, Bill) Date: Thu, 2 Feb 2006 13:40:05 -0600 Subject: OpenSSH_4.3p1, OpenSSL 0.9.8a 11 Oct 2005 on solaris 8/9 Message-ID: <01B031F62986434EACE76AEC21640C23D87E8C@QTOMAE2K3M01.AD.QINTRA.COM> I'll confirm that finding on Solaris 8 for sparc. It seems to provide the logout time correctly, if that's of any help. user pts/1 Wed Dec 31 19:00 - 14:36 (13181+19: -----Original Message----- From: openssh-unix-dev-bounces+bill.fischer=qwest.com at mindrot.org [mailto:openssh-unix-dev-bounces+bill.fischer=qwest.com at mindrot.org] On Behalf Of Matt Goebel Sent: Thursday, February 02, 2006 11:08 AM To: openssh-unix-dev at mindrot.org Subject: OpenSSH_4.3p1, OpenSSL 0.9.8a 11 Oct 2005 on solaris 8/9 Howdy, Not sure, but it appears that OpenSSH_4.3p1 on solaris creates bad wtmpx entries during login? mgoebel pts/5 Wed Dec 31 19:00 still logged in It is creating entries for Dec 31st 1969. Thanks, Matt -- Matthew Goebel : goebel at emunix.emich.edu : Unix Jockey @ EMU : Hail Eris Neo-Student, Net Lurker, Donut consumer, and procrastinating Furry Fan. "Always with the negative waves, Moriarty" - Oddball "Comfort the troubled, and trouble the comfortable." - Dietrich Bonhoeffer _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From rac at tenzing.org Fri Feb 3 07:02:10 2006 From: rac at tenzing.org (Roger Cornelius) Date: Thu, 2 Feb 2006 15:02:10 -0500 Subject: OpenSSH_4.3p1, OpenSSL 0.9.8a 11 Oct 2005 on solaris 8/9 In-Reply-To: <200602021707.k12H7sTR018686@poe.emich.edu> References: <200602021707.k12H7sTR018686@poe.emich.edu> Message-ID: <20060202200210.GA15283@tenzing.org> On 02/02/2006 12:07, Matt Goebel wrote: > > Howdy, > > Not sure, but it appears that OpenSSH_4.3p1 on solaris creates > bad wtmpx entries during login? > > mgoebel pts/5 Wed Dec 31 19:00 still logged in > > It is creating entries for Dec 31st 1969. I've had similar problems on SCO OpenServer 6 (which has other wtmp problems as well). Try building with -DBROKEN_UPDWTMPX and see if that helps. -- Roger Cornelius rac at tenzing.org From goebel at emunix.emich.edu Fri Feb 3 07:46:31 2006 From: goebel at emunix.emich.edu (Matt Goebel) Date: Thu, 2 Feb 2006 15:46:31 -0500 (EST) Subject: OpenSSH_4.3p1, OpenSSL 0.9.8a 11 Oct 2005 on solaris 8/9 In-Reply-To: <20060202200210.GA15283@tenzing.org> Message-ID: <200602022046.k12KkVkX001686@poe.emich.edu> Tried it but, that dosen't appear to have any effect on the solaris issue. Thanks, Matt And now a bit of polka music by "Roger Cornelius" > > On 02/02/2006 12:07, Matt Goebel wrote: > > > > Howdy, > > > > Not sure, but it appears that OpenSSH_4.3p1 on solaris creates > > bad wtmpx entries during login? > > > > mgoebel pts/5 Wed Dec 31 19:00 still logged in > > > > It is creating entries for Dec 31st 1969. > > I've had similar problems on SCO OpenServer 6 (which has other wtmp > problems as well). Try building with -DBROKEN_UPDWTMPX and see if that > helps. > -- > Roger Cornelius rac at tenzing.org > -- Matthew Goebel : goebel at emunix.emich.edu : Unix Jockey @ EMU : Hail Eris Neo-Student, Net Lurker, Donut consumer, and procrastinating Furry Fan. "Always with the negative waves, Moriarty" - Oddball "Comfort the troubled, and trouble the comfortable." - Dietrich Bonhoeffer From tpg at umich.edu Fri Feb 3 07:47:17 2006 From: tpg at umich.edu (Terry Gliedt) Date: Thu, 02 Feb 2006 15:47:17 -0500 Subject: 1. Configure problems on openssh-4.3p1, SunOS 5.8 Message-ID: <43E26FD5.8080104@umich.edu> Trying to make openssh-4.3p1 with openssl-0.9.8a and zlib-1.2.3 uname -a SunOS gauss.hg.med.umich.edu 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-80 Doing the configure I got these messages. checking lastlog.h presence... yes configure: WARNING: lastlog.h: present but cannot be compiled configure: WARNING: lastlog.h: check for missing prerequisite headers? configure: WARNING: lastlog.h: see the Autoconf documentation configure: WARNING: lastlog.h: section "Present But Cannot Be Compiled" configure: WARNING: lastlog.h: proceeding with the preprocessor's result configure: WARNING: lastlog.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## checking for lastlog.h... yes checking net/if.h presence... yes configure: WARNING: net/if.h: present but cannot be compiled configure: WARNING: net/if.h: check for missing prerequisite headers? configure: WARNING: net/if.h: see the Autoconf documentation configure: WARNING: net/if.h: section "Present But Cannot Be Compiled" configure: WARNING: net/if.h: proceeding with the preprocessor's result configure: WARNING: net/if.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## checking for net/if.h... yes checking netinet/in_systm.h usability... no checking netinet/in_systm.h presence... yes configure: WARNING: netinet/in_systm.h: present but cannot be compiled configure: WARNING: netinet/in_systm.h: check for missing prerequisite heade rs? configure: WARNING: netinet/in_systm.h: see the Autoconf documentation configure: WARNING: netinet/in_systm.h: section "Present But Cannot Be Compiled" configure: WARNING: netinet/in_systm.h: proceeding with the preprocessor's result configure: WARNING: netinet/in_systm.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## -- ============================================================= Terry Gliedt tpg at umich.edu http://www.hps.com/~tpg/ Biostatistics, Univ of Michigan Personal Email: tpg at hps.com From vinschen at redhat.com Fri Feb 3 08:31:51 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 2 Feb 2006 22:31:51 +0100 Subject: OpenSSH_4.3p1, OpenSSL 0.9.8a 11 Oct 2005 on solaris 8/9 In-Reply-To: <01B031F62986434EACE76AEC21640C23D87E8C@QTOMAE2K3M01.AD.QINTRA.COM> References: <01B031F62986434EACE76AEC21640C23D87E8C@QTOMAE2K3M01.AD.QINTRA.COM> Message-ID: <20060202213151.GU15572@calimero.vinschen.de> On Feb 2 13:40, Fischer, Bill wrote: > I'll confirm that finding on Solaris 8 for sparc. > > It seems to provide the logout time correctly, if that's of any help. > > user pts/1 Wed Dec 31 19:00 - 14:36 > (13181+19: > > > -----Original Message----- > From: openssh-unix-dev-bounces+bill.fischer=qwest.com at mindrot.org > [mailto:openssh-unix-dev-bounces+bill.fischer=qwest.com at mindrot.org] On > Behalf Of Matt Goebel > Sent: Thursday, February 02, 2006 11:08 AM > To: openssh-unix-dev at mindrot.org > Subject: OpenSSH_4.3p1, OpenSSL 0.9.8a 11 Oct 2005 on solaris 8/9 > > > Howdy, > > Not sure, but it appears that OpenSSH_4.3p1 on solaris creates bad > wtmpx entries during login? > > mgoebel pts/5 Wed Dec 31 19:00 still logged > in > > It is creating entries for Dec 31st 1969. > > Thanks, > Matt I can confirm the same problem on Cygwin. I reran configure from scratch and found the following strange log entries: checking for ut_host field in utmp.h... no checking for ut_host field in utmpx.h... no checking for syslen field in utmpx.h... no checking for ut_pid field in utmp.h... no checking for ut_type field in utmp.h... no checking for ut_type field in utmpx.h... no checking for ut_tv field in utmp.h... no checking for ut_id field in utmp.h... no checking for ut_id field in utmpx.h... no checking for ut_addr field in utmp.h... no checking for ut_addr field in utmpx.h... no checking for ut_addr_v6 field in utmp.h... no checking for ut_addr_v6 field in utmpx.h... no checking for ut_exit field in utmp.h... no checking for ut_time field in utmp.h... no checking for ut_time field in utmpx.h... no checking for ut_tv field in utmpx.h... no Nearly all of these fields are actually present in the affected structures utmp and utmpx. This looks like a bug in the OSSH_CHECK_HEADER_FOR_FIELD routine to me. The problem was not present in the 4.2p1 configury. However, this is just a heads up. I have no patch so far. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From David.Leonard at quest.com Fri Feb 3 08:42:23 2006 From: David.Leonard at quest.com (David Leonard) Date: Fri, 03 Feb 2006 07:42:23 +1000 Subject: Make error durring compilation of OpenSSH 4.3p1 on HP-UX 11.00 In-Reply-To: <10782.1138896193@www020.gmx.net> References: <10782.1138896193@www020.gmx.net> Message-ID: <43E27CBF.7000100@quest.com> Tob_Sch at gmx.de wrote: >But on HP-UX 11.00 (gcc 3.3.2), "make" produces following. >[...] >/usr/ccs/bin/ld: Unsatisfied symbols: > _U_Qfneg (first referenced in >openbsd-compat//libopenbsd-compat.a(bsd-arc4random.o)) (code) > > gcc is busted on your platform. use hp's compiler, or try this horrible patch: --- openbsd-compat/bsd-snprintf.c 23 Dec 2005 00:58:12 -0000 1.3 +++ openbsd-compat/bsd-snprintf.c 2 Feb 2006 21:39:00 -0000 @@ -551,12 +551,13 @@ } } +LDOUBLE _hackery_zero = 0; static LDOUBLE abs_val(LDOUBLE value) { LDOUBLE result = value; if (value < 0) - result = -value; + result = _hackery_zero-value; return result; } bugzilla seems to be down, put there's probably a bug against this already d From vinschen at redhat.com Fri Feb 3 09:07:57 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 2 Feb 2006 23:07:57 +0100 Subject: configure bug (was Re: OpenSSH_4.3p1, OpenSSL 0.9.8a 11 Oct 2005 on solaris 8/9) In-Reply-To: <20060202213151.GU15572@calimero.vinschen.de> References: <01B031F62986434EACE76AEC21640C23D87E8C@QTOMAE2K3M01.AD.QINTRA.COM> <20060202213151.GU15572@calimero.vinschen.de> Message-ID: <20060202220757.GV15572@calimero.vinschen.de> On Feb 2 22:31, Corinna Vinschen wrote: > I can confirm the same problem on Cygwin. I reran configure from scratch > and found the following strange log entries: > > checking for ut_host field in utmp.h... no > checking for ut_host field in utmpx.h... no > checking for syslen field in utmpx.h... no > checking for ut_pid field in utmp.h... no > checking for ut_type field in utmp.h... no > checking for ut_type field in utmpx.h... no > checking for ut_tv field in utmp.h... no > checking for ut_id field in utmp.h... no > checking for ut_id field in utmpx.h... no > checking for ut_addr field in utmp.h... no > checking for ut_addr field in utmpx.h... no > checking for ut_addr_v6 field in utmp.h... no > checking for ut_addr_v6 field in utmpx.h... no > checking for ut_exit field in utmp.h... no > checking for ut_time field in utmp.h... no > checking for ut_time field in utmpx.h... no > checking for ut_tv field in utmpx.h... no > > Nearly all of these fields are actually present in the affected > structures utmp and utmpx. This looks like a bug in the > OSSH_CHECK_HEADER_FOR_FIELD routine to me. The problem was not > present in the 4.2p1 configury. > > However, this is just a heads up. I have no patch so far. I have found the cause. It's sort of an autoconf problem. The OSSH_CHECK_HEADER_FOR_FIELD macro uses $EGREP. The configure.ac file does not explicitely test for egrep, but relies on a formerly made egrep test. However, $EGREP is evaluated by autoconf only once, at the point where the first AC_CHECK_HEADER or AC_CHECK_HEADRERS is called in the configure.ac file. The problem now is, that the first occurance of AC_CHECK_HEADER/ AC_CHECK_HEADRERS is in the big "case "$host" in" statement, called for the *-*-linux host triple. You can easily check this by examining the generated configure. The EGREP test is only made in the linux branch of the case statement. No wonder this didn't happen in 4.2p1, since the new AC_CHECK_HEADER tests in the case statement have been added for the tunnel device header checks on Linux, NetBSD and FreeBSD. One possible fix would be to move the zlib.h header file check before the case statement. When doing this, autoconf would generate the EGREP test early enough, so that all OSes will get a valid $EGREP value, which in turn lets the OSSH_CHECK_HEADER_FOR_FIELD test return useful results. Another possible fix is to add an explicit test for egrep, which would be the best solution probably. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From dtucker at zip.com.au Fri Feb 3 10:00:09 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 3 Feb 2006 10:00:09 +1100 Subject: configure bug (was Re: OpenSSH_4.3p1, OpenSSL 0.9.8a 11 Oct 2005 on solaris 8/9) In-Reply-To: <20060202220757.GV15572@calimero.vinschen.de> References: <01B031F62986434EACE76AEC21640C23D87E8C@QTOMAE2K3M01.AD.QINTRA.COM> <20060202213151.GU15572@calimero.vinschen.de> <20060202220757.GV15572@calimero.vinschen.de> Message-ID: <20060202230009.GA22495@gate.dtucker.net> On Thu, Feb 02, 2006 at 11:07:57PM +0100, Corinna Vinschen wrote: [...] > I have found the cause. It's sort of an autoconf problem. The > OSSH_CHECK_HEADER_FOR_FIELD macro uses $EGREP. The configure.ac > file does not explicitely test for egrep, but relies on a formerly > made egrep test. [...] > Another possible fix is to add an explicit test for egrep, which would > be the best solution probably. Sigh. So something like this ought to do it? Index: configure.ac =================================================================== RCS file: /var/cvs/openssh/configure.ac,v retrieving revision 1.323 diff -u -p -r1.323 configure.ac --- configure.ac 2 Feb 2006 07:44:19 -0000 1.323 +++ configure.ac 2 Feb 2006 22:49:29 -0000 @@ -27,6 +27,7 @@ AC_PROG_AWK AC_PROG_CPP AC_PROG_RANLIB AC_PROG_INSTALL +AC_PROG_EGREP AC_PATH_PROG(AR, ar) AC_PATH_PROG(CAT, cat) AC_PATH_PROG(KILL, kill) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From tim at multitalents.net Fri Feb 3 11:24:54 2006 From: tim at multitalents.net (Tim Rice) Date: Thu, 2 Feb 2006 16:24:54 -0800 (PST) Subject: configure bug (was Re: OpenSSH_4.3p1, OpenSSL 0.9.8a 11 Oct 2005 on solaris 8/9) In-Reply-To: <20060202230009.GA22495@gate.dtucker.net> References: <01B031F62986434EACE76AEC21640C23D87E8C@QTOMAE2K3M01.AD.QINTRA.COM> <20060202213151.GU15572@calimero.vinschen.de> <20060202220757.GV15572@calimero.vinschen.de> <20060202230009.GA22495@gate.dtucker.net> Message-ID: On Fri, 3 Feb 2006, Darren Tucker wrote: > On Thu, Feb 02, 2006 at 11:07:57PM +0100, Corinna Vinschen wrote: > [...] > > I have found the cause. It's sort of an autoconf problem. The > > OSSH_CHECK_HEADER_FOR_FIELD macro uses $EGREP. The configure.ac > > file does not explicitely test for egrep, but relies on a formerly > > made egrep test. > [...] > > Another possible fix is to add an explicit test for egrep, which would > > be the best solution probably. > > Sigh. So something like this ought to do it? Yes that works. And a much more elegant solution than what I was considering. Next time I'll read all my mail before diving into a problem. ;-) Good work Corinna. > > Index: configure.ac > =================================================================== > RCS file: /var/cvs/openssh/configure.ac,v > retrieving revision 1.323 > diff -u -p -r1.323 configure.ac > --- configure.ac 2 Feb 2006 07:44:19 -0000 1.323 > +++ configure.ac 2 Feb 2006 22:49:29 -0000 > @@ -27,6 +27,7 @@ AC_PROG_AWK > AC_PROG_CPP > AC_PROG_RANLIB > AC_PROG_INSTALL > +AC_PROG_EGREP > AC_PATH_PROG(AR, ar) > AC_PATH_PROG(CAT, cat) > AC_PATH_PROG(KILL, kill) > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Fri Feb 3 12:01:37 2006 From: tim at multitalents.net (Tim Rice) Date: Thu, 2 Feb 2006 17:01:37 -0800 (PST) Subject: OpenSSH_4.3p1 configure patch Message-ID: Here is a patch to configure, & configure.ac that should solve the problems people are having with 4.3p1. Thanks to Corina for finding the simple solution. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- diff -ru openssh-4.3p1/configure openssh/configure --- openssh-4.3p1/configure 2006-02-01 03:33:51.000000000 -0800 +++ openssh/configure 2006-02-02 16:10:44.860763002 -0800 @@ -3036,6 +3036,21 @@ test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644' +echo "$as_me:$LINENO: checking for egrep" >&5 +echo $ECHO_N "checking for egrep... $ECHO_C" >&6 +if test "${ac_cv_prog_egrep+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + if echo a | (grep -E '(a|b)') >/dev/null 2>&1 + then ac_cv_prog_egrep='grep -E' + else ac_cv_prog_egrep='egrep' + fi +fi +echo "$as_me:$LINENO: result: $ac_cv_prog_egrep" >&5 +echo "${ECHO_T}$ac_cv_prog_egrep" >&6 + EGREP=$ac_cv_prog_egrep + + # Extract the first word of "ar", so it can be a program name with args. set dummy ar; ac_word=$2 echo "$as_me:$LINENO: checking for $ac_word" >&5 @@ -5640,21 +5655,6 @@ esac # tun(4) forwarding compat code -echo "$as_me:$LINENO: checking for egrep" >&5 -echo $ECHO_N "checking for egrep... $ECHO_C" >&6 -if test "${ac_cv_prog_egrep+set}" = set; then - echo $ECHO_N "(cached) $ECHO_C" >&6 -else - if echo a | (grep -E '(a|b)') >/dev/null 2>&1 - then ac_cv_prog_egrep='grep -E' - else ac_cv_prog_egrep='egrep' - fi -fi -echo "$as_me:$LINENO: result: $ac_cv_prog_egrep" >&5 -echo "${ECHO_T}$ac_cv_prog_egrep" >&6 - EGREP=$ac_cv_prog_egrep - - echo "$as_me:$LINENO: checking for ANSI C header files" >&5 echo $ECHO_N "checking for ANSI C header files... $ECHO_C" >&6 if test "${ac_cv_header_stdc+set}" = set; then @@ -15093,7 +15093,7 @@ #include #include -int main(void) { exit(EVP_aes_192_cbc() == NULL || EVP_aes_256_cbc() == NULL)} +int main(void) { exit(EVP_aes_192_cbc() == NULL || EVP_aes_256_cbc() == NULL);} _ACEOF rm -f conftest.$ac_objext @@ -27440,6 +27440,7 @@ s, at INSTALL_PROGRAM@,$INSTALL_PROGRAM,;t t s, at INSTALL_SCRIPT@,$INSTALL_SCRIPT,;t t s, at INSTALL_DATA@,$INSTALL_DATA,;t t +s, at EGREP@,$EGREP,;t t s, at AR@,$AR,;t t s, at CAT@,$CAT,;t t s, at KILL@,$KILL,;t t @@ -27456,7 +27457,6 @@ s, at LOGIN_PROGRAM_FALLBACK@,$LOGIN_PROGRAM_FALLBACK,;t t s, at PATH_PASSWD_PROG@,$PATH_PASSWD_PROG,;t t s, at LD@,$LD,;t t -s, at EGREP@,$EGREP,;t t s, at LIBWRAP@,$LIBWRAP,;t t s, at LIBEDIT@,$LIBEDIT,;t t s, at LIBPAM@,$LIBPAM,;t t diff -ru openssh-4.3p1/configure.ac openssh/configure.ac --- openssh-4.3p1/configure.ac 2006-01-29 05:22:39.000000000 -0800 +++ openssh/configure.ac 2006-02-02 16:10:29.540763142 -0800 @@ -27,6 +27,7 @@ AC_PROG_CPP AC_PROG_RANLIB AC_PROG_INSTALL +AC_PROG_EGREP AC_PATH_PROG(AR, ar) AC_PATH_PROG(CAT, cat) AC_PATH_PROG(KILL, kill) @@ -1832,7 +1833,7 @@ [AC_LANG_SOURCE([[ #include #include -int main(void) { exit(EVP_aes_192_cbc() == NULL || EVP_aes_256_cbc() == NULL)} +int main(void) { exit(EVP_aes_192_cbc() == NULL || EVP_aes_256_cbc() == NULL);} ]])], [ AC_MSG_RESULT(no) From Richard.Hopkins at bristol.ac.uk Fri Feb 3 03:36:18 2006 From: Richard.Hopkins at bristol.ac.uk (Richard Hopkins) Date: Thu, 02 Feb 2006 16:36:18 +0000 Subject: Portable OpenSSH 4.3 (Solaris) Message-ID: Hi, I get this when I try to configure openssh-4.3p1 under Solaris (8 and 9).. configure: WARNING: lastlog.h: present but cannot be compiled configure: WARNING: lastlog.h: check for missing prerequisite headers? configure: WARNING: lastlog.h: see the Autoconf documentation configure: WARNING: lastlog.h: section "Present But Cannot Be Compiled" configure: WARNING: lastlog.h: proceeding with the preprocessor's result configure: WARNING: lastlog.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## It'll make quite happily, but if used it (unsurprisingly) doesn't write to /var/adm/wtmpx correctly so you end up with entries like... ccxxx pts/13 Thu Jan 1 01:00 still logged in ccxxx pts/13 Thu Jan 1 01:00 still logged in ccxxx pts/3 Thu Jan 1 01:00 still logged in ccxxx pts/14 Thu Jan 1 01:00 still logged in ccxxx pts/14 Thu Jan 1 01:00 still logged in ccxxx pts/13 Thu Jan 1 01:00 still logged in This problem didn't exist with openssh-4.2p1, which logs correctly... ccxxx pts/13 cse-xxx.cse.bris Thu Feb 2 15:33 - 15:34 (00:00) I'm configuring 4.3p1 exactly as I did 4.2p1... ./configure --with-tcp-wrappers --with-pam --with-cflags="-DNO_IDEA" --with-ssl-dir=/usr/local/ssl Is this my problem or a generic Solaris problem? Cheers, Richard Hopkins, Information Services, Computer Centre, University of Bristol, Bristol, BS8 1UD, UK Tel +44 117 928 7859 Fax +44 117 929 1576 From djm at mindrot.org Fri Feb 3 19:39:38 2006 From: djm at mindrot.org (Damien Miller) Date: Fri, 03 Feb 2006 19:39:38 +1100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: References: Message-ID: <43E316CA.9060504@mindrot.org> Tim Rice wrote: > Here is a patch to configure, & configure.ac that should > solve the problems people are having with 4.3p1. > > Thanks to Corina for finding the simple solution. Please test this patch ASAP and so we can make a 4.3p2 release with it included soon (days to a week). -d From vinschen at redhat.com Fri Feb 3 20:42:32 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 3 Feb 2006 10:42:32 +0100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: References: Message-ID: <20060203094232.GA15572@calimero.vinschen.de> On Feb 2 17:01, Tim Rice wrote: > Here is a patch to configure, & configure.ac that should > solve the problems people are having with 4.3p1. Your patch works fine here and, hey, wow, it also solves the "crippled AES" problem I have noticed yesterday! I was going to look into this today but now ... case closed :-) > Thanks to Corina for finding the simple solution. You're welcome. Thanks for your patch. > -- > Tim Rice Multitalents (707) 887-1469 > tim at multitalents.net Content-Description: 4.3p1-configure.patch > [...] > diff -ru openssh-4.3p1/configure.ac openssh/configure.ac > --- openssh-4.3p1/configure.ac 2006-01-29 05:22:39.000000000 -0800 > +++ openssh/configure.ac 2006-02-02 16:10:29.540763142 -0800 > @@ -27,6 +27,7 @@ > AC_PROG_CPP > AC_PROG_RANLIB > AC_PROG_INSTALL > +AC_PROG_EGREP > AC_PATH_PROG(AR, ar) > AC_PATH_PROG(CAT, cat) > AC_PATH_PROG(KILL, kill) > @@ -1832,7 +1833,7 @@ > [AC_LANG_SOURCE([[ > #include > #include > -int main(void) { exit(EVP_aes_192_cbc() == NULL || EVP_aes_256_cbc() == NULL)} > +int main(void) { exit(EVP_aes_192_cbc() == NULL || EVP_aes_256_cbc() == NULL);} > ]])], > [ > AC_MSG_RESULT(no) Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From Richard.Hopkins at bristol.ac.uk Fri Feb 3 21:50:41 2006 From: Richard.Hopkins at bristol.ac.uk (Richard Hopkins) Date: Fri, 03 Feb 2006 10:50:41 +0000 Subject: OpenSSH 4.3 patch? Message-ID: Hi all, Sorry to bug you, but I can't find the message in the list archives which includes the necessary patches to configure and configure.ac which have been referred to. I can see the patch with the message with the patch for configure.ac, but it doesn't appear to be enough on it's own. Could someone do me a big favour and send me all the necessary patches, please? Cheers, Richard Hopkins, Information Services, Computer Centre, University of Bristol, Bristol, BS8 1UD, UK Tel +44 117 928 7859 Fax +44 117 929 1576 From dtucker at zip.com.au Fri Feb 3 22:02:30 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 3 Feb 2006 22:02:30 +1100 Subject: OpenSSH 4.3 patch? In-Reply-To: References: Message-ID: <20060203110230.GA6694@gate.dtucker.net> On Fri, Feb 03, 2006 at 10:50:41AM +0000, Richard Hopkins wrote: > Sorry to bug you, but I can't find the message in the list archives which > includes the necessary patches to configure and configure.ac which have > been referred to. I can see the patch with the message with the patch for > configure.ac, but it doesn't appear to be enough on it's own. This is the one you need: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=113892892008957 In case there's a problem with the archive, I've also put it up on my page: http://www.zip.com.au/~dtucker/openssh/4.3p1-configure.patch -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From eric.buttrum at mohawkcollege.ca Sat Feb 4 01:57:37 2006 From: eric.buttrum at mohawkcollege.ca (Eric Buttrum) Date: Fri, 03 Feb 2006 09:57:37 -0500 Subject: SFTP and MDTM Message-ID: <43E36F61.9000708@mohawkcollege.ca> Hello, I am using a SFTP client that uses the "MDTM" for synchronizing files between hosts. Does the SFTP server sub-system in OpenSSH support this command? Thank you, Eric Buttrum ======================================================================= Eric Buttrum Phone:(905)575-1212 x3339 Technical Support Group Fax:(905)575-2197 Information Technology E-Mail:eric.buttrum at mohawkcollege.ca Mohawk College Web: http://www.mohawkcollege.ca "work as if you don't need money, love as if you've never been hurt, and dance as if you're not being watched." ======================================================================= From tim at multitalents.net Sat Feb 4 09:46:34 2006 From: tim at multitalents.net (Tim Rice) Date: Fri, 3 Feb 2006 14:46:34 -0800 (PST) Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060203094232.GA15572@calimero.vinschen.de> References: <20060203094232.GA15572@calimero.vinschen.de> Message-ID: On Fri, 3 Feb 2006, Corinna Vinschen wrote: > On Feb 2 17:01, Tim Rice wrote: > > Here is a patch to configure, & configure.ac that should > > solve the problems people are having with 4.3p1. > > Your patch works fine here and, hey, wow, it also solves the "crippled > AES" problem I have noticed yesterday! I was going to look into this That was Bug #1148. Darren committed a fix a couple of days ago. > today but now ... case closed :-) > > > Thanks to Corina for finding the simple solution. > > You're welcome. Thanks for your patch. It was actually a little embarrassing for me. I discovered the problem of the first AC_CHECK_HEADERS check being in a platform specific test back in June 2005 (see 20050602 ChangeLog entry) but hadn't dug deep enough to find that adding a simple AC_PROG_EGREP to the top would solve the problem. So we got bit again. Note to self: Find the cause before applying a workaround. > > Content-Description: 4.3p1-configure.patch > > [...] > > diff -ru openssh-4.3p1/configure.ac openssh/configure.ac > > --- openssh-4.3p1/configure.ac 2006-01-29 05:22:39.000000000 -0800 > > +++ openssh/configure.ac 2006-02-02 16:10:29.540763142 -0800 > > @@ -27,6 +27,7 @@ > > AC_PROG_CPP > > AC_PROG_RANLIB > > AC_PROG_INSTALL > > +AC_PROG_EGREP > > AC_PATH_PROG(AR, ar) > > AC_PATH_PROG(CAT, cat) > > AC_PATH_PROG(KILL, kill) > > @@ -1832,7 +1833,7 @@ > > [AC_LANG_SOURCE([[ > > #include > > #include > > -int main(void) { exit(EVP_aes_192_cbc() == NULL || EVP_aes_256_cbc() == NULL)} > > +int main(void) { exit(EVP_aes_192_cbc() == NULL || EVP_aes_256_cbc() == NULL);} > > ]])], > > [ > > AC_MSG_RESULT(no) > > > Corinna > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From Bill.Fischer at qwest.com Sat Feb 4 09:52:41 2006 From: Bill.Fischer at qwest.com (Fischer, Bill) Date: Fri, 3 Feb 2006 16:52:41 -0600 Subject: OpenSSH_4.3p1 configure patch Message-ID: <01B031F62986434EACE76AEC21640C23D87EA9@QTOMAE2K3M01.AD.QINTRA.COM> I'm still having configure/wtmp troubles with 4.3p1 on Solaris 8 for Sparc. I add the patch to a clean source directory: $ gpatch -p1 < 4.3p1-configure.patch patching file configure patching file configure.ac And then I ran configure, which included the following in it's output: configure: WARNING: lastlog.h: present but cannot be compiled configure: WARNING: lastlog.h: check for missing prerequisite headers? configure: WARNING: lastlog.h: see the Autoconf documentation configure: WARNING: lastlog.h: section "Present But Cannot Be Compiled" configure: WARNING: lastlog.h: proceeding with the preprocessor's result configure: WARNING: lastlog.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## . . . configure: WARNING: net/if.h: present but cannot be compiled configure: WARNING: net/if.h: check for missing prerequisite headers? configure: WARNING: net/if.h: see the Autoconf documentation configure: WARNING: net/if.h: section "Present But Cannot Be Compiled" configure: WARNING: net/if.h: proceeding with the preprocessor's result configure: WARNING: net/if.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## . . . configure: WARNING: netinet/in_systm.h: present but cannot be compiled configure: WARNING: netinet/in_systm.h: check for missing prerequisite headers? configure: WARNING: netinet/in_systm.h: see the Autoconf documentation configure: WARNING: netinet/in_systm.h: section "Present But Cannot Be Compiled" configure: WARNING: netinet/in_systm.h: proceeding with the preprocessor's result configure: WARNING: netinet/in_systm.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## .. and when I run it, it is still recording the login time incorrectly. Any suggestions are welcome. -Bill. -----Original Message----- From: openssh-unix-dev-bounces+bill.fischer=qwest.com at mindrot.org [mailto:openssh-unix-dev-bounces+bill.fischer=qwest.com at mindrot.org] On Behalf Of Damien Miller Sent: Friday, February 03, 2006 2:40 AM To: openssh-unix-dev at mindrot.org Subject: Re: OpenSSH_4.3p1 configure patch Tim Rice wrote: > Here is a patch to configure, & configure.ac that should solve the > problems people are having with 4.3p1. > > Thanks to Corina for finding the simple solution. Please test this patch ASAP and so we can make a 4.3p2 release with it included soon (days to a week). -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Sat Feb 4 10:29:25 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 4 Feb 2006 10:29:25 +1100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <01B031F62986434EACE76AEC21640C23D87EA9@QTOMAE2K3M01.AD.QINTRA.COM> References: <01B031F62986434EACE76AEC21640C23D87EA9@QTOMAE2K3M01.AD.QINTRA.COM> Message-ID: <20060203232925.GA16933@gate.dtucker.net> On Fri, Feb 03, 2006 at 04:52:41PM -0600, Fischer, Bill wrote: > I'm still having configure/wtmp troubles with 4.3p1 on Solaris 8 for > Sparc. > > I add the patch to a clean source directory: > > $ gpatch -p1 < 4.3p1-configure.patch > patching file configure > patching file configure.ac > > And then I ran configure, which included the following in it's output: > > configure: WARNING: lastlog.h: present but cannot be compiled > configure: WARNING: lastlog.h: check for missing prerequisite > headers? These can be ignored for the moment. The configure tests will need to be changed so they #include the headers needed by these tests to stop the warnings. (You can see the errors output by the compiler for these in config.log.) > .. and when I run it, it is still recording the login time incorrectly. > Any suggestions are welcome. Please run "make survey" and attach the files "survey" and "config.log" to the bug I've opened for this (the files will be largish so better to not clag up people's inboxes...) http://bugzilla.mindrot.org/show_bug.cgi?id=1150 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From santhi_amirta at HotPOP.com Sat Feb 4 15:00:19 2006 From: santhi_amirta at HotPOP.com (santhi) Date: Sat, 4 Feb 2006 09:30:19 +0530 Subject: getnameinfo() call and fake-rfc2553.c Message-ID: <00be01c6293f$8e7f1750$2d0110ac@samco> Hello All, Im using OpenSSH 4.2p1. The getnameinfo() call in my system libc is broken and as a result SSH fails saying getnameinfo failed:host nor service provided. Im thinking of using getnameinfo() call available from openbsd-compat directory to get rid of this problem. As this is a production system, we can't make changes without convincing my syadmin and managers. I understand that the purpose of openbsd-compat directory is to provide missing libc calls for portable OpenSSH. In this regard I have the following question for the list members. I am trying to use fake-rfc2553.c as part of my compilation (by undefining HAVE_GETNAMEINFO). Is my approach correct? Thanks for the help, Santhi. From dtucker at zip.com.au Sat Feb 4 23:26:48 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 4 Feb 2006 23:26:48 +1100 Subject: getnameinfo() call and fake-rfc2553.c In-Reply-To: <00be01c6293f$8e7f1750$2d0110ac@samco> References: <00be01c6293f$8e7f1750$2d0110ac@samco> Message-ID: <20060204122648.GA23068@gate.dtucker.net> On Sat, Feb 04, 2006 at 09:30:19AM +0530, santhi wrote: > Im using OpenSSH 4.2p1. The getnameinfo() call in my system libc is broken > and as a result SSH fails saying getnameinfo failed:host nor service > provided. Can you tell us what the underlying OS is? If it's consistently broken, maybe configure should handle it specifically. > Im thinking of using getnameinfo() call available from openbsd-compat > directory to get rid of this problem. As this is a production system, we > can't make changes without convincing my syadmin and managers. > > I understand that the purpose of openbsd-compat directory is to provide > missing libc calls for portable OpenSSH. In this regard I have the following > question for the list members. Missing or broken, see below. > I am trying to use fake-rfc2553.c as part of my compilation (by undefining > HAVE_GETNAMEINFO). Is my approach correct? That will work, but it may be easier to define BROKEN_GETADDRINFO, eg "./configure --with-cflags=-DBROKEN_GETADDRINFO". That's effectively what configure already does on systems known to have broken implementations of the getaddrinfo family of functions (eg AIX 4.3.3 and early maintenance levels of 5.1 and 5.2). -- 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 zierke at informatik.uni-hamburg.de Sat Feb 4 22:51:49 2006 From: zierke at informatik.uni-hamburg.de (Reinhard Zierke) Date: Sat, 4 Feb 2006 12:51:49 +0100 Subject: OpenSSH 4.3P1: incorrect wtmpx entries Message-ID: <20060204115149.GA17539@rzdspc10.informatik.uni-hamburg.de> Hi, I just installed OpenSSH 4.3p1 on our Solaris 8 machines and 'last' now shows wtmpx entries for ssh logins like zierke pts/4 Thu Jan 1 01:00 still logged in zierke pts/3 Thu Jan 1 01:00 - 10:56 (13183+09: instead of e.g. zierke pts/3 rzdspc10.informa Sat Feb 4 10:54 - 10:54 (00:00) zierke pts/2 rzdspc10.informa Sat Feb 4 10:53 still logged in i.e. no remote host shown and with the epoch displayed as login time. Previously, I ran OpenSSH 4.1p1 but I just compiled and tried 4.2p1 to verify that that version still writes correct wtmpx entries. Regards, Reinhard -- Reinhard Zierke Universit?t Hamburg, Fakult?t 6, zierke at informatik.uni-hamburg.de Department f?r Informatik postmaster at informatik.uni-hamburg.de Vogt-K?lln-Stra?e 30, D-22527 Hamburg Tel.: (040) 42883-2295/2276 Fax: -2241 From dtucker at zip.com.au Sat Feb 4 23:47:19 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 4 Feb 2006 23:47:19 +1100 Subject: OpenSSH 4.3P1: incorrect wtmpx entries In-Reply-To: <20060204115149.GA17539@rzdspc10.informatik.uni-hamburg.de> References: <20060204115149.GA17539@rzdspc10.informatik.uni-hamburg.de> Message-ID: <20060204124719.GA23403@gate.dtucker.net> On Sat, Feb 04, 2006 at 12:51:49PM +0100, Reinhard Zierke wrote: > I just installed OpenSSH 4.3p1 on our Solaris 8 machines and 'last' now > shows wtmpx entries for ssh logins like > > zierke pts/4 Thu Jan 1 01:00 still logged in > zierke pts/3 Thu Jan 1 01:00 - 10:56 (13183+09: Please try the patch referred to in bug #1150 comment #2 (bug is http://bugzilla.mindrot.org/show_bug.cgi?id=1150, patch is http://www.zip.com.au/~dtucker/openssh/4.3p1-configure.patch) and let us know if that resolves it or not. You will need to do "make distclean" then run configure and make 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 vinschen at redhat.com Sun Feb 5 00:14:46 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 4 Feb 2006 14:14:46 +0100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <43E316CA.9060504@mindrot.org> References: <43E316CA.9060504@mindrot.org> Message-ID: <20060204131446.GM15572@calimero.vinschen.de> On Feb 3 19:39, Damien Miller wrote: > Tim Rice wrote: > > Here is a patch to configure, & configure.ac that should > > solve the problems people are having with 4.3p1. > > > > Thanks to Corina for finding the simple solution. > > Please test this patch ASAP and so we can make a 4.3p2 release with it > included soon (days to a week). Btw., I don't know how many patches will be in 4.3p2, but, can we target maintainers get an early message with a link to the source tar archive supposed to become 4.3p2? This would allow a quick check, if it still looks ok. I'm a bit concerned that we would otherwise see similar problems as with 4.3p1. The last message that 4.3p1 is due and should specificially be tested was sent a long time before 4.3p1 was eventually announced. I was scanning the openssh-unix-dev list every day for an announcement that we should again test some beta package of OpenSSH, but instead it was just suddenly released without further request for testing. Though I build from CVS once in a while to check if nothing has been broken on Cygwin in the meantime, the explicit test announcement are pretty important, IMHO. Especially now that the CVS repository is broken. Keep in mind that people might be only subscribed to the openssh-unix-dev list, but not to the openssh core developer's mailing list. I, for one, am not exactly involved in OpenSSH development, but only interested in the portability to Cygwin. So I don't see what's going on in OpenSSH land, until it hits the portable OpenSSH repository. I hope there's nothing wrong with that approach. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From dpb at bl.com Sun Feb 5 01:33:58 2006 From: dpb at bl.com (Darryl Baker) Date: Sat, 4 Feb 2006 09:33:58 -0500 Subject: Configure Error MacOSX and Solaris 2.6 Message-ID: I got this error on both Solaris 2.6 and MacOSX 10.4.4 configure: WARNING: net/if.h: present but cannot be compiled configure: WARNING: net/if.h: check for missing prerequisite headers? configure: WARNING: net/if.h: see the Autoconf documentation configure: WARNING: net/if.h: section "Present But Cannot Be Compiled" configure: WARNING: net/if.h: proceeding with the preprocessor's result configure: WARNING: net/if.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix- dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## Darryl Baker dpb at bl.com From jbohac at jikos.cz Sun Feb 5 03:11:41 2006 From: jbohac at jikos.cz (Jirka Bohac) Date: Sat, 4 Feb 2006 17:11:41 +0100 Subject: [PATCH] allow user to update changed key in known_hosts Message-ID: <20060204161141.GA28333@twin.jikos.cz> Hi list, I use ssh a lot and I often need to connect to hosts whose host key has changed. If a host key of the remote host changes ssh terminates and the user has to manually delete the offending host key from known_hosts. I had to do this so many times that I no longer like the idea ;-) I would really like ssh to ask me if the new host key is OK and if I want to add it to known_hosts. I talked to other people and they also seemed to be bothered by this behaviour, so I have just written a small patch that introduces a new config option: OffendingKeyOverride When OffendingKeyOverride is "true" and ssh finds an offending key in known_hosts it behaves just as if the key for the host were not there at all. I.e. If StrictHostKeyChecking is set to "ask" the user is prompted to accept the new key and so on... As a result, known_hosts may contain multiple keys for the same host - I find that very useful, for example when connecting to dualboot remote hosts, with different host key in each of their OSes. Is it possible that a similar patch could make it into openssh, or are there any major objections? The patch follows (it looks bigger than it is, because a large chunk of code is moved into a separate function...). Comments appreciated. I am willing to change the patch in any way or do whatever to get this functionality into openssh. Regards, Jirka Bohac diff -aur openssh-4.3p1/readconf.c openssh-4.3p1-patch/readconf.c --- openssh-4.3p1/readconf.c 2005-12-13 09:33:20.000000000 +0100 +++ openssh-4.3p1-patch/readconf.c 2006-02-04 16:41:10.000000000 +0100 @@ -112,7 +112,7 @@ oServerAliveInterval, oServerAliveCountMax, oIdentitiesOnly, oSendEnv, oControlPath, oControlMaster, oHashKnownHosts, oTunnel, oTunnelDevice, oLocalCommand, oPermitLocalCommand, - oDeprecated, oUnsupported + oDeprecated, oUnsupported, oOffendingKeyOverride } OpCodes; /* Textual representations of the tokens. */ @@ -175,6 +175,7 @@ { "batchmode", oBatchMode }, { "checkhostip", oCheckHostIP }, { "stricthostkeychecking", oStrictHostKeyChecking }, + { "offendingkeyoverride", oOffendingKeyOverride }, { "compression", oCompression }, { "compressionlevel", oCompressionLevel }, { "tcpkeepalive", oTCPKeepAlive }, @@ -434,6 +435,7 @@ case oStrictHostKeyChecking: intptr = &options->strict_host_key_checking; + parse_yesnoask: arg = strdelim(&s); if (!arg || *arg == '\0') @@ -452,6 +454,10 @@ *intptr = value; break; + case oOffendingKeyOverride: + intptr = &options->offending_key_override; + goto parse_flag; + case oCompression: intptr = &options->compression; goto parse_flag; @@ -979,6 +985,7 @@ options->batch_mode = -1; options->check_host_ip = -1; options->strict_host_key_checking = -1; + options->offending_key_override = -1; options->compression = -1; options->tcp_keep_alive = -1; options->compression_level = -1; @@ -1073,6 +1080,8 @@ options->check_host_ip = 1; if (options->strict_host_key_checking == -1) options->strict_host_key_checking = 2; /* 2 is default */ + if (options->offending_key_override == -1) + options->offending_key_override = 0; if (options->compression == -1) options->compression = 0; if (options->tcp_keep_alive == -1) diff -aur openssh-4.3p1/readconf.h openssh-4.3p1-patch/readconf.h --- openssh-4.3p1/readconf.h 2005-12-13 09:29:02.000000000 +0100 +++ openssh-4.3p1-patch/readconf.h 2006-02-04 15:07:38.000000000 +0100 @@ -53,6 +53,7 @@ int batch_mode; /* Batch mode: do not ask for passwords. */ int check_host_ip; /* Also keep track of keys for IP address */ int strict_host_key_checking; /* Strict host key checking. */ + int offending_key_override; /* Allow adding changed keys to hostfile */ int compression; /* Compress packets in both directions. */ int compression_level; /* Compression level 1 (fast) to 9 * (best). */ diff -aur openssh-4.3p1/sshconnect.c openssh-4.3p1-patch/sshconnect.c --- openssh-4.3p1/sshconnect.c 2005-12-13 09:29:03.000000000 +0100 +++ openssh-4.3p1-patch/sshconnect.c 2006-02-04 16:42:04.000000000 +0100 @@ -51,6 +51,9 @@ static int show_other_keys(const char *, Key *); static void warn_changed_key(Key *); +static int ask_connect_with_new_key(const char *host, Key *host_key, + const char* ip, const char* type, HostStatus ip_status, + const char *user_hostfile); /* * Connect to the given ssh server using a proxy command. @@ -524,10 +527,9 @@ Key *file_key; const char *type = key_type(host_key); char *ip = NULL; - char hostline[1000], *hostp, *fp; HostStatus host_status; HostStatus ip_status; - int r, local = 0, host_ip_differ = 0; + int local = 0, host_ip_differ = 0; int salen; char ntop[NI_MAXHOST]; char msg[1024]; @@ -674,71 +676,10 @@ error("No %s host key is known for %.200s and you " "have requested strict checking.", type, host); goto fail; - } else if (options.strict_host_key_checking == 2) { - char msg1[1024], msg2[1024]; - - if (show_other_keys(host, host_key)) - snprintf(msg1, sizeof(msg1), - "\nbut keys of different type are already" - " known for this host."); - else - snprintf(msg1, sizeof(msg1), "."); - /* The default */ - fp = key_fingerprint(host_key, SSH_FP_MD5, SSH_FP_HEX); - msg2[0] = '\0'; - if (options.verify_host_key_dns) { - if (matching_host_key_dns) - snprintf(msg2, sizeof(msg2), - "Matching host key fingerprint" - " found in DNS.\n"); - else - snprintf(msg2, sizeof(msg2), - "No matching host key fingerprint" - " found in DNS.\n"); - } - snprintf(msg, sizeof(msg), - "The authenticity of host '%.200s (%s)' can't be " - "established%s\n" - "%s key fingerprint is %s.\n%s" - "Are you sure you want to continue connecting " - "(yes/no)? ", - host, ip, msg1, type, fp, msg2); - xfree(fp); - if (!confirm(msg)) - goto fail; - } - /* - * If not in strict mode, add the key automatically to the - * local known_hosts file. - */ - if (options.check_host_ip && ip_status == HOST_NEW) { - snprintf(hostline, sizeof(hostline), "%s,%s", - host, ip); - hostp = hostline; - if (options.hash_known_hosts) { - /* Add hash of host and IP separately */ - r = add_host_to_hostfile(user_hostfile, host, - host_key, options.hash_known_hosts) && - add_host_to_hostfile(user_hostfile, ip, - host_key, options.hash_known_hosts); - } else { - /* Add unhashed "host,ip" */ - r = add_host_to_hostfile(user_hostfile, - hostline, host_key, - options.hash_known_hosts); - } - } else { - r = add_host_to_hostfile(user_hostfile, host, host_key, - options.hash_known_hosts); - hostp = host; - } + } + if (ask_connect_with_new_key(host, host_key, ip, type, ip_status, user_hostfile)) + goto fail; - if (!r) - logit("Failed to add the host to the list of known " - "hosts (%.500s).", user_hostfile); - else - logit("Warning: Permanently added '%.200s' (%s) to the " - "list of known hosts.", hostp, type); break; case HOST_CHANGED: if (options.check_host_ip && host_ip_differ) { @@ -760,21 +701,30 @@ if (ip_status != HOST_NEW) error("Offending key for IP in %s:%d", ip_file, ip_line); } + /* The host key has changed. */ warn_changed_key(host_key); error("Add correct host key in %.100s to get rid of this message.", user_hostfile); error("Offending key in %s:%d", host_file, host_line); - - /* - * If strict host key checking is in use, the user will have - * to edit the key manually and we can only abort. - */ - if (options.strict_host_key_checking) { + + /* Ask the user whether to accept the new host key */ + if (options.offending_key_override && options.strict_host_key_checking != 1) + { + if (ask_connect_with_new_key(host, host_key, ip, type, ip_status, user_hostfile)) + goto fail; + break; + } else if (options.strict_host_key_checking) { + /* + * If strict host key checking is in use, the user will have + * to edit the key manually and we can only abort. + */ error("%s host key for %.200s has changed and you have " "requested strict checking.", type, host); goto fail; } + + /* * If strict host key checking has not been requested, allow @@ -814,13 +764,6 @@ options.num_local_forwards = options.num_remote_forwards = 0; } - /* - * XXX Should permit the user to change to use the new id. - * This could be done by converting the host key to an - * identifying sentence, tell that the host identifies itself - * by that sentence, and ask the user if he/she whishes to - * accept the authentication. - */ break; case HOST_FOUND: fatal("internal error"); @@ -1014,6 +957,83 @@ return (found); } +static int +ask_connect_with_new_key(const char *host, Key *host_key, const char* ip, + const char* type, HostStatus ip_status, const char *user_hostfile) +{ + char *fp; + const char *hostp; + int r; + char hostline[1000]; + char msg[1024]; + + if (options.strict_host_key_checking == 2) { + char msg1[1024], msg2[1024]; + + if (show_other_keys(host, host_key)) + snprintf(msg1, sizeof(msg1), + "\nbut keys of different type are already" + " known for this host."); + else + snprintf(msg1, sizeof(msg1), "."); + /* The default */ + fp = key_fingerprint(host_key, SSH_FP_MD5, SSH_FP_HEX); + msg2[0] = '\0'; + if (options.verify_host_key_dns) { + if (matching_host_key_dns) + snprintf(msg2, sizeof(msg2), + "Matching host key fingerprint" + " found in DNS.\n"); + else + snprintf(msg2, sizeof(msg2), + "No matching host key fingerprint" + " found in DNS.\n"); + } + snprintf(msg, sizeof(msg), + "The authenticity of host '%.200s (%s)' can't be " + "established%s\n" + "%s key fingerprint is %s.\n%s" + "Are you sure you want to continue connecting " + "(yes/no)? ", + host, ip, msg1, type, fp, msg2); + xfree(fp); + if (!confirm(msg)) + return -1; + } + /* + * If not in strict mode, add the key automatically to the + * local known_hosts file. + */ + if (options.check_host_ip && ip_status == HOST_NEW) { + snprintf(hostline, sizeof(hostline), "%s,%s", + host, ip); + hostp = hostline; + if (options.hash_known_hosts) { + /* Add hash of host and IP separately */ + r = add_host_to_hostfile(user_hostfile, host, + host_key, options.hash_known_hosts) && + add_host_to_hostfile(user_hostfile, ip, + host_key, options.hash_known_hosts); + } else { + /* Add unhashed "host,ip" */ + r = add_host_to_hostfile(user_hostfile, + hostline, host_key, + options.hash_known_hosts); + } + } else { + r = add_host_to_hostfile(user_hostfile, host, host_key, + options.hash_known_hosts); + hostp = host; + } + + if (!r) + logit("Failed to add the host to the list of known " + "hosts (%.500s).", user_hostfile); + else + logit("Warning: Permanently added '%.200s' (%s) to the " + "list of known hosts.", hostp, type); + return 0; +} static void warn_changed_key(Key *host_key) { @@ -1030,7 +1050,6 @@ error("It is also possible that the %s host key has just been changed.", type); error("The fingerprint for the %s key sent by the remote host is\n%s.", type, fp); - error("Please contact your system administrator."); xfree(fp); } From djm at mindrot.org Sun Feb 5 09:32:22 2006 From: djm at mindrot.org (Damien Miller) Date: Sun, 5 Feb 2006 09:32:22 +1100 (EST) Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060204131446.GM15572@calimero.vinschen.de> References: <43E316CA.9060504@mindrot.org> <20060204131446.GM15572@calimero.vinschen.de> Message-ID: On Sat, 4 Feb 2006, Corinna Vinschen wrote: > Btw., I don't know how many patches will be in 4.3p2, but, can we > target maintainers get an early message with a link to the source > tar archive supposed to become 4.3p2? This would allow a quick check, > if it still looks ok. This is what the snapshots are for. Usually the only change between a snapshot and a release is the changes to the version numbers. In this case, anyone who tested a snapshot from Jan 1st onwards would have been able to see the bug. Unfortunately our regress tests don't test for the problems that this bug caused, and I (incorrectly) assumed that the snapshots were receiving wider testing. -d From vinschen at redhat.com Sun Feb 5 09:41:15 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 4 Feb 2006 23:41:15 +0100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: References: <43E316CA.9060504@mindrot.org> <20060204131446.GM15572@calimero.vinschen.de> Message-ID: <20060204224115.GO15572@calimero.vinschen.de> On Feb 5 09:32, Damien Miller wrote: > On Sat, 4 Feb 2006, Corinna Vinschen wrote: > > > Btw., I don't know how many patches will be in 4.3p2, but, can we > > target maintainers get an early message with a link to the source > > tar archive supposed to become 4.3p2? This would allow a quick check, > > if it still looks ok. > > This is what the snapshots are for. Usually the only change between > a snapshot and a release is the changes to the version numbers. > > In this case, anyone who tested a snapshot from Jan 1st onwards would > have been able to see the bug. Unfortunately our regress tests don't test > for the problems that this bug caused, and I (incorrectly) assumed that > the snapshots were receiving wider testing. Honestly, you can't expect that every snapshot is tested just so, without further announcement. We are producing Cygwin snapshots more or less every day or two, but without explicit announcement that we wish people to test snapshots, nothing will happen. And that's normal, frustrating as it might be for us developers. People have day jobs and care mainly for their projects. If important stuff happens, and you wish that snapshots are explicitely tested, please announce. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From tim at multitalents.net Sun Feb 5 13:20:00 2006 From: tim at multitalents.net (Tim Rice) Date: Sat, 4 Feb 2006 18:20:00 -0800 (PST) Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060204224115.GO15572@calimero.vinschen.de> References: <43E316CA.9060504@mindrot.org> <20060204131446.GM15572@calimero.vinschen.de> <20060204224115.GO15572@calimero.vinschen.de> Message-ID: On Sat, 4 Feb 2006, Corinna Vinschen wrote: [snip] > care mainly for their projects. If important stuff happens, and you > wish that snapshots are explicitely tested, please announce. Please do test the next snapshot. I've just commited a couple of changes to congigure.ac. Or save some bandwith and grab http://www.multitalents.net/openssh/configure-1.322.2.4.gz The only other patch to configure.ac we are considering is .... --- configure.ac.old 2006-02-04 17:42:58.000000000 -0800 +++ configure.ac 2006-02-04 17:53:26.769362132 -0800 @@ -680,10 +680,8 @@ login_cap.h \ maillock.h \ ndir.h \ - net/if.h \ netdb.h \ netgroup.h \ - netinet/in_systm.h \ pam/pam_appl.h \ paths.h \ pty.h \ .... As we don't use HAVE_NET_IF_H or HAVE_NETINET_IN_SYSTEM_H, it will only end up quieting some warnings on a couple of platforms. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From openssh at roumenpetrov.info Sun Feb 5 23:22:02 2006 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Sun, 05 Feb 2006 14:22:02 +0200 Subject: [PATCH] allow user to update changed key in known_hosts In-Reply-To: <20060204161141.GA28333@twin.jikos.cz> References: <20060204161141.GA28333@twin.jikos.cz> Message-ID: <43E5EDEA.1000403@roumenpetrov.info> Hi Jirca, Jirka Bohac wrote: > Hi list, > > I use ssh a lot and I often need to connect to hosts whose host key has > changed. If a host key of the remote host changes ssh terminates and the > user has to manually delete the offending host key from known_hosts. Use StrictHostKeyChecking=no for those hosts. > I talked to other people and they also seemed to be bothered by this > behaviour May be people who don't read manual pages will bother other too ? >, so I have just written a small patch that introduces a new > config option: OffendingKeyOverride Please, could you check ssh_config(5) and other manual pages for more usefull options for your environment. From jbohac at jikos.cz Sun Feb 5 23:54:19 2006 From: jbohac at jikos.cz (Jirka Bohac) Date: Sun, 5 Feb 2006 13:54:19 +0100 Subject: [PATCH] allow user to update changed key in known_hosts In-Reply-To: <43E5EDEA.1000403@roumenpetrov.info> References: <20060204161141.GA28333@twin.jikos.cz> <43E5EDEA.1000403@roumenpetrov.info> Message-ID: <20060205125418.GA23238@twin.jikos.cz> Hi, On Sun, Feb 05, 2006 at 02:22:02PM +0200, Roumen Petrov wrote: > >I use ssh a lot and I often need to connect to hosts whose host key has > >changed. If a host key of the remote host changes ssh terminates and the > >user has to manually delete the offending host key from known_hosts. > > Use StrictHostKeyChecking=no for those hosts. This is not what I want: 1) I want to be alerted that the remote host key has been changed and be able to accept it as the new key for the host. I don't want to see the warning each time I log in and learn to ignore it. 2) Even with StrictHostKeyChecking=no, I am not allowed to log in using a password, can't forward X etc. > >I talked to other people and they also seemed to be bothered by this > >behaviour > > May be people who don't read manual pages will bother other too ? Come on! I _did_ read the manpage and know what StrictHostKeyChecking does. It's not what I want. Even the author of the code probably thought similar functionality would be good to have ... see the following comment from sshconnect.c /* * XXX Should permit the user to change to use the new id. * This could be done by converting the host key to an * identifying sentence, tell that the host identifies itself * by that sentence, and ask the user if he/she whishes to * accept the authentication. */ I am willing to finish what the author intended, because I really miss the functionality. I'd just like to hear constructive suggestions. Regards, Jirka From openssh at roumenpetrov.info Mon Feb 6 00:45:09 2006 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Sun, 05 Feb 2006 15:45:09 +0200 Subject: [PATCH] allow user to update changed key in known_hosts In-Reply-To: <20060205125418.GA23238@twin.jikos.cz> References: <20060204161141.GA28333@twin.jikos.cz> <43E5EDEA.1000403@roumenpetrov.info> <20060205125418.GA23238@twin.jikos.cz> Message-ID: <43E60165.8050301@roumenpetrov.info> Hi Jirka, Jirka Bohac wrote: > Hi, > > On Sun, Feb 05, 2006 at 02:22:02PM +0200, Roumen Petrov wrote: > >>>I use ssh a lot and I often need to connect to hosts whose host key has >>>changed. If a host key of the remote host changes ssh terminates and the >>>user has to manually delete the offending host key from known_hosts. >> >>Use StrictHostKeyChecking=no for those hosts. > > > This is not what I want: > 1) I want to be alerted that the remote host key has been changed and be > able to accept it as the new key for the host. I don't want to see > the warning each time I log in and learn to ignore it. > 2) Even with StrictHostKeyChecking=no, I am not allowed to log in using a > password, can't forward X etc. Thanks that you clarify what you exactly need. >>>I talked to other people and they also seemed to be bothered by this >>>behaviour >> >>May be people who don't read manual pages will bother other too ? > > > Come on! I _did_ read the manpage and know what StrictHostKeyChecking > does. It's not what I want. > > Even the author of the code probably thought similar functionality would > be good to have ... see the following comment from sshconnect.c > > /* > * XXX Should permit the user to change to use the new id. > * This could be done by converting the host key to an > * identifying sentence, tell that the host identifies itself > * by that sentence, and ask the user if he/she whishes to > * accept the authentication. > */ > > I am willing to finish what the author intended, because I really miss > the functionality. I'd just like to hear constructive suggestions. You could open a request for extension in openssh bugzila. May be in case HOST_CHANGED and when options.strict_host_key_checking is 2(ask) the code can be changed to ask user what to do ? "goto fail" should happen only when strict_host_key_checking is set to 1("yes"). I'm not sure that new option is necessary. Regards, Roumen Petrov From djm at mindrot.org Mon Feb 6 11:30:34 2006 From: djm at mindrot.org (Damien Miller) Date: Mon, 6 Feb 2006 11:30:34 +1100 (EST) Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060204224115.GO15572@calimero.vinschen.de> References: <43E316CA.9060504@mindrot.org> <20060204131446.GM15572@calimero.vinschen.de> <20060204224115.GO15572@calimero.vinschen.de> Message-ID: On Sat, 4 Feb 2006, Corinna Vinschen wrote: > > In this case, anyone who tested a snapshot from Jan 1st onwards would > > have been able to see the bug. Unfortunately our regress tests don't test > > for the problems that this bug caused, and I (incorrectly) assumed that > > the snapshots were receiving wider testing. > > Honestly, you can't expect that every snapshot is tested just so, > without further announcement. It would be excessive to expect anyone to test every snapshot, but I would hope that active distributors of OpenSSH test at least one snapshot per month. We don't operate a branched development model - CVS HEAD is supposed to always be stable enough to release. This means that people on this list should be able to stay up with -current (*) on non-production hosts (e.g. workstations) and not expect breakage. -d (*) yes, I know that not having a working anoncvs repository makes this difficult at present. We'll fix this soon. From djm at mindrot.org Mon Feb 6 11:35:43 2006 From: djm at mindrot.org (Damien Miller) Date: Mon, 6 Feb 2006 11:35:43 +1100 (EST) Subject: [PATCH] allow user to update changed key in known_hosts In-Reply-To: <20060204161141.GA28333@twin.jikos.cz> References: <20060204161141.GA28333@twin.jikos.cz> Message-ID: On Sat, 4 Feb 2006, Jirka Bohac wrote: > Hi list, > > > I use ssh a lot and I often need to connect to hosts whose host key has > changed. If a host key of the remote host changes ssh terminates and the > user has to manually delete the offending host key from known_hosts. I > had to do this so many times that I no longer like the idea ;-) > I would really like ssh to ask me if the new host key is OK and if I > want to add it to known_hosts. > > I talked to other people and they also seemed to be bothered by this > behaviour, so I have just written a small patch that introduces a new > config option: OffendingKeyOverride I don't think we will add an option like this: part of the OpenSSH's "security UI" is that a changed key is a significant event that requires explicit manual intervention, not just answering "yes" to a question. We are very wary of convenience options like OffendingKeyOverride, as they tend to get turned on indiscriminately and never turned off. BTW, in recent releases, the manual intervention required on key change is as simple as the command: ssh-keygen -R offending.host.name This will remove the old key without editing, while still requiring a manual step. -d From tim at multitalents.net Mon Feb 6 11:47:01 2006 From: tim at multitalents.net (Tim Rice) Date: Sun, 5 Feb 2006 16:47:01 -0800 (PST) Subject: Configure Error MacOSX and Solaris 2.6 In-Reply-To: References: Message-ID: On Sat, 4 Feb 2006, Darryl Baker wrote: > I got this error on both Solaris 2.6 and MacOSX 10.4.4 > > configure: WARNING: net/if.h: present but cannot be compiled > configure: WARNING: net/if.h: check for missing prerequisite > headers? This can safely be ignored. It's fixed in what will be 4.3p2 -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From djm at mindrot.org Mon Feb 6 20:41:15 2006 From: djm at mindrot.org (Damien Miller) Date: Mon, 6 Feb 2006 20:41:15 +1100 (EST) Subject: Testing (please ignore) Message-ID: This is a test that the upgrade to Mailman-2.1.7 went smoothly. Please ignore. Thanks, Damien Miller From vinschen at redhat.com Mon Feb 6 22:02:43 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 6 Feb 2006 12:02:43 +0100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: References: <43E316CA.9060504@mindrot.org> <20060204131446.GM15572@calimero.vinschen.de> <20060204224115.GO15572@calimero.vinschen.de> Message-ID: <20060206110243.GA6756@calimero.vinschen.de> On Feb 4 18:20, Tim Rice wrote: > Please do test the next snapshot. I've just commited a couple of changes > to congigure.ac. Your patches to configure.ac seem to work fine on Cygwin. However, I seem to have found a generic bug in sshd. Since I was closer inspecting what happens with utmp and wtmp entries, I found to my surprise, that login records were added to utmp/wtmp, but logout records were not. I debugged an sshd child and found this: - On logging out from an interactive session, EOF is encountered and down from do_authenticated, session_close_by_pid is called. - session_by_pid returns the correct Session pointer. - s->chanid is != -1, ==> session_exit_message is called. - session_exit_message sets s->pid = 0 and returns to session_close_by_pid. - s->ttyfd != -1, ==> session_pty_cleanup is called. - session_pty_cleanup calls session_pty_cleanup2. - In session_pty_cleanup2, record_logout is only called if s->pid != 0. Do I miss something or is it somehow impossible to get a logout record this way?!? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vinschen at redhat.com Mon Feb 6 22:06:55 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 6 Feb 2006 12:06:55 +0100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: References: <43E316CA.9060504@mindrot.org> <20060204131446.GM15572@calimero.vinschen.de> <20060204224115.GO15572@calimero.vinschen.de> Message-ID: <20060206110655.GA7038@calimero.vinschen.de> On Feb 4 18:20, Tim Rice wrote: > Please do test the next snapshot. I've just commited a couple of changes > to congigure.ac. Can we add this patch to get rid of an annoying compiler warning? --- bsd-cygwin_util.c.ORIG 2006-02-06 12:06:17.657591500 +0100 +++ bsd-cygwin_util.c 2006-02-06 10:55:57.543851300 +0100 @@ -268,7 +268,7 @@ char ** fetch_windows_environment(void) { char **e, **p; - int i, idx = 0; + unsigned int i, idx = 0; p = xmalloc((WENV_SIZ + 1) * sizeof(char *)); for (e = environ; *e != NULL; ++e) { Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vinschen at redhat.com Mon Feb 6 22:07:30 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 6 Feb 2006 12:07:30 +0100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: References: <43E316CA.9060504@mindrot.org> <20060204131446.GM15572@calimero.vinschen.de> <20060204224115.GO15572@calimero.vinschen.de> Message-ID: <20060206110730.GY15572@calimero.vinschen.de> On Feb 6 11:30, Damien Miller wrote: > On Sat, 4 Feb 2006, Corinna Vinschen wrote: > > > In this case, anyone who tested a snapshot from Jan 1st onwards would > > > have been able to see the bug. Unfortunately our regress tests don't test > > > for the problems that this bug caused, and I (incorrectly) assumed that > > > the snapshots were receiving wider testing. > > > > Honestly, you can't expect that every snapshot is tested just so, > > without further announcement. You simply dismissed everything else what I said and just let this single sentence in your reply, which looks like I'm just too lazy to take my responsibilities as platform maintainer serious. OpenSSH is not the only project, and besides developing Cygwin, I'm also maintaining 30+ packages in the Cygwin distro. And, as I mentioned, I *am* testing from CVS once in a while. > It would be excessive to expect anyone to test every snapshot, but I > would hope that active distributors of OpenSSH test at least one > snapshot per month. > > We don't operate a branched development model - CVS HEAD is supposed to > always be stable enough to release. This means that people on this list > should be able to stay up with -current (*) on non-production hosts (e.g. > workstations) and not expect breakage. I'm really wondering what's the problem to advertise changes made to OpenSSH which you would like to be tested. Do you want feedback or not? We want feedback on changes made to Cygwin, consequentially we advertise snapshots on a regular basis to get feedback as soon as possible. This is no guarantee to get all bugs fixed before a release, but if we don't do this, the bugs would be certainly more, and more serious. What's the problem of writing a short note, "Hey guys, we added subspace communication support, please test if that works on your platform"? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vinschen at redhat.com Mon Feb 6 22:11:27 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 6 Feb 2006 12:11:27 +0100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060206110243.GA6756@calimero.vinschen.de> References: <43E316CA.9060504@mindrot.org> <20060204131446.GM15572@calimero.vinschen.de> <20060204224115.GO15572@calimero.vinschen.de> <20060206110243.GA6756@calimero.vinschen.de> Message-ID: <20060206111127.GA7095@calimero.vinschen.de> On Feb 6 12:02, Corinna Vinschen wrote: > On Feb 4 18:20, Tim Rice wrote: > > Please do test the next snapshot. I've just commited a couple of changes > > to congigure.ac. > > Your patches to configure.ac seem to work fine on Cygwin. > > However, I seem to have found a generic bug in sshd. > > Since I was closer inspecting what happens with utmp and wtmp entries, I > found to my surprise, that login records were added to utmp/wtmp, but > logout records were not. > > I debugged an sshd child and found this: > > - On logging out from an interactive session, EOF is encountered and > down from do_authenticated, session_close_by_pid is called. > > - session_by_pid returns the correct Session pointer. > > - s->chanid is != -1, ==> session_exit_message is called. > > - session_exit_message sets s->pid = 0 and returns to session_close_by_pid. > > - s->ttyfd != -1, ==> session_pty_cleanup is called. > > - session_pty_cleanup calls session_pty_cleanup2. > > - In session_pty_cleanup2, record_logout is only called if s->pid != 0. Oh and, just for the sake of completeness, since session_pty_cleanup2 will set s->ttyfd to -1 in the first call, any later call to session_pty_cleanup2, for instance from do_cleanup, will not do anything at all. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From dtucker at zip.com.au Mon Feb 6 22:38:18 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 6 Feb 2006 22:38:18 +1100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060206110243.GA6756@calimero.vinschen.de> References: <43E316CA.9060504@mindrot.org> <20060204131446.GM15572@calimero.vinschen.de> <20060204224115.GO15572@calimero.vinschen.de> <20060206110243.GA6756@calimero.vinschen.de> Message-ID: <20060206113818.GA8655@gate.dtucker.net> On Mon, Feb 06, 2006 at 12:02:43PM +0100, Corinna Vinschen wrote: [...] > I debugged an sshd child and found this: > > - On logging out from an interactive session, EOF is encountered and > down from do_authenticated, session_close_by_pid is called. > > - session_by_pid returns the correct Session pointer. > > - s->chanid is != -1, ==> session_exit_message is called. > > - session_exit_message sets s->pid = 0 and returns to session_close_by_pid. > > - s->ttyfd != -1, ==> session_pty_cleanup is called. > > - session_pty_cleanup calls session_pty_cleanup2. > > - In session_pty_cleanup2, record_logout is only called if s->pid != 0. > > Do I miss something or is it somehow impossible to get a logout record > this way?!? When privsep is on, session_exit_message is called in the slave, but session_pty_cleanup2 is called by the monitor, so it works. It looks like a problem when privsep=no, though, and it's not immediately obvious to me what to do with 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 vinschen at redhat.com Mon Feb 6 22:47:00 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 6 Feb 2006 12:47:00 +0100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060206111127.GA7095@calimero.vinschen.de> References: <43E316CA.9060504@mindrot.org> <20060204131446.GM15572@calimero.vinschen.de> <20060204224115.GO15572@calimero.vinschen.de> <20060206110243.GA6756@calimero.vinschen.de> <20060206111127.GA7095@calimero.vinschen.de> Message-ID: <20060206114700.GA7388@calimero.vinschen.de> On Feb 6 12:11, Corinna Vinschen wrote: > On Feb 6 12:02, Corinna Vinschen wrote: > > On Feb 4 18:20, Tim Rice wrote: > > > Please do test the next snapshot. I've just commited a couple of changes > > > to congigure.ac. > > > > Your patches to configure.ac seem to work fine on Cygwin. > > > > However, I seem to have found a generic bug in sshd. > > > > Since I was closer inspecting what happens with utmp and wtmp entries, I > > found to my surprise, that login records were added to utmp/wtmp, but > > logout records were not. > > > > I debugged an sshd child and found this: > > > > - On logging out from an interactive session, EOF is encountered and > > down from do_authenticated, session_close_by_pid is called. > > > > - session_by_pid returns the correct Session pointer. > > > > - s->chanid is != -1, ==> session_exit_message is called. > > > > - session_exit_message sets s->pid = 0 and returns to session_close_by_pid. > > > > - s->ttyfd != -1, ==> session_pty_cleanup is called. > > > > - session_pty_cleanup calls session_pty_cleanup2. > > > > - In session_pty_cleanup2, record_logout is only called if s->pid != 0. > > Oh and, just for the sake of completeness, since session_pty_cleanup2 > will set s->ttyfd to -1 in the first call, any later call to > session_pty_cleanup2, for instance from do_cleanup, will not do anything > at all. ...and this worked in 4.2p1 because it didn't set s->pid to 0 in session_exit_message, but only s->chanid to -1. I'm not certain how to fix this correctly, however. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vinschen at redhat.com Mon Feb 6 23:44:43 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 6 Feb 2006 13:44:43 +0100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060206113818.GA8655@gate.dtucker.net> References: <43E316CA.9060504@mindrot.org> <20060204131446.GM15572@calimero.vinschen.de> <20060204224115.GO15572@calimero.vinschen.de> <20060206110243.GA6756@calimero.vinschen.de> <20060206113818.GA8655@gate.dtucker.net> Message-ID: <20060206124443.GZ15572@calimero.vinschen.de> On Feb 6 22:38, Darren Tucker wrote: > On Mon, Feb 06, 2006 at 12:02:43PM +0100, Corinna Vinschen wrote: > [...] > > I debugged an sshd child and found this: > > > > - On logging out from an interactive session, EOF is encountered and > > down from do_authenticated, session_close_by_pid is called. > > > > - session_by_pid returns the correct Session pointer. > > > > - s->chanid is != -1, ==> session_exit_message is called. > > > > - session_exit_message sets s->pid = 0 and returns to session_close_by_pid. > > > > - s->ttyfd != -1, ==> session_pty_cleanup is called. > > > > - session_pty_cleanup calls session_pty_cleanup2. > > > > - In session_pty_cleanup2, record_logout is only called if s->pid != 0. > > > > Do I miss something or is it somehow impossible to get a logout record > > this way?!? > > When privsep is on, session_exit_message is called in the slave, but > session_pty_cleanup2 is called by the monitor, so it works. > > It looks like a problem when privsep=no, though, and it's not immediately > obvious to me what to do with it. This also happens if UsePrivilegeSeparation is set to "yes" in /etc/sshd_config on Cygwin. The problem is that descriptor passing doesn't work on Cygwin which in turn sets use_privsep to 0. So, logout logging is entirely broken for all systems which either don't support, or have broken file descriptor passing. Since the old session_exit_message only set s->chanid to -1, maybe we could remove setting s->pid to 0 from session_exit_message and move it to the end of session_close_by_pid? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vinschen at redhat.com Tue Feb 7 00:42:55 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 6 Feb 2006 14:42:55 +0100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060206124443.GZ15572@calimero.vinschen.de> References: <43E316CA.9060504@mindrot.org> <20060204131446.GM15572@calimero.vinschen.de> <20060204224115.GO15572@calimero.vinschen.de> <20060206110243.GA6756@calimero.vinschen.de> <20060206113818.GA8655@gate.dtucker.net> <20060206124443.GZ15572@calimero.vinschen.de> Message-ID: <20060206134255.GA8481@calimero.vinschen.de> On Feb 6 13:44, Corinna Vinschen wrote: > On Feb 6 22:38, Darren Tucker wrote: > > On Mon, Feb 06, 2006 at 12:02:43PM +0100, Corinna Vinschen wrote: > > [...] > > > I debugged an sshd child and found this: > > > > > > - On logging out from an interactive session, EOF is encountered and > > > down from do_authenticated, session_close_by_pid is called. > > > > > > - session_by_pid returns the correct Session pointer. > > > > > > - s->chanid is != -1, ==> session_exit_message is called. > > > > > > - session_exit_message sets s->pid = 0 and returns to session_close_by_pid. > > > > > > - s->ttyfd != -1, ==> session_pty_cleanup is called. > > > > > > - session_pty_cleanup calls session_pty_cleanup2. > > > > > > - In session_pty_cleanup2, record_logout is only called if s->pid != 0. > > > > > > Do I miss something or is it somehow impossible to get a logout record > > > this way?!? > > > > When privsep is on, session_exit_message is called in the slave, but > > session_pty_cleanup2 is called by the monitor, so it works. > > > > It looks like a problem when privsep=no, though, and it's not immediately > > obvious to me what to do with it. > > This also happens if UsePrivilegeSeparation is set to "yes" in > /etc/sshd_config on Cygwin. The problem is that descriptor passing > doesn't work on Cygwin which in turn sets use_privsep to 0. So, logout > logging is entirely broken for all systems which either don't support, > or have broken file descriptor passing. > > Since the old session_exit_message only set s->chanid to -1, maybe we > could remove setting s->pid to 0 from session_exit_message and move it > to the end of session_close_by_pid? I just tested the below patch and it solves the problem for me. Since session_exit_message is only called from session_close_by_pid, the solution seems to be the correct one. Corinna --- session.c.ORIG 2006-02-06 13:50:21.788927500 +0100 +++ session.c 2006-02-06 13:45:27.042081500 +0100 @@ -2176,7 +2176,6 @@ session_exit_message(Session *s, int sta /* disconnect channel */ debug("session_exit_message: release channel %d", s->chanid); - s->pid = 0; /* * Adjust cleanup callback attachment to send close messages when @@ -2238,6 +2237,7 @@ session_close_by_pid(pid_t pid, int stat session_exit_message(s, status); if (s->ttyfd != -1) session_pty_cleanup(s); + s->pid = 0; } /* From dtucker at zip.com.au Tue Feb 7 01:06:44 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 7 Feb 2006 01:06:44 +1100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060206134255.GA8481@calimero.vinschen.de> References: <43E316CA.9060504@mindrot.org> <20060204131446.GM15572@calimero.vinschen.de> <20060204224115.GO15572@calimero.vinschen.de> <20060206110243.GA6756@calimero.vinschen.de> <20060206113818.GA8655@gate.dtucker.net> <20060206124443.GZ15572@calimero.vinschen.de> <20060206134255.GA8481@calimero.vinschen.de> Message-ID: <20060206140644.GB10083@gate.dtucker.net> On Mon, Feb 06, 2006 at 02:42:55PM +0100, Corinna Vinschen wrote: > I just tested the below patch and it solves the problem for me. > Since session_exit_message is only called from session_close_by_pid, > the solution seems to be the correct one. > > > --- session.c.ORIG 2006-02-06 13:50:21.788927500 +0100 > +++ session.c 2006-02-06 13:45:27.042081500 +0100 > @@ -2176,7 +2176,6 @@ session_exit_message(Session *s, int sta > > /* disconnect channel */ > debug("session_exit_message: release channel %d", s->chanid); > - s->pid = 0; > > /* > * Adjust cleanup callback attachment to send close messages when > @@ -2238,6 +2237,7 @@ session_close_by_pid(pid_t pid, int stat > session_exit_message(s, status); > if (s->ttyfd != -1) > session_pty_cleanup(s); > + s->pid = 0; > } FWIW the s->pid bit was added in this change: revision 1.308 date: 2005/11/05 03:52:51; author: djm; state: Exp; lines: +23 -14 - djm at cvs.openbsd.org 2005/10/10 10:23:08 [channels.c channels.h clientloop.c serverloop.c session.c] fix regression I introduced in 4.2: X11 forwardings initiated after a session has exited (e.g. "(sleep 5; xterm) &") would not start. bz #1086 reported by t8m AT centrum.cz; ok markus@ dtucker@ Not sure what (if any) effect the diff would have on the case above. -- 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 rac at tenzing.org Tue Feb 7 03:36:45 2006 From: rac at tenzing.org (Roger Cornelius) Date: Mon, 6 Feb 2006 11:36:45 -0500 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060206134255.GA8481@calimero.vinschen.de> References: <43E316CA.9060504@mindrot.org> <20060204131446.GM15572@calimero.vinschen.de> <20060204224115.GO15572@calimero.vinschen.de> <20060206110243.GA6756@calimero.vinschen.de> <20060206113818.GA8655@gate.dtucker.net> <20060206124443.GZ15572@calimero.vinschen.de> <20060206134255.GA8481@calimero.vinschen.de> Message-ID: <20060206163645.GB11973@tenzing.org> On 02/06/2006 14:42, Corinna Vinschen wrote: > On Feb 6 13:44, Corinna Vinschen wrote: > > On Feb 6 22:38, Darren Tucker wrote: > > > On Mon, Feb 06, 2006 at 12:02:43PM +0100, Corinna Vinschen wrote: > > > [...] > > > > I debugged an sshd child and found this: > > > > > > > > - On logging out from an interactive session, EOF is encountered and > > > > down from do_authenticated, session_close_by_pid is called. > > > > > > > > - session_by_pid returns the correct Session pointer. > > > > > > > > - s->chanid is != -1, ==> session_exit_message is called. > > > > > > > > - session_exit_message sets s->pid = 0 and returns to session_close_by_pid. > > > > > > > > - s->ttyfd != -1, ==> session_pty_cleanup is called. > > > > > > > > - session_pty_cleanup calls session_pty_cleanup2. > > > > > > > > - In session_pty_cleanup2, record_logout is only called if s->pid != 0. > > > > > > > > Do I miss something or is it somehow impossible to get a logout record > > > > this way?!? > > > > > > When privsep is on, session_exit_message is called in the slave, but > > > session_pty_cleanup2 is called by the monitor, so it works. > > > > > > It looks like a problem when privsep=no, though, and it's not immediately > > > obvious to me what to do with it. > > > > This also happens if UsePrivilegeSeparation is set to "yes" in > > /etc/sshd_config on Cygwin. The problem is that descriptor passing > > doesn't work on Cygwin which in turn sets use_privsep to 0. So, logout > > logging is entirely broken for all systems which either don't support, > > or have broken file descriptor passing. > > > > Since the old session_exit_message only set s->chanid to -1, maybe we > > could remove setting s->pid to 0 from session_exit_message and move it > > to the end of session_close_by_pid? > > I just tested the below patch and it solves the problem for me. > Since session_exit_message is only called from session_close_by_pid, > the solution seems to be the correct one. I noticed this behaviour on SCO OSR507 after building 4.3p1 over the weekend. Finding the problem was on my todo list for today. Thank you for saving me the trouble. I do not see the problem on SCO OSR6, so it must be one of the excluded cases you mention (though I haven't checked). Roger -- Roger Cornelius rac at tenzing.org From daesan at mac.com Tue Feb 7 02:34:32 2006 From: daesan at mac.com (Dae San Hwang) Date: Tue, 7 Feb 2006 00:34:32 +0900 Subject: Compile warning report of openssh 4.3p1 on Intel Macs Message-ID: <6FD59A57-BA4A-4D91-8F3E-8DF4B139FF69@mac.com> Hi. I was compiling openssh 4.3p1 on Apple's iMac Core Duo computer and came across following warnings. configure: WARNING: net/if.h: present but cannot be compiled configure: WARNING: net/if.h: check for missing prerequisite headers? configure: WARNING: net/if.h: see the Autoconf documentation configure: WARNING: net/if.h: section "Present But Cannot Be Compiled" configure: WARNING: net/if.h: proceeding with the preprocessor's result configure: WARNING: net/if.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix- dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## Following is the entire output of ./configure script: checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking build system type... i686-apple-darwin8.4.1 checking host system type... i686-apple-darwin8.4.1 checking whether byte ordering is bigendian... no checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking how to run the C preprocessor... gcc -E checking for ranlib... ranlib checking for a BSD-compatible install... /usr/bin/install -c checking for ar... /usr/bin/ar checking for cat... /bin/cat checking for kill... /bin/kill checking for perl5... no checking for perl... /usr/bin/perl checking for sed... /usr/bin/sed checking for ent... no checking for bash... /bin/bash checking for ksh... (cached) /bin/bash checking for sh... (cached) /bin/bash checking for sh... /bin/sh checking for groupadd... groupadd checking for useradd... useradd checking for pkgmk... no checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking for _LARGE_FILES value needed for large files... no checking for login... /usr/bin/login checking for passwd... /usr/bin/passwd checking for inline... inline checking whether LLONG_MAX is declared... yes checking if we have working getaddrinfo... working checking compiler and flags for sanity... yes checking bstring.h usability... no checking bstring.h presence... no checking for bstring.h... no checking crypt.h usability... no checking crypt.h presence... no checking for crypt.h... no checking dirent.h usability... yes checking dirent.h presence... yes checking for dirent.h... yes checking endian.h usability... no checking endian.h presence... no checking for endian.h... no checking features.h usability... no checking features.h presence... no checking for features.h... no checking floatingpoint.h usability... no checking floatingpoint.h presence... no checking for floatingpoint.h... no checking getopt.h usability... yes checking getopt.h presence... yes checking for getopt.h... yes checking glob.h usability... yes checking glob.h presence... yes checking for glob.h... yes checking ia.h usability... no checking ia.h presence... no checking for ia.h... no checking iaf.h usability... no checking iaf.h presence... no checking for iaf.h... no checking lastlog.h usability... no checking lastlog.h presence... no checking for lastlog.h... no checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking login.h usability... no checking login.h presence... no checking for login.h... no checking login_cap.h usability... no checking login_cap.h presence... no checking for login_cap.h... no checking maillock.h usability... no checking maillock.h presence... no checking for maillock.h... no checking ndir.h usability... no checking ndir.h presence... no checking for ndir.h... no checking net/if.h usability... no checking net/if.h presence... yes configure: WARNING: net/if.h: present but cannot be compiled configure: WARNING: net/if.h: check for missing prerequisite headers? configure: WARNING: net/if.h: see the Autoconf documentation configure: WARNING: net/if.h: section "Present But Cannot Be Compiled" configure: WARNING: net/if.h: proceeding with the preprocessor's result configure: WARNING: net/if.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix- dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## checking for net/if.h... yes checking netdb.h usability... yes checking netdb.h presence... yes checking for netdb.h... yes checking netgroup.h usability... no checking netgroup.h presence... no checking for netgroup.h... no checking netinet/in_systm.h usability... yes checking netinet/in_systm.h presence... yes checking for netinet/in_systm.h... yes checking pam/pam_appl.h usability... yes checking pam/pam_appl.h presence... yes checking for pam/pam_appl.h... yes checking paths.h usability... yes checking paths.h presence... yes checking for paths.h... yes checking pty.h usability... no checking pty.h presence... no checking for pty.h... no checking readpassphrase.h usability... yes checking readpassphrase.h presence... yes checking for readpassphrase.h... yes checking rpc/types.h usability... yes checking rpc/types.h presence... yes checking for rpc/types.h... yes checking security/pam_appl.h usability... no checking security/pam_appl.h presence... no checking for security/pam_appl.h... no checking shadow.h usability... no checking shadow.h presence... no checking for shadow.h... no checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking stdint.h usability... yes checking stdint.h presence... yes checking for stdint.h... yes checking string.h usability... yes checking string.h presence... yes checking for string.h... yes checking strings.h usability... yes checking strings.h presence... yes checking for strings.h... yes checking sys/audit.h usability... no checking sys/audit.h presence... no checking for sys/audit.h... no checking sys/bitypes.h usability... no checking sys/bitypes.h presence... no checking for sys/bitypes.h... no checking sys/bsdtty.h usability... no checking sys/bsdtty.h presence... no checking for sys/bsdtty.h... no checking sys/cdefs.h usability... yes checking sys/cdefs.h presence... yes checking for sys/cdefs.h... yes checking sys/dir.h usability... yes checking sys/dir.h presence... yes checking for sys/dir.h... yes checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking sys/ndir.h usability... no checking sys/ndir.h presence... no checking for sys/ndir.h... no checking sys/prctl.h usability... no checking sys/prctl.h presence... no checking for sys/prctl.h... no checking sys/pstat.h usability... no checking sys/pstat.h presence... no checking for sys/pstat.h... no checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking sys/stat.h usability... yes checking sys/stat.h presence... yes checking for sys/stat.h... yes checking sys/stream.h usability... no checking sys/stream.h presence... no checking for sys/stream.h... no checking sys/stropts.h usability... no checking sys/stropts.h presence... no checking for sys/stropts.h... no checking sys/strtio.h usability... no checking sys/strtio.h presence... no checking for sys/strtio.h... no checking sys/sysmacros.h usability... no checking sys/sysmacros.h presence... no checking for sys/sysmacros.h... no checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/timers.h usability... no checking sys/timers.h presence... no checking for sys/timers.h... no checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking time.h usability... yes checking time.h presence... yes checking for time.h... yes checking tmpdir.h usability... no checking tmpdir.h presence... no checking for tmpdir.h... no checking ttyent.h usability... yes checking ttyent.h presence... yes checking for ttyent.h... yes checking unistd.h usability... yes checking unistd.h presence... yes checking for unistd.h... yes checking usersec.h usability... no checking usersec.h presence... no checking for usersec.h... no checking util.h usability... yes checking util.h presence... yes checking for util.h... yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking utmp.h usability... yes checking utmp.h presence... yes checking for utmp.h... yes checking utmpx.h usability... yes checking utmpx.h presence... yes checking for utmpx.h... yes checking vis.h usability... yes checking vis.h presence... yes checking for vis.h... yes checking for sys/ptms.h... no checking for yp_match... yes checking for setsockopt... yes checking for dirname... yes checking libgen.h usability... yes checking libgen.h presence... yes checking for libgen.h... yes checking for getspnam... no checking for getspnam in -lgen... no checking for library containing basename... none required checking for deflate in -lz... yes checking zlib.h usability... yes checking zlib.h presence... yes checking for zlib.h... yes checking for possibly buggy zlib... no checking for strcasecmp... yes checking for utimes... yes checking libutil.h usability... no checking libutil.h presence... no checking for libutil.h... no checking for library containing login... none required checking for logout... yes checking for updwtmp... no checking for logwtmp... yes checking for strftime... yes checking for GLOB_ALTDIRFUNC support... no checking for gl_matchc field in glob_t... no checking whether struct dirent allocates space for d_name... yes checking for /proc/pid/fd directory... no checking for arc4random... yes checking for asprintf... yes checking for b64_ntop... no checking for __b64_ntop... no checking for b64_pton... no checking for __b64_pton... no checking for bcopy... yes checking for bindresvport_sa... yes checking for clock... yes checking for closefrom... no checking for dirfd... no checking for fchmod... yes checking for fchown... yes checking for freeaddrinfo... yes checking for futimes... yes checking for getaddrinfo... yes checking for getcwd... yes checking for getgrouplist... yes checking for getnameinfo... yes checking for getopt... yes checking for getpeereid... yes checking for _getpty... no checking for getrlimit... yes checking for getttyent... yes checking for glob... yes checking for inet_aton... yes checking for inet_ntoa... yes checking for inet_ntop... yes checking for innetgr... yes checking for login_getcapbool... no checking for md5_crypt... no checking for memmove... yes checking for mkdtemp... yes checking for mmap... yes checking for ngetaddrinfo... no checking for nsleep... no checking for ogetaddrinfo... no checking for openlog_r... no checking for openpty... yes checking for prctl... no checking for pstat... no checking for readpassphrase... yes checking for realpath... yes checking for recvmsg... yes checking for rresvport_af... yes checking for sendmsg... yes checking for setdtablesize... no checking for setegid... yes checking for setenv... yes checking for seteuid... yes checking for setgroups... yes checking for setlogin... yes checking for setpcred... no checking for setproctitle... no checking for setregid... yes checking for setreuid... yes checking for setrlimit... yes checking for setsid... yes checking for setvbuf... yes checking for sigaction... yes checking for sigvec... yes checking for snprintf... yes checking for socketpair... yes checking for strdup... yes checking for strerror... yes checking for strlcat... yes checking for strlcpy... yes checking for strmode... yes checking for strnvis... no checking for strtonum... no checking for strtoll... yes checking for strtoul... yes checking for sysconf... yes checking for tcgetpgrp... yes checking for truncate... yes checking for unsetenv... yes checking for updwtmpx... no checking for vasprintf... yes checking for vhangup... no checking for vsnprintf... yes checking for waitpid... yes checking for gai_strerror... yes checking for library containing nanosleep... none required checking whether getrusage is declared... no checking whether strsep is declared... yes checking for strsep... yes checking whether tcsendbreak is declared... yes checking whether h_errno is declared... yes checking for setresuid... no checking for setresgid... no checking for gettimeofday... yes checking for time... yes checking for endutent... no checking for getutent... no checking for getutid... no checking for getutline... no checking for pututline... no checking for setutent... no checking for utmpname... no checking for endutxent... yes checking for getutxent... yes checking for getutxid... yes checking for getutxline... yes checking for pututxline... yes checking for setutxent... yes checking for utmpxname... no checking for daemon... yes checking for getpagesize... yes checking whether snprintf correctly terminates long strings... yes checking whether snprintf can declare const char *fmt... yes checking for (overly) strict mkstemp... no checking whether getpgrp requires zero arguments... yes checking OpenSSL header version... 90709f (OpenSSL 0.9.7i 14 Oct 2005) checking OpenSSL library version... 90709f (OpenSSL 0.9.7i 14 Oct 2005) checking whether OpenSSL's headers match the library... yes checking whether OpenSSL has crippled AES support... yes checking for ia_openinfo in -liaf... no checking whether OpenSSL's PRNG is internally seeded... yes checking for ls... /bin/ls checking for netstat... /usr/sbin/netstat checking for arp... /usr/sbin/arp checking for ifconfig... /sbin/ifconfig checking for jstat... no checking for ps... /bin/ps checking for sar... /usr/bin/sar checking for w... /usr/bin/w checking for who... /usr/bin/who checking for last... /usr/bin/last checking for lastlog... no checking for df... /bin/df checking for vmstat... no checking for uptime... /usr/bin/uptime checking for ipcs... /usr/bin/ipcs checking for tail... /usr/bin/tail checking for long long... yes checking for unsigned long long... yes checking for long double... yes checking for char... yes checking size of char... 1 checking for short int... yes checking size of short int... 2 checking for int... yes checking size of int... 4 checking for long int... yes checking size of long int... 4 checking for long long int... yes checking size of long long int... 8 checking for u_int type... yes checking for intXX_t types... yes checking for int64_t type... yes checking for u_intXX_t types... yes checking for u_int64_t types... yes checking for uintXX_t types in stdint.h... yes checking for u_char... yes checking for socklen_t... yes checking for sig_atomic_t... yes checking for in_addr_t... yes checking for size_t... yes checking for ssize_t... yes checking for clock_t... yes checking for sa_family_t... yes checking for pid_t... yes checking for mode_t... yes checking for struct sockaddr_storage... yes checking for struct sockaddr_in6... yes checking for struct in6_addr... yes checking for struct addrinfo... yes checking for struct timeval... yes checking for struct timespec... yes checking for ut_host field in utmp.h... no checking for ut_host field in utmpx.h... no checking for syslen field in utmpx.h... no checking for ut_pid field in utmp.h... no checking for ut_type field in utmp.h... no checking for ut_type field in utmpx.h... no checking for ut_tv field in utmp.h... no checking for ut_id field in utmp.h... no checking for ut_id field in utmpx.h... no checking for ut_addr field in utmp.h... no checking for ut_addr field in utmpx.h... no checking for ut_addr_v6 field in utmp.h... no checking for ut_addr_v6 field in utmpx.h... no checking for ut_exit field in utmp.h... no checking for ut_time field in utmp.h... no checking for ut_time field in utmpx.h... no checking for ut_tv field in utmpx.h... no checking for struct stat.st_blksize... yes checking for struct __res_state.retrans... yes checking for ss_family field in struct sockaddr_storage... yes checking for __ss_family field in struct sockaddr_storage... no checking for pw_class field in struct passwd... yes checking for pw_expire field in struct passwd... yes checking for pw_change field in struct passwd... yes checking for msg_accrights field in struct msghdr... no checking for msg_control field in struct msghdr... yes checking if libc defines __progname... yes checking whether gcc implements __FUNCTION__... yes checking whether gcc implements __func__... yes checking whether va_copy exists... yes checking whether __va_copy exists... yes checking whether getopt has optreset support... yes checking if libc defines sys_errlist... yes checking if libc defines sys_nerr... yes checking for library containing getrrsetbyname... no checking for library containing res_query... none required checking for library containing dn_expand... none required checking if res_query will link... yes checking for _getshort... yes checking for _getlong... yes checking whether _getshort is declared... yes checking whether _getlong is declared... yes checking for HEADER.ad... no checking for xauth... no checking for "/dev/ptmx"... no checking for "/dev/ptc"... no checking for nroff... /usr/bin/nroff checking if the systems has expire shadow information... no checking for "/etc/default/login"... no Adding /usr/local/bin to USER_PATH so scp will work checking if we need to convert IPv4 in IPv6-mapped addresses... no (default) checking if your system defines LASTLOG_FILE... no checking if your system defines _PATH_LASTLOG... yes checking if your system defines UTMP_FILE... no checking if your system defines WTMP_FILE... no checking if your system defines UTMPX_FILE... yes checking if your system defines WTMPX_FILE... no configure: creating ./config.status config.status: creating Makefile config.status: creating buildpkg.sh config.status: creating opensshd.init config.status: creating openbsd-compat/Makefile config.status: creating scard/Makefile config.status: creating ssh_prng_cmds config.status: creating survey.sh config.status: creating config.h 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:/usr/sbin:/sbin:/ usr/local/bin Manpage format: doc PAM support: no KerberosV support: no Smartcard support: no S/KEY support: no TCP Wrappers support: no MD5 password support: no libedit support: no IP address in $DISPLAY hack: no Translate v4 in v6 hack: no BSD Auth support: no Random number source: OpenSSL internal ONLY Host: i686-apple-darwin8.4.1 Compiler: gcc Compiler flags: -g -O2 -Wall -Wpointer-arith -Wuninitialized - Wsign-compare -Wno-pointer-sign Preprocessor flags: Linker flags: Libraries: -lcrypto -lz I really appreciate your hard work and I hope my report does a little help. Sincerely, Dae San Hwang From tim at multitalents.net Tue Feb 7 04:23:17 2006 From: tim at multitalents.net (Tim Rice) Date: Mon, 6 Feb 2006 09:23:17 -0800 (PST) Subject: Compile warning report of openssh 4.3p1 on Intel Macs In-Reply-To: <6FD59A57-BA4A-4D91-8F3E-8DF4B139FF69@mac.com> Message-ID: On Tue, 7 Feb 2006, Dae San Hwang wrote: > Hi. > > I was compiling openssh 4.3p1 on Apple's iMac Core Duo computer and > came across following warnings. > > configure: WARNING: net/if.h: present but cannot be compiled > configure: WARNING: net/if.h: check for missing prerequisite > headers? That warning can be ignored. It's fixed in the current snapshot. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From vinschen at redhat.com Tue Feb 7 05:16:10 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 6 Feb 2006 19:16:10 +0100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060206140644.GB10083@gate.dtucker.net> References: <43E316CA.9060504@mindrot.org> <20060204131446.GM15572@calimero.vinschen.de> <20060204224115.GO15572@calimero.vinschen.de> <20060206110243.GA6756@calimero.vinschen.de> <20060206113818.GA8655@gate.dtucker.net> <20060206124443.GZ15572@calimero.vinschen.de> <20060206134255.GA8481@calimero.vinschen.de> <20060206140644.GB10083@gate.dtucker.net> Message-ID: <20060206181610.GI15572@calimero.vinschen.de> On Feb 7 01:06, Darren Tucker wrote: > On Mon, Feb 06, 2006 at 02:42:55PM +0100, Corinna Vinschen wrote: > > I just tested the below patch and it solves the problem for me. > > Since session_exit_message is only called from session_close_by_pid, > > the solution seems to be the correct one. > > > > > > --- session.c.ORIG 2006-02-06 13:50:21.788927500 +0100 > > +++ session.c 2006-02-06 13:45:27.042081500 +0100 > > @@ -2176,7 +2176,6 @@ session_exit_message(Session *s, int sta > > > > /* disconnect channel */ > > debug("session_exit_message: release channel %d", s->chanid); > > - s->pid = 0; > > > > /* > > * Adjust cleanup callback attachment to send close messages when > > @@ -2238,6 +2237,7 @@ session_close_by_pid(pid_t pid, int stat > > session_exit_message(s, status); > > if (s->ttyfd != -1) > > session_pty_cleanup(s); > > + s->pid = 0; > > } > > FWIW the s->pid bit was added in this change: I found another problem. If I switch on privilege separation on Cygwin, I get two syslog messages per login, one from the privsep process and another one from the child sshd which handles the connection. This is only a headsup so far, it's too late for today to debug this. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vinschen at redhat.com Tue Feb 7 22:32:33 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 7 Feb 2006 12:32:33 +0100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060206181610.GI15572@calimero.vinschen.de> References: <20060204131446.GM15572@calimero.vinschen.de> <20060204224115.GO15572@calimero.vinschen.de> <20060206110243.GA6756@calimero.vinschen.de> <20060206113818.GA8655@gate.dtucker.net> <20060206124443.GZ15572@calimero.vinschen.de> <20060206134255.GA8481@calimero.vinschen.de> <20060206140644.GB10083@gate.dtucker.net> <20060206181610.GI15572@calimero.vinschen.de> Message-ID: <20060207113233.GB2979@calimero.vinschen.de> On Feb 6 19:16, Corinna Vinschen wrote: > On Feb 7 01:06, Darren Tucker wrote: > > On Mon, Feb 06, 2006 at 02:42:55PM +0100, Corinna Vinschen wrote: > > > I just tested the below patch and it solves the problem for me. > > > Since session_exit_message is only called from session_close_by_pid, > > > the solution seems to be the correct one. > > > > > > > > > --- session.c.ORIG 2006-02-06 13:50:21.788927500 +0100 > > > +++ session.c 2006-02-06 13:45:27.042081500 +0100 > > > @@ -2176,7 +2176,6 @@ session_exit_message(Session *s, int sta > > > > > > /* disconnect channel */ > > > debug("session_exit_message: release channel %d", s->chanid); > > > - s->pid = 0; > > > > > > /* > > > * Adjust cleanup callback attachment to send close messages when > > > @@ -2238,6 +2237,7 @@ session_close_by_pid(pid_t pid, int stat > > > session_exit_message(s, status); > > > if (s->ttyfd != -1) > > > session_pty_cleanup(s); > > > + s->pid = 0; > > > } > > > > FWIW the s->pid bit was added in this change: > > I found another problem. If I switch on privilege separation on > Cygwin, I get two syslog messages per login, one from the privsep > process and another one from the child sshd which handles the connection. > > This is only a headsup so far, it's too late for today to debug this. I found it. If privilege separation is activated, monitor_child_preauth calls auth_log. If privilege separation is not used, userauth_finish calls auth_log. On systems lacking working descriptor passing, both functions are called when privilege separation is on. The only useful way I found to get rid of one of the messages is not to print the message from monitor_child_preauth, if DISABLE_FD_PASSING is set for the target. Patch below. If somebody finds a way without adding another #ifdef, I'd be very glad, though. Corinna --- monitor.c.ORIG 2006-02-07 12:23:49.792704600 +0100 +++ monitor.c 2006-02-07 12:22:55.282671000 +0100 @@ -349,8 +349,10 @@ monitor_child_preauth(Authctxt *_authctx } if (ent->flags & MON_AUTHDECIDE) { +#ifndef DISABLE_FD_PASSING auth_log(authctxt, authenticated, auth_method, compat20 ? " ssh2" : ""); +#endif if (!authenticated) authctxt->failures++; } -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From dtucker at zip.com.au Tue Feb 7 22:52:19 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 7 Feb 2006 22:52:19 +1100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060207113233.GB2979@calimero.vinschen.de> References: <20060204224115.GO15572@calimero.vinschen.de> <20060206110243.GA6756@calimero.vinschen.de> <20060206113818.GA8655@gate.dtucker.net> <20060206124443.GZ15572@calimero.vinschen.de> <20060206134255.GA8481@calimero.vinschen.de> <20060206140644.GB10083@gate.dtucker.net> <20060206181610.GI15572@calimero.vinschen.de> <20060207113233.GB2979@calimero.vinschen.de> Message-ID: <20060207115219.GA11061@gate.dtucker.net> On Tue, Feb 07, 2006 at 12:32:33PM +0100, Corinna Vinschen wrote: > I found it. If privilege separation is activated, monitor_child_preauth > calls auth_log. If privilege separation is not used, userauth_finish > calls auth_log. On systems lacking working descriptor passing, both > functions are called when privilege separation is on. The only useful > way I found to get rid of one of the messages is not to print the > message from monitor_child_preauth, if DISABLE_FD_PASSING is set for > the target. Patch below. If somebody finds a way without adding another > #ifdef, I'd be very glad, though. I've been looking at this too. It looks like I had a similar problem when doing the audit support and came up with an even uglier solution (look for SSH_AUDIT_EVENTS in auth.c). There has to be a nicer way for all concerned. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Tue Feb 7 23:55:01 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 7 Feb 2006 13:55:01 +0100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060207115219.GA11061@gate.dtucker.net> References: <20060204224115.GO15572@calimero.vinschen.de> <20060206110243.GA6756@calimero.vinschen.de> <20060206113818.GA8655@gate.dtucker.net> <20060206124443.GZ15572@calimero.vinschen.de> <20060206134255.GA8481@calimero.vinschen.de> <20060206140644.GB10083@gate.dtucker.net> <20060206181610.GI15572@calimero.vinschen.de> <20060207113233.GB2979@calimero.vinschen.de> <20060207115219.GA11061@gate.dtucker.net> Message-ID: <20060207125501.GC2979@calimero.vinschen.de> On Feb 7 22:52, Darren Tucker wrote: > On Tue, Feb 07, 2006 at 12:32:33PM +0100, Corinna Vinschen wrote: > > I found it. If privilege separation is activated, monitor_child_preauth > > calls auth_log. If privilege separation is not used, userauth_finish > > calls auth_log. On systems lacking working descriptor passing, both > > functions are called when privilege separation is on. The only useful > > way I found to get rid of one of the messages is not to print the > > message from monitor_child_preauth, if DISABLE_FD_PASSING is set for > > the target. Patch below. If somebody finds a way without adding another > > #ifdef, I'd be very glad, though. > > I've been looking at this too. It looks like I had a similar problem > when doing the audit support and came up with an even uglier solution > (look for SSH_AUDIT_EVENTS in auth.c). There has to be a nicer way > for all concerned. I found a better solution which doesn't require an #ifdef: --- auth2.c.ORIG 2006-02-07 13:53:11.561136300 +0100 +++ auth2.c 2006-02-07 13:51:08.992832300 +0100 @@ -243,7 +243,8 @@ userauth_finish(Authctxt *authctxt, int #endif /* _UNICOS */ /* Log before sending the reply */ - auth_log(authctxt, authenticated, method, " ssh2"); + if (!use_privsep) + auth_log(authctxt, authenticated, method, " ssh2"); if (authctxt->postponed) return; Is that ok? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From dtucker at zip.com.au Wed Feb 8 00:02:55 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 8 Feb 2006 00:02:55 +1100 Subject: bsd-cygwin_util.c compiler warning (Was Re: OpenSSH_4.3p1 configure patch) In-Reply-To: <20060206110655.GA7038@calimero.vinschen.de> References: <43E316CA.9060504@mindrot.org> <20060204131446.GM15572@calimero.vinschen.de> <20060204224115.GO15572@calimero.vinschen.de> <20060206110655.GA7038@calimero.vinschen.de> Message-ID: <20060207130255.GA12375@gate.dtucker.net> On Mon, Feb 06, 2006 at 12:06:55PM +0100, Corinna Vinschen wrote: > Can we add this patch to get rid of an annoying compiler warning? [...] > --- bsd-cygwin_util.c.ORIG 2006-02-06 12:06:17.657591500 +0100 > +++ bsd-cygwin_util.c 2006-02-06 10:55:57.543851300 +0100 > @@ -268,7 +268,7 @@ char ** > fetch_windows_environment(void) > { > char **e, **p; > - int i, idx = 0; > + unsigned int i, idx = 0; Fine by me. Any objections? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Wed Feb 8 00:15:35 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 8 Feb 2006 00:15:35 +1100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060207125501.GC2979@calimero.vinschen.de> References: <20060206110243.GA6756@calimero.vinschen.de> <20060206113818.GA8655@gate.dtucker.net> <20060206124443.GZ15572@calimero.vinschen.de> <20060206134255.GA8481@calimero.vinschen.de> <20060206140644.GB10083@gate.dtucker.net> <20060206181610.GI15572@calimero.vinschen.de> <20060207113233.GB2979@calimero.vinschen.de> <20060207115219.GA11061@gate.dtucker.net> <20060207125501.GC2979@calimero.vinschen.de> Message-ID: <20060207131535.GA12434@gate.dtucker.net> On Tue, Feb 07, 2006 at 01:55:01PM +0100, Corinna Vinschen wrote: > I found a better solution which doesn't require an #ifdef: > > --- auth2.c.ORIG 2006-02-07 13:53:11.561136300 +0100 > +++ auth2.c 2006-02-07 13:51:08.992832300 +0100 > @@ -243,7 +243,8 @@ userauth_finish(Authctxt *authctxt, int > #endif /* _UNICOS */ > > /* Log before sending the reply */ > - auth_log(authctxt, authenticated, method, " ssh2"); > + if (!use_privsep) > + auth_log(authctxt, authenticated, method, " ssh2"); > > if (authctxt->postponed) > return; > > Is that ok? I think that will stop logging of some auth attempts entirely when privsep is on (eg those that don't require a monitor call, such as failed pubkey attempts). Eg, compare "sshd -D -e -p 2022 -o maxauthtries=2" with and without the patch. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Wed Feb 8 00:17:45 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 7 Feb 2006 14:17:45 +0100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060206140644.GB10083@gate.dtucker.net> References: <43E316CA.9060504@mindrot.org> <20060204131446.GM15572@calimero.vinschen.de> <20060204224115.GO15572@calimero.vinschen.de> <20060206110243.GA6756@calimero.vinschen.de> <20060206113818.GA8655@gate.dtucker.net> <20060206124443.GZ15572@calimero.vinschen.de> <20060206134255.GA8481@calimero.vinschen.de> <20060206140644.GB10083@gate.dtucker.net> Message-ID: <20060207131745.GD2979@calimero.vinschen.de> On Feb 7 01:06, Darren Tucker wrote: > On Mon, Feb 06, 2006 at 02:42:55PM +0100, Corinna Vinschen wrote: > > I just tested the below patch and it solves the problem for me. > > Since session_exit_message is only called from session_close_by_pid, > > the solution seems to be the correct one. > > > > > > --- session.c.ORIG 2006-02-06 13:50:21.788927500 +0100 > > +++ session.c 2006-02-06 13:45:27.042081500 +0100 > > @@ -2176,7 +2176,6 @@ session_exit_message(Session *s, int sta > > > > /* disconnect channel */ > > debug("session_exit_message: release channel %d", s->chanid); > > - s->pid = 0; > > > > /* > > * Adjust cleanup callback attachment to send close messages when > > @@ -2238,6 +2237,7 @@ session_close_by_pid(pid_t pid, int stat > > session_exit_message(s, status); > > if (s->ttyfd != -1) > > session_pty_cleanup(s); > > + s->pid = 0; > > } > > FWIW the s->pid bit was added in this change: > > revision 1.308 > date: 2005/11/05 03:52:51; author: djm; state: Exp; lines: +23 -14 > - djm at cvs.openbsd.org 2005/10/10 10:23:08 > [channels.c channels.h clientloop.c serverloop.c session.c] > fix regression I introduced in 4.2: X11 forwardings initiated after > a session has exited (e.g. "(sleep 5; xterm) &") would not start. > bz #1086 reported by t8m AT centrum.cz; ok markus@ dtucker@ > > Not sure what (if any) effect the diff would have on the case above. I'm not *quite* sure if I analyzed that correctly, but AFAICS, it should have no effect on the situation solved by the patch from 2005/11/05: - session_exit_message is a static function which is exclusively called by session_close_by_pid. - In session_exit_message, following the setting of s->pid to 0 are only two calls, channel_register_cleanup and chan_write_failed. - channel_register_cleanup only marks session_close_by_channel to be run for the channel on cleanup, but it does not run this function immediately, nor does it itself depend on the setting of s->pid. - chan_write_failed does also not depend on the setting of s->pid. - On return from session_exit_message to session_close_by_pid, session_pty_cleanup is called with correct s->pid setting. - s->pid is set to 0. - In a later cleanup, session_close_by_channel is called and s->pid has the expected value of 0. Did I miss something? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vinschen at redhat.com Wed Feb 8 00:54:34 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 7 Feb 2006 14:54:34 +0100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060207131535.GA12434@gate.dtucker.net> References: <20060206110243.GA6756@calimero.vinschen.de> <20060206113818.GA8655@gate.dtucker.net> <20060206124443.GZ15572@calimero.vinschen.de> <20060206134255.GA8481@calimero.vinschen.de> <20060206140644.GB10083@gate.dtucker.net> <20060206181610.GI15572@calimero.vinschen.de> <20060207113233.GB2979@calimero.vinschen.de> <20060207115219.GA11061@gate.dtucker.net> <20060207125501.GC2979@calimero.vinschen.de> <20060207131535.GA12434@gate.dtucker.net> Message-ID: <20060207135434.GE2979@calimero.vinschen.de> On Feb 8 00:15, Darren Tucker wrote: > On Tue, Feb 07, 2006 at 01:55:01PM +0100, Corinna Vinschen wrote: > > I found a better solution which doesn't require an #ifdef: > > > > --- auth2.c.ORIG 2006-02-07 13:53:11.561136300 +0100 > > +++ auth2.c 2006-02-07 13:51:08.992832300 +0100 > > @@ -243,7 +243,8 @@ userauth_finish(Authctxt *authctxt, int > > #endif /* _UNICOS */ > > > > /* Log before sending the reply */ > > - auth_log(authctxt, authenticated, method, " ssh2"); > > + if (!use_privsep) > > + auth_log(authctxt, authenticated, method, " ssh2"); > > > > if (authctxt->postponed) > > return; > > > > Is that ok? > > I think that will stop logging of some auth attempts entirely when > privsep is on (eg those that don't require a monitor call, such as > failed pubkey attempts). > > Eg, compare "sshd -D -e -p 2022 -o maxauthtries=2" with and without the > patch. Pity. Back to #ifndef DISABLE_FD_PASSING :-( Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From sangelov at globul.bg Wed Feb 8 01:17:22 2006 From: sangelov at globul.bg (Stoyan Angelov) Date: Tue, 07 Feb 2006 16:17:22 +0200 Subject: OpenSSH 4.3P1: incorrect wtmpx entries References: 20060204115149.GA17539@rzdspc10.informatik.uni-hamburg.de Message-ID: <43E8ABF2.7070505@globul.bg> hello all, just FYI i have tested the patch on a solaris 7 x86 (11/99) box experiencing the same problem - the patch works fine and fixes the problem. greetings, Stoyan Angelov From dtucker at zip.com.au Wed Feb 8 09:45:32 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 8 Feb 2006 09:45:32 +1100 Subject: configure.ac: typos in Ultrix and NewsOS sections Message-ID: <20060207224531.GA23720@gate.dtucker.net> Hi all. Bernhard Simon has reported a couple of typos in configure.ac in the sections for Ultrix and Sony NewsOS (NEED_SETPRGP -> NEED_SETPGRP). Now I can't imagine them being heavily used, and the change ought to affect only those (famous last words :-). Anyone see any reason not to do this? Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v retrieving revision 1.327 diff -u -p -r1.327 configure.ac --- configure.ac 5 Feb 2006 19:27:10 -0000 1.327 +++ configure.ac 7 Feb 2006 22:18:34 -0000 @@ -345,7 +345,7 @@ main() { if (NSVersionOfRunTimeLibrary(" fi ;; mips-sony-bsd|mips-sony-newsos4) - AC_DEFINE(NEED_SETPRGP, 1, [Need setpgrp to acquire controlling tty]) + AC_DEFINE(NEED_SETPGRP, 1, [Need setpgrp to acquire controlling tty]) SONY=1 ;; *-*-netbsd*) @@ -589,7 +589,7 @@ mips-sony-bsd|mips-sony-newsos4) *-*-ultrix*) AC_DEFINE(BROKEN_GETGROUPS, 1, [getgroups(0,NULL) will return -1]) AC_DEFINE(BROKEN_MMAP, 1, [Ultrix mmap can't map files]) - AC_DEFINE(NEED_SETPRGP) + AC_DEFINE(NEED_SETPGRP) AC_DEFINE(HAVE_SYS_SYSLOG_H, 1, [Force use of sys/syslog.h on Ultrix]) ;; -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From tim at multitalents.net Wed Feb 8 10:29:06 2006 From: tim at multitalents.net (Tim Rice) Date: Tue, 7 Feb 2006 15:29:06 -0800 (PST) Subject: session.c Was: Re: OpenSSH_4.3p1 configure patch In-Reply-To: <20060207131745.GD2979@calimero.vinschen.de> References: <43E316CA.9060504@mindrot.org> <20060204131446.GM15572@calimero.vinschen.de> <20060204224115.GO15572@calimero.vinschen.de> <20060206110243.GA6756@calimero.vinschen.de> <20060206113818.GA8655@gate.dtucker.net> <20060206124443.GZ15572@calimero.vinschen.de> <20060206134255.GA8481@calimero.vinschen.de> <20060206140644.GB10083@gate.dtucker.net> <20060207131745.GD2979@calimero.vinschen.de> Message-ID: On Tue, 7 Feb 2006, Corinna Vinschen wrote: > On Feb 7 01:06, Darren Tucker wrote: > > On Mon, Feb 06, 2006 at 02:42:55PM +0100, Corinna Vinschen wrote: > > > I just tested the below patch and it solves the problem for me. > > > Since session_exit_message is only called from session_close_by_pid, > > > the solution seems to be the correct one. > > > > > > > > > --- session.c.ORIG 2006-02-06 13:50:21.788927500 +0100 > > > +++ session.c 2006-02-06 13:45:27.042081500 +0100 > > > @@ -2176,7 +2176,6 @@ session_exit_message(Session *s, int sta > > > > > > /* disconnect channel */ > > > debug("session_exit_message: release channel %d", s->chanid); > > > - s->pid = 0; > > > > > > /* > > > * Adjust cleanup callback attachment to send close messages when > > > @@ -2238,6 +2237,7 @@ session_close_by_pid(pid_t pid, int stat > > > session_exit_message(s, status); > > > if (s->ttyfd != -1) > > > session_pty_cleanup(s); > > > + s->pid = 0; > > > } > > > > FWIW the s->pid bit was added in this change: > > > > revision 1.308 > > date: 2005/11/05 03:52:51; author: djm; state: Exp; lines: +23 -14 > > - djm at cvs.openbsd.org 2005/10/10 10:23:08 > > [channels.c channels.h clientloop.c serverloop.c session.c] > > fix regression I introduced in 4.2: X11 forwardings initiated after > > a session has exited (e.g. "(sleep 5; xterm) &") would not start. > > bz #1086 reported by t8m AT centrum.cz; ok markus@ dtucker@ > > > > Not sure what (if any) effect the diff would have on the case above. > > I'm not *quite* sure if I analyzed that correctly, but AFAICS, it should > have no effect on the situation solved by the patch from 2005/11/05: > > - session_exit_message is a static function which is exclusively called > by session_close_by_pid. > > - In session_exit_message, following the setting of s->pid to 0 are only > two calls, channel_register_cleanup and chan_write_failed. > > - channel_register_cleanup only marks session_close_by_channel to be run > for the channel on cleanup, but it does not run this function immediately, > nor does it itself depend on the setting of s->pid. > > - chan_write_failed does also not depend on the setting of s->pid. > > - On return from session_exit_message to session_close_by_pid, > session_pty_cleanup is called with correct s->pid setting. > > - s->pid is set to 0. > > - In a later cleanup, session_close_by_channel is called and s->pid has > the expected value of 0. > > Did I miss something? > It doesn't look like it to me. (and tests good here) I've commited your patch. > > Corinna > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Wed Feb 8 10:58:56 2006 From: tim at multitalents.net (Tim Rice) Date: Tue, 7 Feb 2006 15:58:56 -0800 (PST) Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060207113233.GB2979@calimero.vinschen.de> References: <20060204131446.GM15572@calimero.vinschen.de> <20060204224115.GO15572@calimero.vinschen.de> <20060206110243.GA6756@calimero.vinschen.de> <20060206113818.GA8655@gate.dtucker.net> <20060206124443.GZ15572@calimero.vinschen.de> <20060206134255.GA8481@calimero.vinschen.de> <20060206140644.GB10083@gate.dtucker.net> <20060206181610.GI15572@calimero.vinschen.de> <20060207113233.GB2979@calimero.vinschen.de> Message-ID: On Tue, 7 Feb 2006, Corinna Vinschen wrote: > On Feb 6 19:16, Corinna Vinschen wrote: > > I found another problem. If I switch on privilege separation on > > Cygwin, I get two syslog messages per login, one from the privsep > > process and another one from the child sshd which handles the connection. > > > > This is only a headsup so far, it's too late for today to debug this. > > I found it. If privilege separation is activated, monitor_child_preauth > calls auth_log. If privilege separation is not used, userauth_finish > calls auth_log. On systems lacking working descriptor passing, both > functions are called when privilege separation is on. The only useful > way I found to get rid of one of the messages is not to print the > message from monitor_child_preauth, if DISABLE_FD_PASSING is set for > the target. Patch below. If somebody finds a way without adding another > #ifdef, I'd be very glad, though. I can't duplicate this on another platform (SCO 507) that has DISABLE_FD_PASSING defined. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From dtucker at zip.com.au Wed Feb 8 11:14:04 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 8 Feb 2006 11:14:04 +1100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: References: <20060204224115.GO15572@calimero.vinschen.de> <20060206110243.GA6756@calimero.vinschen.de> <20060206113818.GA8655@gate.dtucker.net> <20060206124443.GZ15572@calimero.vinschen.de> <20060206134255.GA8481@calimero.vinschen.de> <20060206140644.GB10083@gate.dtucker.net> <20060206181610.GI15572@calimero.vinschen.de> <20060207113233.GB2979@calimero.vinschen.de> Message-ID: <20060208001404.GA25442@gate.dtucker.net> On Tue, Feb 07, 2006 at 03:58:56PM -0800, Tim Rice wrote: > On Tue, 7 Feb 2006, Corinna Vinschen wrote: > > > On Feb 6 19:16, Corinna Vinschen wrote: > > > I found another problem. If I switch on privilege separation on > > > Cygwin, I get two syslog messages per login, one from the privsep > > > process and another one from the child sshd which handles the connection. > > > > > > This is only a headsup so far, it's too late for today to debug this. > > > > I found it. If privilege separation is activated, monitor_child_preauth > > calls auth_log. If privilege separation is not used, userauth_finish > > calls auth_log. On systems lacking working descriptor passing, both > > functions are called when privilege separation is on. The only useful > > way I found to get rid of one of the messages is not to print the > > message from monitor_child_preauth, if DISABLE_FD_PASSING is set for > > the target. Patch below. If somebody finds a way without adding another > > #ifdef, I'd be very glad, though. > > I can't duplicate this on another platform (SCO 507) that has > DISABLE_FD_PASSING defined. Do you have a /dev/log in the privsep chroot? I suspect that Cygwin uses some other method for passing its log messages which is why you're seeing a difference. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From tim at multitalents.net Wed Feb 8 11:34:47 2006 From: tim at multitalents.net (Tim Rice) Date: Tue, 7 Feb 2006 16:34:47 -0800 (PST) Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060208001404.GA25442@gate.dtucker.net> References: <20060204224115.GO15572@calimero.vinschen.de> <20060206110243.GA6756@calimero.vinschen.de> <20060206113818.GA8655@gate.dtucker.net> <20060206124443.GZ15572@calimero.vinschen.de> <20060206134255.GA8481@calimero.vinschen.de> <20060206140644.GB10083@gate.dtucker.net> <20060206181610.GI15572@calimero.vinschen.de> <20060207113233.GB2979@calimero.vinschen.de> <20060208001404.GA25442@gate.dtucker.net> Message-ID: On Wed, 8 Feb 2006, Darren Tucker wrote: > On Tue, Feb 07, 2006 at 03:58:56PM -0800, Tim Rice wrote: > > On Tue, 7 Feb 2006, Corinna Vinschen wrote: > > > > > On Feb 6 19:16, Corinna Vinschen wrote: > > > > I found another problem. If I switch on privilege separation on > > > > Cygwin, I get two syslog messages per login, one from the privsep > > > > process and another one from the child sshd which handles the connection. > > > > > > > > This is only a headsup so far, it's too late for today to debug this. > > > > > > I found it. If privilege separation is activated, monitor_child_preauth > > > calls auth_log. If privilege separation is not used, userauth_finish > > > calls auth_log. On systems lacking working descriptor passing, both > > > functions are called when privilege separation is on. The only useful > > > way I found to get rid of one of the messages is not to print the > > > message from monitor_child_preauth, if DISABLE_FD_PASSING is set for > > > the target. Patch below. If somebody finds a way without adding another > > > #ifdef, I'd be very glad, though. > > > > I can't duplicate this on another platform (SCO 507) that has > > DISABLE_FD_PASSING defined. > > Do you have a /dev/log in the privsep chroot? I suspect that Cygwin > uses some other method for passing its log messages which is why you're > seeing a difference. That's it. I'll see if I can reconfigure syslogd. > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From dtucker at zip.com.au Wed Feb 8 11:50:29 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 8 Feb 2006 11:50:29 +1100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: References: <20060206110243.GA6756@calimero.vinschen.de> <20060206113818.GA8655@gate.dtucker.net> <20060206124443.GZ15572@calimero.vinschen.de> <20060206134255.GA8481@calimero.vinschen.de> <20060206140644.GB10083@gate.dtucker.net> <20060206181610.GI15572@calimero.vinschen.de> <20060207113233.GB2979@calimero.vinschen.de> <20060208001404.GA25442@gate.dtucker.net> Message-ID: <20060208005029.GA25859@gate.dtucker.net> On Tue, Feb 07, 2006 at 04:34:47PM -0800, Tim Rice wrote: > > Do you have a /dev/log in the privsep chroot? I suspect that Cygwin > > uses some other method for passing its log messages which is why you're > > seeing a difference. > > That's it. I'll see if I can reconfigure syslogd. sshd -De will show it it w/out changing your syslog. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From tim at multitalents.net Wed Feb 8 12:18:42 2006 From: tim at multitalents.net (Tim Rice) Date: Tue, 7 Feb 2006 17:18:42 -0800 (PST) Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060208005029.GA25859@gate.dtucker.net> References: <20060206110243.GA6756@calimero.vinschen.de> <20060206113818.GA8655@gate.dtucker.net> <20060206124443.GZ15572@calimero.vinschen.de> <20060206134255.GA8481@calimero.vinschen.de> <20060206140644.GB10083@gate.dtucker.net> <20060206181610.GI15572@calimero.vinschen.de> <20060207113233.GB2979@calimero.vinschen.de> <20060208001404.GA25442@gate.dtucker.net> <20060208005029.GA25859@gate.dtucker.net> Message-ID: On Wed, 8 Feb 2006, Darren Tucker wrote: > On Tue, Feb 07, 2006 at 04:34:47PM -0800, Tim Rice wrote: > > > Do you have a /dev/log in the privsep chroot? I suspect that Cygwin > > > uses some other method for passing its log messages which is why you're > > > seeing a difference. > > > > That's it. I'll see if I can reconfigure syslogd. > > sshd -De will show it it w/out changing your syslog. The getluid/setluid bits don't work with that but it's just fine for testing. I don't like the monitor.c patch. The loggong will dissapear without jumping through chroot logging hoops. How about this instead? Skip the monitor.c patch and use this. .... --- auth2.c.old 2005-09-29 16:59:21.603708001 -0700 +++ auth2.c 2006-02-07 17:09:36.211231000 -0800 @@ -243,7 +243,9 @@ #endif /* _UNICOS */ /* Log before sending the reply */ +#ifndef DISABLE_FD_PASSING auth_log(authctxt, authenticated, method, " ssh2"); +#endif if (authctxt->postponed) return; .... It should make cygwin happy too. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From dtucker at zip.com.au Wed Feb 8 12:41:21 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 8 Feb 2006 12:41:21 +1100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: References: <20060206124443.GZ15572@calimero.vinschen.de> <20060206134255.GA8481@calimero.vinschen.de> <20060206140644.GB10083@gate.dtucker.net> <20060206181610.GI15572@calimero.vinschen.de> <20060207113233.GB2979@calimero.vinschen.de> <20060208001404.GA25442@gate.dtucker.net> <20060208005029.GA25859@gate.dtucker.net> Message-ID: <20060208014121.GA26280@gate.dtucker.net> On Tue, Feb 07, 2006 at 05:18:42PM -0800, Tim Rice wrote: > I don't like the monitor.c patch. The loggong will dissapear without > jumping through chroot logging hoops. > > How about this instead? > Skip the monitor.c patch and use this. > > --- auth2.c.old 2005-09-29 16:59:21.603708001 -0700 > +++ auth2.c 2006-02-07 17:09:36.211231000 -0800 > @@ -243,7 +243,9 @@ > #endif /* _UNICOS */ > > /* Log before sending the reply */ > +#ifndef DISABLE_FD_PASSING > auth_log(authctxt, authenticated, method, " ssh2"); > +#endif > > if (authctxt->postponed) > return; Won't that not log at all when DISABLE_FD_PASSING is defined and privsep=no? Maybe: #ifndef DISABLE_FD_PASSING if (!use_privsep) #endif auth_log(authctxt, authenticated, method, " ssh2"); It still looks like there's got to be a nicer solution in there somewhere rather than something that's composed almost entirely of corner cases :-) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From tim at multitalents.net Wed Feb 8 13:37:46 2006 From: tim at multitalents.net (Tim Rice) Date: Tue, 7 Feb 2006 18:37:46 -0800 (PST) Subject: OpenSSH_4.3p1 configure patch In-Reply-To: <20060208014121.GA26280@gate.dtucker.net> References: <20060206124443.GZ15572@calimero.vinschen.de> <20060206134255.GA8481@calimero.vinschen.de> <20060206140644.GB10083@gate.dtucker.net> <20060206181610.GI15572@calimero.vinschen.de> <20060207113233.GB2979@calimero.vinschen.de> <20060208001404.GA25442@gate.dtucker.net> <20060208005029.GA25859@gate.dtucker.net> <20060208014121.GA26280@gate.dtucker.net> Message-ID: On Wed, 8 Feb 2006, Darren Tucker wrote: > On Tue, Feb 07, 2006 at 05:18:42PM -0800, Tim Rice wrote: > > I don't like the monitor.c patch. The loggong will dissapear without > > jumping through chroot logging hoops. > > > > How about this instead? > > Skip the monitor.c patch and use this. > > > > --- auth2.c.old 2005-09-29 16:59:21.603708001 -0700 > > +++ auth2.c 2006-02-07 17:09:36.211231000 -0800 > > @@ -243,7 +243,9 @@ > > #endif /* _UNICOS */ > > > > /* Log before sending the reply */ > > +#ifndef DISABLE_FD_PASSING > > auth_log(authctxt, authenticated, method, " ssh2"); > > +#endif > > > > if (authctxt->postponed) > > return; > > Won't that not log at all when DISABLE_FD_PASSING is defined and > privsep=no? Maybe: Hmm, I hadn't considered privsep=no. After all, with DISABLE_FD_PASSING, it's only preauth privsep. > > #ifndef DISABLE_FD_PASSING > if (!use_privsep) > #endif s/#ifndef/#ifdef/ Yes, that works. > auth_log(authctxt, authenticated, method, " ssh2"); > > It still looks like there's got to be a nicer solution in there somewhere > rather than something that's composed almost entirely of corner cases :-) I'm happy to leave this one until after p2. > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From vinschen at redhat.com Wed Feb 8 20:45:24 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 8 Feb 2006 10:45:24 +0100 Subject: OpenSSH_4.3p1 configure patch In-Reply-To: References: <20060206140644.GB10083@gate.dtucker.net> <20060206181610.GI15572@calimero.vinschen.de> <20060207113233.GB2979@calimero.vinschen.de> <20060208001404.GA25442@gate.dtucker.net> <20060208005029.GA25859@gate.dtucker.net> <20060208014121.GA26280@gate.dtucker.net> Message-ID: <20060208094524.GM2979@calimero.vinschen.de> On Feb 7 18:37, Tim Rice wrote: > On Wed, 8 Feb 2006, Darren Tucker wrote: > > #ifndef DISABLE_FD_PASSING > > if (!use_privsep) > > #endif > > s/#ifndef/#ifdef/ Yes, that works. Works fine on Cygwin. Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vinschen at redhat.com Wed Feb 8 20:45:42 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 8 Feb 2006 10:45:42 +0100 Subject: session.c Was: Re: OpenSSH_4.3p1 configure patch In-Reply-To: References: <20060204224115.GO15572@calimero.vinschen.de> <20060206110243.GA6756@calimero.vinschen.de> <20060206113818.GA8655@gate.dtucker.net> <20060206124443.GZ15572@calimero.vinschen.de> <20060206134255.GA8481@calimero.vinschen.de> <20060206140644.GB10083@gate.dtucker.net> <20060207131745.GD2979@calimero.vinschen.de> Message-ID: <20060208094542.GN2979@calimero.vinschen.de> On Feb 7 15:29, Tim Rice wrote: > On Tue, 7 Feb 2006, Corinna Vinschen wrote: > > I'm not *quite* sure if I analyzed that correctly, but AFAICS, it should > > have no effect on the situation solved by the patch from 2005/11/05: > > > > - session_exit_message is a static function which is exclusively called > > by session_close_by_pid. > > > > - In session_exit_message, following the setting of s->pid to 0 are only > > two calls, channel_register_cleanup and chan_write_failed. > > > > - channel_register_cleanup only marks session_close_by_channel to be run > > for the channel on cleanup, but it does not run this function immediately, > > nor does it itself depend on the setting of s->pid. > > > > - chan_write_failed does also not depend on the setting of s->pid. > > > > - On return from session_exit_message to session_close_by_pid, > > session_pty_cleanup is called with correct s->pid setting. > > > > - s->pid is set to 0. > > > > - In a later cleanup, session_close_by_channel is called and s->pid has > > the expected value of 0. > > > > Did I miss something? > > > > It doesn't look like it to me. (and tests good here) > I've commited your patch. Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From dtucker at zip.com.au Thu Feb 9 00:00:17 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 9 Feb 2006 00:00:17 +1100 Subject: 4.3p2: call for testing Message-ID: <20060208130017.GA3187@gate.dtucker.net> Hi all. As most folks on this list will know, OpenSSH 4.3p1 had some problems with login recording under some configurations. This has been resolved in the current tree and we are looking at rolling a 4.3p2 release to address them. For the most part the changes are fixes only; the ChangeLog since 4.3p1 is below in its entirety. There's one other change that is currently still not decided, which is the double-logging of logins on platforms that do not do descriptor passing. Snapshots can be found at ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/ Test reports (20060208 or later preferred) would be appreciated. Thanks. 20060208 - (tim) [session.c] Logout records were not updated on systems with post auth privsep disabled due to bug 1086 changes. Analysis and patch by vinschen at redhat.com. OK tim@, dtucker at . - (dtucker) [configure.ac] Typo in Ultrix and NewsOS sections (NEED_SETPRGP -> NEED_SETPGRP), reported by Berhard Simon. ok tim@ 20060206 - (tim) [configure.ac] Remove unnecessary tests for net/if.h and netinet/in_systm.h. OK dtucker at . 20060205 - (tim) [configure.ac] Add AC_REVISION. Add sys/time.h to lastlog.h test for Solaris. OK dtucker at . - (tim) [configure.ac] Bug #1149. Changes in QNX section only. Patch by kraai at ftbfs.org. 20060203 - (tim) [configure.ac] test for egrep (AC_PROG_EGREP) before first AC_CHECK_HEADERS test. Without it, if AC_CHECK_HEADERS is first run by a platform specific check, builtin standard includes tests will be skipped on the other platforms. Analysis and suggestion by vinschen at redhat.com, patch by dtucker at . OK tim@, djm at . 20060202 - (dtucker) [configure.ac] Bug #1148: Fix "crippled AES" test so that it works with picky compilers. Patch from alex.kiernan at thus.net. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Thu Feb 9 00:25:36 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 8 Feb 2006 14:25:36 +0100 Subject: 4.3p2: call for testing In-Reply-To: <20060208130017.GA3187@gate.dtucker.net> References: <20060208130017.GA3187@gate.dtucker.net> Message-ID: <20060208132536.GO2979@calimero.vinschen.de> Hi Darren, On Feb 9 00:00, Darren Tucker wrote: > 20060208 > - (tim) [session.c] Logout records were not updated on systems with > post auth privsep disabled due to bug 1086 changes. Analysis and patch > by vinschen at redhat.com. OK tim@, dtucker at . > - (dtucker) [configure.ac] Typo in Ultrix and NewsOS sections (NEED_SETPRGP > -> NEED_SETPGRP), reported by Berhard Simon. ok tim@ > > 20060206 > - (tim) [configure.ac] Remove unnecessary tests for net/if.h and > netinet/in_systm.h. OK dtucker at . > > 20060205 > - (tim) [configure.ac] Add AC_REVISION. Add sys/time.h to lastlog.h test > for Solaris. OK dtucker at . > - (tim) [configure.ac] Bug #1149. Changes in QNX section only. Patch by > kraai at ftbfs.org. > > 20060203 > - (tim) [configure.ac] test for egrep (AC_PROG_EGREP) before first > AC_CHECK_HEADERS test. Without it, if AC_CHECK_HEADERS is first run > by a platform specific check, builtin standard includes tests will be > skipped on the other platforms. > Analysis and suggestion by vinschen at redhat.com, patch by dtucker at . > OK tim@, djm at . > > 20060202 > - (dtucker) [configure.ac] Bug #1148: Fix "crippled AES" test so that it > works with picky compilers. Patch from alex.kiernan at thus.net. did the patch in http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=113922524601646&w=2 just slip through or is it not going to be in 4.3p2? It's just silencing the compiler, so I guess it's not overly important, right? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From jalang at andrew.cmu.edu Thu Feb 9 01:33:28 2006 From: jalang at andrew.cmu.edu (J. Alex Lang) Date: Wed, 8 Feb 2006 09:33:28 -0500 Subject: Commit process, etc Message-ID: <00be01c62cbc$a128fe90$6401a8c0@bokeh> Hi folks: I'm making some local additions to sftp-server.c to add an event handler for the different SFTP transactions (e.g. process_open). This is in support of our web publishing system which uses LDAP to enforce file and directory permissions (we've done this to decouple permissioning from the underlying file system). Anyway, this is my first open-source project of this nature; and I'd like to know if there are URL's/FAQ's out there to help me answer the following: - How would I determine if there's interest in commiting these changes? - If there's interest, what is the process? - If there's interest, is this mailing list the right place to discuss technical aspects of these changes? (For example, if there's a chance that these changes could be committed I would want to ensure that my changes are as much in the spirit of the original code as possible) Thanks for allowing the newbie questions. Best, -Alex J. Alex Lang Web Systems Engineer - Application & Web Services Carnegie Mellon University 5000 Forbes Avenue, Cyert Hall 263 Pittsburgh, PA 15213-3890 (412) 268-9854 Office From dtucker at zip.com.au Thu Feb 9 06:45:18 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 09 Feb 2006 06:45:18 +1100 Subject: 4.3p2: call for testing In-Reply-To: <20060208132536.GO2979@calimero.vinschen.de> References: <20060208130017.GA3187@gate.dtucker.net> <20060208132536.GO2979@calimero.vinschen.de> Message-ID: <43EA4A4E.8050907@zip.com.au> Corinna Vinschen wrote: > did the patch in > > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=113922524601646&w=2 > > just slip through or is it not going to be in 4.3p2? It's just silencing > the compiler, so I guess it's not overly important, right? I still have it in a local tree but it's not in 4.3p2. I was going to commit it to HEAD after the 4.3p2 release. -- 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 markzimm at frii.com Thu Feb 9 09:43:15 2006 From: markzimm at frii.com (Mark Zimmerman) Date: Wed, 8 Feb 2006 15:43:15 -0700 Subject: Warnings from openssh-4.3p1 configure Message-ID: <20060208224315.GA67771@io.frii.com> Greetings: On a Sun Solaris 8 machine using the Sun Studio 11 compiler: taz$ ./configure LDFLAGS=-xarch=v9 CFLAGS='-xO3 -xarch=v9' CC=/opt/SUNWspro/bin/cc --prefix=/opt/openssh-4.3p1 --with-ssl-dir=/opt/openssl-0.9.8a --with-xauth=/usr/openwin/bin/xauth --with-default-path=/bin:/sbin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/openwin/bin:/usr/dt/bin --without-zlib-version-check checking ndir.h usability... no checking ndir.h presence... no checking for ndir.h... no checking net/if.h usability... no checking net/if.h presence... yes configure: WARNING: net/if.h: present but cannot be compiled configure: WARNING: net/if.h: check for missing prerequisite headers? configure: WARNING: net/if.h: see the Autoconf documentation configure: WARNING: net/if.h: section "Present But Cannot Be Compiled" configure: WARNING: net/if.h: proceeding with the preprocessor's result configure: WARNING: net/if.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## checking for net/if.h... yes checking netdb.h usability... yes checking netdb.h presence... yes checking for netdb.h... yes checking netgroup.h usability... no checking netgroup.h presence... no checking for netgroup.h... no checking netinet/in_systm.h usability... no checking netinet/in_systm.h presence... yes configure: WARNING: netinet/in_systm.h: present but cannot be compiled configure: WARNING: netinet/in_systm.h: check for missing prerequisite headers? configure: WARNING: netinet/in_systm.h: see the Autoconf documentation configure: WARNING: netinet/in_systm.h: section "Present But Cannot Be Compiled" configure: WARNING: netinet/in_systm.h: proceeding with the preprocessor's result configure: WARNING: netinet/in_systm.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## checking for netinet/in_systm.h... yes checking pam/pam_appl.h usability... no checking pam/pam_appl.h presence... no checking for pam/pam_appl.h... no checking paths.h usability... no checking paths.h presence... no checking for paths.h... no checking pty.h usability... no From tim at multitalents.net Thu Feb 9 11:20:03 2006 From: tim at multitalents.net (Tim Rice) Date: Wed, 8 Feb 2006 16:20:03 -0800 (PST) Subject: Warnings from openssh-4.3p1 configure In-Reply-To: <20060208224315.GA67771@io.frii.com> References: <20060208224315.GA67771@io.frii.com> Message-ID: On Wed, 8 Feb 2006, Mark Zimmerman wrote: > Greetings: > > On a Sun Solaris 8 machine using the Sun Studio 11 compiler: > [snip] > configure: WARNING: net/if.h: present but cannot be compiled > configure: WARNING: net/if.h: check for missing prerequisite [snip] > configure: WARNING: netinet/in_systm.h: present but cannot be compiled > configure: WARNING: netinet/in_systm.h: check for missing Fixed in CVS. Please try the latest snapshot. Snapshots can be found at ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/ -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tryponraj at gmail.com Thu Feb 9 16:20:46 2006 From: tryponraj at gmail.com (ponraj) Date: Thu, 9 Feb 2006 10:50:46 +0530 Subject: 4.3p2: call for testing References: <20060208130017.GA3187@gate.dtucker.net> Message-ID: <008e01c62d38$eb88fe00$180110ac@pomco> Build and regression tests pass for HP-UX 11.11 and 11.23. -- M.P ----- Original Message ----- From: "Darren Tucker" To: Sent: Wednesday, February 08, 2006 6:30 PM Subject: 4.3p2: call for testing > Hi all. > > As most folks on this list will know, OpenSSH 4.3p1 had some problems > with login recording under some configurations. This has been resolved > in the current tree and we are looking at rolling a 4.3p2 release > to address them. For the most part the changes are fixes only; the > ChangeLog since 4.3p1 is below in its entirety. > > There's one other change that is currently still not decided, which is > the double-logging of logins on platforms that do not do descriptor > passing. > > Snapshots can be found at > ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/ > > Test reports (20060208 or later preferred) would be appreciated. > > Thanks. > > 20060208 > - (tim) [session.c] Logout records were not updated on systems with > post auth privsep disabled due to bug 1086 changes. Analysis and patch > by vinschen at redhat.com. OK tim@, dtucker at . > - (dtucker) [configure.ac] Typo in Ultrix and NewsOS sections > (NEED_SETPRGP > -> NEED_SETPGRP), reported by Berhard Simon. ok tim@ > > 20060206 > - (tim) [configure.ac] Remove unnecessary tests for net/if.h and > netinet/in_systm.h. OK dtucker at . > > 20060205 > - (tim) [configure.ac] Add AC_REVISION. Add sys/time.h to lastlog.h test > for Solaris. OK dtucker at . > - (tim) [configure.ac] Bug #1149. Changes in QNX section only. Patch by > kraai at ftbfs.org. > > 20060203 > - (tim) [configure.ac] test for egrep (AC_PROG_EGREP) before first > AC_CHECK_HEADERS test. Without it, if AC_CHECK_HEADERS is first run > by a platform specific check, builtin standard includes tests will be > skipped on the other platforms. > Analysis and suggestion by vinschen at redhat.com, patch by dtucker at . > OK tim@, djm at . > > 20060202 > - (dtucker) [configure.ac] Bug #1148: Fix "crippled AES" test so that it > works with picky compilers. Patch from alex.kiernan at thus.net. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From bsteensr at csc.com Thu Feb 9 21:15:55 2006 From: bsteensr at csc.com (Bjorn Steensrud) Date: Thu, 9 Feb 2006 11:15:55 +0100 Subject: 4.3p2: call for testing Message-ID: SLES 9.0 - snapshot 20060208 passes all tests. Bj?rn Steensrud ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- From vinschen at redhat.com Thu Feb 9 21:29:49 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 9 Feb 2006 11:29:49 +0100 Subject: 4.3p2: call for testing In-Reply-To: <20060208130017.GA3187@gate.dtucker.net> References: <20060208130017.GA3187@gate.dtucker.net> Message-ID: <20060209102949.GD14219@calimero.vinschen.de> On Feb 9 00:00, Darren Tucker wrote: > Hi all. > > As most folks on this list will know, OpenSSH 4.3p1 had some problems > with login recording under some configurations. This has been resolved > in the current tree and we are looking at rolling a 4.3p2 release > to address them. For the most part the changes are fixes only; the > ChangeLog since 4.3p1 is below in its entirety. > > There's one other change that is currently still not decided, which is > the double-logging of logins on platforms that do not do descriptor > passing. > > Snapshots can be found at > ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/ > > Test reports (20060208 or later preferred) would be appreciated. > > Thanks. > > 20060208 > - (tim) [session.c] Logout records were not updated on systems with > post auth privsep disabled due to bug 1086 changes. Analysis and patch > by vinschen at redhat.com. OK tim@, dtucker at . > - (dtucker) [configure.ac] Typo in Ultrix and NewsOS sections (NEED_SETPRGP > -> NEED_SETPGRP), reported by Berhard Simon. ok tim@ The 20060208 snapshot does not contain these patches. I guess there will be a 20060209 snapshot before releasing 4.3p2? Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From svallet at genoscope.cns.fr Thu Feb 9 22:25:52 2006 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Thu, 9 Feb 2006 12:25:52 +0100 Subject: 4.3p2: call for testing In-Reply-To: <20060208130017.GA3187@gate.dtucker.net> References: <20060208130017.GA3187@gate.dtucker.net> Message-ID: <20060209122552.0024d526.svallet@genoscope.cns.fr> On Thu, 9 Feb 2006 00:00:17 +1100 Darren Tucker wrote: > Snapshots can be found at > ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/ 20060208 passes all tests on Tru64 5.1A Simon From dtucker at zip.com.au Thu Feb 9 22:52:44 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 9 Feb 2006 22:52:44 +1100 Subject: 4.3p2: call for testing In-Reply-To: <20060209102949.GD14219@calimero.vinschen.de> References: <20060208130017.GA3187@gate.dtucker.net> <20060209102949.GD14219@calimero.vinschen.de> Message-ID: <20060209115244.GA13607@gate.dtucker.net> On Thu, Feb 09, 2006 at 11:29:49AM +0100, Corinna Vinschen wrote: [snip ChangeLog] > The 20060208 snapshot does not contain these patches. I guess there will > be a 20060209 snapshot before releasing 4.3p2? Hmm, not sure what's going on there, but I think there might be a missing 20060209 snap? In case that's true, I've put up an unofficial snap here: http://www.zip.com.au/~dtucker/tmp/openssh-snap-20060209dt.tar.gz It's actually from the 4.3 branch, but that's currently identical to -HEAD with the exception of a couple of cvsids. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Fri Feb 10 00:23:02 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 9 Feb 2006 14:23:02 +0100 Subject: 4.3p2: call for testing In-Reply-To: <20060209115244.GA13607@gate.dtucker.net> References: <20060208130017.GA3187@gate.dtucker.net> <20060209102949.GD14219@calimero.vinschen.de> <20060209115244.GA13607@gate.dtucker.net> Message-ID: <20060209132302.GF14219@calimero.vinschen.de> On Feb 9 22:52, Darren Tucker wrote: > On Thu, Feb 09, 2006 at 11:29:49AM +0100, Corinna Vinschen wrote: > [snip ChangeLog] > > The 20060208 snapshot does not contain these patches. I guess there will > > be a 20060209 snapshot before releasing 4.3p2? > > Hmm, not sure what's going on there, but I think there might be a missing > 20060209 snap? > > In case that's true, I've put up an unofficial snap here: > http://www.zip.com.au/~dtucker/tmp/openssh-snap-20060209dt.tar.gz > > It's actually from the 4.3 branch, but that's currently identical to > -HEAD with the exception of a couple of cvsids. Thank you! I've successfully built and tested your snapshot on Cygwin. Syslogging works fine. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From tim at multitalents.net Fri Feb 10 03:58:32 2006 From: tim at multitalents.net (Tim Rice) Date: Thu, 9 Feb 2006 08:58:32 -0800 (PST) Subject: 4.3p2: call for testing In-Reply-To: <20060209132302.GF14219@calimero.vinschen.de> References: <20060208130017.GA3187@gate.dtucker.net> <20060209102949.GD14219@calimero.vinschen.de> <20060209115244.GA13607@gate.dtucker.net> <20060209132302.GF14219@calimero.vinschen.de> Message-ID: On Thu, 9 Feb 2006, Corinna Vinschen wrote: > On Feb 9 22:52, Darren Tucker wrote: > > In case that's true, I've put up an unofficial snap here: > > http://www.zip.com.au/~dtucker/tmp/openssh-snap-20060209dt.tar.gz > > > > It's actually from the 4.3 branch, but that's currently identical to > > -HEAD with the exception of a couple of cvsids. > > Thank you! I've successfully built and tested your snapshot on Cygwin. > Syslogging works fine. Are you saying you are not getting the double logging with the snapshot? > > Corinna > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From vinschen at redhat.com Fri Feb 10 04:08:33 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 9 Feb 2006 18:08:33 +0100 Subject: 4.3p2: call for testing In-Reply-To: References: <20060208130017.GA3187@gate.dtucker.net> <20060209102949.GD14219@calimero.vinschen.de> <20060209115244.GA13607@gate.dtucker.net> <20060209132302.GF14219@calimero.vinschen.de> Message-ID: <20060209170833.GI14219@calimero.vinschen.de> On Feb 9 08:58, Tim Rice wrote: > On Thu, 9 Feb 2006, Corinna Vinschen wrote: > > > On Feb 9 22:52, Darren Tucker wrote: > > > In case that's true, I've put up an unofficial snap here: > > > http://www.zip.com.au/~dtucker/tmp/openssh-snap-20060209dt.tar.gz > > > > > > It's actually from the 4.3 branch, but that's currently identical to > > > -HEAD with the exception of a couple of cvsids. > > > > Thank you! I've successfully built and tested your snapshot on Cygwin. > > Syslogging works fine. > > Are you saying you are not getting the double logging with the snapshot? Urgh! No, I failed to look for the double logging problem. The snapshot does not contain the patch to auth2.c and so does still log twice when privilege separation is used. Sorry for missing that :-( Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From tim at multitalents.net Fri Feb 10 04:20:40 2006 From: tim at multitalents.net (Tim Rice) Date: Thu, 9 Feb 2006 09:20:40 -0800 (PST) Subject: 4.3p2: call for testing In-Reply-To: <20060209170833.GI14219@calimero.vinschen.de> References: <20060208130017.GA3187@gate.dtucker.net> <20060209102949.GD14219@calimero.vinschen.de> <20060209115244.GA13607@gate.dtucker.net> <20060209132302.GF14219@calimero.vinschen.de> <20060209170833.GI14219@calimero.vinschen.de> Message-ID: On Thu, 9 Feb 2006, Corinna Vinschen wrote: > On Feb 9 08:58, Tim Rice wrote: > > On Thu, 9 Feb 2006, Corinna Vinschen wrote: > > > > > Thank you! I've successfully built and tested your snapshot on Cygwin. > > > Syslogging works fine. > > > > Are you saying you are not getting the double logging with the snapshot? > > Urgh! No, I failed to look for the double logging problem. The snapshot > does not contain the patch to auth2.c and so does still log twice when > privilege separation is used. > > > Sorry for missing that :-( Thanks, I was confused there for a while. I knew we hadn't commited the auth2.c patch. > > > Corinna > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From rapier at psc.edu Fri Feb 10 06:02:14 2006 From: rapier at psc.edu (Chris Rapier) Date: Thu, 09 Feb 2006 14:02:14 -0500 Subject: 4.3p2: call for testing In-Reply-To: <20060208130017.GA3187@gate.dtucker.net> References: <20060208130017.GA3187@gate.dtucker.net> Message-ID: <43EB91B6.8000106@psc.edu> Once I got the right version of OpenSSL (specifically the patched version for OS X /Darwin) everything configure, compiled, and tested without a problem. From tim at multitalents.net Fri Feb 10 15:08:00 2006 From: tim at multitalents.net (Tim Rice) Date: Thu, 9 Feb 2006 20:08:00 -0800 (PST) Subject: Warnings from openssh-4.3p1 configure In-Reply-To: <20060209224443.GA44344@io.frii.com> References: <20060209180712.GA33031@io.frii.com> <20060209224443.GA44344@io.frii.com> Message-ID: On Thu, 9 Feb 2006, Mark Zimmerman wrote: > On Thu, Feb 09, 2006 at 02:00:21PM -0800, Tim Rice wrote: > > On Thu, 9 Feb 2006, Mark Zimmerman wrote: > > > > > Greetings: > > > > > > Well, I tried the latest snapshot and it configures without warnings > > > and it compiles, but it doesn't work... > > > > Very suprising. > > Do a diff in the 2 config.h files and send it to me. > > What platform is this? > > foghorn$ uname -a > SunOS cswfsu01 5.8 Generic_117350-31 sun4u sparc SUNW,Sun-Fire-V440 > > > foghorn$ diff openssh-4.3p1/config.h openssh/config.h [diff sniped] Looks right. > > > foghorn$ ./ssh gaim > > > Disconnecting: Bad packet length 1423594411. > > > foghorn$ ./ssh -V > > > OpenSSH_4.3p1-snap20060208, OpenSSL 0.9.8a 11 Oct 2005 Try the 20060210 snap. That's what's in CVS. It's working fine here. SunOS sun2 5.8 Generic_117350-31 sun4u sparc SUNW,Ultra-2 But then I'm using openssl 0.9.7 [hours pass, more building/testing] I just built a current 0.9.8 and tested again. regression tests fail. Hmm. Tests OK with 0.9.8 on my UnixWare box. I'll do more testing as time permits. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From william at 25thandClement.com Fri Feb 10 14:56:26 2006 From: william at 25thandClement.com (William Ahern) Date: Thu, 9 Feb 2006 19:56:26 -0800 Subject: OpenSSH ControlAllowUsers, et al Patch Message-ID: <20060210035625.GA21525@orville.25thandClement.com> Attached (and inline) is a patch to add the following config options: ControlBindMask ControlAllowUsers ControlAllowGroups ControlDenyUsers ControlDenyGroups It pulls the peer credential check from client_process_control() in ssh.c, and expounds upon it in a new function, client_control_grant(). Supplemental groups are not checked in this patch. I didn't feel comfortable taking a shot at defining the semantics of how supplemental groups would work. groupaccess.c probably has all the code necessary to employ supplemental group checking. The patch includes documentation additions, as well. The diff is against Portable OpenSSH 4.2. That's what we have in our tree at the moment. Please send any corrections or complaints my way and I'll refactor the patch as necessary (e.g. if the patch doesn't apply to 4.3 or against OpenBSD trunk). For posterity, let it be known that this work was funded by Barracuda Networks, Inc. - Bill Index: scp.0 =================================================================== --- scp.0 (revision 15802) +++ scp.0 (revision 15803) @@ -70,6 +70,11 @@ ConnectTimeout ControlMaster ControlPath + ControlBindMask + ControlAllowUsers + ControlAllowGroups + ControlDenyUsers + ControlDenyGroups GlobalKnownHostsFile GSSAPIAuthentication GSSAPIDelegateCredentials Index: scp.1 =================================================================== --- scp.1 (revision 15802) +++ scp.1 (revision 15803) @@ -130,6 +130,11 @@ .It ConnectTimeout .It ControlMaster .It ControlPath +.It ControlBindMask +.It ControlAllowUsers +.It ControlAllowGroups +.It ControlDenyUsers +.It ControlDenyGroups .It GlobalKnownHostsFile .It GSSAPIAuthentication .It GSSAPIDelegateCredentials Index: ssh.0 =================================================================== --- ssh.0 (revision 15802) +++ ssh.0 (revision 15803) @@ -392,6 +392,11 @@ ConnectTimeout ControlMaster ControlPath + ControlBindMask + ControlAllowUsers + ControlAllowGroups + ControlDenyUsers + ControlDenyGroups DynamicForward EscapeChar ForwardAgent Index: ssh.1 =================================================================== --- ssh.1 (revision 15802) +++ ssh.1 (revision 15803) @@ -691,6 +691,11 @@ .It ConnectTimeout .It ControlMaster .It ControlPath +.It ControlBindMask +.It ControlAllowUsers +.It ControlAllowGroups +.It ControlDenyUsers +.It ControlDenyGroups .It DynamicForward .It EscapeChar .It ForwardAgent Index: sftp.0 =================================================================== --- sftp.0 (revision 15802) +++ sftp.0 (revision 15803) @@ -74,6 +74,11 @@ ConnectTimeout ControlMaster ControlPath + ControlBindMask + ControlAllowUsers + ControlAllowGroups + ControlDenyUsers + ControlDenyGroups GlobalKnownHostsFile GSSAPIAuthentication GSSAPIDelegateCredentials Index: sftp.1 =================================================================== --- sftp.1 (revision 15802) +++ sftp.1 (revision 15803) @@ -158,6 +158,11 @@ .It ConnectTimeout .It ControlMaster .It ControlPath +.It ControlBindMask +.It ControlAllowUsers +.It ControlAllowGroups +.It ControlDenyUsers +.It ControlDenyGroups .It GlobalKnownHostsFile .It GSSAPIAuthentication .It GSSAPIDelegateCredentials Index: ssh.c =================================================================== --- ssh.c (revision 15802) +++ ssh.c (revision 15803) @@ -1012,7 +1012,7 @@ if ((control_fd = socket(PF_UNIX, SOCK_STREAM, 0)) < 0) fatal("%s socket(): %s\n", __func__, strerror(errno)); - old_umask = umask(0177); + old_umask = umask(options.control_bind_mask); if (bind(control_fd, (struct sockaddr*)&addr, addr_len) == -1) { control_fd = -1; if (errno == EINVAL || errno == EADDRINUSE) Index: clientloop.c =================================================================== --- clientloop.c (revision 15802) +++ clientloop.c (revision 15803) @@ -675,6 +675,84 @@ xfree(cctx); } + +static int +client_control_grant(int client_fd) +{ + struct passwd *epw = 0; + struct group *egr = 0; + char euidstr[48]; /* Sufficient for 2^128 in decimal ascii */ + char egidstr[48]; /* Sufficient for 2^128 in decimal ascii */ + uid_t euid; + gid_t egid; + u_int i; + + if (getpeereid(client_fd, &euid, &egid) < 0) { + error("%s getpeereid failed: %s", __func__, strerror(errno)); + return -1; + } + + if ((euid == 0) || (getuid() == euid)) + return 1; /* Short circuit. */ + + if ((int)sizeof euidstr <= snprintf(euidstr, sizeof euidstr, "%lu", (u_long)euid)) { + error("%s uid too high", __func__); + return -1; + } + + if ((int)sizeof egidstr <= snprintf(egidstr, sizeof egidstr, "%lu", (u_long)egid)) { + error("%s gid too high", __func__); + return -1; + } + + if ((options.num_control_allow_users || options.num_control_deny_users) + && !(epw = getpwuid(euid))) { + error("%s getpwuid failed: %s", __func__, strerror(errno)); + return -1; /* Fail, otherwise we might miss a deny pattern. */ + } + + if ((options.num_control_allow_groups || options.num_control_deny_groups) + && !(egr = getgrgid(euid))) { + error("%s getgrgid failed: %s", __func__, strerror(errno)); + return -1; /* Fail, otherwise we might miss a deny pattern. */ + } + + for (i = 0; i < options.num_control_deny_users; i++) { + if (match_pattern(euidstr,options.control_deny_users[i]) + || (epw && match_pattern(epw->pw_name,options.control_deny_users[i]))) { + error("%s control mode uid denied: %s", __func__, options.control_deny_users[i]); + return 0; + } + } + + for (i = 0; i < options.num_control_deny_groups; i++) { + if (match_pattern(egidstr,options.control_deny_groups[i]) + || (egr && match_pattern(egr->gr_name,options.control_deny_groups[i]))) { + error("%s control mode gid denied: %s", __func__, options.control_deny_groups[i]); + return 0; + } + } + + for (i = 0; i < options.num_control_allow_users; i++) { + if (match_pattern(euidstr,options.control_allow_users[i]) + || (epw && match_pattern(epw->pw_name,options.control_allow_users[i]))) { + return 1; + } + } + + for (i = 0; i < options.num_control_allow_groups; i++) { + if (match_pattern(egidstr,options.control_allow_groups[i]) + || (egr && match_pattern(egr->gr_name,options.control_allow_groups[i]))) { + return 1; + } + } + + error("%s control mode uid/gid denied: %s/%s", __func__, euidstr, egidstr); + + return 0; /* Deny by default. */ +} + + static void client_process_control(fd_set * readset) { @@ -686,8 +764,6 @@ struct confirm_ctx *cctx; char *cmd; u_int i, len, env_len, command, flags; - uid_t euid; - gid_t egid; /* * Accept connection on control socket @@ -703,16 +779,21 @@ return; } - if (getpeereid(client_fd, &euid, &egid) < 0) { - error("%s getpeereid failed: %s", __func__, strerror(errno)); + switch(client_control_grant(client_fd)) { + case 1: /* ALLOWED */ + break; + case 0: /* DENIED */ + error("control access denied!"); close(client_fd); return; - } - if ((euid != 0) && (getuid() != euid)) { - error("control mode uid mismatch: peer euid %u != uid %u", - (u_int) euid, (u_int) getuid()); + case -1: /* SYSERR! */ + error("error granting access"); close(client_fd); return; + default: /* OOPS! */ + error("unknown error granting access"); + close(client_fd); + return; } unset_nonblock(client_fd); Index: readconf.c =================================================================== --- readconf.c (revision 15802) +++ readconf.c (revision 15803) @@ -106,8 +106,9 @@ oEnableSSHKeysign, oRekeyLimit, oVerifyHostKeyDNS, oConnectTimeout, oAddressFamily, oGssAuthentication, oGssDelegateCreds, oServerAliveInterval, oServerAliveCountMax, oIdentitiesOnly, - oSendEnv, oControlPath, oControlMaster, oHashKnownHosts, - oDeprecated, oUnsupported + oSendEnv, oControlBindMask, oControlPath, oControlMaster, + oControlAllowUsers, oControlDenyUsers, oControlAllowGroups, + oControlDenyGroups, oHashKnownHosts, oDeprecated, oUnsupported } OpCodes; /* Textual representations of the tokens. */ @@ -195,8 +196,13 @@ { "serveraliveinterval", oServerAliveInterval }, { "serveralivecountmax", oServerAliveCountMax }, { "sendenv", oSendEnv }, + { "controlbindmask", oControlBindMask }, { "controlpath", oControlPath }, { "controlmaster", oControlMaster }, + { "controlallowusers", oControlAllowUsers }, + { "controldenyusers", oControlDenyUsers }, + { "controlallowgroups", oControlAllowUsers }, + { "controldenygroups", oControlDenyGroups }, { "hashknownhosts", oHashKnownHosts }, { NULL, oBadOption } }; @@ -790,6 +796,17 @@ } break; + case oControlBindMask: + arg = strdelim(&s); + if (!arg || *arg == '\0') + fatal("%.200s line %d: Missing ControlBindMask argument.", + filename, linenum); + value = strtol(arg, &endofnumber, 0); + if (*endofnumber != '\0' || value < 0 || value > 0777) + fatal("%.200s line %d: Bad mask.", filename, linenum); + options->control_bind_mask = value; + break; + case oControlPath: charptr = &options->control_path; goto parse_string; @@ -818,6 +835,46 @@ *intptr = value; break; + case oControlAllowUsers: + while ((arg = strdelim(&s)) && *arg != '\0') { + if (options->num_control_allow_users >= MAX_CONTROL_ALLOW_USERS) + fatal("%s line %d: too many control allow users.", + filename, linenum); + options->control_allow_users[options->num_control_allow_users++] = + xstrdup(arg); + } + break; + + case oControlDenyUsers: + while ((arg = strdelim(&s)) && *arg != '\0') { + if (options->num_control_deny_users >= MAX_CONTROL_DENY_USERS) + fatal("%s line %d: too many control deny users.", + filename, linenum); + options->control_deny_users[options->num_control_deny_users++] = + xstrdup(arg); + } + break; + + case oControlAllowGroups: + while ((arg = strdelim(&s)) && *arg != '\0') { + if (options->num_control_allow_groups >= MAX_CONTROL_ALLOW_GROUPS) + fatal("%s line %d: too many control allow groups.", + filename, linenum); + options->control_allow_groups[options->num_control_allow_groups++] = + xstrdup(arg); + } + break; + + case oControlDenyGroups: + while ((arg = strdelim(&s)) && *arg != '\0') { + if (options->num_control_deny_groups >= MAX_CONTROL_DENY_GROUPS) + fatal("%s line %d: too many control deny groups.", + filename, linenum); + options->control_deny_groups[options->num_control_deny_groups++] = + xstrdup(arg); + } + break; + case oHashKnownHosts: intptr = &options->hash_known_hosts; goto parse_flag; @@ -963,8 +1020,13 @@ options->server_alive_interval = -1; options->server_alive_count_max = -1; options->num_send_env = 0; + options->control_bind_mask = 0177; options->control_path = NULL; options->control_master = -1; + options->num_control_allow_users = 0; + options->num_control_deny_users = 0; + options->num_control_allow_groups = 0; + options->num_control_deny_groups = 0; options->hash_known_hosts = -1; } Index: readconf.h =================================================================== --- readconf.h (revision 15802) +++ readconf.h (revision 15803) @@ -28,8 +28,13 @@ } Forward; /* Data structure for representing option data. */ -#define MAX_SEND_ENV 256 +#define MAX_SEND_ENV 256 +#define MAX_CONTROL_ALLOW_USERS 256 +#define MAX_CONTROL_DENY_USERS 256 +#define MAX_CONTROL_ALLOW_GROUPS 256 +#define MAX_CONTROL_DENY_GROUPS 256 + typedef struct { int forward_agent; /* Forward authentication agent. */ int forward_x11; /* Forward X11 display. */ @@ -110,8 +115,17 @@ int num_send_env; char *send_env[MAX_SEND_ENV]; + mode_t control_bind_mask; char *control_path; int control_master; + u_int num_control_allow_users; + char *control_allow_users[MAX_CONTROL_ALLOW_USERS]; + u_int num_control_deny_users; + char *control_deny_users[MAX_CONTROL_DENY_USERS]; + u_int num_control_allow_groups; + char *control_allow_groups[MAX_CONTROL_ALLOW_GROUPS]; + u_int num_control_deny_groups; + char *control_deny_groups[MAX_CONTROL_ALLOW_USERS]; int hash_known_hosts; } Options; Index: ssh_config.0 =================================================================== --- ssh_config.0 (revision 15802) +++ ssh_config.0 (revision 15803) @@ -158,6 +158,38 @@ three of these escape sequences. This ensures that shared con- nections are uniquely identified. + ControlBindMask + Specify the umask to use when creating/binding the control + socket. + + ControlAllowUsers + Specify a list of uid and/or user name patterns, separated by + spaces. control socket access is granted for non-process owner + users only if the requesting process has an effective uid of 0, + or if the effective uid/user name matches here or the effective + gid/group name matches ControlAllowGroups. + + ControlAllowGroups + Specify a list of gid and/or group name patterns, separated by + spaces. control socket access is granted for non-process owner + users only if the requesting process has an effective uid of 0, + or if the effective gid/group name matches here or the + effective uid/user name matches ControlAllowUsers. + + ControlDenyUsers + Unless the requesting process has an effective uid of 0 or an + effective uid which matches the uid of the control master, + control socket access is denied if the effective uid/user name + matches here or the effective gid/group name matches + ControlDenyGroups. + + ControlDenyGroups + Unless the requesting process has an effective uid of 0 or an + effective uid which matches the uid of the control master, + control socket access is denied if the effective gid/group name + matches here or the effective uid/user name matches + ControlDenyUsers. + DynamicForward Specifies that a TCP/IP port on the local machine be forwarded over the secure channel, and the application protocol is then Index: ssh_config.5 =================================================================== --- ssh_config.5 (revision 15802) +++ ssh_config.5 (revision 15803) @@ -315,6 +315,36 @@ used for opportunistic connection sharing include all three of these escape sequences. This ensures that shared connections are uniquely identified. +.It Cm ControlBindMask +Specify the umask to use when creating/binding the control socket. +.It Cm ControlAllowUsers +Specify a list of uid and/or user name patterns, separated by spaces. +control socket access is granted for non-process owner users only if the +requesting process has an effective uid of 0, or if the effective uid/user +name matches here or the effective gid/group name matches +.Cm ControlAllowGroups +. +.It Cm ControlAllowGroups +Specify a list of gid and/or group name patterns, separated by spaces. +control socket access is granted for non-process owner users only if the +requesting process has an effective uid of 0, or if the effective gid/group +name matches here or the effective uid/user name matches +.Cm ControlAllowUsers +. +.It Cm ControlDenyUsers +Unless the requesting process has an effective uid of 0 or an effective uid +which matches the uid of the control master, control socket access is denied +if the effective uid/user name matches here or the effective gid/group name +matches +.Cm ControlDenyGroups +. +.It Cm ControlDenyGroups +Unless the requesting process has an effective uid of 0 or an effective uid +which matches the uid of the control master, control socket access is denied +if the effective gid/group name matches here or the effective uid/user name +matches +.Cm ControlDenyUsers +. .It Cm DynamicForward Specifies that a TCP/IP port on the local machine be forwarded over the secure channel, and the application -------------- next part -------------- Index: scp.0 =================================================================== --- scp.0 (revision 15802) +++ scp.0 (revision 15803) @@ -70,6 +70,11 @@ ConnectTimeout ControlMaster ControlPath + ControlBindMask + ControlAllowUsers + ControlAllowGroups + ControlDenyUsers + ControlDenyGroups GlobalKnownHostsFile GSSAPIAuthentication GSSAPIDelegateCredentials Index: scp.1 =================================================================== --- scp.1 (revision 15802) +++ scp.1 (revision 15803) @@ -130,6 +130,11 @@ .It ConnectTimeout .It ControlMaster .It ControlPath +.It ControlBindMask +.It ControlAllowUsers +.It ControlAllowGroups +.It ControlDenyUsers +.It ControlDenyGroups .It GlobalKnownHostsFile .It GSSAPIAuthentication .It GSSAPIDelegateCredentials Index: ssh.0 =================================================================== --- ssh.0 (revision 15802) +++ ssh.0 (revision 15803) @@ -392,6 +392,11 @@ ConnectTimeout ControlMaster ControlPath + ControlBindMask + ControlAllowUsers + ControlAllowGroups + ControlDenyUsers + ControlDenyGroups DynamicForward EscapeChar ForwardAgent Index: ssh.1 =================================================================== --- ssh.1 (revision 15802) +++ ssh.1 (revision 15803) @@ -691,6 +691,11 @@ .It ConnectTimeout .It ControlMaster .It ControlPath +.It ControlBindMask +.It ControlAllowUsers +.It ControlAllowGroups +.It ControlDenyUsers +.It ControlDenyGroups .It DynamicForward .It EscapeChar .It ForwardAgent Index: sftp.0 =================================================================== --- sftp.0 (revision 15802) +++ sftp.0 (revision 15803) @@ -74,6 +74,11 @@ ConnectTimeout ControlMaster ControlPath + ControlBindMask + ControlAllowUsers + ControlAllowGroups + ControlDenyUsers + ControlDenyGroups GlobalKnownHostsFile GSSAPIAuthentication GSSAPIDelegateCredentials Index: sftp.1 =================================================================== --- sftp.1 (revision 15802) +++ sftp.1 (revision 15803) @@ -158,6 +158,11 @@ .It ConnectTimeout .It ControlMaster .It ControlPath +.It ControlBindMask +.It ControlAllowUsers +.It ControlAllowGroups +.It ControlDenyUsers +.It ControlDenyGroups .It GlobalKnownHostsFile .It GSSAPIAuthentication .It GSSAPIDelegateCredentials Index: ssh.c =================================================================== --- ssh.c (revision 15802) +++ ssh.c (revision 15803) @@ -1012,7 +1012,7 @@ if ((control_fd = socket(PF_UNIX, SOCK_STREAM, 0)) < 0) fatal("%s socket(): %s\n", __func__, strerror(errno)); - old_umask = umask(0177); + old_umask = umask(options.control_bind_mask); if (bind(control_fd, (struct sockaddr*)&addr, addr_len) == -1) { control_fd = -1; if (errno == EINVAL || errno == EADDRINUSE) Index: clientloop.c =================================================================== --- clientloop.c (revision 15802) +++ clientloop.c (revision 15803) @@ -675,6 +675,84 @@ xfree(cctx); } + +static int +client_control_grant(int client_fd) +{ + struct passwd *epw = 0; + struct group *egr = 0; + char euidstr[48]; /* Sufficient for 2^128 in decimal ascii */ + char egidstr[48]; /* Sufficient for 2^128 in decimal ascii */ + uid_t euid; + gid_t egid; + u_int i; + + if (getpeereid(client_fd, &euid, &egid) < 0) { + error("%s getpeereid failed: %s", __func__, strerror(errno)); + return -1; + } + + if ((euid == 0) || (getuid() == euid)) + return 1; /* Short circuit. */ + + if ((int)sizeof euidstr <= snprintf(euidstr, sizeof euidstr, "%lu", (u_long)euid)) { + error("%s uid too high", __func__); + return -1; + } + + if ((int)sizeof egidstr <= snprintf(egidstr, sizeof egidstr, "%lu", (u_long)egid)) { + error("%s gid too high", __func__); + return -1; + } + + if ((options.num_control_allow_users || options.num_control_deny_users) + && !(epw = getpwuid(euid))) { + error("%s getpwuid failed: %s", __func__, strerror(errno)); + return -1; /* Fail, otherwise we might miss a deny pattern. */ + } + + if ((options.num_control_allow_groups || options.num_control_deny_groups) + && !(egr = getgrgid(euid))) { + error("%s getgrgid failed: %s", __func__, strerror(errno)); + return -1; /* Fail, otherwise we might miss a deny pattern. */ + } + + for (i = 0; i < options.num_control_deny_users; i++) { + if (match_pattern(euidstr,options.control_deny_users[i]) + || (epw && match_pattern(epw->pw_name,options.control_deny_users[i]))) { + error("%s control mode uid denied: %s", __func__, options.control_deny_users[i]); + return 0; + } + } + + for (i = 0; i < options.num_control_deny_groups; i++) { + if (match_pattern(egidstr,options.control_deny_groups[i]) + || (egr && match_pattern(egr->gr_name,options.control_deny_groups[i]))) { + error("%s control mode gid denied: %s", __func__, options.control_deny_groups[i]); + return 0; + } + } + + for (i = 0; i < options.num_control_allow_users; i++) { + if (match_pattern(euidstr,options.control_allow_users[i]) + || (epw && match_pattern(epw->pw_name,options.control_allow_users[i]))) { + return 1; + } + } + + for (i = 0; i < options.num_control_allow_groups; i++) { + if (match_pattern(egidstr,options.control_allow_groups[i]) + || (egr && match_pattern(egr->gr_name,options.control_allow_groups[i]))) { + return 1; + } + } + + error("%s control mode uid/gid denied: %s/%s", __func__, euidstr, egidstr); + + return 0; /* Deny by default. */ +} + + static void client_process_control(fd_set * readset) { @@ -686,8 +764,6 @@ struct confirm_ctx *cctx; char *cmd; u_int i, len, env_len, command, flags; - uid_t euid; - gid_t egid; /* * Accept connection on control socket @@ -703,16 +779,21 @@ return; } - if (getpeereid(client_fd, &euid, &egid) < 0) { - error("%s getpeereid failed: %s", __func__, strerror(errno)); + switch(client_control_grant(client_fd)) { + case 1: /* ALLOWED */ + break; + case 0: /* DENIED */ + error("control access denied!"); close(client_fd); return; - } - if ((euid != 0) && (getuid() != euid)) { - error("control mode uid mismatch: peer euid %u != uid %u", - (u_int) euid, (u_int) getuid()); + case -1: /* SYSERR! */ + error("error granting access"); close(client_fd); return; + default: /* OOPS! */ + error("unknown error granting access"); + close(client_fd); + return; } unset_nonblock(client_fd); Index: readconf.c =================================================================== --- readconf.c (revision 15802) +++ readconf.c (revision 15803) @@ -106,8 +106,9 @@ oEnableSSHKeysign, oRekeyLimit, oVerifyHostKeyDNS, oConnectTimeout, oAddressFamily, oGssAuthentication, oGssDelegateCreds, oServerAliveInterval, oServerAliveCountMax, oIdentitiesOnly, - oSendEnv, oControlPath, oControlMaster, oHashKnownHosts, - oDeprecated, oUnsupported + oSendEnv, oControlBindMask, oControlPath, oControlMaster, + oControlAllowUsers, oControlDenyUsers, oControlAllowGroups, + oControlDenyGroups, oHashKnownHosts, oDeprecated, oUnsupported } OpCodes; /* Textual representations of the tokens. */ @@ -195,8 +196,13 @@ { "serveraliveinterval", oServerAliveInterval }, { "serveralivecountmax", oServerAliveCountMax }, { "sendenv", oSendEnv }, + { "controlbindmask", oControlBindMask }, { "controlpath", oControlPath }, { "controlmaster", oControlMaster }, + { "controlallowusers", oControlAllowUsers }, + { "controldenyusers", oControlDenyUsers }, + { "controlallowgroups", oControlAllowUsers }, + { "controldenygroups", oControlDenyGroups }, { "hashknownhosts", oHashKnownHosts }, { NULL, oBadOption } }; @@ -790,6 +796,17 @@ } break; + case oControlBindMask: + arg = strdelim(&s); + if (!arg || *arg == '\0') + fatal("%.200s line %d: Missing ControlBindMask argument.", + filename, linenum); + value = strtol(arg, &endofnumber, 0); + if (*endofnumber != '\0' || value < 0 || value > 0777) + fatal("%.200s line %d: Bad mask.", filename, linenum); + options->control_bind_mask = value; + break; + case oControlPath: charptr = &options->control_path; goto parse_string; @@ -818,6 +835,46 @@ *intptr = value; break; + case oControlAllowUsers: + while ((arg = strdelim(&s)) && *arg != '\0') { + if (options->num_control_allow_users >= MAX_CONTROL_ALLOW_USERS) + fatal("%s line %d: too many control allow users.", + filename, linenum); + options->control_allow_users[options->num_control_allow_users++] = + xstrdup(arg); + } + break; + + case oControlDenyUsers: + while ((arg = strdelim(&s)) && *arg != '\0') { + if (options->num_control_deny_users >= MAX_CONTROL_DENY_USERS) + fatal("%s line %d: too many control deny users.", + filename, linenum); + options->control_deny_users[options->num_control_deny_users++] = + xstrdup(arg); + } + break; + + case oControlAllowGroups: + while ((arg = strdelim(&s)) && *arg != '\0') { + if (options->num_control_allow_groups >= MAX_CONTROL_ALLOW_GROUPS) + fatal("%s line %d: too many control allow groups.", + filename, linenum); + options->control_allow_groups[options->num_control_allow_groups++] = + xstrdup(arg); + } + break; + + case oControlDenyGroups: + while ((arg = strdelim(&s)) && *arg != '\0') { + if (options->num_control_deny_groups >= MAX_CONTROL_DENY_GROUPS) + fatal("%s line %d: too many control deny groups.", + filename, linenum); + options->control_deny_groups[options->num_control_deny_groups++] = + xstrdup(arg); + } + break; + case oHashKnownHosts: intptr = &options->hash_known_hosts; goto parse_flag; @@ -963,8 +1020,13 @@ options->server_alive_interval = -1; options->server_alive_count_max = -1; options->num_send_env = 0; + options->control_bind_mask = 0177; options->control_path = NULL; options->control_master = -1; + options->num_control_allow_users = 0; + options->num_control_deny_users = 0; + options->num_control_allow_groups = 0; + options->num_control_deny_groups = 0; options->hash_known_hosts = -1; } Index: readconf.h =================================================================== --- readconf.h (revision 15802) +++ readconf.h (revision 15803) @@ -28,8 +28,13 @@ } Forward; /* Data structure for representing option data. */ -#define MAX_SEND_ENV 256 +#define MAX_SEND_ENV 256 +#define MAX_CONTROL_ALLOW_USERS 256 +#define MAX_CONTROL_DENY_USERS 256 +#define MAX_CONTROL_ALLOW_GROUPS 256 +#define MAX_CONTROL_DENY_GROUPS 256 + typedef struct { int forward_agent; /* Forward authentication agent. */ int forward_x11; /* Forward X11 display. */ @@ -110,8 +115,17 @@ int num_send_env; char *send_env[MAX_SEND_ENV]; + mode_t control_bind_mask; char *control_path; int control_master; + u_int num_control_allow_users; + char *control_allow_users[MAX_CONTROL_ALLOW_USERS]; + u_int num_control_deny_users; + char *control_deny_users[MAX_CONTROL_DENY_USERS]; + u_int num_control_allow_groups; + char *control_allow_groups[MAX_CONTROL_ALLOW_GROUPS]; + u_int num_control_deny_groups; + char *control_deny_groups[MAX_CONTROL_ALLOW_USERS]; int hash_known_hosts; } Options; Index: ssh_config.0 =================================================================== --- ssh_config.0 (revision 15802) +++ ssh_config.0 (revision 15803) @@ -158,6 +158,38 @@ three of these escape sequences. This ensures that shared con- nections are uniquely identified. + ControlBindMask + Specify the umask to use when creating/binding the control + socket. + + ControlAllowUsers + Specify a list of uid and/or user name patterns, separated by + spaces. control socket access is granted for non-process owner + users only if the requesting process has an effective uid of 0, + or if the effective uid/user name matches here or the effective + gid/group name matches ControlAllowGroups. + + ControlAllowGroups + Specify a list of gid and/or group name patterns, separated by + spaces. control socket access is granted for non-process owner + users only if the requesting process has an effective uid of 0, + or if the effective gid/group name matches here or the + effective uid/user name matches ControlAllowUsers. + + ControlDenyUsers + Unless the requesting process has an effective uid of 0 or an + effective uid which matches the uid of the control master, + control socket access is denied if the effective uid/user name + matches here or the effective gid/group name matches + ControlDenyGroups. + + ControlDenyGroups + Unless the requesting process has an effective uid of 0 or an + effective uid which matches the uid of the control master, + control socket access is denied if the effective gid/group name + matches here or the effective uid/user name matches + ControlDenyUsers. + DynamicForward Specifies that a TCP/IP port on the local machine be forwarded over the secure channel, and the application protocol is then Index: ssh_config.5 =================================================================== --- ssh_config.5 (revision 15802) +++ ssh_config.5 (revision 15803) @@ -315,6 +315,36 @@ used for opportunistic connection sharing include all three of these escape sequences. This ensures that shared connections are uniquely identified. +.It Cm ControlBindMask +Specify the umask to use when creating/binding the control socket. +.It Cm ControlAllowUsers +Specify a list of uid and/or user name patterns, separated by spaces. +control socket access is granted for non-process owner users only if the +requesting process has an effective uid of 0, or if the effective uid/user +name matches here or the effective gid/group name matches +.Cm ControlAllowGroups +. +.It Cm ControlAllowGroups +Specify a list of gid and/or group name patterns, separated by spaces. +control socket access is granted for non-process owner users only if the +requesting process has an effective uid of 0, or if the effective gid/group +name matches here or the effective uid/user name matches +.Cm ControlAllowUsers +. +.It Cm ControlDenyUsers +Unless the requesting process has an effective uid of 0 or an effective uid +which matches the uid of the control master, control socket access is denied +if the effective uid/user name matches here or the effective gid/group name +matches +.Cm ControlDenyGroups +. +.It Cm ControlDenyGroups +Unless the requesting process has an effective uid of 0 or an effective uid +which matches the uid of the control master, control socket access is denied +if the effective gid/group name matches here or the effective uid/user name +matches +.Cm ControlDenyUsers +. .It Cm DynamicForward Specifies that a TCP/IP port on the local machine be forwarded over the secure channel, and the application From tim at multitalents.net Fri Feb 10 16:00:51 2006 From: tim at multitalents.net (Tim Rice) Date: Thu, 9 Feb 2006 21:00:51 -0800 (PST) Subject: Warnings from openssh-4.3p1 configure In-Reply-To: References: <20060209180712.GA33031@io.frii.com> <20060209224443.GA44344@io.frii.com> Message-ID: On Thu, 9 Feb 2006, Tim Rice wrote: > On Thu, 9 Feb 2006, Mark Zimmerman wrote: > > > On Thu, Feb 09, 2006 at 02:00:21PM -0800, Tim Rice wrote: > > > On Thu, 9 Feb 2006, Mark Zimmerman wrote: > > > > > > > Greetings: > > > > > > > > Well, I tried the latest snapshot and it configures without warnings > > > > and it compiles, but it doesn't work... > > > > > > Very suprising. > > > Do a diff in the 2 config.h files and send it to me. > > > What platform is this? > > > > foghorn$ uname -a > > SunOS cswfsu01 5.8 Generic_117350-31 sun4u sparc SUNW,Sun-Fire-V440 > > > > > > foghorn$ diff openssh-4.3p1/config.h openssh/config.h > [diff sniped] > Looks right. > > > > > foghorn$ ./ssh gaim > > > > Disconnecting: Bad packet length 1423594411. > > > > foghorn$ ./ssh -V > > > > OpenSSH_4.3p1-snap20060208, OpenSSL 0.9.8a 11 Oct 2005 > > Try the 20060210 snap. That's what's in CVS. > > It's working fine here. > SunOS sun2 5.8 Generic_117350-31 sun4u sparc SUNW,Ultra-2 > But then I'm using openssl 0.9.7 > > [hours pass, more building/testing] > I just built a current 0.9.8 and tested again. regression tests fail. > Hmm. > > Tests OK with 0.9.8 on my UnixWare box. > > I'll do more testing as time permits. I may have an idea. I'm guessing that there is a problem with running 2 versions of the openssl shared libs. My Solaris box is seg faulting. .... 27822: getpid() = 27822 [27821] 27822: Incurred fault #6, FLTBOUNDS %pc = 0xFF2328D0 27822: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000014 27822: Received signal #11, SIGSEGV [default] 27822: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000014 27822: *** process killed *** 27828: read(7, 0xFFBEE410, 4) = 0 27828: write(2, " d e b u g 1 : d o _ c".., 20) = 20 27828: _exit(255) .... But my UnixWare 7.1.1 box does not. The Soaris box has a bunch of other shared libs that use the openssl 0.9.7 shared libs. This openssh test run was built with 0.9.8 shared libs. I'm suspecting that this can't work. Anyone have any thoughts on this? Mark, do a truss on the sshd that fails and see what openssl libs it opens. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Fri Feb 10 16:34:26 2006 From: tim at multitalents.net (Tim Rice) Date: Thu, 9 Feb 2006 21:34:26 -0800 (PST) Subject: Warnings from openssh-4.3p1 configure In-Reply-To: References: <20060209180712.GA33031@io.frii.com> <20060209224443.GA44344@io.frii.com> Message-ID: On Thu, 9 Feb 2006, Tim Rice wrote: > On Thu, 9 Feb 2006, Tim Rice wrote: > > > On Thu, 9 Feb 2006, Mark Zimmerman wrote: > > > > > On Thu, Feb 09, 2006 at 02:00:21PM -0800, Tim Rice wrote: > > > > On Thu, 9 Feb 2006, Mark Zimmerman wrote: > > > > > > > > > Greetings: > > > > > > > > > > Well, I tried the latest snapshot and it configures without warnings > > > > > and it compiles, but it doesn't work... > > > > > > > > Very suprising. > > > > Do a diff in the 2 config.h files and send it to me. > > > > What platform is this? > > > > > > foghorn$ uname -a > > > SunOS cswfsu01 5.8 Generic_117350-31 sun4u sparc SUNW,Sun-Fire-V440 > > > > > > > > > foghorn$ diff openssh-4.3p1/config.h openssh/config.h > > [diff sniped] > > Looks right. > > > > > > > foghorn$ ./ssh gaim > > > > > Disconnecting: Bad packet length 1423594411. > > > > > foghorn$ ./ssh -V > > > > > OpenSSH_4.3p1-snap20060208, OpenSSL 0.9.8a 11 Oct 2005 > > > > Try the 20060210 snap. That's what's in CVS. > > > > It's working fine here. > > SunOS sun2 5.8 Generic_117350-31 sun4u sparc SUNW,Ultra-2 > > But then I'm using openssl 0.9.7 > > > > [hours pass, more building/testing] > > I just built a current 0.9.8 and tested again. regression tests fail. > > Hmm. > > > > Tests OK with 0.9.8 on my UnixWare box. > > > > I'll do more testing as time permits. > > I may have an idea. > > I'm guessing that there is a problem with running 2 versions of > the openssl shared libs. My Solaris box is seg faulting. > .... > 27822: getpid() = 27822 [27821] > 27822: Incurred fault #6, FLTBOUNDS %pc = 0xFF2328D0 > 27822: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000014 > 27822: Received signal #11, SIGSEGV [default] > 27822: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000014 > 27822: *** process killed *** > 27828: read(7, 0xFFBEE410, 4) = 0 > 27828: write(2, " d e b u g 1 : d o _ c".., 20) = 20 > 27828: _exit(255) > .... > > But my UnixWare 7.1.1 box does not. > > The Soaris box has a bunch of other shared libs that use the openssl 0.9.7 > shared libs. This openssh test run was built with 0.9.8 shared libs. > > I'm suspecting that this can't work. That was it. If I disabled nss_ldap (that was using openssl 0.9.7 libs), openssh regression tests pass using openssl 0.9.8 > > Anyone have any thoughts on this? > > Mark, do a truss on the sshd that fails and see what openssl libs it > opens. > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From rapier at psc.edu Sat Feb 11 02:27:34 2006 From: rapier at psc.edu (Chris Rapier) Date: Fri, 10 Feb 2006 10:27:34 -0500 Subject: OpenSSH VPN between Mac OS X and OpenBSD In-Reply-To: <3A33485A-EA8C-456B-9798-07CCDC74DF09@jberg.pp.se> References: <3A33485A-EA8C-456B-9798-07CCDC74DF09@jberg.pp.se> Message-ID: <43ECB0E6.6080704@psc.edu> Honestly, I'm probably not the best person to ask this. I really just deal with network performance issues. You should try the OpenSSH development group. I've cc:'d that group on this message. However, a quick look at the code shows that you'd only be getting that warning if both CUSTOM_SYS_TUN_OPEN and SSH_TUN_OPENBSD are not defined. Grep on the first define we find the following in the change log (djm) [misc.c] Disable tunnel code for non-OpenBSD (for now), enable again by providing a sys_tun_open() function for your platform and setting the CUSTOM_SYS_TUN_OPEN define. More work is required to match OpenBSD's tunnel protocol, which prepends the address family to the packet Then on the 20060101 there is a note mentioning support for NetBSD and FreeBSD. But thats about it. No mention of OS X or linux. So... I don't know what this means in terms of what it can or cannot do but the people on the dev list can tell you for sure. Chris Rapier Pittsburgh Supercomputing Center Johan Berg wrote: > Howdy, > > I recently tried to get OpenSSH 4.3 (built on darwinports) and OpenBSD's > OpenSSH 4.3 (OpenBSD as the server) with VPN working. I get stuck when > I've created the tun interfaces on both sides and everything seems OK. > Tiger doesn't come with tun/tap support so I had to get > http://www-user.rhrk.uni-kl.de/~nissler/tuntap/. > > PermitTunnel is set to yes and tun0 got: > > tun0: flags=51 mtu 3000 > groups: tun > inet 192.168.1.1 --> 192.168.1.2 netmask 0xfffffffc > > > > I tried the following from my Mac, with -v: > > voltaire ~ # ssh -vfw 0:1 argus true > OpenSSH_4.3p1, OpenSSL 0.9.8 05 Jul 2005 > debug1: Reading configuration data /Users/johan/.ssh/config > debug1: Applying options for argus > debug1: Reading configuration data /opt/local/etc/ssh/ssh_config > debug1: Connecting to argus [192.168.0.254] port 22. > debug1: Connection established. > debug1: identity file /Users/johan/.ssh/identity type -1 > debug1: identity file /Users/johan/.ssh/id_rsa type 1 > debug1: identity file /Users/johan/.ssh/id_dsa type -1 > debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3 > debug1: match: OpenSSH_4.3 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_4.3 > 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(1024<1024<8192) sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug1: Host 'argus' is known and matches the RSA host key. > debug1: Found key in /Users/johan/.ssh/known_hosts:33 > debug1: ssh_rsa_verify: signature correct > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug1: SSH2_MSG_NEWKEYS received > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug1: Authentications that can continue: > publickey,password,keyboard-interactive > debug1: Next authentication method: publickey > debug1: Trying private key: /Users/johan/.ssh/identity > debug1: Offering public key: /Users/johan/.ssh/id_rsa > debug1: Server accepts key: pkalg ssh-rsa blen 277 > debug1: read PEM private key done: type RSA > debug1: Authentication succeeded (publickey). > debug1: channel 0: new [client-session] > debug1: Entering interactive session. > debug1: Requesting tun. > Tunnel interfaces are not supported on this platform > debug1: Sending command: true > debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 > debug1: channel 0: free: client-session, nchannels 1 > debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.0 seconds > debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 > debug1: Exit status 0 > > Any idea what might cause "Tunnel interfaces are not supported on this > platform", is the tuntap install package broken in some way or is SSH > trying to create a new tun interface which can't be made? > > Regards, > > -- Johan Berg > > From kevmack at accesscomm.ca Sat Feb 11 09:23:30 2006 From: kevmack at accesscomm.ca (Kevin Mack) Date: Fri, 10 Feb 2006 16:23:30 -0600 Subject: 4.3p2: call for testing Message-ID: <20060210222330.GA4265@soltek.localdomain> snap-20060211 builds and runs on Sparc Solaris 8 and 10. From djm at cvs.openbsd.org Sat Feb 11 21:25:09 2006 From: djm at cvs.openbsd.org (Damien Miller) Date: Sat, 11 Feb 2006 03:25:09 -0700 (MST) Subject: Announce: OpenSSH 4.3p2 released Message-ID: <200602111025.k1BAP9Tw021278@cvs.openbsd.org> Portable OpenSSH 4.3p2 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots and purchased T-shirts or posters. T-shirt, poster and CD sales directly support the project. Pictures and more information can be found at: http://www.openbsd.org/tshirts.html and http://www.openbsd.org/orders.html For international orders use http://https.openbsd.org/cgi-bin/order and for European orders, use http://https.openbsd.org/cgi-bin/order.eu Changes since Portable OpenSSH 4.3p1: ==================================== This is a release of Portable OpenSSH only, to resolve some portability bugs. There are no new features, only fixes: * Explicitly test for egrep in ./configure, fixing a problem in 4.3p1 that caused some platforms to fail to detect the available fields in utmp/wtmp/lastlog records. This bug manifested as missing or empty login/logout records (as seen by last(1), etc.) * Fix for logout records not being updated on platforms without support for post-authentication privilege separation (e.g. Cygwin) * Fixed compilation problems on Ultrix, NewsOS and QNX Thanks to everyone who has contributed patches, reported bugs or test releases. Checksums: ========== - SHA1 (openssh-4.3p2.tar.gz) = 2b5b0751fd578283ba7b106025c0ba391fd72f1f Reporting Bugs: =============== - please read http://www.openssh.com/report.html and http://bugzilla.mindrot.org/ OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From djm at mindrot.org Sat Feb 11 21:48:34 2006 From: djm at mindrot.org (Damien Miller) Date: Sat, 11 Feb 2006 21:48:34 +1100 (EST) Subject: Administrivia: Australian co-lo space wanted Message-ID: Hi, I would like to find a home for a public anoncvs, cvsweb and snapshot repository for Portable OpenSSH in a decent datacenter. Can anyone recommend (off-list) good and affordable co-lo facilities in Australia, preferably Melbourne? The facilities needed are a couple of RU and Internet connectivity. IPv6 access is a strong plus, as is access to multiple carriers. If an ISP or data centre operator who values Portable OpenSSH would like to support the project by offering or subsidising space then it would be greatly appreciated. Thanks, Damien Miller From vinschen at redhat.com Sun Feb 12 02:49:56 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 11 Feb 2006 16:49:56 +0100 Subject: Announce: OpenSSH 4.3p2 released In-Reply-To: <200602111025.k1BAP9Tw021278@cvs.openbsd.org> References: <200602111025.k1BAP9Tw021278@cvs.openbsd.org> Message-ID: <20060211154956.GP14219@calimero.vinschen.de> On Feb 11 03:25, Damien Miller wrote: > Portable OpenSSH 4.3p2 has just been released. It will be available > from the mirrors listed at http://www.openssh.com/ shortly. > [...] > Changes since Portable OpenSSH 4.3p1: > ==================================== > > This is a release of Portable OpenSSH only, to resolve some > portability bugs. There are no new features, only fixes: > > * Explicitly test for egrep in ./configure, fixing a problem in 4.3p1 > that caused some platforms to fail to detect the available fields > in utmp/wtmp/lastlog records. This bug manifested as missing or > empty login/logout records (as seen by last(1), etc.) > > * Fix for logout records not being updated on platforms without > support for post-authentication privilege separation (e.g. Cygwin) > > * Fixed compilation problems on Ultrix, NewsOS and QNX Is there a reason why the patch to auth2.c is missing in 4.3p2, which avoids double login syslogging, as discussed at length in http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=113925054523165&w=2 Is there any chance for a 4.3p3? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From djm at mindrot.org Sun Feb 12 09:14:44 2006 From: djm at mindrot.org (Damien Miller) Date: Sun, 12 Feb 2006 09:14:44 +1100 (EST) Subject: Announce: OpenSSH 4.3p2 released In-Reply-To: <20060211154956.GP14219@calimero.vinschen.de> References: <200602111025.k1BAP9Tw021278@cvs.openbsd.org> <20060211154956.GP14219@calimero.vinschen.de> Message-ID: > Is there a reason why the patch to auth2.c is missing in 4.3p2, which > avoids double login syslogging, as discussed at length in > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=113925054523165&w=2 Yes, we need to think about it some more - auth_log has effects beyond just logging. We don't like doing extra portable releases, and wanted to keep this as minimal as possible. That means fixing things that are truly broken, not merely annoying. > Is there any chance for a 4.3p3? Very little. But if we fix it in HEAD now then we can have something for our next release in a couple of months time. -d From dtucker at zip.com.au Sun Feb 12 12:08:18 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 12 Feb 2006 12:08:18 +1100 Subject: sshd double-logging Message-ID: <20060212010818.GA19734@gate.dtucker.net> Hi all. As Corinna pointed out, there are some cases where sshd will log some authentications twice when privsep=yes. This can happen on any platform although it seems most obvious on the ones that don't do post-auth privsep. It also occurs when sshd logs to stderr (eg running under daemontools) or when you have a /dev/log in the privsep chroot. The patch below attempts to solve this for the general case. The idea is that everything is logged by the monitor, except for "postponed" authentications. (The monitor never knows about the "postponed" ones since the slave is just waiting for a response from the client. I don't think it's worth another monitor call to log those.) Index: auth.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth.c,v retrieving revision 1.101 diff -u -p -r1.101 auth.c --- auth.c 31 Aug 2005 16:59:49 -0000 1.101 +++ auth.c 12 Feb 2006 00:24:03 -0000 @@ -231,6 +231,15 @@ auth_log(Authctxt *authctxt, int authent void (*authlog) (const char *fmt,...) = verbose; char *authmsg; +#if 0 + logit("authenticated %d method %s info '%s' postponed %d monitor %d", + authenticated, method, info, authctxt->postponed, mm_is_monitor()); +#endif + authlog = logit; /* XXX for testing only */ + + if (use_privsep && !mm_is_monitor() && !authctxt->postponed) + return; + /* Raise logging level */ if (authenticated == 1 || !authctxt->valid || Index: monitor.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/monitor.c,v retrieving revision 1.88 diff -u -p -r1.88 monitor.c --- monitor.c 5 Nov 2005 04:07:05 -0000 1.88 +++ monitor.c 12 Feb 2006 00:17:03 -0000 @@ -188,7 +188,7 @@ struct mon_table mon_dispatch_proto20[] {MONITOR_REQ_PAM_ACCOUNT, 0, mm_answer_pam_account}, {MONITOR_REQ_PAM_INIT_CTX, MON_ISAUTH, mm_answer_pam_init_ctx}, {MONITOR_REQ_PAM_QUERY, MON_ISAUTH, mm_answer_pam_query}, - {MONITOR_REQ_PAM_RESPOND, MON_ISAUTH, mm_answer_pam_respond}, + {MONITOR_REQ_PAM_RESPOND, MON_AUTH, mm_answer_pam_respond}, {MONITOR_REQ_PAM_FREE_CTX, MON_ONCE|MON_AUTHDECIDE, mm_answer_pam_free_ctx}, #endif #ifdef SSH_AUDIT_EVENTS @@ -231,8 +231,8 @@ struct mon_table mon_dispatch_proto15[] {MONITOR_REQ_SESSKEY, MON_ONCE, mm_answer_sesskey}, {MONITOR_REQ_SESSID, MON_ONCE, mm_answer_sessid}, {MONITOR_REQ_AUTHPASSWORD, MON_AUTH, mm_answer_authpassword}, - {MONITOR_REQ_RSAKEYALLOWED, MON_ISAUTH, mm_answer_rsa_keyallowed}, - {MONITOR_REQ_KEYALLOWED, MON_ISAUTH, mm_answer_keyallowed}, + {MONITOR_REQ_RSAKEYALLOWED, MON_AUTH, mm_answer_rsa_keyallowed}, + {MONITOR_REQ_KEYALLOWED, MON_AUTH, mm_answer_keyallowed}, {MONITOR_REQ_RSACHALLENGE, MON_ONCE, mm_answer_rsa_challenge}, {MONITOR_REQ_RSARESPONSE, MON_ONCE|MON_AUTHDECIDE, mm_answer_rsa_response}, #ifdef BSD_AUTH @@ -248,7 +248,7 @@ struct mon_table mon_dispatch_proto15[] {MONITOR_REQ_PAM_ACCOUNT, 0, mm_answer_pam_account}, {MONITOR_REQ_PAM_INIT_CTX, MON_ISAUTH, mm_answer_pam_init_ctx}, {MONITOR_REQ_PAM_QUERY, MON_ISAUTH, mm_answer_pam_query}, - {MONITOR_REQ_PAM_RESPOND, MON_ISAUTH, mm_answer_pam_respond}, + {MONITOR_REQ_PAM_RESPOND, MON_AUTH, mm_answer_pam_respond}, {MONITOR_REQ_PAM_FREE_CTX, MON_ONCE|MON_AUTHDECIDE, mm_answer_pam_free_ctx}, #endif #ifdef SSH_AUDIT_EVENTS @@ -921,7 +921,8 @@ mm_answer_pam_respond(int sock, Buffer * buffer_clear(m); buffer_put_int(m, ret); mm_request_send(sock, MONITOR_ANS_PAM_RESPOND, m); - auth_method = "keyboard-interactive/pam"; + auth_method = compat20 ? "keyboard-interactive/pam" : + "challenge-response"; if (ret == 0) sshpam_authok = sshpam_ctxt; return (0); @@ -980,17 +981,20 @@ mm_answer_keyallowed(int sock, Buffer *m case MM_USERKEY: allowed = options.pubkey_authentication && user_key_allowed(authctxt->pw, key); + auth_method = "publickey"; break; case MM_HOSTKEY: allowed = options.hostbased_authentication && hostbased_key_allowed(authctxt->pw, cuser, chost, key); + auth_method = "hostbased"; break; case MM_RSAHOSTKEY: key->type = KEY_RSA1; /* XXX */ allowed = options.rhosts_rsa_authentication && auth_rhosts_rsa_key_allowed(authctxt->pw, cuser, chost, key); + auth_method = "rsa"; break; default: fatal("%s: unknown key type %d", __func__, type); @@ -1010,6 +1014,9 @@ mm_answer_keyallowed(int sock, Buffer *m key_blobtype = type; hostbased_cuser = cuser; hostbased_chost = chost; + } else { + /* Log failed attempt */ + auth_log(authctxt, 0, auth_method, compat20 ? " ssh2" : ""); } debug3("%s: key %p is %s", @@ -1374,6 +1381,7 @@ mm_answer_rsa_keyallowed(int sock, Buffe debug3("%s entering", __func__); + auth_method = "rsa"; if (options.rsa_authentication && authctxt->valid) { if ((client_n = BN_new()) == NULL) fatal("%s: BN_new", __func__); -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Sun Feb 12 23:54:58 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 12 Feb 2006 13:54:58 +0100 Subject: sshd double-logging In-Reply-To: <20060212010818.GA19734@gate.dtucker.net> References: <20060212010818.GA19734@gate.dtucker.net> Message-ID: <20060212125458.GA20341@calimero.vinschen.de> On Feb 12 12:08, Darren Tucker wrote: > Hi all. > > As Corinna pointed out, there are some cases where sshd will log some > authentications twice when privsep=yes. > > This can happen on any platform although it seems most obvious on the > ones that don't do post-auth privsep. It also occurs when sshd logs > to stderr (eg running under daemontools) or when you have a /dev/log in > the privsep chroot. > > The patch below attempts to solve this for the general case. The idea > is that everything is logged by the monitor, except for "postponed" > authentications. (The monitor never knows about the "postponed" > ones since the slave is just waiting for a response from the client. > I don't think it's worth another monitor call to log those.) Thanks for the patch, but... instead of two, I now have three messages in the syslog: Feb 12 13:51:19 cathi sshd: PID 3796: Failed none for corinna from 192.168.129.6 port 41585 ssh2 Feb 12 13:51:19 cathi sshd: PID 1692: Postponed publickey for corinna from 192.168.129.6 port 41585 ssh2 Feb 12 13:51:19 cathi sshd: PID 3796: Accepted publickey for corinna from 192.168.129.6 port 41585 ssh This is identical with and without privsep. Corinna PS: I won't be able to test further patches until wednesday. -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vinschen at redhat.com Mon Feb 13 00:10:04 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 12 Feb 2006 14:10:04 +0100 Subject: sshd double-logging In-Reply-To: <20060212125458.GA20341@calimero.vinschen.de> References: <20060212010818.GA19734@gate.dtucker.net> <20060212125458.GA20341@calimero.vinschen.de> Message-ID: <20060212131004.GW14219@calimero.vinschen.de> On Feb 12 13:54, Corinna Vinschen wrote: > On Feb 12 12:08, Darren Tucker wrote: > > Hi all. > > > > As Corinna pointed out, there are some cases where sshd will log some > > authentications twice when privsep=yes. > > > > This can happen on any platform although it seems most obvious on the > > ones that don't do post-auth privsep. It also occurs when sshd logs > > to stderr (eg running under daemontools) or when you have a /dev/log in > > the privsep chroot. > > > > The patch below attempts to solve this for the general case. The idea > > is that everything is logged by the monitor, except for "postponed" > > authentications. (The monitor never knows about the "postponed" > > ones since the slave is just waiting for a response from the client. > > I don't think it's worth another monitor call to log those.) > > Thanks for the patch, but... instead of two, I now have three messages > in the syslog: > > Feb 12 13:51:19 cathi sshd: PID 3796: Failed none for corinna from 192.168.129.6 port 41585 ssh2 > Feb 12 13:51:19 cathi sshd: PID 1692: Postponed publickey for corinna from 192.168.129.6 port 41585 ssh2 > Feb 12 13:51:19 cathi sshd: PID 3796: Accepted publickey for corinna from 192.168.129.6 port 41585 ssh > > This is identical with and without privsep. ... and I get four log entries when no public key is available, so I guess the number of log entries now matches basically the number of authentication methods used: Feb 12 14:07:50 cathi sshd: PID 3264: Failed none for corinna from 192.168.129.6 port 42800 ssh2 Feb 12 14:07:50 cathi sshd: PID 3264: Failed publickey for corinna from 192.168.129.6 port 42800 ssh2 Feb 12 14:07:50 cathi sshd: PID 3264: Failed publickey for corinna from 192.168.129.6 port 42800 ssh2 Feb 12 14:07:55 cathi sshd: PID 3264: Accepted password for corinna from 192.168.129.6 port 42800 ssh2 Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From alon.barlev at gmail.com Mon Feb 13 06:08:02 2006 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sun, 12 Feb 2006 21:08:02 +0200 Subject: [ANNOUNCE] PKCS#11 support in OpenSSH 4.3p2 (version 0.07) Message-ID: <43EF8792.90608@gmail.com> Hello, The version 0.07 of "PKCS#11 support in OpenSSH" is published. Changes: 1. Updated against OpenSSH 4.3p1. 2. Ignore '\r' at password prompt, cygwin/win32 password prompt support. 3. Workaround for iKey PKCS#11 provider bug. 4. Some minor cleanups. 5. Allow clean merge of Roumen Petrov's X.509 patch (version 5.3) after this one. [[[ The patch-set is too large for posting in the list... If you are interested in review it, please send me an email (mailto:alon.barlev at gmail.com) ]]] I will appreciate any comments/suggestions. Enjoy, Alon Bar-Lev. --- Instructions: The PKCS#11 patch modify ssh-add and ssh-agent to support PKCS#11 private keys and certificates. It allows using multiple PKCS#11 providers at the same time, selecting keys by id, label or certificate subject, handling card removal and card insert events, handling card re-insert to a different slot, supporting session expiration. A valid X.509 certificate should exist on the token, without X.509 support it is exported as regular RSA key. Self-signed certificates are treated as RSA key and not as X.509 RSA key. There is a simple utility Timo Felbinger wrote (http://www.timof.qipc.org/x509toOpenSSH.c) that extracts ssh public key from X.509 certificate. If you like X.509 support apply the X.509 patch *AFTER* the PKCS#11 patch. One significant change is that the ssh-agent prompts for passwords now... So you need to configure it with a program that asks for card insert or PIN, a program such as x11-ssh-askpass. Current implementation (ssh-add asks for passwords) is not valid for dynamic smartcard environment. Current implementation uses the askpin program also for prompting card insert... Don't be confused, it only expects ok or cancel, attached is a simple scripts that uses KDE and .NET in order to display these dialogs. You can view full usage by: $ ssh-agent /bin/sh $ ssh-add -h A common scenario is the following: $ ssh-agent /bin/sh $ ssh-add --pkcs11-ask-pin `which openssh-kde-dialogs.sh` $ ssh-add --pkcs11-add-provider --pkcs11-provider /usr/lib/pkcs11/MyProvider.so $ ssh-add --pkcs11-add-id --pkcs11-slot-type label --pkcs11-slot "MyToken" --pkcs11-id-type subject --pkcs11-id "/C=XX/CN=YY" $ ssh myhost In order to see available objects, you can use: $ ssh-add --pkcs11-show-slots --pkcs11-provider /usr/lib/pkcs11/MyProvider.so $ ssh-add --pkcs11-show-objects --pkcs11-provider /usr/lib/pkcs11/MyProvider.so --pkcs11-slot 0 From dtucker at zip.com.au Mon Feb 13 06:37:07 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 13 Feb 2006 06:37:07 +1100 Subject: sshd double-logging In-Reply-To: <20060212131004.GW14219@calimero.vinschen.de> References: <20060212010818.GA19734@gate.dtucker.net> <20060212125458.GA20341@calimero.vinschen.de> <20060212131004.GW14219@calimero.vinschen.de> Message-ID: <20060212193707.GA25583@gate.dtucker.net> On Sun, Feb 12, 2006 at 02:10:04PM +0100, Corinna Vinschen wrote: > > Thanks for the patch, but... instead of two, I now have three messages > > in the syslog: > > > > Feb 12 13:51:19 cathi sshd: PID 3796: Failed none for corinna from 192.168.129.6 port 41585 ssh2 > > Feb 12 13:51:19 cathi sshd: PID 1692: Postponed publickey for corinna from 192.168.129.6 port 41585 ssh2 > > Feb 12 13:51:19 cathi sshd: PID 3796: Accepted publickey for corinna from 192.168.129.6 port 41585 ssh No, that's okay. There's 3 messages but they're different (no dupes). If you comment out the line marked "XXX for testing only" then it should behave as you are used to. (Normally, most failed auth attempts are logged only with a severity of "verbose" until MaxAuthTries/2 attempts have been made to cut down on the noise. I disabled that for the purposes of testing.) > > This is identical with and without privsep. Excellent, that's the idea :-) > ... and I get four log entries when no public key is available, so I guess > the number of log entries now matches basically the number of authentication > methods used: > > Feb 12 14:07:50 cathi sshd: PID 3264: Failed none for corinna from 192.168.129.6 port 42800 ssh2 > Feb 12 14:07:50 cathi sshd: PID 3264: Failed publickey for corinna from 192.168.129.6 port 42800 ssh2 > Feb 12 14:07:50 cathi sshd: PID 3264: Failed publickey for corinna from 192.168.129.6 port 42800 ssh2 > Feb 12 14:07:55 cathi sshd: PID 3264: Accepted password for corinna from 192.168.129.6 port 42800 ssh2 If you run the client with -vvv can you actually see it try 2 public keys? That happens for me because I have 2 keys available (rsa and dsa). Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Mon Feb 13 07:13:05 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 12 Feb 2006 21:13:05 +0100 Subject: sshd double-logging In-Reply-To: <20060212193707.GA25583@gate.dtucker.net> References: <20060212010818.GA19734@gate.dtucker.net> <20060212125458.GA20341@calimero.vinschen.de> <20060212131004.GW14219@calimero.vinschen.de> <20060212193707.GA25583@gate.dtucker.net> Message-ID: <20060212201305.GZ14219@calimero.vinschen.de> On Feb 13 06:37, Darren Tucker wrote: > On Sun, Feb 12, 2006 at 02:10:04PM +0100, Corinna Vinschen wrote: > > > Thanks for the patch, but... instead of two, I now have three messages > > > in the syslog: > > > > > > Feb 12 13:51:19 cathi sshd: PID 3796: Failed none for corinna from 192.168.129.6 port 41585 ssh2 > > > Feb 12 13:51:19 cathi sshd: PID 1692: Postponed publickey for corinna from 192.168.129.6 port 41585 ssh2 > > > Feb 12 13:51:19 cathi sshd: PID 3796: Accepted publickey for corinna from 192.168.129.6 port 41585 ssh > > No, that's okay. There's 3 messages but they're different (no dupes). > > If you comment out the line marked "XXX for testing only" then it should > behave as you are used to. (Normally, most failed auth attempts are > logged only with a severity of "verbose" until MaxAuthTries/2 attempts > have been made to cut down on the noise. I disabled that for the purposes > of testing.) Uh, ok. I disabled this line and it behaves as expected now... > > > > This is identical with and without privsep. > > Excellent, that's the idea :-) ... also with and without privsep. :-) Do you think it's ok to use this patch for the official Cygwin net distro release of 4.3p2? Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From dtucker at zip.com.au Mon Feb 13 09:40:45 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 13 Feb 2006 09:40:45 +1100 Subject: sshd double-logging In-Reply-To: <20060212201305.GZ14219@calimero.vinschen.de> References: <20060212010818.GA19734@gate.dtucker.net> <20060212125458.GA20341@calimero.vinschen.de> <20060212131004.GW14219@calimero.vinschen.de> <20060212193707.GA25583@gate.dtucker.net> <20060212201305.GZ14219@calimero.vinschen.de> Message-ID: <20060212224045.GA2519@gate.dtucker.net> On Sun, Feb 12, 2006 at 09:13:05PM +0100, Corinna Vinschen wrote: [snip] > Do you think it's ok to use this patch for the official Cygwin net distro > release of 4.3p2? I think it's ok but I just want someone to sanity check the monitor changes, particularly the MON_ISAUTH -> MON_AUTH bits. The difference between those two is the MON_AUTHDECIDE flag which is used in two places: the "unexpected authentication" check, and the auth_log logging. -- 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 mhooreman at be.keyware.com Mon Feb 13 22:02:56 2006 From: mhooreman at be.keyware.com (=?iso-8859-1?Q?Micha=EBl_Hooreman?=) Date: Mon, 13 Feb 2006 12:02:56 +0100 Subject: PermitRootLogin proplem Message-ID: <007401c6308d$0bcca200$3f0aa8c0@dmpwks008> Hi all, I think that there is a security problem with the PermitRootLogin option. I asked an root ssh connection: $ ssh root at machine root at machine's password: I typed no password, this prompt stayed in place. In a second time, I changed the PermitRootLogin to no, and then restart ssh server. Third, I typed the password on the previous prompt, and the access was allowed. I then retry to connect and, at this time, the root connection was disallowed, as expected. So, is it possible to inform the ssh client that the ssh server has restarted when he gives a prompt? Thank you for your help. P.S: I didn't see how to subscribe to this list, so I cannot follow your responses. Can anyone send me how to subscibe? P.P.S: The ssh server was a Linux Fedora Core 4, up to date, with openssh v. 4.2p_1. --- Micha?l Hooreman Keyware Transaction and Processing Rue Laid Burniad, 4 1348 - Louvain-La-Neuve Belgium Tel : +32 (0)10 48 01 21 Fax : +32 (0)10 45 77 67 mhooreman at be.keyware.com From gert at greenie.muc.de Mon Feb 13 22:18:44 2006 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 13 Feb 2006 12:18:44 +0100 Subject: PermitRootLogin proplem In-Reply-To: <007401c6308d$0bcca200$3f0aa8c0@dmpwks008> References: <007401c6308d$0bcca200$3f0aa8c0@dmpwks008> Message-ID: <20060213111844.GV22955@greenie.muc.de> Hi, On Mon, Feb 13, 2006 at 12:02:56PM +0100, Micha?l Hooreman wrote: > In a second time, I changed the PermitRootLogin to no, and then restart > ssh server. > > Third, I typed the password on the previous prompt, and the access was > allowed. Actually, you have not "restarted ssh server" - you have restarted the process that handles *new* connections, but you have NOT restarted the process that was already handling this specific connection, sitting at the password prompt. If you stop *all* sshd processes, you'll see that the connection will also go away. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From dtucker at zip.com.au Mon Feb 13 22:26:09 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 13 Feb 2006 22:26:09 +1100 Subject: PermitRootLogin proplem In-Reply-To: <007401c6308d$0bcca200$3f0aa8c0@dmpwks008> References: <007401c6308d$0bcca200$3f0aa8c0@dmpwks008> Message-ID: <20060213112609.GA9780@gate.dtucker.net> On Mon, Feb 13, 2006 at 12:02:56PM +0100, Micha?l Hooreman wrote: > I think that there is a security problem with the PermitRootLogin > option. > > I asked an root ssh connection: > > $ ssh root at machine > root at machine's password: > > I typed no password, this prompt stayed in place. > > In a second time, I changed the PermitRootLogin to no, and then restart > ssh server. > > Third, I typed the password on the previous prompt, and the access was > allowed. That's how most Unix daemons work: once the copy started to handle the connection is forked it's an independant process. If it matters to you, also kill off any running sshd's when you restart (but be careful not to kill the one you're connecting by). The session can only remain active for LoginGraceTime anyway (which by default is 2 min). > I then retry to connect and, at this time, the root connection was > disallowed, as expected. > > So, is it possible to inform the ssh client that the ssh server has > restarted when he gives a prompt? Not easily and/or without the risk of killing off active sessions. Some vendors' sshd restart scripts used to do that kind of thing (ie "pkill sshd"), and as the victim of one of them (on a remote, fortunately non-production machine), I'm not keen to see it make a comeback. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From tim at multitalents.net Tue Feb 14 07:57:04 2006 From: tim at multitalents.net (Tim Rice) Date: Mon, 13 Feb 2006 12:57:04 -0800 (PST) Subject: FYI: buildpkg.sh.in Message-ID: I've just commited the patch below to buildpkg.sh.in to HEAD Just in case anyone is using "make package" to build a SVR4 style package, I thought I'd give a heads the default name for $POST_MAKE_INSTALL_FIXES has changed. --- buildpkg.sh.in.old 2005-12-28 14:24:55.856729016 -0800 +++ buildpkg.sh.in 2006-02-12 10:04:06.383475017 -0800 @@ -35,7 +35,7 @@ SYSVINITSTART=S98 SYSVINITSTOPT=K30 # We will source these if they exist -POST_MAKE_INSTALL_FIXES=./pkg_post_make_install_fixes.sh +POST_MAKE_INSTALL_FIXES=./pkg-post-make-install-fixes.sh POST_PROTOTYPE_EDITS=./pkg-post-prototype-edit.sh # We'll be one level deeper looking for these PKG_PREINSTALL_LOCAL=../pkg-preinstall.local -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tmg at pobox.com Fri Feb 17 00:51:33 2006 From: tmg at pobox.com (Thomas Gardner) Date: Thu, 16 Feb 2006 08:51:33 -0500 (EST) Subject: PAM and passwd age warnings again. Message-ID: <200602161351.k1GDpXFk020966@brak.EECS.cwru.edu> Hi all, This is a patch against 4.2p1 (compiling for a Linux --- an old, highly customized 7.2 to be specific). When I compiled it from your original source, installed it, and turned on PAM (for passwd aging), I couldn't get the passwd expiration warnings as specified in /etc/shadow to work at all (the message that is supposed to warn you as you're logging in that your passwd will expire in XYZ days). The patch below seemed to fix it. It looks like PAM was figgerin' it out, but the message was getting blocked again (although this time it was being blocked for a different reason than the last time I proposed a fix for this). Please let me know if you get this, because I'm not on the mailing list (sorry). If you'd like to put it into the official source, please feel free; that's why I'm giving it to you. If you already have, and I'm a rev or two behind and missed it, please accept my apologies. If you'd like to just completely ignore this and not include it in the source, well, that would be fine too, it's your code, not mine. I'm just sending this to y'all 'cause I worked through it for myself, and I thought you folks might like it. If not, well, that's OK too. I just figgered this was the least I could do for the cause. L8r, tg. ------------------------------------------------------------------------ diff -Naur openssh-4.2p1.old/monitor.c openssh-4.2p1.new/monitor.c --- openssh-4.2p1.old/monitor.c Sun Jul 17 03:53:31 2005 +++ openssh-4.2p1.new/monitor.c Tue Dec 20 09:10:04 2005 @@ -1716,6 +1716,11 @@ child_state.input = buffer_get_string(&m, &child_state.ilen); child_state.output = buffer_get_string(&m, &child_state.olen); + /* Let's not forget our loginmsg, now, eh? */ + p = buffer_get_string (&m, &plen); + if (plen) buffer_append (&loginmsg, p, plen); + xfree (p); + buffer_free(&m); } diff -Naur openssh-4.2p1.old/monitor_wrap.c openssh-4.2p1.new/monitor_wrap.c --- openssh-4.2p1.old/monitor_wrap.c Sun Jul 17 03:53:31 2005 +++ openssh-4.2p1.new/monitor_wrap.c Tue Dec 20 09:09:16 2005 @@ -631,6 +631,9 @@ buffer_put_string(&m, buffer_ptr(&input), buffer_len(&input)); buffer_put_string(&m, buffer_ptr(&output), buffer_len(&output)); + /* Let's not forget our loginmsg, now, eh? */ + buffer_put_string(&m, buffer_ptr(&loginmsg), buffer_len(&loginmsg)); + mm_request_send(monitor->m_recvfd, MONITOR_REQ_KEYEXPORT, &m); debug3("%s: Finished sending state", __func__); From dtucker at zip.com.au Fri Feb 17 07:31:38 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 17 Feb 2006 07:31:38 +1100 Subject: PAM and passwd age warnings again. In-Reply-To: <200602161351.k1GDpXFk020966@brak.EECS.cwru.edu> References: <200602161351.k1GDpXFk020966@brak.EECS.cwru.edu> Message-ID: <20060216203138.GA19608@gate.dtucker.net> On Thu, Feb 16, 2006 at 08:51:33AM -0500, Thomas Gardner wrote: > source, installed it, and turned on PAM (for passwd aging), Password aging should also work without PAM (assuming your custom system uses a standard /etc/shadow arrangement). > I couldn't > get the passwd expiration warnings as specified in /etc/shadow to work > at all (the message that is supposed to warn you as you're logging in > that your passwd will expire in XYZ days). The patch below seemed to > fix it. It looks like PAM was figgerin' it out, but the message was > getting blocked again (although this time it was being blocked for a > different reason than the last time I proposed a fix for this). This was fixed in 4.3p1 and 4.3p2 (you should use the latter as the former has some issues with login recording). The ChangeLog entry is: - (dtucker) [monitor.c] Bug #1087: Send loginmsg to preauth privsep child during PAM account check without clearing it. This restores the post-login warnings such as LDAP password expiry. Patch from Tomas Mraz with help from several others. -- 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 tmg at pobox.com Sat Feb 18 01:28:04 2006 From: tmg at pobox.com (Thomas Gardner) Date: Fri, 17 Feb 2006 09:28:04 -0500 (EST) Subject: PAM and passwd age warnings again. Message-ID: <200602171428.k1HES4ej024576@brak.EECS.cwru.edu> Thank you. Sorry for the intrusion. L8r, tg. > From: Darren Tucker > To: Thomas Gardner > Cc: openssh-unix-dev at mindrot.org > Subject: Re: PAM and passwd age warnings again. > Date: Fri, 17 Feb 2006 07:31:38 +1100 > > This was fixed in 4.3p1 and 4.3p2 (you should use the latter as the > former has some issues with login recording). > > The ChangeLog entry is: > > - (dtucker) [monitor.c] Bug #1087: Send loginmsg to preauth privsep > child during PAM account check without clearing it. This restores the > post-login warnings such as LDAP password expiry. Patch from Tomas Mraz > with help from several others. From svallet at genoscope.cns.fr Tue Feb 21 01:49:23 2006 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Mon, 20 Feb 2006 15:49:23 +0100 Subject: Status of Bugzilla #1153 Message-ID: <20060220154923.5a69e446.svallet@genoscope.cns.fr> Hi, I'd like to know if there is any chance to get bug 1153 fixed soon ? It seems like a trivial issue, a patch is provided, and it's a pain for us to manually patch every new release -- this was reported as a portable-specific bug, but also affects vanilla openssh. The bug is described at http://bugzilla.mindrot.org/show_bug.cgi?id=1153 Simon -- Simon Vallet Ing?nieur Syst?mes/R?seaux G?noscope / CNRG T?l. : 01 60 87 36 06 E-mail : svallet at genoscope.cns.fr From dtucker at zip.com.au Tue Feb 21 07:12:49 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 21 Feb 2006 07:12:49 +1100 Subject: Status of Bugzilla #1153 In-Reply-To: <20060220154923.5a69e446.svallet@genoscope.cns.fr> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> Message-ID: <20060220201249.GA17657@gate.dtucker.net> On Mon, Feb 20, 2006 at 03:49:23PM +0100, Simon Vallet wrote: > I'd like to know if there is any chance to get bug 1153 fixed > soon ? It seems like a trivial issue, a patch is provided, and it's a > pain for us to manually patch every new release -- this was reported > as a portable-specific bug, but also affects vanilla openssh. Well, you haven't explained why it's a bug and should be changed. Under what circumstances is a $DISPLAY of the hostname not the "wanted value"? -- 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 svallet at genoscope.cns.fr Tue Feb 21 21:03:01 2006 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Tue, 21 Feb 2006 11:03:01 +0100 Subject: Status of Bugzilla #1153 In-Reply-To: <20060220201249.GA17657@gate.dtucker.net> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> Message-ID: <20060221110301.03215801.svallet@genoscope.cns.fr> On Tue, 21 Feb 2006 07:12:49 +1100 Darren Tucker wrote: > On Mon, Feb 20, 2006 at 03:49:23PM +0100, Simon Vallet wrote: > > I'd like to know if there is any chance to get bug 1153 fixed > > soon ? It seems like a trivial issue, a patch is provided, and it's a > > pain for us to manually patch every new release -- this was reported > > as a portable-specific bug, but also affects vanilla openssh. > > Well, you haven't explained why it's a bug and should be changed. Under > what circumstances is a $DISPLAY of the hostname not the "wanted value"? OK -- we have globally the following setup here : an external ssh gateway performing X11 forwarding to the internal network -- as this machine is multihomed, a call to gethostname() returns (correctly IMO) the short name of the gateway, which is the value used to set DISPLAY and to add xauth credentials. When called, xauth (correctly) qualifies the host name to the one which resolves to the externally reachable interface of the gateway. DISPLAY, however, is still unqualified. Once on the gateway, if an external user wants to get an X11 client running on an internal machine in an automated way (i.e. without connectiong to the target machine and manually set DISPLAY), it will use the value of DISPLAY set by OpenSSH, which uses the unqualified hostname. When qualifying this hostname, X11 will use the default domain, which is the one from the internal network. And this is were the problem appears : as xauth credentials are set using the FQDN of the external interface of the gateway, any internal X11 client will be denied access to the forwarded X11 server. Not using gethostname() but the connected IP to set DISPLAY solves this qualified/unqualified hostname issue, and is IMO the correct behaviour, considering that I otherwise fail to see how to always choose the working hostname on a multihomed machine. Simon From f_mohr at yahoo.de Tue Feb 21 21:45:23 2006 From: f_mohr at yahoo.de (Frank Mohr) Date: Tue, 21 Feb 2006 11:45:23 +0100 Subject: Status of Bugzilla #1153 In-Reply-To: <20060220201249.GA17657@gate.dtucker.net> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> Message-ID: <43FAEF43.8010909@yahoo.de> Darren Tucker wrote: > On Mon, Feb 20, 2006 at 03:49:23PM +0100, Simon Vallet wrote: > >>I'd like to know if there is any chance to get bug 1153 fixed >>soon ? It seems like a trivial issue, a patch is provided, and it's a >>pain for us to manually patch every new release -- this was reported >>as a portable-specific bug, but also affects vanilla openssh. > > > Well, you haven't explained why it's a bug and should be changed. Under > what circumstances is a $DISPLAY of the hostname not the "wanted value"? > i'm using a similar patch since years. we had problems with AIX/HACMP systems, where the interface with the hostname ip address wasn't active on the standby node. frank ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de From corsmith at gmail.com Wed Feb 22 01:47:50 2006 From: corsmith at gmail.com (Corey Smith) Date: Tue, 21 Feb 2006 09:47:50 -0500 Subject: Status of Bugzilla #1153 In-Reply-To: <20060221110301.03215801.svallet@genoscope.cns.fr> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> Message-ID: <8061fbee0602210647w6f9977f8u844d05e1b7e109d1@mail.gmail.com> On 2/21/06, Simon Vallet wrote: > Once on the gateway, if an external user wants to get an X11 client > running on an internal machine in an automated way (i.e. without > connectiong to the target machine and manually set DISPLAY), it will > use the value of DISPLAY set by OpenSSH, which uses the unqualified > hostname. When qualifying this hostname, X11 will use the default > domain, which is the one from the internal network. Instead of forwarding your X sessions plaintext through the internal network couldn't you just ssh into the internal machine with X forwarding on as well? I assume the problem is with exporting your DISPLAY from the internal machine to the value obtained when X11 forwarding occurs on the ssh server? -Corey Smith From carson at taltos.org Wed Feb 22 02:10:21 2006 From: carson at taltos.org (Carson Gaspar) Date: Tue, 21 Feb 2006 10:10:21 -0500 Subject: Status of Bugzilla #1153 In-Reply-To: <20060221110301.03215801.svallet@genoscope.cns.fr> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> Message-ID: <03388ACE1436421FC8A3AAEC@[192.168.1.2]> --On Tuesday, February 21, 2006 11:03 AM +0100 Simon Vallet wrote: > OK -- we have globally the following setup here : an external ssh > gateway performing X11 forwarding to the internal network -- as this > machine is multihomed, a call to gethostname() returns (correctly IMO) > the short name of the gateway, which is the value used to set DISPLAY > and to add xauth credentials. No. gethostname() needs to return the (or a) FQDN of the server. Anything else is just broken and begging for trouble. This is sysadmin 101. -- Carson From Jefferson.Ogata at noaa.gov Wed Feb 22 02:31:25 2006 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Tue, 21 Feb 2006 10:31:25 -0500 Subject: Status of Bugzilla #1153 In-Reply-To: <03388ACE1436421FC8A3AAEC@[192.168.1.2]> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> Message-ID: <43FB324D.10403@noaa.gov> On 02/21/2006 10:10 AM, Carson Gaspar wrote: > --On Tuesday, February 21, 2006 11:03 AM +0100 Simon Vallet > wrote: >>OK -- we have globally the following setup here : an external ssh >>gateway performing X11 forwarding to the internal network -- as this >>machine is multihomed, a call to gethostname() returns (correctly IMO) >>the short name of the gateway, which is the value used to set DISPLAY >>and to add xauth credentials. > > No. gethostname() needs to return the (or a) FQDN of the server. Anything > else is just broken and begging for trouble. This is sysadmin 101. Not everyone agrees with that opinion. DNS is just a namespace, after all. It isn't the be-all, end-all of namespaces, especially given how easy it is to spoof. Consider that sysadmin 240. :^) One thing I don't understand: my experience is that ssh uses localhost:x.0 for the DISPLAY variable. Am I on crack? -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From svallet at genoscope.cns.fr Wed Feb 22 02:38:56 2006 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Tue, 21 Feb 2006 16:38:56 +0100 Subject: Status of Bugzilla #1153 In-Reply-To: <8061fbee0602210647w6f9977f8u844d05e1b7e109d1@mail.gmail.com> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <8061fbee0602210647w6f9977f8u844d05e1b7e109d1@mail.gmail.com> Message-ID: <20060221163856.4e7fab5f.svallet@genoscope.cns.fr> On Tue, 21 Feb 2006 09:47:50 -0500 "Corey Smith" wrote: > On 2/21/06, Simon Vallet wrote: > > Instead of forwarding your X sessions plaintext through the internal > network couldn't you just ssh into the internal machine with X > forwarding on as well? I assume the problem is with exporting your > DISPLAY from the internal machine to the value obtained when X11 > forwarding occurs on the ssh server? We could indeed do so, but decided a long time ago against using ssh to tunnel X11 connections on the internal network for performance reasons -- X11 over ssh is quite slow, and can rapidly become unusable, especially when the target servers are not the newest gear available. Simon From svallet at genoscope.cns.fr Wed Feb 22 03:02:41 2006 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Tue, 21 Feb 2006 17:02:41 +0100 Subject: Status of Bugzilla #1153 In-Reply-To: <03388ACE1436421FC8A3AAEC@[192.168.1.2]> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> Message-ID: <20060221170241.2e70a0ec.svallet@genoscope.cns.fr> On Tue, 21 Feb 2006 10:10:21 -0500 Carson Gaspar wrote: > > --On Tuesday, February 21, 2006 11:03 AM +0100 Simon Vallet > wrote: > > > OK -- we have globally the following setup here : an external ssh > > gateway performing X11 forwarding to the internal network -- as this > > machine is multihomed, a call to gethostname() returns (correctly IMO) > > the short name of the gateway, which is the value used to set DISPLAY > > and to add xauth credentials. > > No. gethostname() needs to return the (or a) FQDN of the server. Anything > else is just broken and begging for trouble. This is sysadmin 101. This is not in any way included in any standard, and I personally think that it was a reasonable choice. However, even if this is a debatable topic, it totally misses the point : even when gethostname() returns an FQDN, there is no way to tell in advance if the returned value will fit wanted ("working") usage. And actually, arbitrarily (from an OpenSSH POV) choosing an interface/hostname to use in DISPLAY regardless of the interface the SSH traffic is coming from seems just as "broken" and "begging for trouble". Simon From carson at taltos.org Wed Feb 22 03:10:21 2006 From: carson at taltos.org (Carson Gaspar) Date: Tue, 21 Feb 2006 11:10:21 -0500 Subject: Status of Bugzilla #1153 In-Reply-To: <43FB324D.10403@noaa.gov> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <43FB324D.10403@noaa.gov> Message-ID: <68E268D9BE7AD85CF6534013@[192.168.1.2]> --On Tuesday, February 21, 2006 10:31 AM -0500 Jefferson Ogata wrote: > On 02/21/2006 10:10 AM, Carson Gaspar wrote: >> --On Tuesday, February 21, 2006 11:03 AM +0100 Simon Vallet >> wrote: >>> OK -- we have globally the following setup here : an external ssh >>> gateway performing X11 forwarding to the internal network -- as this >>> machine is multihomed, a call to gethostname() returns (correctly IMO) >>> the short name of the gateway, which is the value used to set DISPLAY >>> and to add xauth credentials. >> >> No. gethostname() needs to return the (or a) FQDN of the server. >> Anything else is just broken and begging for trouble. This is sysadmin >> 101. > > Not everyone agrees with that opinion. I've never met anyone who disagreed who had a sane reason not use the FQDN (we're still using NIS for hostnames is not sane...). Would you like to be the first? I'd be extremely interested in your reasoning why the FQDN isn't the Right Thing To DO. > DNS is just a namespace, after all. It isn't the be-all, end-all of > namespaces, especially given how easy it is to spoof. Consider that > sysadmin 240. :^) True, but he's using DNS as his namespace internally, and complaining about ambiguous shortname->FQDN mapping (and hasn't put "shortname." into DNS, so he's not doing weird advanced things). "Doctor, it hurts when I do this!" "Then don't do it." And what other namespace is deployed (ignoring NIS, which is just evil and wrong)? > One thing I don't understand: my experience is that ssh uses > localhost:x.0 for the DISPLAY variable. Am I on crack? Read your sshd config file - you have X11UseLocalhost set. -- Carson From Jefferson.Ogata at noaa.gov Wed Feb 22 03:12:25 2006 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Tue, 21 Feb 2006 11:12:25 -0500 Subject: Status of Bugzilla #1153 In-Reply-To: <20060221170241.2e70a0ec.svallet@genoscope.cns.fr> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <20060221170241.2e70a0ec.svallet@genoscope.cns.fr> Message-ID: <43FB3BE9.7020002@noaa.gov> On 02/21/2006 11:02 AM, Simon Vallet wrote: > On Tue, 21 Feb 2006 10:10:21 -0500 > Carson Gaspar wrote: >>No. gethostname() needs to return the (or a) FQDN of the server. Anything >>else is just broken and begging for trouble. This is sysadmin 101. > > This is not in any way included in any standard, and I personally > think that it was a reasonable choice. However, even if this is a > debatable topic, it totally misses the point : even when gethostname() > returns an FQDN, there is no way to tell in advance if the returned > value will fit wanted ("working") usage. > > And actually, arbitrarily (from an OpenSSH POV) choosing an > interface/hostname to use in DISPLAY regardless of the interface the > SSH traffic is coming from seems just as "broken" and "begging for > trouble". Yes, it seems to me a more obvious choice for sshd's DISPLAY variable (if not localhost) is the numeric IP of the sshd's local endpoint. This is congruent with SSH_CLIENT, which doesn't try to resolve names in DNS. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From carson at taltos.org Wed Feb 22 03:20:54 2006 From: carson at taltos.org (Carson Gaspar) Date: Tue, 21 Feb 2006 11:20:54 -0500 Subject: Status of Bugzilla #1153 In-Reply-To: <20060221170241.2e70a0ec.svallet@genoscope.cns.fr> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <20060221170241.2e70a0ec.svallet@genoscope.cns.fr> Message-ID: --On Tuesday, February 21, 2006 5:02 PM +0100 Simon Vallet wrote: > This is not in any way included in any standard, and I personally > think that it was a reasonable choice. However, even if this is a > debatable topic, it totally misses the point : even when gethostname() > returns an FQDN, there is no way to tell in advance if the returned > value will fit wanted ("working") usage. > > And actually, arbitrarily (from an OpenSSH POV) choosing an > interface/hostname to use in DISPLAY regardless of the interface the > SSH traffic is coming from seems just as "broken" and "begging for > trouble". Your "solution" will _break_ many sane setups. In the exact setup you describe (ssh from a less trusted network to a bastion host, then connecting to more trusted hosts), I don't _want_ the DISPLAY variable to have the FQDN of the _external_ interface, as nothing internal will be able to connect to it. I have no idea how this is supposed to make your problem _better_. Set your hostname to be sane, and all will be well. Or give your users init scripts that do whatever DISPLAY/xauth transforms you wish. Don't break ssh for the rest of us because you have some religious belief that hostname() should return an ambiguous name. -- Carson From svallet at genoscope.cns.fr Wed Feb 22 03:32:54 2006 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Tue, 21 Feb 2006 17:32:54 +0100 Subject: Status of Bugzilla #1153 In-Reply-To: <68E268D9BE7AD85CF6534013@[192.168.1.2]> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <43FB324D.10403@noaa.gov> <68E268D9BE7AD85CF6534013@[192.168.1.2]> Message-ID: <20060221173254.2e8596d9.svallet@genoscope.cns.fr> On Tue, 21 Feb 2006 11:10:21 -0500 Carson Gaspar wrote: > True, but he's using DNS as his namespace internally, and complaining about > ambiguous shortname->FQDN mapping (and hasn't put "shortname." into DNS, so > he's not doing weird advanced things). Come on now -- let's quit this this useless ranting. I'm not whining here : I experienced a problem with the way OpenSSH sets DISPLAY, I notified the developpers, and I even provide a fix. If you don't think this is useful, fine -- but please tell us why -- apart from vague assertions mentioning Sysadmin 101. > "Doctor, it hurts when I do this!" > "Then don't do it." The general Unix philosophy is to give anyone enough rope to hang itself -- and actually there *are* some people who enjoy to get "hurt" that way. If you don't it's OK -- nobody asks you to not set your hostname to an FQDN -- you're safe ;-) Simon From svallet at genoscope.cns.fr Wed Feb 22 04:09:16 2006 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Tue, 21 Feb 2006 18:09:16 +0100 Subject: Status of Bugzilla #1153 In-Reply-To: References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <20060221170241.2e70a0ec.svallet@genoscope.cns.fr> Message-ID: <20060221180916.398f979f.svallet@genoscope.cns.fr> On Tue, 21 Feb 2006 11:20:54 -0500 Carson Gaspar wrote: > --On Tuesday, February 21, 2006 5:02 PM +0100 Simon Vallet > wrote: > > Your "solution" will _break_ many sane setups. In the exact setup you > describe (ssh from a less trusted network to a bastion host, then > connecting to more trusted hosts), I don't _want_ the DISPLAY variable to > have the FQDN of the _external_ interface, as nothing internal will be able > to connect to it. OK, I understand this is a legitimate concern, however you might want to check the routing behaviour on your bastion host : I personally don't see any reason why only one interface of the bastion would be reachable from the trusted side -- we're not talking about forwarding packets to an untrusted zone, of course. > Or give your users init scripts that do whatever DISPLAY/xauth transforms you wish. That was also discussed here, but we found it cleaner to solve the problem at the SSH level instead of some ugly post-treatment hack. > Don't break ssh for the rest of us because you have some religious belief that > hostname() should return an ambiguous name. Of course my purpose wasn't to break ssh for *anybody* -- I never experienced problems reaching the "other" interface(s) of any forwarding host, that's all. Which OS are you using ? Simon From dtucker at zip.com.au Wed Feb 22 07:22:15 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 22 Feb 2006 07:22:15 +1100 Subject: Status of Bugzilla #1153 In-Reply-To: <20060221110301.03215801.svallet@genoscope.cns.fr> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> Message-ID: <43FB7677.3090106@zip.com.au> Simon Vallet wrote: > OK -- we have globally the following setup here : an external ssh > gateway performing X11 forwarding to the internal network -- as this > machine is multihomed, a call to gethostname() returns (correctly IMO) > the short name of the gateway, which is the value used to set DISPLAY > and to add xauth credentials. > > When called, xauth (correctly) qualifies the host name to the one which > resolves to the externally reachable interface of the gateway. DISPLAY, > however, is still unqualified. > > Once on the gateway, if an external user wants to get an X11 client > running on an internal machine in an automated way (i.e. without > connectiong to the target machine and manually set DISPLAY), it will > use the value of DISPLAY set by OpenSSH, which uses the unqualified > hostname. When qualifying this hostname, X11 will use the default > domain, which is the one from the internal network. > > And this is were the problem appears : as xauth credentials > are set using the FQDN of the external interface of the gateway, any > internal X11 client will be denied access to the forwarded X11 server. This seems to be an argument for mimicking what xauth does. Your patch doesn't do that, though. It does something different that happens to have the same result in your environment. As others have pointed out, that may not be true in other environments. An alternative would be to retrieve $DISPLAY from xauth after setting the cookie, ie: xauth> add foo:12 MIT-MAGIC-COOKIE-1 edc426897f65ac50b9ed7f9789b26063 xauth> list foo:12 foo.example.com:12 MIT-MAGIC-COOKIE-1 edc426897f65ac50b9ed7f9789b26063 xauth> then have sshd set $DISPLAY to foo.example.com:12 returned by "xauth list". This would remove the need to second-guess what xauth is going to do. (It would also make sshd a bit more sensitive to the output format of xauth, though.) I don't know how this would work with the HACMP situation that Frank described. (We used OpenSSH with X11 on HACMP clusters at a previous employer and had no problems, but I can't remember what the name resolution setup was.) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Wed Feb 22 07:41:36 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 22 Feb 2006 07:41:36 +1100 Subject: Status of Bugzilla #1153 In-Reply-To: <20060221180916.398f979f.svallet@genoscope.cns.fr> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <20060221170241.2e70a0ec.svallet@genoscope.cns.fr> <20060221180916.398f979f.svallet@genoscope.cns.fr> Message-ID: <43FB7B00.5000803@zip.com.au> Simon Vallet wrote: > OK, I understand this is a legitimate concern, however you might want > to check the routing behaviour on your bastion host : I personally don't > see any reason why only one interface of the bastion would be reachable > from the trusted side -- we're not talking about forwarding packets to > an untrusted zone, of course. I think you're missing the point: there may be *no* route to the external interface's address at all. I've seen networks where there was no default route and all traffic in and out was via bastion hosts. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Wed Feb 22 07:46:06 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 22 Feb 2006 07:46:06 +1100 Subject: Status of Bugzilla #1153 In-Reply-To: <20060221173254.2e8596d9.svallet@genoscope.cns.fr> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <43FB324D.10403@noaa.gov> <68E268D9BE7AD85CF6534013@[192.168.1.2]> <20060221173254.2e8596d9.svallet@genoscope.cns.fr> Message-ID: <43FB7C0E.2000904@zip.com.au> Simon Vallet wrote: > Come on now -- let's quit this this useless ranting. I'm not whining > here : I experienced a problem with the way OpenSSH sets DISPLAY, I > notified the developpers, and I even provide a fix. No, you provided a patch (which is more than many people do, so for that, thank you) but whether or not it's a fix is still indeterminate. > The general Unix philosophy is to give anyone enough rope to hang > itself -- and actually there *are* some people who enjoy to get "hurt" > that way. Sure. But we try to avoid hanging innocent bystanders at the same time :-) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From svallet at genoscope.cns.fr Wed Feb 22 08:22:34 2006 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Tue, 21 Feb 2006 22:22:34 +0100 Subject: Status of Bugzilla #1153 In-Reply-To: <43FB7C0E.2000904@zip.com.au> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <43FB324D.10403@noaa.gov> <68E268D9BE7AD85CF6534013@[192.168.1.2]> <20060221173254.2e8596d9.svallet@genoscope.cns.fr> <43FB7C0E.2000904@zip.com.au> Message-ID: <20060221212234.GA363627@houba.genoscope.cns.fr> On Wed, Feb 22, 2006 at 07:46:06AM +1100, Darren Tucker wrote: > Simon Vallet wrote: > > Come on now -- let's quit this this useless ranting. I'm not whining > > here : I experienced a problem with the way OpenSSH sets DISPLAY, I > > notified the developpers, and I even provide a fix. > > No, you provided a patch (which is more than many people do, so for > that, thank you) but whether or not it's a fix is still indeterminate. Hmmm -- I wasn't aware of this subtle difference -- OK, let's make it a patch, then > > > The general Unix philosophy is to give anyone enough rope to hang > > itself -- and actually there *are* some people who enjoy to get "hurt" > > that way. > > Sure. But we try to avoid hanging innocent bystanders at the same time :-) That goes without saying. From svallet at genoscope.cns.fr Wed Feb 22 08:28:10 2006 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Tue, 21 Feb 2006 22:28:10 +0100 Subject: Status of Bugzilla #1153 In-Reply-To: <43FB7B00.5000803@zip.com.au> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <20060221170241.2e70a0ec.svallet@genoscope.cns.fr> <20060221180916.398f979f.svallet@genoscope.cns.fr> <43FB7B00.5000803@zip.com.au> Message-ID: <20060221212810.GB363627@houba.genoscope.cns.fr> On Wed, Feb 22, 2006 at 07:41:36AM +1100, Darren Tucker wrote: > Simon Vallet wrote: > > OK, I understand this is a legitimate concern, however you might want > > to check the routing behaviour on your bastion host : I personally don't > > see any reason why only one interface of the bastion would be reachable > > from the trusted side -- we're not talking about forwarding packets to > > an untrusted zone, of course. > > I think you're missing the point: there may be *no* route to the > external interface's address at all. I've seen networks where there was > no default route and all traffic in and out was via bastion hosts. I *definitely* think I'm missing something now ;-) How on earth would you route every packet destined to the outside through the bastion without specifying that bastion in a default route (be it static or dynamic) ? Unless you want to list every block except the one containing the external interface in your routing tables... From svallet at genoscope.cns.fr Wed Feb 22 08:40:43 2006 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Tue, 21 Feb 2006 22:40:43 +0100 Subject: Status of Bugzilla #1153 In-Reply-To: <43FB7677.3090106@zip.com.au> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <43FB7677.3090106@zip.com.au> Message-ID: <20060221214043.GC363627@houba.genoscope.cns.fr> On Wed, Feb 22, 2006 at 07:22:15AM +1100, Darren Tucker wrote: > > > >And this is were the problem appears : as xauth credentials > >are set using the FQDN of the external interface of the gateway, any > >internal X11 client will be denied access to the forwarded X11 server. > > This seems to be an argument for mimicking what xauth does. Actually, this is not ;-) -- it's simply an explanation of what we see here > An alternative would be to retrieve $DISPLAY from xauth after setting > the cookie, ie: > > xauth> add foo:12 MIT-MAGIC-COOKIE-1 edc426897f65ac50b9ed7f9789b26063 > xauth> list foo:12 > foo.example.com:12 MIT-MAGIC-COOKIE-1 edc426897f65ac50b9ed7f9789b26063 > xauth> > > then have sshd set $DISPLAY to foo.example.com:12 returned by "xauth > list". This would remove the need to second-guess what xauth is going > to do. (It would also make sshd a bit more sensitive to the output > format of xauth, though.) Well, this would solve the problem that we encounter, and has the advantage of not breaking some existing installs -- as far as I'm concerned, this is fine > I don't know how this would work with the HACMP situation that Frank > described. (We used OpenSSH with X11 on HACMP clusters at a previous > employer and had no problems, but I can't remember what the name > resolution setup was.) Not so sure about this one, however -- this would depend on xauth behaviour Simon From dtucker at zip.com.au Wed Feb 22 09:41:52 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 22 Feb 2006 09:41:52 +1100 Subject: Status of Bugzilla #1153 In-Reply-To: <20060221212810.GB363627@houba.genoscope.cns.fr> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <20060221170241.2e70a0ec.svallet@genoscope.cns.fr> <20060221180916.398f979f.svallet@genoscope.cns.fr> <43FB7B00.5000803@zip.com.au> <20060221212810.GB363627@houba.genoscope.cns.fr> Message-ID: <43FB9730.3030809@zip.com.au> Simon Vallet wrote: > I *definitely* think I'm missing something now ;-) How on earth would you route > every packet destined to the outside through the bastion without specifying > that bastion in a default route (be it static or dynamic) ? That's the point: in such a configuration you don't route any *packets* to the outside at all. Connections get proxied at the TCP or application level, eg via SOCKS, tcprelay, web proxy, mail gateway or similar on the bastion host (which typically has IP forwarding disabled). IP packets destined for addresses not in the internal network result in an ICMP network-unreachable. (Your two-hop X11-over-ssh scheme is an example of this kind of application-level relay; it should be able to work in such an environment but with your proposed change probably won't.) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From svallet at genoscope.cns.fr Wed Feb 22 09:51:17 2006 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Tue, 21 Feb 2006 23:51:17 +0100 Subject: Status of Bugzilla #1153 In-Reply-To: <43FB9730.3030809@zip.com.au> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <20060221170241.2e70a0ec.svallet@genoscope.cns.fr> <20060221180916.398f979f.svallet@genoscope.cns.fr> <43FB7B00.5000803@zip.com.au> <20060221212810.GB363627@houba.genoscope.cns.fr> <43FB9730.3030809@zip.com.au> Message-ID: <20060221225117.GD363627@houba.genoscope.cns.fr> On Wed, Feb 22, 2006 at 09:41:52AM +1100, Darren Tucker wrote: > Simon Vallet wrote: > >I *definitely* think I'm missing something now ;-) How on earth would you > >route > >every packet destined to the outside through the bastion without > >specifying that bastion in a default route (be it static or dynamic) ? > > That's the point: in such a configuration you don't route any *packets* > to the outside at all. Connections get proxied at the TCP or > application level, eg via SOCKS, tcprelay, web proxy, mail gateway or > similar on the bastion host (which typically has IP forwarding disabled). > > IP packets destined for addresses not in the internal network result in > an ICMP network-unreachable. Interesting -- I never thought of implementing such a solution, as application-level proxying and filtering at the gateway seemed enough. This is really nice, I'll give it a try sometime. From dtucker at zip.com.au Wed Feb 22 09:56:49 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 22 Feb 2006 09:56:49 +1100 Subject: Status of Bugzilla #1153 In-Reply-To: <20060221214043.GC363627@houba.genoscope.cns.fr> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <43FB7677.3090106@zip.com.au> <20060221214043.GC363627@houba.genoscope.cns.fr> Message-ID: <43FB9AB1.8010009@zip.com.au> Simon Vallet wrote: > On Wed, Feb 22, 2006 at 07:22:15AM +1100, Darren Tucker wrote: >>> And this is were the problem appears : as xauth credentials >>> are set using the FQDN of the external interface of the gateway, any >>> internal X11 client will be denied access to the forwarded X11 server. >> This seems to be an argument for mimicking what xauth does. > > Actually, this is not ;-) -- it's simply an explanation of what we see here The fundamental problem is that $DISPLAY and the cookie in .Xauthority don't match, right? Also, while your patch works for your typical case, does X11 work if you ssh from the inside to the bastion host? (You'll get your internal address in $DISPLAY but FQDN in .Xauthority, right? Xlib might fudge it to work, though.) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From petesea at bigfoot.com Wed Feb 22 11:21:45 2006 From: petesea at bigfoot.com (Dan Peterson) Date: Tue, 21 Feb 2006 16:21:45 -0800 (Pacific Standard Time) Subject: Kerberos and authorizied_keys Message-ID: How reasonable, acceptable and difficult would it be to "enhance" openssh so authorizations using kerberos (specifically kerberos tickets) consulted the authorized_keys file? And to be a bit more precise... consulted authorized_keys so it could utilize any "options" (eg. from=, command=, environment=, etc) that may be present? I'm willing to make custom changes, but would prefer if this was standard behavior, so I thought I'd check to see how likely a change like this would have of getting put in the standard source. My plan (and I haven't really looked at the source) would be to add a new "key type"... say "ssh-krb" where the "key" would be the kerberos principal. Would having this new key-type break anything for openssh clients that don't recognize it? Or is the code smart enough just to ignore unknown key-types? The main purpose for this so we can use ssh as a tunnel for CVS and Subversion clients. We need to use kerberos for authentication and we need to restrict the commands the user can execute. The authorized_keys "command=" facility seems to be the perfect solution except it doesn't work with kerberos. I'm certainly willing to consider alternate solutions... especially if they don't involve a custom change to openssh. But at the present time the best alternative I've come up with is forcing all the users to have a custom login shell and that's not really going to work. From carson at taltos.org Wed Feb 22 11:59:49 2006 From: carson at taltos.org (Carson Gaspar) Date: Tue, 21 Feb 2006 19:59:49 -0500 Subject: Status of Bugzilla #1153 In-Reply-To: <20060221180916.398f979f.svallet@genoscope.cns.fr> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <20060221170241.2e70a0ec.svallet@genoscope.cns.fr> <20060221180916.398f979f.svallet@genoscope.cns.fr> Message-ID: --On Tuesday, February 21, 2006 06:09:16 PM +0100 Simon Vallet wrote: > Of course my purpose wasn't to break ssh for *anybody* -- I never > experienced problems reaching the "other" interface(s) of any > forwarding host, that's all. Which OS are you using ? It's not an OS issue, it's a routing issue. External networks are not advertised to Internal servers. And if they were, it wouldn't be with the ssh proxy bastion as the route. Of course this is fixable by doing some static host route injection, but that's a really evil solution to having the wrong fqdn being used. If you really want to follow the "give the user enough rope" maxim, what you'd want is Yet Another Config Option to sshd that allows you to specify the X11 host name. But I doubt the maintainers would be happy with that, given their (not unjustified) resistance to more knobs. I still think that your patch, as proposed, is a Very Bad Idea. And that you'd make your life much easier for yourself if you'd just make hostname() return an internally resolvable/reachable FQDN. Or if you're dead set against that, just transmogrify DISPLAY in the init scripts. -- Carson From Jefferson.Ogata at noaa.gov Wed Feb 22 12:27:39 2006 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Tue, 21 Feb 2006 20:27:39 -0500 Subject: Status of Bugzilla #1153 In-Reply-To: <68E268D9BE7AD85CF6534013@[192.168.1.2]> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <43FB324D.10403@noaa.gov> <68E268D9BE7AD85CF6534013@[192.168.1.2]> Message-ID: <43FBBE0B.60104@noaa.gov> On 02/21/2006 11:10 AM, Carson Gaspar wrote: > --On Tuesday, February 21, 2006 10:31 AM -0500 Jefferson Ogata > wrote: >>On 02/21/2006 10:10 AM, Carson Gaspar wrote: >>>No. gethostname() needs to return the (or a) FQDN of the server. >>>Anything else is just broken and begging for trouble. This is sysadmin >>>101. >> >>Not everyone agrees with that opinion. > > I've never met anyone who disagreed who had a sane reason not use the FQDN > (we're still using NIS for hostnames is not sane...). Would you like to be > the first? I'd be extremely interested in your reasoning why the FQDN isn't > the Right Thing To DO. First of all, if you think DNS is fundamentally any more secure than NIS, you're unexpectedly naive. I've met you, Carson, so I doubt you really think that, but here you are pooh-poohing NIS while touting a DNS FQDN as somehow more precious and perfect. I'm not sure I understand. As for the Right Thing to DO, I go with what's appropriate in context. If the system is exposed to the Internet I might go with FQDN. If it's on a private network with split DNS and only one DNS zone in view, I might go with short name. I prefer short names in prompts, window titles, and the like, so if there's no compelling reason for using an FQDN, I may well go with short name. That depends on the OS as well. Conversely, you might be asked to show why in your reasoning FQDN is magically blessed and the One True Way for gethostname(). :^) >>DNS is just a namespace, after all. It isn't the be-all, end-all of >>namespaces, especially given how easy it is to spoof. Consider that >>sysadmin 240. :^) > > True, but he's using DNS as his namespace internally, and complaining about > ambiguous shortname->FQDN mapping (and hasn't put "shortname." into DNS, so > he's not doing weird advanced things). "Doctor, it hurts when I do this!" > "Then don't do it." And what other namespace is deployed (ignoring NIS, > which is just evil and wrong)? Your other remarks about the particular setup under consideration may be true. What I don't follow is what the objection to sshing to target hosts is. I see no performance degradation in X11 over ssh, and over low bandwidth connections I'll see performance improvements thanks to compression. On the other hand, I have written programs to capture keystrokes from monitored X11 connections, and I wouldn't run X over a cleartext connection under any circumstance. Other namespaces: well /etc/hosts is the obvious one. Less obvious, LDAP, which, over SSL, is substantially more secure than DNS. AFAIK LDAP DNs are not widely supported by IP applications, including ssh, though. Widely deployed, though of much broader scope and not so applicable to this context: ASN.1. Someday we'll all be running DNSSEC and things will be different. >>One thing I don't understand: my experience is that ssh uses >>localhost:x.0 for the DISPLAY variable. Am I on crack? > > Read your sshd config file - you have X11UseLocalhost set. Indeed I do. Forgot about that. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From djm at mindrot.org Wed Feb 22 13:01:05 2006 From: djm at mindrot.org (Damien Miller) Date: Wed, 22 Feb 2006 13:01:05 +1100 (EST) Subject: Kerberos and authorizied_keys In-Reply-To: References: Message-ID: On Tue, 21 Feb 2006, Dan Peterson wrote: > How reasonable, acceptable and difficult would it be to "enhance" openssh > so authorizations using kerberos (specifically kerberos tickets) consulted > the authorized_keys file? And to be a bit more precise... consulted > authorized_keys so it could utilize any "options" (eg. from=, command=, > environment=, etc) that may be present? > > I'm willing to make custom changes, but would prefer if this was standard > behavior, so I thought I'd check to see how likely a change like this > would have of getting put in the standard source. > > My plan (and I haven't really looked at the source) would be to add a new > "key type"... say "ssh-krb" where the "key" would be the kerberos > principal. There was some discussion of this a couple of years back when the GSSAPI code landed IIRC and there may have even been a patch. I didn't want to look at it until the dust had settled (which I think it has). If you want to pursue this, then please try to keep your changes as minimal and non-intrusive to non-GSSAPI/Kerberos related code as possible. It would be fair to say that we greatly favour stability of OpenSSH over new features at this point. > Would having this new key-type break anything for openssh clients that > don't recognize it? Or is the code smart enough just to ignore unknown > key-types? If the key type only existed in the authorized_keys file, then no - sshd ignores lines in that file that it doesn't understand. > The main purpose for this so we can use ssh as a tunnel for CVS and > Subversion clients. We need to use kerberos for authentication and we > need to restrict the commands the user can execute. The authorized_keys > "command=" facility seems to be the perfect solution except it doesn't > work with kerberos. One alternative is to create accounts with a login shell that forces them to use your chosen command, and to allocate principles to these accounts. -d From f_mohr at yahoo.de Wed Feb 22 20:54:23 2006 From: f_mohr at yahoo.de (Frank Mohr) Date: Wed, 22 Feb 2006 10:54:23 +0100 Subject: Status of Bugzilla #1153 In-Reply-To: <43FB7C0E.2000904@zip.com.au> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <43FB324D.10403@noaa.gov> <68E268D9BE7AD85CF6534013@[192.168.1.2]> <20060221173254.2e8596d9.svallet@genoscope.cns.fr> <43FB7C0E.2000904@zip.com.au> Message-ID: <43FC34CF.4010604@yahoo.de> Darren Tucker wrote: > Simon Vallet wrote: > >>Come on now -- let's quit this this useless ranting. I'm not whining >>here : I experienced a problem with the way OpenSSH sets DISPLAY, I >>notified the developpers, and I even provide a fix. > > > No, you provided a patch (which is more than many people do, so for > that, thank you) i just compared the patch on bugzilla with the patch i'm using on AIX, Solaris and Linux since openssh 2.* without problems. i'm setting DISPLAY to the ip address from get_local_ipaddr(packet_get_connection_in()) without getting the DNS name for this ip > but whether or not it's a fix is still indeterminate. Simons reason for that patch might not be so common, but i see some other reasons to set DISPLAY that way. - the only interface you can be sure it's up of on a system is the one thats used to connect (all others might be down) - standby cluster systems sometimes have the interface with the hostname down (thats why i did my patch as explained in another mail on that thread) - our installations are done over a interface in a admin network, while the hostname of the systems is on a interface in a service network. in some cases, the service interface is configured, but down until the installation and configuration is finished frank ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de From svallet at genoscope.cns.fr Wed Feb 22 20:55:55 2006 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Wed, 22 Feb 2006 10:55:55 +0100 Subject: Status of Bugzilla #1153 In-Reply-To: <43FBBE0B.60104@noaa.gov> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <43FB324D.10403@noaa.gov> <68E268D9BE7AD85CF6534013@[192.168.1.2]> <43FBBE0B.60104@noaa.gov> Message-ID: <20060222105555.7825e413.svallet@genoscope.cns.fr> On Tue, 21 Feb 2006 20:27:39 -0500 "Jefferson Ogata" wrote: > I see no performance degradation in X11 over ssh, and over low > bandwidth connections I'll see performance improvements thanks to > compression. On the other hand, I have written programs to capture > keystrokes from monitored X11 connections, and I wouldn't run X over a > cleartext connection under any circumstance. We are well aware of the risk of using plain X11 -- but this was a choice we made : trust me, on some of our machines, bloated Java GUIs are simply not useable over SSH -- and yes, some of our users need those. > Someday we'll all be running DNSSEC and things will be different. and also IPsec-enabled IPv6 ;-) I think those times are not coming very soon, sadly. From sxw at inf.ed.ac.uk Wed Feb 22 21:04:40 2006 From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk) Date: Wed, 22 Feb 2006 10:04:40 +0000 (GMT) Subject: Kerberos and authorizied_keys In-Reply-To: References: Message-ID: On Wed, 22 Feb 2006, Damien Miller wrote: > On Tue, 21 Feb 2006, Dan Peterson wrote: > > There was some discussion of this a couple of years back when the GSSAPI > code landed IIRC and there may have even been a patch. I didn't want to > look at it until the dust had settled (which I think it has). Nico Williams produced a patch to do this. I'll see if I've still got a copy. Simon. From dtucker at zip.com.au Wed Feb 22 21:18:33 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 22 Feb 2006 21:18:33 +1100 Subject: Status of Bugzilla #1153 In-Reply-To: <43FC34CF.4010604@yahoo.de> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <43FB324D.10403@noaa.gov> <68E268D9BE7AD85CF6534013@[192.168.1.2]> <20060221173254.2e8596d9.svallet@genoscope.cns.fr> <43FB7C0E.2000904@zip.com.au> <43FC34CF.4010604@yahoo.de> Message-ID: <43FC3A79.9010105@zip.com.au> Frank Mohr wrote: > Simons reason for that patch might not be so common, > but i see some other reasons to set DISPLAY that way. > > - the only interface you can be sure it's up of on a > system is the one thats used to connect (all others might be down) Any reason you don't use the loopback interface (X11UseLocalhost)? It's usually up (admittedly it's not guaranteed, though). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From svallet at genoscope.cns.fr Wed Feb 22 21:13:03 2006 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Wed, 22 Feb 2006 11:13:03 +0100 Subject: Status of Bugzilla #1153 In-Reply-To: References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <20060221170241.2e70a0ec.svallet@genoscope.cns.fr> <20060221180916.398f979f.svallet@genoscope.cns.fr> Message-ID: <20060222111303.2854bc9c.svallet@genoscope.cns.fr> On Tue, 21 Feb 2006 19:59:49 -0500 Carson Gaspar wrote: > If you really want to follow the "give the user enough rope" maxim, what > you'd want is Yet Another Config Option to sshd that allows you to specify > the X11 host name. In fact I think this _is_ a very good idea > But I doubt the maintainers would be happy with that, > given their (not unjustified) resistance to more knobs. I doubt it also (and I can understand it), but this is not the topic for now. > I still think that your patch, as proposed, is a Very Bad Idea. And that > you'd make your life much easier for yourself if you'd just make hostname() > return an internally resolvable/reachable FQDN. Or if you're dead set > against that, just transmogrify DISPLAY in the init scripts. I see that there is strong opposition to this patch, because it breaks your setup, probably other ones too, and this is clearly undesirable. We agree on this -- however I still think there is a bug, and that it should be fixed : Darren suggested an interesting alternative -- I think we might agree on this one. I will repeat it once again: my interest is not in breaking other peoples setup, it is on getting this bug fixed, so we (and others) don't have to manually patch every single release. Simon From dtucker at zip.com.au Wed Feb 22 23:58:07 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 22 Feb 2006 23:58:07 +1100 Subject: Status of Bugzilla #1153 In-Reply-To: <20060222111303.2854bc9c.svallet@genoscope.cns.fr> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <20060221170241.2e70a0ec.svallet@genoscope.cns.fr> <20060221180916.398f979f.svallet@genoscope.cns.fr> <20060222111303.2854bc9c.svallet@genoscope.cns.fr> Message-ID: <20060222125807.GA6714@gate.dtucker.net> On Wed, Feb 22, 2006 at 11:13:03AM +0100, Simon Vallet wrote: > I see that there is strong opposition to this patch, because it breaks > your setup, probably other ones too, and this is clearly undesirable. > We agree on this -- however I still think there is a bug, and that it > should be fixed : Darren suggested an interesting alternative -- I > think we might agree on this one. Here's a quick patch that implements what was described. It's not nice in places, but should prove whether or not it works as expected. BTW, we don't want it for X11UseLocalhost=yes as it will cause this: $ echo $DISPLAY gate.dtucker.net/unix:13 $ xterm _X11TransSocketUNIXConnect: Can't connect: errno = 2 Index: session.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/session.c,v retrieving revision 1.313 diff -u -p -r1.313 session.c --- session.c 7 Feb 2006 23:17:44 -0000 1.313 +++ session.c 22 Feb 2006 12:54:15 -0000 @@ -1158,7 +1158,7 @@ static void do_rc_files(Session *s, const char *shell) { FILE *f = NULL; - char cmd[1024]; + char cmd[1024], dpy[1024]; int do_xauth; struct stat st; @@ -1213,10 +1213,39 @@ do_rc_files(Session *s, const char *shel fprintf(f, "add %s %s %s\n", s->auth_display, s->auth_proto, s->auth_data); - pclose(f); + if (pclose(f) != 0) + error("%s failed.", options.xauth_location); } else { fprintf(stderr, "Could not run %s\n", cmd); + return; + } + if (options.x11_use_localhost) + return; + snprintf(cmd, sizeof cmd, "%s -q list %s", + options.xauth_location, s->auth_display); + f = popen(cmd, "r"); + if (f) { + if (fgets(cmd, sizeof(cmd), f) == NULL) { + error("Could not read xauth data: %s", + strerror(errno)); + } else { + if (sscanf(cmd, "%1024s %*s %*s", dpy) != 1) { + error("Bad xauth data"); + } else { + debug("xauth returned display %s", + s->display); + xfree(s->display); + s->display = xstrdup(dpy); + setenv("DISPLAY", s->display, 1); + } + } + if (pclose(f) != 0) + error("%s failed.", options.xauth_location); + } else { + fprintf(stderr, "Could not run %s list\n", + cmd); + return; } } } -- 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 svallet at genoscope.cns.fr Thu Feb 23 03:28:53 2006 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Wed, 22 Feb 2006 17:28:53 +0100 Subject: Status of Bugzilla #1153 In-Reply-To: <20060222125807.GA6714@gate.dtucker.net> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <20060221170241.2e70a0ec.svallet@genoscope.cns.fr> <20060221180916.398f979f.svallet@genoscope.cns.fr> <20060222111303.2854bc9c.svallet@genoscope.cns.fr> <20060222125807.GA6714@gate.dtucker.net> Message-ID: <20060222172854.59b89ccb.svallet@genoscope.cns.fr> On Wed, 22 Feb 2006 23:58:07 +1100 Darren Tucker wrote: > Here's a quick patch that implements what was described. It's not nice > in places, but should prove whether or not it works as expected. Thanks -- applied against 4.3p2 and tested : it does work as expected, i.e. sets DISPLAY according to xauth choices, and therefore does solve the forwarding problem :-) It seems this breaks something, however, as regression tests are failing while testing the agent : run test agent.sh ... ssh-add -l via agent fwd proto 1 failed (exit code 0) agent fwd proto 1 failed (exit code 0) ssh-add -l via agent fwd proto 2 failed (exit code 0) agent fwd proto 2 failed (exit code 0) failed simple agent test gmake[1]: *** [t-exec] Error 1 gmake[1]: Leaving directory `/env/export/c/fc1d67/proj18/local_src/security/openssh/openssh-4.3p2-darren1/regress' gmake: *** [tests] Error 2 However, I'm not sure this is specific to the patch, and I'm recompiling a vanilla 4.3p2 right now to check this. Regression tests for 4.2p1 and 20060208 ran fine on this same machine (Tru64 5.1A). Simon From miklos at szeredi.hu Thu Feb 23 02:49:46 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Wed, 22 Feb 2006 16:49:46 +0100 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: <43D8999C.7040900@mindrot.org> (message from Damien Miller on Thu, 26 Jan 2006 20:42:52 +1100) References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <43D8999C.7040900@mindrot.org> Message-ID: > We can look at turning Nagle off unconditionally after we get 4.3 out > the door. Just a reminder. http://bugzilla.mindrot.org/show_bug.cgi?id=556 I've tested the patch supplied in the bugreport, and it fixes the issue. Could you please apply it? Thanks, Miklos From svallet at genoscope.cns.fr Thu Feb 23 04:33:54 2006 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Wed, 22 Feb 2006 18:33:54 +0100 Subject: Status of Bugzilla #1153 In-Reply-To: <20060222172854.59b89ccb.svallet@genoscope.cns.fr> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <20060221170241.2e70a0ec.svallet@genoscope.cns.fr> <20060221180916.398f979f.svallet@genoscope.cns.fr> <20060222111303.2854bc9c.svallet@genoscope.cns.fr> <20060222125807.GA6714@gate.dtucker.net> <20060222172854.59b89ccb.svallet@genoscope.cns.fr> Message-ID: <20060222183354.1046675b.svallet@genoscope.cns.fr> On Wed, 22 Feb 2006 17:28:53 +0100 I wrote: > It seems this breaks something, however, as regression tests are > failing while testing the agent : [...] > However, I'm not sure this is specific to the patch, and I'm recompiling > a vanilla 4.3p2 right now to check this. Regression tests for 4.2p1 and > 20060208 ran fine on this same machine (Tru64 5.1A). OK, my bad -- vanilla 4.3p2 exhibits the same problem, so this isn't patch-specific. From cei at YourShop.com Thu Feb 23 04:59:51 2006 From: cei at YourShop.com (Claudio Eichenberger) Date: Wed, 22 Feb 2006 18:59:51 +0100 Subject: warning about net/if_tap.h & login_cap.h Message-ID: <20060222175951.GB34574@wks.ch> Hi I've encountered this: configure: WARNING: net/if_tap.h: present but cannot be compiled configure: WARNING: net/if_tap.h: check for missing prerequisite headers? configure: WARNING: net/if_tap.h: see the Autoconf documentation configure: WARNING: net/if_tap.h: section "Present But Cannot Be Compiled" configure: WARNING: net/if_tap.h: proceeding with the preprocessor's result configure: WARNING: net/if_tap.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## configure: WARNING: login_cap.h: present but cannot be compiled configure: WARNING: login_cap.h: check for missing prerequisite headers? configure: WARNING: login_cap.h: see the Autoconf documentation configure: WARNING: login_cap.h: section "Present But Cannot Be Compiled" configure: WARNING: login_cap.h: proceeding with the preprocessor's result configure: WARNING: login_cap.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## FreeBSD .... 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Wed Feb 22 16:52:18 UTC 2006 root at ....:/usr/src/sys/amd64/compile/MYKERNEL amd64 # gcc -v Using built-in specs. Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 3.4.4 [FreeBSD] 20050518 I didn't use the ports version but compiled it myself. Releases: zlib-1.2.3 openssl-0.9.8a openssh-4.3p2 Thanks for your help Claudio -- Claudio Eichenberger Tel +41 21 67 17 111 Mob +41 79 34 72 100 Claudio at yourshop.com Http://YourShop.com/ "Come to me all who are weary and burdened and I will give you rest" -- Jesus Christ From tim at multitalents.net Thu Feb 23 06:24:12 2006 From: tim at multitalents.net (Tim Rice) Date: Wed, 22 Feb 2006 11:24:12 -0800 (PST) Subject: warning about net/if_tap.h & login_cap.h In-Reply-To: <20060222175951.GB34574@wks.ch> References: <20060222175951.GB34574@wks.ch> Message-ID: On Wed, 22 Feb 2006, Claudio Eichenberger wrote: > Hi > > I've encountered this: > > configure: WARNING: net/if_tap.h: present but cannot be compiled > configure: WARNING: net/if_tap.h: check for missing prerequisite headers? [snip] > configure: WARNING: login_cap.h: present but cannot be compiled > configure: WARNING: login_cap.h: check for missing prerequisite headers? [snip] Look at your config.log to see why it failed. Like the WARNING said, there is probably some system header that needs to be included in the test. > FreeBSD .... 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Wed Feb 22 16:52:18 UTC 2006 root at ....:/usr/src/sys/amd64/compile/MYKERNEL amd64 > > # gcc -v > Using built-in specs. > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 3.4.4 [FreeBSD] 20050518 > > I didn't use the ports version but compiled it myself. > > Releases: > > zlib-1.2.3 > openssl-0.9.8a > openssh-4.3p2 > > Thanks for your help > > Claudio > -- Tim Rice Multitalents tim at multitalents.net From carson at taltos.org Thu Feb 23 08:19:08 2006 From: carson at taltos.org (Carson Gaspar) Date: Wed, 22 Feb 2006 16:19:08 -0500 Subject: Status of Bugzilla #1153 In-Reply-To: <20060222125807.GA6714@gate.dtucker.net> References: <20060220154923.5a69e446.svallet@genoscope.cns.fr> <20060220201249.GA17657@gate.dtucker.net> <20060221110301.03215801.svallet@genoscope.cns.fr> <03388ACE1436421FC8A3AAEC@[192.168.1.2]> <20060221170241.2e70a0ec.svallet@genoscope.cns.fr> <20060221180916.398f979f.svallet@genoscope.cns.fr> <20060222111303.2854bc9c.svallet@genoscope.cns.fr> <20060222125807.GA6714@gate.dtucker.net> Message-ID: <185D3407ED7F07638F5226A0@gaspac.ny.ficc.gs.com> --On Wednesday, February 22, 2006 11:58:07 PM +1100 Darren Tucker wrote: > On Wed, Feb 22, 2006 at 11:13:03AM +0100, Simon Vallet wrote: >> I see that there is strong opposition to this patch, because it breaks >> your setup, probably other ones too, and this is clearly undesirable. >> We agree on this -- however I still think there is a bug, and that it >> should be fixed : Darren suggested an interesting alternative -- I >> think we might agree on this one. > > Here's a quick patch that implements what was described. It's not nice > in places, but should prove whether or not it works as expected. Since I've been mouthing off about this, I want to say for the record that I have no objections to Darren's proposal (assuming no issues show up in testing). -- Carson From tryponraj at gmail.com Thu Feb 23 18:25:13 2006 From: tryponraj at gmail.com (ponraj) Date: Thu, 23 Feb 2006 12:55:13 +0530 Subject: Questions about sshd_config man page and comments in the file Message-ID: <006801c6384a$4b8dd700$180110ac@pomco> Hi , I have two problems when i went through a) the man page of sshd_config and b) the comments quoted in sshd_config file itself. They are given below. a) >From the man page of sshd_config: "If UsePAM is enabled, you will not be able to run sshd(8) as a non-privileged user." I changed the permission of the hostkeys to a non-privileged user and tried to run sshd alongwith "UsePAM=yes" in one of the non-privileged ports . sshd was successfully initiated but it failed to handle client's connection request. Is this the behaviour highlighted in the man page ? b)Comments in sshd_config file: # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication mechanism. # Depending on your PAM configuration, this may bypass the setting of # PasswordAuthentication, PermitEmptyPasswords, and # "PermitRootLogin without-password". If you just want the PAM account and # session checks to run without PAM authentication, then enable this but set # ChallengeResponseAuthentication=no sshd has been started along with the following command-line configuration settings. # /opt/ssh/sbin/sshd -o "usepam yes" -o "challengeresponseauthentication no" -o "kerberosauthentication no" -o "passwordauthentication yes" -o "kerberosorlocalpasswd no" Authentication ,Password management modules were set to "libpam_krb5.so.1" and Session,Account management modules were set to "libpam_unix.so.1" in pam configuation file. During ssh conneciton, Kerberos password got succeeded when the ssh client was prompted for password. This violates the steps commented in sshd_config file.Can anyone clarify this ? I am using OpenSSH-4.2p1 compiled with OpenSSL 0.9.7i. -- Ponraj M From dtucker at zip.com.au Thu Feb 23 20:13:08 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 23 Feb 2006 20:13:08 +1100 Subject: Questions about sshd_config man page and comments in the file In-Reply-To: <006801c6384a$4b8dd700$180110ac@pomco> References: <006801c6384a$4b8dd700$180110ac@pomco> Message-ID: <20060223091308.GA22897@gate.dtucker.net> On Thu, Feb 23, 2006 at 12:55:13PM +0530, ponraj wrote: > Hi , > > I have two problems when i went through a) the man page of sshd_config and > b) the comments quoted in sshd_config file itself. They are given below. > > a) > >From the man page of sshd_config: > "If UsePAM is enabled, you will not be able to run sshd(8) as a > non-privileged user." > > I changed the permission of the hostkeys to a non-privileged user and tried > to run sshd alongwith "UsePAM=yes" in one of the non-privileged ports . sshd > was successfully initiated but it failed to handle client's connection > request. Is this the behaviour highlighted in the man page ? Yes. PAM typically needs root privs and is used for more than just authentication. > b)Comments in sshd_config file: > > # Set this to 'yes' to enable PAM authentication, account processing, > # and session processing. If this is enabled, PAM authentication will > # be allowed through the ChallengeResponseAuthentication mechanism. > # Depending on your PAM configuration, this may bypass the setting of > # PasswordAuthentication, PermitEmptyPasswords, and > # "PermitRootLogin without-password". If you just want the PAM > account and > # session checks to run without PAM authentication, then enable this > but set > # ChallengeResponseAuthentication=no > > sshd has been started along with the following command-line configuration > settings. > # /opt/ssh/sbin/sshd -o "usepam yes" -o > "challengeresponseauthentication no" -o "kerberosauthentication no" -o > "passwordauthentication yes" -o "kerberosorlocalpasswd no" > Authentication ,Password management modules were set to "libpam_krb5.so.1" > and Session,Account management modules were set to "libpam_unix.so.1" in pam > configuation file. > > During ssh conneciton, Kerberos password got succeeded when the ssh client > was prompted for password. This violates the steps commented in sshd_config > file.Can anyone clarify this ? The comment in the example config file is outdated and should be fixed. PasswordAuthentication uses PAM in recent versions (>=3.9p1 from memory). -- 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 Feb 23 20:28:57 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 23 Feb 2006 20:28:57 +1100 Subject: Questions about sshd_config man page and comments in the file In-Reply-To: <20060223091308.GA22897@gate.dtucker.net> References: <006801c6384a$4b8dd700$180110ac@pomco> <20060223091308.GA22897@gate.dtucker.net> Message-ID: <20060223092857.GB23215@gate.dtucker.net> On Thu, Feb 23, 2006 at 08:13:08PM +1100, Darren Tucker wrote: > > b)Comments in sshd_config file: [...] > The comment in the example config file is outdated and should be fixed. Does this help clear up the confusion? Index: sshd_config =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/sshd_config,v retrieving revision 1.74 diff -u -p -r1.74 sshd_config --- sshd_config 13 Dec 2005 08:29:03 -0000 1.74 +++ sshd_config 23 Feb 2006 09:26:42 -0000 @@ -71,12 +71,13 @@ # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will -# be allowed through the ChallengeResponseAuthentication mechanism. -# Depending on your PAM configuration, this may bypass the setting of -# PasswordAuthentication, PermitEmptyPasswords, and -# "PermitRootLogin without-password". If you just want the PAM account and -# session checks to run without PAM authentication, then enable this but set -# ChallengeResponseAuthentication=no +# be allowed through the ChallengeResponseAuthentication and +# PasswordAuthentication. Depending on your PAM configuration, +# PAM authentication via ChallengeResponseAuthentication may bypass +# the setting of "PermitRootLogin without-password". +# If you just want the PAM account and session checks to run without +# PAM authentication, then enable this but set PasswordAuthentication +# and ChallengeResponseAuthentication to 'no'. #UsePAM no #AllowTcpForwarding yes Index: sshd_config.5 =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/sshd_config.5,v retrieving revision 1.53 diff -u -p -r1.53 sshd_config.5 --- sshd_config.5 3 Jan 2006 07:47:31 -0000 1.53 +++ sshd_config.5 23 Feb 2006 09:27:42 -0000 @@ -677,7 +677,10 @@ If set to .Dq yes this will enable PAM authentication using .Cm ChallengeResponseAuthentication -and PAM account and session module processing for all authentication types. +and +.Cm PasswordAuthentication +in addition to PAM account and session module processing for all +authentication types. .Pp Because PAM challenge-response authentication usually serves an equivalent role to password authentication, you should disable either -- 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 tryponraj at gmail.com Thu Feb 23 21:27:54 2006 From: tryponraj at gmail.com (ponraj) Date: Thu, 23 Feb 2006 15:57:54 +0530 Subject: Questions about sshd_config man page and comments in the file References: <006801c6384a$4b8dd700$180110ac@pomco><20060223091308.GA22897@gate.dtucker.net> <20060223092857.GB23215@gate.dtucker.net> Message-ID: <00c101c63863$d19a0e90$180110ac@pomco> Yes.This sort out the confusion. Thanks for the fix. -- M.P ----- Original Message ----- From: "Darren Tucker" To: "ponraj" Cc: Sent: Thursday, February 23, 2006 2:58 PM Subject: Re: Questions about sshd_config man page and comments in the file > On Thu, Feb 23, 2006 at 08:13:08PM +1100, Darren Tucker wrote: >> > b)Comments in sshd_config file: > [...] >> The comment in the example config file is outdated and should be fixed. > > Does this help clear up the confusion? > > Index: sshd_config > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/sshd_config,v > retrieving revision 1.74 > diff -u -p -r1.74 sshd_config > --- sshd_config 13 Dec 2005 08:29:03 -0000 1.74 > +++ sshd_config 23 Feb 2006 09:26:42 -0000 > @@ -71,12 +71,13 @@ > > # Set this to 'yes' to enable PAM authentication, account processing, > # and session processing. If this is enabled, PAM authentication will > -# be allowed through the ChallengeResponseAuthentication mechanism. > -# Depending on your PAM configuration, this may bypass the setting of > -# PasswordAuthentication, PermitEmptyPasswords, and > -# "PermitRootLogin without-password". If you just want the PAM account > and > -# session checks to run without PAM authentication, then enable this but > set > -# ChallengeResponseAuthentication=no > +# be allowed through the ChallengeResponseAuthentication and > +# PasswordAuthentication. Depending on your PAM configuration, > +# PAM authentication via ChallengeResponseAuthentication may bypass > +# the setting of "PermitRootLogin without-password". > +# If you just want the PAM account and session checks to run without > +# PAM authentication, then enable this but set PasswordAuthentication > +# and ChallengeResponseAuthentication to 'no'. > #UsePAM no > > #AllowTcpForwarding yes > Index: sshd_config.5 > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/sshd_config.5,v > retrieving revision 1.53 > diff -u -p -r1.53 sshd_config.5 > --- sshd_config.5 3 Jan 2006 07:47:31 -0000 1.53 > +++ sshd_config.5 23 Feb 2006 09:27:42 -0000 > @@ -677,7 +677,10 @@ If set to > .Dq yes > this will enable PAM authentication using > .Cm ChallengeResponseAuthentication > -and PAM account and session module processing for all authentication > types. > +and > +.Cm PasswordAuthentication > +in addition to PAM account and session module processing for all > +authentication types. > .Pp > Because PAM challenge-response authentication usually serves an equivalent > role to password authentication, you should disable either > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From jan.vejvalka at lfmotol.cuni.cz Sun Feb 26 03:41:42 2006 From: jan.vejvalka at lfmotol.cuni.cz (Jan Vejvalka) Date: Sat, 25 Feb 2006 17:41:42 +0100 Subject: scp doesn't run in jail anymore Message-ID: <440088C6.9060009@lfmotol.cuni.cz> Hi *, in Slackware 10.2, under scponly 4.6 chrooted shell, scp from openssh 4.2p1 (scp.c,v 1.125 2005/07/27 10:39:03 dtucker) runs fine. scp from openssh 4.3p1 (scp.c,v 1.130 2006/01/31 10:35:43 djm), however, does not start (or maybe does, but doesn't report to my WinSCP client). Under bash, both versions run fine. Any idea / help ? I'm ready to do any further testing / experiments. Thanks, Jan From yusuke at cs.nyu.edu Mon Feb 27 07:00:15 2006 From: yusuke at cs.nyu.edu (Yusuke Shinyama) Date: Sun, 26 Feb 2006 15:00:15 -0500 Subject: NFS via VPN stuck after a certain amount of transfer Message-ID: <20060226200015.8177.11688.yusuke@mango.cs.nyu.edu> Hello, I'm testing NFS via VPN on openssh-4.3p2 and experienced occational glitches. When I tried to copy a huge directory, sometimes the VPN connection was stuck and the tun interface stopped responding. The underlying network connection was still alive. When I quit the client and reconnect, it starts working again. More concretely, I made a connection from a Linux box to a FreeBSD box via a cable modem. Both are running openssh-4.3p2 client/server and enabled for point-to-point tunneling. Then I mounted the remote directory via NFS with tcp and intr option. Everything worked fine so far. Then I tried to "cp -Rp /mnt/remote/linux-2.4.31 /local". After the directory is partially transferred, the cp process stopped and ping to the remote host (via tun) didn't respond. But this only happens occationaly. For smaller directories, the copy finishes without any problem. I've also tried the same thing with -v -v option for the client and seen the following output: ... debug2: channel 1: window 64688 sent adjust 66384 debug2: channel 1: window 64936 sent adjust 66136 debug2: channel 1: window 64272 sent adjust 66800 debug2: channel 1: window 64100 sent adjust 66972 debug2: channel 1: rcvd adjust 247216 I noticed this "rcvd" number that is ocasinally displayed kept growing. But I'm not sure if this is a problem of ssh/sshd or NFS. How to diagnose this? I am happy to do further testing. Thank you very much, Yusuke From drathi at informatica.com Mon Feb 27 23:02:15 2006 From: drathi at informatica.com (Rathi, Dinesh) Date: Mon, 27 Feb 2006 17:32:15 +0530 Subject: Openssh src - 64 bit clean Message-ID: <02E7FA106DF5944BB0571C25A9243DE628E0F0@in23ex01.informatica.com> Hi ??????????? I wanted to know if openssh src is 64 bit clean? I need to use it on sun 64/ aix 64/ linux 64 and hp-ipf 64 bit platforms. Has anyone tried it on any of these platforms? Thanks Dinesh From gert at greenie.muc.de Tue Feb 28 00:03:39 2006 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 27 Feb 2006 14:03:39 +0100 Subject: Openssh src - 64 bit clean In-Reply-To: <02E7FA106DF5944BB0571C25A9243DE628E0F0@in23ex01.informatica.com> References: <02E7FA106DF5944BB0571C25A9243DE628E0F0@in23ex01.informatica.com> Message-ID: <20060227130339.GO22955@greenie.muc.de> Hi, On Mon, Feb 27, 2006 at 05:32:15PM +0530, Rathi, Dinesh wrote: > ??????????? I wanted to know if openssh src is 64 bit clean? I > need to use it on sun 64/ aix 64/ linux 64 and hp-ipf 64 bit > platforms. Has anyone tried it on any of these platforms? Works for me on AIX and on NetBSD/Sparc64. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From svallet at genoscope.cns.fr Tue Feb 28 00:19:25 2006 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Mon, 27 Feb 2006 14:19:25 +0100 Subject: Openssh src - 64 bit clean In-Reply-To: <02E7FA106DF5944BB0571C25A9243DE628E0F0@in23ex01.informatica.com> References: <02E7FA106DF5944BB0571C25A9243DE628E0F0@in23ex01.informatica.com> Message-ID: <20060227141925.12ac231b.svallet@genoscope.cns.fr> On Mon, 27 Feb 2006 17:32:15 +0530 "Rathi, Dinesh" wrote: > Hi > ??????????? I wanted to know if openssh src is 64 bit clean? I need to use it on sun 64/ aix 64/ linux 64 and hp-ipf 64 bit platforms. Has anyone tried it on any of these platforms? It compiled and ran fine for us on Solaris 7/8/9 Sparc64 Simon From corsmith at gmail.com Tue Feb 28 01:32:41 2006 From: corsmith at gmail.com (Corey Smith) Date: Mon, 27 Feb 2006 09:32:41 -0500 Subject: NFS via VPN stuck after a certain amount of transfer In-Reply-To: <20060226200015.8177.11688.yusuke@mango.cs.nyu.edu> References: <20060226200015.8177.11688.yusuke@mango.cs.nyu.edu> Message-ID: <8061fbee0602270632s19830a83l62f2fa249d0a7fc2@mail.gmail.com> On 2/26/06, Yusuke Shinyama wrote: > More concretely, I made a connection from a Linux box > to a FreeBSD box via a cable modem. Both are running openssh-4.3p2 > client/server and enabled for point-to-point tunneling. > Then I mounted the remote directory via NFS with tcp and intr option. > Everything worked fine so far. Then I tried to > "cp -Rp /mnt/remote/linux-2.4.31 /local". > After the directory is partially transferred, the cp process > stopped and ping to the remote host (via tun) didn't respond. > But this only happens occationaly. For smaller directories, > the copy finishes without any problem. This sounds very familiar: http://www.mindrot.org/pipermail/openssh-unix-dev/2006-January/024101.html Have you tried looking at a tcpdump of the tun interface? I would be interested to know if the tunnel is unidirectional (packets are only received but not sent or vise versa). -Corey Smith From eric at andante.org Tue Feb 28 02:39:45 2006 From: eric at andante.org (Eric Youngdale) Date: Mon, 27 Feb 2006 10:39:45 -0500 Subject: Bug in Kerberos support for openssh. Message-ID: <44031D41.6090702@andante.org> It took me a while to track this down. I am using MIT Kerberos 1.4.3 and libgssapi-0.7. With some patches that came with Suse 10, but that doesn't appear to be relevant. I have been using openssh-4.2p1 (with Simon's patches) and openssh-4p3p2 out of the box. I see the same problem no matter which version of openssh I am using. I am using two Suse Linux x86 boxes as a test environment, and was able to reproduce the problem there. The KDC is a Windows Server 2003 box, but that probably isn't relevant. The failure mode is that when I connect using ssh, the connection gets set up most of the way. It finds something it doesn't like, and then tears down the connection. In the server logs, I would see messages like this: debug1: userauth-request for user vatester service ssh-connection method gssapi-with-mic debug1: attempt 1 failures 1 debug2: input_userauth_request: try method gssapi-with-mic Postponed gssapi-with-mic for vatester from 10.18.3.52 port 1960 ssh2 debug1: Got no client credentials debug1: An invalid name was supplied A parameter was malformed Validation error Couldn't convert client name debug1: do_cleanup I spent some time in the debugger, and found that essentially the problem was that ssh is calling ctx->major = gss_accept_sec_context(&ctx->minor, &ctx->context, ctx->creds, recv_tok, GSS_C_NO_CHANNEL_BINDINGS, &ctx->client, &mech, send_tok, flags, NULL, &ctx->client_creds); and saving off ctx->client for later use. Under the hood, ctx->client is simply a gss_union_name_t. Later on (not much further later), ssh calls if ((ctx->major = gss_export_name(&ctx->minor, ctx->client, &ename))) { ssh_gssapi_error(ctx); return (ctx->major); } Here ctx->client is passed in but gss_export_name assumes that the input name is a krb5_principal. Not surprisingly, the datatype mismatch causes the call to fail. Could have caused it to crash, I suppose - that would have been a much clearer indication of what the trouble was. I did manage to hack the thing to work - I first hacked libgssapi.so to include a new function: OM_uint32 KRB5_CALLCONV gss_hack_ssh_to_fix_stupid_bug(minor_status, input_name, output_name) OM_uint32 * minor_status; gss_name_t input_name; gss_name_t * output_name; { gss_union_name_t union_name; union_name = (gss_union_name_t) input_name; *output_name = union_name->mech_name; return 0; } and then hacked gss-serv.c to have this: #if 0 /* FIXME(eric) - this is the wrong type for this type of * lookup. */ if ((ctx->major = gss_export_name(&ctx->minor, ctx->client, &ename))) { ssh_gssapi_error(ctx); return (ctx->major); } #else { extern gss_hack_ssh_to_fix_stupid_bug(OM_uint32 * minor_status, gss_name_t input_name, gss_name_t *output_name); void * pname; gss_hack_ssh_to_fix_stupid_bug(NULL, ctx->client, &pname); if ((ctx->major = gss_export_name(&ctx->minor, pname, &ename))) { ssh_gssapi_error(ctx); return (ctx->major); } } #endif With these two changes, ssh is now able to authenticate with Kerberos, and I get a nice shell prompt on the remote machine. Server logs look good too: WARNING: /usr/local/etc/moduli does not exist, using fixed modulus Authorized to vatester, krb5 principal vatester at VADEV.COM (krb5_kuserok) Accepted gssapi-with-mic for vatester from 10.18.3.52 port 2729 ssh2 I honestly have no clue how this could have ever have worked - my guess is that at one point in the past libgssapi didn't use the gss_union_name_t, and just used krb5_principal as a return parameter from gss_accept_sec_context(). I leave it to the people who know the history of this thing, and who better understand the intent of the original code to best figure out how to fix this. From David.Leonard at quest.com Tue Feb 28 11:37:21 2006 From: David.Leonard at quest.com (David Leonard) Date: Tue, 28 Feb 2006 10:37:21 +1000 Subject: Bug in Kerberos support for openssh. In-Reply-To: <44031D41.6090702@andante.org> References: <44031D41.6090702@andante.org> Message-ID: <44039B41.3020309@quest.com> Eric Youngdale wrote: >debug1: An invalid name was supplied >A parameter was malformed >Validation error > ... >Later on (not much further later), ssh calls > > if ((ctx->major = gss_export_name(&ctx->minor, ctx->client, > &ename))) { > ssh_gssapi_error(ctx); > return (ctx->major); > } > >Here ctx->client is passed in but gss_export_name assumes that the input >name is a krb5_principal. gss_export_name() should work with any src_name returned by gss_accept_sec_context()... Whatversion of the MIT libraries do you have? The error appears to come not from a nametype check, but from a pointer validation: if (! kg_validate_name(input_name)) { if (minor_status) *minor_status = (OM_uint32) G_VALIDATE_FAILED; krb5_free_context(context); return(GSS_S_CALL_BAD_STRUCTURE|GSS_S_BAD_NAME); } Is it possible that the ctx->client pointer is getting mangled somehow? d -- David Leonard Vintela Resource Central software engineer Quest Software; 303 Adelaide St, Brisbane, Australia; www.quest.com Phone: (US) +1 801 655 2755 (AU) +61 7 3023 5133 From eric at andante.org Tue Feb 28 13:41:26 2006 From: eric at andante.org (Eric Youngdale) Date: Mon, 27 Feb 2006 21:41:26 -0500 Subject: Bug in Kerberos support for openssh. In-Reply-To: <44039B41.3020309@quest.com> References: <44031D41.6090702@andante.org> <44039B41.3020309@quest.com> Message-ID: <4403B856.40807@andante.org> David Leonard wrote: >> >> >> Here ctx->client is passed in but gss_export_name assumes that the >> input name is a krb5_principal. > gss_export_name() should work with any src_name returned by > gss_accept_sec_context()... > > Whatversion of the MIT libraries do you have? The error appears to > come not from a nametype check, but from a pointer validation: > if (! kg_validate_name(input_name)) { > if (minor_status) > *minor_status = (OM_uint32) G_VALIDATE_FAILED; > krb5_free_context(context); > return(GSS_S_CALL_BAD_STRUCTURE|GSS_S_BAD_NAME); > } > > Is it possible that the ctx->client pointer is getting mangled somehow? It isn't mangled - the pointer is still valid, but not pointing to the same type of object that kg_validate_name is expecting. All I needed to do to hack around the problem was to cast the thing to the real type of the object, dereference to get the member which does represent a krb5_principal, and then feed that into gss_export_name and life was good again. Using Kerberos 1.4.3 from MIT, and libgssapi-0.7. I am seeing this with Suse-10 - I essentially got the source RPMS fro krb5-devel and libgssapi, unpacked and built with debugging so I could step all the way in and figure out what the heck this was all about. The problem could well be in libgssapi instead of ssh - it is inside of gss_accept_sec_context that status = __gss_convert_name_to_union_name(&temp_minor_status, mech, internal_name, (gss_name_t *) &union_name); is called - this is what sets up the value returned to ctx->client, and sets it up as this union_name thing. So which one is wrong here? Is the mistake that libgssapi is returning a name from gss_accept_sec_context() that isn't a krb5_principal, or is the bug in ssh in that it makes assumptions about what ctx->client really is? I think I have ruled out Kerberos proper however - everything on that level seems to be working. I should note that the man pages I found online for gss_accept_sec_context() suggest that the value returned to ctx->client should be deallocated by passing it to gss_release_name(): http://docs.hp.com/en/B2355-90694/gss_accept_sec_context.3.html I examined the source to gss_release_name() and it again assumes that the opaque type is one which should be cast to a union_name, which implies that libgssapi is behaving consistently and that the problem is that ssh is assuming that this pointer returned from gss_accept_sec_context() into ctx->client is something that can be passed to gss_export_name(). What are other people using as a sourcebase for libgssapi?? From sxw at inf.ed.ac.uk Tue Feb 28 23:32:56 2006 From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk) Date: Tue, 28 Feb 2006 12:32:56 +0000 (GMT) Subject: Bug in Kerberos support for openssh. In-Reply-To: <44031D41.6090702@andante.org> References: <44031D41.6090702@andante.org> Message-ID: [ cross-posted both to openssh-unix-dev and kerberos at mit.edu as this question has been asked on both lists ] The first and most important point to note here is that the problem you're seeing isn't a bug in OpenSSH - it's a problem with the libraries that your vendor is shipping, and in particular with the libgssapi package. On Mon, 27 Feb 2006, Eric Youngdale wrote > I spent some time in the debugger, and found that essentially the > problem was that ssh is calling > > ctx->major = gss_accept_sec_context(&ctx->minor, > Later on (not much further later), ssh calls > > if ((ctx->major = gss_export_name(&ctx->minor, ctx->client, > > Here ctx->client is passed in but gss_export_name assumes that the input > name is a krb5_principal. Not surprisingly, the datatype mismatch > causes the call to fail. Could have caused it to crash, I suppose - > that would have been a much clearer indication of what the trouble was. GSSAPI is an IETF standard. If your GSSAPI library doesn't allow gss_export_name to be called with the client name returned by gss_accept_sec_context then it is broken. The type of the client name is, as others have noted on the Kerberos mailing list, opaque. An implementation can chose to make this whatever it likes, as long as that decision is consistent across every call. The OpenSSH code has been tested with (to my knowledge) GSSAPI implementations from MIT, Heimdal and Globus, and works correctly with all of these. SuSe 10 ships with a library called 'libgssapi', which isn't a Kerberos GSSAPI library at all (the Kerberos GSSAPI library from the MIT code is called libgssapi_krb5.so). It's a version of the 'mechglue' code which, I believe, CITI have packaged up to work with NFSv4. It acts as a 'shim' layer, allowing multiple different GSSAPI libraries to be used by the one application. Unfortunately this code has issues that are causing problems for a number of people trying to do GSSAPI on SuSE 10. Firstly, it calls exit() when it encounters problems - not particular great behaviour from a shared library. I first encountered this with Thunderbird's Kerberos support - both Thunderbird and Firefox now explicitly check for this library and don't use it if found. Secondly, as you've noted, its support for calling 'export_name' is broken. In fact, the version of the library that I have to hand doesn't even support export_name - so I suspect that you're falling back to using the native export_name provided by libgssapi_krb5, although I'm not familiar enough with the behaviour of Linux's linker to work out how. The short answer is - don't build OpenSSH against libgssapi - build it against the GSSAPI library (libgssapi_krb5) which ships with MIT Kerberos. File a bug with your vendor about the fact that they're shipping a broken GSSAPI library. I'll drop Kevin Coffman at UMICH a mail about this too. Cheers, Simon.