From Nigel.Metheringham at VData.co.uk Fri Dec 1 00:09:48 2000 From: Nigel.Metheringham at VData.co.uk (Nigel Metheringham) Date: Thu, 30 Nov 2000 13:09:48 +0000 Subject: StrictHostKeyChecking In-Reply-To: Message from Nigel Metheringham of "Mon, 27 Nov 2000 15:41:23 GMT." Message-ID: I found what was causing this problem... and I'll share my embarrassment in public. I build and install all packages as rpms. Unfortunately in a moment of madness, I had installed the Red Hat package of openssl 0.9.5a on my build machine, but had my rebuild of Damien's openssl 0.9.5a on all the others. Something in those 2 versions of openssl libraries don't quite match up. Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham at VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] From J.Horne at plymouth.ac.uk Fri Dec 1 01:06:54 2000 From: J.Horne at plymouth.ac.uk (John Horne) Date: Thu, 30 Nov 2000 14:06:54 -0000 (GMT) Subject: Pseudo-tty allocation and -T option In-Reply-To: <20001130080208.A8115@folly> Message-ID: On 30-Nov-00 at 07:02:08 Markus Friedl wrote: > try the patch or > ssh host dummy > instead of > ssh host > -markus > The patch works fine - thanks :-) I must agree with Markus regarding a 'Password' option. I'm using ssh because I want a secure environment; using plaintext passwords and the like seems to somewhat contradict this. John. ------------------------------------------------------------------------ John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: jhorne at plymouth.ac.uk PGP key available from public key servers From res at shore.net Fri Dec 1 02:18:24 2000 From: res at shore.net (Richard E. Silverman) Date: Thu, 30 Nov 2000 10:18:24 -0500 (EST) Subject: Problem and Patch: Multiple keys in ssh.com V2 agent In-Reply-To: Message-ID: On Thu, 30 Nov 2000, Ulrich Kiermayr wrote: > > If I have more than one key in my agent, then the agent tries to > authenticicate me with every one of them at the OpenSSH server; but none > of them is a valid key for that server. The Problem is that the Server > increments the authctxt->attempt at every of that tries. So even if you > want to login with a password at that server, you have to disable the > agent first in order to get that chance. If the agent is running, you run > out of tries _before_ you are able to enter a password. This is a known issue. I think the right thing to do is to allow unlimited public-key checks (i.e. SSH_MSG_USERAUTH_REQUEST's with the boolean parameter set to FALSE), but count requests that actually contain a signature (TRUE) against the limit. Markus agreed with me, last time we corresponded about this. -- Richard Silverman slade at shore.net From gilesc at hyperlink.com Fri Dec 1 02:31:58 2000 From: gilesc at hyperlink.com (Giles Constant) Date: Thu, 30 Nov 2000 15:31:58 +0000 (GMT) Subject: Pseudo-tty allocation and -T option In-Reply-To: <20001130125939.A17888@faui02.informatik.uni-erlangen.de> Message-ID: On Thu, 30 Nov 2000, Markus Friedl wrote: > i don't think that a > Password foo > option will ever be included in OpenSSH. > > it's a bad practice to have plaintext passwords > in files, commandlines or environment variables > and i don't want to encourage this in OpenSSH. It might be bad practice, but in my case it was unavoidable. The current implementation of sshd on NT won't allow access without providing a domain password, and this is unlikely to change, due to the way it works. When scripting something to ssh to NT, there has to be some mechanism for providing the password. Perhaps it could be included as a compile-time option? Having a file with a password in it is no less secure than having a blank password for your identity. Actually, there is a way around - perhaps ssh could be extended to run through some sort of lockable-detachable pipe object, eg : connect: slogin foo at bar.com: -oCreateAttachFile ./foo secure it: chmod 700 ./foo attach[1]: ssh-reattach ./foo do something: ls (runs as foo at bar.com) detach: ^D attach[2]: ssh-reattach ./foo do something else: echo hello detach: ^D close connection: ssh-close-attachment ./foo [1] and [2] connect to the attached link, and fire up a remote shell in the process. Detaching will close the shell, but will maintain the link. If this could be implemented in a way such that it has a similar feature-set to rpc, et all, it would get around my problem and possibly many others. From marekm at diament.ists.pwr.wroc.pl Fri Dec 1 02:41:34 2000 From: marekm at diament.ists.pwr.wroc.pl (marekm at diament.ists.pwr.wroc.pl) Date: Thu, 30 Nov 2000 16:41:34 +0100 (CET) Subject: Problem talking to SSH 2.3.0 server Message-ID: <20001130154134.24970.qmail@diament.ists.pwr.wroc.pl> I'd like to report a problem I found with the OpenSSH client talking to the SSH 2.3.0 server. client: i686-pc-linux (Debian 2.2, kernel 2.2.18pre19, glibc-2.1.3), SSH-2.0-OpenSSH_2.3.0p1 (built by me from source, but the same problem occurs with ssh_2.2.0p1-1.1 as shipped with Debian 2.2). server: sparc-sun-solaris2.7, SSH-2.0-2.3.0 SSH Secure Shell (non-commercial) Problem: some time after logging into the server (few minutes to few hours, happens even if the session is mostly idle), I get this error message: Hm, dispatch protocol error: type 20 plen 136 and no more data can be received from the server (the other direction appears to be OK - the server gets the commands I type, but I can't see them echoed back). The ~. escape closes the connection as it should. Thanks, Marek PS. Yes, I will try to convince the admin of that server to install OpenSSH instead. From pekkas at netcore.fi Fri Dec 1 02:54:38 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 30 Nov 2000 17:54:38 +0200 (EET) Subject: Problem talking to SSH 2.3.0 server In-Reply-To: <20001130154134.24970.qmail@diament.ists.pwr.wroc.pl> Message-ID: On Thu, 30 Nov 2000 marekm at diament.ists.pwr.wroc.pl wrote: > server: sparc-sun-solaris2.7, > SSH-2.0-2.3.0 SSH Secure Shell (non-commercial) > > Problem: some time after logging into the server (few minutes to few > hours, happens even if the session is mostly idle), I get this error > message: > > Hm, dispatch protocol error: type 20 plen 136 > > and no more data can be received from the server (the other direction > appears to be OK - the server gets the commands I type, but I can't see > them echoed back). The ~. escape closes the connection as it should. Perhaps this is related to rekeying feature in ssh.com SSH? If this is the case, setting 'RekeyIntervalSeconds 0' in sshd2_config might help. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From uk at ap.univie.ac.at Fri Dec 1 03:20:54 2000 From: uk at ap.univie.ac.at (Ulrich Kiermayr) Date: Thu, 30 Nov 2000 17:20:54 +0100 (MET) Subject: Problem and Patch: Multiple keys in ssh.com V2 agent In-Reply-To: Message-ID: On Thu, 30 Nov 2000, Richard E. Silverman wrote: > On Thu, 30 Nov 2000, Ulrich Kiermayr wrote: > > > > If I have more than one key in my agent, then the agent tries to > > authenticicate me with every one of them at the OpenSSH server; but none > > of them is a valid key for that server. The Problem is that the Server > > increments the authctxt->attempt at every of that tries. So even if you > > want to login with a password at that server, you have to disable the > > agent first in order to get that chance. If the agent is running, you run > > out of tries _before_ you are able to enter a password. > > This is a known issue. I think the right thing to do is to allow > unlimited public-key checks (i.e. SSH_MSG_USERAUTH_REQUEST's with the > boolean parameter set to FALSE), but count requests that actually contain > a signature (TRUE) against the limit. Markus agreed with me, last time we > corresponded about this. Hmm great, but one has to check if alloung infinite public-key checks could maybe lead to some sort of DoS against the daemon. (Just thinking....) LL&P uk -- --------------------------------------------------------------------------- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Security Team Boltzmanngasse 5, A-1090 Vienna, Austria --------------------------------------------------------------------------- eMail: ulrich.kiermayr at univie.ac.at Tel: (+43 1) 4277 / 14104 Hotline: security.zid at univie.ac.at Fax: (+43 1) 4277 / 9141 Web: http://www.univie.ac.at/zid/security --------------------------------------------------------------------------- GPG Key fingerprint = BF0D 5749 4DC1 ED74 AB67 7180 105F 491D A8D7 64D8 From rob at hagopian.net Fri Dec 1 06:40:09 2000 From: rob at hagopian.net (Rob Hagopian) Date: Thu, 30 Nov 2000 14:40:09 -0500 (EST) Subject: hanging ssh connections (still) Message-ID: Using the latest snapshot, I'm still getting periodic ssh sessions hanging after they've completed. It used to be very common, but the prior fixes reduced the frequency to about one hung per day (out of thousands). These don't timeout at any point, they'll hang around for days if not killed manually (blocking the scripts from continuing). The commands ssh is hanging on are nothing but simple shell scripts on FreeBSD 3.5 (the shell for the account is tcsh, the scripts use sh). I'm not sure how to go about providing more information as it's not practical to run sshd in debug mode every time. I'd be happy to try anything out though... -Rob From mouring at etoh.eviladmin.org Fri Dec 1 07:50:23 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 30 Nov 2000 14:50:23 -0600 (CST) Subject: hanging ssh connections (still) In-Reply-To: Message-ID: Damien backed out of all the current hacks. So yes any background processes will cause ssh client to hang until they are resolved. This is also true for doing "nohup" commands. I have another angle to look at tonight. But I spent most of last night without any luck in coming up with a work around that is correct. (I have a workaround.. But it's a hack to the server_loop() call which causes channel errors which cause it to close right.. Which is 100% wrong.=) If you look back on the list Damien Miller describes the problem as it occurs under Linux. try: ssh localhost then: sleep 10&exit if it does not quit ssh right away it's the same problem that we are looking for a solution on Linux. - Ben On Thu, 30 Nov 2000, Rob Hagopian wrote: > Using the latest snapshot, I'm still getting periodic ssh sessions hanging > after they've completed. It used to be very common, but the prior fixes > reduced the frequency to about one hung per day (out of thousands). These > don't timeout at any point, they'll hang around for days if not killed > manually (blocking the scripts from continuing). > > The commands ssh is hanging on are nothing but simple shell scripts on > FreeBSD 3.5 (the shell for the account is tcsh, the scripts use sh). > > I'm not sure how to go about providing more information as it's not > practical to run sshd in debug mode every time. I'd be happy to try > anything out though... > -Rob > > From marekm at linux.org.pl Fri Dec 1 06:39:20 2000 From: marekm at linux.org.pl (Marek Michalkiewicz) Date: Thu, 30 Nov 2000 20:39:20 +0100 (CET) Subject: Problem talking to SSH 2.3.0 server In-Reply-To: from Pekka Savola at "Nov 30, 2000 05:54:38 pm" Message-ID: <200011301939.UAA02944@marekm.home> > > Hm, dispatch protocol error: type 20 plen 136 > Perhaps this is related to rekeying feature in ssh.com SSH? > > If this is the case, setting 'RekeyIntervalSeconds 0' in sshd2_config > might help. Thanks for fast response. I will check this (I will need to talk to the admin of that machine about changing this). I see that OpenSSH generally tries to be compatible with any other implementations - good. Would it be possible to add support for this feature to OpenSSH as well? If that is difficult, at least it would be nice to print a message that better explains the problem - SSH protocol feature that is not yet implemented in OpenSSH. Again thanks, and keep up the good work! Marek From rob at hagopian.net Fri Dec 1 07:16:55 2000 From: rob at hagopian.net (Rob Hagopian) Date: Thu, 30 Nov 2000 15:16:55 -0500 (EST) Subject: hanging ssh connections (still) In-Reply-To: Message-ID: Actually, that works fine for me in quick testing: > sleep 10&exit [1] 26610 logout Connection to dhoose301 closed. > sh $ sleep 10&exit > exit logout Connection to dhoose301 closed. > nohup sleep 10 & exit [1] 26619 logout Connection to dhoose301 closed. (both machines are FreeBSD 3.5 and running the latest 2.3.0p2 snap) That did hang between two linux boxen, the client running 2.3.0p1 and the server running 2.2.0p1 from RedHat 7... I'll set up and overnight test for the FreeBSD systems... -Rob On Thu, 30 Nov 2000 mouring at etoh.eviladmin.org wrote: > Damien backed out of all the current hacks. So yes any background > processes will cause ssh client to hang until they are resolved. > > This is also true for doing "nohup" commands. > > I have another angle to look at tonight. But I spent most of last night > without any luck in coming up with a work around that is correct. (I have > a workaround.. But it's a hack to the server_loop() call which causes > channel errors which cause it to close right.. Which is 100% wrong.=) > > If you look back on the list Damien Miller describes the problem as it > occurs under Linux. > > try: > > ssh localhost > then: sleep 10&exit > > if it does not quit ssh right away it's the same problem that we are > looking for a solution on Linux. > > - Ben > > > > On Thu, 30 Nov 2000, Rob Hagopian wrote: > > > Using the latest snapshot, I'm still getting periodic ssh sessions hanging > > after they've completed. It used to be very common, but the prior fixes > > reduced the frequency to about one hung per day (out of thousands). These > > don't timeout at any point, they'll hang around for days if not killed > > manually (blocking the scripts from continuing). > > > > The commands ssh is hanging on are nothing but simple shell scripts on > > FreeBSD 3.5 (the shell for the account is tcsh, the scripts use sh). > > > > I'm not sure how to go about providing more information as it's not > > practical to run sshd in debug mode every time. I'd be happy to try > > anything out though... > > -Rob > > > > > From rob at hagopian.net Fri Dec 1 07:28:19 2000 From: rob at hagopian.net (Rob Hagopian) Date: Thu, 30 Nov 2000 15:28:19 -0500 (EST) Subject: Pseudo-tty allocation and -T option In-Reply-To: Message-ID: FreeBSD has a method of setting a user's password that may be applicable (from 'man pw'): -h fd This option provides a special interface by which interac- tive scripts can set an account password using pw. Because the command line and environment are fundamentally insecure mechanisms by which programs can accept information, pw will only allow setting of account and group passwords via a file descriptor (usually a pipe between an interactive script and the program). sh, bash, ksh and perl all pos- sess mechanisms by which this can be done. Alternatively, pw will prompt for the user's password if `-h 0' is given, nominating stdin as the file descriptor on which to read the password. Note that this password will be read only once and is intended for use by a script rather than for interactive use. If you wish to have new password confir- mation along the lines of passwd(1), this must be imple- mented as part of an interactive script that calls pw. If a value of `-' is given as the argument fd, then the password will be set to `*', rendering the account inacces- sible via password-based login. This can be used from a sh script as: pw useradd -n prod -u 1002 -c "User Account" -m -h 3 3< prodpass Just make sure that prodpass is owned by root and has 600 perms... I'm not a fan of storing passwords like this, but I don't see how it's much more insecure than having a private RSA/DSA key with no encryption (as long as this plaintext password is not used anywhere else)... -Rob On Thu, 30 Nov 2000, Giles Constant wrote: > On Thu, 30 Nov 2000, Markus Friedl wrote: > > > i don't think that a > > Password foo > > option will ever be included in OpenSSH. > > > > it's a bad practice to have plaintext passwords > > in files, commandlines or environment variables > > and i don't want to encourage this in OpenSSH. > > It might be bad practice, but in my case it was unavoidable. The current > implementation of sshd on NT won't allow access without providing a domain > password, and this is unlikely to change, due to the way it works. When > scripting something to ssh to NT, there has to be some mechanism for > providing the password. Perhaps it could be included as a compile-time > option? Having a file with a password in it is no less secure than having > a blank password for your identity. > > Actually, there is a way around - perhaps ssh could be extended to run > through some sort of lockable-detachable pipe object, eg : > > connect: slogin foo at bar.com: -oCreateAttachFile ./foo > secure it: chmod 700 ./foo > attach[1]: ssh-reattach ./foo > do something: ls (runs as foo at bar.com) > detach: ^D > attach[2]: ssh-reattach ./foo > do something else: echo hello > detach: ^D > close connection: ssh-close-attachment ./foo > > [1] and [2] connect to the attached link, and fire up a remote shell in > the process. Detaching will close the shell, but will maintain the link. > > If this could be implemented in a way such that it has a similar > feature-set to rpc, et all, it would get around my problem and possibly > many others. > > > > From ftobin at uiuc.edu Fri Dec 1 07:42:02 2000 From: ftobin at uiuc.edu (Frank Tobin) Date: Thu, 30 Nov 2000 14:42:02 -0600 (CST) Subject: Pseudo-tty allocation and -T option In-Reply-To: Message-ID: Rob Hagopian, at 15:28 -0500 on Thu, 30 Nov 2000, wrote: pw useradd -n prod -u 1002 -c "User Account" -m -h 3 3< prodpass This is similar to GnuPG's method of passing in passphrases, which uses a --passphrase-fd option. This method of interactiong is both highly useable from both many scripting languages and from shell syntax. -- Frank Tobin http://www.uiuc.edu/~ftobin/ From rob at hagopian.net Fri Dec 1 08:11:46 2000 From: rob at hagopian.net (Rob Hagopian) Date: Thu, 30 Nov 2000 16:11:46 -0500 (EST) Subject: hanging ssh connections (still) In-Reply-To: Message-ID: Whoops! I missed the latest latest snapshot... I'm using the one after 2.3.0p1 was released but before the latest latest... I'll check that one out tommrow... -Rob On Thu, 30 Nov 2000 mouring at etoh.eviladmin.org wrote: > Damien backed out of all the current hacks. So yes any background > processes will cause ssh client to hang until they are resolved. > > This is also true for doing "nohup" commands. > > I have another angle to look at tonight. But I spent most of last night > without any luck in coming up with a work around that is correct. (I have > a workaround.. But it's a hack to the server_loop() call which causes > channel errors which cause it to close right.. Which is 100% wrong.=) > > If you look back on the list Damien Miller describes the problem as it > occurs under Linux. > > try: > > ssh localhost > then: sleep 10&exit > > if it does not quit ssh right away it's the same problem that we are > looking for a solution on Linux. > > - Ben > > > > On Thu, 30 Nov 2000, Rob Hagopian wrote: > > > Using the latest snapshot, I'm still getting periodic ssh sessions hanging > > after they've completed. It used to be very common, but the prior fixes > > reduced the frequency to about one hung per day (out of thousands). These > > don't timeout at any point, they'll hang around for days if not killed > > manually (blocking the scripts from continuing). > > > > The commands ssh is hanging on are nothing but simple shell scripts on > > FreeBSD 3.5 (the shell for the account is tcsh, the scripts use sh). > > > > I'm not sure how to go about providing more information as it's not > > practical to run sshd in debug mode every time. I'd be happy to try > > anything out though... > > -Rob > > > > > > From djm at mindrot.org Fri Dec 1 11:13:07 2000 From: djm at mindrot.org (Damien Miller) Date: Fri, 1 Dec 2000 11:13:07 +1100 (EST) Subject: Problem talking to SSH 2.3.0 server In-Reply-To: <20001130154134.24970.qmail@diament.ists.pwr.wroc.pl> Message-ID: On Thu, 30 Nov 2000 marekm at diament.ists.pwr.wroc.pl wrote: > Hm, dispatch protocol error: type 20 plen 136 > > and no more data can be received from the server (the other direction > appears to be OK - the server gets the commands I type, but I can't see > them echoed back). The ~. escape closes the connection as it should. IIRC, you need to disable rekeying on the server end. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From stevesk at sweden.hp.com Fri Dec 1 16:23:12 2000 From: stevesk at sweden.hp.com (Kevin Steves) Date: Fri, 1 Dec 2000 06:23:12 +0100 (CET) Subject: /etc/issue possible? In-Reply-To: <3A1E11AB.316C7ECC@iastate.edu> Message-ID: <200012010517.GAA07436@b0fh.sweden.hp.com> On Fri, 24 Nov 2000, Chris wrote: : Is it possible to have sshd print out /etc/issue before users attempt to : log in? We are required to print some sort of disclaimer, and the only : way I have found to do this so far is some disgusting hack involving : debug statements. In the version 2 drafts the server is allowed to send data before the version string which the client may choose to display. It seems this may provide the mechanism to do what you want, but currently any such lines are not displayed by the client and the server would have to be changed to generate them (with a BannerFile option for example). From aspa at kronodoc.fi Sat Dec 2 00:13:51 2000 From: aspa at kronodoc.fi (Marko Asplund) Date: Fri, 1 Dec 2000 15:13:51 +0200 (EET) Subject: Problem talking to SSH 2.3.0 server In-Reply-To: Message-ID: On Fri, 1 Dec 2000, Damien Miller wrote: > ... > > Hm, dispatch protocol error: type 20 plen 136 > > > > and no more data can be received from the server (the other direction > > appears to be OK - the server gets the commands I type, but I can't see > > them echoed back). The ~. escape closes the connection as it should. > > IIRC, you need to disable rekeying on the server end. this, of course, is impossible unless you've root access on the server machine. i think the rekeying problem is a major interoperability annoyance when talking to ssh.com servers. are there any plans for supporting rekeying in OpenSSH? -- aspa From Markus.Friedl at informatik.uni-erlangen.de Sat Dec 2 00:35:17 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 1 Dec 2000 14:35:17 +0100 Subject: Problem talking to SSH 2.3.0 server In-Reply-To: ; from aspa@kronodoc.fi on Fri, Dec 01, 2000 at 03:13:51PM +0200 References: Message-ID: <20001201143517.A20836@faui02.informatik.uni-erlangen.de> On Fri, Dec 01, 2000 at 03:13:51PM +0200, Marko Asplund wrote: > > IIRC, you need to disable rekeying on the server end. > > this, of course, is impossible unless you've root access on the server > machine. i think the rekeying problem is a major interoperability > annoyance when talking to ssh.com servers. are there any plans for > supporting rekeying in OpenSSH? yes. but it will take time. donations could speed up development, but it will take time, if this should be done properly. -markus From mstone at cs.loyola.edu Sat Dec 2 03:43:02 2000 From: mstone at cs.loyola.edu (Michael Stone) Date: Fri, 1 Dec 2000 11:43:02 -0500 Subject: two irix patches Message-ID: <20001201114302.A5330@justice.loyola.edu> First, does anyone know why the following was added in the first place? It purposely strips the tty off of tty names (e.g., ttyq1 becomes q1) before sticking them in wtmp. IRIX then has no idea what terminal people are attached to, causing commands like wall to fail (as they try to open /dev/q1). Maybe this should be version specific? --- openssh-SNAP-20001129.orig/loginrec.c Thu Nov 9 22:28:31 2000 +++ openssh-SNAP-20001129/loginrec.c Thu Nov 30 13:52:24 2000 @@ -512,13 +512,8 @@ line_stripname(char *dst, const char *src, int dstsize) { memset(dst, '\0', dstsize); -#ifdef sgi - if (strncmp(src, "/dev/tty", 8) == 0) - strlcpy(dst, src + 8, dstsize); -#else if (strncmp(src, "/dev/", 5) == 0) strlcpy(dst, src + 5, dstsize); -#endif else strlcpy(dst, src, dstsize); return dst; Next, we need some sort of mansubdir: --- openssh-SNAP-20001129.orig/configure.in Tue Nov 28 21:28:50 2000 +++ openssh-SNAP-20001129/configure.in Thu Nov 30 13:42:55 2000 @@ -119,6 +120,7 @@ no_libsocket=1 no_libnsl=1 AC_DEFINE(BROKEN_INET_NTOA) + mansubdir=man ;; *-*-linux*) no_dev_ptmx=1 -- Mike Stone From mouring at etoh.eviladmin.org Sat Dec 2 04:56:04 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 1 Dec 2000 11:56:04 -0600 (CST) Subject: two irix patches In-Reply-To: <20001201114302.A5330@justice.loyola.edu> Message-ID: On Fri, 1 Dec 2000, Michael Stone wrote: > First, does anyone know why the following was added in the first place? > It purposely strips the tty off of tty names (e.g., ttyq1 becomes q1) > before sticking them in wtmp. IRIX then has no idea what terminal people > are attached to, causing commands like wall to fail (as they try to open > /dev/q1). Maybe this should be version specific? > revision 1.26 date: 2000/09/30 10:34:44; author: djm; state: Exp; lines: +14 -4 - (djm) Irix strips "/dev/tty" from [uw]tmp entries (other systems only strip "/dev/"). Fix loginrec.c based on patch from Alain St-Denis No idea what version Alain is running for SGI. - Ben From Alain.St-Denis at ec.gc.ca Sat Dec 2 04:13:02 2000 From: Alain.St-Denis at ec.gc.ca (Alain St-Denis) Date: Fri, 01 Dec 2000 12:13:02 -0500 Subject: two irix patches References: Message-ID: <3A27DC1E.5FD28F2E@ec.gc.ca> Irix 6.5.5 OpenSSH 2.2.0p1 Alain. mouring at etoh.eviladmin.org wrote: > On Fri, 1 Dec 2000, Michael Stone wrote: > > > First, does anyone know why the following was added in the first place? > > It purposely strips the tty off of tty names (e.g., ttyq1 becomes q1) > > before sticking them in wtmp. IRIX then has no idea what terminal people > > are attached to, causing commands like wall to fail (as they try to open > > /dev/q1). Maybe this should be version specific? > > > revision 1.26 > date: 2000/09/30 10:34:44; author: djm; state: Exp; lines: +14 -4 > - (djm) Irix strips "/dev/tty" from [uw]tmp entries (other systems only > strip "/dev/"). Fix loginrec.c based on patch from Alain St-Denis > > > No idea what version Alain is running for SGI. > > - Ben From Alain.St-Denis at ec.gc.ca Sat Dec 2 05:44:34 2000 From: Alain.St-Denis at ec.gc.ca (Alain St-Denis) Date: Fri, 01 Dec 2000 13:44:34 -0500 Subject: two irix patches References: Message-ID: <3A27F192.2707AD2E@ec.gc.ca> After a few e-mail Exchanges with Michael, I realized only the ut_id field needs to have the "tty" stripped. I think this means only the line_abbrevname func needs the ifdef sgi code. Hope this will do... Here is the diff against 2.3.0p1: *** loginrec.c.orig Fri Dec 01 13:39:13 EST 2000 --- loginrec.c Fri Dec 01 13:39:28 EST 2000 *************** *** 508,520 **** line_stripname(char *dst, const char *src, int dstsize) { memset(dst, '\0', dstsize); - #ifdef sgi - if (strncmp(src, "/dev/tty", 8) == 0) - strlcpy(dst, src + 8, dstsize); - #else if (strncmp(src, "/dev/", 5) == 0) strlcpy(dst, src + 5, dstsize); - #endif else strlcpy(dst, src, dstsize); return dst; --- 508,515 ---- I tried it and it seems to work for me. Alain. Michael Stone wrote: > On Fri, Dec 01, 2000 at 01:12:01PM -0500, you wrote: > > Irix only stores whatever comes after /dev/tty in [uw]tmp[x] files. > > > > Do a "who -a" and look for the id field, you'll understand what I mean. > > On mine, I see a ttyd1 from the console login. If I do a 'w', I see only > the last two characters, but that's true whether I recorded ttyq1 or q1 > as the tty name. There is one difference: if I didn't store ttyq1, I > don't JCPU or PCPU, and there's a - in the what field. > > -- > Mike Stone mouring at etoh.eviladmin.org wrote: > On Fri, 1 Dec 2000, Michael Stone wrote: > > > First, does anyone know why the following was added in the first place? > > It purposely strips the tty off of tty names (e.g., ttyq1 becomes q1) > > before sticking them in wtmp. IRIX then has no idea what terminal people > > > are attached to, causing commands like wall to fail (as they try to open > > > /dev/q1). Maybe this should be version specific? > > > revision 1.26 > date: 2000/09/30 10:34:44; author: djm; state: Exp; lines: +14 -4 > - (djm) Irix strips "/dev/tty" from [uw]tmp entries (other systems only > strip "/dev/"). Fix loginrec.c based on patch from Alain St-Denis > > > No idea what version Alain is running for SGI. > > - Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001201/83285a61/attachment.html From mouring at etoh.eviladmin.org Sat Dec 2 09:29:25 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 1 Dec 2000 16:29:25 -0600 (CST) Subject: two irix patches In-Reply-To: <20001201114302.A5330@justice.loyola.edu> Message-ID: Reverted and Applied. - Ben On Fri, 1 Dec 2000, Michael Stone wrote: > First, does anyone know why the following was added in the first place? > It purposely strips the tty off of tty names (e.g., ttyq1 becomes q1) > before sticking them in wtmp. IRIX then has no idea what terminal people > are attached to, causing commands like wall to fail (as they try to open > /dev/q1). Maybe this should be version specific? > > --- openssh-SNAP-20001129.orig/loginrec.c Thu Nov 9 22:28:31 2000 > +++ openssh-SNAP-20001129/loginrec.c Thu Nov 30 13:52:24 2000 > @@ -512,13 +512,8 @@ > line_stripname(char *dst, const char *src, int dstsize) > { > memset(dst, '\0', dstsize); > -#ifdef sgi > - if (strncmp(src, "/dev/tty", 8) == 0) > - strlcpy(dst, src + 8, dstsize); > -#else > if (strncmp(src, "/dev/", 5) == 0) > strlcpy(dst, src + 5, dstsize); > -#endif > else > strlcpy(dst, src, dstsize); > return dst; > > > Next, we need some sort of mansubdir: > > --- openssh-SNAP-20001129.orig/configure.in Tue Nov 28 21:28:50 2000 > +++ openssh-SNAP-20001129/configure.in Thu Nov 30 13:42:55 2000 > @@ -119,6 +120,7 @@ > no_libsocket=1 > no_libnsl=1 > AC_DEFINE(BROKEN_INET_NTOA) > + mansubdir=man > ;; > *-*-linux*) > no_dev_ptmx=1 > > From brhamon at cisco.com Sat Dec 2 08:39:46 2000 From: brhamon at cisco.com (Hamon, Brian K.) Date: Fri, 01 Dec 2000 15:39:46 -0600 Subject: Bug fix -- version grepping in compat.c Message-ID: <4.3.2.7.2.20001201152913.00b11c70@3rdclass.cisco.com> In OpenSSH-2.3.0, in the file ssh/compat.c, line 61 the line: { "^OpenSSH[-_]2\\.[012]", SSH_OLD_SESSIONID }, Will not match another OpenSSH-2.3.0 client. The quick fix is to add "3" to the regular expression as follows: { "^OpenSSH[-_]2\\.[0123]", SSH_OLD_SESSIONID }, The same bug is in the portable release, but the line number is 65. From Markus.Friedl at informatik.uni-erlangen.de Sat Dec 2 08:45:48 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 1 Dec 2000 22:45:48 +0100 Subject: Bug fix -- version grepping in compat.c In-Reply-To: <4.3.2.7.2.20001201152913.00b11c70@3rdclass.cisco.com>; from brhamon@cisco.com on Fri, Dec 01, 2000 at 03:39:46PM -0600 References: <4.3.2.7.2.20001201152913.00b11c70@3rdclass.cisco.com> Message-ID: <20001201224548.A22130@faui02.informatik.uni-erlangen.de> what bug does your suggestion fix? what bug do you see? there is not bug to fix. On Fri, Dec 01, 2000 at 03:39:46PM -0600, Hamon, Brian K. wrote: > In OpenSSH-2.3.0, in the file ssh/compat.c, line 61 the line: > > { "^OpenSSH[-_]2\\.[012]", SSH_OLD_SESSIONID }, > > Will not match another OpenSSH-2.3.0 client. The quick fix is to add "3" to > the regular expression as follows: > > { "^OpenSSH[-_]2\\.[0123]", SSH_OLD_SESSIONID }, > > The same bug is in the portable release, but the line number is 65. > > From brhamon at cisco.com Sat Dec 2 09:15:15 2000 From: brhamon at cisco.com (Hamon, Brian K.) Date: Fri, 01 Dec 2000 16:15:15 -0600 Subject: Bug fix -- version grepping in compat.c Message-ID: <4.3.2.7.2.20001201155245.00aede90@3rdclass.cisco.com> I beg your pardon. The problem was definitely on my end and was unrelated to the regular expression I modified. Rebuilding fixed my core dump. I still note a minor issue, which may possibly have some impact. When connecting between two OpenSSH-2.3.0 implementations as follows: ssh -2 -v host The debug output contains a "no match" warning: debug: Connection established. debug: Remote protocol version 1.99, remote software version OpenSSH_2.3.0p1 debug: no match: OpenSSH_2.3.0p1 Enabling compatibility mode for protocol 2.0 Is the "no match" warning worth addressing? Probably not. I made the change in the regular expression and the warning went away. The difference this change makes is whether the SSH_OLD_SESSIONID bug fix is applied. This appears to be irrelevant. The "no match" warning could be considered unexpected behavior, but appears to have no consequences. >what bug does your suggestion fix? >what bug do you see? there is not bug to fix. > > >On Fri, Dec 01, 2000 at 03:39:46PM -0600, Hamon, Brian K. wrote: > > In OpenSSH-2.3.0, in the file ssh/compat.c, line 61 the line: > > > > { "^OpenSSH[-_]2\\.[012]", SSH_OLD_SESSIONID }, > > > > Will not match another OpenSSH-2.3.0 client. The quick fix is to add > "3" to > > the regular expression as follows: > > > > { "^OpenSSH[-_]2\\.[0123]", SSH_OLD_SESSIONID }, > > > > The same bug is in the portable release, but the line number is 65. > > > > From Markus.Friedl at informatik.uni-erlangen.de Sat Dec 2 09:44:35 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 1 Dec 2000 23:44:35 +0100 Subject: Bug fix -- version grepping in compat.c In-Reply-To: <4.3.2.7.2.20001201155245.00aede90@3rdclass.cisco.com>; from brhamon@cisco.com on Fri, Dec 01, 2000 at 04:15:15PM -0600 References: <4.3.2.7.2.20001201155245.00aede90@3rdclass.cisco.com> Message-ID: <20001201234435.A24321@faui02.informatik.uni-erlangen.de> the "no match" message is no warning. it's a debug message: "debug: no match: OpenSSH_2.3.0p1" it informs you that there is no known interoperability bug for version OpenSSH_2.3.0 On Fri, Dec 01, 2000 at 04:15:15PM -0600, Hamon, Brian K. wrote: > I beg your pardon. The problem was definitely on my end and was unrelated > to the regular expression I modified. Rebuilding fixed my core dump. I > still note a minor issue, which may possibly have some impact. > > When connecting between two OpenSSH-2.3.0 implementations as follows: > > ssh -2 -v host > > The debug output contains a "no match" warning: > > debug: Connection established. > debug: Remote protocol version 1.99, remote software version OpenSSH_2.3.0p1 > debug: no match: OpenSSH_2.3.0p1 > Enabling compatibility mode for protocol 2.0 > > Is the "no match" warning worth addressing? Probably not. I made the change > in the regular expression and the warning went away. The difference this > change makes is whether the SSH_OLD_SESSIONID bug fix is applied. This > appears to be irrelevant. 2.3.0 does not have the SSH_OLD_SESSIONID bug. > The "no match" warning could be considered unexpected behavior, but appears > to have no consequences. no, it's not a warning. i cannot see what makes it look like a warning. > > >what bug does your suggestion fix? > >what bug do you see? there is not bug to fix. > > > > > >On Fri, Dec 01, 2000 at 03:39:46PM -0600, Hamon, Brian K. wrote: > > > In OpenSSH-2.3.0, in the file ssh/compat.c, line 61 the line: > > > > > > { "^OpenSSH[-_]2\\.[012]", SSH_OLD_SESSIONID }, > > > > > > Will not match another OpenSSH-2.3.0 client. The quick fix is to add > > "3" to > > > the regular expression as follows: > > > > > > { "^OpenSSH[-_]2\\.[0123]", SSH_OLD_SESSIONID }, > > > > > > The same bug is in the portable release, but the line number is 65. > > > > > > > > From mstone at cs.loyola.edu Sat Dec 2 11:26:07 2000 From: mstone at cs.loyola.edu (Michael Stone) Date: Fri, 1 Dec 2000 19:26:07 -0500 Subject: Bug fix -- version grepping in compat.c In-Reply-To: <20001201234435.A24321@faui02.informatik.uni-erlangen.de>; from Markus.Friedl@informatik.uni-erlangen.de on Fri, Dec 01, 2000 at 11:44:35PM +0100 References: <4.3.2.7.2.20001201155245.00aede90@3rdclass.cisco.com> <20001201234435.A24321@faui02.informatik.uni-erlangen.de> Message-ID: <20001201192607.F5710@justice.loyola.edu> On Fri, Dec 01, 2000 at 11:44:35PM +0100, Markus Friedl wrote: > the "no match" message is no warning. > > it's a debug message: "debug: no match: OpenSSH_2.3.0p1" > > it informs you that there is no known interoperability bug > for version OpenSSH_2.3.0 I think this has come up before. How 'bout changing the message to something like debug: no known interoperability bugs in remote version: [whatever] -- Mike Stone From mdejong at cygnus.com Sat Dec 2 13:46:22 2000 From: mdejong at cygnus.com (Mo DeJong) Date: Fri, 1 Dec 2000 18:46:22 -0800 (PST) Subject: Is fixpaths the only perl dependency? Message-ID: Hello. I just tried to download and build the 2.3.0.p1 (portable) release with Cygwin on an NT box. It fails to build because of the use of a perl script. Cygwin does not have Perl installed by default and to be honest it seems like a bit of a stretch to require perl to be able to build shh, that just makes it harder to build. I poked around and it seems like these files depend on perl: contrib/make-shh-known-hosts.pl fixpaths fixprogs I took a quick peek at the fixpaths script and it does not look too complex, seems like something an AWK script would be able to handle. The fixprogs looks more complex, it is used during the build process or just for testing ala "make check" ? I am willing to hack up an awk script to take the place of fixpaths if it will be accepted into the next release. I have checked out the CVS version of the code but I don't see the scripts in there, is there some other CVS module where these scripts live? thanks Mo DeJong Red Hat Inc From mouring at etoh.eviladmin.org Sat Dec 2 14:49:55 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 1 Dec 2000 21:49:55 -0600 (CST) Subject: Is fixpaths the only perl dependency? In-Reply-To: Message-ID: The CVS tree you are poking around is the OpenBSD tree. The most recent copy can be picked up from the current nightly snapshot at: http://www.mindrot.org/misc/openssh/ I don't believe that OpenSSH portable CVS tree is public at this point. - Ben On Fri, 1 Dec 2000, Mo DeJong wrote: > Hello. > > I just tried to download and build the 2.3.0.p1 > (portable) release with Cygwin on an NT box. > It fails to build because of the use of a perl > script. Cygwin does not have Perl installed > by default and to be honest it seems like > a bit of a stretch to require perl to be > able to build shh, that just makes it harder > to build. > > I poked around and it seems like these files > depend on perl: > > contrib/make-shh-known-hosts.pl > fixpaths > fixprogs > > I took a quick peek at the fixpaths script > and it does not look too complex, seems > like something an AWK script would be > able to handle. The fixprogs looks > more complex, it is used during the > build process or just for testing > ala "make check" ? > > I am willing to hack up an awk script > to take the place of fixpaths if it > will be accepted into the next release. > > I have checked out the CVS version of > the code but I don't see the scripts > in there, is there some other CVS > module where these scripts live? > > thanks > Mo DeJong > Red Hat Inc > From djm at mindrot.org Sat Dec 2 15:39:55 2000 From: djm at mindrot.org (Damien Miller) Date: Sat, 2 Dec 2000 15:39:55 +1100 (EST) Subject: Is fixpaths the only perl dependency? In-Reply-To: Message-ID: On Fri, 1 Dec 2000, Mo DeJong wrote: > I took a quick peek at the fixpaths script > and it does not look too complex, seems > like something an AWK script would be > able to handle. The fixprogs looks > more complex, it is used during the > build process or just for testing > ala "make check" ? It is used for building if you are using the builtin random number collection routines. > I am willing to hack up an awk script > to take the place of fixpaths if it > will be accepted into the next release. I am not really that keen on fixing what isn't broken. If you need to do it for other reasons then sure - go ahead, but IMO you energy would be better spent on one of the TODO items :) -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From djm at mindrot.org Sat Dec 2 15:42:20 2000 From: djm at mindrot.org (Damien Miller) Date: Sat, 2 Dec 2000 15:42:20 +1100 (EST) Subject: Is fixpaths the only perl dependency? In-Reply-To: Message-ID: On Fri, 1 Dec 2000 mouring at etoh.eviladmin.org wrote: > The CVS tree you are poking around is the OpenBSD tree. The > most recent copy can be picked up from the current nightly > snapshot at: http://www.mindrot.org/misc/openssh/ > > I don't believe that OpenSSH portable CVS tree is public at this point. I am working on getting a well-connected box to host a public CVS tree, until then offers of hosting for anonymous-only CVS will be entertained :) -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From mouring at etoh.eviladmin.org Sat Dec 2 17:27:33 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 2 Dec 2000 00:27:33 -0600 (CST) Subject: Is fixpaths the only perl dependency? In-Reply-To: Message-ID: On Sat, 2 Dec 2000, Damien Miller wrote: > On Fri, 1 Dec 2000 mouring at etoh.eviladmin.org wrote: > > > The CVS tree you are poking around is the OpenBSD tree. The > > most recent copy can be picked up from the current nightly > > snapshot at: http://www.mindrot.org/misc/openssh/ > > > > I don't believe that OpenSSH portable CVS tree is public at this point. > > I am working on getting a well-connected box to host a public CVS tree, > until then offers of hosting for anonymous-only CVS will be > entertained :) > I would offer up my connection.. but I doubt a US based 640/272kbit DSL conncetion would be much better. I would like to mirror the whole CVS tree locally. It would make things nicer for me. And I'd be happy to setup a CVSWeb until we have a well connected box as long as everyone leaves me some with bandwidth to live on.=) Hmm.. Wonder if I could talk the owner of vastnet.net in New York to host a CVS server or hand over a machine for me to set it up. He does owe me big still. - Ben From Florian.Weimer at RUS.Uni-Stuttgart.DE Sun Dec 3 01:00:12 2000 From: Florian.Weimer at RUS.Uni-Stuttgart.DE (Florian Weimer) Date: 02 Dec 2000 15:00:12 +0100 Subject: Is fixpaths the only perl dependency? In-Reply-To: References: Message-ID: Damien Miller writes: > I am working on getting a well-connected box to host a public CVS tree, > until then offers of hosting for anonymous-only CVS will be > entertained :) We could host a CVS tree with write access for selected developers. (I'm building up the infrastructure for it anyway.) However, the box is located inside the DFN, the German Research Network, which means that access from the US and other countries probably involves some latencies (although the available bandwidth on our end easily exceeds 10 MBit/sec). -- Florian Weimer Florian.Weimer at RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From pekkas at netcore.fi Sun Dec 3 03:06:56 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 2 Dec 2000 18:06:56 +0200 (EET) Subject: PATCH: Datafellows SSH misdetection in compat.c Message-ID: Hello all, All SSH/Datafellows versions don't match properly in compat.c. This should be fixed in OpenBSD version, naturally. An example of this is: debug: match: 2.1.0.pl2 SSH Secure Shell (non-commercial) pat ^2\. The match should definitely be 2.1.0. This is caused by the fact that a requisite space was added to the check when converting to regexp matching on Oct 10; CVS Id 1.24: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/compat.c?r1=1.23&r2=1.24 More information about the problem: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=21509 Patch attached. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------- next part -------------- --- compat.c.orig Sun Nov 5 07:42:36 2000 +++ compat.c Sat Dec 2 17:58:56 2000 @@ -64,12 +64,12 @@ } check[] = { { "^OpenSSH[-_]2\\.[012]", SSH_OLD_SESSIONID }, { "MindTerm", 0 }, - { "^2\\.1\\.0 ", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| + { "^2\\.1\\.0", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| SSH_OLD_SESSIONID }, { "^2\\.0\\.", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| SSH_OLD_SESSIONID| SSH_BUG_PUBKEYAUTH|SSH_BUG_X11FWD }, - { "^2\\.[23]\\.0 ", SSH_BUG_HMAC}, + { "^2\\.[23]\\.0", SSH_BUG_HMAC}, { "^2\\.[2-9]\\.", 0 }, { "^2\\.4$", SSH_OLD_SESSIONID}, /* Van Dyke */ { "^3\\.0 SecureCRT", SSH_OLD_SESSIONID}, From help at pdscc.com Sun Dec 3 05:13:11 2000 From: help at pdscc.com (Harondel J. Sibble) Date: Sat, 2 Dec 2000 10:13:11 -0800 Subject: pam, openssh and opie Message-ID: <3A28CB37.10609.9D7F60@localhost> Hello folks, this looks about the only place I can find on issues dealing with the subject line. The message that got me posting is included below the line of *'s. Basically I've tried getting this working with Pam authentication and using the new login binary that comes with Opie 2.32. No joy. I am using RedHat 6.0 OpenSSH 2.3.0p1 Pam 0.66-18 I can get the opie challenge only on a console (no openssh), if I attempt to to include the opie_pam module in the /etc/pam.d/sshd file, all authentication fails and no login is possible. Has anyone come up with any workarounds. I had previously tried to get s/key working, but kept bumping up against the issue of s/key not supporting shadow passwords and the pam s/key module is a tad old.... Any suggestions other than abandoning the whole OTP and OpenSSH idea? Note I am not a list member, so please cc me. TIA *************MESSAGE FROM ARCHIVES*************** > mouring at pconline.com said: > > If I knew of a S/Key library outside of the code in the OpenBSD tree > > I'd be happy to compile it up under Linux and see if I can mimic this > > problem. > > There is the OPIE project - which appears to now be defunct and well > hidden. > > I have a working implementation on Linux, with source code taken from > http://www.inner.net/pub/opie/ > > There is also a (basic) PAM implementation for authentication - I've > not even attempted to see if that works with openssh > http://www.tho.org/~andy/pam_opie-0.21.tar.gz > > Unfortunately single use passwords seem to have fallen out of favour - > slightly strange when generation of the passwords is nice and easy now > with Palm devices and the like. > > Nigel. > Harondel J. Sibble Sibble Computer Consulting Creating solutions for the small business and home computer user. help at pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com (604) 739-3709 (voice/fax) (604) 686-2253 (pager) From mouring at etoh.eviladmin.org Sun Dec 3 06:53:08 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 2 Dec 2000 13:53:08 -0600 (CST) Subject: pam, openssh and opie In-Reply-To: <3A28CB37.10609.9D7F60@localhost> Message-ID: The S/Key listed in the 'INSTALL' file in the current snapshot points to a ported version of S/Key libraries from OpenBSD that is known to work with Redhat and shadowing. However it does not support PAM from my understanding. I'm unsure at this point if/when there will be support for advanced PAM features such as alternate authenication. - Ben On Sat, 2 Dec 2000, Harondel J. Sibble wrote: > Hello folks, this looks about the only place I can find on issues dealing > with the subject line. The message that got me posting is included below the > line of *'s. > > Basically I've tried getting this working with Pam authentication and using > the new login binary that comes with Opie 2.32. No joy. > > I am using > RedHat 6.0 > OpenSSH 2.3.0p1 > Pam 0.66-18 > > I can get the opie challenge only on a console (no openssh), if I attempt to > to include the opie_pam module in the /etc/pam.d/sshd file, all > authentication fails and no login is possible. Has anyone come up with any > workarounds. I had previously tried to get s/key working, but kept bumping up > against the issue of s/key not supporting shadow passwords and the pam s/key > module is a tad old.... > > > Any suggestions other than abandoning the whole OTP and OpenSSH idea? > > Note I am not a list member, so please cc me. > > TIA > > > *************MESSAGE FROM ARCHIVES*************** > > > > mouring at pconline.com said: > > > If I knew of a S/Key library outside of the code in the OpenBSD tree > > > I'd be happy to compile it up under Linux and see if I can mimic this > > > problem. > > > > There is the OPIE project - which appears to now be defunct and well > > hidden. > > > > I have a working implementation on Linux, with source code taken from > > http://www.inner.net/pub/opie/ > > > > There is also a (basic) PAM implementation for authentication - I've > > not even attempted to see if that works with openssh > > http://www.tho.org/~andy/pam_opie-0.21.tar.gz > > > > Unfortunately single use passwords seem to have fallen out of favour - > > slightly strange when generation of the passwords is nice and easy now > > with Palm devices and the like. > > > > Nigel. > > > > > > > Harondel J. Sibble > Sibble Computer Consulting > Creating solutions for the small business and home computer user. > help at pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com > (604) 739-3709 (voice/fax) (604) 686-2253 (pager) > From vinschen at redhat.com Sun Dec 3 10:20:20 2000 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 03 Dec 2000 00:20:20 +0100 Subject: Is fixpaths the only perl dependency? References: Message-ID: <3A2983B4.7E5987C8@redhat.com> Damien Miller wrote: > > On Fri, 1 Dec 2000 mouring at etoh.eviladmin.org wrote: > > > The CVS tree you are poking around is the OpenBSD tree. The > > most recent copy can be picked up from the current nightly > > snapshot at: http://www.mindrot.org/misc/openssh/ > > > > I don't believe that OpenSSH portable CVS tree is public at this point. > > I am working on getting a well-connected box to host a public CVS tree, > until then offers of hosting for anonymous-only CVS will be > entertained :) I can offer sources.redhat.com (former sourceware.cygnus.com). It has a fairly good connection and is already home for various open source projects like GDB, binutils, autoconf or Cygwin. Anonymous as well as CVS write access for the maintainer team is available. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin at cygwin.com Red Hat, Inc. mailto:vinschen at redhat.com From mdejong at cygnus.com Sun Dec 3 10:33:30 2000 From: mdejong at cygnus.com (Mo DeJong) Date: Sat, 2 Dec 2000 15:33:30 -0800 (PST) Subject: Hosting openssh on sources.redhat.com (was: Is fixpaths the only perl dependency?) In-Reply-To: <3A2983B4.7E5987C8@redhat.com> Message-ID: On Sun, 3 Dec 2000, Corinna Vinschen wrote: > Damien Miller wrote: > > > > On Fri, 1 Dec 2000 mouring at etoh.eviladmin.org wrote: > > > > > The CVS tree you are poking around is the OpenBSD tree. The > > > most recent copy can be picked up from the current nightly > > > snapshot at: http://www.mindrot.org/misc/openssh/ > > > > > > I don't believe that OpenSSH portable CVS tree is public at this point. > > > > I am working on getting a well-connected box to host a public CVS tree, > > until then offers of hosting for anonymous-only CVS will be > > entertained :) > > I can offer sources.redhat.com (former sourceware.cygnus.com). It has > a fairly good connection and is already home for various open source > projects like GDB, binutils, autoconf or Cygwin. Anonymous as well as > CVS write access for the maintainer team is available. > > Corinna Hosting the project on sourceware also has the nice benefit that releases will appear on all of the mirrors. You could also host the mailing list there, but it does not seem nearly as useful as the CVS access. Mo DeJong Red Hat Inc From djm at mindrot.org Sun Dec 3 11:53:36 2000 From: djm at mindrot.org (Damien Miller) Date: Sun, 3 Dec 2000 11:53:36 +1100 (EST) Subject: pam, openssh and opie In-Reply-To: <3A28CB37.10609.9D7F60@localhost> Message-ID: On Sat, 2 Dec 2000, Harondel J. Sibble wrote: > I can get the opie challenge only on a console (no openssh), if I > attempt to to include the opie_pam module in the /etc/pam.d/sshd > file, all authentication fails and no login is possible. Has > anyone come up with any workarounds. I had previously tried to > get s/key working, but kept bumping up against the issue of s/key > not supporting shadow passwords and the pam s/key module is a tad > old.... I have just committed a patch from Nalin Dahyabhai which enables PAM to use KbdInteractive authentication, which will allow for this sort of challenge/response stuff. It will be in tomorrow morning's snapshot. To use it you need to add "KbdInteractiveAuthentication yes" to both your client and server configs. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From drosih at rpi.edu Sun Dec 3 13:48:35 2000 From: drosih at rpi.edu (Garance A Drosihn) Date: Sat, 2 Dec 2000 21:48:35 -0500 Subject: Hosting openssh's CVS repository In-Reply-To: <3A2983B4.7E5987C8@redhat.com> References: <3A2983B4.7E5987C8@redhat.com> Message-ID: At 12:20 AM +0100 12/3/00, Corinna Vinschen wrote: >Damien Miller wrote: >> > > On Fri, 1 Dec 2000 mouring at etoh.eviladmin.org wrote: > > > I don't believe that OpenSSH portable CVS tree is public at > > > this point. > > > > I am working on getting a well-connected box to host a public > > CVS tree, until then offers of hosting for anonymous-only CVS > > will be entertained :) > >I can offer sources.redhat.com (former sourceware.cygnus.com). It >has a fairly good connection and is already home for various open >source projects like GDB, binutils, autoconf or Cygwin. Anonymous >as well as CVS write access for the maintainer team is available. Would www.sourceforge.net be another possibility? (I'm not all that familiar with sourceforge, but I already HAVE an account there, so that makes it slightly more interesting to me than sources.redhat.com. Also, sources.redhat.com kinda suggests that this is a redhat project, and it might be confusing to have that implied) -- Garance Alistair Drosehn = gad at eclipse.acs.rpi.edu Senior Systems Programmer or gad at freebsd.org Rensselaer Polytechnic Institute or drosih at rpi.edu From mouring at etoh.eviladmin.org Sun Dec 3 20:02:58 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 3 Dec 2000 03:02:58 -0600 (CST) Subject: Hosting openssh's CVS repository In-Reply-To: Message-ID: On Sat, 2 Dec 2000, Garance A Drosihn wrote: > At 12:20 AM +0100 12/3/00, Corinna Vinschen wrote: > >Damien Miller wrote: > >> > > > On Fri, 1 Dec 2000 mouring at etoh.eviladmin.org wrote: > > > > I don't believe that OpenSSH portable CVS tree is public at > > > > this point. > > > > > > I am working on getting a well-connected box to host a public > > > CVS tree, until then offers of hosting for anonymous-only CVS > > > will be entertained :) > > > >I can offer sources.redhat.com (former sourceware.cygnus.com). It > >has a fairly good connection and is already home for various open > >source projects like GDB, binutils, autoconf or Cygwin. Anonymous > >as well as CVS write access for the maintainer team is available. > > Would www.sourceforge.net be another possibility? > > (I'm not all that familiar with sourceforge, but I already HAVE > an account there, so that makes it slightly more interesting to > me than sources.redhat.com. Also, sources.redhat.com kinda > suggests that this is a redhat project, and it might be confusing > to have that implied) > I don't know about Damien, but I would perfer to avoid sourceforge. I become extremely edgy around 'large public CVS farms.' Maybe it goes back to the issue that I'm a closet control freak. =) I think the best thing would be to find one or two well connected machines that will mirror every 2 to 6 hours. And leave the official commit location at mindrot.org. However I will follow the 'hurd' as long as it's not off the nearest cliff.=) - Ben From pekkas at netcore.fi Sun Dec 3 19:21:33 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 3 Dec 2000 10:21:33 +0200 (EET) Subject: pam, openssh and opie In-Reply-To: Message-ID: On Sun, 3 Dec 2000, Damien Miller wrote: > On Sat, 2 Dec 2000, Harondel J. Sibble wrote: > > > I can get the opie challenge only on a console (no openssh), if I > > attempt to to include the opie_pam module in the /etc/pam.d/sshd > > file, all authentication fails and no login is possible. Has > > anyone come up with any workarounds. I had previously tried to > > get s/key working, but kept bumping up against the issue of s/key > > not supporting shadow passwords and the pam s/key module is a tad > > old.... > > I have just committed a patch from Nalin Dahyabhai which enables PAM > to use KbdInteractive authentication, which will allow for this sort > of challenge/response stuff. It will be in tomorrow morning's snapshot. Could we also have the latest ChangeLog exported to www.mindrot.org/misc/openssh/? This could even be done more frequently than the snapshots, since the name is static. A nice way to check what's happening quickly before CVS gets there. I take it you didn't commit RH OpenSSH-2.3.0p1-6 (http://people.redhat.com/nalin/test/) changes to pam.d/sshd though? What's your take on those? They require errata PAM for RHL6x, though. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From mouring at etoh.eviladmin.org Sun Dec 3 20:58:06 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 3 Dec 2000 03:58:06 -0600 (CST) Subject: pam, openssh and opie In-Reply-To: Message-ID: On Sun, 3 Dec 2000, Damien Miller wrote: > On Sat, 2 Dec 2000, Harondel J. Sibble wrote: > > > I can get the opie challenge only on a console (no openssh), if I > > attempt to to include the opie_pam module in the /etc/pam.d/sshd > > file, all authentication fails and no login is possible. Has > > anyone come up with any workarounds. I had previously tried to > > get s/key working, but kept bumping up against the issue of s/key > > not supporting shadow passwords and the pam s/key module is a tad > > old.... > > I have just committed a patch from Nalin Dahyabhai which enables PAM > to use KbdInteractive authentication, which will allow for this sort > of challenge/response stuff. It will be in tomorrow morning's snapshot. > > To use it you need to add "KbdInteractiveAuthentication yes" to both > your client and server configs. > Can I assume that this does not conver Protocol 1? Because I believe KbdInteractive is just Protocol 2. I'd love to unite some of these features a bit more. Can protocol 1 support the same concept, Markus? - Ben From vinschen at redhat.com Sun Dec 3 21:30:11 2000 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 03 Dec 2000 11:30:11 +0100 Subject: Hosting openssh's CVS repository References: <3A2983B4.7E5987C8@redhat.com> Message-ID: <3A2A20B3.77778585@redhat.com> Garance A Drosihn wrote: > At 12:20 AM +0100 12/3/00, Corinna Vinschen wrote: > >I can offer sources.redhat.com (former sourceware.cygnus.com). It > >has a fairly good connection and is already home for various open > >source projects like GDB, binutils, autoconf or Cygwin. Anonymous > >as well as CVS write access for the maintainer team is available. > > Would www.sourceforge.net be another possibility? > > (I'm not all that familiar with sourceforge, but I already HAVE > an account there, so that makes it slightly more interesting to > me than sources.redhat.com. Also, sources.redhat.com kinda > suggests that this is a redhat project, and it might be confusing > to have that implied) It's a pity that this might confuse people. A similar effect never happened when the name was sourceware.cygnus.com. Please note that sources.redhat.com is a box which is in no way inside of the Red Hat network. It's a machine which is 100% dedicated to support open source software and it's maintained by a set of volunteers, only some of them Red Hat stuff. BTW: It would be possible to set up a virtual host name for the box as for eg. `www.cygwin.com'. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin at cygwin.com Red Hat, Inc. mailto:vinschen at redhat.com From bk at rt.fm Sun Dec 3 22:00:57 2000 From: bk at rt.fm (Brian Kifiak) Date: Sun, 3 Dec 2000 05:00:57 -0600 Subject: Hosting openssh's CVS repository In-Reply-To: <3A2A20B3.77778585@redhat.com>; from vinschen@redhat.com on Sun, Dec 03, 2000 at 11:30:11AM +0100 References: <3A2983B4.7E5987C8@redhat.com> <3A2A20B3.77778585@redhat.com> Message-ID: <20001203050057.A18154@rt.fm> > It's a pity that this might confuse people. redhat set it up like this, no? are they trying to confuse people? or maybe it's just for brand recognition. who knows. > Please note that sources.redhat.com is a box which is in no way > inside of the Red Hat network. oh? it's certainly dependant on redhat.com's dns, no? also, http://sources.redhat.com/mission.html "... Red Hat is pleased to provide sources.redhat.com ..." not to mention the redhat logo on everything in http://sources.redhat.com/*. gee, who'd have thought this was inside redhat's network? polluting some (much?) of the userbase by choosing sourceforge (va) or sources (redhat) isn't -- in my opinion -- such a great idea. (it would pollute because not everyone loves va and redhat.) From markus.friedl at informatik.uni-erlangen.de Sun Dec 3 22:12:16 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sun, 3 Dec 2000 12:12:16 +0100 Subject: pam, openssh and opie In-Reply-To: ; from mouring@etoh.eviladmin.org on Sun, Dec 03, 2000 at 03:58:06AM -0600 References: Message-ID: <20001203121216.B5682@folly> On Sun, Dec 03, 2000 at 03:58:06AM -0600, mouring at etoh.eviladmin.org wrote: > Can I assume that this does not conver Protocol 1? Because I believe > KbdInteractive is just Protocol 2. > > I'd love to unite some of these features a bit more. Can protocol 1 > support the same concept, Markus? no, protocol 1 is dead :) i think there will be no major changes in the protocol 1 support. it's too different IMHO. -markus From mdejong at cygnus.com Sun Dec 3 22:15:12 2000 From: mdejong at cygnus.com (Mo DeJong) Date: Sun, 3 Dec 2000 03:15:12 -0800 (PST) Subject: Hosting openssh's CVS repository In-Reply-To: <20001203050057.A18154@rt.fm> Message-ID: On Sun, 3 Dec 2000, Brian Kifiak wrote: > > It's a pity that this might confuse people. > > redhat set it up like this, no? are they trying to confuse people? > or maybe it's just for brand recognition. who knows. Confuse? I am sure it is more for the "brand building" than some nefarious scheme to confuse folks. > > Please note that sources.redhat.com is a box which is in no way > > inside of the Red Hat network. > > oh? it's certainly dependant on redhat.com's dns, no? also, Yeah, so what? The point was that it is a CVS site that can be accessed by anyone, unlike the current situation. > polluting some (much?) of the userbase by choosing sourceforge (va) > or sources (redhat) isn't -- in my opinion -- such a great idea. > (it would pollute because not everyone loves va and redhat.) I am not sure how "lack of like" equates to "pollution", but you folks are welcome to do what you like. Just thought you might like some options. cheers Mo DeJong Red Hat Inc From markus.friedl at informatik.uni-erlangen.de Sun Dec 3 22:30:23 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sun, 3 Dec 2000 12:30:23 +0100 Subject: PATCH: Datafellows SSH misdetection in compat.c In-Reply-To: ; from pekkas@netcore.fi on Sat, Dec 02, 2000 at 06:06:56PM +0200 References: Message-ID: <20001203123023.A23704@folly> On Sat, Dec 02, 2000 at 06:06:56PM +0200, Pekka Savola wrote: > All SSH/Datafellows versions don't match properly in compat.c. This > should be fixed in OpenBSD version, naturally. thanks, i'll added this. (as well as support for ssh/f-secure 2.0.12 pubkey auth). From bk at rt.fm Sun Dec 3 22:31:54 2000 From: bk at rt.fm (Brian Kifiak) Date: Sun, 3 Dec 2000 05:31:54 -0600 Subject: Hosting openssh's CVS repository In-Reply-To: ; from mdejong@cygnus.com on Sun, Dec 03, 2000 at 03:15:12AM -0800 References: <20001203050057.A18154@rt.fm> Message-ID: <20001203053154.A13881@rt.fm> > Confuse? I am sure it is more for the "brand building" > than some nefarious scheme to confuse folks. sarcasm. > > oh? it's certainly dependant on redhat.com's dns, no? also, > > Yeah, so what? there was claim that sources.redhat.com isn't inside redhat's network. it would appear to many who don't posess insight into the beast (redhat) or have esp, that sources.redhat.com is inside redhat's network. > I am not sure how "lack of like" equates to "pollution" assuming a "lack of like" is strong enough, it often results in pollution. > Just thought you might like some options. of course. i'm not suggesting they shouldn't be presented. i'm just raising some issues with the proposal. From vinschen at redhat.com Sun Dec 3 22:39:04 2000 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 03 Dec 2000 12:39:04 +0100 Subject: Hosting openssh's CVS repository References: <3A2983B4.7E5987C8@redhat.com> <3A2A20B3.77778585@redhat.com> <20001203050057.A18154@rt.fm> Message-ID: <3A2A30D8.A4D588CD@redhat.com> Brian Kifiak wrote: > > > It's a pity that this might confuse people. > > redhat set it up like this, no? are they trying to confuse people? > or maybe it's just for brand recognition. who knows. > > > Please note that sources.redhat.com is a box which is in no way > > inside of the Red Hat network. > > oh? it's certainly dependant on redhat.com's dns, no? also, > > http://sources.redhat.com/mission.html > "... Red Hat is pleased to provide sources.redhat.com ..." > > not to mention the redhat logo on everything in > http://sources.redhat.com/*. > > gee, who'd have thought this was inside redhat's network? I'm not sure why that sponsoring is a problem. Red Hat pays the T1. So far so good. > polluting some (much?) of the userbase by choosing sourceforge (va) > or sources (redhat) isn't -- in my opinion -- such a great idea. > (it would pollute because not everyone loves va and redhat.) However, it was simply an offer. I'm not the person for discussing politics. If you think sources.redhat.com is a good starting point for a reliable CVS repository, ok. If not, it's ok, too. Do whatever you want, but spare the list with endless discussions about "politics", "name pollution", "bad and ugly companies" and similar. This is already hit to death on gnu.misc.discuss. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin at cygwin.com Red Hat, Inc. mailto:vinschen at redhat.com From drosih at rpi.edu Mon Dec 4 02:50:56 2000 From: drosih at rpi.edu (Garance A Drosihn) Date: Sun, 3 Dec 2000 10:50:56 -0500 Subject: Hosting openssh's CVS repository In-Reply-To: <3A2A20B3.77778585@redhat.com> References: <3A2983B4.7E5987C8@redhat.com> <3A2A20B3.77778585@redhat.com> Message-ID: At 11:30 AM +0100 12/3/00, Corinna Vinschen wrote: >Garance A Drosihn wrote: >> At 12:20 AM +0100 12/3/00, Corinna Vinschen wrote: >> >I can offer sources.redhat.com (former sourceware.cygnus.com). It >> >has a fairly good connection and is already home for various open >> >source projects like GDB, binutils, autoconf or Cygwin. Anonymous >> >as well as CVS write access for the maintainer team is available. >> >> Would www.sourceforge.net be another possibility? >> >> (I'm not all that familiar with sourceforge, but I already HAVE >> an account there, so that makes it slightly more interesting to >> me than sources.redhat.com. Also, sources.redhat.com kinda >> suggests that this is a redhat project, and it might be confusing >> to have that implied) > >It's a pity that this might confuse people. Well, I didn't mean to instigate a raging debate. My only misgiving is that it sounded like I would have to get yet another account if it weren't at sourceforge (and I already have about a dozen accounts to various web sites). To be honest, I don't even know enough about sourceforge to say how I'd GET to the cvs repository if it were there, but I just assumed that would easy enough to figure out. apologies if the above does trigger an endless debate, I guess I should have avoided mentioning redhat per se. It would be nice to have access to the cvs repository, if we could all agree on where that should be. Maybe have it at sources.redhat.com, but advertise the location via some innocuous CNAME? :-) -- Garance Alistair Drosehn = gad at eclipse.acs.rpi.edu Senior Systems Programmer or gad at freebsd.org Rensselaer Polytechnic Institute or drosih at rpi.edu From vinschen at redhat.com Mon Dec 4 03:17:38 2000 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 03 Dec 2000 17:17:38 +0100 Subject: Hosting openssh's CVS repository References: <3A2983B4.7E5987C8@redhat.com> <3A2A20B3.77778585@redhat.com> Message-ID: <3A2A7222.8CBBBC91@redhat.com> Garance A Drosihn wrote: > apologies if the above does trigger an endless debate, I > guess I should have avoided mentioning redhat per se. It's ok. Sourceforge has the same problem because of it's sponsoring by VA. Bigger companies are for some reason always the bad guys. Seems to be the "Microsoft effect". However, you can be sure that this offer is not a decision of Red Hat as a company but by the volunteering maintainer team of sources. > Maybe have it at sources.redhat.com, but advertise the > location via some innocuous CNAME? :-) Sure. See `www.cygwin.com' which is sources.redhat.com. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin at cygwin.com Red Hat, Inc. mailto:vinschen at redhat.com From markus.friedl at informatik.uni-erlangen.de Mon Dec 4 03:51:39 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sun, 3 Dec 2000 17:51:39 +0100 Subject: Hosting openssh's CVS repository In-Reply-To: <3A2A20B3.77778585@redhat.com>; from vinschen@redhat.com on Sun, Dec 03, 2000 at 11:30:11AM +0100 References: <3A2983B4.7E5987C8@redhat.com> <3A2A20B3.77778585@redhat.com> <20001203050057.A18154@rt.fm> <3A2983B4.7E5987C8@redhat.com> <3A2A20B3.77778585@redhat.com> Message-ID: <20001203175139.C5293@folly> i don't see a problem if redhat, sourceforge and everyone else provide anoncvs mirrors of the openssh repository. i really don't understand the discussion. -markus From chenda at cs.unc.edu Mon Dec 4 06:09:51 2000 From: chenda at cs.unc.edu (Daniel T. Chen) Date: Sun, 3 Dec 2000 14:09:51 -0500 (EST) Subject: Hosting openssh's CVS repository In-Reply-To: <20001203175139.C5293@folly> Message-ID: Agreed, this seems a bit high-handed. Don't let anti-RH or anti-VA zealousness get in the way here. dtc --- Daniel T. Chen | chenda at cs.unc.edu On Sun, 3 Dec 2000, Markus Friedl wrote: > i don't see a problem if redhat, sourceforge and everyone else > provide anoncvs mirrors of the openssh repository. > > i really don't understand the discussion. > > -markus > > From bk at rt.fm Mon Dec 4 08:41:12 2000 From: bk at rt.fm (Brian Kifiak) Date: Sun, 3 Dec 2000 15:41:12 -0600 Subject: Hosting openssh's CVS repository In-Reply-To: <20001203175139.C5293@folly>; from markus.friedl@informatik.uni-erlangen.de on Sun, Dec 03, 2000 at 05:51:39PM +0100 References: <3A2983B4.7E5987C8@redhat.com> <3A2A20B3.77778585@redhat.com> <20001203050057.A18154@rt.fm> <3A2983B4.7E5987C8@redhat.com> <3A2A20B3.77778585@redhat.com> <20001203175139.C5293@folly> Message-ID: <20001203154112.A28993@rt.fm> > i don't see a problem if redhat, sourceforge and everyone else > provide anoncvs mirrors of the openssh repository. i'm mearly saying that it could be an issue for some. that's all. i'm not saying that it would be. i'm not saying that it should be a deciding factor. it's mearly something to think about. if you don't think it's an issue, fine. apologies for giving the wrong impression. From mdejong at cygnus.com Mon Dec 4 15:29:13 2000 From: mdejong at cygnus.com (Mo DeJong) Date: Sun, 3 Dec 2000 20:29:13 -0800 (PST) Subject: Is fixpaths the only perl dependency? In-Reply-To: Message-ID: On Sat, 2 Dec 2000, Damien Miller wrote: > On Fri, 1 Dec 2000, Mo DeJong wrote: > > > I took a quick peek at the fixpaths script > > and it does not look too complex, seems > > like something an AWK script would be > > able to handle. The fixprogs looks > > more complex, it is used during the > > build process or just for testing > > ala "make check" ? > > It is used for building if you are using the builtin random number > collection routines. Ok, I will have to look at that one later. It looks a lot more complex than fixpaths. > > I am willing to hack up an awk script > > to take the place of fixpaths if it > > will be accepted into the next release. > > I am not really that keen on fixing what isn't broken. If you need to > do it for other reasons then sure - go ahead, but IMO you energy would > be better spent on one of the TODO items :) Woops, did I say awk, I meant sed. I am sure from your point of view it is "not broken", but it does not build under the default Cygwin install so that is broken in my book. It is fine to require a bunch of installed programs on a developers box, but if someone just wants to build openssh they should not need to have everything installed. At any rate, I have attached a patch that replaces the fixpaths script with an inlined sed script. I ran it on my Linux box and it worked there, so it should work fine under Cygwin. Of course, I will not be able to test that until tomorrow. I guess you could use this for a ChangeLog entry. 20001203 - (mdejong at redhat.com) Replace fixpaths with a sed script. While writing this up, I noticed something strange. I don't get why paths are replaced in the ssh_config and primes files. There are paths in sshd_config that need replacing but I don't see any in ssh_config or primes. Does anyone know what is up with that? My patch does not change how it currently works, I just thought I might point it out. Mo DeJong Red Hat Inc -------------- next part -------------- diff -u -r old/openssh/Makefile.in openssh/Makefile.in --- old/openssh/Makefile.in Tue Nov 28 18:28:50 2000 +++ openssh/Makefile.in Sun Dec 3 18:48:44 2000 @@ -26,6 +26,7 @@ RANLIB=@RANLIB@ INSTALL=@INSTALL@ PERL=@PERL@ +SED=@SED@ ENT=@ENT@ XAUTH_PATH=@XAUTH_PATH@ LDFLAGS=-L. @LDFLAGS@ @@ -51,20 +52,20 @@ CONFIGFILES=sshd_config ssh_config primes PATHSUBS = \ - -D/etc/ssh_config=$(sysconfdir)/ssh_config \ - -D/etc/ssh_known_hosts=$(sysconfdir)/ssh_known_hosts \ - -D/etc/sshd_config=$(sysconfdir)/sshd_config \ - -D/usr/libexec=$(libexecdir) \ - -D/etc/shosts.equiv=$(sysconfdir)/shosts.equiv \ - -D/etc/ssh_host_key=$(sysconfdir)/ssh_host_key \ - -D/etc/ssh_host_dsa_key=$(sysconfdir)/ssh_host_dsa_key \ - -D/etc/ssh_host_rsa_key=$(sysconfdir)/ssh_host_rsa_key \ - -D/var/run/sshd.pid=$(piddir)/sshd.pid \ - -D/etc/primes=$(sysconfdir)/primes \ - -D/etc/sshrc=$(sysconfdir)/sshrc \ - -D/usr/X11R6/bin/xauth=$(XAUTH_PATH) + -e 's|/etc/ssh_config|$(sysconfdir)/ssh_config|g' \ + -e 's|/etc/ssh_known_hosts|$(sysconfdir)/ssh_known_hosts|g' \ + -e 's|/etc/sshd_config|$(sysconfdir)/sshd_config|g' \ + -e 's|/usr/libexec|$(libexecdir)|g' \ + -e 's|/etc/shosts.equiv|$(sysconfdir)/shosts.equiv|g' \ + -e 's|/etc/ssh_host_key|$(sysconfdir)/ssh_host_key|g' \ + -e 's|/etc/ssh_host_dsa_key|$(sysconfdir)/ssh_host_dsa_key|g' \ + -e 's|/etc/ssh_host_rsa_key|$(sysconfdir)/ssh_host_rsa_key|g' \ + -e 's|/var/run/sshd.pid|$(piddir)/sshd.pid|g' \ + -e 's|/etc/primes|$(sysconfdir)/primes|g' \ + -e 's|/etc/sshrc|$(sysconfdir)/sshrc|g' \ + -e 's|/usr/X11R6/bin/xauth|$(XAUTH_PATH)|g' -FIXPATHSCMD = $(PERL) $(srcdir)/fixpaths $(PATHSUBS) +FIXPATHSCMD = $(SED) $(PATHSUBS) all: $(TARGETS) $(CONFIGFILES) @@ -108,7 +109,7 @@ $(LD) -o $@ logintest.o $(LDFLAGS) loginrec.o -lopenbsd-compat -lssh log-client.o $(LIBS) $(MANPAGES) $(CONFIGFILES):: - $(FIXPATHSCMD) $(srcdir)/$@ + $(FIXPATHSCMD) $(srcdir)/$@ > $@.out clean: rm -f *.o *.a $(TARGETS) logintest config.cache config.log diff -u -r old/openssh/configure.in openssh/configure.in --- old/openssh/configure.in Tue Nov 28 18:28:50 2000 +++ openssh/configure.in Sun Dec 3 19:02:10 2000 @@ -10,6 +10,7 @@ AC_PROG_INSTALL AC_CHECK_PROG(AR, ar, ar) AC_PATH_PROG(PERL, perl) +AC_PATH_PROG(SED, sed) AC_SUBST(PERL) AC_PATH_PROG(ENT, ent) AC_SUBST(ENT) From rob at hagopian.net Mon Dec 4 16:01:18 2000 From: rob at hagopian.net (Rob Hagopian) Date: Mon, 4 Dec 2000 00:01:18 -0500 (EST) Subject: OpenSSH vs ssh.com In-Reply-To: Message-ID: openssh-snap-20001204 vs F-SECURE SSH Version 2.0.12 (from BigIP v3.3) doesn't work for protocol 2 (but is fine for protocol 1), any ideas what would cause this? Below are full debug outputs. In addition, the prior snapshot I had on the machine caused the following output in the sshd on the BigIP machine: Dec 4 03:18:44 b1abv sshd[144]: connection from "10.30.12.11" Dec 4 03:18:44 b1abv sshd[15841]: DNS lookup failed for "10.30.12.11". Dec 4 03:18:45 b1abv sshd[15841]: got bad packet when verifying user root's publickey. Dec 4 03:18:45 b1abv sshd[15841]: Remote host disconnected: Connection closed. Dec 4 03:18:45 b1abv sshd[15841]: connection lost: 'Connection closed.' sshd -v output: b1abv:~# /usr/contrib/sbin/sshd -v WARNING: Development-time debugging not compiled in. WARNING: To enable, configure with --enable-debug and recompile. WARNING: Development-time debugging not compiled in. WARNING: To enable, configure with --enable-debug and recompile. debug: Reading private host key from /etc/ssh2/hostkey debug: Key comment: 1024-bit dsa hostkey debug: Reading public host key from: /etc/ssh2/hostkey.pub debug: Becoming server. debug: Creating listener debug: Listener created sshd[18717]: Listener created on port 22. sshd[18717]: Daemon is running. debug: Running event loop sshd[18717]: connection from "10.30.12.11" debug: ssh_server_wrap: creating transport protocol debug: ssh_server_wrap: creating userauth protocol sshd[18717]: DNS lookup failed for "10.30.12.11". debug: new_connection_callback returning debug: Remote version: SSH-2.0-OpenSSH_2.3.0p2 debug: ssh_sigchld_real_callback debug: ssh_sigchld_process_pid: no handler for pid 18722 code 0 debug: ssh_user_validate_secure_rpc_password: not yet implemented debug: ssh_user_validate_kerberos_password: not yet implemented debug: ssh_user_validate_secure_rpc_password: not yet implemented debug: ssh_user_validate_kerberos_password: not yet implemented debug: ssh_user_validate_secure_rpc_password: not yet implemented debug: ssh_user_validate_kerberos_password: not yet implemented sshd[18717]: Remote host disconnected: Authentication method disabled. (user 'prod', client address '10.30.12.11:648', requested service 'ssh-connection') sshd[18717]: User authentication failed: 'Authentication method disabled. (user 'prod', client address '10.30.12.11:648', requested service 'ssh-connection')' debug: Exiting event loop ssh output: %ssh -v b1abv SSH Version OpenSSH_2.3.0p2, protocol versions 1.5/2.0. Compiled with SSL (0x0090581f). debug: Reading configuration data /usr/etc/ssh_config debug: Applying options for * debug: ssh_connect: getuid 0 geteuid 0 anon 0 debug: Connecting to b1abv [216.200.130.7] port 22. debug: Allocated local port 648. debug: Connection established. debug: identity file /usr/dh/home/prod/.ssh/identity type 0 debug: identity file /usr/dh/home/prod/.ssh/id_dsa type 3 debug: Remote protocol version 1.99, remote software version 2.0.12 F-SECURE SSH debug: match: 2.0.12 F-SECURE SSH pat ^2\.0\. Enabling compatibility mode for protocol 2.0 debug: Local version string SSH-2.0-OpenSSH_2.3.0p2 debug: send KEXINIT debug: done debug: wait KEXINIT debug: got kexinit: diffie-hellman-group1-sha1 debug: got kexinit: ssh-dss debug: got kexinit: 3des-cbc,cast128-cbc,blowfish-cbc,twofish-cbc,arcfour,none debug: got kexinit: 3des-cbc,cast128-cbc,blowfish-cbc,twofish-cbc,arcfour,none debug: got kexinit: hmac-md5,md5-8,none debug: got kexinit: hmac-md5,md5-8,none debug: got kexinit: none,zlib debug: got kexinit: none,zlib debug: got kexinit: debug: got kexinit: debug: first kex follow: 0 debug: reserved: 0 debug: done debug: kex: server->client 3des-cbc hmac-md5 none debug: kex: client->server 3des-cbc hmac-md5 none debug: Sending SSH2_MSG_KEXDH_INIT. debug: bits set: 507/1024 debug: Wait SSH2_MSG_KEXDH_REPLY. debug: Got SSH2_MSG_KEXDH_REPLY. debug: Host 'b1abv' is known and matches the DSA host key. debug: bits set: 500/1024 debug: len 40 datafellows 63 debug: ssh_dss_verify: signature correct debug: Wait SSH2_MSG_NEWKEYS. debug: GOT SSH2_MSG_NEWKEYS. debug: send SSH2_MSG_NEWKEYS. debug: done: send SSH2_MSG_NEWKEYS. debug: done: KEX2. debug: send SSH2_MSG_SERVICE_REQUEST debug: buggy server: service_accept w/o service debug: got SSH2_MSG_SERVICE_ACCEPT debug: authentications that can continue: publickey,password debug: next auth method to try is publickey debug: try pubkey: /usr/dh/home/prod/.ssh/id_dsa debug: read SSH2 private key done: name dsa w/o comment success 1 debug: sig size 20 20 debug: datafellows debug: authentications that can continue: publickey,password debug: next auth method to try is publickey debug: next auth method to try is password prod at b1abv's password: debug: authentications that can continue: publickey,password debug: next auth method to try is password Permission denied, please try again. prod at b1abv's password: debug: authentications that can continue: publickey,password debug: next auth method to try is password Permission denied, please try again. prod at b1abv's password: Received disconnect: 12: Authentication method disabled. debug: Calling cleanup 0x805b184(0x0) -Rob From mouring at etoh.eviladmin.org Mon Dec 4 17:11:53 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 4 Dec 2000 00:11:53 -0600 (CST) Subject: OpenSSH vs ssh.com In-Reply-To: Message-ID: Ask and ye shall recieve. Yesterday (CST), I commited Markus' patches to provide F-SECURE support for 2.0.12. So they should be in the snapshots now. - Ben On Mon, 4 Dec 2000, Rob Hagopian wrote: > openssh-snap-20001204 vs F-SECURE SSH Version 2.0.12 (from BigIP v3.3) > doesn't work for protocol 2 (but is fine for protocol 1), any ideas what > would cause this? Below are full debug outputs. In addition, the prior > snapshot I had on the machine caused the following output in the sshd on > the BigIP machine: > > Dec 4 03:18:44 b1abv sshd[144]: connection from "10.30.12.11" > Dec 4 03:18:44 b1abv sshd[15841]: DNS lookup failed for "10.30.12.11". > Dec 4 03:18:45 b1abv sshd[15841]: got bad packet when verifying user > root's publickey. > Dec 4 03:18:45 b1abv sshd[15841]: Remote host disconnected: Connection > closed. > Dec 4 03:18:45 b1abv sshd[15841]: connection lost: 'Connection closed.' > > sshd -v output: > b1abv:~# /usr/contrib/sbin/sshd -v > WARNING: Development-time debugging not compiled in. > WARNING: To enable, configure with --enable-debug and recompile. > WARNING: Development-time debugging not compiled in. > WARNING: To enable, configure with --enable-debug and recompile. > debug: Reading private host key from /etc/ssh2/hostkey > debug: Key comment: 1024-bit dsa hostkey > debug: Reading public host key from: /etc/ssh2/hostkey.pub > debug: Becoming server. > debug: Creating listener > debug: Listener created > sshd[18717]: Listener created on port 22. > sshd[18717]: Daemon is running. > debug: Running event loop > sshd[18717]: connection from "10.30.12.11" > debug: ssh_server_wrap: creating transport protocol > debug: ssh_server_wrap: creating userauth protocol > sshd[18717]: DNS lookup failed for "10.30.12.11". > debug: new_connection_callback returning > debug: Remote version: SSH-2.0-OpenSSH_2.3.0p2 > > debug: ssh_sigchld_real_callback > debug: ssh_sigchld_process_pid: no handler for pid 18722 code 0 > debug: ssh_user_validate_secure_rpc_password: not yet implemented > debug: ssh_user_validate_kerberos_password: not yet implemented > debug: ssh_user_validate_secure_rpc_password: not yet implemented > debug: ssh_user_validate_kerberos_password: not yet implemented > debug: ssh_user_validate_secure_rpc_password: not yet implemented > debug: ssh_user_validate_kerberos_password: not yet implemented > sshd[18717]: Remote host disconnected: Authentication method > disabled. (user 'prod', client address '10.30.12.11:648', requested > service 'ssh-connection') > sshd[18717]: User authentication failed: 'Authentication method > disabled. (user 'prod', client address '10.30.12.11:648', requested > service 'ssh-connection')' > debug: Exiting event loop > > ssh output: > %ssh -v b1abv > SSH Version OpenSSH_2.3.0p2, protocol versions 1.5/2.0. > Compiled with SSL (0x0090581f). > debug: Reading configuration data /usr/etc/ssh_config > debug: Applying options for * > debug: ssh_connect: getuid 0 geteuid 0 anon 0 > debug: Connecting to b1abv [216.200.130.7] port 22. > debug: Allocated local port 648. > debug: Connection established. > debug: identity file /usr/dh/home/prod/.ssh/identity type 0 > debug: identity file /usr/dh/home/prod/.ssh/id_dsa type 3 > debug: Remote protocol version 1.99, remote software version 2.0.12 > F-SECURE SSH > debug: match: 2.0.12 F-SECURE SSH pat ^2\.0\. > > Enabling compatibility mode for protocol 2.0 > debug: Local version string SSH-2.0-OpenSSH_2.3.0p2 > debug: send KEXINIT > debug: done > debug: wait KEXINIT > debug: got kexinit: diffie-hellman-group1-sha1 > debug: got kexinit: ssh-dss > debug: got > kexinit: 3des-cbc,cast128-cbc,blowfish-cbc,twofish-cbc,arcfour,none > debug: got > kexinit: 3des-cbc,cast128-cbc,blowfish-cbc,twofish-cbc,arcfour,none > debug: got kexinit: hmac-md5,md5-8,none > debug: got kexinit: hmac-md5,md5-8,none > debug: got kexinit: none,zlib > debug: got kexinit: none,zlib > debug: got kexinit: > debug: got kexinit: > debug: first kex follow: 0 > debug: reserved: 0 > debug: done > debug: kex: server->client 3des-cbc hmac-md5 none > debug: kex: client->server 3des-cbc hmac-md5 none > debug: Sending SSH2_MSG_KEXDH_INIT. > debug: bits set: 507/1024 > debug: Wait SSH2_MSG_KEXDH_REPLY. > debug: Got SSH2_MSG_KEXDH_REPLY. > debug: Host 'b1abv' is known and matches the DSA host key. > debug: bits set: 500/1024 > debug: len 40 datafellows 63 > debug: ssh_dss_verify: signature correct > debug: Wait SSH2_MSG_NEWKEYS. > debug: GOT SSH2_MSG_NEWKEYS. > debug: send SSH2_MSG_NEWKEYS. > debug: done: send SSH2_MSG_NEWKEYS. > debug: done: KEX2. > debug: send SSH2_MSG_SERVICE_REQUEST > debug: buggy server: service_accept w/o service > debug: got SSH2_MSG_SERVICE_ACCEPT > debug: authentications that can continue: publickey,password > debug: next auth method to try is publickey > debug: try pubkey: /usr/dh/home/prod/.ssh/id_dsa > debug: read SSH2 private key done: name dsa w/o comment success 1 > debug: sig size 20 20 > debug: datafellows > debug: authentications that can continue: publickey,password > debug: next auth method to try is publickey > debug: next auth method to try is password > prod at b1abv's password: > debug: authentications that can continue: publickey,password > debug: next auth method to try is password > Permission denied, please try again. > prod at b1abv's password: > debug: authentications that can continue: publickey,password > debug: next auth method to try is password > Permission denied, please try again. > prod at b1abv's password: > Received disconnect: 12: Authentication method disabled. > debug: Calling cleanup 0x805b184(0x0) > -Rob > > From wngdn at src.uchicago.edu Tue Dec 5 10:11:03 2000 From: wngdn at src.uchicago.edu (Kelsang Wangden) Date: Mon, 4 Dec 2000 17:11:03 -0600 Subject: Makefile bug in 2.3.0p1 Message-ID: <20001204171103.C20109@src.uchicago.edu> Hi all, I just installed OpenSSH 2.3.0p1 on an HP-UX 10.20 box, and I'm psyched to try out sftpd. I found one bug in the Makefile. Under the host-key and host-key-force targets, ssh-keygen is called as '$(srcdir)/ssh-keygen'. This is fine if you configure and build in the source dir, but not if you build in a separate dir as I did in order to build several architechtures from one source tree. A kludgy fix would be to call it as './ssh-keygen'. A real fix would be to have the path to the build dir in a variable and do something like '$(builddir)/ssh-keygen'. Please Cc me on replies, since I don't subscribe to this list. Thanks, Wangden From rob at hagopian.net Tue Dec 5 10:16:26 2000 From: rob at hagopian.net (Rob Hagopian) Date: Mon, 4 Dec 2000 18:16:26 -0500 (EST) Subject: OpenSSH vs ssh.com In-Reply-To: Message-ID: Excellent. Thx! -Rob On Mon, 4 Dec 2000 mouring at etoh.eviladmin.org wrote: > > Ask and ye shall recieve. Yesterday (CST), I commited Markus' > patches to provide F-SECURE support for 2.0.12. So they should be in the > snapshots now. > > - Ben > > > On Mon, 4 Dec 2000, Rob Hagopian wrote: > > > openssh-snap-20001204 vs F-SECURE SSH Version 2.0.12 (from BigIP v3.3) > > doesn't work for protocol 2 (but is fine for protocol 1), any ideas what > > would cause this? Below are full debug outputs. In addition, the prior > > snapshot I had on the machine caused the following output in the sshd on > > the BigIP machine: > > > > Dec 4 03:18:44 b1abv sshd[144]: connection from "10.30.12.11" > > Dec 4 03:18:44 b1abv sshd[15841]: DNS lookup failed for "10.30.12.11". > > Dec 4 03:18:45 b1abv sshd[15841]: got bad packet when verifying user > > root's publickey. > > Dec 4 03:18:45 b1abv sshd[15841]: Remote host disconnected: Connection > > closed. > > Dec 4 03:18:45 b1abv sshd[15841]: connection lost: 'Connection closed.' > > > > sshd -v output: > > b1abv:~# /usr/contrib/sbin/sshd -v > > WARNING: Development-time debugging not compiled in. > > WARNING: To enable, configure with --enable-debug and recompile. > > WARNING: Development-time debugging not compiled in. > > WARNING: To enable, configure with --enable-debug and recompile. > > debug: Reading private host key from /etc/ssh2/hostkey > > debug: Key comment: 1024-bit dsa hostkey > > debug: Reading public host key from: /etc/ssh2/hostkey.pub > > debug: Becoming server. > > debug: Creating listener > > debug: Listener created > > sshd[18717]: Listener created on port 22. > > sshd[18717]: Daemon is running. > > debug: Running event loop > > sshd[18717]: connection from "10.30.12.11" > > debug: ssh_server_wrap: creating transport protocol > > debug: ssh_server_wrap: creating userauth protocol > > sshd[18717]: DNS lookup failed for "10.30.12.11". > > debug: new_connection_callback returning > > debug: Remote version: SSH-2.0-OpenSSH_2.3.0p2 > > > > debug: ssh_sigchld_real_callback > > debug: ssh_sigchld_process_pid: no handler for pid 18722 code 0 > > debug: ssh_user_validate_secure_rpc_password: not yet implemented > > debug: ssh_user_validate_kerberos_password: not yet implemented > > debug: ssh_user_validate_secure_rpc_password: not yet implemented > > debug: ssh_user_validate_kerberos_password: not yet implemented > > debug: ssh_user_validate_secure_rpc_password: not yet implemented > > debug: ssh_user_validate_kerberos_password: not yet implemented > > sshd[18717]: Remote host disconnected: Authentication method > > disabled. (user 'prod', client address '10.30.12.11:648', requested > > service 'ssh-connection') > > sshd[18717]: User authentication failed: 'Authentication method > > disabled. (user 'prod', client address '10.30.12.11:648', requested > > service 'ssh-connection')' > > debug: Exiting event loop > > > > ssh output: > > %ssh -v b1abv > > SSH Version OpenSSH_2.3.0p2, protocol versions 1.5/2.0. > > Compiled with SSL (0x0090581f). > > debug: Reading configuration data /usr/etc/ssh_config > > debug: Applying options for * > > debug: ssh_connect: getuid 0 geteuid 0 anon 0 > > debug: Connecting to b1abv [216.200.130.7] port 22. > > debug: Allocated local port 648. > > debug: Connection established. > > debug: identity file /usr/dh/home/prod/.ssh/identity type 0 > > debug: identity file /usr/dh/home/prod/.ssh/id_dsa type 3 > > debug: Remote protocol version 1.99, remote software version 2.0.12 > > F-SECURE SSH > > debug: match: 2.0.12 F-SECURE SSH pat ^2\.0\. > > > > Enabling compatibility mode for protocol 2.0 > > debug: Local version string SSH-2.0-OpenSSH_2.3.0p2 > > debug: send KEXINIT > > debug: done > > debug: wait KEXINIT > > debug: got kexinit: diffie-hellman-group1-sha1 > > debug: got kexinit: ssh-dss > > debug: got > > kexinit: 3des-cbc,cast128-cbc,blowfish-cbc,twofish-cbc,arcfour,none > > debug: got > > kexinit: 3des-cbc,cast128-cbc,blowfish-cbc,twofish-cbc,arcfour,none > > debug: got kexinit: hmac-md5,md5-8,none > > debug: got kexinit: hmac-md5,md5-8,none > > debug: got kexinit: none,zlib > > debug: got kexinit: none,zlib > > debug: got kexinit: > > debug: got kexinit: > > debug: first kex follow: 0 > > debug: reserved: 0 > > debug: done > > debug: kex: server->client 3des-cbc hmac-md5 none > > debug: kex: client->server 3des-cbc hmac-md5 none > > debug: Sending SSH2_MSG_KEXDH_INIT. > > debug: bits set: 507/1024 > > debug: Wait SSH2_MSG_KEXDH_REPLY. > > debug: Got SSH2_MSG_KEXDH_REPLY. > > debug: Host 'b1abv' is known and matches the DSA host key. > > debug: bits set: 500/1024 > > debug: len 40 datafellows 63 > > debug: ssh_dss_verify: signature correct > > debug: Wait SSH2_MSG_NEWKEYS. > > debug: GOT SSH2_MSG_NEWKEYS. > > debug: send SSH2_MSG_NEWKEYS. > > debug: done: send SSH2_MSG_NEWKEYS. > > debug: done: KEX2. > > debug: send SSH2_MSG_SERVICE_REQUEST > > debug: buggy server: service_accept w/o service > > debug: got SSH2_MSG_SERVICE_ACCEPT > > debug: authentications that can continue: publickey,password > > debug: next auth method to try is publickey > > debug: try pubkey: /usr/dh/home/prod/.ssh/id_dsa > > debug: read SSH2 private key done: name dsa w/o comment success 1 > > debug: sig size 20 20 > > debug: datafellows > > debug: authentications that can continue: publickey,password > > debug: next auth method to try is publickey > > debug: next auth method to try is password > > prod at b1abv's password: > > debug: authentications that can continue: publickey,password > > debug: next auth method to try is password > > Permission denied, please try again. > > prod at b1abv's password: > > debug: authentications that can continue: publickey,password > > debug: next auth method to try is password > > Permission denied, please try again. > > prod at b1abv's password: > > Received disconnect: 12: Authentication method disabled. > > debug: Calling cleanup 0x805b184(0x0) > > -Rob > > > > > From pekkas at netcore.fi Tue Dec 5 10:20:46 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 5 Dec 2000 01:20:46 +0200 (EET) Subject: Makefile bug in 2.3.0p1 In-Reply-To: <20001204171103.C20109@src.uchicago.edu> Message-ID: On Mon, 4 Dec 2000, Kelsang Wangden wrote: > I just installed OpenSSH 2.3.0p1 on an HP-UX 10.20 box, and I'm > psyched to try out sftpd. > > I found one bug in the Makefile. Under the host-key and > host-key-force targets, ssh-keygen is called as > '$(srcdir)/ssh-keygen'. This is fine if you configure and build in > the source dir, but not if you build in a separate dir as I did in > order to build several architechtures from one source tree. > > A kludgy fix would be to call it as './ssh-keygen'. A real fix would > be to have the path to the build dir in a variable and do something > like '$(builddir)/ssh-keygen'. This is './ssh-keygen' in the post-2.3.0p1 snapshots (http://www.mindrot.org/misc/openssh). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From jpm at class.de Wed Dec 6 00:03:12 2000 From: jpm at class.de (Juergen P. Meier) Date: Tue, 5 Dec 2000 14:03:12 +0100 Subject: Bugreport: openssh-2.3.0p1 scp to SSH2 (2.0.13) server Message-ID: <20001205140312.A20194@fm.rz.fh-muenchen.de> Hi, this is a type 3 bugreport ;) ( 3. Repeatable problems specific to your software layout.) first of all i must state, that i run openssh on a fairly old redhat based system (redhat 6.1). if you have any further questions, feel free to contact me. configure options: CFLAGS="-O2 -m486" ./configure --without-rsh --with-tcp-wrappers --prefix=/opt/openssh-2.3.0 --with-default-path=/bin:/usr/bin:/usr/sbin:/opt/openssh-2.3.0/bin:/usr/local/bin output of the scp command: test at foo:~> scp localtest test at bar:/tmp/test -v Executing: program /opt/openssh-2.3.0/bin/ssh host bar, user test, command scp -v -t /tmp/test test at bar's password: warning: Development-time debugging not compiled in. warning: To enable, configure with --enable-debug and recompile. warning: Executing scp1 compatibility. select: Bad file descriptor lost connection Note: on the target runs a SSH-1.99-2.0.13 (non-commercial) scp runs fine in every other combination (openssh <-> openssh, openssh <-> ssh1 and ssh2 -> openssh) just that one direction, from openssh to ssh2 does not work. Lack of other platforms made it impossible for me to test different machines. strace from the exec'ed ssh where the error happened: read(4, "\n", 1) = 1 ioctl(4, SNDCTL_TMR_START, {B38400 opost isig icanon echo ...}) = 0 ioctl(4, TCGETS, {B38400 opost isig icanon echo ...}) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 write(4, "\n", 1) = 1 close(4) = 0 open("/dev/tty", O_RDWR) = 4 write(4, "test at bar\'s password: ", 19) = 19 rt_sigprocmask(SIG_BLOCK, [TSTP], [], 8) = 0 rt_sigaction(SIGINT, {0x805a7d0, [], 0x4000000}, {SIG_DFL}, 8) = 0 ioctl(4, TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(4, SNDCTL_TMR_START, {B38400 opost isig icanon -echo ...}) = 0 ioctl(4, TCGETS, {B38400 opost isig icanon -echo ...}) = 0 read(4, "x", 1) = 1 read(4, "x", 1) = 1 read(4, "x", 1) = 1 read(4, "x", 1) = 1 read(4, "x", 1) = 1 read(4, "x", 1) = 1 read(4, "x", 1) = 1 read(4, "x", 1) = 1 read(4, "\n", 1) = 1 ioctl(4, SNDCTL_TMR_START, {B38400 opost isig icanon echo ...}) = 0 ioctl(4, TCGETS, {B38400 opost isig icanon echo ...}) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 write(4, "\n", 1) = 1 close(4) = 0 write(3, "X=\340\0261\26\243\373\355<\305duV _b\320+\312B\353\253"..., 80) = 80 select(4, [3], NULL, NULL, NULL) = 1 (in [3]) read(3, "Hp\226B\223\363\205\267\267\337\315\5\5`wZ.\223\237\25"..., 8192) = 32 dup(0) = 4 dup(1) = 5 dup(2) = 6 ioctl(4, TCGETS, 0xbffff574) = -1 EINVAL (Invalid argument) fcntl(4, F_GETFL) = 0 (flags O_RDONLY) fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 ioctl(5, TCGETS, 0xbffff574) = -1 EINVAL (Invalid argument) fcntl(5, F_GETFL) = 0x1 (flags O_WRONLY) fcntl(5, F_SETFL, O_WRONLY|O_NONBLOCK) = 0 ioctl(6, TCGETS, {B38400 opost isig icanon echo ...}) = 0 brk(0x80fd000) = 0x80fd000 gettimeofday({976017265, 12614}, NULL) = 0 brk(0x80ff000) = 0x80ff000 rt_sigaction(SIGINT, {0x8052540, [], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGQUIT, {0x8052540, [], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTERM, {0x8052540, [], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0 select(7, [3], [3], NULL, NULL) = 1 (out [3]) write(3, "L\210K\275U\330\352\33p\247\334\324\344\306\231\321\273"..., 56) = 56 select(7, [3], [], NULL, NULL) = 1 (in [3]) read(3, "w.2\247C&\310\330\5]rhP)Y\221;\267\263\30I\321\213\325"..., 8192) = 48 select(7, [3 4], [3], NULL, NULL) = 1 (out [3]) write(3, "\335g\342\317\274Nu9\332\0s\323P\" \250M\1\356\304\343"..., 64) = 64 select(7, [3 4], [], NULL, NULL) = 1 (in [3]) read(3, "\345\314\235zlA\r\333\316\242>\16\0,\314e\375\4\255Ac\334"..., 8192) = 160 select(7, [3 4], [6], NULL, NULL) = 1 (out [6]) write(6, "warning: Development-time debugg"..., 120) = 120 select(7, [3 4], [], NULL, NULL) = 1 (in [3]) read(3, "T\31`\274\314\6(r+E\7N\343\333u\3242\234N\30\327N\346_"..., 8192) = 256 close(4) = 0 close(5) = 0 brk(0x8101000) = 0x8101000 close(6) = 0 select(7, [3], [3 6], NULL, NULL) = -1 EBADF (Bad file descriptor) open("/usr/share/locale/locale.alias", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=2174, ...}) = 0 mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40013000 read(4, "# Locale name alias data base.\n#"..., 4096) = 2174 read(4, "", 4096) = 0 close(4) = 0 munmap(0x40013000, 4096) = 0 open("/usr/share/i18n/locale.alias", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "select: Bad file descriptor\r\n", 29) = 29 gettimeofday({976017265, 87243}, NULL) = 0 shutdown(3, 2 /* send and receive */) = 0 close(3) = 0 _exit(1) = ? greetings, Juergen -- Juergen P. Meier email: jpm at class.de From sandra at tomandandy.com Wed Dec 6 04:39:03 2000 From: sandra at tomandandy.com (Sandra Panesso) Date: Tue, 05 Dec 2000 12:39:03 -0500 Subject: openssh problems Message-ID: <3A2D2836.8C03E3C3@tomandandy.com> Hi everyone: I am new so I hope so that this list will be the correct place for my question. I install openssh-2.3.0p1 yesterday on a machine with Red Hut Linux 6.2 and it was fine as client but not as server in other words I can use openssh from my machine to get in the other machines but when I try to do from another machines to the machine that I mentioned above, I got a error that said "permission denied, try again". I have the same problem with two machines more running on Red Hut LInux 6.2 but they have openssh 2.2. I don't know if it is something wrong that i did when I compile it but the process that I used was this ./configure make make test make install (as root). If somebody could help me I would really appreciated Sandra From markus.friedl at informatik.uni-erlangen.de Wed Dec 6 07:17:09 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Tue, 5 Dec 2000 21:17:09 +0100 Subject: openssh problems In-Reply-To: <3A2D2836.8C03E3C3@tomandandy.com>; from sandra@tomandandy.com on Tue, Dec 05, 2000 at 12:39:03PM -0500 References: <3A2D2836.8C03E3C3@tomandandy.com> Message-ID: <20001205211709.D281@folly> did you read INSTALL and setup PAM? On Tue, Dec 05, 2000 at 12:39:03PM -0500, Sandra Panesso wrote: > Hi everyone: > > I am new so I hope so that this list will be the correct place for my > question. > > I install openssh-2.3.0p1 yesterday on a machine with Red Hut Linux > 6.2 and it was fine as client but not as server in other words I can > use openssh from my machine to get in the other machines but when I try > to do from another machines to the machine that I mentioned above, I got > a error that said "permission denied, try again". I have the same > problem with two machines more running on Red Hut LInux 6.2 but they > have openssh 2.2. I don't know if it is something wrong that i did > when I compile it but the process that I used was this > ./configure > make > make test > make install (as root). > > If somebody could help me I would really appreciated > > Sandra > > From pekkas at netcore.fi Wed Dec 6 07:26:55 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 5 Dec 2000 22:26:55 +0200 (EET) Subject: openssh problems In-Reply-To: <3A2D2836.8C03E3C3@tomandandy.com> Message-ID: On Tue, 5 Dec 2000, Sandra Panesso wrote: > I install openssh-2.3.0p1 yesterday on a machine with Red Hut Linux > 6.2 and it was fine as client but not as server in other words I can > use openssh from my machine to get in the other machines but when I try > to do from another machines to the machine that I mentioned above, I got > a error that said "permission denied, try again". I have the same > problem with two machines more running on Red Hut LInux 6.2 but they > have openssh 2.2. I don't know if it is something wrong that i did > when I compile it but the process that I used was this > ./configure > make > make test > make install (as root). > > If somebody could help me I would really appreciated Try installing from RPM, it's easier. If that won't help, we need to see the debugging output. Use 'sshd -d -d -d' and 'ssh -v -v -v' or the like. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From markus.friedl at informatik.uni-erlangen.de Wed Dec 6 07:16:46 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Tue, 5 Dec 2000 21:16:46 +0100 Subject: Bugreport: openssh-2.3.0p1 scp to SSH2 (2.0.13) server In-Reply-To: <20001205140312.A20194@fm.rz.fh-muenchen.de>; from jpm@class.de on Tue, Dec 05, 2000 at 02:03:12PM +0100 References: <20001205140312.A20194@fm.rz.fh-muenchen.de> Message-ID: <20001205211646.C281@folly> you can scp only to a ssh-2.0.13 server if the server has scp1 installed. i think you also have to make sure that scp on the server is a link to scp1. -m On Tue, Dec 05, 2000 at 02:03:12PM +0100, Juergen P. Meier wrote: > Hi, > this is a type 3 bugreport ;) > ( 3. Repeatable problems specific to your software layout.) > first of all i must state, that i run openssh on a fairly > old redhat based system (redhat 6.1). > > if you have any further questions, feel free to contact me. > > configure options: > CFLAGS="-O2 -m486" ./configure --without-rsh --with-tcp-wrappers --prefix=/opt/openssh-2.3.0 --with-default-path=/bin:/usr/bin:/usr/sbin:/opt/openssh-2.3.0/bin:/usr/local/bin > > output of the scp command: > test at foo:~> scp localtest test at bar:/tmp/test -v > Executing: program /opt/openssh-2.3.0/bin/ssh host bar, user test, command scp -v -t /tmp/test > test at bar's password: > warning: Development-time debugging not compiled in. > warning: To enable, configure with --enable-debug and recompile. > warning: Executing scp1 compatibility. > select: Bad file descriptor > lost connection > > Note: on the target runs a SSH-1.99-2.0.13 (non-commercial) > > scp runs fine in every other combination (openssh <-> openssh, > openssh <-> ssh1 and ssh2 -> openssh) just that one direction, > from openssh to ssh2 does not work. > > Lack of other platforms made it impossible for me to test different machines. > > strace from the exec'ed ssh where the error happened: > > read(4, "\n", 1) = 1 > ioctl(4, SNDCTL_TMR_START, {B38400 opost isig icanon echo ...}) = 0 > ioctl(4, TCGETS, {B38400 opost isig icanon echo ...}) = 0 > rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 > rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 > write(4, "\n", 1) = 1 > close(4) = 0 > open("/dev/tty", O_RDWR) = 4 > write(4, "test at bar\'s password: ", 19) = 19 > rt_sigprocmask(SIG_BLOCK, [TSTP], [], 8) = 0 > rt_sigaction(SIGINT, {0x805a7d0, [], 0x4000000}, {SIG_DFL}, 8) = 0 > ioctl(4, TCGETS, {B38400 opost isig icanon echo ...}) = 0 > ioctl(4, SNDCTL_TMR_START, {B38400 opost isig icanon -echo ...}) = 0 > ioctl(4, TCGETS, {B38400 opost isig icanon -echo ...}) = 0 > read(4, "x", 1) = 1 > read(4, "x", 1) = 1 > read(4, "x", 1) = 1 > read(4, "x", 1) = 1 > read(4, "x", 1) = 1 > read(4, "x", 1) = 1 > read(4, "x", 1) = 1 > read(4, "x", 1) = 1 > read(4, "\n", 1) = 1 > ioctl(4, SNDCTL_TMR_START, {B38400 opost isig icanon echo ...}) = 0 > ioctl(4, TCGETS, {B38400 opost isig icanon echo ...}) = 0 > rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 > rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 > write(4, "\n", 1) = 1 > close(4) = 0 > write(3, "X=\340\0261\26\243\373\355<\305duV _b\320+\312B\353\253"..., 80) = 80 > select(4, [3], NULL, NULL, NULL) = 1 (in [3]) > read(3, "Hp\226B\223\363\205\267\267\337\315\5\5`wZ.\223\237\25"..., 8192) = 32 > dup(0) = 4 > dup(1) = 5 > dup(2) = 6 > ioctl(4, TCGETS, 0xbffff574) = -1 EINVAL (Invalid argument) > fcntl(4, F_GETFL) = 0 (flags O_RDONLY) > fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 > ioctl(5, TCGETS, 0xbffff574) = -1 EINVAL (Invalid argument) > fcntl(5, F_GETFL) = 0x1 (flags O_WRONLY) > fcntl(5, F_SETFL, O_WRONLY|O_NONBLOCK) = 0 > ioctl(6, TCGETS, {B38400 opost isig icanon echo ...}) = 0 > brk(0x80fd000) = 0x80fd000 > gettimeofday({976017265, 12614}, NULL) = 0 > brk(0x80ff000) = 0x80ff000 > rt_sigaction(SIGINT, {0x8052540, [], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGQUIT, {0x8052540, [], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGTERM, {0x8052540, [], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0 > select(7, [3], [3], NULL, NULL) = 1 (out [3]) > write(3, "L\210K\275U\330\352\33p\247\334\324\344\306\231\321\273"..., 56) = 56 > select(7, [3], [], NULL, NULL) = 1 (in [3]) > read(3, "w.2\247C&\310\330\5]rhP)Y\221;\267\263\30I\321\213\325"..., 8192) = 48 > select(7, [3 4], [3], NULL, NULL) = 1 (out [3]) > write(3, "\335g\342\317\274Nu9\332\0s\323P\" \250M\1\356\304\343"..., 64) = 64 > select(7, [3 4], [], NULL, NULL) = 1 (in [3]) > read(3, "\345\314\235zlA\r\333\316\242>\16\0,\314e\375\4\255Ac\334"..., 8192) = 160 > select(7, [3 4], [6], NULL, NULL) = 1 (out [6]) > write(6, "warning: Development-time debugg"..., 120) = 120 > select(7, [3 4], [], NULL, NULL) = 1 (in [3]) > read(3, "T\31`\274\314\6(r+E\7N\343\333u\3242\234N\30\327N\346_"..., 8192) = 256 > close(4) = 0 > close(5) = 0 > brk(0x8101000) = 0x8101000 > close(6) = 0 > select(7, [3], [3 6], NULL, NULL) = -1 EBADF (Bad file descriptor) > open("/usr/share/locale/locale.alias", O_RDONLY) = 4 > fstat(4, {st_mode=S_IFREG|0644, st_size=2174, ...}) = 0 > mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40013000 > read(4, "# Locale name alias data base.\n#"..., 4096) = 2174 > read(4, "", 4096) = 0 > close(4) = 0 > munmap(0x40013000, 4096) = 0 > open("/usr/share/i18n/locale.alias", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) > write(2, "select: Bad file descriptor\r\n", 29) = 29 > gettimeofday({976017265, 87243}, NULL) = 0 > shutdown(3, 2 /* send and receive */) = 0 > close(3) = 0 > _exit(1) = ? > > > > > greetings, > > Juergen > > -- > Juergen P. Meier email: jpm at class.de > From mdejong at cygnus.com Wed Dec 6 08:00:23 2000 From: mdejong at cygnus.com (Mo DeJong) Date: Tue, 5 Dec 2000 13:00:23 -0800 (PST) Subject: Is fixpaths the only perl dependency? In-Reply-To: Message-ID: > On Sat, 2 Dec 2000, Damien Miller wrote: > > At any rate, I have attached a patch that replaces the > fixpaths script with an inlined sed script. I ran it > on my Linux box and it worked there, so it should > work fine under Cygwin. Of course, I will not be able > to test that until tomorrow. Just an FYI, I tested these changes out under Cygwin and ssh now builds out of the box with the default Cygwin install. One thing I noticed, is that in the 2.2.0p1 release it attempts to run executables from the srcdir, this is fixed in the snap, but I was wondering why the executables are run from the build dir instead of the install dir. This patch was originally from the 2.2.0p1, it is not needed for the snapshot, it is just to given you are idea of what I mean. @@ -95,7 +103,7 @@ $(LD) -o $@ logintest.o $(LDFLAGS) loginrec.o -lopenbsd-compat -lssh log-client.o $(LIBS) $(MANPAGES) $(CONFIGFILES):: - $(FIXPATHSCMD) $(srcdir)/$@ + $(FIXPATHSCMD) $(srcdir)/$@ > $@.out clean: rm -f *.o *.a $(TARGETS) logintest config.cache config.log @@ -164,18 +172,18 @@ if [ -f "$(DESTDIR)$(sysconfdir)/ssh_host_key" ] ; then \ echo "$(DESTDIR)$(sysconfdir)/ssh_host_key already exists, skipping." ; \ else \ - $(srcdir)/ssh-keygen -b 1024 -f $(DESTDIR)$(sysconfdir)/ssh_host_key -N "" ; \ + $(DESTDIR)$(bindir)/ssh-keygen -b 1024 -f $(DESTDIR)$(sysconfdir)/ssh_host_key -N "" ; \ fi ; \ if [ -f $(DESTDIR)$(sysconfdir)/ssh_host_dsa_key ] ; then \ echo "$(DESTDIR)$(sysconfdir)/ssh_host_dsa_key already exists, skipping." ; \ else \ - $(srcdir)/ssh-keygen -d -f $(DESTDIR)$(sysconfdir)/ssh_host_dsa_key -N "" ; \ + $(DESTDIR)$(bindir)/ssh-keygen -d -f $(DESTDIR)$(sysconfdir)/ssh_host_dsa_key -N "" ; \ fi ; \ fi ; host-key-force: ssh-keygen$(EXEEXT) - $(srcdir)/ssh-keygen -b 1024 -f $(DESTDIR)$(sysconfdir)/ssh_host_key -N "" - $(srcdir)/ssh-keygen -d -f $(DESTDIR)$(sysconfdir)/ssh_host_dsa_key -N "" + $(DESTDIR)$(bindir)/ssh-keygen -b 1024 -f $(DESTDIR)$(sysconfdir)/ssh_host_key -N "" + $(DESTDIR)$(bindir)/ssh-keygen -d -f $(DESTDIR)$(sysconfdir)/ssh_host_dsa_key -N "" uninstallall: uninstall -rm -f $(DESTDIR)$(sysconfdir)/ssh_config cheers Mo DeJong Red Hat Inc From jgrady at acm.jhu.edu Wed Dec 6 09:02:44 2000 From: jgrady at acm.jhu.edu (Jeff Grady) Date: Tue, 5 Dec 2000 17:02:44 -0500 (EST) Subject: SSH_BUG_SIGBLOB? Message-ID: Here are the details of my connection attempt: my computer: [jgrady at blarg jgrady]$ ssh -V SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090581f). university server: bash$ ssh -V ssh: SSH Secure Shell 2.3.0 (non-commercial version) on mips-sgi-irix6.5 and the verbose output of my connection attempt: [jgrady at blarg jgrady]$ ssh -v xxxxxx.xxx.xxx.xxx SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090581f). debug: Reading configuration data /etc/ssh/ssh_config debug: Applying options for * debug: Seeding random number generator debug: ssh_connect: getuid 500 geteuid 0 anon 0 debug: Connecting to xxxxxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22. debug: Allocated local port 1021. debug: Connection established. debug: Remote protocol version 1.99, remote software version 2.1.0.pl2 SSH Secure Shell (non-commercial) debug: match: 2.1.0.pl2 SSH Secure Shell (non-commercial) pat ^2\. Enabling compatibility mode for protocol 2.0 debug: Local version string SSH-2.0-OpenSSH_2.3.0p1 debug: Seeding random number generator debug: send KEXINIT debug: done debug: wait KEXINIT debug: got kexinit: diffie-hellman-group1-sha1 debug: got kexinit: ssh-dss debug: got kexinit: 3des-cbc,blowfish-cbc,twofish-cbc,arcfour,none debug: got kexinit: 3des-cbc,blowfish-cbc,twofish-cbc,arcfour,none debug: got kexinit: hmac-md5,md5-8,none debug: got kexinit: hmac-md5,md5-8,none debug: got kexinit: none,zlib debug: got kexinit: none,zlib debug: got kexinit: debug: got kexinit: debug: first kex follow: 0 debug: reserved: 0 debug: done debug: kex: server->client 3des-cbc hmac-md5 none debug: kex: client->server 3des-cbc hmac-md5 none debug: Sending SSH2_MSG_KEXDH_INIT. debug: bits set: 518/1024 debug: Wait SSH2_MSG_KEXDH_REPLY. debug: Got SSH2_MSG_KEXDH_REPLY. debug: Host 'xxxxxx.xxx.xxx.xxx' is known and matches the DSA host key. debug: bits set: 503/1024 autodetect SSH_BUG_SIGBLOB debug: len 40 datafellows -2 Received packet with bad string length 419867393 debug: Calling cleanup 0x805f3c0(0x0) ...and there it dies. Any help or comments is greatly appreciated. Please let me know if there are any questions about my system configuration or the server's. -Jeff From mouring at etoh.eviladmin.org Wed Dec 6 10:23:30 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 5 Dec 2000 17:23:30 -0600 (CST) Subject: SSH_BUG_SIGBLOB? In-Reply-To: Message-ID: Can we try this on the latest snapshot. I believe this issue has been addressed already. Thanks -Ben Snapshots: http://www.mindrot.org/misc/openssh/ On Tue, 5 Dec 2000, Jeff Grady wrote: > Here are the details of my connection attempt: > > my computer: > [jgrady at blarg jgrady]$ ssh -V > SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. > Compiled with SSL (0x0090581f). > > university server: > bash$ ssh -V > ssh: SSH Secure Shell 2.3.0 (non-commercial version) on mips-sgi-irix6.5 > > and the verbose output of my connection attempt: > > [jgrady at blarg jgrady]$ ssh -v xxxxxx.xxx.xxx.xxx > SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. > Compiled with SSL (0x0090581f). > debug: Reading configuration data /etc/ssh/ssh_config > debug: Applying options for * > debug: Seeding random number generator > debug: ssh_connect: getuid 500 geteuid 0 anon 0 > debug: Connecting to xxxxxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22. > debug: Allocated local port 1021. > debug: Connection established. > debug: Remote protocol version 1.99, remote software version 2.1.0.pl2 SSH > Secure Shell (non-commercial) > debug: match: 2.1.0.pl2 SSH Secure Shell (non-commercial) pat ^2\. > > Enabling compatibility mode for protocol 2.0 > debug: Local version string SSH-2.0-OpenSSH_2.3.0p1 > debug: Seeding random number generator > debug: send KEXINIT > debug: done > debug: wait KEXINIT > debug: got kexinit: diffie-hellman-group1-sha1 > debug: got kexinit: ssh-dss > debug: got kexinit: 3des-cbc,blowfish-cbc,twofish-cbc,arcfour,none > debug: got kexinit: 3des-cbc,blowfish-cbc,twofish-cbc,arcfour,none > debug: got kexinit: hmac-md5,md5-8,none > debug: got kexinit: hmac-md5,md5-8,none > debug: got kexinit: none,zlib > debug: got kexinit: none,zlib > debug: got kexinit: > debug: got kexinit: > debug: first kex follow: 0 > debug: reserved: 0 > debug: done > debug: kex: server->client 3des-cbc hmac-md5 none > debug: kex: client->server 3des-cbc hmac-md5 none > debug: Sending SSH2_MSG_KEXDH_INIT. > debug: bits set: 518/1024 > debug: Wait SSH2_MSG_KEXDH_REPLY. > debug: Got SSH2_MSG_KEXDH_REPLY. > debug: Host 'xxxxxx.xxx.xxx.xxx' is known and matches the DSA host key. > debug: bits set: 503/1024 > autodetect SSH_BUG_SIGBLOB > debug: len 40 datafellows -2 > Received packet with bad string length 419867393 > debug: Calling cleanup 0x805f3c0(0x0) > > ...and there it dies. > > Any help or comments is greatly appreciated. Please let me know if there are > any questions about my system configuration or the server's. > > -Jeff > > > From jgrady at acm.jhu.edu Wed Dec 6 11:00:51 2000 From: jgrady at acm.jhu.edu (Jeff Grady) Date: Tue, 5 Dec 2000 19:00:51 -0500 (EST) Subject: SSH_BUG_SIGBLOB? In-Reply-To: Message-ID: I installed openssh-SNAP-20001206.tar.gz and that took care of the problem. The version of openssh I had installed was from RedHat's updated rpm for RedHat 7.0 (openssh-*-2.3.0p1-4.i386.rpm) I entered this problem as a new bug in RedHat's Bugzilla database (#21784) Hopefully they'll be more on-the-ball next time. :/ Thanks for your help! -Jeff On Tue, 5 Dec 2000 mouring at etoh.eviladmin.org wrote: > > Can we try this on the latest snapshot. I believe this issue has been > addressed already. > > Thanks > -Ben > > Snapshots: http://www.mindrot.org/misc/openssh/ > > > On Tue, 5 Dec 2000, Jeff Grady wrote: > > > Here are the details of my connection attempt: > > > > my computer: > > [jgrady at blarg jgrady]$ ssh -V > > SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. > > Compiled with SSL (0x0090581f). > > > > university server: > > bash$ ssh -V > > ssh: SSH Secure Shell 2.3.0 (non-commercial version) on mips-sgi-irix6.5 > > > > and the verbose output of my connection attempt: > > > > [jgrady at blarg jgrady]$ ssh -v xxxxxx.xxx.xxx.xxx > > SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. > > Compiled with SSL (0x0090581f). > > debug: Reading configuration data /etc/ssh/ssh_config > > debug: Applying options for * > > debug: Seeding random number generator > > debug: ssh_connect: getuid 500 geteuid 0 anon 0 > > debug: Connecting to xxxxxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22. > > debug: Allocated local port 1021. > > debug: Connection established. > > debug: Remote protocol version 1.99, remote software version 2.1.0.pl2 SSH > > Secure Shell (non-commercial) > > debug: match: 2.1.0.pl2 SSH Secure Shell (non-commercial) pat ^2\. > > > > Enabling compatibility mode for protocol 2.0 > > debug: Local version string SSH-2.0-OpenSSH_2.3.0p1 > > debug: Seeding random number generator > > debug: send KEXINIT > > debug: done > > debug: wait KEXINIT > > debug: got kexinit: diffie-hellman-group1-sha1 > > debug: got kexinit: ssh-dss > > debug: got kexinit: 3des-cbc,blowfish-cbc,twofish-cbc,arcfour,none > > debug: got kexinit: 3des-cbc,blowfish-cbc,twofish-cbc,arcfour,none > > debug: got kexinit: hmac-md5,md5-8,none > > debug: got kexinit: hmac-md5,md5-8,none > > debug: got kexinit: none,zlib > > debug: got kexinit: none,zlib > > debug: got kexinit: > > debug: got kexinit: > > debug: first kex follow: 0 > > debug: reserved: 0 > > debug: done > > debug: kex: server->client 3des-cbc hmac-md5 none > > debug: kex: client->server 3des-cbc hmac-md5 none > > debug: Sending SSH2_MSG_KEXDH_INIT. > > debug: bits set: 518/1024 > > debug: Wait SSH2_MSG_KEXDH_REPLY. > > debug: Got SSH2_MSG_KEXDH_REPLY. > > debug: Host 'xxxxxx.xxx.xxx.xxx' is known and matches the DSA host key. > > debug: bits set: 503/1024 > > autodetect SSH_BUG_SIGBLOB > > debug: len 40 datafellows -2 > > Received packet with bad string length 419867393 > > debug: Calling cleanup 0x805f3c0(0x0) > > > > ...and there it dies. > > > > Any help or comments is greatly appreciated. Please let me know if there are > > any questions about my system configuration or the server's. > > > > -Jeff > > > > > > > From P.Lister at sychron.com Thu Dec 7 00:04:06 2000 From: P.Lister at sychron.com (Peter Lister) Date: Wed, 06 Dec 2000 13:04:06 +0000 Subject: openssh-2.3.0p1 (Linux) fails using options with dss key Message-ID: I'm trying to change my local setup from ssh2 to openssh-2.3.0p1. I need captive comands and specific environments for each key, i.e. the "command=XXX" and "environment=X=y" options. Unfortunately I *also* need to support the existing ssh2 client for a transition period, since it's impractical to change all user's environments to openssh in one go. I have converted the ssh2 public keys OK (see appended authorized_keys2), and WITHOUT OPTIONS I can log in as normal, with the key in authorized_keys2. But as soon as I put options in before "ssh-dss" in authorized_keys2, the connection fails. I append logs of successful and failed connections - the only difference is the whether the environment option is set. As you can see, even during a failure the server seems to parse the file OK and finds a matching key on line 3 of authorized_keys2, but then dies for no apparent reason. It seems that this is an openssh server problem, as the client should not be aware of what is going on on the server side, and the failure seems to be before the authentication. NB - the sshd man page does not seem to know about the ssh-dss keys (it states that all keys begin with numbers, which is clearly not so for dss keys) so I don't know for certain that this is right - an example would be useful. -------------- next part -------------- /usr/local/bin/ssh bennevis -v -p 1022 Development-time debugging not compiled in. To enable, configure with --enable-debug and recompile. debug: connecting to bennevis... debug: entering event loop debug: ssh_client_wrap: creating transport protocol debug: ssh_client_wrap: creating userauth protocol debug: Remote version: SSH-1.99-OpenSSH_2.3.0p1 debug: Host key found from the database. FATAL: ssh_conn_received_packet: bad DISCONNECT -------------- next part -------------- /usr/sbin/sshd -p 1022 -d debug1: sshd version OpenSSH_2.3.0p1 debug1: Seeding random number generator debug1: read DSA private key done debug1: Seeding random number generator debug1: Bind to port 1022 on 0.0.0.0. Server listening on 0.0.0.0 port 1022. Generating 768 bit RSA key. debug1: Seeding random number generator debug1: Seeding random number generator RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 62.232.14.113 port 3589 debug1: Client protocol version 1.99; client software version 2.0.13 (non-commer cial) debug1: match: 2.0.13 (non-commercial) pat ^2\.0\. Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_2.3.0p1 debug1: send KEXINIT debug1: done debug1: wait KEXINIT debug1: got kexinit: diffie-hellman-group1-sha1 debug1: got kexinit: ssh-dss debug1: got kexinit: 3des-cbc,blowfish-cbc,none debug1: got kexinit: 3des-cbc,blowfish-cbc,none debug1: got kexinit: hmac-md5,md5-8,none debug1: got kexinit: hmac-md5,md5-8,none debug1: got kexinit: none,zlib debug1: got kexinit: none,zlib debug1: got kexinit: debug1: got kexinit: debug1: first kex follow: 1 debug1: reserved: 0 debug1: done debug1: kex: client->server 3des-cbc hmac-md5 none debug1: kex: server->client 3des-cbc hmac-md5 none debug1: bits set: 514/1024 debug1: bits set: 515/1024 debug1: sig size 20 20 debug1: datafellows debug1: send SSH2_MSG_NEWKEYS. debug1: done: send SSH2_MSG_NEWKEYS. debug1: Wait SSH2_MSG_NEWKEYS. debug1: GOT SSH2_MSG_NEWKEYS. debug1: done: KEX2. debug1: userauth-request for user prl service ssh-connection method none debug1: attempt #1 Failed none for prl from 62.232.14.113 port 3589 ssh2 debug1: userauth-request for user prl service ssh-connection method publickey debug1: attempt #2 debug1: test whether pkalg/pkblob are acceptable debug1: Adding to environment: ONE=two debug1: matching key found: file /users/prl/.ssh/authorized_keys2, line 1 Postponed publickey for prl from 62.232.14.113 port 3589 ssh2 fatal: Read from socket failed: Broken pipe debug1: Calling cleanup 0x805d608(0x0) -------------- next part -------------- /usr/local/bin/ssh bennevis -v -p 1022 Development-time debugging not compiled in. To enable, configure with --enable-debug and recompile. debug: connecting to bennevis... debug: entering event loop FATAL: Connecting to bennevis failed: Connection Refused [prl at tomintoul ~]$ /usr/local/bin/ssh bennevis -v -p 1022 Development-time debugging not compiled in. To enable, configure with --enable-debug and recompile. debug: connecting to bennevis... debug: entering event loop debug: ssh_client_wrap: creating transport protocol debug: ssh_client_wrap: creating userauth protocol debug: Remote version: SSH-1.99-OpenSSH_2.3.0p1 debug: Host key found from the database. debug: Ssh2AuthPubKeyClient/authc-pubkey.c:368/ssh_client_auth_pubkey_send_signature: ssh_client_auth_pubkey_send_signature debug: Ssh2/ssh2.c:304/client_authenticated: client_authenticated debug: Requesting X11 forwarding with authentication spoofing. Last login: Wed Dec 6 12:31:59 2000 from tomintoul.sychron.com Environment: USER=prl LOGNAME=prl HOME=/users/prl PATH=/usr/bin:/bin:/usr/sbin:/sbin MAIL=/var/spool/mail/prl SHELL=/bin/tcsh SSH_CLIENT=62.232.14.113 3596 1022 SSH_TTY=/dev/ttyp2 TERM=xterm [prl at bennevis ~]$ -------------- next part -------------- /usr/sbin/sshd -p 1022 -d debug1: sshd version OpenSSH_2.3.0p1 debug1: Seeding random number generator debug1: read DSA private key done debug1: Seeding random number generator debug1: Bind to port 1022 on 0.0.0.0. Server listening on 0.0.0.0 port 1022. Generating 768 bit RSA key. debug1: Seeding random number generator debug1: Seeding random number generator RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 62.232.14.113 port 3596 debug1: Client protocol version 1.99; client software version 2.0.13 (non-commer cial) debug1: match: 2.0.13 (non-commercial) pat ^2\.0\. Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_2.3.0p1 debug1: send KEXINIT debug1: done debug1: wait KEXINIT debug1: got kexinit: diffie-hellman-group1-sha1 debug1: got kexinit: ssh-dss debug1: got kexinit: 3des-cbc,blowfish-cbc,none debug1: got kexinit: 3des-cbc,blowfish-cbc,none debug1: got kexinit: hmac-md5,md5-8,none debug1: got kexinit: hmac-md5,md5-8,none debug1: got kexinit: none,zlib debug1: got kexinit: none,zlib debug1: got kexinit: debug1: got kexinit: debug1: first kex follow: 1 debug1: reserved: 0 debug1: done debug1: kex: client->server 3des-cbc hmac-md5 none debug1: kex: server->client 3des-cbc hmac-md5 none debug1: Wait SSH2_MSG_KEXDH_INIT. debug1: bits set: 499/1024 debug1: bits set: 525/1024 debug1: sig size 20 20 debug1: datafellows debug1: send SSH2_MSG_NEWKEYS. debug1: done: send SSH2_MSG_NEWKEYS. debug1: Wait SSH2_MSG_NEWKEYS. debug1: GOT SSH2_MSG_NEWKEYS. debug1: done: KEX2. debug1: userauth-request for user prl service ssh-connection method none debug1: attempt #1 Failed none for prl from 62.232.14.113 port 3596 ssh2 debug1: userauth-request for user prl service ssh-connection method publickey debug1: attempt #2 debug1: test whether pkalg/pkblob are acceptable debug1: matching key found: file /users/prl/.ssh/authorized_keys2, line 2 Postponed publickey for prl from 62.232.14.113 port 3596 ssh2 debug1: userauth-request for user prl service ssh-connection method publickey debug1: attempt #3 debug1: matching key found: file /users/prl/.ssh/authorized_keys2, line 2 debug1: len 40 datafellows 31 debug1: dsa_verify: signature correct Accepted publickey for prl from 62.232.14.113 port 3596 ssh2 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 10000 max 512 debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: confirm session debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 channel 0 request pty-req reply 0 debug1: session_pty_req: session 0 alloc /dev/ttyp2 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 channel 0 request x11-req reply 0 debug1: X11 forwarding disabled in server configuration file. debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 channel 0 request auth-agent-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 channel 0 request shell reply 1 debug1: fd 7 setting O_NONBLOCK debug1: fd 3 IS O_NONBLOCK debug1: Setting controlling tty using TIOCSCTTY. -------------- next part -------------- #environment="ONE=two" ssh-dss AAAAB3NzaC1kc3MAAACBAOV2zL1T2+0bl8FTtultv/oIBz4WRZ9aOOB/sXPoPQE6P/0+ldToN+ulUgb6zs3lU0ESnZyXOPv7pszDu3LceKfld3Mn6RnPyv4FDRgjnN/obMtAxDUIfPKI+MmEFFsIClxaTs8xZ1LBLdHDNh/h/xp+/QpXRihHjV22ekgktzk7AAAAFQC1KGpxg+Gtvd5HmSvJjKkfsqBlJwAAAIB1N/8AKP2mpDU/dHhKdd1IsH9nBCmqj2RyAunC5tEXr1jbj/Y4jAJtfc93KpqlykyZJo3C2NBs6iiFzUyzGWGbLuw7MEHinev30BBRPKFowTdW6bN+FdZHJiltSyMqHzMdLyyWSss+aiI7BUPjgKcogPEwXwcpzxhFl+4ZV9YIVAAAAIAA6q55UAsiH50jQbQJTwsRvyWneG6txUKEbfqyuJk/pFJuw9rIkD3oI49SNwJKA0HKfMEbGSCyrddp0kDqo0v6u+peea/l9tm6JSvu1+8W/WywBTMtUtwKScKT0LP+xiwu56Ze9vN90LRmQyZBYuUUdFNPMICQgi75FnVsuSnTMw== -------------- next part -------------- Peter Lister P.Lister at sychron.com PGP (RSA): 0xE4D85541 Sychron Ltd http://www.sychron.com PGP (DSS): 0xBC1D7258 1 Cambridge Terrace Voice: +44 1865 200211 Oxford OX1 1UR UK FAX: +44 1865 249666 From markus.friedl at informatik.uni-erlangen.de Thu Dec 7 06:57:45 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 6 Dec 2000 20:57:45 +0100 Subject: Problems on Sparcs (fwd) Message-ID: <20001206205745.A4219@folly> comments? -------------- next part -------------- An embedded message was scrubbed... From: Charles Clancy Subject: Problems on Sparcs Date: Wed, 6 Dec 2000 09:55:41 -0500 (EST) Size: 2913 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001206/c7cb5d2a/attachment.mht From brhamon at cisco.com Thu Dec 7 07:14:48 2000 From: brhamon at cisco.com (Hamon, Brian K.) Date: Wed, 06 Dec 2000 14:14:48 -0600 Subject: Problems on Sparcs (fwd) In-Reply-To: <20001206205745.A4219@folly> Message-ID: <4.3.2.7.2.20001206140937.00b23c90@3rdclass.cisco.com> One thing I can see is that you are running sshd from inetd through tcp_wrappers. Wouldn't it be preferable to link in libwrap.a and start sshd in /etc/rc3.d ? At 01:57 PM 12/06/2000, Markus Friedl wrote: >comments? >Return-Path: >Received: from faui45.informatik.uni-erlangen.de >(root at faui45.informatik.uni-erlangen.de [131.188.34.45]) > by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) with > ESMTP id PAA10287 > for ; Wed, 6 Dec 2000 > 15:56:43 +0100 (MET) >Received: from cvs.openbsd.org (IDENT:root at cvs.openbsd.org [199.185.137.3]) > by faui45.informatik.uni-erlangen.de (8.9.1/8.1.49-FAU) with > ESMTP id PAA20410 > for ; Wed, 6 Dec 2000 > 15:56:41 +0100 (MET) >Received: from hermes.cs.rose-hulman.edu (hermes.cs.rose-hulman.edu >[137.112.40.22]) > by cvs.openbsd.org (8.10.1/8.10.1) with ESMTP id eB6EtcD08240 > for ; Wed, 6 Dec 2000 07:55:38 -0700 (MST) >Received: from skyhawk (skyhawk [137.112.40.33]) > by hermes.cs.rose-hulman.edu (8.11.0/8.11.0) with ESMTP id > eB6EtgV07928 > for ; Wed, 6 Dec 2000 09:55:42 -0500 (EST) >Date: Wed, 6 Dec 2000 09:55:41 -0500 (EST) >From: Charles Clancy >X-Sender: >To: >Subject: Problems on Sparcs >Message-ID: >MIME-Version: 1.0 >Content-Type: TEXT/PLAIN; charset=US-ASCII > >I compiled OpenSSH 2.3.0p1 for Solaris 7 (32-bit) with OpenSSL 0.95a, with >GCC 2.95.2 (sunfreeware.com binaries). > >We are using OpenSSH because it supports PAM, which is required for our >network, as our workstations run AFS, and very few daemons support >authentication via AFS. > >On our most frequently used Ultra 80 (2x450MHz, 1G RAM), we have been >having problems ever since upgrading from SSH 1.2.27 (w/ PAM patch) to >OpenSSH. Remote SSH connections stop working after about 2 days (sshd is >run from inetd through tcp_wrappers). After 2 days, if you log in >locally, graphical logins will halt. A console text-based login works, >but about half the basic unix commands have problems. For example, a "w" >only returns the first line, and then halts. A "ps -ef" will get about >half way through before getting stuck. A CTRL-C won't get you out of them >either. All you can do is "sync; reboot" from a telnet connection >(tcp_wrappers is configured to allow telnet from one of our servers). > >This machine is being used mostly as a general purpose workstation. I >know at least one person is using MATLAB and doing some X-Forwarding. > >All the other machines (1 Ultra 80 and 10 Ultra 10s) are working fine. We >did have one Ultra 2 (web server) that exhibited some of these problems, >but I immediately switched it back to SSH 1.2.27, because we can't afford >any downtime on that machine. > >Do you have any idea what would cause this bizarre behavior? > >Thanks! >_______________________________________________________ > Charles Clancy -- mgrtcc at cs.rose-hulman.edu >Senior UNIX Administrator, Rose-Hulman Computer Science From markus.friedl at informatik.uni-erlangen.de Thu Dec 7 07:29:49 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 6 Dec 2000 21:29:49 +0100 Subject: openssh-2.3.0p1 (Linux) fails using options with dss key In-Reply-To: ; from P.Lister@sychron.com on Wed, Dec 06, 2000 at 01:04:06PM +0000 References: Message-ID: <20001206212949.D4219@folly> On Wed, Dec 06, 2000 at 01:04:06PM +0000, Peter Lister wrote: > FATAL: ssh_conn_received_packet: bad DISCONNECT i can confirm this for SSH.COM/F-Secure versions 2.0.12, 2.0.12, 2.1.0 However, the auth-options work fine for SSH.COM versions 2.2.0, 2.3.0 the problem is that the SSH.COM client is confused if it receives a DEBUG message during authentication. could you please try this patch? it disables all DEBUG messages: Index: packet.c =================================================================== RCS file: /home/markus/cvs/ssh/packet.c,v retrieving revision 1.38 diff -U10 -r1.38 packet.c --- packet.c 2000/10/12 14:21:12 1.38 +++ packet.c 2000/12/06 20:20:04 @@ -1094,20 +1094,22 @@ * authentication problems. The length of the formatted message must not * exceed 1024 bytes. This will automatically call packet_write_wait. */ void packet_send_debug(const char *fmt,...) { char buf[1024]; va_list args; +return; + va_start(args, fmt); vsnprintf(buf, sizeof(buf), fmt, args); va_end(args); if (compat20) { packet_start(SSH2_MSG_DEBUG); packet_put_char(0); /* bool: always display */ packet_put_cstring(buf); packet_put_cstring(""); } else { From james at amethyst.nurealm.net Thu Dec 7 10:33:41 2000 From: james at amethyst.nurealm.net (James) Date: Wed, 06 Dec 2000 16:33:41 -0700 Subject: openssh-SNAP-20001207 scp "Bad file descriptor" sort-of work-around Message-ID: <200012062333.QAA03147@amethyst.nurealm.net> Everything seems to work, though I still have trouble with scp. The behaviour is not protocol dependent - acts the same with either. (Using RedHat 6.2) When I scp :, bash is invoked as a login shell on the server side host - this doesn't seem right. With my /etc/profile, I get Dec 6 15:06:20 amethyst sshd[3027]: error: select: Bad file descriptor in the log (something doesn't like my script), and sourcing /etc/profile... Connection to closed by remote host. on the client side. (My /etc/profile generates the "sourcing /etc/profile..." message.) If instead I mv /etc/profile /etc/profile.tmp, scp is successful. strace then gives, toward the end: open("/etc/passwd", O_RDONLY) = 3 fcntl(3, F_GETFD) = 0 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 fstat(3, {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 2335 close(3) = 0 munmap(0x40015000, 4096) = 0 ioctl(2, TCGETS, 0xbffff734) = -1 EINVAL (Invalid argument) rt_sigaction(SIGPIPE, {0x804b0bc, [], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 pipe([3, 4]) = 0 pipe([5, 6]) = 0 pipe([7, 8]) = 0 close(3) = 0 close(4) = 0 fork() = 21936 close(5) = 0 close(8) = 0 read(7, bash: /etc/profile: No such file or directory bash: cma: command not found "\0", 1) = 1 open("ssh-copy-id", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=1144, ...}) = 0 write(6, "C0644 1144 ssh-copy-id\n", 23) = 23 read(7, "\0", 1) = 1 fstat(3, {st_mode=S_IFREG|0644, st_size=1144, ...}) = 0 brk(0x8051000) = 0x8051000 read(3, "#!/bin/sh\n\n# Shell script to ins"..., 1144) = 1144 write(6, "#!/bin/sh\n\n# Shell script to ins"..., 1144) = 1144 close(3) = 0 write(6, "\0", 1) = 1 read(7, "\0", 1) = 1 _exit(0) ("cma" is a missing command from /etc/profile called from ~/.profile. "ssh-copy-id" is the test file I'm trying to scp.) When scp breaks, the very end looks like: read(7, ".", 1) = 1 read(7, "\n", 1) = 1 write(2, "sourcing /etc/profile...\n", 25sourcing /etc/profile... ) = 25 _exit(1) = ? Connection to closed by remote host. So, is starting a bash login shell correct behavior for scp? This login shell behaviour is a problem, as you can see. An incompatibility with /etc/profile or ~/.profile kills scp - uhg. Might I have misconfigured something in ssh_config or sshd_config? or compiling the package? I have: OpenSSH configured has been configured with the following options. User binaries: /usr/bin User binaries: /usr/bin System binaries: /usr/sbin Configuration files: /etc/ssh Askpass program: /usr/libexec/ssh-askpass Manual pages: /usr/man/manX PID file: /var/run Random number collection: Device (/dev/urandom) Manpage format: man PAM support: yes KerberosIV support: no AFS support: no S/KEY support: yes TCP Wrappers support: yes MD5 password support: no IP address in $DISPLAY hack: no Use IPv4 by default hack: no Translate v4 in v6 hack: yes Host: i686-pc-linux-gnu Compiler: gcc Compiler flags: -g -O2 -Wall -I. -I. -I/usr/include Linker flags: -L/usr/lib -L/usr Libraries: -ldl -lnsl -lz -lutil -lpam -lcrypto -lskey -lwrap Please Cc me on any response, as I'm not subscribed to the list. Thanks. James Feeney From wsanchez at apple.com Thu Dec 7 11:00:29 2000 From: wsanchez at apple.com (Wilfredo Sanchez) Date: Wed, 6 Dec 2000 16:00:29 -0800 Subject: [PATCH] Separate CFLAGS and CPPFLAGS Message-ID: <200012070000.QAA28129@scv3.apple.com> If you want to override CFLAGS on the make line (eg. "make CFLAGS='-O3'"), you lose because you end up stomping preprocessor flags as well. Preprocessor should be in CPPFLAGS. The following patch takes care of this. -Fred Index: Makefile.in =================================================================== RCS file: /cvs/Darwin/Services/OpenSSH/openssh/Makefile.in,v retrieving revision 1.1.1.4 retrieving revision 1.8 diff -u -d -b -w -r1.1.1.4 -r1.8 --- Makefile.in 2000/12/06 21:56:06 1.1.1.4 +++ Makefile.in 2000/12/06 22:11:15 1.8 @@ -20,7 +20,8 @@ CC=@CC@ LD=@LD@ PATHS=-DETCDIR=\"$(sysconfdir)\" -DSSH_PROGRAM=\"$(SSH_PROGRAM)\" -DSSH_ASKPASS_DEFAULT=\"$(ASKPASS_PROGRAM)\" -CFLAGS=@CFLAGS@ $(PATHS) @DEFS@ +CFLAGS=@CFLAGS@ +CPPFLAGS=@CPPFLAGS@ $(PATHS) @DEFS@ -I. -I$(srcdir) LIBS=@LIBS@ AR=@AR@ RANLIB=@RANLIB@ Wilfredo S?nchez, wsanchez at apple.com Open Source Engineering Lead Apple Computer, Inc., Core Operating System Group 1 Infinite Loop, Cupertino, CA 94086, 408.974-5174 From wsanchez at apple.com Thu Dec 7 11:04:44 2000 From: wsanchez at apple.com (Wilfredo Sanchez) Date: Wed, 6 Dec 2000 16:04:44 -0800 Subject: [PATCH] Typo in ssh.1 Message-ID: <200012070004.QAA29102@scv3.apple.com> Small nit. -Fred Index: ssh.1 =================================================================== RCS file: /cvs/Darwin/Services/OpenSSH/openssh/ssh.1,v retrieving revision 1.1.1.4 retrieving revision 1.3 diff -u -d -b -w -r1.1.1.4 -r1.3 --- ssh.1 2000/12/06 21:56:41 1.1.1.4 +++ ssh.1 2000/12/06 22:11:16 1.3 @@ -272,7 +272,7 @@ .Dq none will also make the session transparent even if a tty is used. .Pp -The session terminates when the command or shell in on the remote +The session terminates when the command or shell on the remote machine exists and all X11 and TCP/IP connections have been closed. The exit status of the remote program is returned as the exit status of Wilfredo S?nchez, wsanchez at apple.com Open Source Engineering Lead Apple Computer, Inc., Core Operating System Group 1 Infinite Loop, Cupertino, CA 94086, 408.974-5174 From wsanchez at apple.com Thu Dec 7 11:06:02 2000 From: wsanchez at apple.com (Wilfredo Sanchez) Date: Wed, 6 Dec 2000 16:06:02 -0800 Subject: [PATCH] typo in uidswap.c Message-ID: <200012070006.QAA29394@scv3.apple.com> Another nit. -Fred Index: uidswap.c =================================================================== RCS file: /cvs/Darwin/Services/OpenSSH/openssh/uidswap.c,v retrieving revision 1.1.1.4 retrieving revision 1.4 diff -u -d -b -w -r1.1.1.4 -r1.4 --- uidswap.c 2000/12/06 21:56:45 1.1.1.4 +++ uidswap.c 2000/12/06 22:11:16 1.4 @@ -53,7 +53,7 @@ /* Set the effective uid to the given (unprivileged) uid. */ if (seteuid(uid) == -1) debug("seteuid %u: %.100s", (u_int) uid, strerror(errno)); -#else /* SAVED_IDS_WORK_WITH_SETUID */ +#else /* SAVED_IDS_WORK_WITH_SETEUID */ /* Propagate the privileged uid to all of our uids. */ if (setuid(geteuid()) < 0) debug("setuid %u: %.100s", (u_int) geteuid(), strerror(errno)); Wilfredo S?nchez, wsanchez at apple.com Open Source Engineering Lead Apple Computer, Inc., Core Operating System Group 1 Infinite Loop, Cupertino, CA 94086, 408.974-5174 From wsanchez at apple.com Thu Dec 7 11:20:18 2000 From: wsanchez at apple.com (Wilfredo Sanchez) Date: Wed, 6 Dec 2000 16:20:18 -0800 Subject: Mode of ~/.ssh (Darwin bug #2575103) Message-ID: <200012070020.QAA27470@scv1.apple.com> OpenSSH's ssh-keygen sets the mode of ~/.ssh to 700, unlike "Classic" ssh, which set it to 755. I've noticed a couple of problems: If your home directory is on an NFS server which maps user root from clients to nobody (typical "safe" setup), sshd, which runs as root, will find itself without the ability to read that user's .ssh/authorized_keys file. This can be worked around by running as that user via setuid while checking the file, but that won't work on kerberized NFS or other network volumes which require a security token of some sort instead of blindly trusting the client machine to authenticate users. This is a drag. Also, since your public key live in ~/.ssh, it seems unfortunate that other users can no longer get to it. Minor drag. I'm wondering why it was deemed necessary to be fascist with the directory rather than selectively fascist about the files in it. -Fred Wilfredo S?nchez, wsanchez at apple.com Open Source Engineering Lead Apple Computer, Inc., Core Operating System Group 1 Infinite Loop, Cupertino, CA 94086, 408.974-5174 From mouring at etoh.eviladmin.org Thu Dec 7 13:38:36 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 6 Dec 2000 20:38:36 -0600 (CST) Subject: [PATCH] Separate CFLAGS and CPPFLAGS In-Reply-To: <200012070000.QAA28129@scv3.apple.com> Message-ID: Along with breaks most of the ports since they put all the -I entries in CFLAGS. However it will be noted as something to do. - Ben On Wed, 6 Dec 2000, Wilfredo Sanchez wrote: > If you want to override CFLAGS on the make line (eg. "make CFLAGS='-O3'"), > you lose because you end up stomping preprocessor flags as well. > Preprocessor should be in CPPFLAGS. The following patch takes care of this. > > -Fred > > Index: Makefile.in > =================================================================== > RCS file: /cvs/Darwin/Services/OpenSSH/openssh/Makefile.in,v > retrieving revision 1.1.1.4 > retrieving revision 1.8 > diff -u -d -b -w -r1.1.1.4 -r1.8 > --- Makefile.in 2000/12/06 21:56:06 1.1.1.4 > +++ Makefile.in 2000/12/06 22:11:15 1.8 > @@ -20,7 +20,8 @@ > CC=@CC@ > LD=@LD@ > PATHS=-DETCDIR=\"$(sysconfdir)\" -DSSH_PROGRAM=\"$(SSH_PROGRAM)\" -DSSH_ASKPASS_DEFAULT=\"$(ASKPASS_PROGRAM)\" > -CFLAGS=@CFLAGS@ $(PATHS) @DEFS@ > +CFLAGS=@CFLAGS@ > +CPPFLAGS=@CPPFLAGS@ $(PATHS) @DEFS@ -I. -I$(srcdir) > LIBS=@LIBS@ > AR=@AR@ > RANLIB=@RANLIB@ > > Wilfredo S?nchez, wsanchez at apple.com > Open Source Engineering Lead > Apple Computer, Inc., Core Operating System Group > 1 Infinite Loop, Cupertino, CA 94086, 408.974-5174 > From mouring at etoh.eviladmin.org Thu Dec 7 13:58:48 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 6 Dec 2000 20:58:48 -0600 (CST) Subject: [PATCH] Separate CFLAGS and CPPFLAGS In-Reply-To: Message-ID: Ok.. Let me wake up for a few minutes. =) Attached should be a patch that splits CFLAGS into CFLAGS and CPPFLAGS. If anyone knows a better way or sees a problem with it.. Let me know. If I don't hear anything I'll apply it in a few days. On Wed, 6 Dec 2000 mouring at etoh.eviladmin.org wrote: > > Along with breaks most of the ports since they put all the -I entries in > CFLAGS. > > However it will be noted as something to do. > > - Ben > > On Wed, 6 Dec 2000, Wilfredo Sanchez wrote: > > > If you want to override CFLAGS on the make line (eg. "make CFLAGS='-O3'"), > > you lose because you end up stomping preprocessor flags as well. > > Preprocessor should be in CPPFLAGS. The following patch takes care of this. > > > > -Fred > > > > Index: Makefile.in > > =================================================================== > > RCS file: /cvs/Darwin/Services/OpenSSH/openssh/Makefile.in,v > > retrieving revision 1.1.1.4 > > retrieving revision 1.8 > > diff -u -d -b -w -r1.1.1.4 -r1.8 > > --- Makefile.in 2000/12/06 21:56:06 1.1.1.4 > > +++ Makefile.in 2000/12/06 22:11:15 1.8 > > @@ -20,7 +20,8 @@ > > CC=@CC@ > > LD=@LD@ > > PATHS=-DETCDIR=\"$(sysconfdir)\" -DSSH_PROGRAM=\"$(SSH_PROGRAM)\" -DSSH_ASKPASS_DEFAULT=\"$(ASKPASS_PROGRAM)\" > > -CFLAGS=@CFLAGS@ $(PATHS) @DEFS@ > > +CFLAGS=@CFLAGS@ > > +CPPFLAGS=@CPPFLAGS@ $(PATHS) @DEFS@ -I. -I$(srcdir) > > LIBS=@LIBS@ > > AR=@AR@ > > RANLIB=@RANLIB@ > > > > Wilfredo S?nchez, wsanchez at apple.com > > Open Source Engineering Lead > > Apple Computer, Inc., Core Operating System Group > > 1 Infinite Loop, Cupertino, CA 94086, 408.974-5174 > > > > -------------- next part -------------- diff -ur openssh/Makefile.in ossh/Makefile.in --- openssh/Makefile.in Mon Dec 4 20:06:06 2000 +++ ossh/Makefile.in Wed Dec 6 20:34:01 2000 @@ -20,7 +20,8 @@ CC=@CC@ LD=@LD@ PATHS=-DETCDIR=\"$(sysconfdir)\" -DSSH_PROGRAM=\"$(SSH_PROGRAM)\" -DSSH_ASKPASS_DEFAULT=\"$(ASKPASS_PROGRAM)\" -CFLAGS=@CFLAGS@ $(PATHS) @DEFS@ +CFLAGS=@CFLAGS@ +CPPFLAGS=@CPPFLAGS@ -I$(srcdir) $(PATHS) @DEFS@ LIBS=@LIBS@ AR=@AR@ RANLIB=@RANLIB@ Only in ossh: config.h.in diff -ur openssh/configure.in ossh/configure.in --- openssh/configure.in Wed Dec 6 20:09:31 2000 +++ ossh/configure.in Wed Dec 6 20:41:50 2000 @@ -41,13 +41,11 @@ CFLAGS="$CFLAGS -Wall" fi -CFLAGS="$CFLAGS -I. -I${srcdir-.}" - # Check for some target-specific stuff case "$host" in *-*-aix*) AFS_LIBS="-lld" - CFLAGS="$CFLAGS -I/usr/local/include" + CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib" if (test "$LD" != "gcc" && test -z "$blibpath"); then blibpath="/usr/lib:/lib:/usr/local/lib" @@ -75,9 +73,9 @@ ;; *-*-hpux10*) if test -z "$GCC"; then - CFLAGS="$CFLAGS -Ae" + CPPFLAGS="$CPPFLAGS -Ae" fi - CFLAGS="$CFLAGS -D_HPUX_SOURCE" + CPPFLAGS="$CPPFLAGS -D_HPUX_SOURCE" IPADDR_IN_DISPLAY=yes AC_DEFINE(USE_PIPES) AC_DEFINE(DISABLE_SHADOW) @@ -88,7 +86,7 @@ mansubdir=cat ;; *-*-hpux11*) - CFLAGS="$CFLAGS -D_HPUX_SOURCE" + CPPFLAGS="$CPPFLAGS -D_HPUX_SOURCE" IPADDR_IN_DISPLAY=yes AC_DEFINE(USE_PIPES) AC_DEFINE(DISABLE_SHADOW) @@ -99,7 +97,7 @@ mansubdir=cat ;; *-*-irix5*) - CFLAGS="$CFLAGS -I/usr/local/include" + CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS" PATH="$PATH:/usr/etc" MANTYPE='$(CATMAN)' @@ -108,7 +106,7 @@ AC_DEFINE(BROKEN_INET_NTOA) ;; *-*-irix6*) - CFLAGS="$CFLAGS -I/usr/local/include" + CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS" PATH="$PATH:/usr/etc" MANTYPE='$(CATMAN)' @@ -145,10 +143,10 @@ AC_DEFINE(HAVE_NEXT) AC_DEFINE(BROKEN_REALPATH) AC_DEFINE(USE_PIPES) - CFLAGS="$CFLAGS -I/usr/local/include" + CPPFLAGS="$CPPFLAGS -I/usr/local/include" ;; *-*-solaris*) - CFLAGS="$CFLAGS -I/usr/local/include" + CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib -R/usr/local/lib -L/usr/ucblib -R/usr/ucblib" need_dash_r=1 # hardwire lastlog location (can't detect it on some versions) @@ -164,7 +162,7 @@ fi ;; *-*-sunos4*) - CFLAGS="$CFLAGS -DSUNOS4" + CPPFLAGS="$CPPFLAGS -DSUNOS4" AC_CHECK_FUNCS(getpwanam) conf_utmp_location=/etc/utmp conf_wtmp_location=/var/adm/wtmp @@ -174,7 +172,7 @@ mansubdir=cat ;; *-sni-sysv*) - CFLAGS="$CFLAGS -I/usr/local/include" + CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib -L/usr/ucblib" MANTYPE='$(CATMAN)' AC_DEFINE(IP_TOS_IS_BROKEN) @@ -182,7 +180,7 @@ LIBS="$LIBS -lgen -lnsl -lucb" ;; *-*-sysv4.2*) - CFLAGS="$CFLAGS -I/usr/local/include" + CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib" MANTYPE='$(CATMAN)' mansubdir=cat @@ -190,7 +188,7 @@ enable_suid_ssh=no ;; *-*-sysv5*) - CFLAGS="$CFLAGS -I/usr/local/include" + CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib" MANTYPE='$(CATMAN)' mansubdir=cat @@ -198,7 +196,7 @@ enable_suid_ssh=no ;; *-*-sysv*) - CFLAGS="$CFLAGS -I/usr/local/include" + CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib" MANTYPE='$(CATMAN)' mansubdir=cat @@ -206,7 +204,7 @@ ;; *-*-sco3.2v4*) AC_DEFINE(USE_PIPES) - CFLAGS="$CFLAGS -Dftruncate=chsize -I/usr/local/include" + CPPFLAGS="$CPPFLAGS -Dftruncate=chsize -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib" MANTYPE='$(CATMAN)' mansubdir=cat @@ -219,7 +217,7 @@ AC_DEFINE(DISABLE_SHADOW) ;; *-*-sco3.2v5*) - CFLAGS="$CFLAGS -I/usr/local/include" + CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib" MANTYPE='$(CATMAN)' mansubdir=cat @@ -250,7 +248,7 @@ [ --with-cflags Specify additional flags to pass to compiler], [ if test "x$withval" != "xno" ; then - CFLAGS="$CFLAGS $withval" + CPPFLAGS="$CPPFLAGS $withval" fi ] ) @@ -396,7 +394,7 @@ saved_LIBS="$LIBS" saved_LDFLAGS="$LDFLAGS" -saved_CFLAGS="$CFLAGS" +saved_CPPFLAGS="$CPPFLAGS" if test "x$prefix" != "xNONE" ; then tryssldir="$tryssldir $prefix" fi @@ -405,7 +403,7 @@ for ssldir in $tryssldir "" /usr/local/openssl /usr/lib/openssl /usr/local/ssl /usr/lib/ssl /usr/local /usr/pkg /opt /opt/openssl ; do if test ! -z "$ssldir" ; then LDFLAGS="$saved_LDFLAGS -L$ssldir/lib -L$ssldir" - CFLAGS="$saved_CFLAGS -I$ssldir/include" + CPPFLAGS="$saved_CPPFLAGS -I$ssldir/include" if test ! -z "$need_dash_r" ; then LDFLAGS="$LDFLAGS -R$ssldir/lib -R$ssldir" fi @@ -454,7 +452,7 @@ AC_DEFINE(HAVE_OPENSSL) dnl Need to recover ssldir - test above runs in subshell ssldir=$ac_cv_openssldir - CFLAGS="$saved_CFLAGS -I$ssldir/include" + CPPFLAGS="$saved_CPPFLAGS -I$ssldir/include" LDFLAGS="$saved_LDFLAGS -L$ssldir/lib -L$ssldir" if test ! -z "$need_dash_r" ; then LDFLAGS="$LDFLAGS -R$ssldir/lib -R$ssldir" @@ -1057,7 +1055,7 @@ if test "x$withval" != "xno" ; then if test "x$withval" != "xyes" ; then - CFLAGS="$CFLAGS -I${withval}/include" + CPPFLAGS="$CPPFLAGS -I${withval}/include" LDFLAGS="$LDFLAGS -L${withval}/lib" if test ! -z "$need_dash_r" ; then LDFLAGS="$LDFLAGS -R${withval}/lib" @@ -1067,7 +1065,7 @@ fi else if test -d /usr/include/kerberosIV ; then - CFLAGS="$CFLAGS -I/usr/include/kerberosIV" + CPPFLAGS="$CPPFLAGS -I/usr/include/kerberosIV" fi fi @@ -1097,7 +1095,7 @@ if test "x$withval" != "xno" ; then if test "x$withval" != "xyes" ; then - CFLAGS="$CFLAGS -I${withval}/include" + CPPFLAGS="$CPPFLAGS -I${withval}/include" LDFLAGS="$LDFLAGS -L${withval}/lib" fi @@ -1124,7 +1122,7 @@ if test "x$withval" != "xno" ; then if test "x$withval" != "xyes" ; then - CFLAGS="$CFLAGS -I${withval}/include" + CPPFLAGS="$CPPFLAGS -I${withval}/include" LDFLAGS="$LDFLAGS -L${withval}/lib" fi @@ -1599,11 +1597,12 @@ echo "" -echo " Host: ${host}" -echo " Compiler: ${CC}" -echo " Compiler flags: ${CFLAGS}" -echo " Linker flags: ${LDFLAGS}" -echo " Libraries: ${LIBS}" +echo " Host: ${host}" +echo " Compiler: ${CC}" +echo " Compiler flags: ${CFLAGS}" +echo "Preprocessor flags: ${CPPFLAGS}" +echo " Linker flags: ${LDFLAGS}" +echo " Libraries: ${LIBS}" echo "" From wsanchez at apple.com Thu Dec 7 13:14:19 2000 From: wsanchez at apple.com (Wilfredo Sanchez) Date: Wed, 6 Dec 2000 18:14:19 -0800 Subject: [PATCH] Separate CFLAGS and CPPFLAGS In-Reply-To: Message-ID: <200012070214.SAA26434@scv1.apple.com> > Along with breaks most of the ports since they put all the -I entries in > CFLAGS. As far as I can tell, that would continue to work, even though it will continue to be the wrong way to do it. Though it's not like that would be a big challenge to fix in the ports. -Fred Wilfredo S?nchez, wsanchez at apple.com Open Source Engineering Lead Apple Computer, Inc., Core Operating System Group 1 Infinite Loop, Cupertino, CA 94086, 408.974-5174 From wsanchez at apple.com Thu Dec 7 13:16:45 2000 From: wsanchez at apple.com (Wilfredo Sanchez) Date: Wed, 6 Dec 2000 18:16:45 -0800 Subject: [PATCH] Separate CFLAGS and CPPFLAGS In-Reply-To: Message-ID: <200012070216.SAA26867@scv1.apple.com> > Attached should be a patch that splits CFLAGS into CFLAGS and CPPFLAGS. Oh, much better. I'm feeling rather stupid for not having checked configure. I even know better. Thanks, -Fred Wilfredo S?nchez, wsanchez at apple.com Open Source Engineering Lead Apple Computer, Inc., Core Operating System Group 1 Infinite Loop, Cupertino, CA 94086, 408.974-5174 From djm at mindrot.org Thu Dec 7 14:41:14 2000 From: djm at mindrot.org (Damien Miller) Date: Thu, 7 Dec 2000 14:41:14 +1100 (EST) Subject: openssh-SNAP-20001207 scp "Bad file descriptor" sort-of work-around In-Reply-To: <200012062333.QAA03147@amethyst.nurealm.net> Message-ID: On Wed, 6 Dec 2000, James wrote: > Everything seems to work, though I still have trouble with scp. The > behaviour is not protocol dependent - acts the same with either. (Using > RedHat 6.2) > > When I scp :, bash is invoked as a login shell on the > server side host - this doesn't seem right. With my /etc/profile, I get Do you have something in your profile or shell rc which causes text to be displayed on non-interactive logins? What does "ssh localhost true" say? You mustn't have junk being printed for non-interactive sessions. -d > Dec 6 15:06:20 amethyst sshd[3027]: error: select: Bad file descriptor > > in the log (something doesn't like my script), and > > sourcing /etc/profile... > Connection to closed by remote host. > > on the client side. (My /etc/profile generates the "sourcing > /etc/profile..." message.) > > If instead I mv /etc/profile /etc/profile.tmp, scp is successful. strace > then gives, toward the end: > > open("/etc/passwd", O_RDONLY) = 3 > fcntl(3, F_GETFD) = 0 > fcntl(3, F_SETFD, FD_CLOEXEC) = 0 > fstat(3, {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0 > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > 0) = 0x40015000 > read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 2335 > close(3) = 0 > munmap(0x40015000, 4096) = 0 > ioctl(2, TCGETS, 0xbffff734) = -1 EINVAL (Invalid argument) > rt_sigaction(SIGPIPE, {0x804b0bc, [], SA_RESTART|0x4000000}, {SIG_DFL}, 8) > = 0 > pipe([3, 4]) = 0 > pipe([5, 6]) = 0 > pipe([7, 8]) = 0 > close(3) = 0 > close(4) = 0 > fork() = 21936 > close(5) = 0 > close(8) = 0 > read(7, bash: /etc/profile: No such file or directory > bash: cma: command not found > "\0", 1) = 1 > open("ssh-copy-id", O_RDONLY) = 3 > fstat(3, {st_mode=S_IFREG|0644, st_size=1144, ...}) = 0 > write(6, "C0644 1144 ssh-copy-id\n", 23) = 23 > read(7, "\0", 1) = 1 > fstat(3, {st_mode=S_IFREG|0644, st_size=1144, ...}) = 0 > brk(0x8051000) = 0x8051000 > read(3, "#!/bin/sh\n\n# Shell script to ins"..., 1144) = 1144 > write(6, "#!/bin/sh\n\n# Shell script to ins"..., 1144) = 1144 > close(3) = 0 > write(6, "\0", 1) = 1 > read(7, "\0", 1) = 1 > _exit(0) > > ("cma" is a missing command from /etc/profile called from ~/.profile. > "ssh-copy-id" is the test file I'm trying to scp.) > > When scp breaks, the very end looks like: > > read(7, ".", 1) = 1 > read(7, "\n", 1) = 1 > write(2, "sourcing /etc/profile...\n", 25sourcing /etc/profile... > ) = 25 > _exit(1) = ? > Connection to closed by remote host. > > > So, is starting a bash login shell correct behavior for scp? > > This login shell behaviour is a problem, as you can see. An incompatibility > with /etc/profile or ~/.profile kills scp - uhg. > > Might I have misconfigured something in ssh_config or sshd_config? or > compiling the package? I have: > > OpenSSH configured has been configured with the following options. > User binaries: /usr/bin > User binaries: /usr/bin > System binaries: /usr/sbin > Configuration files: /etc/ssh > Askpass program: /usr/libexec/ssh-askpass > Manual pages: /usr/man/manX > PID file: /var/run > Random number collection: Device (/dev/urandom) > Manpage format: man > PAM support: yes > KerberosIV support: no > AFS support: no > S/KEY support: yes > TCP Wrappers support: yes > MD5 password support: no > IP address in $DISPLAY hack: no > Use IPv4 by default hack: no > Translate v4 in v6 hack: yes > > Host: i686-pc-linux-gnu > Compiler: gcc > Compiler flags: -g -O2 -Wall -I. -I. -I/usr/include > Linker flags: -L/usr/lib -L/usr > Libraries: -ldl -lnsl -lz -lutil -lpam -lcrypto -lskey -lwrap > > > Please Cc me on any response, as I'm not subscribed to the list. Thanks. > > > James Feeney > > > -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From djm at mindrot.org Thu Dec 7 15:03:57 2000 From: djm at mindrot.org (Damien Miller) Date: Thu, 7 Dec 2000 15:03:57 +1100 (EST) Subject: [PATCH] Separate CFLAGS and CPPFLAGS In-Reply-To: Message-ID: On Wed, 6 Dec 2000 mouring at etoh.eviladmin.org wrote: > > Ok.. Let me wake up for a few minutes. > > =) > > Attached should be a patch that splits CFLAGS into CFLAGS and CPPFLAGS. > > If anyone knows a better way or sees a problem with it.. Let me know. If > I don't hear anything I'll apply it in a few days. Is this correct? *-*-hpux10*) if test -z "$GCC"; then - CFLAGS="$CFLAGS -Ae" + CPPFLAGS="$CPPFLAGS -Ae" fi Is Ae a c or cpp flag? You might also want to add a '--with-cppflags' configure option for consistency. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From mouring at etoh.eviladmin.org Thu Dec 7 16:11:54 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 6 Dec 2000 23:11:54 -0600 (CST) Subject: [PATCH] Separate CFLAGS and CPPFLAGS In-Reply-To: Message-ID: On Thu, 7 Dec 2000, Damien Miller wrote: > On Wed, 6 Dec 2000 mouring at etoh.eviladmin.org wrote: > > > > > Ok.. Let me wake up for a few minutes. > > > > =) > > > > Attached should be a patch that splits CFLAGS into CFLAGS and CPPFLAGS. > > > > If anyone knows a better way or sees a problem with it.. Let me know. If > > I don't hear anything I'll apply it in a few days. > > Is this correct? > > *-*-hpux10*) > if test -z "$GCC"; then > - CFLAGS="$CFLAGS -Ae" > + CPPFLAGS="$CPPFLAGS -Ae" > fi > > Is Ae a c or cpp flag? > Unsure. I assumed that anything that was required to compile OpenSSH should be pushed to CPPFLAGS to ensure that one does not mistakenly clober things by doing 'make CLFAGS=".."' But each respective platform maintainer(s) should really review and let me know if I'm smoking crack. =) > You might also want to add a '--with-cppflags' configure option for > consistency. > Noted.. I'll add it before the final commit. From mouring at etoh.eviladmin.org Thu Dec 7 16:15:50 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 6 Dec 2000 23:15:50 -0600 (CST) Subject: [PATCH] Separate CFLAGS and CPPFLAGS In-Reply-To: Message-ID: On Wed, 6 Dec 2000 mouring at etoh.eviladmin.org wrote: > On Thu, 7 Dec 2000, Damien Miller wrote: > > > On Wed, 6 Dec 2000 mouring at etoh.eviladmin.org wrote: > > > > > > > > Ok.. Let me wake up for a few minutes. > > > > > > =) > > > > > > Attached should be a patch that splits CFLAGS into CFLAGS and CPPFLAGS. > > > > > > If anyone knows a better way or sees a problem with it.. Let me know. If > > > I don't hear anything I'll apply it in a few days. > > > > Is this correct? > > > > *-*-hpux10*) > > if test -z "$GCC"; then > > - CFLAGS="$CFLAGS -Ae" > > + CPPFLAGS="$CPPFLAGS -Ae" > > fi > > > > Is Ae a c or cpp flag? > > > Unsure. I assumed that anything that was required to compile OpenSSH > should be pushed to CPPFLAGS to ensure that one does not mistakenly > clober things by doing 'make CLFAGS=".."' > > But each respective platform maintainer(s) should really review and let me > know if I'm smoking crack. =) > > > You might also want to add a '--with-cppflags' configure option for > > consistency. > > > Noted.. I'll add it before the final commit. > > Umm... No one tell me about --with-cflags issue. =) I caught it.. I mistaken changed it. to CPPFLAGS =) Oops. - Ben From rob at hagopian.net Thu Dec 7 16:31:02 2000 From: rob at hagopian.net (Rob Hagopian) Date: Thu, 7 Dec 2000 00:31:02 -0500 (EST) Subject: openssh-SNAP-20001207 scp "Bad file descriptor" sort-of work-around In-Reply-To: Message-ID: Indeed, I've had users do that and it took me a bit to figure out why... Isn't there just a way to just ignore that? -Rob On Thu, 7 Dec 2000, Damien Miller wrote: > On Wed, 6 Dec 2000, James wrote: > > > Everything seems to work, though I still have trouble with scp. The > > behaviour is not protocol dependent - acts the same with either. (Using > > RedHat 6.2) > > > > When I scp :, bash is invoked as a login shell on the > > server side host - this doesn't seem right. With my /etc/profile, I get > > > Do you have something in your profile or shell rc which causes text to > be displayed on non-interactive logins? > > What does "ssh localhost true" say? > > You mustn't have junk being printed for non-interactive sessions. > > -d > > > Dec 6 15:06:20 amethyst sshd[3027]: error: select: Bad file descriptor > > > > in the log (something doesn't like my script), and > > > > sourcing /etc/profile... > > Connection to closed by remote host. > > > > on the client side. (My /etc/profile generates the "sourcing > > /etc/profile..." message.) > > > > If instead I mv /etc/profile /etc/profile.tmp, scp is successful. strace > > then gives, toward the end: > > > > open("/etc/passwd", O_RDONLY) = 3 > > fcntl(3, F_GETFD) = 0 > > fcntl(3, F_SETFD, FD_CLOEXEC) = 0 > > fstat(3, {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0 > > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > > 0) = 0x40015000 > > read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 2335 > > close(3) = 0 > > munmap(0x40015000, 4096) = 0 > > ioctl(2, TCGETS, 0xbffff734) = -1 EINVAL (Invalid argument) > > rt_sigaction(SIGPIPE, {0x804b0bc, [], SA_RESTART|0x4000000}, {SIG_DFL}, 8) > > = 0 > > pipe([3, 4]) = 0 > > pipe([5, 6]) = 0 > > pipe([7, 8]) = 0 > > close(3) = 0 > > close(4) = 0 > > fork() = 21936 > > close(5) = 0 > > close(8) = 0 > > read(7, bash: /etc/profile: No such file or directory > > bash: cma: command not found > > "\0", 1) = 1 > > open("ssh-copy-id", O_RDONLY) = 3 > > fstat(3, {st_mode=S_IFREG|0644, st_size=1144, ...}) = 0 > > write(6, "C0644 1144 ssh-copy-id\n", 23) = 23 > > read(7, "\0", 1) = 1 > > fstat(3, {st_mode=S_IFREG|0644, st_size=1144, ...}) = 0 > > brk(0x8051000) = 0x8051000 > > read(3, "#!/bin/sh\n\n# Shell script to ins"..., 1144) = 1144 > > write(6, "#!/bin/sh\n\n# Shell script to ins"..., 1144) = 1144 > > close(3) = 0 > > write(6, "\0", 1) = 1 > > read(7, "\0", 1) = 1 > > _exit(0) > > > > ("cma" is a missing command from /etc/profile called from ~/.profile. > > "ssh-copy-id" is the test file I'm trying to scp.) > > > > When scp breaks, the very end looks like: > > > > read(7, ".", 1) = 1 > > read(7, "\n", 1) = 1 > > write(2, "sourcing /etc/profile...\n", 25sourcing /etc/profile... > > ) = 25 > > _exit(1) = ? > > Connection to closed by remote host. > > > > > > So, is starting a bash login shell correct behavior for scp? > > > > This login shell behaviour is a problem, as you can see. An incompatibility > > with /etc/profile or ~/.profile kills scp - uhg. > > > > Might I have misconfigured something in ssh_config or sshd_config? or > > compiling the package? I have: > > > > OpenSSH configured has been configured with the following options. > > User binaries: /usr/bin > > User binaries: /usr/bin > > System binaries: /usr/sbin > > Configuration files: /etc/ssh > > Askpass program: /usr/libexec/ssh-askpass > > Manual pages: /usr/man/manX > > PID file: /var/run > > Random number collection: Device (/dev/urandom) > > Manpage format: man > > PAM support: yes > > KerberosIV support: no > > AFS support: no > > S/KEY support: yes > > TCP Wrappers support: yes > > MD5 password support: no > > IP address in $DISPLAY hack: no > > Use IPv4 by default hack: no > > Translate v4 in v6 hack: yes > > > > Host: i686-pc-linux-gnu > > Compiler: gcc > > Compiler flags: -g -O2 -Wall -I. -I. -I/usr/include > > Linker flags: -L/usr/lib -L/usr > > Libraries: -ldl -lnsl -lz -lutil -lpam -lcrypto -lskey -lwrap > > > > > > Please Cc me on any response, as I'm not subscribed to the list. Thanks. > > > > > > James Feeney > > > > > > > > From Jan.Iven at cern.ch Thu Dec 7 19:20:39 2000 From: Jan.Iven at cern.ch (Jan IVEN) Date: 07 Dec 2000 09:20:39 +0100 Subject: Problems on Sparcs (fwd) In-Reply-To: Markus Friedl's message of "Wed, 6 Dec 2000 20:57:45 +0100" References: <20001206205745.A4219@folly> Message-ID: >>>>> "MF" == Markus Friedl writes: MF> comments? MF> From: Charles Clancy MF> Subject: Problems on Sparcs MF> To: MF> Date: Wed, 6 Dec 2000 09:55:41 -0500 (EST) MF> I compiled OpenSSH 2.3.0p1 for Solaris 7 (32-bit) with OpenSSL 0.95a, with MF> GCC 2.95.2 (sunfreeware.com binaries). Similar setup here (locally compiled gcc-2.91.66, kth-1.0.2 for KRB4 support). MF> We are using OpenSSH because it supports PAM, which is required for our MF> network, as our workstations run AFS, and very few daemons support MF> authentication via AFS. We tried PAM on Solaris for the same reasons, then discovered that compiling sshd without PAM works even better - AFS token forwarding works in both cases, and without PAM, standard KRB4 authentication will be used. This works nicely as long as you have a /etc/srvtab on all machines. MF> On our most frequently used Ultra 80 (2x450MHz, 1G RAM), we have been MF> having problems ever since upgrading from SSH 1.2.27 (w/ PAM patch) to MF> OpenSSH. Remote SSH connections stop working after about 2 days (sshd is MF> run from inetd through tcp_wrappers). After 2 days, if you log in MF> locally, graphical logins will halt. A console text-based login works, MF> but about half the basic unix commands have problems. For example, a "w" MF> only returns the first line, and then halts. A "ps -ef" will get about MF> half way through before getting stuck. A CTRL-C won't get you out of them MF> either. All you can do is "sync; reboot" from a telnet connection MF> (tcp_wrappers is configured to allow telnet from one of our servers). similar symptoms seen infrequently over here, but only on Solaris7 (not on 2.6). MF> This machine is being used mostly as a general purpose workstation. I MF> know at least one person is using MATLAB and doing some X-Forwarding. MF> All the other machines (1 Ultra 80 and 10 Ultra 10s) are working fine. We MF> did have one Ultra 2 (web server) that exhibited some of these problems, MF> but I immediately switched it back to SSH 1.2.27, because we can't afford MF> any downtime on that machine. MF> Do you have any idea what would cause this bizarre behavior? TransARC libpamafs has been causing trouble in the past, and we are happy to have gotten rid of it. The AFS kernel support for Solaris7 may be somewhat flaky as well (k_hasafs() sometimes returning 0...) Sorry, no easy answer from over here. Our build environment/binaries is at /afs/cern.ch/project/connectivity/openssh-2.2.0/@sys/install/, feel free to have a look.(it is actually a patched-up 2.3.0) Regards Jan From Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Dec 7 20:00:32 2000 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Thu, 7 Dec 2000 10:00:32 +0100 Subject: [PATCH] Separate CFLAGS and CPPFLAGS In-Reply-To: ; from djm@mindrot.org on Thu, Dec 07, 2000 at 03:03:57PM +1100 References: Message-ID: <20001207100032.B810@ws01.aet.tu-cottbus.de> On Thu, Dec 07, 2000 at 03:03:57PM +1100, Damien Miller wrote: > On Wed, 6 Dec 2000 mouring at etoh.eviladmin.org wrote: > > If anyone knows a better way or sees a problem with it.. Let me know. If > > I don't hear anything I'll apply it in a few days. > *-*-hpux10*) > if test -z "$GCC"; then > - CFLAGS="$CFLAGS -Ae" > + CPPFLAGS="$CPPFLAGS -Ae" > fi > > Is Ae a c or cpp flag? Seems I have to download the latest snapshot and look myself. CFLAGS are flags passed to the C-compiler, influencing its standard version, optimization and/or debugging feature. CPPFLAGS are traditionally flags only needed for the C-preprocessor. Depending on the package I have seen scripts using the C-preprocessor directly (invoked as cpp), so CPPFLAGS should only contain flags typically understood by C-preprocessors: That is -I and -D (there are others like -U, but I have never seen them in practice :-). (*) Modern versions tend to use "cc -E" to call the preprocessor. Having this said, -Ae switches the C-compiler to ANSI mode (with some extensions), hence this clearly belongs to CFLAGS. My standard way of configuring packages using "autoconf"-style configure scripts (I have a standard /usr/local instead of /opt/packagename setup): CC=cc CFLAGS="-Ae -O +DAportable" CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" ./configure This is how I use CFLAGS and CPPFLAGS and as far as I have experienced while porting packages, this seems to match the expectations :-) Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From Ulrich.Windl at rz.uni-regensburg.de Thu Dec 7 21:34:36 2000 From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl) Date: Thu, 7 Dec 2000 11:34:36 +0100 Subject: sshd fails to accept connections on HP-UX 11.00 Message-ID: <3A2F75C4.28881.C3A011@localhost> Hello, we run OpenSSH_2.3.0p1 on HP-UX 11.00. Today I had a problem connecting to a machine via SSH. The connection seemed to hang. Syslog showed nothing, and no sshd processes were started, although I had two hanging connections (no output). I logged in via telnet and found one sshd (master) running in addition to a ssh-agent from a session that went away. That ssh-agent was owned by my user id. After killing the ssh- agent, ssh login worked again. I don't quite understand that: I thought ssh-agent is responsible for outgoing connections, but not incoming ones. In addition, how does the master sshd know about the existence of a ssh-agent? Regards, Ulrich P.S. Not subscribed here, so please CC: From stheinri at hamilton.physik.uni-konstanz.de Fri Dec 8 02:54:44 2000 From: stheinri at hamilton.physik.uni-konstanz.de (Stefan Heinrichs) Date: Thu, 7 Dec 2000 16:54:44 +0100 Subject: Bugreport: Lines swallowed in std_out redirection Message-ID: <20001207165444.A22552@athene.physik.uni-konstanz.de> Hi, we are using OpenSSH_2.3.0p1. When using non-interactive mode, sometimes lines are swallowed from standard output: root at hydra:~ # ssh anderson "ls -l /usr/sbin/sshd" -rwxr-xr-x 1 root root 612344 Nov 25 20:26 /usr/sbin/sshd root at hydra:~ # ssh anderson "ls -l /usr/sbin/sshd" root at hydra:~ # ssh anderson "ls -l /usr/sbin/sshd" -rwxr-xr-x 1 root root 612344 Nov 25 20:26 /usr/sbin/sshd At the same time the following appears in /var/log/messages: sshd[6741]: error: channel 0: internal error: we do not read, but chan_read_failed for istate 8 We tested several kernel versions: 2.2.16, 2.2.17, 2.2.17-SMP with some local patches, and 2.2.17, 2.2.18pre24, 2.2.18pre24-SMP unpatched. Compilers used to generate the kernels were: gcc-2.7.2.3, egcs-1.1.2 and gcc-2.95.2. The problem could not be reproduced on SMP machines and only occurs in non-interactive mode. The problem did not occur with OpenSSH-2.1.1p4 The problem also disappears if ';true' is appended to the command line executed remotely. Best regards, Stefan From mstone at cs.loyola.edu Fri Dec 8 03:25:30 2000 From: mstone at cs.loyola.edu (Michael Stone) Date: Thu, 7 Dec 2000 11:25:30 -0500 Subject: Cipher 'none' In-Reply-To: ; from epa98@doc.ic.ac.uk on Fri, Oct 13, 2000 at 04:11:12PM +0100 References: Message-ID: <20001207112530.O5710@justice.loyola.edu> What was the final resolution of this thread? Does key-based authentication provide secure auth if cipher none is used? What about rhosts-rsa? -- Mike Stone From rob at hagopian.net Fri Dec 8 03:42:57 2000 From: rob at hagopian.net (Rob Hagopian) Date: Thu, 7 Dec 2000 11:42:57 -0500 (EST) Subject: Cipher 'none' In-Reply-To: <20001207112530.O5710@justice.loyola.edu> Message-ID: As I understood it, patches would be considered, but noone has submitted one... -Rob On Thu, 7 Dec 2000, Michael Stone wrote: > What was the final resolution of this thread? Does key-based > authentication provide secure auth if cipher none is used? What about > rhosts-rsa? > > From ishikawa at yk.rim.or.jp Fri Dec 8 03:49:57 2000 From: ishikawa at yk.rim.or.jp (Ishikawa) Date: Fri, 08 Dec 2000 01:49:57 +0900 Subject: sunos 4.1.4 Makefile and regex.[ch] fix Message-ID: <3A2FBFB5.2090105@yk.rim.or.jp> Hi, At the office, there is an old ss5 box running sunos 4.1.4. I have configured openssh using gcc on this machine. In doing so, I found a few compilation and configuration problems. 1. Compilation Problem. SunOS 4.1.4 doesn't have regex.h header nor the entry points regex.c is supposed to offer. Solution. Copy regex.c and regex.h from, say, GNU awk distribution to the openssh directory and add regex.o in Makefile (Makefile.in). configure and it would work. I have no idea how to fix configure.in, etc.. X-PMC-CI-e-mail-id: 14242 =================================================================== RCS file: RCS/Makefile,v retrieving revision 1.1 diff -cibw -r1.1 Makefile *** Makefile 2000/12/06 12:46:01 1.1 --- Makefile 2000/12/06 12:52:26 *************** *** 35,41 **** TARGETS=ssh$(EXEEXT) sshd$(EXEEXT) ssh-add$(EXEEXT) ssh-keygen$(EXEEXT) ssh-agent$(EXEEXT) scp$(EXEEXT) sftp-server$(EXEEXT) $(EXTRA_TARGETS) ! LIBSSH_OBJS=atomicio.o authfd.o authfile.o bufaux.o buffer.o canohost.o channels.o cipher.o cli.o compat.o compress.o crc32.o cygwin_util.o deattack.o dispatch.o dsa.o hmac.o hostfile.o key.o kex.o log.o match.o mpaux.o nchan.o packet.o radix.o rijndael.o entropy.o readpass.o rsa.o tildexpand.o ttymodes.o uidswap.o util.o uuencode.o xmalloc.o LIBOPENBSD_COMPAT_OBJS=bsd-arc4random.o bsd-base64.o bsd-bindresvport.o bsd-daemon.o bsd-getcwd.o bsd-inet_aton.o bsd-inet_ntoa.o bsd-misc.o bsd-mktemp.o bsd-realpath.o bsd-rresvport.o bsd-setenv.o bsd-sigaction.o bsd-snprintf.o bsd-strlcat.o bsd-strlcpy.o bsd-strsep.o bsd-strtok.o bsd-vis.o bsd-setproctitle.o bsd-waitpid.o fake-getaddrinfo.o fake-getnameinfo.o next-posix.o --- 35,41 ---- TARGETS=ssh$(EXEEXT) sshd$(EXEEXT) ssh-add$(EXEEXT) ssh-keygen$(EXEEXT) ssh-agent$(EXEEXT) scp$(EXEEXT) sftp-server$(EXEEXT) $(EXTRA_TARGETS) ! LIBSSH_OBJS=atomicio.o authfd.o authfile.o bufaux.o buffer.o canohost.o channels.o cipher.o cli.o compat.o compress.o crc32.o cygwin_util.o deattack.o dispatch.o dsa.o hmac.o hostfile.o key.o kex.o log.o match.o mpaux.o nchan.o packet.o radix.o rijndael.o entropy.o readpass.o rsa.o tildexpand.o ttymodes.o uidswap.o util.o uuencode.o xmalloc.o regex.o LIBOPENBSD_COMPAT_OBJS=bsd-arc4random.o bsd-base64.o bsd-bindresvport.o bsd-daemon.o bsd-getcwd.o bsd-inet_aton.o bsd-inet_ntoa.o bsd-misc.o bsd-mktemp.o bsd-realpath.o bsd-rresvport.o bsd-setenv.o bsd-sigaction.o bsd-snprintf.o bsd-strlcat.o bsd-strlcpy.o bsd-strsep.o bsd-strtok.o bsd-vis.o bsd-setproctitle.o bsd-waitpid.o fake-getaddrinfo.o fake-getnameinfo.o next-posix.o 2. Configuration problem: This may be serious since the problem described here may apply to wider installation base. Since SunOS 4.1.4 doesn't have (u)random devices, the sshd and ssh resort to a shell script installed in /usr/local/etc to gather entropy for pseudo random number generation. Well, I looked into the script and tested various commands by hand. There may be problems under certain configurations. There are many references to various system directories such as /var/adm, /var/log, etc.. It turns out some of the popular directory names on this particular sparc box are symlinks to directories on different physical disk. Since sun's default OS installer sets aside rather smallish amount for /var directory by default, I bet there are many systems where some of the heavily used var directories are symlinks to later added larger disks. Unfortunately, on SunOS, many ls commands in the scripts probably return the same data (just a symlink name with the same time stamp over and over. It won't descend into the target directory.) and won't add to entropy much. I wonder if someone can figure out a way to modify the directory entries in the script so that the target of the symlinks are placed in the installed copy instead of the original symlink names. I manually modified the script, but wonder if automatic way is better. Definitely yes, but I am not sure how to go about it. Just a thought. I tested the ssh (never inteded to run sshd on this machine) against an opensshd daemon running on Solaris 7 (sunos 5.7) for x86 box and it seemed to work fine. Please keep up the good work! Happy Hacking, ishikawa From ETARDIEU at CPR.FR Fri Dec 8 04:47:20 2000 From: ETARDIEU at CPR.FR (TARDIEU Emmanuel) Date: Thu, 7 Dec 2000 18:47:20 +0100 Subject: Bugreport: Lines swallowed in std_out redirection Message-ID: <5BF932D2CD05D211B54800805FE60FEB08F52A63@serv-hermes.systeme.cpr.fr> I have the same problem with openssh-2.3.0p1 on sun solaris 2.6 sparc. ssh -l root gaia echo \$PATH would sometime produce nothing to the standard output. Emmanuel > -----Message d'origine----- > De : Stefan Heinrichs > [mailto:stheinri at hamilton.physik.uni-konstanz.de] > Envoy? : jeudi 7 d?cembre 2000 16:55 > ? : openssh-unix-dev at mindrot.org > Objet : Bugreport: Lines swallowed in std_out redirection > > > Hi, > > we are using OpenSSH_2.3.0p1. When using non-interactive mode, > sometimes lines are swallowed from standard output: > > root at hydra:~ # ssh anderson "ls -l /usr/sbin/sshd" > -rwxr-xr-x 1 root root 612344 Nov 25 20:26 /usr/sbin/sshd > root at hydra:~ # ssh anderson "ls -l /usr/sbin/sshd" > root at hydra:~ # ssh anderson "ls -l /usr/sbin/sshd" > -rwxr-xr-x 1 root root 612344 Nov 25 20:26 > /usr/sbin/sshd > > At the same time the following appears in /var/log/messages: > > sshd[6741]: error: channel 0: internal error: we do not read, but > chan_read_failed for istate 8 > > We tested several kernel versions: > 2.2.16, 2.2.17, 2.2.17-SMP with some local patches, > and 2.2.17, 2.2.18pre24, 2.2.18pre24-SMP unpatched. > Compilers used to generate the kernels were: > gcc-2.7.2.3, egcs-1.1.2 and gcc-2.95.2. > > The problem could not be reproduced on SMP machines and only occurs in > non-interactive mode. > > The problem did not occur with OpenSSH-2.1.1p4 > > The problem also disappears if ';true' is appended to the command line > executed remotely. > > Best regards, > > Stefan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001207/0e9c0e6b/attachment.html From bazsi at balabit.hu Fri Dec 8 04:57:32 2000 From: bazsi at balabit.hu (Balazs Scheidler) Date: Thu, 7 Dec 2000 18:57:32 +0100 Subject: [PATCH] tis authserv support Message-ID: <20001207185732.A1406@balabit.hu> Hi, We at BalaBit IT Security Ltd developed a patch against openssh 2.3.0p1 to support TIS authserv authentication. TIS authserv uses a simple protocol, and supports CryptoCard, SKey, password etc. authentication. The commercial versions of SSH support this protocol, OpenSSH implemented SKey on its own using the protocol primitives originally invented for TIS authentication. Our patch is an alternative to S/Key support in OpenSSH, the two cannot be compiled in at the same time. Inclusion of this patch in openssh would be welcome and appreciated. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 url: http://www.balabit.hu/pgpkey.txt -------------- next part -------------- diff -urN openssh-2.3.0p1/Makefile.in openssh-2.3.0p1-tis/Makefile.in --- openssh-2.3.0p1/Makefile.in Sun Nov 5 22:13:45 2000 +++ openssh-2.3.0p1-tis/Makefile.in Thu Dec 7 18:38:42 2000 @@ -41,7 +41,7 @@ SSHOBJS= ssh.o sshconnect.o sshconnect1.o sshconnect2.o log-client.o readconf.o clientloop.o -SSHDOBJS= sshd.o auth.o auth1.o auth2.o auth-skey.o auth2-skey.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o dh.o pty.o log-server.o login.o loginrec.o servconf.o serverloop.o md5crypt.o session.o +SSHDOBJS= sshd.o auth.o auth1.o auth2.o auth-skey.o auth2-skey.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o dh.o pty.o log-server.o login.o loginrec.o servconf.o serverloop.o md5crypt.o session.o tisauth.o TROFFMAN = scp.1 ssh-add.1 ssh-agent.1 ssh-keygen.1 ssh.1 sshd.8 sftp-server.8 CATMAN = scp.0 ssh-add.0 ssh-agent.0 ssh-keygen.0 ssh.0 sshd.0 sftp-server.0 diff -urN openssh-2.3.0p1/acconfig.h openssh-2.3.0p1-tis/acconfig.h --- openssh-2.3.0p1/acconfig.h Wed Oct 18 15:11:44 2000 +++ openssh-2.3.0p1-tis/acconfig.h Thu Dec 7 18:38:42 2000 @@ -276,6 +276,8 @@ /* Detect IPv4 in IPv6 mapped addresses and treat as IPv4 */ #undef IPV4_IN_IPV6 +#undef TIS_AUTH + @BOTTOM@ /* ******************* Shouldn't need to edit below this line ************** */ diff -urN openssh-2.3.0p1/auth1.c openssh-2.3.0p1-tis/auth1.c --- openssh-2.3.0p1/auth1.c Sat Oct 14 07:23:11 2000 +++ openssh-2.3.0p1-tis/auth1.c Thu Dec 7 18:38:42 2000 @@ -12,6 +12,10 @@ #include "includes.h" RCSID("$OpenBSD: auth1.c,v 1.6 2000/10/11 20:27:23 markus Exp $"); +#ifdef TIS_AUTH +#include "tisauth.h" +#endif + #ifdef HAVE_OSF_SIA # include # include @@ -40,6 +44,10 @@ extern char **saved_argv; #endif /* HAVE_OSF_SIA */ +#if defined(SKEY) && defined(TIS_AUTH) +#error "S/Key and TIS authentication is not supported at the same time" +#endif + /* * convert ssh auth msg type into description */ @@ -60,6 +68,10 @@ case SSH_CMSG_AUTH_KERBEROS: return "kerberos"; #endif +#ifdef TIS_AUTH + case SSH_CMSG_AUTH_TIS_RESPONSE: + return "tis"; +#endif #ifdef SKEY case SSH_CMSG_AUTH_TIS_RESPONSE: return "s/key"; @@ -91,6 +103,9 @@ unsigned int ulen; int type = 0; void (*authlog) (const char *fmt,...) = verbose; +#ifdef TIS_AUTH + struct tis_context *tis = NULL; +#endif /* Indicate that authentication is needed. */ packet_start(SSH_SMSG_FAILURE); @@ -267,7 +282,54 @@ xfree(password); break; -#ifdef SKEY +#ifdef TIS_AUTH + case SSH_CMSG_AUTH_TIS: + debug("rcvd SSH_CMSG_AUTH_TIS"); + if (options.tis_authentication == 1) { + char *challenge = NULL; + + if (pw) { + tis_free(tis); + tis = tis_connect_multi(options.authserv_addrs); + if (tis) { + challenge = tis_authenticate(tis, pw->pw_name); + } + else { + log("Error connecting TIS authserv"); + } + else { + challenge = tis_fake_challenge(); + } + if (!challenge) { + break; + } + if (challenge != NULL) { + debug("sending challenge '%s'", challenge); + packet_start(SSH_SMSG_AUTH_TIS_CHALLENGE); + packet_put_string(challenge, strlen(challenge) - 1); + packet_send(); + packet_write_wait(); + xfree(challenge); + continue; + } + } + break; + case SSH_CMSG_AUTH_TIS_RESPONSE: + if (options.tis_authentication == 1 && tis && pw) { + char *response = packet_get_string(&dlen); + + debug("tis response == '%s'", response); + packet_integrity_check(plen, 4 + dlen, type); + authenticated = tis_response(tis, response); + tis_free(tis); + tis = NULL; + + /* allow only one attempt */ + attempt = AUTH_FAIL_MAX + 1; + xfree(response); + } + break; +#elif SKEY case SSH_CMSG_AUTH_TIS: debug("rcvd SSH_CMSG_AUTH_TIS"); if (options.skey_authentication == 1) { diff -urN openssh-2.3.0p1/config.h.in openssh-2.3.0p1-tis/config.h.in --- openssh-2.3.0p1/config.h.in Mon Nov 6 04:25:18 2000 +++ openssh-2.3.0p1-tis/config.h.in Thu Dec 7 18:38:42 2000 @@ -269,6 +269,8 @@ /* Detect IPv4 in IPv6 mapped addresses and treat as IPv4 */ #undef IPV4_IN_IPV6 +#undef TIS_AUTH + /* The number of bytes in a char. */ #undef SIZEOF_CHAR @@ -601,6 +603,9 @@ /* Define if you have the header file. */ #undef HAVE_VIS_H + +/* Define if you have the crypt library (-lcrypt). */ +#undef HAVE_LIBCRYPT /* Define if you have the dl library (-ldl). */ #undef HAVE_LIBDL diff -urN openssh-2.3.0p1/configure.in openssh-2.3.0p1-tis/configure.in --- openssh-2.3.0p1/configure.in Sun Nov 5 10:08:45 2000 +++ openssh-2.3.0p1-tis/configure.in Thu Dec 7 18:38:42 2000 @@ -263,10 +263,10 @@ ] ) - # Checks for libraries. AC_CHECK_LIB(z, deflate, ,AC_MSG_ERROR([*** zlib missing - please install first ***])) AC_CHECK_LIB(util, login, AC_DEFINE(HAVE_LIBUTIL_LOGIN) LIBS="$LIBS -lutil") +AC_CHECK_LIB(crypt, crypt) AC_CHECK_FUNC(regcomp, [], @@ -1116,6 +1116,18 @@ ] ) +# Check whether user wants S/Key support +TIS_MSG="no" +AC_ARG_WITH(tis, + [ --with-tis Enable TIS authsrv support, may not be used with --with-skey], + [ + if test "x$withval" != "xno" ; then + AC_DEFINE(TIS_AUTH) + TIS_MSG="yes" + fi + ] +) + # Check whether user wants TCP wrappers support TCPW_MSG="no" AC_ARG_WITH(tcp-wrappers, @@ -1566,6 +1578,7 @@ echo " KerberosIV support: $KRB4_MSG" echo " AFS support: $AFS_MSG" echo " S/KEY support: $SKEY_MSG" +echo " TIS authsrv support: $TIS_MSG" echo " TCP Wrappers support: $TCPW_MSG" echo " MD5 password support: $MD5_MSG" echo " IP address in \$DISPLAY hack: $DISPLAY_HACK_MSG" diff -urN openssh-2.3.0p1/readconf.c openssh-2.3.0p1-tis/readconf.c --- openssh-2.3.0p1/readconf.c Sat Oct 14 07:23:12 2000 +++ openssh-2.3.0p1-tis/readconf.c Thu Dec 7 18:38:42 2000 @@ -313,7 +313,7 @@ goto parse_flag; case oTISAuthentication: - /* fallthrough, there is no difference on the client side */ + /* fallthrough */ case oSkeyAuthentication: intptr = &options->skey_authentication; goto parse_flag; diff -urN openssh-2.3.0p1/servconf.c openssh-2.3.0p1-tis/servconf.c --- openssh-2.3.0p1/servconf.c Mon Oct 16 03:14:42 2000 +++ openssh-2.3.0p1-tis/servconf.c Thu Dec 7 18:41:00 2000 @@ -64,6 +64,9 @@ options->kbd_interactive_authentication = -1; #ifdef SKEY options->skey_authentication = -1; +#elif TIS_AUTH + options->tis_authentication = -1; + options->authserv_addrs = NULL; #endif options->permit_empty_passwd = -1; options->use_login = -1; @@ -155,6 +158,9 @@ #ifdef SKEY if (options->skey_authentication == -1) options->skey_authentication = 1; +#elif TIS_AUTH + if (options->tis_authentication == -1) + options->tis_authentication = 1; #endif if (options->permit_empty_passwd == -1) options->permit_empty_passwd = 0; @@ -188,6 +194,9 @@ #endif #ifdef SKEY sSkeyAuthentication, +#elif TIS_AUTH + sTISAuthentication, + sAuthservAddress, #endif sPasswordAuthentication, sKbdInteractiveAuthentication, sListenAddress, sPrintMotd, sIgnoreRhosts, sX11Forwarding, sX11DisplayOffset, @@ -230,6 +239,9 @@ { "kbdinteractiveauthentication", sKbdInteractiveAuthentication }, #ifdef SKEY { "skeyauthentication", sSkeyAuthentication }, +#elif TIS_AUTH + { "tisauthentication", sTISAuthentication }, + { "authservaddress", sAuthservAddress }, #endif { "checkmail", sCheckMail }, { "listenaddress", sListenAddress }, @@ -277,6 +289,35 @@ return sBadOption; } +#ifdef TIS_AUTH +void +add_authserv_addr(ServerOptions *options, char **addr) +{ + extern int IPv4or6; + struct addrinfo hints, *ai, *aitop; + char *host, *service; + int gaierr; + + memset(&hints, 0, sizeof(hints)); + hints.ai_family = IPv4or6; + hints.ai_socktype = SOCK_STREAM; + hints.ai_flags = (addr == NULL) ? AI_PASSIVE : 0; + + host = strdelim(addr); + service = strdelim(addr); + + if ((gaierr = getaddrinfo(host, service, &hints, &aitop)) != 0) + fatal("bad addr or host: %s (%s)\n", + host ? host : "", + gai_strerror(gaierr)); + for (ai = aitop; ai->ai_next; ai = ai->ai_next) + ; + ai->ai_next = options->authserv_addrs; + options->authserv_addrs = aitop; + +} +#endif + /* * add listen address */ @@ -518,6 +559,14 @@ case sSkeyAuthentication: intptr = &options->skey_authentication; goto parse_flag; +#elif TIS_AUTH + case sTISAuthentication: + intptr = &options->tis_authentication; + goto parse_flag; + + case sAuthservAddress: + add_authserv_addr(options, &cp); + break; #endif case sPrintMotd: diff -urN openssh-2.3.0p1/servconf.h openssh-2.3.0p1-tis/servconf.h --- openssh-2.3.0p1/servconf.h Mon Oct 16 03:14:43 2000 +++ openssh-2.3.0p1-tis/servconf.h Thu Dec 7 18:38:42 2000 @@ -83,6 +83,10 @@ int skey_authentication; /* If true, permit s/key * authentication. */ #endif +#ifdef TIS_AUTH + struct addrinfo *authserv_addrs; /* Addresses where a TIS authserv can be found. */ + int tis_authentication; /* if true, permit TIS authsrv authentication */ +#endif int permit_empty_passwd; /* If false, do not permit empty * passwords. */ int use_login; /* If true, login(1) is used */ diff -urN openssh-2.3.0p1/sshd.c openssh-2.3.0p1-tis/sshd.c --- openssh-2.3.0p1/sshd.c Sat Oct 14 07:23:13 2000 +++ openssh-2.3.0p1-tis/sshd.c Thu Dec 7 18:38:42 2000 @@ -1182,6 +1182,11 @@ if (options.skey_authentication == 1) auth_mask |= 1 << SSH_AUTH_TIS; #endif +#ifdef TIS_AUTH + if (options.tis_authentication == 1) + auth_mask |= 1 << SSH_AUTH_TIS; +#endif + if (options.password_authentication) auth_mask |= 1 << SSH_AUTH_PASSWORD; packet_put_int(auth_mask); diff -urN openssh-2.3.0p1/tisauth.c openssh-2.3.0p1-tis/tisauth.c --- openssh-2.3.0p1/tisauth.c Thu Jan 1 01:00:00 1970 +++ openssh-2.3.0p1-tis/tisauth.c Thu Dec 7 18:44:26 2000 @@ -0,0 +1,127 @@ +/* + * Copyright (c) 2000 BalaBit IT Ltd. + * All rights reserved + * + * Authors: Bal?zs Scheidler, Attila Szalay + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include "includes.h" +#include "ssh.h" + +#ifdef TIS_AUTH + +struct tis_context { + int connfd; +}; + +struct tis_context *tis_connect(struct sockaddr *addr, int addrlen) +{ + struct tis_context *ctx; + char line[128]; + int fd; + + fd = socket(addr->sa_family, SOCK_STREAM, 0); + if (fd < 0) + return NULL; + + if (connect(fd, addr, addrlen) < 0) { + close(fd); + return NULL; + } + + /* grab greeting line */ + if (read(fd, line, sizeof(line)) < 0) { + close(fd); + return NULL; + } + ctx = malloc(sizeof(struct tis_context)); + ctx->connfd = fd; + return ctx; +} + +struct tis_context *tis_connect_multi(struct addrinfo *addrs) +{ + struct addrinfo *p; + struct tis_context *tis; + + for (p = addrs; p; p = p->ai_next) { + tis = tis_connect(p->ai_addr, p->ai_addrlen); + if (tis) + return tis; + } + return NULL; +} + +void tis_free(struct tis_context *ctx) +{ + if (ctx) { + close(ctx->connfd); + free(ctx); + } +} + +char *tis_authenticate(struct tis_context *ctx, char *user) +{ + char line[128]; + int length; + + snprintf(line, 120, "authenticate \"%.32s\"\n", user); + if (send(ctx->connfd,line,strlen(line),0) < 0) { + return NULL; + } + if ((length = recv(ctx->connfd, line, sizeof(line) - 1, 0)) < 0) + return NULL; + line[length] = 0; + if (strncmp(line, "challenge", 9) != 0) + return NULL; + return strdup(line + 10); +} + +int tis_response(struct tis_context *ctx, char *response) +{ + char line[128]; + int length; + + snprintf(line, 120, "response \"%.64s\"\n", response) ; + if (send(ctx->connfd, line, strlen(line), 0) < 0) + return 0; + if ((length = recv(ctx->connfd, line, sizeof(line) - 1, 0)) < 0) + return 0; + line[length] = 0; + if (strncmp(line, "ok", 2) == 0) { + return 1; + } + return 0; +} + +char *tis_fake_challenge(void) +{ + char challenge[9]; + unsigned long rnd; + + rnd = time(NULL) ^ getpid(); + snprintf(challenge, sizeof(challenge), "%ld", rnd); + return strdup(challenge); +} + +#endif diff -urN openssh-2.3.0p1/tisauth.h openssh-2.3.0p1-tis/tisauth.h --- openssh-2.3.0p1/tisauth.h Thu Jan 1 01:00:00 1970 +++ openssh-2.3.0p1-tis/tisauth.h Thu Dec 7 18:44:53 2000 @@ -0,0 +1,41 @@ +/* + * Copyright (c) 2000 BalaBit IT Ltd. + * All rights reserved + * + * Authors: Bal?zs Scheidler, Attila Szalay + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#ifndef _TISAUTH_H_INCLUDED +#define _TISAUTH_H_INCLUDED + +struct tis_context; + +struct tis_context *tis_connect(struct sockaddr *addr, int addrlen); +struct tis_context *tis_connect_multi(struct addrinfo *addrs); +void tis_free(struct tis_context *ctx); +char *tis_authenticate(struct tis_context *ctx, char *user); +int tis_response(struct tis_context *ctx, char *response); +char *tis_fake_challenge(void); + +#endif + From epa98 at doc.ic.ac.uk Fri Dec 8 05:44:10 2000 From: epa98 at doc.ic.ac.uk (Edward Avis) Date: Thu, 7 Dec 2000 18:44:10 +0000 (GMT) Subject: Cipher 'none' In-Reply-To: Message-ID: yOn Thu, 7 Dec 2000, Rob Hagopian wrote: >As I understood it, patches would be considered, but noone has submitted >one... I had hoped to submit a simple one-line patch to reenable the cipher 'none', but it seems that people wouldn't accept that without extra safeguards to stop users shooting themselves in the foot. When I realized that something more complex would be needed, I was scared off. I might spend some time looking at the ssh source in greater depth and working out how to enable 'none' only if RSA/DSA authentication is being used (for example), but I haven't bothered to so far. -- Ed Avis epa98 at doc.ic.ac.uk From roth+openssh at feep.net Fri Dec 8 06:33:12 2000 From: roth+openssh at feep.net (Mark D. Roth) Date: Thu, 7 Dec 2000 13:33:12 -0600 Subject: [PATCH] tis authserv support In-Reply-To: <20001207132033.A26892@enterprise.isdn.uiuc.edu>; from roth+openssh@feep.net on Thu, Dec 07, 2000 at 01:20:33PM -0600 References: <20001207185732.A1406@balabit.hu> <20001207132033.A26892@enterprise.isdn.uiuc.edu> Message-ID: <20001207133312.A26994@enterprise.isdn.uiuc.edu> On Thu Dec 07 13:20 2000 -0600, Mark D. Roth wrote: > On Thu Dec 07 18:57 2000 +0100, Balazs Scheidler wrote: > > We at BalaBit IT Security Ltd developed a patch against openssh 2.3.0p1 to > > support TIS authserv authentication. TIS authserv uses a simple protocol, > > and supports CryptoCard, SKey, password etc. authentication. > > > > The commercial versions of SSH support this protocol, OpenSSH implemented > > SKey on its own using the protocol primitives originally invented for TIS > > authentication. > > > > Our patch is an alternative to S/Key support in OpenSSH, the two cannot be > > compiled in at the same time. > > I already submitted a patch to do this, but the OpenSSH folks declined > to include it. I've attached my patch, which I will begin > distributing from a publicly-accessible website sometime next week. > > If there's anything that your patch does that mine does not, please > feel free to send me the changes. IMHO, it's to everyone's benefit to > have only a single version of this patch floating around. Ugh. It looks like the patch was too big to be sent over the list. I've put it up at: http://www-dev.cso.uiuc.edu/openssh/ I'll finish cleaning up the webpage and adding documentation when I get back from LISA next week. -- Mark D. Roth http://www.feep.net/~roth/ From james at amethyst.nurealm.net Fri Dec 8 07:54:48 2000 From: james at amethyst.nurealm.net (James) Date: Thu, 07 Dec 2000 13:54:48 -0700 Subject: openssh-SNAP-20001207 scp "Bad file descriptor" sort-of work-around Message-ID: <200012072054.NAA03475@amethyst.nurealm.net> Damien wrote: > Do you have something in your profile or shell rc which causes text to > be displayed on non-interactive logins? No, but there's part of where the problem is. scp seems to read /etc/passwd on the _target_ server machine (as well as on the client machine) to determine the user's default shell on that target machine, and then invokes a non-login _interactive_ shell, NOT a non-interactive shell. I know this from changing the various scripts and the /etc/passwd login shell for the user (root). Where man bash has INVOCATION A login shell is one whose first character of argument zero is a -, or one started with the -login flag. An interactive shell is one whose standard input and out put are both connected to terminals (as determined by isatty(3)), or one started with the -i option. PS1 is set and $- includes i if bash is interactive, allowing a shell script or a startup file to test this state. Login shells: On login (subject to the -noprofile option): if /etc/profile exists, source it. if ~/.bash_profile exists, source it, else if ~/.bash_login exists, source it, else if ~/.profile exists, source it. On exit: if ~/.bash_logout exists, source it. Non-login interactive shells: On startup (subject to the -norc and -rcfile options): if ~/.bashrc exists, source it. My ~/.bashrc normally starts with "source /etc/profile", which was what actually generated the text, and the "sshd[3381]: error: select: Bad file descriptor" message in the log file. (I noticed that if I simply put echo "a bunch of random characters asdlfkjsd" into ~/.bashrc, that will also kill scp, but - and only in this particular case - without the "Bad file descriptor" error message.) I suppose I can try to modify ~/.bashrc to check how it's being called, but... Could this be a problem with bash? or a problem with how sshd calls the login shell? # echo $BASH_VERSION 1.14.7(1) > What does "ssh localhost true" say? On the client machine: # ssh localhost true ssh_exchange_identification: Connection closed by remote host with "sshd[25040]: refused connect from 127.0.0.1" in the log file. On the server machine, the same. Also the same if 127.0.0.1 is added to /etc/hosts.allow for sshd. Also the same for a non root user. > You mustn't have junk being printed for non-interactive sessions. What's the easiest way to invoke a for-sure non-interactive session for testing? Again, please Cc me on any response, as I'm not subscribed to the list. Thanks. James Feeney From GILBERT.R.LOOMIS at saic.com Fri Dec 8 07:52:49 2000 From: GILBERT.R.LOOMIS at saic.com (Loomis, Rip) Date: Thu, 7 Dec 2000 15:52:49 -0500 Subject: sunos 4.1.4 Makefile and regex.[ch] fix Message-ID: <791BD3CB503DD411A6510008C7CF6477F8C2DA@COL-581-EXS01> Hmmm... I've got at least one box here that has a similar problem (where doing an ls of e.g. /var/log just gets the same non-varying answer) since /var/log/ is a symlink to /u1/newvarlog to make up for a poor choice by a long-ago sysadmin. I'm not sure whether the built-in entropy gathering notices that a particular command is a poor source of entropy. One solution is to have the ls be an "ls -alni /var/log/*" rather than /var/log, since /var/log/* will produce useful output even if /var/log is a symlink. Is there any disadvantage that I'm unaware of to making this change to each of the ls lines in ssh_prng_cmds? Obviously /dev/random is a better thing in general, but... Rip Loomis Voice Number: (410) 953-6874 -------------------------------------------------------- Senior Security Engineer Center for Information Security Technology Science Applications International Corporation http://www.cist.saic.com > -----Original Message----- > From: Ishikawa [mailto:ishikawa at yk.rim.or.jp] > Sent: Thursday, December 07, 2000 11:50 AM [[SNIP]] > At the office, there is an old ss5 box running sunos 4.1.4. > I have configured openssh using gcc on this machine. > > In doing so, I found a few compilation and configuration problems. [[SNIP]] > This may be serious since the problem described here may apply to > wider installation base. > Since SunOS 4.1.4 doesn't have (u)random devices, the sshd and ssh > resort to a shell script installed in /usr/local/etc to > gather entropy for > pseudo random number generation. [[SNIP]] > > Unfortunately, on SunOS, many ls commands in the scripts probably > return the same data (just a symlink name with the same time stamp > over and over. It won't descend into the target directory.) > and won't add to entropy much. > > I wonder if someone can figure out a way to > modify the directory entries in the script so that > the target of the symlinks are placed in the > installed copy instead of the original symlink names. > > I manually modified the script, but wonder if automatic way > is better. Definitely yes, but I am not sure how to go about it. From djm at mindrot.org Fri Dec 8 08:40:13 2000 From: djm at mindrot.org (Damien Miller) Date: Fri, 8 Dec 2000 08:40:13 +1100 (EST) Subject: openssh-SNAP-20001207 scp "Bad file descriptor" sort-of work-around In-Reply-To: <200012072054.NAA03475@amethyst.nurealm.net> Message-ID: On Thu, 7 Dec 2000, James wrote: > Damien wrote: > > > Do you have something in your profile or shell rc which causes text to > > be displayed on non-interactive logins? > > No, but there's part of where the problem is. scp seems to read > /etc/passwd on the _target_ server machine (as well as on the client > machine) to determine the user's default shell on that target > machine, and then invokes a non-login _interactive_ shell, NOT a > non-interactive shell. > > I know this from changing the various scripts and the /etc/passwd > login shell for the user (root). Where man bash has > > My ~/.bashrc normally starts with "source /etc/profile", which > was what actually generated the text, This is your problem here: profile should only be read for interactive sessions - the shell does this automatically for you, you should not source it in bashrc. Your shell initialisation for non-interactive sessions must not produce any output. This requirement isn't unique to scp, all the tools layered on top of rsh have it too. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From carl at bl.echidna.id.au Fri Dec 8 08:44:28 2000 From: carl at bl.echidna.id.au (carl at bl.echidna.id.au) Date: Fri, 8 Dec 2000 08:44:28 +1100 (EST) Subject: openssh-SNAP-20001207 scp "Bad file descriptor" sort-of work-around Message-ID: <200012072144.eB7LiS819524@rollcage.bl.echidna.id.au> > From: Damien Miller > To: james at nurealm.net > Cc: openssh-unix-dev at mindrot.org > > On Thu, 7 Dec 2000, James wrote: > > > Damien wrote: > > > > > Do you have something in your profile or shell rc which causes text to > > > be displayed on non-interactive logins? > > > > No, but there's part of where the problem is. scp seems to read > > /etc/passwd on the _target_ server machine (as well as on the client > > machine) to determine the user's default shell on that target > > machine, and then invokes a non-login _interactive_ shell, NOT a > > non-interactive shell. > > > > I know this from changing the various scripts and the /etc/passwd > > login shell for the user (root). Where man bash has > > > > My ~/.bashrc normally starts with "source /etc/profile", which > > was what actually generated the text, > > This is your problem here: profile should only be read for interactive sessions - the shell does this automatically for you, you should not > source it in bashrc. > > Your shell initialisation for non-interactive sessions must not produce > any output. This requirement isn't unique to scp, all the tools layered > on top of rsh have it too. Which is why any shell rc should check, if you have it set up to do silly things like that :) Example for csh : if ($?USER == 0 || $?prompt == 0) exit From mouring at etoh.eviladmin.org Fri Dec 8 11:52:10 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 7 Dec 2000 18:52:10 -0600 (CST) Subject: Cipher 'none' In-Reply-To: Message-ID: The result of the argument was it would never go into the OpenBSD's tree. However it was suggested a qualify patch could be accepted and put into contrib/ section. - Ben On Thu, 7 Dec 2000, Edward Avis wrote: > yOn Thu, 7 Dec 2000, Rob Hagopian wrote: > > >As I understood it, patches would be considered, but noone has submitted > >one... > > I had hoped to submit a simple one-line patch to reenable the cipher > 'none', but it seems that people wouldn't accept that without extra > safeguards to stop users shooting themselves in the foot. When I > realized that something more complex would be needed, I was scared off. > I might spend some time looking at the ssh source in greater depth and > working out how to enable 'none' only if RSA/DSA authentication is being > used (for example), but I haven't bothered to so far. > > From mouring at etoh.eviladmin.org Fri Dec 8 11:56:03 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 7 Dec 2000 18:56:03 -0600 (CST) Subject: sunos 4.1.4 Makefile and regex.[ch] fix In-Reply-To: <3A2FBFB5.2090105@yk.rim.or.jp> Message-ID: On Fri, 8 Dec 2000, Ishikawa wrote: > Hi, > > At the office, there is an old ss5 box running sunos 4.1.4. > I have configured openssh using gcc on this machine. > > In doing so, I found a few compilation and configuration problems. > > 1. Compilation Problem. > SunOS 4.1.4 doesn't have regex.h header nor the entry points regex.c > is supposed to offer. > We support pcre (POSIX Regular Expression Library) for OS that lack regex, or have a non-POSIX version (Like NeXTStep). The 'INSTALL' file has a URL to where you can pick up the library. - Ben From james at amethyst.nurealm.net Fri Dec 8 14:50:51 2000 From: james at amethyst.nurealm.net (James) Date: Thu, 07 Dec 2000 20:50:51 -0700 Subject: openssh-SNAP-20001207 scp "Bad file descriptor" sort-of work-around Message-ID: <200012080350.UAA03674@amethyst.nurealm.net> Damien wrote: > This is your problem here: profile should only be read for interactive > sessions - the shell does this automatically for you, you should not > source it in bashrc. > > Your shell initialisation for non-interactive sessions must not produce > any output. This requirement isn't unique to scp, all the tools layered on > top of rsh have it too. Ok, I'm having trouble with the language here. You talk about interactive and non-interactive sessions, but there are, in fact, for bash: a) Login-interactive shells b) Non-login-interactive shells c) Non-interactive shells You say "Your shell initialisation for non-interactive sessions must not produce any output." Well, it does not, really, none at all, zip. And still, scp breaks. scp is NOT starting a _non-interactive_ shell. My question was: Is scp _suppose_ to start a _non-interactive_ shell? If so, scp is broken, simple as that. If not, then let's stop talking about _non-interactive_ sessions. I call /etc/profile from ~/.bashrc because I start Non-login-interactive shells on my virtual terminals, and I want the same initialization as for my single Login-interactive shell. Copying the whole /etc/profile into ~/.bashrc seems a silly solution. Now, if scp is NOT suppose to start a _non-interactive_ shell, and, in fact, is supposed to start a non-login _interactive_ shell, then we'll all have to deal with that. Not much point in deciding what to do without knowing if scp is broken, other than to suggest that scp ought to be smart enough to toss a little extraneous text. So, is scp broken, or is it _suppose_ to invoke an _interactive_ session? Again, please Cc me, as I'm not subscribed to the list. Thanks. James Feeney From res at shore.net Fri Dec 8 16:33:53 2000 From: res at shore.net (Richard E. Silverman) Date: Fri, 8 Dec 2000 00:33:53 -0500 (EST) Subject: openssh-SNAP-20001207 scp "Bad file descriptor" sort-of work-around In-Reply-To: <200012080350.UAA03674@amethyst.nurealm.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 7 Dec 2000, James wrote: > Ok, I'm having trouble with the language here. You talk about interactive > and non-interactive sessions, but there are, in fact, for bash: > > a) Login-interactive shells > b) Non-login-interactive shells > c) Non-interactive shells And you're missing one: "non-login-non-interactive." All you're pointing out is that a shell has two binary properties: "login-ness" and "interactive-ness." The usual definitions of these things are reflected in the man page for bash: A login shell is one whose first character of argument zero is a -, or one started with the -login flag. An interactive shell is one whose standard input and out put are both connected to terminals (as determined by isatty(3)), or one started with the -i option. ... Under this definition, scp is indeed starting a non-interactive shell: it runs ssh in a subprocess, to run scp in server mode as a remote command on the other side. SSH does not allocate a pty on the remote side for commands (unless forced to with the -t option). Your shell is run as " -c scp ..." to start the remote scp, and isatty(0) will return false. > You say "Your shell initialisation for non-interactive sessions must not > produce any output." Well, it does not, really, none at all, zip. How have you tested this? > And still, scp breaks. scp is NOT starting a _non-interactive_ shell. What definition of "non-interactive shell" are you using? - -- Richard Silverman slade at shore.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.2 (GNU/Linux) Comment: pgpenvelope 2.8.10 - http://pgpenvelope.sourceforge.net/ iD8DBQE6MHLMRF4zsgDn/HcRAhSSAJ4g8KsrlPZyLi2kheaas1TvJJCZJgCfU2/8 bzsxfjYQxkiBDQcZDxcgDJ0= =F9Sh -----END PGP SIGNATURE----- From bazsi at balabit.hu Sat Dec 9 00:40:13 2000 From: bazsi at balabit.hu (Balazs Scheidler) Date: Fri, 8 Dec 2000 14:40:13 +0100 Subject: [PATCH] tis authserv support In-Reply-To: <20001207133312.A26994@enterprise.isdn.uiuc.edu>; from roth+openssh@feep.net on Thu, Dec 07, 2000 at 01:33:12PM -0600 References: <20001207185732.A1406@balabit.hu> <20001207132033.A26892@enterprise.isdn.uiuc.edu> <20001207133312.A26994@enterprise.isdn.uiuc.edu> Message-ID: <20001208144013.A4796@balabit.hu> > > > Our patch is an alternative to S/Key support in OpenSSH, the two cannot be > > > compiled in at the same time. > > > > I already submitted a patch to do this, but the OpenSSH folks declined > > to include it. I've attached my patch, which I will begin > > distributing from a publicly-accessible website sometime next week. > > > > If there's anything that your patch does that mine does not, please > > feel free to send me the changes. IMHO, it's to everyone's benefit to > > have only a single version of this patch floating around. > > Ugh. It looks like the patch was too big to be sent over the list. > I've put it up at: > > http://www-dev.cso.uiuc.edu/openssh/ > > I'll finish cleaning up the webpage and adding documentation when I > get back from LISA next week. Our patch doesn't link to fwtk's libauth.a, but uses its own implementation of the protocol, and fetches configuration options from sshd_config. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 url: http://www.balabit.hu/pgpkey.txt From james at amethyst.nurealm.net Sat Dec 9 01:30:44 2000 From: james at amethyst.nurealm.net (James) Date: Fri, 08 Dec 2000 07:30:44 -0700 Subject: openssh-SNAP-20001207 scp "Bad file descriptor" sort-of work-around Message-ID: <200012081430.HAA03765@amethyst.nurealm.net> Richard wrote > Under this definition, scp is indeed starting a non-interactive shell: it > runs ssh in a subprocess, to run scp in server mode as a remote command on > the other side. SSH does not allocate a pty on the remote side for > commands (unless forced to with the -t option). Your shell is run as > " -c scp ..." to start the remote scp, and isatty(0) will return > false. Ok, this helps. All I know for sure is that bash-1.14.7(1) is calling ~/.bashrc, since any output from ~/.bashrc is returned to scp. >From the bash man page, the only shell mode from which bash will call ~/.bashrc is from: Non-login interactive shells: On startup (subject to the -norc and -rcfile options): if ~/.bashrc exists, source it. >> You say "Your shell initialisation for non-interactive sessions must not >> produce any output." Well, it does not, really, none at all, zip. > How have you tested this? I have not tested this - I'm making a rash assumption. I had asked earlier "What's the easiest way to invoke a for-sure non-interactive session for testing?", but the distinction is moot until resolving the mode in which bash is running. >> And still, scp breaks. scp is NOT starting a _non-interactive_ shell. > What definition of "non-interactive shell" are you using? Only indirectly, the definition quoted above (and previously) which describes bash's "Non-login interactive shells" and, again indirectly, the definition, also from the man page, of bash's "Non-interactive shells". Non-interactive shells: On startup: if the environment variable ENV is non-null, expand it and source the file it names, as if the command if [ "$ENV" ]; then . $ENV; fi had been executed, but do not use PATH to search for the pathname. When not started in Posix mode, bash looks for BASH_ENV before ENV. I'm assuming that a non-interactive shell is a shell that is not an interactive shell and that the definition of "Non-interactive shells" is exclusive (meaning "does NOT also source ~/.bashrc"). My ENV is empty or unset, and I'm assuming scp does not set ENV or BASH_ENV. If I understand you (and Damien), since the method used to invoke bash is definitely _not_ "one whose standard input and output are both connected to terminals (as determined by isatty(3)), or one started with the -i option", and thereby, also according bash(1), _not_ a method invoking an "interactive shell", therefor, either bash-1.14.7(1) is broken or bash(1) is broken. Does that seem to be a fair interpretation? Again, please Cc me, as I'm not subscribed to the list. Thanks. James Feeney From andreas at schuldei.org Sat Dec 9 01:36:48 2000 From: andreas at schuldei.org (Andreas Schuldei) Date: Fri, 8 Dec 2000 15:36:48 +0100 Subject: opensshd 2.3.0 (oBSD 2.8) ignores ME! Message-ID: <20001208153647.A12114@sigrid.schuldei.com> I have a problem I can not identify. Two firewalls with OpenBSD 2.8 sshd version OpenSSH_2.3.0 I do a ssh root at 195.84.181.91 -v SSH Version OpenSSH_2.3.0, protocol versions 1.5/2.0. Compiled with SSL (0x0090581f). debug: Reading configuration data /etc/ssh_config debug: ssh_connect: getuid 0 geteuid 0 anon 0 debug: Connecting to 195.84.181.91 [195.84.181.91] port 22. debug: Allocated local port 638. debug: connect: Connection timed out debug: Trying again... ... and on the Server side a tcpdump -ni rl0 host 195.84.105.112 and port 22 tcpdump: listening on rl0 09:07:00.534120 195.84.181.90.22 > 195.84.105.112.40066: . ack 3776275139 win 32120 (DF) 09:07:00.574027 195.84.181.90.22 > 195.84.105.112.40066: P 0:44(44) ack 1 win 32120 (DF) ... nothing else, no reply. The firewall rules on the server are pass in quick from any to any pass out quick from any to any The sshd_config is the default one. ssh root at localhost works fine. sshd -d does not show anything (exept the normal waiting..., can not do it from here!) The strange thing is: I can log into the box from other IPs by my own. Please check for yourself if it reacts to other remote OpenBSD Clients. I can not, I have only this one which is ignored. From Markus.Friedl at informatik.uni-erlangen.de Sat Dec 9 03:13:54 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 8 Dec 2000 17:13:54 +0100 Subject: opensshd 2.3.0 (oBSD 2.8) ignores ME! In-Reply-To: <20001208153647.A12114@sigrid.schuldei.com>; from andreas@schuldei.org on Fri, Dec 08, 2000 at 03:36:48PM +0100 References: <20001208153647.A12114@sigrid.schuldei.com> Message-ID: <20001208171354.E10953@faui02.informatik.uni-erlangen.de> does $ ssh -o UsePrivilegedPort=no root at 195.84.181.91 work? On Fri, Dec 08, 2000 at 03:36:48PM +0100, Andreas Schuldei wrote: > I have a problem I can not identify. > Two firewalls with OpenBSD 2.8 > > sshd version OpenSSH_2.3.0 > > I do a > > ssh root at 195.84.181.91 -v > SSH Version OpenSSH_2.3.0, protocol versions 1.5/2.0. > Compiled with SSL (0x0090581f). > debug: Reading configuration data /etc/ssh_config > debug: ssh_connect: getuid 0 geteuid 0 anon 0 > debug: Connecting to 195.84.181.91 [195.84.181.91] port 22. > debug: Allocated local port 638. > debug: connect: Connection timed out > debug: Trying again... > ... > > > and on the Server side a > tcpdump -ni rl0 host 195.84.105.112 and port 22 > tcpdump: listening on rl0 > 09:07:00.534120 195.84.181.90.22 > 195.84.105.112.40066: . ack 3776275139 win 32120 (DF) > 09:07:00.574027 195.84.181.90.22 > 195.84.105.112.40066: P 0:44(44) ack 1 win 32120 (DF) > ... > > nothing else, no reply. > > The firewall rules on the server are > > pass in quick from any to any > pass out quick from any to any > > The sshd_config is the default one. > > ssh root at localhost works fine. > > sshd -d does not show anything (exept the normal waiting..., can not do it > from here!) > > The strange thing is: I can log into the box from other IPs by my own. > > Please check for yourself if it reacts to other remote OpenBSD Clients. I can > not, I have only this one which is ignored. > > > > From andreas at schuldei.org Sat Dec 9 03:29:13 2000 From: andreas at schuldei.org (Andreas Schuldei) Date: Fri, 8 Dec 2000 17:29:13 +0100 Subject: opensshd 2.3.0 (oBSD 2.8) ignores ME! In-Reply-To: <20001208171354.E10953@faui02.informatik.uni-erlangen.de>; from Markus.Friedl@informatik.uni-erlangen.de on Fri, Dec 08, 2000 at 05:13:54PM +0100 References: <20001208153647.A12114@sigrid.schuldei.com> <20001208171354.E10953@faui02.informatik.uni-erlangen.de> Message-ID: <20001208172913.A12551@sigrid.schuldei.com> * Markus Friedl (Markus.Friedl at informatik.uni-erlangen.de) [001208 17:16]: > does > $ ssh -o UsePrivilegedPort=no root at 195.84.181.91 > work? no, th?t does not change anything. Does it work from other OpenBSD 2.8 Boxes? Has anyone tried? Please cc me to andreas at schuldei.org, the mailinglist archive is really slow, it seems. From william.wilson at NAU.EDU Sat Dec 9 03:34:19 2000 From: william.wilson at NAU.EDU (William Wilson) Date: Fri, 08 Dec 2000 09:34:19 -0700 Subject: Slow connects Message-ID: <4.1.20001208093410.00b95270@jan.ucc.nau.edu> I've just installed openssh 2.3.0p1 on a number of Solaris 2.6 boxes. I've noticed that connect times can take up to 3 minutes when connecting from box a to box b with the new ssh client and daemon. When I connect using a pc client like f-secure or with an old ssh client on unix the connect times are wonderfully fast. Any idea why I would get slow connect times with the new client and new daemon? Thanks. ************************************************************************** * William Wilson - Northern AZ Univ * william.wilson at nau.edu *** http://jan.ucc.nau.edu/~wew From roth+openssh at feep.net Sat Dec 9 05:09:28 2000 From: roth+openssh at feep.net (Mark D. Roth) Date: Fri, 8 Dec 2000 12:09:28 -0600 Subject: [PATCH] tis authserv support In-Reply-To: <20001208144013.A4796@balabit.hu>; from bazsi@balabit.hu on Fri, Dec 08, 2000 at 02:40:13PM +0100 References: <20001207185732.A1406@balabit.hu> <20001207132033.A26892@enterprise.isdn.uiuc.edu> <20001207133312.A26994@enterprise.isdn.uiuc.edu> <20001208144013.A4796@balabit.hu> Message-ID: <20001208120928.A28134@enterprise.isdn.uiuc.edu> On Fri Dec 08 14:40 2000 +0100, Balazs Scheidler wrote: > Our patch doesn't link to fwtk's libauth.a, but uses its own implementation > of the protocol, and fetches configuration options from sshd_config. Hrmm. What are the advantages of that setup? I may be missing something, but it seems to me that it would make more sense to use the existing API so that the application is shielded from the protocol details. It also seems preferable to specify the auth servers in TIS's netperm-table file so that you don't have to list the same servers in a different config file for every program which talks to the auth servers. Are there problems with this setup which I'm missing? If so, please let me know. Thanks! (BTW, the patch I posted allows the administrator to choose between S/Key and TIS authentication at run-time. It also supports the sshd_tis.map file for compatibility with the commercial ssh implementation.) -- Mark D. Roth http://www.feep.net/~roth/ From bazsi at balabit.hu Sat Dec 9 05:15:04 2000 From: bazsi at balabit.hu (Balazs Scheidler) Date: Fri, 8 Dec 2000 19:15:04 +0100 Subject: [PATCH] tis authserv support In-Reply-To: <20001208120928.A28134@enterprise.isdn.uiuc.edu>; from roth+openssh@feep.net on Fri, Dec 08, 2000 at 12:09:28PM -0600 References: <20001207185732.A1406@balabit.hu> <20001207132033.A26892@enterprise.isdn.uiuc.edu> <20001207133312.A26994@enterprise.isdn.uiuc.edu> <20001208144013.A4796@balabit.hu> <20001208120928.A28134@enterprise.isdn.uiuc.edu> Message-ID: <20001208191504.A10414@balabit.hu> On Fri, Dec 08, 2000 at 12:09:28PM -0600, Mark D. Roth wrote: > On Fri Dec 08 14:40 2000 +0100, Balazs Scheidler wrote: > > Our patch doesn't link to fwtk's libauth.a, but uses its own implementation > > of the protocol, and fetches configuration options from sshd_config. > > Hrmm. What are the advantages of that setup? I may be missing > something, but it seems to me that it would make more sense to use the > existing API so that the application is shielded from the protocol > details. It also seems preferable to specify the auth servers in > TIS's netperm-table file so that you don't have to list the same > servers in a different config file for every program which talks to > the auth servers. > > Are there problems with this setup which I'm missing? If so, please > let me know. Thanks! What if neither fwtk nor gauntlet is installed on the server? We implemented this patch primarily to allow CryptoCard authentication on servers with sshd running. They were not firewalls, just simple servers. Another reason against fwtk/gauntlet is its license. Our patch is 100% free software, licensed under the BSD license. > (BTW, the patch I posted allows the administrator to choose between > S/Key and TIS authentication at run-time. It also supports the > sshd_tis.map file for compatibility with the commercial ssh > implementation.) Apart from the need of fwtk libraries, I like the features you implemented. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 url: http://www.balabit.hu/pgpkey.txt From james at amethyst.nurealm.net Sat Dec 9 06:06:35 2000 From: james at amethyst.nurealm.net (James) Date: Fri, 08 Dec 2000 12:06:35 -0700 Subject: openssh-SNAP-20001207 scp "Bad file descriptor" sort-of work-around Message-ID: <200012081906.MAA03995@amethyst.nurealm.net> Damien had asked: > What does "ssh localhost true" say? Before, I was getting: # ssh localhost true ssh_exchange_identification: Connection closed by remote host Seems I screwed up my hosts.deny with an extra linefeed. For the record, the actual response should have been: # ssh localhost true Unable to find an authentication method With the syslog Dec 8 12:01:31 amethyst sshd[3985]: connect from local.host Dec 8 12:01:39 amethyst sshd[3985]: Connection closed by 127.0.0.1 Dec 8 12:01:39 amethyst PAM_pwdb[3985]: (sshd) session closed for user james Dec 8 12:01:39 amethyst inetd[130]: pid 3985: exit status 255 Again, please Cc me on any response, as I'm not subscribed to the list. Thanks. James Feeney From roth+openssh at feep.net Sat Dec 9 06:27:18 2000 From: roth+openssh at feep.net (Mark D. Roth) Date: Fri, 8 Dec 2000 13:27:18 -0600 Subject: [PATCH] tis authserv support In-Reply-To: <20001208191504.A10414@balabit.hu>; from bazsi@balabit.hu on Fri, Dec 08, 2000 at 07:15:04PM +0100 References: <20001207185732.A1406@balabit.hu> <20001207132033.A26892@enterprise.isdn.uiuc.edu> <20001207133312.A26994@enterprise.isdn.uiuc.edu> <20001208144013.A4796@balabit.hu> <20001208120928.A28134@enterprise.isdn.uiuc.edu> <20001208191504.A10414@balabit.hu> Message-ID: <20001208132718.A27622@enterprise.isdn.uiuc.edu> On Fri Dec 08 19:15 2000 +0100, Balazs Scheidler wrote: > What if neither fwtk nor gauntlet is installed on the server? We implemented > this patch primarily to allow CryptoCard authentication on servers with > sshd running. They were not firewalls, just simple servers. We do the same thing, but it's not a problem because you can install the netperm-table file without installing the entire fwtk package. > Another reason against fwtk/gauntlet is its license. Our patch is 100% free > software, licensed under the BSD license. If you mean that as a philosophical objection, I can't argue. ;) If you mean it as a legal objection, I'm not sure that there's a problem, since the only folks who would build OpenSSH with TIS auth support are the ones who are already using the TIS authsrv. However, if this would make the patch any more acceptable to the OpenSSH folks, I could incorporate your changes. Unfortunately, I suspect that they still won't be interested. Markus, Ben, et al...? -- Mark D. Roth http://www.feep.net/~roth/ From markus.friedl at informatik.uni-erlangen.de Sat Dec 9 09:58:17 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 8 Dec 2000 23:58:17 +0100 Subject: opensshd 2.3.0 (oBSD 2.8) ignores ME! In-Reply-To: <20001208172913.A12551@sigrid.schuldei.com>; from andreas@schuldei.org on Fri, Dec 08, 2000 at 05:29:13PM +0100 References: <20001208153647.A12114@sigrid.schuldei.com> <20001208171354.E10953@faui02.informatik.uni-erlangen.de> <20001208172913.A12551@sigrid.schuldei.com> Message-ID: <20001208235817.A11097@folly> > Does it work from other OpenBSD 2.8 Boxes? Has anyone tried? openssh is developed on my openbsd 2.8 box. From markus.friedl at informatik.uni-erlangen.de Sat Dec 9 10:00:56 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 9 Dec 2000 00:00:56 +0100 Subject: opensshd 2.3.0 (oBSD 2.8) ignores ME! In-Reply-To: <20001208153647.A12114@sigrid.schuldei.com>; from andreas@schuldei.org on Fri, Dec 08, 2000 at 03:36:48PM +0100 References: <20001208153647.A12114@sigrid.schuldei.com> Message-ID: <20001209000056.B11097@folly> On Fri, Dec 08, 2000 at 03:36:48PM +0100, Andreas Schuldei wrote: > I have a problem I can not identify. > Two firewalls with OpenBSD 2.8 > > sshd version OpenSSH_2.3.0 > > I do a > > ssh root at 195.84.181.91 -v > SSH Version OpenSSH_2.3.0, protocol versions 1.5/2.0. > Compiled with SSL (0x0090581f). > debug: Reading configuration data /etc/ssh_config > debug: ssh_connect: getuid 0 geteuid 0 anon 0 > debug: Connecting to 195.84.181.91 [195.84.181.91] port 22. here i see IP 195.84.181.91 > debug: Allocated local port 638. > debug: connect: Connection timed out > debug: Trying again... > ... > > > and on the Server side a > tcpdump -ni rl0 host 195.84.105.112 and port 22 > tcpdump: listening on rl0 > 09:07:00.534120 195.84.181.90.22 > 195.84.105.112.40066: . ack 3776275139 win 32120 (DF) > 09:07:00.574027 195.84.181.90.22 > 195.84.105.112.40066: P 0:44(44) ack 1 win 32120 (DF) and here it's 195.84.181.90 apart from this i cannot see how your problems are related to openssh. does telnet work? what does telnet server 22 say? does ping work? what does tcpdump on the client say? From karthy at SunSITE.dk Fri Dec 1 23:47:33 2000 From: karthy at SunSITE.dk (Karsten Thygesen) Date: 1 Dec 2000 12:47:33 -0000 Subject: Compile problem and fix Message-ID: <20001201124733.1956.qmail@karthy.net> Hi I use openssh-2.3.0p1 on Solaris-7, KTH-krb4-1.0.3, TransArc-AFS-3.6 # ../openssh-2.3.0p1/configure --prefix=/afs/eos.dk/sw/pack/openssh-2.3.0p1 --with-kerberos4=/afs/eos.dk/sw/pack/krb4-1.0.3 --with-afs --with-ssl-dir=/afs/eos.dk/sw/pack/openssl-0.9.6 To make it compile, I have to add the patch below to make sshconnect1.c line 546 compile. It states: void send_afs_tokens(void) { CREDENTIALS creds; struct ViceIoctl parms; struct ClearToken ct; int i, type, len, plen; char buf[2048], *p, *server_cell; char buffer[8192]; /* Move over ktc_GetToken, here's something leaner. */ for (i = 0; i < 100; i++) { /* just in case */ parms.in = (char *) &i; parms.in_size = sizeof(i); parms.out = buf; parms.out_size = sizeof(buf); ---> if (k_pioctl(0, VIOCGETTOK, &parms, 0) != 0) break; p = buf; The ViceIoctl is defined in transarc's AFS headers, but we need a few include files to make it complete: ====================================================================== *** sshconnect1.c~ Tue May 9 03:03:03 2000 --- sshconnect1.c Wed May 10 16:38:51 2000 *************** *** 16,21 **** --- 16,24 ---- #include #include + #include + #include + #include "xmalloc.h" #include "rsa.h" #include "ssh.h" ====================================================================== Karsten From subdude at post.com Fri Dec 1 03:09:42 2000 From: subdude at post.com (Brian) Date: Thu, 30 Nov 2000 08:09:42 -0800 Subject: 2.3.0pl1 on Linux Message-ID: <000101c05ae7$f3eb4040$0201a8c0@bango.english-bay.com> Hi: Downloaded, built and installed 2.3.0pl1 for Linux. Followed instructions but unfortunately the final configuration didn't go well. Problem: The instructions for key generation bare no resemblance to what the current man pages require. Quite frankly I am new to this and am quite confused. " make host-key " doesn't work. " ssh-keygen -b 1024 -f /etc/ssh/ssh_host_key -N "" " doesn't work. " ssh-keygen -d -f /etc/ssh/ssh_host_dsa_key -N "" " doesn't work. "Server failed host key check" is a common occurrence when attempting to login with puTTY - at other times it appears to work. I am removing openssh for the time being and installing ssh-2.3.0 - I really require ssh running now. Best regards, Brian From lupe at lupe-christoph.de Fri Dec 1 20:35:52 2000 From: lupe at lupe-christoph.de (Lupe Christoph) Date: Fri, 1 Dec 2000 10:35:52 +0100 Subject: Autoconfigure miss on Solaris 8 x86 (2.3.0p1) Message-ID: <20001201103552.A20024@alanya.lupe-christoph.de> Your configure checks for u_int*_t in and checks for them in only together with int*_t. I have BIND 8.2.2-P5, and use it's include files with OpenSSH. BIND's bitypes.h defines only the unsigned types, so the second test fails, and then the first compilation during 'make' fails because of a redefinition of u_int*_t. I'd recommend to separate the tests for the signed and the unsigned types. Thanks for the great package! Lupe Christoph -- | lupe at lupe-christoph.de | http://free.prohosting.com/~lupe | | "jryy vg ybbxf yvxr gur l2x oht qvqa'g erne vg'f htyl urnq." "lrc. gur | | qbbzfnlref unir orra cebira jebat lrg ntnva." .... "qvq lbh frr gung | | gbb?" "ubhfgba. jr unir n ceboyrz." User Friendly 2000-01-01 | From william.wilson at NAU.EDU Sat Dec 9 03:32:07 2000 From: william.wilson at NAU.EDU (William Wilson) Date: Fri, 08 Dec 2000 09:32:07 -0700 Subject: Slow connects In-Reply-To: <20001208171354.E10953@faui02.informatik.uni-erlangen.de> References: <20001208153647.A12114@sigrid.schuldei.com> <20001208153647.A12114@sigrid.schuldei.com> Message-ID: <4.1.20001208093008.00b9d1b0@jan.ucc.nau.edu> I've just installed openssh 2.3.0p1 on a number of Solaris 2.6 boxes. I've noticed that connect times can take up to 3 minutes when connecting from box a to box b with the new ssh client and daemon. When I connect using a pc client like f-secure or with an old ssh client on unix the connect times are wonderfully fast. Any idea why I would get slow connect times with the new client and new daemon? Thanks. ************************************************************************** * William Wilson - Northern AZ Univ * william.wilson at nau.edu *** http://jan.ucc.nau.edu/~wew From james at amethyst.nurealm.net Sat Dec 9 15:11:58 2000 From: james at amethyst.nurealm.net (James) Date: Fri, 08 Dec 2000 21:11:58 -0700 Subject: openssh-SNAP-20001207 scp "Bad file descriptor" sort-of work-around Message-ID: <200012090411.VAA08671@amethyst.nurealm.net> Ok, I'm starting to get a handle. Damien had asked: > What does "ssh localhost true" say? Finally, I went back and cleaned up ~/.ssh/config and ~/.ssh/authorized_keys2. So now that "ssh localhost" actually works, I get: $ ssh localhost true Enter passphrase for key '/home/james/.ssh/id_dsa_jkey': sourcing /etc/profile... Running Linux 2.2.16-3. Fri Dec 8 16:36:21 MST 2000 not a tty select: Bad file descriptor (You can see the output of my "tty" command there.) Now, I tried using Bash 2.03.8(1)-release from RedHat 6.2 and noted that it acts the same as Bash 1.14.7(1). I then downloaded Bash 2.04 and read the man page. Very interesting: INVOCATION . . . Bash attempts to determine when it is being run by the remote shell daemon, usually rshd. If bash determines it is being run by rshd, it reads and executes commands from ~/.bashrc, if that file exists and is readable. It will not do this if invoked as sh. The --norc option may be used to inhibit this behavior, and the --rcfile option may be used to force another file to be read, but rshd does not generally invoke the shell with those options or allow them to be specified. Ugh! I'd think bash should read different startup files when invoked by a remote shell daemon and when invoked as a non interactive shell. Is sending random text to a remote shell daemon really such a bad thing that ssh and scp couldn't be made to simply pass through the text? Again, please Cc me on any response, as I'm not subscribed to the list. Thanks. James Feeney From res at shore.net Sat Dec 9 15:55:31 2000 From: res at shore.net (Richard E. Silverman) Date: Fri, 8 Dec 2000 23:55:31 -0500 (EST) Subject: openssh-SNAP-20001207 scp "Bad file descriptor" sort-of work-around In-Reply-To: <200012090411.VAA08671@amethyst.nurealm.net> Message-ID: On Fri, 8 Dec 2000, James wrote: > Ugh! I'd think bash should read different startup files when invoked by a > remote shell daemon and when invoked as a non interactive shell. How would you suggest it tell the difference? > Is sending random text to a remote shell daemon really such a bad thing > that ssh and scp couldn't be made to simply pass through the text? The issue is that if you do "ssh/rsh/whatever host command", you expect to see only the output from the command on stdout. Greetings, motd files, etc. are only appropriate for an interactive session, where there's a human on the other side to interpret them. A non-interactive session is probably one program talking to another, and the random text simply screws up whatever protocol they're speaking. It's more reasonable to expect a transparent, unpolluted connection, than to expect that every pair of programs you might want to connect together using SSH must try to heuristically filter out stuff that "looks like unwanted text" from their conversation. -- Richard Silverman slade at shore.net From res at shore.net Sat Dec 9 16:06:25 2000 From: res at shore.net (Richard E. Silverman) Date: Sat, 9 Dec 2000 00:06:25 -0500 (EST) Subject: 2.3.0pl1 on Linux In-Reply-To: <000101c05ae7$f3eb4040$0201a8c0@bango.english-bay.com> Message-ID: OpenSSH builds and works perfectly under Linux for quite a few people (including me). It would be more helpful if you would provide the version of Linux you're using and the platform. Also, the details of what goes wrong, instead of just "it doesn't work," are necessary to give any kind of response. It is not normally necessary to manually install generate the host key; "make install" does it if there is not already one installed. In fact, the fact that you can connect with PuTTY at all implies that you *do* have a host key, since sshd would not even run without one. Are you perhaps thinking that your host key is missing because of the message about "failing the host key check?" That doesn't mean the host key is missing; it means that the host key you have recorded on the PuTTY client machine does not match the one being used by the SSH server. That would happen if you connected once, then used any of the commands you quoted to generate a new host key, restarted sshd, and connected again. -- Richard Silverman slade at shore.net From bazsi at balabit.hu Sat Dec 9 05:15:04 2000 From: bazsi at balabit.hu (Balazs Scheidler) Date: Fri, 8 Dec 2000 19:15:04 +0100 Subject: [PATCH] tis authserv support In-Reply-To: <20001208120928.A28134@enterprise.isdn.uiuc.edu>; from roth+openssh@feep.net on Fri, Dec 08, 2000 at 12:09:28PM -0600 References: <20001207185732.A1406@balabit.hu> <20001207132033.A26892@enterprise.isdn.uiuc.edu> <20001207133312.A26994@enterprise.isdn.uiuc.edu> <20001208144013.A4796@balabit.hu> <20001208120928.A28134@enterprise.isdn.uiuc.edu> Message-ID: <20001208191504.A10414@balabit.hu> On Fri, Dec 08, 2000 at 12:09:28PM -0600, Mark D. Roth wrote: > On Fri Dec 08 14:40 2000 +0100, Balazs Scheidler wrote: > > Our patch doesn't link to fwtk's libauth.a, but uses its own implementation > > of the protocol, and fetches configuration options from sshd_config. > > Hrmm. What are the advantages of that setup? I may be missing > something, but it seems to me that it would make more sense to use the > existing API so that the application is shielded from the protocol > details. It also seems preferable to specify the auth servers in > TIS's netperm-table file so that you don't have to list the same > servers in a different config file for every program which talks to > the auth servers. > > Are there problems with this setup which I'm missing? If so, please > let me know. Thanks! What if neither fwtk nor gauntlet is installed on the server? We implemented this patch primarily to allow CryptoCard authentication on servers with sshd running. They were not firewalls, just simple servers. Another reason against fwtk/gauntlet is its license. Our patch is 100% free software, licensed under the BSD license. > (BTW, the patch I posted allows the administrator to choose between > S/Key and TIS authentication at run-time. It also supports the > sshd_tis.map file for compatibility with the commercial ssh > implementation.) Apart from the need of fwtk libraries, I like the features you implemented. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 url: http://www.balabit.hu/pgpkey.txt From james at amethyst.nurealm.net Sun Dec 10 05:17:28 2000 From: james at amethyst.nurealm.net (James) Date: Sat, 09 Dec 2000 11:17:28 -0700 Subject: openssh-SNAP-20001207 scp "Bad file descriptor" sort-of work-around Message-ID: <200012091817.LAA00572@amethyst.nurealm.net> On Fri, 8 Dec 2000, Richard wrote: >> Ugh! I'd think bash should read different startup files when invoked by a >> remote shell daemon and when invoked as a non interactive shell. > How would you suggest it tell the difference? As I understand, bash already can tell the difference - that's why BASH(1) says: Bash attempts to determine when it is being run by the remote shell daemon, usually rshd. That's part of the reason I had a problem with scp to start with. bash-2.04/shell.c has: --- /* The name of the .(shell)rc file. */ static char *bashrc_file = "~/.bashrc"; --- /* Execute ~/.bashrc for most shells. Never execute it if ACT_LIKE_SH is set, or if NO_RC is set. If the executable file "/usr/gnu/src/bash/foo" contains: #!/usr/gnu/bin/bash echo hello then: COMMAND EXECUTE BASHRC -------------------------------- bash -c foo NO bash foo NO foo NO rsh machine ls YES (for rsh, which calls `bash -c') rsh machine foo YES (for shell started by rsh) NO (for foo!) echo ls | bash NO login NO bash YES */ --- static void run_startup_files () { #if defined (JOB_CONTROL) int old_job_control; #endif int sourced_login, run_by_ssh; /* get the rshd/sshd case out of the way first. */ if (interactive_shell == 0 && no_rc == 0 && login_shell == 0 && act_like_sh == 0 && local_pending_command) { run_by_ssh = find_variable ("SSH_CLIENT") != (SHELL_VAR *)0; run_by_ssh |= find_variable ("SSH2_CLIENT") != (SHELL_VAR *)0; /* If we were run by sshd or we think we were run by rshd, execute ~/.bashrc if we are a top-level shell. */ if ((run_by_ssh || isnetconn (fileno (stdin))) && shell_level < 2) { #ifdef SYS_BASHRC # if defined (__OPENNT) maybe_execute_file (_prefixInstallPath(SYS_BASHRC, NULL, 0), 1); # else maybe_execute_file (SYS_BASHRC, 1); # endif #endif maybe_execute_file (bashrc_file, 1); return; } } I suppose the trick is to simply replace maybe_execute_file (bashrc_file, 1); with something like maybe_execute_file ("~/.bash_rsh", 1); > A non-interactive session is probably one program talking to another, and > the random text simply screws up whatever protocol they're speaking. It's > more reasonable to expect a transparent, unpolluted connection, than to > expect that every pair of programs you might want to connect together > using SSH must try to heuristically filter out stuff that "looks like > unwanted text" from their conversation. I can see your point. Still, I'm not suggesting a need for any kind of heuristic filter. Rather, I don't see any need for scp, in particular, to be either the enforcer or the victim of a policy expecting a transparent, unpolluted connection. scp is simply not being "robust" here. There doesn't seem to be any _need_ to have scp fail crypticly. Though I think bash needs to distinguish between "rshd" and "non-interactive" startup files, I also think robust behavior for scp would be to simply display or trash, depending on the terminal status, any inconsequential returned text. (Remember that fierce "suicide squad" at the end of "Life of Brian"? scp doesn't _need_ to be a member of the "suicide squad", does it?) Again, please Cc me on any response, as I'm not subscribed to the list. Thanks. James Feeney From a.piesk at gmx.net Sun Dec 10 09:54:51 2000 From: a.piesk at gmx.net (Andreas Piesk) Date: Sat, 09 Dec 2000 23:54:51 +0100 Subject: minor problem with openssh and man Message-ID: <200012092350.eB9Noxb16242@cvs.openbsd.org> hiho, there's a minor problem with openssh and man. here's a log: [root at server /root]# man gunzip: stdout: Broken pipe gunzip: stdout: Broken pipe ... grotty::13442:fatal error: output error [root at server /root]# the manpage itself is correct. i'm using: redhat 6.2 man-1.5h1 openssh-2.3.0p1 before openssh i used ssh2-2.3.0 without having this little problem. i tried openssh with and without pty terms. i've got the same results. ciao -ap Andreas Piesk a.piesk at gmx.net PGP: 23CB A7E2 2E53 373C DBCD 8EFC 7777 61C1 From pekkas at netcore.fi Mon Dec 11 08:39:31 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 10 Dec 2000 23:39:31 +0200 (EET) Subject: snapshot: ssh-keyscan problems Message-ID: Hello all, Tested the latest snapshot. ssh-keyscan seems to have gone in. :) Two issues about it (patched): 1) the man pages aren't installed, only uninstalled 2) RH spec file (and the others no doubt..) won't include it. General observations: for RSA keys only?, kinda obsoletes contrib/make-ssh-known-hosts*. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------- next part -------------- --- Makefile.in~ Tue Dec 5 03:15:10 2000 +++ Makefile.in Sun Dec 10 22:39:50 2000 @@ -157,6 +157,7 @@ $(INSTALL) -m 644 ssh-add.[01].out $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-add.1 $(INSTALL) -m 644 ssh-agent.[01].out $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-agent.1 $(INSTALL) -m 644 ssh-keygen.[01].out $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-keygen.1 + $(INSTALL) -m 644 ssh-keyscan.[01].out $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-keyscan.1 $(INSTALL) -m 644 sshd.[08].out $(DESTDIR)$(mandir)/$(mansubdir)8/sshd.8 $(INSTALL) -m 644 sftp-server.[08].out $(DESTDIR)$(mandir)/$(mansubdir)8/sftp-server.8 -rm -f $(DESTDIR)$(bindir)/slogin -------------- next part -------------- --- openssh.spec- Sun Dec 10 23:25:05 2000 +++ openssh.spec Sun Dec 10 23:24:50 2000 @@ -212,7 +212,9 @@ %doc CREDITS LICENCE %attr(0755,root,root) %{_bindir}/ssh-keygen %attr(0755,root,root) %{_bindir}/scp +%attr(0755,root,root) %{_bindir}/ssh-keyscan %attr(0644,root,root) %{_mandir}/man1/ssh-keygen.1* +%attr(0644,root,root) %{_mandir}/man1/ssh-keyscan.1* %attr(0644,root,root) %{_mandir}/man1/scp.1* %attr(0755,root,root) %dir %{_sysconfdir} %attr(0600,root,root) %config(noreplace) %{_sysconfdir}/primes From mouring at etoh.eviladmin.org Mon Dec 11 10:10:38 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 10 Dec 2000 17:10:38 -0600 (CST) Subject: snapshot: ssh-keyscan problems In-Reply-To: Message-ID: On Sun, 10 Dec 2000, Pekka Savola wrote: > Hello all, > > Tested the latest snapshot. ssh-keyscan seems to have gone in. :) > > Two issues about it (patched): > 1) the man pages aren't installed, only uninstalled Thanks. I missed that when I merged ssh-keyscan in. Applied. > 2) RH spec file (and the others no doubt..) won't include it. > Applied. - Ben From markus.friedl at informatik.uni-erlangen.de Mon Dec 11 09:40:56 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sun, 10 Dec 2000 23:40:56 +0100 Subject: snapshot: ssh-keyscan problems In-Reply-To: ; from pekkas@netcore.fi on Sun, Dec 10, 2000 at 11:39:31PM +0200 References: Message-ID: <20001210234056.A15858@folly> > General observations: for RSA keys only? yes, only for ssh-1, feel free to update for SSH-2 :) From rob at hagopian.net Mon Dec 11 10:36:05 2000 From: rob at hagopian.net (Rob Hagopian) Date: Sun, 10 Dec 2000 18:36:05 -0500 (EST) Subject: openssh-SNAP-20001207 scp "Bad file descriptor" sort-of work-around In-Reply-To: Message-ID: Is it really that tough? One algorighm I can think of off the top of my head is to keep pulling lines of text from the client until it finds a line containing only an scp "magic cookie". From there negotiations continue as expected. In fact, sendmail works somewhat like this, you can connect to port 25, type whatever you want, and sendmail will ignore most all of this until it gets a HELO line... Of course, the existing protocol specs may not allow for something like this (?)... -Rob On Fri, 8 Dec 2000, Richard E. Silverman wrote: > On Fri, 8 Dec 2000, James wrote: > > > Ugh! I'd think bash should read different startup files when invoked by a > > remote shell daemon and when invoked as a non interactive shell. > > How would you suggest it tell the difference? > > > Is sending random text to a remote shell daemon really such a bad thing > > that ssh and scp couldn't be made to simply pass through the text? > > The issue is that if you do "ssh/rsh/whatever host command", you expect to > see only the output from the command on stdout. Greetings, motd files, > etc. are only appropriate for an interactive session, where there's a > human on the other side to interpret them. A non-interactive session is > probably one program talking to another, and the random text simply screws > up whatever protocol they're speaking. It's more reasonable to expect a > transparent, unpolluted connection, than to expect that every pair of > programs you might want to connect together using SSH must try to > heuristically filter out stuff that "looks like unwanted text" from their > conversation. > > From andreas at schuldei.org Mon Dec 11 10:48:16 2000 From: andreas at schuldei.org (Andreas Schuldei) Date: Mon, 11 Dec 2000 00:48:16 +0100 Subject: opensshd 2.3.0 (oBSD 2.8) ignores ME! In-Reply-To: <20001209131323.A1279@folly>; from markus.friedl@informatik.uni-erlangen.de on Sat, Dec 09, 2000 at 01:13:24PM +0100 References: <20001208153647.A12114@sigrid.schuldei.com> <20001209000056.B11097@folly> <20001209081159.A13818@sigrid.schuldei.com> <20001209131323.A1279@folly> Message-ID: <20001211004816.A17279@sigrid.schuldei.com> * Markus Friedl (markus.friedl at informatik.uni-erlangen.de) [001209 13:16]: > and all other connections between the 2 machines work fine? > ping? telnet? portscan? I traced the problem back to some kernel bug that is triggered by isakmpd when switching to encrypted traffic. I could reset isakmpd to allow traffic again but not ssh. I am not sure niklas at openbsd.org, whom I contacted about this has solved it allready, but Angelos suggested that the problem was known/solved. it seems to be a kernelbug. bummer. From engert at isg.de Mon Dec 11 12:15:04 2000 From: engert at isg.de (Kai Engert) Date: Mon, 11 Dec 2000 02:15:04 +0100 Subject: Point in usernames / scp Message-ID: <3A342A98.27447416@isg.de> Hi, we are using usernames on our systems that contain a point '.', like "r.john". We found it necessary to patch the source to make the "scp" command work with those usernames. Cheers Kai --- openssh-2.2.0p1/scp.c Wed Aug 30 01:11:30 2000 +++ withpoint/scp.c Mon Dec 11 02:06:35 2000 @@ -1042,7 +1042,7 @@ c = *cp; if (c & 0200) goto bad; - if (!isalpha(c) && !isdigit(c) && c != '_' && c != '-') + if (!isalpha(c) && !isdigit(c) && c != '_' && c != '-' && c != '.') goto bad; } while (*++cp); return (1); From mouring at etoh.eviladmin.org Mon Dec 11 14:09:53 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 10 Dec 2000 21:09:53 -0600 (CST) Subject: snapshot: ssh-keyscan problems In-Reply-To: <20001210234056.A15858@folly> Message-ID: On Sun, 10 Dec 2000, Markus Friedl wrote: > > General observations: for RSA keys only? > > yes, only for ssh-1, feel free to update for SSH-2 :) > How does this patch stack up against what you want for added feature to ssh-keyscan? I'm not promising it's pretty, but it does not job and I can't find where it breaks as of yet. =) - Ben --- ../openssh/ssh-keyscan.c Wed Dec 6 16:47:55 2000 +++ ssh-keyscan.c Sun Dec 10 21:07:36 2000 @@ -27,8 +27,6 @@ #include "buffer.h" #include "bufaux.h" -static int argno = 1; /* Number of argument currently being parsed */ - int family = AF_UNSPEC; /* IPv4, IPv6 or both */ #define PORT 22 @@ -86,6 +84,12 @@ void (*errfun) (const char *,...); } Linebuf; +struct { + int dsa; + int rsa; + int rsa1; +} keylists = { 0, 0, 0 }; + static inline Linebuf * Linebuf_alloc(const char *filename, void (*errfun) (const char *,...)) { @@ -241,15 +245,15 @@ } void -keyprint(char *host, char *output_name, char *kd, int len) +keyprint(int key,char *host, char *output_name, char *kd, int len) { - static Key *rsa; + static Key *k; static Buffer msg; - if (rsa == NULL) { + if (k == NULL) { buffer_init(&msg); - rsa = key_new(KEY_RSA1); } + k = key_new(key); buffer_append(&msg, kd, len); buffer_consume(&msg, 8 - (len & 7)); /* padding */ if (buffer_get_char(&msg) != (int) SSH_SMSG_PUBLIC_KEY) { @@ -261,17 +265,27 @@ /* server key */ (void) buffer_get_int(&msg); - buffer_get_bignum(&msg, rsa->rsa->e); - buffer_get_bignum(&msg, rsa->rsa->n); + if (key == KEY_DSA) { + buffer_get_bignum(&msg, k->dsa->p); + buffer_get_bignum(&msg, k->dsa->q); + } else { + buffer_get_bignum(&msg, k->rsa->e); + buffer_get_bignum(&msg, k->rsa->n); + } /* host key */ (void) buffer_get_int(&msg); - buffer_get_bignum(&msg, rsa->rsa->e); - buffer_get_bignum(&msg, rsa->rsa->n); + if (key == KEY_DSA) { + buffer_get_bignum(&msg, k->dsa->p); + buffer_get_bignum(&msg, k->dsa->q); + } else { + buffer_get_bignum(&msg, k->rsa->e); + buffer_get_bignum(&msg, k->rsa->n); + } buffer_clear(&msg); fprintf(stdout, "%s ", output_name ? output_name : host); - key_write(rsa, stdout); + key_write(k, stdout); fputs("\n", stdout); } @@ -446,7 +460,12 @@ c->c_status = CS_KEYS; break; case CS_KEYS: - keyprint(c->c_name, c->c_output_name, c->c_data, c->c_plen); + if (keylists.rsa1) + keyprint(KEY_RSA1,c->c_name, c->c_output_name, c->c_data, c->c_plen); + if (keylists.rsa) + keyprint(KEY_RSA,c->c_name, c->c_output_name, c->c_data, c->c_plen); + if (keylists.dsa) + keyprint(KEY_DSA,c->c_name, c->c_output_name, c->c_data, c->c_plen); confree(s); return; break; @@ -501,50 +520,10 @@ } } -char * -nexthost(int argc, char **argv) -{ - static Linebuf *lb; - - for (;;) { - if (!lb) { - if (argno >= argc) - return (NULL); - if (argv[argno][0] != '-') - return (argv[argno++]); - if (!strcmp(argv[argno], "--")) { - if (++argno >= argc) - return (NULL); - return (argv[argno++]); - } else if (!strncmp(argv[argno], "-f", 2)) { - char *fname; - if (argv[argno][2]) - fname = &argv[argno++][2]; - else if (++argno >= argc) { - error("missing filename for `-f'"); - return (NULL); - } else - fname = argv[argno++]; - if (!strcmp(fname, "-")) - fname = NULL; - lb = Linebuf_alloc(fname, error); - } else - error("ignoring invalid/misplaced option `%s'", argv[argno++]); - } else { - char *line; - line = getline(lb); - if (line) - return (line); - Linebuf_free(lb); - lb = NULL; - } - } -} - static void usage(void) { - fatal("usage: %s [-t timeout] { [--] host | -f file } ...\n", prog); + fatal("usage: %s [-1RD] [-t timeout] { [--] host | -f file } ...\n", prog); return; } @@ -552,6 +531,10 @@ main(int argc, char **argv) { char *host = NULL; + char ch; + int defaultkey = 1; + Linebuf *lb = NULL; + extern int optind; TAILQ_INIT(&tq); @@ -560,24 +543,35 @@ else prog = argv[0]; - if (argc <= argno) - usage(); - - if (argv[1][0] == '-' && argv[1][1] == 't') { - argno++; - if (argv[1][2]) - timeout = atoi(&argv[1][2]); - else { - if (argno >= argc) + while ((ch = getopt(argc,argv,"t:f:1DR")) != EOF) + switch(ch) { + case 't': + timeout = atoi(optarg); + break; + case 'f': + lb = Linebuf_alloc(optarg, error); + break; + case '1': + keylists.rsa1=1; + defaultkey=0; + break; + case 'D': + keylists.dsa=1; + defaultkey=0; + break; + case 'R': + keylists.rsa=1; + defaultkey=0; + break; + default: usage(); - timeout = atoi(argv[argno++]); } - if (timeout <= 0) - usage(); - } - if (argc <= argno) - usage(); + argc -= optind; + argv += optind; + if (defaultkey) + keylists.rsa1=1; + maxfd = fdlim_get(1); if (maxfd < 0) fatal("%s: fdlim_get: bad value\n", prog); @@ -593,7 +587,17 @@ while (ncon < maxcon) { char *name; - host = nexthost(argc, argv); + if (!lb) { + host = argv[0]; + argv++; + } else { + host = getline(lb); + if (host == NULL) { + Linebuf_free(lb); + lb = NULL; + } + } + if (host == NULL) break; name = strnnsep(&host, " \t\n"); From mouring at etoh.eviladmin.org Mon Dec 11 15:32:44 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 10 Dec 2000 22:32:44 -0600 (CST) Subject: snapshot: ssh-keyscan problems In-Reply-To: Message-ID: On Sun, 10 Dec 2000 mouring at etoh.eviladmin.org wrote: > On Sun, 10 Dec 2000, Markus Friedl wrote: > > > > General observations: for RSA keys only? > > > > yes, only for ssh-1, feel free to update for SSH-2 :) > > > How does this patch stack up against what you want for added feature > to ssh-keyscan? > > I'm not promising it's pretty, but it does not job and I can't find > where it breaks as of yet. =) > Ermm..I take that back.. I find a few places where it does not act like the original program. One being that it does not support multiple -f. - Ben From Stephan.Hendl at lds.brandenburg.de Mon Dec 11 17:34:23 2000 From: Stephan.Hendl at lds.brandenburg.de (Stephan Hendl) Date: Mon, 11 Dec 2000 07:34:23 +0100 Subject: Antw: problem with installing openssh on HP/UX Message-ID: Hi, > acro-284> uname -a > HP-UX niit1 A.09.01 A 9000/730 2015353714 two-user license I don't know what "niit1" stand for. We use openssh on several HP 9000/800 series (HP-UX 10.20, 11.00) compiled with gcc-2.95.2 and did not run into problems with the latest portable openssh version and the pam-patch provides earlier in this list. Stephan -- LDS Brandenburg Dr. Stephan Hendl fon: +49-(0)331-39 471 fax: +49-(0)331-27548 1187 EMail: stephan.hendl at lds.brandenburg.de From Markus.Friedl at informatik.uni-erlangen.de Mon Dec 11 19:01:13 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 11 Dec 2000 09:01:13 +0100 Subject: snapshot: ssh-keyscan problems In-Reply-To: ; from mouring@etoh.eviladmin.org on Sun, Dec 10, 2000 at 09:09:53PM -0600 References: <20001210234056.A15858@folly> Message-ID: <20001211090113.A9777@faui02.informatik.uni-erlangen.de> On Sun, Dec 10, 2000 at 09:09:53PM -0600, mouring at etoh.eviladmin.org wrote: > On Sun, 10 Dec 2000, Markus Friedl wrote: > > > > General observations: for RSA keys only? > > > > yes, only for ssh-1, feel free to update for SSH-2 :) > > > How does this patch stack up against what you want for added feature > to ssh-keyscan? > > I'm not promising it's pretty, but it does not job and I can't find > where it breaks as of yet. =) your patch tries to get DSA keys from a SSH-1 server. won't work. the protocols and encodings are too different. From mouring at etoh.eviladmin.org Mon Dec 11 16:35:14 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 10 Dec 2000 23:35:14 -0600 (CST) Subject: snapshot: ssh-keyscan problems In-Reply-To: Message-ID: Umm.. Nevermind. I'm missing code to put it into protocol v2 mode.=) - Ben From djm at mindrot.org Mon Dec 11 21:16:39 2000 From: djm at mindrot.org (Damien Miller) Date: Mon, 11 Dec 2000 21:16:39 +1100 (EST) Subject: Test - please ignore Message-ID: Please ignore -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From Florian.Weimer at RUS.Uni-Stuttgart.DE Tue Dec 12 02:29:39 2000 From: Florian.Weimer at RUS.Uni-Stuttgart.DE (Florian Weimer) Date: 11 Dec 2000 16:29:39 +0100 Subject: Point in usernames / scp In-Reply-To: <3A342A98.27447416@isg.de> References: <3A342A98.27447416@isg.de> Message-ID: Kai Engert writes: > - if (!isalpha(c) && !isdigit(c) && c != '_' && c != '-') > + if (!isalpha(c) && !isdigit(c) && c != '_' && c != '-' && c != '.') If you are at it, you couuld also include '+' here. -- Florian Weimer Florian.Weimer at RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From stevesk at pobox.com Tue Dec 12 06:53:36 2000 From: stevesk at pobox.com (Kevin Steves) Date: Mon, 11 Dec 2000 20:53:36 +0100 (CET) Subject: Antw: problem with installing openssh on HP/UX In-Reply-To: Message-ID: : > acro-284> uname -a : > HP-UX niit1 A.09.01 A 9000/730 2015353714 two-user license We don't support 9.X because it's obsolete. : I don't know what "niit1" stand for. We use openssh on several HP : 9000/800 series (HP-UX 10.20, 11.00) compiled with gcc-2.95.2 and : did not run into problems with the latest portable openssh version : and the pam-patch provides earlier in this list. 10.20 and 11.0 are supported (11.11 should be ok as well). From mouring at etoh.eviladmin.org Tue Dec 12 09:35:12 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 11 Dec 2000 16:35:12 -0600 (CST) Subject: Antw: problem with installing openssh on HP/UX In-Reply-To: Message-ID: On Mon, 11 Dec 2000, Kevin Steves wrote: > : > acro-284> uname -a > : > HP-UX niit1 A.09.01 A 9000/730 2015353714 two-user license > > We don't support 9.X because it's obsolete. > Don't say that too loudly or you'd have a point to throw out the NeXT support. =) - Ben From chans at goldencasket.com Tue Dec 12 17:28:27 2000 From: chans at goldencasket.com (Stanley Chan) Date: Tue, 12 Dec 2000 16:28:27 +1000 Subject: Openssh Message-ID: <575465686330D411860800D0B73FE7E4122DB0@gcpesv0.gcau.com.au> Hi There I downloaded a copy of already compiled version of Openssh for Solaris 8 from sunfreeware.com and had some problem of trying to start it. No matter which program I tried to start e.g. ssh, sshd, ssh-agent, ssh-keygen etc etc. It always come back with an error message "PRNG initialisation failed -- exiting." My system is SUN E3500 with Solaris 8 10/00. Can anyone suggest a solution ??? Please email me as I have no access to the mail group. ---- Stanley Chan Principal System Administrator Ph 617-38771016 Fax 617-38771120 E-Mail chans at goldencasket.com Snail Golden Casket Lottery Corp. 87 Ipswich Rd. Woolloongabba Brisbane, Qld. Australia 4102 PLEASE NOTE If you are not the intended recipient of this communication please destroy all copies and telephone Golden Casket Lottery Corporation Limited on +61 7 3877 1300 immediately. No authority is given to copy, disclose or distribute this communication unless confirmed in writing. Any personal opinion expressed in this communication is that of the individual sender. From res at shore.net Tue Dec 12 17:38:40 2000 From: res at shore.net (Richard E. Silverman) Date: Tue, 12 Dec 2000 01:38:40 -0500 (EST) Subject: Openssh In-Reply-To: <575465686330D411860800D0B73FE7E4122DB0@gcpesv0.gcau.com.au> Message-ID: On Tue, 12 Dec 2000, Stanley Chan wrote: > Hi There > I downloaded a copy of already compiled version of Openssh for > Solaris 8 from sunfreeware.com and had some problem of trying to start it. > No matter which program I tried to start e.g. ssh, sshd, ssh-agent, > ssh-keygen etc etc. It always come back with an error message > "PRNG initialisation failed -- exiting." Your pre-compiled version was probably missing the file /etc/ssh_prng_cmds. Grab a copy of the source and get it from there, or just compile and install from source entirely. -- Richard Silverman slade at shore.net From openssh-contact at citecs.de Wed Dec 13 02:25:00 2000 From: openssh-contact at citecs.de (Christian Recktenwald) Date: Tue, 12 Dec 2000 16:25:00 +0100 Subject: openssh 2.3.0p1 crashes Message-ID: <20001212162500.A27640@MrFabulous.citecs> System: RedHat 7.0, Kernel 2.2.17, glibc-2.1.92-14 $ ssh chris at 172.16.5.2 -v SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090600f). debug: Reading configuration data /usr/local/app/openssh-2.3.0p1/etc/ssh_config debug: Seeding random number generator debug: ssh_connect: getuid 0 geteuid 0 anon 0 debug: Connecting to 172.16.5.2 [172.16.5.2] port 22. debug: Seeding random number generator debug: Allocated local port 764. debug: Connection established. debug: Remote protocol version 1.99, remote software version OpenSSH_2.3.0p1 debug: no match: OpenSSH_2.3.0p1 debug: Local version string SSH-1.5-OpenSSH_2.3.0p1 debug: Waiting for server public key. debug: Received server public key (768 bits) and host key (1024 bits). The authenticity of host '172.16.5.2' can't be established. RSA key fingerprint is ff:9c:c7:c2:1a:ee:93:20:7d:92:ee:c7:f9:99:55:fb. Are you sure you want to continue connecting (yes/no)? Segmentation fault This happens if the public key of system I want to connect to isn't known to the system I'm connecting from. The local system does have access to a DNS server. gdb says: $ gdb /usr/local/app/openssh-2.3.0p1/bin/ssh core GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"...(no debugging symbols found)... Core was generated by `ssh chris 172.16.5.2 -v'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libNoVersion.so.1...done. Loaded symbols for /lib/libNoVersion.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/libutil.so.1...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/libpam.so.0...done. Loaded symbols for /lib/libpam.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 #0 0x400bf737 in _IO_getline_info (fp=0x80de3d0, buf=0xbfffe834 "?\e\017\b?\e\017\b(", n=1023, delim=10, extract_delim=1, eof=0x0) at ../sysdeps/i386/i486/bits/string.h:435 435 ../sysdeps/i386/i486/bits/string.h: No such file or directory. (gdb) where #0 0x400bf737 in _IO_getline_info (fp=0x80de3d0, buf=0xbfffe834 "?\e\017\b?\e\017\b(", n=1023, delim=10, extract_delim=1, eof=0x0) at ../sysdeps/i386/i486/bits/string.h:435 #1 0x400bf87d in _IO_getline (fp=0x80de3d0, buf=0xbfffe834 "?\e\017\b?\e\017\b(", n=1023, delim=10, extract_delim=1) at iogetline.c:39 #2 0x400be938 in _IO_fgets (buf=0xbfffe834 "?\e\017\b?\e\017\b(", n=1024, fp=0x80de3d0) at iofgets.c:48 #3 0x804de09 in _start () #4 0x804e1f9 in _start () #5 0x804efb5 in _start () #6 0x804e4bd in _start () #7 0x804cb84 in _start () (gdb) quit strace says: [...] 3295 write(2, "Waiting for server public key.\r\n", 32) = 32 3295 select(5, [4], NULL, NULL, NULL) = 1 (in [4]) 3295 read(4, "\0\0\1\v\0\0\0\0\0\2\36\311$\2176<\354\33\0\0\3\0\0\6#"..., 8192) = 276 3295 write(2, "debug: ", 7) = 7 3295 write(2, "Received server public key (768 "..., 65) = 65 3295 open("/root/.ssh/known_hosts", O_RDONLY) = -1 ENOENT (No such file or directory) 3295 open("/usr/local/app/openssh-2.3.0p1/etc/ssh_known_hosts", O_RDONLY) = 5 3295 fstat(5, {st_mode=S_IFREG|0644, st_size=786, ...}) = 0 3295 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000 3295 read(5, "pluto,pluto.hwk-stuttgart.de,172"..., 4096) = 786 3295 read(5, "", 4096) = 0 3295 close(5) = 0 3295 munmap(0x4001a000, 4096) = 0 3295 ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0 3295 write(2, "The authenticity of host \'172.16"..., 187) = 187 3295 --- SIGSEGV (Segmentation fault) --- 3295 +++ killed by SIGSEGV +++ $ ldd /usr/local/bin/ssh /lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 (0x40018000) libdl.so.2 => /lib/libdl.so.2 (0x4001e000) libnsl.so.1 => /lib/libnsl.so.1 (0x40021000) libz.so.1 => /usr/lib/libz.so.1 (0x40038000) libutil.so.1 => /lib/libutil.so.1 (0x40046000) libpam.so.0 => /lib/libpam.so.0 (0x40049000) libc.so.6 => /lib/libc.so.6 (0x40051000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) -- Christian Recktenwald : : citecs GmbH : chris at citecs.de : Unternehmensberatung fuer : voice +49 711 601 2090 : Burgstallstrasse 54 EDV und Telekommunikation : fax +49 711 601 2092 : D-70199 Stuttgart From stain at nvg.org Wed Dec 13 04:12:37 2000 From: stain at nvg.org (Stian Soiland) Date: Tue, 12 Dec 2000 18:12:37 +0100 Subject: scp and filenames with weird characters Message-ID: <20001212181236.B20966@traad.dhs.org> I've experienced some troubles using scp with remote files with spaces, amphersands or parantheses in their filenames on Linux hosts. This happens: stain at false:~$ scp "bender.linpro.no:blapp blapp" . scp: blapp: No such file or directory scp: blapp: No such file or directory stain at false:~$ scp "bender.linpro.no:blapp&blapp" . bash: blapp: command not found This might be abused, like this: stain at false:~$ scp "bender.linpro.no:blapp&cat /etc/passwd" . root:x:0:0:root:/root:/bin/bash You might object that the person could done this simply with stain at false:~$ ssh bender.linpro.no cat /etc/passwd and even received more than one line, but the problem here is that one does not always have the same control over filenames as with commands. Note: This bug does not seem to effect local-to-remote copying or remote-to-local copying with shell filename expansion (*) One might temporarily overcome the problem with doublescaping, ie, stain at false:~$ scp "bender.linpro.no:blapp\ blapp" . blapp blapp 100% |*****************************************| 0 --:-- ETA Although the simplest is to patch the sourcecode: (A patchfile for the CVS-version is included, but these fixes should work for any 2.2.0-version (as the one in Debian woody) as far as I can see) in scp.c: - strlen(thost) + strlen(targ) + CMDNEEDS + 32; + strlen(thost) + strlen(targ) + CMDNEEDS + 40; - "%s%s -x -o'FallBackToRsh no' -n -l %s %s %s %s '%s%s%s:%s'", + "%s%s -x -o'FallBackToRsh no' -n -l \"%s\" \"%s\" \"%s\"\"%s\" '%s%s%s:%s'", - "exec %s%s -x -o'FallBackToRsh no' -n %s %s %s '%s%s%s:%s'", + "exec %s%s -x -o'FallBackToRsh no' -n \"%s\" \"%s\" \"%s\" '%s%s%s:%s'", - len = strlen(src) + CMDNEEDS + 20; + len = strlen(src) + CMDNEEDS + 22; - (void) sprintf(bp, "%s -f %s", cmd, src); + (void) sprintf(bp, "%s -f \"%s\"", cmd, src); as the clever eye might see, all I do is to surround arguments to the remote ssh with ""es and increases the memory allocation caused by this. Note: This even applies to other arguments, such as host and username, although it rarely happens that one haves usernames or hostnames with & or "". IMPORTANT: This does not fix the problem with filenames with " in them. (you probabbly need to tripple escape with something as ugly as scp "blapp.machine.com:filename\\\"blapp" . ) A search-replace routine on the src-string (" to \") would fix this, but my C-knowledge is non-existing. -- Stian S?iland - Trondheim, Norway - http://stain.portveien.to/ Uten forutg?ende varsel har utleier rett til ? tilintetgj?re illeluktende gjenstander - enten dette er mat eller andre ting. [Voll studentby] -------------- next part -------------- --- scp.c Tue Dec 12 17:36:30 2000 +++ /home/stain/scp.c Tue Dec 12 17:36:17 2000 @@ -387,7 +387,7 @@ host = strchr(argv[i], '@'); len = strlen(ssh_program) + strlen(argv[i]) + strlen(src) + (tuser ? strlen(tuser) : 0) + - strlen(thost) + strlen(targ) + CMDNEEDS + 32; + strlen(thost) + strlen(targ) + CMDNEEDS + 40; bp = xmalloc(len); if (host) { *host++ = 0; @@ -398,7 +398,7 @@ else if (!okname(suser)) continue; sprintf(bp, - "%s%s -x -o'FallBackToRsh no' -n -l %s %s %s %s '%s%s%s:%s'", + "%s%s -x -o'FallBackToRsh no' -n -l \"%s\" \"%s\" \"%s\" \"%s\" '%s%s%s:%s'", ssh_program, verbose_mode ? " -v" : "", suser, host, cmd, src, tuser ? tuser : "", tuser ? "@" : "", @@ -406,7 +406,7 @@ } else { host = cleanhostname(argv[i]); sprintf(bp, - "exec %s%s -x -o'FallBackToRsh no' -n %s %s %s '%s%s%s:%s'", + "exec %s%s -x -o'FallBackToRsh no' -n \"%s\" \"%s\" \"%s\" '%s%s%s:%s'", ssh_program, verbose_mode ? " -v" : "", host, cmd, src, tuser ? tuser : "", tuser ? "@" : "", @@ -472,9 +472,9 @@ continue; } host = cleanhostname(host); - len = strlen(src) + CMDNEEDS + 20; + len = strlen(src) + CMDNEEDS + 22; bp = xmalloc(len); - (void) sprintf(bp, "%s -f %s", cmd, src); + (void) sprintf(bp, "%s -f \"%s\"", cmd, src); if (do_cmd(host, suser, bp, &remin, &remout, argc) < 0) { (void) xfree(bp); ++errs; From joses at snelling.com Wed Dec 13 06:17:53 2000 From: joses at snelling.com (Jose Salicrup) Date: Tue, 12 Dec 2000 13:17:53 -0600 Subject: configure Error Message-ID: <3A3679E1.BF28385F@snelling.com> This is an Sun Ultra-I running Solaris 7. Open SSL is was compiled under /usr2/jjtest/openssl/openssl-0.9.6 and the installed in the default /usr/local/ssl directory. I've run ./ configure with the "--with-ssl-dir=DIR" and still get the following error: checking for OpenSSL directory... configure: error: Could not find working SSLeay / OpenSSL libraries, please install What can I do to correct this error? -- Jose L. Salicrup Snelling and Snelling, Inc., 12801 North Central Expressway, Suite 700 Dallas, TX 75243 972-776-1447 (w) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001212/14acd17f/attachment.html From rader at ginseng.physics.wisc.edu Wed Dec 13 07:31:56 2000 From: rader at ginseng.physics.wisc.edu (steve rader) Date: Tue, 12 Dec 2000 14:31:56 -0600 Subject: a (generic?!?) problem with server-side PATH to scp Message-ID: <200012122031.OAA18777@ginseng.physics.wisc.edu> First, thanks for making my life much more secure! Second, note that I just went from ssh 1.2.27 to openssh 2.3.0p1 and found that server-side scp was broken: make install put scp in /usr/local/bin yet the server-side PATH doesn't include /usr/local/bin... ssh-server# pwd /usr/local/src/openssh-2.3.0p1 ssh-server# ./configure --sysconfdir=/etc --with-ssl-dir=../openssl-0.9.6 \ --with-kerberos4=../krb4-1.0.3 --with-afs=/usr/afsws ssh-server# make; make install ssh-server# sshd -d -p 2222 ssh-client# ssh -P 2222 /etc/motd ssh-server:/dev/null [...] PATH=/usr/bin:/bin:/usr/sbin:/sbin [...] bash: scp: command not found lost connection Maybe this is just a problem introduced my crazy ./configure for afs, but it seems like USER_PATH should be include bindir (ala --prefix) when --with-default-path=PATH is not used or somesuch hacking sillyness. I readly admit it's easy 'nuf to hack _PATH_STDPATH in defines.h, at any rate. later steve - - - systems & network guy high energy physics university of wisconsin From markus.friedl at informatik.uni-erlangen.de Wed Dec 13 08:36:10 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Tue, 12 Dec 2000 22:36:10 +0100 Subject: need help on scp (fwd) Message-ID: <20001212223610.C30757@folly> where is --with-default-path= documented? in the INSTALL? in the FAQ? it should be probably a FAQ. perhaps configure should print a warning/notice if scp is installed in a non-standard path? -m -------------- next part -------------- An embedded message was scrubbed... From: "Horng-Twu Lihn" Subject: Re: need help on scp Date: Mon, 11 Dec 2000 09:52:26 -0500 Size: 2918 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001212/3aa46c72/attachment.mht From amk at krell.zikzak.de Tue Dec 12 09:56:22 2000 From: amk at krell.zikzak.de (Andreas M. Kirchwitz) Date: Mon, 11 Dec 2000 23:56:22 +0100 Subject: OpenSSH 2.3.0p1: Broken pipe / SIGPIPE Message-ID: <20001211235622.A32409@krell.zikzak.de> Dear OpenSSH gurus! ;-) I recently upgraded from "OpenSSH 2.1.1p4" to "OpenSSH 2.3.0p1" on my Linux 2.2.17 box with OpenSSL 0.9.5a (RedHat 7.0). According to the "ChangeLog", there was a change in SIGPIPE handling: | 20000930 | [...] | - (djm) Ignore SIGPIPEs from serverloop to child. Fixes crashes with | very short lived X connections. Bug report from Tobias Oetiker | . Fix from Markus Friedl I don't know what it fixes for X, but it breaks pipe handling in some other ways. While "yes | head -1" worked okay with OpenSSH 2.1.1p4, it hangs with tcsh 6.10.00 and OpenSSH 2.3.0p1 due to the ignored SIGPIPE in the serverloop. With bash 2.04.11 and OpenSSH 2.3.0p1, "yes | head -1" says "Broken pipe". It works okay with OpenSSH 2.3.0p1 if I disable the two signal() calls (in serverloop.c) that ignore SIGPIPE. Another example is to call something like "grep foobar file | less" on a file with thousands of occurences of "foobar". After "less" has displayed the first page, if I then hit "q" (for quit), I get thousands of lines saying: grep: writing output: Broken pipe With OpenSSH 2.1.1p4, everything was fine. Well, I don't say, that OpenSSH is broken... although the bad behaviour obviously came from a change to OpenSSH (see ChangeLog). But even if it's not OpenSSH's fault, maybe you have an idea what's wrong with the other applications like tcsh, bash, head, less etc. Any help is welcome! ;-) Greetings, Andreas From rachit at ensim.com Wed Dec 13 09:47:28 2000 From: rachit at ensim.com (Rachit Siamwalla) Date: Tue, 12 Dec 2000 14:47:28 -0800 Subject: OpenSSH 2.3.0p1: Broken pipe / SIGPIPE References: <20001211235622.A32409@krell.zikzak.de> Message-ID: <3A36AB00.C82CDB56@ensim.com> I believe this is normal behavior. Try it without using SSH, and it will happen. Basically it happens if the command on the right hand side of the pipe exits (normally or abnormally) before the command on the left of the pipe finishes writing its output. The fd will be closed and thus the process on the left will get a SIGPIPE (or pipe write error if its masked out). -rchit > "yes | head -1" says "Broken pipe". > Another example is to call something like "grep foobar file | less" > on a file with thousands of occurences of "foobar". After "less" > has displayed the first page, if I then hit "q" (for quit), I get > thousands of lines saying: > > grep: writing output: Broken pipe > From djm at mindrot.org Wed Dec 13 10:25:18 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 13 Dec 2000 10:25:18 +1100 (EST) Subject: OpenSSH 2.3.0p1: Broken pipe / SIGPIPE In-Reply-To: <3A36AB00.C82CDB56@ensim.com> Message-ID: On Tue, 12 Dec 2000, Rachit Siamwalla wrote: Does this patch help? Index: session.c =================================================================== RCS file: /cvs/openssh_cvs/session.c,v retrieving revision 1.58 diff -u -r1.58 session.c --- session.c 2000/11/29 04:55:17 1.58 +++ session.c 2000/12/12 23:24:37 @@ -480,8 +480,6 @@ if (s == NULL) fatal("do_exec_no_pty: no session"); - signal(SIGPIPE, SIG_DFL); - session_proctitle(s); #ifdef USE_PAM @@ -493,6 +491,8 @@ /* Child. Reinitialize the log since the pid has changed. */ log_init(__progname, options.log_level, options.log_facility, log_stderr); + signal(SIGPIPE, SIG_DFL); + /* * Create a new session and process group since the 4.4BSD * setlogin() affects the entire process group. @@ -605,6 +605,8 @@ if ((pid = fork()) == 0) { /* Child. Reinitialize the log because the pid has changed. */ log_init(__progname, options.log_level, options.log_facility, log_stderr); + + signal(SIGPIPE, SIG_DFL); /* Close the master side of the pseudo tty. */ close(ptyfd); > I believe this is normal behavior. Try it without using SSH, and it will > happen. > > Basically it happens if the command on the right hand side of the pipe > exits (normally or abnormally) before the command on the left of the > pipe finishes writing its output. The fd will be closed and thus the > process on the left will get a SIGPIPE (or pipe write error if its > masked out). > > -rchit > > > "yes | head -1" says "Broken pipe". > > Another example is to call something like "grep foobar file | less" > > on a file with thousands of occurences of "foobar". After "less" > > has displayed the first page, if I then hit "q" (for quit), I get > > thousands of lines saying: > > > > grep: writing output: Broken pipe > > > -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From stevesk at pobox.com Wed Dec 13 10:47:08 2000 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 13 Dec 2000 00:47:08 +0100 (CET) Subject: reinstalling SIGCHLD handler before wait() Message-ID: HP-UX 11 is looping on SIGCHLD/sigchld_handler2() when exiting a protocol 2 session apparently because we don't call wait before reinstalling the handler. Any thoughts on this issue or how to address it? serverloop.c from latest snapshots: void sigchld_handler2(int sig) { int save_errno = errno; debug("Received SIGCHLD."); child_terminated = 1; signal(SIGCHLD, sigchld_handler2); errno = save_errno; } from signal(5) on HP-UX 11 (SIGCLD is the same as SIGCHLD): If one of the signal interface routines is used to set the action for SIGCLD to be caught (that is, a function address is supplied) in a process that currently has terminated (zombie) children, a SIGCLD signal is delivered to the parent process immediately. Thus, if the signal-catching function reinstalls itself, the apparent effect is that any SIGCLD signals received due to the death of children while the function is executing are queued and the signal-catching function is continually reentered until the queue is empty. Note that the function must reinstall itself after it calls wait(), wait3(), or waitpid(). Otherwise the presence of the child that caused the original signal causes another signal immediately, resulting in infinite recursion. From markus.friedl at informatik.uni-erlangen.de Wed Dec 13 10:57:28 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 13 Dec 2000 00:57:28 +0100 Subject: reinstalling SIGCHLD handler before wait() In-Reply-To: ; from stevesk@pobox.com on Wed, Dec 13, 2000 at 12:47:08AM +0100 References: Message-ID: <20001213005728.B10786@folly> i wrote this code and i'd prefer signal handlers that only set flags and do _not_ call waitpid etc. moreover, i don't want to have to re-install the signal handler. i'll read my stevens again. On Wed, Dec 13, 2000 at 12:47:08AM +0100, Kevin Steves wrote: > HP-UX 11 is looping on SIGCHLD/sigchld_handler2() when exiting a > protocol 2 session apparently because we don't call wait before > reinstalling the handler. Any thoughts on this issue or how to address > it? > > serverloop.c from latest snapshots: > > void > sigchld_handler2(int sig) > { > int save_errno = errno; > debug("Received SIGCHLD."); > child_terminated = 1; > signal(SIGCHLD, sigchld_handler2); > errno = save_errno; > } > > from signal(5) on HP-UX 11 (SIGCLD is the same as SIGCHLD): > > If one of the signal interface routines is used to > set the action for SIGCLD to be caught (that is, a > function address is supplied) in a process that > currently has terminated (zombie) children, a > SIGCLD signal is delivered to the parent process > immediately. Thus, if the signal-catching > function reinstalls itself, the apparent effect is > that any SIGCLD signals received due to the death > of children while the function is executing are > queued and the signal-catching function is > continually reentered until the queue is empty. > Note that the function must reinstall itself after > it calls wait(), wait3(), or waitpid(). Otherwise > the presence of the child that caused the original > signal causes another signal immediately, > resulting in infinite recursion. > > From djm at mindrot.org Wed Dec 13 13:10:36 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 13 Dec 2000 13:10:36 +1100 (EST) Subject: need help on scp (fwd) In-Reply-To: <20001212223610.C30757@folly> Message-ID: On Tue, 12 Dec 2000, Markus Friedl wrote: > where is --with-default-path= documented? > in the INSTALL? in the FAQ? Both :) > perhaps configure should print a warning/notice > if scp is installed in a non-standard path? We could grep the current PATH for the installation directory, but this may not be perfect. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From djm at mindrot.org Wed Dec 13 13:11:54 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 13 Dec 2000 13:11:54 +1100 (EST) Subject: openssh 2.3.0p1 crashes In-Reply-To: <20001212162500.A27640@MrFabulous.citecs> Message-ID: On Tue, 12 Dec 2000, Christian Recktenwald wrote: > System: RedHat 7.0, Kernel 2.2.17, glibc-2.1.92-14 Can you replicate with the glibc-2.2 errata RPM installed? -d > $ ssh chris at 172.16.5.2 -v > SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. > Compiled with SSL (0x0090600f). > debug: Reading configuration data /usr/local/app/openssh-2.3.0p1/etc/ssh_config > debug: Seeding random number generator > debug: ssh_connect: getuid 0 geteuid 0 anon 0 > debug: Connecting to 172.16.5.2 [172.16.5.2] port 22. > debug: Seeding random number generator > debug: Allocated local port 764. > debug: Connection established. > debug: Remote protocol version 1.99, remote software version OpenSSH_2.3.0p1 > debug: no match: OpenSSH_2.3.0p1 > debug: Local version string SSH-1.5-OpenSSH_2.3.0p1 > debug: Waiting for server public key. > debug: Received server public key (768 bits) and host key (1024 bits). > The authenticity of host '172.16.5.2' can't be established. > RSA key fingerprint is ff:9c:c7:c2:1a:ee:93:20:7d:92:ee:c7:f9:99:55:fb. > Are you sure you want to continue connecting (yes/no)? Segmentation fault > > This happens if the public key of system I want to connect to > isn't known to the system I'm connecting from. > > The local system does have access to a DNS server. > > gdb says: > > $ gdb /usr/local/app/openssh-2.3.0p1/bin/ssh core > GNU gdb 5.0 > Copyright 2000 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-redhat-linux"...(no debugging symbols found)... > Core was generated by `ssh chris 172.16.5.2 -v'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /lib/libNoVersion.so.1...done. > Loaded symbols for /lib/libNoVersion.so.1 > Reading symbols from /lib/libdl.so.2...done. > Loaded symbols for /lib/libdl.so.2 > Reading symbols from /lib/libnsl.so.1...done. > Loaded symbols for /lib/libnsl.so.1 > Reading symbols from /usr/lib/libz.so.1...done. > Loaded symbols for /usr/lib/libz.so.1 > Reading symbols from /lib/libutil.so.1...done. > Loaded symbols for /lib/libutil.so.1 > Reading symbols from /lib/libpam.so.0...done. > Loaded symbols for /lib/libpam.so.0 > Reading symbols from /lib/libc.so.6...done. > Loaded symbols for /lib/libc.so.6 > Reading symbols from /lib/ld-linux.so.2...done. > Loaded symbols for /lib/ld-linux.so.2 > Reading symbols from /lib/libnss_files.so.2...done. > Loaded symbols for /lib/libnss_files.so.2 > #0 0x400bf737 in _IO_getline_info (fp=0x80de3d0, buf=0xbfffe834 "?\e\017\b?\e\017\b(", n=1023, delim=10, extract_delim=1, eof=0x0) > at ../sysdeps/i386/i486/bits/string.h:435 > 435 ../sysdeps/i386/i486/bits/string.h: No such file or directory. > (gdb) where > #0 0x400bf737 in _IO_getline_info (fp=0x80de3d0, buf=0xbfffe834 "?\e\017\b?\e\017\b(", n=1023, delim=10, extract_delim=1, eof=0x0) > at ../sysdeps/i386/i486/bits/string.h:435 > #1 0x400bf87d in _IO_getline (fp=0x80de3d0, buf=0xbfffe834 "?\e\017\b?\e\017\b(", n=1023, delim=10, extract_delim=1) at iogetline.c:39 > #2 0x400be938 in _IO_fgets (buf=0xbfffe834 "?\e\017\b?\e\017\b(", n=1024, fp=0x80de3d0) at iofgets.c:48 > #3 0x804de09 in _start () > #4 0x804e1f9 in _start () > #5 0x804efb5 in _start () > #6 0x804e4bd in _start () > #7 0x804cb84 in _start () > (gdb) quit > > strace says: > > [...] > 3295 write(2, "Waiting for server public key.\r\n", 32) = 32 > 3295 select(5, [4], NULL, NULL, NULL) = 1 (in [4]) > 3295 read(4, "\0\0\1\v\0\0\0\0\0\2\36\311$\2176<\354\33\0\0\3\0\0\6#"..., 8192) = 276 > 3295 write(2, "debug: ", 7) = 7 > 3295 write(2, "Received server public key (768 "..., 65) = 65 > 3295 open("/root/.ssh/known_hosts", O_RDONLY) = -1 ENOENT (No such file or directory) > 3295 open("/usr/local/app/openssh-2.3.0p1/etc/ssh_known_hosts", O_RDONLY) = 5 > 3295 fstat(5, {st_mode=S_IFREG|0644, st_size=786, ...}) = 0 > 3295 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000 > 3295 read(5, "pluto,pluto.hwk-stuttgart.de,172"..., 4096) = 786 > 3295 read(5, "", 4096) = 0 > 3295 close(5) = 0 > 3295 munmap(0x4001a000, 4096) = 0 > 3295 ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0 > 3295 write(2, "The authenticity of host \'172.16"..., 187) = 187 > 3295 --- SIGSEGV (Segmentation fault) --- > 3295 +++ killed by SIGSEGV +++ > > $ ldd /usr/local/bin/ssh > /lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 (0x40018000) > libdl.so.2 => /lib/libdl.so.2 (0x4001e000) > libnsl.so.1 => /lib/libnsl.so.1 (0x40021000) > libz.so.1 => /usr/lib/libz.so.1 (0x40038000) > libutil.so.1 => /lib/libutil.so.1 (0x40046000) > libpam.so.0 => /lib/libpam.so.0 (0x40049000) > libc.so.6 => /lib/libc.so.6 (0x40051000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From djm at mindrot.org Wed Dec 13 13:20:50 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 13 Dec 2000 13:20:50 +1100 (EST) Subject: reinstalling SIGCHLD handler before wait() In-Reply-To: <20001213005728.B10786@folly> Message-ID: On Wed, 13 Dec 2000, Markus Friedl wrote: > i wrote this code and i'd prefer signal handlers that > only set flags and do _not_ call waitpid etc. moreover, i > don't want to have to re-install the signal handler. > i'll read my stevens again. How about delaying the reinstatement of sigchld_handler2 until after the while(waidpid()) loop in server_loop2? -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From amk at krell.zikzak.de Wed Dec 13 14:30:31 2000 From: amk at krell.zikzak.de (Andreas M. Kirchwitz) Date: Wed, 13 Dec 2000 04:30:31 +0100 Subject: OpenSSH 2.3.0p1: Broken pipe / SIGPIPE In-Reply-To: ; from djm@mindrot.org on Wed, Dec 13, 2000 at 10:25:18AM +1100 References: <3A36AB00.C82CDB56@ensim.com> Message-ID: <20001213043031.A12191@krell.zikzak.de> Damien Miller wrote: > Index: session.c > =================================================================== > RCS file: /cvs/openssh_cvs/session.c,v > retrieving revision 1.58 > diff -u -r1.58 session.c > --- session.c 2000/11/29 04:55:17 1.58 > +++ session.c 2000/12/12 23:24:37 > @@ -480,8 +480,6 @@ > if (s == NULL) > fatal("do_exec_no_pty: no session"); > > - signal(SIGPIPE, SIG_DFL); > - > session_proctitle(s); > > #ifdef USE_PAM > @@ -493,6 +491,8 @@ > /* Child. Reinitialize the log since the pid has changed. */ > log_init(__progname, options.log_level, options.log_facility, log_stderr); > > + signal(SIGPIPE, SIG_DFL); > + > /* > * Create a new session and process group since the 4.4BSD > * setlogin() affects the entire process group. > @@ -605,6 +605,8 @@ > if ((pid = fork()) == 0) { > /* Child. Reinitialize the log because the pid has changed. */ > log_init(__progname, options.log_level, options.log_facility, log_stderr); > + > + signal(SIGPIPE, SIG_DFL); > > /* Close the master side of the pseudo tty. */ > close(ptyfd); > > Does this patch help? YEAH! That looks very good! Couldn't see any bad side effects so far with this patch. It successfully solves the "Broken pipe" problem with OpenSSH 2.3.0p1. "yes | head -1" now works again as expected with tcsh and bash. Great! Thanks a lot for your help... Btw, will this patch go into the official OpenSSH(p) distribution? Greetings, Andreas From jbailey at nisa.net Wed Dec 13 15:01:53 2000 From: jbailey at nisa.net (Jeff Bailey) Date: Tue, 12 Dec 2000 20:01:53 -0800 Subject: GMP in COPYING.Ylonen Message-ID: <20001212200153.A28466@sparky.nisa.net> COPYING.Ylonen contains: [ GMP is now external. No more GNU licence. ] I don't see how GMP is linked in at all. rms asked me to look into this, because this might constitute a license conflict. Thanks for your help! -- No matter how big the bell, if you only tap it, it can give out only a faint sound. We must understand thoroughly that the weakness of the blow, not a fault of the bell makes the sound poor. - Koichi Tohei From djm at mindrot.org Wed Dec 13 15:41:06 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 13 Dec 2000 15:41:06 +1100 (EST) Subject: Anonymous CVS, Snapshot mirrors available Message-ID: Thanks to the generosity of Rob Hagopian , portable OpenSSH now has a public anonymous CVS tree and a mirror of the snapshots on a fast (colocated) machine. The nightly snapshots are now available from: http://bass.directhit.com/openssh_snap/ Please use these instead of the mindrot.org ones (which will be going away soon). To checkout the CVS tree, issue the following commands: cvs -d :pserver:cvs at bass.directhit.com:/cvs login (just hit enter when asked for a password) cvs -d :pserver:cvs at bass.directhit.com:/cvs co openssh_cvs If sending patches, please use the unified diff format ("diff -u" or "cvs diff -u") as it is much easier to read. Regards, Damien Miller -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From djm at mindrot.org Wed Dec 13 15:47:26 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 13 Dec 2000 15:47:26 +1100 (EST) Subject: GMP in COPYING.Ylonen In-Reply-To: <20001212200153.A28466@sparky.nisa.net> Message-ID: On Tue, 12 Dec 2000, Jeff Bailey wrote: > COPYING.Ylonen contains: > [ GMP is now external. No more GNU licence. ] > > I don't see how GMP is linked in at all. rms asked me to look into this, > because this might constitute a license conflict. GMP isn't used at all. OpenSSH uses the OpenSSL library for its bignum functions. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From jbailey at nisa.net Wed Dec 13 16:06:26 2000 From: jbailey at nisa.net (Jeff Bailey) Date: Tue, 12 Dec 2000 21:06:26 -0800 Subject: GMP in COPYING.Ylonen In-Reply-To: ; from Damien Miller on Wed, Dec 13, 2000 at 03:47:26PM +1100 References: <20001212200153.A28466@sparky.nisa.net> Message-ID: <20001212210626.I28466@sparky.nisa.net> On Wed, Dec 13, 2000 at 03:47:26PM +1100, Damien Miller wrote: > > COPYING.Ylonen contains: > > [ GMP is now external. No more GNU licence. ] > > > > I don't see how GMP is linked in at all. rms asked me to look into this, > > because this might constitute a license conflict. > > GMP isn't used at all. OpenSSH uses the OpenSSL library for its bignum > functions. Thanks! It might be worth changing that to say "is no longer used" to make it clearer. -- No matter how big the bell, if you only tap it, it can give out only a faint sound. We must understand thoroughly that the weakness of the blow, not a fault of the bell makes the sound poor. - Koichi Tohei From deraadt at cvs.openbsd.org Wed Dec 13 16:53:28 2000 From: deraadt at cvs.openbsd.org (Theo de Raadt) Date: Tue, 12 Dec 2000 22:53:28 -0700 Subject: GMP in COPYING.Ylonen In-Reply-To: Your message of "Tue, 12 Dec 2000 21:06:26 PST." <20001212210626.I28466@sparky.nisa.net> Message-ID: <200012130553.eBD5rSb03881@cvs.openbsd.org> > On Wed, Dec 13, 2000 at 03:47:26PM +1100, Damien Miller wrote: > > > > COPYING.Ylonen contains: > > > [ GMP is now external. No more GNU licence. ] > > > > > > I don't see how GMP is linked in at all. rms asked me to look into this, > > > because this might constitute a license conflict. > > > > GMP isn't used at all. OpenSSH uses the OpenSSL library for its bignum > > functions. > > Thanks! It might be worth changing that to say "is no longer used" to > make it clearer. Tough cookies. I don't think we'll change that. Next time, read the source. From jason-openssh at dfmm.org Wed Dec 13 18:01:54 2000 From: jason-openssh at dfmm.org (Jason Stone) Date: Tue, 12 Dec 2000 23:01:54 -0800 (PST) Subject: Garbage in syslog Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I recently had some weirdness that maybe someone can help explain. I have a linux box (2.2.18pre21+ext3+freeswan) running openssh 2.2.0p and openssl 0.9.5a. My box crashed mysteriously and then when it started back up, I saw this in the logs: Dec 12 21:45:19 moonchild sshd: Starting sshd: Dec 12 21:45:20 moonchild sshd[509]: Server listening on 0.0.0.0 port 22. Dec 12 21:45:20 moonchild sshd[509]: Generating 1152 bit RSA key. Dec 12 21:45:20 moonchild sshd: sshd startup succeeded Dec 12 21:45:20 moonchild sshd: ^[[300C^[[20D Dec 12 21:45:20 moonchild sshd: [ Dec 12 21:45:20 moonchild sshd: ^[[1;32mOK Dec 12 21:45:20 moonchild sshd: ^[[0;39m Dec 12 21:45:20 moonchild sshd: ] Dec 12 21:45:20 moonchild sshd: Whenever I see garbage characters in logs, I start to get paranoid about buffer overruns - so does anyone know why sshd might produce the above? -Jason --------------------------- If the Revolution comes to grief, it will be because you and those you lead have become alarmed at your own brutality. --John Gardner -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE6Nx7lswXMWWtptckRAhhWAKDzrgE3ohuQSS/McZEpImeR5wc7qwCePdyG nRQfu/hFk8NMg3UUQo/o7XM= =pi9H -----END PGP SIGNATURE----- From matthewm at webcentral.com.au Wed Dec 13 18:14:48 2000 From: matthewm at webcentral.com.au (Matthew Melvin) Date: Wed, 13 Dec 2000 17:14:48 +1000 (EST) Subject: Garbage in syslog In-Reply-To: Message-ID: On Tue, 12 Dec 2000, Jason Stone wrote: > > I recently had some weirdness that maybe someone can help explain. I have > a linux box (2.2.18pre21+ext3+freeswan) running openssh 2.2.0p and openssl > 0.9.5a. My box crashed mysteriously and then when it started back up, I > saw this in the logs: > > Dec 12 21:45:19 moonchild sshd: Starting sshd: > Dec 12 21:45:20 moonchild sshd[509]: Server listening on 0.0.0.0 port 22. > Dec 12 21:45:20 moonchild sshd[509]: Generating 1152 bit RSA key. > Dec 12 21:45:20 moonchild sshd: sshd startup succeeded > Dec 12 21:45:20 moonchild sshd: ^[[300C^[[20D > Dec 12 21:45:20 moonchild sshd: [ > Dec 12 21:45:20 moonchild sshd: ^[[1;32mOK > Dec 12 21:45:20 moonchild sshd: ^[[0;39m > Dec 12 21:45:20 moonchild sshd: ] > Dec 12 21:45:20 moonchild sshd: > > Whenever I see garbage characters in logs, I start to get paranoid about > buffer overruns - so does anyone know why sshd might produce the above? > I don't know how it got into your syslog but this is Red Hat (or similar)'s green 'OK' message. Starting sshd: [ OK ] .. obviously in the syslog these escape characters are written as litterals. M. -- WebCentral Pty Ltd Australia's #1 Internet Web Hosting Company Level 1, 96 Lytton Road. Network Operations - Systems Engineer PO Box 4169, East Brisbane. phone: +61 7 3249 2583 Queensland, Australia. pgp key id: 0x900E515F From Markus.Friedl at informatik.uni-erlangen.de Wed Dec 13 19:10:51 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 13 Dec 2000 09:10:51 +0100 Subject: reinstalling SIGCHLD handler before wait() In-Reply-To: ; from djm@mindrot.org on Wed, Dec 13, 2000 at 01:20:50PM +1100 References: <20001213005728.B10786@folly> Message-ID: <20001213091051.A28860@faui02.informatik.uni-erlangen.de> On Wed, Dec 13, 2000 at 01:20:50PM +1100, Damien Miller wrote: > On Wed, 13 Dec 2000, Markus Friedl wrote: > > > i wrote this code and i'd prefer signal handlers that > > only set flags and do _not_ call waitpid etc. moreover, i > > don't want to have to re-install the signal handler. > > i'll read my stevens again. > > How about delaying the reinstatement of sigchld_handler2 until after > the while(waidpid()) loop in server_loop2? what happens with signals between the waitpid and the re-install? i'd like to have the handler _always_ installed. i prefer this signal-semantic. From wpilorz at bdk.pl Wed Dec 13 20:24:03 2000 From: wpilorz at bdk.pl (Wojtek Pilorz) Date: Wed, 13 Dec 2000 10:24:03 +0100 (CET) Subject: reinstalling SIGCHLD handler before wait() In-Reply-To: <20001213091051.A28860@faui02.informatik.uni-erlangen.de> Message-ID: On Wed, 13 Dec 2000, Markus Friedl wrote: > Date: Wed, 13 Dec 2000 09:10:51 +0100 > From: Markus Friedl > To: Damien Miller > Cc: Kevin Steves , openssh-unix-dev at mindrot.org > Subject: Re: reinstalling SIGCHLD handler before wait() > > On Wed, Dec 13, 2000 at 01:20:50PM +1100, Damien Miller wrote: > > On Wed, 13 Dec 2000, Markus Friedl wrote: > > > > > i wrote this code and i'd prefer signal handlers that > > > only set flags and do _not_ call waitpid etc. moreover, i > > > don't want to have to re-install the signal handler. > > > i'll read my stevens again. > > > > How about delaying the reinstatement of sigchld_handler2 until after > > the while(waidpid()) loop in server_loop2? > > what happens with signals between the waitpid and the re-install? > > i'd like to have the handler _always_ installed. i prefer this > signal-semantic. > Maybe we could use sigaction rather than signal ? I believe sigaction in considered more robust and preferred way of handling signals. Best regards, Wojtek From gert at greenie.muc.de Wed Dec 13 20:30:18 2000 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 13 Dec 2000 10:30:18 +0100 Subject: reinstalling SIGCHLD handler before wait() In-Reply-To: ; from Wojtek Pilorz on Wed, Dec 13, 2000 at 10:24:03AM +0100 References: <20001213091051.A28860@faui02.informatik.uni-erlangen.de> Message-ID: <20001213103018.A3381@greenie.muc.de> Hi, On Wed, Dec 13, 2000 at 10:24:03AM +0100, Wojtek Pilorz wrote: > I believe sigaction in considered more robust and preferred way of > handling signals. But a lot less portable. Especially older SysV systems do not have sigaction(). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From wpilorz at bdk.pl Wed Dec 13 21:17:46 2000 From: wpilorz at bdk.pl (Wojtek Pilorz) Date: Wed, 13 Dec 2000 11:17:46 +0100 (CET) Subject: reinstalling SIGCHLD handler before wait() In-Reply-To: <20001213103018.A3381@greenie.muc.de> Message-ID: On Wed, 13 Dec 2000, Gert Doering wrote: > Date: Wed, 13 Dec 2000 10:30:18 +0100 > From: Gert Doering > To: Wojtek Pilorz , > Markus Friedl > Cc: Damien Miller , Kevin Steves , > openssh-unix-dev at mindrot.org > Subject: Re: reinstalling SIGCHLD handler before wait() > > Hi, > > On Wed, Dec 13, 2000 at 10:24:03AM +0100, Wojtek Pilorz wrote: > > I believe sigaction in considered more robust and preferred way of > > handling signals. > > But a lot less portable. Especially older SysV systems do not have > sigaction(). Yes, but I believe the vast majority of UNIX and UNIX-like systems do provide sigaction (sigaction is required by POSIX, isn't it?), and for those systems it would be preferred way of handling signals. For the systems which are not enough POSIX-compatible me might 1. choose not to support them 2. use some #ifdefs throughout the code 3. use emulation as it is done for snprintf now (there is even file openssh/bsd-sigaction.c which emulates sigaction using sigvec; do those older SysV systems define sigvec?) Each of the approaches would have pros and cons. Also, please note that sigaction is already being used in scp.c; And while it is used in a rather not critical piece of code (progressmeter function), if we had heard no complaints about it so far. maybe even option 1. would be acceptable? If we stick with signal there will always be some race conditions after a signal is received and before its handler is installed again. > > gert > -- > USENET is *not* the non-clickable part of WWW! > //www.muc.de/~gert/ > Gert Doering - Munich, Germany gert at greenie.muc.de > fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de > Best regards, Wojtek From jason-openssh at dfmm.org Wed Dec 13 23:08:06 2000 From: jason-openssh at dfmm.org (Jason Stone) Date: Wed, 13 Dec 2000 04:08:06 -0800 (PST) Subject: Garbage in syslog In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > I recently had some weirdness that maybe someone can help explain. I > > have a linux box (2.2.18pre21+ext3+freeswan) running openssh 2.2.0p > > and openssl 0.9.5a. My box crashed mysteriously and then when it > > started back up, I saw this in the logs: > I don't know how it got into your syslog but this is Red Hat (or > similar)'s green 'OK' message. .. obviously in the syslog these escape > characters are written as litterals. Doh! Sorry - next time I'll read more carefully before spamming.... Thanks. -Jason --------------------------- If the Revolution comes to grief, it will be because you and those you lead have become alarmed at your own brutality. --John Gardner -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE6N2arswXMWWtptckRAoMDAJ9EZbB9xbxymqld9yUBufo4o5oAwgCgmSkv QHVC9gaqdSiW1HfTs/45KoI= =tejy -----END PGP SIGNATURE----- From gert at greenie.muc.de Thu Dec 14 01:51:53 2000 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 13 Dec 2000 15:51:53 +0100 Subject: Anonymous CVS, Snapshot mirrors available In-Reply-To: ; from Damien Miller on Wed, Dec 13, 2000 at 03:41:06PM +1100 References: Message-ID: <20001213155153.F4429@greenie.muc.de> Hi, On Wed, Dec 13, 2000 at 03:41:06PM +1100, Damien Miller wrote: > Thanks to the generosity of Rob Hagopian , portable > OpenSSH now has a public anonymous CVS tree and a mirror of the > snapshots on a fast (colocated) machine. These are good news. I just tried this on AIX, and this resulted in "configure" complaining about: creating config.h cat: cannot open ./config.h.in Is there anything special besides doing: cvs checkout ... cd openssh_cvs autoconf ./configure ? Maybe my autoconf version is too old (I'm using 2.13)? ... ah! Found it: config.h.in depends on running running "autoheader". Hmm. Is there a way to automate running "autoconf" and "autoheader"? Any makefile tricks that I do not know yet? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From rms at gnu.org Thu Dec 14 04:38:39 2000 From: rms at gnu.org (Richard Stallman) Date: Wed, 13 Dec 2000 10:38:39 -0700 (MST) Subject: GMP in COPYING.Ylonen In-Reply-To: <200012130553.eBD5rSb03881@cvs.openbsd.org> (message from Theo de Raadt on Tue, 12 Dec 2000 22:53:28 -0700) References: <200012130553.eBD5rSb03881@cvs.openbsd.org> Message-ID: <200012131738.KAA25698@wijiji.santafe.edu> De Raadt hates the GNU Project so much, if a GNU person whispered to him that his fly was open, he would scream back in rage: "I won't zip it up for you!" From provos at citi.umich.edu Thu Dec 14 05:04:14 2000 From: provos at citi.umich.edu (Niels Provos) Date: Wed, 13 Dec 2000 13:04:14 -0500 Subject: GMP in COPYING.Ylonen Message-ID: <20001213180414.35E84207C6@citi.umich.edu> >De Raadt hates the GNU Project so much, if a GNU person whispered to >him that his fly was open, he would scream back in rage: "I won't zip >it up for you!" I am sorry, Richard, this is one of the more stupid comments that I have seen from you. You certainly don't help to foster any fond feelings towards the GNU project with remarks like that. If you would have bothered to check the OpenSSH distribution, you would have seen that no GPL'ed component are used in OpenSSH what so ever. There is no misleading documentation either. We would like everyone to be able to use OpenSSH, the GPL does not help with that very much. I know that you disagree, and if you would like to discuss this issue further, please reply to me in private email, so that we don't bore all the people subscribed to the mailing list. Greetings, Niels. From stevesk at pobox.com Thu Dec 14 05:45:07 2000 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 13 Dec 2000 19:45:07 +0100 (CET) Subject: GMP in COPYING.Ylonen In-Reply-To: Message-ID: On Wed, 13 Dec 2000, Damien Miller wrote: : > COPYING.Ylonen contains: : > [ GMP is now external. No more GNU licence. ] : > : > I don't see how GMP is linked in at all. rms asked me to look into this, : > because this might constitute a license conflict. : : GMP isn't used at all. OpenSSH uses the OpenSSL library for its bignum : functions. should we continue to include COPYING.Ylonen in the portable release? i see openbsd doesn't include it any longer (same REAMDE.Ylonen). From deraadt at cvs.openbsd.org Thu Dec 14 05:54:35 2000 From: deraadt at cvs.openbsd.org (Theo de Raadt) Date: Wed, 13 Dec 2000 11:54:35 -0700 Subject: GMP in COPYING.Ylonen In-Reply-To: Your message of "Wed, 13 Dec 2000 10:38:39 MST." <200012131738.KAA25698@wijiji.santafe.edu> Message-ID: <200012131854.eBDIsab27426@cvs.openbsd.org> > De Raadt hates the GNU Project so much, if a GNU person whispered to > him that his fly was open, he would scream back in rage: "I won't zip > it up for you!" Wow, you're even more funny in email than you are when you talk!!!!! From djm at mindrot.org Thu Dec 14 08:53:45 2000 From: djm at mindrot.org (Damien Miller) Date: Thu, 14 Dec 2000 08:53:45 +1100 (EST) Subject: Anonymous CVS, Snapshot mirrors available In-Reply-To: <20001213155153.F4429@greenie.muc.de> Message-ID: On Wed, 13 Dec 2000, Gert Doering wrote: > ... ah! Found it: config.h.in depends on running running "autoheader". > > Hmm. > > Is there a way to automate running "autoconf" and "autoheader"? Any > makefile tricks that I do not know yet? make -f Makefile.in distprep -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From markus.friedl at informatik.uni-erlangen.de Thu Dec 14 10:30:56 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 14 Dec 2000 00:30:56 +0100 Subject: new port to MiNT (fwd) Message-ID: <20001214003056.C8162@folly> fyi -------------- next part -------------- An embedded message was scrubbed... From: =?iso-8859-1?Q?Martin-=C9ric_Racine?= Subject: new port to MiNT Date: Thu, 14 Dec 2000 00:06:25 +0200 (EET) Size: 1683 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001214/a5533174/attachment.mht From mdejong at cygnus.com Thu Dec 14 11:56:53 2000 From: mdejong at cygnus.com (Mo DeJong) Date: Wed, 13 Dec 2000 16:56:53 -0800 (PST) Subject: Could this autogen.sh script be added? Message-ID: Could someone add this autogen.sh script to the toplevel of openssh_cvs? Many projects include an autogen.sh script so that folks need not remember what auto commands need to get run and in what order. % cat autogen.sh #!/bin/sh # Run this program (./autogen.sh) after changing any of # the files that are used to automatically generate # other files. #aclocal autoheader autoconf #automake --ignore-deps thanks Mo DeJong Red Hat Inc From murray at dcci.cc Thu Dec 14 15:28:16 2000 From: murray at dcci.cc (Murray Hooper) Date: Wed, 13 Dec 2000 23:28:16 -0500 Subject: SCO OpenServer 5.0.5 port Message-ID: Just starting to go down the ssh road on SCO OpenServer. Has any started/completed a port of SSH2 to this platform? tia murray From tim at multitalents.net Thu Dec 14 16:03:01 2000 From: tim at multitalents.net (Tim Rice) Date: Wed, 13 Dec 2000 21:03:01 -0800 (PST) Subject: SCO OpenServer 5.0.5 port In-Reply-To: Message-ID: On Wed, 13 Dec 2000, Murray Hooper wrote: > Just starting to go down the ssh road on SCO OpenServer. > > Has any started/completed a port of SSH2 to this platform? I have a patched version of openssh-2.2.0p1 that works good. Most of my patch is in the current code base but if you are using the SCO compiler the newer code will not compile. If you are using gcc, it will probably work. > > tia > murray > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mouring at etoh.eviladmin.org Thu Dec 14 17:14:15 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 14 Dec 2000 00:14:15 -0600 (CST) Subject: SCO OpenServer 5.0.5 port In-Reply-To: Message-ID: On Wed, 13 Dec 2000, Tim Rice wrote: > On Wed, 13 Dec 2000, Murray Hooper wrote: > > > Just starting to go down the ssh road on SCO OpenServer. > > > > Has any started/completed a port of SSH2 to this platform? > > I have a patched version of openssh-2.2.0p1 that works good. > Most of my patch is in the current code base but if you are using > the SCO compiler the newer code will not compile. > If you are using gcc, it will probably work. > Damien backed out of required 64bit integers. So the current 2.3.0 snapshots should compile under SCO w/ a native compiler minus sftp-server which requires 64bit integers. I'm open to suggestions if someone has a patch for SCO w/ native compiler to support u_int64_t. As long as it's not extremely distruptive to the source. - Ben From provos at citi.umich.edu Thu Dec 14 16:19:00 2000 From: provos at citi.umich.edu (Niels Provos) Date: Thu, 14 Dec 2000 00:19:00 -0500 Subject: GMP in COPYING.Ylonen In-Reply-To: Kevin Steves, Wed, 13 Dec 2000 19:45:07 +0100 Message-ID: <20001214051900.79C05207C1@citi.umich.edu> In message , Kev in Steves writes: >should we continue to include COPYING.Ylonen in the portable release? i >see openbsd doesn't include it any longer (same REAMDE.Ylonen). I guess it should be removed. The other files contain all the relevant information. Niels. From tim at multitalents.net Thu Dec 14 17:37:09 2000 From: tim at multitalents.net (Tim Rice) Date: Wed, 13 Dec 2000 22:37:09 -0800 (PST) Subject: SCO OpenServer 5.0.5 port In-Reply-To: Message-ID: On Thu, 14 Dec 2000 mouring at etoh.eviladmin.org wrote: > On Wed, 13 Dec 2000, Tim Rice wrote: > > > On Wed, 13 Dec 2000, Murray Hooper wrote: > > > > > Just starting to go down the ssh road on SCO OpenServer. [snip] > > > Damien backed out of required 64bit integers. So the current 2.3.0 > snapshots should compile under SCO w/ a native compiler minus sftp-server > which requires 64bit integers. Cool, I'll try and find time this weekend to check out the CVS and give it a try. > > I'm open to suggestions if someone has a patch for SCO w/ native compiler > to support u_int64_t. As long as it's not extremely distruptive to the > source. > > > - Ben > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From djm at mindrot.org Thu Dec 14 22:55:17 2000 From: djm at mindrot.org (Damien Miller) Date: Thu, 14 Dec 2000 22:55:17 +1100 (EST) Subject: SCO OpenServer 5.0.5 port In-Reply-To: Message-ID: On Wed, 13 Dec 2000, Tim Rice wrote: > On Thu, 14 Dec 2000 mouring at etoh.eviladmin.org wrote: > > > On Wed, 13 Dec 2000, Tim Rice wrote: > > > > > On Wed, 13 Dec 2000, Murray Hooper wrote: > > > > > > > Just starting to go down the ssh road on SCO OpenServer. > [snip] > > > > > Damien backed out of required 64bit integers. So the current 2.3.0 > > snapshots should compile under SCO w/ a native compiler minus sftp-server > > which requires 64bit integers. > > Cool, I'll try and find time this weekend to check out the CVS and > give it a try. You may need to "make -k" (ignore errors) or equivalent to get ssh{,d}_config built - there is no autoconf logic to disable building of sftp-server, so compilation will fail. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From djm at mindrot.org Thu Dec 14 22:58:11 2000 From: djm at mindrot.org (Damien Miller) Date: Thu, 14 Dec 2000 22:58:11 +1100 (EST) Subject: Could this autogen.sh script be added? In-Reply-To: Message-ID: On Wed, 13 Dec 2000, Mo DeJong wrote: > Could someone add this autogen.sh script to the > toplevel of openssh_cvs? Most autogen.sh scripts I have seen do a "./configure $*" as well - or am I mistaken? -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From ksulliva at psc.edu Fri Dec 15 00:39:54 2000 From: ksulliva at psc.edu (Kevin Sullivan) Date: Thu, 14 Dec 2000 08:39:54 -0500 Subject: OpenSSH, Kth kerberos, and Digital Unix Message-ID: <3405.976801194@sludge.psc.edu> I've compiled OpenSSH 2.3.0p1 with Kerberos 4 from Kth (1.0.4). We use AFS heavily and need the AFS token passing features. This combo is working great on Irix and NetBSD/{alpha,i386}, but it's dying on Digital Unix (4.0f and 5.0). "ssh -v hostname" dumps core in des_pcbc_encrypt() after "Trying Kerberos authentication". My suspicion is that the des routines from OpenSSL and Kerberos are getting confused by the linker, but I'm not sure how to test that or fix it. Has anyone seen this before? Any suggestions? -Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 284 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001214/2cf1c9c5/attachment.bin From Jan.Iven at cern.ch Fri Dec 15 02:23:32 2000 From: Jan.Iven at cern.ch (Jan IVEN) Date: 14 Dec 2000 16:23:32 +0100 Subject: OpenSSH, Kth kerberos, and Digital Unix In-Reply-To: Kevin Sullivan's message of "Thu, 14 Dec 2000 08:39:54 -0500" References: <3405.976801194@sludge.psc.edu> Message-ID: >>>>> "KS" == Kevin Sullivan writes: KS> I've compiled OpenSSH 2.3.0p1 with Kerberos 4 from Kth (1.0.4). We use AFS KS> heavily and need the AFS token passing features. This combo is working KS> great on Irix and NetBSD/{alpha,i386}, but it's dying on Digital Unix (4.0f KS> and 5.0). KS> "ssh -v hostname" dumps core in des_pcbc_encrypt() after "Trying Kerberos KS> authentication". My suspicion is that the des routines from OpenSSL and KS> Kerberos are getting confused by the linker, but I'm not sure how to test KS> that or fix it. KS> Has anyone seen this before? Any suggestions? We have trouble with the self-test for DES from openssl-0.9.6 on Digital boxes (OSF1 refdux40f V4.0 1229 alpha). The tests produce lots of "unaligned access" errors and all of them fail (despite being converted transparently). If you have "uac noprint sigbus" on your machine, this might be the same problem in disguise? Best regards Jan From mstone at cs.loyola.edu Fri Dec 15 03:16:28 2000 From: mstone at cs.loyola.edu (Michael Stone) Date: Thu, 14 Dec 2000 11:16:28 -0500 Subject: password expiration Message-ID: <20001214111628.B20665@justice.loyola.edu> How are people handling password expirations in (non-pam) openssh? I'm currently running a program in the various startup scripts that reports to the user when their password will expire and runs passwd if that date is getting close. How are other people dealing with this? Is anyone working on integrating password changing into openssh? Is doing so even desired, since it's fairly trivial to implement outside of openssh? On a related note, there was a change some time ago which made allowed_user reject users whose password has been set to "force change" with passwd -f (or equivalent). (Specifically, the check for sp_lstchg was set to >= 0 rather than > 0). The result is that there's no way to force a user to change his password on next login, because doing so makes him unable to log in. Is there any reason not to reverse this? Digging throught the list archives, it looks like the change was suggested by stevesk at sweden.hp.com, but I don't see any discussion of why the new behavior is preferred. -- Mike Stone From mdejong at cygnus.com Fri Dec 15 05:47:14 2000 From: mdejong at cygnus.com (Mo DeJong) Date: Thu, 14 Dec 2000 10:47:14 -0800 (PST) Subject: Could this autogen.sh script be added? In-Reply-To: Message-ID: On Thu, 14 Dec 2000, Damien Miller wrote: > On Wed, 13 Dec 2000, Mo DeJong wrote: > > > Could someone add this autogen.sh script to the > > toplevel of openssh_cvs? > > Most autogen.sh scripts I have seen do a "./configure $*" as well - or > am I mistaken? You are not mistaken, it is the authors of some autogen.sh scripts that are mistaken. It is an error to actually call ./configure from inside an automake.sh script because the user may not want to build in the srcdir. For example, I might want to run: mkdir build_openssh ; cd build_openssh ../openssh_cvs/configure make If I download the CVS and then run ./autogen.sh and it goes ahead and runs ./configure in the srcdir, I would be very miffed. Mo DeJong Red Hat Inc From josb at cncdsl.com Fri Dec 15 13:05:26 2000 From: josb at cncdsl.com (Jos Backus) Date: Thu, 14 Dec 2000 18:05:26 -0800 Subject: scp without permitting shell access, possible? Message-ID: <20001214180526.C66873@lizzy.bugworks.com> [My apologies if this question is deemed inappropriate for this list.] Using OpenSSH, is it possible for a program/script to copy files with known filenames from a remote server (running sshd), without allowing (interactive) ssh access to that server? I.e. ``ssh server ls'' or ``ssh server'' should not be possible (for security reasons), but ``scp server:file .'' should. Thanks, -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From mouring at etoh.eviladmin.org Fri Dec 15 14:29:11 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 14 Dec 2000 21:29:11 -0600 (CST) Subject: scp without permitting shell access, possible? In-Reply-To: <20001214180526.C66873@lizzy.bugworks.com> Message-ID: On Thu, 14 Dec 2000, Jos Backus wrote: > [My apologies if this question is deemed inappropriate for this list.] > > Using OpenSSH, is it possible for a program/script to copy files with known > filenames from a remote server (running sshd), without allowing (interactive) > ssh access to that server? I.e. ``ssh server ls'' or ``ssh server'' should not > be possible (for security reasons), but ``scp server:file .'' should. > I don't see how you can do such a thing without changing how scp works. (Which is scp would no longer spawn the user's interactive shell, but either spawn /bin/sh w/ no .*rc files.) I'd have to test it.. but you may be able to pull it off with sftp-server. But I am not up on my 'subsystem' definations of SSH2. - Ben From maf at appgate.com Fri Dec 15 13:35:51 2000 From: maf at appgate.com (Martin Forssen) Date: Thu, 14 Dec 2000 18:35:51 -0800 (PST) Subject: scp without permitting shell access, possible? In-Reply-To: Message-ID: <20001215023551.03808317AA@pelee.firedoor.se> On 14 Dec, mouring at etoh.eviladmin.org wrote: > > On Thu, 14 Dec 2000, Jos Backus wrote: > >> [My apologies if this question is deemed inappropriate for this list.] >> >> Using OpenSSH, is it possible for a program/script to copy files with >> known filenames from a remote server (running sshd), without allowing >> (interactive) ssh access to that server? I.e. ``ssh server ls'' or >> ``ssh server'' should not be possible (for security reasons), but >> ``scp server:file .'' should. >> > I don't see how you can do such a thing without changing how scp > works. (Which is scp would no longer spawn the user's interactive > shell, but either spawn /bin/sh w/ no .*rc files.) > > I'd have to test it.. but you may be able to pull it off with > sftp-server. But I am not up on my 'subsystem' definations of SSH2. You could write a custom login-shell for the user on the server which only allows execution of the scp program. /MaF From jason at dfmm.org Fri Dec 15 13:37:29 2000 From: jason at dfmm.org (Jason Stone) Date: Thu, 14 Dec 2000 18:37:29 -0800 (PST) Subject: scp without permitting shell access, possible? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > [My apologies if this question is deemed inappropriate for this list.] I think it kind-of is, but that's okay. > Using OpenSSH, is it possible for a program/script to copy files with > known filenames from a remote server (running sshd), without allowing > (interactive) ssh access to that server? I.e. ``ssh server ls'' or > ``ssh server'' should not be possible (for security reasons), but > ``scp server:file .'' should. The way I usually do this is with keys and command squashing. "man sshd" for the details, but basically, you set up keys like normal ("man ssh-keygen") but in the authorized_keys file, you preface the key you want to restrict with restriction commands. an example: Say your rsa public key looks like: 1024 35 41249862493867123982176...lots of digits...11243590723 user at host You would tack onto the front command="scp -f " - so the line in your authorized_keys file would look like: command="scp -f " 1024 35 41249862...lots of digits...723 user at host all on one line. Now, whenever someone logs in with this key, no matter what command they try to run, the server will only (and always) run that scp. And you can add other restrictions too - for example, you should probablly prevent port forwarding to the machine, so the restriction string (all the text before the "1024 35 1212541512342...") might look like: command="scp -f ",no-port-forwarding,no-X11-forwarding,no-pty -Jason --------------------------- If the Revolution comes to grief, it will be because you and those you lead have become alarmed at your own brutality. --John Gardner -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE6OYPsswXMWWtptckRAoTTAJ4/vVoQ1IlflclcboPI8IaVFw01/gCgvuiR ZIzAHBOGyt+ekKPR5jEqWgo= =QsrM -----END PGP SIGNATURE----- From josb at cncdsl.com Fri Dec 15 13:45:29 2000 From: josb at cncdsl.com (Jos Backus) Date: Thu, 14 Dec 2000 18:45:29 -0800 Subject: scp without permitting shell access, possible? In-Reply-To: ; from jason@dfmm.org on Thu, Dec 14, 2000 at 06:37:07PM -0800 References: Message-ID: <20001214184529.A69117@lizzy.bugworks.com> On Thu, Dec 14, 2000 at 06:37:07PM -0800, Jason Stone wrote: > command="scp -f ",no-port-forwarding,no-X11-forwarding,no-pty I have thought of that, and am in fact using it for another application already. The problem is that varies. E.g. I fetch a well-known file(name) which, among others, contains the list of other files I need to fetch. It's not feasible to have separate identities for each file. Thanks, -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From josb at cncdsl.com Fri Dec 15 13:49:12 2000 From: josb at cncdsl.com (Jos Backus) Date: Thu, 14 Dec 2000 18:49:12 -0800 Subject: scp without permitting shell access, possible? In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Dec 14, 2000 at 09:28:49PM -0600 References: <20001214180526.C66873@lizzy.bugworks.com> Message-ID: <20001214184912.B69117@lizzy.bugworks.com> On Thu, Dec 14, 2000 at 09:28:49PM -0600, mouring at etoh.eviladmin.org wrote: > I don't see how you can do such a thing without changing how scp > works. (Which is scp would no longer spawn the user's interactive shell, > but either spawn /bin/sh w/ no .*rc files.) Yes, it seems like an all-or-nothing proposal. scp also enables interactive access, which you'd then have to hack around to close that "hole". > I'd have to test it.. but you may be able to pull it off with > sftp-server. But I am not up on my 'subsystem' definations of SSH2. Me neither. Maybe hsftp helps here? Thanks, -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From josb at cncdsl.com Fri Dec 15 13:50:32 2000 From: josb at cncdsl.com (Jos Backus) Date: Thu, 14 Dec 2000 18:50:32 -0800 Subject: scp without permitting shell access, possible? In-Reply-To: <20001215023551.03808317AA@pelee.firedoor.se>; from maf@appgate.com on Thu, Dec 14, 2000 at 06:35:29PM -0800 References: <20001215023551.03808317AA@pelee.firedoor.se> Message-ID: <20001214185032.C69117@lizzy.bugworks.com> On Thu, Dec 14, 2000 at 06:35:29PM -0800, Martin Forssen wrote: > You could write a custom login-shell for the user on the server which > only allows execution of the scp program. If I can't come up with any other solutions I may end up suggesting (and implementing) this, yes. Thanks, -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From rachit at ensim.com Fri Dec 15 13:54:52 2000 From: rachit at ensim.com (Rachit Siamwalla) Date: Thu, 14 Dec 2000 18:54:52 -0800 Subject: scp without permitting shell access, possible? References: <20001214180526.C66873@lizzy.bugworks.com> Message-ID: <3A3987FC.B567AF18@ensim.com> I did it in a very stupid, but simple way, implement a simple version of scp through a restricted shell. Which usually ends up going something like this: ssh hostname cat file > destfile where your restricted shell is /bin/cat Jos Backus wrote: > > [My apologies if this question is deemed inappropriate for this list.] > > Using OpenSSH, is it possible for a program/script to copy files with known > filenames from a remote server (running sshd), without allowing (interactive) > ssh access to that server? I.e. ``ssh server ls'' or ``ssh server'' should not > be possible (for security reasons), but ``scp server:file .'' should. > > Thanks, > -- > Jos Backus _/ _/_/_/ "Modularity is not a hack." > _/ _/ _/ -- D. J. Bernstein > _/ _/_/_/ > _/ _/ _/ _/ > josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From leakin at japh.itg.ti.com Fri Dec 15 14:03:48 2000 From: leakin at japh.itg.ti.com (Lee Eakin) Date: Thu, 14 Dec 2000 21:03:48 -0600 Subject: scp without permitting shell access, possible? In-Reply-To: <20001214184529.A69117@lizzy.bugworks.com>; from josb@cncdsl.com on Thu, Dec 14, 2000 at 06:45:29PM -0800 References: <20001214184529.A69117@lizzy.bugworks.com> Message-ID: <20001214210348.A21287@japh.itg.ti.com> Instead of setting command to 'scp -f file' you need to write a simple wrapper script and set command to that script. Then that script can parse thru the environment variable "SSH_ORIGIANL_COMMAND". If the command is 'scp -f ' and one of the allowed files then it exec's that command, otherwise it prints an error, (possibly logs or mails the admin of the attempted command) and exits. -Lee ---begin quoted text--- > Delivered-To: openssh-unix-dev-list-93873 at mindrot.org > Date: Thu, 14 Dec 2000 18:45:29 -0800 > From: Jos Backus > To: openssh-unix-dev at mindrot.org > Subject: Re: scp without permitting shell access, possible? > Reply-To: Jos Backus > User-Agent: Mutt/1.2.5i > > On Thu, Dec 14, 2000 at 06:37:07PM -0800, Jason Stone wrote: > > command="scp -f ",no-port-forwarding,no-X11-forwarding,no-pty > > I have thought of that, and am in fact using it for another application > already. > > The problem is that varies. E.g. I fetch a well-known file(name) which, > among others, contains the list of other files I need to fetch. It's not > feasible to have separate identities for each file. > > Thanks, > -- > Jos Backus _/ _/_/_/ "Modularity is not a hack." > _/ _/ _/ -- D. J. Bernstein > _/ _/_/_/ > _/ _/ _/ _/ > josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; ---end quoted text--- -- Lee Eakin - leakin at ti.com - Naming Services, Texas Instruments -o) [ permanent e-mail: Lee at Eakin.Org ] /\\ _\_v Farnsdick's corollary: After things have gone from bad to worse, the cycle will repeat itself. From gjb at cs.washington.edu Fri Dec 15 14:11:56 2000 From: gjb at cs.washington.edu (Greg Badros) Date: 14 Dec 2000 19:11:56 -0800 Subject: Preserving argument splitting with SSH Message-ID: I'm using: % ssh -V SSH Version OpenSSH-1.2.3, protocol version 1.5. Compiled with SSL. % uname -a Linux gellar 2.2.13 #1 SMP Wed Dec 29 14:07:41 PST 1999 i686 unknown and am wondering whether it's a fundamental shortcoming of the SSH protocol that argument splitting is not preserved from client to server, but instead the argument list is re-split on whitespace. E.g., from my machine `gellar', I execute: % ssh gellar args foo bar 'baz bong' ARG0 = /usr/home/gregb/bin/share/args, NumArgs = 4 1 = "foo" 2 = "bar" 3 = "baz" 4 = "bong" (where args is just a script that outputs the arguments), instead of what I get when I run args directly: % args foo bar 'baz bong' ARG0 = /usr/home/gregb/bin/share/args, NumArgs = 3 1 = "foo" 2 = "bar" 3 = "baz bong" which is much better. If it's not a limitation of the protocol, then it should be a pretty easy (and valuable!) fix. Please include me in replies as I'm not on the list. Thanks, Greg From leakin at japh.itg.ti.com Fri Dec 15 14:21:12 2000 From: leakin at japh.itg.ti.com (Lee Eakin) Date: Thu, 14 Dec 2000 21:21:12 -0600 Subject: Preserving argument splitting with SSH In-Reply-To: ; from gjb@cs.washington.edu on Thu, Dec 14, 2000 at 07:11:56PM -0800 References: Message-ID: <20001214212112.A21347@japh.itg.ti.com> The arg splitting is not preserved because it is parsed once by the local shell, and then again by the shell on the remote system. When the remote system's shell sees it the quotes are already gone. Try this: ssh gellar args foo bar \'baz bong\' or: ssh gellar args foo bar "'baz bong'" I think you'll see it parses properly then. -Lee ---begin quoted text--- > Delivered-To: openssh-unix-dev-list-93873 at mindrot.org > To: openssh-unix-dev at mindrot.org > Subject: Preserving argument splitting with SSH > From: Greg Badros > Date: 14 Dec 2000 19:11:56 -0800 > X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" > > I'm using: > > % ssh -V > SSH Version OpenSSH-1.2.3, protocol version 1.5. > Compiled with SSL. > % uname -a > Linux gellar 2.2.13 #1 SMP Wed Dec 29 14:07:41 PST 1999 i686 unknown > > and am wondering whether it's a fundamental shortcoming of the SSH > protocol that argument splitting is not preserved from client to server, > but instead the argument list is re-split on whitespace. E.g., from my > machine `gellar', I execute: > > % ssh gellar args foo bar 'baz bong' > ARG0 = /usr/home/gregb/bin/share/args, NumArgs = 4 > 1 = "foo" > 2 = "bar" > 3 = "baz" > 4 = "bong" > > (where args is just a script that outputs the arguments), instead of > what I get when I run args directly: > > % args foo bar 'baz bong' > ARG0 = /usr/home/gregb/bin/share/args, NumArgs = 3 > 1 = "foo" > 2 = "bar" > 3 = "baz bong" > > which is much better. If it's not a limitation of the protocol, then it > should be a pretty easy (and valuable!) fix. > > Please include me in replies as I'm not on the list. > > Thanks, > Greg ---end quoted text--- -- Lee Eakin - leakin at ti.com - Naming Services, Texas Instruments -o) [ permanent e-mail: Lee at Eakin.Org ] /\\ _\_v Allen's Axiom: When all else fails, follow instructions. From gem at rellim.com Fri Dec 15 14:52:19 2000 From: gem at rellim.com (Gary E. Miller) Date: Thu, 14 Dec 2000 19:52:19 -0800 (PST) Subject: scp without permitting shell access, possible? In-Reply-To: <20001214185032.C69117@lizzy.bugworks.com> Message-ID: Yo Martin! On Thu, Dec 14, 2000 at 06:35:29PM -0800, Martin Forssen wrote: > You could write a custom login-shell for the user on the server which > only allows execution of the scp program. I have done this. I created a short program that sets up a PATH that points to a directory (/usr/local/rbin) with just scp in it. Then exec()s to bash as a restricted shell. Just a few lines of C code and the user is now locked in with rbash. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 // gem - 13 Sep 00 // Gary E. Miller // // Description: // this is a cheap hack to be able to run a shell from /etc/passwd // with command line arguments and a restricted PATH // #include #include #include #include int main(int argc, char **argv) { int cnt = 0; char **my_argv = NULL; char **ptr_argv = NULL; // get a new argv array my_argv = calloc( argc + 5, sizeof(char*) ); if ( !my_argv ) { // out of RAM !? perror ( argv[0] ); // get out now exit(2); } // limit the users PATH, rbash will enforce it setenv("PATH", "/usr/local/rbin", 1); // set up the argv array my_argv[0] = "/bin/bash2"; // the command to run my_argv[1] = "--restricted"; // restrict it my_argv[2] = "--noprofile"; // really restrict it // need to pass the command line args to rbash // skip the first one (the name of this program) for ( cnt = 1; cnt < argc ; cnt++ ) { my_argv[cnt + 2] = argv[cnt]; } my_argv[cnt + 2] = NULL; // terminate the list // run the rbash execv( "/bin/bash", my_argv); // should return only on a serious error perror( argv[0] ); exit(1); } From peter at vanderlanden.nl Fri Dec 15 19:55:26 2000 From: peter at vanderlanden.nl (Peter van der Landen) Date: Fri, 15 Dec 2000 09:55:26 +0100 Subject: Even more secure FTP? Message-ID: <00e401c06675$58c842e0$1a897382@marune> L.S, I was very happy to find that OpenSSH 2.3.0 now has server support for F-Secure's Win32 FTP client. A problem I have run into a few times (and maybe others before me) is: I want to allow technically unsophisticated users to update their web pages without having to resort to running something like wu-ftpd on my system. SFTPD is a great solution for that since even a casual user can understand it's user interface (The Win32 scp client is not an acceptable solution in this case). SFTPD still leaves me with a few items on my wishlist that could be solved on the server side: - I would prefer it if some users would be limited to SFTP access and not be allowed ssh interactive access or scp. (this is similar to Jos Backus' request posted earlier on this list). - It would be great if a user using SFTP could (optionally and configurable per user) be chrooted to his homedirectory (or some other directory). Any chance of implementing this? Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001215/5b0d427f/attachment.html From mdejong at cygnus.com Fri Dec 15 20:05:33 2000 From: mdejong at cygnus.com (Mo DeJong) Date: Fri, 15 Dec 2000 01:05:33 -0800 (PST) Subject: Even more secure FTP? In-Reply-To: <00e401c06675$58c842e0$1a897382@marune> Message-ID: Humm, I seem to remember reading something like: "HTML mail is NOT PERMITTED on this list." And yet, Peter is posting in HTML. What gives Peter? Does this mailing list have a filter to automatically bounce messages in HTML format? If not, it seems like a very handy thing to add. Mo DeJong Red Hat Inc From peter at vanderlanden.nl Fri Dec 15 20:10:49 2000 From: peter at vanderlanden.nl (Peter van der Landen) Date: Fri, 15 Dec 2000 10:10:49 +0100 Subject: Even more secure FTP? Message-ID: <010d01c06676$eb2ad200$1a897382@marune> Mo & others: My sincere apologies for posting in HTML. I repeat my question in a civilized format (and crawl under a rock somewhere): L.S, I was very happy to find that OpenSSH 2.3.0 now has server support for F-Secure's Win32 FTP client. A problem I have run into a few times (and maybe others before me) is: I want to allow technically unsophisticated users to update their web pages without having to resort to running something like wu-ftpd on my system. SFTPD is a great solution for that since even a casual user can understand it's user interface (The Win32 scp client is not an acceptable solution in this case). SFTPD still leaves me with a few items on my wishlist that could be solved on the server side: - I would prefer it if some users would be limited to SFTP access and not be allowed ssh interactive access or scp. (this is similar to Jos Backus' request posted earlier on this list). - It would be great if a user using SFTP could (optionally and configurable per user) be chrooted to his homedirectory (or some other directory). Any chance of implementing this? Regards, Peter From mouring at etoh.eviladmin.org Sat Dec 16 04:07:39 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 15 Dec 2000 11:07:39 -0600 (CST) Subject: Even more secure FTP? In-Reply-To: <010d01c06676$eb2ad200$1a897382@marune> Message-ID: On Fri, 15 Dec 2000, Peter van der Landen wrote: > I want to allow technically unsophisticated users to update their web pages > without having to resort to running something like wu-ftpd on my system. > SFTPD is a great solution for that since even a casual user can understand > it's user interface (The Win32 scp client is not an acceptable solution in > this case). > > SFTPD still leaves me with a few items on my wishlist that could be solved > on the server side: > > - I would prefer it if some users would be limited to SFTP access and not be > allowed ssh interactive access or scp. (this is similar to Jos Backus' > request posted earlier on this list). > > - It would be great if a user using SFTP could (optionally and configurable > per user) be chrooted to his homedirectory (or some other directory). > Have you tried the contrib/chroot.diff ? This would at least limit users to their home directories. Unsure if anyone has testested it with SFTP. I would but I'm kinda booked up until Monday for anything remotely related to 'playing'. - Ben From gjb at cs.washington.edu Sat Dec 16 03:54:12 2000 From: gjb at cs.washington.edu (Greg Badros) Date: 15 Dec 2000 08:54:12 -0800 Subject: Preserving argument splitting with SSH In-Reply-To: Lee Eakin's message of "Thu, 14 Dec 2000 21:21:12 -0600" References: <20001214212112.A21347@japh.itg.ti.com> Message-ID: Lee Eakin writes: > The arg splitting is not preserved because it is parsed once by the local > shell, and then again by the shell on the remote system. When the remote > system's shell sees it the quotes are already gone. > > Try this: > ssh gellar args foo bar \'baz bong\' > or: > ssh gellar args foo bar "'baz bong'" > > I think you'll see it parses properly then. Right; I don't think I'd written clearly enough: you do not always need to run a shell at the remote end. In my example, just exec'ing with the appropriate argv and environment is sufficient. I was wondering about making ssh just Do The Right Thing (e.g., if there are no shell globs or shell metacharacters it clearly can just exec). Alternatively, perhaps there could be an option to just make the remote side do an exec directly rather than use a shell. Thanks for the response, Lee. And I apologize for not mentioning the two possible solutions I had in mind. Thanks, Greg > -Lee > > ---begin quoted text--- > > Delivered-To: openssh-unix-dev-list-93873 at mindrot.org > > To: openssh-unix-dev at mindrot.org > > Subject: Preserving argument splitting with SSH > > From: Greg Badros > > Date: 14 Dec 2000 19:11:56 -0800 > > X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" > > > > I'm using: > > > > % ssh -V > > SSH Version OpenSSH-1.2.3, protocol version 1.5. > > Compiled with SSL. > > % uname -a > > Linux gellar 2.2.13 #1 SMP Wed Dec 29 14:07:41 PST 1999 i686 unknown > > > > and am wondering whether it's a fundamental shortcoming of the SSH > > protocol that argument splitting is not preserved from client to server, > > but instead the argument list is re-split on whitespace. E.g., from my > > machine `gellar', I execute: > > > > % ssh gellar args foo bar 'baz bong' > > ARG0 = /usr/home/gregb/bin/share/args, NumArgs = 4 > > 1 = "foo" > > 2 = "bar" > > 3 = "baz" > > 4 = "bong" > > > > (where args is just a script that outputs the arguments), instead of > > what I get when I run args directly: > > > > % args foo bar 'baz bong' > > ARG0 = /usr/home/gregb/bin/share/args, NumArgs = 3 > > 1 = "foo" > > 2 = "bar" > > 3 = "baz bong" > > > > which is much better. If it's not a limitation of the protocol, then it > > should be a pretty easy (and valuable!) fix. > > > > Please include me in replies as I'm not on the list. > > > > Thanks, > > Greg > ---end quoted text--- > > -- > Lee Eakin - leakin at ti.com - Naming Services, Texas Instruments -o) > [ permanent e-mail: Lee at Eakin.Org ] /\\ > _\_v > Allen's Axiom: > When all else fails, follow instructions. From vsu at mivlgu.murom.ru Sat Dec 16 05:00:33 2000 From: vsu at mivlgu.murom.ru (Sergey Vlasov) Date: Fri, 15 Dec 2000 21:00:33 +0300 Subject: OpenSSH 2.3.0p1: Problem with the init script in the RPM Message-ID: <3A3A5C41.CD8C53A2@mivlgu.murom.ru> There is a problem in the contrib/redhat/sshd.init script: it starts sshd without specifying the full path (/usr/bin/sshd for the RPM installation). The daemon starts up and works, but dies when it receives a SIGHUP, because it is unable to re-exec itself without the full path. -------------- next part -------------- --- openssh-2.3.0p1/contrib/redhat/sshd.init.initfix Mon Oct 16 05:25:17 2000 +++ openssh-2.3.0p1/contrib/redhat/sshd.init Fri Dec 15 20:49:53 2000 @@ -57,7 +57,7 @@ echo -n "Starting sshd: " if [ ! -f $PID_FILE ] ; then - sshd + /usr/sbin/sshd RETVAL=$? if [ "$RETVAL" = "0" ] ; then success "sshd startup" From pekkas at netcore.fi Sat Dec 16 05:09:45 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 15 Dec 2000 20:09:45 +0200 (EET) Subject: OpenSSH 2.3.0p1: Problem with the init script in the RPM In-Reply-To: <3A3A5C41.CD8C53A2@mivlgu.murom.ru> Message-ID: On Fri, 15 Dec 2000, Sergey Vlasov wrote: > There is a problem in the contrib/redhat/sshd.init script: it starts > sshd without specifying the full path (/usr/bin/sshd for the RPM > installation). The daemon starts up and works, but dies when it receives > a SIGHUP, because it is unable to re-exec itself without the full path. This has been noted before (by me, at least). The problem is that sshd might not always be in /usr/sbin; for example, if you redefine %{_prefix} in your rpm macros to make all RPM's go under /usr/local (as a company policy, for example..), the script won't work. These people are a small minority, though. The change would be good for most people, but it might create problems for others. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From wyodlows at andromeda.rutgers.edu Sat Dec 16 05:20:00 2000 From: wyodlows at andromeda.rutgers.edu (William Yodlowsky) Date: Fri, 15 Dec 2000 13:20:00 -0500 Subject: istate / ostate error? Message-ID: <20001215131959.A5200@andromeda.rutgers.edu> Log snippet: channel 10: istate 4 != open channel 10: ostate 64 != open channel 11: istate 4 != open channel 11: ostate 64 != open channel 12: istate 4 != open channel 12: ostate 64 != open channel 13: istate 4 != open channel 13: ostate 64 != open channel 14: istate 4 != open channel 14: ostate 64 != open channel 15: istate 4 != open channel 15: ostate 64 != open % ssh -V SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090600f). This is on Solaris 8 SPARC with all the patches + OpenSSL 0.9.6. This install has been running since Nov 8 with no problems. A couple of days ago I started seeing those error messages in my sessions. The only change I made was to my syslog.conf, so perhaps it was doing it all along and no one noticed... I tried the FAQ, archives, web, and Deja and the only reference I found was the same problem in NetBSD's "version" of ssh. What to do? Thanks in advance. From markus.friedl at informatik.uni-erlangen.de Sat Dec 16 06:11:31 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 15 Dec 2000 20:11:31 +0100 Subject: fatal: xfree: NULL pointer given as argument (fwd) (fwd) Message-ID: <20001215201131.B16767@folly> fyi. have you seen this? -------------- next part -------------- An embedded message was scrubbed... From: Markus Friedl Subject: fatal: xfree: NULL pointer given as argument (fwd) Date: Fri, 15 Dec 2000 14:41:16 +0100 Size: 9024 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001215/2cdb43bc/attachment.mht From jss at ast.cam.ac.uk Sat Dec 16 02:15:36 2000 From: jss at ast.cam.ac.uk (Jeremy Sanders) Date: Fri, 15 Dec 2000 15:15:36 +0000 (GMT) Subject: Problem with openssh-2.3.0p1 man pages on Compaq Tru64 4.0 Message-ID: Hi The man pages don't format properly on Tru64 unix for portable openssh. They come out as a solid lump of text. I managed to fix the problem by including the line .so /usr/local/share/groff/tmac/tmac.andoc (I have GNU groff installed) In the man pages. It appears the OSF -man option on nroff doesn't format the pages correctly. Thanks Jeremy -- Jeremy Sanders http://www-xray.ast.cam.ac.uk/~jss/ Pembroke College, Cambridge. UK Institute of Astronomy, Cambridge. UK From johan at essay.org Sat Dec 16 02:52:10 2000 From: johan at essay.org (Johan F Ohman) Date: Fri, 15 Dec 2000 16:52:10 +0100 Subject: sshd demons Message-ID: <022c01c066ae$fbf69dc0$aefda8c0@demoen> Hi there, I'm having a problem with sshd demons not shuting down after connection is closed. The strange thing is that this is happening on both my Redhat 6.2 server and Redhat 7.0, both running OpenSSH_2.3.0p1. I'm positive that KeepAlive is set to yes ! Is this a common problem ? I'm suspecting that is has something to do with the client as well. Think we're all using vandyke.com's Secure CRT. I guess these bugs are really hard to track down :/ , and I'm not sure what info you need. But I just wanted to tell you that I assume something is wrong in the sshd program. -- JF? [root at fido johanfo]# /usr/sbin/sshd -version /usr/sbin/sshd: invalid option -- v sshd version OpenSSH_2.3.0p1 [root at fido johanfo]# uname -a Linux fido.workone.com 2.2.16-3 #1 Mon Jun 19 18:49:25 EDT 2000 i586 unknown [root at fido johanfo]# w 4:46pm up 106 days, 3:14, 24 users, load average: 0.37, 0.60, 0.87 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT johanfo pts/3 krs-dhcp005.stud 6Dec 0 8days 0.18s ? - johanfo pts/7 212.71.80.253 7Dec 0 8days 0.15s 0.15s -bash fls pts/1 s120a.studby.ntn 5Dec 0 9days 0.19s 0.19s -bash johanfo pts/6 krs-dhcp005.stud 6Dec 0 8days 0.18s ? - fls pts/8 s120a.studby.ntn 8Dec 0 7days 0.16s 0.16s -bash fls pts/9 s120a.studby.ntn 9Dec 0 6days 0.11s 0.11s -bash johanfo pts/10 krs-dhcp005.stud Sun 1pm 5days 0.07s 0.07s -bash johanfo pts/11 krs-dhcp005.stud Sun 2pm 5days 0.12s 0.12s -bash fls pts/13 s120a.studby.ntn Sun 2pm 5days 0.21s 0.21s -bash kristob pts/15 c245-s33-r12h5.u 3:29pm 1:02m 0.13s 0.01s man 5 crontab johanfo pts/14 krs-dhcp005.stud Thu 8pm 19:49m 0.56s ? - johanfo pts/16 krs-dhcp005.stud Thu10pm 17:25m 0.07s 0.07s -bash johanfo pts/17 212.71.80.253 4:40pm 0.00s 0.31s ? - kristob pts/5 62.65.28.66 Thu12pm 28:36m 0.08s 0.08s -bash From vsu at mivlgu.murom.ru Sat Dec 16 06:31:45 2000 From: vsu at mivlgu.murom.ru (Sergey Vlasov) Date: Fri, 15 Dec 2000 22:31:45 +0300 Subject: OpenSSH 2.3.0p1: Problem with the init script in the RPM References: Message-ID: <3A3A71A1.248C2EEA@mivlgu.murom.ru> Pekka Savola wrote: > > On Fri, 15 Dec 2000, Sergey Vlasov wrote: > > There is a problem in the contrib/redhat/sshd.init script: it starts > > sshd without specifying the full path (/usr/bin/sshd for the RPM > > installation). The daemon starts up and works, but dies when it receives > > a SIGHUP, because it is unable to re-exec itself without the full path. > > This has been noted before (by me, at least). > > The problem is that sshd might not always be in /usr/sbin; for example, > if you redefine %{_prefix} in your rpm macros to make all RPM's go under > /usr/local (as a company policy, for example..), the script won't work. > > These people are a small minority, though. The change would be good for > most people, but it might create problems for others. Then what about doing this: perl -pi -e 's,/usr/sbin/sshd,%{sbindir}/sshd,' \ $RPM_BUILD_ROOT/etc/rc.d/init.d/sshd in %install? The RPM is not relocatable anyway. Anyway, the older sshd.init-5.x and the SuSE script just use /usr/sbin/sshd. If someone wants to use non-default directories, they should know how to deal with these problems. From sunilvk at yahoo.com Sat Dec 16 06:44:27 2000 From: sunilvk at yahoo.com (Sunil Vallamkonda) Date: Fri, 15 Dec 2000 11:44:27 -0800 (PST) Subject: bug or feature ? Message-ID: <20001215194427.58565.qmail@web10408.mail.yahoo.com> Hello, I donot know if this is a bug or a feature or something that I need to configure... I have: RCSID("$OpenBSD: sshd.c,v 1.122 2000/07/11 08:11:34 deraadt Exp $"); I am experiencing a weird symptom when I run sshd on NetBSD1.4.1. When I run sshd -d (debug on), everything is fine. If I run sshd as stand alone (w/o debug on), sshd is in hug state, after following output: server: Could not load DSA host key: /usr/siara/config/ssh_host_dsa_key Disabling protocol version 2 Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. RSA key generation complete. and thus client cannot communicated with server. Any suggestions/ideas ? Thank you. Sunil. __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From leakin at japh.itg.ti.com Sat Dec 16 06:47:03 2000 From: leakin at japh.itg.ti.com (Lee Eakin) Date: Fri, 15 Dec 2000 13:47:03 -0600 Subject: Preserving argument splitting with SSH In-Reply-To: ; from gjb@cs.washington.edu on Fri, Dec 15, 2000 at 08:54:12AM -0800 References: <20001214212112.A21347@japh.itg.ti.com> Message-ID: <20001215134703.A26018@japh.itg.ti.com> I see what you are getting at now. Perl has some magic to decide whether or not it should invoke /bin/sh or just exec a command directly. I don't like the idea of magic (especially in a context of security), but an option to make ssh exec a command directly instead of thru the shell could be quite useful. Perhaps a '-o UseShell=no' or something similar in nature. It would still need to honor the 'command=' in the authorized_keys file so no holes are opened, but I can see how this sort of option would simplify automation. -Lee ---begin quoted text--- > To: Lee Eakin > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Preserving argument splitting with SSH > From: Greg Badros > Date: 15 Dec 2000 08:54:12 -0800 > X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" > > Lee Eakin writes: > > > The arg splitting is not preserved because it is parsed once by the local > > shell, and then again by the shell on the remote system. When the remote > > system's shell sees it the quotes are already gone. > > > > Try this: > > ssh gellar args foo bar \'baz bong\' > > or: > > ssh gellar args foo bar "'baz bong'" > > > > I think you'll see it parses properly then. > > Right; I don't think I'd written clearly enough: you do not always need > to run a shell at the remote end. In my example, just exec'ing with the > appropriate argv and environment is sufficient. I was wondering about > making ssh just Do The Right Thing (e.g., if there are no shell globs or > shell metacharacters it clearly can just exec). Alternatively, perhaps > there could be an option to just make the remote side do an exec > directly rather than use a shell. > > Thanks for the response, Lee. And I apologize for not mentioning the > two possible solutions I had in mind. > > Thanks, > Greg > > > > -Lee > > > > ---begin quoted text--- > > > Delivered-To: openssh-unix-dev-list-93873 at mindrot.org > > > To: openssh-unix-dev at mindrot.org > > > Subject: Preserving argument splitting with SSH > > > From: Greg Badros > > > Date: 14 Dec 2000 19:11:56 -0800 > > > X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" > > > > > > I'm using: > > > > > > % ssh -V > > > SSH Version OpenSSH-1.2.3, protocol version 1.5. > > > Compiled with SSL. > > > % uname -a > > > Linux gellar 2.2.13 #1 SMP Wed Dec 29 14:07:41 PST 1999 i686 unknown > > > > > > and am wondering whether it's a fundamental shortcoming of the SSH > > > protocol that argument splitting is not preserved from client to server, > > > but instead the argument list is re-split on whitespace. E.g., from my > > > machine `gellar', I execute: > > > > > > % ssh gellar args foo bar 'baz bong' > > > ARG0 = /usr/home/gregb/bin/share/args, NumArgs = 4 > > > 1 = "foo" > > > 2 = "bar" > > > 3 = "baz" > > > 4 = "bong" > > > > > > (where args is just a script that outputs the arguments), instead of > > > what I get when I run args directly: > > > > > > % args foo bar 'baz bong' > > > ARG0 = /usr/home/gregb/bin/share/args, NumArgs = 3 > > > 1 = "foo" > > > 2 = "bar" > > > 3 = "baz bong" > > > > > > which is much better. If it's not a limitation of the protocol, then it > > > should be a pretty easy (and valuable!) fix. > > > > > > Please include me in replies as I'm not on the list. > > > > > > Thanks, > > > Greg > > ---end quoted text--- > > > > -- > > Lee Eakin - leakin at ti.com - Naming Services, Texas Instruments -o) > > [ permanent e-mail: Lee at Eakin.Org ] /\\ > > _\_v > > Allen's Axiom: > > When all else fails, follow instructions. ---end quoted text--- -- Lee Eakin - leakin at ti.com - Naming Services, Texas Instruments -o) [ permanent e-mail: Lee at Eakin.Org ] /\\ _\_v If nobody uses something, there's probably a reason. From jmitchel at lucent.com Sat Dec 16 08:38:16 2000 From: jmitchel at lucent.com (James Mitchell) Date: Fri, 15 Dec 2000 15:38:16 -0600 (CST) Subject: GMP in COPYING.Ylonen In-Reply-To: <200012131854.eBDIsab27426@cvs.openbsd.org> Message-ID: Mr de Raadt, It seems odd somehow that a movement so founded on freedom and cooperation can be led by such fractious and uncooperative people as Mr Stalman and yourself. I apreciate your work with OpenBSD and especially OpenSSH, but please keep your petty squables to yourselves (and don't think I didn't chide RMS similarly). James Mitchell jmitchel at jmitchel.com On Wed, 13 Dec 2000, Theo de Raadt wrote: > > De Raadt hates the GNU Project so much, if a GNU person whispered to > > him that his fly was open, he would scream back in rage: "I won't zip > > it up for you!" > > > Wow, you're even more funny in email than you are when you talk!!!!! > > From jmitchel at lucent.com Sat Dec 16 08:43:18 2000 From: jmitchel at lucent.com (James Mitchell) Date: Fri, 15 Dec 2000 15:43:18 -0600 (CST) Subject: GMP in COPYING.Ylonen In-Reply-To: Message-ID: From stevesk at pobox.com Sat Dec 16 10:59:35 2000 From: stevesk at pobox.com (Kevin Steves) Date: Sat, 16 Dec 2000 00:59:35 +0100 (CET) Subject: Point in usernames / scp In-Reply-To: <3A342A98.27447416@isg.de> Message-ID: On Mon, 11 Dec 2000, Kai Engert wrote: : we are using usernames on our systems that contain a point '.', like : "r.john". : : We found it necessary to patch the source to make the "scp" command work : with those usernames. : : Cheers : Kai : : --- openssh-2.2.0p1/scp.c Wed Aug 30 01:11:30 2000 : +++ withpoint/scp.c Mon Dec 11 02:06:35 2000 : @@ -1042,7 +1042,7 @@ : c = *cp; : if (c & 0200) : goto bad; : - if (!isalpha(c) && !isdigit(c) && c != '_' && c != '-') : + if (!isalpha(c) && !isdigit(c) && c != '_' && c != '-' && c != '.') : goto bad; : } while (*++cp); : return (1); That change was intended a while back, but didn't get fully applied; it's now in the CVS tree. From stevesk at pobox.com Sat Dec 16 11:19:24 2000 From: stevesk at pobox.com (Kevin Steves) Date: Sat, 16 Dec 2000 01:19:24 +0100 (CET) Subject: password expiration In-Reply-To: <20001214111628.B20665@justice.loyola.edu> Message-ID: On Thu, 14 Dec 2000, Michael Stone wrote: : How are people handling password expirations in (non-pam) openssh? There's currently no support for this other than via PAM. : I'm currently running a program in the various startup scripts that : reports to the user when their password will expire and runs passwd if : that date is getting close. How are other people dealing with this? : Is anyone working on integrating password changing into openssh? Is : doing so even desired, since it's fairly trivial to implement outside of : openssh? I've been slowly working on a password interface but it's not ready to integrate yet. It would (eventually) include a change password capability. : On a related note, there was a change some time ago which made : allowed_user reject users whose password has been set to "force change" : with passwd -f (or equivalent). (Specifically, the check for sp_lstchg : was set to >= 0 rather than > 0). The result is that there's no way to : force a user to change his password on next login, because doing so : makes him unable to log in. Is there any reason not to reverse this? : Digging throught the list archives, it looks like the change was : suggested by stevesk at sweden.hp.com, but I don't see any discussion of : why the new behavior is preferred. Given that there wasn't functionality to force a user to change their password when sp_lstchg==0, I took a paranoid stance and decided to not let them login. Also we don't let users with expired passwords login either, so it was consistent with that. From lstein at presto.cshl.org Sat Dec 16 14:45:18 2000 From: lstein at presto.cshl.org (Lincoln Stein) Date: Fri, 15 Dec 2000 22:45:18 -0500 Subject: minor bug in channels.c Message-ID: <200012160345.WAA06596@localhost.cshl.org> On openssh-2.2.0p1, I found that with certain Linux kernel configurations the check for unsupported address families in channels.c fails because the errno returned is EAFNOSUPPORT rather than EINVAL. This causes the sshd server to terminate when trying to set up X11 forwarding. A patch is enclosed. Keep up the great work! Best, Lincoln -- ======================================================================== Lincoln D. Stein Cold Spring Harbor Laboratory lstein at cshl.org Cold Spring Harbor, NY Positions available at my lab: see http://stein.cshl.org/#hire ======================================================================== *** channels.c.orig Tue Aug 22 20:46:24 2000 --- channels.c Fri Dec 15 22:35:48 2000 *************** *** 1740,1746 **** continue; sock = socket(ai->ai_family, SOCK_STREAM, 0); if (sock < 0) { ! if (errno != EINVAL) { error("socket: %.100s", strerror(errno)); return NULL; } else { --- 1740,1746 ---- continue; sock = socket(ai->ai_family, SOCK_STREAM, 0); if (sock < 0) { ! if (errno != EINVAL && errno != EAFNOSUPPORT) { error("socket: %.100s", strerror(errno)); return NULL; } else { From markus.friedl at informatik.uni-erlangen.de Sat Dec 16 20:26:29 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 16 Dec 2000 10:26:29 +0100 Subject: bug or feature ? In-Reply-To: <20001215194427.58565.qmail@web10408.mail.yahoo.com>; from sunilvk@yahoo.com on Fri, Dec 15, 2000 at 11:44:27AM -0800 References: <20001215194427.58565.qmail@web10408.mail.yahoo.com> Message-ID: <20001216102629.B24998@folly> On Fri, Dec 15, 2000 at 11:44:27AM -0800, Sunil Vallamkonda wrote: > Could not load DSA host key: > /usr/siara/config/ssh_host_dsa_key > Disabling protocol version 2 > Server listening on 0.0.0.0 port 22. > Generating 768 bit RSA key. > RSA key generation complete. > > > and thus client cannot communicated with server. why not? protocol 1 is not disabled. it also seens that the hostkey is not valid. -markus From markus.friedl at informatik.uni-erlangen.de Sat Dec 16 20:28:21 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 16 Dec 2000 10:28:21 +0100 Subject: Preserving argument splitting with SSH In-Reply-To: <20001215134703.A26018@japh.itg.ti.com>; from leakin@japh.itg.ti.com on Fri, Dec 15, 2000 at 01:47:03PM -0600 References: <20001214212112.A21347@japh.itg.ti.com> <20001215134703.A26018@japh.itg.ti.com> Message-ID: <20001216102821.C24998@folly> On Fri, Dec 15, 2000 at 01:47:03PM -0600, Lee Eakin wrote: > Perhaps a '-o UseShell=no' or something similar in nature. the client cannot tell the server about this. it's a server side policy. moreover, many site do accouting via loginshell binaries, so the loginshell must be executed. From leakin at japh.itg.ti.com Sun Dec 17 06:04:56 2000 From: leakin at japh.itg.ti.com (Lee Eakin) Date: Sat, 16 Dec 2000 13:04:56 -0600 Subject: Preserving argument splitting with SSH In-Reply-To: <20001216102821.C24998@folly>; from markus.friedl@informatik.uni-erlangen.de on Sat, Dec 16, 2000 at 10:28:21AM +0100 References: <20001214212112.A21347@japh.itg.ti.com> <20001215134703.A26018@japh.itg.ti.com> <20001216102821.C24998@folly> Message-ID: <20001216130456.A30694@japh.itg.ti.com> I thought there might be good reason this feature was not already in there. It also dawns on me that the account might be disabled by setting the shell to /bin/false and this would be a hole in that case as well. -Lee ---begin quoted text--- > From: Markus Friedl > > On Fri, Dec 15, 2000 at 01:47:03PM -0600, Lee Eakin wrote: > > Perhaps a '-o UseShell=no' or something similar in nature. > > the client cannot tell the server about this. > it's a server side policy. > > moreover, many site do accouting via loginshell binaries, > so the loginshell must be executed. ---end quoted text--- -- Fourth Law of Thermodynamics: If the probability of success is not almost one, then it is damned near zero. From jfortin at revelex.com Mon Dec 18 09:23:05 2000 From: jfortin at revelex.com (Jonathan Fortin) Date: Sun, 17 Dec 2000 17:23:05 -0500 Subject: Portable OpenSSH Solaris UseLogin Issue In-Reply-To: Message-ID: Greetings, In order to use solaris's BSM (Basic security module) also called c2 audit, which logs specific kernel calls depending on your audit_control, I would need to use login(1) to log users exec calls and whatnot because Portable OpenSSH does not have support, now that would mean I would have to enable Uselogin in sshd_config in order for that to work. I am running openssh's latest portable version on Solaris 7 core install with latest patches. When I enabled Uselogin, and I ssh with debug mode on, I get the following: Environment: TZ=US/Eastern SSH_CLIENT=x.x.x.x 34951 22 SSH_TTY=/dev/pts/3 TERM=vt100 No utmpx entry. You must exec "login" from the lowest level "shell". Connection to x.x.x.x closed. Here's my debug output from sshd: Connection from x.x.x.x port 34949 debug: Client protocol version 1.5; client software version x.x.x debug: Local version string SSH-1.5-x.x.x debug: Sent 1152 bit public key and 1024 bit host key. debug: Encryption type: 3des debug: Received session key; encryption turned on. debug: Installing crc compensation attack detector. debug: Attempting authentication for xxxxxx. Accepted password for xxxxx from x.x.x.x port 34949 debug: session_new: init debug: session_new: session 0 debug: Allocating pty. debug: Entering interactive session. debug: fd 3 setting O_NONBLOCK debug: server_init_dispatch_13 debug: server_init_dispatch_15 debug: tvp!=NULL kid 0 mili 10 debug: Received SIGCHLD. debug: tvp!=NULL kid 1 mili 10 debug: tvp!=NULL kid 1 mili 10 debug: tvp!=NULL kid 1 mili 100 debug: End of interactive session; stdin 0, stdout (read 171, sent 171), stderr 0 bytes. debug: Command exited with status 1. debug: Received exit confirmation. debug: session_pty_cleanup: session 0 release /dev/pts/3 Closing connection to 10.10.1.31 I also tryed giving mode 777 to both sshd and login and it did not work to see if that would make a difference. Telnetting in works so I don't see a problem with login(1) or utmp[x]. Could it be a broken implementation of Uselogin in Solaris? Any help is appreciated.. Sincerely, Jonathan From stevesk at sweden.hp.com Mon Dec 18 14:49:12 2000 From: stevesk at sweden.hp.com (Kevin Steves) Date: Mon, 18 Dec 2000 04:49:12 +0100 (CET) Subject: SCO remove() and unlink() Message-ID: There was a patch merged in on 9/29 that changed remove() calls to unlink(): - (djm) Merged big SCO portability patch from Tim Rice Does SCO's libc not include remove()? Note that sftp-server.c is currently using remove. The reason I ask is I'd like to keep the portable tree as close to openbsd as possible, and if we need remove() for SCO we should add a bsd-remove.c or something. From Markus.Friedl at informatik.uni-erlangen.de Mon Dec 18 19:03:28 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 18 Dec 2000 09:03:28 +0100 Subject: Portable OpenSSH Solaris UseLogin Issue In-Reply-To: ; from jfortin@revelex.com on Sun, Dec 17, 2000 at 05:23:05PM -0500 References: Message-ID: <20001218090328.A21281@faui02.informatik.uni-erlangen.de> does telnetd call login? how does telnetd call login? On Sun, Dec 17, 2000 at 05:23:05PM -0500, Jonathan Fortin wrote: > In order to use solaris's BSM (Basic security module) also called c2 audit, > which logs specific kernel calls depending on your audit_control, > I would need to use login(1) to log users exec calls and whatnot because > Portable OpenSSH does not have support, now that would mean I > would have to enable Uselogin in sshd_config in order for that to work. From Markus.Friedl at informatik.uni-erlangen.de Mon Dec 18 19:05:01 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 18 Dec 2000 09:05:01 +0100 Subject: SCO remove() and unlink() In-Reply-To: ; from stevesk@sweden.hp.com on Mon, Dec 18, 2000 at 04:49:12AM +0100 References: Message-ID: <20001218090501.B21281@faui02.informatik.uni-erlangen.de> in the openbsd cvs tree both remove and unlink are used. i think, i will switch to unlink() only. On Mon, Dec 18, 2000 at 04:49:12AM +0100, Kevin Steves wrote: > There was a patch merged in on 9/29 that changed remove() calls to > unlink(): > > - (djm) Merged big SCO portability patch from Tim Rice > > > Does SCO's libc not include remove()? Note that sftp-server.c is > currently using remove. The reason I ask is I'd like to keep the > portable tree as close to openbsd as possible, and if we need remove() > for SCO we should add a bsd-remove.c or something. > From jason at dfmm.org Mon Dec 18 19:45:09 2000 From: jason at dfmm.org (Jason Stone) Date: Mon, 18 Dec 2000 00:45:09 -0800 (PST) Subject: Preserving argument splitting with SSH In-Reply-To: <20001215134703.A26018@japh.itg.ti.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > but an option to make ssh exec a command directly instead of thru the > shell could be quite useful. Perhaps a '-o UseShell=no' or something > similar in nature. I quite agree. You couldn't do it from the client side, but it should be an option on the server side. The reason for this is because I frequently want to allow some users to run particular commands via command-squashed keys, but I don't want to give the accounts real shells - I want sshd to fork the commands directly, not to go through the shell. This should at least be an option. -Jason --------------------------- If the Revolution comes to grief, it will be because you and those you lead have become alarmed at your own brutality. --John Gardner -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE6Pc6YswXMWWtptckRAptTAJ4rCRJkvOJz56PPWQqXd3p3vbyicQCfW4t/ pCLJYokkM4bMSacRoj6g0hc= =R7Yu -----END PGP SIGNATURE----- From gert at greenie.muc.de Mon Dec 18 19:47:24 2000 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 18 Dec 2000 09:47:24 +0100 Subject: SCO remove() and unlink() In-Reply-To: ; from Kevin Steves on Mon, Dec 18, 2000 at 04:49:12AM +0100 References: Message-ID: <20001218094724.B28872@greenie.muc.de> Hi, On Mon, Dec 18, 2000 at 04:49:12AM +0100, Kevin Steves wrote: > There was a patch merged in on 9/29 that changed remove() calls to > unlink(): > > - (djm) Merged big SCO portability patch from Tim Rice > > > Does SCO's libc not include remove()? Note that sftp-server.c is > currently using remove. The reason I ask is I'd like to keep the > portable tree as close to openbsd as possible, and if we need remove() > for SCO we should add a bsd-remove.c or something. Hmmm, well, unlink() is the "more standard" function, so I'd vote for using unlink() everywhere (even in the OpenBSD tree). OTOH, we don't need a bsd-remove.c - just add something like #ifndef HAVE_REMOVE # define remove(a) unlink(a) #endif to "defines.h" would be sufficient. Actually, this is exactly what my SCO (OpenServer 3.0) does in - which means that programs using remove() have to include for it to work. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From johan.adolfsson at axis.com Tue Dec 19 00:22:58 2000 From: johan.adolfsson at axis.com (Johan Adolfsson) Date: Mon, 18 Dec 2000 14:22:58 +0100 Subject: cross compiling configure errors Message-ID: <022f01c068f5$a386f1a0$0a070d0a@pcjohana.axis.se> Hi all! I want to cross compile openssh to our own CPU and our embedded Linux platform, however I get at least the following errors when running configure: checking whether snprintf correctly terminates long strings... configure: error: can not run test program while cross compiling checking whether getpgrp takes no argument... configure: error: cannot check getpgrp if cross compiling checking for OpenSSL directory... configure: error: can not run test program while cross compiling checking for RSA support... configure: error: can not run test program while cross compiling I'm not really familiar with configure/autoconf etc. and wonder if there are any better solution then adding "if test "$cross_compiling" = no; then fi" around the failing tests? I feel that there must be more people doing cross compiling out there? I can't find anything in the FAQ or in the mail archives. When running autoconf I get: configure.in:337: warning: AC_TRY_RUN called without default to allow cross compiling configure.in:446: warning: AC_TRY_RUN called without default to allow cross compiling configure.in:492: warning: AC_TRY_RUN called without default to allow cross compiling configure.in:955: warning: Cannot check for file existence when cross compiling configure.in:962: warning: Cannot check for file existence when cross compiling configure.in:985: warning: Cannot check for file existence when cross compiling which seems to indicate that it should handle cross compiling, at least for the 3 first messages. Any hints? /Johan From Donald.Smith at qwest.com Tue Dec 19 01:17:34 2000 From: Donald.Smith at qwest.com (Smith, Donald ) Date: Mon, 18 Dec 2000 07:17:34 -0700 Subject: cross compiling configure errors Message-ID: <2D00AD0E4D36D411BD300008C786E4240125826D@Denntex021.qwest.net> These errors make sense. If your crosscompiling any test that involves running a binary on your local host should fail because your compiling for a different platform. The same can be said for "real" lib path checks. The path checks don't make sense on your local host only on the target host. Having said that these errors do serve to remind the compiler (the person not the software) that some of the tests were not run. So the compiler (the person not the software) needs to either check these by hand and/or hardcode known information into the Makefile that matches the target system (Yes to RSA if you know you have rsa support on the target....) -----Original Message----- From: Johan Adolfsson [mailto:johan.adolfsson at axis.com] Sent: Monday, December 18, 2000 6:23 AM To: openssh-unix-dev at mindrot.org Subject: cross compiling configure errors Hi all! I want to cross compile openssh to our own CPU and our embedded Linux platform, however I get at least the following errors when running configure: checking whether snprintf correctly terminates long strings... configure: error: can not run test program while cross compiling checking whether getpgrp takes no argument... configure: error: cannot check getpgrp if cross compiling checking for OpenSSL directory... configure: error: can not run test program while cross compiling checking for RSA support... configure: error: can not run test program while cross compiling I'm not really familiar with configure/autoconf etc. and wonder if there are any better solution then adding "if test "$cross_compiling" = no; then fi" around the failing tests? I feel that there must be more people doing cross compiling out there? I can't find anything in the FAQ or in the mail archives. When running autoconf I get: configure.in:337: warning: AC_TRY_RUN called without default to allow cross compiling configure.in:446: warning: AC_TRY_RUN called without default to allow cross compiling configure.in:492: warning: AC_TRY_RUN called without default to allow cross compiling configure.in:955: warning: Cannot check for file existence when cross compiling configure.in:962: warning: Cannot check for file existence when cross compiling configure.in:985: warning: Cannot check for file existence when cross compiling which seems to indicate that it should handle cross compiling, at least for the 3 first messages. Any hints? /Johan From ruf at tik.ee.ethz.ch Tue Dec 19 01:44:10 2000 From: ruf at tik.ee.ethz.ch (Lukas Ruf) Date: Mon, 18 Dec 2000 15:44:10 +0100 Subject: OpenSSHd: PATHs in configuration files Message-ID: <20001218154410.A15158@ee.ethz.ch> Dear all, is it possible to specify the default paths in the appropriate configuration of the Daemon ? If not, wouldn't it make sense to include that feature as the configuration files get parsed anyway ? What do you mean ? Kind regards, Lukas -- Lukas Ruf Swiss Federal Institute of Technology Office: ETZ-G61.2 Computer Engineering and Phone: +41/1/632 7312 Networks Laboratory (TIK) Fax: +41/1/632 1035 ETH Zentrum PGP 2.6: ID D20BA2ED; Gloriastr. 35 Fingerprint 6323 B9BC 9C8E 6563 B477 BADD FEA6 E6B7 CH-8092 Zurich From Jan.Iven at cern.ch Tue Dec 19 01:48:45 2000 From: Jan.Iven at cern.ch (Jan IVEN) Date: 18 Dec 2000 15:48:45 +0100 Subject: scp remote path specification Message-ID: Hello, in order to use "scp", the scp binary has to be in the compile-time default path on the remote host. For some users (like root), we try to avoid this since scp may be on a network file system (AFS/NFS), and we don't want to hang root's session on network outages. Would a patch to scp be acceptable in the main tree that allows to set the path to remote scp explicity, either as a new command line or as an ENV variable (it looks like a ssh config file parameter won't work, since the file is not read by scp itself). I know that a workaround is to put "PATH=/path/to/bla" into these user's .ssh/environment or as a parameter to their key, but I don't want this PATH to be taken for interactive use. Please advise. Best regards Jan Iven PS: a small patch so that /full/path/to/scp will find the corresponding local /full/path/to/ssh is appended below. --- openssh/scp.c~ Sat Oct 28 05:19:58 2000 +++ openssh/scp.c Tue Nov 7 17:59:37 2000 @@ -245,7 +245,7 @@ char *argv[]; { int ch, fflag, tflag; - char *targ; + char *targ, *pathsep; extern char *optarg; extern int optind; @@ -253,6 +253,19 @@ addargs("ssh"); /* overwritten with ssh_program */ addargs("-x"); addargs("-oFallBackToRsh no"); + + /* check explicit path for ssh binary, default is SSH_PROGRAM */ + if ((argc > 0) && + (argv[0] != NULL)) { + pathsep = strrchr(argv[0], '/'); + if (pathsep != NULL) { + pathsep++; + *pathsep = 0; + ssh_program = xmalloc(strlen(argv[0]) + 4); /* "../path" + "ssh\0" */ + strcpy(ssh_program, argv[0]); + strcat(ssh_program, "ssh"); + } + } fflag = tflag = 0; while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q46S:o:")) != EOF) From pekkas at netcore.fi Tue Dec 19 02:02:24 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 18 Dec 2000 17:02:24 +0200 (EET) Subject: scp remote path specification In-Reply-To: Message-ID: On 18 Dec 2000, Jan IVEN wrote: > Hello, > > in order to use "scp", the scp binary has to be in the compile-time > default path on the remote host. For some users (like root), we try to > avoid this since scp may be on a network file system (AFS/NFS), and we > don't want to hang root's session on network outages. > > Would a patch to scp be acceptable in the main tree that allows to set > the path to remote scp explicity, either as a new command line or as > an ENV variable (it looks like a ssh config file parameter won't work, > since the file is not read by scp itself). > > I know that a workaround is to put "PATH=/path/to/bla" into these user's > .ssh/environment or as a parameter to their key, but I don't want this > PATH to be taken for interactive use. > > Please advise. > > Best regards > Jan Iven > > PS: a small patch so that /full/path/to/scp will find the > corresponding local /full/path/to/ssh is appended below. If I'm not mistaken, with this you can force the remote server to execute a trojaned ssh, if you run e.g. '/tmp/scp user at remote:xxx .' and have managed to create /tmp/ssh on the remote system. Doesn't look good as this this breaks sshd expectations with regard to PATH and what users can control. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From Jan.Iven at cern.ch Tue Dec 19 02:24:08 2000 From: Jan.Iven at cern.ch (Jan IVEN) Date: 18 Dec 2000 16:24:08 +0100 Subject: scp remote path specification In-Reply-To: Pekka Savola's message of "Mon, 18 Dec 2000 17:02:24 +0200 (EET)" References: Message-ID: >>>>> "PS" == Pekka Savola writes: PS> On 18 Dec 2000, Jan IVEN wrote: >> Hello, >> >> in order to use "scp", the scp binary has to be in the compile-time >> default path on the remote host. For some users (like root), we try to >> avoid this since scp may be on a network file system (AFS/NFS), and we >> don't want to hang root's session on network outages. >> >> Would a patch to scp be acceptable in the main tree that allows to set >> the path to remote scp explicity, either as a new command line or as >> an ENV variable (it looks like a ssh config file parameter won't work, >> since the file is not read by scp itself). >> >> I know that a workaround is to put "PATH=/path/to/bla" into these user's >> .ssh/environment or as a parameter to their key, but I don't want this >> PATH to be taken for interactive use. >> >> Please advise. >> >> Best regards >> Jan Iven >> >> PS: a small patch so that /full/path/to/scp will find the >> corresponding local /full/path/to/ssh is appended below. PS> If I'm not mistaken, with this you can force the remote server to execute PS> a trojaned ssh, if you run e.g. '/tmp/scp user at remote:xxx .' and have PS> managed to create /tmp/ssh on the remote system. PS> Doesn't look good as this this breaks sshd expectations with regard to PS> PATH and what users can control. Not sure whether the remark applies to the proposed stuff or the attached patch. My understanding of the execution sequence is as follows: local: scp user at remote:xxx local scp runs local ssh, specifies remote command "scp": ssh user at remote scp -{r|-t} xxx local ssh contacts remote server, authenticates remote server runs "scp" in user context proposed change: pass "/path/to/scp" as command to server instead of "scp". Still runs in user context, and can be done directly from ssh as well right now (without using local scp). No additional security risk as far as I can see. attached patch: help local scp find the local ssh. Server is not involved. Security risk if you can get somebody to run a version of scp (with full path) that lives in a directory with a trojan ssh, so the trojan will get executed in local user context. But if permissions on the directory allow for an trojan ssh, they probably allow for installation of a trojaned scp as well. Please correct me if I'm wrong. Regards Jan From Markus.Friedl at informatik.uni-erlangen.de Tue Dec 19 02:41:43 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 18 Dec 2000 16:41:43 +0100 Subject: scp remote path specification In-Reply-To: ; from Jan.Iven@cern.ch on Mon, Dec 18, 2000 at 03:48:45PM +0100 References: Message-ID: <20001218164143.B16853@faui02.informatik.uni-erlangen.de> you cannot assume that the path for the remote scp is the same as for the local scp. it's better to add an option to scp, e.g.: $ scp -X /remote/path/to/scp /etc/passwd otherhost:/etc -m On Mon, Dec 18, 2000 at 03:48:45PM +0100, Jan IVEN wrote: > Hello, > > in order to use "scp", the scp binary has to be in the compile-time > default path on the remote host. For some users (like root), we try to > avoid this since scp may be on a network file system (AFS/NFS), and we > don't want to hang root's session on network outages. > > Would a patch to scp be acceptable in the main tree that allows to set > the path to remote scp explicity, either as a new command line or as > an ENV variable (it looks like a ssh config file parameter won't work, > since the file is not read by scp itself). > > I know that a workaround is to put "PATH=/path/to/bla" into these user's > .ssh/environment or as a parameter to their key, but I don't want this > PATH to be taken for interactive use. > > Please advise. > > Best regards > Jan Iven > > PS: a small patch so that /full/path/to/scp will find the > corresponding local /full/path/to/ssh is appended below. > > --- openssh/scp.c~ Sat Oct 28 05:19:58 2000 > +++ openssh/scp.c Tue Nov 7 17:59:37 2000 > @@ -245,7 +245,7 @@ > char *argv[]; > { > int ch, fflag, tflag; > - char *targ; > + char *targ, *pathsep; > extern char *optarg; > extern int optind; > > @@ -253,6 +253,19 @@ > addargs("ssh"); /* overwritten with ssh_program */ > addargs("-x"); > addargs("-oFallBackToRsh no"); > + > + /* check explicit path for ssh binary, default is SSH_PROGRAM */ > + if ((argc > 0) && > + (argv[0] != NULL)) { > + pathsep = strrchr(argv[0], '/'); > + if (pathsep != NULL) { > + pathsep++; > + *pathsep = 0; > + ssh_program = xmalloc(strlen(argv[0]) + 4); /* "../path" + "ssh\0" */ > + strcpy(ssh_program, argv[0]); > + strcat(ssh_program, "ssh"); > + } > + } > > fflag = tflag = 0; > while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q46S:o:")) != EOF) > > From Markus.Friedl at informatik.uni-erlangen.de Tue Dec 19 02:42:27 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 18 Dec 2000 16:42:27 +0100 Subject: scp remote path specification In-Reply-To: ; from pekkas@netcore.fi on Mon, Dec 18, 2000 at 05:02:24PM +0200 References: Message-ID: <20001218164227.C16853@faui02.informatik.uni-erlangen.de> On Mon, Dec 18, 2000 at 05:02:24PM +0200, Pekka Savola wrote: > If I'm not mistaken, with this you can force the remote server to execute > a trojaned ssh, if you run e.g. '/tmp/scp user at remote:xxx .' and have > managed to create /tmp/ssh on the remote system. what's the point? you can call $ ssh remote /tmp/ssh in any case. -m From pekkas at netcore.fi Tue Dec 19 02:59:48 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 18 Dec 2000 17:59:48 +0200 (EET) Subject: scp remote path specification In-Reply-To: <20001218164227.C16853@faui02.informatik.uni-erlangen.de> Message-ID: On Mon, 18 Dec 2000, Markus Friedl wrote: > On Mon, Dec 18, 2000 at 05:02:24PM +0200, Pekka Savola wrote: > > If I'm not mistaken, with this you can force the remote server to execute > > a trojaned ssh, if you run e.g. '/tmp/scp user at remote:xxx .' and have > > managed to create /tmp/ssh on the remote system. > > what's the point? > > you can call > $ ssh remote /tmp/ssh > in any case. Oh, the user context has already been changed at this point. How unthoughtful of me. :-) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From rob at hagopian.net Tue Dec 19 03:58:00 2000 From: rob at hagopian.net (Rob Hagopian) Date: Mon, 18 Dec 2000 11:58:00 -0500 (EST) Subject: Hanging ssh Message-ID: OK, with openssh-SNAP-20001218 I still have the problem of a hanging ssh when running (one specific) command on a server. On the server side, there's a small suid C prog (/usr/dh/mgmt/HupServer) that runs system "/usr/local/apache/bin/apachectl stop/start". Incidentally, apachectl is a shell script, hence the need for a suid wrapper for non-root users... On the client side, there's a shell script that removes the machine from load balancing and then stops/starts the webserver by sshing to the server and running the C prog there. The problem doesn't arise if I run the HupServer program from the command line, only from within the shell script that does the load balancing enable/disable. In that script, the 'stop' command has no problems, only 'start'. - I assumed that a fd was being left open, so I added: close(2); close(1); close(0); exit(0); to the C prog, but with no affect... - Last I checked the -t switch had no affect... - Hitting Ctrl-C on either debug run finishes the process up cleanly - During the hanging there is no HupServer executable running on the server - The problem was diminished, but not eliminated, by the prior patches to end the connection before the fds were closed. Any ideas on how I can work around this? Would forking HupServer be of any use? -Rob The ssh dump: SSH Version OpenSSH_2.3.0p2, protocol versions 1.5/2.0. Compiled with SSL (0x0090581f). debug: Reading configuration data /etc/ssh/ssh_config debug: Applying options for * debug: ssh_connect: getuid 500 geteuid 0 anon 0 debug: Connecting to dhumb400 [10.40.10.10] port 22. debug: Allocated local port 1022. debug: Connection established. debug: identity file /home/prod/.ssh/identity type 0 debug: identity file /home/prod/.ssh/id_dsa type 3 debug: Remote protocol version 1.99, remote software version OpenSSH_2.3.0p2 debug: no match: OpenSSH_2.3.0p2 Enabling compatibility mode for protocol 2.0 debug: Local version string SSH-2.0-OpenSSH_2.3.0p2 debug: Seeding random number generator debug: send KEXINIT debug: done debug: wait KEXINIT debug: got kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug: got kexinit: ssh-dss,ssh-rsa debug: got kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug: got kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com debug: got kexinit: none,zlib debug: got kexinit: none,zlib debug: got kexinit: debug: got kexinit: debug: first kex follow: 0 debug: reserved: 0 debug: done debug: kex: server->client arcfour hmac-sha1 none debug: kex: client->server arcfour hmac-sha1 none debug: Sending SSH2_MSG_KEX_DH_GEX_REQUEST. debug: Wait SSH2_MSG_KEX_DH_GEX_GROUP. debug: Got SSH2_MSG_KEX_DH_GEX_GROUP. debug: bits set: 1002/2049 debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. debug: Got SSH2_MSG_KEXDH_REPLY. debug: Host 'dhumb400' is known and matches the RSA host key. debug: bits set: 1034/2049 debug: ssh_rsa_verify: signature correct debug: Wait SSH2_MSG_NEWKEYS. debug: GOT SSH2_MSG_NEWKEYS. debug: send SSH2_MSG_NEWKEYS. debug: done: send SSH2_MSG_NEWKEYS. debug: done: KEX2. debug: send SSH2_MSG_SERVICE_REQUEST debug: service_accept: ssh-userauth debug: got SSH2_MSG_SERVICE_ACCEPT debug: authentications that can continue: publickey,password debug: next auth method to try is publickey debug: try pubkey: /home/prod/.ssh/id_dsa debug: read SSH2 private key done: name dsa w/o comment success 1 debug: sig size 20 20 debug: ssh-userauth2 successfull: method publickey debug: channel 0: new [client-session] debug: send channel open 0 debug: Entering interactive session. debug: client_init id 0 arg 0 debug: Sending command: /usr/dh/mgmt/scripts/HupServer start debug: channel 0: open confirm rwindow 0 rmax 16384 Environment: USER=prod LOGNAME=prod HOME=/usr/dh/home/prod PATH=/usr/dh/home/prod/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin MAIL=/var/mail/prod SHELL=/usr/local/bin/tcsh SSH_CLIENT=10.40.12.11 1022 22 /usr/local/apache/bin/apachectl start: httpd started debug: client_input_channel_req: rtype exit-status reply 0 Connection to dhumb400 closed by remote host. debug: Transferred: stdin 0, stdout 0, stderr 47 bytes in 138.8 seconds debug: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.3 debug: Exit status 0 and the sshd dump: debug1: sshd version OpenSSH_2.3.0p2 debug1: load_private_key_autodetect: type 0 RSA1 debug1: read SSH2 private key done: name dsa w/o comment success 1 debug1: load_private_key_autodetect: type 2 DSA debug1: read SSH2 private key done: name rsa w/o comment success 1 debug1: load_private_key_autodetect: type 1 RSA debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 10.40.12.11 port 1022 debug1: Client protocol version 2.0; client software version OpenSSH_2.3.0p2 debug1: no match: OpenSSH_2.3.0p2 Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_2.3.0p2 debug1: list_hostkey_types: ssh-dss,ssh-rsa debug1: send KEXINIT debug1: done debug1: wait KEXINIT debug1: got kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug1: got kexinit: ssh-rsa,ssh-dss debug1: got kexinit: arcfour,3des-cbc,blowfish-cbc,cast128-cbc debug1: got kexinit: arcfour,3des-cbc,blowfish-cbc,cast128-cbc debug1: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com debug1: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com debug1: got kexinit: none debug1: got kexinit: none debug1: got kexinit: debug1: got kexinit: debug1: first kex follow: 0 debug1: reserved: 0 debug1: done debug1: kex: client->server arcfour hmac-sha1 none debug1: kex: server->client arcfour hmac-sha1 none debug1: Wait SSH2_MSG_KEX_DH_GEX_REQUEST. debug1: Sending SSH2_MSG_KEX_DH_GEX_GROUP. debug1: bits set: 1034/2049 debug1: Wait SSH2_MSG_KEX_DH_GEX_INIT. debug1: bits set: 1002/2049 debug1: send SSH2_MSG_NEWKEYS. debug1: done: send SSH2_MSG_NEWKEYS. debug1: Wait SSH2_MSG_NEWKEYS. debug1: GOT SSH2_MSG_NEWKEYS. debug1: done: KEX2. debug1: userauth-request for user prod service ssh-connection method none debug1: attempt #1 debug1: Starting up PAM with username "prod" Failed none for prod from 10.40.12.11 port 1022 ssh2 debug1: userauth-request for user prod service ssh-connection method publickey debug1: attempt #2 debug1: matching key found: file /usr/dh/home/prod/.ssh/authorized_keys2, line 2 debug1: len 55 datafellows 0 debug1: ssh_dss_verify: signature correct Could not reverse map address 10.40.12.11. debug1: PAM setting rhost to "10.40.12.11" Accepted publickey for prod from 10.40.12.11 port 1022 ssh2 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 32768 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 channel 0 request exec reply 0 debug1: PAM establishing creds debug1: fd 7 setting O_NONBLOCK debug1: fd 7 IS O_NONBLOCK debug1: fd 9 setting O_NONBLOCK debug1: Received SIGCHLD. debug1: tvp!=NULL kid 1 mili 100 debug1: session_by_pid: pid 34260 debug1: session_exit_message: session 0 channel 0 pid 34260 debug1: session_exit_message: release channel 0 debug1: channel 0: write failed debug1: channel 0: output open -> closed debug1: channel 0: close_write debug1: session_free: session 0 pid 34260 From stevesk at pobox.com Tue Dec 19 04:40:42 2000 From: stevesk at pobox.com (Kevin Steves) Date: Mon, 18 Dec 2000 18:40:42 +0100 (CET) Subject: SCO remove() and unlink() In-Reply-To: <20001218090501.B21281@faui02.informatik.uni-erlangen.de> Message-ID: On Mon, 18 Dec 2000, Markus Friedl wrote: : in the openbsd cvs tree both remove and unlink are : used. i think, i will switch to unlink() only. that would be great. all the remove()'s were deleting files, and rmdir() was handled separately. From stevesk at pobox.com Tue Dec 19 04:45:23 2000 From: stevesk at pobox.com (Kevin Steves) Date: Mon, 18 Dec 2000 18:45:23 +0100 (CET) Subject: SCO remove() and unlink() In-Reply-To: <20001218094724.B28872@greenie.muc.de> Message-ID: On Mon, 18 Dec 2000, Gert Doering wrote: : OTOH, we don't need a bsd-remove.c - just add something like : : #ifndef HAVE_REMOVE : # define remove(a) unlink(a) : #endif remove() can also delete directories. From johan.adolfsson at axis.com Tue Dec 19 05:11:49 2000 From: johan.adolfsson at axis.com (Johan Adolfsson) Date: Mon, 18 Dec 2000 19:11:49 +0100 Subject: cross compiling configure errors Message-ID: <038001c0691d$fe130000$0a070d0a@pcjohana.axis.se> I agree that the tests make sense, but the problem is that configure failes and exists when it reaches an error and you don't get a Makefile created that you can tweak, "./configure --help" wont give much help either. There should be options to override the settings that normally fails during cross compiling, or the AC_TRY_RUN should do something "useful" in the cross compile section. Are there/should there be any way to run configure so that it skips these tests? E.g. something like --with-correct-snprintf / --with-incorrect-snprintf Or add cross compile action to AC_TRY_RUN : AC_MSG_RESULT(yes) AC_MSG_WARN([** Cross compiling, assuming correct snprintf ]) (or be on the "safe" side and assume it's broken?) --with-getpgrp-void (BTW: Wouldn't it be possible to test this without running a testprogram, just compile and check the warnings and assume the header files are correct? Is the AC_FUNC_GETPGRP macro really ok?) --with-ssl-dir=xxx This exists, but doesn't prevent the tests, shouldn't it? AC_TRY_LINK instead of AC_TRY_RUN seems to fix the OpenSSL test for me, wonder if it breaks it for someone else? :) --with-rsaref Or should the AC_TRY_RUN macros have an [action-if-cross-compiling] entry, e.g: echo "Cross compiling, assuming RSA works" rsa_works=1 break; or AC_MSG_WARN( [ ** Cross compiling, use rsa_works=1 if RSA works]) break; Setting rsa_work=1 before running configure works for me. Some of the "options" to skip tests are "hidden" in the configure.in, they really should be mentioned when doing "./configure --help": no_rsa rsa_work no_dev_ptmx no_dev_ptc (missing, but should be there I think) There is also the issue when crosscompiling that some paths should be with prefix and some without. The Makefile has the variable DESTDIR that looks like it fixes that problem. I have now managed to get it through configure and quite far in the build process, but now it fails on sshd.c: gcc_cris -melinux -muclibc=/home/johana/e2/eroot -O2 -Wall -D__linux__ -DELI NUX -DGETPGRP_VOID=1 -Wall -I. -I. -I/home/johana/e2/eroot/include -DETCDIR= \"/etc\" -DSSH_PROGRAM=\"/bin/ssh\" -DSSH_ASKPASS_DEFAULT=\"/libexec/ssh-ask pass\" -DHAVE_CONFIG_H -c sshd.c -o sshd.o sshd.c: In function `main': sshd.c:864: warning: implicit declaration of function `howmany' sshd.c:864: `fd_mask' undeclared (first use this function) sshd.c:864: (Each undeclared identifier is reported only once sshd.c:864: for each function it appears in.) make[1]: *** [sshd.o] Error 1 Any hints on this one? I have attached a patch file that I hope is reasonable in size, any chance some of it gets into the distribution? Best regards /Johan -----Original Message----- From: Smith, Donald To: 'Johan Adolfsson' ; openssh-unix-dev at mindrot.org Date: Monday, December 18, 2000 15:26 Subject: RE: cross compiling configure errors >These errors make sense. If your crosscompiling any test that involves >running a binary on your local >host should fail because your compiling for a different platform. The same >can be said for "real" lib path >checks. The path checks don't make sense on your local host only on the >target host. >Having said that these errors do serve to remind the compiler (the person >not the software) that >some of the tests were not run. So the compiler (the person not the >software) needs to either check these >by hand and/or hardcode known information into the Makefile that matches the >target system (Yes to RSA if >you know you have rsa support on the target....) > -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh_configure_in.patch Type: application/octet-stream Size: 1561 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001218/ddaf507c/attachment.obj From tim at multitalents.net Tue Dec 19 05:29:44 2000 From: tim at multitalents.net (Tim Rice) Date: Mon, 18 Dec 2000 10:29:44 -0800 (PST) Subject: SCO remove() and unlink() In-Reply-To: Message-ID: On Mon, 18 Dec 2000, Kevin Steves wrote: > There was a patch merged in on 9/29 that changed remove() calls to > unlink(): > > - (djm) Merged big SCO portability patch from Tim Rice > > > Does SCO's libc not include remove()? Note that sftp-server.c is SCO's 3.2v4.2 does not have remove(). The version of openssh I patched was not implementing sftp yet so I didn't catch that one. > currently using remove. The reason I ask is I'd like to keep the > portable tree as close to openbsd as possible, and if we need remove() > for SCO we should add a bsd-remove.c or something. That would work. > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Tue Dec 19 05:39:55 2000 From: tim at multitalents.net (Tim Rice) Date: Mon, 18 Dec 2000 10:39:55 -0800 (PST) Subject: SCO remove() and unlink() In-Reply-To: <20001218094724.B28872@greenie.muc.de> Message-ID: On Mon, 18 Dec 2000, Gert Doering wrote: > Hi, > > On Mon, Dec 18, 2000 at 04:49:12AM +0100, Kevin Steves wrote: > > There was a patch merged in on 9/29 that changed remove() calls to > > unlink(): > > > > - (djm) Merged big SCO portability patch from Tim Rice > > > > > > Does SCO's libc not include remove()? Note that sftp-server.c is > > currently using remove. The reason I ask is I'd like to keep the > > portable tree as close to openbsd as possible, and if we need remove() > > for SCO we should add a bsd-remove.c or something. > > Hmmm, well, unlink() is the "more standard" function, so I'd vote for > using unlink() everywhere (even in the OpenBSD tree). > > OTOH, we don't need a bsd-remove.c - just add something like > > #ifndef HAVE_REMOVE > # define remove(a) unlink(a) > #endif > > to "defines.h" would be sufficient. Actually, this is exactly what my SCO > (OpenServer 3.0) does in - which means that programs using > remove() have to include for it to work. Now I remember, ----------- #if __STDC__ #define remove(name) (__unlink(name)) #else #define remove(name) (unlink(name)) #endif /* __STDC__ */ -------------------- This is what caused me the problems. I was using gcc and it had trouble with __unlink() Perhaps my gcc (2.7.2.1) is slightly broken. > > gert > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From morgan at transmeta.com Tue Dec 19 06:07:21 2000 From: morgan at transmeta.com (Andrew Morgan) Date: Mon, 18 Dec 2000 11:07:21 -0800 Subject: auth-pam.c support for pam_chauthtok() References: Message-ID: <3A3E6069.5CB8EB8D@transmeta.com> [Much time passes, and I'm working my way through 1600 ssh messages..] I believe this patch contains a bug. Its really a Sun documentation bug that no one noticed until 4 years after Linux had a working PAM implementation (read, its not going to change in the Linux implementation of PAM now) and two years after Sun released their first PAM support. Basically, the patch as submitted, included this diff (auth-pam.c): - for(count = 0; count < num_msg; count++) { - switch (msg[count]->msg_style) { + for (count = 0; count < num_msg; count++) { + switch ((*msg)[count].msg_style) { Note, the 'msg' got replaced with '(*msg)'. For single prompts (count=0) thanks to 'C' these two are identical. Unfortunately, the former (-) is correct for Linux-PAM, and the latter (+) is correct for Solaris. For (count!=0) these two differ. [FWIW, some PAM module vendors actually supply msg pointers that doubly link to the actual messages. But, in the main, Linux differs from Solaris on this point.] If it isn't clear: * Linux provides a pointer to an array of message pointers. * Solaris provides a pointer to a pointer to an array of message structures (yes this is somewhat bizzarre with one unnecessary level of indirection). Please conditionalize the above change with something like this: ========= /* Note, the original PAM spec was unclear on the nature of the 'msg' pointer passed to the conversation function. Solaris (and thus HPUX - who's PAM is based on the Sun codebase), assumed a second level of indirection, Linux (and basically every other OS since they use the Linux-PAM source code) interpreted this as a pointer to an array of pointers. Here we support both with a little bit of macro redirection. */ #ifdef closed-source-base-from-sun (solaris, hpux) # define PMSG (*msg) #else /* 99.9% likely to be a port of Linux-PAM */ # define PMSG msg #endif ========= And then pepper the code with PMSG instead of what's there now: s/(*msg)/PMSG/g . Thanks Andrew Damien Miller wrote: > > On Wed, 13 Sep 2000, Steve VanDevender wrote: > > > When we installed OpenSSH 2.1.1p4 on our Solaris systems, our users > > noticed that it did not honor password expiration consistently with > > other Solaris login services. > > > > The patch below is against OpenSSH 2.2.0p1 and adds support for PAM > > password changes on expiration via pam_chauthtok(). A brief summary of > > changes: > > Thanks - applied. > > -d From GILBERT.R.LOOMIS at saic.com Tue Dec 19 06:10:14 2000 From: GILBERT.R.LOOMIS at saic.com (Loomis, Rip) Date: Mon, 18 Dec 2000 14:10:14 -0500 Subject: Portable OpenSSH Solaris UseLogin Issue Message-ID: <791BD3CB503DD411A6510008C7CF6477F8C2EF@COL-581-EXS01> Aarggh. Telnetd has the necessary audit initialization code (and generation of login/logout audit events) written in by Sun. The "best" fix (IMHO) is to do the audit initialization within OpenSSH, in the same way that OpenSSH needs to do it for SGI IRIX, etc., and in the same way that telnetd does it for Solaris. I have code (which was written for a previous customer against "commercial" SSH 1.2.27) that correctly implements all the audit initialization stuff for Solaris. I've been trying to make the time to integrate the code into OpenSSH for several months, but Real Work keeps intruding. Does someone want the existing (not real pretty but workable) code against 1.2.27 as a starting point? If not then I'll try to make time in the next couple of weeks, but trying to make time hasn't historically seemed to work. The biggest stumbling block when I last went in to integrate the code was that (IIRC) OpenSSH calls one "session initialization" function which is common to both the ssh client and sshd. This caused some problems...but I'll excavate my codebase again now and take another look this afternoon. Rip Loomis Voice Number: (410) 953-6874 -------------------------------------------------------- Senior Security Engineer Center for Information Security Technology Science Applications International Corporation http://www.cist.saic.com > -----Original Message----- > From: Markus Friedl [mailto:Markus.Friedl at informatik.uni-erlangen.de] > Sent: Monday, December 18, 2000 3:03 AM > To: Jonathan Fortin > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Portable OpenSSH Solaris UseLogin Issue > > > does telnetd call login? how does telnetd call login? > > On Sun, Dec 17, 2000 at 05:23:05PM -0500, Jonathan Fortin wrote: > > In order to use solaris's BSM (Basic security module) also > called c2 audit, > > which logs specific kernel calls depending on your audit_control, > > I would need to use login(1) to log users exec calls and > whatnot because > > Portable OpenSSH does not have support, now > that would mean I > > would have to enable Uselogin in sshd_config in order for > that to work. > From mouring at etoh.eviladmin.org Tue Dec 19 07:59:08 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 18 Dec 2000 14:59:08 -0600 (CST) Subject: [PATCH] Separate CFLAGS and CPPFLAGS In-Reply-To: <200012070216.SAA26867@scv1.apple.com> Message-ID: On Wed, 6 Dec 2000, Wilfredo Sanchez wrote: > > Attached should be a patch that splits CFLAGS into CFLAGS and CPPFLAGS. > > Oh, much better. I'm feeling rather stupid for not having checked > configure. I even know better. > > Thanks, > -Fred > Since I've not heard anything outside the HP/UX -Ae question.. (Which I moved back over to being a CFLAGS entry) I've applied my patch. Let me know if when it hits the snapshots if it causes any problems. From rachit at ensim.com Tue Dec 19 07:15:36 2000 From: rachit at ensim.com (Rachit Siamwalla) Date: Mon, 18 Dec 2000 12:15:36 -0800 Subject: Hanging ssh References: Message-ID: <3A3E7068.9D35D93D@ensim.com> does this happen if you test this through rsh? If so, i've had a similar problem (unfortunately no good solution though). The way i "solved" the problem is writing my own shellscript that had the same effect. apachectl is probably a shell script too. try cutting out only what is needed and narrow the problem down from there. -rchit Rob Hagopian wrote: > > OK, with openssh-SNAP-20001218 I still have the problem of a hanging ssh > when running (one specific) command on a server. On the server side, > there's a small suid C prog (/usr/dh/mgmt/HupServer) that runs system > "/usr/local/apache/bin/apachectl stop/start". Incidentally, apachectl is a > shell script, hence the need for a suid wrapper for non-root users... On > the client side, there's a shell script that removes the machine from load > balancing and then stops/starts the webserver by sshing to the server and > running the C prog there. > > The problem doesn't arise if I run the HupServer program from the command > line, only from within the shell script that does the load balancing > enable/disable. In that script, the 'stop' command has no problems, only > 'start'. > > - I assumed that a fd was being left open, so I added: > close(2); close(1); close(0); exit(0); > to the C prog, but with no affect... > - Last I checked the -t switch had no affect... > - Hitting Ctrl-C on either debug run finishes the process up cleanly > - During the hanging there is no HupServer executable running on the > server > - The problem was diminished, but not eliminated, by the prior patches to > end the connection before the fds were closed. > > Any ideas on how I can work around this? Would forking HupServer be of any > use? > -Rob > > The ssh dump: > > SSH Version OpenSSH_2.3.0p2, protocol versions 1.5/2.0. > Compiled with SSL (0x0090581f). > debug: Reading configuration data /etc/ssh/ssh_config > debug: Applying options for * > debug: ssh_connect: getuid 500 geteuid 0 anon 0 > debug: Connecting to dhumb400 [10.40.10.10] port 22. > debug: Allocated local port 1022. > debug: Connection established. > debug: identity file /home/prod/.ssh/identity type 0 > debug: identity file /home/prod/.ssh/id_dsa type 3 > debug: Remote protocol version 1.99, remote software version > OpenSSH_2.3.0p2 > debug: no match: OpenSSH_2.3.0p2 > Enabling compatibility mode for protocol 2.0 > debug: Local version string SSH-2.0-OpenSSH_2.3.0p2 > debug: Seeding random number generator > debug: send KEXINIT > debug: done > debug: wait KEXINIT > debug: got > kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > debug: got kexinit: ssh-dss,ssh-rsa > debug: got > kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se > debug: got > kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se > debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > debug: got kexinit: none,zlib > debug: got kexinit: none,zlib > debug: got kexinit: > debug: got kexinit: > debug: first kex follow: 0 > debug: reserved: 0 > debug: done > debug: kex: server->client arcfour hmac-sha1 none > debug: kex: client->server arcfour hmac-sha1 none > debug: Sending SSH2_MSG_KEX_DH_GEX_REQUEST. > debug: Wait SSH2_MSG_KEX_DH_GEX_GROUP. > debug: Got SSH2_MSG_KEX_DH_GEX_GROUP. > debug: bits set: 1002/2049 > debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. > debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. > debug: Got SSH2_MSG_KEXDH_REPLY. > debug: Host 'dhumb400' is known and matches the RSA host key. > debug: bits set: 1034/2049 > debug: ssh_rsa_verify: signature correct > debug: Wait SSH2_MSG_NEWKEYS. > debug: GOT SSH2_MSG_NEWKEYS. > debug: send SSH2_MSG_NEWKEYS. > debug: done: send SSH2_MSG_NEWKEYS. > debug: done: KEX2. > debug: send SSH2_MSG_SERVICE_REQUEST > debug: service_accept: ssh-userauth > debug: got SSH2_MSG_SERVICE_ACCEPT > debug: authentications that can continue: publickey,password > debug: next auth method to try is publickey > debug: try pubkey: /home/prod/.ssh/id_dsa > debug: read SSH2 private key done: name dsa w/o comment success 1 > debug: sig size 20 20 > debug: ssh-userauth2 successfull: method publickey > debug: channel 0: new [client-session] > debug: send channel open 0 > debug: Entering interactive session. > debug: client_init id 0 arg 0 > debug: Sending command: /usr/dh/mgmt/scripts/HupServer start > debug: channel 0: open confirm rwindow 0 rmax 16384 > Environment: > USER=prod > LOGNAME=prod > HOME=/usr/dh/home/prod > PATH=/usr/dh/home/prod/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin > MAIL=/var/mail/prod > SHELL=/usr/local/bin/tcsh > SSH_CLIENT=10.40.12.11 1022 22 > /usr/local/apache/bin/apachectl start: httpd started > debug: client_input_channel_req: rtype exit-status reply 0 > Connection to dhumb400 closed by remote host. > debug: Transferred: stdin 0, stdout 0, stderr 47 bytes in 138.8 seconds > debug: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.3 > debug: Exit status 0 > > and the sshd dump: > debug1: sshd version OpenSSH_2.3.0p2 > debug1: load_private_key_autodetect: type 0 RSA1 > debug1: read SSH2 private key done: name dsa w/o comment success 1 > debug1: load_private_key_autodetect: type 2 DSA > debug1: read SSH2 private key done: name rsa w/o comment success 1 > debug1: load_private_key_autodetect: type 1 RSA > debug1: Bind to port 22 on 0.0.0.0. > Server listening on 0.0.0.0 port 22. > Generating 768 bit RSA key. > RSA key generation complete. > debug1: Server will not fork when running in debugging mode. > Connection from 10.40.12.11 port 1022 > debug1: Client protocol version 2.0; client software version > OpenSSH_2.3.0p2 > debug1: no match: OpenSSH_2.3.0p2 > Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-1.99-OpenSSH_2.3.0p2 > debug1: list_hostkey_types: ssh-dss,ssh-rsa > debug1: send KEXINIT > debug1: done > debug1: wait KEXINIT > debug1: got > kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > debug1: got kexinit: ssh-rsa,ssh-dss > debug1: got kexinit: arcfour,3des-cbc,blowfish-cbc,cast128-cbc > debug1: got kexinit: arcfour,3des-cbc,blowfish-cbc,cast128-cbc > debug1: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > debug1: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > debug1: got kexinit: none > debug1: got kexinit: none > debug1: got kexinit: > debug1: got kexinit: > debug1: first kex follow: 0 > debug1: reserved: 0 > debug1: done > debug1: kex: client->server arcfour hmac-sha1 none > debug1: kex: server->client arcfour hmac-sha1 none > debug1: Wait SSH2_MSG_KEX_DH_GEX_REQUEST. > debug1: Sending SSH2_MSG_KEX_DH_GEX_GROUP. > debug1: bits set: 1034/2049 > debug1: Wait SSH2_MSG_KEX_DH_GEX_INIT. > debug1: bits set: 1002/2049 > debug1: send SSH2_MSG_NEWKEYS. > debug1: done: send SSH2_MSG_NEWKEYS. > debug1: Wait SSH2_MSG_NEWKEYS. > debug1: GOT SSH2_MSG_NEWKEYS. > debug1: done: KEX2. > debug1: userauth-request for user prod service ssh-connection method none > debug1: attempt #1 > debug1: Starting up PAM with username "prod" > Failed none for prod from 10.40.12.11 port 1022 ssh2 > debug1: userauth-request for user prod service ssh-connection method > publickey > debug1: attempt #2 > debug1: matching key found: file /usr/dh/home/prod/.ssh/authorized_keys2, > line 2 > debug1: len 55 datafellows 0 > debug1: ssh_dss_verify: signature correct > Could not reverse map address 10.40.12.11. > debug1: PAM setting rhost to "10.40.12.11" > Accepted publickey for prod from 10.40.12.11 port 1022 ssh2 > debug1: Entering interactive session for SSH2. > debug1: server_init_dispatch_20 > debug1: server_input_channel_open: ctype session rchan 0 win 65536 max > 32768 > debug1: input_session_request > debug1: channel 0: new [server-session] > debug1: session_new: init > debug1: session_new: session 0 > debug1: session_open: channel 0 > debug1: session_open: session 0: link with channel 0 > debug1: server_input_channel_open: confirm session > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 channel 0 request exec reply > 0 > debug1: PAM establishing creds > debug1: fd 7 setting O_NONBLOCK > debug1: fd 7 IS O_NONBLOCK > debug1: fd 9 setting O_NONBLOCK > debug1: Received SIGCHLD. > debug1: tvp!=NULL kid 1 mili 100 > debug1: session_by_pid: pid 34260 > debug1: session_exit_message: session 0 channel 0 pid 34260 > debug1: session_exit_message: release channel 0 > debug1: channel 0: write failed > debug1: channel 0: output open -> closed > debug1: channel 0: close_write > debug1: session_free: session 0 pid 34260 From mouring at etoh.eviladmin.org Tue Dec 19 08:24:32 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 18 Dec 2000 15:24:32 -0600 (CST) Subject: Hanging ssh In-Reply-To: <3A3E7068.9D35D93D@ensim.com> Message-ID: What platform? I know Linux has such an issue. The patch to resolve the issue caused scp to not complete it's transfers under meduim loads so it was removed. I have/had (somewhere) a hack to work around scp for protocol 1. That did not SEEM to cause problems.. But I was not happy with it. I've not been able to verify but does the old 1.2.16 source tree from ssh.com produce the same results? There are some major rewrites in the lower level channel support that may be the problem. - Ben On Mon, 18 Dec 2000, Rachit Siamwalla wrote: > does this happen if you test this through rsh? > > If so, i've had a similar problem (unfortunately no good solution > though). The way i "solved" the problem is writing my own shellscript > that had the same effect. apachectl is probably a shell script too. try > cutting out only what is needed and narrow the problem down from there. > > -rchit > > > Rob Hagopian wrote: > > > > OK, with openssh-SNAP-20001218 I still have the problem of a hanging ssh > > when running (one specific) command on a server. On the server side, > > there's a small suid C prog (/usr/dh/mgmt/HupServer) that runs system > > "/usr/local/apache/bin/apachectl stop/start". Incidentally, apachectl is a > > shell script, hence the need for a suid wrapper for non-root users... On > > the client side, there's a shell script that removes the machine from load > > balancing and then stops/starts the webserver by sshing to the server and > > running the C prog there. > > > > The problem doesn't arise if I run the HupServer program from the command > > line, only from within the shell script that does the load balancing > > enable/disable. In that script, the 'stop' command has no problems, only > > 'start'. > > > > - I assumed that a fd was being left open, so I added: > > close(2); close(1); close(0); exit(0); > > to the C prog, but with no affect... > > - Last I checked the -t switch had no affect... > > - Hitting Ctrl-C on either debug run finishes the process up cleanly > > - During the hanging there is no HupServer executable running on the > > server > > - The problem was diminished, but not eliminated, by the prior patches to > > end the connection before the fds were closed. > > > > Any ideas on how I can work around this? Would forking HupServer be of any > > use? > > -Rob > > > > The ssh dump: > > > > SSH Version OpenSSH_2.3.0p2, protocol versions 1.5/2.0. > > Compiled with SSL (0x0090581f). > > debug: Reading configuration data /etc/ssh/ssh_config > > debug: Applying options for * > > debug: ssh_connect: getuid 500 geteuid 0 anon 0 > > debug: Connecting to dhumb400 [10.40.10.10] port 22. > > debug: Allocated local port 1022. > > debug: Connection established. > > debug: identity file /home/prod/.ssh/identity type 0 > > debug: identity file /home/prod/.ssh/id_dsa type 3 > > debug: Remote protocol version 1.99, remote software version > > OpenSSH_2.3.0p2 > > debug: no match: OpenSSH_2.3.0p2 > > Enabling compatibility mode for protocol 2.0 > > debug: Local version string SSH-2.0-OpenSSH_2.3.0p2 > > debug: Seeding random number generator > > debug: send KEXINIT > > debug: done > > debug: wait KEXINIT > > debug: got > > kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > > debug: got kexinit: ssh-dss,ssh-rsa > > debug: got > > kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se > > debug: got > > kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se > > debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > > debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > > debug: got kexinit: none,zlib > > debug: got kexinit: none,zlib > > debug: got kexinit: > > debug: got kexinit: > > debug: first kex follow: 0 > > debug: reserved: 0 > > debug: done > > debug: kex: server->client arcfour hmac-sha1 none > > debug: kex: client->server arcfour hmac-sha1 none > > debug: Sending SSH2_MSG_KEX_DH_GEX_REQUEST. > > debug: Wait SSH2_MSG_KEX_DH_GEX_GROUP. > > debug: Got SSH2_MSG_KEX_DH_GEX_GROUP. > > debug: bits set: 1002/2049 > > debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. > > debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. > > debug: Got SSH2_MSG_KEXDH_REPLY. > > debug: Host 'dhumb400' is known and matches the RSA host key. > > debug: bits set: 1034/2049 > > debug: ssh_rsa_verify: signature correct > > debug: Wait SSH2_MSG_NEWKEYS. > > debug: GOT SSH2_MSG_NEWKEYS. > > debug: send SSH2_MSG_NEWKEYS. > > debug: done: send SSH2_MSG_NEWKEYS. > > debug: done: KEX2. > > debug: send SSH2_MSG_SERVICE_REQUEST > > debug: service_accept: ssh-userauth > > debug: got SSH2_MSG_SERVICE_ACCEPT > > debug: authentications that can continue: publickey,password > > debug: next auth method to try is publickey > > debug: try pubkey: /home/prod/.ssh/id_dsa > > debug: read SSH2 private key done: name dsa w/o comment success 1 > > debug: sig size 20 20 > > debug: ssh-userauth2 successfull: method publickey > > debug: channel 0: new [client-session] > > debug: send channel open 0 > > debug: Entering interactive session. > > debug: client_init id 0 arg 0 > > debug: Sending command: /usr/dh/mgmt/scripts/HupServer start > > debug: channel 0: open confirm rwindow 0 rmax 16384 > > Environment: > > USER=prod > > LOGNAME=prod > > HOME=/usr/dh/home/prod > > PATH=/usr/dh/home/prod/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin > > MAIL=/var/mail/prod > > SHELL=/usr/local/bin/tcsh > > SSH_CLIENT=10.40.12.11 1022 22 > > /usr/local/apache/bin/apachectl start: httpd started > > debug: client_input_channel_req: rtype exit-status reply 0 > > Connection to dhumb400 closed by remote host. > > debug: Transferred: stdin 0, stdout 0, stderr 47 bytes in 138.8 seconds > > debug: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.3 > > debug: Exit status 0 > > > > and the sshd dump: > > debug1: sshd version OpenSSH_2.3.0p2 > > debug1: load_private_key_autodetect: type 0 RSA1 > > debug1: read SSH2 private key done: name dsa w/o comment success 1 > > debug1: load_private_key_autodetect: type 2 DSA > > debug1: read SSH2 private key done: name rsa w/o comment success 1 > > debug1: load_private_key_autodetect: type 1 RSA > > debug1: Bind to port 22 on 0.0.0.0. > > Server listening on 0.0.0.0 port 22. > > Generating 768 bit RSA key. > > RSA key generation complete. > > debug1: Server will not fork when running in debugging mode. > > Connection from 10.40.12.11 port 1022 > > debug1: Client protocol version 2.0; client software version > > OpenSSH_2.3.0p2 > > debug1: no match: OpenSSH_2.3.0p2 > > Enabling compatibility mode for protocol 2.0 > > debug1: Local version string SSH-1.99-OpenSSH_2.3.0p2 > > debug1: list_hostkey_types: ssh-dss,ssh-rsa > > debug1: send KEXINIT > > debug1: done > > debug1: wait KEXINIT > > debug1: got > > kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > > debug1: got kexinit: ssh-rsa,ssh-dss > > debug1: got kexinit: arcfour,3des-cbc,blowfish-cbc,cast128-cbc > > debug1: got kexinit: arcfour,3des-cbc,blowfish-cbc,cast128-cbc > > debug1: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > > debug1: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > > debug1: got kexinit: none > > debug1: got kexinit: none > > debug1: got kexinit: > > debug1: got kexinit: > > debug1: first kex follow: 0 > > debug1: reserved: 0 > > debug1: done > > debug1: kex: client->server arcfour hmac-sha1 none > > debug1: kex: server->client arcfour hmac-sha1 none > > debug1: Wait SSH2_MSG_KEX_DH_GEX_REQUEST. > > debug1: Sending SSH2_MSG_KEX_DH_GEX_GROUP. > > debug1: bits set: 1034/2049 > > debug1: Wait SSH2_MSG_KEX_DH_GEX_INIT. > > debug1: bits set: 1002/2049 > > debug1: send SSH2_MSG_NEWKEYS. > > debug1: done: send SSH2_MSG_NEWKEYS. > > debug1: Wait SSH2_MSG_NEWKEYS. > > debug1: GOT SSH2_MSG_NEWKEYS. > > debug1: done: KEX2. > > debug1: userauth-request for user prod service ssh-connection method none > > debug1: attempt #1 > > debug1: Starting up PAM with username "prod" > > Failed none for prod from 10.40.12.11 port 1022 ssh2 > > debug1: userauth-request for user prod service ssh-connection method > > publickey > > debug1: attempt #2 > > debug1: matching key found: file /usr/dh/home/prod/.ssh/authorized_keys2, > > line 2 > > debug1: len 55 datafellows 0 > > debug1: ssh_dss_verify: signature correct > > Could not reverse map address 10.40.12.11. > > debug1: PAM setting rhost to "10.40.12.11" > > Accepted publickey for prod from 10.40.12.11 port 1022 ssh2 > > debug1: Entering interactive session for SSH2. > > debug1: server_init_dispatch_20 > > debug1: server_input_channel_open: ctype session rchan 0 win 65536 max > > 32768 > > debug1: input_session_request > > debug1: channel 0: new [server-session] > > debug1: session_new: init > > debug1: session_new: session 0 > > debug1: session_open: channel 0 > > debug1: session_open: session 0: link with channel 0 > > debug1: server_input_channel_open: confirm session > > debug1: session_by_channel: session 0 channel 0 > > debug1: session_input_channel_req: session 0 channel 0 request exec reply > > 0 > > debug1: PAM establishing creds > > debug1: fd 7 setting O_NONBLOCK > > debug1: fd 7 IS O_NONBLOCK > > debug1: fd 9 setting O_NONBLOCK > > debug1: Received SIGCHLD. > > debug1: tvp!=NULL kid 1 mili 100 > > debug1: session_by_pid: pid 34260 > > debug1: session_exit_message: session 0 channel 0 pid 34260 > > debug1: session_exit_message: release channel 0 > > debug1: channel 0: write failed > > debug1: channel 0: output open -> closed > > debug1: channel 0: close_write > > debug1: session_free: session 0 pid 34260 > From rachit at ensim.com Tue Dec 19 07:38:11 2000 From: rachit at ensim.com (Rachit Siamwalla) Date: Mon, 18 Dec 2000 12:38:11 -0800 Subject: Hanging ssh References: Message-ID: <3A3E75B3.25A28AE@ensim.com> It was linux for me, but this was a while ago. oh no, whoops, it was fsecure ssh i had problems with. sorry for the confusion. Although i wouldn't be surprised if openssh had the same problem, because rsh had the problem too. -rchit mouring at etoh.eviladmin.org wrote: > > What platform? I know Linux has such an issue. The patch to resolve the > issue caused scp to not complete it's transfers under meduim loads so > it was removed. I have/had (somewhere) a hack to work around scp for > protocol 1. That did not SEEM to cause problems.. But I was not happy > with it. > > I've not been able to verify but does the old 1.2.16 source tree from > ssh.com produce the same results? There are some major rewrites in the > lower level channel support that may be the problem. > > - Ben > > On Mon, 18 Dec 2000, Rachit Siamwalla wrote: > > > does this happen if you test this through rsh? > > > > If so, i've had a similar problem (unfortunately no good solution > > though). The way i "solved" the problem is writing my own shellscript > > that had the same effect. apachectl is probably a shell script too. try > > cutting out only what is needed and narrow the problem down from there. > > > > -rchit > > > > > > Rob Hagopian wrote: > > > > > > OK, with openssh-SNAP-20001218 I still have the problem of a hanging ssh > > > when running (one specific) command on a server. On the server side, > > > there's a small suid C prog (/usr/dh/mgmt/HupServer) that runs system > > > "/usr/local/apache/bin/apachectl stop/start". Incidentally, apachectl is a > > > shell script, hence the need for a suid wrapper for non-root users... On > > > the client side, there's a shell script that removes the machine from load > > > balancing and then stops/starts the webserver by sshing to the server and > > > running the C prog there. > > > > > > The problem doesn't arise if I run the HupServer program from the command > > > line, only from within the shell script that does the load balancing > > > enable/disable. In that script, the 'stop' command has no problems, only > > > 'start'. > > > > > > - I assumed that a fd was being left open, so I added: > > > close(2); close(1); close(0); exit(0); > > > to the C prog, but with no affect... > > > - Last I checked the -t switch had no affect... > > > - Hitting Ctrl-C on either debug run finishes the process up cleanly > > > - During the hanging there is no HupServer executable running on the > > > server > > > - The problem was diminished, but not eliminated, by the prior patches to > > > end the connection before the fds were closed. > > > > > > Any ideas on how I can work around this? Would forking HupServer be of any > > > use? > > > -Rob > > > > > > The ssh dump: > > > > > > SSH Version OpenSSH_2.3.0p2, protocol versions 1.5/2.0. > > > Compiled with SSL (0x0090581f). > > > debug: Reading configuration data /etc/ssh/ssh_config > > > debug: Applying options for * > > > debug: ssh_connect: getuid 500 geteuid 0 anon 0 > > > debug: Connecting to dhumb400 [10.40.10.10] port 22. > > > debug: Allocated local port 1022. > > > debug: Connection established. > > > debug: identity file /home/prod/.ssh/identity type 0 > > > debug: identity file /home/prod/.ssh/id_dsa type 3 > > > debug: Remote protocol version 1.99, remote software version > > > OpenSSH_2.3.0p2 > > > debug: no match: OpenSSH_2.3.0p2 > > > Enabling compatibility mode for protocol 2.0 > > > debug: Local version string SSH-2.0-OpenSSH_2.3.0p2 > > > debug: Seeding random number generator > > > debug: send KEXINIT > > > debug: done > > > debug: wait KEXINIT > > > debug: got > > > kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > > > debug: got kexinit: ssh-dss,ssh-rsa > > > debug: got > > > kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se > > > debug: got > > > kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se > > > debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > > > debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > > > debug: got kexinit: none,zlib > > > debug: got kexinit: none,zlib > > > debug: got kexinit: > > > debug: got kexinit: > > > debug: first kex follow: 0 > > > debug: reserved: 0 > > > debug: done > > > debug: kex: server->client arcfour hmac-sha1 none > > > debug: kex: client->server arcfour hmac-sha1 none > > > debug: Sending SSH2_MSG_KEX_DH_GEX_REQUEST. > > > debug: Wait SSH2_MSG_KEX_DH_GEX_GROUP. > > > debug: Got SSH2_MSG_KEX_DH_GEX_GROUP. > > > debug: bits set: 1002/2049 > > > debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. > > > debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. > > > debug: Got SSH2_MSG_KEXDH_REPLY. > > > debug: Host 'dhumb400' is known and matches the RSA host key. > > > debug: bits set: 1034/2049 > > > debug: ssh_rsa_verify: signature correct > > > debug: Wait SSH2_MSG_NEWKEYS. > > > debug: GOT SSH2_MSG_NEWKEYS. > > > debug: send SSH2_MSG_NEWKEYS. > > > debug: done: send SSH2_MSG_NEWKEYS. > > > debug: done: KEX2. > > > debug: send SSH2_MSG_SERVICE_REQUEST > > > debug: service_accept: ssh-userauth > > > debug: got SSH2_MSG_SERVICE_ACCEPT > > > debug: authentications that can continue: publickey,password > > > debug: next auth method to try is publickey > > > debug: try pubkey: /home/prod/.ssh/id_dsa > > > debug: read SSH2 private key done: name dsa w/o comment success 1 > > > debug: sig size 20 20 > > > debug: ssh-userauth2 successfull: method publickey > > > debug: channel 0: new [client-session] > > > debug: send channel open 0 > > > debug: Entering interactive session. > > > debug: client_init id 0 arg 0 > > > debug: Sending command: /usr/dh/mgmt/scripts/HupServer start > > > debug: channel 0: open confirm rwindow 0 rmax 16384 > > > Environment: > > > USER=prod > > > LOGNAME=prod > > > HOME=/usr/dh/home/prod > > > PATH=/usr/dh/home/prod/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin > > > MAIL=/var/mail/prod > > > SHELL=/usr/local/bin/tcsh > > > SSH_CLIENT=10.40.12.11 1022 22 > > > /usr/local/apache/bin/apachectl start: httpd started > > > debug: client_input_channel_req: rtype exit-status reply 0 > > > Connection to dhumb400 closed by remote host. > > > debug: Transferred: stdin 0, stdout 0, stderr 47 bytes in 138.8 seconds > > > debug: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.3 > > > debug: Exit status 0 > > > > > > and the sshd dump: > > > debug1: sshd version OpenSSH_2.3.0p2 > > > debug1: load_private_key_autodetect: type 0 RSA1 > > > debug1: read SSH2 private key done: name dsa w/o comment success 1 > > > debug1: load_private_key_autodetect: type 2 DSA > > > debug1: read SSH2 private key done: name rsa w/o comment success 1 > > > debug1: load_private_key_autodetect: type 1 RSA > > > debug1: Bind to port 22 on 0.0.0.0. > > > Server listening on 0.0.0.0 port 22. > > > Generating 768 bit RSA key. > > > RSA key generation complete. > > > debug1: Server will not fork when running in debugging mode. > > > Connection from 10.40.12.11 port 1022 > > > debug1: Client protocol version 2.0; client software version > > > OpenSSH_2.3.0p2 > > > debug1: no match: OpenSSH_2.3.0p2 > > > Enabling compatibility mode for protocol 2.0 > > > debug1: Local version string SSH-1.99-OpenSSH_2.3.0p2 > > > debug1: list_hostkey_types: ssh-dss,ssh-rsa > > > debug1: send KEXINIT > > > debug1: done > > > debug1: wait KEXINIT > > > debug1: got > > > kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > > > debug1: got kexinit: ssh-rsa,ssh-dss > > > debug1: got kexinit: arcfour,3des-cbc,blowfish-cbc,cast128-cbc > > > debug1: got kexinit: arcfour,3des-cbc,blowfish-cbc,cast128-cbc > > > debug1: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > > > debug1: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > > > debug1: got kexinit: none > > > debug1: got kexinit: none > > > debug1: got kexinit: > > > debug1: got kexinit: > > > debug1: first kex follow: 0 > > > debug1: reserved: 0 > > > debug1: done > > > debug1: kex: client->server arcfour hmac-sha1 none > > > debug1: kex: server->client arcfour hmac-sha1 none > > > debug1: Wait SSH2_MSG_KEX_DH_GEX_REQUEST. > > > debug1: Sending SSH2_MSG_KEX_DH_GEX_GROUP. > > > debug1: bits set: 1034/2049 > > > debug1: Wait SSH2_MSG_KEX_DH_GEX_INIT. > > > debug1: bits set: 1002/2049 > > > debug1: send SSH2_MSG_NEWKEYS. > > > debug1: done: send SSH2_MSG_NEWKEYS. > > > debug1: Wait SSH2_MSG_NEWKEYS. > > > debug1: GOT SSH2_MSG_NEWKEYS. > > > debug1: done: KEX2. > > > debug1: userauth-request for user prod service ssh-connection method none > > > debug1: attempt #1 > > > debug1: Starting up PAM with username "prod" > > > Failed none for prod from 10.40.12.11 port 1022 ssh2 > > > debug1: userauth-request for user prod service ssh-connection method > > > publickey > > > debug1: attempt #2 > > > debug1: matching key found: file /usr/dh/home/prod/.ssh/authorized_keys2, > > > line 2 > > > debug1: len 55 datafellows 0 > > > debug1: ssh_dss_verify: signature correct > > > Could not reverse map address 10.40.12.11. > > > debug1: PAM setting rhost to "10.40.12.11" > > > Accepted publickey for prod from 10.40.12.11 port 1022 ssh2 > > > debug1: Entering interactive session for SSH2. > > > debug1: server_init_dispatch_20 > > > debug1: server_input_channel_open: ctype session rchan 0 win 65536 max > > > 32768 > > > debug1: input_session_request > > > debug1: channel 0: new [server-session] > > > debug1: session_new: init > > > debug1: session_new: session 0 > > > debug1: session_open: channel 0 > > > debug1: session_open: session 0: link with channel 0 > > > debug1: server_input_channel_open: confirm session > > > debug1: session_by_channel: session 0 channel 0 > > > debug1: session_input_channel_req: session 0 channel 0 request exec reply > > > 0 > > > debug1: PAM establishing creds > > > debug1: fd 7 setting O_NONBLOCK > > > debug1: fd 7 IS O_NONBLOCK > > > debug1: fd 9 setting O_NONBLOCK > > > debug1: Received SIGCHLD. > > > debug1: tvp!=NULL kid 1 mili 100 > > > debug1: session_by_pid: pid 34260 > > > debug1: session_exit_message: session 0 channel 0 pid 34260 > > > debug1: session_exit_message: release channel 0 > > > debug1: channel 0: write failed > > > debug1: channel 0: output open -> closed > > > debug1: channel 0: close_write > > > debug1: session_free: session 0 pid 34260 > > From gert at greenie.muc.de Tue Dec 19 09:38:11 2000 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 18 Dec 2000 23:38:11 +0100 Subject: SCO remove() and unlink() In-Reply-To: ; from Kevin Steves on Mon, Dec 18, 2000 at 06:45:23PM +0100 References: <20001218094724.B28872@greenie.muc.de> Message-ID: <20001218233811.A14042@greenie.muc.de> Hi, On Mon, Dec 18, 2000 at 06:45:23PM +0100, Kevin Steves wrote: > On Mon, 18 Dec 2000, Gert Doering wrote: > : OTOH, we don't need a bsd-remove.c - just add something like > : > : #ifndef HAVE_REMOVE > : # define remove(a) unlink(a) > : #endif > > remove() can also delete directories. Not according to my man page. I checked various, but the clearest is FreeBSD's: DESCRIPTION The remove() function is an alias for the unlink(2) system call. It deletes the file referenced by path. ... ERRORS The remove() function may fail and set errno for any of the errors speci- fied for the routine unlink(2). unlink(2) lists in turn: [EPERM] The named file is a directory. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From ftobin at uiuc.edu Tue Dec 19 11:04:03 2000 From: ftobin at uiuc.edu (Frank Tobin) Date: Mon, 18 Dec 2000 18:04:03 -0600 (CST) Subject: scp remote path specification In-Reply-To: <20001218164143.B16853@faui02.informatik.uni-erlangen.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Markus Friedl, at 16:41 +0100 on Mon, 18 Dec 2000, wrote: you cannot assume that the path for the remote scp is the same as for the local scp. it's better to add an option to scp, e.g.: $ scp -X /remote/path/to/scp /etc/passwd otherhost:/etc This is not a good solution if you ever expect there to be multiple remote hosts in scp's arguments (e.g., scp file at remote1 file2 at remote2). You need to tie the path to each remote file-location specification. - -- Frank Tobin http://www.uiuc.edu/~ftobin/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iEYEARECAAYFAjo+pf0ACgkQVv/RCiYMT6PWcgCfQw8mtNOka3ZNB3J9sWORDk/K /1UAn1eK16gatg01AI2u8XtgKPyMhz5G =NQqV -----END PGP SIGNATURE----- From bk at rt.fm Tue Dec 19 11:04:48 2000 From: bk at rt.fm (Brian Kifiak) Date: Mon, 18 Dec 2000 18:04:48 -0600 Subject: SCO remove() and unlink() In-Reply-To: <20001218233811.A14042@greenie.muc.de>; from gert@greenie.muc.de on Mon, Dec 18, 2000 at 11:38:11PM +0100 References: <20001218094724.B28872@greenie.muc.de> <20001218233811.A14042@greenie.muc.de> Message-ID: <20001218180448.D3008@rt.fm> > I checked various, but the clearest is FreeBSD's: openbsd's disagrees: > DESCRIPTION > The remove() function is an alias for the unlink(2) system call. It > deletes the file referenced by path. DESCRIPTION The remove() function removes the file or directory specified by path. If path specifies a directory, remove(path) is the equivalent of rmdir(path). Otherwise, it is the equivalent of unlink(path). ... STANDARDS The remove() function conforms to ANSI X3.159-1989 (``ANSI C'') and X/Open Portability Guide Issue 4.2 (``XPG4.2''). From mouring at etoh.eviladmin.org Tue Dec 19 12:29:09 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 18 Dec 2000 19:29:09 -0600 (CST) Subject: SCO remove() and unlink() In-Reply-To: <20001218180448.D3008@rt.fm> Message-ID: Not that I trust Redhat or Linux in general's manpage but it also disagrees: DESCRIPTION remove deletes a name from the filesystem. It calls unlink for files, and rmdir for directories. - Ben On Mon, 18 Dec 2000, Brian Kifiak wrote: > > I checked various, but the clearest is FreeBSD's: > > openbsd's disagrees: > > > DESCRIPTION > > The remove() function is an alias for the unlink(2) system call. It > > deletes the file referenced by path. > > DESCRIPTION > The remove() function removes the file or directory specified > by path. > > If path specifies a directory, remove(path) is the equivalent > of rmdir(path). Otherwise, it is the equivalent of > unlink(path). > > ... > > STANDARDS > The remove() function conforms to ANSI X3.159-1989 (``ANSI C'') > and X/Open Portability Guide Issue 4.2 (``XPG4.2''). > From djm at mindrot.org Tue Dec 19 12:18:02 2000 From: djm at mindrot.org (Damien Miller) Date: Tue, 19 Dec 2000 12:18:02 +1100 (EST) Subject: OpenSSHd: PATHs in configuration files In-Reply-To: <20001218154410.A15158@ee.ethz.ch> Message-ID: On Mon, 18 Dec 2000, Lukas Ruf wrote: > Dear all, > > is it possible to specify the default paths in the appropriate > configuration of the Daemon ? You can set PATH in /etc/environment ~/.ssh/environment -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From johnh at isi.edu Tue Dec 19 15:19:48 2000 From: johnh at isi.edu (John Heidemann) Date: Mon, 18 Dec 2000 20:19:48 -0800 Subject: setup debugging suggestion and offer to help Message-ID: <200012190419.eBJ4Jmm07194@dash.isi.edu> First, OpenSSH is great... but it can be REALLY hard to get it properly configured. The problem is that there are MANY different ways of authenticating (4 in ssh1, 2 in ssh2). Each can be enabled/disabled in many different places (command line args, server config, personal config, and other ways). Thus it can be really confusing when the way you expect to authenticate doesn't happen. This makes it really hard to properly configure. For example, recently I was trying to get ssh1 RSAHostAuthentication to work... I ended up running everything under a debugger only to find out that things were now not working, but for a different reason (because I was now running it on a non-privileged port to debug). It sure would have been nice to see a warning message that it was disabling RSAHostAutentication because of a non-priviledged port instead of silently turning it off. Yes, ssh -v is pretty helpful and gets some debugging about what's on and off, but not enough. (Not this case, for example :-) My modest proposal is that before enabling or disabling ANY protocol ssh should log why (in a way seen by ssh -v). (In addition to making deployment easier, this should enhance security by making it obvious why something is enabled that you may not expect.) I have two questions: 1. Do folks agree this is a good idea? 2. As a US citizen, would you take code contributed by me to accomplish this task? I certainly don't want to jepordize the code base or break the (US) law about crypto code. (I have a preliminary patch for the case I outlined, but what is really called for is a comprehensive audit of where crypto methods are turned on and off.) -John Heidemann From gert at greenie.muc.de Tue Dec 19 18:04:36 2000 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 19 Dec 2000 08:04:36 +0100 Subject: SCO remove() and unlink() In-Reply-To: <20001218180448.D3008@rt.fm>; from Brian Kifiak on Mon, Dec 18, 2000 at 06:04:48PM -0600 References: <20001218094724.B28872@greenie.muc.de> <20001218233811.A14042@greenie.muc.de> <20001218180448.D3008@rt.fm> Message-ID: <20001219080436.A24878@greenie.muc.de> Hi, On Mon, Dec 18, 2000 at 06:04:48PM -0600, Brian Kifiak wrote: > > I checked various, but the clearest is FreeBSD's: > openbsd's disagrees: [..] > STANDARDS > The remove() function conforms to ANSI X3.159-1989 (``ANSI C'') > and X/Open Portability Guide Issue 4.2 (``XPG4.2''). Interesting fact. Sounds as if it really isn't that standardized - and if one definitely should not rely on this behaviour because it's guaranteed not to work on one or the other platform. Thanks for digging this up. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From Markus.Friedl at informatik.uni-erlangen.de Tue Dec 19 20:51:03 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Tue, 19 Dec 2000 10:51:03 +0100 Subject: scp remote path specification In-Reply-To: ; from ftobin@uiuc.edu on Mon, Dec 18, 2000 at 06:04:03PM -0600 References: <20001218164143.B16853@faui02.informatik.uni-erlangen.de> Message-ID: <20001219105103.B27148@faui02.informatik.uni-erlangen.de> On Mon, Dec 18, 2000 at 06:04:03PM -0600, Frank Tobin wrote: > Markus Friedl, at 16:41 +0100 on Mon, 18 Dec 2000, wrote: > > you cannot assume that the path for the remote scp is the > same as for the local scp. it's better to add an option > to scp, e.g.: > $ scp -X /remote/path/to/scp /etc/passwd otherhost:/etc > > This is not a good solution if you ever expect there to be multiple remote > hosts in scp's arguments (e.g., scp file at remote1 file2 at remote2). You need > to tie the path to each remote file-location specification. more than 99% of the uses involve only a single remote host. if you have more specific uses is much better to use ssh+tar instead of scp. many people have already problems with scp hosta:/file1 hostb:/file2 expanding to ssh hosta 'scp /file1 hostb:/file2' From Jan.Iven at cern.ch Wed Dec 20 00:57:12 2000 From: Jan.Iven at cern.ch (Jan IVEN) Date: 19 Dec 2000 14:57:12 +0100 Subject: [PATCH] Re: scp remote path specification In-Reply-To: Markus Friedl's message of "Tue, 19 Dec 2000 10:51:03 +0100" References: <20001218164143.B16853@faui02.informatik.uni-erlangen.de> <20001219105103.B27148@faui02.informatik.uni-erlangen.de> Message-ID: >>>>> "MF" == Markus Friedl writes: MF> On Mon, Dec 18, 2000 at 06:04:03PM -0600, Frank Tobin wrote: >> Markus Friedl, at 16:41 +0100 on Mon, 18 Dec 2000, wrote: >> >> you cannot assume that the path for the remote scp is the >> same as for the local scp. it's better to add an option >> to scp, e.g.: >> $ scp -X /remote/path/to/scp /etc/passwd otherhost:/etc >> >> This is not a good solution if you ever expect there to be multiple remote >> hosts in scp's arguments (e.g., scp file at remote1 file2 at remote2). You need >> to tie the path to each remote file-location specification. MF> more than 99% of the uses involve only a single remote host. MF> if you have more specific uses is much better to use ssh+tar MF> instead of scp. MF> many people have already problems with MF> scp hosta:/file1 hostb:/file2 MF> expanding to MF> ssh hosta 'scp /file1 hostb:/file2' Ok, here is a patch for a new option -X to scp (includes my first "find local ssh in scp path" patch). Works for me. If the remote command does not exist or does not understand the options, scp will report an error after a short timeout. Best regards Jan --- openssh-SNAP-20001213.orig/scp.0 Tue Dec 12 18:30:23 2000 +++ openssh/scp.0 Tue Dec 19 12:04:04 2000 @@ -54,7 +54,14 @@ -S program Name of program to use for the encrypted connection. The program - must understand ssh(1) options. + must understand ssh(1) options. The default is "/usr/bin/ssh" (set + at compilation time). If you run /path/to/scp instead of scp, + the default will be "/path/to/ssh". + + -X program + Name of program invoke on the remote host. The program must + understand scp(1) options. The same program will be used on all + remote hosts. -o option The given option is directly passed to ssh(1). --- openssh-SNAP-20001213.orig/scp.1 Mon Nov 6 02:39:34 2000 +++ openssh/scp.1 Tue Dec 19 12:03:04 2000 @@ -106,7 +106,16 @@ to use for the encrypted connection. The program must understand .Xr ssh 1 -options. +options. The default is "/usr/bin/ssh" (set at compilation time). If you run +/path/to/scp instead of scp, the +default will be "/path/to/ssh". +.It Fl X Ar program +Name of +.Ar program +to invoke on the remote host. +The program must understand +.Xr scp 1 +options. The same program will be used on all remote hosts. .It Fl o Ar option The given option is directly passed to .Xr ssh 1 . --- openssh-SNAP-20001213.orig/scp.c Fri Nov 17 04:47:20 2000 +++ openssh/scp.c Tue Dec 19 11:50:55 2000 @@ -135,6 +135,9 @@ /* This is the program to execute for the secured connection. ("ssh" or -S) */ char *ssh_program = SSH_PROGRAM; +/* This is the remote program that does the other side of the transfer ("scp" or -X) */ +char *scp_program = "scp"; + /* This is the list of arguments that scp passes to ssh */ struct { char **list; @@ -251,7 +254,7 @@ char *argv[]; { int ch, fflag, tflag; - char *targ; + char *targ, *pathsep; extern char *optarg; extern int optind; @@ -262,8 +265,21 @@ addargs("-x"); addargs("-oFallBackToRsh no"); + /* check explicit path for ssh binary, default is SSH_PROGRAM */ + if ((argc > 0) && + (argv[0] != NULL)) { + pathsep = strrchr(argv[0], '/'); + if (pathsep != NULL) { + pathsep++; + *pathsep = 0; + ssh_program = xmalloc(strlen(argv[0]) + 4); /* "../path" + "ssh\0" */ + strcpy(ssh_program, argv[0]); + strcat(ssh_program, "ssh"); + } + } + fflag = tflag = 0; - while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q46S:o:")) != EOF) + while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q46S:X:o:")) != EOF) switch (ch) { /* User-visible flags. */ case '4': @@ -291,6 +307,9 @@ case 'S': ssh_program = xstrdup(optarg); break; + case 'X': + scp_program = xstrdup(optarg); + break; case 'v': verbose_mode = 1; break; @@ -344,7 +363,7 @@ remin = remout = -1; /* Command to be executed on remote system using "ssh". */ - (void) sprintf(cmd, "scp%s%s%s%s", verbose_mode ? " -v" : "", + (void) sprintf(cmd, "%s%s%s%s%s", scp_program, verbose_mode ? " -v" : "", iamrecursive ? " -r" : "", pflag ? " -p" : "", targetshouldbedirectory ? " -d" : ""); @@ -969,7 +988,7 @@ usage() { (void) fprintf(stderr, "usage: scp " - "[-pqrvC46] [-S ssh] [-P port] [-c cipher] [-i identity] f1 f2; or:\n" + "[-pqrvC46] [-S ssh] [-X /remote/scp] [-P port] [-c cipher] [-i identity] f1 f2; or:\n" " scp [options] f1 ... fn directory\n"); exit(1); } From rob at hagopian.net Wed Dec 20 02:27:47 2000 From: rob at hagopian.net (Rob Hagopian) Date: Tue, 19 Dec 2000 10:27:47 -0500 (EST) Subject: Hanging ssh In-Reply-To: Message-ID: Your comments got me thinking; I tried my situation using Protocol 1 (forced by sshd) and no problems so far... the repeatable problem using snaps later than 20001114 (I believe the last one to contain the patch) has gone away, and it survived the night without leaving a hung process around (which even 20001114 did). Is this of any use? Is there anything else I can do to help track this down? I'd rather not have to convert to ssh1... -Rob On Mon, 18 Dec 2000 mouring at etoh.eviladmin.org wrote: > > What platform? I know Linux has such an issue. The patch to resolve the > issue caused scp to not complete it's transfers under meduim loads so > it was removed. I have/had (somewhere) a hack to work around scp for > protocol 1. That did not SEEM to cause problems.. But I was not happy > with it. > > I've not been able to verify but does the old 1.2.16 source tree from > ssh.com produce the same results? There are some major rewrites in the > lower level channel support that may be the problem. > > - Ben > > On Mon, 18 Dec 2000, Rachit Siamwalla wrote: > > > does this happen if you test this through rsh? > > > > If so, i've had a similar problem (unfortunately no good solution > > though). The way i "solved" the problem is writing my own shellscript > > that had the same effect. apachectl is probably a shell script too. try > > cutting out only what is needed and narrow the problem down from there. > > > > -rchit > > > > > > Rob Hagopian wrote: > > > > > > OK, with openssh-SNAP-20001218 I still have the problem of a hanging ssh > > > when running (one specific) command on a server. On the server side, > > > there's a small suid C prog (/usr/dh/mgmt/HupServer) that runs system > > > "/usr/local/apache/bin/apachectl stop/start". Incidentally, apachectl is a > > > shell script, hence the need for a suid wrapper for non-root users... On > > > the client side, there's a shell script that removes the machine from load > > > balancing and then stops/starts the webserver by sshing to the server and > > > running the C prog there. > > > > > > The problem doesn't arise if I run the HupServer program from the command > > > line, only from within the shell script that does the load balancing > > > enable/disable. In that script, the 'stop' command has no problems, only > > > 'start'. > > > > > > - I assumed that a fd was being left open, so I added: > > > close(2); close(1); close(0); exit(0); > > > to the C prog, but with no affect... > > > - Last I checked the -t switch had no affect... > > > - Hitting Ctrl-C on either debug run finishes the process up cleanly > > > - During the hanging there is no HupServer executable running on the > > > server > > > - The problem was diminished, but not eliminated, by the prior patches to > > > end the connection before the fds were closed. > > > > > > Any ideas on how I can work around this? Would forking HupServer be of any > > > use? > > > -Rob > > > > > > The ssh dump: > > > > > > SSH Version OpenSSH_2.3.0p2, protocol versions 1.5/2.0. > > > Compiled with SSL (0x0090581f). > > > debug: Reading configuration data /etc/ssh/ssh_config > > > debug: Applying options for * > > > debug: ssh_connect: getuid 500 geteuid 0 anon 0 > > > debug: Connecting to dhumb400 [10.40.10.10] port 22. > > > debug: Allocated local port 1022. > > > debug: Connection established. > > > debug: identity file /home/prod/.ssh/identity type 0 > > > debug: identity file /home/prod/.ssh/id_dsa type 3 > > > debug: Remote protocol version 1.99, remote software version > > > OpenSSH_2.3.0p2 > > > debug: no match: OpenSSH_2.3.0p2 > > > Enabling compatibility mode for protocol 2.0 > > > debug: Local version string SSH-2.0-OpenSSH_2.3.0p2 > > > debug: Seeding random number generator > > > debug: send KEXINIT > > > debug: done > > > debug: wait KEXINIT > > > debug: got > > > kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > > > debug: got kexinit: ssh-dss,ssh-rsa > > > debug: got > > > kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se > > > debug: got > > > kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se > > > debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > > > debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > > > debug: got kexinit: none,zlib > > > debug: got kexinit: none,zlib > > > debug: got kexinit: > > > debug: got kexinit: > > > debug: first kex follow: 0 > > > debug: reserved: 0 > > > debug: done > > > debug: kex: server->client arcfour hmac-sha1 none > > > debug: kex: client->server arcfour hmac-sha1 none > > > debug: Sending SSH2_MSG_KEX_DH_GEX_REQUEST. > > > debug: Wait SSH2_MSG_KEX_DH_GEX_GROUP. > > > debug: Got SSH2_MSG_KEX_DH_GEX_GROUP. > > > debug: bits set: 1002/2049 > > > debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. > > > debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. > > > debug: Got SSH2_MSG_KEXDH_REPLY. > > > debug: Host 'dhumb400' is known and matches the RSA host key. > > > debug: bits set: 1034/2049 > > > debug: ssh_rsa_verify: signature correct > > > debug: Wait SSH2_MSG_NEWKEYS. > > > debug: GOT SSH2_MSG_NEWKEYS. > > > debug: send SSH2_MSG_NEWKEYS. > > > debug: done: send SSH2_MSG_NEWKEYS. > > > debug: done: KEX2. > > > debug: send SSH2_MSG_SERVICE_REQUEST > > > debug: service_accept: ssh-userauth > > > debug: got SSH2_MSG_SERVICE_ACCEPT > > > debug: authentications that can continue: publickey,password > > > debug: next auth method to try is publickey > > > debug: try pubkey: /home/prod/.ssh/id_dsa > > > debug: read SSH2 private key done: name dsa w/o comment success 1 > > > debug: sig size 20 20 > > > debug: ssh-userauth2 successfull: method publickey > > > debug: channel 0: new [client-session] > > > debug: send channel open 0 > > > debug: Entering interactive session. > > > debug: client_init id 0 arg 0 > > > debug: Sending command: /usr/dh/mgmt/scripts/HupServer start > > > debug: channel 0: open confirm rwindow 0 rmax 16384 > > > Environment: > > > USER=prod > > > LOGNAME=prod > > > HOME=/usr/dh/home/prod > > > PATH=/usr/dh/home/prod/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin > > > MAIL=/var/mail/prod > > > SHELL=/usr/local/bin/tcsh > > > SSH_CLIENT=10.40.12.11 1022 22 > > > /usr/local/apache/bin/apachectl start: httpd started > > > debug: client_input_channel_req: rtype exit-status reply 0 > > > Connection to dhumb400 closed by remote host. > > > debug: Transferred: stdin 0, stdout 0, stderr 47 bytes in 138.8 seconds > > > debug: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.3 > > > debug: Exit status 0 > > > > > > and the sshd dump: > > > debug1: sshd version OpenSSH_2.3.0p2 > > > debug1: load_private_key_autodetect: type 0 RSA1 > > > debug1: read SSH2 private key done: name dsa w/o comment success 1 > > > debug1: load_private_key_autodetect: type 2 DSA > > > debug1: read SSH2 private key done: name rsa w/o comment success 1 > > > debug1: load_private_key_autodetect: type 1 RSA > > > debug1: Bind to port 22 on 0.0.0.0. > > > Server listening on 0.0.0.0 port 22. > > > Generating 768 bit RSA key. > > > RSA key generation complete. > > > debug1: Server will not fork when running in debugging mode. > > > Connection from 10.40.12.11 port 1022 > > > debug1: Client protocol version 2.0; client software version > > > OpenSSH_2.3.0p2 > > > debug1: no match: OpenSSH_2.3.0p2 > > > Enabling compatibility mode for protocol 2.0 > > > debug1: Local version string SSH-1.99-OpenSSH_2.3.0p2 > > > debug1: list_hostkey_types: ssh-dss,ssh-rsa > > > debug1: send KEXINIT > > > debug1: done > > > debug1: wait KEXINIT > > > debug1: got > > > kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > > > debug1: got kexinit: ssh-rsa,ssh-dss > > > debug1: got kexinit: arcfour,3des-cbc,blowfish-cbc,cast128-cbc > > > debug1: got kexinit: arcfour,3des-cbc,blowfish-cbc,cast128-cbc > > > debug1: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > > > debug1: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > > > debug1: got kexinit: none > > > debug1: got kexinit: none > > > debug1: got kexinit: > > > debug1: got kexinit: > > > debug1: first kex follow: 0 > > > debug1: reserved: 0 > > > debug1: done > > > debug1: kex: client->server arcfour hmac-sha1 none > > > debug1: kex: server->client arcfour hmac-sha1 none > > > debug1: Wait SSH2_MSG_KEX_DH_GEX_REQUEST. > > > debug1: Sending SSH2_MSG_KEX_DH_GEX_GROUP. > > > debug1: bits set: 1034/2049 > > > debug1: Wait SSH2_MSG_KEX_DH_GEX_INIT. > > > debug1: bits set: 1002/2049 > > > debug1: send SSH2_MSG_NEWKEYS. > > > debug1: done: send SSH2_MSG_NEWKEYS. > > > debug1: Wait SSH2_MSG_NEWKEYS. > > > debug1: GOT SSH2_MSG_NEWKEYS. > > > debug1: done: KEX2. > > > debug1: userauth-request for user prod service ssh-connection method none > > > debug1: attempt #1 > > > debug1: Starting up PAM with username "prod" > > > Failed none for prod from 10.40.12.11 port 1022 ssh2 > > > debug1: userauth-request for user prod service ssh-connection method > > > publickey > > > debug1: attempt #2 > > > debug1: matching key found: file /usr/dh/home/prod/.ssh/authorized_keys2, > > > line 2 > > > debug1: len 55 datafellows 0 > > > debug1: ssh_dss_verify: signature correct > > > Could not reverse map address 10.40.12.11. > > > debug1: PAM setting rhost to "10.40.12.11" > > > Accepted publickey for prod from 10.40.12.11 port 1022 ssh2 > > > debug1: Entering interactive session for SSH2. > > > debug1: server_init_dispatch_20 > > > debug1: server_input_channel_open: ctype session rchan 0 win 65536 max > > > 32768 > > > debug1: input_session_request > > > debug1: channel 0: new [server-session] > > > debug1: session_new: init > > > debug1: session_new: session 0 > > > debug1: session_open: channel 0 > > > debug1: session_open: session 0: link with channel 0 > > > debug1: server_input_channel_open: confirm session > > > debug1: session_by_channel: session 0 channel 0 > > > debug1: session_input_channel_req: session 0 channel 0 request exec reply > > > 0 > > > debug1: PAM establishing creds > > > debug1: fd 7 setting O_NONBLOCK > > > debug1: fd 7 IS O_NONBLOCK > > > debug1: fd 9 setting O_NONBLOCK > > > debug1: Received SIGCHLD. > > > debug1: tvp!=NULL kid 1 mili 100 > > > debug1: session_by_pid: pid 34260 > > > debug1: session_exit_message: session 0 channel 0 pid 34260 > > > debug1: session_exit_message: release channel 0 > > > debug1: channel 0: write failed > > > debug1: channel 0: output open -> closed > > > debug1: channel 0: close_write > > > debug1: session_free: session 0 pid 34260 > > > From gert at greenie.muc.de Wed Dec 20 05:27:31 2000 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 19 Dec 2000 19:27:31 +0100 Subject: setup debugging suggestion and offer to help In-Reply-To: <200012190419.eBJ4Jmm07194@dash.isi.edu>; from John Heidemann on Mon, Dec 18, 2000 at 08:19:48PM -0800 References: <200012190419.eBJ4Jmm07194@dash.isi.edu> Message-ID: <20001219192731.I1974@greenie.muc.de> Hi, On Mon, Dec 18, 2000 at 08:19:48PM -0800, John Heidemann wrote: > My modest proposal is that before enabling or disabling ANY protocol > ssh should log why (in a way seen by ssh -v). I second this. (I think this is planned anyway - it has at least been discussed on the list a few weeks ago). Maybe have them only be visible with "-v -v", things like AFS and such are IMHO not *that* interesting that "-v" should show them...? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From wyodlows at andromeda.rutgers.edu Wed Dec 20 05:58:23 2000 From: wyodlows at andromeda.rutgers.edu (William Yodlowsky) Date: Tue, 19 Dec 2000 13:58:23 -0500 Subject: istate / ostate error? In-Reply-To: <20001215131959.A5200@andromeda.rutgers.edu>; from wyodlows@andromeda.rutgers.edu on Fri, Dec 15, 2000 at 01:20:00PM -0500 References: <20001215131959.A5200@andromeda.rutgers.edu> Message-ID: <20001219135823.A5093@andromeda.rutgers.edu> I hate people who reply to their own list postings. I unfortunately got no replies at all about the problem described below... nothing appears in my logs. (Yes I wrote "Log snippet" but that's actually wrong; those messages appear in my ssh session at apparently random times). They don't seem to have any effect; I stay connected and if I clear the screen all is well. How can I provide more information? Thanks in advance... and thanks to the developers for all their hard work! On Fri, Dec 15, 2000 at 01:20:00PM -0500, William Yodlowsky wrote: > Log snippet: > > channel 10: istate 4 != open > channel 10: ostate 64 != open > channel 11: istate 4 != open > channel 11: ostate 64 != open > channel 12: istate 4 != open > channel 12: ostate 64 != open > channel 13: istate 4 != open > channel 13: ostate 64 != open > channel 14: istate 4 != open > channel 14: ostate 64 != open > channel 15: istate 4 != open > channel 15: ostate 64 != open > > % ssh -V > SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. > Compiled with SSL (0x0090600f). > > This is on Solaris 8 SPARC with all the patches + OpenSSL 0.9.6. This > install has been running since Nov 8 with no problems. A couple of > days ago I started seeing those error messages in my sessions. The > only change I made was to my syslog.conf, so perhaps it was doing it > all along and no one noticed... > > I tried the FAQ, archives, web, and Deja and the only reference I found > was the same problem in NetBSD's "version" of ssh. > > What to do? Thanks in advance. From mouring at etoh.eviladmin.org Wed Dec 20 09:15:41 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 19 Dec 2000 16:15:41 -0600 (CST) Subject: Hanging ssh In-Reply-To: Message-ID: At this point.. I don't know.. I'm taking a break from it (and a lot of stuff to catch up with life).. I spent almost two week digging in the depths of session.c and channel.c.. Don't know of Damien has any other words of wisdom. I know I don't. - Ben On Tue, 19 Dec 2000, Rob Hagopian wrote: > Your comments got me thinking; I tried my situation using Protocol 1 > (forced by sshd) and no problems so far... the repeatable problem using > snaps later than 20001114 (I believe the last one to contain the > patch) has gone away, and it survived the night without leaving a hung > process around (which even 20001114 did). > > Is this of any use? Is there anything else I can do to help track this > down? I'd rather not have to convert to ssh1... > -Rob > > On Mon, 18 Dec 2000 mouring at etoh.eviladmin.org wrote: > > > > > What platform? I know Linux has such an issue. The patch to resolve the > > issue caused scp to not complete it's transfers under meduim loads so > > it was removed. I have/had (somewhere) a hack to work around scp for > > protocol 1. That did not SEEM to cause problems.. But I was not happy > > with it. > > > > I've not been able to verify but does the old 1.2.16 source tree from > > ssh.com produce the same results? There are some major rewrites in the > > lower level channel support that may be the problem. > > > > - Ben > > > > On Mon, 18 Dec 2000, Rachit Siamwalla wrote: > > > > > does this happen if you test this through rsh? > > > > > > If so, i've had a similar problem (unfortunately no good solution > > > though). The way i "solved" the problem is writing my own shellscript > > > that had the same effect. apachectl is probably a shell script too. try > > > cutting out only what is needed and narrow the problem down from there. > > > > > > -rchit > > > > > > > > > Rob Hagopian wrote: > > > > > > > > OK, with openssh-SNAP-20001218 I still have the problem of a hanging ssh > > > > when running (one specific) command on a server. On the server side, > > > > there's a small suid C prog (/usr/dh/mgmt/HupServer) that runs system > > > > "/usr/local/apache/bin/apachectl stop/start". Incidentally, apachectl is a > > > > shell script, hence the need for a suid wrapper for non-root users... On > > > > the client side, there's a shell script that removes the machine from load > > > > balancing and then stops/starts the webserver by sshing to the server and > > > > running the C prog there. > > > > > > > > The problem doesn't arise if I run the HupServer program from the command > > > > line, only from within the shell script that does the load balancing > > > > enable/disable. In that script, the 'stop' command has no problems, only > > > > 'start'. > > > > > > > > - I assumed that a fd was being left open, so I added: > > > > close(2); close(1); close(0); exit(0); > > > > to the C prog, but with no affect... > > > > - Last I checked the -t switch had no affect... > > > > - Hitting Ctrl-C on either debug run finishes the process up cleanly > > > > - During the hanging there is no HupServer executable running on the > > > > server > > > > - The problem was diminished, but not eliminated, by the prior patches to > > > > end the connection before the fds were closed. > > > > > > > > Any ideas on how I can work around this? Would forking HupServer be of any > > > > use? > > > > -Rob > > > > > > > > The ssh dump: > > > > > > > > SSH Version OpenSSH_2.3.0p2, protocol versions 1.5/2.0. > > > > Compiled with SSL (0x0090581f). > > > > debug: Reading configuration data /etc/ssh/ssh_config > > > > debug: Applying options for * > > > > debug: ssh_connect: getuid 500 geteuid 0 anon 0 > > > > debug: Connecting to dhumb400 [10.40.10.10] port 22. > > > > debug: Allocated local port 1022. > > > > debug: Connection established. > > > > debug: identity file /home/prod/.ssh/identity type 0 > > > > debug: identity file /home/prod/.ssh/id_dsa type 3 > > > > debug: Remote protocol version 1.99, remote software version > > > > OpenSSH_2.3.0p2 > > > > debug: no match: OpenSSH_2.3.0p2 > > > > Enabling compatibility mode for protocol 2.0 > > > > debug: Local version string SSH-2.0-OpenSSH_2.3.0p2 > > > > debug: Seeding random number generator > > > > debug: send KEXINIT > > > > debug: done > > > > debug: wait KEXINIT > > > > debug: got > > > > kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > > > > debug: got kexinit: ssh-dss,ssh-rsa > > > > debug: got > > > > kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se > > > > debug: got > > > > kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se > > > > debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > > > > debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > > > > debug: got kexinit: none,zlib > > > > debug: got kexinit: none,zlib > > > > debug: got kexinit: > > > > debug: got kexinit: > > > > debug: first kex follow: 0 > > > > debug: reserved: 0 > > > > debug: done > > > > debug: kex: server->client arcfour hmac-sha1 none > > > > debug: kex: client->server arcfour hmac-sha1 none > > > > debug: Sending SSH2_MSG_KEX_DH_GEX_REQUEST. > > > > debug: Wait SSH2_MSG_KEX_DH_GEX_GROUP. > > > > debug: Got SSH2_MSG_KEX_DH_GEX_GROUP. > > > > debug: bits set: 1002/2049 > > > > debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. > > > > debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. > > > > debug: Got SSH2_MSG_KEXDH_REPLY. > > > > debug: Host 'dhumb400' is known and matches the RSA host key. > > > > debug: bits set: 1034/2049 > > > > debug: ssh_rsa_verify: signature correct > > > > debug: Wait SSH2_MSG_NEWKEYS. > > > > debug: GOT SSH2_MSG_NEWKEYS. > > > > debug: send SSH2_MSG_NEWKEYS. > > > > debug: done: send SSH2_MSG_NEWKEYS. > > > > debug: done: KEX2. > > > > debug: send SSH2_MSG_SERVICE_REQUEST > > > > debug: service_accept: ssh-userauth > > > > debug: got SSH2_MSG_SERVICE_ACCEPT > > > > debug: authentications that can continue: publickey,password > > > > debug: next auth method to try is publickey > > > > debug: try pubkey: /home/prod/.ssh/id_dsa > > > > debug: read SSH2 private key done: name dsa w/o comment success 1 > > > > debug: sig size 20 20 > > > > debug: ssh-userauth2 successfull: method publickey > > > > debug: channel 0: new [client-session] > > > > debug: send channel open 0 > > > > debug: Entering interactive session. > > > > debug: client_init id 0 arg 0 > > > > debug: Sending command: /usr/dh/mgmt/scripts/HupServer start > > > > debug: channel 0: open confirm rwindow 0 rmax 16384 > > > > Environment: > > > > USER=prod > > > > LOGNAME=prod > > > > HOME=/usr/dh/home/prod > > > > PATH=/usr/dh/home/prod/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin > > > > MAIL=/var/mail/prod > > > > SHELL=/usr/local/bin/tcsh > > > > SSH_CLIENT=10.40.12.11 1022 22 > > > > /usr/local/apache/bin/apachectl start: httpd started > > > > debug: client_input_channel_req: rtype exit-status reply 0 > > > > Connection to dhumb400 closed by remote host. > > > > debug: Transferred: stdin 0, stdout 0, stderr 47 bytes in 138.8 seconds > > > > debug: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.3 > > > > debug: Exit status 0 > > > > > > > > and the sshd dump: > > > > debug1: sshd version OpenSSH_2.3.0p2 > > > > debug1: load_private_key_autodetect: type 0 RSA1 > > > > debug1: read SSH2 private key done: name dsa w/o comment success 1 > > > > debug1: load_private_key_autodetect: type 2 DSA > > > > debug1: read SSH2 private key done: name rsa w/o comment success 1 > > > > debug1: load_private_key_autodetect: type 1 RSA > > > > debug1: Bind to port 22 on 0.0.0.0. > > > > Server listening on 0.0.0.0 port 22. > > > > Generating 768 bit RSA key. > > > > RSA key generation complete. > > > > debug1: Server will not fork when running in debugging mode. > > > > Connection from 10.40.12.11 port 1022 > > > > debug1: Client protocol version 2.0; client software version > > > > OpenSSH_2.3.0p2 > > > > debug1: no match: OpenSSH_2.3.0p2 > > > > Enabling compatibility mode for protocol 2.0 > > > > debug1: Local version string SSH-1.99-OpenSSH_2.3.0p2 > > > > debug1: list_hostkey_types: ssh-dss,ssh-rsa > > > > debug1: send KEXINIT > > > > debug1: done > > > > debug1: wait KEXINIT > > > > debug1: got > > > > kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > > > > debug1: got kexinit: ssh-rsa,ssh-dss > > > > debug1: got kexinit: arcfour,3des-cbc,blowfish-cbc,cast128-cbc > > > > debug1: got kexinit: arcfour,3des-cbc,blowfish-cbc,cast128-cbc > > > > debug1: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > > > > debug1: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > > > > debug1: got kexinit: none > > > > debug1: got kexinit: none > > > > debug1: got kexinit: > > > > debug1: got kexinit: > > > > debug1: first kex follow: 0 > > > > debug1: reserved: 0 > > > > debug1: done > > > > debug1: kex: client->server arcfour hmac-sha1 none > > > > debug1: kex: server->client arcfour hmac-sha1 none > > > > debug1: Wait SSH2_MSG_KEX_DH_GEX_REQUEST. > > > > debug1: Sending SSH2_MSG_KEX_DH_GEX_GROUP. > > > > debug1: bits set: 1034/2049 > > > > debug1: Wait SSH2_MSG_KEX_DH_GEX_INIT. > > > > debug1: bits set: 1002/2049 > > > > debug1: send SSH2_MSG_NEWKEYS. > > > > debug1: done: send SSH2_MSG_NEWKEYS. > > > > debug1: Wait SSH2_MSG_NEWKEYS. > > > > debug1: GOT SSH2_MSG_NEWKEYS. > > > > debug1: done: KEX2. > > > > debug1: userauth-request for user prod service ssh-connection method none > > > > debug1: attempt #1 > > > > debug1: Starting up PAM with username "prod" > > > > Failed none for prod from 10.40.12.11 port 1022 ssh2 > > > > debug1: userauth-request for user prod service ssh-connection method > > > > publickey > > > > debug1: attempt #2 > > > > debug1: matching key found: file /usr/dh/home/prod/.ssh/authorized_keys2, > > > > line 2 > > > > debug1: len 55 datafellows 0 > > > > debug1: ssh_dss_verify: signature correct > > > > Could not reverse map address 10.40.12.11. > > > > debug1: PAM setting rhost to "10.40.12.11" > > > > Accepted publickey for prod from 10.40.12.11 port 1022 ssh2 > > > > debug1: Entering interactive session for SSH2. > > > > debug1: server_init_dispatch_20 > > > > debug1: server_input_channel_open: ctype session rchan 0 win 65536 max > > > > 32768 > > > > debug1: input_session_request > > > > debug1: channel 0: new [server-session] > > > > debug1: session_new: init > > > > debug1: session_new: session 0 > > > > debug1: session_open: channel 0 > > > > debug1: session_open: session 0: link with channel 0 > > > > debug1: server_input_channel_open: confirm session > > > > debug1: session_by_channel: session 0 channel 0 > > > > debug1: session_input_channel_req: session 0 channel 0 request exec reply > > > > 0 > > > > debug1: PAM establishing creds > > > > debug1: fd 7 setting O_NONBLOCK > > > > debug1: fd 7 IS O_NONBLOCK > > > > debug1: fd 9 setting O_NONBLOCK > > > > debug1: Received SIGCHLD. > > > > debug1: tvp!=NULL kid 1 mili 100 > > > > debug1: session_by_pid: pid 34260 > > > > debug1: session_exit_message: session 0 channel 0 pid 34260 > > > > debug1: session_exit_message: release channel 0 > > > > debug1: channel 0: write failed > > > > debug1: channel 0: output open -> closed > > > > debug1: channel 0: close_write > > > > debug1: session_free: session 0 pid 34260 > > > > > > > From djm at mindrot.org Wed Dec 20 10:43:38 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 20 Dec 2000 10:43:38 +1100 (EST) Subject: auth-pam.c support for pam_chauthtok() In-Reply-To: <3A3E6069.5CB8EB8D@transmeta.com> Message-ID: On Mon, 18 Dec 2000, Andrew Morgan wrote: > [Much time passes, and I'm working my way through 1600 ssh messages..] > > I believe this patch contains a bug. Its really a Sun documentation bug > that no one noticed until 4 years after Linux had a working PAM > implementation (read, its not going to change in the Linux > implementation of PAM now) and two years after Sun released their first > PAM support. [snip] > * Linux provides a pointer to an array of message pointers. > > * Solaris provides a pointer to a pointer to an array of message > structures (yes this is somewhat bizzarre with one unnecessary level of > indirection). Would this be correct? Index: auth-pam.c =================================================================== RCS file: /var/cvs/openssh/auth-pam.c,v retrieving revision 1.19 diff -u -r1.19 auth-pam.c --- auth-pam.c 2000/12/03 00:51:51 1.19 +++ auth-pam.c 2000/12/19 23:43:09 @@ -97,7 +97,11 @@ return PAM_CONV_ERR; for (count = 0; count < num_msg; count++) { - switch ((*msg)[count].msg_style) { +#ifdef PAM_SUN + switch((*msg)[count].msg_style) { +#else /* PAM_SUN */ + switch(msg[count]->msg_style) { +#endif /* PAM_SUN */ case PAM_PROMPT_ECHO_ON: if (pamstate == INITIAL_LOGIN) { free(reply); Index: auth2-pam.c =================================================================== RCS file: /var/cvs/openssh/auth2-pam.c,v retrieving revision 1.1 diff -u -r1.1 auth2-pam.c --- auth2-pam.c 2000/12/03 00:51:51 1.1 +++ auth2-pam.c 2000/12/19 23:43:10 @@ -79,7 +79,11 @@ packet_put_int(j); /* Number of prompts. */ context_pam2.num_expected = j; for (i = 0, j = 0; i < num_msg; i++) { +#ifdef PAM_SUN switch((*msg)[i].msg_style) { +#else /* PAM_SUN */ + switch(msg[i]->msg_style) { +#endif /* PAM_SUN */ case PAM_PROMPT_ECHO_ON: echo = 1; break; Index: configure.in =================================================================== RCS file: /var/cvs/openssh/configure.in,v retrieving revision 1.205 diff -u -r1.205 configure.in --- configure.in 2000/12/18 19:58:57 1.205 +++ configure.in 2000/12/19 23:43:12 @@ -77,6 +77,7 @@ fi CPPFLAGS="$CPPFLAGS -D_HPUX_SOURCE" IPADDR_IN_DISPLAY=yes + AC_DEFINE(PAM_SUN) AC_DEFINE(USE_PIPES) AC_DEFINE(DISABLE_SHADOW) AC_DEFINE(DISABLE_UTMP) @@ -88,6 +89,7 @@ *-*-hpux11*) CPPFLAGS="$CPPFLAGS -D_HPUX_SOURCE" IPADDR_IN_DISPLAY=yes + AC_DEFINE(PAM_SUN) AC_DEFINE(USE_PIPES) AC_DEFINE(DISABLE_SHADOW) AC_DEFINE(DISABLE_UTMP) @@ -149,6 +151,7 @@ CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib -R/usr/local/lib -L/usr/ucblib -R/usr/ucblib" need_dash_r=1 + AC_DEFINE(PAM_SUN) # hardwire lastlog location (can't detect it on some versions) conf_lastlog_location="/var/adm/lastlog" AC_MSG_CHECKING(for obsolete utmp and wtmp in solaris2.x) @@ -164,6 +167,7 @@ *-*-sunos4*) CPPFLAGS="$CPPFLAGS -DSUNOS4" AC_CHECK_FUNCS(getpwanam) + AC_DEFINE(PAM_SUN) conf_utmp_location=/etc/utmp conf_wtmp_location=/var/adm/wtmp conf_lastlog_location=/var/adm/lastlog -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From ftobin at uiuc.edu Wed Dec 20 12:43:28 2000 From: ftobin at uiuc.edu (Frank Tobin) Date: Tue, 19 Dec 2000 19:43:28 -0600 (CST) Subject: scp remote path specification In-Reply-To: <20001219105103.B27148@faui02.informatik.uni-erlangen.de> Message-ID: Markus Friedl, at 10:51 +0100 on Tue, 19 Dec 2000, wrote: many people have already problems with scp hosta:/file1 hostb:/file2 expanding to ssh hosta 'scp /file1 hostb:/file2' True, openssh appears really broken when having multiple remote hosts on the command line (e.g., it doesn't even appear to do proper name lookups on the second host with "scp fqdn:/etc/hosts non-fqdn:hosts"; I haven't figured out what the other problems are yet), but that doesn't mean we should further cut off the possible of expanded functionality. If it were possible, it surely stands that some are going to want to do: scp a:file1 b:file2 c:file3 d:file4 final_host:final_dir/ If you _ever_ want to do this sort of thing in the future, you need to at least let your design account for it. For example, let the remote-path specification be put into the config file, where you can do host-specific options, instead of an argument, where it is much more difficult to do so. -- Frank Tobin http://www.uiuc.edu/~ftobin/ From mouring at etoh.eviladmin.org Wed Dec 20 13:44:35 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 19 Dec 2000 20:44:35 -0600 (CST) Subject: [PATCH] Re: scp remote path specification In-Reply-To: Message-ID: > @@ -262,8 +265,21 @@ > addargs("-x"); > addargs("-oFallBackToRsh no"); > > + /* check explicit path for ssh binary, default is SSH_PROGRAM */ > + if ((argc > 0) && > + (argv[0] != NULL)) { > + pathsep = strrchr(argv[0], '/'); > + if (pathsep != NULL) { > + pathsep++; > + *pathsep = 0; > + ssh_program = xmalloc(strlen(argv[0]) + 4); /* "../path" + "ssh\0" */ > + strcpy(ssh_program, argv[0]); > + strcat(ssh_program, "ssh"); > + } > + } > + Why do we want to force ssh_program to adopt the the argv[0]'s path? This seems like a bad practice to me. - Ben From mouring at etoh.eviladmin.org Wed Dec 20 14:08:32 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 19 Dec 2000 21:08:32 -0600 (CST) Subject: scp remote path specification In-Reply-To: Message-ID: On Tue, 19 Dec 2000, Frank Tobin wrote: > Markus Friedl, at 10:51 +0100 on Tue, 19 Dec 2000, wrote: > > many people have already problems with > scp hosta:/file1 hostb:/file2 > expanding to > ssh hosta 'scp /file1 hostb:/file2' > > True, openssh appears really broken when having multiple remote hosts on > the command line (e.g., it doesn't even appear to do proper name lookups > on the second host with "scp fqdn:/etc/hosts non-fqdn:hosts"; I haven't > figured out what the other problems are yet), but that doesn't mean we > should further cut off the possible of expanded functionality. If it were > possible, it surely stands that some are going to want to do: > > scp a:file1 b:file2 c:file3 d:file4 final_host:final_dir/ > > If you _ever_ want to do this sort of thing in the future, you need to at > least let your design account for it. For example, let the remote-path > specification be put into the config file, where you can do host-specific > options, instead of an argument, where it is much more difficult to do so. > > Is it supose to work? Doing the above style scp on 1.2.x ssh.com version spits back "User Abort!" since the final resting spot of the file is not local. However the following works (for OpenSSH and ssh v1.2.x): scp a:file1 b:file2 dir/ I would try ssh v2.3.0, but I don't currently have a machine which it's setup on, but I would expect the same results. If you run the same test using 'rcp' (I removed the beast off all my machines years ago) can you succesfully do a: rcp a:file1 b:file2 ? I suspect that the answer is no. - Ben From ftobin at uiuc.edu Wed Dec 20 13:17:34 2000 From: ftobin at uiuc.edu (Frank Tobin) Date: Tue, 19 Dec 2000 20:17:34 -0600 (CST) Subject: scp remote path specification In-Reply-To: Message-ID: mouring at etoh.eviladmin.org, at 21:08 -0600 on Tue, 19 Dec 2000, wrote: Is it supose to work? Doing the above style scp on 1.2.x ssh.com version spits back "User Abort!" since the final resting spot of the file is not local. I'll quote from the scp manpage (ssh version 2.2.0) Any file name may contain a host and user specification to indicate that the file is to be copied to/from that host. Copies between two remote hosts are permitted. rcp, similiarly: Rcp copies files between machines. Each file or directory argument is either a remote file name of the form ``rname at rhost:path'', or a local file name (containing no `:' characters, or a `/' before any `:'s). -- Frank Tobin http://www.uiuc.edu/~ftobin/ From stevesk at pobox.com Wed Dec 20 13:31:02 2000 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 20 Dec 2000 03:31:02 +0100 (CET) Subject: auth-pam.c support for pam_chauthtok() In-Reply-To: Message-ID: On Wed, 20 Dec 2000, Damien Miller wrote: : --- configure.in 2000/12/18 19:58:57 1.205 : +++ configure.in 2000/12/19 23:43:12 : @@ -77,6 +77,7 @@ : fi : CPPFLAGS="$CPPFLAGS -D_HPUX_SOURCE" : IPADDR_IN_DISPLAY=yes : + AC_DEFINE(PAM_SUN) : AC_DEFINE(USE_PIPES) : AC_DEFINE(DISABLE_SHADOW) : AC_DEFINE(DISABLE_UTMP) HP-UX 10* doesn't set and doesn't want to use USE_PAM, so I don't think we should set it for that platform. Also, what about PAM_SUN_CODEBASE, to eliminate confusion about defining it on non-Sun platforms? From djm at mindrot.org Wed Dec 20 13:30:56 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 20 Dec 2000 13:30:56 +1100 (EST) Subject: auth-pam.c support for pam_chauthtok() In-Reply-To: Message-ID: On Wed, 20 Dec 2000, Kevin Steves wrote: > HP-UX 10* doesn't set and doesn't want to use USE_PAM, so I don't think > we should set it for that platform. Fixed - thanks. > Also, what about PAM_SUN_CODEBASE, to eliminate confusion about defining > it on non-Sun platforms? Good idea. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From euske at cl.cs.titech.ac.jp Wed Dec 20 15:24:59 2000 From: euske at cl.cs.titech.ac.jp (SHINYAMA Yusuke) Date: Wed, 20 Dec 2000 13:24:59 +0900 Subject: OpenSSH.com: Japanese translation Message-ID: <20001220042459.19870.qmail@godot.cl.cs.titech.ac.jp> Hello, I have translated the openssh.com web pages into Japanese. What should I do to bring them to the official site? Can I have a cvs account or something for the web site? If this question is not appropriate in this list, please tell me who I should tell to about this matter. Thank you SHINYAMA Yusuke euske at cl.cs.titech.ac.jp From mouring at etoh.eviladmin.org Wed Dec 20 17:34:54 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 20 Dec 2000 00:34:54 -0600 (CST) Subject: scp remote path specification In-Reply-To: Message-ID: On Tue, 19 Dec 2000, Frank Tobin wrote: > mouring at etoh.eviladmin.org, at 21:08 -0600 on Tue, 19 Dec 2000, wrote: > > Is it supose to work? Doing the above style scp on 1.2.x ssh.com version > spits back "User Abort!" since the final resting spot of the file is not > local. > > I'll quote from the scp manpage (ssh version 2.2.0) > > Any file name may contain a host and user specification to > indicate that the file is to be copied to/from that host. Copies > between two remote hosts are permitted. > > rcp, similiarly: > > Rcp copies files between machines. Each file or directory > argument is either a remote file name of the form > ``rname at rhost:path'', or a local file name (containing no `:' > characters, or a `/' before any `:'s). > Actually.. taking a closer look at rcp.c from OpenBSD source. scp is doing the right thing. However the right thing requires that scp final remote host (SiteB) not prompt for a password. One can mimic what you expect by doing: ssh -t SiteA "scp file SiteB:file2" As for a direct scp fix. I don't see a quick thirty second "Duh" fix. - Ben From Jan.Iven at cern.ch Wed Dec 20 18:23:18 2000 From: Jan.Iven at cern.ch (Jan IVEN) Date: 20 Dec 2000 08:23:18 +0100 Subject: [PATCH] Re: scp remote path specification In-Reply-To: mouring@etoh.eviladmin.org's message of "Tue, 19 Dec 2000 20:44:35 -0600 (CST)" References: Message-ID: >>>>> "B" == mouring writes: >> @@ -262,8 +265,21 @@ >> addargs("-x"); >> addargs("-oFallBackToRsh no"); >> >> + /* check explicit path for ssh binary, default is SSH_PROGRAM */ >> + if ((argc > 0) && >> + (argv[0] != NULL)) { >> + pathsep = strrchr(argv[0], '/'); >> + if (pathsep != NULL) { >> + pathsep++; >> + *pathsep = 0; >> + ssh_program = xmalloc(strlen(argv[0]) + 4); /* "../path" + "ssh\0" */ >> + strcpy(ssh_program, argv[0]); >> + strcat(ssh_program, "ssh"); >> + } >> + } >> + B> Why do we want to force ssh_program to adopt the the argv[0]'s path? This B> seems like a bad practice to me. If you have to specify scp's path, it is highly probable that you'd have to specify ssh's path as well since they normally get installed in the same location. Also useful for testing - you don't want to have your test version of scp call the installed version of ssh, but the ssh test version. While you can specify the explicit path to ssh using -S, this is a "convenience hack". A similar feature exists in ssh-1.2.26, so in order to minimize surprises on a transition from commercial ssh to openssh, I added this hack. Best regards Jan From Markus.Friedl at informatik.uni-erlangen.de Wed Dec 20 20:15:37 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 20 Dec 2000 10:15:37 +0100 Subject: scp remote path specification In-Reply-To: ; from ftobin@uiuc.edu on Tue, Dec 19, 2000 at 07:43:28PM -0600 References: <20001219105103.B27148@faui02.informatik.uni-erlangen.de> Message-ID: <20001220101537.A1912@faui02.informatik.uni-erlangen.de> On Tue, Dec 19, 2000 at 07:43:28PM -0600, Frank Tobin wrote: > If you _ever_ want to do this sort of thing in the future, you need to at > least let your design account for it. For example, let the remote-path > specification be put into the config file, where you can do host-specific > options, instead of an argument, where it is much more difficult to do so. there is no config file for scp and ssh does not know anything about scp. scp is just a random protocol over a ssh channel. ssh2 subsystems should fix this problem, but you have to write a scp client for the SFTP-protocol first. who wants to? this would help many people. -markus From Jan.Iven at cern.ch Thu Dec 21 03:35:11 2000 From: Jan.Iven at cern.ch (Jan IVEN) Date: 20 Dec 2000 17:35:11 +0100 Subject: [PATCH] sshd drops connection if host key is not found. Message-ID: Hello, if one of the host keys from the config file cannot be found at runtime, sshd may drop any connection after exchanging the session key. This is due to the fact that uninitialized memory is passed to key_free which either chokes with a fatal "key_free: bad key type" or quietly commits SEGV. A possible solution is appended below. Best regards Jan --- openssh-SNAP-20001213.orig/sshd.c Wed Dec 6 02:42:49 2000 +++ openssh/sshd.c Wed Dec 20 17:26:05 2000 @@ -706,6 +708,7 @@ for(i = 0; i < options.num_host_key_files; i++) { Key *key = load_private_key_autodetect(options.host_key_files[i]); + sensitive_data.host_keys[i] = NULL; if (key == NULL) { error("Could not load host key: %.200s: %.100s", options.host_key_files[i], strerror(errno)); From nigelw at wizardis.com.au Thu Dec 21 11:17:09 2000 From: nigelw at wizardis.com.au (Nigel Williams) Date: 21 Dec 2000 11:17:09 +1100 Subject: Patch to allow DSA as well as RSA identities to be specified on the command line Message-ID: <87u27yeigq.fsf@wizardis.com.au> This patch allows DSA identities to be specified on the command line. Previously, only RSA identities were allowed. ------------------------------------------------------------------------ diff -U2 openssh-2.2.0p1/ssh.0 openssh-2.2.0p1.nigelw/ssh.0 --- openssh-2.2.0p1/ssh.0 Sat Sep 2 10:08:46 2000 +++ openssh-2.2.0p1.nigelw/ssh.0 Thu Dec 21 10:53:07 2000 @@ -224,5 +224,5 @@ -g Allows remote hosts to connect to local forwarded ports. - -i identity_file + -i rsa_identity_file Selects the file from which the identity (private key) for RSA authentication is read. Default is $HOME/.ssh/identity in the @@ -230,4 +230,12 @@ per-host basis in the configuration file. It is possible to have multiple -i options (and multiple identities specified in config- + uration files). + + -I dsa_identity_file + Selects the file from which the identity (private key) for DSA + authentication is read. Default is $HOME/.ssh/id_dsa in the + user's home directory. Identity files may also be specified on a + per-host basis in the configuration file. It is possible to have + multiple -I options (and multiple identities specified in config- uration files). diff -U2 openssh-2.2.0p1/ssh.1 openssh-2.2.0p1.nigelw/ssh.1 --- openssh-2.2.0p1/ssh.1 Tue Aug 29 11:33:51 2000 +++ openssh-2.2.0p1.nigelw/ssh.1 Thu Dec 21 10:56:23 2000 @@ -28,5 +28,6 @@ .Op Fl c Ar cipher_spec .Op Fl e Ar escape_char -.Op Fl i Ar identity_file +.Op Fl i Ar rsa_identity_file +.Op Fl I Ar dsa_identity_file .Op Fl l Ar login_name .Op Fl o Ar option @@ -381,9 +382,21 @@ .It Fl g Allows remote hosts to connect to local forwarded ports. -.It Fl i Ar identity_file +.It Fl i Ar rsa_identity_file Selects the file from which the identity (private key) for RSA authentication is read. Default is .Pa $HOME/.ssh/identity +in the user's home directory. +Identity files may also be specified on +a per-host basis in the configuration file. +It is possible to have multiple +.Fl i +options (and multiple identities specified in +configuration files). +.It Fl I Ar dsa_identity_file +Selects the file from which the identity (private key) for +DSA authentication is read. +Default is +.Pa $HOME/.ssh/id_dsa in the user's home directory. Identity files may also be specified on diff -U2 openssh-2.2.0p1/ssh.c openssh-2.2.0p1.nigelw/ssh.c --- openssh-2.2.0p1/ssh.c Tue Aug 29 11:33:51 2000 +++ openssh-2.2.0p1.nigelw/ssh.c Thu Dec 21 11:01:39 2000 @@ -125,4 +125,5 @@ fprintf(stderr, " -x Disable X11 connection forwarding.\n"); fprintf(stderr, " -i file Identity for RSA authentication (default: ~/.ssh/identity).\n"); + fprintf(stderr, " -I file Identity for DSA authentication (default: ~/.ssh/id_dsa).\n"); fprintf(stderr, " -t Tty; allocate a tty even if command is given.\n"); fprintf(stderr, " -T Do not allocate a tty.\n"); @@ -275,5 +276,5 @@ if (!opt) usage(); - if (strchr("eilcpLRo", opt)) { /* options with arguments */ + if (strchr("eiIlcpLRo", opt)) { /* options with arguments */ optarg = av[optind] + 2; if (strcmp(optarg, "") == 0) { @@ -330,12 +331,24 @@ case 'i': if (stat(optarg, &st) < 0) { - fprintf(stderr, "Warning: Identity file %s does not exist.\n", + fprintf(stderr, "Warning: RSA identity file %s does not exist.\n", optarg); break; } if (options.num_identity_files >= SSH_MAX_IDENTITY_FILES) - fatal("Too many identity files specified (max %d)", + fatal("Too many RSA identity files specified (max %d)", SSH_MAX_IDENTITY_FILES); options.identity_files[options.num_identity_files++] = + xstrdup(optarg); + break; + case 'I': + if (stat(optarg, &st) < 0) { + fprintf(stderr, "Warning: DSA identity file %s does not exist.\n", + optarg); + break; + } + if (options.num_identity_files2 >= SSH_MAX_IDENTITY_FILES) + fatal("Too many DSA identity files specified (max %d)", + SSH_MAX_IDENTITY_FILES); + options.identity_files2[options.num_identity_files2++] = xstrdup(optarg); break; ------------------------------------------------------------------------ Nigel -- Heavily armed, easily bored, and off my medication. From Markus.Friedl at informatik.uni-erlangen.de Thu Dec 21 12:01:13 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 21 Dec 2000 02:01:13 +0100 Subject: Patch to allow DSA as well as RSA identities to be specified on the command line In-Reply-To: <87u27yeigq.fsf@wizardis.com.au>; from nigelw@wizardis.com.au on Thu, Dec 21, 2000 at 11:17:09AM +1100 References: <87u27yeigq.fsf@wizardis.com.au> Message-ID: <20001221020113.A7328@faui02.informatik.uni-erlangen.de> thanks, but 2.2.0 is obsolete. recent openssh versions support -i for ssh1 RSA and ssh2 RSA/DSA keys. On Thu, Dec 21, 2000 at 11:17:09AM +1100, Nigel Williams wrote: > This patch allows DSA identities to be specified on the command > line. Previously, only RSA identities were allowed. > > ------------------------------------------------------------------------ > diff -U2 openssh-2.2.0p1/ssh.0 openssh-2.2.0p1.nigelw/ssh.0 > --- openssh-2.2.0p1/ssh.0 Sat Sep 2 10:08:46 2000 > +++ openssh-2.2.0p1.nigelw/ssh.0 Thu Dec 21 10:53:07 2000 > @@ -224,5 +224,5 @@ > -g Allows remote hosts to connect to local forwarded ports. > > - -i identity_file > + -i rsa_identity_file > Selects the file from which the identity (private key) for RSA > authentication is read. Default is $HOME/.ssh/identity in the > @@ -230,4 +230,12 @@ > per-host basis in the configuration file. It is possible to have > multiple -i options (and multiple identities specified in config- > + uration files). > + > + -I dsa_identity_file > + Selects the file from which the identity (private key) for DSA > + authentication is read. Default is $HOME/.ssh/id_dsa in the > + user's home directory. Identity files may also be specified on a > + per-host basis in the configuration file. It is possible to have > + multiple -I options (and multiple identities specified in config- > uration files). > > diff -U2 openssh-2.2.0p1/ssh.1 openssh-2.2.0p1.nigelw/ssh.1 > --- openssh-2.2.0p1/ssh.1 Tue Aug 29 11:33:51 2000 > +++ openssh-2.2.0p1.nigelw/ssh.1 Thu Dec 21 10:56:23 2000 > @@ -28,5 +28,6 @@ > .Op Fl c Ar cipher_spec > .Op Fl e Ar escape_char > -.Op Fl i Ar identity_file > +.Op Fl i Ar rsa_identity_file > +.Op Fl I Ar dsa_identity_file > .Op Fl l Ar login_name > .Op Fl o Ar option > @@ -381,9 +382,21 @@ > .It Fl g > Allows remote hosts to connect to local forwarded ports. > -.It Fl i Ar identity_file > +.It Fl i Ar rsa_identity_file > Selects the file from which the identity (private key) for > RSA authentication is read. > Default is > .Pa $HOME/.ssh/identity > +in the user's home directory. > +Identity files may also be specified on > +a per-host basis in the configuration file. > +It is possible to have multiple > +.Fl i > +options (and multiple identities specified in > +configuration files). > +.It Fl I Ar dsa_identity_file > +Selects the file from which the identity (private key) for > +DSA authentication is read. > +Default is > +.Pa $HOME/.ssh/id_dsa > in the user's home directory. > Identity files may also be specified on > diff -U2 openssh-2.2.0p1/ssh.c openssh-2.2.0p1.nigelw/ssh.c > --- openssh-2.2.0p1/ssh.c Tue Aug 29 11:33:51 2000 > +++ openssh-2.2.0p1.nigelw/ssh.c Thu Dec 21 11:01:39 2000 > @@ -125,4 +125,5 @@ > fprintf(stderr, " -x Disable X11 connection forwarding.\n"); > fprintf(stderr, " -i file Identity for RSA authentication (default: ~/.ssh/identity).\n"); > + fprintf(stderr, " -I file Identity for DSA authentication (default: ~/.ssh/id_dsa).\n"); > fprintf(stderr, " -t Tty; allocate a tty even if command is given.\n"); > fprintf(stderr, " -T Do not allocate a tty.\n"); > @@ -275,5 +276,5 @@ > if (!opt) > usage(); > - if (strchr("eilcpLRo", opt)) { /* options with arguments */ > + if (strchr("eiIlcpLRo", opt)) { /* options with arguments */ > optarg = av[optind] + 2; > if (strcmp(optarg, "") == 0) { > @@ -330,12 +331,24 @@ > case 'i': > if (stat(optarg, &st) < 0) { > - fprintf(stderr, "Warning: Identity file %s does not exist.\n", > + fprintf(stderr, "Warning: RSA identity file %s does not exist.\n", > optarg); > break; > } > if (options.num_identity_files >= SSH_MAX_IDENTITY_FILES) > - fatal("Too many identity files specified (max %d)", > + fatal("Too many RSA identity files specified (max %d)", > SSH_MAX_IDENTITY_FILES); > options.identity_files[options.num_identity_files++] = > + xstrdup(optarg); > + break; > + case 'I': > + if (stat(optarg, &st) < 0) { > + fprintf(stderr, "Warning: DSA identity file %s does not exist.\n", > + optarg); > + break; > + } > + if (options.num_identity_files2 >= SSH_MAX_IDENTITY_FILES) > + fatal("Too many DSA identity files specified (max %d)", > + SSH_MAX_IDENTITY_FILES); > + options.identity_files2[options.num_identity_files2++] = > xstrdup(optarg); > break; > ------------------------------------------------------------------------ > > Nigel > -- > Heavily armed, easily bored, and off my medication. > From jesus at omniti.com Thu Dec 21 15:04:15 2000 From: jesus at omniti.com (Theo E. Schlossnagle) Date: Wed, 20 Dec 2000 23:04:15 -0500 Subject: OpenSSH/SecurID References: Message-ID: <3A41813F.3A1D8D75@omniti.com> Barrow, Your email motivated me to port my patch to work against 2.3.0p1. I wish I could be so easily motivated to do the other things on my todo list :-) The patch is now available on my projects page: http://www.omniti.com/~jesus/projects/ bhkwan at ThoughtWorks.com wrote: > I found a OpenSSH/SecurID patch from your website, but this is for > Openssh 2.2.0p1. I am wondering if you will post a patch for > Openssh2.3.0p1 soon? -- Theo Schlossnagle 1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F 2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7 From mdejong at cygnus.com Thu Dec 21 18:49:58 2000 From: mdejong at cygnus.com (Mo DeJong) Date: Wed, 20 Dec 2000 23:49:58 -0800 (PST) Subject: Is fixpaths the only perl dependency? In-Reply-To: Message-ID: Hi all. I just did a CVS update and it looks like my patch to remove fixpaths and replace it with an inlined sed script has not yet been added. Just wondering if there was some problem with the patch and I don't remember hearing anything back. I would kind of like to be able to build openssh out of the box under Cygwin and this is the only thing standing in the way. thanks Mo DeJong Red Hat Inc From yusufg at outblaze.com Thu Dec 21 19:03:55 2000 From: yusufg at outblaze.com (Yusuf Goolamabbas) Date: 21 Dec 2000 08:03:55 -0000 Subject: ssh 2.3.0p1 does not seem to fallback protocol from 2 to 1 Message-ID: <20001221080355.15275.qmail@yusufg.portal2.com> Hi, I have the following line in $HOME/.ssh/config Protocol 2,1 I run OpenSSH 2.3.0p1 on my RH 7.0 box running 2.2.18. I am trying to ssh into a FreeBSD 4.2-stable box which runs OpenSSH 2.2.0. The account I am trying to ssh into has two files in $HOME/.ssh authorized_keys and authorized_key2 which contains RSA and DSA keys respectively. >From my RH 7.0 machine, I do the following ssh -v and it gets me in via DSA key Then I rename authorized_keys2 on remote machine to ak_2 and do the same thing. OpenSSH 2.3.0 tries to connect via DSA key and when it can't find the key prompts me for the remote users password. I would have expected it to use the RSA key instead to log me in. Is there something I might have missed Regards, Yusuf -- Yusuf Goolamabbas yusufg at outblaze.com From Roumen.Petrov at skalasoft.com Thu Dec 21 21:27:59 2000 From: Roumen.Petrov at skalasoft.com (Roumen Petrov) Date: Thu, 21 Dec 2000 12:27:59 +0200 Subject: dsa public key file Message-ID: <3A41DB2F.2020903@skalasoft.com> I have just instated ( yesterday ) OpenSSH 2.3.0p1 on my Slack 7.1. Before this I use SSH 2.3.0 which public key certificate and after new generation of dsa user keys I must copy to SSH server. This is problem. SSH 2.3.0 use different file format for public keys. I make two awk scripts to convert public key between OpenSSH and SSH. I am new to this forum ( mailing list ) and don`t known how to post scripts. I attach to my mail dsaKeyConvertor.tgz -------------- next part -------------- A non-text attachment was scrubbed... Name: dsaKeyConvertor.tgz Type: application/octet-stream Size: 819 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001221/c8eb0a6d/attachment.obj From Markus.Friedl at informatik.uni-erlangen.de Thu Dec 21 21:40:03 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 21 Dec 2000 11:40:03 +0100 Subject: dsa public key file In-Reply-To: <3A41DB2F.2020903@skalasoft.com>; from Roumen.Petrov@skalasoft.com on Thu, Dec 21, 2000 at 12:27:59PM +0200 References: <3A41DB2F.2020903@skalasoft.com> Message-ID: <20001221114003.A16606@faui02.informatik.uni-erlangen.de> ssh-keygen -[xXy] does this for you. see ssh-keygen(1) On Thu, Dec 21, 2000 at 12:27:59PM +0200, Roumen Petrov wrote: > I have just instated ( yesterday ) OpenSSH 2.3.0p1 on my Slack 7.1. > Before this I use SSH 2.3.0 which public key certificate and after > new generation of dsa user keys I must copy to SSH server. > This is problem. SSH 2.3.0 use different file format for public keys. > > I make two awk scripts to convert public key between OpenSSH and SSH. > > I am new to this forum ( mailing list ) and don`t known how to post > scripts. I attach to my mail dsaKeyConvertor.tgz From Markus.Friedl at informatik.uni-erlangen.de Thu Dec 21 22:06:20 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 21 Dec 2000 12:06:20 +0100 Subject: ssh 2.3.0p1 does not seem to fallback protocol from 2 to 1 In-Reply-To: <20001221080355.15275.qmail@yusufg.portal2.com>; from yusufg@outblaze.com on Thu, Dec 21, 2000 at 08:03:55AM -0000 References: <20001221080355.15275.qmail@yusufg.portal2.com> Message-ID: <20001221120620.B16606@faui02.informatik.uni-erlangen.de> On Thu, Dec 21, 2000 at 08:03:55AM -0000, Yusuf Goolamabbas wrote: > I would have expected it to use the RSA key instead to log me in. > > Is there something I might have missed yes. your expectations are wrong :) 'Protocol 2,1' means: try to start speak the protocol 2 to the ssh server. if the server does not speak protocol 2, then fallback to protocol 1. you did expect: connect with protocol 2 if possible if authentication fails for some specific method (DSA in your case), don't even try other methods (like passwd) but reconnect with protocol 1 and try RSA auth for example. this will never work. the fallback is for about: what protocol do i speak to the server. once you have chosen a protocol and started speaking it's impossible to change the protocol. hope this makes things clear. -markus From Roumen.Petrov at skalasoft.com Thu Dec 21 22:22:39 2000 From: Roumen.Petrov at skalasoft.com (Roumen Petrov) Date: Thu, 21 Dec 2000 13:22:39 +0200 Subject: dsa public key file References: <3A41DB2F.2020903@skalasoft.com> <20001221114003.A16606@faui02.informatik.uni-erlangen.de> Message-ID: <3A41E7FF.4070608@skalasoft.com> U-u-f-f :-) I have in /etc/ssh_config ... Protocol 2,1 ... and expected ssh-keygen -x to use ~/.ssh/id_dsa ( not ~/.ssh/identity ). O.K. I tested 'ssh-keygen -d -x' but redirection to file is bad. --- #ssh-keygen -d -x 1>xx --- and output begin with: Enter file in which the key is (/.ssh/id_dsa): ---- BEGIN .... and difference is: SSH file: -Subject: -Comment: "1024-bit dsa, @, " Generated form OpenSSH SSH file: +Comment: "1024-bit DSA, converted from OpenSSH by @" but I not found problem to connect to SSH host with generated from OpenSSH pub.file. P.P. About ssh-add: I must add explicitly dsa public key file in this configuration. Markus Friedl wrote: > ssh-keygen -[xXy] does this for you. see ssh-keygen(1) > > On Thu, Dec 21, 2000 at 12:27:59PM +0200, Roumen Petrov wrote: > >> I have just instated ( yesterday ) OpenSSH 2.3.0p1 on my Slack 7.1. >> Before this I use SSH 2.3.0 which public key certificate and after >> new generation of dsa user keys I must copy to SSH server. >> This is problem. SSH 2.3.0 use different file format for public keys. >> >> I make two awk scripts to convert public key between OpenSSH and SSH. >> >> I am new to this forum ( mailing list ) and don`t known how to post >> scripts. I attach to my mail dsaKeyConvertor.tgz From Markus.Friedl at informatik.uni-erlangen.de Thu Dec 21 22:41:27 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 21 Dec 2000 12:41:27 +0100 Subject: dsa public key file In-Reply-To: <3A41E7FF.4070608@skalasoft.com>; from Roumen.Petrov@skalasoft.com on Thu, Dec 21, 2000 at 01:22:39PM +0200 References: <3A41DB2F.2020903@skalasoft.com> <20001221114003.A16606@faui02.informatik.uni-erlangen.de> <3A41E7FF.4070608@skalasoft.com> Message-ID: <20001221124127.A21364@faui02.informatik.uni-erlangen.de> On Thu, Dec 21, 2000 at 01:22:39PM +0200, Roumen Petrov wrote: > U-u-f-f :-) > I have in /etc/ssh_config > ... > Protocol 2,1 > ... > and expected ssh-keygen -x to use ~/.ssh/id_dsa ( not ~/.ssh/identity ). ok :) but man ssh-keygen does not speak about ssh_config. there is not config file for ssh-keygen. only ssh and sshd read config files. > O.K. I tested 'ssh-keygen -d -x' but redirection to file is bad. > --- > #ssh-keygen -d -x 1>xx > > --- > and output begin with: > Enter file in which the key is (/.ssh/id_dsa): ---- BEGIN .... > > and > difference is: > SSH file: > -Subject: > -Comment: "1024-bit dsa, @, " > Generated form OpenSSH SSH file: > +Comment: "1024-bit DSA, converted from OpenSSH by @" > > but I not found problem to connect to SSH host with generated from > OpenSSH pub.file. ok, so ssh-keygen works fine for you? > P.P. > About ssh-add: I must add explicitly dsa public key file in this > configuration. yes. i don't think it should add the file automagically. otherwise you will be prompted for passphrases twice, and so on. and there are ssh-agents that do not know about DSA keys. -markus From Roumen.Petrov at skalasoft.com Thu Dec 21 23:10:32 2000 From: Roumen.Petrov at skalasoft.com (Roumen Petrov) Date: Thu, 21 Dec 2000 14:10:32 +0200 Subject: configure.in: Someone please show me a better way :) Message-ID: <3A41F338.9060302@skalasoft.com> Q: What platform don't run this script: ---------------------------------------- #!/bin/sh export X0='x0' export X1a="$X0/1" export X1b='$X0/1' export X2a="$X1a/2" export X2b='$X1b/2' $SHELL < If I remove all the export and change all the ' in ", it does work on SCO 3.2v5.0.4 |--------+-----------------------------> | | Roumen Petrov | | | | | | | | | 21/12/00 13:10 | | | | |--------+-----------------------------> >----------------------------------------------------------------------------| | | | Pour : openssh-unix-dev at mindrot.org | | cc : (ccc : Philippe WILLEM/CER59/REC) | | Objet : configure.in: Someone please show me a better way :) | >----------------------------------------------------------------------------| Q: What platform don't run this script: ---------------------------------------- #!/bin/sh export X0='x0' export X1a="$X0/1" export X1b='$X0/1' export X2a="$X1a/2" export X2b='$X1b/2' $SHELL < Message-ID: <3A41FEC6.1020008@skalasoft.com> Sorry for mistake for sh file must begin with ------------------------------- X0='x0' X1a="$X0/1" X1b='$X0/1' X2a="$X1a/2" X2b='$X1b/2' export X0 export X1a export X1b export X2a export X2b ------------------------------ Without export don`t work on linux sh ( bash ) Philippe WILLEM wrote: > > If I remove all the export and change all the ' in ", it does work on SCO > 3.2v5.0.4 > > > > |--------+-----------------------------> > | | Roumen Petrov | > | | | | asoft.com> | > | | | > | | 21/12/00 13:10 | > | | | > |--------+-----------------------------> > >----------------------------------------------------------------------------| > | | > | Pour : openssh-unix-dev at mindrot.org | > | cc : (ccc : Philippe WILLEM/CER59/REC) | > | Objet : configure.in: Someone please show me a better way :) | > >----------------------------------------------------------------------------| > > > > Q: What platform don't run this script: > ---------------------------------------- > #!/bin/sh > > export X0='x0' > > export X1a="$X0/1" > export X1b='$X0/1' > > export X2a="$X1a/2" > export X2b='$X1b/2' > > $SHELL < $SHELL < cat < #define a "$X2a/aa" > #define b "$X2b/bb" > EOF > EOF_1 > EOF_2 > ---------------------------------------- > Output must be: > #define a "x0/1/2/aa" > #define b "x0/1/2/bb" > > With bash and bash in sh mode on linux work. > What about other ..UX implementation ? > > Genarated from autoconf variable in configure script like > libexecdir='${exec_prefix}/libexec' > is not expanded in script and substitution > s%@libexecdir@%$libexecdir%g > is usefull only for makefiles. > > if script work file we can use ( about configure.in ) > ---------------------------------------- > ..... > export prefix > export exec_prefix > export bindir > > $SHELL < $SHELL < cat < OpenSSH configured has been configured with the following options. > User binaries: ${bindir} > EOF > EOF_1 > EOF_2 > ..... > ---------------------------------------- > > Is this idea better that: > E=`eval echo ${libexecdir}/ssh-askpass` ; E=`eval echo ${E}` > ..... From Roumen.Petrov at skalasoft.com Fri Dec 22 01:43:24 2000 From: Roumen.Petrov at skalasoft.com (Roumen Petrov) Date: Thu, 21 Dec 2000 16:43:24 +0200 Subject: dsa public key file References: <3A41DB2F.2020903@skalasoft.com> <20001221114003.A16606@faui02.informatik.uni-erlangen.de> Message-ID: <3A42170C.3040507@skalasoft.com> Minor patch for SNAP-20001221: ---------------------------------------------------------------- --- ssh-keygen.c.ORIG Wed Nov 29 03:18:44 2000 +++ ssh-keygen.c Thu Dec 21 16:16:12 2000 @@ -101,8 +101,8 @@ break; } snprintf(identity_file, sizeof(identity_file), "%s/%s", pw->pw_dir, name); - printf("%s (%s): ", prompt, identity_file); - fflush(stdout); + fprintf(stderr, "%s (%s): ", prompt, identity_file); + fflush(stderr); if (fgets(buf, sizeof(buf), stdin) == NULL) exit(1); if (strchr(buf, '\n')) ---------------------------------------------------------------- After this 'ssh-keygen -x > file_name.pub' work fine. From vinschen at redhat.com Fri Dec 22 02:07:17 2000 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 21 Dec 2000 16:07:17 +0100 Subject: [PATCH]: Compile cleanly under Cygwin Message-ID: <00122116071705.10826@cygbert> Hi, the attached patch is relative to the current CVS content. It's needed to build and compile cleanly under Cygwin. The problem are the functions setrlimit/getrlimit. I have added checks for getrlimit, sysconf and setdtablesize to configure.in and appropriate checks in the source code. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh.cygwin.diff Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001221/54eb37ee/attachment.ksh From gem at rellim.com Fri Dec 22 07:05:08 2000 From: gem at rellim.com (Gary E. Miller) Date: Thu, 21 Dec 2000 12:05:08 -0800 (PST) Subject: configure.in: Someone please show me a better way :) In-Reply-To: <3A41F338.9060302@skalasoft.com> Message-ID: Yo Roumen! /bin/sh in SCO fails the script: $ /bin/sh tmp UX:sh (tmp): ERROR: X0=x0: is not an identifier uname -a UnixWare demo 5 7.1.0 i386 x86at SCO UNIX_SVR5 AIX works: $ uname -a AIX aixtest 3 4 0019203D4C00 RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 On Thu, 21 Dec 2000, Roumen Petrov wrote: > > Q: What platform don't run this script: > ---------------------------------------- > #!/bin/sh > > export X0='x0' > > export X1a="$X0/1" > export X1b='$X0/1' > > export X2a="$X1a/2" > export X2b='$X1b/2' > > $SHELL < $SHELL < cat < #define a "$X2a/aa" > #define b "$X2b/bb" > EOF > EOF_1 > EOF_2 > ---------------------------------------- > Output must be: > #define a "x0/1/2/aa" > #define b "x0/1/2/bb" > > With bash and bash in sh mode on linux work. > What about other ..UX implementation ? From gem at rellim.com Fri Dec 22 07:10:55 2000 From: gem at rellim.com (Gary E. Miller) Date: Thu, 21 Dec 2000 12:10:55 -0800 (PST) Subject: =?ISO-8859-1?Q?R=E9f=2E?= : configure.in: Someone please show me a better way :) In-Reply-To: <3A41FEC6.1020008@skalasoft.com> Message-ID: Yo Roumen! That now works on SCO. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 On Thu, 21 Dec 2000, Roumen Petrov wrote: > Sorry for mistake for sh file must begin with > ------------------------------- From mw at moni.msci.memphis.edu Fri Dec 22 08:02:54 2000 From: mw at moni.msci.memphis.edu (Mate Wierdl) Date: Thu, 21 Dec 2000 15:02:54 -0600 Subject: configure.in: Someone please show me a better way :) In-Reply-To: ; from gem@rellim.com on Thu, Dec 21, 2000 at 12:05:08PM -0800 References: <3A41F338.9060302@skalasoft.com> Message-ID: <20001221150254.A5940@moni.msci.memphis.edu> On Thu, Dec 21, 2000 at 12:05:08PM -0800, Gary E. Miller wrote: > Yo Roumen! > > /bin/sh in SCO fails the script: > > $ /bin/sh tmp > UX:sh (tmp): ERROR: X0=x0: is not an identifier Some sh (like Solaris's /bin/sh) does not understand export VAR=value Instead, do VAR=value; export VAR Mate From gert at greenie.muc.de Fri Dec 22 08:32:53 2000 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 21 Dec 2000 22:32:53 +0100 Subject: [PATCH]: Compile cleanly under Cygwin In-Reply-To: <00122116071705.10826@cygbert>; from Corinna Vinschen on Thu, Dec 21, 2000 at 04:07:17PM +0100 References: <00122116071705.10826@cygbert> Message-ID: <20001221223253.B5596@greenie.muc.de> Hi, On Thu, Dec 21, 2000 at 04:07:17PM +0100, Corinna Vinschen wrote: > the attached patch is relative to the current CVS content. It's needed > to build and compile cleanly under Cygwin. The problem are the > functions setrlimit/getrlimit. I have added checks for getrlimit, sysconf > and setdtablesize to configure.in and appropriate checks in the source > code. I second the need for that - I'm right now battling against SCO Unix 3.2v4.2 (ODT 3.0), and it doesn't have setrlimit either. I'll send out a patch for the things not handled here "soon". As soon as I find out why sshd core dumps on me... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From bill.odonnell at doa.state.wi.us Fri Dec 22 10:52:46 2000 From: bill.odonnell at doa.state.wi.us (ODonnell, Bill - DOA) Date: Thu, 21 Dec 2000 17:52:46 -0600 Subject: SSH on OS/390 Unix System Services Message-ID: <28EDA1B41BC1D411BDEA00D0B71DBF841EEA43@doamail04.doa.state.wi.us> Hello Can someone help. I have a real need to have ssh working with OS390 Unix System Services. IBM said that they would like it there as well, but they said the openssh organization has issues with this. Can you help me understand what the deal is or issues are??? Thanks, Bill O'Donnell From tlewis at secureworks.net Fri Dec 22 10:58:39 2000 From: tlewis at secureworks.net (Todd Lewis) Date: Thu, 21 Dec 2000 18:58:39 -0500 (EST) Subject: SSH on OS/390 Unix System Services In-Reply-To: <28EDA1B41BC1D411BDEA00D0B71DBF841EEA43@doamail04.doa.state.wi.us> Message-ID: You should have IBM tell someone exactly what the issues are: they can tell you and you can forward them here, or they can tell the devs directly. -- Todd Lewis tlewis at secureworks.net God grant me the courage not to give up what I think is right, even though I think it is hopeless. - Admiral Chester W. Nimitz On Thu, 21 Dec 2000, ODonnell, Bill - DOA wrote: > Hello > Can someone help. I have a real need to have ssh working with OS390 Unix > System Services. IBM said that they would like it there as well, but they > said the openssh organization has issues with this. Can you help me > understand what the deal is or issues are??? > > Thanks, Bill O'Donnell > From mouring at etoh.eviladmin.org Fri Dec 22 11:57:14 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 21 Dec 2000 18:57:14 -0600 (CST) Subject: SSH on OS/390 Unix System Services In-Reply-To: <28EDA1B41BC1D411BDEA00D0B71DBF841EEA43@doamail04.doa.state.wi.us> Message-ID: I have not even heard of an attempt at a OS/390 port of OpenSSH. If I had access to one I'd be happy to see what issues exist on that platform and see what would be required for such a port. - Ben On Thu, 21 Dec 2000, ODonnell, Bill - DOA wrote: > Hello > Can someone help. I have a real need to have ssh working with OS390 Unix > System Services. IBM said that they would like it there as well, but they > said the openssh organization has issues with this. Can you help me > understand what the deal is or issues are??? > > Thanks, Bill O'Donnell > > From stevesk at pobox.com Fri Dec 22 12:52:31 2000 From: stevesk at pobox.com (Kevin Steves) Date: Fri, 22 Dec 2000 02:52:31 +0100 (CET) Subject: [PATCH]: Compile cleanly under Cygwin In-Reply-To: <00122116071705.10826@cygbert> Message-ID: On Thu, 21 Dec 2000, Corinna Vinschen wrote: : the attached patch is relative to the current CVS content. It's needed : to build and compile cleanly under Cygwin. The problem are the : functions setrlimit/getrlimit. I have added checks for getrlimit, sysconf : and setdtablesize to configure.in and appropriate checks in the source : code. how are hard vs. soft limits handled in the absense of [gs]etrlimit()? with this patch, fdlim_get(1) == fdlim_get(0) so fdlim_set() will never be called. From hj4hj6 at yahoo.com Thu Dec 21 02:47:49 2000 From: hj4hj6 at yahoo.com (hj4hj6 at yahoo.com) Date: 21 Dec 00 2:47:49 PM Subject: Improve your stepfamily life Message-ID: Does your stepfamily life resemble a soap opera more than it does the Brady Bunch? The Stepfamily Association of America invites you to participate in THE NATIONAL CONFERENCE FOR STEPFAMILIES, Feb. 23-24, 2001, at the New Orleans Marriott Hotel. This is an opportunity, designed by knowledgeable professionals, in stepfamilies themselves, to help you: * Make your remarriage a success * Create bonds with your stepchildren * Help your children adjust emotionally * Manage money matters unique to your family * Get more help from legal, financial, psychological advisors * Overcome stepfather and stepmother stereotypes * Elicit cooperation from your children's schools * Bring more harmony into family life Complete conference details at http://www.edupr.com REGISTER ONLINE! Attend, and also enjoy Mardi Gras week in New Orleans! Special discounts for couples, students, groups. HOTEL IS BOOKING UP FAST. ACT NOW BEFORE ROOM BLOCK AND AIRLINE SEATS FILL Special rates for conference attendees. Visit http://www.edupr.com for discounts. Childcare available through a bonded local service. Up to 17 professional development credits available if you are an educator, clinician, financial planner, social worker. Questions? Email stepfamilyconf at mail.com If you would like to be removed, please email us back with the word "Remove" in the subject line. We apologize for any inconvenience. From gert at greenie.muc.de Fri Dec 22 18:35:07 2000 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 22 Dec 2000 08:35:07 +0100 Subject: [PATCH]: Compile cleanly under Cygwin In-Reply-To: ; from Kevin Steves on Fri, Dec 22, 2000 at 02:52:31AM +0100 References: <00122116071705.10826@cygbert> Message-ID: <20001222083507.A15974@greenie.muc.de> Hi, On Fri, Dec 22, 2000 at 02:52:31AM +0100, Kevin Steves wrote: > On Thu, 21 Dec 2000, Corinna Vinschen wrote: > : the attached patch is relative to the current CVS content. It's needed > : to build and compile cleanly under Cygwin. The problem are the > : functions setrlimit/getrlimit. I have added checks for getrlimit, sysconf > : and setdtablesize to configure.in and appropriate checks in the source > : code. > > how are hard vs. soft limits handled in the absense of > [gs]etrlimit()? On SCO 3.0, all you have is ulimit(), and all you can do with it is to read/set the maximum file size (UL_GET/SETFSIZE). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From ruf at tik.ee.ethz.ch Fri Dec 22 21:41:39 2000 From: ruf at tik.ee.ethz.ch (Lukas Ruf) Date: Fri, 22 Dec 2000 11:41:39 +0100 Subject: config.h.in Message-ID: <20001222114139.D10110@ee.ethz.ch> Dear developers, today, I cvs'ed the newest openSSH. Unfortunately, the config.h.in file was missing. I copied it from the tar-ball. Was this my fault or a problem in the CVS ? Thanks for the answer, Lukas -- Lukas Ruf Swiss Federal Institute of Technology Office: ETZ-G61.2 Computer Engineering and Phone: +41/1/632 7312 Networks Laboratory (TIK) Fax: +41/1/632 1035 ETH Zentrum PGP 2.6: ID D20BA2ED; Gloriastr. 35 Fingerprint 6323 B9BC 9C8E 6563 B477 BADD FEA6 E6B7 CH-8092 Zurich From gert at greenie.muc.de Sat Dec 23 00:23:33 2000 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 22 Dec 2000 14:23:33 +0100 Subject: config.h.in In-Reply-To: <20001222114139.D10110@ee.ethz.ch>; from Lukas Ruf on Fri, Dec 22, 2000 at 11:41:39AM +0100 References: <20001222114139.D10110@ee.ethz.ch> Message-ID: <20001222142333.B20596@greenie.muc.de> Hi, On Fri, Dec 22, 2000 at 11:41:39AM +0100, Lukas Ruf wrote: > today, I cvs'ed the newest openSSH. Unfortunately, the config.h.in file > was missing. I copied it from the tar-ball. Was this my fault or a > problem in the CVS ? Just run "autoheader" before running "autoconf". gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From jesus at omniti.com Sat Dec 23 01:39:24 2000 From: jesus at omniti.com (Theo E. Schlossnagle) Date: Fri, 22 Dec 2000 09:39:24 -0500 Subject: SecurID patch. Message-ID: <3A43679C.420ACFF7@omniti.com> What are the chances of getting the SecurID patch integrated into OpenSSH? I think I asked before and was told that it could be done with PAM, but I (and others) are not satisfied with the PAM support. This "tight" integration seems to work much better. If not, I'll just sit on my rogue patches :-( -- Theo Schlossnagle 1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F 2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7 From gmarzot at nortelnetworks.com Sat Dec 23 01:43:13 2000 From: gmarzot at nortelnetworks.com (G. S. Marzot) Date: 22 Dec 2000 09:43:13 -0500 Subject: patch to specify DSA host key on command line Message-ID: --- openssh-2.3.0p1/sshd.c Sat Oct 14 01:23:13 2000 +++ openssh-2.3.0p1.new/sshd.c Tue Dec 19 11:26:51 2000 @@ -506,7 +506,7 @@ initialize_server_options(&options); /* Parse command-line arguments. */ - while ((opt = getopt(ac, av, "f:p:b:k:h:g:V:u:diqQ46")) != EOF) { + while ((opt = getopt(ac, av, "f:p:b:k:h:H:g:V:u:diqQ46")) != EOF) { switch (opt) { case '4': IPv4or6 = AF_INET; @@ -557,6 +557,9 @@ case 'h': options.host_key_file = optarg; break; + case 'H': + options.host_dsa_key_file = optarg; + break; case 'V': client_version_string = optarg; /* only makes sense with inetd_flag, i.e. no listen() */ @@ -578,8 +581,9 @@ fprintf(stderr, " -k seconds Regenerate server key every this many seconds (default: 3600)\n"); fprintf(stderr, " -g seconds Grace period for authentication (default: 300)\n"); fprintf(stderr, " -b bits Size of server RSA key (default: 768 bits)\n"); - fprintf(stderr, " -h file File from which to read host key (default: %s)\n", - HOST_KEY_FILE); + fprintf(stderr, " -h file File from which to read host key (default: %s)\n",HOST_KEY_FILE); + fprintf(stderr, " -H file File from which to read DSA host key (default: %s)\n",HOST_DSA_KEY_FILE); + fprintf(stderr, " -u len Maximum hostname length for utmp recording\n"); fprintf(stderr, " -4 Use IPv4 only\n"); fprintf(stderr, " -6 Use IPv6 only\n"); -- G.S. Marzot email: gmarzot at nortelnetworks.com Nortel Networks voice: (978)288-3990 600 Tech Park M/S E65-60-405 Billerica, MA 01821 fax: (978)670-8145 From gert at greenie.muc.de Sat Dec 23 02:01:33 2000 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 22 Dec 2000 16:01:33 +0100 Subject: bug in sshd.d (destroy_sensitive_data core dumps) Message-ID: <20001222160133.A24143@greenie.muc.de> Hi, experimenting with openssh_cvs on my SCO Unix 3.2v4.2 machine, I had sshd core dumping on me. Tracking this, I found that if a host key is specified in the sshd_config that does not exist (I used "./sshd -d -d -d -f sshd_config" with the shipped sshd_config file, to work around incompatibilities with the installed sshd.com's sshd_config, and I do not have ssh2 host keys on this machine), sshd will leave sensitive_data.host_keys[] uninitialized - the memory area is malloc()ed, so never initialized, and later on destroy_sensitive_data reads a pointer from it and tries to overwrite *that* memory location. A quick fix is appended below: if a host key file can't be read, host_keys[i] is set to NULL. This does not seem to have adverse effects, and the core dumps go away. The patch is off by a few lines due to other changes (debugging added to track this). gert Index: sshd.c =================================================================== RCS file: /cvs/openssh_cvs/sshd.c,v retrieving revision 1.101 diff -u -r1.101 sshd.c --- sshd.c 2000/12/15 23:31:01 1.101 +++ sshd.c 2000/12/22 14:56:29 @@ -702,6 +706,7 @@ if (key == NULL) { error("Could not load host key: %.200s: %.100s", options.host_key_files[i], strerror(errno)); + sensitive_data.host_keys[i] = NULL; continue; } switch(key->type){ -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From gert at greenie.muc.de Sat Dec 23 02:17:52 2000 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 22 Dec 2000 16:17:52 +0100 Subject: bug in sshd.c (destroy_sensitive_data core dumps) In-Reply-To: <20001222160133.A24143@greenie.muc.de>; from Gert Doering on Fri, Dec 22, 2000 at 04:01:33PM +0100 References: <20001222160133.A24143@greenie.muc.de> Message-ID: <20001222161752.D22141@greenie.muc.de> Hi, On Fri, Dec 22, 2000 at 04:01:33PM +0100, Gert Doering wrote: > Tracking this, I found that if a host key is specified in the sshd_config > that does not exist (I used "./sshd -d -d -d -f sshd_config" with the > shipped sshd_config file, to work around incompatibilities with the > installed sshd.com's sshd_config, and I do not have ssh2 host keys on > this machine), sshd will leave > > sensitive_data.host_keys[] > > uninitialized - the memory area is malloc()ed, so never initialized, and > later on destroy_sensitive_data reads a pointer from it and tries to > overwrite *that* memory location. ... and right after sending out this mail, I found that in the current CVS (as of today!), this bug has been fixed. So please ignore my e-mail. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From vinschen at redhat.com Sat Dec 23 03:23:06 2000 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 22 Dec 2000 17:23:06 +0100 Subject: [PATCH]: Compile cleanly under Cygwin In-Reply-To: <20001222083507.A15974@greenie.muc.de> References: <00122116071705.10826@cygbert> <20001222083507.A15974@greenie.muc.de> Message-ID: <00122217230600.00503@cygbert> On Friday 22 December 2000 08:35, Gert Doering wrote: > Hi, > > On Fri, Dec 22, 2000 at 02:52:31AM +0100, Kevin Steves wrote: > > On Thu, 21 Dec 2000, Corinna Vinschen wrote: > > : the attached patch is relative to the current CVS content. It's > > : needed to build and compile cleanly under Cygwin. The problem are > > : the functions setrlimit/getrlimit. I have added checks for > > : getrlimit, sysconf and setdtablesize to configure.in and > > : appropriate checks in the source code. > > > > how are hard vs. soft limits handled in the absense of > > [gs]etrlimit()? > > On SCO 3.0, all you have is ulimit(), and all you can do with it is > to read/set the maximum file size (UL_GET/SETFSIZE). And on Cygwin it's more or less the same. There doesn't exist any hard limit or at least can't be inquired. I know that fdlim_set isn't called under these circumstances but I think it's not that clean to patch only one function and simply assume that the calling function will never change it's behaviour. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From gert at greenie.muc.de Sat Dec 23 04:34:41 2000 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 22 Dec 2000 18:34:41 +0100 Subject: Makefile dependencies Message-ID: <20001222183441.A4844@greenie.muc.de> Hi, the openssh_cvs Makefile includes the following rules: $(LIBSSH_OBJS): config.h $(LIBOPENBSD_COMPAT_OBJS): config.h but no equivalent for $(LIBSSHD_OBJS) - is this desired or an oversigt? In my case, I built the sshd, tested it, reconfigured with SKEY support, rebuilt (just running "make", no "make clean"), and tracked down the non-working s/key for a while before I noticed that servconf.o hadn't been rebuilt, thus the server still had no skey... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From jason at oddjob.utias.utoronto.ca Sat Dec 23 05:32:06 2000 From: jason at oddjob.utias.utoronto.ca (Jason Lassaline) Date: Fri, 22 Dec 2000 13:32:06 -0500 Subject: XAUTHORITY=/tmp/ssh-*/cookies makes forwarding through firewall difficult... Message-ID: <3A439E26.4F2F7D2B@oddjob.utias.utoronto.ca> Hi. I see this XAUTHORITY=/tmp/ssh-*/cookies issue has been discussed repeatedly, but I haven't seen a solution to the following problem. Remote user logs into firewall. On firewall, DISPLAY var set to secure channel, XAUTHORITY set to /tmp/ssh-*/cookies. X11 forwarding from firewall works fine. User logs into machine behind firewall, and sets DISPLAY var to firewall:X11DisplayOffset.0. Xauth fails because neither XAUTHORITY nor ~/.Xauthority are correct. /tmp on firewall is not visible to machines behind firewall. Problem is independent of broken login scripts that bash XAUTHORITY. A workaround I've found that works: Remote user logs into firewall. On firewall: 'cat $XAUTHORITY >> ~/.Xauthority'. Log into machine behind firewall, & set DISPLAY to firewall:X11DisplayOffset.0. Now I understand that setting XAUTHORITY to something local other than $HOME makes it easier to control XAUTHORITY bashing and cleanup upon exit. However, as you see by the above there is no way (that I can find) of getting OpenSSH to put the cookie elsewhere than /tmp/ssh-*/cookies. Why not set the cookie to /tmp/ssh-*/cookies & append a copy to ~/.Xauthority? Makes the clean up on exit issue more difficult, but still possible. Pls cc: me on replies, I'm not subscribed to this list. Thanx. Jason. From ramki at taos.com Sat Dec 23 14:36:56 2000 From: ramki at taos.com (Ramki Balasubramanian) Date: Fri, 22 Dec 2000 19:36:56 -0800 Subject: OpenSSH-2.3.0p1 patch for yet another F-secure version Message-ID: <20001222193656.A29211@shell.taos.com> Hi, Here's a problem in openssh, some logs, and a very minor patch that cures this: Issue: (open)ssh client WILL NOT talk to F secure SSH-2.0-2.1.0pl2 client S/W version: openssh-2.3.0p1 client O/S version: SunOS 5.7 Generic_106541-11 sun4u sparc server S/W version: SSH-2.0-2.1.0pl2 server O/S version: SunOS 5.7 Generic_106541-11 sun4u sparc Log/Details: : % telnet 22 : Trying xx.xx.xx.xx... : Connected to sd099001. : Escape character is '^]'. : SSH-2.0-2.1.0.pl2 SSH Secure Shell (non-commercial) : % ssh : .. : autodetect SSH_BUG_SIGBLOB : .. : len 20 datafellows -2 : : Received packet with bad string length ...... : ...DIES.... Actual problem: compat_datafellows() in compat.c does not recognize 2.1.0.pl2 version of SSH as 2.1.0, so it sets the variable "datafellows" to the wrong value. This causes death. one Working patch to the problem: --------------------------------- *** compat.c Sat Nov 4 21:42:36 2000 --- compat.c.new Fri Dec 22 11:10:52 2000 *************** *** 66,71 **** --- 66,74 ---- { "MindTerm", 0 }, { "^2\\.1\\.0 ", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| SSH_OLD_SESSIONID }, + /* yetanother 2.1.0 */ + { "^2\\.1\\.0.pl2 ", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| + SSH_OLD_SESSIONID }, { "^2\\.0\\.", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| SSH_OLD_SESSIONID| SSH_BUG_PUBKEYAUTH|SSH_BUG_X11FWD }, From mouring at etoh.eviladmin.org Sat Dec 23 07:52:10 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 22 Dec 2000 14:52:10 -0600 (CST) Subject: config.h.in In-Reply-To: <20001222142333.B20596@greenie.muc.de> Message-ID: Or just type: make distprep -f Makefile.in ./configure and everything will be fine. - Ben On Fri, 22 Dec 2000, Gert Doering wrote: > Hi, > > On Fri, Dec 22, 2000 at 11:41:39AM +0100, Lukas Ruf wrote: > > today, I cvs'ed the newest openSSH. Unfortunately, the config.h.in file > > was missing. I copied it from the tar-ball. Was this my fault or a > > problem in the CVS ? > > Just run "autoheader" before running "autoconf". > > gert > From pekkas at netcore.fi Sat Dec 23 07:00:39 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 22 Dec 2000 22:00:39 +0200 (EET) Subject: OpenSSH-2.3.0p1 patch for yet another F-secure version In-Reply-To: <20001222193656.A29211@shell.taos.com> Message-ID: On Fri, 22 Dec 2000, Ramki Balasubramanian wrote: [snip] > server S/W version: SSH-2.0-2.1.0pl2 > server O/S version: SunOS 5.7 Generic_106541-11 sun4u sparc [snip] > { "MindTerm", 0 }, > { "^2\\.1\\.0 ", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| > SSH_OLD_SESSIONID }, > + /* yetanother 2.1.0 */ > + { "^2\\.1\\.0.pl2 ", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| > + SSH_OLD_SESSIONID }, > { "^2\\.0\\.", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| > SSH_OLD_SESSIONID| > SSH_BUG_PUBKEYAUTH|SSH_BUG_X11FWD }, This has been fixed 3 weeks ago in CVS: --- - markus at cvs.openbsd.org 2000/12/03 11:27:55 [compat.c] correctly match "2.1.0.pl2 SSH" etc; from pekkas at netcore.fi/bugzilla.redhat --- CVS snapshots are available at http://bass.directhit.com/openssh_snap/ -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From mouring at etoh.eviladmin.org Sat Dec 23 08:15:48 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 22 Dec 2000 15:15:48 -0600 (CST) Subject: Makefile dependencies In-Reply-To: <20001222183441.A4844@greenie.muc.de> Message-ID: On Fri, 22 Dec 2000, Gert Doering wrote: > Hi, > > the openssh_cvs Makefile includes the following rules: > > $(LIBSSH_OBJS): config.h > > $(LIBOPENBSD_COMPAT_OBJS): config.h > > but no equivalent for $(LIBSSHD_OBJS) - is this desired or an oversigt? > > In my case, I built the sshd, tested it, reconfigured with SKEY support, > rebuilt (just running "make", no "make clean"), and tracked down the > non-working s/key for a while before I noticed that servconf.o hadn't > been rebuilt, thus the server still had no skey... > LIBSSH_OBJS is used to build the libssh.a library. SSHOBJS and SSHDOBJS are used to build the ssh and sshd binaries. Below is two lines to insert into your Makefile.in which should ensure that all ssh and sshd objects are recompiled on changes in config.h, but that still leaves all the other commands (ssh-keygen, ssh-keyscan, etc) with potentially out of date object files. -- Add on Makefile.in after $(LIBSSH_OBJS): config.h line -- $(SSHOBJS): config.h $(SSHDOBJS): config.h -- Snip --- I strongly suggest doing a 'make clean' after any new ./configure (or change to config.h) to ensure that all object files are up to date. - Ben From res at shore.net Sun Dec 24 14:24:58 2000 From: res at shore.net (Richard E. Silverman) Date: Sat, 23 Dec 2000 22:24:58 -0500 (EST) Subject: XAUTHORITY=/tmp/ssh-*/cookies makes forwarding through firewall difficult... In-Reply-To: <3A439E26.4F2F7D2B@oddjob.utias.utoronto.ca> Message-ID: On Fri, 22 Dec 2000, Jason Lassaline wrote: > A workaround I've found that works: > Remote user logs into firewall. On firewall: 'cat $XAUTHORITY >> > ~/.Xauthority'. Log into machine behind firewall, & set DISPLAY to > firewall:X11DisplayOffset.0. This appears to imply that your accounts on the firewall box and on the "machine behind firewall" are sharing a home directory via NFS. It strikes me as a rather odd arrangement. In any event, if that's so, then you are sending your proxy display key in the clear over your private network when you do this copy. > Why not set the cookie to /tmp/ssh-*/cookies & append a copy to > ~/.Xauthority? Makes the clean up on exit issue more difficult, but > still possible. Because the point of putting it under /tmp is to avoid the problem I just mentioned. Just copy your proxy display key over the secure connection. You can do this via cut-and-paste with "xauth add", or like this as a separate command: firewall% xauth extract - $DISPLAY | ssh other-box xauth merge - -- Richard Silverman slade at shore.net From lists at fips.de Mon Dec 25 01:42:17 2000 From: lists at fips.de (Philipp Buehler) Date: Sun, 24 Dec 2000 15:42:17 +0100 Subject: scp -f / interactive ? Message-ID: <20001224154217.A12535@pohl.fips.de> Hi, % scp -v user at host:file.txt . [..] debug: Remote protocol version 1.99, remote software version OpenSSH_2.3.0p1 debug: Local version string SSH-1.5-OpenSSH_2.1.1 [..] debug: Sending command: scp -v -f file.txt debug: Entering interactive session. Sending file modes: C0644 3093316 file.txt Since it 'interactives' the remote user needs a shell. Any workaround? But more interesting is that scp -f call. Didnt found it in the manpage? Is this related to the background-mechanism like ssh -f ? ciao -- Philipp Buehler, aka fIpS | sysfive.com GmbH | BOfH | NUCH | %SYSTEM-F-TOOEARLY, please contact your sysadmin at a sensible time. Artificial Intelligence stands no chance against Natural Stupidity. [X] <-- nail here for new monitor From res at shore.net Mon Dec 25 02:22:53 2000 From: res at shore.net (Richard E. Silverman) Date: Sun, 24 Dec 2000 10:22:53 -0500 (EST) Subject: scp -f / interactive ? In-Reply-To: <20001224154217.A12535@pohl.fips.de> Message-ID: On Sun, 24 Dec 2000, Philipp Buehler wrote: > debug: Sending command: scp -v -f file.txt > debug: Entering interactive session. > Sending file modes: C0644 3093316 file.txt > > Since it 'interactives' the remote user needs a shell. This message is misleading. What it really means is that the client is starting an SSH "exec" channel to run a remote program; it will always print that. > Any workaround? No, because sshd uses the remote user's shell to run any program it needs to start, via "$SHELL -c ". > But more interesting is that scp -f call. Didnt found it in the > manpage? Is this related to the background-mechanism like > ssh -f ? No. -f and -t are undocumented switches which tell the remote scp to send or prepare to receive a file or files from the local scp. -- Richard Silverman slade at shore.net From karl at gnu.org Mon Dec 25 12:02:15 2000 From: karl at gnu.org (karl at gnu.org) Date: Sun, 24 Dec 2000 20:02:15 -0500 (EST) Subject: hostinstall target? Message-ID: <200012250102.UAA04637@vortex.ma.intuit.com> It would be very useful if openssh could have the same sort of hostinstall target that traditional ssh does. The ssh programs only have to be installed once, for central distribution via nfs or rdist or whatever, but every host needs its key ... Thanks for a great program. karl at gnu.org From openssh-unix-dev at progressive-comp.com Mon Dec 25 19:40:06 2000 From: openssh-unix-dev at progressive-comp.com (Hank Leininger) Date: Mon, 25 Dec 2000 03:40:06 -0500 Subject: scp -f / interactive ? Message-ID: <200012250840.DAA05059@mailer.progressive-comp.com> On 2000-12-24, "Richard E. Silverman" wrote: > On Sun, 24 Dec 2000, Philipp Buehler wrote: > > debug: Sending command: scp -v -f file.txt > > debug: Entering interactive session. > > Sending file modes: C0644 3093316 file.txt > > > > Since it 'interactives' the remote user needs a shell. [snip] > > Any workaround? > No, because sshd uses the remote user's shell to run any program it > needs to start, via "$SHELL -c ". Well, depending on what qualifies as a "workaround," yes there is. If, for instance, you want user 'foo' to only ever access drop directories to upload or download files, and your goal is to be able to keep that account from getting access to a regular shell (via ssh or other usual means), you can: -Use RSA/DSA authentication only -Give the user 'foo' their own group 'foo' -Make their home directory owned by root.foo and mode 710 or so; this prevents .forward, .shosts, etc tricks -Make their .ssh and .ssh/authorized_keys{,2} files root.foo, not writable by group foo -Create a ~foo/in directory which is root.foo mode 1730 -Use an RSA or DSA public key with 'command="scp -t in"' in authorized_keys and all other fun things disabled (no-pty,no-*-forwarding, etc), using that identity to start uploads[0] -Create a ~foo/out directory which is root.foo mode 750 -Use a public key with 'command="scp -f out/*"', using that identity to start downloads[1] -Set environment="PATH=/path/to/sshbins" in the authorized_keys entries for paranoia's sake, since 'scp' gets started w/no path specified -Lock the user's password in the shadow file (simply put in a '*', etc), this blocks conventional login methods as well as forcing RSA/DSA auth via the specially crafted authorized_keys files -If possible, add from="..." tokens to the authorized_keys files to only allow transfers to/from a set of possible addresses -Optionally, write a small "shell" wrapper which checks the parent process is sshd, allows only the arguments '-c scp (-t in|-f out/*)', and exits w/error code if started up any other way. A small, properly paranoid perl script would do. ("Doing it right" in C would probably be a nice contrib-able project for some student.) This will further block conventional access to the account. This'll result in an account which can upload and/or download files into subdirectories of their home directory, and nothing else. To make life easier, you *may* want a third identity whose key has a command="..." which renames 'in/tmpfile' to 'done/tmpfile'. This makes it easy to tell, lazily, when a file is done being uploaded simply by checking for its existance in 'done' as opposed to fuser'ing it and checking when scp is done writing to it in 'in'.[2] Besides the obvious caveats, does anybody see anything fundamentally wrong with the above (besides that it sounds complex and painful; really it isn't after the first or second time ;) ? Bonus points for using the chroot patch for sshd ( http://marc.theaimsgroup.com/?t=97237758900001&r=1&w=2 ) and arranging for the scp to be done chrooted under their home directory, especially since scp still has the "evil server can cause writes to arbitrary files" bug -- see http://marc.theaimsgroup.com/?l=bugtraq&r=1&s=scp+file+transfer+hole&q=b (I've just verified that 2.3.0p1 running either protocol 1 *or* 2, contrary to the discussion at the time, is vulnerable). I have to wonder if a client couldn't fool the server into doing the reverse--feeding it and/or writing to files not requested on the command line and thus screened by the command="..." and/or custom shells. Of course the chroot env setup would take a bit more work (static wrapper shell && scp in /home/foo/bin/, etc). [0 Many of these things ought be done in /etc/sshd_config anyway on a "trust no one" box--sshd should turn off various forwardings, set only RSAAuthentication, etc. But they won't hurt to put in the keys files as well. ] [1 AFAIK the path/file being downloaded will be in scp's command line, so must be present in the command="..." entry. This is the best workaround for transferring arbitrary filenames and not having to use either one fixed name, or keeping multiple downloader authorized_keys entries around that I can think of. While it's fugly, I don't think it really adds risk (though it does require that the download dir be readable...). It'd be nice if there was a cleaner way... anyone? A fake wrapper shell could perhaps enforce this more elegantly, but it'd be nice if it didn't have to, since ssh's command="..." *almost* gets it perfect. ] [2 This of course creates the "but then I can only upload one file at a time" problem. Oh well, nothing's perfect... make the wrapper shell able to do this more generally (rename in/*, etc), I guess. ] -- Hank Leininger From djm at mindrot.org Mon Dec 25 23:35:53 2000 From: djm at mindrot.org (Damien Miller) Date: Mon, 25 Dec 2000 23:35:53 +1100 (EST) Subject: hostinstall target? In-Reply-To: <200012250102.UAA04637@vortex.ma.intuit.com> Message-ID: On Sun, 24 Dec 2000 karl at gnu.org wrote: > It would be very useful if openssh could have the same sort of > hostinstall target that traditional ssh does. The ssh programs only > have to be installed once, for central distribution via nfs or rdist or > whatever, but every host needs its key ... What does the hostinstall target do? OpenSSH does support a "host-key" which will generate keys in @sysconfdir@ -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From djm at mindrot.org Mon Dec 25 23:38:05 2000 From: djm at mindrot.org (Damien Miller) Date: Mon, 25 Dec 2000 23:38:05 +1100 (EST) Subject: SecurID patch. In-Reply-To: <3A43679C.420ACFF7@omniti.com> Message-ID: On Fri, 22 Dec 2000, Theo E. Schlossnagle wrote: > What are the chances of getting the SecurID patch integrated into > OpenSSH? I think I asked before and was told that it could be done > with PAM, but I (and others) are not satisfied with the PAM support. What is wrong with the PAM support? Have you tried the KbdInteractive support in the snapshots? -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From karl at gnu.org Tue Dec 26 03:33:49 2000 From: karl at gnu.org (karl at gnu.org) Date: Mon, 25 Dec 2000 11:33:49 -0500 Subject: hostinstall target? Message-ID: <200012251633.LAA05288@billohost.com> Hi Damien, What does the hostinstall target do? OpenSSH does support a "host-key" which will generate keys in @sysconfdir@ Yes, and this is the most important thing that hostinstall does too. However, host-key by itself fails by itself without doing a full `install' first: couldn't read entropy commands file /l/etc/openssh/ssh_prng_cmds: No such file or directory couldn't read entropy commands file /l/etc/openssh/ssh_prng_cmds: No such file or directory (I've configured with --sysconfdir=/l/etc/openssh.) So, the parts of install that host key generation depends on could be split off into a separate target, that host-key could depend on. This is ssh_prng_commands and the config files, at least; I didn't actually try it, so don't know if there's anything else. Thanks (and happy holidays :), Karl From primus at gblx.net Tue Dec 26 07:31:36 2000 From: primus at gblx.net (primus) Date: Mon, 25 Dec 2000 20:31:36 +0000 Subject: ssh-agent and protocol 2 ... Message-ID: <20001225203136.L9279@gblx.net> Mon Dec 25 20:19:05 GMT 2000 Greetings. I noticed that in OpenSSH_2.2.0, DSA keys were allowed to be added to ssh-agent, however the ability for allowing ForwardAgent does not yet seem in place for protocol-2. I've noticed that when using protocol-2, no socket is created in /tmp/ssh-*/, and consequently SSH_AUTH_SOCK is not being set. Hence the ability to ssh to another machine (using protocol-1 or protocol-2) without being asked for a password is lost. Is this something currently under development, or is it just a completely bad idea? If the latter, what are the technical reasons? Cheers. -- primus From mike at hyperreal.org Tue Dec 26 12:05:57 2000 From: mike at hyperreal.org (mike at hyperreal.org) Date: Mon, 25 Dec 2000 17:05:57 -0800 (PST) Subject: openssh 2.2, fbsd 4.2: incoming data hangs sshd on tty Message-ID: <20001226010557.9861.qmail@hyperreal.org> This message is reporting 2 possible bugs: a possible problem with sshd from OpenSSH 2.2 on FreeBSD 4.2, and a possible security hole in FreeBSD's boot process (??) I am not an expert on these kinds of issues and therefore do not have the knowledge necessary to trace the origins of the problem to the extent that would probably be helpful. Nevertheless, here goes: Here is the physical environment: - dual Pentium 133 box running a fresh install of FreeBSD 4.2-RELEASE - OpenSSH 2.2 installed as a package at O/S install time - 2 NICs in the box; natd running to provide a LAN with Internet access - net connection is 256 kbps DSL Here is the problem: sshd, specifically the forked sshd process that is attached to a terminal when a connection is made, tends to freeze when receiving data over the link. The only way out is to kill -9 this process. It is easily reproducible by pasting text into an editor. It is reproducible using different SSH clients, and it does not matter if I am connecting from the LAN or from the Internet, thus ruling out the possibility of it being related to one of the network cards or the speed of the connection (the DSL connection being much slower than the LAN). This happens often enough that I can't do much of anything with my system unless I sit at the console or use insecure telnet. What can I do to diagnose this problem further? If someone on the OpenSSH project wants access to my box, contact me privately and that can be arranged. ... Now for the security problem. While trying to diagnose the problem, I tried running sshd in debug mode. To do this I put sshd_flags="-d" in /etc/rc.conf, and rebooted with 'shutdown -r now'. Various debug messages appeared in the console when I SSH'd in, but the only message of interest was "debug: tvp!=NULL kid 0 mili 10", which was repeated a number of times. However, neither this message nor any other appeared when I pasted some text to induced the freeze-up. Since it didn't look like debug mode was telling me anything useful, I decided to reboot again and not be in debug mode. I left the child sshd hung and telnetted in, since the main sshd, in debug mode, only allows one connection by design. I removed the extra line from /etc/rc.conf and issued another 'shutdown -r now'. I got a console message saying shutdown: reboot by mike, and then ... nothing! So from my telnet session I killed the hung sshd child. This is the really scary part. The machine apparently thought that it had already gone through the initial boot stages. The next messages that came up on my console were typical of what you see at the last stages of a bootup: . Initial rc.i386 initialization:. rc.i386 configuring syscons: keyrate font8x16 font8x14 font8x8 blank_time screensaver. additional ABI support: linux. Local package initialization: apache dnetc. Additional TCP options:. Raising kernel security level kern.securelevel: -1 -> 2 Mon Dec 25 17:05:10 MST 2000 followed by a login prompt. ...All this *without ever dropping the telnet connection*. A few minutes later, I lost all Internet connectivity. The LAN and telnet connection stayed up. A subsequent 'shutdown -r now' achieved a full reboot and the Internet was again accessible. Is this normal?!? Did I find some kind of security hole? What's interesting is that the console messages on the false reboot are what you see right after the line that normally says starting standard daemons: inetd cron sendmail sshd. Note that the period did appear in the false reboot. Well I hope this is of some use to someone. Please contact me for any further info. I'm not on the openssh-unix-dev list but I am on the freebsd-questions list. Thanks, - Mike ________________________________________________________________________ Mike Brown / Hyperreal | Hyperreal http://music.hyperreal.org/ PO Box 61334 | XML & XSL http://skew.org/xml/ Denver CO 80206-8334 USA | personal http://www.hyperreal.org/~mike/ From mike at hyperreal.org Tue Dec 26 13:30:20 2000 From: mike at hyperreal.org (mike at hyperreal.org) Date: Mon, 25 Dec 2000 18:30:20 -0800 (PST) Subject: openssh 2.2, fbsd 4.2: incoming data hangs sshd on tty In-Reply-To: From "(env:" "mike)" at "Dec 25, 2000 05:05:57 pm" Message-ID: <20001226023020.13748.qmail@hyperreal.org> I wrote: > sshd, specifically the forked sshd process that is attached to a terminal > when a connection is made, tends to freeze when receiving data over the link. > The only way out is to kill -9 this process. It is easily reproducible by > pasting text into an editor. With the help of someone who advised me to run ktrace on the sshd process that freezes, I have narrowed down the circumstances under which the problem is reproducible, and I discovered that sshd does receive a little bit more data from the paste than I get to see coming back from the editor. It seems to have to do with whatever the pico (yes, pico, old habits die hard) editor is doing when it is receiving keystrokes and writing out to the screen. General screen repaints (ctrl-L) are fine; as are individual keystrokes. But pasting into the editor causes the ssh freeze-up. As I mentioned, there is no way to get out of it; killing the editor or the shell don't work; the processes stick around waiting for sshd to let them go or something. I have to kill the sshd process. Contrary to earlier test results, I am unable to reproduce the problem outside of pico. Pasting the same text into an echo "..." command in the shell multiple times yielded no problems. Tail end of the kdump follows. Note that it does not RET from the write() at the end: 407 sshd CALL select(0x6,0xbfbff39c,0xbfbff31c,0,0) 407 sshd RET select 1 407 sshd CALL read(0x4,0xbfbfb2dc,0x4000) 407 sshd GIO fd 4 read 156 bytes "\0\0\0>?\M^X??A?8\M^Wl\M^_?????\aM???4?1?>?\M^M?4\^C??\M^@w?\M^I?Q\^\?\ ?o\M^H\M^YY?A?{=l,e???\fb{?|\M^F\^T???u\M^_\M^S????V" 407 sshd RET read 156/0x9c 407 sshd CALL select(0x6,0xbfbff39c,0xbfbff31c,0,0) 407 sshd RET select 1 407 sshd CALL read(0x5,0xbfbfb2dc,0x4000) 407 sshd GIO fd 5 read 8 bytes "\^[[19;64H" 407 sshd RET read 8 407 sshd CALL select(0x6,0xbfbff39c,0xbfbff31c,0,0xbfbff2d4) 407 sshd RET select 1 407 sshd CALL write(0x3,0x8082000,0x6ea) Don't know if this is helpful or not. From mouring at etoh.eviladmin.org Tue Dec 26 18:45:16 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 26 Dec 2000 01:45:16 -0600 (CST) Subject: openssh 2.2, fbsd 4.2: incoming data hangs sshd on tty In-Reply-To: <20001226023020.13748.qmail@hyperreal.org> Message-ID: Can you verify this against the latest snapshot at: http://bass.directhit.com/openssh_snap/ 2.2.0 is very old release. Since we are on the verge (from the sounds of it from Markus) of 2.4.0 release. - Ben On Mon, 25 Dec 2000 mike at hyperreal.org wrote: > I wrote: > > sshd, specifically the forked sshd process that is attached to a terminal > > when a connection is made, tends to freeze when receiving data over the link. > > The only way out is to kill -9 this process. It is easily reproducible by > > pasting text into an editor. > > With the help of someone who advised me to run ktrace on the sshd process > that freezes, I have narrowed down the circumstances under which the problem > is reproducible, and I discovered that sshd does receive a little bit more > data from the paste than I get to see coming back from the editor. > > It seems to have to do with whatever the pico (yes, pico, old habits die > hard) editor is doing when it is receiving keystrokes and writing out to the > screen. General screen repaints (ctrl-L) are fine; as are individual > keystrokes. But pasting into the editor causes the ssh freeze-up. As I > mentioned, there is no way to get out of it; killing the editor or the shell > don't work; the processes stick around waiting for sshd to let them go or > something. I have to kill the sshd process. > > Contrary to earlier test results, I am unable to reproduce the problem > outside of pico. Pasting the same text into an echo "..." command in the > shell multiple times yielded no problems. > > Tail end of the kdump follows. Note that it does not RET from the write() at > the end: > > 407 sshd CALL select(0x6,0xbfbff39c,0xbfbff31c,0,0) > 407 sshd RET select 1 > 407 sshd CALL read(0x4,0xbfbfb2dc,0x4000) > 407 sshd GIO fd 4 read 156 bytes > "\0\0\0>?\M^X??A?8\M^Wl\M^_ ?\M^Am<\^P\M^Y?o??oB\M^U?\^N?Ed\^W?\^O?F0?p\0\0\0 > |??x?\M^]????E??<-]\0\0\0>?????\aM???4?1?>?\M^M?4\^C??\M^@w?\M^I?Q\^\?\ > ?o\M^H\M^YY?A?{=l,e???\fb{?|\M^F\^T???u\M^_\M^S????V" > 407 sshd RET read 156/0x9c > 407 sshd CALL select(0x6,0xbfbff39c,0xbfbff31c,0,0) > 407 sshd RET select 1 > 407 sshd CALL read(0x5,0xbfbfb2dc,0x4000) > 407 sshd GIO fd 5 read 8 bytes > "\^[[19;64H" > 407 sshd RET read 8 > 407 sshd CALL select(0x6,0xbfbff39c,0xbfbff31c,0,0xbfbff2d4) > 407 sshd RET select 1 > 407 sshd CALL write(0x3,0x8082000,0x6ea) > > Don't know if this is helpful or not. > From markus.friedl at informatik.uni-erlangen.de Tue Dec 26 21:14:19 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Tue, 26 Dec 2000 11:14:19 +0100 Subject: ssh-agent and protocol 2 ... In-Reply-To: <20001225203136.L9279@gblx.net>; from primus@gblx.net on Mon, Dec 25, 2000 at 08:31:36PM +0000 References: <20001225203136.L9279@gblx.net> Message-ID: <20001226111419.A24852@folly> openssh-2.2 allows you to use the agent from the host where the agent is running. openssh-2.3 does support agent forwarding, too. -markus On Mon, Dec 25, 2000 at 08:31:36PM +0000, primus wrote: > Mon Dec 25 20:19:05 GMT 2000 > > Greetings. > > I noticed that in OpenSSH_2.2.0, DSA keys were > allowed to be added to ssh-agent, however the > ability for allowing ForwardAgent does not yet > seem in place for protocol-2. > > I've noticed that when using protocol-2, no socket > is created in /tmp/ssh-*/, and consequently > SSH_AUTH_SOCK is not being set. Hence the ability > to ssh to another machine (using protocol-1 or > protocol-2) without being asked for a password is > lost. > > Is this something currently under development, or > is it just a completely bad idea? If the latter, > what are the technical reasons? > > > Cheers. > > -- > primus From primus at gblx.net Wed Dec 27 02:41:41 2000 From: primus at gblx.net (Primus) Date: Tue, 26 Dec 2000 15:41:41 +0000 Subject: ssh-agent and protocol 2 ... In-Reply-To: <20001226111419.A24852@folly>; from markus.friedl@informatik.uni-erlangen.de on Tue, Dec 26, 2000 at 11:14:19AM +0100 References: <20001225203136.L9279@gblx.net> <20001226111419.A24852@folly> Message-ID: <20001226154141.M9279@gblx.net> Tue Dec 26 13:27:33 GMT 2000 I posted the email only after searching the ssh archives and not the 'dev' archives. I am using OpenSSH-2.3.0 synopsis of problem: 3 machines: A,B,C A: home machine where private and public RSA and DSA keys have been generated. B,C: only have authorized_keys and authorized_keys2 in ~/.ssh containing public RSA and DSA keys respecitvely. server: OpenSSH-2.2.0p1 B: in ~/.ssh/config, Host entry for C created setting ForwardAgent yes ACLs do not permit direct access to C from A. ssh-agent and ssh-add used on A. using Protocol 1, I can ssh to B and subsequently ssh from B to C and not have to enter a password or pass phrase on either. using Protocol 2, I can ssh to B as before, but regardless of which Protocol I set in B:~/.ssh/config for Host C, I am asked for a password when connecting to C from B. I found the following in the openssh-unix-dev archives: does it still apply? List: openssh-unix-dev Subject: Re: ssh2 authentication and ip forwarding From: Markus Friedl Date: 2000-10-16 21:42:00 [Download message RAW] agent forwarding is not in ssh2 since we don't do the officical agent protocol (there is no spec) and since we would have to do our own proprietary protocol for this. but if someone sends 'clean' patches, we can add this to openssh, of course. Thanks. -primus On Tue, Dec 26, 2000 at 11:14:19AM +0100, Markus Friedl wrote: | openssh-2.2 allows you to use the agent from | the host where the agent is running. | | openssh-2.3 does support agent forwarding, too. | | -markus | | On Mon, Dec 25, 2000 at 08:31:36PM +0000, primus wrote: | > Mon Dec 25 20:19:05 GMT 2000 | > | > Greetings. | > | > I noticed that in OpenSSH_2.2.0, DSA keys were | > allowed to be added to ssh-agent, however the | > ability for allowing ForwardAgent does not yet | > seem in place for protocol-2. | > | > I've noticed that when using protocol-2, no socket | > is created in /tmp/ssh-*/, and consequently | > SSH_AUTH_SOCK is not being set. Hence the ability | > to ssh to another machine (using protocol-1 or | > protocol-2) without being asked for a password is | > lost. | > | > Is this something currently under development, or | > is it just a completely bad idea? If the latter, | > what are the technical reasons? | > | > | > Cheers. | > | > -- | > primus From tim at multitalents.net Wed Dec 27 05:39:20 2000 From: tim at multitalents.net (Tim Rice) Date: Tue, 26 Dec 2000 10:39:20 -0800 (PST) Subject: =?ISO-8859-1?Q?R=E9f=2E?= : configure.in: Someone please show me a better way :) In-Reply-To: <3A41FEC6.1020008@skalasoft.com> Message-ID: Works with both sh and ksh on Solaris 7 UnixWare 2.03 SCO 3.2v4.2 UnixWare 2.1.3 SCO 5.0.4 UnixWare 7.1.0 (allready reported) AIX 4.3.2.0 On Thu, 21 Dec 2000, Roumen Petrov wrote: > Sorry for mistake for sh file must begin with > ------------------------------- > X0='x0' > X1a="$X0/1" > X1b='$X0/1' > X2a="$X1a/2" > X2b='$X1b/2' > > export X0 > export X1a > export X1b > export X2a > export X2b > ------------------------------ [snip] > > $SHELL < > $SHELL < > cat < > #define a "$X2a/aa" > > #define b "$X2b/bb" > > EOF > > EOF_1 > > EOF_2 > > ---------------------------------------- > > Output must be: > > #define a "x0/1/2/aa" > > #define b "x0/1/2/bb" > > > > With bash and bash in sh mode on linux work. > > What about other ..UX implementation ? > > > > Genarated from autoconf variable in configure script like > > libexecdir='${exec_prefix}/libexec' > > is not expanded in script and substitution > > s%@libexecdir@%$libexecdir%g > > is usefull only for makefiles. > > > > if script work file we can use ( about configure.in ) > > ---------------------------------------- > > ..... > > export prefix > > export exec_prefix > > export bindir > > > > $SHELL < > $SHELL < > cat < > OpenSSH configured has been configured with the following options. > > User binaries: ${bindir} > > EOF > > EOF_1 > > EOF_2 > > ..... > > ---------------------------------------- > > > > Is this idea better that: > > E=`eval echo ${libexecdir}/ssh-askpass` ; E=`eval echo ${E}` > > ..... > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mike at hyperreal.org Wed Dec 27 06:44:42 2000 From: mike at hyperreal.org (mike at hyperreal.org) Date: Tue, 26 Dec 2000 11:44:42 -0800 (PST) Subject: openssh 2.2, fbsd 4.2: incoming data hangs sshd on tty In-Reply-To: <20001226023020.13748.qmail@hyperreal.org> from "mike@hyperreal.org" at "Dec 25, 2000 06:30:20 pm" Message-ID: <20001226194442.13277.qmail@hyperreal.org> I wrote: > Contrary to earlier test results, I am unable to reproduce the problem > outside of pico. Pasting the same text into an echo "..." command in the > shell multiple times yielded no problems. *sigh* Again I must amend this report. I just got a classic lock-up outside of pico, when elm 2.4ME+ PL84 (like I said, old habits..) was displaying a list of messages in a mailbox. So the sshd problem is not just restricted to certain text editors. - Mike ________________________________________________________________________ Mike Brown / Hyperreal | Hyperreal http://music.hyperreal.org/ PO Box 61334 | XML & XSL http://skew.org/xml/ Denver CO 80206-8334 USA | personal http://www.hyperreal.org/~mike/ From mike at hyperreal.org Wed Dec 27 07:35:48 2000 From: mike at hyperreal.org (mike at hyperreal.org) Date: Tue, 26 Dec 2000 12:35:48 -0800 (PST) Subject: openssh 2.2, fbsd 4.2: incoming data hangs sshd on tty In-Reply-To: from "mouring@etoh.eviladmin.org" at "Dec 26, 2000 01:45:16 am" Message-ID: <20001226203548.21082.qmail@hyperreal.org> Well with an out-of-the-box compile I get this upon attempted startup of sshd: Dec 26 13:20:20 chillout sshd[330]: no modules loaded for `sshd' service Dec 26 13:20:20 chillout sshd[330]: fatal: PAM session setup failed[6]: Permission denied Dec 26 13:20:20 chillout sshd[330]: no modules loaded for `sshd' service If I reconfigure with --without-pam, I get this during compilation: gcc -o sshd sshd.o auth.o auth1.o auth2.o auth-skey.o auth2-skey.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth2-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o dh.o pty.o log-server.o login.o loginrec.o servconf.o serverloop.o md5crypt.o session.o -L. -lssh -lopenbsd-compat -lz -lutil -lcrypto auth-passwd.o: In function `auth_password': /usr/local/src/openssh/auth-passwd.c(.text+0x5a): undefined reference to `crypt' mouring at etoh.eviladmin.org wrote: > > Can you verify this against the latest snapshot at: > http://bass.directhit.com/openssh_snap/ > > 2.2.0 is very old release. Since we are on the verge (from the sounds of > it from Markus) of 2.4.0 release. > > - Ben > > On Mon, 25 Dec 2000 mike at hyperreal.org wrote: > > > I wrote: > > > sshd, specifically the forked sshd process that is attached to a terminal > > > when a connection is made, tends to freeze when receiving data over the link. > > > The only way out is to kill -9 this process. It is easily reproducible by > > > pasting text into an editor. > > > > With the help of someone who advised me to run ktrace on the sshd process > > that freezes, I have narrowed down the circumstances under which the problem > > is reproducible, and I discovered that sshd does receive a little bit more > > data from the paste than I get to see coming back from the editor. > > > > It seems to have to do with whatever the pico (yes, pico, old habits die > > hard) editor is doing when it is receiving keystrokes and writing out to the > > screen. General screen repaints (ctrl-L) are fine; as are individual > > keystrokes. But pasting into the editor causes the ssh freeze-up. As I > > mentioned, there is no way to get out of it; killing the editor or the shell > > don't work; the processes stick around waiting for sshd to let them go or > > something. I have to kill the sshd process. > > > > Contrary to earlier test results, I am unable to reproduce the problem > > outside of pico. Pasting the same text into an echo "..." command in the > > shell multiple times yielded no problems. > > > > Tail end of the kdump follows. Note that it does not RET from the write() at > > the end: > > > > 407 sshd CALL select(0x6,0xbfbff39c,0xbfbff31c,0,0) > > 407 sshd RET select 1 > > 407 sshd CALL read(0x4,0xbfbfb2dc,0x4000) > > 407 sshd GIO fd 4 read 156 bytes > > "\0\0\0>_\M^X__A_8\M^Wl\M^_ > _\M^Am<\^P\M^Y_o__oB\M^U_\^N_Ed\^W_\^O_F0_p\0\0\0 > > |__x_\M^]____E__<-]\0\0\0>_____\aM_?_4_1_>_\M^M_4\^C__\M^@w_\M^I_Q\^\_\ > > _o\M^H\M^YY_A_{=l,e___\fb{_|\M^F\^T___u\M^_\M^S__?_V" > > 407 sshd RET read 156/0x9c > > 407 sshd CALL select(0x6,0xbfbff39c,0xbfbff31c,0,0) > > 407 sshd RET select 1 > > 407 sshd CALL read(0x5,0xbfbfb2dc,0x4000) > > 407 sshd GIO fd 5 read 8 bytes > > "\^[[19;64H" > > 407 sshd RET read 8 > > 407 sshd CALL select(0x6,0xbfbff39c,0xbfbff31c,0,0xbfbff2d4) > > 407 sshd RET select 1 > > 407 sshd CALL write(0x3,0x8082000,0x6ea) > > > > Don't know if this is helpful or not. > > > > From djm at mindrot.org Wed Dec 27 09:36:41 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 27 Dec 2000 09:36:41 +1100 (EST) Subject: minor bugs in openssh-2.3.0p1 (fwd) Message-ID: -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org ---------- Forwarded message ---------- Date: Tue, 26 Dec 2000 09:12:48 -0800 From: Takumi Yamane Reply-To: yamtak at b-session.com To: openssh at openssh.com Cc: yamtak at b-session.com Subject: minor bugs in openssh-2.3.0p1 Hi, I found that there are minor bugs in openssh-2.3.0p1. There are some function checking for 'entutx?ent' in configure, but its typo, it must be 'endutx?ent'. Thus endutx?ent() was never called. configure.in:line 296 entutent -> endutent configure.in:line 299 entutxent -> endutxent configure:line 2263 entutent -> endutent configure:line 2373 entutxent -> endutxent config.h.in:line 311 entutent -> endutent config.h.in:line 312 HAVE_ENTUTENT -> HAVE_ENDUTENT config.h.in:line 314 entutxent -> endutxent config.h.in:line 315 HAVE_ENTUTXENT -> HAVE_ENDUTXENT Regards. Takumi Yamane From mouring at etoh.eviladmin.org Wed Dec 27 13:27:34 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 26 Dec 2000 20:27:34 -0600 (CST) Subject: openssh 2.2, fbsd 4.2: incoming data hangs sshd on tty In-Reply-To: <20001226203548.21082.qmail@hyperreal.org> Message-ID: I assumed you put in the contrib/sshd.pam.freebsd file in the correct /etc location (Under most Linux's it's /etc/pam.d/). Otherwise you would see that type of errors. On Tue, 26 Dec 2000 mike at hyperreal.org wrote: > Well with an out-of-the-box compile I get this upon attempted startup of sshd: > > Dec 26 13:20:20 chillout sshd[330]: no modules loaded for `sshd' service > Dec 26 13:20:20 chillout sshd[330]: fatal: PAM session setup failed[6]: Permission denied > Dec 26 13:20:20 chillout sshd[330]: no modules loaded for `sshd' service > > If I reconfigure with --without-pam, I get this during compilation: > > gcc -o sshd sshd.o auth.o auth1.o auth2.o auth-skey.o auth2-skey.o > auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth2-pam.o auth-passwd.o > auth-rsa.o auth-rh-rsa.o dh.o pty.o log-server.o login.o loginrec.o > servconf.o serverloop.o md5crypt.o session.o -L. -lssh -lopenbsd-compat -lz > -lutil -lcrypto > auth-passwd.o: In function `auth_password': > /usr/local/src/openssh/auth-passwd.c(.text+0x5a): undefined reference to `crypt' > > mouring at etoh.eviladmin.org wrote: > > > > Can you verify this against the latest snapshot at: > > http://bass.directhit.com/openssh_snap/ > > > > 2.2.0 is very old release. Since we are on the verge (from the sounds of > > it from Markus) of 2.4.0 release. > > > > - Ben > > > > On Mon, 25 Dec 2000 mike at hyperreal.org wrote: > > > > > I wrote: > > > > sshd, specifically the forked sshd process that is attached to a terminal > > > > when a connection is made, tends to freeze when receiving data over the link. > > > > The only way out is to kill -9 this process. It is easily reproducible by > > > > pasting text into an editor. > > > > > > With the help of someone who advised me to run ktrace on the sshd process > > > that freezes, I have narrowed down the circumstances under which the problem > > > is reproducible, and I discovered that sshd does receive a little bit more > > > data from the paste than I get to see coming back from the editor. > > > > > > It seems to have to do with whatever the pico (yes, pico, old habits die > > > hard) editor is doing when it is receiving keystrokes and writing out to the > > > screen. General screen repaints (ctrl-L) are fine; as are individual > > > keystrokes. But pasting into the editor causes the ssh freeze-up. As I > > > mentioned, there is no way to get out of it; killing the editor or the shell > > > don't work; the processes stick around waiting for sshd to let them go or > > > something. I have to kill the sshd process. > > > > > > Contrary to earlier test results, I am unable to reproduce the problem > > > outside of pico. Pasting the same text into an echo "..." command in the > > > shell multiple times yielded no problems. > > > > > > Tail end of the kdump follows. Note that it does not RET from the write() at > > > the end: > > > > > > 407 sshd CALL select(0x6,0xbfbff39c,0xbfbff31c,0,0) > > > 407 sshd RET select 1 > > > 407 sshd CALL read(0x4,0xbfbfb2dc,0x4000) > > > 407 sshd GIO fd 4 read 156 bytes > > > "\0\0\0>_\M^X__A_8\M^Wl\M^_ > > _\M^Am<\^P\M^Y_o__oB\M^U_\^N_Ed\^W_\^O_F0_p\0\0\0 > > > |__x_\M^]____E__<-]\0\0\0>_____\aM_?_4_1_>_\M^M_4\^C__\M^@w_\M^I_Q\^\_\ > > > _o\M^H\M^YY_A_{=l,e___\fb{_|\M^F\^T___u\M^_\M^S__?_V" > > > 407 sshd RET read 156/0x9c > > > 407 sshd CALL select(0x6,0xbfbff39c,0xbfbff31c,0,0) > > > 407 sshd RET select 1 > > > 407 sshd CALL read(0x5,0xbfbfb2dc,0x4000) > > > 407 sshd GIO fd 5 read 8 bytes > > > "\^[[19;64H" > > > 407 sshd RET read 8 > > > 407 sshd CALL select(0x6,0xbfbff39c,0xbfbff31c,0,0xbfbff2d4) > > > 407 sshd RET select 1 > > > 407 sshd CALL write(0x3,0x8082000,0x6ea) > > > > > > Don't know if this is helpful or not. > > > > > > > > > From djm at mindrot.org Wed Dec 27 13:28:04 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 27 Dec 2000 13:28:04 +1100 (EST) Subject: PAM configuration Message-ID: To stem the tide of support requests from people who don't read the INSTALL file when installing OpenSSH and then complain about password auth failing. I am considering the idea of automagically installing a PAM file into /etc/pam.d if it exists, PAM support is enabled and no such file already exists. I have a couple of questions: - How is PAM controlled on Solaris? Is there a pam.d directory or does it just use pam.conf? Do we need to install a control file for OpenSSH? - Does FreeBSD and other systems where PAM is a port or addon still use /etc/pam.d? - Some PAM control files specifiy full paths to the modules, is this necessary? - I want a "no-frills" control file which will work with the widest range of systems and still be secure. Would something like the following work everywhere? I assume pam_unix is pretty standards, but how about pam_cracklib, pam_nologin and pam_limits? I don't really want to ship without pam_cracklib in for password changes (since that is what most sites use as default). Can password changing be disabled using pam_deny? #%PAM-1.0 auth required pam_unix.so shadow nodelay auth required pam_nologin.so account required pam_unix.so password required pam_cracklib.so password required pam_unix.so shadow md5 nullok use_authtok session required pam_unix.so session required pam_limits.so -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From mouring at etoh.eviladmin.org Wed Dec 27 17:08:03 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 27 Dec 2000 00:08:03 -0600 (CST) Subject: OpenSSH 2.4.0 patch call.. Message-ID: I spoke with Markus before Christmas (I hope all your holidays were better then mine.. But that's another topic. Car are evil.=) and he would like to release 2.4.0 in the very near future. Is there any undisputed patches still out not applied to the current portable CVS tree? (BTW, I just applied the getrlimit patch from Corinna.) - Ben From tim at multitalents.net Wed Dec 27 16:25:22 2000 From: tim at multitalents.net (Tim Rice) Date: Tue, 26 Dec 2000 21:25:22 -0800 (PST) Subject: Anonymous CVS, Snapshot mirrors available In-Reply-To: Message-ID: On Thu, 14 Dec 2000, Damien Miller wrote: > On Wed, 13 Dec 2000, Gert Doering wrote: > > ... ah! Found it: config.h.in depends on running running "autoheader". > > > > Hmm. > > > > Is there a way to automate running "autoconf" and "autoheader"? Any > > makefile tricks that I do not know yet? > > make -f Makefile.in distprep tim(trr)@uw213 44% gmake -f Makefile.in distprep UX:sh (/bin/sh): ERROR: Bad substitution gmake: *** [catman-do] Error 1 Do I detect some bash dependencies? > > -d > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From djm at mindrot.org Wed Dec 27 16:44:54 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 27 Dec 2000 16:44:54 +1100 (EST) Subject: Anonymous CVS, Snapshot mirrors available In-Reply-To: Message-ID: On Tue, 26 Dec 2000, Tim Rice wrote: > On Thu, 14 Dec 2000, Damien Miller wrote: > > > On Wed, 13 Dec 2000, Gert Doering wrote: > > > ... ah! Found it: config.h.in depends on running running "autoheader". > > > > > > Hmm. > > > > > > Is there a way to automate running "autoconf" and "autoheader"? Any > > > makefile tricks that I do not know yet? > > > > make -f Makefile.in distprep > > tim(trr)@uw213 44% gmake -f Makefile.in distprep > UX:sh (/bin/sh): ERROR: Bad substitution > gmake: *** [catman-do] Error 1 > > Do I detect some bash dependencies? Yep :) The 'catman-do' target uses some bashisms. I will commit this in a moment: Index: Makefile.in =================================================================== RCS file: /var/cvs/openssh/Makefile.in,v retrieving revision 1.126 diff -u -r1.126 Makefile.in --- Makefile.in 2000/12/22 20:27:44 1.126 +++ Makefile.in 2000/12/27 05:43:35 @@ -127,9 +127,10 @@ catman-do: @for f in $(TROFFMAN) ; do \ - echo "$$f -> $${f%%.[18]}.0" ; \ + base=`echo $$f | sed 's/\..*$$//'` ; \ + echo "$$f -> $$base.0" ; \ nroff -mandoc $$f | cat -v | sed -e 's/.\^H//g' \ - >$${f%%.[18]}.0 ; \ + >$$base.0 ; \ done distprep: catman-do -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From chenda at cs.unc.edu Wed Dec 27 16:55:10 2000 From: chenda at cs.unc.edu (Daniel T. Chen) Date: Wed, 27 Dec 2000 00:55:10 -0500 (EST) Subject: PAM configuration In-Reply-To: Message-ID: On Wed, 27 Dec 2000, Damien Miller wrote: > To stem the tide of support requests from people who don't read the > INSTALL file when installing OpenSSH and then complain about password > auth failing. I am considering the idea of automagically installing a > PAM file into /etc/pam.d if it exists, PAM support is enabled and no > such file already exists. I think this is a great idea. I'm attaching an /etc/pam.d/sshd that works on my SuSE 6.[3,4] and 7.0 machines. > - Some PAM control files specifiy full paths to the modules, is this > necessary? According to the Linux-PAM system administrators' guide, this is necessary (check around line 185 of PAM(8) ). I can't really speak for other operating systems. > - I want a "no-frills" control file which will work with the widest > range of systems and still be secure. Would something like the following > work everywhere? I assume pam_unix is pretty standards, but how about > pam_cracklib, pam_nologin and pam_limits? SuSE 6.[3,4] and 7.0 use "specializations" of pam_unix.so (probably hard links to one particular pam_unix_[acct,auth,passwd,session], but otherwise pam_cracklib, pam_nologin, and pam_limits are as defined. See my attached /etc/pam.d/sshd. > [...] Thx, dtc -------------- next part -------------- #%PAM-1.0 auth required /lib/security/pam_unix_auth.so shadow nodelay auth required /lib/security/pam_nologin.so account required /lib/security/pam_unix_acct.so password required /lib/security/pam_cracklib.so password required /lib/security/pam_unix_passwd.so shadow md5 use_authtok session required /lib/security/pam_unix_session.so session required /lib/security/pam_limits.so From pekkas at netcore.fi Wed Dec 27 17:45:59 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 27 Dec 2000 08:45:59 +0200 (EET) Subject: PAM configuration In-Reply-To: Message-ID: On Wed, 27 Dec 2000, Damien Miller wrote: > To stem the tide of support requests from people who don't read the > INSTALL file when installing OpenSSH and then complain about password > auth failing. I am considering the idea of automagically installing a > PAM file into /etc/pam.d if it exists, PAM support is enabled and no > such file already exists. > > I have a couple of questions: > > - How is PAM controlled on Solaris? Is there a pam.d directory or does > it just use pam.conf? Do we need to install a control file for OpenSSH? > > - Does FreeBSD and other systems where PAM is a port or addon still > use /etc/pam.d? FreeBSD (as of 4.2) uses only /etc/pam.conf. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From pekkas at netcore.fi Wed Dec 27 17:50:02 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 27 Dec 2000 08:50:02 +0200 (EET) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: Message-ID: On Wed, 27 Dec 2000 mouring at etoh.eviladmin.org wrote: > Is there any undisputed patches still out not applied to the current > portable CVS tree? (BTW, I just applied the getrlimit patch from > Corinna.) It's not 'undisputed', but the hanging connection endings with background processes problem is still there, right? :-( -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From mouring at etoh.eviladmin.org Wed Dec 27 18:51:33 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 27 Dec 2000 01:51:33 -0600 (CST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: Message-ID: On Wed, 27 Dec 2000, Pekka Savola wrote: > On Wed, 27 Dec 2000 mouring at etoh.eviladmin.org wrote: > > Is there any undisputed patches still out not applied to the current > > portable CVS tree? (BTW, I just applied the getrlimit patch from > > Corinna.) > > It's not 'undisputed', but the hanging connection endings with > background processes problem is still there, right? :-( > I've yet to see a patch that kills the issue.=) But yet it's still an issue. - Ben From djm at mindrot.org Wed Dec 27 19:08:59 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 27 Dec 2000 19:08:59 +1100 (EST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: Message-ID: On Wed, 27 Dec 2000 mouring at etoh.eviladmin.org wrote: > I've yet to see a patch that kills the issue.=) But yet it's still an > issue. Is it a problem for any platform other than Linux? stracing it on Linux shows we block in a read on an FD which is explicitly set as non-blocking. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From djm at mindrot.org Wed Dec 27 19:10:17 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 27 Dec 2000 19:10:17 +1100 (EST) Subject: PAM configuration In-Reply-To: Message-ID: On Wed, 27 Dec 2000, Pekka Savola wrote: > > - Does FreeBSD and other systems where PAM is a port or addon still > > use /etc/pam.d? > > FreeBSD (as of 4.2) uses only /etc/pam.conf. Does it include usable defaults (i.e. ones that will allow password auth to proceed) when no explicit configuration is found? -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From yozo at ipc.chiba-u.ac.jp Wed Dec 27 21:20:24 2000 From: yozo at ipc.chiba-u.ac.jp (Yozo TODA) Date: Wed, 27 Dec 2000 19:20:24 +0900 Subject: PAM configuration In-Reply-To: Your message of "Wed, 27 Dec 2000 08:45:59 JST." Message-ID: <200012271020.eBRAKOr28120@aohakobe.ipc.chiba-u.ac.jp> > > - How is PAM controlled on Solaris? Is there a pam.d directory or does > > it just use pam.conf? Do we need to install a control file for OpenSSH? Solaris8 uses /etc/pam.conf, /etc/pam.d/ doesn't exist. I don't know defaults('other' entries) are usable or not... ezotsutsuji% cat /etc/pam.conf-solaris8 # #ident "@(#)pam.conf 1.14 99/09/16 SMI" # # Copyright (c) 1996-1999, Sun Microsystems, Inc. # All Rights Reserved. # # PAM configuration # # Authentication management # login auth required /usr/lib/security/$ISA/pam_unix.so.1 login auth required /usr/lib/security/$ISA/pam_dial_auth.so.1 # rlogin auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1 rlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 # dtlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 # rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1 other auth required /usr/lib/security/$ISA/pam_unix.so.1 # # Account management # login account requisite /usr/lib/security/$ISA/pam_roles.so.1 login account required /usr/lib/security/$ISA/pam_unix.so.1 # dtlogin account requisite /usr/lib/security/$ISA/pam_roles.so.1 dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1 # other account requisite /usr/lib/security/$ISA/pam_roles.so.1 other account required /usr/lib/security/$ISA/pam_unix.so.1 # # Session management # other session required /usr/lib/security/$ISA/pam_unix.so.1 # # Password management # other password required /usr/lib/security/$ISA/pam_unix.so.1 dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1 # # Support for Kerberos V5 authentication (uncomment to use Kerberos) # #rlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass #login auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass #dtlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass #other auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass #dtlogin account optional /usr/lib/security/$ISA/pam_krb5.so.1 #other account optional /usr/lib/security/$ISA/pam_krb5.so.1 #other session optional /usr/lib/security/$ISA/pam_krb5.so.1 #other password optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass ezotsutsuji% -- yozo. From vinschen at redhat.com Wed Dec 27 21:41:17 2000 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 27 Dec 2000 11:41:17 +0100 Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: ; from djm@mindrot.org on Wed, Dec 27, 2000 at 07:08:59PM +1100 References: Message-ID: <20001227114117.B11368@cygbert.vinschen.de> On Wed, Dec 27, 2000 at 07:08:59PM +1100, Damien Miller wrote: > On Wed, 27 Dec 2000 mouring at etoh.eviladmin.org wrote: > > > I've yet to see a patch that kills the issue.=) But yet it's still an > > issue. > > Is it a problem for any platform other than Linux? You probably don't want to hear this but it's an issue as well on *gulp* Win 95/98/ME. It's no problem on NT/2000. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From pekkas at netcore.fi Wed Dec 27 22:02:19 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 27 Dec 2000 13:02:19 +0200 (EET) Subject: PAM configuration In-Reply-To: Message-ID: On Wed, 27 Dec 2000, Damien Miller wrote: > On Wed, 27 Dec 2000, Pekka Savola wrote: > > > > - Does FreeBSD and other systems where PAM is a port or addon still > > > use /etc/pam.d? > > > > FreeBSD (as of 4.2) uses only /etc/pam.conf. > > Does it include usable defaults (i.e. ones that will allow password > auth to proceed) when no explicit configuration is found? [pam-list snipped] Nope. Nothing relating to 'sshd', so incoming connections fail: --- Dec 27 12:42:48 gap sshd[16503]: no modules loaded for `sshd' service Dec 27 12:42:56 gap sshd[16504]: no modules loaded for `sshd' service Dec 27 12:42:56 gap sshd[16504]: fatal: PAM session setup failed[6]: Permission denied --- FreeBSD OpenSSH is based on OpenBSD version directly, IIRC. On Dec 5, OpenSSH 2.3.0 with PAM support was merged in FreeBSD-5.0 CVS tree, see e.g.: http://www.FreeBSD.org/cgi/cvsweb.cgi/src/crypto/openssh/sshd.c It still requires modifications for pam.conf, though. Btw, Also I noticed there is a 'ConnectionsPerPeriod' option for sshd which allows ratelimiting (conns/sec) for incoming connections. I don't think this has been upstreamed. The man page gives the following info: --- ConnectionsPerPeriod This keyword allows for rate-limiting of connections, and is fol- lowed by two numbers in the format ``n/s'', where n is the number of connections from a certain address group accepted per period of s seconds. Any connection after the number n connection in the period of s seconds will be dropped, and an informational message will be logged. A connection will belong to a certain group, of which there are 13 by default, according to its IP ad- dress. The default for this keyword is ``0/0'', and rate-limit- ing can be explicitly turned off by using an n parameter of `0' and any s parameter. --- These were inherited a long time ago from /usr/ports/security/openssh/files/patch-a{o,p,r}, it seems. I can send these over if there's interest. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From pekkas at netcore.fi Wed Dec 27 22:24:23 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 27 Dec 2000 13:24:23 +0200 (EET) Subject: implicit declaration warnings Message-ID: Hi, When I tested the latest snapshot on FreeBSD 4.2, I noticed some implicit declaration warnings I didn't recall seeing on Linux. I think this is caused by the fact that if autoconf does detect the presence of some BSD capability, necessary header files and declarations may not be included (as these are assumed to be the same ~everywhere, and already included). If such capability is missing, everything will seem to be fine. E.g.: --- uuencode.c: In function `uuencode': uuencode.c:36: warning: implicit declaration of function `__b64_ntop' uuencode.c: In function `uudecode': uuencode.c:54: warning: implicit declaration of function `__b64_pton' auth-rhosts.c: In function `check_rhosts_file': auth-rhosts.c:110: warning: implicit declaration of function `innetgr' loginrec.c: In function `syslogin_perform_login': loginrec.c:1282: warning: implicit declaration of function `login' loginrec.c: In function `syslogin_perform_logout': loginrec.c:1295: warning: implicit declaration of function `logout' loginrec.c:1299: warning: implicit declaration of function `logwtmp' --- In config.h, there are: #define HAVE___B64_NTOP 1 #define HAVE_LIBUTIL_LOGIN 1 #define HAVE_INNETGR 1 Attached patch removes the warnings about login functions BUT will break on systems that define LIBUTIL_LOGIN but don't have libutil.h (e.g. Linux). So, it's not the way to go. But some sort of "nice" way of handling the necessary includes should probably be used? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------- next part -------------- --- loginrec.c.orig Fri Dec 1 23:19:51 2000 +++ loginrec.c Wed Dec 27 13:06:12 2000 @@ -167,6 +167,10 @@ # include #endif +#ifdef HAVE_LIBUTIL_LOGIN +# include +#endif + /** ** prototypes for helper functions in this file **/ From yamtak at ix.netcom.com Wed Dec 27 04:12:48 2000 From: yamtak at ix.netcom.com (Takumi Yamane) Date: Tue, 26 Dec 2000 09:12:48 -0800 Subject: minor bugs in openssh-2.3.0p1 Message-ID: <200012261712.JAA32645@nix.home.world4me.com> Hi, I found that there are minor bugs in openssh-2.3.0p1. There are some function checking for 'entutx?ent' in configure, but its typo, it must be 'endutx?ent'. Thus endutx?ent() was never called. configure.in:line 296 entutent -> endutent configure.in:line 299 entutxent -> endutxent configure:line 2263 entutent -> endutent configure:line 2373 entutxent -> endutxent config.h.in:line 311 entutent -> endutent config.h.in:line 312 HAVE_ENTUTENT -> HAVE_ENDUTENT config.h.in:line 314 entutxent -> endutxent config.h.in:line 315 HAVE_ENTUTXENT -> HAVE_ENDUTXENT Regards. Takumi Yamane From openssh-unix-dev at progressive-comp.com Wed Dec 27 23:02:37 2000 From: openssh-unix-dev at progressive-comp.com (Hank Leininger) Date: Wed, 27 Dec 2000 07:02:37 -0500 Subject: 'debug1: tvp!=NULL kid 0 mili 10' messages Message-ID: <200012271202.HAA28019@mailer.progressive-comp.com> Since 2.4 is approaching, I'll raise a question that's been bugging me... I prefer to run all my sshd's with LogLevel DEBUG. I'm just a paranoid control freak ;) Anyway, for as long as I can remember openssh's sshd spits out 'tvp!=NULL kid 0 mili 10' (or very minor variations) continuously when LogLevel DEBUG is used. Looking at serverloop.c it looks like this prints (at least) every time sshd reads some data from STDERR of a process. It's been mentioned often on this list, but always tangentially, so I don't think anyone's ever focused attention on this. I've just been patching that out (completely, or suppressing the log entry unless child_terminated > 0). I'd like to request that someone who knows (and/or, wrote to begin with? :) this code (serverloop.c:258 in 2.3.0p1) take a look and see if it's really necessary. Otherwise it generates useless chatter between sshd and syslogd, causes unnecessary context switches, and of course scribbles useless stuff to disk. At the very least, could these be changed to debug2 or debug3 so that it's disabled for not-really-that-verbose DEBUG LogLevels? Thanks, Hank Leininger From markus.friedl at informatik.uni-erlangen.de Wed Dec 27 23:08:32 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 27 Dec 2000 13:08:32 +0100 Subject: ssh-agent and protocol 2 ... In-Reply-To: <20001226154141.M9279@gblx.net>; from primus@gblx.net on Tue, Dec 26, 2000 at 03:41:41PM +0000 References: <20001225203136.L9279@gblx.net> <20001226111419.A24852@folly> <20001226154141.M9279@gblx.net> Message-ID: <20001227130832.A31667@folly> As i wrote in my previous message: > openssh-2.2 allows you to use the agent from > the host where the agent is running. > > openssh-2.3 does support agent forwarding, too. this explains your problems. you have to upgrade the server to 2.3.x if you want to use agent-forwarding. On Tue, Dec 26, 2000 at 03:41:41PM +0000, Primus wrote: > Tue Dec 26 13:27:33 GMT 2000 > > I posted the email only after searching the ssh > archives and not the 'dev' archives. > > I am using OpenSSH-2.3.0 > > synopsis of problem: > > 3 machines: A,B,C > A: home machine where private and public RSA and DSA > keys have been generated. > > B,C: only have authorized_keys and authorized_keys2 in ~/.ssh > containing public RSA and DSA keys > respecitvely. > server: OpenSSH-2.2.0p1 > > B: in ~/.ssh/config, Host entry for C created setting > ForwardAgent yes > > ACLs do not permit direct access to C from A. > > ssh-agent and ssh-add used on A. > using Protocol 1, I can ssh to B and subsequently ssh from B to C > and not have to enter a password or pass phrase on either. > > using Protocol 2, I can ssh to B as before, but regardless of which > Protocol I set in B:~/.ssh/config for Host C, I am asked for a password > when connecting to C from B. > > > I found the following in the openssh-unix-dev > archives: does it still apply? > > List: openssh-unix-dev > Subject: Re: ssh2 authentication and ip forwarding > From: Markus Friedl > Date: 2000-10-16 21:42:00 > [Download message RAW] > > agent forwarding is not in ssh2 since we don't do the > officical agent protocol (there is no spec) and since > we would have to do our own proprietary protocol for this. > but if someone sends 'clean' patches, we can add this to > openssh, of course. > > Thanks. > > > -primus > > > > On Tue, Dec 26, 2000 at 11:14:19AM +0100, Markus Friedl wrote: > | openssh-2.2 allows you to use the agent from > | the host where the agent is running. > | > | openssh-2.3 does support agent forwarding, too. > | > | -markus > | > | On Mon, Dec 25, 2000 at 08:31:36PM +0000, primus wrote: > | > Mon Dec 25 20:19:05 GMT 2000 > | > > | > Greetings. > | > > | > I noticed that in OpenSSH_2.2.0, DSA keys were > | > allowed to be added to ssh-agent, however the > | > ability for allowing ForwardAgent does not yet > | > seem in place for protocol-2. > | > > | > I've noticed that when using protocol-2, no socket > | > is created in /tmp/ssh-*/, and consequently > | > SSH_AUTH_SOCK is not being set. Hence the ability > | > to ssh to another machine (using protocol-1 or > | > protocol-2) without being asked for a password is > | > lost. > | > > | > Is this something currently under development, or > | > is it just a completely bad idea? If the latter, > | > what are the technical reasons? > | > > | > > | > Cheers. > | > > | > -- > | > primus From jlandstr at astro.uwo.ca Wed Dec 27 11:15:53 2000 From: jlandstr at astro.uwo.ca (John Landstreet) Date: Tue, 26 Dec 2000 19:15:53 -0500 (EST) Subject: problem report about installation of OpenSSH Message-ID: Hello I apologise for sending this in in no particular format, but I do not have "sendbug" on my machine. I have just downloaded openssh-2.3.0p1 for installation on my Slackware 3.4 Linux OS (running on a Compaq Armada 1540DM laptop with a 150 MHz Pentium). As instructed, I also obtained and installed zlib-1.1.3 and openssl-0.9.6. Both unpacked, compiled, and installed without apparent problems, using gcc version 2.7.2.3 and GNU Make version 3.76.1. When I ran ./configure for OpenSSH, it did not appear to have any problem, and offered the following report: ________________________________________________________________________ OpenSSH configured has been configured with the following options. User binaries: /usr/local/bin 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 Random number collection: Device (/dev/urandom) Manpage format: man PAM support: no KerberosIV support: no AFS support: no S/KEY support: no TCP Wrappers support: no MD5 password support: no IP address in $DISPLAY hack: no Use IPv4 by default hack: no Translate v4 in v6 hack: yes Host: i586-pc-linux-gnu Compiler: gcc Compiler flags: -g -O2 -Wall -I. -I. -I/usr/local/ssl/include Linker flags: -L/usr/local/ssl/lib -L/usr/local/ssl Libraries: -lz -lbsd -lcrypto ______________________________________________________________________ However, when I try to compile with make, the make does not work, with the following message: _______________________________________________________________________ /usr/local/src/openssh-2.3.0p1>make gcc -g -O2 -Wall -I. -I. -I/usr/local/ssl/include -DETCDIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-base64.c -o bsd-base64.o gcc: Internal compiler error: program cc1 got fatal signal 6 make: *** [bsd-base64.o] Error 1 ______________________________________________________________________ I do not know what to try next. I have looked over the FAQ file for OpenSSH, as well as the README and the INSTALL files, and none of the comments seem to be relevant. I would be most grateful for any suggestions you could make about how to proceed from here. Thanks very much. Yours sincerely, John Landstreet Prof. John D. Landstreet Dept. of Physics & Astronomy, Univ. of Western Ontario (519) 661-2111 ext 86707 (me), 661-3183 (dept. office), 661-2033 (fax) WWW: http://phobos.astro.uwo.ca/~jlandstr From anubis at slackwarez.org Wed Dec 27 13:04:01 2000 From: anubis at slackwarez.org (anubis) Date: Wed, 27 Dec 2000 02:04:01 +0000 Subject: Openssh and Slackware 7.1 Message-ID: <00122702052900.02767@anubis> password authentication fails even tho i used LIBS=-lcrypt option Any help will be appreciated From markus.friedl at informatik.uni-erlangen.de Wed Dec 27 23:19:16 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 27 Dec 2000 13:19:16 +0100 Subject: PAM configuration In-Reply-To: ; from pekkas@netcore.fi on Wed, Dec 27, 2000 at 01:02:19PM +0200 References: Message-ID: <20001227131916.C31667@folly> On Wed, Dec 27, 2000 at 01:02:19PM +0200, Pekka Savola wrote: > Also I noticed there is a 'ConnectionsPerPeriod' option for sshd which > allows ratelimiting (conns/sec) for incoming connections. I don't think > this has been upstreamed. The man page gives the following info: openssh already has 'MaxStartups'. this is imho more useful. From markus.friedl at informatik.uni-erlangen.de Thu Dec 28 01:19:17 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 27 Dec 2000 15:19:17 +0100 Subject: supervise and openssh (fwd) Message-ID: <20001227151917.A2301@folly> fyi, not all changes are integrated. -------------- next part -------------- An embedded message was scrubbed... From: blinky Subject: Re: supervise and openssh Date: Wed, 27 Dec 2000 14:33:59 +0100 Size: 1399 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001227/02628ef8/attachment.mht From naddy at mips.inka.de Thu Dec 28 02:07:23 2000 From: naddy at mips.inka.de (Christian Weisgerber) Date: Wed, 27 Dec 2000 15:07:23 +0000 (UTC) Subject: PAM configuration References: Message-ID: <92d0jb$1kfi$1@kemoauc.mips.inka.de> Damien Miller wrote: > - Does FreeBSD and other systems where PAM is a port or addon still > use /etc/pam.d? FreeBSD has OpenSSH in the base system. -- Christian "naddy" Weisgerber naddy at mips.inka.de From vorlon at netexpress.net Thu Dec 28 04:36:13 2000 From: vorlon at netexpress.net (Steve Langasek) Date: Wed, 27 Dec 2000 11:36:13 -0600 (CST) Subject: PAM configuration In-Reply-To: Message-ID: Hi Damien, On Wed, 27 Dec 2000, Damien Miller wrote: > To stem the tide of support requests from people who don't read the > INSTALL file when installing OpenSSH and then complain about password > auth failing. I am considering the idea of automagically installing a > PAM file into /etc/pam.d if it exists, PAM support is enabled and no > such file already exists. > I have a couple of questions: > - Some PAM control files specifiy full paths to the modules, is this > necessary? It is not necessary with Linux-PAM; if an absolute path is not specified, Linux-PAM will look for the module in the compiled-in default directory. It seems to be personal preference on the part of the admin/packager that determines which way it's written. The default module directory isn't likely to move anytime soon, so effectively it's not very important. > - I want a "no-frills" control file which will work with the widest > range of systems and still be secure. Would something like the following > work everywhere? I assume pam_unix is pretty standards, but how about > pam_cracklib, pam_nologin and pam_limits? The big question, of course, is whether these modules are available with the Solaris and HPUX PAM implementations. I haven't worked with either, so I don't have any idea. I don't know that I would agree with using pam_cracklib by default. The module has a somewhat spotty history, and even if available everywhere it will not always give the desired results, particularly on older Linux installs. Let the distro maintainers deal with those problems when they package openssh, rather than bringing those support issues down on yourself. :) > I don't really want to ship without pam_cracklib in for password > changes (since that is what most sites use as default). Can password > changing be disabled using pam_deny? > #%PAM-1.0 > auth required pam_unix.so shadow nodelay The 'shadow' option to pam_unix has no meaning when used in the 'auth' section, and never has. All versions of pam_unix that I've ever seen (and pam_pwdb, for that matter) will auto-detect whether to look in the shadow file for the password, as should be the case. This ever-present 'shadow' arg seems to be something someone at RedHat came up with once upon a time, and everyone else has just followed along unquestioningly without ever looking at the source. :) Fortunately, all versions of pam_unix I've ever seen will also silently ignore this option when given in the 'auth' section, but according to the docs, an unknown argument to a pam module is to be considered a fatal error. Implementations of pam_unix on other OSes may follow this more strictly, so where portability is an issue, 'shadow' should be dropped. Cheers, Steve Langasek postmodern programmer From mouring at etoh.eviladmin.org Thu Dec 28 06:00:20 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 27 Dec 2000 13:00:20 -0600 (CST) Subject: supervise and openssh (fwd) In-Reply-To: <20001227151917.A2301@folly> Message-ID: On Wed, 27 Dec 2000, Markus Friedl wrote: > fyi, not all changes are integrated. > It is in the snapshots, but I just noticed that there is no usage entry for it. Nor is there an entry in the OpenBSD tree. The following should resolve the issue (against the portable tree). --- ../openssh/sshd.c Thu Dec 21 20:37:04 2000 +++ sshd.c Wed Dec 27 12:53:28 2000 @@ -653,6 +653,7 @@ fprintf(stderr, " -f file Configuration file (default %s)\n", SERVER_CONFIG_FILE); fprintf(stderr, " -d Debugging mode (multiple -d means more debugging)\n"); fprintf(stderr, " -i Started from inetd\n"); + fprintf(stderr, " -D Startup without forking\n"); fprintf(stderr, " -q Quiet (no logging)\n"); fprintf(stderr, " -p port Listen on the specified port (default: 22)\n"); fprintf(stderr, " -k seconds Regenerate server key every this many seconds (default: 3600)\n"); From mouring at etoh.eviladmin.org Thu Dec 28 06:15:55 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 27 Dec 2000 13:15:55 -0600 (CST) Subject: implicit declaration warnings In-Reply-To: Message-ID: On Wed, 27 Dec 2000, Pekka Savola wrote: > Hi, > > When I tested the latest snapshot on FreeBSD 4.2, I noticed some implicit > declaration warnings I didn't recall seeing on Linux. > Hmm.. I think the following patch may be what you wanted. - Ben --- ../openssh/loginrec.c Fri Dec 1 15:19:51 2000 +++ loginrec.c Wed Dec 27 13:11:13 2000 @@ -167,6 +167,10 @@ # include #endif +#ifdef HAVE_LIBUTIL_H +# include +#endif + /** ** prototypes for helper functions in this file **/ --- ../openssh/configure.in Wed Dec 27 00:52:07 2000 +++ configure.in Wed Dec 27 13:08:18 2000 @@ -309,6 +308,7 @@ dnl Checks for time functions AC_CHECK_FUNCS(gettimeofday time) dnl Checks for libutil functions +AC_CHECK_HEADERS(libutil.h) AC_CHECK_FUNCS(login logout updwtmp logwtmp) dnl Checks for utmp functions AC_CHECK_FUNCS(endutent getutent getutid getutline pututline setutent) From Alan.Millar at lpcorp.com Thu Dec 28 05:42:50 2000 From: Alan.Millar at lpcorp.com (Alan Millar) Date: Wed, 27 Dec 2000 10:42:50 -0800 Subject: PAM configuration (HP-UX pam) In-Reply-To: Message-ID: > > To stem the tide of support requests from people who don't read the > > INSTALL file when installing OpenSSH and then complain > about password > > auth failing. I am considering the idea of automagically > installing a > > PAM file into /etc/pam.d if it exists, PAM support is > enabled and no > > such file already exists. > > - I want a "no-frills" control file which will work with the widest > > range of systems and still be secure. Would something like > the following > > work everywhere? I assume pam_unix is pretty standards, but > how about > > pam_cracklib, pam_nologin and pam_limits? > > The big question, of course, is whether these modules are > available with the > Solaris and HPUX PAM implementations. I haven't worked with > either, so I > don't have any idea. FWIW, HP-UX 11.0 uses pam, included as part of the OS from HP. I don't know how far it varies from the current Linux or Solaris pam implementations. Not being very versed in pam myself, it appears to me that it matches Solaris pam a little closer than Linux, definitely compared to current Linux work. In compiling mod_auth_pam for Apache on HP-UX 11.0, a few ifdef's were needed that matched the Solaris ones. HP-UX 11 uses /etc/pam.conf. The pam_cracklib, pam_nologin and pam_limits modules are not included with the HP distribution. I have not looked into whether people are adding them after-the-fact or not. I have heard that some people [are attempting to?] use Linux pam ported to HP-UX 10.20, which didn't have universal pam support from HP, but I don't know any details. For better or for worse, if the OpenSSH install looks for /etc/pam.d, it will bypass any HP-UX 11.0 compatibility issues :-) - Alan -- Alan Millar Email: Alan.Millar at LPCorp.com Unix System Administrator Voice: 503-624-9004 x3014 Louisiana-Pacific Fax: 509-692-3948 From shorty at getuid.de Thu Dec 28 06:16:45 2000 From: shorty at getuid.de (Christian Kurz) Date: Wed, 27 Dec 2000 20:16:45 +0100 Subject: Incorrect shell quotation in scp Message-ID: <20001227201645.L10650@seteuid.getuid.de> Hi, as the current debian maintainer of the openssh package is a bit busy, I'm helping him with fixing a part of the bugs in openssh that debian users found will forward some of the reports to you. This is the first one and a fix or a comment why this should not be fixed would be appropriated. Thanks Space in filename is not correctly passed by scp to other invoked programs: |host:/usr/src/xx# scp vana:/mnt2/mp3/Celine\ Dion/ . |root at host.do.main's password: |scp: /mnt2/mp3/Celine: No such file or directory |scp: Dion/: No such file or directory |host:/usr/src/xx# scp "vana:/mnt2/mp3/Celine Dion" . |root at host.do.main's password: |scp: /mnt2/mp3/Celine: No such file or directory |scp: Dion: No such file or directory |host:/usr/src/xx# scp vana:\"/mnt2/mp3/Celine Dion\" . |root at host.do.main's password: |bash: -c: line 1: unexpected EOF while looking for matching `"' |bash: -c: line 2: syntax error: unexpected end of file |sh: -c: line 1: unexpected EOF while looking for matching `"' |sh: -c: line 2: syntax error: unexpected end of file |host:/usr/src/xx# scp "vana:\"/mnt2/mp3/Celine Dion\"" . |root at host.do.main's password: |scp: /mnt2/mp3/Celine Dion: not a regular file |host:/usr/src/xx# |So only correct syntax is last one - "host:\"path\""... Everything |else gives some unexpected results: |host:/usr/src/xx# scp "vana:/; echo rwx666" . |root at host.do.main's password: |scp: /: not a regular file |protocol error: expected control record |host:/usr/src/xx# |As command after ';' is not executed with uid of sshd (I believe), I'm |marking it as wishlist only... -- While the year 2000 (y2k) problem is not an issue for us, all Linux implementations will impacted by the year 2038 (y2.038k) issue. The Debian Project is committed to working with the industry on this issue and we will have our full plans and strategy posted by the first quarter of 2020. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001227/6cf0ec90/attachment.bin From shorty at debian.org Thu Dec 28 06:33:21 2000 From: shorty at debian.org (Christian Kurz) Date: Wed, 27 Dec 2000 20:33:21 +0100 Subject: /etc/nologin ignored on RSA auth Message-ID: <20001227203321.P10650@seteuid.getuid.de> Hi, and here's another bug report against openssh which I could verify using openssh from cvs. So could we please change the behaviour of openssh to be consistent? > when /etc/nologin exists and the pam_nologin.so module is included in > the sshd pam file then users will be denied access when it exists > (though its contents are not displayed to them) however if the user > logs in using RSA authentication then they are allowed in regardless > of /etc/nologin. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001227/ed928c8c/attachment.bin From pekkas at netcore.fi Thu Dec 28 06:48:50 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 27 Dec 2000 21:48:50 +0200 (EET) Subject: implicit declaration warnings In-Reply-To: Message-ID: On Wed, 27 Dec 2000 mouring at etoh.eviladmin.org wrote: > On Wed, 27 Dec 2000, Pekka Savola wrote: > > > Hi, > > > > When I tested the latest snapshot on FreeBSD 4.2, I noticed some implicit > > declaration warnings I didn't recall seeing on Linux. > > > Hmm.. I think the following patch may be what you wanted. Yeah. Works with that. Also, __b64_ntop and _pton warnings can be avoided by adding resolv.h in similar fashion but that makes the linking fail in uudecode on Linux (which doesn't have B64_NTOP etc.) -- -lresolv would be required for that, and adding that would be rather suboptimal. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From carenas at chasqui.lared.net.pe Thu Dec 28 07:00:35 2000 From: carenas at chasqui.lared.net.pe (Carlo Marcelo Arenas Belon) Date: Wed, 27 Dec 2000 15:00:35 -0500 (PET) Subject: [PAM] Re: PAM configuration In-Reply-To: Message-ID: > > - How is PAM controlled on Solaris? Is there a pam.d directory or does > > it just use pam.conf? Do we need to install a control file for OpenSSH? on Solaris 7 there is an /etc/pam.conf as there is one on Solaris 2.6, dunno if there is any change on Solaris 8. HTH Carlo From stain at nvg.org Thu Dec 28 07:03:06 2000 From: stain at nvg.org (Stian Soiland) Date: Wed, 27 Dec 2000 21:03:06 +0100 Subject: Incorrect shell quotation in scp In-Reply-To: <20001227201645.L10650@seteuid.getuid.de>; from shorty@getuid.de on Wed, Dec 27, 2000 at 08:16:45PM +0100 References: <20001227201645.L10650@seteuid.getuid.de> Message-ID: <20001227210306.B31685@traad.dhs.org> On 2000-12-27 20:16:45+0100, Christian Kurz wrote: >as the current debian maintainer of the openssh package is a bit busy, >I'm helping him with fixing a part of the bugs in openssh that debian >users found will forward some of the reports to you. This is the first >one and a fix or a comment why this should not be fixed would be >appropriated. Thanks >Space in filename is not correctly passed by scp to other invoked >programs: I supplied a patch for this problem two weeks ago. The patch is still uncommented on the list, and not taken into the CVS, but it really works great. Here goes: http://stain.portveien.to/diverse/scp/ The problem resides in missing quotation of commands from scp to ssh. This patch should fix this. (and, yes, you might as well change the same lines in the woody-version. :) ) -- Stian S?iland - Trondheim, Norway - http://stain.portveien.to/ Jeg kan ikke late som om jeg ikke vet det jeg vet. Men det er drit. Det er det virkelig. Gi meg en ball. Gi meg en sykkel. Det er st?rrelser jeg takler. [Loe] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001227/0a236bf0/attachment.bin From shorty at debian.org Thu Dec 28 07:03:07 2000 From: shorty at debian.org (Christian Kurz) Date: Wed, 27 Dec 2000 21:03:07 +0100 Subject: scp doesn't have a 'Use non privileged port' switch Message-ID: <20001227210307.W10650@seteuid.getuid.de> Hi, and another feature request that I got from a debian user and that I think should be included in openssh. Thanks. |Unlike the 'old' ssh (Package: ssh; Version: 1.2.26-1.2)'s scp |openssh's scp does not support the -L option which according to |old ssh's manpage does the following: |> -L Use non privileged port. With this you cannot use |> rhosts or rsarhosts authentications, but it can be |> used to bypass some firewalls that dont allow privi? |> leged source ports to pass. Same as saying "-o |> UsePriviledgePort=no" or -P to ssh; -L is used due |> to exhaustion of suitable letters. |This can and does break scripts and is esp. nasty behind firewalls. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001227/c157aedc/attachment.bin From shorty at debian.org Thu Dec 28 07:08:49 2000 From: shorty at debian.org (Christian Kurz) Date: Wed, 27 Dec 2000 21:08:49 +0100 Subject: Problems with reading pam_env and setting enviroment variables Message-ID: <20001227210849.A12722@seteuid.getuid.de> Hi guys, here's another nasty bug in openssh that I also noticed. Has this already been fixed or would someone please take care of this? Thanks. > If I enable the line: > auth required pam_env.so > to the ssh pam file, with the following line in > /etc/security/pam_env.conf > file: > PATH DEFAULT=/usr/local/bin:/bin:/usr/bin:/usr/bin/X11:/usr/games > then when I login with ssh, I get garbage for a path: > ?Cr/t?l@??Cca?>l@?'@/bi?????>n@?'@4????\&@lg&@?\&@??????:@?????Cr/t?l@??Cca?>l@?'@/bi?????>n@?'@4????\&@lgg&@?\&@??????:@???? > Disableing pam_env.so in the ssh pam file fixes this. Also, putting PATH > in /etc/environment and excluding it from pam_env.conf works. I'd > normally think this is a pam bug, but I've only seen this with ssh. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001227/d02dc374/attachment.bin From pekkas at netcore.fi Thu Dec 28 08:19:39 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 27 Dec 2000 23:19:39 +0200 (EET) Subject: scp doesn't have a 'Use non privileged port' switch In-Reply-To: <20001227210307.W10650@seteuid.getuid.de> Message-ID: On Wed, 27 Dec 2000, Christian Kurz wrote: > Hi, > > and another feature request that I got from a debian user and that I > think should be included in openssh. Thanks. > > |Unlike the 'old' ssh (Package: ssh; Version: 1.2.26-1.2)'s scp > |openssh's scp does not support the -L option which according to > |old ssh's manpage does the following: > > |> -L Use non privileged port. With this you cannot use > |> rhosts or rsarhosts authentications, but it can be > |> used to bypass some firewalls that dont allow privi? > |> leged source ports to pass. Same as saying "-o > |> UsePriviledgePort=no" or -P to ssh; -L is used due > |> to exhaustion of suitable letters. > As mentioned, use 'scp -o "UsePrivilegedPort=no"' or add the option to ssh_config or .ssh/config. IIRC there's no intention of bloating scp with all kinds of options when you can pass them directly to ssh with -o (this was the argument with scp -2 option, at least). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From openssh-unix-dev at progressive-comp.com Thu Dec 28 09:31:19 2000 From: openssh-unix-dev at progressive-comp.com (Hank Leininger) Date: Wed, 27 Dec 2000 17:31:19 -0500 Subject: Openssh and Slackware 7.1 Message-ID: <200012272231.RAA25775@mailer.progressive-comp.com> On 2000-12-27, anubis wrote: > password authentication fails even tho i used LIBS=-lcrypt option > Any help will be appreciated Dollars to donuts you didn't pass configure the --with-md5-passwords option. Slackware 7.x uses md5-hash based passwords instead of crypt, a hash based on DES. Rerun configure with --with-md5-passwords and rebuild/ reinstall and it should work. -- Hank Leininger From shorty at debian.org Thu Dec 28 07:51:35 2000 From: shorty at debian.org (Christian Kurz) Date: Wed, 27 Dec 2000 21:51:35 +0100 Subject: PrintLastLog option is not honored Message-ID: <20001227215135.H12722@seteuid.getuid.de> Hi, here's another bug report against openssh with a patch included (from the same person who submitted the bug report). Would you please apply it? Thanks! > The Debian package of ssh includes patches to recognize a 'PrintLastLog' > option which can be used to disable the automatic display of the last > login time. (This is often handled by PAM.) The option is scanned and > converted to a flag variable, but that flag variable is never examined, > so the patch does no good. |--- openssh-2.2.0p1/session.c Tue Aug 29 15:21:22 2000 |+++ openssh-2.2.0p1z/session.c Mon Sep 18 09:55:01 2000 |@@ -686,7 +686,7 @@ | */ | last_login_time = get_last_login_time(pw->pw_uid, pw->pw_name, | buf, sizeof(buf)); |- if (last_login_time != 0) { |+ if (last_login_time != 0 && options.print_lastlog) { | time_string = ctime(&last_login_time); | if (strchr(time_string, '\n')) | *strchr(time_string, '\n') = 0; Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001227/976b1a34/attachment.bin From shorty at debian.org Thu Dec 28 09:19:27 2000 From: shorty at debian.org (Christian Kurz) Date: Wed, 27 Dec 2000 23:19:27 +0100 Subject: sshd prints the motd with -t option Message-ID: <20001227231927.I12722@seteuid.getuid.de> Hi, and another interesting bug report, where I'm not sure what the correct behaviour of openssh should be. Thanks for your comments: > I find myself frequently using OpenSSH to log in and perform a single > command (particularly in a script to perform some quick, simple task on > multiple machines I administer). If the '-t' option is not included, the > behavior is no different than with the non-OpenSSH ssh inplementation. > However, this causes problems when I need to enter a password for, say, > sudo; the password is echoed back to the screen and the command fails. If > instead I enter 'ssh -t user at host command', sudo and others will work > properly, but the motd is printed as well. This adds significantly to the > output to be human-parsed and makes it more difficult to discern what > output came from which machine, as well as being different from the > original ssh and ssh2 implementations. Here is some sample output; first, > an example of performing a command on a host running the original ssh > implementation: |bj at host01:~$ ssh host00 ls / |Warning: Server lies about size of server host key: actual size is 1023 |bits vs. | announced 1024. |Warning: This may be due to an old implementation of ssh. |bj at host00.do.main's password: |bin |boot |cdrom |dev |etc |floppy |home |initrd |lib |lost+found |mnt |proc |root |sbin |tmp |usr |var |vmlinuz |vmlinuz.old |bj at host01:~$ ssh -t host00 ls / |Warning: Server lies about size of server host key: actual size is 1023 |bits vs. announced 1024. |Warning: This may be due to an old implementation of ssh. |bj at host00.do.main's password: |bin etc lib root var |boot floppy lost+found sbin vmlinuz |cdrom home mnt tmp vmlinuz.old |dev initrd proc usr |Connection to host00.do.main closed. |bj at host01:~$ |Next, connecting to a host running OpenSSH's sshd: |bj at host00:~$ ssh host01 ls / |bj at host01's password: |bin |boot |cdrom |dev |etc |floppy |home |home.delete |initrd |lib |lost+found |mnt |proc |root |sbin |storage |tmp |usr |var |vmlinuz |vmlinuz.old |bj at host00:~$ ssh -t host01 ls / |bj at host01's password: |Last login: Sat Aug 12 18:20:18 2000 from some.host.do.main on pts/1 |Linux host01 2.2.5 #2 Wed May 24 19:31:11 EDT 2000 i686 unknown |Most of the programs included with the Debian GNU/Linux system are |freely redistributable; the exact distribution terms for each program |are described in the individual files in /usr/doc/*/copyright |Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent |permitted by applicable law. |You have new mail. |bin dev home lib proc storage var |boot etc home.delete lost+found root tmp vmlinuz |cdrom floppy initrd mnt sbin usr vmlinuz.old |Connection to host01 closed. |bj at host00:~$ |host00 is a slink system running the older implementation of ssh, and |host01 is a potato system running OpenSSH. |I would like to suggest that OpenSSH be modified to suppress printing the |motd if the -t option is used and it is a non-login session, ie, the |connection is opened for command processing only. |bj at host00:~$ grep PrintMotd /etc/ssh/sshd_config |PrintMotd yes |bj at host01:~$ grep PrintMotd /etc/ssh/sshd_config |PrintMotd no Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001227/69a57d4f/attachment.bin From pekkas at netcore.fi Thu Dec 28 09:45:03 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 28 Dec 2000 00:45:03 +0200 (EET) Subject: PrintLastLog option is not honored In-Reply-To: <20001227215135.H12722@seteuid.getuid.de> Message-ID: On Wed, 27 Dec 2000, Christian Kurz wrote: > here's another bug report against openssh with a patch included (from > the same person who submitted the bug report). Would you please apply > it? Thanks! Umm.. There is no print_lastlog option in OpenSSH base/portable. Perhaps you should supply the actual patch too ;-) > > The Debian package of ssh includes patches to recognize a 'PrintLastLog' > > option which can be used to disable the automatic display of the last > > login time. (This is often handled by PAM.) The option is scanned and > > converted to a flag variable, but that flag variable is never examined, > > so the patch does no good. > > |--- openssh-2.2.0p1/session.c Tue Aug 29 15:21:22 2000 > |+++ openssh-2.2.0p1z/session.c Mon Sep 18 09:55:01 2000 > |@@ -686,7 +686,7 @@ > | */ > | last_login_time = get_last_login_time(pw->pw_uid, pw->pw_name, > | buf, sizeof(buf)); > |- if (last_login_time != 0) { > |+ if (last_login_time != 0 && options.print_lastlog) { > | time_string = ctime(&last_login_time); > | if (strchr(time_string, '\n')) > | *strchr(time_string, '\n') = 0; > > Ciao > Christian > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From shorty at debian.org Thu Dec 28 09:56:56 2000 From: shorty at debian.org (Christian Kurz) Date: Wed, 27 Dec 2000 23:56:56 +0100 Subject: PrintLastLog option is not honored In-Reply-To: References: <20001227215135.H12722@seteuid.getuid.de> Message-ID: <20001227235656.A3372@bofh.de> On 00-12-28 Pekka Savola wrote: > On Wed, 27 Dec 2000, Christian Kurz wrote: > > here's another bug report against openssh with a patch included (from > > the same person who submitted the bug report). Would you please apply > > it? Thanks! > Umm.. There is no print_lastlog option in OpenSSH base/portable. > Perhaps you should supply the actual patch too ;-) Thanks, I just noticed that I wonder where this patch is coming from. Damn it's getting late. I should better go to bed know, but could this be the patch for LastLog: Index: session.c --- session.c.prev +++ session.c Tue Sep 12 14:29:49 2000 @@ -681,19 +681,22 @@ do_login(Session *s) #endif /* WITH_AIXAUTHENTICATE */ - /* - * Get the time when the user last logged in. 'buf' will be set - * to contain the hostname the last login was from. - */ - last_login_time = get_last_login_time(pw->pw_uid, pw->pw_name, - buf, sizeof(buf)); - if (last_login_time != 0) { - time_string = ctime(&last_login_time); - if (strchr(time_string, '\n')) - *strchr(time_string, '\n') = 0; - if (strcmp(buf, "") == 0) - printf("Last login: %s\r\n", time_string); - else - printf("Last login: %s from %s\r\n", time_string, buf); + if (options.print_lastlog) { + /* + * Get the time when the user last logged in. 'buf' will + * be set to contain the hostname the last login was from. + */ + last_login_time = get_last_login_time(pw->pw_uid, pw->pw_name, + buf, sizeof(buf)); + if (last_login_time != 0) { + time_string = ctime(&last_login_time); + if (strchr(time_string, '\n')) + *strchr(time_string, '\n') = 0; + printf("Last login: %s", time_string); + if (*buf) + printf(" from %s", buf); + printf("\r\n"); + } } + if (options.print_motd) { #ifdef HAVE_LOGIN_CAP I found it in a bugreport with the comment: |The PrintLastLogin configuration option is currently ignored: |last-login info is *always* printed. This patch corrects the bug. The patch above was written by Chip Salzenberg , if this matters. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 From shorty at debian.org Thu Dec 28 09:45:40 2000 From: shorty at debian.org (Christian Kurz) Date: Wed, 27 Dec 2000 23:45:40 +0100 Subject: PAM_RHOST not available for authentication Message-ID: <20001227234540.M12722@seteuid.getuid.de> Hi and here's an feature request from a user/developer, wher I would like to hear your comments again. Thanks > The PAM_RHOST item, which tells PAM which remote host it is conversing > with, is currently set by OpenSSH _after_ authentication is made. This > is not a good thing for me, as a have written a module which needs the > IP of the peer as a part of authentication. > My module was written to eleminate the need for a patched ssh daemon so > I was not happy to see that PAM_RHOST was not set until do_pam_account() > which is called from within an 'if (authenticated)' in auth[12].c > What I would like to see is a > pam_set_item((pam_handle_t *)pamh, PAM_RHOST, get_canonical_hostname()); > as soon as possible in the code, before authentication. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001227/087973ff/attachment.bin From shorty at debian.org Thu Dec 28 09:47:58 2000 From: shorty at debian.org (Christian Kurz) Date: Wed, 27 Dec 2000 23:47:58 +0100 Subject: patch to support hurd-i386 Message-ID: <20001227234758.N12722@seteuid.getuid.de> Hi, here's a patch so that ssh also supports hurd-i386. Thanks for incorporating. The patch comes from Robert Bihlmeyer . > openssh 2.2.0p1-1.1 does not build on the Hurd. The appended patch > fixes that. Changes in detail: > * PAM is not (yet?) supported, so the PAM dependencies are only put into > the control file on architectures != hurd-i386. > * Hurd has no random device, therefore /etc/ssh/ssh_prng_conf is needed. > Added to conffiles. > * Do not try to generate a hostkey while building the package. This is > useless, and it will fail on the Hurd if ssh is not yet installed. > * Hurd has no MAXHOSTNAME. Two instances replaced by fixed limit, where > only the first N bytes were used, anyway. Two more instances replaced > by a grow-until-fits loop. diff -Nur openssh-2.2.0p1-/Makefile.in openssh-2.2.0p1/Makefile.in --- openssh-2.2.0p1-/Makefile.in Sun Oct 29 16:17:49 2000 +++ openssh-2.2.0p1/Makefile.in Sun Oct 29 16:44:49 2000 @@ -116,7 +116,7 @@ distprep: catman-do autoreconf -install: manpages $(TARGETS) install-files host-key +install: manpages $(TARGETS) install-files install-files: ./mkinstalldirs $(DESTDIR)$(bindir) diff -Nur openssh-2.2.0p1-/canohost.c openssh-2.2.0p1/canohost.c --- openssh-2.2.0p1-/canohost.c Thu Jun 22 13:32:31 2000 +++ openssh-2.2.0p1/canohost.c Sun Oct 29 16:44:49 2000 @@ -32,7 +32,8 @@ int i; socklen_t fromlen; struct addrinfo hints, *ai, *aitop; - char name[MAXHOSTNAMELEN]; + char *name; + size_t name_size; char ntop[NI_MAXHOST], ntop2[NI_MAXHOST]; /* Get IP address of client. */ @@ -71,10 +72,21 @@ fatal("get_remote_hostname: getnameinfo NI_NUMERICHOST failed"); /* Map the IP address to a host name. */ - if (getnameinfo((struct sockaddr *)&from, fromlen, name, sizeof(name), - NULL, 0, NI_NAMEREQD) == 0) { + name_size = 100; + name = malloc(name_size); + if (name == NULL) + fatal("get_remote_hostname: not enough space for hostname"); + while ((i = getnameinfo((struct sockaddr *)&from, fromlen, name, + name_size, NULL, 0, NI_NAMEREQD)) + == EAI_MEMORY) { + name_size <<= 1; + name = realloc(name, name_size); + if (name == NULL) + fatal("get_remote_hostname: not enough space for hostname"); + } + if (i == 0) { /* Got host name. */ - name[sizeof(name) - 1] = '\0'; + name[name_size - 1] = '\0'; /* * Convert it to all lowercase (which is expected by the rest * of this software). @@ -97,7 +109,7 @@ hints.ai_socktype = SOCK_STREAM; if (getaddrinfo(name, NULL, &hints, &aitop) != 0) { log("reverse mapping checking getaddrinfo for %.700s failed - POSSIBLE BREAKIN ATTEMPT!", name); - strlcpy(name, ntop, sizeof name); + strlcpy(name, ntop, name_size); goto check_ip_options; } /* Look for the address from the list of addresses. */ @@ -113,13 +125,13 @@ /* Address not found for the host name. */ log("Address %.100s maps to %.600s, but this does not map back to the address - POSSIBLE BREAKIN ATTEMPT!", ntop, name); - strlcpy(name, ntop, sizeof name); + strlcpy(name, ntop, name_size); goto check_ip_options; } /* Address was found for the host name. We accept the host name. */ } else { /* Host name not found. Use ascii representation of the address. */ - strlcpy(name, ntop, sizeof name); + strlcpy(name, ntop, name_size); log("Could not reverse map address %.100s.", name); } @@ -162,7 +174,7 @@ } } - return xstrdup(name); + return name; } /* diff -Nur openssh-2.2.0p1-/channels.c openssh-2.2.0p1/channels.c --- openssh-2.2.0p1-/channels.c Sun Oct 29 16:17:49 2000 +++ openssh-2.2.0p1/channels.c Sun Oct 29 16:44:49 2000 @@ -1720,7 +1720,7 @@ char strport[NI_MAXSERV]; int gaierr, n, num_socks = 0, socks[NUM_SOCKS]; char display[512]; - char hostname[MAXHOSTNAMELEN]; + char hostname[401]; /* we only use the first 400 bytes anyway*/ for (display_number = x11_display_offset; display_number < MAX_DISPLAYS; @@ -1791,7 +1791,8 @@ /* Set up a suitable value for the DISPLAY variable. */ - if (gethostname(hostname, sizeof(hostname)) < 0) + if (gethostname(hostname, sizeof(hostname)) < 0 + && errno != ENAMETOOLONG) fatal("gethostname: %.100s", strerror(errno)); #ifdef IPADDR_IN_DISPLAY -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001227/9332129d/attachment.bin From shorty at debian.org Thu Dec 28 09:51:20 2000 From: shorty at debian.org (Christian Kurz) Date: Wed, 27 Dec 2000 23:51:20 +0100 Subject: patch to support hurd-i386. Message-ID: <20001227235120.O12722@seteuid.getuid.de> Damn, forgot the rest of the patch. Here it comes. diff -Nur openssh-2.2.0p1-/ssh-keygen.c openssh-2.2.0p1/ssh-keygen.c --- openssh-2.2.0p1-/ssh-keygen.c Wed Aug 23 02:46:24 2000 +++ openssh-2.2.0p1/ssh-keygen.c Sun Oct 29 16:44:50 2000 @@ -68,7 +68,7 @@ static const char *__progname = "ssh-keygen"; #endif /* HAVE___PROGNAME */ -char hostname[MAXHOSTNAMELEN]; +char *hostname; void ask_filename(struct passwd *pw, const char *prompt) @@ -525,10 +525,24 @@ printf("You don't exist, go away!\n"); exit(1); } - if (gethostname(hostname, sizeof(hostname)) < 0) { - perror("gethostname"); - exit(1); - } + { + size_t size = 100; + hostname = (char *)malloc(size); + while (hostname) { + if (gethostname(hostname, size) >= 0) + break; + if (errno != ENAMETOOLONG) { + perror("gethostname"); + exit(1); + } + size <<= 1; + hostname = realloc(hostname, size); + } + if (hostname == NULL) { + perror("malloc"); + exit(1); + } + } while ((opt = getopt(ac, av, "dqpclRxXyb:f:P:N:C:")) != EOF) { switch (opt) { diff -Nur openssh-2.2.0p1-/sshd.c openssh-2.2.0p1/sshd.c --- openssh-2.2.0p1-/sshd.c Tue Aug 29 02:05:50 2000 +++ openssh-2.2.0p1/sshd.c Sun Oct 29 16:44:50 2000 @@ -140,7 +140,7 @@ int session_id2_len = 0; /* record remote hostname or ip */ -unsigned int utmp_len = MAXHOSTNAMELEN; +unsigned int utmp_len = 256; /* bigger than LI_HOSTSIZE makes no sense */ /* Prototypes for various functions defined later in this file. */ void do_ssh1_kex(); -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001227/8a794ead/attachment.bin From mouring at etoh.eviladmin.org Thu Dec 28 12:18:51 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 27 Dec 2000 19:18:51 -0600 (CST) Subject: PrintLastLog option is not honored In-Reply-To: <20001227235656.A3372@bofh.de> Message-ID: On Wed, 27 Dec 2000, Christian Kurz wrote: > On 00-12-28 Pekka Savola wrote: > > On Wed, 27 Dec 2000, Christian Kurz wrote: > > > here's another bug report against openssh with a patch included (from > > > the same person who submitted the bug report). Would you please apply > > > it? Thanks! > > > Umm.. There is no print_lastlog option in OpenSSH base/portable. > > Perhaps you should supply the actual patch too ;-) > > Thanks, I just noticed that I wonder where this patch is coming from. > Damn it's getting late. I should better go to bed know, but could this > be the patch for LastLog: > Still an incomplete and broken patch. If the person who originally submitted it wants to write a complete patch and submit it. Then we would be happy to debate if it will be included. - Ben From mouring at etoh.eviladmin.org Thu Dec 28 12:40:53 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 27 Dec 2000 19:40:53 -0600 (CST) Subject: patch to support hurd-i386 In-Reply-To: <20001227234758.N12722@seteuid.getuid.de> Message-ID: On Wed, 27 Dec 2000, Christian Kurz wrote: > Hi, > > here's a patch so that ssh also supports hurd-i386. Thanks for > incorporating. The patch comes from Robert Bihlmeyer . > > > openssh 2.2.0p1-1.1 does not build on the Hurd. The appended patch > > fixes that. Changes in detail: > > > * PAM is not (yet?) supported, so the PAM dependencies are only put into > > the control file on architectures != hurd-i386. > > > * Hurd has no random device, therefore /etc/ssh/ssh_prng_conf is needed. > > Added to conffiles. > > > * Do not try to generate a hostkey while building the package. This is > > useless, and it will fail on the Hurd if ssh is not yet installed. > "make install" should alway check if it should generate hostkeys. The package manager should not be calling 'make install' unless it's doing a test run (via -n). Also in the most recent CVS tree all ssh-keygen are relative to the make directory. > > * Hurd has no MAXHOSTNAME. Two instances replaced by fixed limit, where > > only the first N bytes were used, anyway. Two more instances replaced > > by a grow-until-fits loop. > HURD does not have MAXHOSTNAME?! They must have removed it from the MACH header files or NeXTStep added it. I would want to know Markus' view on that aspect of the patch. I find it overly complex (besides the fact we have xmalloc() and xrealloc() to handle the null returns that should fail using fatal()). I see one or two nice things suggestions in the patch. I think they may want to consider either defining MAXHOSTNAME (because it's used by a lot of software) or we can test and set a limit if there is none. - Ben From tim at multitalents.net Thu Dec 28 13:40:51 2000 From: tim at multitalents.net (Tim Rice) Date: Wed, 27 Dec 2000 18:40:51 -0800 (PST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: Message-ID: Here is a patch for SCO Open Server 5 It has sys/queue.h but it has nothing to do with the intended use. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- acconfig.h.old Tue Dec 19 18:34:49 2000 +++ acconfig.h Wed Dec 27 18:00:28 2000 @@ -12,6 +12,7 @@ /* SCO workaround */ #undef BROKEN_SYS_TERMIO_H +#undef HAVE_BOGUS_SYS_QUEUE_H /* Define if you have SCO protected password database */ #undef HAVE_SCO_PROTECTED_PW --- configure.in.old Tue Dec 19 18:34:49 2000 +++ configure.in Wed Dec 27 17:55:28 2000 @@ -229,6 +229,7 @@ rsh_path="/usr/bin/rcmd" AC_DEFINE(HAVE_SCO_PROTECTED_PW) AC_DEFINE(DISABLE_SHADOW) + AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) ;; *-dec-osf*) # This is untested --- ssh-keyscan.c.old Thu Dec 21 17:44:00 2000 +++ ssh-keyscan.c Wed Dec 27 17:57:25 2000 @@ -10,7 +10,7 @@ #include "includes.h" RCSID("$OpenBSD: ssh-keyscan.c,v 1.6 2000/12/19 23:17:58 markus Exp $"); -#ifdef HAVE_SYS_QUEUE_H +#if defined(HAVE_SYS_QUEUE_H) && !defined(HAVE_BOGUS_SYS_QUEUE_H) #include #else #include "bsd-queue.h" From stevesk at pobox.com Thu Dec 28 13:57:45 2000 From: stevesk at pobox.com (Kevin Steves) Date: Thu, 28 Dec 2000 03:57:45 +0100 (CET) Subject: implicit declaration warnings In-Reply-To: Message-ID: On Wed, 27 Dec 2000, Pekka Savola wrote: : auth-rhosts.c:110: warning: implicit declaration of function `innetgr' is there a standard place for the proto for innetgr()? openbsd has ; linux has ; HP-UX doesn't define a prototype at all (i'll submit a defect). btw, unless i'm missing something, i think we want this: --- ../../openssh-2.3.0p1/includes.h Wed Oct 18 02:02:25 2000 +++ includes.h Thu Dec 28 03:55:37 2000 @@ -32,7 +32,6 @@ #include #endif #include -#include #include #include From shorty at debian.org Thu Dec 28 10:05:30 2000 From: shorty at debian.org (Christian Kurz) Date: Thu, 28 Dec 2000 00:05:30 +0100 Subject: scp doesn't have a 'Use non privileged port' switch In-Reply-To: References: <20001227210307.W10650@seteuid.getuid.de> Message-ID: <20001228000530.Q12722@seteuid.getuid.de> On 00-12-27 Pekka Savola wrote: > On Wed, 27 Dec 2000, Christian Kurz wrote: > > and another feature request that I got from a debian user and that I > > think should be included in openssh. Thanks. > > > > |Unlike the 'old' ssh (Package: ssh; Version: 1.2.26-1.2)'s scp > > |openssh's scp does not support the -L option which according to > > |old ssh's manpage does the following: > > > > |> -L Use non privileged port. With this you cannot use > > |> rhosts or rsarhosts authentications, but it can be > > |> used to bypass some firewalls that dont allow privi? > > |> leged source ports to pass. Same as saying "-o > > |> UsePriviledgePort=no" or -P to ssh; -L is used due > > |> to exhaustion of suitable letters. > > > As mentioned, use 'scp -o "UsePrivilegedPort=no"' or add the option to > ssh_config or .ssh/config. > IIRC there's no intention of bloating scp with all kinds of options when > you can pass them directly to ssh with -o (this was the argument with scp > -2 option, at least). Thanks, just wanted to ask here, before adding a small note about this to the README in our debian package. Thanks. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001228/d02e8d7c/attachment.bin From stevesk at pobox.com Thu Dec 28 14:09:07 2000 From: stevesk at pobox.com (Kevin Steves) Date: Thu, 28 Dec 2000 04:09:07 +0100 (CET) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: Message-ID: On Wed, 27 Dec 2000 mouring at etoh.eviladmin.org wrote: : Is there any undisputed patches still out not applied to the current : portable CVS tree? not a patch per se but proto 2 is broken on hp-ux due to the issue with the SIGCHLD handler being reinstalled before a wait(). From djm at mindrot.org Thu Dec 28 14:15:50 2000 From: djm at mindrot.org (Damien Miller) Date: Thu, 28 Dec 2000 14:15:50 +1100 (EST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: Message-ID: On Thu, 28 Dec 2000, Kevin Steves wrote: > On Wed, 27 Dec 2000 mouring at etoh.eviladmin.org wrote: > : Is there any undisputed patches still out not applied to the current > : portable CVS tree? > > not a patch per se but proto 2 is broken on hp-ux due to the issue with > the SIGCHLD handler being reinstalled before a wait(). Does the hang with background processes problem exist on HPUX? -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From stevesk at pobox.com Thu Dec 28 14:33:18 2000 From: stevesk at pobox.com (Kevin Steves) Date: Thu, 28 Dec 2000 04:33:18 +0100 (CET) Subject: PAM configuration (HP-UX pam) In-Reply-To: Message-ID: On Wed, 27 Dec 2000, Alan Millar wrote: : FWIW, HP-UX 11.0 uses pam, included as part of the OS from HP. I don't : know how far it varies from the current Linux or Solaris pam : implementations. Not being very versed in pam myself, it appears to me : that it matches Solaris pam a little closer than Linux, definitely : compared to current Linux work. In compiling mod_auth_pam for Apache : on HP-UX 11.0, a few ifdef's were needed that matched the Solaris ones. : : HP-UX 11 uses /etc/pam.conf. The pam_cracklib, pam_nologin and : pam_limits modules are not included with the HP distribution. I have : not looked into whether people are adding them after-the-fact or not. : : I have heard that some people [are attempting to?] use Linux pam ported : to HP-UX 10.20, which didn't have universal pam support from HP, but I : don't know any details. : : For better or for worse, if the OpenSSH install looks for /etc/pam.d, it : will bypass any HP-UX 11.0 compatibility issues :-) when i asked i was told that hp pam was originally ported from sun code, presumably for 10.0. 10.X had limited pam support, which was used by CDE. 11.X supports the pam api for other applications and pam is used by the standard login services (login, ftpd, su, etc). sshd works out-of-the-box on 11.X with pam via the ``other'' service entries in the default /etc/pam.conf. From mouring at etoh.eviladmin.org Thu Dec 28 17:28:47 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 28 Dec 2000 00:28:47 -0600 (CST) Subject: implicit declaration warnings In-Reply-To: Message-ID: On Thu, 28 Dec 2000, Kevin Steves wrote: > On Wed, 27 Dec 2000, Pekka Savola wrote: > : auth-rhosts.c:110: warning: implicit declaration of function `innetgr' > > is there a standard place for the proto for innetgr()? openbsd has > ; linux has ; HP-UX doesn't define a prototype at > all (i'll submit a defect). > > btw, unless i'm missing something, i think we want this: > Hmm.. That would explain a minor patch I had to apply long ago for the other reference to netdb.h. It'd included twice, and older systems like NeXT really hate that. - Ben From mdejong at cygnus.com Thu Dec 28 16:31:24 2000 From: mdejong at cygnus.com (Mo DeJong) Date: Wed, 27 Dec 2000 21:31:24 -0800 (PST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: Message-ID: On Wed, 27 Dec 2000 mouring at etoh.eviladmin.org wrote: > : Is there any undisputed patches still out not applied to the current > : portable CVS tree? I am still wondering about my patch to remove the fixpaths perl script and replace it with a sed script (it fixes the build under Cygwin). I am not sure if it is "undisputed" since I don't remember hearing anything back. I have appended it to this email in case it got lost in the shuffle. Mo DeJong Red Hat Inc Index: Makefile.in =================================================================== RCS file: /cvs/openssh_cvs/Makefile.in,v retrieving revision 1.127 diff -u -r1.127 Makefile.in --- Makefile.in 2000/12/27 05:44:51 1.127 +++ Makefile.in 2000/12/28 05:30:27 @@ -25,6 +25,7 @@ RANLIB=@RANLIB@ INSTALL=@INSTALL@ PERL=@PERL@ +SED=@SED@ ENT=@ENT@ XAUTH_PATH=@XAUTH_PATH@ LDFLAGS=-L. @LDFLAGS@ @@ -50,20 +51,20 @@ CONFIGFILES=sshd_config ssh_config primes PATHSUBS = \ - -D/etc/ssh_config=$(sysconfdir)/ssh_config \ - -D/etc/ssh_known_hosts=$(sysconfdir)/ssh_known_hosts \ - -D/etc/sshd_config=$(sysconfdir)/sshd_config \ - -D/usr/libexec=$(libexecdir) \ - -D/etc/shosts.equiv=$(sysconfdir)/shosts.equiv \ - -D/etc/ssh_host_key=$(sysconfdir)/ssh_host_key \ - -D/etc/ssh_host_dsa_key=$(sysconfdir)/ssh_host_dsa_key \ - -D/etc/ssh_host_rsa_key=$(sysconfdir)/ssh_host_rsa_key \ - -D/var/run/sshd.pid=$(piddir)/sshd.pid \ - -D/etc/primes=$(sysconfdir)/primes \ - -D/etc/sshrc=$(sysconfdir)/sshrc \ - -D/usr/X11R6/bin/xauth=$(XAUTH_PATH) + -e 's|/etc/ssh_config|$(sysconfdir)/ssh_config|g' \ + -e 's|/etc/ssh_known_hosts|$(sysconfdir)/ssh_known_hosts|g' \ + -e 's|/etc/sshd_config|$(sysconfdir)/sshd_config|g' \ + -e 's|/usr/libexec|$(libexecdir)|g' \ + -e 's|/etc/shosts.equiv|$(sysconfdir)/shosts.equiv|g' \ + -e 's|/etc/ssh_host_key|$(sysconfdir)/ssh_host_key|g' \ + -e 's|/etc/ssh_host_dsa_key|$(sysconfdir)/ssh_host_dsa_key|g' \ + -e 's|/etc/ssh_host_rsa_key|$(sysconfdir)/ssh_host_rsa_key|g' \ + -e 's|/var/run/sshd.pid|$(piddir)/sshd.pid|g' \ + -e 's|/etc/primes|$(sysconfdir)/primes|g' \ + -e 's|/etc/sshrc|$(sysconfdir)/sshrc|g' \ + -e 's|/usr/X11R6/bin/xauth|$(XAUTH_PATH)|g' -FIXPATHSCMD = $(PERL) $(srcdir)/fixpaths $(PATHSUBS) +FIXPATHSCMD = $(SED) $(PATHSUBS) all: $(TARGETS) $(CONFIGFILES) @@ -111,7 +112,7 @@ $(LD) -o $@ logintest.o $(LDFLAGS) loginrec.o -lopenbsd-compat -lssh log-client.o $(LIBS) $(MANPAGES) $(CONFIGFILES):: - $(FIXPATHSCMD) $(srcdir)/$@ + $(FIXPATHSCMD) $(srcdir)/$@ > $@.out clean: rm -f *.o *.a $(TARGETS) logintest config.cache config.log Index: configure.in =================================================================== RCS file: /cvs/openssh_cvs/configure.in,v retrieving revision 1.209 diff -u -r1.209 configure.in --- configure.in 2000/12/28 00:07:07 1.209 +++ configure.in 2000/12/28 05:30:27 @@ -10,6 +10,7 @@ AC_PROG_INSTALL AC_CHECK_PROG(AR, ar, ar) AC_PATH_PROG(PERL, perl) +AC_PATH_PROG(SED, sed) AC_SUBST(PERL) AC_PATH_PROG(ENT, ent) AC_SUBST(ENT) From mouring at etoh.eviladmin.org Thu Dec 28 17:40:39 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 28 Dec 2000 00:40:39 -0600 (CST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: Message-ID: On Wed, 27 Dec 2000, Mo DeJong wrote: > On Wed, 27 Dec 2000 mouring at etoh.eviladmin.org wrote: > > > : Is there any undisputed patches still out not applied to the current > > : portable CVS tree? > > I am still wondering about my patch to remove the fixpaths > perl script and replace it with a sed script (it fixes the build > under Cygwin). I am not sure if it is "undisputed" since I > don't remember hearing anything back. I have appended it > to this email in case it got lost in the shuffle. > Unless one of the other commiters signs off on it. I prefer to know it works on all platforms. sed is known to have a lot of strange quarks on some platforms (solaris being one of them). Where perl does not. I'll be trying it on NeXT as soon as I finish bring NeXT back into the fold of working platforms. Granted, I still want to know how you install OpenSSL from source without perl.=) - Ben From pekkas at netcore.fi Thu Dec 28 18:12:32 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 28 Dec 2000 09:12:32 +0200 (EET) Subject: implicit declaration warnings In-Reply-To: Message-ID: On Thu, 28 Dec 2000, Kevin Steves wrote: > On Wed, 27 Dec 2000, Pekka Savola wrote: > : auth-rhosts.c:110: warning: implicit declaration of function `innetgr' > > is there a standard place for the proto for innetgr()? openbsd has > ; linux has ; HP-UX doesn't define a prototype at > all (i'll submit a defect). > > btw, unless i'm missing something, i think we want this: Doesn't help. However, 'grep -i -r innetgr /usr/include/*' on FreeBSD shows nothing. Some other declarations, like getnetgrent are missing too. I take it the system just has incomplete headers or something (innetgr is in netdb.h on Linux). > --- ../../openssh-2.3.0p1/includes.h Wed Oct 18 02:02:25 2000 > +++ includes.h Thu Dec 28 03:55:37 2000 > @@ -32,7 +32,6 @@ > #include > #endif > #include > -#include > > #include > #include > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From shorty at debian.org Thu Dec 28 18:02:00 2000 From: shorty at debian.org (Christian Kurz) Date: Thu, 28 Dec 2000 08:02:00 +0100 Subject: PrintLastLog option is not honored In-Reply-To: References: <20001227235656.A3372@bofh.de> Message-ID: <20001228080200.S12722@seteuid.getuid.de> On 00-12-27 mouring at etoh.eviladmin.org wrote: > On Wed, 27 Dec 2000, Christian Kurz wrote: > > On 00-12-28 Pekka Savola wrote: > > > On Wed, 27 Dec 2000, Christian Kurz wrote: > > > > here's another bug report against openssh with a patch included (from > > > > the same person who submitted the bug report). Would you please apply > > > > it? Thanks! > > > > > Umm.. There is no print_lastlog option in OpenSSH base/portable. > > > Perhaps you should supply the actual patch too ;-) > > > > Thanks, I just noticed that I wonder where this patch is coming from. > > Damn it's getting late. I should better go to bed know, but could this > > be the patch for LastLog: > > > Still an incomplete and broken patch. If the person who originally > submitted it wants to write a complete patch and submit it. Then we would > be happy to debate if it will be included. Hm, either this was something that was in the 1.2-releases of openssh or it seems like it has something to do with PAM. I will look into this later today. Thanks for your help. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001228/6a641d1a/attachment.bin From shorty at getuid.de Thu Dec 28 18:25:10 2000 From: shorty at getuid.de (Christian Kurz) Date: Thu, 28 Dec 2000 08:25:10 +0100 Subject: patch to support hurd-i386 In-Reply-To: References: <20001227234758.N12722@seteuid.getuid.de> Message-ID: <20001228082510.W12722@seteuid.getuid.de> On 00-12-27 mouring at etoh.eviladmin.org wrote: > On Wed, 27 Dec 2000, Christian Kurz wrote: > > here's a patch so that ssh also supports hurd-i386. Thanks for > > incorporating. The patch comes from Robert Bihlmeyer . > > > > > openssh 2.2.0p1-1.1 does not build on the Hurd. The appended patch > > > fixes that. Changes in detail: > > > > > * PAM is not (yet?) supported, so the PAM dependencies are only put into > > > the control file on architectures != hurd-i386. > > > > > * Hurd has no random device, therefore /etc/ssh/ssh_prng_conf is needed. > > > Added to conffiles. > > > > > * Do not try to generate a hostkey while building the package. This is > > > useless, and it will fail on the Hurd if ssh is not yet installed. > > > "make install" should alway check if it should generate hostkeys. The > package manager should not be calling 'make install' unless it's doing a > test run (via -n). Also in the most recent CVS tree all ssh-keygen are > relative to the make directory. Well, we will try to fix this bug as good as possible in our packaging building system. I'm mostly concerned about the other patches that hurd needs. > > > * Hurd has no MAXHOSTNAME. Two instances replaced by fixed limit, where > > > only the first N bytes were used, anyway. Two more instances replaced > > > by a grow-until-fits loop. > > > HURD does not have MAXHOSTNAME?! They must have removed it from the MACH > header files or NeXTStep added it. I would want to know Markus' view on > that aspect of the patch. I find it overly complex (besides the fact > we have xmalloc() and xrealloc() to handle the null returns that should > fail using fatal()). I see one or two nice things suggestions in the > patch. I think they may want to consider either defining MAXHOSTNAME > (because it's used by a lot of software) or we can test and set a limit if > there is none. Well, that's why I forwarded it to you guys, to first here your opinion and maybe talk with the author of the patch about it, before applying it to our debian package of ssh or incorporating it into the CVS of openssh. Ciao Christian -- While the year 2000 (y2k) problem is not an issue for us, all Linux implementations will impacted by the year 2038 (y2.038k) issue. The Debian Project is committed to working with the industry on this issue and we will have our full plans and strategy posted by the first quarter of 2020. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001228/509cbeeb/attachment.bin From shorty at getuid.de Thu Dec 28 18:27:16 2000 From: shorty at getuid.de (Christian Kurz) Date: Thu, 28 Dec 2000 08:27:16 +0100 Subject: Incorrect shell quotation in scp In-Reply-To: <20001227210306.B31685@traad.dhs.org> References: <20001227201645.L10650@seteuid.getuid.de> <20001227210306.B31685@traad.dhs.org> Message-ID: <20001228082716.X12722@seteuid.getuid.de> On 00-12-27 Stian Soiland wrote: > On 2000-12-27 20:16:45+0100, Christian Kurz wrote: > >as the current debian maintainer of the openssh package is a bit busy, > >I'm helping him with fixing a part of the bugs in openssh that debian > >users found will forward some of the reports to you. This is the first > >one and a fix or a comment why this should not be fixed would be > >appropriated. Thanks > >Space in filename is not correctly passed by scp to other invoked > >programs: > I supplied a patch for this problem two weeks ago. The patch is still > uncommented on the list, and not taken into the CVS, but it really > works great. Here goes: > http://stain.portveien.to/diverse/scp/ > The problem resides in missing quotation of commands from scp to ssh. > This patch should fix this. Well, as I don't want to have to extra patches for the openssh package, I would prefer if either your patch will be taken into CVS or the developers come up with a better patch. > (and, yes, you might as well change the same lines in the > woody-version. :) ) Oh you are a debian user? :) Ciao Christian -- While the year 2000 (y2k) problem is not an issue for us, all Linux implementations will impacted by the year 2038 (y2.038k) issue. The Debian Project is committed to working with the industry on this issue and we will have our full plans and strategy posted by the first quarter of 2020. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001228/1ae1a85c/attachment.bin From shorty at debian.org Thu Dec 28 18:32:28 2000 From: shorty at debian.org (Christian Kurz) Date: Thu, 28 Dec 2000 08:32:28 +0100 Subject: sshd and pam_env both read /etc/environment, but assume different syntax Message-ID: <20001228083228.Z12722@seteuid.getuid.de> Morning, and that's the next bugreport that I have to forward you, because the fix should be applied in the upstream sources. Thanks. > sshd (in ssh 1:1.2.3-9) in its default configuration reads > /etc/environment file twice when a user logs in: first, it is > read through pam_env module of PAM (due to the configuration > in /etc/pam.d/ssh), and then by `read_environment_file()' > function of `sshd.c' itself. > The real problem is that the syntax of /etc/environment > assumed by these are slightly different (as of pam-modules > 0.72-9 and ssh 1:1.2.3-9); for example, pam_env supports > Bourne shell-like `export' prefix and quoting (surrounding > quotes are removed), which are not handled by sshd.c. > It follows that the resulting environments may be different > between ssh and normal login, as the latter relies only upon > pam_env for setting up the system-wide default environment. > For consistency, it would be nice if the reading of > /etc/environment is solely handled via pam_env in sshd as well, > just like normal login process. > I'm attaching below a small patch against sshd.c for this purpose. > Even if the ssh maintainer somehow does not like changing the > current situation, the manpage of sshd should mention that > the file /etc/environment is used for setting up the ``basic > environment,'' at the least. The present manpage only tells us > $HOME/.ssh/environment is consulted, which gives the users wrong > impression that /etc/environment takes effect only because > /etc/pam.d/ssh has `pam_env' line (and it does not haev `readenv=0' > option). > I asked him now if this bug is still true for newer version and he > confirmed that in 2.2.0p1 the bug is still existing and send a fix: > If you mean (open)ssh 1:2.2.0p1-1.1, yes, it still suffers > from the same problem. > The relevant code is now around line 1116 of openssh-2.2.0p1/session.c. > ---8<---8<--- > #ifdef USE_PAM > /* Pull in any environment variables that may have been set by PAM. */ > do_pam_environment(&env, &envsize); > #endif /* USE_PAM */ > read_environment_file(&env,&envsize,"/etc/environment"); > ---8<---8<--- > The function do_pam_environment() incorporates all the variables defined > by pam_env, but those defined in /etc/environment are later overriden by > read_environment_file() function. > They produce different results if the value of a variable had > quotes or `#' character in it, or if the definition was prefixed with > `export'. > It's easy to see how sshd sets environment by starting sshd with -d flag. > I think the problem (in part, if not all) comes from the lack of > policy in Debian on the use (and the format) of /etc/environment file. So would you agree that this is a valid bug that should be fixed or do you also think that this is a flaw in debian? Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001228/2879eced/attachment.bin From mouring at etoh.eviladmin.org Thu Dec 28 20:12:59 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 28 Dec 2000 03:12:59 -0600 (CST) Subject: sshd prints the motd with -t option In-Reply-To: <20001227231927.I12722@seteuid.getuid.de> Message-ID: Using their examples I can not replicate this using the current CVS tree. - Ben On Wed, 27 Dec 2000, Christian Kurz wrote: > Hi, > > and another interesting bug report, where I'm not sure what the correct > behaviour of openssh should be. Thanks for your comments: > > > I find myself frequently using OpenSSH to log in and perform a single > > command (particularly in a script to perform some quick, simple task on > > multiple machines I administer). If the '-t' option is not included, the > > behavior is no different than with the non-OpenSSH ssh inplementation. > > However, this causes problems when I need to enter a password for, say, > > sudo; the password is echoed back to the screen and the command fails. If > > instead I enter 'ssh -t user at host command', sudo and others will work > > properly, but the motd is printed as well. This adds significantly to the > > output to be human-parsed and makes it more difficult to discern what > > output came from which machine, as well as being different from the > > original ssh and ssh2 implementations. Here is some sample output; first, > > an example of performing a command on a host running the original ssh > > implementation: > > |bj at host01:~$ ssh host00 ls / > |Warning: Server lies about size of server host key: actual size is 1023 > |bits vs. > | announced 1024. > |Warning: This may be due to an old implementation of ssh. > |bj at host00.do.main's password: > |bin > |boot > |cdrom > |dev > |etc > |floppy > |home > |initrd > |lib > |lost+found > |mnt > |proc > |root > |sbin > |tmp > |usr > |var > |vmlinuz > |vmlinuz.old > |bj at host01:~$ ssh -t host00 ls / > |Warning: Server lies about size of server host key: actual size is 1023 > |bits vs. announced 1024. > |Warning: This may be due to an old implementation of ssh. > |bj at host00.do.main's password: > |bin etc lib root var > |boot floppy lost+found sbin vmlinuz > |cdrom home mnt tmp vmlinuz.old > |dev initrd proc usr > |Connection to host00.do.main closed. > |bj at host01:~$ > > |Next, connecting to a host running OpenSSH's sshd: > |bj at host00:~$ ssh host01 ls / > |bj at host01's password: > |bin > |boot > |cdrom > |dev > |etc > |floppy > |home > |home.delete > |initrd > |lib > |lost+found > |mnt > |proc > |root > |sbin > |storage > |tmp > |usr > |var > |vmlinuz > |vmlinuz.old > |bj at host00:~$ ssh -t host01 ls / > |bj at host01's password: > |Last login: Sat Aug 12 18:20:18 2000 from some.host.do.main on pts/1 > |Linux host01 2.2.5 #2 Wed May 24 19:31:11 EDT 2000 i686 unknown > > |Most of the programs included with the Debian GNU/Linux system are > |freely redistributable; the exact distribution terms for each program > |are described in the individual files in /usr/doc/*/copyright > > |Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent > |permitted by applicable law. > |You have new mail. > |bin dev home lib proc storage var > |boot etc home.delete lost+found root tmp vmlinuz > |cdrom floppy initrd mnt sbin usr vmlinuz.old > |Connection to host01 closed. > |bj at host00:~$ > > |host00 is a slink system running the older implementation of ssh, and > |host01 is a potato system running OpenSSH. > > |I would like to suggest that OpenSSH be modified to suppress printing the > |motd if the -t option is used and it is a non-login session, ie, the > |connection is opened for command processing only. > > |bj at host00:~$ grep PrintMotd /etc/ssh/sshd_config > |PrintMotd yes > > |bj at host01:~$ grep PrintMotd /etc/ssh/sshd_config > |PrintMotd no > > Ciao > Christian > From vinschen at redhat.com Thu Dec 28 19:51:50 2000 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 28 Dec 2000 09:51:50 +0100 Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Dec 28, 2000 at 12:40:39AM -0600 References: Message-ID: <20001228095150.G11368@cygbert.vinschen.de> On Thu, Dec 28, 2000 at 12:40:39AM -0600, mouring at etoh.eviladmin.org wrote: > On Wed, 27 Dec 2000, Mo DeJong wrote: > > I am still wondering about my patch to remove the fixpaths > > perl script and replace it with a sed script (it fixes the build > > under Cygwin). I am not sure if it is "undisputed" since I > > don't remember hearing anything back. I have appended it > > to this email in case it got lost in the shuffle. > > Unless one of the other commiters signs off on it. I prefer to know it > works on all platforms. sed is known to have a lot of strange quarks on > some platforms (solaris being one of them). Where perl does not. > > I'll be trying it on NeXT as soon as I finish bring NeXT back into the > fold of working platforms. > > Granted, I still want to know how you install OpenSSL from source without > perl.=) With the help of an external contributed perl. Anyway, perl is now becoming part of the Cygwin base distro so this shouldn't be an issue anymore. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From mdejong at cygnus.com Thu Dec 28 20:13:58 2000 From: mdejong at cygnus.com (Mo DeJong) Date: Thu, 28 Dec 2000 01:13:58 -0800 (PST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: <20001228095150.G11368@cygbert.vinschen.de> Message-ID: On Thu, 28 Dec 2000, Corinna Vinschen wrote: > On Thu, Dec 28, 2000 at 12:40:39AM -0600, mouring at etoh.eviladmin.org wrote: > > On Wed, 27 Dec 2000, Mo DeJong wrote: > > > I am still wondering about my patch to remove the fixpaths > > > perl script and replace it with a sed script (it fixes the build > > > under Cygwin). I am not sure if it is "undisputed" since I > > > don't remember hearing anything back. I have appended it > > > to this email in case it got lost in the shuffle. > > > > Unless one of the other commiters signs off on it. I prefer to know it > > works on all platforms. sed is known to have a lot of strange quarks on > > some platforms (solaris being one of them). Where perl does not. > > > > I'll be trying it on NeXT as soon as I finish bring NeXT back into the > > fold of working platforms. > > > > Granted, I still want to know how you install OpenSSL from source without > > perl.=) > > With the help of an external contributed perl. > > Anyway, perl is now becoming part of the Cygwin base distro so this > shouldn't be an issue anymore. > > Corinna I disagree. Even if/when perl is added to the base Cygwin distro, it is still an issue. What if folks decide to skip the perl module? For the matter, what about all the Unix systems that ship without perl? Why should someone need to install perl just to build a package? There is a good reason autoconf is written using sh scripts. It runs in many places without having to download a bunch of extra things. It is just a bad idea to require a lot of additional tools on the build machine. It is fine if you require them on the developers machine. Automake is written in perl, but it outputs a Makefile.in that can be used to build on a system without perl. This is the kind of thing that does not seem too important when you are the developer with a perfectly configured machine. It is quite another story when you are the poor sap that needs to install 15 extra packages just to get something to build on some strango system. I think a quote from Mrs. Lovejoy says it best: "Won't someone please think of the children!" Mo DeJong Red Hat Inc From vinschen at redhat.com Thu Dec 28 20:33:01 2000 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 28 Dec 2000 10:33:01 +0100 Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: ; from mdejong@cygnus.com on Thu, Dec 28, 2000 at 01:13:58AM -0800 References: <20001228095150.G11368@cygbert.vinschen.de> Message-ID: <20001228103301.H11368@cygbert.vinschen.de> On Thu, Dec 28, 2000 at 01:13:58AM -0800, Mo DeJong wrote: > On Thu, 28 Dec 2000, Corinna Vinschen wrote: > > On Thu, Dec 28, 2000 at 12:40:39AM -0600, mouring at etoh.eviladmin.org wrote: > > > Granted, I still want to know how you install OpenSSL from source without > > > perl.=) > > > > With the help of an external contributed perl. > > > > Anyway, perl is now becoming part of the Cygwin base distro so this > > shouldn't be an issue anymore. > > I disagree. Even if/when perl is added to the base Cygwin > distro, it is still an issue. What if folks decide to skip > the perl module? Good question. What if folks decide to skip gcc, binutils, ... That's no joke. Folks already do this. > I think a quote from Mrs. Lovejoy says it best: > "Won't someone please think of the children!" We _are_ thinking of the children. What other reason do adults have when releasing a binary distribution? Nobody is forced to compile anything from the base distro (including OpenSSL and OpenSSH) by himself. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From shorty at debian.org Thu Dec 28 21:30:29 2000 From: shorty at debian.org (Christian Kurz) Date: Thu, 28 Dec 2000 11:30:29 +0100 Subject: sshd prints the motd with -t option In-Reply-To: References: <20001227231927.I12722@seteuid.getuid.de> Message-ID: <20001228113029.A6830@bofh.de> On 00-12-28 mouring at etoh.eviladmin.org wrote: > Using their examples I can not replicate this using the current CVS tree. Thanks, then I can mark this bug as fixed, as I will update our openssh package to version 2.3.0p1 which should not be to different from the behaviour of openssh from CVS, but I will check this before. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 From shorty at debian.org Thu Dec 28 21:38:43 2000 From: shorty at debian.org (Christian Kurz) Date: Thu, 28 Dec 2000 11:38:43 +0100 Subject: Information leakage in sshd Message-ID: <20001228113843.C6830@bofh.de> Hi guys, and here's a security related bug report. I think it's has been fixed in the 2.2.x-release of openssh, but I'm not sure. I tried to reproduce the problem with my 2.2.0p1 and could find any difference in the behaviour of ssh depending on wether PermitRootLogin was set to no. Could someone please confirm that this problem is not existing anymore? > When PermitRootLogin is set to no in /etc/ssh/sshd_config it should not > be possible to determine whether a root password is correct remotely. > However sshd behaves differently depending on whether the password is > correct. > host% ssh root at localhost > root at localhost's password: [typed the correct password] > Received disconnect: ROOT LOGIN REFUSED FROM localhost > host% ssh root at localhost > root at localhost's password: [typed an incorrect password] > [pauses a second, then prints:] > Permission denied, please try again. Thanks for all your feedback and your great work. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 From bk at rt.fm Thu Dec 28 22:12:49 2000 From: bk at rt.fm (Brian Kifiak) Date: Thu, 28 Dec 2000 05:12:49 -0600 Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: ; from mdejong@cygnus.com on Thu, Dec 28, 2000 at 01:13:58AM -0800 References: <20001228095150.G11368@cygbert.vinschen.de> Message-ID: <20001228051249.A30382@rt.fm> > For the matter, what about all the Unix systems that ship without > perl? (large?) case in point: netbsd. > There is a good reason autoconf is written using sh scripts. good example. i believe the question is ``is perl standard?'' i don't think it is. i don't think it should be. perhaps i'm in minority. Ben (Mouring?) writes: > I prefer to know it works on all platforms. i don't think it currently works on all platforms. see above. > Granted, I still want to know how you install OpenSSL from source > without perl. if enough people believe that perl shouldn't be a requirement of openssh, perhaps the openssl group needs a push as well. i'd at least hope that a ``without perl'' option would be available. further, such an option could be used as a fallback if perl isn't found. From djm at mindrot.org Thu Dec 28 22:48:10 2000 From: djm at mindrot.org (Damien Miller) Date: Thu, 28 Dec 2000 22:48:10 +1100 (EST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: <20001228051249.A30382@rt.fm> Message-ID: On Thu, 28 Dec 2000, Brian Kifiak wrote: > > For the matter, what about all the Unix systems that ship without > > perl? > > (large?) case in point: netbsd. NetBSD has their own port. > > There is a good reason autoconf is written using sh scripts. > > good example. > > i believe the question is ``is perl standard?'' > > i don't think it is. i don't think it should be. perhaps i'm in > minority. You need perl to build OpenSSL which is required anyway. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From markus.friedl at informatik.uni-erlangen.de Thu Dec 28 23:22:21 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 28 Dec 2000 13:22:21 +0100 Subject: scp and filenames with weird characters In-Reply-To: <20001212181236.B20966@traad.dhs.org>; from stain@nvg.org on Tue, Dec 12, 2000 at 06:12:37PM +0100 References: <20001212181236.B20966@traad.dhs.org> Message-ID: <20001228132221.E27359@folly> On Tue, Dec 12, 2000 at 06:12:37PM +0100, Stian Soiland wrote: > - "%s%s -x -o'FallBackToRsh no' -n -l %s %s %s %s '%s%s%s:%s'", > + "%s%s -x -o'FallBackToRsh no' -n -l > \"%s\" \"%s\" \"%s\"\"%s\" '%s%s%s:%s'", not every shell uses " for quotes, some use ' only. From markus.friedl at informatik.uni-erlangen.de Thu Dec 28 23:31:37 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 28 Dec 2000 13:31:37 +0100 Subject: Information leakage in sshd In-Reply-To: <20001228113843.C6830@bofh.de>; from shorty@debian.org on Thu, Dec 28, 2000 at 11:38:43AM +0100 References: <20001228113843.C6830@bofh.de> Message-ID: <20001228133137.F27359@folly> this has been fixed 2000/03/09. On Thu, Dec 28, 2000 at 11:38:43AM +0100, Christian Kurz wrote: > Hi guys, > > and here's a security related bug report. I think it's has been fixed in > the 2.2.x-release of openssh, but I'm not sure. I tried to reproduce the > problem with my 2.2.0p1 and could find any difference in the behaviour > of ssh depending on wether PermitRootLogin was set to no. Could someone > please confirm that this problem is not existing anymore? > > > When PermitRootLogin is set to no in /etc/ssh/sshd_config it should not > > be possible to determine whether a root password is correct remotely. > > However sshd behaves differently depending on whether the password is > > correct. > > > host% ssh root at localhost > > root at localhost's password: [typed the correct password] > > Received disconnect: ROOT LOGIN REFUSED FROM localhost > > > host% ssh root at localhost > > root at localhost's password: [typed an incorrect password] > > [pauses a second, then prints:] > > Permission denied, please try again. > > Thanks for all your feedback and your great work. > > Ciao > Christian > -- > Debian Developer and Quality Assurance Team Member > 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 > From shorty at debian.org Fri Dec 29 00:07:15 2000 From: shorty at debian.org (Christian Kurz) Date: Thu, 28 Dec 2000 14:07:15 +0100 Subject: sshd doesn't log which RSA key was used Message-ID: <20001228140715.A7582@bofh.de> Hi guys, and another feature request for sshd which I would classify as really useful. And I think this behaviour is currently not available (If yes, sorry, I must have missed it): > I believe that the sshd should log which RSA key was used to connect to > an account. When there are a number of keys in the authorized_keys file > it is often useful to know which one was used for each login. I have > been looking at the code for this but have not been able to determine > where to add this. The problem is that the authentication is done by > number only. It seems that the best way to make it work the way I want > would be to use a "struct Key" type all through the authentication > process. But I have been getting lost in the code. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 From shorty at debian.org Fri Dec 29 00:21:34 2000 From: shorty at debian.org (Christian Kurz) Date: Thu, 28 Dec 2000 14:21:34 +0100 Subject: COMPATIBILITY: AllowHosts/DenyHosts/SilentDeny not supported Message-ID: <20001228142134.A7723@bofh.de> Hi, here's another feature request that I just found and where I would like to hear your comments first: > The above commands are valid ssh-nonfree, but openssh doesn't like them. The > first two are important for security conscious sites. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 From shorty at debian.org Fri Dec 29 00:23:49 2000 From: shorty at debian.org (Christian Kurz) Date: Thu, 28 Dec 2000 14:23:49 +0100 Subject: ssh: doesn't live well with user-group system Message-ID: <20001228142349.B7723@bofh.de> Hi, and that's another feature request. Sorry if it looks like some kind of spamming, but our current maintainer was very stressed in the past and had not time to forward those reports to you and now I help him a bit out. So thanks for your patience and answering of all my mails with bugreport and feature-reqeust. > Debian by default uses the user-group system. Each user has their own > group. 002 is a reasonable umask to decide to use if you are using the > user-group system. (It's hardly the only choice, but it is a valid choice.) > However, ssh is excessivly paranoid about files that are owned by a group, > even if that group is a user-group. > host: Remote: Bad file modes for /home/joey/.ssh/authorized_keys > host: Server refused our key. > user at host:~/.ssh>ls -l authorized_keys > -rw-rw-r-- 1 user user 988 Jan 4 12:16 authorized_keys > There is nothing "bad" about that file mode. > My wishlist is that ssh have an option to make it accept files that are > group writable. Call it anything you want, even > "allow-insecure-file-group-modes", I don't particularly care.. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 From shorty at debian.org Fri Dec 29 00:26:41 2000 From: shorty at debian.org (Christian Kurz) Date: Thu, 28 Dec 2000 14:26:41 +0100 Subject: Error in sshd's manpage Message-ID: <20001228142641.C7723@bofh.de> Hi, I just confirmed this bug for openssh 2.2.0p1. Could you please fix this upstream? Thanks. > The manpage for sshd lists the option 'PrintLastLogin' as being enabled by > default, but in fact the option is called 'PrintLastLog'. I encountered > this problem when upgrading, after customizing my sshd_config file, and not > accepting the Debian version upon upgrade of the ssh package. Also, this > manpage seems to imply that the 'PrintLastLog' option has the states of > yes/off instead of yes/no. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 From shorty at debian.org Fri Dec 29 00:31:14 2000 From: shorty at debian.org (Christian Kurz) Date: Thu, 28 Dec 2000 14:31:14 +0100 Subject: Might want to allow different host keys for different ports on same host Message-ID: <20001228143114.E7723@bofh.de> Hi, and here's the next feature request, which sounds interesting. Also I think I won't need much extra code to add this feature. So what do you guys think? > `ssh' with its host key checking is incompatible with the use of > `redir' to map different ports on a gateway/firewall system to > different systems behind the firewall. > For instance, I redirect ports as follows: > |-----------------| > | fw.somesite.com | > |-----------------| > -> | port 2224 | -> (port 22) internalhost1.somesite.com > Internet -> | port 2223 | -> (port 22) internalhost2.somesite.com > -> | port 2222 | -> (port 22) internalhost3.somesite.com > |-----------------| > In this case, the following three commands end up on different hosts: > ssh -p 2224 fw.somesite.com > ssh -p 2223 fw.somesite.com > ssh -p 2222 fw.somesite.com > Thus, there are different host keys, which leads `ssh' to believe that > the host key has been altered between sessions. > Would it be possible to save both host/IP as well as portnumber as > keys in the 'known_hosts' file? Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 From markus.friedl at informatik.uni-erlangen.de Fri Dec 29 00:34:24 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 28 Dec 2000 14:34:24 +0100 Subject: Error in sshd's manpage In-Reply-To: <20001228142641.C7723@bofh.de>; from shorty@debian.org on Thu, Dec 28, 2000 at 02:26:41PM +0100 References: <20001228142641.C7723@bofh.de> Message-ID: <20001228143424.A10071@folly> $ grep -i lastlog * does not match a single file. On Thu, Dec 28, 2000 at 02:26:41PM +0100, Christian Kurz wrote: > Hi, > > I just confirmed this bug for openssh 2.2.0p1. Could you please fix this > upstream? Thanks. > > > The manpage for sshd lists the option 'PrintLastLogin' as being enabled by > > default, but in fact the option is called 'PrintLastLog'. I encountered > > this problem when upgrading, after customizing my sshd_config file, and not > > accepting the Debian version upon upgrade of the ssh package. Also, this > > manpage seems to imply that the 'PrintLastLog' option has the states of > > yes/off instead of yes/no. > > Ciao > Christian > -- > Debian Developer and Quality Assurance Team Member > 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 > From markus.friedl at informatik.uni-erlangen.de Fri Dec 29 00:36:00 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 28 Dec 2000 14:36:00 +0100 Subject: Might want to allow different host keys for different ports on same host In-Reply-To: <20001228143114.E7723@bofh.de>; from shorty@debian.org on Thu, Dec 28, 2000 at 02:31:14PM +0100 References: <20001228143114.E7723@bofh.de> Message-ID: <20001228143600.B10071@folly> the HostKeyAlias option (added yesterday) can be used for this and similar problems. On Thu, Dec 28, 2000 at 02:31:14PM +0100, Christian Kurz wrote: > Hi, > > and here's the next feature request, which sounds interesting. Also I > think I won't need much extra code to add this feature. So what do you > guys think? > > > `ssh' with its host key checking is incompatible with the use of > > `redir' to map different ports on a gateway/firewall system to > > different systems behind the firewall. > > > For instance, I redirect ports as follows: > > > |-----------------| > > | fw.somesite.com | > > |-----------------| > > -> | port 2224 | -> (port 22) internalhost1.somesite.com > > Internet -> | port 2223 | -> (port 22) internalhost2.somesite.com > > -> | port 2222 | -> (port 22) internalhost3.somesite.com > > |-----------------| > > > > In this case, the following three commands end up on different hosts: > > > ssh -p 2224 fw.somesite.com > > ssh -p 2223 fw.somesite.com > > ssh -p 2222 fw.somesite.com > > > Thus, there are different host keys, which leads `ssh' to believe that > > the host key has been altered between sessions. > > > Would it be possible to save both host/IP as well as portnumber as > > keys in the 'known_hosts' file? > > Ciao > Christian > -- > Debian Developer and Quality Assurance Team Member > 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 > From markus.friedl at informatik.uni-erlangen.de Fri Dec 29 00:38:26 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 28 Dec 2000 14:38:26 +0100 Subject: ssh: doesn't live well with user-group system In-Reply-To: <20001228142349.B7723@bofh.de>; from shorty@debian.org on Thu, Dec 28, 2000 at 02:23:49PM +0100 References: <20001228142349.B7723@bofh.de> Message-ID: <20001228143826.C10071@folly> On Thu, Dec 28, 2000 at 02:23:49PM +0100, Christian Kurz wrote: > > user at host:~/.ssh>ls -l authorized_keys > > -rw-rw-r-- 1 user user 988 Jan 4 12:16 authorized_keys > > > There is nothing "bad" about that file mode. in sshd's view it's "bad" since openssh does not know how many users belong to the group. authorized_keys should not be group writeable. however, you can turn off StrictModes in sshd_config, but this is a bad idea. From jhuuskon at messi.uku.fi Fri Dec 29 00:36:50 2000 From: jhuuskon at messi.uku.fi (Jarno Huuskonen) Date: Thu, 28 Dec 2000 15:36:50 +0200 Subject: Information leakage in sshd In-Reply-To: <20001228113843.C6830@bofh.de>; from shorty@debian.org on Thu, Dec 28, 2000 at 11:38:43AM +0100 References: <20001228113843.C6830@bofh.de> Message-ID: <20001228153650.A2261@laivuri63.uku.fi> On Thu, Dec 28, Christian Kurz wrote: > and here's a security related bug report. I think it's has been fixed in > the 2.2.x-release of openssh, but I'm not sure. I tried to reproduce the > problem with my 2.2.0p1 and could find any difference in the behaviour > of ssh depending on wether PermitRootLogin was set to no. Could someone > please confirm that this problem is not existing anymore? I couldn't reproduce this with openssh-2.3.0p1 ... Here's output: root at localhost's password: Permission denied, please try again. root at localhost's password: Permission denied, please try again. root at localhost's password: Unable to find an authentication method Here I gave the right passwd on first try and incorrect passwd on the 2nd/3rd try. -Jarno -- Jarno Huuskonen - System Administrator | Jarno.Huuskonen at uku.fi University of Kuopio - Computer Centre | Work: +358 17 162822 PO BOX 1627, 70211 Kuopio, Finland | Mobile: +358 40 5388169 From shorty at debian.org Fri Dec 29 00:39:36 2000 From: shorty at debian.org (Christian Kurz) Date: Thu, 28 Dec 2000 14:39:36 +0100 Subject: Error in sshd's manpage In-Reply-To: <20001228143424.A10071@folly> References: <20001228142641.C7723@bofh.de> <20001228143424.A10071@folly> Message-ID: <20001228143936.A7889@bofh.de> On 00-12-28 Markus Friedl wrote: > $ grep -i lastlog * > does not match a single file. I just grabbed the source of the ssh package in debian (which is openssh 2.2.0p1) and if I do this grep in the source-dir, I also find these lines: |sshd.8:.It Cm PrintLastLogin |sshd.pam:session optional pam_lastlog.so # [1] |sshd_config:#PrintLastLog no So, has this option been removed in openssh now or has it been added by some undocumented extra patch? Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 From markus.friedl at informatik.uni-erlangen.de Fri Dec 29 00:40:07 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 28 Dec 2000 14:40:07 +0100 Subject: COMPATIBILITY: AllowHosts/DenyHosts/SilentDeny not supported In-Reply-To: <20001228142134.A7723@bofh.de>; from shorty@debian.org on Thu, Dec 28, 2000 at 02:21:34PM +0100 References: <20001228142134.A7723@bofh.de> Message-ID: <20001228144006.D10071@folly> use /etc/hosts.allow and friends for AllowHosts and DenyHosts SilentDeny is not really needed. openssh does not try to emulate all of the features of the commercial versions. we don't want to bloat openssh. On Thu, Dec 28, 2000 at 02:21:34PM +0100, Christian Kurz wrote: > Hi, > > here's another feature request that I just found and where I would like > to hear your comments first: > > > The above commands are valid ssh-nonfree, but openssh doesn't like them. The > > first two are important for security conscious sites. > > Ciao > Christian > > -- > Debian Developer and Quality Assurance Team Member > 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 > From shorty at debian.org Fri Dec 29 00:40:27 2000 From: shorty at debian.org (Christian Kurz) Date: Thu, 28 Dec 2000 14:40:27 +0100 Subject: Might want to allow different host keys for different ports on same host In-Reply-To: <20001228143600.B10071@folly> References: <20001228143114.E7723@bofh.de> <20001228143600.B10071@folly> Message-ID: <20001228144027.B7889@bofh.de> On 00-12-28 Markus Friedl wrote: > the HostKeyAlias option (added yesterday) > can be used for this and similar problems. That's really good news. Thanks for you work on openssh and for answering my bug reports so fast. :) Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 From shorty at debian.org Fri Dec 29 00:41:48 2000 From: shorty at debian.org (Christian Kurz) Date: Thu, 28 Dec 2000 14:41:48 +0100 Subject: ssh: doesn't live well with user-group system In-Reply-To: <20001228143826.C10071@folly> References: <20001228142349.B7723@bofh.de> <20001228143826.C10071@folly> Message-ID: <20001228144148.C7889@bofh.de> On 00-12-28 Markus Friedl wrote: > On Thu, Dec 28, 2000 at 02:23:49PM +0100, Christian Kurz wrote: > > > user at host:~/.ssh>ls -l authorized_keys > > > -rw-rw-r-- 1 user user 988 Jan 4 12:16 authorized_keys > > > > > There is nothing "bad" about that file mode. > in sshd's view it's "bad" since openssh does not know > how many users belong to the group. > authorized_keys should not be group writeable. > however, you can turn off StrictModes in sshd_config, > but this is a bad idea. Thank you, so I have now some explanation that I can use to close this bug. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 From markus.friedl at informatik.uni-erlangen.de Fri Dec 29 00:44:32 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 28 Dec 2000 14:44:32 +0100 Subject: sshd doesn't log which RSA key was used In-Reply-To: <20001228140715.A7582@bofh.de>; from shorty@debian.org on Thu, Dec 28, 2000 at 02:07:15PM +0100 References: <20001228140715.A7582@bofh.de> Message-ID: <20001228144432.E10071@folly> i am not sure about this feature. you could add a {Key k; k.rsa=pk; k.type=KEY_RSA1; verbose("RSA auth accepted with key %s", key_fingerprint(&k); } to auth_rsa(). On Thu, Dec 28, 2000 at 02:07:15PM +0100, Christian Kurz wrote: > Hi guys, > > and another feature request for sshd which I would classify as really > useful. And I think this behaviour is currently not available (If yes, > sorry, I must have missed it): > > > I believe that the sshd should log which RSA key was used to connect to > > an account. When there are a number of keys in the authorized_keys file > > it is often useful to know which one was used for each login. I have > > been looking at the code for this but have not been able to determine > > where to add this. The problem is that the authentication is done by > > number only. It seems that the best way to make it work the way I want > > would be to use a "struct Key" type all through the authentication > > process. But I have been getting lost in the code. > > Ciao > Christian > -- > Debian Developer and Quality Assurance Team Member > 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 > From markus.friedl at informatik.uni-erlangen.de Fri Dec 29 00:46:19 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 28 Dec 2000 14:46:19 +0100 Subject: patch to support hurd-i386. In-Reply-To: <20001227235120.O12722@seteuid.getuid.de>; from shorty@debian.org on Wed, Dec 27, 2000 at 11:51:20PM +0100 References: <20001227235120.O12722@seteuid.getuid.de> Message-ID: <20001228144619.F10071@folly> 1) IMHO, Hurd should add a definition for MAXHOSTNAMELEN. 2) the patch does not use xmalloc,xrealloc On Wed, Dec 27, 2000 at 11:51:20PM +0100, Christian Kurz wrote: > > Damn, forgot the rest of the patch. Here it comes. > > diff -Nur openssh-2.2.0p1-/ssh-keygen.c openssh-2.2.0p1/ssh-keygen.c > --- openssh-2.2.0p1-/ssh-keygen.c Wed Aug 23 02:46:24 2000 > +++ openssh-2.2.0p1/ssh-keygen.c Sun Oct 29 16:44:50 2000 > @@ -68,7 +68,7 @@ > static const char *__progname = "ssh-keygen"; > #endif /* HAVE___PROGNAME */ > > -char hostname[MAXHOSTNAMELEN]; > +char *hostname; > > void > ask_filename(struct passwd *pw, const char *prompt) > @@ -525,10 +525,24 @@ > printf("You don't exist, go away!\n"); > exit(1); > } > - if (gethostname(hostname, sizeof(hostname)) < 0) { > - perror("gethostname"); > - exit(1); > - } > + { > + size_t size = 100; > + hostname = (char *)malloc(size); > + while (hostname) { > + if (gethostname(hostname, size) >= 0) > + break; > + if (errno != ENAMETOOLONG) { > + perror("gethostname"); > + exit(1); > + } > + size <<= 1; > + hostname = realloc(hostname, size); > + } > + if (hostname == NULL) { > + perror("malloc"); > + exit(1); > + } > + } > > while ((opt = getopt(ac, av, "dqpclRxXyb:f:P:N:C:")) != EOF) { > switch (opt) { > diff -Nur openssh-2.2.0p1-/sshd.c openssh-2.2.0p1/sshd.c > --- openssh-2.2.0p1-/sshd.c Tue Aug 29 02:05:50 2000 > +++ openssh-2.2.0p1/sshd.c Sun Oct 29 16:44:50 2000 > @@ -140,7 +140,7 @@ > int session_id2_len = 0; > > /* record remote hostname or ip */ > -unsigned int utmp_len = MAXHOSTNAMELEN; > +unsigned int utmp_len = 256; /* bigger than LI_HOSTSIZE makes no sense */ > > /* Prototypes for various functions defined later in this file. */ > void do_ssh1_kex(); > > -- > Debian Developer and Quality Assurance Team Member > 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 From shorty at getuid.de Fri Dec 29 00:47:37 2000 From: shorty at getuid.de (Christian Kurz) Date: Thu, 28 Dec 2000 14:47:37 +0100 Subject: COMPATIBILITY: AllowHosts/DenyHosts/SilentDeny not supported In-Reply-To: <20001228144006.D10071@folly> References: <20001228142134.A7723@bofh.de> <20001228144006.D10071@folly> Message-ID: <20001228144737.A8026@bofh.de> On 00-12-28 Markus Friedl wrote: > use /etc/hosts.allow and friends for AllowHosts and DenyHosts > SilentDeny is not really needed. Thanks for the statement. > openssh does not try to emulate all of the features of the > commercial versions. we don't want to bloat openssh. I had something like that in mind, as I track this list now for quite a time. But this are some feature request, where I prefer to get first a statement from you, before I tell the user, that it won't be included. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 From gert at greenie.muc.de Fri Dec 29 01:54:59 2000 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 28 Dec 2000 15:54:59 +0100 Subject: scp and filenames with weird characters In-Reply-To: <20001228132221.E27359@folly>; from Markus Friedl on Thu, Dec 28, 2000 at 01:22:21PM +0100 References: <20001212181236.B20966@traad.dhs.org> <20001228132221.E27359@folly> Message-ID: <20001228155459.A531@greenie.muc.de> Hi, On Thu, Dec 28, 2000 at 01:22:21PM +0100, Markus Friedl wrote: > > - "%s%s -x -o'FallBackToRsh no' -n -l %s %s %s %s '%s%s%s:%s'", > > + "%s%s -x -o'FallBackToRsh no' -n -l > > \"%s\" \"%s\" \"%s\"\"%s\" '%s%s%s:%s'", > > not every shell uses " for quotes, some use ' only. For all shells that I've tested so far, " and ' are equivalent in the context of "quoting is used to preserve blanks in arguments" (sh and all compatibles, csh, zsh). The main difference between these is whether variables ("$foo") are expanded or not. So single quotes might be a better choice to avoid surprises with '$' in file names. gert -- Gert Doering Mobile communications ... right now writing from *Aichach* ... mobile phone: +49 177 2160221 ... or mail me: gert at greenie.muc.de From shorty at debian.org Fri Dec 29 00:53:06 2000 From: shorty at debian.org (Christian Kurz) Date: Thu, 28 Dec 2000 14:53:06 +0100 Subject: manpage for ssh-copy-id misspells authorized_keys Message-ID: <20001228145306.A8124@bofh.de> Hi, here's a minor and easy to fix bug. Thanks for fixing: > Manual for ssh-copy-id claims public key will be appended to remote file > ~/.ssh/authorised_keys, which should read ~/.ssh/authorized_keys ('s'->'z'). Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 From Markus.Friedl at informatik.uni-erlangen.de Fri Dec 29 00:54:05 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 28 Dec 2000 14:54:05 +0100 Subject: scp and filenames with weird characters In-Reply-To: <20001228155459.A531@greenie.muc.de>; from gert@greenie.muc.de on Thu, Dec 28, 2000 at 03:54:59PM +0100 References: <20001212181236.B20966@traad.dhs.org> <20001228132221.E27359@folly> <20001228155459.A531@greenie.muc.de> Message-ID: <20001228145405.A16600@faui02.informatik.uni-erlangen.de> es and rc are different. On Thu, Dec 28, 2000 at 03:54:59PM +0100, Gert Doering wrote: > Hi, > > On Thu, Dec 28, 2000 at 01:22:21PM +0100, Markus Friedl wrote: > > > - "%s%s -x -o'FallBackToRsh no' -n -l %s %s %s %s '%s%s%s:%s'", > > > + "%s%s -x -o'FallBackToRsh no' -n -l > > > \"%s\" \"%s\" \"%s\"\"%s\" '%s%s%s:%s'", > > > > not every shell uses " for quotes, some use ' only. > > For all shells that I've tested so far, " and ' are equivalent in the > context of "quoting is used to preserve blanks in arguments" (sh and > all compatibles, csh, zsh). > > The main difference between these is whether variables ("$foo") are > expanded or not. So single quotes might be a better choice to avoid > surprises with '$' in file names. > > gert > -- > Gert Doering > Mobile communications ... right now writing from *Aichach* > ... mobile phone: +49 177 2160221 ... or mail me: gert at greenie.muc.de From shorty at debian.org Fri Dec 29 00:58:06 2000 From: shorty at debian.org (Christian Kurz) Date: Thu, 28 Dec 2000 14:58:06 +0100 Subject: patch to support hurd-i386. In-Reply-To: <20001228144619.F10071@folly> References: <20001227235120.O12722@seteuid.getuid.de> <20001228144619.F10071@folly> Message-ID: <20001228145806.B8124@bofh.de> On 00-12-28 Markus Friedl wrote: > 1) IMHO, Hurd should add a definition for MAXHOSTNAMELEN. Well, would you please talk about this with the one who made this patch, Robert Bihlmeyer ? Thanks, he knows more about Hurd and it's development then me and would be the approiate contact. > 2) the patch does not use xmalloc,xrealloc So, he needs to use this function for a clear patch? Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 From shorty at debian.org Fri Dec 29 01:00:57 2000 From: shorty at debian.org (Christian Kurz) Date: Thu, 28 Dec 2000 15:00:57 +0100 Subject: sshd doesn't log which RSA key was used In-Reply-To: <20001228144432.E10071@folly> References: <20001228140715.A7582@bofh.de> <20001228144432.E10071@folly> Message-ID: <20001228150057.C8124@bofh.de> On 00-12-28 Markus Friedl wrote: > i am not sure about this feature. > you could add a > {Key k; k.rsa=pk; k.type=KEY_RSA1; > verbose("RSA auth accepted with key %s", key_fingerprint(&k); > } > to auth_rsa(). Well, at my former employer we had only one account that was used by everyone to log into the server. In this situation it would be useful to have a line in the auth.log like this to see which user logged and which key he used. Now I work at an other company where we have seperate acounts, where this is not needed. So I think such a patch would be helpful in some situations. And it looks line this 4 lines wouldn't bload the code of openssh but instead add a bit more logging and security to it in some enviroments. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 From mouring at etoh.eviladmin.org Fri Dec 29 03:18:34 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 28 Dec 2000 10:18:34 -0600 (CST) Subject: Error in sshd's manpage In-Reply-To: <20001228143936.A7889@bofh.de> Message-ID: On Thu, 28 Dec 2000, Christian Kurz wrote: > On 00-12-28 Markus Friedl wrote: > > $ grep -i lastlog * > > does not match a single file. > > I just grabbed the source of the ssh package in debian (which is > openssh 2.2.0p1) and if I do this grep in the source-dir, I also find > these lines: > > |sshd.8:.It Cm PrintLastLogin > |sshd.pam:session optional pam_lastlog.so # [1] > |sshd_config:#PrintLastLog no > > So, has this option been removed in openssh now or has it been added by > some undocumented extra patch? > Looks like it's a Debian patch that was added since it does not exist in the CVS tree. From mouring at etoh.eviladmin.org Fri Dec 29 03:26:07 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 28 Dec 2000 10:26:07 -0600 (CST) Subject: manpage for ssh-copy-id misspells authorized_keys In-Reply-To: <20001228145306.A8124@bofh.de> Message-ID: Fixed. - Ben On Thu, 28 Dec 2000, Christian Kurz wrote: > Hi, > > here's a minor and easy to fix bug. Thanks for fixing: > > > Manual for ssh-copy-id claims public key will be appended to remote file > > ~/.ssh/authorised_keys, which should read ~/.ssh/authorized_keys ('s'->'z'). > > Ciao > Christian > From shorty at debian.org Fri Dec 29 02:33:08 2000 From: shorty at debian.org (Christian Kurz) Date: Thu, 28 Dec 2000 16:33:08 +0100 Subject: Error in sshd's manpage In-Reply-To: References: <20001228143936.A7889@bofh.de> Message-ID: <20001228163308.A8678@bofh.de> On 00-12-28 mouring at etoh.eviladmin.org wrote: > On Thu, 28 Dec 2000, Christian Kurz wrote: > > On 00-12-28 Markus Friedl wrote: > > > $ grep -i lastlog * > > > does not match a single file. > > > > I just grabbed the source of the ssh package in debian (which is > > openssh 2.2.0p1) and if I do this grep in the source-dir, I also find > > these lines: > > > > |sshd.8:.It Cm PrintLastLogin > > |sshd.pam:session optional pam_lastlog.so # [1] > > |sshd_config:#PrintLastLog no > > > > So, has this option been removed in openssh now or has it been added by > > some undocumented extra patch? > > > Looks like it's a Debian patch that was added since it does not exist in > the CVS tree. Damn, and I could find a documentation about this. :( Looks like I have to check the 2.3.0p1 source again when I'm back home. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 From shorty at debian.org Fri Dec 29 02:47:31 2000 From: shorty at debian.org (Christian Kurz) Date: Thu, 28 Dec 2000 16:47:31 +0100 Subject: Error in sshd's manpage In-Reply-To: <20001228163308.A8678@bofh.de> References: <20001228143936.A7889@bofh.de> <20001228163308.A8678@bofh.de> Message-ID: <20001228164731.B8678@bofh.de> On 00-12-28 Christian Kurz wrote: > On 00-12-28 mouring at etoh.eviladmin.org wrote: > > On Thu, 28 Dec 2000, Christian Kurz wrote: > > > On 00-12-28 Markus Friedl wrote: > > > > $ grep -i lastlog * > > > > does not match a single file. > > > > > > I just grabbed the source of the ssh package in debian (which is > > > openssh 2.2.0p1) and if I do this grep in the source-dir, I also find > > > these lines: > > > > > > |sshd.8:.It Cm PrintLastLogin > > > |sshd.pam:session optional pam_lastlog.so # [1] > > > |sshd_config:#PrintLastLog no > > > > > > So, has this option been removed in openssh now or has it been added by > > > some undocumented extra patch? > > > > > Looks like it's a Debian patch that was added since it does not exist in > > the CVS tree. > Damn, and I could find a documentation about this. :( Looks like I have > to check the 2.3.0p1 source again when I'm back home. Hm, I now managed to grab a 2.3.0p1.tar.gz and look into it and the option is not there anymore. Looks like it was maybe in some 2.2.0 releases or a debian patch, that was never documented. Well, I will then close the bug. Thanks for your help. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 From shea at gtsdesign.com Fri Dec 29 05:12:36 2000 From: shea at gtsdesign.com (Gary Shea) Date: Thu, 28 Dec 2000 11:12:36 -0700 (MST) Subject: ssh-agent, protocol 2, openssh-2.3.0p1 Message-ID: Hi -- I saw an email on December 26th in the openssh-unix-dev mailing list archived on MARC, indicating that agent forwarding is indeed not working for 2.2, but that it is working for 2.3. That email referred to a user with 2.3 clients and 2.2 server. I am running the 2.3 client AND server and am having a similar problem. The only unusual aspect of my installation is that I'm using port 24 until I convince myself that this is all something I'm doing wrong, and switch to openssh! Apologies in advance if I'm offbase... I'm a moderately experienced ssh user, been running various versions for about three years, and have been using agent forwarding for the last couple of years with ssh.com's ssh1 and ssh2. This is my first dalliance with openssh. There are two machines, A and B. A is running openssh-2.3.0p1 compiled by me on Mandrake Linux 7.2 (RedHat 7?). B is also running openssh-2.3.0p1 compiled by me on Solaris 5.8 (an UltraSparc box). On A and B, the /etc/ssh/ssh_config and .ssh/ssh_config have 'Host *' followed by 'ForwardAgent yes' entries, and no other Host lines. As far as I can see, there are no sshd_config directives that affect agent forwarding. The Mandrake installation (on A) uses ssh-agent to set up KDE, so I see an ssh-agent running and have a corresponding SSH_AGENT_PID and SSH_AUTH_SOCKET in the shell environment. I ssh-add .ssh/gary_shea.dsa (my identity file, set up with IdentityFile2 in .ssh/ssh_config). ssh-add -l shows the identity. If I then 'ssh -A' to machine B, I do not need to type the passphrase, indicating that the ssh-agent works to that extent. BUT, my environment on B does not contain the SSH_AGENT_PID and SSH_AUTH_SOCK entries. I am forwarding X11 also, and the X11 forwarding appears to be working, based on the presence of DISPLAY in the environment on B, and the characteristic delay starting vim on B. Is there something I'm missing? Gary From stevesk at pobox.com Fri Dec 29 05:42:34 2000 From: stevesk at pobox.com (Kevin Steves) Date: Thu, 28 Dec 2000 19:42:34 +0100 (CET) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: Message-ID: On Thu, 28 Dec 2000, Damien Miller wrote: : > not a patch per se but proto 2 is broken on hp-ux due to the issue with : > the SIGCHLD handler being reinstalled before a wait(). : : Does the hang with background processes problem exist on HPUX? are we using sleep 10& exit to test this? bash-2.04$ uname -a HP-UX jenny B.11.11 A 9000/800 670359383 two-user license bash-2.04$ sleep 20& exit [1] 13064 logout logout Connection to jenny closed. [20 seconds later] that's on 11.11, and i'm pretty sure 11.0 is going to be the same. can someone with 10.20 test with the latest snapshot? From stevesk at pobox.com Fri Dec 29 05:58:31 2000 From: stevesk at pobox.com (Kevin Steves) Date: Thu, 28 Dec 2000 19:58:31 +0100 (CET) Subject: Work around Linux kernel bug provoked by nchan.c In-Reply-To: <20000723100323.F263@wolery.cumb.org> Message-ID: hp-ux 10.20 and 11 seem to have a similar issue in that shutdown(sock, SHUT_RD) return EINVAL when the write side has been previously closed. you can dup this with: ssh -R 2300:bar:23 foo telnet 0 2300 Dec 22 22:04:18 jenny sshd[21722]: error: channel 1: chan_shutdown_read: shutdown() failed for fd13 [i1 o128]: Invalid argument regarding the patch below, why do we test for this: + || c->ostate == CHAN_OUTPUT_OPEN + || c->ostate == CHAN_OUTPUT_WAIT_DRAIN)) vs. just checking for ENOTCONN? On Sun, 23 Jul 2000, Zack Weinberg wrote: : The Linux implementation of TCP sockets has a bug which causes : shutdown(sock, SHUT_RD) to fail spuriously (ENOTCONN) if the write : side of the socket has already been shut down. If you are using SSH : port forwarding to tunnel HTTP through a firewall, nchan.c will tickle : this bug once for every HTTP exchange. You will therefore get lots of : useless, annoying error messages: : : channel 2: chan_shutdown_read: shutdown() failed for fd7 [i1 o128]: Transport endpoint is not connected : : Here's a complete debugging trace of one such forwarded channel. This : is SSH1 protocol; I haven't got the setup to do SSH2 yet. The remote : server is 2.0.12 F-SECURE SSH on Solaris 2.6; I am using openssh : 2.1.1p4 with kernel 2.2.16. : : debug: channel 2: new [listen port 3128 for webcache.example.com port 3128, connect from localhost port 1817] : debug: channel 2: rcvd ieof : debug: channel 2: output open -> drain : debug: channel 2: obuf empty : debug: channel 2: output drain -> closed : debug: channel 2: send oclose : debug: channel 2: close_write : debug: channel 2: read<=0 rfd 7 len 0 : debug: channel 2: read failed : debug: channel 2: input open -> drain : debug: channel 2: close_read : channel 2: chan_shutdown_read: shutdown() failed for fd7 [i1 o128]: Transport endpoint is not connected : debug: channel 2: input: no drain shortcut : debug: channel 2: ibuf empty : debug: channel 2: input drain -> wait_oclose : debug: channel 2: send ieof : debug: channel 2: rcvd oclose : debug: channel 2: input wait_oclose -> closed : debug: channel 2: full closed : : I'd appreciate it if the appended patch could be applied. It causes : ssh to recognize the bug and not emit the error message. : : [I've reported the bug to the kernel developers but they do not seem : interested in fixing it.] : : zw : : --- openssh-2.1.1p4.orig/nchan.c Thu Jun 22 04:32:31 2000 : +++ openssh-2.1.1p4/nchan.c Sun Jul 23 09:42:23 2000 : @@ -483,7 +483,12 @@ : return; : debug("channel %d: close_read", c->self); : if (c->sock != -1) { : - if (shutdown(c->sock, SHUT_RD) < 0) : + /* shutdown(sock, SHUT_READ) may return ENOTCONN if the : + write side has been closed already. */ : + if (shutdown(c->sock, SHUT_RD) < 0 : + && (errno != ENOTCONN : + || c->ostate == CHAN_OUTPUT_OPEN : + || c->ostate == CHAN_OUTPUT_WAIT_DRAIN)) : error("channel %d: chan_shutdown_read: shutdown() failed for fd%d [i%d o%d]: %.100s", : c->self, c->sock, c->istate, c->ostate, strerror(errno)); : } else { : From mstone at cs.loyola.edu Fri Dec 29 06:00:36 2000 From: mstone at cs.loyola.edu (Michael Stone) Date: Thu, 28 Dec 2000 14:00:36 -0500 Subject: scp progress bar Message-ID: <20001228140036.A17493@justice.loyola.edu> ISTR that someone had a patch once upon a time to add some of the favorite features back to the scp output (e.g., transfer rate.) Did that get rejected or forgotten or what? -- Mike Stone From hlein at progressive-comp.com Fri Dec 29 08:56:50 2000 From: hlein at progressive-comp.com (Hank Leininger) Date: Thu, 28 Dec 2000 16:56:50 -0500 (EST) Subject: sshd doesn't log which RSA key was used Message-ID: <10012281624120.6184-100000@interpage.progressive-comp.com> On 2000-12-28, Christian Kurz wrote: > On 00-12-28 Markus Friedl wrote: > > i am not sure about this feature. > > you could add a > > {Key k; k.rsa=pk; k.type=KEY_RSA1; > > verbose("RSA auth accepted with key %s", key_fingerprint(&k); > > } > > to auth_rsa(). > Well, at my former employer we had only one account that was used by > everyone to log into the server. In this situation it would be useful > to have a line in the auth.log like this to see which user logged and > which key he used. Now I work at an other company where we have Yup. This'd also be quite nice for automated jobs that can, say, log in as root with a forced command="...", or shared access to an account that runs a forced command="..." or scp's. Here are some (lightly tested, whee) small patches to implement this for RSA and DSA authentications. I also added key-line-number printing for keys which are skipped because their options blocks have restrictive from='s, etc. (BTW I think that wording is misleading: sshd says "correct key but not from a permitted host", but as far as I can tell, the key hasn't actually been tested yet--that check happens *before* the client is challenged. The verbage suggests it wasn't always so.) I'm also including a one-liner for my request the other day, that changes 'tvp!=NULL kid...' from debug to debug2. Mebbe these are small enough for someone to look over (and, probably, fix ;) in time for inclusion in 2.4.0 ? Thanks, Hank Leininger ### diff -u auth-options.c.orig auth-options.c --- auth-options.c.orig Sat Oct 14 01:23:11 2000 +++ auth-options.c Thu Dec 28 15:51:38 2000 @@ -193,9 +193,9 @@ xfree(patterns); if (mname == -1 || mip == -1 || (mname != 1 && mip != 1)) { - log("Authentication tried for %.100s with correct key but not from a permitted host (host=%.200s, ip=%.200s).", + log("Authentication tried for %.100s with correct key but not from a permitted host (host=%.200s, ip=%.200s, line=%lu).", pw->pw_name, get_canonical_hostname(), - get_remote_ipaddr()); + get_remote_ipaddr(), linenum); packet_send_debug("Your host '%.200s' is not permitted to use this key for login.", get_canonical_hostname()); /* deny access */ diff -u auth-rsa.c.orig auth-rsa.c --- auth-rsa.c.orig Sun Oct 15 21:14:42 2000 +++ auth-rsa.c Thu Dec 28 16:50:12 2000 @@ -28,6 +28,8 @@ #include #include +#include +#include "key.h" /* import */ @@ -276,6 +278,11 @@ * otherwise continue searching. */ authenticated = 1; + /* Log which RSA key was used */ + { + Key k; k.rsa=pk; k.type=KEY_RSA; + verbose("RSA auth successful for key %s", key_fingerprint(&k)); + } break; } diff -u auth2.c.orig auth2.c --- auth2.c.orig Sat Oct 28 06:05:57 2000 +++ auth2.c Thu Dec 28 16:04:14 2000 @@ -464,8 +464,11 @@ #endif /* test for correct signature */ if (user_dsa_key_allowed(authctxt->pw, key) && - dsa_verify(key, sig, slen, buffer_ptr(&b), buffer_len(&b)) == 1) + dsa_verify(key, sig, slen, buffer_ptr(&b), buffer_len(&b)) == 1) { authenticated = 1; + /* Log which DSA key was used */ + verbose("DSA auth successful for key %s", key_fingerprint(key)); + } buffer_clear(&b); xfree(sig); } else { diff -u serverloop.c.orig serverloop.c --- serverloop.c.orig Fri Oct 27 23:19:58 2000 +++ serverloop.c Wed Dec 27 22:32:23 2000 @@ -256,7 +256,7 @@ tvp = &tv; } if (tvp!=NULL) - debug("tvp!=NULL kid %d mili %d", child_terminated, max_time_milliseconds); + debug2("tvp!=NULL kid %d mili %d", child_terminated, max_time_milliseconds); /* Wait for something to happen, or the timeout to expire. */ ret = select(max_fd + 1, readset, writeset, NULL, tvp); From mouring at etoh.eviladmin.org Fri Dec 29 10:44:34 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 28 Dec 2000 17:44:34 -0600 (CST) Subject: scp progress bar In-Reply-To: <20001228140036.A17493@justice.loyola.edu> Message-ID: I think it was lost in the shuffle. I'm in mucking with progressmeter() and I've found the patch that adds in transfer rates and see if I can merge it into my current work. Don't expect it in 2.4.0 unless Markus or someone else bets me to the punch or if 2.4.0 ends up being delayed longer.=) - Ben On Thu, 28 Dec 2000, Michael Stone wrote: > ISTR that someone had a patch once upon a time to add some of the > favorite features back to the scp output (e.g., transfer rate.) Did that > get rejected or forgotten or what? > > From djm at mindrot.org Fri Dec 29 10:20:22 2000 From: djm at mindrot.org (Damien Miller) Date: Fri, 29 Dec 2000 10:20:22 +1100 (EST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: Message-ID: On Thu, 28 Dec 2000, Kevin Steves wrote: > On Thu, 28 Dec 2000, Damien Miller wrote: > : > not a patch per se but proto 2 is broken on hp-ux due to the issue with > : > the SIGCHLD handler being reinstalled before a wait(). > : > : Does the hang with background processes problem exist on HPUX? > > are we using sleep 10& exit to test this? > > bash-2.04$ uname -a > HP-UX jenny B.11.11 A 9000/800 670359383 two-user license > bash-2.04$ sleep 20& exit > [1] 13064 > logout > logout > Connection to jenny closed. > [20 seconds later] damn - can you strace it to see if/where we are blocking. On Linux we end up stuck in a read() on a fd which has been explicitly marked non-blocking, which strikes me as weird. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From shorty at debian.org Fri Dec 29 10:10:57 2000 From: shorty at debian.org (Christian Kurz) Date: Fri, 29 Dec 2000 00:10:57 +0100 Subject: Bug in lastlog printing Message-ID: <20001229001057.A23589@seteuid.getuid.de> Hi, I just ltraced ssh to see why it prints the lastlog twice instead of one time. I think the bug seems to be in the parsing of the lastlog-entry and I especially think that the function lastlog_populate_entry is the buggy one, but I'm not sure, as I'm not very familar with the code. So if someone of you, would please trace this bug down and fix it, I would really appreciate that. Thanks. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001229/a75372d2/attachment.bin From djm at mindrot.org Fri Dec 29 10:27:12 2000 From: djm at mindrot.org (Damien Miller) Date: Fri, 29 Dec 2000 10:27:12 +1100 (EST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: Message-ID: On Fri, 29 Dec 2000, Damien Miller wrote: > > bash-2.04$ uname -a > > HP-UX jenny B.11.11 A 9000/800 670359383 two-user license > > bash-2.04$ sleep 20& exit > > [1] 13064 > > logout > > logout > > Connection to jenny closed. > > [20 seconds later] > > damn - can you strace it to see if/where we are blocking. On Linux we > end up stuck in a read() on a fd which has been explicitly marked > non-blocking, which strikes me as weird. Another datapoint: the grandchild processes never receive a HUP. We are either messing up on the terminal handling or on the setting up of pgid or sid. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From djm at mindrot.org Fri Dec 29 10:43:18 2000 From: djm at mindrot.org (Damien Miller) Date: Fri, 29 Dec 2000 10:43:18 +1100 (EST) Subject: Bug in lastlog printing In-Reply-To: <20001229001057.A23589@seteuid.getuid.de> Message-ID: On Fri, 29 Dec 2000, Christian Kurz wrote: > Hi, > > I just ltraced ssh to see why it prints the lastlog twice instead of one > time. I have never seen this behaviour. > I think the bug seems to be in the parsing of the lastlog-entry > and I especially think that the function lastlog_populate_entry is the > buggy one, but I'm not sure, as I'm not very familar with the code. So > if someone of you, would please trace this bug down and fix it, I would > really appreciate that. Thanks. Are you sure that you are not using a pam_lastlog module? -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From shorty at debian.org Fri Dec 29 10:48:11 2000 From: shorty at debian.org (Christian Kurz) Date: Fri, 29 Dec 2000 00:48:11 +0100 Subject: Bug in lastlog printing In-Reply-To: References: <20001229001057.A23589@seteuid.getuid.de> Message-ID: <20001229004811.A12162@bofh.de> On 00-12-29 Damien Miller wrote: > On Fri, 29 Dec 2000, Christian Kurz wrote: > > I think the bug seems to be in the parsing of the lastlog-entry > > and I especially think that the function lastlog_populate_entry is the > > buggy one, but I'm not sure, as I'm not very familar with the code. So > > if someone of you, would please trace this bug down and fix it, I would > > really appreciate that. Thanks. > Are you sure that you are not using a pam_lastlog module? Hm, could this occur because of the usage of this pam_lastlog module? So to now get this twice, we should either disable the lastlog in ssh (which is bad in my opinion) or remove the lastlog-module from the pam-configuration of ssh? For me it looks like it's that module that is printing the second lastlog message, but currently I'm a bit too sleepy to be sure. :) Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 From djm at mindrot.org Fri Dec 29 11:31:16 2000 From: djm at mindrot.org (Damien Miller) Date: Fri, 29 Dec 2000 11:31:16 +1100 (EST) Subject: Bug in lastlog printing In-Reply-To: <20001229004811.A12162@bofh.de> Message-ID: On Fri, 29 Dec 2000, Christian Kurz wrote: > > Are you sure that you are not using a pam_lastlog module? > > Hm, could this occur because of the usage of this pam_lastlog module? So > to now get this twice, we should either disable the lastlog in ssh > (which is bad in my opinion) or remove the lastlog-module from the > pam-configuration of ssh? For me it looks like it's that module that is > printing the second lastlog message, but currently I'm a bit too sleepy > to be sure. :) Remove the pam_lastlog module - ssh does this itself. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From djm at mindrot.org Fri Dec 29 11:54:10 2000 From: djm at mindrot.org (Damien Miller) Date: Fri, 29 Dec 2000 11:54:10 +1100 (EST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: Message-ID: On Fri, 29 Dec 2000, Damien Miller wrote: In the grand tradition of replying to one's own reply: > Another datapoint: the grandchild processes never receive a HUP. We are > either messing up on the terminal handling or on the setting up > of pgid or sid. After rereading Stevens I am not sure that they are supposed to. It looks like only stopped jobs are supposed to get a HUP (and then a CONT). pdksh, tcsh, bash1 bash2 don't HUP their children. ash does. zsh will warn on the first exit "you have running jobs" and then hangs up on the second. The bash info page states that it does this too, but I see no evidence that it works. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From djm at mindrot.org Fri Dec 29 12:37:46 2000 From: djm at mindrot.org (Damien Miller) Date: Fri, 29 Dec 2000 12:37:46 +1100 (EST) Subject: ssh: doesn't live well with user-group system In-Reply-To: <20001228142349.B7723@bofh.de> Message-ID: On Thu, 28 Dec 2000, Christian Kurz wrote: > Hi, > > and that's another feature request. Sorry if it looks like some kind of > spamming, but our current maintainer was very stressed in the past and > had not time to forward those reports to you and now I help him a bit > out. So thanks for your patience and answering of all my mails with > bugreport and feature-reqeust. > > Debian by default uses the user-group system. Each user has their > > own group. 002 is a reasonable umask to decide to use if you are > > using the user-group system. (It's hardly the only choice, but it > > is a valid choice.) This should be a Debain-specific patch. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From djm at mindrot.org Fri Dec 29 12:39:02 2000 From: djm at mindrot.org (Damien Miller) Date: Fri, 29 Dec 2000 12:39:02 +1100 (EST) Subject: Error in sshd's manpage In-Reply-To: <20001228143936.A7889@bofh.de> Message-ID: On Thu, 28 Dec 2000, Christian Kurz wrote: > So, has this option been removed in openssh now or has it been added by > some undocumented extra patch? It is one of your patches. -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From shorty at debian.org Fri Dec 29 18:03:34 2000 From: shorty at debian.org (Christian Kurz) Date: Fri, 29 Dec 2000 08:03:34 +0100 Subject: ssh: doesn't live well with user-group system In-Reply-To: References: <20001228142349.B7723@bofh.de> Message-ID: <20001229080334.G23589@seteuid.getuid.de> On 00-12-29 Damien Miller wrote: > On Thu, 28 Dec 2000, Christian Kurz wrote: > > and that's another feature request. Sorry if it looks like some kind of > > spamming, but our current maintainer was very stressed in the past and > > had not time to forward those reports to you and now I help him a bit > > out. So thanks for your patience and answering of all my mails with > > bugreport and feature-reqeust. > > > Debian by default uses the user-group system. Each user has their > > > own group. 002 is a reasonable umask to decide to use if you are > > > using the user-group system. (It's hardly the only choice, but it > > > is a valid choice.) > This should be a Debain-specific patch. Thanks, but I closed for now the bug after heaving read Markus explanation with an similar explanation. If he still thinks this is a problem, I think, he should write the patch for this and maybe we integrate it in our debian package, but I'm not sure. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001229/e2bd38c5/attachment.bin From shorty at debian.org Fri Dec 29 18:01:29 2000 From: shorty at debian.org (Christian Kurz) Date: Fri, 29 Dec 2000 08:01:29 +0100 Subject: Error in sshd's manpage In-Reply-To: References: <20001228143936.A7889@bofh.de> Message-ID: <20001229080129.F23589@seteuid.getuid.de> On 00-12-29 Damien Miller wrote: > On Thu, 28 Dec 2000, Christian Kurz wrote: > > So, has this option been removed in openssh now or has it been added by > > some undocumented extra patch? > It is one of your patches. So I got now the answer from the one who wrote it and I asked him to first contact you about such a page, because I want to use the upstream source without an extra patch for the debian package. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001229/4587d163/attachment.bin From markus.friedl at informatik.uni-erlangen.de Fri Dec 29 21:59:27 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 29 Dec 2000 11:59:27 +0100 Subject: ssh-agent, protocol 2, openssh-2.3.0p1 In-Reply-To: ; from shea@gtsdesign.com on Thu, Dec 28, 2000 at 11:12:36AM -0700 References: Message-ID: <20001229115927.D16494@folly> you have to try a recent snapshot if you need agent-fwding in ssh2: http://bass.directhit.com/openssh_snap/ On Thu, Dec 28, 2000 at 11:12:36AM -0700, Gary Shea wrote: > Hi -- > > I saw an email on December 26th in the openssh-unix-dev mailing list > archived on MARC, indicating that agent forwarding is indeed not working > for 2.2, but that it is working for 2.3. That email referred to a user > with 2.3 clients and 2.2 server. I am running the 2.3 client AND server > and am having a similar problem. The only unusual aspect of my installation > is that I'm using port 24 until I convince myself that this is all something > I'm doing wrong, and switch to openssh! Apologies in advance if I'm > offbase... > > I'm a moderately experienced ssh user, been running various versions for > about three years, and have been using agent forwarding for the last > couple of years with ssh.com's ssh1 and ssh2. This is my first dalliance > with openssh. > > There are two machines, A and B. A is running openssh-2.3.0p1 compiled > by me on Mandrake Linux 7.2 (RedHat 7?). B is also running > openssh-2.3.0p1 compiled by me on Solaris 5.8 (an UltraSparc box). > On A and B, the /etc/ssh/ssh_config and .ssh/ssh_config > have 'Host *' followed by 'ForwardAgent yes' entries, and no > other Host lines. As far as I can see, there are no sshd_config > directives that affect agent forwarding. > > The Mandrake installation (on A) uses ssh-agent to set up KDE, > so I see an ssh-agent running and have a corresponding SSH_AGENT_PID > and SSH_AUTH_SOCKET in the shell environment. I ssh-add > .ssh/gary_shea.dsa (my identity file, set up with IdentityFile2 in > .ssh/ssh_config). ssh-add -l shows the identity. If I then 'ssh -A' > to machine B, I do not need to type the passphrase, indicating that the > ssh-agent works to that extent. BUT, my environment on B > does not contain the SSH_AGENT_PID and SSH_AUTH_SOCK entries. > > I am forwarding X11 also, and the X11 forwarding appears to be working, > based on the presence of DISPLAY in the environment on B, and the > characteristic delay starting vim on B. > > Is there something I'm missing? > > Gary > > From Lutz.Jaenicke at aet.TU-Cottbus.DE Fri Dec 29 23:17:51 2000 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Fri, 29 Dec 2000 13:17:51 +0100 Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: ; from stevesk@pobox.com on Thu, Dec 28, 2000 at 07:42:34PM +0100 References: Message-ID: <20001229131751.A12662@serv01.aet.tu-cottbus.de> On Thu, Dec 28, 2000 at 07:42:34PM +0100, Kevin Steves wrote: > On Thu, 28 Dec 2000, Damien Miller wrote: > : > not a patch per se but proto 2 is broken on hp-ux due to the issue with > : > the SIGCHLD handler being reinstalled before a wait(). > : > : Does the hang with background processes problem exist on HPUX? > > are we using sleep 10& exit to test this? > > bash-2.04$ uname -a > HP-UX jenny B.11.11 A 9000/800 670359383 two-user license > bash-2.04$ sleep 20& exit > [1] 13064 > logout > logout > Connection to jenny closed. > [20 seconds later] > > that's on 11.11, and i'm pretty sure 11.0 is going to be the same. > > can someone with 10.20 test with the latest snapshot? Hmm, I couldn't get it to run on 10.20 at all. I have installed the latest snapshot (20001229), then performed a "slogin -2". The connection was opened and the lastlog information was displayed, then it hangs. "top" reports a memory usage of 85MB for sshd, which doesn't make sense either. Oh, now I see why the system is so slow... I just received: # ls -al /core -rw------- 1 root root 54804480 Dec 29 13:10 /core At this size my / partition was full... I am writing these lines from home via ISDN, so actually debugging doesn't make too much sense (ever tried DDD via ISDN line), so I will only be back to full "effectivity" next week back in the office. BTW, it seems OpenSSH is now also going the GNU way to require even more GNU utilities. The "make" process is broken for HP-UX make and GNU make is required, as flags are not passed as needed. ws01 38: make cc -O -Ae +DAportable -I/usr/local/include -c bsd-arc4random.c cpp: "bsd-arc4random.c", line 29: error 4036: Can't open include file 'openssl/rand.h'. cpp: "bsd-arc4random.c", line 30: error 4036: Can't open include file 'openssl/rc4.h'. *** Error exit code 1 As you can see, CPPFLAGS are not honored. (Because there is not .c.o rule?) Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From sfrost at snowman.net Sat Dec 30 00:35:38 2000 From: sfrost at snowman.net (Stephen Frost) Date: Fri, 29 Dec 2000 08:35:38 -0500 Subject: [PATCH] Added option 'RetryDelay' In-Reply-To: <20001114082508.T5470@ns>; from sfrost@snowman.net on Tue, Nov 14, 2000 at 08:25:08AM -0500 References: <20001114082508.T5470@ns> Message-ID: <20001229083538.Y26953@ns> * Stephen Frost (sfrost at snowman.net) wrote: > Being rather aggrevated when testing at the enforced 1 second > delay between each connection attempt and the useless 1 second delay > done after all connection attempts have failed I wrote a patch to make > the number of seconds delayed between each connection attempt > configurable. Here is my patch again, this time against openssh-SNAP-20001229. I'd hope to see this patch or something similar put in place. It does not change default behaviour in any way but adds an option for those of us who want it. :) Stephen -------------- next part -------------- diff -u --recursive openssh-clean/readconf.c openssh/readconf.c --- openssh-clean/readconf.c Thu Dec 28 11:40:05 2000 +++ openssh/readconf.c Fri Dec 29 06:51:55 2000 @@ -98,7 +98,7 @@ #endif oIdentityFile, oHostName, oPort, oCipher, oRemoteForward, oLocalForward, oUser, oHost, oEscapeChar, oRhostsRSAAuthentication, oProxyCommand, - oGlobalKnownHostsFile, oUserKnownHostsFile, oConnectionAttempts, + oGlobalKnownHostsFile, oUserKnownHostsFile, oConnectionAttempts, oRetryDelay, oBatchMode, oCheckHostIP, oStrictHostKeyChecking, oCompression, oCompressionLevel, oKeepAlives, oNumberOfPasswordPrompts, oTISAuthentication, oUsePrivilegedPort, oLogLevel, oCiphers, oProtocol, @@ -154,6 +154,7 @@ { "globalknownhostsfile2", oGlobalKnownHostsFile2 }, { "userknownhostsfile2", oUserKnownHostsFile2 }, { "connectionattempts", oConnectionAttempts }, + { "retrydelay", oRetryDelay }, { "batchmode", oBatchMode }, { "checkhostip", oCheckHostIP }, { "stricthostkeychecking", oStrictHostKeyChecking }, @@ -475,6 +476,10 @@ intptr = &options->connection_attempts; goto parse_int; + case oRetryDelay: + intptr = &options->retry_delay; + goto parse_int; + case oCipher: intptr = &options->cipher; arg = strdelim(&s); @@ -688,6 +693,7 @@ options->compression_level = -1; options->port = -1; options->connection_attempts = -1; + options->retry_delay = -1; options->number_of_password_prompts = -1; options->cipher = -1; options->ciphers = NULL; @@ -771,6 +777,8 @@ options->port = 0; /* Filled in ssh_connect. */ if (options->connection_attempts == -1) options->connection_attempts = 4; + if (options->retry_delay == -1) + options->retry_delay = 1; if (options->number_of_password_prompts == -1) options->number_of_password_prompts = 3; /* Selected in ssh_login(). */ diff -u --recursive openssh-clean/readconf.h openssh/readconf.h --- openssh-clean/readconf.h Thu Dec 28 11:40:05 2000 +++ openssh/readconf.h Fri Dec 29 06:51:55 2000 @@ -61,8 +61,10 @@ LogLevel log_level; /* Level for logging. */ int port; /* Port to connect. */ - int connection_attempts; /* Max attempts (seconds) before + int connection_attempts; /* Max connection attempts before * giving up */ + int retry_delay; /* Number of seconds to delay between each + * connection attempt */ int number_of_password_prompts; /* Max number of password * prompts. */ int cipher; /* Cipher to use. */ diff -u --recursive openssh-clean/ssh.0 openssh/ssh.0 --- openssh-clean/ssh.0 Thu Dec 28 12:30:15 2000 +++ openssh/ssh.0 Fri Dec 29 06:51:55 2000 @@ -538,6 +538,10 @@ additional forwardings can be given on the command line. Only the superuser can forward privileged ports. + RetryDelay + Specifies the number of seconds to delay between each connection + attempt. + RhostsAuthentication Specifies whether to try rhosts based authentication. Note that this declaration only affects the client side and has no effect diff -u --recursive openssh-clean/ssh.1 openssh/ssh.1 --- openssh-clean/ssh.1 Thu Dec 28 11:40:05 2000 +++ openssh/ssh.1 Fri Dec 29 06:51:55 2000 @@ -878,6 +878,10 @@ Multiple forwardings may be specified, and additional forwardings can be given on the command line. Only the superuser can forward privileged ports. +.It Cm RetryDelay +Specifies the number of seconds to delay before attempting to +reconnect after a failed ConnectionAttempt +The argument must be an integer. .It Cm RhostsAuthentication Specifies whether to try rhosts based authentication. Note that this diff -u --recursive openssh-clean/ssh.c openssh/ssh.c --- openssh-clean/ssh.c Thu Dec 28 11:40:05 2000 +++ openssh/ssh.c Fri Dec 29 06:55:26 2000 @@ -607,7 +607,7 @@ /* Open a connection to the remote host. */ ok = ssh_connect(host, &hostaddr, options.port, - options.connection_attempts, + options.connection_attempts, options.retry_delay, original_effective_uid != 0 || !options.use_privileged_port, original_real_uid, options.proxy_command); diff -u --recursive openssh-clean/ssh.h openssh/ssh.h --- openssh-clean/ssh.h Thu Dec 21 20:44:00 2000 +++ openssh/ssh.h Fri Dec 29 06:51:55 2000 @@ -323,11 +323,12 @@ * privileges if anonymous is false. Connection_attempts specifies the * maximum number of tries, one per second. This returns true on success, * and zero on failure. If the connection is successful, this calls - * packet_set_connection for the connection. + * packet_set_connection for the connection. Retry_delay specifies the seconds + * to wait between connection attempts. */ int ssh_connect(const char *host, struct sockaddr_storage * hostaddr, - u_short port, int connection_attempts, + u_short port, int connection_attempts, int retry_delay, int anonymous, uid_t original_real_uid, const char *proxy_command); diff -u --recursive openssh-clean/sshconnect.c openssh/sshconnect.c --- openssh-clean/sshconnect.c Thu Dec 28 11:40:06 2000 +++ openssh/sshconnect.c Fri Dec 29 06:51:55 2000 @@ -176,14 +176,14 @@ * If port is 0, the default port will be used. If anonymous is zero, * a privileged port will be allocated to make the connection. * This requires super-user privileges if anonymous is false. - * Connection_attempts specifies the maximum number of tries (one per - * second). If proxy_command is non-NULL, it specifies the command (with %h - * and %p substituted for host and port, respectively) to use to contact - * the daemon. + * Connection_attempts specifies the maximum number of tries. Retry_delay + * specifies the seconds to delay between attempts. If proxy_command is + * non-NULL, it specifies the command (with %h * and %p substituted for + * host and port, respectively) to use to contact the daemon. */ int ssh_connect(const char *host, struct sockaddr_storage * hostaddr, - u_short port, int connection_attempts, + u_short port, int connection_attempts, int retry_delay, int anonymous, uid_t original_real_uid, const char *proxy_command) { @@ -280,7 +280,7 @@ break; /* Successful connection. */ /* Sleep a moment before retrying. */ - sleep(1); + sleep(retry_delay); } freeaddrinfo(aitop); -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001229/6205cfff/attachment.bin From mouring at etoh.eviladmin.org Sat Dec 30 03:49:09 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 29 Dec 2000 10:49:09 -0600 (CST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: <20001229131751.A12662@serv01.aet.tu-cottbus.de> Message-ID: On Fri, 29 Dec 2000, Lutz Jaenicke wrote: > BTW, it seems OpenSSH is now also going the GNU way to require even more > GNU utilities. The "make" process is broken for HP-UX make and GNU make > is required, as flags are not passed as needed. > ws01 38: make > cc -O -Ae +DAportable -I/usr/local/include -c bsd-arc4random.c > cpp: "bsd-arc4random.c", line 29: error 4036: Can't open include file 'openssl/rand.h'. > cpp: "bsd-arc4random.c", line 30: error 4036: Can't open include file 'openssl/rc4.h'. > *** Error exit code 1 > As you can see, CPPFLAGS are not honored. (Because there is not .c.o rule?) > When I did the patch to split CFLAGS and CPPFLAGS I had not tested it on my NeXT box.. and I'm running into the same issue. However it's worse under NeXT. 'configure' fails because CPPFLAGS are not being honored from the start. So I'm not sure if it's make or the cc compiler. - Ben From Lutz.Jaenicke at aet.TU-Cottbus.DE Sat Dec 30 04:10:02 2000 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Fri, 29 Dec 2000 18:10:02 +0100 Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Dec 29, 2000 at 10:49:09AM -0600 References: <20001229131751.A12662@serv01.aet.tu-cottbus.de> Message-ID: <20001229181002.A14576@serv01.aet.tu-cottbus.de> On Fri, Dec 29, 2000 at 10:49:09AM -0600, mouring at etoh.eviladmin.org wrote: > On Fri, 29 Dec 2000, Lutz Jaenicke wrote: > When I did the patch to split CFLAGS and CPPFLAGS I had not tested it on > my NeXT box.. and I'm running into the same issue. However it's worse > under NeXT. 'configure' fails because CPPFLAGS are not being honored from > the start. > > So I'm not sure if it's make or the cc compiler. This question is easily to be answered :-) The cc compiler does not give anything about ENVIRONMENT variables being set or not. Different incarnations of "make" will automatically take into account a different set of environment variables. The HP-UX make e.g. will take into account CC and CFLAGS and will automatically use a general rule to compile C programs to objects: .c.o: $(CC) $(CFLAGS) -c $< Hence, "make" will automatically honor CC and CFLAGS but no other flags will be recognized, especially not CPPFLAGS. Since the common set of rules between "make" programs may not be the same, the safest way should be to include the rule into Makefile(.in) .c.o: $(CC) $(CFLAGS) $(CPPFLAGS) -c $< This way it should work for all platforms. (Another commonly used way is to start in Makefile with something like CFLAGS= $(CFLAGS) $(CPPFLAGS) or similar.) I have not yet checked "configure" into detail, but for me it seems that CPPFLAGS are being recognized and are used to record -Include path directives. Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From gert at greenie.muc.de Sat Dec 30 05:57:55 2000 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 29 Dec 2000 19:57:55 +0100 Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: <20001229131751.A12662@serv01.aet.tu-cottbus.de>; from Lutz Jaenicke on Fri, Dec 29, 2000 at 01:17:51PM +0100 References: <20001229131751.A12662@serv01.aet.tu-cottbus.de> Message-ID: <20001229195755.C772@greenie.muc.de> Hi, On Fri, Dec 29, 2000 at 01:17:51PM +0100, Lutz Jaenicke wrote: > The "make" process is broken for HP-UX make and GNU make > is required, as flags are not passed as needed. Same for SCO ODT 3.0 and AIX "make". > ws01 38: make > cc -O -Ae +DAportable -I/usr/local/include -c bsd-arc4random.c > cpp: "bsd-arc4random.c", line 29: error 4036: Can't open include file 'openssl/rand.h'. > cpp: "bsd-arc4random.c", line 30: error 4036: Can't open include file 'openssl/rc4.h'. > *** Error exit code 1 > As you can see, CPPFLAGS are not honored. (Because there is not .c.o rule?) That would be my guess as well - no .c.o rule, and the default rule doesn't use $(CPPFLAGS). I think it should not be a major portability issue to just add the proper .c.o rule - but then, I don't know all the weirder systems out there. gert -- Gert Doering Mobile communications ... right now writing from *Aichach* ... mobile phone: +49 177 2160221 ... or mail me: gert at greenie.muc.de From markus.friedl at informatik.uni-erlangen.de Sat Dec 30 05:57:07 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 29 Dec 2000 19:57:07 +0100 Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: ; from stevesk@pobox.com on Thu, Dec 28, 2000 at 04:09:07AM +0100 References: Message-ID: <20001229195707.A13319@folly> On Thu, Dec 28, 2000 at 04:09:07AM +0100, Kevin Steves wrote: > On Wed, 27 Dec 2000 mouring at etoh.eviladmin.org wrote: > : Is there any undisputed patches still out not applied to the current > : portable CVS tree? > > not a patch per se but proto 2 is broken on hp-ux due to the issue with > the SIGCHLD handler being reinstalled before a wait(). i think we should switch to sigaction since the sematics for signal() are different on every system. e.g. replace signal() with mysignal(): typedef void (*mysig_t)(int); mysig_t mysignal(int s, mysig_t a) { struct sigaction sa, osa; memset(&sa, 0, sizeof sa); sigemptyset(&sa.sa_mask); sa.sa_flags = 0; sa.sa_handler = a; if (sigaction(s, &sa, &osa) < 0) return (mysig_t)-1; return (osa.sa_handler); } mysignal can fallback to signal if sigaction is not available. with mysignal() we don't need to reinstall signalhandlers. comments? -markus From gert at greenie.muc.de Sat Dec 30 06:58:33 2000 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 29 Dec 2000 20:58:33 +0100 Subject: patch to support hurd-i386 In-Reply-To: ; from mouring@etoh.eviladmin.org on Wed, Dec 27, 2000 at 07:40:53PM -0600 References: <20001227234758.N12722@seteuid.getuid.de> Message-ID: <20001229205833.B1193@greenie.muc.de> Hi, On Wed, Dec 27, 2000 at 07:40:53PM -0600, mouring at etoh.eviladmin.org wrote: > fail using fatal()). I see one or two nice things suggestions in the > patch. I think they may want to consider either defining MAXHOSTNAME > (because it's used by a lot of software) or we can test and set a limit if > there is none. SCO 3.0 does not have MAXHOSTNAME either. So maybe it should be #ifdef'ed... gert -- Gert Doering Mobile communications ... right now writing from *Aichach* ... mobile phone: +49 177 2160221 ... or mail me: gert at greenie.muc.de From stevesk at pobox.com Sat Dec 30 06:11:36 2000 From: stevesk at pobox.com (Kevin Steves) Date: Fri, 29 Dec 2000 20:11:36 +0100 (CET) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: <20001229131751.A12662@serv01.aet.tu-cottbus.de> Message-ID: On Fri, 29 Dec 2000, Lutz Jaenicke wrote: : Hmm, I couldn't get it to run on 10.20 at all. I have installed the : latest snapshot (20001229), then performed a "slogin -2". The connection : was opened and the lastlog information was displayed, then it hangs. : "top" reports a memory usage of 85MB for sshd, which doesn't make sense : either. Oh, now I see why the system is so slow... I just received: : # ls -al /core : -rw------- 1 root root 54804480 Dec 29 13:10 /core : At this size my / partition was full... protocol 2 doesn't work on hp-ux right now. can you test with protocol 1? From Lutz.Jaenicke at aet.TU-Cottbus.DE Sat Dec 30 06:09:35 2000 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Fri, 29 Dec 2000 20:09:35 +0100 Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: ; from stevesk@pobox.com on Fri, Dec 29, 2000 at 08:11:36PM +0100 References: <20001229131751.A12662@serv01.aet.tu-cottbus.de> Message-ID: <20001229200935.A15471@serv01.aet.tu-cottbus.de> On Fri, Dec 29, 2000 at 08:11:36PM +0100, Kevin Steves wrote: > On Fri, 29 Dec 2000, Lutz Jaenicke wrote: > : Hmm, I couldn't get it to run on 10.20 at all. I have installed the > : latest snapshot (20001229), then performed a "slogin -2". The connection > : was opened and the lastlog information was displayed, then it hangs. > : "top" reports a memory usage of 85MB for sshd, which doesn't make sense > : either. Oh, now I see why the system is so slow... I just received: > : # ls -al /core > : -rw------- 1 root root 54804480 Dec 29 13:10 /core > : At this size my / partition was full... > > protocol 2 doesn't work on hp-ux right now. can you test with protocol > 1? protocol 1: sleep 10 & exit performs the "logout", then hangs approx. 10 seconds, then the connection is closed. That matches your experience. (Wasn't this actually about protocol 2? That's why I explicitly tried "2"). Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From sunil at redback.com Sat Dec 30 06:48:07 2000 From: sunil at redback.com (Sunil K. Vallamkonda) Date: Fri, 29 Dec 2000 11:48:07 -0800 (PST) Subject: openssl lib question. In-Reply-To: <20001228133137.F27359@folly> Message-ID: Hello, I am trying to use openssh with openssl lib on NetBSD. I am not a security expert, thus sending this email to the list. I am not looking for legal advice (which I will contact lawyer), but looking to get general info on what algorithms (such as RC5 etc..) in openssl are used by openssh that may need legal attention. And what are the alternatives ? I see that openssl has some patent issues. It has many ciphers and algorithms: BF_cbc_encrypt, BF_decrypt, BF_encrypt, CAST_cbc_encrypt, CAST_decrypt, CAST_encrypt, RC4, RC5_32_cbc_encrypt, RC5_32_decrypt, RC5_32_encrypt, bn_add_words, bn_div_words, bn_mul_add_words, bn_mul_comba4, bn_mul_comba8, bn_mul_words, bn_sqr_comba4, bn_sqr_comba8, bn_sqr_words, bn_sub_words, des_decrypt3, des_ede3_cbc_encrypt, des_encrypt, des_encrypt2, des_encrypt3, des_ncbc_encrypt, md5_block_asm_host_order, sha1_block_asm_data_order Which of above are legal contenders ? Are BSAFE/RSAREF part of above ? Any information/pointers is appreciated. Thank you. Sunil. From GILBERT.R.LOOMIS at saic.com Sat Dec 30 07:24:13 2000 From: GILBERT.R.LOOMIS at saic.com (Loomis, Rip) Date: Fri, 29 Dec 2000 15:24:13 -0500 Subject: Cryptography patents (was: openssl lib question.) Message-ID: <791BD3CB503DD411A6510008C7CF6477F8C309@col-581-exs01.cist.saic.com> Sunil-- Actually, you do not "see that openssl has some patent issues." You do see that OpenSSL implements many algorithms, some of which have been (at various times) been patented or encumbered in some countries. Without knowing what country you're in, none of us here can really give useful advice as to which software/algorithm patents could potentially apply. To the best of my non-legally-admissible knowledge, however, none of the algorithms in the current OpenSSL implementation are currently encumbered by patents that would restrict their use in any country. (I'll have to defer to others with more specific knowledge on this, of course). Specifically, DES, 3DES, and SHA-1 are US Government standards and (even if still under patent) are in general usable worldwide without royalties. RSAREF should no longer be required in any environment, as the primary RSA public key algorithm is now unencumbered: http://www.rsasecurity.com/news/pr/000906-1.html (In fact, if you're using RSAREF and haven't applied patches, you may be vulnerable to specific attacks.) The only patent-encumbered algorithm of which I'm aware which is included in any SSH implementation is IDEA-- which is very specifically not included in OpenSSH. Perhaps a better place to ask this question isn't on the OpenSSH list, but on one of the many official OpenSSL lists: http://www.openssl.org/support/ You could also take a quick look around on Google for pointers. It didn't take me a whole lot of searching to happen upon http://www.rsasecurity.com/rsalabs/faq/ which has a good section on the key patents affecting cryptography, or http://www.mail-archive.com/openssl-users at openssl.org/msg01425.html which is a posting to one of the OpenSSL lists regarding patents on cryptographic algorithms. Hope this helps, and Happy New Year if you choose the Gregorian calendar! Rip Loomis Voice Number: (410) 953-6874 -------------------------------------------------------- Senior Security Engineer Center for Information Security Technology Science Applications International Corporation http://www.cist.saic.com > -----Original Message----- > From: Sunil K. Vallamkonda [mailto:sunil at redback.com] > Sent: Friday, December 29, 2000 2:48 PM > To: Markus Friedl > Cc: openssh-unix-dev at mindrot.org > Subject: openssl lib question. > > > Hello, > > > I am trying to use openssh with openssl lib on > NetBSD. I am not a security expert, thus sending > this email to the list. I am not looking for > legal advice (which I will contact lawyer), but looking > to get general info on what algorithms (such as RC5 etc..) > in openssl are used by openssh that may need legal attention. > And what are the alternatives ? > > I see that openssl has some patent issues. It > has many ciphers and algorithms: > > BF_cbc_encrypt, BF_decrypt, BF_encrypt, CAST_cbc_encrypt, > CAST_decrypt, CAST_encrypt, RC4, RC5_32_cbc_encrypt, > RC5_32_decrypt, > RC5_32_encrypt, bn_add_words, bn_div_words, bn_mul_add_words, > bn_mul_comba4, bn_mul_comba8, bn_mul_words, bn_sqr_comba4, > bn_sqr_comba8, bn_sqr_words, bn_sub_words, des_decrypt3, > des_ede3_cbc_encrypt, des_encrypt, des_encrypt2, > des_encrypt3, > des_ncbc_encrypt, md5_block_asm_host_order, > sha1_block_asm_data_order > > Which of above are legal contenders ? > Are BSAFE/RSAREF part of above ? > > Any information/pointers is appreciated. > > > Thank you. > > Sunil. > > > > > > From mhw at wittsend.com Sat Dec 30 08:13:53 2000 From: mhw at wittsend.com (Michael H. Warfield) Date: Fri, 29 Dec 2000 16:13:53 -0500 Subject: [kdo@cosmos.phy.tufts.edu: protocol incompatibility between OpenSSH and SSH secure shell?] Message-ID: <20001229161353.B22369@alcove.wittsend.com> Hello all! I didn't see anyone else reply to this, but I also didn't see anything show up on the OpenSSH development list (Cc'ed here). There is a patch call out right now for the pending release of 2.4.0. I'm wondering if anyone is aware of this and if it's already been covered in 2.4.0? Please reply to list and original poster... ----- Forwarded message from Ken Olum ----- Date: Wed, 27 Dec 2000 16:19:20 -0500 From: Ken Olum To: ssh at clinet.fi Subject: protocol incompatibility between OpenSSH and SSH secure shell? Precedence: bulk I am using SSH secure shell version 2.3 under Windows 95 as the client and OpenSSH_2.3.0p1 under Red Hat 7.0 as the server. When I tell the client to forward a random incoming port the server gives the error "error: Hm, dispatch protocol error: type 80 plen 33" instead of listening on my port. Sorry if this is the wrong place to report this, or if I should have looked in some list of known problems. Ken Olum ----- End forwarded message ----- Mike -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From mouring at etoh.eviladmin.org Sat Dec 30 09:19:41 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 29 Dec 2000 16:19:41 -0600 (CST) Subject: patch to support hurd-i386 In-Reply-To: <20001229205833.B1193@greenie.muc.de> Message-ID: On Fri, 29 Dec 2000, Gert Doering wrote: > Hi, > > On Wed, Dec 27, 2000 at 07:40:53PM -0600, mouring at etoh.eviladmin.org wrote: > > fail using fatal()). I see one or two nice things suggestions in the > > patch. I think they may want to consider either defining MAXHOSTNAME > > (because it's used by a lot of software) or we can test and set a limit if > > there is none. > > SCO 3.0 does not have MAXHOSTNAME either. So maybe it should be > #ifdef'ed... > I assume that MAXHOSTNAMELEN should be the same on every platform. I just submitted a patch to define it at 64 characters if it's not found. Let me know if it should be raised, but I suspect it should be fine. - Ben From mouring at etoh.eviladmin.org Sat Dec 30 09:30:05 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 29 Dec 2000 16:30:05 -0600 (CST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: <20001229181002.A14576@serv01.aet.tu-cottbus.de> Message-ID: On Fri, 29 Dec 2000, Lutz Jaenicke wrote: > On Fri, Dec 29, 2000 at 10:49:09AM -0600, mouring at etoh.eviladmin.org wrote: > > On Fri, 29 Dec 2000, Lutz Jaenicke wrote: > > When I did the patch to split CFLAGS and CPPFLAGS I had not tested it on > > my NeXT box.. and I'm running into the same issue. However it's worse > > under NeXT. 'configure' fails because CPPFLAGS are not being honored from > > the start. > > > > So I'm not sure if it's make or the cc compiler. > > This question is easily to be answered :-) > The cc compiler does not give anything about ENVIRONMENT variables being > set or not. Different incarnations of "make" will automatically take into > account a different set of environment variables. The HP-UX make e.g. > will take into account CC and CFLAGS and will automatically use a > general rule to compile C programs to objects: > .c.o: > $(CC) $(CFLAGS) -c $< > Hence, "make" will automatically honor CC and CFLAGS but no other > flags will be recognized, especially not CPPFLAGS. > Since the common set of rules between "make" programs may not be the same, > the safest way should be to include the rule into Makefile(.in) > .c.o: > $(CC) $(CFLAGS) $(CPPFLAGS) -c $< > This way it should work for all platforms. > (Another commonly used way is to start in Makefile with something like > CFLAGS= $(CFLAGS) $(CPPFLAGS) or similar.) > That's simple enough. However if it's not being honored within 'configure' (as it is not on NeXT) then I may opt to just back out of the CPPFLAGS/CFLAGS patch. (If all that is affected is NeXT then I'll just look for a NeXT work around.) - Ben From pekkas at netcore.fi Sat Dec 30 08:33:37 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 29 Dec 2000 23:33:37 +0200 (EET) Subject: patch to support hurd-i386 In-Reply-To: Message-ID: On Fri, 29 Dec 2000 mouring at etoh.eviladmin.org wrote: > On Fri, 29 Dec 2000, Gert Doering wrote: > > > Hi, > > > > On Wed, Dec 27, 2000 at 07:40:53PM -0600, mouring at etoh.eviladmin.org wrote: > > > fail using fatal()). I see one or two nice things suggestions in the > > > patch. I think they may want to consider either defining MAXHOSTNAME > > > (because it's used by a lot of software) or we can test and set a limit if > > > there is none. > > > > SCO 3.0 does not have MAXHOSTNAME either. So maybe it should be > > #ifdef'ed... > > > I assume that MAXHOSTNAMELEN should be the same on every platform. I just > submitted a patch to define it at 64 characters if it's not found. > > Let me know if it should be raised, but I suspect it should be fine. [ Cc: cleaned a bit ] Try 'llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch.co.uk'. Seriously, I don't think it should be raised but someone is bound to bring this up sooner or later ;-) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From GILBERT.R.LOOMIS at saic.com Sat Dec 30 08:31:07 2000 From: GILBERT.R.LOOMIS at saic.com (Loomis, Rip) Date: Fri, 29 Dec 2000 16:31:07 -0500 Subject: More [A tangent on RC5] Cryptography patents (was: openssl lib question.) Message-ID: <791BD3CB503DD411A6510008C7CF6477F8C30A@col-581-exs01.cist.saic.com> I hate following up to myself, but I thought a clarification of one point (specifically WRT RC5 which was mentioned in the original question) might be worthwhile...because what I should have said originally was that "To the best of my non-legally- admissible knowledge, however, none of the algorithms in the current *OpenSSH* implementation are currently encumbered by patents that would restrict their use in any country." I definitely can't categorically discuss every algorithm which is implemented in OpenSSL. Anyway, I knew that there were issues with RC5 but was reasonably certain that they didn't impact OpenSSH. I took more of a look at some of the links I had found (and several follow-ons), and verified that: 1. A patent for RC5 was granted to RSA Data Security in March 1998 http://www.delphion.com/details?pn=US05724428__ (although RSA's website claims the patent was granted May 1997.) 2. RC6 (the AES competitor follow-on to RC5) is "proprietary of RSA Security"--and although it's not public knowledge as to whether a patent application has been submitted for RC6, I would think it likely. (The two main patents on RC5 would seem to cover RC6 as well, in the opinion of most legally-minded cryptographers. In fact, there is some reason to believe that the patents on RC5 helped cause the selection of Rijndael as the AES-designate--not because it is clearly the best, but because it is more definitively unencumbered.) 3. I can find bugger-all information (other than what's above) to be able to verify what the exact usage/licensing terms of RC5 really are for the rest of us. That would appear to be intentional, since it's RSA Security's most important remaining patent (in my very humble opinion). RSA Security would, one expects, grant a license for RC5 usage when given sufficient money. 4. It doesn't appear to matter, since OpenSSH doesn't actually use RC5. OpenSSH does allow "Arcfour", which is widely believed http://home.earthlink.net/~neilbawd/arcfour.html to be equivalent to the RSA RC4* algorithm, but does not use RC5. 5. Most importantly, the bottom of the ssh(1) clearly states at the bottom that "This version of OpenSSH has all components of a restrictive nature (i.e., patents) directly removed from the source code; any licensed or patented components are chosen from external libraries", and the OpenSSH FAQ discusses patents as well (down in questions 5 & 20): http://www.openssh.com/faq.html --so the question is for another list or lawyer, and should be phrased, "Of this list of algorithms which OpenSSH actually uses, which ones (if any) are encumbered?" I am confident that the answer is "none". If on the other hand you are using OpenSSL in another application, then the question is still for another list. [* The name RC4 is copyrighted by RSA Security and their implementation of RC4 was/is a tradesecret, but the mathematics of RC4 are not patented.] Again, hope this dissertation helps in more than just filling up your inbox-- Rip Loomis Voice Number: (410) 953-6874 -------------------------------------------------------- Senior Security Engineer Center for Information Security Technology Science Applications International Corporation http://www.cist.saic.com > -----Original Message----- > From: Loomis, Rip [mailto:GILBERT.R.LOOMIS at saic.com] > Sent: Friday, December 29, 2000 3:24 PM > To: 'Sunil K. Vallamkonda' > Cc: openssh-unix-dev at mindrot.org > Subject: Cryptography patents (was: openssl lib question.) > > > Sunil-- > Actually, you do not "see that openssl > has some patent issues." You do see that > OpenSSL implements many algorithms, some > of which have been (at various times) > been patented or encumbered in some > countries. > > Without knowing what country you're in, > none of us here can really give useful advice > as to which software/algorithm patents > could potentially apply. To the best > of my non-legally-admissible knowledge, > however, none of the algorithms in > the current OpenSSL implementation > are currently encumbered by patents > that would restrict their use in any > country. (I'll have to defer to others > with more specific knowledge on this, > of course). > > Specifically, DES, 3DES, and SHA-1 are > US Government standards and (even if > still under patent) are in general > usable worldwide without royalties. > RSAREF should no longer be required > in any environment, as the primary RSA public > key algorithm is now unencumbered: > http://www.rsasecurity.com/news/pr/000906-1.html > (In fact, if you're using RSAREF and > haven't applied patches, you may be > vulnerable to specific attacks.) > The only patent-encumbered algorithm > of which I'm aware which is included > in any SSH implementation is IDEA-- > which is very specifically not > included in OpenSSH. > > Perhaps a better place to ask this > question isn't on the OpenSSH list, > but on one of the many official > OpenSSL lists: > http://www.openssl.org/support/ > You could also take a quick look > around on Google for pointers. It > didn't take me a whole lot of searching > to happen upon > http://www.rsasecurity.com/rsalabs/faq/ > which has a good section on the key > patents affecting cryptography, or > http://www.mail-archive.com/openssl-users at openssl.org/msg01425.html > which is a posting to one of the > OpenSSL lists regarding patents on > cryptographic algorithms. > > Hope this helps, and Happy New Year if > you choose the Gregorian calendar! > > Rip Loomis Voice Number: (410) 953-6874 > -------------------------------------------------------- > Senior Security Engineer > Center for Information Security Technology > Science Applications International Corporation > http://www.cist.saic.com > > > > > -----Original Message----- > > From: Sunil K. Vallamkonda [mailto:sunil at redback.com] > > Sent: Friday, December 29, 2000 2:48 PM > > To: Markus Friedl > > Cc: openssh-unix-dev at mindrot.org > > Subject: openssl lib question. > > > > > > Hello, > > > > > > I am trying to use openssh with openssl lib on > > NetBSD. I am not a security expert, thus sending > > this email to the list. I am not looking for > > legal advice (which I will contact lawyer), but looking > > to get general info on what algorithms (such as RC5 etc..) > > in openssl are used by openssh that may need legal attention. > > And what are the alternatives ? > > > > I see that openssl has some patent issues. It > > has many ciphers and algorithms: > > > > BF_cbc_encrypt, BF_decrypt, BF_encrypt, CAST_cbc_encrypt, > > CAST_decrypt, CAST_encrypt, RC4, RC5_32_cbc_encrypt, > > RC5_32_decrypt, > > RC5_32_encrypt, bn_add_words, bn_div_words, > bn_mul_add_words, > > bn_mul_comba4, bn_mul_comba8, bn_mul_words, bn_sqr_comba4, > > bn_sqr_comba8, bn_sqr_words, bn_sub_words, des_decrypt3, > > des_ede3_cbc_encrypt, des_encrypt, des_encrypt2, > > des_encrypt3, > > des_ncbc_encrypt, md5_block_asm_host_order, > > sha1_block_asm_data_order > > > > Which of above are legal contenders ? > > Are BSAFE/RSAREF part of above ? > > > > Any information/pointers is appreciated. > > > > > > Thank you. > > > > Sunil. > > > > > > > > > > > > > From Lutz.Jaenicke at aet.TU-Cottbus.DE Sat Dec 30 08:40:01 2000 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Fri, 29 Dec 2000 22:40:01 +0100 Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Dec 29, 2000 at 04:30:05PM -0600 References: <20001229181002.A14576@serv01.aet.tu-cottbus.de> Message-ID: <20001229224001.B16235@serv01.aet.tu-cottbus.de> On Fri, Dec 29, 2000 at 04:30:05PM -0600, mouring at etoh.eviladmin.org wrote: > > .c.o: > > $(CC) $(CFLAGS) $(CPPFLAGS) -c $< > > This way it should work for all platforms. > > (Another commonly used way is to start in Makefile with something like > > CFLAGS= $(CFLAGS) $(CPPFLAGS) or similar.) > > > That's simple enough. However if it's not being honored within > 'configure' (as it is not on NeXT) then I may opt to just back out of the > CPPFLAGS/CFLAGS patch. (If all that is affected is NeXT then I'll just > look for a NeXT work around.) I don't care for either solution, as long as it works :-) It may however also be practical to fix "configure". Distinguishing between CFLAGS and CPPFLAGS is a normal practice when using autoconf. My experience is that typically "configure" manages to handle CFLAGS and CPPFLAGS consistently and then later CPPFLAGS is not used in Makefile.in... That reminds me to send an error message stating that and some things more to the author of wvware/libwmf (wordviewer for windows)... What is your problem with "configure"? Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From mouring at etoh.eviladmin.org Sat Dec 30 09:42:36 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 29 Dec 2000 16:42:36 -0600 (CST) Subject: patch to support hurd-i386 In-Reply-To: Message-ID: On Fri, 29 Dec 2000, Pekka Savola wrote: > On Fri, 29 Dec 2000 mouring at etoh.eviladmin.org wrote: > > > On Fri, 29 Dec 2000, Gert Doering wrote: > > > > > Hi, > > > > > > On Wed, Dec 27, 2000 at 07:40:53PM -0600, mouring at etoh.eviladmin.org wrote: > > > > fail using fatal()). I see one or two nice things suggestions in the > > > > patch. I think they may want to consider either defining MAXHOSTNAME > > > > (because it's used by a lot of software) or we can test and set a limit if > > > > there is none. > > > > > > SCO 3.0 does not have MAXHOSTNAME either. So maybe it should be > > > #ifdef'ed... > > > > > I assume that MAXHOSTNAMELEN should be the same on every platform. I just > > submitted a patch to define it at 64 characters if it's not found. > > > > Let me know if it should be raised, but I suspect it should be fine. > > [ Cc: cleaned a bit ] > > Try 'llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch.co.uk'. > > Seriously, I don't think it should be raised but someone is bound to bring > this up sooner or later ;-) > > Seriously, =) do we want to honor people who ssh into their vanity domains? (I know.. it's a arbrarity limit.. =) ssh mouring at The.world.is.coming.to.an.end.and.I.will.be.jumping.on.hailbob.com But I would like to see that we check ENAMETOOLONG (Would you accept a patch on that Markus?) and fatal() (or at least warn the user) at this point. - Ben From mouring at etoh.eviladmin.org Sat Dec 30 10:08:49 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 29 Dec 2000 17:08:49 -0600 (CST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: <20001229224001.B16235@serv01.aet.tu-cottbus.de> Message-ID: On Fri, 29 Dec 2000, Lutz Jaenicke wrote: > On Fri, Dec 29, 2000 at 04:30:05PM -0600, mouring at etoh.eviladmin.org wrote: > > > .c.o: > > > $(CC) $(CFLAGS) $(CPPFLAGS) -c $< > > > This way it should work for all platforms. > > > (Another commonly used way is to start in Makefile with something like > > > CFLAGS= $(CFLAGS) $(CPPFLAGS) or similar.) > > > > > That's simple enough. However if it's not being honored within > > 'configure' (as it is not on NeXT) then I may opt to just back out of the > > CPPFLAGS/CFLAGS patch. (If all that is affected is NeXT then I'll just > > look for a NeXT work around.) > > I don't care for either solution, as long as it works :-) > It may however also be practical to fix "configure". Distinguishing between > CFLAGS and CPPFLAGS is a normal practice when using autoconf. My experience > is that typically "configure" manages to handle CFLAGS and CPPFLAGS > consistently and then later CPPFLAGS is not used in Makefile.in... > That reminds me to send an error message stating that and some things more > to the author of wvware/libwmf (wordviewer for windows)... > > What is your problem with "configure"? > hmmmm.. I'll retract my comment about ./configure not working right with a split CPPFLAGS/CFLAGS. I seem to have bits of another patch I was working on causing the problems. - Ben From markus.friedl at informatik.uni-erlangen.de Sat Dec 30 09:22:01 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 29 Dec 2000 23:22:01 +0100 Subject: [kdo@cosmos.phy.tufts.edu: protocol incompatibility between OpenSSH and SSH secure shell?] In-Reply-To: <20001229161353.B22369@alcove.wittsend.com>; from mhw@wittsend.com on Fri, Dec 29, 2000 at 04:13:53PM -0500 References: <20001229161353.B22369@alcove.wittsend.com> Message-ID: <20001229232201.B30844@folly> openssh does not support rekeying (yet). perhaps openssh-2.5 will, openssh-2.4 will not. upgrading the windows client to ssh.com-2.4.0 should help. -markus On Fri, Dec 29, 2000 at 04:13:53PM -0500, Michael H. Warfield wrote: > Hello all! > > I didn't see anyone else reply to this, but I also didn't see > anything show up on the OpenSSH development list (Cc'ed here). There > is a patch call out right now for the pending release of 2.4.0. I'm > wondering if anyone is aware of this and if it's already been covered > in 2.4.0? > > Please reply to list and original poster... > > ----- Forwarded message from Ken Olum ----- > > Date: Wed, 27 Dec 2000 16:19:20 -0500 > From: Ken Olum > To: ssh at clinet.fi > Subject: protocol incompatibility between OpenSSH and SSH secure shell? > Precedence: bulk > > I am using SSH secure shell version 2.3 under Windows 95 as the > client and OpenSSH_2.3.0p1 under Red Hat 7.0 as the server. When I > tell the client to forward a random incoming port the server gives the > error "error: Hm, dispatch protocol error: type 80 plen 33" instead of > listening on my port. > > Sorry if this is the wrong place to report this, or if I should have > looked in some list of known problems. > > Ken Olum > > ----- End forwarded message ----- > > Mike > -- > Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com > (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ > NIC whois: MHW9 | An optimist believes we live in the best of all > PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! > > From vaughan99 at yahoo.com Sat Dec 30 09:10:06 2000 From: vaughan99 at yahoo.com (Chris Vaughan) Date: Fri, 29 Dec 2000 14:10:06 -0800 (PST) Subject: another possible mem leak, AIX-specific Message-ID: <20001229221006.33359.qmail@web11505.mail.yahoo.com> On AIX, the config.h generated by 'configure' sets up the following directives: #define HAVE_FREEADDRINFO 1 #define HAVE_GETADDRINFO 1 #define BROKEN_GETADDRINFO 1 This allows the compiler to use the 'getaddrinfo()' routine in fake-getaddrinfo.c, but it uses the 'freeaddrinfo()' provided by AIX. I don't think 'freeaddrinfo()' is releasing the linked list properly, because I think I'm seeing a memory leak roughly a multiple of the struct size per new channel. If I undefine HAVE_FREEADDRINFO in config.h, the memory leak seems to go away. I would solve this by having a 'BROKEN_FREEADDRINFO' flag defined for AIX, and use the same logic as when 'BROKEN_GETADDRINFO' is defined. That way, the 'freeaddrinfo()' routine from fake-getaddrinfo.c is used, as opposed to the one from AIX. - chrisv ===== ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Vaughan | "I love deadlines. I like the | swooshing sound as they fly by." vaughan99 at yahoo.com | - Douglas Adams __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ From sunilvk at netscape.net Sat Dec 30 10:06:37 2000 From: sunilvk at netscape.net (sunil vallamkonda) Date: 29 Dec 00 15:06:37 PST Subject: openSSH/openSSL question. Message-ID: <20001229230637.4074.qmail@www0i.netaddress.usa.net> Hello, Looking at: http://www.openssh.com/features.html Under 'Free Licensing' section: "any licensed or patented components are chosen from external libraries (e.g. OpenSSL)" Can someone please enlighten me which components specifically have patent/ licensing restrictions from openSSL that are being used by openSSH ? Are any of these restricted by US export laws ? Thank you. Sunil. ____________________________________________________________________ Get your own FREE, personal Netscape WebMail account today at http://home.netscape.com/webmail From djm at mindrot.org Sat Dec 30 12:08:23 2000 From: djm at mindrot.org (Damien Miller) Date: Sat, 30 Dec 2000 12:08:23 +1100 (EST) Subject: patch to support hurd-i386 In-Reply-To: Message-ID: On Fri, 29 Dec 2000 mouring at etoh.eviladmin.org wrote: > I assume that MAXHOSTNAMELEN should be the same on every platform. I just > submitted a patch to define it at 64 characters if it's not found. I feel very uneasy about this, can we define it per host (in configure.in) only after we have verified it against each implementation? I would much rather have a few platforms where compilation fails than one where we get a buffer overrun. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From djm at mindrot.org Sat Dec 30 12:15:43 2000 From: djm at mindrot.org (Damien Miller) Date: Sat, 30 Dec 2000 12:15:43 +1100 (EST) Subject: openSSH/openSSL question. In-Reply-To: <20001229230637.4074.qmail@www0i.netaddress.usa.net> Message-ID: On 29 Dec 2000, sunil vallamkonda wrote: > Hello, > > Looking at: > http://www.openssh.com/features.html > > Under 'Free Licensing' section: > > "any licensed or patented components are chosen from > external libraries (e.g. OpenSSL)" > > Can someone please enlighten me which > components specifically have patent/ > licensing restrictions from openSSL that > are being used by openSSH ? This is not legal advice. OpenSSH uses the following cryptographic primitives: DES (1DES and 3DES), Blowfish, CAST128, Rijndael, RC4, RSA, DSA, Diffie-Hellman, MD5, SHA1, HMAC. I may have missed some. > Are any of these restricted by US export laws ? Speak to a lawyer. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From Chiaki.Ishikawa at personal-media.co.jp Sat Dec 30 14:13:24 2000 From: Chiaki.Ishikawa at personal-media.co.jp (Chiaki Ishikawa) Date: Sat, 30 Dec 2000 12:13:24 +0900 (JST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: <20001229195707.A13319@folly> (markus.friedl@informatik.uni-erlangen.de) Message-ID: <200012300313.MAA09018@sparc18.personal-media.co.jp> X-PMC-CI-e-mail-id: 14371 >>>>> "|" == Markus Friedl writes: |> On Thu, Dec 28, 2000 at 04:09:07AM +0100, Kevin Steves wrote: >> On Wed, 27 Dec 2000 mouring at etoh.eviladmin.org wrote: >> : Is there any undisputed patches still out not applied to the current >> : portable CVS tree? >> >> not a patch per se but proto 2 is broken on hp-ux due to the issue with >> the SIGCHLD handler being reinstalled before a wait(). |> i think we should switch to sigaction since the sematics for |> signal() are different on every system. |> e.g. replace signal() with mysignal(): Please add handling for SA_INTERRUPT and SA_RESTART and many will be greatful for that. The mods suggested below are taken from Stevens Unix Network Programming (but can be found Advanced Unix Programming by the same author.) By the way, some people find the one-letter argument names are difficult to follow. /* include suitable headers here, ... */ /* for example, sys/signalh on sunos4 */ #include ... typedef void (*mysig_t)(int); mysig_t mysignal(int s, mysig_t a) { struct sigaction sa, osa; memset(&sa, 0, sizeof sa); sigemptyset(&sa.sa_mask); sa.sa_flags = 0; sa.sa_handler = a; /* change begins */ if(s == SIGALRM) { #ifdef SA_INTERRUPT sa.sa_flags |= SA_INTERRUPT; /* sunos 4.x */ #endif } else { #ifdef SA_RESTART sa.sa_flags |= SA_RESTART; /* svr4, 4.4bsd */ #endif } /* change ends */ /* also note the return value is SIG_ERR in Steven's book */ if (sigaction(s, &sa, &osa) < 0) return (mysig_t)SIG_ERR; return (osa.sa_handler); } |>mysignal can fallback to signal if sigaction is not available. |>with mysignal() we don't need to reinstall signalhandlers. |> |>comments? -markus -- Ishikawa, Chiaki ishikawa at personal-media.co.jp.NoSpam or (family name, given name) Chiaki.Ishikawa at personal-media.co.jp.NoSpam Personal Media Corp. ** Remove .NoSpam at the end before use ** Shinagawa, Tokyo, Japan 142-0051 From mouring at etoh.eviladmin.org Sat Dec 30 16:39:51 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 29 Dec 2000 23:39:51 -0600 (CST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: Message-ID: On Fri, 29 Dec 2000, Damien Miller wrote: > On Fri, 29 Dec 2000, Damien Miller wrote: > > > > bash-2.04$ uname -a > > > HP-UX jenny B.11.11 A 9000/800 670359383 two-user license > > > bash-2.04$ sleep 20& exit > > > [1] 13064 > > > logout > > > logout > > > Connection to jenny closed. > > > [20 seconds later] > > > > damn - can you strace it to see if/where we are blocking. On Linux we > > end up stuck in a read() on a fd which has been explicitly marked > > non-blocking, which strikes me as weird. > > Another datapoint: the grandchild processes never receive a HUP. We are > either messing up on the terminal handling or on the setting up > of pgid or sid. > I know this does not solve Protocol 1 hanging, but can you give me a reason why the following patch won't work for Protocol 2 to hang the 'sleep 30&exit' issue. It tells OpenSSH to explicitly drain the input buffers if the output buffers are closed. (Of course the same trick does not work under protocol 1 ecause channel_write_fail1() is not called soon enough.) - Ben --- ../openssh/nchan.c Mon Nov 13 05:57:26 2000 +++ nchan.c Fri Dec 29 23:19:40 2000 @@ -335,11 +335,13 @@ case CHAN_OUTPUT_OPEN: debug("channel %d: output open -> closed", c->self); chan_shutdown_write(c); /* ?? */ + c->istate = CHAN_INPUT_WAIT_DRAIN; c->ostate = CHAN_OUTPUT_CLOSED; break; case CHAN_OUTPUT_WAIT_DRAIN: debug("channel %d: output drain -> closed", c->self); chan_shutdown_write(c); + c->istate = CHAN_INPUT_WAIT_DRAIN; c->ostate = CHAN_OUTPUT_CLOSED; break; default: From markus.friedl at informatik.uni-erlangen.de Sat Dec 30 23:35:03 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 30 Dec 2000 13:35:03 +0100 Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: <200012300313.MAA09018@sparc18.personal-media.co.jp>; from Chiaki.Ishikawa@personal-media.co.jp on Sat, Dec 30, 2000 at 12:13:24PM +0900 References: <20001229195707.A13319@folly> <200012300313.MAA09018@sparc18.personal-media.co.jp> Message-ID: <20001230133503.B9008@folly> On Sat, Dec 30, 2000 at 12:13:24PM +0900, Chiaki Ishikawa wrote: > X-PMC-CI-e-mail-id: 14371 > >>>>> "|" == Markus Friedl writes: > > |> On Thu, Dec 28, 2000 at 04:09:07AM +0100, Kevin Steves wrote: > >> On Wed, 27 Dec 2000 mouring at etoh.eviladmin.org wrote: > >> : Is there any undisputed patches still out not applied to the current > >> : portable CVS tree? > >> > >> not a patch per se but proto 2 is broken on hp-ux due to the issue with > >> the SIGCHLD handler being reinstalled before a wait(). > > |> i think we should switch to sigaction since the sematics for > |> signal() are different on every system. > > |> e.g. replace signal() with mysignal(): > > Please add handling for > SA_INTERRUPT and SA_RESTART and many will be greatful > for that. why? what is the rationale? even stevens APUE has 2 versions. on with SA_RESTART and one without. > The mods suggested below are taken from > Stevens Unix Network Programming (but can be found > Advanced Unix Programming by the same author.) > By the way, some people find the one-letter argument names > are difficult to follow. > > /* include suitable headers here, ... */ > /* for example, sys/signalh on sunos4 */ > #include ... > > typedef void (*mysig_t)(int); > > mysig_t > mysignal(int s, mysig_t a) > { > struct sigaction sa, osa; > > memset(&sa, 0, sizeof sa); > sigemptyset(&sa.sa_mask); > sa.sa_flags = 0; > sa.sa_handler = a; > > /* change begins */ > if(s == SIGALRM) { > #ifdef SA_INTERRUPT > sa.sa_flags |= SA_INTERRUPT; /* sunos 4.x */ > #endif > } else { > #ifdef SA_RESTART > sa.sa_flags |= SA_RESTART; /* svr4, 4.4bsd */ > #endif > } > /* change ends */ > /* also note the return value is SIG_ERR > in Steven's book */ > > if (sigaction(s, &sa, &osa) < 0) > return (mysig_t)SIG_ERR; > return (osa.sa_handler); > } > > |>mysignal can fallback to signal if sigaction is not available. > |>with mysignal() we don't need to reinstall signalhandlers. > |> > |>comments? > > -markus > > > > -- > Ishikawa, Chiaki ishikawa at personal-media.co.jp.NoSpam or > (family name, given name) Chiaki.Ishikawa at personal-media.co.jp.NoSpam > Personal Media Corp. ** Remove .NoSpam at the end before use ** > Shinagawa, Tokyo, Japan 142-0051 > > From markus.friedl at informatik.uni-erlangen.de Sat Dec 30 23:49:34 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 30 Dec 2000 13:49:34 +0100 Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Dec 29, 2000 at 11:39:51PM -0600 References: Message-ID: <20001230134934.C9008@folly> i don't understand your change. have you looked at nchan2.ms? why should we stop reading from a socket if we no longer write to the very same socket? -markus On Fri, Dec 29, 2000 at 11:39:51PM -0600, mouring at etoh.eviladmin.org wrote: > I know this does not solve Protocol 1 hanging, but can you give me a > reason why the following patch won't work for Protocol 2 to hang the > 'sleep 30&exit' issue. It tells OpenSSH to explicitly drain the input > buffers if the output buffers are closed. (Of course the same trick does > not work under protocol 1 ecause channel_write_fail1() is not called soon > enough.) > > - Ben > > --- ../openssh/nchan.c Mon Nov 13 05:57:26 2000 > +++ nchan.c Fri Dec 29 23:19:40 2000 > @@ -335,11 +335,13 @@ > case CHAN_OUTPUT_OPEN: > debug("channel %d: output open -> closed", c->self); > chan_shutdown_write(c); /* ?? */ > + c->istate = CHAN_INPUT_WAIT_DRAIN; > c->ostate = CHAN_OUTPUT_CLOSED; > break; > case CHAN_OUTPUT_WAIT_DRAIN: > debug("channel %d: output drain -> closed", c->self); > chan_shutdown_write(c); > + c->istate = CHAN_INPUT_WAIT_DRAIN; > c->ostate = CHAN_OUTPUT_CLOSED; > break; > default: > From sunilvk at netscape.net Sun Dec 31 03:36:07 2000 From: sunilvk at netscape.net (sunil vallamkonda) Date: 30 Dec 00 08:36:07 PST Subject: [Re: openSSH/openSSL question.] Message-ID: <20001230163607.23789.qmail@ww183.netaddress.usa.net> Damien Miller wrote: On 29 Dec 2000, sunil vallamkonda wrote: > Hello, > > Looking at: > http://www.openssh.com/features.html > > Under 'Free Licensing' section: > > "any licensed or patented components are chosen from > external libraries (e.g. OpenSSL)" > > Can someone please enlighten me which > components specifically have patent/ > licensing restrictions from openSSL that > are being used by openSSH ? This is not legal advice. OpenSSH uses the following cryptographic primitives: DES (1DES and 3DES), Blowfish, CAST128, Rijndael, RC4, RSA, DSA, Diffie-Hellman, MD5, SHA1, HMAC. ^^^^^^^^^^^^^^^^^^^^^ Thank you for your email. In openSSH INSTALL, requires openSSL. The above mentioned crypto primitives are they derived from openssl library ? Also I see that: "....OpenSSH does allow "Arcfour", which is widely believed http://home.earthlink.net/~neilbawd/arcfour.html to be equivalent to the RSA RC4* algorithm, ..." does openSSH use RC4 or Arcfour ? Thank you I may have missed some. > Are any of these restricted by US export laws ? Speak to a lawyer. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org ____________________________________________________________________ Get your own FREE, personal Netscape WebMail account today at http://home.netscape.com/webmail From shorty at debian.org Sun Dec 31 03:10:23 2000 From: shorty at debian.org (Christian Kurz) Date: Sat, 30 Dec 2000 17:10:23 +0100 Subject: Failure message of configure from openssh 2.3.0p1 is wrong. Message-ID: <20001230171023.Z27861@seteuid.getuid.de> Hi, if i add --with-tcp-wrappers and --with-skey and don't have an skey-library installed configure will fail with a message telling me that I don't have libwrap installed. But after looking into config.log I see the following: |configure:6344: checking for libwrap |configure:6356: gcc -o conftest -g -O2 -Wall -I. -I. conftest.c -ldl -lnsl -lz | -lutil -lpam -lcrypto -lskey -lwrap 1>&5 |/usr/bin/ld: cannot find -lskey |collect2: ld returned 1 exit status |configure: failed program was: |#line 6346 "configure" |#include "confdefs.h" |#include | int deny_severity = 0, allow_severity = |0; |int main() { |hosts_access(0); |; return 0; } So not libwrap is missing but instead the skey library. Please change the configure error message to contain the right information. Thanks. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001230/e23106b3/attachment.bin From tim at multitalents.net Sun Dec 31 07:09:38 2000 From: tim at multitalents.net (Tim Rice) Date: Sat, 30 Dec 2000 12:09:38 -0800 (PST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: Message-ID: ... gcc -g -O2 -Wall -Dftruncate=chsize -I/usr/local/include -I/usr/local/ssl/includ e -I. -Isrc -DETCDIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DS SH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c src/com pat.c src/compat.c:35: regex.h: No such file or directory gmake: *** [compat.o] Error 1 ... SCO Open Server 3 doesn't have regex libraries. I saw in the ChangeLog file 20001014 - (bal) Corrected mistake in INSTALL in regards to GNU rx library - (bal) Add support for GNU rx library for those lacking regexp support Do we want to require installing GNU rx on systems without regex support? Or do we want to add regex to the openssh code base like in HylaFAX? -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From djm at mindrot.org Sun Dec 31 10:20:14 2000 From: djm at mindrot.org (Damien Miller) Date: Sun, 31 Dec 2000 10:20:14 +1100 (EST) Subject: [Re: openSSH/openSSL question.] In-Reply-To: <20001230163607.23789.qmail@ww183.netaddress.usa.net> Message-ID: On 30 Dec 2000, sunil vallamkonda wrote: > This is not legal advice. > > OpenSSH uses the following cryptographic primitives: > > DES (1DES and 3DES), Blowfish, CAST128, Rijndael, RC4, RSA, DSA, > Diffie-Hellman, MD5, SHA1, HMAC. > > ^^^^^^^^^^^^^^^^^^^^^ > > Thank you for your email. > > In openSSH INSTALL, requires openSSL. > The above mentioned crypto primitives are they derived from > openssl library ? These all come from the OpenSSL library. > Also I see that: > > "....OpenSSH does allow "Arcfour", > which is widely believed > http://home.earthlink.net/~neilbawd/arcfour.html > to be equivalent to the RSA RC4* > algorithm, > ..." > > does openSSH use RC4 or Arcfour ? They are the same. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From djm at mindrot.org Sun Dec 31 10:33:51 2000 From: djm at mindrot.org (Damien Miller) Date: Sun, 31 Dec 2000 10:33:51 +1100 (EST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: Message-ID: On Fri, 29 Dec 2000 mouring at etoh.eviladmin.org wrote: > I know this does not solve Protocol 1 hanging, but can you give me a > reason why the following patch won't work for Protocol 2 to hang the > 'sleep 30&exit' issue. It tells OpenSSH to explicitly drain the input > buffers if the output buffers are closed. (Of course the same trick does > not work under protocol 1 ecause channel_write_fail1() is not called soon > enough.) It doesn't work - it brings back the loss of data problem where the fd from the client is closed before all the data has been read: [djm at mothra openssh]$ ./ssh -p 2222 localhost "dd if=/dev/zero bs=10240 count=10" | wc -c select: Bad file descriptor 71680 -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From djm at mindrot.org Sun Dec 31 10:43:10 2000 From: djm at mindrot.org (Damien Miller) Date: Sun, 31 Dec 2000 10:43:10 +1100 (EST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: Message-ID: On Sat, 30 Dec 2000, Tim Rice wrote: > SCO Open Server 3 doesn't have regex libraries. > > I saw in the ChangeLog file > 20001014 > - (bal) Corrected mistake in INSTALL in regards to GNU rx library > - (bal) Add support for GNU rx library for those lacking regexp support > > Do we want to require installing GNU rx on systems without regex support? > Or do we want to add regex to the openssh code base like in HylaFAX? I am not keen to add regex code to portable OpenSSH. The regex code is fairly large (~100k) and, unlike the other replacement code that has already been included, is readily available in library form. You can use GNU regex or the PCRE library[1] -d [1] ftp://ftp.cus.cam.ac.uk/pub/software/programs/pcre/ -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From tim at multitalents.net Sun Dec 31 10:53:24 2000 From: tim at multitalents.net (Tim Rice) Date: Sat, 30 Dec 2000 15:53:24 -0800 (PST) Subject: MAXHOSTNAMELEN Message-ID: ChangeLog 20001230 - (bal) if no MAXHOSTNAMELEN is defined. Default to 64 character defination. Suggested by Christian Kurz This change causes compiler warnings on UnixWare 7, Solaris 7, others? ... gcc -g -O2 -Wall -I/usr/local/include -I/usr/local/ssl/include -I. -Isrc -DETCDI R=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DEFAULT= \"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c src/bsd-arc4random.c In file included from src/includes.h:59, from src/bsd-arc4random.c:25: /usr/include/netdb.h:302: warning: `MAXHOSTNAMELEN' redefined src/defines.h:82: warning: this is the location of the previous definition ... Perhaps defines.h should have #ifdef HAVE_NETDB_H # include #endif -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Sun Dec 31 11:04:04 2000 From: tim at multitalents.net (Tim Rice) Date: Sat, 30 Dec 2000 16:04:04 -0800 (PST) Subject: utime() -> utimes() Message-ID: ChangeLog says - markus at cvs.openbsd.org 2000/09/21 05:11:42 scp.c utime() to utimes(); mouring at pconline.com SCO's Open Server 3 does not have utimes. ... gcc -o scp scp.o -L. -L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/ssl -ls sh -lopenbsd-compat -lz -lsocket -lgen -lsocket -los -lprot -lx -ltinfo -lm -lc rypto undefined first referenced symbol in file utimes scp.o ld fatal: Symbol referencing errors. No output written to scp gmake: *** [scp] Error 1 ... -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Sun Dec 31 13:12:17 2000 From: tim at multitalents.net (Tim Rice) Date: Sat, 30 Dec 2000 18:12:17 -0800 (PST) Subject: Anonymous CVS, Snapshot mirrors available In-Reply-To: Message-ID: On Wed, 27 Dec 2000, Damien Miller wrote: > On Tue, 26 Dec 2000, Tim Rice wrote: > > > On Thu, 14 Dec 2000, Damien Miller wrote: > > > > > On Wed, 13 Dec 2000, Gert Doering wrote: > > > > ... ah! Found it: config.h.in depends on running running "autoheader". > > > > > > > > Hmm. > > > > > > > > Is there a way to automate running "autoconf" and "autoheader"? Any > > > > makefile tricks that I do not know yet? > > > > > > make -f Makefile.in distprep > > > > tim(trr)@uw213 44% gmake -f Makefile.in distprep > > UX:sh (/bin/sh): ERROR: Bad substitution > > gmake: *** [catman-do] Error 1 > > > > Do I detect some bash dependencies? > > Yep :) The 'catman-do' target uses some bashisms. That helps. Now if nroff -mandoc was portable. > > I will commit this in a moment: > > Index: Makefile.in > =================================================================== > RCS file: /var/cvs/openssh/Makefile.in,v > retrieving revision 1.126 > diff -u -r1.126 Makefile.in > --- Makefile.in 2000/12/22 20:27:44 1.126 > +++ Makefile.in 2000/12/27 05:43:35 > @@ -127,9 +127,10 @@ > > catman-do: > @for f in $(TROFFMAN) ; do \ > - echo "$$f -> $${f%%.[18]}.0" ; \ > + base=`echo $$f | sed 's/\..*$$//'` ; \ > + echo "$$f -> $$base.0" ; \ > nroff -mandoc $$f | cat -v | sed -e 's/.\^H//g' \ > - >$${f%%.[18]}.0 ; \ > + >$$base.0 ; \ > done > > distprep: catman-do > > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Sun Dec 31 13:45:00 2000 From: tim at multitalents.net (Tim Rice) Date: Sat, 30 Dec 2000 18:45:00 -0800 (PST) Subject: SCO OpenServer 5.0.5 port In-Reply-To: Message-ID: On Thu, 14 Dec 2000, Damien Miller wrote: > On Wed, 13 Dec 2000, Tim Rice wrote: > > > On Thu, 14 Dec 2000 mouring at etoh.eviladmin.org wrote: > > > > > Damien backed out of required 64bit integers. So the current 2.3.0 > > > snapshots should compile under SCO w/ a native compiler minus sftp-server > > > which requires 64bit integers. > > > > Cool, I'll try and find time this weekend to check out the CVS and > > give it a try. > > You may need to "make -k" (ignore errors) or equivalent to get > ssh{,d}_config built - there is no autoconf logic to disable building > of sftp-server, so compilation will fail. Here is a patch to skip building sftp-server if there are no 64bit data types. It also has some UnixWare 2.x fixes. > > -d > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- Makefile.in.old Sat Dec 30 11:17:04 2000 +++ Makefile.in Sat Dec 30 15:27:44 2000 @@ -33,7 +33,9 @@ INSTALL_SSH_PRNG_CMDS=@INSTALL_SSH_PRNG_CMDS@ -TARGETS=ssh$(EXEEXT) sshd$(EXEEXT) ssh-add$(EXEEXT) ssh-keygen$(EXEEXT) ssh-keyscan${EXEEXT} ssh-agent$(EXEEXT) scp$(EXEEXT) sftp-server$(EXEEXT) + at NO_64BIT_TYPE@SFTP-SERVER=sftp-server$(EXEEXT) + +TARGETS=ssh$(EXEEXT) sshd$(EXEEXT) ssh-add$(EXEEXT) ssh-keygen$(EXEEXT) ssh-keyscan${EXEEXT} ssh-agent$(EXEEXT) scp$(EXEEXT) $(SFTP-SERVER) LIBSSH_OBJS=atomicio.o authfd.o authfile.o bufaux.o buffer.o canohost.o channels.o cipher.o cli.o compat.o compress.o crc32.o cygwin_util.o deattack.o dispatch.o hmac.o hostfile.o key.o kex.o log.o match.o mpaux.o nchan.o packet.o radix.o rijndael.o entropy.o readpass.o rsa.o ssh-dss.o ssh-rsa.o tildexpand.o ttymodes.o uidswap.o util.o uuencode.o xmalloc.o @@ -106,8 +108,8 @@ ssh-keyscan$(EXEEXT): libopenbsd-compat.a libssh.a log-client.o ssh-keyscan.o $(LD) -o $@ ssh-keyscan.o log-client.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) -sftp-server$(EXEEXT): libopenbsd-compat.a libssh.a sftp-server.o log-server.o - $(LD) -o $@ sftp-server.o log-server.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) + at NO_64BIT_TYPE@sftp-server$(EXEEXT): libopenbsd-compat.a libssh.a sftp-server.o log-server.o + at NO_64BIT_TYPE@ $(LD) -o $@ sftp-server.o log-server.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) # test driver for the loginrec code - not built by default logintest: logintest.o libopenbsd-compat.a libssh.a log-client.o loginrec.o @@ -155,7 +157,7 @@ $(INSTALL) -m 0755 -s ssh-keygen $(DESTDIR)$(bindir)/ssh-keygen $(INSTALL) -m 0775 -s ssh-keyscan $(DESTDIR)$(bindir)/ssh-keyscan $(INSTALL) -m 0755 -s sshd $(DESTDIR)$(sbindir)/sshd - $(INSTALL) -m 0755 -s sftp-server $(DESTDIR)$(libexecdir)/sftp-server + at NO_64BIT_TYPE@ $(INSTALL) -m 0755 -s sftp-server $(DESTDIR)$(libexecdir)/sftp-server $(INSTALL) -m 644 ssh.[01].out $(DESTDIR)$(mandir)/$(mansubdir)1/ssh.1 $(INSTALL) -m 644 scp.[01].out $(DESTDIR)$(mandir)/$(mansubdir)1/scp.1 $(INSTALL) -m 644 ssh-add.[01].out $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-add.1 --- configure.in.old Sat Dec 30 11:17:11 2000 +++ configure.in Sat Dec 30 15:21:49 2000 @@ -188,7 +188,6 @@ LDFLAGS="$LDFLAGS -L/usr/local/lib" MANTYPE='$(CATMAN)' mansubdir=cat - LIBS="$LIBS -lgen -lsocket -lnsl -lresolv" enable_suid_ssh=no ;; *-*-sysv5*) @@ -196,7 +195,6 @@ LDFLAGS="$LDFLAGS -L/usr/local/lib" MANTYPE='$(CATMAN)' mansubdir=cat - LIBS="$LIBS -lgen -lsocket" enable_suid_ssh=no ;; *-*-sysv*) @@ -219,13 +217,14 @@ rsh_path="/usr/bin/rcmd" AC_DEFINE(HAVE_SCO_PROTECTED_PW) AC_DEFINE(DISABLE_SHADOW) + AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) ;; *-*-sco3.2v5*) CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib" MANTYPE='$(CATMAN)' mansubdir=cat - LIBS="$LIBS -lgen -lsocket -lprot -lx -ltinfo -lm" + LIBS="$LIBS -lprot -lx -ltinfo -lm" no_dev_ptmx=1 rsh_path="/usr/bin/rcmd" AC_DEFINE(HAVE_SCO_PROTECTED_PW) @@ -284,6 +283,14 @@ # Checks for libraries. +if test -z "$no_libsocket" ; then + AC_CHECK_LIB(nsl, yp_match, , ) +fi +if test -z "$no_libnsl" ; then + AC_CHECK_LIB(socket, main, , ) +fi + +AC_CHECK_LIB(gen, getspnam, LIBS="$LIBS -lgen") AC_CHECK_LIB(z, deflate, ,AC_MSG_ERROR([*** zlib missing - please install first ***])) AC_CHECK_LIB(util, login, AC_DEFINE(HAVE_LIBUTIL_LOGIN) LIBS="$LIBS -lutil") @@ -295,12 +302,13 @@ ] ) -if test -z "$no_libsocket" ; then - AC_CHECK_LIB(nsl, yp_match, , ) -fi -if test -z "$no_libnsl" ; then - AC_CHECK_LIB(socket, main, , ) -fi +dnl UnixWare 2.x +AC_CHECK_FUNC(strcasecmp, + [], [ AC_CHECK_LIB(resolv, strcasecmp, LIBS="$LIBS -lresolv") ] +) +AC_CHECK_FUNC(utimes, + [], [ AC_CHECK_LIB(c89, utimes, LIBS="$LIBS -lc89") ] +) # Checks for header files. AC_CHECK_HEADERS(bstring.h endian.h floatingpoint.h getopt.h lastlog.h limits.h login.h login_cap.h maillock.h netdb.h netgroup.h netinet/in_systm.h paths.h poll.h pty.h shadow.h security/pam_appl.h sys/bitypes.h sys/bsdtty.h sys/cdefs.h sys/poll.h sys/queue.h sys/select.h sys/stat.h sys/stropts.h sys/sysmacros.h sys/time.h sys/ttcompat.h sys/un.h stddef.h time.h ttyent.h usersec.h util.h utmp.h utmpx.h vis.h) @@ -801,6 +809,13 @@ AC_DEFINE(HAVE_STRUCT_ADDRINFO) fi +if test "x$ac_cv_have_int64_t" = "xno" -a \ + "x$ac_cv_sizeof_long_int" != "x8" -a \ + "x$ac_cv_sizeof_long_long_int" = "x0" ; then + NO_64BIT_TYPE='#' + AC_SUBST(NO_64BIT_TYPE) +fi + dnl Checks for structure members OSSH_CHECK_HEADER_FOR_FIELD(ut_host, utmp.h, HAVE_HOST_IN_UTMP) OSSH_CHECK_HEADER_FOR_FIELD(ut_host, utmpx.h, HAVE_HOST_IN_UTMPX) From mouring at etoh.eviladmin.org Sun Dec 31 19:01:22 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 31 Dec 2000 02:01:22 -0600 (CST) Subject: utime() -> utimes() In-Reply-To: Message-ID: It's rather a simple matter of providing a utimes() support via utime(). utime() tends to be a bit more portable. If you write up a bsd-utimes.[ch] I'll be happy to include it. On Sat, 30 Dec 2000, Tim Rice wrote: > > ChangeLog says > - markus at cvs.openbsd.org 2000/09/21 05:11:42 > scp.c > utime() to utimes(); mouring at pconline.com > > SCO's Open Server 3 does not have utimes. > ... > gcc -o scp scp.o -L. -L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/ssl -ls > sh -lopenbsd-compat -lz -lsocket -lgen -lsocket -los -lprot -lx -ltinfo -lm -lc > rypto > undefined first referenced > symbol in file > utimes scp.o > ld fatal: Symbol referencing errors. No output written to scp > gmake: *** [scp] Error 1 > ... > > From mouring at etoh.eviladmin.org Sun Dec 31 19:04:54 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 31 Dec 2000 02:04:54 -0600 (CST) Subject: MAXHOSTNAMELEN In-Reply-To: Message-ID: I'm removing it right now. If you have a platform that requires it then include it in your configure.in section. - Ben On Sat, 30 Dec 2000, Tim Rice wrote: > > ChangeLog > 20001230 > - (bal) if no MAXHOSTNAMELEN is defined. Default to 64 character defination. > Suggested by Christian Kurz > > This change causes compiler warnings on UnixWare 7, Solaris 7, others? > ... > gcc -g -O2 -Wall -I/usr/local/include -I/usr/local/ssl/include -I. -Isrc -DETCDI > R=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DEFAULT= > \"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c src/bsd-arc4random.c > In file included from src/includes.h:59, > from src/bsd-arc4random.c:25: > /usr/include/netdb.h:302: warning: `MAXHOSTNAMELEN' redefined > src/defines.h:82: warning: this is the location of the previous definition > ... > > Perhaps defines.h should have > #ifdef HAVE_NETDB_H > # include > #endif > > From mouring at etoh.eviladmin.org Sun Dec 31 19:06:18 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 31 Dec 2000 02:06:18 -0600 (CST) Subject: OpenSSH 2.4.0 patch call.. In-Reply-To: Message-ID: On Sat, 30 Dec 2000, Tim Rice wrote: > ... > gcc -g -O2 -Wall -Dftruncate=chsize -I/usr/local/include -I/usr/local/ssl/includ > e -I. -Isrc -DETCDIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DS > SH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c src/com > pat.c > src/compat.c:35: regex.h: No such file or directory > gmake: *** [compat.o] Error 1 > ... > > SCO Open Server 3 doesn't have regex libraries. > > I saw in the ChangeLog file > 20001014 > - (bal) Corrected mistake in INSTALL in regards to GNU rx library > - (bal) Add support for GNU rx library for those lacking regexp support > > Do we want to require installing GNU rx on systems without regex support? > Or do we want to add regex to the openssh code base like in HylaFAX? > > NeXTStep also lacks a sane Regex implemented. I suggest install PCRE. I don't think forking our own regex is a good idea. It's more then just a 'few' lines of code. =) - Ben From mouring at etoh.eviladmin.org Sun Dec 31 19:20:04 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 31 Dec 2000 02:20:04 -0600 (CST) Subject: Failure message of configure from openssh 2.3.0p1 is wrong. In-Reply-To: <20001230171023.Z27861@seteuid.getuid.de> Message-ID: On Sat, 30 Dec 2000, Christian Kurz wrote: > Hi, > > if i add --with-tcp-wrappers and --with-skey and don't have an > skey-library installed configure will fail with a message telling me > that I don't have libwrap installed. But after looking into config.log I > see the following: > I get an error out if --with-skey fails to find the s/key libraries from the current CVS tree when it checks for the s/key libraries. 2.3.0p1 was released on 11/06/2000. I did an --with-skey update on 11/10/2000 which lets you define the path of the library in --with-skey that also included a patch to make --with-skey work under the OpenSSH portable (before this release it was broken). *PLEASE* can we do us a favor and verify some of these problems with a newer version? A lot of what you've brought up has been fixed for almost a month or more. =) Thanks. I think we really do need a 2.4.0 release soon.=) - Ben From shorty at debian.org Sun Dec 31 21:13:34 2000 From: shorty at debian.org (Christian Kurz) Date: Sun, 31 Dec 2000 11:13:34 +0100 Subject: Failure message of configure from openssh 2.3.0p1 is wrong. In-Reply-To: References: <20001230171023.Z27861@seteuid.getuid.de> Message-ID: <20001231111334.E27861@seteuid.getuid.de> On 00-12-31 mouring at etoh.eviladmin.org wrote: > On Sat, 30 Dec 2000, Christian Kurz wrote: > > if i add --with-tcp-wrappers and --with-skey and don't have an > > skey-library installed configure will fail with a message telling me > > that I don't have libwrap installed. But after looking into config.log I > > see the following: > I get an error out if --with-skey fails to find the s/key libraries from > the current CVS tree when it checks for the s/key libraries. That sounds like the correct error message. > 2.3.0p1 was released on 11/06/2000. I did an --with-skey update on > 11/10/2000 which lets you define the path of the library in --with-skey > that also included a patch to make --with-skey work under the OpenSSH > portable (before this release it was broken). Ah, so this update is not in the release included. :( > *PLEASE* can we do us a favor and verify some of these problems with a > newer version? A lot of what you've brought up has been fixed for almost > a month or more. =) Thanks. I can do some of it now, but mostly all stuff that I send you is still a bug in the openssh from cvs (last check out was last weekend). I just reported this bug here, because I think it may confuse some more users. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001231/7b885c44/attachment.bin From gert at greenie.muc.de Sun Dec 31 23:45:16 2000 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 31 Dec 2000 13:45:16 +0100 Subject: utime() -> utimes() In-Reply-To: ; from mouring@etoh.eviladmin.org on Sun, Dec 31, 2000 at 02:01:22AM -0600 References: Message-ID: <20001231134516.B4253@greenie.muc.de> Hi, On Sun, Dec 31, 2000 at 02:01:22AM -0600, mouring at etoh.eviladmin.org wrote: > It's rather a simple matter of providing a utimes() support via > utime(). > > utime() tends to be a bit more portable. If you write up a > bsd-utimes.[ch] I'll be happy to include it. >From the man pages that I have, utime() seems to be portable while utimes() is a BSD-ism. So why not change scp.c back to using utime()? >From looking at the code, using utimes() doesn't bring any benefits, as the tv[].tv_usec is set to "0" anyway. gert -- Gert Doering Mobile communications ... right now writing from *Aichach* ... mobile phone: +49 177 2160221 ... or mail me: gert at greenie.muc.de