From mw at moni.msci.memphis.edu Wed Nov 1 03:39:53 2000 From: mw at moni.msci.memphis.edu (Mate Wierdl) Date: Tue, 31 Oct 2000 10:39:53 -0600 Subject: offtopic--using rbl Message-ID: <20001031103953.F4666@moni.msci.memphis.edu> I just read about the webpage http://www.summersault.com/chris/techno/qmail/qmail-antispam.html on the qmail list. This makes it possible to use RBL on a per user basis. Perhaps somebody can adopt this for Postfix and mailman---or whatever is used to manage this list? Mate From pekkas at netcore.fi Wed Nov 1 04:33:32 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 31 Oct 2000 19:33:32 +0200 (EET) Subject: RhostsAuthentication + nondefault port doesn't work? In-Reply-To: <20001031155457.A25643@faui02.informatik.uni-erlangen.de> Message-ID: On Tue, 31 Oct 2000, Markus Friedl wrote: > i have not looked into this. > perhaps a bug, perhaps a feature inherited from ssh-1.2.12. > > On Tue, Oct 31, 2000 at 03:27:39PM +0200, Pekka Savola wrote: > > On Tue, 31 Oct 2000, Markus Friedl wrote: > > > > > try a serverport below 1024. > > > does this work? > > > > Yes. > > > > I'm not sure if this is an (old?) intentional "security measure". Even if > > some evil user ran sshd on some non-privileged port, the authentication > > would have to happen with root privileges anyway.. Yes. This is an obsolete check from ssh-1.2.12. It only proves the server was started as root, but root can have servers running on other ports too (e.g. 2022 for debugging :). Anyway, there are other authorization methods which deal with this. Also, it seems this check has been removed in newer "commercial" ssh versions too. The patch attached will fix the problem, and also make sshd a little more informative about what it's doing. What are those verbose levels for anyway if they're not used ;-) -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" -------------- next part -------------- --- sshconnect.c.orig Sat Sep 23 09:15:57 2000 +++ sshconnect.c Tue Oct 31 18:33:16 2000 @@ -249,9 +249,9 @@ /* Create a socket for connecting. */ sock = ssh_create_socket(original_real_uid, #ifdef HAVE_CYGWIN - !anonymous && port < IPPORT_RESERVED, + !anonymous, #else - !anonymous && geteuid() == 0 && port < IPPORT_RESERVED, + !anonymous && geteuid() == 0, #endif ai->ai_family); if (sock < 0) --- sshd.c.orig Sat Oct 14 08:23:13 2000 +++ sshd.c Tue Oct 31 18:57:21 2000 @@ -1065,6 +1065,7 @@ */ if (remote_port >= IPPORT_RESERVED || remote_port < IPPORT_RESERVED / 2) { + debug("Rhosts Authentication methods disabled, originating port not trusted."); options.rhosts_authentication = 0; options.rhosts_rsa_authentication = 0; } --- ssh.c.orig Sat Oct 28 06:19:58 2000 +++ ssh.c Tue Oct 31 19:17:31 2000 @@ -590,6 +590,7 @@ #else if (original_effective_uid != 0 || !options.use_privileged_port) { #endif + debug("Rhosts Authentication methods disabled, originating port will not be trusted."); options.rhosts_authentication = 0; options.rhosts_rsa_authentication = 0; } From pekkas at netcore.fi Wed Nov 1 04:47:57 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 31 Oct 2000 19:47:57 +0200 (EET) Subject: offtopic--using rbl In-Reply-To: <20001031103953.F4666@moni.msci.memphis.edu> Message-ID: On Tue, 31 Oct 2000, Mate Wierdl wrote: > I just read about the webpage > > http://www.summersault.com/chris/techno/qmail/qmail-antispam.html > > on the qmail list. This makes it possible to use RBL on a per user > basis. Perhaps somebody can adopt this for Postfix and mailman---or > whatever is used to manage this list? IMO, it's not that this list gets spammed too often. I don't remember that happing once. -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From mw at moni.msci.memphis.edu Wed Nov 1 04:59:45 2000 From: mw at moni.msci.memphis.edu (Mate Wierdl) Date: Tue, 31 Oct 2000 11:59:45 -0600 Subject: offtopic--using rbl In-Reply-To: ; from pekkas@netcore.fi on Tue, Oct 31, 2000 at 07:47:57PM +0200 References: <20001031103953.F4666@moni.msci.memphis.edu> Message-ID: <20001031115945.B8835@moni.msci.memphis.edu> On Tue, Oct 31, 2000 at 07:47:57PM +0200, Pekka Savola wrote: > On Tue, 31 Oct 2000, Mate Wierdl wrote: > > I just read about the webpage > > > > http://www.summersault.com/chris/techno/qmail/qmail-antispam.html > > > > on the qmail list. This makes it possible to use RBL on a per user > > basis. Perhaps somebody can adopt this for Postfix and mailman---or > > whatever is used to manage this list? > > IMO, it's not that this list gets spammed too often. I don't remember > that happing once. It did back then, and if I recall correctly we were asked if anybody knew how to make Postfix and majordomo(?) work with RBL without setting RBL lookups systemwide. Mate From djm at mindrot.org Wed Nov 1 09:29:40 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 1 Nov 2000 09:29:40 +1100 (EST) Subject: offtopic--using rbl In-Reply-To: <20001031115945.B8835@moni.msci.memphis.edu> Message-ID: On Tue, 31 Oct 2000, Mate Wierdl wrote: > It did back then, and if I recall correctly we were asked if anybody > knew how to make Postfix and majordomo(?) work with RBL without > setting RBL lookups systemwide. The list has had about 3 spam emails sent in its life. OTOH there have been about 9 messages discussing how to deal with the spam. Which is more distracting? -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 Wed Nov 1 04:11:56 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Tue, 31 Oct 2000 18:11:56 +0100 Subject: Compatibility with 1.2.16 (commercial)? In-Reply-To: <200010301923.LAA86810@garnet.juniper.net>; from mdb@juniper.net on Mon, Oct 30, 2000 at 11:23:17AM -0800 References: <200010301923.LAA86810@garnet.juniper.net> Message-ID: <20001031181156.A10541@folly> On Mon, Oct 30, 2000 at 11:23:17AM -0800, Mark D. Baushke wrote: > There is no good reason that an OpenSSH client should not be able to > speak to a 1.4 protocol ssh server. well, openssh does not support 1.4 so the client should fall back to 1.3, could you please try this: Index: sshconnect.c =================================================================== RCS file: /home/markus/cvs/ssh/sshconnect.c,v retrieving revision 1.79 diff -u -r1.79 sshconnect.c --- sshconnect.c 2000/09/17 15:52:51 1.79 +++ sshconnect.c 2000/10/31 17:11:02 @@ -313,6 +313,7 @@ int remote_major, remote_minor, i, mismatch; int connection_in = packet_get_connection_in(); int connection_out = packet_get_connection_out(); + int minor1 = PROTOCOL_MINOR_1; /* Read other side\'s version identification. */ for (;;) { @@ -366,9 +367,10 @@ } if (remote_minor < 3) { fatal("Remote machine has too old SSH software version."); - } else if (remote_minor == 3) { + } else if (remote_minor == 3 || remote_minor == 4) { /* We speak 1.3, too. */ enable_compat13(); + minor1 = 3; if (options.forward_agent) { log("Agent forwarding disabled for protocol 1.3"); options.forward_agent = 0; @@ -394,7 +396,7 @@ /* Send our own protocol version identification. */ snprintf(buf, sizeof buf, "SSH-%d.%d-%.100s\n", compat20 ? PROTOCOL_MAJOR_2 : PROTOCOL_MAJOR_1, - compat20 ? PROTOCOL_MINOR_2 : PROTOCOL_MINOR_1, + compat20 ? PROTOCOL_MINOR_2 : minor1, SSH_VERSION); if (atomicio(write, connection_out, buf, strlen(buf)) != strlen(buf)) fatal("write: %.100s", strerror(errno)); From mstone at cs.loyola.edu Fri Nov 3 06:15:59 2000 From: mstone at cs.loyola.edu (Michael Stone) Date: Thu, 2 Nov 2000 14:15:59 -0500 Subject: misc. minor patches Message-ID: <20001102141559.O32037@justice.loyola.edu> I've had these laying about for a while, can't remember whether I sent them before. diff -u openssh-2.1.1p1.orig/entropy.c openssh-2.1.1p1/entropy.c --- openssh-2.1.1p1.orig/entropy.c Wed Jun 7 08:20:23 2000 +++ openssh-2.1.1p1/entropy.c Thu Jun 15 13:58:25 2000 @@ -201,7 +201,9 @@ total_entropy_estimate += stir_gettimeofday(1.0); total_entropy_estimate += stir_clock(0.2); +#ifdef HAVE_GETRUSAGE total_entropy_estimate += stir_rusage(RUSAGE_SELF, 2.0); +#endif return(total_entropy_estimate); } @@ -247,8 +249,10 @@ /* Execution times should be a little unpredictable */ total_entropy_estimate += stir_gettimeofday(0.05); total_entropy_estimate += stir_clock(0.05); +#ifdef HAVE_GETRUSAGE total_entropy_estimate += stir_rusage(RUSAGE_SELF, 0.1); total_entropy_estimate += stir_rusage(RUSAGE_CHILDREN, 0.1); +#endif } else { #ifdef DEBUG_ENTROPY debug("Command '%s' disabled (badness %d)", diff -u openssh-2.1.1p1.orig/packet.c openssh-2.1.1p1/packet.c --- openssh-2.1.1p1.orig/packet.c Wed May 17 08:53:35 2000 +++ openssh-2.1.1p1/packet.c Tue Jun 20 16:39:00 2000 @@ -356,7 +356,7 @@ char buf[9]; buffer_clear(&outgoing_packet); - memset(buf, 0, 8); + memset(buf, 0, 9); buf[8] = type; buffer_append(&outgoing_packet, buf, 9); } From wpilorz at bdk.pl Fri Nov 3 19:53:40 2000 From: wpilorz at bdk.pl (Wojtek Pilorz) Date: Fri, 3 Nov 2000 09:53:40 +0100 (CET) Subject: misc. minor patches In-Reply-To: <20001102141559.O32037@justice.loyola.edu> Message-ID: On Thu, 2 Nov 2000, Michael Stone wrote: > Date: Thu, 2 Nov 2000 14:15:59 -0500 > From: Michael Stone > To: openssh-unix-dev at mindrot.org > Subject: misc. minor patches > > I've had these laying about for a while, can't remember whether I sent > them before. > > diff -u openssh-2.1.1p1.orig/entropy.c openssh-2.1.1p1/entropy.c [...] > > diff -u openssh-2.1.1p1.orig/packet.c openssh-2.1.1p1/packet.c > --- openssh-2.1.1p1.orig/packet.c Wed May 17 08:53:35 2000 > +++ openssh-2.1.1p1/packet.c Tue Jun 20 16:39:00 2000 > @@ -356,7 +356,7 @@ > char buf[9]; > > buffer_clear(&outgoing_packet); > - memset(buf, 0, 8); > + memset(buf, 0, 9); Why this change if the last byte of buf is set in the next line? > buf[8] = type; > buffer_append(&outgoing_packet, buf, 9); > } > > > Regards, Wojtek From mstone at cs.loyola.edu Fri Nov 3 23:16:05 2000 From: mstone at cs.loyola.edu (Michael Stone) Date: Fri, 3 Nov 2000 07:16:05 -0500 Subject: misc. minor patches In-Reply-To: ; from wpilorz@bdk.pl on Fri, Nov 03, 2000 at 09:53:40AM +0100 References: <20001102141559.O32037@justice.loyola.edu> Message-ID: <20001103071605.Q32037@justice.loyola.edu> On Fri, Nov 03, 2000 at 09:53:40AM +0100, Wojtek Pilorz wrote: > Why this change if the last byte of buf is set in the next line? As I already mentioned to someone else, it was afternoon brain fade. I picked it off the pile without really looking at it. -- Mike Stone From gert at greenie.muc.de Sat Nov 4 03:11:19 2000 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 3 Nov 2000 17:11:19 +0100 Subject: Another shapshot In-Reply-To: ; from Damien Miller on Sat, Oct 28, 2000 at 11:53:10PM +1100 References: Message-ID: <20001103171119.C13824@greenie.muc.de> Hi, On Sat, Oct 28, 2000 at 11:53:10PM +1100, Damien Miller wrote: > I have just uploaded another snapshot to: > > http://www.mindrot.org/misc/openssh/openssh-SNAP-20001028.tar.gz > > Please test this one extra hard, it is likely to become 2.3.0p1 early > next week. OK, gave it another "go" on AIX 4.3.3. Without s/key, everything looks fine. With s/key, things fall apart: gcc -o sshd sshd.o auth.o auth1.o auth2.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 -L. -L/gnu/lib -L/gnulocal/lib -L/usr/local/lib -L/gnu/lib -L/gnu -lssh -lopenbsd-compat -lnsl -lz -lcrypto -lskey ld: 0711-317 ERROR: Undefined symbol: .auth2_skey ld: 0711-317 ERROR: Undefined symbol: .skey_fake_keyinfo ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status - from browsing through the sources and s/key sources, it seems as if auth2_skey and skey_fake_keyinfo should be defined in OpenSSH somewhere, but are not. Is that correct? If yes, how to fix it? I use the skey-1.1 package from .su which claims to be a direct port from the OpenSSH skey sources. configure outputs the following: OpenSSH configured has been configured with the following options. User binaries: /gnu/bin User binaries: /gnu/bin System binaries: /gnu/sbin Configuration files: /etc Askpass program: /gnu/libexec/ssh-askpass Manual pages: /gnu/man/catX PID file: /etc Random number collection: EGD (/dtmp/egd.entropy) Manpage format: cat PAM support: no KerberosIV support: no AFS support: no S/KEY support: yes 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: no Host: rs6000-ibm-aix4.3.3.0 Compiler: gcc Compiler flags: -O -I/gnu/include -I/gnulocal/include -Wall -I. -I. -I/usr/local/include -I/gnu/include Linker flags: -L/gnu/lib -L/gnulocal/lib -L/usr/local/lib -L/gnu/lib -L/gnu Libraries: -lnsl -lz -lcrypto -lskey regards, 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 roth at feep.net Sat Nov 4 03:43:51 2000 From: roth at feep.net (Mark D. Roth) Date: Fri, 3 Nov 2000 10:43:51 -0600 Subject: Minor fixes for openssh-SNAP-20001028 In-Reply-To: <20001030151615.A14498@enterprise.isdn.uiuc.edu>; from roth@feep.net on Mon, Oct 30, 2000 at 03:16:15PM -0600 References: <20001030151615.A14498@enterprise.isdn.uiuc.edu> Message-ID: <20001103104351.A22338@enterprise.isdn.uiuc.edu> On Mon Oct 30 15:16 2000 -0600, Mark D. Roth wrote: > I've attached a patch for openssh-SNAP-20001028 which fixes the > following two problems: I haven't gotten any feedback on this patch, but I'd like to see it included in the next release of portable OpenSSH. Perhaphs I should have expanded a bit on why these issues were problems. > 1) I fixed fixpaths to complain instead of failing silently if it > can't write the output file. I keep my source code on an NFS-mounted filesystem so that I can access it from multiple machines. The filesystem is not exported with root permissions, for obvious security reasons. Therefore, I run configure and make as a non-root user with umask 022, followed by su'ing and running make install. Because make install tries to write files to the build directory, it fails. However, since fixpaths doesn't detect the failure, make doesn't bail out until it tries to install the manpages, at which point it complains that the .[01].out files don't exist. As a result, it takes some investigation to determine where the real cause of the failure was. > 2) I changed log-server.c to use av0 as the first argument to > openlog(). I also made sure it called openlog() before the TCP > wrapper stuff, because libwrap calls syslog() and winds up using > the wrong program name. On most of our Production systems, we run two invokations of sshd. The normal one is invoked as sshd and listens on port 22 for normal user connections. The additional one is invoked using a different name, listens on a different port, allows a different set of authentication mechansisms, and has a different daemon name for TCP wrappers. In this context, it makes sense to use the name that the daemon was invoked as when sending syslog messages, so that you can easily figure out which log messages are from which daemon. I'd appreciate some feedback from the OpenSSH Portability Team as to whether these changes will make it into the next release. Thanks! -- Mark D. Roth http://www.feep.net/~roth/ From rob at hagopian.net Sat Nov 4 07:51:15 2000 From: rob at hagopian.net (Rob Hagopian) Date: Fri, 3 Nov 2000 15:51:15 -0500 (EST) Subject: Snapshots In-Reply-To: <20001103171119.C13824@greenie.muc.de> Message-ID: This is actually in regards to SNAP-20001016, I simply haven't had time to upgrade all of our machines to the latest one... But anyways, the hanging problem hasn't completely gone away for me. Over the last few days I've noticed a few hung ssh processes. These are ssh2 connections that run automagicly (authorized DSA keys, scripts run out of cron) doing things like 'find /usr -name *.ready'. All machines are FreeBSD 3.5. I've had two (out of what are likely to be thousands) hang on me in as many days now. I hope to upgrade to the latest snap ASAP to provide more info, but I thought I'd at least mention it before the 2.3.0p1 release... -Rob From markus.friedl at informatik.uni-erlangen.de Sat Nov 4 21:15:20 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 4 Nov 2000 11:15:20 +0100 Subject: Another shapshot In-Reply-To: <20001103171119.C13824@greenie.muc.de>; from gert@greenie.muc.de on Fri, Nov 03, 2000 at 05:11:19PM +0100 References: <20001103171119.C13824@greenie.muc.de> Message-ID: <20001104111520.B24338@folly> On Fri, Nov 03, 2000 at 05:11:19PM +0100, Gert Doering wrote: > gcc -o sshd sshd.o auth.o auth1.o auth2.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 -L. -L/gnu/lib -L/gnulocal/lib -L/usr/local/lib -L/gnu/lib > -L/gnu -lssh -lopenbsd-compat -lnsl -lz -lcrypto -lskey > ld: 0711-317 ERROR: Undefined symbol: .auth2_skey > ld: 0711-317 ERROR: Undefined symbol: .skey_fake_keyinfo > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. > collect2: ld returned 8 exit status you have to link auth2-skey.o and auth-skey.o, too. just edit the Makefile. From gert at greenie.muc.de Sat Nov 4 21:22:32 2000 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 4 Nov 2000 11:22:32 +0100 Subject: Another shapshot In-Reply-To: <20001104111520.B24338@folly>; from Markus Friedl on Sat, Nov 04, 2000 at 11:15:20AM +0100 References: <20001103171119.C13824@greenie.muc.de> <20001104111520.B24338@folly> Message-ID: <20001104112232.A6920@greenie.muc.de> Hi, On Sat, Nov 04, 2000 at 11:15:20AM +0100, Markus Friedl wrote: > On Fri, Nov 03, 2000 at 05:11:19PM +0100, Gert Doering wrote: > > gcc -o sshd sshd.o auth.o auth1.o auth2.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 -L. -L/gnu/lib -L/gnulocal/lib -L/usr/local/lib -L/gnu/lib > > -L/gnu -lssh -lopenbsd-compat -lnsl -lz -lcrypto -lskey > > ld: 0711-317 ERROR: Undefined symbol: .auth2_skey > > ld: 0711-317 ERROR: Undefined symbol: .skey_fake_keyinfo > > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. > > collect2: ld returned 8 exit status > > you have to link auth2-skey.o and auth-skey.o, too. > just edit the Makefile. Sounds easy, but: gd at hilb0:/gnulocal/src/openssh-SNAP-20001028> grep auth2_skey *.c *.h auth2.c: authenticated = auth2_skey(authctxt); auth.h:int auth2_skey(Authctxt *authctxt); gd at hilb0:/gnulocal/src/openssh-SNAP-20001028> ls -l *skey* -rw-rw-r-- 1 gd staff 5690 Oct 28 05:19 auth-skey.c there is no auth2-skey in the SNAP-20001028. If I link only auth-skey.o, the error message about skey_fake_keyinfo() goes away, but the other one stays: gcc -o sshd sshd.o auth.o auth1.o auth2.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 auth-skey.o -L. -L/gnu/lib -L/gnulocal/lib -L/usr/local/lib -L/gnu/lib -L/gnu -lssh -lopenbsd-compat -lnsl -lz -lcrypto -lskey ld: 0711-317 ERROR: Undefined symbol: .auth2_skey ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status gmake: *** [sshd] Error 1 sooo...: * could someone please send me auth2-skey.c (and please include it into the next snapshot :) )? * configure / configure.in should be changed so that auth*-skey.o are automatically included in SSHDOBJS. thanks, 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 pekkas at netcore.fi Sat Nov 4 21:42:23 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 4 Nov 2000 12:42:23 +0200 (EET) Subject: Another shapshot In-Reply-To: <20001104112232.A6920@greenie.muc.de> Message-ID: On Sat, 4 Nov 2000, Gert Doering wrote: > * could someone please send me auth2-skey.c (and please include it into the > next snapshot :) )? It's in OpenBSD CVS, hasn't been ported/merged yet: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/auth2-skey.c ( Oct 11 ) It wouldn't seem to require that many modifications; #ifdef SKEY/#endif at the bottom and top, naturally. -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From gert at greenie.muc.de Sun Nov 5 04:30:20 2000 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 4 Nov 2000 18:30:20 +0100 Subject: Another shapshot In-Reply-To: <20001104112232.A6920@greenie.muc.de>; from Gert Doering on Sat, Nov 04, 2000 at 11:22:32AM +0100 References: <20001103171119.C13824@greenie.muc.de> <20001104111520.B24338@folly> <20001104112232.A6920@greenie.muc.de> Message-ID: <20001104183020.B14315@greenie.muc.de> Hi, On Sat, Nov 04, 2000 at 11:22:32AM +0100, Gert Doering wrote: > * could someone please send me auth2-skey.c (and please include it into the > next snapshot :) )? Markus sent it to me, thanks. Now I just have to get it to work - is there any documentation available how to use S/Key with OpenSSH? I have "skeyinit"'ed myself, so that should work, but no matter what I do, ssh/sshd do not ask me for a s/key challenge/response. I use ssh protocol 1, which (from reading the source comments) *should* permit it - either directly, or by entering "password: s/key", but both do not happen. Could somebody who is using S/Key with OpenSSH and ssh protocol 1 send me his ssh*config files (only the relevant sections) and show me a sample ssh/sshd invocation and log file, please? 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 Sun Nov 5 06:05:24 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 4 Nov 2000 20:05:24 +0100 Subject: Another shapshot In-Reply-To: <20001104183020.B14315@greenie.muc.de>; from gert@greenie.muc.de on Sat, Nov 04, 2000 at 06:30:20PM +0100 References: <20001103171119.C13824@greenie.muc.de> <20001104111520.B24338@folly> <20001104112232.A6920@greenie.muc.de> <20001104183020.B14315@greenie.muc.de> Message-ID: <20001104200524.A24226@folly> On Sat, Nov 04, 2000 at 06:30:20PM +0100, Gert Doering wrote: > Hi, > > On Sat, Nov 04, 2000 at 11:22:32AM +0100, Gert Doering wrote: > > * could someone please send me auth2-skey.c (and please include it into the > > next snapshot :) )? > > Markus sent it to me, thanks. > > Now I just have to get it to work - is there any documentation available > how to use S/Key with OpenSSH? I have "skeyinit"'ed myself, so that > should work, but no matter what I do, ssh/sshd do not ask me for a s/key > challenge/response. > > I use ssh protocol 1, which (from reading the source comments) *should* > permit it - either directly, or by entering "password: s/key", but both do > not happen. this has been disabled. try ssh -o 'skeyauthentication=yes' -o 'passwordauthentication=no' host From gert at greenie.muc.de Sun Nov 5 11:33:41 2000 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 5 Nov 2000 01:33:41 +0100 Subject: Another shapshot In-Reply-To: <20001104200524.A24226@folly>; from Markus Friedl on Sat, Nov 04, 2000 at 08:05:24PM +0100 References: <20001103171119.C13824@greenie.muc.de> <20001104111520.B24338@folly> <20001104112232.A6920@greenie.muc.de> <20001104183020.B14315@greenie.muc.de> <20001104200524.A24226@folly> Message-ID: <20001105013341.C14315@greenie.muc.de> Hi, On Sat, Nov 04, 2000 at 08:05:24PM +0100, Markus Friedl wrote: > > I use ssh protocol 1, which (from reading the source comments) *should* > > permit it - either directly, or by entering "password: s/key", but both do > > not happen. > > this has been disabled. I see. > try > ssh -o 'skeyauthentication=yes' -o 'passwordauthentication=no' host Better - that is, the following happens: server side: debug1: rcvd SSH_CMSG_AUTH_TIS debug1: generating fake skeyinfo for gd. debug1: sending challenge 'otp-md5 58 hilb68813' client side: debug: Installing crc compensation attack detector. debug: Received encrypted confirmation. debug: Doing skey authentication. otp-md5 58 hilb68813 Response: - the thing that is now puzzling me is that it shouldn't be "58" here. The skeys are freshly generated, the current challenge is #98: openssh-SNAP-20001028> skeyinfo 98 hilb65361 (and subsequently it doesn't work if I feed the output of "skey -md5 58 hilb68813" plus my pass phrase into ssh - always "denied" on the client side and "Failed s/key ..." on the server side). On the other hand, if I use the challenge that has "its turn" (in my case, "98 hilb65361", instead of "58 hilb68813"), login works fine. So I think there is some bug in the printing of the challenge, the "58" in the challenge seems to be static, even though "skeyinfo" prints now "95 hilb65361" (burned a few numbers in the meantime). I cannot claim to understand what's going on inside auth-skey.c before printing the "otp-..." stuff - it takes some bytes that and adds them to create the sequence number, and those bytes have been massaged by SHA1 before. No idea what that does and whether that's the way it should be... regards, 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 gert at greenie.muc.de Sun Nov 5 11:38:47 2000 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 5 Nov 2000 01:38:47 +0100 Subject: Another shapshot In-Reply-To: <20001105013341.C14315@greenie.muc.de>; from Gert Doering on Sun, Nov 05, 2000 at 01:33:41AM +0100 References: <20001103171119.C13824@greenie.muc.de> <20001104111520.B24338@folly> <20001104112232.A6920@greenie.muc.de> <20001104183020.B14315@greenie.muc.de> <20001104200524.A24226@folly> <20001105013341.C14315@greenie.muc.de> Message-ID: <20001105013847.A21297@greenie.muc.de> Hi, On Sun, Nov 05, 2000 at 01:33:41AM +0100, Gert Doering wrote: > I cannot claim to understand what's going on inside auth-skey.c before > printing the "otp-..." stuff - it takes some bytes that and adds them > to create the sequence number, and those bytes have been massaged by SHA1 > before. No idea what that does and whether that's the way it should > be... Idea. What it does is: ptr = (up[2] + up[3]) % 99 ... - do, by chance, the first 4 bytes of "up" contain a long int and the code is adding the two "low bytes" together? I'm on a big endian machine (PowerPC) and if that is so, this might need byte-swapping... Just a random thought too late in the night :-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From mouring at pconline.com Sun Nov 5 18:58:39 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Sun, 5 Nov 2000 01:58:39 -0600 (CST) Subject: Another shapshot In-Reply-To: <20001104183020.B14315@greenie.muc.de> Message-ID: I just checked in auth2-keys.c file from OpenBSD and added it to the Makefile. If there are any other changes that need to be made let us know. - Ben On Sat, 4 Nov 2000, Gert Doering wrote: > Hi, > > On Sat, Nov 04, 2000 at 11:22:32AM +0100, Gert Doering wrote: > > * could someone please send me auth2-skey.c (and please include it into the > > next snapshot :) )? > > Markus sent it to me, thanks. > > Now I just have to get it to work - is there any documentation available > how to use S/Key with OpenSSH? I have "skeyinit"'ed myself, so that > should work, but no matter what I do, ssh/sshd do not ask me for a s/key > challenge/response. > > I use ssh protocol 1, which (from reading the source comments) *should* > permit it - either directly, or by entering "password: s/key", but both do > not happen. > > Could somebody who is using S/Key with OpenSSH and ssh protocol 1 send me > his ssh*config files (only the relevant sections) and show me a sample > ssh/sshd invocation and log file, please? > > 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 gert at greenie.muc.de Sun Nov 5 20:24:35 2000 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 5 Nov 2000 10:24:35 +0100 Subject: Another shapshot In-Reply-To: ; from Ben Lindstrom on Sun, Nov 05, 2000 at 01:58:39AM -0600 References: <20001104183020.B14315@greenie.muc.de> Message-ID: <20001105102435.A27358@greenie.muc.de> Hi, On Sun, Nov 05, 2000 at 01:58:39AM -0600, Ben Lindstrom wrote: > I just checked in auth2-keys.c file from OpenBSD and added it to the > Makefile. If there are any other changes that need to be made let us > know. I think it would be good if auth-skey.o and auth2-skey.o would be automatically added to the SSHDOBJS list if "--with-skey" is specified at configure time. Also, there seems to be some problem with the printing of the challenge (sequence number), as reported by me last night. I hope Markus can shed some light into this. 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 gert at greenie.muc.de Sun Nov 5 20:26:17 2000 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 5 Nov 2000 10:26:17 +0100 Subject: Another shapshot In-Reply-To: <20001104200524.A24226@folly>; from Markus Friedl on Sat, Nov 04, 2000 at 08:05:24PM +0100 References: <20001103171119.C13824@greenie.muc.de> <20001104111520.B24338@folly> <20001104112232.A6920@greenie.muc.de> <20001104183020.B14315@greenie.muc.de> <20001104200524.A24226@folly> Message-ID: <20001105102617.B27358@greenie.muc.de> Hi, On Sat, Nov 04, 2000 at 08:05:24PM +0100, Markus Friedl wrote: > > I use ssh protocol 1, which (from reading the source comments) *should* > > permit it - either directly, or by entering "password: s/key", but both do > > not happen. > > this has been disabled. Just to come back to this: why? I think this might come in handy if you have to use a "user-supplied" ssh client that doesn't know "-o skeyauthentication=yes" (like commercial SSH or so). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From mouring at pconline.com Sun Nov 5 20:33:14 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Sun, 5 Nov 2000 03:33:14 -0600 (CST) Subject: Another shapshot In-Reply-To: <20001105102435.A27358@greenie.muc.de> Message-ID: On Sun, 5 Nov 2000, Gert Doering wrote: > Hi, > > On Sun, Nov 05, 2000 at 01:58:39AM -0600, Ben Lindstrom wrote: > > I just checked in auth2-keys.c file from OpenBSD and added it to the > > Makefile. If there are any other changes that need to be made let us > > know. > > I think it would be good if auth-skey.o and auth2-skey.o would be > automatically added to the SSHDOBJS list if "--with-skey" is specified at > configure time. Hmm... skey was totally disabled.. I added in auth-skey.o back into the SSHDOBJS. I'll wait to sync up until I hear more about the status. (Since I'm going to bed. =) > > Also, there seems to be some problem with the printing of the challenge > (sequence number), as reported by me last night. I hope Markus can shed > some light into this. > I saw that.. I don't have S/Key libraries installed on my Linux box to do any testing and I'm not sure where to dig them up. If I could ever get around to buying the right null modem cables for my PowerComputing box I could add PowerMac to the list of test machines.=) - Ben From markus.friedl at informatik.uni-erlangen.de Sun Nov 5 23:56:24 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sun, 5 Nov 2000 13:56:24 +0100 Subject: Another shapshot In-Reply-To: <20001105102617.B27358@greenie.muc.de>; from gert@greenie.muc.de on Sun, Nov 05, 2000 at 10:26:17AM +0100 References: <20001103171119.C13824@greenie.muc.de> <20001104111520.B24338@folly> <20001104112232.A6920@greenie.muc.de> <20001104183020.B14315@greenie.muc.de> <20001104200524.A24226@folly> <20001105102617.B27358@greenie.muc.de> Message-ID: <20001105135624.A2381@folly> On Sun, Nov 05, 2000 at 10:26:17AM +0100, Gert Doering wrote: > Hi, > > On Sat, Nov 04, 2000 at 08:05:24PM +0100, Markus Friedl wrote: > > > I use ssh protocol 1, which (from reading the source comments) *should* > > > permit it - either directly, or by entering "password: s/key", but both do > > > not happen. > > > > this has been disabled. > > Just to come back to this: why? I think this might come in handy if > you have to use a "user-supplied" ssh client that doesn't know > "-o skeyauthentication=yes" (like commercial SSH or so). commercial ssh1 can use -o TISAuthentication=yes secureCRT and ttssh clients have to turn on OneTimePasswd or TIS. -markus From gert at greenie.muc.de Mon Nov 6 05:32:34 2000 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 5 Nov 2000 19:32:34 +0100 Subject: Another shapshot In-Reply-To: <20001105135624.A2381@folly>; from Markus Friedl on Sun, Nov 05, 2000 at 01:56:24PM +0100 References: <20001103171119.C13824@greenie.muc.de> <20001104111520.B24338@folly> <20001104112232.A6920@greenie.muc.de> <20001104183020.B14315@greenie.muc.de> <20001104200524.A24226@folly> <20001105102617.B27358@greenie.muc.de> <20001105135624.A2381@folly> Message-ID: <20001105193234.B6684@greenie.muc.de> Hi, On Sun, Nov 05, 2000 at 01:56:24PM +0100, Markus Friedl wrote: > > On Sat, Nov 04, 2000 at 08:05:24PM +0100, Markus Friedl wrote: > > > [using "password: s/key"] this has been disabled. > > > > Just to come back to this: why? I think this might come in handy if > > you have to use a "user-supplied" ssh client that doesn't know > > "-o skeyauthentication=yes" (like commercial SSH or so). > > commercial ssh1 can use > -o TISAuthentication=yes > secureCRT and ttssh clients have to turn on OneTimePasswd or TIS. Ummm, well, yes. Maybe. Every client does it differently. What's so bad at using "password: s/key" that it has been dropped? I think it's pretty useful - just use the client as is, and tell it on a per-session basis, at login time, what to do... yes, sure, it's a hack, but a useful one. 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 stevesk at sweden.hp.com Mon Nov 6 06:47:25 2000 From: stevesk at sweden.hp.com (Kevin Steves) Date: Sun, 5 Nov 2000 20:47:25 +0100 (MET) Subject: HP-UX 11.0 libpam patch Message-ID: Patch PHCO_22265 (s700_800 11.00 cumulative libpam and libpam_unix patch) is now available that fixes a problem discussed a while back on the list regarding an incorrect return value from pam_acct_mgmt(), which effected the ability to change an expired password: (SR: 8606160402 CR: JAGad29724) HP-UX is inconsistent with the PAM standard with respect to the return value for an expired password. libpam_unix.1 returns PAM_AUTHTOK_EXPIRED when it detects an expired password; the PAM standard expects PAM_NEW_AUTHTOK_REQD to be returned. This inconsistency causes a problem for programs written to run on multiple platforms. Resolution: When an expired password is detected, libpam_unix.1 now returns standard PAM_NEW_AUTHTOK_REQD instead of PAM_AUTHTOK_EXPIRED. I'm running a pre-release of this patch and openssh-SNAP-20001028.tar.gz on several 11.0 production hosts and things are working fine. You can get this patch from: ftp://europe-ffs.external.hp.com/hp-ux_patches/s700_800/11.X/PHCO_22265 ftp://us-ffs.external.hp.com/hp-ux_patches/s700_800/11.X/PHCO_22265 From stevesk at sweden.hp.com Mon Nov 6 06:55:20 2000 From: stevesk at sweden.hp.com (Kevin Steves) Date: Sun, 5 Nov 2000 20:55:20 +0100 (MET) Subject: keyboard-interactive and PAM under protocol v2 In-Reply-To: <20001018231417.F0AA7F842@nayarit.avantgo.com> Message-ID: On Wed, 18 Oct 2000, Michael Kiernan wrote: : Support for the keyboard-interactive authentication method has recently : been added to OpenSSH. This looks like a nice way to take advantage : of more of the capabilities provided by PAM, at least under version 2 : of the SSH protocol. Is anybody currently looking into this or otherwise : working in this direction? It looks very interesting. Is there a newer draft than the one from 7 March that I found? From maf at appgate.com Mon Nov 6 07:15:18 2000 From: maf at appgate.com (Martin Forssen) Date: Sun, 5 Nov 2000 21:15:18 +0100 (MET) Subject: keyboard-interactive and PAM under protocol v2 In-Reply-To: Message-ID: On Sun, 5 Nov 2000, Kevin Steves wrote: > On Wed, 18 Oct 2000, Michael Kiernan wrote: > : Support for the keyboard-interactive authentication method has recently > : been added to OpenSSH. This looks like a nice way to take advantage > : of more of the capabilities provided by PAM, at least under version 2 > : of the SSH protocol. Is anybody currently looking into this or otherwise > : working in this direction? > > It looks very interesting. Is there a newer draft than the one from 7 > March that I found? Yes, I just submitted an updated version. It is curently available at http://www.appgate.com/~maf/secsh-auth-kbdinteract-01.txt The protocol has not changed since the old draft. /MaF From stevesk at sweden.hp.com Mon Nov 6 07:29:46 2000 From: stevesk at sweden.hp.com (Kevin Steves) Date: Sun, 5 Nov 2000 21:29:46 +0100 (MET) Subject: Locking pages in core In-Reply-To: Message-ID: On Tue, 31 Oct 2000, Jason Stone wrote: : Is there any interest in using mlock to lock pages in core so that : potentially sensitive data won't get swapped out to disk? (GnuPG, for : example, does this). : : There was a thread on this a long time ago, and it degenerated into a : discussion of crypto-swap, but the question was never answered. : : Is there a good reason not to do this? The only one I can think of is : that we'll need to make ssh-agent setuid as mlock requires root : priveleges. I think it's worthwhile to pursue this. My first thought is some type of secmem library ala gpg. I think OpenSSH is already careful about clearing buffers that have held sensitive data asap, but it would be better to place this data in non-swapable segments in the first place. For HP-UX: 11.0 support mlock(2) and it doesn't require root if you use the privgrp(4) mechanism. 10.20 has plock(2) which isn't as fine-grained as mlock() and basically permits you to lock the entire data segment. plock() supports privgrp as well. I think there's an mlock() stub in libc that will just raise SIGSYS. From mouring at pconline.com Mon Nov 6 09:09:34 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Sun, 5 Nov 2000 16:09:34 -0600 (CST) Subject: suggested bsd-setproctitle.c Message-ID: Keven Steves, Can I suggest this minor change. To halt a bit of compiler grumble on BSD4.3 platforms. It's complaining about unsued variable "__progname". I wanted to check with you before committing it incase you had some other plans in mind (and I know how I hate when others break my code =). Thanks, - Ben --- ../openssh/bsd-setproctitle.c Wed Oct 18 08:11:44 2000 +++ bsd-setproctitle.c Sun Nov 5 16:59:07 2000 @@ -56,11 +56,13 @@ #define MAX_PROCTITLE 2048 -#ifdef HAVE___PROGNAME -extern char *__progname; -#else -static const char *__progname = "sshd"; -#endif /* HAVE___PROGNAME */ +#if SPT_TYPE != SPT_NONE +# ifdef HAVE___PROGNAME + extern char *__progname; +# else + static const char *__progname = "sshd"; +# endif /* HAVE___PROGNAME */ +#endif /* SPT_TYPE != SPT_NONE */ /* * Set Process Title (SPT) defines. Modeled after sendmail's From djm at mindrot.org Mon Nov 6 09:21:20 2000 From: djm at mindrot.org (Damien Miller) Date: Mon, 6 Nov 2000 09:21:20 +1100 (EST) Subject: Locking pages in core In-Reply-To: Message-ID: On Sun, 5 Nov 2000, Kevin Steves wrote: > I think it's worthwhile to pursue this. My first thought is some type > of secmem library ala gpg. I think OpenSSH is already careful about > clearing buffers that have held sensitive data asap, but it would be > better to place this data in non-swapable segments in the first place. A secmem library would be the way to go, but it would best be done in conjunction with the OpenSSL people - there is a fair bit of mallocing and private data (random pools, etc) on their side of the fence. Perhaps such a library would be best incorporated into OpenSSL. -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 dale at accentre.com Mon Nov 6 10:01:13 2000 From: dale at accentre.com (Dale Stimson) Date: Sun, 5 Nov 2000 15:01:13 -0800 Subject: Socket options not properly set for ssh and sshd. Message-ID: <20001105150113.C8676@cupro.opengvs.com> I'm sending this only to openssh-unix-dev at mindrot.org (since I'm using the ported version of OpenSSH) and not to openssh at openssh.com, even though I believe this to be a general problem. Please advise if you think I should redirect this to the other mailing list. Version: OpenSSH_2.2.0p1 Keywords: setsockopt keepalive hang masquerade Symptom: For protocol 2, socket options (especially keepalive) are not being properly set for OpenSSH_2.2.0p1 (Redhat 7.0 distribution). I believe this to be a general problem that is not specific to the portable version of OpenSSH. Function packet_set_interactive is intended to be called to set socket options that are desired for interactive sessions. TCP keepalive messages are included in the socket options set, although they more properly ought to be elsewhere (as they are not related to interactivity). The problem: Function set_packet_set_interactive is never called for protocol 2 connections -- only for protocol 1. This is the case for both ssh and sshd. Specifically, for sshd protocol 1 connections, function calls are made: main to do_authentication to do_authenticated to packet_set_interactive For sshd protocol 2 connections, function calls are made: main to do_authentication2 to do_authenticated2 which does not call packet_set_interactive. For ssh protocol 1 connections, packet_set_interactive is called from ssh_session. For protocol 2, the corresponding function ssh_session2 makes no call to packet_set_interactive. ---------------- I haven't delved into the protocol specifications, so if protocol 2 lacks an obvious way to determine if a connection is "interactive", then so be it. However, the keepalive value ought to be set in any case. My suggestions: 1. Move keepalive setsockopt out of packet_set_interactive, as it's not related to interactive vs non-interactive. Instead, make the keepalive setsockopt call in: ssh -- in sshconnect.c, after the setsockopt for SO_LINGER, right before call to packet_set_connection. sshd -- in sshd.c, after the setsockopt for SO_LINGER. 2. Secondarily, for ssh and sshd, ensure packet_set_interactive is called for ssh2 also if appropriate. ----------------------- As an aside (as information for anyone else with the same problem), I need keepalives to keep my connections from hanging after thirty minutes due to an ISP (Cox at work) router that is masquerading IP addresses for my local network. This router apparently drops the masquerade table entries after 30 minutes of inactivity. (Then, in response to any further activity from the client it just sends TCP resets, which generally leaves the connected incarnation of sshd hung until killed). My solution to that problem is to change the default keepalive time on my Linux system from 120 minutes to 20 minutes (1200 seconds) via echo 1200 > /proc/sys/net/ipv4/tcp_keepalive_time and then depend on sshd keepalives to avoid inactivity. From stevesk at sweden.hp.com Mon Nov 6 16:52:02 2000 From: stevesk at sweden.hp.com (Kevin Steves) Date: Mon, 6 Nov 2000 06:52:02 +0100 (MET) Subject: suggested bsd-setproctitle.c In-Reply-To: Message-ID: On Sun, 5 Nov 2000, Ben Lindstrom wrote: : Can I suggest this minor change. To halt a bit of compiler grumble on : BSD4.3 platforms. : : It's complaining about unsued variable "__progname". : : I wanted to check with you before committing it incase you had some : other plans in mind (and I know how I hate when others break my code =). That should work. But it seems this __progname issue could be cleaned up by defining the variable in main() files if needed: #ifndef HAVE___PROGNAME const char *__progname = "foo"; #endif then declaring it (no ifdefs) if it's referenced: extern const char *__progname; This gets us closer to OpenBSD's tree with fewer ifdefs. I'll do this patch unless someone points out what it will break :) From aspa at kronodoc.fi Mon Nov 6 17:41:27 2000 From: aspa at kronodoc.fi (Marko Asplund) Date: Mon, 6 Nov 2000 08:41:27 +0200 (EET) Subject: a small typo in configure.in In-Reply-To: Message-ID: hello there seems to be a small typo in OpenSSH 2.2.0p1 configure.in. as a result 'configure --help' prints the wrong name for the '--with-ldflags' configuration flag. best regards, -- aspa -------------- next part -------------- *** configure.in.dist Mon Nov 6 09:07:43 2000 --- configure.in Mon Nov 6 09:26:06 2000 *************** *** 203,209 **** ] ) AC_ARG_WITH(ldflags, ! [ --with-ldlags Specify additional flags to pass to linker], [ if test "x$withval" != "xno" ; then LDFLAGS="$LDFLAGS $withval" --- 203,209 ---- ] ) AC_ARG_WITH(ldflags, ! [ --with-ldflags Specify additional flags to pass to linker], [ if test "x$withval" != "xno" ; then LDFLAGS="$LDFLAGS $withval" From mouring at pconline.com Mon Nov 6 18:15:54 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Mon, 6 Nov 2000 01:15:54 -0600 (CST) Subject: a small typo in configure.in In-Reply-To: Message-ID: Thanks. Applied. On Mon, 6 Nov 2000, Marko Asplund wrote: > hello > > there seems to be a small typo in OpenSSH 2.2.0p1 configure.in. as a > result 'configure --help' prints the wrong name for the '--with-ldflags' > configuration flag. > > best regards, > -- > aspa > From stevesk at sweden.hp.com Mon Nov 6 22:25:39 2000 From: stevesk at sweden.hp.com (Kevin Steves) Date: Mon, 6 Nov 2000 12:25:39 +0100 (CET) Subject: suggested bsd-setproctitle.c In-Reply-To: Message-ID: <200011061108.MAA06855@b0fh.sweden.hp.com> On Mon, 6 Nov 2000, Kevin Steves wrote: : That should work. But it seems this __progname issue could be cleaned : up by defining the variable in main() files if needed: : : #ifndef HAVE___PROGNAME : const char *__progname = "foo"; : #endif : : then declaring it (no ifdefs) if it's referenced: : : extern const char *__progname; : : This gets us closer to OpenBSD's tree with fewer ifdefs. : : I'll do this patch unless someone points out what it will break :) How does the attached patch look? -------------- next part -------------- Index: bsd-setproctitle.c =================================================================== RCS file: /var/cvs/openssh/bsd-setproctitle.c,v retrieving revision 1.1 diff -u -r1.1 bsd-setproctitle.c --- bsd-setproctitle.c 2000/10/18 13:11:44 1.1 +++ bsd-setproctitle.c 2000/11/06 11:02:51 @@ -56,11 +56,7 @@ #define MAX_PROCTITLE 2048 -#ifdef HAVE___PROGNAME -extern char *__progname; -#else -static const char *__progname = "sshd"; -#endif /* HAVE___PROGNAME */ +extern const char *__progname; /* * Set Process Title (SPT) defines. Modeled after sendmail's Index: log-server.c =================================================================== RCS file: /var/cvs/openssh/log-server.c,v retrieving revision 1.12 diff -u -r1.12 log-server.c --- log-server.c 2000/09/16 02:29:09 1.12 +++ log-server.c 2000/11/06 11:02:51 @@ -43,12 +43,6 @@ #include "xmalloc.h" #include "ssh.h" -#ifdef HAVE___PROGNAME -extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "sshd"; -#endif /* HAVE___PROGNAME */ - static LogLevel log_level = SYSLOG_LEVEL_INFO; static int log_on_stderr = 0; static int log_facility = LOG_AUTH; @@ -129,6 +123,7 @@ char fmtbuf[MSGBUFSIZ]; char *txt = NULL; int pri = LOG_INFO; + extern char *__progname; if (level > log_level) return; Index: sshconnect.c =================================================================== RCS file: /var/cvs/openssh/sshconnect.c,v retrieving revision 1.44 diff -u -r1.44 sshconnect.c --- sshconnect.c 2000/09/23 06:15:57 1.44 +++ sshconnect.c 2000/11/06 11:02:53 @@ -35,11 +35,7 @@ char *server_version_string = NULL; extern Options options; -#ifdef HAVE___PROGNAME -extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh"; -#endif /* HAVE___PROGNAME */ +extern const char *__progname; /* * Connect to the given ssh server using a proxy command. Index: session.c =================================================================== RCS file: /var/cvs/openssh/session.c,v retrieving revision 1.52 diff -u -r1.52 session.c --- session.c 2000/10/28 03:19:58 1.52 +++ session.c 2000/11/06 11:02:56 @@ -128,12 +128,7 @@ /* import */ extern ServerOptions options; -#ifdef HAVE___PROGNAME -extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "sshd"; -#endif /* HAVE___PROGNAME */ - +extern const char *__progname; extern int log_stderr; extern int debug_flag; extern unsigned int utmp_len; Index: ssh-add.c =================================================================== RCS file: /var/cvs/openssh/ssh-add.c,v retrieving revision 1.26 diff -u -r1.26 ssh-add.c --- ssh-add.c 2000/10/17 12:22:28 1.26 +++ ssh-add.c 2000/11/06 11:02:56 @@ -48,11 +48,9 @@ #include "authfd.h" #include "authfile.h" -#ifdef HAVE___PROGNAME -extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh-add"; -#endif /* HAVE___PROGNAME */ +#ifndef HAVE___PROGNAME +const char *__progname = "ssh-add"; +#endif void delete_file(AuthenticationConnection *ac, const char *filename) Index: ssh-agent.c =================================================================== RCS file: /var/cvs/openssh/ssh-agent.c,v retrieving revision 1.33 diff -u -r1.33 ssh-agent.c --- ssh-agent.c 2000/09/29 12:01:37 1.33 +++ ssh-agent.c 2000/11/06 11:02:57 @@ -92,11 +92,9 @@ char socket_name[1024]; char socket_dir[1024]; -#ifdef HAVE___PROGNAME -extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh-agent"; -#endif /* HAVE___PROGNAME */ +#ifndef HAVE___PROGNAME +const char *__progname = "ssh-agent"; +#endif void idtab_init(void) Index: ssh-keygen.c =================================================================== RCS file: /var/cvs/openssh/ssh-keygen.c,v retrieving revision 1.26 diff -u -r1.26 ssh-keygen.c --- ssh-keygen.c 2000/10/14 05:23:12 1.26 +++ ssh-keygen.c 2000/11/06 11:02:57 @@ -70,11 +70,9 @@ int dsa_mode = 0; /* argv0 */ -#ifdef HAVE___PROGNAME -extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh-keygen"; -#endif /* HAVE___PROGNAME */ +#ifndef HAVE___PROGNAME +const char *__progname = "ssh-keygen"; +#endif char hostname[MAXHOSTNAMELEN]; Index: ssh.c =================================================================== RCS file: /var/cvs/openssh/ssh.c,v retrieving revision 1.47 diff -u -r1.47 ssh.c --- ssh.c 2000/10/28 03:19:58 1.47 +++ ssh.c 2000/11/06 11:03:01 @@ -59,11 +59,9 @@ #include "authfd.h" #include "authfile.h" -#ifdef HAVE___PROGNAME -extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh"; -#endif /* HAVE___PROGNAME */ +#ifndef HAVE___PROGNAME +const char *__progname = "ssh"; +#endif /* Flag indicating whether IPv4 or IPv6. This can be set on the command line. Default value is AF_UNSPEC means both IPv4 and IPv6. */ Index: sftp-server.c =================================================================== RCS file: /var/cvs/openssh/sftp-server.c,v retrieving revision 1.3 diff -u -r1.3 sftp-server.c --- sftp-server.c 2000/09/23 03:58:32 1.3 +++ sftp-server.c 2000/11/06 11:03:01 @@ -90,6 +90,10 @@ #define get_string(lenp) buffer_get_string(&iqueue, lenp); #define TRACE log +#ifndef HAVE___PROGNAME +const char *__progname = "sftp-server"; +#endif + /* input and output queue */ Buffer iqueue; Buffer oqueue; Index: ChangeLog =================================================================== RCS file: /var/cvs/openssh/ChangeLog,v retrieving revision 1.519 diff -u -r1.519 ChangeLog --- ChangeLog 2000/11/06 07:15:43 1.519 +++ ChangeLog 2000/11/06 11:03:09 @@ -11,6 +11,7 @@ - (bal) typo in configure.in in regards to --with-ldflags from Marko Asplund - (bal) fixed next-posix.h. Forgot prototype of getppid(). + - (stevesk) Clean up __progname definitions. 20001105 - (bal) Sync with OpenBSD: From Ulrich.Windl at rz.uni-regensburg.de Mon Nov 6 22:15:37 2000 From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl) Date: Mon, 6 Nov 2000 12:15:37 +0100 Subject: openssh-2.1.1p1 on HP-UX 11.00: processes hanging around Message-ID: <3A06A0E5.7498.EBD142@localhost> Hello, I'm unsure what kind of problem this is, but If I use eval $(ssh-agent) ssh-add scp ... (several times) ssh-add -D exit There are many ssh processes around in the system: UID PID PPID C STIME TTY TIME COMMAND root 4266 1 0 11:33:56 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no root 1876 9788 0 11:11:26 ? 0:01 /usr/local/sbin/sshd root 4199 1 0 11:33:37 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no root 4323 1 0 11:34:13 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no root 7816 1 0 12:05:16 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no root 7723 1 0 12:05:10 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no windl 8208 1905 2 12:07:01 pts/0 0:00 grep ss root 4689 1 0 11:35:52 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no root 7900 1 0 12:05:29 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no root 9788 1 0 Oct 27 ? 0:21 /usr/local/sbin/sshd root 4518 1 0 11:35:11 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no root 4585 1 0 11:35:25 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no root 9429 9788 0 Oct 30 ? 0:00 /usr/local/sbin/sshd root 4471 1 0 11:34:59 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no root 5719 1 0 11:44:31 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no root 5548 1 0 11:43:54 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no root 4351 9788 0 11:34:17 ? 0:00 /usr/local/sbin/sshd root 4642 1 0 11:35:38 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no root 4057 1 0 11:32:12 ? 0:01 ssh-agent root 5662 1 0 11:44:19 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no root 5608 1 0 11:44:07 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no root 5767 1 0 11:44:42 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no root 7863 1 0 12:05:23 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no root 8041 1 0 12:05:48 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no root 7957 1 0 12:05:36 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no root 7994 1 0 12:05:42 pts/0 0:00 /usr/local/bin/ssh -x -oFallBack ToRsh no -oFallBackToRsh no However the only SSH directory remaining in /tmp is: rkdvmhp3:windl(46) % ll -d /tmp/s* drwx------ 2 root sys 96 Nov 6 11:32 /tmp/ssh-GClt4020 Is this a known problem? Configuration was quite simple: # This directory was configured as follows, # on host rkdvmhp3: # # ./configure Regards, Ulrich From Lutz.Jaenicke at aet.TU-Cottbus.DE Mon Nov 6 22:31:32 2000 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Mon, 6 Nov 2000 12:31:32 +0100 Subject: openssh-2.1.1p1 on HP-UX 11.00: processes hanging around In-Reply-To: <3A06A0E5.7498.EBD142@localhost>; from Ulrich.Windl@rz.uni-regensburg.de on Mon, Nov 06, 2000 at 12:15:37PM +0100 References: <3A06A0E5.7498.EBD142@localhost> Message-ID: <20001106123132.A24629@serv01.aet.tu-cottbus.de> On Mon, Nov 06, 2000 at 12:15:37PM +0100, Ulrich Windl wrote: > Hello, > > I'm unsure what kind of problem this is, but If I use > > eval $(ssh-agent) > ssh-add > scp ... > (several times) > > ssh-add -D > exit > > There are many ssh processes around in the system: [And hanging counterparts at the receiving machine.] > Is this a known problem? Yes. You must compile 2.1.1 with -DUSE_PIPES. As of 2.2.0p1 this is the default for HP-UX. 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 Tue Nov 7 01:05:41 2000 From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl) Date: Mon, 6 Nov 2000 15:05:41 +0100 Subject: HP-UX: sshd[11336]: Cannot delete credentials: Permission denied Message-ID: <3A06C8C0.19217.1878753@localhost> Hello, I get the syslog message Oct 31 17:00:02 rkdvmhp1 sshd[11336]: Cannot delete credentials: Permission denied What could be wrong? sshd is running as "root" process. The version used is SSH Version OpenSSH_2.1.1, protocol versions 1.5/2.0. Compiled with SSL (0x0090581f). and HP-UX 11.00 has all the patches from the September CD. Regards, Ulrich From stevesk at sweden.hp.com Tue Nov 7 01:58:06 2000 From: stevesk at sweden.hp.com (Kevin Steves) Date: Mon, 6 Nov 2000 15:58:06 +0100 (CET) Subject: HP-UX: sshd[11336]: Cannot delete credentials: Permission denied In-Reply-To: <3A06C8C0.19217.1878753@localhost> Message-ID: <200011061440.PAA15426@b0fh.sweden.hp.com> On Mon, 6 Nov 2000, Ulrich Windl wrote: : I get the syslog message : Oct 31 17:00:02 rkdvmhp1 sshd[11336]: Cannot delete credentials: : Permission denied It's a known issue with an unknown explanation. I've asked the HP PAM guys and they weren't sure what it was and haven't had time to pursue it. I think Solaris PAM does the same thing. Note that I believe starting at 2.2.0 that message is logged at debug, which means you won't see it unless you're logging debug in sshd and syslog. From mouring at pconline.com Tue Nov 7 06:43:36 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Mon, 6 Nov 2000 13:43:36 -0600 (CST) Subject: suggested bsd-setproctitle.c In-Reply-To: <200011061108.MAA06855@b0fh.sweden.hp.com> Message-ID: I'll have to look at it when I get home tonight.. but it does not work as claimed under Linux. So I doubt it will work under NeXT. [mouring at etoh ossh]$ make gcc -g -O2 -Wall -I. -I. -I/opt/openssl/include -DETCDIR=\"/opt/openssh/etc\" -D SSH_PROGRAM=\"/opt/openssh/bin/ssh\" -DSSH_ASKPASS_DEFAULT=\"/opt/openssh/libexe c/ssh-askpass\" -DHAVE_CONFIG_H -c -o ssh.o ssh.c ssh.c: In function `main': ssh.c:568: `__progname' undeclared (first use in this function) ssh.c:568: (Each undeclared identifier is reported only once ssh.c:568: for each function it appears in.) [mouring at etoh ossh]$ grep HAVE___PROG *.h acconfig.h:#undef HAVE___PROGNAME config.h:#define HAVE___PROGNAME 1 SSHing home is a bear for some odd reason lately. - Ben On Mon, 6 Nov 2000, Kevin Steves wrote: > On Mon, 6 Nov 2000, Kevin Steves wrote: > : That should work. But it seems this __progname issue could be cleaned > : up by defining the variable in main() files if needed: > : > : #ifndef HAVE___PROGNAME > : const char *__progname = "foo"; > : #endif > : > : then declaring it (no ifdefs) if it's referenced: > : > : extern const char *__progname; > : > : This gets us closer to OpenBSD's tree with fewer ifdefs. > : > : I'll do this patch unless someone points out what it will break :) > > How does the attached patch look? > From stevesk at sweden.hp.com Tue Nov 7 07:18:20 2000 From: stevesk at sweden.hp.com (Kevin Steves) Date: Mon, 6 Nov 2000 21:18:20 +0100 (MET) Subject: suggested bsd-setproctitle.c In-Reply-To: Message-ID: On Mon, 6 Nov 2000, Ben Lindstrom wrote: : I'll have to look at it when I get home tonight.. but it does not work : as claimed under Linux. So I doubt it will work under NeXT. ok, in main() programs we need to have: #ifndef HAVE___PROGNAME const char *__progname = "foo"; #else extern char *__progname; #endif From djm at mindrot.org Tue Nov 7 11:43:15 2000 From: djm at mindrot.org (Damien Miller) Date: Tue, 7 Nov 2000 11:43:15 +1100 (EST) Subject: ANNOUNCE: openssh-2.3.0p1 Message-ID: This is to announce the release of portable openssh-2.3.0p1. This release includes many new features and bug fixes. This is a recommended upgrade if you are using 2.2.0p1 or an older release. Portable OpenSSH is available from one of the many mirrors listed at http://www.openssh.com/portable.html Some of the more notable features include: - Rijndael support for SSH2. Use the "Ciphers" configuration directive to enable it. (Markus Friedl - Cygwin support (Corinna Vinschen ) - sftp-server support (Markus Friedl ) - SSH1 single-des support for interop with Cisco routers. This cipher is never enabled automatically, you have to either specify "-c des" or enable it using "Cipher des" in a config file. (Markus Friedl - Support expired password change through PAM (Steve VanDevender's ) - Better compatibility with buggy SSH implementations (Markus Friedl - S/key support for SSH2, based on kbd-interactive auth (Markus Friedl and mkiernan at avantgo.com - scp now supports "-o" option (Ben Lindstron ) Please refer to the ChangeLog for a full list of features and bugfixes. 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 aspa at kronodoc.fi Tue Nov 7 17:52:33 2000 From: aspa at kronodoc.fi (Marko Asplund) Date: Tue, 7 Nov 2000 08:52:33 +0200 (EET) Subject: minor openssh-2.3.0p1 issues on RH6.2 In-Reply-To: Message-ID: hi i just upgraded OpenSSH to v2.3.0p1 on Redhat linux v6.2. the server seems to be working fine but there are a few strange messages in the log files: ... sshd[1953]: WARNING: /usr/local/openssh2/etc/primes does not exist, \ using old prime and ... sshd[1976]: error: channel 0: internal error: we do not read, but \ chan_read_failed for istate 8 does someone know what's causing these? also, the sftp-server seems to be logging an awful lot of debugging messages to the server logs. best regards, -- aspa From pekkas at netcore.fi Tue Nov 7 22:26:38 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 7 Nov 2000 13:26:38 +0200 (EET) Subject: scp does not die w/ error codes as ssh.com's? Message-ID: Hi, It appears that scp from OpenSSH and SSH.COM work differently here. For example: --- server $ touch a b ; chmod 000 a client $ touch a b ; scp a b user at server:~/ --- OpenSSH copies file b while SSH.COM scp dies for no perms after failing to copy a. I take this is considered a feature ? -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From jmknoble at jmknoble.cx Tue Nov 7 22:49:15 2000 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Tue, 7 Nov 2000 06:49:15 -0500 Subject: ANNOUNCE: x11-ssh-askpass v1.1.0 Message-ID: <20001107064915.D23390@quipu.half.pint-stowp.cx> x11-ssh-askpass version 1.1.0 is now available from the following locations: http://www.jmknoble.cx/software/x11-ssh-askpass/ http://www.ntrnet.net/~jmknoble/software/x11-ssh-askpass/ x11-ssh-askpass is a passphrase dialog for use with OpenSSH (www.openssh.com) under the X Window System. The important changes since version 1.0.3 are as follows: - Added a timeout feature (resource *inputTimeout, in seconds) to enable x11-ssh-askpass to disappear after a while if it doesn't get any input (thanks to John Horne for the suggestion). - A few minor user interface improvements. [Damien, if you've not built the 2.3.0p1 RPM packages yet, this is a good one to use. If you have already, no sweat.] -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From jhuuskon at messi.uku.fi Wed Nov 8 00:11:23 2000 From: jhuuskon at messi.uku.fi (Jarno Huuskonen) Date: Tue, 7 Nov 2000 15:11:23 +0200 Subject: RedHat sshd.init script typo ? Message-ID: <20001107151123.A22080@laivuri63.uku.fi> Hi, I noticed one small possible error in the openssh-2.3.0p1/contrib/redhat/sshd.init script. In the stop option: stop) echo -n "Shutting down sshd: " if [ -f $PID_FILE ] ; then killproc sshd [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/sshd fi echo Shouldn't there be RETVAL=$? after killproc sshd ? If this is the case here's a patch: --- sshd.init~ Mon Oct 16 04:25:17 2000 +++ sshd.init Tue Nov 7 15:06:16 2000 @@ -72,6 +72,7 @@ echo -n "Shutting down sshd: " if [ -f $PID_FILE ] ; then killproc sshd + RETVAL=$? [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/sshd fi echo -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 mouring at pconline.com Wed Nov 8 02:16:33 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Tue, 7 Nov 2000 09:16:33 -0600 (CST) Subject: suggested bsd-setproctitle.c In-Reply-To: <200011071428.PAA10784@b0fh.sweden.hp.com> Message-ID: On Tue, 7 Nov 2000, Kevin Steves wrote: > On Mon, 6 Nov 2000, Kevin Steves wrote: > : ok, in main() programs we need to have: > : > : #ifndef HAVE___PROGNAME > : const char *__progname = "foo"; > : #else > : extern char *__progname; > : #endif > > How does the attached patch work? I tested on HP-UX > !defined(HAVE___PROGNAME) and Linux defined(HAVE___PROGNAME). I don't > use const now to keep things consistent, and went back to #ifdef > HAVE___PROGNAME. > I'll try it later on, but just skimming the patch it seems to do the same thing that I did last night. I would have posted my patch (which looks just like it, but I left the 'const' in) last night if QWORST (US West + Qwest) did not take out my ISP's Virtual ATM Circuit for DSL service for almost 5 hours. - Ben From pekkas at netcore.fi Wed Nov 8 03:26:04 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 7 Nov 2000 18:26:04 +0200 (EET) Subject: RedHat sshd.init script typo ? In-Reply-To: <20001107151123.A22080@laivuri63.uku.fi> Message-ID: On Tue, 7 Nov 2000, Jarno Huuskonen wrote: > > I noticed one small possible error in the > openssh-2.3.0p1/contrib/redhat/sshd.init script. > In the stop option: > stop) > echo -n "Shutting down sshd: " > if [ -f $PID_FILE ] ; then > killproc sshd > [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/sshd > fi > echo > > Shouldn't there be RETVAL=$? after killproc sshd ? Yeah, RETVAL seems to have been omitted by mistake. The problem has been there for a while now. Luckily enough, sshd won't break too badly for it. :-/ -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From mouring at pconline.com Wed Nov 8 03:39:55 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Tue, 7 Nov 2000 10:39:55 -0600 (CST) Subject: RedHat sshd.init script typo ? In-Reply-To: Message-ID: Same problem existed in sshd.init-5.x also. Both have been fixed now. Thanks. - Ben On Tue, 7 Nov 2000, Pekka Savola wrote: > On Tue, 7 Nov 2000, Jarno Huuskonen wrote: > > > > I noticed one small possible error in the > > openssh-2.3.0p1/contrib/redhat/sshd.init script. > > In the stop option: > > stop) > > echo -n "Shutting down sshd: " > > if [ -f $PID_FILE ] ; then > > killproc sshd > > [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/sshd > > fi > > echo > > > > Shouldn't there be RETVAL=$? after killproc sshd ? > > Yeah, RETVAL seems to have been omitted by mistake. The problem has been > there for a while now. Luckily enough, sshd won't break too badly for it. > :-/ > > -- > Pekka Savola "Tell me of difficulties surmounted, > Pekka.Savola at netcore.fi not those you stumble over and fall" > > From Donald.Smith at qwest.com Wed Nov 8 03:57:48 2000 From: Donald.Smith at qwest.com (Smith, Donald ) Date: Tue, 7 Nov 2000 09:57:48 -0700 Subject: RedHat sshd.init script typo ? Message-ID: <2D00AD0E4D36D411BD300008C786E4242299B5@Denntex021.qwest.net> Donald Smith Staff IP Engineer IP Network Engineering Security 303-226-9939 Office 303-226-0688 fax 720-320-1537 cell > -----Original Message----- > From: Jarno Huuskonen [mailto:jhuuskon at messi.uku.fi] > Sent: Tuesday, November 07, 2000 6:11 AM > To: openssh-unix-dev at mindrot.org > Subject: RedHat sshd.init script typo ? > > > Hi, > > I noticed one small possible error in the > openssh-2.3.0p1/contrib/redhat/sshd.init script. > In the stop option: > stop) > echo -n "Shutting down sshd: " > if [ -f $PID_FILE ] ; then > killproc sshd > [ $RETVAL -eq 0 ] && rm -f Why bother assigning RETVAL then comparing it to 0. How about a comment explaining $? # The return value from killproc is stored in $? (normal sh behavior) then [ $? -eq 0 ] && rm -f /var/lock/subsys/sshd > fi > echo This saves an assignment helps newbies understand that in borneshell $? is the decimal value returned by the last synchronously executed command. > > Shouldn't there be RETVAL=$? after killproc sshd ? > If this is the case here's a patch: > > --- sshd.init~ Mon Oct 16 04:25:17 2000 > +++ sshd.init Tue Nov 7 15:06:16 2000 > @@ -72,6 +72,7 @@ > echo -n "Shutting down sshd: " > if [ -f $PID_FILE ] ; then > killproc sshd > + RETVAL=$? > [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/sshd > fi > echo > > -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 pekkas at netcore.fi Wed Nov 8 04:15:22 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 7 Nov 2000 19:15:22 +0200 (EET) Subject: RedHat sshd.init script typo ? In-Reply-To: <2D00AD0E4D36D411BD300008C786E4242299B5@Denntex021.qwest.net> Message-ID: On Tue, 7 Nov 2000, Smith, Donald wrote: > Why bother assigning RETVAL then comparing it to 0. How about a comment > explaining $? > # The return value from killproc is stored in $? (normal sh behavior) then > [ $? -eq 0 ] && rm -f /var/lock/subsys/sshd > > fi > > echo > This saves an assignment helps newbies understand that in borneshell $? is > the decimal value returned by the last synchronously executed command. Assignment is not a big deal -- more readable than comments here :-) And it's used in there throughout the script. You couldn't use $? in every other circumstance there. -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From jmknoble at jmknoble.cx Wed Nov 8 04:36:30 2000 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Tue, 7 Nov 2000 12:36:30 -0500 Subject: RedHat sshd.init script typo ? In-Reply-To: <2D00AD0E4D36D411BD300008C786E4242299B5@Denntex021.qwest.net>; from Donald.Smith@qwest.com on Tue, Nov 07, 2000 at 09:57:48AM -0700 References: <2D00AD0E4D36D411BD300008C786E4242299B5@Denntex021.qwest.net> Message-ID: <20001107123630.B12715@shell.ntrnet.net> Circa 2000-Nov-07 09:57:48 -0700 dixit Smith, Donald : : Why bother assigning RETVAL then comparing it to 0. How about a comment : explaining $? : # The return value from killproc is stored in $? (normal sh behavior) then : [ $? -eq 0 ] && rm -f /var/lock/subsys/sshd : > fi : > echo : This saves an assignment helps newbies understand that in borneshell $? is : the decimal value returned by the last synchronously executed command. The init script ought to 'exit ${RETVAL}' as its last action; that's why to save the value of $? in RETVAL (though i can think of a much better name for that variable...). -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From mouring at pconline.com Wed Nov 8 04:56:05 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Tue, 7 Nov 2000 11:56:05 -0600 (CST) Subject: suggested bsd-setproctitle.c In-Reply-To: Message-ID: Looks good to me. Compiles cleaning under Linux Redhat 7.0 and NeXTStep 4.2. I doubt any other platform will have a problem with it. - Ben On Tue, 7 Nov 2000, Ben Lindstrom wrote: > > > On Tue, 7 Nov 2000, Kevin Steves wrote: > > > On Mon, 6 Nov 2000, Kevin Steves wrote: > > : ok, in main() programs we need to have: > > : > > : #ifndef HAVE___PROGNAME > > : const char *__progname = "foo"; > > : #else > > : extern char *__progname; > > : #endif > > > > How does the attached patch work? I tested on HP-UX > > !defined(HAVE___PROGNAME) and Linux defined(HAVE___PROGNAME). I don't > > use const now to keep things consistent, and went back to #ifdef > > HAVE___PROGNAME. > > > I'll try it later on, but just skimming the patch it seems to do the same > thing that I did last night. I would have posted my patch (which looks > just like it, but I left the 'const' in) last night if QWORST (US West + > Qwest) did not take out my ISP's Virtual ATM Circuit for DSL service for > almost 5 hours. > > - Ben > > > From Donald.Smith at qwest.com Wed Nov 8 04:54:43 2000 From: Donald.Smith at qwest.com (Smith, Donald ) Date: Tue, 7 Nov 2000 10:54:43 -0700 Subject: RedHat sshd.init script typo ? Message-ID: <2D00AD0E4D36D411BD300008C786E4242299B7@Denntex021.qwest.net> Donald Smith Staff IP Engineer IP Network Engineering Security 303-226-9939 Office 303-226-0688 fax 720-320-1537 cell > -----Original Message----- > From: Jim Knoble [mailto:jmknoble at jmknoble.cx] > Sent: Tuesday, November 07, 2000 10:37 AM > To: openssh-unix-dev at mindrot.org > Subject: Re: RedHat sshd.init script typo ? > > > Circa 2000-Nov-07 09:57:48 -0700 dixit Smith, Donald : > > : Why bother assigning RETVAL then comparing it to 0. How > about a comment > : explaining $? > : # The return value from killproc is stored in $? (normal sh > behavior) then > : [ $? -eq 0 ] && rm -f > /var/lock/subsys/sshd > : > fi > : > echo > : This saves an assignment helps newbies understand that in > borneshell $? is > : the decimal value returned by the last synchronously > executed command. > > The init script ought to 'exit ${RETVAL}' as its last action; that's > why to save the value of $? in RETVAL (though i can think of a much > better name for that variable...). Ok if you exit $(The_Return_Value_Of_The_killproc_AND_the_return_value_of_the_rm_Of_the_loc k) then I guess this makes sense. Odviously if the lock can't be removed that error should be reported also. > > -- > jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ > From mw at moni.msci.memphis.edu Wed Nov 8 06:32:01 2000 From: mw at moni.msci.memphis.edu (Mate Wierdl) Date: Tue, 7 Nov 2000 13:32:01 -0600 Subject: RedHat sshd.init script typo ? In-Reply-To: <2D00AD0E4D36D411BD300008C786E4242299B5@Denntex021.qwest.net>; from Donald.Smith@qwest.com on Tue, Nov 07, 2000 at 09:57:48AM -0700 References: <2D00AD0E4D36D411BD300008C786E4242299B5@Denntex021.qwest.net> Message-ID: <20001107133201.B8247@moni.msci.memphis.edu> On Tue, Nov 07, 2000 at 09:57:48AM -0700, Smith, Donald wrote: > Why bother assigning RETVAL then comparing it to 0. How about a comment > explaining $? Initscripts are not sh intros. But the point is that RH uses RETVAL in *every* initscript---and the value stored is used in return $RETVAL which is then used by various initfunctions to display the exit status of services with text and color. Mate From mw at moni.msci.memphis.edu Wed Nov 8 06:46:44 2000 From: mw at moni.msci.memphis.edu (Mate Wierdl) Date: Tue, 7 Nov 2000 13:46:44 -0600 Subject: RedHat sshd.init script typo ? In-Reply-To: <2D00AD0E4D36D411BD300008C786E4242299B7@Denntex021.qwest.net>; from Donald.Smith@qwest.com on Tue, Nov 07, 2000 at 10:54:43AM -0700 References: <2D00AD0E4D36D411BD300008C786E4242299B7@Denntex021.qwest.net> Message-ID: <20001107134643.C8247@moni.msci.memphis.edu> On Tue, Nov 07, 2000 at 10:54:43AM -0700, Smith, Donald wrote: > Ok if you exit > $(The_Return_Value_Of_The_killproc_AND_the_return_value_of_the_rm_Of_the_loc > k) > then I guess this makes sense. Odviously if the lock can't be removed that > error should be > reported also. RH only wants to report whether a service was successfully terminated/started---this is why they *explicitly* return with $RETVAL and not with the exit status of the stop() function. What I said in my previous post was wrong, though: the exit status of stop() is not used anywhere as far as I can tell. Mate From jreed at support.ddiworld.com Wed Nov 8 08:40:14 2000 From: jreed at support.ddiworld.com (joel w. reed) Date: Tue, 7 Nov 2000 16:40:14 -0500 Subject: bug in documentation for "Protocol" option Message-ID: <20001107164014.C13343@support.ddiworld.com> ssh.1 says Protocol Specifies the protocol versions ssh should support in order of preference. The possible values are ``1'' and ``2''. Multiple versions must be comma-separated. The default is ``1,2''. This means that ssh tries version 1 and falls back to version 2 if version 1 is not available. but /etc/ssh/ssh_config shows the default for Protocol as... # Port 22 # Protocol 2,1 # Cipher blowfish one of the above should be fixed. jr -- ------------------------------------------------------------------------ Joel W. Reed 412-257-3881 --------------All the simple programs have been written.---------------- -------------- 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/20001107/89a53e8d/attachment.bin From rob at hagopian.net Wed Nov 8 08:15:12 2000 From: rob at hagopian.net (Rob Hagopian) Date: Tue, 7 Nov 2000 16:15:12 -0500 (EST) Subject: bug in documentation for "Protocol" option In-Reply-To: <20001107164014.C13343@support.ddiworld.com> Message-ID: I believe I was told that there are some theoretical weaknesses with protocol 1? And since ssh.com uses 2 by default shouldn't this be the same for openssh? Also, in another case of the default isn't really the default: # StrictHostKeyChecking no The default is actually yes if it's commented out (and I believe this one should be yes even though I always turn it off manually :-) ) so the conf file should be changed? -Rob On Tue, 7 Nov 2000, joel w. reed wrote: > ssh.1 says > > Protocol Specifies the protocol versions ssh should support in order of > preference. The possible values are ``1'' and ``2''. Multiple > versions must be comma-separated. The default is ``1,2''. This > means that ssh tries version 1 and falls back to version 2 if > version 1 is not available. > > but /etc/ssh/ssh_config shows the default for Protocol as... > > # Port 22 > # Protocol 2,1 > # Cipher blowfish > > one of the above should be fixed. > > jr > > From pekkas at netcore.fi Wed Nov 8 08:20:13 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 7 Nov 2000 23:20:13 +0200 (EET) Subject: bug in documentation for "Protocol" option In-Reply-To: <20001107164014.C13343@support.ddiworld.com> Message-ID: On Tue, 7 Nov 2000, joel w. reed wrote: > ssh.1 says > > Protocol Specifies the protocol versions ssh should support in order of > preference. The possible values are ``1'' and ``2''. Multiple > versions must be comma-separated. The default is ``1,2''. This > means that ssh tries version 1 and falls back to version 2 if > version 1 is not available. > > but /etc/ssh/ssh_config shows the default for Protocol as... > > # Port 22 > # Protocol 2,1 > # Cipher blowfish > > one of the above should be fixed. Both are correct. ssh uses Protocol 1 by default if nothing else is defined. What's written _commented out_ in ssh_config is of no consequence; default Cipher isn't blowfish either, etc.. If you uncomment the line there, it obviously changes the default ... -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From dcp at sgi.com Wed Nov 8 08:38:11 2000 From: dcp at sgi.com (Dennis Parker) Date: Tue, 7 Nov 2000 15:38:11 -0600 (CST) Subject: new Irix feature Message-ID: <200011072138.PAA11357@yooper.americas.sgi.com> SGI's Irix operating system contains a new feature called job limits. I'll skip the description of what exactly job limits is for now (I'll happily send it to anyone who's interested). Suffice it to say that login, telnet, rshd, rexecd, etc have all been modified to support job limits and I'd like to get openssh modified as well. I've downloaded the 2.2.0p1 source, added the necessary couple of lines of code and tested it out. Everything seems to work fine. How do I go about getting the changes accepted into the openssh release? Thanks for any info you can send me. - Dennis Parker dcp at sgi.com From mouring at pconline.com Wed Nov 8 08:44:53 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Tue, 7 Nov 2000 15:44:53 -0600 (CST) Subject: new Irix feature In-Reply-To: <200011072138.PAA11357@yooper.americas.sgi.com> Message-ID: The first step would be to port up to 2.3.0p1 that was recently release. Then point us to what patch. The less code you touch in the core OpenSSH tree the more likely it will be accepted. That's pretty much it. I'd be interested in this "job limits" and why SGI decided to create them.=) On Tue, 7 Nov 2000, Dennis Parker wrote: > SGI's Irix operating system contains a new feature called job limits. I'll > skip the description of what exactly job limits is for now (I'll happily send > it to anyone who's interested). Suffice it to say that login, telnet, rshd, > rexecd, etc have all been modified to support job limits and I'd like to get > openssh modified as well. I've downloaded the 2.2.0p1 source, added the > necessary couple of lines of code and tested it out. Everything seems to > work fine. > > How do I go about getting the changes accepted into the openssh release? > Thanks for any info you can send me. > > - Dennis Parker > dcp at sgi.com > From pekkas at netcore.fi Wed Nov 8 08:46:56 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 7 Nov 2000 23:46:56 +0200 (EET) Subject: new Irix feature In-Reply-To: <200011072138.PAA11357@yooper.americas.sgi.com> Message-ID: On Tue, 7 Nov 2000, Dennis Parker wrote: > SGI's Irix operating system contains a new feature called job limits. I'll > skip the description of what exactly job limits is for now (I'll happily send > it to anyone who's interested). Suffice it to say that login, telnet, rshd, > rexecd, etc have all been modified to support job limits and I'd like to get > openssh modified as well. I've downloaded the 2.2.0p1 source, added the > necessary couple of lines of code and tested it out. Everything seems to > work fine. > > How do I go about getting the changes accepted into the openssh release? > Thanks for any info you can send me. Send the patch on the list. :-) I'd make a 2.3.0p1 version first though, shouldn't be difficult. -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From rob at hagopian.net Wed Nov 8 08:52:56 2000 From: rob at hagopian.net (Rob Hagopian) Date: Tue, 7 Nov 2000 16:52:56 -0500 (EST) Subject: bug in documentation for "Protocol" option In-Reply-To: Message-ID: I believe the point is that the commented out lines in ssh_config should really reflect the defaults. At least ssh.com does, and while I can't point to any other concrete examples, it strikes me as common practice to do so. -Rob On Tue, 7 Nov 2000, Pekka Savola wrote: > On Tue, 7 Nov 2000, joel w. reed wrote: > > ssh.1 says > > > > Protocol Specifies the protocol versions ssh should support in order of > > preference. The possible values are ``1'' and ``2''. Multiple > > versions must be comma-separated. The default is ``1,2''. This > > means that ssh tries version 1 and falls back to version 2 if > > version 1 is not available. > > > > but /etc/ssh/ssh_config shows the default for Protocol as... > > > > # Port 22 > > # Protocol 2,1 > > # Cipher blowfish > > > > one of the above should be fixed. > > Both are correct. > > ssh uses Protocol 1 by default if nothing else is defined. What's written > _commented out_ in ssh_config is of no consequence; default Cipher isn't > blowfish either, etc.. > > If you uncomment the line there, it obviously changes the default ... > > From pekkas at netcore.fi Wed Nov 8 08:55:03 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 7 Nov 2000 23:55:03 +0200 (EET) Subject: bug in documentation for "Protocol" option In-Reply-To: Message-ID: On Tue, 7 Nov 2000, Rob Hagopian wrote: > I believe the point is that the commented out lines in ssh_config should > really reflect the defaults. At least ssh.com does, and while I can't > point to any other concrete examples, it strikes me as common practice to > do so. > -Rob Well, the only value for them that way would be another default reference. IMO, it's better to have settings like "if you have to change this to non-default, this is what you'd probably want to use". -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From gert at greenie.muc.de Wed Nov 8 10:00:22 2000 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 8 Nov 2000 00:00:22 +0100 Subject: Another shapshot In-Reply-To: <20001105013847.A21297@greenie.muc.de>; from Gert Doering on Sun, Nov 05, 2000 at 01:38:47AM +0100 References: <20001103171119.C13824@greenie.muc.de> <20001104111520.B24338@folly> <20001104112232.A6920@greenie.muc.de> <20001104183020.B14315@greenie.muc.de> <20001104200524.A24226@folly> <20001105013341.C14315@greenie.muc.de> <20001105013847.A21297@greenie.muc.de> Message-ID: <20001108000022.I4747@greenie.muc.de> Hi, On Sun, Nov 05, 2000 at 01:38:47AM +0100, Gert Doering wrote: > Idea. What it does is: > > ptr = (up[2] + up[3]) % 99 ... > > - do, by chance, the first 4 bytes of "up" contain a long int and the code > is adding the two "low bytes" together? I'm on a big endian machine > (PowerPC) and if that is so, this might need byte-swapping... No. Tried using up[0]+up[1] instead, but that also gives me a constant number - the first always gives me "58", the second "85", but neither gives the current challenge. So - is anybody working on S/Key in OpenSSH? Is somebody using it on a non-BSD platform? If yes, what did you do, which s/key library, which CPU endianness, ...? Is anybody interested in getting this to work? I think a portable way to do OTPs is very important. 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 rob at hagopian.net Wed Nov 8 10:05:19 2000 From: rob at hagopian.net (Rob Hagopian) Date: Tue, 7 Nov 2000 18:05:19 -0500 (EST) Subject: bug in documentation for "Protocol" option In-Reply-To: Message-ID: Then it should be clear which are defaults and which aren't; now it's a mix of the two, which is made worse by the text at the top that implies that the file contains defaults (while the text is technically accurate because all the options are commented out, I found it misleading). I'm not sure how your system would work for some settings like: # IdentityFile ~/.ssh/identity # EscapeChar ~ # Port 22 and most of the others which are indeed the defaults as described in the man page... I can't think of too many non-default settings that would qualify as "probably want to use" for these... How about a section in the default ssh*_config that has all of the settings and their default values, all commented out, as a quick reference for people? It's a lot easier than cross checking the man page for each setting... -Rob On Tue, 7 Nov 2000, Pekka Savola wrote: > On Tue, 7 Nov 2000, Rob Hagopian wrote: > > > I believe the point is that the commented out lines in ssh_config should > > really reflect the defaults. At least ssh.com does, and while I can't > > point to any other concrete examples, it strikes me as common practice to > > do so. > > -Rob > > Well, the only value for them that way would be another default reference. > > IMO, it's better to have settings like "if you have to change this to > non-default, this is what you'd probably want to use". > > From pekkas at netcore.fi Wed Nov 8 10:30:08 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 8 Nov 2000 01:30:08 +0200 (EET) Subject: bug in documentation for "Protocol" option In-Reply-To: Message-ID: On Tue, 7 Nov 2000, Rob Hagopian wrote: > # IdentityFile ~/.ssh/identity > # EscapeChar ~ > # Port 22 > > and most of the others which are indeed the defaults as described in the > man page... I can't think of too many non-default settings that would > qualify as "probably want to use" for these... No, and that's why there are the defaults there for those. Sometimes I use settings like: --- Host * ForwardAgent no ForwardX11 yes FallBackToRsh no Protocol 2,1 Cipher blowfish Ciphers arcfour,blowfish-cbc --- [ good for heavy traffic because arcfour is the fastest algorithm ] *Authentication, Cipher*, Protocol etc. options are ones you usually want to change. Having them as defaults has it's good and bad points, obviously. > How about a section in the default ssh*_config that has all of the > settings and their default values, all commented out, as a quick reference > for people? It's a lot easier than cross checking the man page for each > setting... Committing to this would get you yet another place to keep track of these... -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From jreed at support.ddiworld.com Wed Nov 8 12:29:28 2000 From: jreed at support.ddiworld.com (joel w. reed) Date: Tue, 7 Nov 2000 20:29:28 -0500 Subject: bug in documentation for "Protocol" option In-Reply-To: ; from rob@hagopian.net on Tue, Nov 07, 2000 at 06:05:19PM -0500 References: Message-ID: <20001107202928.A22974@support.ddiworld.com> On Nov 07, rob at hagopian.net contorted a few electrons to say... Rob> Then it should be clear which are defaults and which aren't; now it's a Rob> mix of the two, which is made worse by the text at the top that implies Rob> that the file contains defaults (while the text is technically accurate Rob> because all the options are commented out, I found it misleading). this was my point. clearly the text at the top says "these are the default settings if you don't specify anything" - but at least for Protocol it is wrong & should be fixed. jr -- ------------------------------------------------------------------------ Joel W. Reed 412-257-3881 --------------All the simple programs have been written.---------------- -------------- 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/20001107/4745851c/attachment.bin From mouring at pconline.com Wed Nov 8 12:10:17 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Tue, 7 Nov 2000 19:10:17 -0600 (CST) Subject: Minor fixes for openssh-SNAP-20001028 In-Reply-To: <20001030151615.A14498@enterprise.isdn.uiuc.edu> Message-ID: Hmm..this one fell through the craks. Thanks to someone on #unixhelp for bring it up again. I applied the patch for fixpaths. I'm declining to apply the second patch until Steve and I finish with the rework of __progname (which should be done. Steve just needs to commit it). Grab the progname2.patch from Steve's last posted and let us know if there is still a problem. - Ben On Mon, 30 Oct 2000, Mark D. Roth wrote: > I've attached a patch for openssh-SNAP-20001028 which fixes the > following two problems: > > 1) I fixed fixpaths to complain instead of failing silently if it > can't write the output file. > > 2) I changed log-server.c to use av0 as the first argument to > openlog(). I also made sure it called openlog() before the TCP > wrapper stuff, because libwrap calls syslog() and winds up using > the wrong program name. > > Please let me know if you have any questions or problems. Thanks! > > -- > Mark D. Roth > http://www.feep.net/~roth/ > From dbt at meat.net Wed Nov 8 12:16:22 2000 From: dbt at meat.net (David Terrell) Date: Tue, 7 Nov 2000 17:16:22 -0800 Subject: suggested bsd-setproctitle.c In-Reply-To: ; from stevesk@sweden.hp.com on Mon, Nov 06, 2000 at 06:52:02AM +0100 References: Message-ID: <20001107171622.A17606@pianosa.catch22.org> On Mon, Nov 06, 2000 at 06:52:02AM +0100, Kevin Steves wrote: > That should work. But it seems this __progname issue could be cleaned > up by defining the variable in main() files if needed: > > #ifndef HAVE___PROGNAME > const char *__progname = "foo"; > #endif > > then declaring it (no ifdefs) if it's referenced: > > extern const char *__progname; > > This gets us closer to OpenBSD's tree with fewer ifdefs. > > I'll do this patch unless someone points out what it will break :) It breaks the actual functionality of __progname, which is roughly equivelent to basename(argv[0]). -- David Terrell | p = "you are nasty" q = "my first name is Janet" Nebcorp PM | r = "my first name is baby" s = "My name is Miss Jackson" dbt at meat.net | (!r -> q) & (p -> s) - Braverman's Third Lemma wwn.nebcorp.com | !r & (!p -> q) & (p -> s) - Libor's Corrolary From dbt at meat.net Wed Nov 8 12:49:57 2000 From: dbt at meat.net (David Terrell) Date: Tue, 7 Nov 2000 17:49:57 -0800 Subject: suggested bsd-setproctitle.c In-Reply-To: <20001107171622.A17606@pianosa.catch22.org>; from dbt@meat.net on Tue, Nov 07, 2000 at 05:16:22PM -0800 References: <20001107171622.A17606@pianosa.catch22.org> Message-ID: <20001107174957.C17606@pianosa.catch22.org> On Tue, Nov 07, 2000 at 05:16:22PM -0800, David Terrell wrote: > On Mon, Nov 06, 2000 at 06:52:02AM +0100, Kevin Steves wrote: > > That should work. But it seems this __progname issue could be cleaned > > up by defining the variable in main() files if needed: > > > > #ifndef HAVE___PROGNAME > > const char *__progname = "foo"; > > #endif > > > > then declaring it (no ifdefs) if it's referenced: > > > > extern const char *__progname; > > > > This gets us closer to OpenBSD's tree with fewer ifdefs. > > > > I'll do this patch unless someone points out what it will break :) > > It breaks the actual functionality of __progname, which is roughly > equivelent to basename(argv[0]). To make a more useful suggestion: #ifndef HAVE___PROGNAME char *__progname; #endif then in main() #ifndef HAVE___PROGNAME __progname = xstrdup(basename(argv[0]); #endif It's not a const, though. Tread carefully. Make sure not to pass it to printf()-like functions as a format string, especially in ssh, where it could be setuid. etc. Dave, who can write up a pretty patch if desired, I don't have the portable source tree around right now. -- David Terrell | "To increase the hype, I'm gonna release a bunch Nebcorp PM | of BLT variants (NetBLT, FreeBLT, BLT386, etc) dbt at meat.net | and create artificial rivalries." wwn.nebcorp.com | - Brian Sweltand (www.openblt.org) From mouring at pconline.com Wed Nov 8 12:52:26 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Tue, 7 Nov 2000 19:52:26 -0600 (CST) Subject: suggested bsd-setproctitle.c In-Reply-To: <20001107171622.A17606@pianosa.catch22.org> Message-ID: On Tue, 7 Nov 2000, David Terrell wrote: > On Mon, Nov 06, 2000 at 06:52:02AM +0100, Kevin Steves wrote: > > > > I'll do this patch unless someone points out what it will break :) > > It breaks the actual functionality of __progname, which is roughly > equivelent to basename(argv[0]). > Hmm...It's technically broken as it is. Most of the patch is right. Just the section for ssh-add, sshd, ssh, scp, ssh-agent, etc are wrong. Is this much more to everyone's liking? It moves the assignment of the value of __progname to the main() and only use if it HAVE__PROGNAME is fault.. Ermm.. I just noticed I missed scp.c =) Which I'm fixing now. - Ben -------------- next part -------------- diff -u openssh/ChangeLog ossh/ChangeLog --- openssh/ChangeLog Tue Nov 7 19:58:00 2000 +++ ossh/ChangeLog Tue Nov 7 20:43:06 2000 @@ -5,6 +5,8 @@ Jarno Huuskonen - (bal) fixpaths fixed to stop it from quitely failing. Patch by Mark D. Roth + - (stevesk & bal) Clean up __progname definations w/ suggestion from + David Terrell 20001106 - (djm) Use Jim's new 1.0.3 askpass in Redhat RPMs diff -u openssh/bsd-setproctitle.c ossh/bsd-setproctitle.c --- openssh/bsd-setproctitle.c Mon Nov 6 02:07:18 2000 +++ ossh/bsd-setproctitle.c Tue Nov 7 20:22:25 2000 @@ -56,11 +56,7 @@ #define MAX_PROCTITLE 2048 -#ifdef HAVE___PROGNAME extern char *__progname; -#else -static const char *__progname = "sshd"; -#endif /* HAVE___PROGNAME */ /* * Set Process Title (SPT) defines. Modeled after sendmail's diff -u openssh/log-server.c ossh/log-server.c --- openssh/log-server.c Fri Sep 15 21:29:09 2000 +++ ossh/log-server.c Tue Nov 7 20:22:25 2000 @@ -43,12 +43,6 @@ #include "xmalloc.h" #include "ssh.h" -#ifdef HAVE___PROGNAME -extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "sshd"; -#endif /* HAVE___PROGNAME */ - static LogLevel log_level = SYSLOG_LEVEL_INFO; static int log_on_stderr = 0; static int log_facility = LOG_AUTH; @@ -129,6 +123,7 @@ char fmtbuf[MSGBUFSIZ]; char *txt = NULL; int pri = LOG_INFO; + extern char *__progname; if (level > log_level) return; diff -u openssh/session.c ossh/session.c --- openssh/session.c Fri Oct 27 22:19:58 2000 +++ ossh/session.c Tue Nov 7 20:22:25 2000 @@ -128,12 +128,7 @@ /* import */ extern ServerOptions options; -#ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "sshd"; -#endif /* HAVE___PROGNAME */ - extern int log_stderr; extern int debug_flag; extern unsigned int utmp_len; diff -u openssh/sftp-server.c ossh/sftp-server.c --- openssh/sftp-server.c Fri Sep 22 22:58:32 2000 +++ ossh/sftp-server.c Tue Nov 7 20:39:14 2000 @@ -90,6 +90,12 @@ #define get_string(lenp) buffer_get_string(&iqueue, lenp); #define TRACE log +#ifdef HAVE___PROGNAME +extern char *__progname; +#else +char *__progname; +#endif + /* input and output queue */ Buffer iqueue; Buffer oqueue; @@ -1014,6 +1020,9 @@ fd_set rset, wset; int in, out, max; ssize_t len, olen; +#ifndef HAVE___PROGNAME + __progname = xstrdup(basename(argv[0]); +#endif handle_init(); diff -u openssh/ssh-add.c ossh/ssh-add.c --- openssh/ssh-add.c Tue Oct 17 07:22:28 2000 +++ ossh/ssh-add.c Tue Nov 7 20:37:38 2000 @@ -50,9 +50,9 @@ #ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh-add"; -#endif /* HAVE___PROGNAME */ +#else +char *__progname; +#endif void delete_file(AuthenticationConnection *ac, const char *filename) @@ -247,6 +247,9 @@ int no_files = 1; int i; int deleting = 0; +#ifndef HAVE___PROGNAME + __progname = xstrdup(basename(argv[0]); +#endif init_rng(); diff -u openssh/ssh-agent.c ossh/ssh-agent.c --- openssh/ssh-agent.c Fri Sep 29 07:01:37 2000 +++ ossh/ssh-agent.c Tue Nov 7 20:39:57 2000 @@ -94,9 +94,9 @@ #ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh-agent"; -#endif /* HAVE___PROGNAME */ +#else +char *__progname; +#endif void idtab_init(void) @@ -667,6 +667,9 @@ pid_t pid; char *shell, *format, *pidstr, pidstrbuf[1 + 3 * sizeof pid]; extern int optind; +#ifndef HAVE___PROGNAME + __progname = xstrdup(basename(argv[0]); +#endif init_rng(); diff -u openssh/ssh-keygen.c ossh/ssh-keygen.c --- openssh/ssh-keygen.c Sat Oct 14 00:23:12 2000 +++ ossh/ssh-keygen.c Tue Nov 7 20:40:19 2000 @@ -72,9 +72,9 @@ /* argv0 */ #ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh-keygen"; -#endif /* HAVE___PROGNAME */ +#else +char *__progname; +#endif char hostname[MAXHOSTNAMELEN]; @@ -602,6 +602,9 @@ Key *public; extern int optind; extern char *optarg; +#ifndef HAVE___PROGNAME + __progname = xstrdup(basename(argv[0]); +#endif init_rng(); diff -u openssh/ssh.c ossh/ssh.c --- openssh/ssh.c Fri Oct 27 22:19:58 2000 +++ ossh/ssh.c Tue Nov 7 20:40:46 2000 @@ -61,9 +61,9 @@ #ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh"; -#endif /* HAVE___PROGNAME */ +#else +char *__progname; +#endif /* Flag indicating whether IPv4 or IPv6. This can be set on the command line. Default value is AF_UNSPEC means both IPv4 and IPv6. */ @@ -234,6 +234,9 @@ struct passwd *pw, pwcopy; int dummy; uid_t original_effective_uid; +#ifndef HAVE___PROGNAME + __progname = xstrdup(basename(argv[0]); +#endif init_rng(); diff -u openssh/sshconnect.c ossh/sshconnect.c --- openssh/sshconnect.c Sat Sep 23 01:15:57 2000 +++ ossh/sshconnect.c Tue Nov 7 20:22:25 2000 @@ -35,11 +35,7 @@ char *server_version_string = NULL; extern Options options; -#ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh"; -#endif /* HAVE___PROGNAME */ /* * Connect to the given ssh server using a proxy command. diff -u openssh/sshd.c ossh/sshd.c --- openssh/sshd.c Sat Oct 14 00:23:13 2000 +++ ossh/sshd.c Tue Nov 7 20:41:11 2000 @@ -79,6 +79,12 @@ #define O_NOCTTY 0 #endif +#ifdef HAVE___PROGNAME +extern char *__progname; +#else +char *__progname; +#endif + /* Server configuration options. */ ServerOptions options; @@ -491,6 +497,9 @@ int listen_sock, maxfd; int startup_p[2]; int startups = 0; +#ifndef HAVE___PROGNAME + __progname = xstrdup(basename(argv[0]); +#endif init_rng(); From mouring at pconline.com Wed Nov 8 13:14:48 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Tue, 7 Nov 2000 20:14:48 -0600 (CST) Subject: suggested bsd-setproctitle.c In-Reply-To: Message-ID: On Tue, 7 Nov 2000, Ben Lindstrom wrote: > > On Tue, 7 Nov 2000, David Terrell wrote: > > > On Mon, Nov 06, 2000 at 06:52:02AM +0100, Kevin Steves wrote: > > > > > > I'll do this patch unless someone points out what it will break :) > > > > It breaks the actual functionality of __progname, which is roughly > > equivelent to basename(argv[0]). > > > Hmm...It's technically broken as it is. > > Most of the patch is right. Just the section for ssh-add, sshd, ssh, scp, > ssh-agent, etc are wrong. > > Is this much more to everyone's liking? > > It moves the assignment of the value of __progname to the main() and only > use if it HAVE__PROGNAME is fault.. > > Ermm.. I just noticed I missed scp.c =) Which I'm fixing now. > Bah... Someone should go put together a patch to make main(..) defines the same.=) There are a few problems more with that patch.. argv[0] vs av[0] ... Nice thing about having old UNIX boxes around..they catch stupid mistakes. =) From stevesk at sweden.hp.com Wed Nov 8 01:46:13 2000 From: stevesk at sweden.hp.com (Kevin Steves) Date: Tue, 7 Nov 2000 15:46:13 +0100 (CET) Subject: suggested bsd-setproctitle.c In-Reply-To: Message-ID: <200011071428.PAA10784@b0fh.sweden.hp.com> On Mon, 6 Nov 2000, Kevin Steves wrote: : ok, in main() programs we need to have: : : #ifndef HAVE___PROGNAME : const char *__progname = "foo"; : #else : extern char *__progname; : #endif How does the attached patch work? I tested on HP-UX !defined(HAVE___PROGNAME) and Linux defined(HAVE___PROGNAME). I don't use const now to keep things consistent, and went back to #ifdef HAVE___PROGNAME. -------------- next part -------------- Index: bsd-setproctitle.c =================================================================== RCS file: /var/cvs/openssh/bsd-setproctitle.c,v retrieving revision 1.1 diff -u -r1.1 bsd-setproctitle.c --- bsd-setproctitle.c 2000/10/18 13:11:44 1.1 +++ bsd-setproctitle.c 2000/11/07 13:53:49 @@ -56,11 +56,7 @@ #define MAX_PROCTITLE 2048 -#ifdef HAVE___PROGNAME extern char *__progname; -#else -static const char *__progname = "sshd"; -#endif /* HAVE___PROGNAME */ /* * Set Process Title (SPT) defines. Modeled after sendmail's Index: log-server.c =================================================================== RCS file: /var/cvs/openssh/log-server.c,v retrieving revision 1.12 diff -u -r1.12 log-server.c --- log-server.c 2000/09/16 02:29:09 1.12 +++ log-server.c 2000/11/07 13:53:49 @@ -43,12 +43,6 @@ #include "xmalloc.h" #include "ssh.h" -#ifdef HAVE___PROGNAME -extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "sshd"; -#endif /* HAVE___PROGNAME */ - static LogLevel log_level = SYSLOG_LEVEL_INFO; static int log_on_stderr = 0; static int log_facility = LOG_AUTH; @@ -129,6 +123,7 @@ char fmtbuf[MSGBUFSIZ]; char *txt = NULL; int pri = LOG_INFO; + extern char *__progname; if (level > log_level) return; Index: sshconnect.c =================================================================== RCS file: /var/cvs/openssh/sshconnect.c,v retrieving revision 1.44 diff -u -r1.44 sshconnect.c --- sshconnect.c 2000/09/23 06:15:57 1.44 +++ sshconnect.c 2000/11/07 13:53:52 @@ -35,11 +35,7 @@ char *server_version_string = NULL; extern Options options; -#ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh"; -#endif /* HAVE___PROGNAME */ /* * Connect to the given ssh server using a proxy command. Index: session.c =================================================================== RCS file: /var/cvs/openssh/session.c,v retrieving revision 1.52 diff -u -r1.52 session.c --- session.c 2000/10/28 03:19:58 1.52 +++ session.c 2000/11/07 13:53:56 @@ -128,12 +128,7 @@ /* import */ extern ServerOptions options; -#ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "sshd"; -#endif /* HAVE___PROGNAME */ - extern int log_stderr; extern int debug_flag; extern unsigned int utmp_len; Index: ssh-add.c =================================================================== RCS file: /var/cvs/openssh/ssh-add.c,v retrieving revision 1.26 diff -u -r1.26 ssh-add.c --- ssh-add.c 2000/10/17 12:22:28 1.26 +++ ssh-add.c 2000/11/07 13:53:56 @@ -50,9 +50,9 @@ #ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh-add"; -#endif /* HAVE___PROGNAME */ +#else +char *__progname = "ssh-add"; +#endif void delete_file(AuthenticationConnection *ac, const char *filename) Index: ssh-agent.c =================================================================== RCS file: /var/cvs/openssh/ssh-agent.c,v retrieving revision 1.33 diff -u -r1.33 ssh-agent.c --- ssh-agent.c 2000/09/29 12:01:37 1.33 +++ ssh-agent.c 2000/11/07 13:53:58 @@ -94,9 +94,9 @@ #ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh-agent"; -#endif /* HAVE___PROGNAME */ +#else +char *__progname = "ssh-agent"; +#endif void idtab_init(void) Index: ssh-keygen.c =================================================================== RCS file: /var/cvs/openssh/ssh-keygen.c,v retrieving revision 1.26 diff -u -r1.26 ssh-keygen.c --- ssh-keygen.c 2000/10/14 05:23:12 1.26 +++ ssh-keygen.c 2000/11/07 13:53:58 @@ -72,9 +72,9 @@ /* argv0 */ #ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh-keygen"; -#endif /* HAVE___PROGNAME */ +#else +char *__progname = "ssh-keygen"; +#endif char hostname[MAXHOSTNAMELEN]; Index: ssh.c =================================================================== RCS file: /var/cvs/openssh/ssh.c,v retrieving revision 1.47 diff -u -r1.47 ssh.c --- ssh.c 2000/10/28 03:19:58 1.47 +++ ssh.c 2000/11/07 13:54:03 @@ -61,9 +61,9 @@ #ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh"; -#endif /* HAVE___PROGNAME */ +#else +char *__progname = "ssh"; +#endif /* Flag indicating whether IPv4 or IPv6. This can be set on the command line. Default value is AF_UNSPEC means both IPv4 and IPv6. */ Index: sftp-server.c =================================================================== RCS file: /var/cvs/openssh/sftp-server.c,v retrieving revision 1.3 diff -u -r1.3 sftp-server.c --- sftp-server.c 2000/09/23 03:58:32 1.3 +++ sftp-server.c 2000/11/07 13:54:03 @@ -90,6 +90,12 @@ #define get_string(lenp) buffer_get_string(&iqueue, lenp); #define TRACE log +#ifdef HAVE___PROGNAME +extern char *__progname; +#else +char *__progname = "sftp-server"; +#endif + /* input and output queue */ Buffer iqueue; Buffer oqueue; Index: sshd.c =================================================================== RCS file: /var/cvs/openssh/sshd.c,v retrieving revision 1.94 diff -u -r1.94 sshd.c --- sshd.c 2000/10/14 05:23:13 1.94 +++ sshd.c 2000/11/07 13:54:07 @@ -79,6 +79,12 @@ #define O_NOCTTY 0 #endif +#ifdef HAVE___PROGNAME +extern char *__progname; +#else +char *__progname = "sshd"; +#endif + /* Server configuration options. */ ServerOptions options; Index: ChangeLog =================================================================== RCS file: /var/cvs/openssh/ChangeLog,v retrieving revision 1.519 diff -u -r1.519 ChangeLog --- ChangeLog 2000/11/06 07:15:43 1.519 +++ ChangeLog 2000/11/07 13:54:17 @@ -11,6 +11,7 @@ - (bal) typo in configure.in in regards to --with-ldflags from Marko Asplund - (bal) fixed next-posix.h. Forgot prototype of getppid(). + - (stevesk) Clean up __progname definitions. 20001105 - (bal) Sync with OpenBSD: From roth at feep.net Wed Nov 8 15:53:32 2000 From: roth at feep.net (Mark D. Roth) Date: Tue, 7 Nov 2000 22:53:32 -0600 Subject: suggested bsd-setproctitle.c In-Reply-To: <200011071428.PAA10784@b0fh.sweden.hp.com>; from stevesk@sweden.hp.com on Tue, Nov 07, 2000 at 03:46:13PM +0100 References: <200011071428.PAA10784@b0fh.sweden.hp.com> Message-ID: <20001107225332.A3352@yorktown.isdn.uiuc.edu> On Tue Nov 07 15:46 2000 +0100, Kevin Steves wrote: > How does the attached patch work? I tested on HP-UX > !defined(HAVE___PROGNAME) and Linux defined(HAVE___PROGNAME). I don't > use const now to keep things consistent, and went back to #ifdef > HAVE___PROGNAME. Unfortunately, you're still setting __progname to a hard-coded value instead of basename(argv[0]), which means that you don't get a reasonable value when you invoke one of these programs using something other than the default name. I'd suggest the attached patch instead. I'm not super familiar with the code, so please let me know if I'm missing something here... Thanks! -- Mark D. Roth http://www.feep.net/~roth/ -------------- next part -------------- diff -urN openssh-2.3.0p1/bsd-setproctitle.c openssh-2.3.0p1-new/bsd-setproctitle.c --- openssh-2.3.0p1/bsd-setproctitle.c Wed Oct 18 08:11:44 2000 +++ openssh-2.3.0p1-new/bsd-setproctitle.c Tue Nov 7 22:24:36 2000 @@ -56,11 +56,7 @@ #define MAX_PROCTITLE 2048 -#ifdef HAVE___PROGNAME extern char *__progname; -#else -static const char *__progname = "sshd"; -#endif /* HAVE___PROGNAME */ /* * Set Process Title (SPT) defines. Modeled after sendmail's diff -urN openssh-2.3.0p1/log-server.c openssh-2.3.0p1-new/log-server.c --- openssh-2.3.0p1/log-server.c Fri Sep 15 21:29:09 2000 +++ openssh-2.3.0p1-new/log-server.c Tue Nov 7 22:24:51 2000 @@ -43,11 +43,7 @@ #include "xmalloc.h" #include "ssh.h" -#ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "sshd"; -#endif /* HAVE___PROGNAME */ static LogLevel log_level = SYSLOG_LEVEL_INFO; static int log_on_stderr = 0; diff -urN openssh-2.3.0p1/session.c openssh-2.3.0p1-new/session.c --- openssh-2.3.0p1/session.c Fri Oct 27 22:19:58 2000 +++ openssh-2.3.0p1-new/session.c Tue Nov 7 22:25:02 2000 @@ -128,11 +128,7 @@ /* import */ extern ServerOptions options; -#ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "sshd"; -#endif /* HAVE___PROGNAME */ extern int log_stderr; extern int debug_flag; diff -urN openssh-2.3.0p1/sftp-server.c openssh-2.3.0p1-new/sftp-server.c --- openssh-2.3.0p1/sftp-server.c Fri Sep 22 22:58:32 2000 +++ openssh-2.3.0p1-new/sftp-server.c Tue Nov 7 22:51:49 2000 @@ -30,6 +30,10 @@ #include "getput.h" #include "xmalloc.h" +#ifndef HAVE___PROGNAME +char *__progname; +#endif /* ! HAVE___PROGNAME */ + /* version */ #define SSH_FILEXFER_VERSION 2 @@ -1014,6 +1018,12 @@ fd_set rset, wset; int in, out, max; ssize_t len, olen; + +#ifndef HAVE___PROGNAME + __progname = xstrdup(strrchr(av[0], '/') + 1); + if (__progname == NULL) + __progname = "sftp-server"; +#endif /* ! HAVE___PROGNAME */ handle_init(); diff -urN openssh-2.3.0p1/ssh-add.c openssh-2.3.0p1-new/ssh-add.c --- openssh-2.3.0p1/ssh-add.c Tue Oct 17 07:22:28 2000 +++ openssh-2.3.0p1-new/ssh-add.c Tue Nov 7 22:49:42 2000 @@ -48,10 +48,8 @@ #include "authfd.h" #include "authfile.h" -#ifdef HAVE___PROGNAME -extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh-add"; +#ifndef HAVE___PROGNAME +char *__progname; #endif /* HAVE___PROGNAME */ void @@ -247,6 +245,12 @@ int no_files = 1; int i; int deleting = 0; + +#ifndef HAVE___PROGNAME + __progname = xstrdup(strrchr(argv[0], '/') + 1); + if (__progname == NULL) + __progname = "ssh-add"; +#endif /* ! HAVE___PROGNAME */ init_rng(); diff -urN openssh-2.3.0p1/ssh-agent.c openssh-2.3.0p1-new/ssh-agent.c --- openssh-2.3.0p1/ssh-agent.c Fri Sep 29 07:01:37 2000 +++ openssh-2.3.0p1-new/ssh-agent.c Tue Nov 7 22:46:04 2000 @@ -92,10 +92,8 @@ char socket_name[1024]; char socket_dir[1024]; -#ifdef HAVE___PROGNAME -extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh-agent"; +#ifndef HAVE___PROGNAME +char *__progname; #endif /* HAVE___PROGNAME */ void @@ -667,6 +665,12 @@ pid_t pid; char *shell, *format, *pidstr, pidstrbuf[1 + 3 * sizeof pid]; extern int optind; + +#ifndef HAVE___PROGNAME + __progname = xstrdup(strrchr(av[0], '/') + 1); + if (__progname == NULL) + __progname = "ssh-agent"; +#endif /* ! HAVE___PROGNAME */ init_rng(); diff -urN openssh-2.3.0p1/ssh-keygen.c openssh-2.3.0p1-new/ssh-keygen.c --- openssh-2.3.0p1/ssh-keygen.c Sat Oct 14 00:23:12 2000 +++ openssh-2.3.0p1-new/ssh-keygen.c Tue Nov 7 22:46:08 2000 @@ -70,10 +70,8 @@ int dsa_mode = 0; /* argv0 */ -#ifdef HAVE___PROGNAME -extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh-keygen"; +#ifndef HAVE___PROGNAME +char *__progname; #endif /* HAVE___PROGNAME */ char hostname[MAXHOSTNAMELEN]; @@ -602,6 +600,12 @@ Key *public; extern int optind; extern char *optarg; + +#ifndef HAVE___PROGNAME + __progname = xstrdup(strrchr(av[0], '/') + 1); + if (__progname == NULL) + __progname = "ssh-keygen"; +#endif /* ! HAVE___PROGNAME */ init_rng(); diff -urN openssh-2.3.0p1/ssh.c openssh-2.3.0p1-new/ssh.c --- openssh-2.3.0p1/ssh.c Fri Oct 27 22:19:58 2000 +++ openssh-2.3.0p1-new/ssh.c Tue Nov 7 22:45:01 2000 @@ -59,10 +59,8 @@ #include "authfd.h" #include "authfile.h" -#ifdef HAVE___PROGNAME -extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh"; +#ifndef HAVE___PROGNAME +char *__progname; #endif /* HAVE___PROGNAME */ /* Flag indicating whether IPv4 or IPv6. This can be set on the command line. @@ -234,6 +232,12 @@ struct passwd *pw, pwcopy; int dummy; uid_t original_effective_uid; + +#ifndef HAVE___PROGNAME + __progname = xstrdup(strrchr(av[0], '/') + 1); + if (__progname == NULL) + __progname = "ssh"; +#endif /* ! HAVE___PROGNAME */ init_rng(); diff -urN openssh-2.3.0p1/sshconnect.c openssh-2.3.0p1-new/sshconnect.c --- openssh-2.3.0p1/sshconnect.c Sat Sep 23 01:15:57 2000 +++ openssh-2.3.0p1-new/sshconnect.c Tue Nov 7 22:29:25 2000 @@ -35,11 +35,7 @@ char *server_version_string = NULL; extern Options options; -#ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh"; -#endif /* HAVE___PROGNAME */ /* * Connect to the given ssh server using a proxy command. diff -urN openssh-2.3.0p1/sshd.c openssh-2.3.0p1-new/sshd.c --- openssh-2.3.0p1/sshd.c Sat Oct 14 00:23:13 2000 +++ openssh-2.3.0p1-new/sshd.c Tue Nov 7 22:48:58 2000 @@ -82,6 +82,10 @@ /* Server configuration options. */ ServerOptions options; +#ifndef HAVE___PROGNAME +char *__progname; +#endif /* ! HAVE___PROGNAME */ + /* Name of the server configuration file. */ char *config_file_name = SERVER_CONFIG_FILE; @@ -491,6 +495,12 @@ int listen_sock, maxfd; int startup_p[2]; int startups = 0; + +#ifndef HAVE___PROGNAME + __progname = xstrdup(strrchr(av[0], '/') + 1); + if (__progname == NULL) + __progname = "sshd"; +#endif /* ! HAVE___PROGNAME */ init_rng(); From mouring at pconline.com Wed Nov 8 15:59:57 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Tue, 7 Nov 2000 22:59:57 -0600 (CST) Subject: Final Suggestion (Re: suggested bsd-setproctitle.c) In-Reply-To: <20001107225332.A3352@yorktown.isdn.uiuc.edu> Message-ID: On Tue, 7 Nov 2000, Mark D. Roth wrote: > On Tue Nov 07 15:46 2000 +0100, Kevin Steves wrote: > > How does the attached patch work? I tested on HP-UX > > !defined(HAVE___PROGNAME) and Linux defined(HAVE___PROGNAME). I don't > > use const now to keep things consistent, and went back to #ifdef > > HAVE___PROGNAME. > > Unfortunately, you're still setting __progname to a hard-coded value > instead of basename(argv[0]), which means that you don't get a > reasonable value when you invoke one of these programs using something > other than the default name. > > I'd suggest the attached patch instead. I'm not super familiar with > the code, so please let me know if I'm missing something here... > Thanks! May I suggest the attached patch. Since It's been compiled against NeXT it pretty much ensure that all __progname is setup right (since NeXT supports it). I would perfer using basename() over strrchar() and NULL check. Even it it required me to snag basename() from the OpenBSD tree. (Which I was happy to see compiled without any changes!! =) Anyone have any comments? - Ben -------------- next part -------------- diff -urN openssh/ChangeLog ossh/ChangeLog --- openssh/ChangeLog Tue Nov 7 19:58:00 2000 +++ ossh/ChangeLog Tue Nov 7 23:41:45 2000 @@ -1,3 +1,8 @@ +20001108 + - (stevek & bal) Clean up __progname definations w/ suggestion from + David Terrell + - (bal) Added bsd-basename.[ch] since some platforms lack it. + 20001107 - (bal) acconfig.in - removed the double "USE_PIPES" entry. Patch by Mark Miller diff -urN openssh/Makefile.in ossh/Makefile.in --- openssh/Makefile.in Sun Nov 5 04:27:54 2000 +++ ossh/Makefile.in Tue Nov 7 22:32:07 2000 @@ -37,7 +37,7 @@ 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 +LIBOPENBSD_COMPAT_OBJS=bsd-arc4random.o bsd-base64.o bsd-basename.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 SSHOBJS= ssh.o sshconnect.o sshconnect1.o sshconnect2.o log-client.o readconf.o clientloop.o diff -urN openssh/bsd-basename.c ossh/bsd-basename.c --- openssh/bsd-basename.c Wed Dec 31 18:00:00 1969 +++ ossh/bsd-basename.c Tue Nov 7 23:36:36 2000 @@ -0,0 +1,78 @@ +/* $OpenBSD: basename.c,v 1.4 1999/05/30 17:10:30 espie Exp $ */ + +/* + * Copyright (c) 1997 Todd C. Miller + * All rights reserved. + * + * 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. + * 3. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED ``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" +#ifndef HAVE_BASENAME + +#ifndef lint +static char *rcsid = "$OpenBSD: basename.c,v 1.4 1999/05/30 17:10:30 espie Exp $"; +#endif /* not lint */ + +#include +#include +#include + +char * +basename(const char *path) +{ + static char bname[MAXPATHLEN]; + register const char *endp, *startp; + + /* Empty or NULL string gets treated as "." */ + if (path == NULL || *path == '\0') { + (void)strcpy(bname, "."); + return(bname); + } + + /* Strip trailing slashes */ + endp = path + strlen(path) - 1; + while (endp > path && *endp == '/') + endp--; + + /* All slashes becomes "/" */ + if (endp == path && *endp == '/') { + (void)strcpy(bname, "/"); + return(bname); + } + + /* Find the start of the base */ + startp = endp; + while (startp > path && *(startp - 1) != '/') + startp--; + + if (endp - startp + 1 > sizeof(bname)) { + errno = ENAMETOOLONG; + return(NULL); + } + (void)strncpy(bname, startp, endp - startp + 1); + bname[endp - startp + 1] = '\0'; + return(bname); +} + +#endif /* !HAVE_BASENAME */ diff -urN openssh/bsd-basename.h ossh/bsd-basename.h --- openssh/bsd-basename.h Wed Dec 31 18:00:00 1969 +++ ossh/bsd-basename.h Tue Nov 7 22:32:07 2000 @@ -0,0 +1,34 @@ +/* $OpenBSD: basename.c,v 1.4 1999/05/30 17:10:30 espie Exp $ */ + +/* + * Copyright (c) 1997 Todd C. Miller + * All rights reserved. + * + * 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. + * 3. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED ``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 HAVE_BASENAME + +char *basename(const char *path); + +#endif /* !HAVE_BASENAME */ diff -urN openssh/bsd-setproctitle.c ossh/bsd-setproctitle.c --- openssh/bsd-setproctitle.c Mon Nov 6 02:07:18 2000 +++ ossh/bsd-setproctitle.c Tue Nov 7 22:32:07 2000 @@ -56,11 +56,7 @@ #define MAX_PROCTITLE 2048 -#ifdef HAVE___PROGNAME extern char *__progname; -#else -static const char *__progname = "sshd"; -#endif /* HAVE___PROGNAME */ /* * Set Process Title (SPT) defines. Modeled after sendmail's diff -urN openssh/configure.in ossh/configure.in --- openssh/configure.in Mon Nov 6 02:06:02 2000 +++ ossh/configure.in Tue Nov 7 22:34:15 2000 @@ -287,7 +287,7 @@ 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/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) dnl Checks for library functions. -AC_CHECK_FUNCS(arc4random atexit b64_ntop bcopy bindresvport_af clock fchmod freeaddrinfo futimes gai_strerror getcwd getaddrinfo getnameinfo getrusage getttyent inet_aton inet_ntoa innetgr login_getcapbool md5_crypt memmove mkdtemp on_exit openpty realpath rresvport_af setenv seteuid setlogin setproctitle setreuid setrlimit setsid sigaction sigvec snprintf strerror strlcat strlcpy strsep strtok_r vsnprintf vhangup vis waitpid _getpty __b64_ntop) +AC_CHECK_FUNCS(arc4random atexit basename b64_ntop bcopy bindresvport_af clock fchmod freeaddrinfo futimes gai_strerror getcwd getaddrinfo getnameinfo getrusage getttyent inet_aton inet_ntoa innetgr login_getcapbool md5_crypt memmove mkdtemp on_exit openpty realpath rresvport_af setenv seteuid setlogin setproctitle setreuid setrlimit setsid sigaction sigvec snprintf strerror strlcat strlcpy strsep strtok_r vsnprintf vhangup vis waitpid _getpty __b64_ntop) dnl Checks for time functions AC_CHECK_FUNCS(gettimeofday time) dnl Checks for libutil functions diff -urN openssh/log-server.c ossh/log-server.c --- openssh/log-server.c Fri Sep 15 21:29:09 2000 +++ ossh/log-server.c Tue Nov 7 22:32:07 2000 @@ -43,12 +43,6 @@ #include "xmalloc.h" #include "ssh.h" -#ifdef HAVE___PROGNAME -extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "sshd"; -#endif /* HAVE___PROGNAME */ - static LogLevel log_level = SYSLOG_LEVEL_INFO; static int log_on_stderr = 0; static int log_facility = LOG_AUTH; @@ -129,6 +123,7 @@ char fmtbuf[MSGBUFSIZ]; char *txt = NULL; int pri = LOG_INFO; + extern char *__progname; if (level > log_level) return; diff -urN openssh/openbsd-compat.h ossh/openbsd-compat.h --- openssh/openbsd-compat.h Sun Nov 5 04:01:03 2000 +++ ossh/openbsd-compat.h Tue Nov 7 22:32:07 2000 @@ -5,6 +5,7 @@ /* BSD function replacements */ #include "bsd-arc4random.h" +#include "bsd-basename.h" #include "bsd-bindresvport.h" #include "bsd-getcwd.h" #include "bsd-realpath.h" diff -urN openssh/scp.c ossh/scp.c --- openssh/scp.c Fri Oct 27 22:19:58 2000 +++ ossh/scp.c Tue Nov 7 23:44:25 2000 @@ -84,6 +84,12 @@ #define _PATH_CP "cp" #endif +#ifdef HAVE___PROGNAME +extern char *__progname; +#else +char *__progname; +#endif + /* For progressmeter() -- number of seconds before xfer considered "stalled" */ #define STALLTIME 5 @@ -248,6 +254,9 @@ char *targ; extern char *optarg; extern int optind; +#ifndef HAVE___PROGNAME + __progname = xstrdup(basename(argv[0])); +#endif args.list = NULL; addargs("ssh"); /* overwritten with ssh_program */ diff -urN openssh/session.c ossh/session.c --- openssh/session.c Fri Oct 27 22:19:58 2000 +++ ossh/session.c Tue Nov 7 22:32:07 2000 @@ -128,12 +128,7 @@ /* import */ extern ServerOptions options; -#ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "sshd"; -#endif /* HAVE___PROGNAME */ - extern int log_stderr; extern int debug_flag; extern unsigned int utmp_len; diff -urN openssh/sftp-server.c ossh/sftp-server.c --- openssh/sftp-server.c Fri Sep 22 22:58:32 2000 +++ ossh/sftp-server.c Tue Nov 7 22:32:07 2000 @@ -90,6 +90,12 @@ #define get_string(lenp) buffer_get_string(&iqueue, lenp); #define TRACE log +#ifdef HAVE___PROGNAME +extern char *__progname; +#else +char *__progname; +#endif + /* input and output queue */ Buffer iqueue; Buffer oqueue; @@ -1014,6 +1020,9 @@ fd_set rset, wset; int in, out, max; ssize_t len, olen; +#ifndef HAVE___PROGNAME + __progname = xstrdup(basename(av[0])); +#endif handle_init(); diff -urN openssh/ssh-add.c ossh/ssh-add.c --- openssh/ssh-add.c Tue Oct 17 07:22:28 2000 +++ ossh/ssh-add.c Tue Nov 7 22:32:07 2000 @@ -50,9 +50,9 @@ #ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh-add"; -#endif /* HAVE___PROGNAME */ +#else +char *__progname; +#endif void delete_file(AuthenticationConnection *ac, const char *filename) @@ -247,6 +247,9 @@ int no_files = 1; int i; int deleting = 0; +#ifndef HAVE___PROGNAME + __progname = xstrdup(basename(argv[0])); +#endif init_rng(); diff -urN openssh/ssh-agent.c ossh/ssh-agent.c --- openssh/ssh-agent.c Fri Sep 29 07:01:37 2000 +++ ossh/ssh-agent.c Tue Nov 7 22:32:07 2000 @@ -94,9 +94,9 @@ #ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh-agent"; -#endif /* HAVE___PROGNAME */ +#else +char *__progname; +#endif void idtab_init(void) @@ -667,6 +667,9 @@ pid_t pid; char *shell, *format, *pidstr, pidstrbuf[1 + 3 * sizeof pid]; extern int optind; +#ifndef HAVE___PROGNAME + __progname = xstrdup(basename(av[0])); +#endif init_rng(); diff -urN openssh/ssh-keygen.c ossh/ssh-keygen.c --- openssh/ssh-keygen.c Sat Oct 14 00:23:12 2000 +++ ossh/ssh-keygen.c Tue Nov 7 22:32:07 2000 @@ -72,9 +72,9 @@ /* argv0 */ #ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh-keygen"; -#endif /* HAVE___PROGNAME */ +#else +char *__progname; +#endif char hostname[MAXHOSTNAMELEN]; @@ -602,6 +602,9 @@ Key *public; extern int optind; extern char *optarg; +#ifndef HAVE___PROGNAME + __progname = xstrdup(basename(av[0])); +#endif init_rng(); diff -urN openssh/ssh.c ossh/ssh.c --- openssh/ssh.c Fri Oct 27 22:19:58 2000 +++ ossh/ssh.c Tue Nov 7 22:32:07 2000 @@ -61,9 +61,9 @@ #ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh"; -#endif /* HAVE___PROGNAME */ +#else +char *__progname; +#endif /* Flag indicating whether IPv4 or IPv6. This can be set on the command line. Default value is AF_UNSPEC means both IPv4 and IPv6. */ @@ -234,6 +234,9 @@ struct passwd *pw, pwcopy; int dummy; uid_t original_effective_uid; +#ifndef HAVE___PROGNAME + __progname = xstrdup(basename(av[0])); +#endif init_rng(); diff -urN openssh/sshconnect.c ossh/sshconnect.c --- openssh/sshconnect.c Sat Sep 23 01:15:57 2000 +++ ossh/sshconnect.c Tue Nov 7 22:32:07 2000 @@ -35,11 +35,7 @@ char *server_version_string = NULL; extern Options options; -#ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh"; -#endif /* HAVE___PROGNAME */ /* * Connect to the given ssh server using a proxy command. diff -urN openssh/sshd.c ossh/sshd.c --- openssh/sshd.c Sat Oct 14 00:23:13 2000 +++ ossh/sshd.c Tue Nov 7 22:32:07 2000 @@ -79,6 +79,12 @@ #define O_NOCTTY 0 #endif +#ifdef HAVE___PROGNAME +extern char *__progname; +#else +char *__progname; +#endif + /* Server configuration options. */ ServerOptions options; @@ -491,6 +497,9 @@ int listen_sock, maxfd; int startup_p[2]; int startups = 0; +#ifndef HAVE___PROGNAME + __progname = xstrdup(basename(av[0])); +#endif init_rng(); From roth at feep.net Wed Nov 8 16:52:05 2000 From: roth at feep.net (Mark D. Roth) Date: Tue, 7 Nov 2000 23:52:05 -0600 Subject: Final Suggestion (Re: suggested bsd-setproctitle.c) In-Reply-To: ; from mouring@pconline.com on Tue, Nov 07, 2000 at 10:59:57PM -0600 References: <20001107225332.A3352@yorktown.isdn.uiuc.edu> Message-ID: <20001107235205.A3591@yorktown.isdn.uiuc.edu> On Tue Nov 07 22:59 2000 -0600, Ben Lindstrom wrote: > I would perfer using basename() over strrchar() and NULL check. Even it > it required me to snag basename() from the OpenBSD tree. (Which I was > happy to see compiled without any changes!! =) The NULL check actually had nothing to do with strrchr() (although now that you mention it, I should have checked strrchr()'s result as well). The real purpose was to make sure xstrdup() didn't fail because we're out of memory. Admittedly, this is a very unprobable situation, but there might be problems if __progname is set to NULL later in the code. Also, I have encountered some fairly serious problems in the past with systems which have basename() calls that don't work properly. The most notable example of this was Linux systems running early versions of glibc 2.0. None of these bugs should affect the code we're talking about, but I'd feel a lot more comfortable if some folks with RedHat 6.0 systems could test it for us. (All my Linux machines are at 6.1 or 6.2 by now.) Other than these nitpicks, it looks fine to me. I'll actually test it once we have a bit more of a consensus. ;) -- Mark D. Roth http://www.feep.net/~roth/ From mouring at pconline.com Wed Nov 8 17:01:23 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Wed, 8 Nov 2000 00:01:23 -0600 (CST) Subject: Final Suggestion (Re: suggested bsd-setproctitle.c) In-Reply-To: <20001107235205.A3591@yorktown.isdn.uiuc.edu> Message-ID: On Tue, 7 Nov 2000, Mark D. Roth wrote: > On Tue Nov 07 22:59 2000 -0600, Ben Lindstrom wrote: > > I would perfer using basename() over strrchar() and NULL check. Even it > > it required me to snag basename() from the OpenBSD tree. (Which I was > > happy to see compiled without any changes!! =) > > The NULL check actually had nothing to do with strrchr() (although now > that you mention it, I should have checked strrchr()'s result as > well). The real purpose was to make sure xstrdup() didn't fail > because we're out of memory. Admittedly, this is a very unprobable > situation, but there might be problems if __progname is set to NULL > later in the code. > xstrdup() would fail during the xmalloc() call which would cause a call to fatal() and it would quit. So the check is really not valid for that reason. Which is why I figured you were doing it for strrchr(). because xmalloc(0) is valid. > Also, I have encountered some fairly serious problems in the past with > systems which have basename() calls that don't work properly. The > most notable example of this was Linux systems running early versions > of glibc 2.0. None of these bugs should affect the code we're talking > about, but I'd feel a lot more comfortable if some folks with RedHat > 6.0 systems could test it for us. (All my Linux machines are at 6.1 > or 6.2 by now.) > Noted. And either it may have to go into an FAQ begging people to upgrade at least their glibc or add in another sprintf() hack type check. > Other than these nitpicks, it looks fine to me. I'll actually test it > once we have a bit more of a consensus. ;) > I'm not going anywhere.=) Bush is *BARELY* leading the presidental race, and it's way too dang close.=) - Ben From pekkas at netcore.fi Wed Nov 8 17:46:28 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 8 Nov 2000 08:46:28 +0200 (EET) Subject: bug in documentation for "Protocol" option In-Reply-To: <20001107202928.A22974@support.ddiworld.com> Message-ID: On Tue, 7 Nov 2000, joel w. reed wrote: > this was my point. clearly the text at the top says "these > are the default settings if you don't specify anything" - but > at least for Protocol it is wrong & should be fixed. Not really (IMO :), it says: --- # This is ssh client systemwide configuration file. This file provides # defaults for users, and the values can be changed in per-user configuration # files or on the command line. --- Ie. "With this file, you can specify defaults for ssh(1) which the users can override with .ssh/config or with command-line options". I guess the wording could be a bit better though -- it could be understood the other ways too. -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From mouring at pconline.com Wed Nov 8 18:34:04 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Wed, 8 Nov 2000 01:34:04 -0600 (CST) Subject: Another shapshot In-Reply-To: <20001108000022.I4747@greenie.muc.de> Message-ID: On Wed, 8 Nov 2000, Gert Doering wrote: > Hi, > > On Sun, Nov 05, 2000 at 01:38:47AM +0100, Gert Doering wrote: > > Idea. What it does is: > > > > ptr = (up[2] + up[3]) % 99 ... > > > > - do, by chance, the first 4 bytes of "up" contain a long int and the code > > is adding the two "low bytes" together? I'm on a big endian machine > > (PowerPC) and if that is so, this might need byte-swapping... > > No. Tried using up[0]+up[1] instead, but that also gives me a constant > number - the first always gives me "58", the second "85", but neither > gives the current challenge. > > So - is anybody working on S/Key in OpenSSH? Is somebody using it on a > non-BSD platform? If yes, what did you do, which s/key library, which > CPU endianness, ...? > 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. > Is anybody interested in getting this to work? I think a portable way to > do OTPs is very important. > May be worth porting the S/Key library in the OpenBSD tree. It's rather small, but it has a lot of dependancy from what it looks at. - Ben From gert at greenie.muc.de Wed Nov 8 20:00:06 2000 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 8 Nov 2000 10:00:06 +0100 Subject: Another shapshot In-Reply-To: ; from Ben Lindstrom on Wed, Nov 08, 2000 at 01:34:04AM -0600 References: <20001108000022.I4747@greenie.muc.de> Message-ID: <20001108100006.B21929@greenie.muc.de> Hi, On Wed, Nov 08, 2000 at 01:34:04AM -0600, Ben Lindstrom wrote: > > No. Tried using up[0]+up[1] instead, but that also gives me a constant > > number - the first always gives me "58", the second "85", but neither > > gives the current challenge. > > > > So - is anybody working on S/Key in OpenSSH? Is somebody using it on a > > non-BSD platform? If yes, what did you do, which s/key library, which > > CPU endianness, ...? > > > 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 one that has been ported from OpenBSD (similar to OpenSSH), I found it by looking in "www.google.com" for "skey source". I found it at http://www.sparc.spb.su/solaris/skey/, which, as I understand, is also its home site. I use version 1.1. The S/Key library itself seems to work fine, that is: - I have "skeyinit"ed a bunch of challenges for me - When I log in via OpenSSH, I call "skeyinfo" to get the actual challenge number, call "skey " to generate the response, and enter that into OpenSSH, and I can log in. - The only thing that is absolutely not working is the correct printing of the challenge number from inside OpenSSH - it always prints "58" (but OpenSSH doesn't seem to actually *use* libskey for that, there is quite a lot of code in auth-skey.c that calls directly into some crypto functions, if I read the code correctly). I did not yet try skey with ssh2 (no DSA keys on all my test machines, and so on). > > Is anybody interested in getting this to work? I think a portable way to > > do OTPs is very important. > May be worth porting the S/Key library in the OpenBSD tree. It's rather > small, but it has a lot of dependancy from what it looks at. This seems to have been done already :-) 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 stevesk at sweden.hp.com Wed Nov 8 20:51:16 2000 From: stevesk at sweden.hp.com (Kevin Steves) Date: Wed, 8 Nov 2000 10:51:16 +0100 (CET) Subject: Final Suggestion (Re: suggested bsd-setproctitle.c) In-Reply-To: Message-ID: <200011080933.KAA05501@b0fh.sweden.hp.com> On Tue, 7 Nov 2000, Ben Lindstrom wrote: : May I suggest the attached patch. Since It's been compiled against NeXT : it pretty much ensure that all __progname is setup right (since NeXT : supports it). : : I would perfer using basename() over strrchar() and NULL check. Even it : it required me to snag basename() from the OpenBSD tree. (Which I was : happy to see compiled without any changes!! =) I was more concerned with cleaning up ifdef bloat vs. fixing the hardcoded names, but I agree it makes sense to fix that as well. I don't see a need to necessarily malloc new space for a copy. i386/crt0.c does this: if ((ap = argv[0])) if ((__progname = _strrchr(ap, '/')) == NULL) __progname = ap; else ++__progname; If you look at Kerberos or afs warnerr.c you see: #ifndef HAVE___PROGNAME const char *__progname; #endif void set_progname(char *argv0) { #ifndef HAVE___PROGNAME char *p; if(argv0 == NULL) return; p = strrchr(argv0, '/'); if(p == NULL) p = argv0; else p++; __progname = p; #endif } I'd prefer adding a set_progname() modified to return progname, and using it vs. importing bsd-basename and mallocing space. So in main() we'd have: __progname = set_progname(argv[0]); From Nigel.Metheringham at VData.co.uk Wed Nov 8 20:37:02 2000 From: Nigel.Metheringham at VData.co.uk (Nigel Metheringham) Date: Wed, 08 Nov 2000 09:37:02 +0000 Subject: Another shapshot In-Reply-To: Message from Ben Lindstrom of "Wed, 08 Nov 2000 01:34:04 CST." Message-ID: 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. -- [ - 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 Stephan.Hendl at lds.brandenburg.de Wed Nov 8 21:36:31 2000 From: Stephan.Hendl at lds.brandenburg.de (Stephan Hendl) Date: Wed, 08 Nov 2000 11:36:31 +0100 Subject: man pages won't work Message-ID: Hi, I am sorry about this stupid question but after compilation of openssh-2.3.0p1 the manpages were installed but a man ssh gives only unstructured response without underlined lines etc. A nroff -man sshd.8 gives the same output but the contents of the file shows a nroff-format. Any ideas? My system is a HP-UX 11.000 with the pam-patch. regards 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 mouring at pconline.com Thu Nov 9 01:07:18 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Wed, 8 Nov 2000 08:07:18 -0600 (CST) Subject: Final Suggestion (Re: suggested bsd-setproctitle.c) In-Reply-To: <200011080933.KAA05501@b0fh.sweden.hp.com> Message-ID: On Wed, 8 Nov 2000, Kevin Steves wrote: [..] > #ifndef HAVE___PROGNAME > const char *__progname; > #endif > > void > set_progname(char *argv0) > { > #ifndef HAVE___PROGNAME > char *p; > if(argv0 == NULL) > return; > p = strrchr(argv0, '/'); > if(p == NULL) > p = argv0; > else > p++; > __progname = p; > #endif > } > > I'd prefer adding a set_progname() modified to return progname, and > using it vs. importing bsd-basename and mallocing space. > > So in main() we'd have: > > __progname = set_progname(argv[0]); > For as much as I dislike functions that modify global variables. I think the orignal set_progname() may be better then changing it to return the progname. I don't believe we should be setting __progname unless it's not set originally. Unless you plan on moving the #ifndef .. #endif to around the call in main(). - Ben From stevesk at sweden.hp.com Thu Nov 9 02:03:49 2000 From: stevesk at sweden.hp.com (Kevin Steves) Date: Wed, 8 Nov 2000 16:03:49 +0100 (CET) Subject: Final Suggestion (Re: suggested bsd-setproctitle.c) In-Reply-To: Message-ID: <200011081445.PAA04350@b0fh.sweden.hp.com> On Wed, 8 Nov 2000, Ben Lindstrom wrote: : > I'd prefer adding a set_progname() modified to return progname, and : > using it vs. importing bsd-basename and mallocing space. : > : > So in main() we'd have: : > : > __progname = set_progname(argv[0]); : > : For as much as I dislike functions that modify global variables. I think I agree regarding modifying globals. : the orignal set_progname() may be better then changing it to return the : progname. I don't believe we should be setting __progname unless it's not : set originally. I was thinking of: #ifdef HAVE___PROGNAME return __progname; #else ... : Unless you plan on moving the #ifndef .. #endif to around the call in : main(). I was trying to avoid that, but if we don't want to assign __progname to itself, it's fine with me. From mouring at pconline.com Thu Nov 9 02:13:07 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Wed, 8 Nov 2000 09:13:07 -0600 (CST) Subject: Final Suggestion (Re: suggested bsd-setproctitle.c) In-Reply-To: <200011081445.PAA04350@b0fh.sweden.hp.com> Message-ID: On Wed, 8 Nov 2000, Kevin Steves wrote: > On Wed, 8 Nov 2000, Ben Lindstrom wrote: [..] > > I was thinking of: > > #ifdef HAVE___PROGNAME > return __progname; > #else > ... > > : Unless you plan on moving the #ifndef .. #endif to around the call in > : main(). > > I was trying to avoid that, but if we don't want to assign __progname to > itself, it's fine with me. > I have no real quarms with assign itself to itself. One would hope during an optimization phase the compiler would quietly drop it. - Ben From J.Horne at plymouth.ac.uk Thu Nov 9 03:30:15 2000 From: J.Horne at plymouth.ac.uk (John Horne) Date: Wed, 08 Nov 2000 16:30:15 -0000 (GMT) Subject: internal error: we do not read, but chan_read_failed Message-ID: Hello, The error message in the subject line occurs with the new 2.3.0 openssh version and appeared in the previous snapshots on our Solaris systems. As far as I remember it was reported, but have not seen any more about this. I have looked into it a little bit. First, the file session.c (line 1849 onwards): debug("session_exit_message: release channel %d", s->chanid); channel_cancel_cleanup(s->chanid); /* * emulate a write failure with 'chan_write_failed', nobody will be * interested in data we write. * Note that we must not call 'chan_read_failed', since there could * be some more data waiting in the pipe. * djm - This is no longer true as we have allowed one pass through * the select loop before killing the connection */ if (c->ostate != CHAN_OUTPUT_CLOSED) chan_write_failed(c); if (c->istate != CHAN_INPUT_CLOSED) chan_read_failed(c); s->chanid = -1; The output from the server when copying a file from one system to another using scp gives: debug1: channel 0: close_write debug1: Received SIGCHLD. debug1: tvp!=NULL kid 1 mili 100 debug1: session_by_pid: pid 28343 debug1: session_exit_message: session 0 channel 0 pid 28343 debug1: session_exit_message: release channel 0 debug1: channel 0: read failed debug1: channel 0: input open -> drain debug1: tvp!=NULL kid 1 mili 100 debug1: session_by_pid: pid 28343 debug1: session_exit_message: session 0 channel 0 pid 28343 debug1: session_exit_message: release channel 0 debug1: channel 0: read failed debug1: channel 0: input open -> drain debug1: channel 0: close_read debug1: channel 0: input: no drain shortcut debug1: channel 0: ibuf empty debug1: channel 0: input drain -> closed debug1: channel 0: send eof debug1: session_free: session 0 pid 28343 debug1: channel 0: read<=0 rfd 8 len 0 debug1: channel 0: read failed error: channel 0: internal error: we do not read, but chan_read_failed for istate 8 debug1: channel 0: closing efd 10 debug1: channel 0: send close debug1: channel 0: rcvd close debug1: channel 0: full closed2 debug1: channel_free: channel 0: status: The following connections are open: #0 server-session (t4 r0 i8/0 o128/0 fd 8/8) However if I comment out from session.c the call to 'chan_read_failed' (which I assume was not there previously), then I get: debug1: channel 0: close_write debug1: Received SIGCHLD. debug1: tvp!=NULL kid 1 mili 100 debug1: session_by_pid: pid 10918 debug1: session_exit_message: session 0 channel 0 pid 10918 debug1: session_exit_message: release channel 0 debug1: session_free: session 0 pid 10918 debug1: channel 0: read<=0 rfd 8 len 0 debug1: channel 0: read failed debug1: channel 0: input open -> drain debug1: channel 0: close_read debug1: channel 0: input: no drain shortcut debug1: channel 0: ibuf empty debug1: channel 0: input drain -> closed debug1: channel 0: send eof debug2: channel 0: read 0 from efd 10 debug1: channel 0: closing efd 10 debug1: channel 0: send close debug1: channel 0: rcvd close debug1: channel 0: full closed2 debug1: channel_free: channel 0: status: The following connections are open: #0 server-session (t4 r0 i8/0 o128/0 fd 8/8) SIGCHLD is caught within serverloop.c. This calls 'session_close_by_pid' which calls 'session_exit_message'. At this point everything seems to be pretty much the same in the original and the modified version. However, next in the modified version is the call to 'session_free' as seen in the latter server output. In the original version 'session_exit_message' calls 'chan_read_failed' because the input channel state is not (yet) closed (CHAN_INPUT_CLOSED); it is open but gets changed to CHAN_INPUT_WAIT_DRAIN (it seems). As such it attempts to read more info; gets none and goes through the 'read failed'; 'input open -> drain'; 'input open -> closed'; 'send eof' sequence. *Then* 'session_free' is called (as part of session close), and we end up back in session.c. Next (in serverloop.c) is called 'channel_after_select' which calls channel_handler. This calls (in our case we are using protocol 2) 'channel_post_open_2', which calls 'channel_handle_rfd' which (eventually) calls 'chan_read_failed' because the channel still hasn't been closed. As such in the original openssh we get the final - debug1: channel 0: read<=0 rfd 8 len 0 debug1: channel 0: read failed error: channel 0: internal error: we do not read, but chan_read_failed for istate 8 - messages appearing. Okay, so I'm not *sure* that this is how it all seems to hang together, but it looks like it. Basically, the extra 'chan_read_failed' call in session.c seems to be the culprit because it starts the session closing sequence, but the serverloop (which it eventually returns to) seems to expect to do that with the 'channel_after_select'. As things have already been started, it comes across unexpected conditions and (ultimately) produces the error message. If someone who knows what they are doing (not me!) wants to go through this and either verify or not that this is the cause, then I'd be grateful. I have commented out the call to 'chan_read_failed' here and have seen no problems so far. That's it - phew! 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 rob at hagopian.net Thu Nov 9 03:46:09 2000 From: rob at hagopian.net (Rob Hagopian) Date: Wed, 8 Nov 2000 11:46:09 -0500 (EST) Subject: bug in documentation for "Protocol" option In-Reply-To: Message-ID: Then why do we list anything in the file? Why not have no options in the config files and put both default and suggested alternatives in the man page? Mixing the two in the config file with little documentation is misleading and will confuse those less experienced and those used to ssh.com's versions. IMO consistency is important. Right now there is an inconsistent mix of defaults and non-defaults in the config file with no clear direction on them. -Rob On Wed, 8 Nov 2000, Pekka Savola wrote: > On Tue, 7 Nov 2000, Rob Hagopian wrote: > > # IdentityFile ~/.ssh/identity > > # EscapeChar ~ > > # Port 22 > > > > and most of the others which are indeed the defaults as described in the > > man page... I can't think of too many non-default settings that would > > qualify as "probably want to use" for these... > > No, and that's why there are the defaults there for those. > > Sometimes I use settings like: > --- > Host * > ForwardAgent no > ForwardX11 yes > FallBackToRsh no > Protocol 2,1 > Cipher blowfish > Ciphers arcfour,blowfish-cbc > --- > [ good for heavy traffic because arcfour is the fastest algorithm ] > > *Authentication, Cipher*, Protocol etc. options are ones you usually want > to change. Having them as defaults has it's good and bad points, > obviously. > > > How about a section in the default ssh*_config that has all of the > > settings and their default values, all commented out, as a quick reference > > for people? It's a lot easier than cross checking the man page for each > > setting... > > Committing to this would get you yet another place to keep track of > these... > > From rob at hagopian.net Thu Nov 9 03:49:26 2000 From: rob at hagopian.net (Rob Hagopian) Date: Wed, 8 Nov 2000 11:49:26 -0500 (EST) Subject: 2.3.0p1 vs 2.0.12 Message-ID: With the 2.3.0p1 client on Linux vs F-SECURE SSH Version 2.0.12 on a BSDI box using ssh v2 DSA keys I get the following on the server side: debug: new_connection_callback returning debug: Remote version: SSH-2.0-OpenSSH_2.3.0p1 sshd[7778]: got bad packet when verifying user auto's publickey. Incidentally, there's an option -2 to use v2 if "1,2" is the Protocol line, but no -1 to use v1 if "2,1" is in the Protocol line... Is there a reason for this? -Rob From J.Horne at plymouth.ac.uk Thu Nov 9 04:22:37 2000 From: J.Horne at plymouth.ac.uk (John Horne) Date: Wed, 08 Nov 2000 17:22:37 -0000 (GMT) Subject: internal error: we do not read, but chan_read_failed In-Reply-To: Message-ID: On 08-Nov-00 at 16:30:15 John Horne wrote: > The error message in the subject line occurs with the new 2.3.0 openssh > version and appeared in the previous snapshots on our Solaris systems. As > far as I remember it was reported, but have not seen any more about this. > I have looked into it a little bit. > Hmm, well I'm about to leave work and I started a background job on one of the Suns, only to notice that the ssh session didn't close - the old problem regarding background jobs. To sort that out (and I think the above error) I have left session.c as supplied with 2.3.0p1 but modified nchan.c at line 100 so that it says: switch (c->istate) { case CHAN_INPUT_WAIT_DRAIN: case CHAN_INPUT_CLOSED: break; case CHAN_INPUT_OPEN: Perhaps that'll work :-) It seems to. Off home now... 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 gert at greenie.muc.de Thu Nov 9 04:48:22 2000 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 8 Nov 2000 18:48:22 +0100 Subject: man pages won't work In-Reply-To: ; from Stephan Hendl on Wed, Nov 08, 2000 at 11:36:31AM +0100 References: Message-ID: <20001108184822.A1551@greenie.muc.de> Hi, On Wed, Nov 08, 2000 at 11:36:31AM +0100, Stephan Hendl wrote: > I am sorry about this stupid question but after compilation of openssh-2.3.0p1 the manpages were installed but a man ssh gives only unstructured response without underlined lines etc. A nroff -man sshd.8 gives the same output but the contents of the file shows a nroff-format. Seconded. I thought it was only me (and didn't investigate further). To me, it seems as if some nroff-macros are used that "generic nroff -man" doesn't know. > Any ideas? > My system is a HP-UX 11.000 with the pam-patch. IBM AIX 4.3. 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 james at amethyst.nurealm.net Thu Nov 9 05:06:30 2000 From: james at amethyst.nurealm.net (James) Date: Wed, 08 Nov 2000 11:06:30 -0700 Subject: openssh-2.3.0p1-1 with RedHat 6.2 - Bad packet length Message-ID: <200011081806.LAA20705@amethyst.nurealm.net> I haven't been able to get scp to work with RedHat 6.2 (select: Bad file descriptor), so... I tried upgrading with openssh-2.3.0p1-1.src.rpm and openssl-0.9.5a-3.src.rpm No joy. When running just ssh, I get "Disconnecting: Bad packet length 795178083." This seems to be a problem with sshd, since the 2.3 ssh client will work fine with a 2.1 server (but not scp, which still gives "select: Bad file descriptor". Any suggestions? Please Cc me on any response, as I'm not subscribed to the list. Thanks. ______________________ :~$ ssh -v sapphire SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090581f). debug: Reading configuration data /home/james/.ssh/config debug: Applying options for sapphire debug: Reading configuration data /etc/ssh/ssh_config debug: ssh_connect: getuid 500 geteuid 0 anon 0 debug: Connecting to sapphire.nurealm.net [199.45.155.11] port 22. debug: Seeding random number generator debug: Allocated local port 765. debug: Connection established. debug: Remote protocol version 2.0, remote software version OpenSSH_2.3.0p1 debug: no match: OpenSSH_2.3.0p1 Enabling compatibility mode for protocol 2.0 debug: Local version string SSH-2.0-OpenSSH_2.3.0p1 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 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 3des-cbc hmac-sha1 none debug: kex: client->server 3des-cbc hmac-sha1 none debug: Sending SSH2_MSG_KEX_DH_GEX_REQUEST. debug: Wait SSH2_MSG_KEX_DH_GEX_GROUP. 2f 65 74 63 2f 73 73 68 Disconnecting: Bad packet length 795178083. debug: Calling cleanup 0x805d910(0x0) From dwd at bell-labs.com Thu Nov 9 05:54:08 2000 From: dwd at bell-labs.com (Dave Dykstra) Date: Wed, 8 Nov 2000 12:54:08 -0600 Subject: man pages won't work In-Reply-To: <20001108184822.A1551@greenie.muc.de>; from gert@greenie.muc.de on Wed, Nov 08, 2000 at 06:48:22PM +0100 References: <20001108184822.A1551@greenie.muc.de> Message-ID: <20001108125407.A17105@lucent.com> On Wed, Nov 08, 2000 at 06:48:22PM +0100, Gert Doering wrote: > Hi, > > On Wed, Nov 08, 2000 at 11:36:31AM +0100, Stephan Hendl wrote: > > I am sorry about this stupid question but after compilation of openssh-2.3.0p1 the manpages were installed but a man ssh gives only unstructured response without underlined lines etc. A nroff -man sshd.8 gives the same output but the contents of the file shows a nroff-format. > > Seconded. I thought it was only me (and didn't investigate further). > > To me, it seems as if some nroff-macros are used that "generic nroff -man" > doesn't know. It's using -mandoc instead of -man. I can get that to work with GNU's nroff but not any others, and I can see this is going to be a problem for me because not everywhere I need to deploy openssh to will have access to -mandoc. - Dave Dykstra From djast at cs.toronto.edu Thu Nov 9 06:00:44 2000 From: djast at cs.toronto.edu (Dan Astoorian) Date: Wed, 8 Nov 2000 14:00:44 -0500 Subject: openssh-2.3.0p1 bug: vsprintf("%h") is broken Message-ID: <00Nov8.140046edt.453138-10333@jane.cs.toronto.edu> I discovered this in openssh-2.3.0p1; it may affect earlier versions as well. Platforms: Solaris 2.5.1 and 8, probably others. Observed behaviour: With -v, when attempting to connect to a host which is not listening on the requested port, I noticed that the port number is reported as zero in the message: Secure connection to hostname on port 0 refused. Apparent cause: At line 671 of ssh.c, the message is logged using a format string of "%hu". It appears that the vsnprintf() implementation in /bsd-snprintf.c handles %hu incorrectly. It does the following at line 262: if (cflags == DP_C_SHORT) value = va_arg (args, short int); Similarly for %hd, %hi, %ho and %hx. The man page for va_arg under Solaris 8 indicates the following: | It is non-portable to specify a second argument of char or | short to va_arg, because arguments seen by the called func- | tion are not char or short. C converts char and short | arguments to int before passing them to a function. To reproduce: Compile the following against bsd-snprintf.o: #include #include char msgbuf[256]; void foo(char *fmt, ...) { va_list args; va_start(args, fmt); vsnprintf(msgbuf, sizeof(msgbuf), fmt, args); printf("%s", msgbuf); } main() { int i = 10; short j = 10; foo("x %d x\n", i); foo("x %hu x\n", i); foo("x %d x\n", j); foo("x %hu x\n", j); } The resulting program prints "x 0 x" instead of "x 10 x" on the second and fourth lines. Remedy: Presumably, change "short int" to "int", and "unsigned short int" at the relevant lines (263, 275, 287, 301 of bsd-snprintf.c). If there are implementations which break the specification and fail to promote arguments of type short to an integer argument, it may be necessary to #ifdef around this on those platforms. Security implications: None known. Other notes: sshconnect.c line 59 (ssh_proxy_connect()) *may* suffer from the same bug: snprintf(strport, sizeof strport, "%hu", port); Please let me know if you require further details. Thanks, -- People shouldn't think that it's better to have Dan Astoorian loved and lost than never loved at all. It's Sysadmin, CSLab not, it's better to have loved and won. All djast at cs.toronto.edu the other options really suck. --Dan Redican From Donald.Smith at qwest.com Thu Nov 9 06:48:30 2000 From: Donald.Smith at qwest.com (Smith, Donald ) Date: Wed, 8 Nov 2000 12:48:30 -0700 Subject: man pages won't work Message-ID: <2D00AD0E4D36D411BD300008C786E4240125817B@Denntex021.qwest.net> Try configure --with-catman=man (and what ever other switches you use) Then u could just make manpages to install only the manpages. Donald Smith Staff IP Engineer IP Network Engineering Security 303-226-9939 Office 303-226-0688 fax 720-320-1537 cell > -----Original Message----- > From: Dave Dykstra [mailto:dwd at bell-labs.com] > Sent: Wednesday, November 08, 2000 11:54 AM > To: Gert Doering > Cc: Stephan Hendl; openssh-unix-dev at mindrot.org > Subject: Re: man pages won't work > > > On Wed, Nov 08, 2000 at 06:48:22PM +0100, Gert Doering wrote: > > Hi, > > > > On Wed, Nov 08, 2000 at 11:36:31AM +0100, Stephan Hendl wrote: > > > I am sorry about this stupid question but after > compilation of openssh-2.3.0p1 the manpages were installed > but a man ssh gives only unstructured response without > underlined lines etc. A nroff -man sshd.8 gives the same > output but the contents of the file shows a nroff-format. > > > > Seconded. I thought it was only me (and didn't investigate > further). > > > > To me, it seems as if some nroff-macros are used that > "generic nroff -man" > > doesn't know. > > It's using -mandoc instead of -man. I can get that to work with GNU's > nroff but not any others, and I can see this is going to be a problem > for me because not everywhere I need to deploy openssh to will have > access to -mandoc. > > - Dave Dykstra > From djm at mindrot.org Thu Nov 9 09:09:28 2000 From: djm at mindrot.org (Damien Miller) Date: Thu, 9 Nov 2000 09:09:28 +1100 (EST) Subject: man pages won't work In-Reply-To: <20001108184822.A1551@greenie.muc.de> Message-ID: On Wed, 8 Nov 2000, Gert Doering wrote: > Seconded. I thought it was only me (and didn't investigate further). > > To me, it seems as if some nroff-macros are used that "generic nroff -man" > doesn't know. A few people have reported this as a problem. If someone with an affected system and better knowledge of nroff can come up with a solution it would be appreciated. -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 Donald.Smith at qwest.com Thu Nov 9 10:12:25 2000 From: Donald.Smith at qwest.com (Smith, Donald ) Date: Wed, 8 Nov 2000 16:12:25 -0700 Subject: man pages won't work Message-ID: <2D00AD0E4D36D411BD300008C786E4240125817F@Denntex021.qwest.net> look at scp.0 and scp.1 with nroff -man scp.0 | more it looks like a normal man page. look at scp.1 with nroff -man scp.1 |more it looks like unformated text. The scp.0 file is for catman the scp.1 file is for TROFFMAN or MANPAGES per the Makefile. SOLUTION those of you with broken manpages just copy the *.0 files into the correct directories. (/usr/local/man/man1,5,8) Donald Smith Staff IP Engineer IP Network Engineering Security 303-226-9939 Office 303-226-0688 fax 720-320-1537 cell > -----Original Message----- > From: Damien Miller [mailto:djm at mindrot.org] > Sent: Wednesday, November 08, 2000 3:09 PM > To: Gert Doering > Cc: Stephan Hendl; openssh-unix-dev at mindrot.org > Subject: Re: man pages won't work > > > On Wed, 8 Nov 2000, Gert Doering wrote: > > > Seconded. I thought it was only me (and didn't investigate > further). > > > > To me, it seems as if some nroff-macros are used that > "generic nroff -man" > > doesn't know. > > A few people have reported this as a problem. > > If someone with an affected system and better knowledge of > nroff can come > up with a solution it would be appreciated. > > -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 djast at cs.toronto.edu Thu Nov 9 10:31:54 2000 From: djast at cs.toronto.edu (Dan Astoorian) Date: Wed, 8 Nov 2000 18:31:54 -0500 Subject: openssh-2.3.0p1 bug: vsprintf("%h") is broken In-Reply-To: Your message of "Wed, 08 Nov 2000 14:00:44 EST." Message-ID: <00Nov8.183158edt.453138-10333@jane.cs.toronto.edu> On Wed, 08 Nov 2000 14:00:44 EST, I wrote: > I discovered this in openssh-2.3.0p1; it may affect earlier versions as > well. > > Platforms: Solaris 2.5.1 and 8, probably others. Apologies for leaving out a critical detail: the compiler was gcc 2.7.2. The problem does not appear when Sun's Workshop compiler (5.0, /opt/SUNWspro/bin/cc) is used to compile bsd-snprintf.c. -- People shouldn't think that it's better to have Dan Astoorian loved and lost than never loved at all. It's Sysadmin, CSLab not, it's better to have loved and won. All djast at cs.toronto.edu the other options really suck. --Dan Redican From stuge at cdy.org Thu Nov 9 10:46:49 2000 From: stuge at cdy.org (Peter Stuge) Date: Thu, 9 Nov 2000 00:46:49 +0100 Subject: openssh-2.3.0p1-1 with RedHat 6.2 - Bad packet length In-Reply-To: <200011081806.LAA20705@amethyst.nurealm.net>; from james@amethyst.nurealm.net on Wed, Nov 08, 2000 at 11:06:30AM -0700 References: <200011081806.LAA20705@amethyst.nurealm.net> Message-ID: <20001109004649.A23719@foo.birdnet.se> On Wed, Nov 08, 2000 at 11:06:30AM -0700, James wrote: > I haven't been able to get scp to work with RedHat 6.2 (select: Bad file > descriptor), so... I tried upgrading with openssh-2.3.0p1-1.src.rpm and > openssl-0.9.5a-3.src.rpm No joy. When running just ssh, I get > "Disconnecting: Bad packet length 795178083." > > This seems to be a problem with sshd, since the 2.3 ssh client will work > fine with a 2.1 server (but not scp, which still gives "select: Bad file > descriptor". > > Any suggestions? I've gotten the "select: Bad file descriptor" from not having the binary scp in the PATH that sshd sets on the server side when my scp running ssh connects. This error message should probably be made more informative. About the "Bad packet length" I've only gotten that when trying to play with F-Secure SSH. I solved this problem by surrounding myself with mostly OpenSSH. //Peter -- irc: CareBear\ tel: +46-40-914420 irl: Peter Stuge gsm: +46-705-783805 From nitkin at europa.com Thu Nov 9 13:56:27 2000 From: nitkin at europa.com (Nate Itkin) Date: Wed, 8 Nov 2000 18:56:27 -0800 (PST) Subject: man pages won't work In-Reply-To: <2D00AD0E4D36D411BD300008C786E4240125817F@Denntex021.qwest.net> from "Smith, Donald " at "Nov 8, 2000 04:12:25 pm" Message-ID: <200011090256.SAA28746@thetics.europa.com> My workaround was to distribute the formatted files (/.../man/cat{1,8}) created using gnroff/mandoc to the systems without those utilities. You don't have a whatis database, but otherwise it works fine. -- - Nate Itkin - Nate.Itkin at europa.com - "Looking for an off-ramp on the Information Superhighway" From jmknoble at jmknoble.cx Thu Nov 9 15:53:31 2000 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Wed, 8 Nov 2000 23:53:31 -0500 Subject: ANNOUNCE: x11-ssh-askpass v1.1.1 Message-ID: <20001108235331.E23390@quipu.half.pint-stowp.cx> x11-ssh-askpass version 1.1.1 (Frog In a Sock) is now available from the following locations: http://www.jmknoble.cx/software/x11-ssh-askpass/ http://www.ntrnet.net/~jmknoble/software/x11-ssh-askpass/ x11-ssh-askpass is a passphrase dialog for use with OpenSSH (www.openssh.com) under the X Window System. The important changes since version 1.1.0 are as follows: - Fixed a bug where x11-ssh-askpass complained that an inputTimeout of '0' was invalid. - Plugged a minor potential memory leak. [Damien, looks like it's a good thing 1.1.0 didn't make it into the 2.3.0p1 RPM packages... :P] -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From mouring at pconline.com Thu Nov 9 16:09:27 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Wed, 8 Nov 2000 23:09:27 -0600 (CST) Subject: OpenSSH and S/Key (Re: Another shapshot) In-Reply-To: <20001108100006.B21929@greenie.muc.de> Message-ID: On Wed, 8 Nov 2000, Gert Doering wrote: > On Wed, Nov 08, 2000 at 01:34:04AM -0600, Ben Lindstrom wrote: > > > No. Tried using up[0]+up[1] instead, but that also gives me a constant > > > number - the first always gives me "58", the second "85", but neither > > > gives the current challenge. > > > > > > So - is anybody working on S/Key in OpenSSH? Is somebody using it on a > > > non-BSD platform? If yes, what did you do, which s/key library, which > > > CPU endianness, ...? > > > > > 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 one that has been ported from OpenBSD (similar to OpenSSH), I > found it by looking in "www.google.com" for "skey source". I found it > at http://www.sparc.spb.su/solaris/skey/, which, as I understand, is > also its home site. I use version 1.1. > > The S/Key library itself seems to work fine, that is: > Hmm... I see. I finally have it running after tweaking the skey and and OpenSSH. And I see what you mean.. And this is on a linux/i86 box. Challenge states: 40 etoh54947 It should state: 98 etoh39309 I doubt it's any type of endedness. I think it's a problem with OpenSSH portable code. (doing a diff -u of auth-skey.c and you'll notice large blocks of function changes..Which I'm attempting to track down) I think there is a good reason why it was disabled. =) Does anyone have this code working correctly on any platform (besides the given OpenBSD =)?? - Ben From mouring at pconline.com Thu Nov 9 16:20:05 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Wed, 8 Nov 2000 23:20:05 -0600 (CST) Subject: OpenSSH and S/Key (Re: Another shapshot) In-Reply-To: Message-ID: I'm tired.. but I think I see the problem. Should S/Key and OpenSSL SHA1 code be inter-changeable? =) Because that i what it seems happened. OpenSSL functions are being used instead of S/Key libraries. - Ben On Wed, 8 Nov 2000, Ben Lindstrom wrote: > On Wed, 8 Nov 2000, Gert Doering wrote: > > On Wed, Nov 08, 2000 at 01:34:04AM -0600, Ben Lindstrom wrote: > > > > No. Tried using up[0]+up[1] instead, but that also gives me a constant > > > > number - the first always gives me "58", the second "85", but neither > > > > gives the current challenge. > > > > > > > > So - is anybody working on S/Key in OpenSSH? Is somebody using it on a > > > > non-BSD platform? If yes, what did you do, which s/key library, which > > > > CPU endianness, ...? > > > > > > > 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 one that has been ported from OpenBSD (similar to OpenSSH), I > > found it by looking in "www.google.com" for "skey source". I found it > > at http://www.sparc.spb.su/solaris/skey/, which, as I understand, is > > also its home site. I use version 1.1. > > > > The S/Key library itself seems to work fine, that is: > > > Hmm... I see. I finally have it running after tweaking the skey and > and OpenSSH. > > And I see what you mean.. And this is on a linux/i86 box. > > Challenge states: 40 etoh54947 > It should state: 98 etoh39309 > > I doubt it's any type of endedness. I think it's a problem with > OpenSSH portable code. (doing a diff -u of auth-skey.c and you'll > notice large blocks of function changes..Which I'm attempting to track > down) > > I think there is a good reason why it was disabled. =) > > Does anyone have this code working correctly on any platform (besides the > given OpenBSD =)?? > > - Ben > > From mouring at pconline.com Thu Nov 9 16:34:52 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Wed, 8 Nov 2000 23:34:52 -0600 (CST) Subject: 2.3.0p1 vs 2.0.12 In-Reply-To: Message-ID: -2 was there for compatibility with SSH.com. -1 can be done by doing ssh "-o protocol 1" site. - Ben On Wed, 8 Nov 2000, Rob Hagopian wrote: > With the 2.3.0p1 client on Linux vs F-SECURE SSH Version 2.0.12 on a BSDI > box using ssh v2 DSA keys I get the following on the server side: > > debug: new_connection_callback returning > debug: Remote version: SSH-2.0-OpenSSH_2.3.0p1 > sshd[7778]: got bad packet when verifying user auto's publickey. > > Incidentally, there's an option -2 to use v2 if "1,2" is the Protocol > line, but no -1 to use v1 if "2,1" is in the Protocol line... Is there a > reason for this? > -Rob > > From a.d.stribblehill at durham.ac.uk Thu Nov 9 21:50:33 2000 From: a.d.stribblehill at durham.ac.uk (Andrew Stribblehill) Date: Thu, 9 Nov 2000 10:50:33 +0000 Subject: man pages won't work In-Reply-To: ; from djm@mindrot.org on Thu, Nov 09, 2000 at 09:09:28AM +1100 References: <20001108184822.A1551@greenie.muc.de> Message-ID: <20001109105033.A14779@womble.dur.ac.uk> Quoting Damien Miller : > On Wed, 8 Nov 2000, Gert Doering wrote: > > > Seconded. I thought it was only me (and didn't investigate further). > > > > To me, it seems as if some nroff-macros are used that "generic nroff -man" > > doesn't know. > > A few people have reported this as a problem. > > If someone with an affected system and better knowledge of nroff can come > up with a solution it would be appreciated. > > -d The same's true with Solaris. Since mdoc is a BSD thing[1], we're not going to get most SysV systems to understand it. I thought this was why we included the --with-manpage=cat flag (from memory) in the ./configure script. Certainly using preformatted pages is lots better than nothing, and is what I've done at Durham. Cheerio, Andrew Stribblehill Systems Programmer, IT Service, University of Durham, England [1] Mdoc is immesurably better than mm, but it's just not standard. From stevesk at sweden.hp.com Fri Nov 10 01:41:59 2000 From: stevesk at sweden.hp.com (Kevin Steves) Date: Thu, 9 Nov 2000 15:41:59 +0100 (CET) Subject: Final Suggestion (Re: suggested bsd-setproctitle.c) In-Reply-To: Message-ID: <200011091423.PAA10312@b0fh.sweden.hp.com> On Wed, 8 Nov 2000, Ben Lindstrom wrote: : On Wed, 8 Nov 2000, Kevin Steves wrote: : > I was thinking of: : > : > #ifdef HAVE___PROGNAME : > return __progname; : > #else : > ... : > : > : Unless you plan on moving the #ifndef .. #endif to around the call in : > : main(). : > : > I was trying to avoid that, but if we don't want to assign __progname to : > itself, it's fine with me. : > : I have no real quarms with assign itself to itself. One would hope during : an optimization phase the compiler would quietly drop it. Where should the set_progname() function go? Should I create a util-portable.c or is there a better place? From Stephan.Hendl at lds.brandenburg.de Fri Nov 10 01:24:07 2000 From: Stephan.Hendl at lds.brandenburg.de (Stephan Hendl) Date: Thu, 09 Nov 2000 15:24:07 +0100 Subject: PAM auth. and HP-UX Message-ID: Hi, just a few days ago I upgraded to openssh-2.3.0p1 on HP-UX 11.00, trusted system, incl. the PAM-patch PHCO_22265 and I run into another problem. The situation is the following. I come from server inside a firewall and go through the firewall wia a ssh-plug-gateway to one host in our internet section and further do a second server in the internet section. All this including the ssh-agent mechanism. The command is like: hendl at server > ssh -t host_a ssh -t firewall ssh -t host_b This procedere works fine, but on the host firewall I am disabled after an couple of conncetions because of too many unseccesful logins. Unfortunately the lastb command says nothing and in fact I didn't login to that machine, I used it only as an gateway. The syslog.log tells: sshd [xxx] Accepted rsa for hendl from a.b.c.d port 52166 sshd [xxx] Accepted rsa for hendl from a.b.c.d port 52167 sshd [xxx] Accepted rsa for hendl from a.b.c.d port 52168 sshd [xxx] Accepted rsa for hendl from a.b.c.d port 52169 sshd [xxx] Accepted rsa for hendl from a.b.c.d port 52170 sshd [xxx] PAM rejected by account configuration[28]: Account is disabled - see Account Administrator It looks for me that the PAM tries to authenticate via passwd but the authentication comes via the ssh-agent and therefore the account is disabled after three connections. Any help appreciated! regards 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 stevesk at sweden.hp.com Fri Nov 10 03:23:01 2000 From: stevesk at sweden.hp.com (Kevin Steves) Date: Thu, 9 Nov 2000 17:23:01 +0100 (CET) Subject: PAM auth. and HP-UX In-Reply-To: Message-ID: <200011091604.RAA04975@b0fh.sweden.hp.com> On Thu, 9 Nov 2000, Stephan Hendl wrote: : hendl at server > ssh -t host_a ssh -t firewall ssh -t host_b : : This procedere works fine, but on the host firewall I am disabled : after an couple of conncetions because of too many unseccesful : logins. Unfortunately the lastb command says nothing and in fact I : didn't login to that machine, I used it only as an gateway. The : syslog.log tells: : : sshd [xxx] Accepted rsa for hendl from a.b.c.d port 52166 : sshd [xxx] Accepted rsa for hendl from a.b.c.d port 52167 : sshd [xxx] Accepted rsa for hendl from a.b.c.d port 52168 : sshd [xxx] Accepted rsa for hendl from a.b.c.d port 52169 : sshd [xxx] Accepted rsa for hendl from a.b.c.d port 52170 : sshd [xxx] PAM rejected by account configuration[28]: Account is disabled - see Account Administrator Then firewall is the HP-UX host? Can you enable 'LogLevel DEBUG1' and provide the debug messages from sshd there? From aebenjam at opentext.com Fri Nov 10 04:53:22 2000 From: aebenjam at opentext.com (Adam Benjamin) Date: Thu, 9 Nov 2000 12:53:22 -0500 (EST) Subject: Bug Report - sshd invoked by inetd on Solaris 8 Message-ID: Hello, My apologies if this is a known "feature" and I'm simply reporting something already known. The situation is this: - the sshd in openssh-2.3.0p1 (and also previously in openssh-2.1.1p4) fail when invoked via inetd on Solaris 8 - the sshd is invoked with: 1) an entry in /etc/services: sshback 10000/tcp sshdback # SSH Back Door 2) an entry in /etc/inetd.conf sshback stream tcp nowait root /usr/local/sbin/sshd sshd -i -f \ /usr/local/etc/ssh/sshd_config.inetd (line split exists in this email, but not in original file) - the sshd_config.inetd is pretty standard with nothing special other than (for example) the port number changed - when connecting from an ssh client (also openssh-2.3.0p1) with verbose mode turned on, session appears as follows. Only the last 11 lines are shown (please let me know if you wish to see more) and the hex values after debug: Wait SSH2_MSG_KEX_DH_GEX_GROUP have been changed... I wasn't sure if I was exposing my private key data. Is someone can explain to me what that data is and why it will help your debugging, I'd be happy to pass it on: debug: got kexinit: debug: first kex follow: 0 debug: reserved: 0 debug: done debug: kex: server->client blowfish-cbc hmac-sha1 none debug: kex: client->server blowfish-cbc hmac-sha1 none debug: Sending SSH2_MSG_KEX_DH_GEX_REQUEST. debug: Wait SSH2_MSG_KEX_DH_GEX_GROUP. ff ff ff ff ff ff ff ff <------ please see above notes Disconnecting: Bad packet length 796226418. debug: Calling cleanup 0x805d910(0x0) - note that this same method works properly on other OS's and versions - I would be happy to answer any questions that assist in your diagnosis, but I expect you'll be able to reproduce the problem readily with access to another solaris 8 server. I hope that helps, Adam Benjamin Systems Administrator Open Text Corporation From aebenjam at opentext.com Fri Nov 10 05:01:00 2000 From: aebenjam at opentext.com (Adam Benjamin) Date: Thu, 9 Nov 2000 13:01:00 -0500 (EST) Subject: Bug Report - sshd invoked by inetd (follow-up) Message-ID: It would seem I didn't test this thoroughly enough before I sent my email. I can reproduce the problem (same openssh version) on both Solaris 8 and Solaris 6. (I had thought it was only on Solaris 8.) I haven't checked to see if it exists on other versions of Solaris, but the problem does not exist however on RedHat 6.2 running the same openssh version. I hope that helps. Adam Benjamin Systems Administrator Open Text Corporation ---------- Forwarded message ---------- Date: Thu, 9 Nov 2000 12:53:22 -0500 (EST) From: Adam Benjamin To: openssh-unix-dev at mindrot.org Subject: Bug Report - sshd invoked by inetd on Solaris 8 Hello, My apologies if this is a known "feature" and I'm simply reporting something already known. The situation is this: - the sshd in openssh-2.3.0p1 (and also previously in openssh-2.1.1p4) fail when invoked via inetd on Solaris 8 - the sshd is invoked with: 1) an entry in /etc/services: sshback 10000/tcp sshdback # SSH Back Door 2) an entry in /etc/inetd.conf sshback stream tcp nowait root /usr/local/sbin/sshd sshd -i -f \ /usr/local/etc/ssh/sshd_config.inetd (line split exists in this email, but not in original file) - the sshd_config.inetd is pretty standard with nothing special other than (for example) the port number changed - when connecting from an ssh client (also openssh-2.3.0p1) with verbose mode turned on, session appears as follows. Only the last 11 lines are shown (please let me know if you wish to see more) and the hex values after debug: Wait SSH2_MSG_KEX_DH_GEX_GROUP have been changed... I wasn't sure if I was exposing my private key data. Is someone can explain to me what that data is and why it will help your debugging, I'd be happy to pass it on: debug: got kexinit: debug: first kex follow: 0 debug: reserved: 0 debug: done debug: kex: server->client blowfish-cbc hmac-sha1 none debug: kex: client->server blowfish-cbc hmac-sha1 none debug: Sending SSH2_MSG_KEX_DH_GEX_REQUEST. debug: Wait SSH2_MSG_KEX_DH_GEX_GROUP. ff ff ff ff ff ff ff ff <------ please see above notes Disconnecting: Bad packet length 796226418. debug: Calling cleanup 0x805d910(0x0) - note that this same method works properly on other OS's and versions - I would be happy to answer any questions that assist in your diagnosis, but I expect you'll be able to reproduce the problem readily with access to another solaris 8 server. I hope that helps, Adam Benjamin Systems Administrator Open Text Corporation From root at theporch.com Fri Nov 10 07:38:48 2000 From: root at theporch.com (Phillip Porch) Date: Thu, 9 Nov 2000 14:38:48 -0600 (CST) Subject: SCO Openserver Patch Message-ID: I downloaded the Openssh-2.3.0p1 file and ran configure only to have it fail reporting the lack of libz. I found that configure was failing beacuse the test program did not include the libtinfo and libm which are needed to resolve references in libprot. I made changes to the configure script to add those libraries for SCO Openserver and then tried to compile the programs only to run into another problem with the shadow stuff. It turns out that even though Openserver has a shadow file, the protected password database stuff seems to work fine in the current code but if you do not define DISABLE-SHADOW, conflicts arise... So I made another change to configure to DISABLE_SHADOW if HAVE_SCO_PROTECTED_PW is defined. I have tested this on Openserver 5.0.5 and 5.0.6. Here is the universal patch fo configure to allow it to work with openserver. --- configure Sun Nov 5 21:25:18 2000 +++ /configure Thu Nov 9 14:18:21 2000 @@ -1685,7 +1685,7 @@ LDFLAGS="$LDFLAGS -L/usr/local/lib" MANTYPE='$(CATMAN)' mansubdir=cat - LIBS="$LIBS -lgen -lsocket -los -lprot -lx" + LIBS="$LIBS -lgen -lsocket -los -lprot -lx -ltinfo -lm" no_dev_ptmx=1 RANLIB=true cat >> confdefs.h <<\EOF @@ -1703,11 +1703,12 @@ LDFLAGS="$LDFLAGS -L/usr/local/lib" MANTYPE='$(CATMAN)' mansubdir=cat - LIBS="$LIBS -lgen -lsocket -lprot -lx" + LIBS="$LIBS -lgen -lsocket -lprot -lx -ltinfo -lm" no_dev_ptmx=1 rsh_path="/usr/bin/rcmd" cat >> confdefs.h <<\EOF #define HAVE_SCO_PROTECTED_PW 1 +#define DISABLE_SHADOW 1 EOF ;; -- Phillip P. Porch NIC:PP1573 finger for http://www.theporch.com UTM - 16 514546E 3994565N GnuPG key From gert at greenie.muc.de Fri Nov 10 10:10:44 2000 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 10 Nov 2000 00:10:44 +0100 Subject: S/Key solution In-Reply-To: ; from Ben Lindstrom on Thu, Nov 09, 2000 at 10:30:28AM -0600 References: <20001108100006.B21929@greenie.muc.de> Message-ID: <20001110001044.A2595@greenie.muc.de> Hi, On Thu, Nov 09, 2000 at 10:30:28AM -0600, Ben Lindstrom wrote: > Moving back to skey_keyinfo() makes it work, *BUT* ignores the original > problem which is stated in the 1.1 check in comments by Markus: [..] > So I assume the solution should be doing something like: > > char *skey_fake_keyinfo(char *username) > { > int i; > static char str[SKEY_MAX_CHALLENGE]; > struct skey skey; > > i = skeychallenge(&skey, username, str); > if (i == -1) { ** Generated Fake Response ** } > > return(str); > } Sounds fine to me, and should catch both problems. 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 Fri Nov 10 12:12:30 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 10 Nov 2000 02:12:30 +0100 Subject: S/Key solution In-Reply-To: ; from mouring@pconline.com on Thu, Nov 09, 2000 at 06:00:12PM -0600 References: <20001110001044.A2595@greenie.muc.de> Message-ID: <20001110021230.A10281@folly> On Thu, Nov 09, 2000 at 06:00:12PM -0600, Ben Lindstrom wrote: > Someone hit me. The problem is not in auth-skey.c. It's > really in the fact that the return from skey_keyinfo() is not saved in > auth1.c. Below in the patch which correctly fixes it. thanks for spotting this typo... > This same problem exists within the OpenBSD tree also. > > BTW.. This only works with RSA keys. s/key is not related to public keys. > Is S/Key valid in the view of > protocl 2.0? yes, it works via the keyboardinteractive options. From root at theporch.com Fri Nov 10 14:50:11 2000 From: root at theporch.com (Phillip Porch) Date: Thu, 9 Nov 2000 21:50:11 -0600 (CST) Subject: SCO Openserver Patch In-Reply-To: Message-ID: On Thu, 9 Nov 2000, Ben Lindstrom wrote: > Subject: Re: SCO Openserver Patch > > > Can we get this patch again configure.in instead? > > Thanks. > OK here it is: --- configure.in Sun Nov 5 03:08:45 2000 +++ /configure.in Thu Nov 9 21:26:14 2000 @@ -204,22 +204,24 @@ LDFLAGS="$LDFLAGS -L/usr/local/lib" MANTYPE='$(CATMAN)' mansubdir=cat - LIBS="$LIBS -lgen -lsocket -los -lprot -lx" + LIBS="$LIBS -lgen -lsocket -los -lprot -lx -ltinfo -lm" no_dev_ptmx=1 RANLIB=true AC_DEFINE(BROKEN_SYS_TERMIO_H) rsh_path="/usr/bin/rcmd" AC_DEFINE(HAVE_SCO_PROTECTED_PW) + AC_DEFINE(DISABLE_SHADOW) ;; *-*-sco3.2v5*) CFLAGS="$CFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib" MANTYPE='$(CATMAN)' mansubdir=cat - LIBS="$LIBS -lgen -lsocket -lprot -lx" + LIBS="$LIBS -lgen -lsocket -lprot -lx -ltinfo -lm" no_dev_ptmx=1 rsh_path="/usr/bin/rcmd" AC_DEFINE(HAVE_SCO_PROTECTED_PW) + AC_DEFINE(DISABLE_SHADOW) ;; *-dec-osf*) # This is untested -- Phillip P. Porch NIC:PP1573 finger for http://www.theporch.com UTM - 16 514546E 3994565N GnuPG key From openssh-unix-dev at progressive-comp.com Fri Nov 10 15:37:38 2000 From: openssh-unix-dev at progressive-comp.com (Hank Leininger) Date: Thu, 9 Nov 2000 23:37:38 -0500 Subject: bug in documentation for "Protocol" option Message-ID: <200011100437.XAA19463@mailer.progressive-comp.com> On 2000-11-08, Rob Hagopian wrote: > IMO consistency is important. Right now there is an inconsistent mix of > defaults and non-defaults in the config file with no clear direction on > them. I agree. Perhaps it's only because this is how I'm used to the SSH config files behaving, but I think it's valuable for the default config files to represent only the defaults, because then the defaults for a particular version are self-documenting. I'm used to saying "OK, let me go through /etc/sshd?_config and change all the defaults I don't agree with." Which means, a commented-out value that I *agree* with I shouldn't have to touch. A mix where some reflect "the default should be changed to this" and others represent "this is the default" violates the principle of least surprise, IMHO, and makes it a given that you either a)explicitly set every single option, b)look up every single option in the manpage and/or source, c)learn the "real" defaults by heart and be *sure* to update your brain with any/all changes that happen between versions[*]. a)is probably the correct answer, and is what i tend to do anyway, but it's sorta silly... [*] This is still something of a problem when upgrading from 2.x.y to 2.m.n, 'cuz the previous config file won't be overwritten by the install (and shouldn't be), but then one can always look at the default config file that came with 2.m.n and look for surprises. -- Hank Leininger From markus.friedl at informatik.uni-erlangen.de Sat Nov 11 00:31:46 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 10 Nov 2000 14:31:46 +0100 Subject: bug in documentation for "Protocol" option In-Reply-To: ; from rob@hagopian.net on Wed, Nov 08, 2000 at 11:46:09AM -0500 References: Message-ID: <20001110143146.C22913@folly> On Wed, Nov 08, 2000 at 11:46:09AM -0500, Rob Hagopian wrote: > IMO consistency is important. Right now there is an inconsistent mix of > defaults and non-defaults in the config file with no clear direction on > them. sending patches is useful. endless discussion is not. From gert at greenie.muc.de Sat Nov 11 03:13:48 2000 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 10 Nov 2000 17:13:48 +0100 Subject: bug in documentation for "Protocol" option In-Reply-To: <20001110143146.C22913@folly>; from Markus Friedl on Fri, Nov 10, 2000 at 02:31:46PM +0100 References: <20001110143146.C22913@folly> Message-ID: <20001110171348.A19788@greenie.muc.de> Hi, On Fri, Nov 10, 2000 at 02:31:46PM +0100, Markus Friedl wrote: > > IMO consistency is important. Right now there is an inconsistent mix of > > defaults and non-defaults in the config file with no clear direction on > > them. > sending patches is useful. endless discussion is not. I tend to disagree - we can't send in patches until there is consensus what the outcome should be. As long as we don't agree what we *want* in the config file, what good is sending patches? 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 rob at hagopian.net Sat Nov 11 03:44:31 2000 From: rob at hagopian.net (Rob Hagopian) Date: Fri, 10 Nov 2000 11:44:31 -0500 (EST) Subject: bug in documentation for "Protocol" option In-Reply-To: <20001110143146.C22913@folly> Message-ID: I could make patches until the cows came home, if noone's going to apply them it's a waste of time. I'll be happy to make a patch to put defaults in the conf file and explanations in the man pages if this is acceptable to everyone. I did start to make a patch anyways and discovered that most of the options documented in the man page don't even specify defaults, so a complete fix is a little more involved... -Rob On Fri, 10 Nov 2000, Markus Friedl wrote: > On Wed, Nov 08, 2000 at 11:46:09AM -0500, Rob Hagopian wrote: > > IMO consistency is important. Right now there is an inconsistent mix of > > defaults and non-defaults in the config file with no clear direction on > > them. > > sending patches is useful. endless discussion is not. > From markus.friedl at informatik.uni-erlangen.de Sat Nov 11 06:43:44 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 10 Nov 2000 20:43:44 +0100 Subject: bug in documentation for "Protocol" option In-Reply-To: <20001110171348.A19788@greenie.muc.de>; from gert@greenie.muc.de on Fri, Nov 10, 2000 at 05:13:48PM +0100 References: <20001110143146.C22913@folly> <20001110171348.A19788@greenie.muc.de> Message-ID: <20001110204344.C22105@folly> On Fri, Nov 10, 2000 at 05:13:48PM +0100, Gert Doering wrote: > As long as we don't agree what we *want* in the config file, what good is > sending patches? ok. ssh_config should look like sshd_config. sshd_config tries to have the defaults uncommented; suggested changes are commented out. this is what is intended and may not reflect the current state of the files. -markus From rob at hagopian.net Sat Nov 11 07:05:57 2000 From: rob at hagopian.net (Rob Hagopian) Date: Fri, 10 Nov 2000 15:05:57 -0500 (EST) Subject: bug in documentation for "Protocol" option In-Reply-To: <20001110204344.C22105@folly> Message-ID: OK, this weekend I'll make patches using these guidelines? -Rob On Fri, 10 Nov 2000, Markus Friedl wrote: > On Fri, Nov 10, 2000 at 05:13:48PM +0100, Gert Doering wrote: > > As long as we don't agree what we *want* in the config file, what good is > > sending patches? > > ok. ssh_config should look like sshd_config. > > sshd_config tries to have the defaults uncommented; > suggested changes are commented out. > > this is what is intended and may not reflect the current > state of the files. > > -markus > From mouring at pconline.com Sat Nov 11 17:47:55 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Sat, 11 Nov 2000 00:47:55 -0600 (CST) Subject: Testing.. please ignore. Message-ID: For some reason all my email is getting defered.. Just testing to see if this has been resolved. - Ben From djm at mindrot.org Sun Nov 12 00:20:18 2000 From: djm at mindrot.org (Damien Miller) Date: Sun, 12 Nov 2000 00:20:18 +1100 (EST) Subject: Testing.. please ignore. In-Reply-To: Message-ID: On Sat, 11 Nov 2000, Ben Lindstrom wrote: > For some reason all my email is getting defered.. > > Just testing to see if this has been resolved. My email hub was done for a few hours after a hardware upgrade turned nasty :( -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 dcp at sgi.com Sat Nov 11 03:19:38 2000 From: dcp at sgi.com (Dennis Parker) Date: Fri, 10 Nov 2000 10:19:38 -0600 (CST) Subject: Irix job limits patch Message-ID: <200011101619.KAA03553@yooper.americas.sgi.com> I've finished the 2.3 patch for Irix job limits. It's a bit longer than a couple of lines. The bulk of the patch changes the configuration files to enable the job limits support on Irix. The meat of the change is in session.c where the new job containter is created at the same point as the other Irix specific actions. - Dennis --- config.h.in Sun Nov 5 21:25:18 2000 +++ config.h.in Wed Nov 8 10:25:53 2000 @@ -92,6 +92,9 @@ /* Define if you want IRIX audit trails */ #undef WITH_IRIX_AUDIT +/* Define if you want IRIX kernel job initiation */ +#undef WITH_IRIX_JOBS + /* Location of random number pool */ #undef RANDOM_POOL end --- configure.in Sun Nov 5 03:08:45 2000 +++ configure.in Wed Nov 8 10:26:57 2000 @@ -111,6 +111,7 @@ AC_DEFINE(WITH_IRIX_ARRAY) AC_DEFINE(WITH_IRIX_PROJECT) AC_DEFINE(WITH_IRIX_AUDIT) + AC_DEFINE(WITH_IRIX_JOBS) no_libsocket=1 no_libnsl=1 AC_DEFINE(BROKEN_INET_NTOA) end --- configure Sun Nov 5 21:25:18 2000 +++ configure Wed Nov 8 10:28:11 2000 @@ -1459,6 +1459,10 @@ #define WITH_IRIX_AUDIT 1 EOF + cat >> confdefs.h <<\EOF +#define WITH_IRIX_JOBS 1 +EOF + no_libsocket=1 no_libnsl=1 cat >> confdefs.h <<\EOF end --- acconfig.h Wed Oct 18 08:11:44 2000 +++ acconfig.h Wed Nov 8 10:28:56 2000 @@ -83,6 +83,9 @@ /* Define if you want IRIX audit trails */ #undef WITH_IRIX_AUDIT +/* Define if you want IRIX kernel jobs */ +#undef WITH_IRIX_JOBS + /* Location of random number pool */ #undef RANDOM_POOL end --- session.c Fri Oct 27 22:19:58 2000 +++ session.c Wed Nov 8 13:20:03 2000 @@ -55,6 +55,9 @@ #ifdef WITH_IRIX_PROJECT #include #endif /* WITH_IRIX_PROJECT */ +#ifdef WITH_IRIX_JOBS +#include +#endif #if defined(HAVE_USERSEC_H) #include @@ -1014,6 +1017,14 @@ #ifdef WITH_IRIX_PROJECT prid_t projid; #endif /* WITH_IRIX_PROJECT */ +#ifdef WITH_IRIX_JOBS + jid_t jid = 0; +#else +#ifdef WITH_IRIX_ARRAY + int jid = 0; +#endif /* WITH_IRIX_ARRAY */ +#endif /* WITH_IRIX_JOBS */ + /* login(1) is only called if we execute the login shell */ if (options.use_login && command != NULL) @@ -1086,11 +1097,21 @@ exit(1); } endgrent(); +# ifdef WITH_IRIX_JOBS + jid = jlimit_startjob(pw->pw_name, pw->pw_uid, "interactive"); + if (jid == -1) { + fatal("Failed to create job container: %.100s", + strerror(errno)); + } +# endif /* WITH_IRIX_JOBS */ + # ifdef WITH_IRIX_ARRAY /* initialize array session */ - if (newarraysess() != 0) - fatal("Failed to set up new array session: %.100s", - strerror(errno)); + if (jid == 0) { + if (newarraysess() != 0) + fatal("Failed to set up new array session: %.100s", + strerror(errno)); + } # endif /* WITH_IRIX_ARRAY */ # ifdef WITH_IRIX_PROJECT /* initialize irix project info */ end From mouring at pconline.com Fri Nov 10 11:00:12 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Thu, 9 Nov 2000 18:00:12 -0600 (CST) Subject: S/Key solution In-Reply-To: <20001110001044.A2595@greenie.muc.de> Message-ID: On Fri, 10 Nov 2000, Gert Doering wrote: > Hi, > > On Thu, Nov 09, 2000 at 10:30:28AM -0600, Ben Lindstrom wrote: > > Moving back to skey_keyinfo() makes it work, *BUT* ignores the original > > problem which is stated in the 1.1 check in comments by Markus: > [..] > > So I assume the solution should be doing something like: > > [..] > > Sounds fine to me, and should catch both problems. > Someone hit me. The problem is not in auth-skey.c. It's really in the fact that the return from skey_keyinfo() is not saved in auth1.c. Below in the patch which correctly fixes it. This same problem exists within the OpenBSD tree also. BTW.. This only works with RSA keys. Is S/Key valid in the view of protocl 2.0? Gert, let me know if this fixes the problem. It does under Linux/i86. --- ../openssh/auth1.c Sat Oct 14 00:23:11 2000 +++ auth1.c Thu Nov 9 18:47:20 2000 @@ -273,7 +273,7 @@ if (options.skey_authentication == 1) { char *skeyinfo = NULL; if (pw != NULL) - skey_keyinfo(pw->pw_name); + skeyinfo = skey_keyinfo(pw->pw_name); if (skeyinfo == NULL) { debug("generating fake skeyinfo for %.100s.", luser); skeyinfo = skey_fake_keyinfo(luser); From Donald.Smith at qwest.com Fri Nov 10 01:42:05 2000 From: Donald.Smith at qwest.com (Smith, Donald ) Date: Thu, 9 Nov 2000 07:42:05 -0700 Subject: man pages won't work Message-ID: <2D00AD0E4D36D411BD300008C786E42401258182@Denntex021.qwest.net> To fix your whatis database just do a makewhatis or catman -w to rebuild the index for your new manpages. MANPATH probably needs to be set to find manpages in /usr/local/man. Donald Smith Staff IP Engineer IP Network Engineering Security 303-226-9939 Office 303-226-0688 fax 720-320-1537 cell > -----Original Message----- > From: Nate Itkin [mailto:nitkin at europa.com] > Sent: Wednesday, November 08, 2000 7:56 PM > To: openssh-unix-dev at mindrot.org > Subject: Re: man pages won't work > > > My workaround was to distribute the formatted files > (/.../man/cat{1,8}) > created using gnroff/mandoc to the systems without those utilities. > You don't have a whatis database, but otherwise it works fine. > > -- > - Nate Itkin > - Nate.Itkin at europa.com > - "Looking for an off-ramp on the Information Superhighway" > From aspa at kronodoc.fi Fri Nov 10 18:22:23 2000 From: aspa at kronodoc.fi (Marko Asplund) Date: Fri, 10 Nov 2000 09:22:23 +0200 (EET) Subject: ssh command & valid cipher names In-Reply-To: Message-ID: hello i thought that it would be useful to make ssh command to print valid cipher names in case an unknown cipher has been specified by the user for example the command 'ssh -c list' would print: Unknown cipher type 'list' valid cipher names: none, des, 3des, blowfish, 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 i've included a patch in case someone is interested in this small feature. best regards, -- aspa -------------- next part -------------- *** openssh-2.3.0p1/cipher.c.dist Fri Nov 10 07:44:26 2000 --- openssh-2.3.0p1/cipher.c Fri Nov 10 08:39:20 2000 *************** *** 442,447 **** --- 442,459 ---- return mask; } + char **get_valid_cipher_names() { + int max_cipher_cnt = 30; + char **cipher_names = (char **) xmalloc(max_cipher_cnt*sizeof(char *)); + int i; + Cipher *c; + + for (c = ciphers, i = 0; (c->name != NULL) && i < max_cipher_cnt-1; c++, i++) + cipher_names[i] = c->name; + cipher_names[i] = NULL; + return cipher_names; + } + Cipher * cipher_by_name(const char *name) { *** openssh-2.3.0p1/cipher.h.dist Fri Nov 10 07:51:59 2000 --- openssh-2.3.0p1/cipher.h Fri Nov 10 08:32:05 2000 *************** *** 108,113 **** --- 108,114 ---- Cipher *cipher_by_number(int id); int cipher_number(const char *name); char *cipher_name(int id); + char **get_valid_cipher_names(void); int ciphers_valid(const char *names); void cipher_init(CipherContext *, Cipher *, const u_char *, u_int, const u_char *, u_int); void cipher_encrypt(CipherContext *context, u_char *dest, const u_char *src, u_int len); *** openssh-2.3.0p1/ssh.c.dist Fri Nov 10 07:45:47 2000 --- openssh-2.3.0p1/ssh.c Fri Nov 10 08:37:09 2000 *************** *** 58,63 **** --- 58,64 ---- #include "key.h" #include "authfd.h" #include "authfile.h" + #include "cipher.h" #ifdef HAVE___PROGNAME extern char *__progname; *************** *** 427,433 **** --- 428,443 ---- /* SSH1 only */ Cipher *c = cipher_by_name(optarg); if (c == NULL || c->number < 0) { + char **namelist; + int i; fprintf(stderr, "Unknown cipher type '%s'\n", optarg); + fprintf(stderr, "valid cipher names: "); + namelist = get_valid_cipher_names(); + for(i=0; namelist[i] != NULL; i++) { + if(i) fprintf(stderr, ", "); + fprintf(stderr, "%s", namelist[i]); + } + fprintf(stderr, "\n"); exit(1); } options.cipher = c->number; From stevesk at sweden.hp.com Sun Nov 12 03:28:33 2000 From: stevesk at sweden.hp.com (Kevin Steves) Date: Sat, 11 Nov 2000 17:28:33 +0100 (CET) Subject: Final Suggestion (Re: suggested bsd-setproctitle.c) In-Reply-To: Message-ID: <200011111609.RAA09589@b0fh.sweden.hp.com> On Thu, 9 Nov 2000, Ben Lindstrom wrote: : On Thu, 9 Nov 2000, Kevin Steves wrote: : > Where should the set_progname() function go? Should I create a : > util-portable.c or is there a better place? : > : I see no problems putting it in bsd-misc.c myself. We have around 95 : files.. And I don't think that set_progname() needs it's own file.=) How does the attached patch look? : I'd love to take all the bsd-*.c files and push them into a compat/ : directory and tweak the configure/make files just to clean things : up. =) But that distrupts the CVS a great deal. I was thinking about that too. -------------- next part -------------- Index: bsd-misc.h =================================================================== RCS file: /var/cvs/openssh/bsd-misc.h,v retrieving revision 1.9 diff -u -r1.9 bsd-misc.h --- bsd-misc.h 2000/11/05 09:08:45 1.9 +++ bsd-misc.h 2000/11/11 15:56:36 @@ -27,10 +27,11 @@ #include "config.h" +char *get_progname(char *argv0); + #ifndef HAVE_SETSID #define setsid() setpgrp(0, getpid()) #endif /* !HAVE_SETSID */ - #ifndef HAVE_SETENV int setenv(const char *name, const char *value, int overwrite); Index: bsd-misc.c =================================================================== RCS file: /var/cvs/openssh/bsd-misc.c,v retrieving revision 1.16 diff -u -r1.16 bsd-misc.c --- bsd-misc.c 2000/10/18 13:11:44 1.16 +++ bsd-misc.c 2000/11/11 15:56:36 @@ -26,6 +26,26 @@ #include "xmalloc.h" #include "ssh.h" +char *get_progname(char *argv0) +{ +#ifdef HAVE___PROGNAME + extern char *__progname; + + return __progname; +#else + char *p; + + if (argv0 == NULL) + return "unknown"; /* XXX */ + p = strrchr(argv0, '/'); + if (p == NULL) + p = argv0; + else + p++; + return p; +#endif +} + #ifndef HAVE_SETLOGIN int setlogin(const char *name) { Index: bsd-setproctitle.c =================================================================== RCS file: /var/cvs/openssh/bsd-setproctitle.c,v retrieving revision 1.1 diff -u -r1.1 bsd-setproctitle.c --- bsd-setproctitle.c 2000/10/18 13:11:44 1.1 +++ bsd-setproctitle.c 2000/11/11 15:56:36 @@ -56,11 +56,7 @@ #define MAX_PROCTITLE 2048 -#ifdef HAVE___PROGNAME extern char *__progname; -#else -static const char *__progname = "sshd"; -#endif /* HAVE___PROGNAME */ /* * Set Process Title (SPT) defines. Modeled after sendmail's Index: log-server.c =================================================================== RCS file: /var/cvs/openssh/log-server.c,v retrieving revision 1.12 diff -u -r1.12 log-server.c --- log-server.c 2000/09/16 02:29:09 1.12 +++ log-server.c 2000/11/11 15:56:36 @@ -43,12 +43,6 @@ #include "xmalloc.h" #include "ssh.h" -#ifdef HAVE___PROGNAME -extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "sshd"; -#endif /* HAVE___PROGNAME */ - static LogLevel log_level = SYSLOG_LEVEL_INFO; static int log_on_stderr = 0; static int log_facility = LOG_AUTH; @@ -129,6 +123,7 @@ char fmtbuf[MSGBUFSIZ]; char *txt = NULL; int pri = LOG_INFO; + extern char *__progname; if (level > log_level) return; Index: sshconnect.c =================================================================== RCS file: /var/cvs/openssh/sshconnect.c,v retrieving revision 1.44 diff -u -r1.44 sshconnect.c --- sshconnect.c 2000/09/23 06:15:57 1.44 +++ sshconnect.c 2000/11/11 15:56:38 @@ -35,11 +35,7 @@ char *server_version_string = NULL; extern Options options; -#ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh"; -#endif /* HAVE___PROGNAME */ /* * Connect to the given ssh server using a proxy command. Index: session.c =================================================================== RCS file: /var/cvs/openssh/session.c,v retrieving revision 1.52 diff -u -r1.52 session.c --- session.c 2000/10/28 03:19:58 1.52 +++ session.c 2000/11/11 15:56:42 @@ -128,12 +128,7 @@ /* import */ extern ServerOptions options; -#ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "sshd"; -#endif /* HAVE___PROGNAME */ - extern int log_stderr; extern int debug_flag; extern unsigned int utmp_len; Index: ssh-add.c =================================================================== RCS file: /var/cvs/openssh/ssh-add.c,v retrieving revision 1.26 diff -u -r1.26 ssh-add.c --- ssh-add.c 2000/10/17 12:22:28 1.26 +++ ssh-add.c 2000/11/11 15:56:42 @@ -50,9 +50,9 @@ #ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh-add"; -#endif /* HAVE___PROGNAME */ +#else +char *__progname; +#endif void delete_file(AuthenticationConnection *ac, const char *filename) @@ -248,6 +248,7 @@ int i; int deleting = 0; + __progname = get_progname(argv[0]); init_rng(); /* check if RSA support exists */ Index: ssh-agent.c =================================================================== RCS file: /var/cvs/openssh/ssh-agent.c,v retrieving revision 1.33 diff -u -r1.33 ssh-agent.c --- ssh-agent.c 2000/09/29 12:01:37 1.33 +++ ssh-agent.c 2000/11/11 15:56:44 @@ -94,9 +94,9 @@ #ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh-agent"; -#endif /* HAVE___PROGNAME */ +#else +char *__progname; +#endif void idtab_init(void) @@ -668,6 +668,7 @@ char *shell, *format, *pidstr, pidstrbuf[1 + 3 * sizeof pid]; extern int optind; + __progname = get_progname(av[0]); init_rng(); /* check if RSA support exists */ Index: ssh-keygen.c =================================================================== RCS file: /var/cvs/openssh/ssh-keygen.c,v retrieving revision 1.26 diff -u -r1.26 ssh-keygen.c --- ssh-keygen.c 2000/10/14 05:23:12 1.26 +++ ssh-keygen.c 2000/11/11 15:56:44 @@ -72,9 +72,9 @@ /* argv0 */ #ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh-keygen"; -#endif /* HAVE___PROGNAME */ +#else +char *__progname; +#endif char hostname[MAXHOSTNAMELEN]; @@ -603,6 +603,7 @@ extern int optind; extern char *optarg; + __progname = get_progname(av[0]); init_rng(); SSLeay_add_all_algorithms(); Index: ssh.c =================================================================== RCS file: /var/cvs/openssh/ssh.c,v retrieving revision 1.47 diff -u -r1.47 ssh.c --- ssh.c 2000/10/28 03:19:58 1.47 +++ ssh.c 2000/11/11 15:56:48 @@ -61,9 +61,9 @@ #ifdef HAVE___PROGNAME extern char *__progname; -#else /* HAVE___PROGNAME */ -static const char *__progname = "ssh"; -#endif /* HAVE___PROGNAME */ +#else +char *__progname; +#endif /* Flag indicating whether IPv4 or IPv6. This can be set on the command line. Default value is AF_UNSPEC means both IPv4 and IPv6. */ @@ -235,6 +235,7 @@ int dummy; uid_t original_effective_uid; + __progname = get_progname(av[0]); init_rng(); /* Index: sftp-server.c =================================================================== RCS file: /var/cvs/openssh/sftp-server.c,v retrieving revision 1.3 diff -u -r1.3 sftp-server.c --- sftp-server.c 2000/09/23 03:58:32 1.3 +++ sftp-server.c 2000/11/11 15:56:48 @@ -90,6 +90,12 @@ #define get_string(lenp) buffer_get_string(&iqueue, lenp); #define TRACE log +#ifdef HAVE___PROGNAME +extern char *__progname; +#else +char *__progname; +#endif + /* input and output queue */ Buffer iqueue; Buffer oqueue; @@ -1015,6 +1021,7 @@ int in, out, max; ssize_t len, olen; + __progname = get_progname(av[0]); handle_init(); in = dup(STDIN_FILENO); Index: sshd.c =================================================================== RCS file: /var/cvs/openssh/sshd.c,v retrieving revision 1.94 diff -u -r1.94 sshd.c --- sshd.c 2000/10/14 05:23:13 1.94 +++ sshd.c 2000/11/11 15:56:52 @@ -79,6 +79,12 @@ #define O_NOCTTY 0 #endif +#ifdef HAVE___PROGNAME +extern char *__progname; +#else +char *__progname; +#endif + /* Server configuration options. */ ServerOptions options; @@ -492,6 +498,7 @@ int startup_p[2]; int startups = 0; + __progname = get_progname(av[0]); init_rng(); /* Save argv[0]. */ Index: scp.c =================================================================== RCS file: /var/cvs/openssh/scp.c,v retrieving revision 1.39 diff -u -r1.39 scp.c --- scp.c 2000/10/28 03:19:58 1.39 +++ scp.c 2000/11/11 15:56:54 @@ -84,6 +84,12 @@ #define _PATH_CP "cp" #endif +#ifdef HAVE___PROGNAME +extern char *__progname; +#else +char *__progname; +#endif + /* For progressmeter() -- number of seconds before xfer considered "stalled" */ #define STALLTIME 5 @@ -248,6 +254,8 @@ char *targ; extern char *optarg; extern int optind; + + __progname = get_progname(argv[0]); args.list = NULL; addargs("ssh"); /* overwritten with ssh_program */ From mouring at pconline.com Fri Nov 10 13:15:38 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Thu, 9 Nov 2000 20:15:38 -0600 (CST) Subject: Last S/Key thing to consider... Message-ID: What is everyone's opinion on reverting back to the OpenBSD's auth-skey.c which uses S/Key's sha1.h and libskey.a instead of OpenSSL. Personally it does not matter to me. I would perfer to revert back myself to reduce the differences between the two code trees. (Or if OpenBSD could pick up the changes. Either way.) I've already sent a patch to the person doing the portable OpenBSD S/Key library with a few minor corrects and a request to expose sha1.h since I know a few other projects that would use it. Either way it won't really matter since it's only used to generate the false S/Key response (But they do actually give different OTP outputs). - Ben From mouring at pconline.com Fri Nov 10 11:55:10 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Thu, 9 Nov 2000 18:55:10 -0600 (CST) Subject: SCO Openserver Patch In-Reply-To: Message-ID: Can we get this patch again configure.in instead? Thanks. On Thu, 9 Nov 2000, Phillip Porch wrote: > I downloaded the Openssh-2.3.0p1 file and ran configure only to have it > fail reporting the lack of libz. I found that configure was failing > beacuse the test program did not include the libtinfo and libm which are > needed to resolve references in libprot. I made changes to the configure > script to add those libraries for SCO Openserver and then tried to compile > the programs only to run into another problem with the shadow stuff. It > turns out that even though Openserver has a shadow file, the protected > password database stuff seems to work fine in the current code but if you > do not define DISABLE-SHADOW, conflicts arise... So I made another change > to configure to DISABLE_SHADOW if HAVE_SCO_PROTECTED_PW is defined. I have > tested this on Openserver 5.0.5 and 5.0.6. Here is the universal patch fo > configure to allow it to work with openserver. > > --- configure Sun Nov 5 21:25:18 2000 > +++ /configure Thu Nov 9 14:18:21 2000 > @@ -1685,7 +1685,7 @@ > LDFLAGS="$LDFLAGS -L/usr/local/lib" > MANTYPE='$(CATMAN)' > mansubdir=cat > - LIBS="$LIBS -lgen -lsocket -los -lprot -lx" > + LIBS="$LIBS -lgen -lsocket -los -lprot -lx -ltinfo -lm" > no_dev_ptmx=1 > RANLIB=true > cat >> confdefs.h <<\EOF > @@ -1703,11 +1703,12 @@ > LDFLAGS="$LDFLAGS -L/usr/local/lib" > MANTYPE='$(CATMAN)' > mansubdir=cat > - LIBS="$LIBS -lgen -lsocket -lprot -lx" > + LIBS="$LIBS -lgen -lsocket -lprot -lx -ltinfo -lm" > no_dev_ptmx=1 > rsh_path="/usr/bin/rcmd" > cat >> confdefs.h <<\EOF > #define HAVE_SCO_PROTECTED_PW 1 > +#define DISABLE_SHADOW 1 > EOF > > ;; > > -- > Phillip P. Porch NIC:PP1573 finger for > http://www.theporch.com UTM - 16 514546E 3994565N GnuPG key > > From mouring at pconline.com Sun Nov 12 06:34:57 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Sat, 11 Nov 2000 13:34:57 -0600 (CST) Subject: Final Suggestion (Re: suggested bsd-setproctitle.c) In-Reply-To: <200011111609.RAA09589@b0fh.sweden.hp.com> Message-ID: No complaints here. Everything seems perfectly fine to me. On Sat, 11 Nov 2000, Kevin Steves wrote: > On Thu, 9 Nov 2000, Ben Lindstrom wrote: > : On Thu, 9 Nov 2000, Kevin Steves wrote: > : > Where should the set_progname() function go? Should I create a > : > util-portable.c or is there a better place? > : > > : I see no problems putting it in bsd-misc.c myself. We have around 95 > : files.. And I don't think that set_progname() needs it's own file.=) > > How does the attached patch look? > > : I'd love to take all the bsd-*.c files and push them into a compat/ > : directory and tweak the configure/make files just to clean things > : up. =) But that distrupts the CVS a great deal. > > I was thinking about that too. > From mouring at pconline.com Fri Nov 10 02:04:39 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Thu, 9 Nov 2000 09:04:39 -0600 (CST) Subject: Final Suggestion (Re: suggested bsd-setproctitle.c) In-Reply-To: <200011091423.PAA10312@b0fh.sweden.hp.com> Message-ID: On Thu, 9 Nov 2000, Kevin Steves wrote: [..] > : I have no real quarms with assign itself to itself. One would hope during > : an optimization phase the compiler would quietly drop it. > > Where should the set_progname() function go? Should I create a > util-portable.c or is there a better place? > I see no problems putting it in bsd-misc.c myself. We have around 95 files.. And I don't think that set_progname() needs it's own file.=) I'd love to take all the bsd-*.c files and push them into a compat/ directory and tweak the configure/make files just to clean things up. =) But that distrupts the CVS a great deal. From mouring at pconline.com Fri Nov 10 03:30:28 2000 From: mouring at pconline.com (Ben Lindstrom) Date: Thu, 9 Nov 2000 10:30:28 -0600 (CST) Subject: S/Key solution In-Reply-To: <20001108100006.B21929@greenie.muc.de> Message-ID: Ok.. I think I've pieces together things. The skey_fake_keyinfo() is broken. I've not tried the skey code on my OpenBSD box, but I restored all the code in auth-skey.c back to the original code and I recieved yet another incorrect challenge. Moving back to skey_keyinfo() makes it work, *BUT* ignores the original problem which is stated in the 1.1 check in comments by Markus: [[...Quote...]] 4) generate fake skeys, for s/key for nonexisting users, too limit auth-tries for nonexisting users, too. [[...End Quote...]] So I assume the solution should be doing something like: char *skey_fake_keyinfo(char *username) { int i; static char str[SKEY_MAX_CHALLENGE]; struct skey skey; i = skeychallenge(&skey, username, str); if (i == -1) { ** Generated Fake Response ** } return(str); } This ensures that if the challenge exists we will always get a valid response (since it's the same code as skeyinfo command =), and if there is no challege then faking it so we don't drop hints of existing/non-existing S/Key accounts. Unless I missed something during the S/Key etup. =) - Ben From djm at mindrot.org Sun Nov 12 12:41:32 2000 From: djm at mindrot.org (Damien Miller) Date: Sun, 12 Nov 2000 12:41:32 +1100 (EST) Subject: Free Sun patch 105710-01 provides /dev/random on Solaris (fwd) Message-ID: Can anyone verify this and provide a URL for the docs? -- | ``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: Sat, 11 Nov 2000 11:18:24 -0800 (PST) From: Mixmaster Reply-To: openssl-users at openssl.org To: openssl-users at openssl.org Subject: Free Sun patch 105710-01 provides /dev/random on Solaris Several people have been looking for Sun's /dev/random patch and haven't been able to find it... Sun's patch 105710-01 is available for free download and includes their /dev/random equivalent for SPARC architectures. The patch is actually a bunch of packages to patch up their web server product. One of the packages is the SUNWski package which includes their "cryptorand" random number generator. The cryptorand daemon hooks itself up to a named fifo. The name of the fifo defaults to /dev/random but it can easily be changed by editing the cryotrand startup script in /etc/init.d/. Presumably if it were changed to /dev/urandom, OpenSSL would use it by default. If you just want cryptorand and not the "skiserv" daemon that's in the same package, you can pick the parts you want out of the "reloc" directory and copy them into place by hand. Haven't tried it. If it works for anyone, please post the story. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users at openssl.org Automated List Manager majordomo at openssl.org From gw2 at andrew.cmu.edu Sun Nov 12 14:48:22 2000 From: gw2 at andrew.cmu.edu (Geoffrey Alan Washburn) Date: Sat, 11 Nov 2000 22:48:22 -0500 (EST) Subject: scp problems? Message-ID: Hi. So I have been having problems using scp to copy files between two of my machines, both of which are running OpenSSH 2.30p1 (though I've had the same problem with previous versions). It is basically as simple as the file not being transferred after authentication occurs. I can however use scp to copy files back and forth from another machine using a SSH Communications version 1.2.27 daemon and client. Additionally, ssh between the two hosts itself works perfectly. Here is a log of what happens on the sender: $ scp -v -v -v foo.bar xxxxxxxx: Executing: program /usr/local/openssh/bin/ssh host xxxxxxxx, user (unspecified), command scp -v -t . gw2 at xxxxxxxx's password: stty: standard input: Invalid argument $ And here is the receiver: $ sshd -d -d -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 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. 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 128.2.xx.xxx port 708 debug1: Client protocol version 2.0; client software version OpenSSH_2.3.0p1 debug1: no match: OpenSSH_2.3.0p1 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-group-exchange-sha1,diffie-hellman-group1-sha1 debug1: got kexinit: ssh-dss debug1: 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 debug1: 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 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: zlib debug1: got kexinit: zlib debug1: got kexinit: debug1: got kexinit: debug1: first kex follow: 0 debug1: reserved: 0 debug1: done debug1: kex: client->server 3des-cbc hmac-sha1 zlib debug1: kex: server->client 3des-cbc hmac-sha1 zlib debug1: Wait SSH2_MSG_KEX_DH_GEX_REQUEST. /usr/local/openssh/etc/primes: No such file or directory WARNING: /usr/local/openssh/etc/primes does not exist, using old prime debug1: bits set: 515/1024 debug1: Sending SSH2_MSG_KEX_DH_GEX_GROUP. debug1: Wait SSH2_MSG_KEX_DH_GEX_INIT. debug1: bits set: 499/1024 debug1: sig size 20 20 debug1: send SSH2_MSG_NEWKEYS. debug1: Enabling compression at level 6. debug1: done: send SSH2_MSG_NEWKEYS. debug1: Wait SSH2_MSG_NEWKEYS. debug1: GOT SSH2_MSG_NEWKEYS. debug1: done: KEX2. debug1: userauth-request for user gw2 service ssh-connection method none debug1: attempt #1 debug2: input_userauth_request: setting up authctxt for gw2 debug1: Starting up PAM with username "gw2" debug2: input_userauth_request: try method none Failed none for gw2 from 128.2.xx.xxx port 708 ssh2 debug1: userauth-request for user gw2 service ssh-connection method password debug1: attempt #2 debug2: input_userauth_request: try method password debug1: PAM Password authentication accepted for user "gw2" debug1: PAM setting rhost to "xxxxxxxxxx.xx.xx.cmu.edu" Accepted password for gw2 from 128.2.xx.xxx port 708 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: open session 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 debug2: callback start 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 debug2: callback done debug2: channel 0: read 55 from efd 9 debug2: channel 0: read 108 from efd 9 debug2: channel 0: read 20 from efd 9 debug2: channel 0: read 19 from efd 9 debug1: channel 0: rcvd eof debug1: channel 0: output open -> drain debug1: channel 0: rcvd close debug1: channel 0: input open -> closed debug1: channel 0: close_read debug1: channel 0: obuf empty debug1: channel 0: output drain -> closed debug1: channel 0: close_write debug1: channel 0: send close debug1: channel 0: full closed2 debug1: channel_free: channel 0: status: The following connections are open: #0 server-session (t4 r0 i8/0 o128/0 fd 7/7) debug1: channel_free: channel 0: dettaching channel user debug1: session_by_channel: session 0 channel 0 debug1: session_close_by_channel: channel 0 kill 6864 debug1: Received SIGCHLD. debug1: tvp!=NULL kid 1 mili 100 error: select: Bad file descriptor debug1: session_by_pid: pid 6864 debug1: session_free: session 0 pid 6864 debug1: !channel_still_open. Closing connection to 128.2.xx.xxx debug1: compress outgoing: raw data 400, compressed 312, factor 0.78 debug1: compress incoming: raw data 165, compressed 129, factor 0.78 $ Both the sender and receiver were compiled with the following configuration: --with-kerberos4 --with-afs=/usr/local/lib/afs --with-default-path=/bin:/usr/bin:/usr/local/bin If you have any other questions let me know. This has been bugging me for a long time now... -- --- Geoff Washburn | washburn at acm.org | http://www.andrew.cmu.edu/~gw2/ --- From fortezzo at directlink.net Sun Nov 12 15:37:04 2000 From: fortezzo at directlink.net (Jason Fortezzo) Date: Sat, 11 Nov 2000 22:37:04 -0600 Subject: Free Sun patch 105710-01 provides /dev/random on Solaris (fwd) In-Reply-To: Message-ID: <4.3.2.7.2.20001111222633.00ba9d78@mailhost.directlink.net> At 07:41 PM 11/11/2000, you wrote: >Can anyone verify this and provide a URL for the docs? > You can get it via SunSolve, ftp://sunsolve.sun.com/pub/patches/105710-01.tar.Z. There are a few catches, mind you. 1) The patch in question only works for SunOS 5.5.1 and 5.6 2) This patch is the international version, I don't think it matters one bit for the /dev/random functionality tho. The patch contains multiple Solaris packages, you only need to install SUNWski, however. The only file you truly need in the package is /usr/lib/security/cryptorand, the rest is fluff. You also need the /var/etc directory to exist. I've been using the /dev/random thing for months now and it works great. One thing that concerns me is the "randomness" of the data, better than nothing I guess. I tried calling up Sun (with my platinum support no less) and they were completely clueless about the whole /dev/random thing and only after several days were they able to find any reference to it. So I reckon asking them about the "randomness" would be an excercise in futility. Jason Fortezzo fortezzo at directlink.net PGP Key: http://mysite.directlink.net/fortezzo/pgpkey --- If you have any trouble sounding condescending, find a Unix user to show you how it's done. --Scott Adams From gert at greenie.muc.de Mon Nov 13 07:30:08 2000 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 12 Nov 2000 21:30:08 +0100 Subject: S/Key solution In-Reply-To: ; from Ben Lindstrom on Thu, Nov 09, 2000 at 06:00:12PM -0600 References: <20001110001044.A2595@greenie.muc.de> Message-ID: <20001112213008.D1894@greenie.muc.de> Hi, On Thu, Nov 09, 2000 at 06:00:12PM -0600, Ben Lindstrom wrote: > Gert, let me know if this fixes the problem. It does under Linux/i86. > > --- ../openssh/auth1.c Sat Oct 14 00:23:11 2000 > +++ auth1.c Thu Nov 9 18:47:20 2000 > @@ -273,7 +273,7 @@ > if (options.skey_authentication == 1) { > char *skeyinfo = NULL; > if (pw != NULL) > - skey_keyinfo(pw->pw_name); > + skeyinfo = skey_keyinfo(pw->pw_name); > if (skeyinfo == NULL) { Well, this fix is "obviously correct" :-) Nevertheless, I've just tested it, and yes, it fixes things. Now S/Key works just as expected. Thanks! 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 gert at greenie.muc.de Mon Nov 13 07:33:40 2000 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 12 Nov 2000 21:33:40 +0100 Subject: Last S/Key thing to consider... In-Reply-To: ; from Ben Lindstrom on Thu, Nov 09, 2000 at 08:15:38PM -0600 References: Message-ID: <20001112213340.E1894@greenie.muc.de> Hi, On Thu, Nov 09, 2000 at 08:15:38PM -0600, Ben Lindstrom wrote: > What is everyone's opinion on reverting back to the OpenBSD's auth-skey.c > which uses S/Key's sha1.h and libskey.a instead of OpenSSL. I like the idea - why have two different SHA implementations in the same binary? It's just more code size to carry around. (Whether they create the same "fake" OTP or not doesn't matter much to 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 gert at greenie.muc.de Mon Nov 13 07:35:30 2000 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 12 Nov 2000 21:35:30 +0100 Subject: Skey with OpenSSH 2.2.0 In-Reply-To: <39F5B095.A8998750@sdv.fr>; from Laurent Papier on Tue, Oct 24, 2000 at 05:53:57PM +0200 References: <39F5B095.A8998750@sdv.fr> Message-ID: <20001112213530.F1894@greenie.muc.de> Hi, On Tue, Oct 24, 2000 at 05:53:57PM +0200, Laurent Papier wrote: > I need to setup OpenSSH on a AIX host with skey support. > I have search this mailing list archive and try all incarnation of skey > lib, but couldn't get openssh to compile with skey support on a non > openbsd system without pam support. > Even on my Linux box, I can't get it to compile. Earlier versions of the openssh package missed a few source files. Using openssh-2.3.0p1 with Ben's one-line fix should make skey work (at least with the .su s/key library). 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 jamesb-lists at alongtheway.com Mon Nov 13 08:19:47 2000 From: jamesb-lists at alongtheway.com (Jim B) Date: Sun, 12 Nov 2000 21:19:47 +0000 Subject: having some trouble using another user's RSA/DSA keys In-Reply-To: <20001025214650.T27161@alongtheway.com>; from jamesb-lists@alongtheway.com on Wed, Oct 25, 2000 at 09:46:50PM +0000 References: <2D00AD0E4D36D411BD300008C786E424229963@Denntex021.qwest.net> <20001025214650.T27161@alongtheway.com> Message-ID: <20001112211947.H21597@conflict.net> Has anyone looked into this? Is this something that _should_ work and is broken? Would appreciate a follow-up. Thanks. P.S. If anyone missed the beginnings of the thread I'd be happy to forward copies. On Wed, Oct 25, 2000 at 09:46:50PM +0000, Jim Breton wrote: > On Wed, Oct 25, 2000 at 09:26:10AM -0600, Smith, Donald wrote: > > Do you use the from="hostname" clause in your keys? > > I have seen this error between different versions of ssh where the public > > key had the from clause. > > Hi -- I'm not familiar with this, and do not see it in my public key. > > Would anyone be able to confirm that my scheme _does_ work with > OpenSSH-2.2.0p1 (i.e., make sure it's not a bug)? It should be easy > enough for someone to test. FYI I just tried the same thing against an > OpenSSH-1.2.3 server on another one of my boxen and achieved the same > result, so it doesn't appear to be an interoperability problem with the > commercial SSH (which is what was running on the first remote host I > tried). -- "I may disagree with what you have to say, but I will defend to the death your right to say it" -- Voltaire Jim B From rob at hagopian.net Tue Nov 14 04:29:06 2000 From: rob at hagopian.net (Rob Hagopian) Date: Mon, 13 Nov 2000 12:29:06 -0500 (EST) Subject: openssh-2.3.0p1-1 with RedHat 6.2 - Bad packet length In-Reply-To: <20001109004649.A23719@foo.birdnet.se> Message-ID: FYI, I get 'select: Bad file descriptor' even when scp is in the path, right before the copy starts... -Rob On Thu, 9 Nov 2000, Peter Stuge wrote: > On Wed, Nov 08, 2000 at 11:06:30AM -0700, James wrote: > > I haven't been able to get scp to work with RedHat 6.2 (select: Bad file > > descriptor), so... I tried upgrading with openssh-2.3.0p1-1.src.rpm and > > openssl-0.9.5a-3.src.rpm No joy. When running just ssh, I get > > "Disconnecting: Bad packet length 795178083." > > > > This seems to be a problem with sshd, since the 2.3 ssh client will work > > fine with a 2.1 server (but not scp, which still gives "select: Bad file > > descriptor". > > > > Any suggestions? > > I've gotten the "select: Bad file descriptor" from not having the binary scp > in the PATH that sshd sets on the server side when my scp running ssh > connects. This error message should probably be made more informative. > > About the "Bad packet length" I've only gotten that when trying to play with > F-Secure SSH. I solved this problem by surrounding myself with mostly > OpenSSH. > > //Peter > > From davidb at research.netsol.com Tue Nov 14 05:00:37 2000 From: davidb at research.netsol.com (David Blacka) Date: 13 Nov 2000 13:00:37 -0500 Subject: Free Sun patch 105710-01 provides /dev/random on Solaris (fwd) In-Reply-To: Jason Fortezzo's message of "Sat, 11 Nov 2000 22:37:04 -0600" References: <4.3.2.7.2.20001111222633.00ba9d78@mailhost.directlink.net> Message-ID: >>>>> "JF" == Jason Fortezzo writes: JF> At 07:41 PM 11/11/2000, you wrote: >> Can anyone verify this and provide a URL for the docs? >> JF> You can get it via SunSolve, JF> ftp://sunsolve.sun.com/pub/patches/105710-01.tar.Z. JF> There are a few catches, mind you. JF> 1) The patch in question only works for SunOS 5.5.1 and 5.6 JF> 2) This patch is the international version, I don't JF> think it matters one bit for the /dev/random functionality tho. Actually, I've used it successfully on Solaris 5.7 and 5.8, but in 32-bit mode only. -- David Blacka Sr. Research Engineer Research and Development -- Network Solutions, Herndon, VA From robert.steinfeldt at steeleye.com Tue Nov 14 05:08:30 2000 From: robert.steinfeldt at steeleye.com (Robert Steinfeldt) Date: Mon, 13 Nov 2000 10:08:30 -0800 Subject: openssh-2.3.0p1-1 with RedHat 6.2 - Bad packet length References: Message-ID: <3A102E1E.5000308@steeleye.com> Rob Hagopian wrote: > FYI, I get 'select: Bad file descriptor' even when scp is in the path, > right before the copy starts... > -Rob I had this problem when I upgraded a series of RedHat 6.1 and 6.2 machines from OpenSSH 2.2.0* to 2.3.0p1.[1] Even /with/ the correct OpenSSH scp in the path before any other scp might be called, I was having the general problems you're describing when I tried to copy TO a machine that had had ssh.com's ssh installed in the /usr/local tree.[2] What I did to make the problem stop was to completely remove the ssh.com installation in /usr/local on the side being copied to. It appears that the problem emerged with the upgrade to OpenSSH 2.3.0, since I'd done scp transfers between the machines when they ran OpenSSH 2.2.0, without a problem. This may not be the issue you're seeing, but it's worth a try. Robert Steinfeldt -- robert.steinfeldt at steeleye.com [1] - In both cases, I was using the provided Redhat RPMs available from openssh.com. [2] - I used to have the noncommercial ssh.com version run from inetd, and when I originally upgraded to OpenSSH, simply commented out that line and let OpenSSH run sshd from /etc/rc.d/init.d. The old installation just sat where it was. > > On Thu, 9 Nov 2000, Peter Stuge wrote: > > >> On Wed, Nov 08, 2000 at 11:06:30AM -0700, James wrote: >> >>> I haven't been able to get scp to work with RedHat 6.2 (select: Bad file >>> descriptor), so... I tried upgrading with openssh-2.3.0p1-1.src.rpm and >>> openssl-0.9.5a-3.src.rpm No joy. When running just ssh, I get >>> "Disconnecting: Bad packet length 795178083." >>> >>> This seems to be a problem with sshd, since the 2.3 ssh client will work >>> fine with a 2.1 server (but not scp, which still gives "select: Bad file >>> descriptor". >>> >>> Any suggestions? >> >> I've gotten the "select: Bad file descriptor" from not having the binary scp >> in the PATH that sshd sets on the server side when my scp running ssh >> connects. This error message should probably be made more informative. >> >> About the "Bad packet length" I've only gotten that when trying to play with >> F-Secure SSH. I solved this problem by surrounding myself with mostly >> OpenSSH. >> >> //Peter >> >> From rob at hagopian.net Tue Nov 14 05:55:51 2000 From: rob at hagopian.net (Rob Hagopian) Date: Mon, 13 Nov 2000 13:55:51 -0500 (EST) Subject: openssh-2.3.0p1-1 with RedHat 6.2 - Bad packet length In-Reply-To: <3A102E1E.5000308@steeleye.com> Message-ID: Hehe... I did totally remove the commercial ssh beforehand... All client machines are running the last snapshot before 2.3.0p1 and the server machine is running 2.3.0p1 (BTW: this setup still has an occasional hanging problem). The funny thing is, I went to double check with: $ for i in `cat *`; do > ssh ${i} ls /usr/local/bin/scp > done and got this as output: select: Bad file descriptor select: Bad file descriptor select: Bad file descriptor select: Bad file descriptor select: Bad file descriptor select: Bad file descriptor ls: select: Bad file descriptor select: Bad file descriptor ls: select: Bad file descriptor etc, etc, etc... So I do another test: $ ssh dhcorp301 ls 1 $ ssh dhcorp301 ls asdf select: Bad file descriptor Ah... ls will print to stderr if it can't find the file... Considering how long debug output is, I'll append it to the end of this email (after the included quotes). If server output is needed let me know... -Rob On Mon, 13 Nov 2000, Robert Steinfeldt wrote: > Rob Hagopian wrote: > > > FYI, I get 'select: Bad file descriptor' even when scp is in the path, > > right before the copy starts... > > -Rob > > I had this problem when I upgraded a series of RedHat 6.1 and 6.2 > machines from OpenSSH 2.2.0* to 2.3.0p1.[1] Even /with/ the correct > OpenSSH scp in the path before any other scp might be called, I was > having the general problems you're describing when I tried to copy TO a > machine that had had ssh.com's ssh installed in the /usr/local tree.[2] > What I did to make the problem stop was to completely remove the ssh.com > installation in /usr/local on the side being copied to. > > It appears that the problem emerged with the upgrade to OpenSSH 2.3.0, > since I'd done scp transfers between the machines when they ran OpenSSH > 2.2.0, without a problem. This may not be the issue you're seeing, but > it's worth a try. > > Robert Steinfeldt -- robert.steinfeldt at steeleye.com > > [1] - In both cases, I was using the provided Redhat RPMs available from > openssh.com. > [2] - I used to have the noncommercial ssh.com version run from inetd, > and when I originally upgraded to OpenSSH, simply commented out that > line and let OpenSSH run sshd from /etc/rc.d/init.d. The old > installation just sat where it was. > > > > > On Thu, 9 Nov 2000, Peter Stuge wrote: > > > > > >> On Wed, Nov 08, 2000 at 11:06:30AM -0700, James wrote: > >> > >>> I haven't been able to get scp to work with RedHat 6.2 (select: Bad file > >>> descriptor), so... I tried upgrading with openssh-2.3.0p1-1.src.rpm and > >>> openssl-0.9.5a-3.src.rpm No joy. When running just ssh, I get > >>> "Disconnecting: Bad packet length 795178083." > >>> > >>> This seems to be a problem with sshd, since the 2.3 ssh client will work > >>> fine with a 2.1 server (but not scp, which still gives "select: Bad file > >>> descriptor". > >>> > >>> Any suggestions? > >> > >> I've gotten the "select: Bad file descriptor" from not having the binary scp > >> in the PATH that sshd sets on the server side when my scp running ssh > >> connects. This error message should probably be made more informative. > >> > >> About the "Bad packet length" I've only gotten that when trying to play with > >> F-Secure SSH. I solved this problem by surrounding myself with mostly > >> OpenSSH. > >> > >> //Peter > >> > >> > > $ ssh -v dhcorp301 ls SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090581f). debug: Reading configuration data /usr/etc/ssh_config debug: Applying options for * debug: Seeding random number generator debug: ssh_connect: getuid 0 geteuid 0 anon 0 debug: Connecting to dhcorp301 [216.200.130.46] port 22. debug: Allocated local port 994. 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 debug: Local version string SSH-2.0-OpenSSH_2.3.0p1 debug: send KEXINIT debug: done debug: wait KEXINIT debug: got kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha 1 debug: got kexinit: ssh-dss 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 lysa tor.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 lysa tor.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: 520/1024 debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. debug: Got SSH2_MSG_KEXDH_REPLY. debug: Host 'dhcorp301' is known and matches the DSA host key. debug: bits set: 526/1024 debug: len 55 datafellows 0 debug: dsa_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: /usr/dh/home/prod/.ssh/id_dsa debug: read DSA private key done 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: ls debug: channel 0: open confirm rwindow 0 rmax 16384 debug: client_input_channel_req: rtype exit-status reply 0 debug: channel 0: rcvd eof debug: channel 0: output open -> drain debug: channel 0: rcvd close debug: channel 0: input open -> closed debug: channel 0: close_read 1 debug: channel 0: obuf empty debug: channel 0: output drain -> closed debug: channel 0: close_write debug: channel 0: send close debug: channel 0: full closed2 debug: channel_free: channel 0: status: The following connections are open: #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1) debug: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.2 seconds debug: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug: Exit status 0 $ $ ssh -v dhcorp301 ls asdf SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090581f). debug: Reading configuration data /usr/etc/ssh_config debug: Applying options for * debug: Seeding random number generator debug: ssh_connect: getuid 0 geteuid 0 anon 0 debug: Connecting to dhcorp301 [216.200.130.46] port 22. debug: Allocated local port 687. 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 debug: Local version string SSH-2.0-OpenSSH_2.3.0p1 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 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: 544/1024 debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. debug: Got SSH2_MSG_KEXDH_REPLY. debug: Host 'dhcorp301' is known and matches the DSA host key. debug: bits set: 498/1024 debug: len 55 datafellows 0 debug: dsa_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: /usr/dh/home/prod/.ssh/id_dsa debug: read DSA private key done 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: ls asdf debug: channel 0: open confirm rwindow 0 rmax 16384 debug: client_input_channel_req: rtype exit-status reply 0 debug: channel 0: rcvd eof debug: channel 0: output open -> drain debug: channel 0: rcvd close debug: channel 0: input open -> closed debug: channel 0: close_read debug: channel 0: obuf empty debug: channel 0: output drain -> closed debug: channel 0: close_write debug: channel 0: send close debug: channel 0: full closed2 debug: channel_free: channel 0: status: The following connections are open: #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1) select: Bad file descriptor debug: Transferred: stdin 0, stdout 0, stderr 29 bytes in 0.2 seconds debug: Bytes per second: stdin 0.0, stdout 0.0, stderr 171.5 debug: Exit status 1 $ From mitchell at ucar.edu Tue Nov 14 06:54:14 2000 From: mitchell at ucar.edu (David Mitchell) Date: Mon, 13 Nov 2000 12:54:14 -0700 Subject: scp -r bug References: Message-ID: <3A1046E6.5DD06BF9@ucar.edu> I reported this bug back in 2.1.1p4, but never got any response. Since it's still there in 2.3.0p1 I thought I would try again. If you include a trailing slash on the source directory name, the code in scp to extract the directory name fails. The result is that rather than creating the directory on the far side, it simply copies the files. In other words, scp -r foo/ host:bar acts like scp -r foo/* host:bar instead of scp -r foo host:bar The problem is due to this code in scp.c at about line 621: last = strrchr(name, '/'); if (last == 0) last = name; else last++; If you have a trailing slash, this code points last to the terminating null character instead of the beginning of the directory name. One possible solution is to remove the trailing slash if it exists. Anything fancier might involve reworking the whole directory parsing code. This is a simple fix which does the trick. Adding this before the code above make scp act the way it should. /* Bugfix. If the name has a trailing slash, take it off. This * ensures that we actually get a directory name, not a null string * if the user provides a trailing slash. */ if (name[strlen(name) - 1] == '/') { name[strlen(name) - 1] = 0x00; }; It it possible to get this fix (or a similar one) merged back in? I can apply all my local installations, but that's a hassle. While this may seem like a minor bug, it can easily lead to the inadvertant overwriting of the wrong file. -David Mitchell From markus.friedl at informatik.uni-erlangen.de Tue Nov 14 07:08:44 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 13 Nov 2000 21:08:44 +0100 Subject: having some trouble using another user's RSA/DSA keys In-Reply-To: <20001112211947.H21597@conflict.net>; from jamesb-lists@alongtheway.com on Sun, Nov 12, 2000 at 09:19:47PM +0000 References: <2D00AD0E4D36D411BD300008C786E424229963@Denntex021.qwest.net> <20001025214650.T27161@alongtheway.com> <20001112211947.H21597@conflict.net> Message-ID: <20001113210844.H7859@folly> i can confirm that from="blablabla" works with DSA keys in openssh-2.3.x On Sun, Nov 12, 2000 at 09:19:47PM +0000, Jim B wrote: > Has anyone looked into this? Is this something that _should_ work and > is broken? Would appreciate a follow-up. Thanks. > > P.S. If anyone missed the beginnings of the thread I'd be happy to > forward copies. > > > On Wed, Oct 25, 2000 at 09:46:50PM +0000, Jim Breton wrote: > > On Wed, Oct 25, 2000 at 09:26:10AM -0600, Smith, Donald wrote: > > > Do you use the from="hostname" clause in your keys? > > > I have seen this error between different versions of ssh where the public > > > key had the from clause. > > > > Hi -- I'm not familiar with this, and do not see it in my public key. > > > > Would anyone be able to confirm that my scheme _does_ work with > > OpenSSH-2.2.0p1 (i.e., make sure it's not a bug)? It should be easy > > enough for someone to test. FYI I just tried the same thing against an > > OpenSSH-1.2.3 server on another one of my boxen and achieved the same > > result, so it doesn't appear to be an interoperability problem with the > > commercial SSH (which is what was running on the first remote host I > > tried). > > -- > "I may disagree with what you have to say, > but I will defend to the death your right to say it" > -- Voltaire > > Jim B > From markus.friedl at informatik.uni-erlangen.de Tue Nov 14 07:13:18 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 13 Nov 2000 21:13:18 +0100 Subject: OpenSSH Security Advisory (adv.fwd) Message-ID: <20001113211318.A27132@folly> Hostile servers can force OpenSSH clients to do agent or X11 forwarding 1. Systems affected: All versions of OpenSSH prior to 2.3.0 are affected. 2. Description: If agent or X11 forwarding is disabled in the ssh client configuration, the client does not request these features during session setup. This is the correct behaviour. However, when the ssh client receives an actual request asking for access to the ssh-agent, the client fails to check whether this feature has been negotiated during session setup. The client does not check whether the request is in compliance with the client configuration and grants access to the ssh-agent. A similar problem exists in the X11 forwarding implementation. 3. Impact: Hostile servers can access your X11 display or your ssh-agent. 4. Short Term Solution: Clear both the $DISPLAY and the $SSH_AUTH_SOCK variable before connecting to untrusted hosts: % unset SSH_AUTH_SOCK; unset DISPLAY; ssh host 5. Solution: Upgrade to OpenSSH-2.3.0 or apply the attached patch. OpenSSH-2.3.0 is available from www.openssh.com. 6. Credits: Thanks to Jacob Langseth for pointing out the X11 forwarding issue. Appendix: Patch against openssh-2.2.0 --- /openssh-2.2.0/clientloop.c Sun Aug 20 00:21:19 2000 +++ ssh/clientloop.c Fri Nov 10 13:54:42 2000 @@ -32,6 +32,8 @@ #include "buffer.h" #include "bufaux.h" +extern Options options; + /* Flag indicating that stdin should be redirected from /dev/null. */ extern int stdin_null_flag; @@ -750,7 +752,6 @@ int client_loop(int have_pty, int escape_char_arg, int ssh2_chan_id) { - extern Options options; double start_time, total_time; int len; char buf[100]; @@ -993,7 +994,7 @@ debug("client_input_channel_open: ctype %s rchan %d win %d max %d", ctype, rchan, rwindow, rmaxpack); - if (strcmp(ctype, "x11") == 0) { + if (strcmp(ctype, "x11") == 0 && options.forward_x11) { int sock; char *originator; int originator_port; @@ -1066,11 +1067,14 @@ dispatch_set(SSH_MSG_CHANNEL_OPEN_CONFIRMATION, &channel_input_open_confirmation); dispatch_set(SSH_MSG_CHANNEL_OPEN_FAILURE, &channel_input_open_failure); dispatch_set(SSH_MSG_PORT_OPEN, &channel_input_port_open); - dispatch_set(SSH_SMSG_AGENT_OPEN, &auth_input_open_request); dispatch_set(SSH_SMSG_EXITSTATUS, &client_input_exit_status); dispatch_set(SSH_SMSG_STDERR_DATA, &client_input_stderr_data); dispatch_set(SSH_SMSG_STDOUT_DATA, &client_input_stdout_data); - dispatch_set(SSH_SMSG_X11_OPEN, &x11_input_open); + + dispatch_set(SSH_SMSG_AGENT_OPEN, options.forward_agent ? + &auth_input_open_request : NULL); + dispatch_set(SSH_SMSG_X11_OPEN, options.forward_x11 ? + &x11_input_open : NULL); } void client_init_dispatch_15() From paul.l.allen at boeing.com Tue Nov 14 10:30:13 2000 From: paul.l.allen at boeing.com (Paul Allen) Date: Mon, 13 Nov 2000 15:30:13 -0800 Subject: Free Sun patch 105710-01 provides /dev/random on Solaris (fwd) References: <4.3.2.7.2.20001111222633.00ba9d78@mailhost.directlink.net> Message-ID: <3A107985.931BE253@boeing.com> David Blacka wrote: > > >>>>> "JF" == Jason Fortezzo writes: > > JF> At 07:41 PM 11/11/2000, you wrote: > >> Can anyone verify this and provide a URL for the docs? > >> > > JF> You can get it via SunSolve, > JF> ftp://sunsolve.sun.com/pub/patches/105710-01.tar.Z. > > JF> There are a few catches, mind you. > JF> 1) The patch in question only works for SunOS 5.5.1 and 5.6 > JF> 2) This patch is the international version, I don't > JF> think it matters one bit for the /dev/random functionality tho. > > Actually, I've used it successfully on Solaris 5.7 and 5.8, but in > 32-bit mode only. I've used it on 64-bit hardware (Ultra 10) under Solaris 8. No problems that I can see. Paul Allen -- Paul L. Allen | voice: (425) 865-3297 fax: (425) 865-2964 Unix Technical Support | paul.l.allen at boeing.com Boeing Phantom Works Math & Computing Technology Site Operations, POB 3707 M/S 7L-68, Seattle, WA 98124-2207 From jhriv at ucsd.edu Tue Nov 14 11:33:23 2000 From: jhriv at ucsd.edu (John H. Robinson, IV) Date: Mon, 13 Nov 2000 16:33:23 -0800 Subject: OpenSSH-2.3.0p1 - debug: no match: OpenSSH_2.3.0p1 Message-ID: <20001113163322.A17042@ucsd.edu> disclaimer: i am not subscribed to the list. i just compiled OpenSSH-2.3.0p1 and replaced OpenSSH-2.2.0p1. i noticed that OpenSSH-2.3.0p1 does not match itself in compat.c the problem seems to be in line 65 of compat.c, { "^OpenSSH[-_]2\\.[012]", SSH_OLD_SESSIONID }, it looks like the regex needs to be expanded to include 3: { "^OpenSSH[-_]2\\.[0123]", SSH_OLD_SESSIONID }, not understanding the ramifications of such a change, i am loathe to do it myself. -john From djm at mindrot.org Tue Nov 14 12:15:04 2000 From: djm at mindrot.org (Damien Miller) Date: Tue, 14 Nov 2000 12:15:04 +1100 (EST) Subject: New snapshot Message-ID: I have just uploaded a new snapshot to: http://www.mindrot.org/misc/openssh/openssh-SNAP-20001114.tar.gz This snapshot includes Markus Friedl's new SSH2 RSA authentication work and -R portforwarding for SSH2. Please give these a good test. The new RSA authentications works similar to the current SSH2 DSA keys, but requires a little modification to config files. Currently RSA key cannot be shared between SSH1 and SSH2. To generate keys, ssh-keygen now has a type '-t' parameter. Valid types are 'rsa1' (for SSH1 RSA keys), 'rsa' (SSH2 RSA) and 'dsa' (SSH2 DSA). eg. "ssh-keygen -t rsa -f ~/.ssh/id_rsa" will generate a new SSH2 RSA key. For public key authentication, just copy the public portion of the RSA key into your ~/.ssh/authorized_keys2 file. It is normal for the public RSA keys to be shorter than DSA keys. SSH2 RSA keys are fully supported by ssh-agent. Keys are tried in the order in which they are added to the agent, so 'ssh-add' your RSA key first if you want to try it out. For the server, all hostkeys are now unified and sshd will automatically detect the type of a host key. The 'HostDSAKey' option is therefore deprecated in favor of 'HostKey'. To specify RSA and DSA keys for SSH2 use, just use more 'HostKey' options. The 'DSAAuthentication' option is deprecated in favour of the general 'PubkeyAuthentication' option. The host key section of my sshd_config looks like this: HostKey /etc/ssh/ssh_host_key HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key For the client, the 'IdentityFile2' option is deprecated in favor of an autodetecting 'IdentityFile' option. You can specity rsa1, dsa and rsa keys using this option. RSA pubkey auth seems a little quicker than DSA and it is not vulnerable to the problems described in the WARNING.RNG file. Full changelog: 20001113 - (djm) Add pointer to http://www.imasy.or.jp/~gotoh/connect.c to contrib/README - (djm) Merge OpenBSD changes: - markus at cvs.openbsd.org 2000/11/06 16:04:56 [channels.c channels.h clientloop.c nchan.c serverloop.c] [session.c ssh.c] agent forwarding and -R for ssh2, based on work from jhuuskon at messi.uku.fi - markus at cvs.openbsd.org 2000/11/06 16:13:27 [ssh.c sshconnect.c sshd.c] do not disabled rhosts(rsa) if server port > 1024; from pekkas at netcore.fi - markus at cvs.openbsd.org 2000/11/06 16:16:35 [sshconnect.c] downgrade client to 1.3 if server is 1.4; help from mdb at juniper.net - markus at cvs.openbsd.org 2000/11/09 18:04:40 [auth1.c] typo; from mouring at pconline.com - markus at cvs.openbsd.org 2000/11/12 12:03:28 [ssh-agent.c] off-by-one when removing a key from the agent - markus at cvs.openbsd.org 2000/11/12 12:50:39 [auth-rh-rsa.c auth2.c authfd.c authfd.h] [authfile.c hostfile.c kex.c kex.h key.c key.h myproposal.h] [readconf.c readconf.h rsa.c rsa.h servconf.c servconf.h ssh-add.c] [ssh-agent.c ssh-keygen.1 ssh-keygen.c ssh.1 ssh.c ssh_config] [sshconnect1.c sshconnect2.c sshd.8 sshd.c sshd_config ssh-dss.c] [ssh-dss.h ssh-rsa.c ssh-rsa.h dsa.c dsa.h] add support for RSA to SSH2. please test. there are now 3 types of keys: RSA1 is used by ssh-1 only, RSA and DSA are used by SSH2. you can use 'ssh-keygen -t rsa -f ssh2_rsa_file' to generate RSA keys for SSH2 and use the RSA keys for hostkeys or for user keys. SSH2 RSA or DSA keys are added to .ssh/authorised_keys2 as before. - (djm) Fix up Makefile and Redhat init script to create RSA host keys - (djm) Change to interim version - (djm) Fix RPM spec file stupidity - (djm) fixpaths to DSA and RSA keys too 20001112 - (bal) SCO Patch to add needed libraries for configure.in. Patch by Phillips Porch - (bal) IRIX patch to adding Job Limits. Patch by Denis Parker - (stevesk) pty.c: HP-UX 10 and 11 don't define TIOCSCTTY. Add error() to failed ioctl(TIOCSCTTY) call. 20001111 - (djm) Added /etc/primes for kex DH group neg, fixup Makefile.in and packaging files - (djm) Fix new Makefile.in warnings - (djm) Fix vsprintf("%h") in bsd-snprintf.c, short int va_args are promoted to type int. Report and fix from Dan Astoorian - (djm) Hardwire sysconfdir in RPM spec files as some RPM versions get it wrong. Report from Bennett Todd 20001110 - (bal) Fixed dropped answer from skey_keyinfo() in auth1.c - (bal) Changed from --with-skey to --with-skey=PATH in configure.in - (bal) Added in check to verify S/Key library is being detected in configure.in - (bal) next-posix.h - added another prototype wrapped in POSIX ifdef/endif. Patch by Mark Miller - (bal) Added 'util.h' header to loginrec.c only if HAVE_UTIL_H is defined to remove warnings under MacOS X. Patch by Mark Miller - (bal) Fixed LDFLAG mispelling in configure.in for --with-afs 20001107 - (bal) acconfig.in - removed the double "USE_PIPES" entry. Patch by Mark Miller - (bal) sshd.init files corrected to assign $? to RETVAL. Patch by Jarno Huuskonen - (bal) fixpaths fixed to stop it from quitely failing. Patch by Mark D. Roth 20001106 - (bal) typo in configure.in in regards to --with-ldflags from Marko Asplund - (bal) fixed next-posix.h. Forgot prototype of getppid(). -- | ``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 gem at rellim.com Tue Nov 14 13:10:10 2000 From: gem at rellim.com (Gary E. Miller) Date: Mon, 13 Nov 2000 18:10:10 -0800 (PST) Subject: New snapshot In-Reply-To: Message-ID: Yo Damien! First pass looks good on Slackware 7.0: 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: yes MD5 password support: yes 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/local/ssl/include Linker flags: -L/usr/local/ssl/lib -L/usr/local/ssl Libraries: -lnsl -lz -lutil -lcrypto -lwrap 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 Tue, 14 Nov 2000, Damien Miller wrote: > I have just uploaded a new snapshot to: > > http://www.mindrot.org/misc/openssh/openssh-SNAP-20001114.tar.gz > > This snapshot includes Markus Friedl's new SSH2 RSA authentication work > and -R portforwarding for SSH2. Please give these a good test. From bright at wintelcom.net Tue Nov 14 13:10:37 2000 From: bright at wintelcom.net (Alfred Perlstein) Date: Mon, 13 Nov 2000 18:10:37 -0800 Subject: Restricted agent. Message-ID: <20001113181037.Y11449@fw.wintelcom.net> I thought as a means of preventing ssh-agent hijacking by remote hosts one could have a local process communicating with the agent, simply by having a term open with this sort of dialog: agent-mon: on host foo.elite.com requesting agent forwarding for host bar.elite.com (fingerprint matches known_hosts) allow? [yes/no]: I know concepts presented along with patches are prefered, but I'm pretty occupied at the moment and wanted to know if such a system was feasable and/or desireable in order to protect against agent hijacking on remote hosts. I'm assuming one would need a "known_hosts" entry for 'bar' on the machine running the agent to make sure that it's not someone waiting for you to attempt to ssh to a trusted machine then hijacks the conversation. I'm not subscribed so be sure to CC' me on any flames. :) thanks, -- -Alfred Perlstein - [bright at wintelcom.net|alfred at freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." From gem at rellim.com Tue Nov 14 13:51:29 2000 From: gem at rellim.com (Gary E. Miller) Date: Mon, 13 Nov 2000 18:51:29 -0800 (PST) Subject: New snapshot In-Reply-To: Message-ID: Yo Damien! The new snap compiles OK on Unixware 7.1.0. Protocol 1 inbound and outbound seems OK. Protocol 2 outbound is OK, but protocol 2 inbound is still broken. Debug output like the last time I reported this. 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/catX PID file: /usr/local/etc Random number collection: Builtin (timeout 200) Manpage format: cat 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: no Host: i586-sco-sysv5uw7.1.0 Compiler: cc Compiler flags: -g -I. -I. -I/usr/local/include -I/usr/local/ssl/include Linker flags: -L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/ssl Libraries: -lsocket -lnsl -lz -lgen -lsocket -lcrypto I got these warnings on sshconnect2.c, none look important but should be fixed: UX:acomp: WARNING: "sshconnect2.c", line 521: argument is incompatible with prototype: arg #1 Is is packet_get_string(int) or packet_get_string(unsigned in)? UX:acomp: WARNING: "sshconnect2.c", line 655: argument is incompatible with prototype: arg #3 Is it: int key_to_blob(Key *key, unsigned char **blobp, unsigned int *lenp); or int key_to_blob(Key *key, unsigned char **blobp, int *lenp);? UX:acomp: WARNING: "sshconnect2.c", line 662: argument is incompatible with prototype: arg #2 Is it: void buffer_append(Buffer * buffer, const char *data, unsigned int len); or void buffer_append(Buffer * buffer, unsigned char *data, unsigned int len); UX:acomp: WARNING: "sshconnect2.c", line 680: argument is incompatible with prototype: arg #5 Is it: typedef int sign_cb_fn( Authctxt *authctxt, Key *key, unsigned char **sigp, int *lenp, unsigned char *data, int datalen); or: typedef int sign_cb_fn( Authctxt *authctxt, Key *key, unsigned char **sigp, int *lenp, char *data, int datalen); UX:acomp: WARNING: "sshconnect2.c", line 691: argument is incompatible with prototype: arg #2 buffer_append(0 again.... Other files had some warnings if you want to see them too just ask... 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 Tue, 14 Nov 2000, Damien Miller wrote: > I have just uploaded a new snapshot to: > > http://www.mindrot.org/misc/openssh/openssh-SNAP-20001114.tar.gz > > This snapshot includes Markus Friedl's new SSH2 RSA authentication work > and -R portforwarding for SSH2. Please give these a good test. From chenda at cs.unc.edu Tue Nov 14 15:25:27 2000 From: chenda at cs.unc.edu (Daniel T. Chen) Date: Mon, 13 Nov 2000 23:25:27 -0500 (EST) Subject: New snapshot In-Reply-To: Message-ID: Hey all, the latest snapshot configures, compiles, and runs fine on the x86 SuSE 6.3, 6.4, and 7.0 test machines (all OpenSSL-0.9.6). Host: i686-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: -ldl -lnsl -lz -lutil -lpam -lcrypto -lwrap dtc --- Daniel T. Chen | chenda at cs.unc.edu On Tue, 14 Nov 2000, Damien Miller wrote: > I have just uploaded a new snapshot to: > > http://www.mindrot.org/misc/openssh/openssh-SNAP-20001114.tar.gz > > This snapshot includes Markus Friedl's new SSH2 RSA authentication work > and -R portforwarding for SSH2. Please give these a good test. > > The new RSA authentications works similar to the current SSH2 DSA keys, > but requires a little modification to config files. Currently RSA > key cannot be shared between SSH1 and SSH2. > > To generate keys, ssh-keygen now has a type '-t' parameter. Valid types > are 'rsa1' (for SSH1 RSA keys), 'rsa' (SSH2 RSA) and 'dsa' (SSH2 DSA). > > eg. "ssh-keygen -t rsa -f ~/.ssh/id_rsa" will generate a new SSH2 RSA key. > > For public key authentication, just copy the public portion of the RSA > key into your ~/.ssh/authorized_keys2 file. It is normal for the public > RSA keys to be shorter than DSA keys. > > SSH2 RSA keys are fully supported by ssh-agent. Keys are tried in the order > in which they are added to the agent, so 'ssh-add' your RSA key first if > you want to try it out. > > For the server, all hostkeys are now unified and sshd will automatically > detect the type of a host key. The 'HostDSAKey' option is therefore > deprecated in favor of 'HostKey'. To specify RSA and DSA keys for SSH2 use, > just use more 'HostKey' options. The 'DSAAuthentication' option is > deprecated in favour of the general 'PubkeyAuthentication' option. > > The host key section of my sshd_config looks like this: > > HostKey /etc/ssh/ssh_host_key > HostKey /etc/ssh/ssh_host_rsa_key > HostKey /etc/ssh/ssh_host_dsa_key > > For the client, the 'IdentityFile2' option is deprecated in favor of an > autodetecting 'IdentityFile' option. You can specity rsa1, dsa and rsa keys > using this option. > > RSA pubkey auth seems a little quicker than DSA and it is not vulnerable to > the problems described in the WARNING.RNG file. > > Full changelog: > > 20001113 > - (djm) Add pointer to http://www.imasy.or.jp/~gotoh/connect.c to > contrib/README > - (djm) Merge OpenBSD changes: > - markus at cvs.openbsd.org 2000/11/06 16:04:56 > [channels.c channels.h clientloop.c nchan.c serverloop.c] > [session.c ssh.c] > agent forwarding and -R for ssh2, based on work from > jhuuskon at messi.uku.fi > - markus at cvs.openbsd.org 2000/11/06 16:13:27 > [ssh.c sshconnect.c sshd.c] > do not disabled rhosts(rsa) if server port > 1024; from > pekkas at netcore.fi > - markus at cvs.openbsd.org 2000/11/06 16:16:35 > [sshconnect.c] > downgrade client to 1.3 if server is 1.4; help from mdb at juniper.net > - markus at cvs.openbsd.org 2000/11/09 18:04:40 > [auth1.c] > typo; from mouring at pconline.com > - markus at cvs.openbsd.org 2000/11/12 12:03:28 > [ssh-agent.c] > off-by-one when removing a key from the agent > - markus at cvs.openbsd.org 2000/11/12 12:50:39 > [auth-rh-rsa.c auth2.c authfd.c authfd.h] > [authfile.c hostfile.c kex.c kex.h key.c key.h myproposal.h] > [readconf.c readconf.h rsa.c rsa.h servconf.c servconf.h ssh-add.c] > [ssh-agent.c ssh-keygen.1 ssh-keygen.c ssh.1 ssh.c ssh_config] > [sshconnect1.c sshconnect2.c sshd.8 sshd.c sshd_config ssh-dss.c] > [ssh-dss.h ssh-rsa.c ssh-rsa.h dsa.c dsa.h] > add support for RSA to SSH2. please test. > there are now 3 types of keys: RSA1 is used by ssh-1 only, > RSA and DSA are used by SSH2. > you can use 'ssh-keygen -t rsa -f ssh2_rsa_file' to generate RSA > keys for SSH2 and use the RSA keys for hostkeys or for user keys. > SSH2 RSA or DSA keys are added to .ssh/authorised_keys2 as before. > - (djm) Fix up Makefile and Redhat init script to create RSA host keys > - (djm) Change to interim version > - (djm) Fix RPM spec file stupidity > - (djm) fixpaths to DSA and RSA keys too > > 20001112 > - (bal) SCO Patch to add needed libraries for configure.in. Patch by > Phillips Porch > - (bal) IRIX patch to adding Job Limits. Patch by Denis Parker > > - (stevesk) pty.c: HP-UX 10 and 11 don't define TIOCSCTTY. Add error() to > failed ioctl(TIOCSCTTY) call. > > 20001111 > - (djm) Added /etc/primes for kex DH group neg, fixup Makefile.in and > packaging files > - (djm) Fix new Makefile.in warnings > - (djm) Fix vsprintf("%h") in bsd-snprintf.c, short int va_args are > promoted to type int. Report and fix from Dan Astoorian > > - (djm) Hardwire sysconfdir in RPM spec files as some RPM versions get > it wrong. Report from Bennett Todd > > 20001110 > - (bal) Fixed dropped answer from skey_keyinfo() in auth1.c > - (bal) Changed from --with-skey to --with-skey=PATH in configure.in > - (bal) Added in check to verify S/Key library is being detected in > configure.in > - (bal) next-posix.h - added another prototype wrapped in POSIX ifdef/endif. > Patch by Mark Miller > - (bal) Added 'util.h' header to loginrec.c only if HAVE_UTIL_H is defined > to remove warnings under MacOS X. Patch by Mark Miller > - (bal) Fixed LDFLAG mispelling in configure.in for --with-afs > > 20001107 > - (bal) acconfig.in - removed the double "USE_PIPES" entry. Patch by > Mark Miller > - (bal) sshd.init files corrected to assign $? to RETVAL. Patch by > Jarno Huuskonen > - (bal) fixpaths fixed to stop it from quitely failing. Patch by > Mark D. Roth > > 20001106 > - (bal) typo in configure.in in regards to --with-ldflags from Marko > Asplund > - (bal) fixed next-posix.h. Forgot prototype of getppid(). > > > > From mouring at etoh.eviladmin.org Tue Nov 14 16:49:10 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 13 Nov 2000 23:49:10 -0600 (CST) Subject: New snapshot In-Reply-To: Message-ID: Host: i686-pc-linux-gnu Compiler: gcc Compiler flags: -g -O2 -Wall -I. -I. -I/opt/openssl/include Linker flags: -L/opt/openssl/lib -L/opt/openssl Libraries: -ldl -lnsl -lz -lutil -lpam -lcrypto Compiles and works w/ both S/Key and standard on Redhat 7.0 (kgcc-1.1.2, not the nasty gcc-2.96). NeXT stuff will be tested in a day or so. - Ben From tim at multitalents.net Tue Nov 14 17:06:34 2000 From: tim at multitalents.net (Tim Rice) Date: Mon, 13 Nov 2000 22:06:34 -0800 (PST) Subject: New snapshot In-Reply-To: Message-ID: On Tue, 14 Nov 2000, Damien Miller wrote: > I have just uploaded a new snapshot to: > > http://www.mindrot.org/misc/openssh/openssh-SNAP-20001114.tar.gz > [snip] > > UnixWare 2.03, UnixWare 2.13, & SCO 5.0.4 get errors like ... /usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DEFAULT=\"/u sr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c ../openssh/bsd-arc4random.c UX:acomp: ERROR: "../openssh/defines.h", line 174: #error: "64 bit int type not found." gmake: *** [bsd-arc4random.o] Error 1 ... SCO 3.2v4.2 gets the following error ... gcc -g -O2 -Wall -I. -Isrc -Dftruncate=chsize -I/usr/local/include -I/usr/local/ ssl/include -DETCDIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DS SH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c src/b sd-realpath.c -o bsd-realpath.o src/bsd-realpath.c: In function `realpath': src/bsd-realpath.c:108: `MAXSYMLINKS' undeclared (first use this function) src/bsd-realpath.c:108: (Each undeclared identifier is reported only once src/bsd-realpath.c:108: for each function it appears in.) gmake: *** [bsd-realpath.o] Error 1 ... -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mouring at etoh.eviladmin.org Tue Nov 14 18:02:23 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 14 Nov 2000 01:02:23 -0600 (CST) Subject: New snapshot In-Reply-To: Message-ID: On Mon, 13 Nov 2000, Tim Rice wrote: > On Tue, 14 Nov 2000, Damien Miller wrote: > > > I have just uploaded a new snapshot to: > > > > http://www.mindrot.org/misc/openssh/openssh-SNAP-20001114.tar.gz > > > [snip] > > > > > UnixWare 2.03, UnixWare 2.13, & SCO 5.0.4 get errors like > ... > /usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DEFAULT=\"/u > sr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c ../openssh/bsd-arc4random.c > UX:acomp: ERROR: "../openssh/defines.h", line 174: #error: "64 bit int type not > found." > gmake: *** [bsd-arc4random.o] Error 1 > ... > Can not help here.. Sorry. > SCO 3.2v4.2 gets the following error > ... > gcc -g -O2 -Wall -I. -Isrc -Dftruncate=chsize -I/usr/local/include -I/usr/local/ > ssl/include -DETCDIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DS > SH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c src/b > sd-realpath.c -o bsd-realpath.o > src/bsd-realpath.c: In function `realpath': > src/bsd-realpath.c:108: `MAXSYMLINKS' undeclared (first use this function) > src/bsd-realpath.c:108: (Each undeclared identifier is reported only once > src/bsd-realpath.c:108: for each function it appears in.) > gmake: *** [bsd-realpath.o] Error 1 > ... > Try the attach patch. However please do a 'find /usr/includes -type f -print | xargs grep MAXSYMLINKS' for me and verify that SCO does not define this value somewhere else. - Ben -------------- next part -------------- --- ../openssh/bsd-realpath.c Sat Oct 14 19:17:36 2000 +++ bsd-realpath.c Tue Nov 14 00:55:44 2000 @@ -52,6 +52,13 @@ #endif /* + * MAXSYMLINKS + */ +#ifndef MAXSYMLINKS +#define MAXSYMLINKS 5 +#endif + +/* * char *realpath(const char *path, char resolved_path[MAXPATHLEN]); * * Find the real name of path, by removing all ".", ".." and symlink From pekkas at netcore.fi Tue Nov 14 18:08:14 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 14 Nov 2000 09:08:14 +0200 (EET) Subject: OpenSSH-2.3.0p1 - debug: no match: OpenSSH_2.3.0p1 In-Reply-To: <20001113163322.A17042@ucsd.edu> Message-ID: On Mon, 13 Nov 2000, John H. Robinson, IV wrote: > i just compiled OpenSSH-2.3.0p1 and replaced OpenSSH-2.2.0p1. > i noticed that OpenSSH-2.3.0p1 does not match itself in compat.c > the problem seems to be in line 65 of compat.c, > > { "^OpenSSH[-_]2\\.[012]", SSH_OLD_SESSIONID }, > > it looks like the regex needs to be expanded to include 3: > > { "^OpenSSH[-_]2\\.[0123]", SSH_OLD_SESSIONID }, > > not understanding the ramifications of such a change, i am loathe to > do it myself. I noticed that too; a warning is generated in verbose mode for that. I took it to mean that there are no bugs or incompatibilities with OpenSSH 2.3.0 <-> OpenSSH 2.3.0. As well as there shouldn't be! ;-) -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From sfrost at snowman.net Wed Nov 15 00:25:08 2000 From: sfrost at snowman.net (Stephen Frost) Date: Tue, 14 Nov 2000 08:25:08 -0500 Subject: [PATCH] Added option 'RetryDelay' Message-ID: <20001114082508.T5470@ns> 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. Stephen -------------- next part -------------- diff -u --recursive openssh-2.3.0p1/ChangeLog openssh-2.3.0p1-new/ChangeLog --- openssh-2.3.0p1/ChangeLog Sun Nov 5 22:17:38 2000 +++ openssh-2.3.0p1-new/ChangeLog Mon Nov 13 11:05:27 2000 @@ -1,3 +1,7 @@ +20001113 + - (spf) Made sleep(1) in sshconnect.c configureable wrt time + ("RetryDelay" option added) + 20001106 - (djm) Use Jim's new 1.0.3 askpass in Redhat RPMs - (djm) Manually fix up missed diff hunks (mainly RCS idents) diff -u --recursive openssh-2.3.0p1/readconf.c openssh-2.3.0p1-new/readconf.c --- openssh-2.3.0p1/readconf.c Sat Oct 14 01:23:12 2000 +++ openssh-2.3.0p1-new/readconf.c Mon Nov 13 11:06:57 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, oIdentityFile2, @@ -152,6 +152,7 @@ { "globalknownhostsfile2", oGlobalKnownHostsFile2 }, { "userknownhostsfile2", oUserKnownHostsFile2 }, { "connectionattempts", oConnectionAttempts }, + { "retrydelay", oRetryDelay }, { "batchmode", oBatchMode }, { "checkhostip", oCheckHostIP }, { "stricthostkeychecking", oStrictHostKeyChecking }, @@ -474,6 +475,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); @@ -687,6 +692,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; @@ -770,6 +776,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-2.3.0p1/readconf.h openssh-2.3.0p1-new/readconf.h --- openssh-2.3.0p1/readconf.h Sat Oct 14 01:23:12 2000 +++ openssh-2.3.0p1-new/readconf.h Tue Nov 14 08:01:33 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-2.3.0p1/ssh.0 openssh-2.3.0p1-new/ssh.0 --- openssh-2.3.0p1/ssh.0 Sun Nov 5 22:25:20 2000 +++ openssh-2.3.0p1-new/ssh.0 Tue Nov 14 07:54:28 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-2.3.0p1/ssh.1 openssh-2.3.0p1-new/ssh.1 --- openssh-2.3.0p1/ssh.1 Fri Oct 27 23:19:58 2000 +++ openssh-2.3.0p1-new/ssh.1 Tue Nov 14 07:55:25 2000 @@ -862,6 +862,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-2.3.0p1/ssh.c openssh-2.3.0p1-new/ssh.c --- openssh-2.3.0p1/ssh.c Fri Oct 27 23:19:58 2000 +++ openssh-2.3.0p1-new/ssh.c Tue Nov 14 07:59:56 2000 @@ -620,7 +620,7 @@ */ ok = ssh_connect(host, &hostaddr, options.port, - options.connection_attempts, + options.connection_attempts, options.retry_delay, !options.rhosts_authentication && !options.rhosts_rsa_authentication, original_real_uid, diff -u --recursive openssh-2.3.0p1/ssh.h openssh-2.3.0p1-new/ssh.h --- openssh-2.3.0p1/ssh.h Sat Oct 14 01:23:12 2000 +++ openssh-2.3.0p1-new/ssh.h Tue Nov 14 07:51:15 2000 @@ -321,11 +321,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-2.3.0p1/sshconnect.c openssh-2.3.0p1-new/sshconnect.c --- openssh-2.3.0p1/sshconnect.c Sat Sep 23 02:15:57 2000 +++ openssh-2.3.0p1-new/sshconnect.c Tue Nov 14 07:53:06 2000 @@ -180,14 +180,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) { @@ -284,7 +284,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/20001114/05360265/attachment.bin From douglas.manton at uk.ibm.com Wed Nov 15 01:51:24 2000 From: douglas.manton at uk.ibm.com (douglas.manton at uk.ibm.com) Date: Tue, 14 Nov 2000 14:51:24 +0000 Subject: [PATCH] AIX Password Ageing for OpenSSH-2.3.0p1 Message-ID: <80256997.00519E1E.00@d06mta05.portsmouth.uk.ibm.com> Please find attached a patch file to enable the following under AIX: - forced reset of expired passwords - feedback for failed logins following successful authentication (e.g. locked account, login times, failed login count) - failed login count incremented once after each unsuccessful login attempt (rather than once for after AUTH_FAIL_MAX attempts. If I set AIX to lock out after 5 attempts, I mean 5 -- not 15!) (See attached file: aix.patch) Best wishes, -------------------------------------------------------- Doug Manton, AT&T EMEA Firewall and Security Solutions E: demanton at att.com -------------------------------------------------------- "If privacy is outlawed, only outlaws will have privacy" -------------- next part -------------- A non-text attachment was scrubbed... Name: aix.patch Type: application/octet-stream Size: 6646 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001114/e84e64a4/attachment.obj From mstone at cs.loyola.edu Wed Nov 15 01:55:18 2000 From: mstone at cs.loyola.edu (Michael Stone) Date: Tue, 14 Nov 2000 09:55:18 -0500 Subject: New snapshot In-Reply-To: ; from djm@mindrot.org on Tue, Nov 14, 2000 at 12:15:04PM +1100 References: Message-ID: <20001114095518.O17700@justice.loyola.edu> The IRIX job limits patch will only build on IRIX >= 6.5.7. I hacked up configure to do the checking, but I'm not sure of the configure.in syntax. Does this look legal? *-*-irix6*) CFLAGS="$CFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS" PATH="$PATH:/usr/etc" MANTYPE='$(CATMAN)' AC_DEFINE(WITH_IRIX_ARRAY) AC_DEFINE(WITH_IRIX_PROJECT) AC_DEFINE(WITH_IRIX_AUDIT) IFS=.fm set `uname -r` if test $2 -ge 5 ; then set `uname -R` if test $3 -gt 5 -o $4 -gt 7 ; then AC_DEFINE(WITH_IRIX_JOBS) fi fi unset IFS no_libsocket=1 no_libnsl=1 AC_DEFINE(BROKEN_INET_NTOA) ;; I've also been meaning to send a patch to move the satsetid call to session.c. Attached. -- Mike Stone -------------- next part -------------- --- uidswap.c.orig Tue Nov 14 09:38:44 2000 +++ uidswap.c Tue Nov 14 09:42:53 2000 @@ -16,9 +16,6 @@ #include "ssh.h" #include "uidswap.h" -#ifdef WITH_IRIX_AUDIT -#include -#endif /* WITH_IRIX_AUDIT */ /* * Note: all these functions must work in all of the following cases: @@ -91,14 +88,6 @@ void permanently_set_uid(uid_t uid) { -#ifdef WITH_IRIX_AUDIT - if (sysconf(_SC_AUDIT)) { - debug("Setting sat id to %d", (int) uid); - if (satsetid(uid)) - debug("error setting satid: %.100s", strerror(errno)); - } -#endif /* WITH_IRIX_AUDIT */ - if (setuid(uid) < 0) debug("setuid %u: %.100s", (u_int) uid, strerror(errno)); } --- session.c.orig Tue Nov 14 09:38:20 2000 +++ session.c Tue Nov 14 09:43:15 2000 @@ -57,7 +57,10 @@ #endif /* WITH_IRIX_PROJECT */ #ifdef WITH_IRIX_JOBS #include -#endif +#endif +#ifdef WITH_IRIX_AUDIT +#include +#endif /* WITH_IRIX_AUDIT */ #if defined(HAVE_USERSEC_H) #include @@ -1104,7 +1107,6 @@ strerror(errno)); } # endif /* WITH_IRIX_JOBS */ - # ifdef WITH_IRIX_ARRAY /* initialize array session */ if (jid == 0) { @@ -1123,6 +1125,14 @@ fatal("Failed to initialize project %d for %s: %.100s", (int)projid, pw->pw_name, strerror(errno)); # endif /* WITH_IRIX_PROJECT */ +#ifdef WITH_IRIX_AUDIT + if (sysconf(_SC_AUDIT)) { + debug("Setting sat id to %d", (int) uid); + if (satsetid(uid)) + debug("error setting satid: %.100s", strerror(errno)); + } +#endif /* WITH_IRIX_AUDIT */ + /* Permanently switch to the desired uid. */ permanently_set_uid(pw->pw_uid); # endif /* HAVE_LOGIN_CAP */ From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Nov 15 02:20:18 2000 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 14 Nov 2000 16:20:18 +0100 Subject: New snapshot In-Reply-To: ; from djm@mindrot.org on Tue, Nov 14, 2000 at 12:15:04PM +1100 References: Message-ID: <20001114162018.A2565@ws01.aet.tu-cottbus.de> Hi! Host: hppa2.0-hp-hpux10.20 Compiler: cc Compiler flags: -O -I. -I. -Ae -D_HPUX_SOURCE +DAportable -I/usr/local/include -I/usr/local/ssl/include Linker flags: -L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/ssl Libraries: -lz -lsec -lcrypto -lwrap compiles fine and passes some short tests. I didn't toucht the new features. 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 Wed Nov 15 02:21:36 2000 From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl) Date: Tue, 14 Nov 2000 16:21:36 +0100 Subject: openssh-2.1.1p1: ssh-keygen.1 Message-ID: <3A11668A.30667.1C97107@localhost> The manual page for ssh-keygen hides option "-d" almost: It's not listed in the usual way: The options are as follows: -b bits Specifies the number of bits in the key to create. Minimum is 512 bits. Generally 1024 bits is considered sufficient, and key sizes above that no longer improve security but make things slow- er. The default is 1024 bits. -c Requests changing the comment in the private and public key files. The program will prompt for the file containing the pri- vate keys, for passphrase if the key has one, and for the new comment. -f Specifies the filename of the key file. ... Regards, Ulrich From jhriv at ucsd.edu Wed Nov 15 02:47:43 2000 From: jhriv at ucsd.edu (John H. Robinson, IV) Date: Tue, 14 Nov 2000 07:47:43 -0800 Subject: OpenSSH-2.3.0p1 - debug: no match: OpenSSH_2.3.0p1 In-Reply-To: ; from pekkas@netcore.fi on Tue, Nov 14, 2000 at 09:08:14AM +0200 References: <20001113163322.A17042@ucsd.edu> Message-ID: <20001114074743.A25594@ucsd.edu> On Tue, Nov 14, 2000 at 09:08:14AM +0200, Pekka Savola wrote: > On Mon, 13 Nov 2000, John H. Robinson, IV wrote: > > I noticed that too; a warning is generated in verbose mode for that. > > I took it to mean that there are no bugs or incompatibilities with OpenSSH > 2.3.0 <-> OpenSSH 2.3.0. As well as there shouldn't be! ;-) based upon your interpretation, i took a look at the source for compat.c in openssh-2.20p1 and 2.1.1p4, and i failed to notice any strings that match openssh at all. it seems to be limited to only the datafellows product. i can tell you why i got scared: i saw a new message in verbose that i had never seen before, and not understanding it, i went to the source. not understanding the source, i went to the list :) thank you for clearing that up for me. -john From amann at physik.tu-berlin.de Wed Nov 15 06:32:13 2000 From: amann at physik.tu-berlin.de (Andreas Amann) Date: Tue, 14 Nov 2000 20:32:13 +0100 Subject: logical path to current dir lost during login Message-ID: <14865.37693.48287.955520@bill.physik.TU-Berlin.DE> Hello, I use openssh-2.3.0p1 under linux-2.2.16 with standard settings and experience the following annoying problem: After I login the current directory is not set to the $HOME directory as expected, but to the _resolved_ path-name of the $HOME directory, where links and automounter dirs are expanded. To be specific, my $HOME is "/home/amann" but since /home is a link to the automounter directory /net/hservnlds/home/, my current working directory after login is "/tmp_mnt/hservnlds/home/amann". The reason for this is that sshd does not set the $PWD variable correctly. In order to fix this bug, I propose the following patch: diff -u ../../sb/openssh-2.3.0p1/session.c ./session.c --- ../../sb/openssh-2.3.0p1/session.c Sat Oct 28 05:19:58 2000 +++ ./session.c Tue Nov 14 16:07:54 2000 @@ -1293,6 +1293,8 @@ if (login_getcapbool(lc, "requirehome", 0)) exit(1); #endif + } else { + child_set_env(&env, &envsize, "PWD", pw->pw_dir); } /* Disclaimer: This patch fixes the problem for me. Since I am not at all familiar with security-critical programming, please check twice before you apply this patch. It might also be considered to set $PWD already before $HOME/.ssh/environment is read. (BTW, why is there no global /etc/environment file, I really miss it). CU, Andreas From jamesb-lists at alongtheway.com Wed Nov 15 06:55:55 2000 From: jamesb-lists at alongtheway.com (Jim Breton) Date: Tue, 14 Nov 2000 19:55:55 +0000 Subject: having some trouble using another user's RSA/DSA keys In-Reply-To: <20001113210844.H7859@folly>; from markus.friedl@informatik.uni-erlangen.de on Mon, Nov 13, 2000 at 09:08:44PM +0100 References: <2D00AD0E4D36D411BD300008C786E424229963@Denntex021.qwest.net> <20001025214650.T27161@alongtheway.com> <20001112211947.H21597@conflict.net> <20001113210844.H7859@folly> Message-ID: <20001114195555.W21597@alongtheway.com> On Mon, Nov 13, 2000 at 09:08:44PM +0100, Markus Friedl wrote: > i can confirm that from="blablabla" works with DSA keys in openssh-2.3.x Thanks. :) I am now running OpenSSH-2.3.0 and authenticating against an ssh.com server, however I believe there is some problem with the OpenSSH client code. The problem of the unnecessary warnings seems to have gone away with this release, but I still am unable to use someone else's key for authentication. If I use the following command line: root at tarkin:~# ssh -v -2 -l jamesb -i /home/jamesb/.ssh/id_dsa remotehost I would expect root to connect to "remotehost," as userid "jamesb," using jamesb's id_dsa key. However, take a look at this output: debug: authentications that can continue: publickey,password debug: next auth method to try is publickey debug: key does not exist: /root/.ssh/id_dsa ### this doesn't make sense! debug: next auth method to try is password jamesb at remotehost's password: Notice that it's still trying to use root's DSA key, despite my -i switch. If anyone knows a decent reason for this to happen please let me know. :) If I get time later I will also try this on my OpenBSD-2.8 snapshot box and see if it's an upstream problem as well. From djm at mindrot.org Wed Nov 15 07:21:11 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 15 Nov 2000 07:21:11 +1100 (EST) Subject: 2.3.0p1, Solaris 7 and last login (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, 14 Nov 2000 16:33:18 +0100 From: System Administrator To: openssh at openssh.com Subject: 2.3.0p1, Solaris 7 and last login Hi, I'm having a problem with sshd showing the wrong last login entry, that is, it shows the current login. I didn't notice it until recently, but it seems that it has been there since version 2.2.0p1. Some (more or less) useful stats here. I'm reporting the bug against: Version: portable OpenSSH 2.3.0p1 OS: Solaris 7 for Sparc w/ many recent recommended/security patches. Additional kernel module for /dev/[u]random support (from Andreas Maier, version 0.4) Configure command: ./configure --with-ipv4-default \ --with-ssl-dir=/usr/local/openssl-0.9.6 --with-random=/dev/urandom \ --prefix=/usr/local/openssh --sysconfdir=/etc/openssh \ --localstatedir=/var/run OpenSSL version: 0.9.6 Compiler: gcc 2.95.2 I've been looking around in the mailing list archive, and it seems that a problem with similar symptoms was fixed in 2.3.0p1, but unfortunately, this does not fix the problem for me. The fix in question was the removal of an erroneous call to write_login() which happened before getting the last login details. However, I found out that the call to do_pam_session(), which happens before the get_last_login_time() call, also writes a last login entry in my case. I made a workaround for the problem, but I'm sure it is not the way to do it. One good reason is that my patch does not take the result of do_login() into account and always prints the last login message. My patch is included in an attachment. Hope that I've been any help, Boi Ps. did I mention that in general, OpenSSH rocks? :) -- UNIX System Administrator - Boi Sletterink Phone: +31-15-278 2504 -------------- next part -------------- *** session.c.orig Sat Oct 28 05:19:58 2000 --- session.c Tue Nov 14 16:04:21 2000 *************** *** 590,600 **** --- 590,616 ---- int fdout, ptyfd, ttyfd, ptymaster; pid_t pid; + #define BOIS_DIRTY_PATCH + #ifdef BOIS_DIRTY_PATCH + char hostname[MAXHOSTNAMELEN]; + time_t last_login_time; + struct passwd * pw = s->pw; + char *time_string; + #endif + if (s == NULL) fatal("do_exec_pty: no session"); ptyfd = s->ptyfd; ttyfd = s->ttyfd; + #ifdef BOIS_DIRTY_PATCH + /* Get the time and hostname when the user last logged in. */ + hostname[0] = '\0'; + last_login_time = get_last_login_time(pw->pw_uid, pw->pw_name, + hostname, sizeof(hostname)); + #endif + + #ifdef USE_PAM do_pam_session(pw->pw_name, s->tty); do_pam_setcred(); *************** *** 628,634 **** --- 644,667 ---- /* record login, etc. similar to login(1) */ if (!(options.use_login && command == NULL)) + { + #ifdef BOIS_DIRTY_PATCH + if (last_login_time != 0) { + time_string = ctime(&last_login_time); + if (strchr(time_string, '\n')) + *strchr(time_string, '\n') = 0; + if (strcmp(hostname, "") == 0) + printf("Last login: %s\r\n", time_string); + else + printf("Last login: %s from %s\r\n", time_string, hostname); + } + else + { + printf("Never logged in before.\n"); + } + #endif do_login(s, command); + } /* Do common processing for the child, such as execing the command. */ do_child(command, pw, s->term, s->display, s->auth_proto, *************** *** 711,720 **** --- 744,755 ---- } } + #ifndef BOIS_DIRTY_PATCH /* Get the time and hostname when the user last logged in. */ hostname[0] = '\0'; last_login_time = get_last_login_time(pw->pw_uid, pw->pw_name, hostname, sizeof(hostname)); + #endif /* Record that there was a login on that tty from the remote host. */ record_login(pid, s->tty, pw->pw_name, pw->pw_uid, *************** *** 751,756 **** --- 786,792 ---- printf("%s\n", aixloginmsg); #endif /* WITH_AIXAUTHENTICATE */ + #ifndef BOIS_DIRTY_PATCH if (last_login_time != 0) { time_string = ctime(&last_login_time); if (strchr(time_string, '\n')) *************** *** 760,765 **** --- 796,803 ---- else printf("Last login: %s from %s\r\n", time_string, hostname); } + #endif + if (options.print_motd) { #ifdef HAVE_LOGIN_CAP f = fopen(login_getcapstr(lc, "welcome", "/etc/motd", From djm at mindrot.org Wed Nov 15 07:21:17 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 15 Nov 2000 07:21:17 +1100 (EST) Subject: 2.3.0p1 + Sco3.2v5.0.5 (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, 14 Nov 2000 22:00:41 +1000 From: Robert Brady To: openssh at openssh.com Subject: 2.3.0p1 + Sco3.2v5.0.5 Hi, I'm trying to build openssh 2.3.0p1 on sco openserver 5.0.5. configure is failing as shown below. Version 2.2.0p1 build and runs OK crow:~/openssh-2.3.0p1$./configure loading cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking host system type... i386-pc-sco3.2v5.0.5 checking how to run the C preprocessor... gcc -E checking for ranlib... : checking for a BSD compatible install... /usr/bin/X11/scoinst -c checking for ar... ar checking for perl... /usr/local/bin/perl checking for ent... no checking for filepriv... no checking for login... /bin/login checking for inline... inline checking for deflate in -lz... no configure: error: *** zlib missing - please install first *** crow:~/openssh-2.3.0p1$ ### config.log snip #####configure:1776: checking for deflate in -lz configure:1795: gcc -o conftest -g -O2 -Wall -I. -I. -I/usr/local/include -L/u sr/local/lib conftest.c -lz -lgen -lsocket -lprot -lx 1>&5 Undefined first referenced symbol in file setupterm /lib/libprot.so ceil /lib/libprot.so log /lib/libprot.so cur_term /lib/libprot.so reset_shell_mode /lib/libprot.so conftest: fatal error: Symbol referencing errors. No output written to conftest collect2: ld returned 1 exit status configure: failed program was: #line 1784 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char deflate(); int main() { deflate() ; return 0; } -- ================================================ Robert Brady robert at cfs.net.au ================================================ From gert at greenie.muc.de Wed Nov 15 07:49:41 2000 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 14 Nov 2000 21:49:41 +0100 Subject: New snapshot In-Reply-To: ; from Damien Miller on Tue, Nov 14, 2000 at 12:15:04PM +1100 References: Message-ID: <20001114214941.G3489@greenie.muc.de> Hi, On Tue, Nov 14, 2000 at 12:15:04PM +1100, Damien Miller wrote: > The new RSA authentications works similar to the current SSH2 DSA keys, > but requires a little modification to config files. Currently RSA > key cannot be shared between SSH1 and SSH2. Maybe I'm just a bit slow, maybe I just don't understand enough crypto stuff. What is this good for? We now have *three* different sorts of host keys. It most certainly confuses me, and I've worked with SSH for a long time now, so I'm sure it will confuse the hell out of "ordinary users". I can somewhat understand the RSA/DSA issue (RSA patent?) but having a third key, RSA again but incompatible to ssh1 makes this really confusing. Now if someone would stand up and say "oh, it's very easy, 2.4.0 will drop DSA keys (except for compatibility to ssh.com) and RSA 1 will be the same as RSA 2", I will be the first to shout "hooray!"... :-) 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 pekkas at netcore.fi Wed Nov 15 09:22:36 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 15 Nov 2000 00:22:36 +0200 (EET) Subject: New snapshot In-Reply-To: Message-ID: On Tue, 14 Nov 2000, Damien Miller wrote: Host: i386-redhat-linux-gnu Compiler: gcc Compiler flags: -O2 -m486 -fno-strength-reduce -Wall -I. -I. -I/usr/include Linker flags: -L/usr/lib -L/usr Libraries: -ldl -lnsl -lz -lutil -lpam -lcrypto -lwrap Seems to work on both RHL 6.2 and 7.0.. which was to be expected. Having to add HostKey's for both new keys or ssh2 gets disabled is rather irritating, but I guess it can't be avoided.. unless sshd would just try the defaults even though not specifically asked to (as with ssh_host_dsa_key, before) Apparently, defining extra HostKey's with previous versions is not harmful. Also, if such files are missing, that isn't even reported anywhere (well, probably in verbose mode..). In this snapshot there is an error "Could not load host key [...]" printed on screen, but I don't get it syslogged(?). Weird. A few compile warnings I came across -- don't look too harmful: --- bsd-bindresvport.c: In function `bindresvport_af': bsd-bindresvport.c:59: warning: `error' might be used uninitialized in this function auth-pam.c: In function `pamconv': auth-pam.c:105: warning: passing arg 1 of `read_passphrase' discards `const' from pointer target type pty.c: In function `pty_allocate': pty.c:55: warning: implicit declaration of function `openpty' session.c: In function `do_authenticated': session.c:217: warning: `type' might be used uninitialized in this function session.c:260: warning: `success' might be used uninitialized in this function --- -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From sen_ml at eccosys.com Wed Nov 15 12:56:25 2000 From: sen_ml at eccosys.com (sen_ml at eccosys.com) Date: Wed, 15 Nov 2000 10:56:25 +0900 (JST) Subject: New snapshot In-Reply-To: <20001114214941.G3489@greenie.muc.de> References: <20001114214941.G3489@greenie.muc.de> Message-ID: <20001115.105625.35035532.sen_ml@eccosys.com> From: Gert Doering Subject: Re: New snapshot Date: Tue, 14 Nov 2000 21:49:41 +0100 > I can somewhat understand the RSA/DSA issue (RSA patent?) but having a > third key, RSA again but incompatible to ssh1 makes this really confusing. iirc, no more rsa patent, so imo that's not the reason. i don't know the reason for a second type of rsa key. perhaps that has already been mentioned or will be touched upon. however, concerning multiple public key algorithm choice, consider the following scenario...one day you wake up to find that rsa algorithm has been broken. what are you going to do? oh look, we've also got the choice of using dsa. good thing we're able to use alternative algorithms in our protocol! ;-) From tim at multitalents.net Wed Nov 15 15:13:40 2000 From: tim at multitalents.net (Tim Rice) Date: Tue, 14 Nov 2000 20:13:40 -0800 (PST) Subject: 2.3.0p1 + Sco3.2v5.0.5 Message-ID: > ---------- Forwarded message ---------- > Date: Tue, 14 Nov 2000 22:00:41 +1000 > >From: Robert Brady > To: openssh at openssh.com > Subject: 2.3.0p1 + Sco3.2v5.0.5 > > Hi, > I'm trying to build openssh 2.3.0p1 on sco openserver 5.0.5. > configure is failing as shown below. > Version 2.2.0p1 build and runs OK > > crow:~/openssh-2.3.0p1$./configure > loading cache ./config.cache > checking for gcc... gcc > checking whether the C compiler (gcc ) works... yes > checking whether the C compiler (gcc ) is a cross-compiler... no > checking whether we are using GNU C... yes > checking whether gcc accepts -g... yes > checking host system type... i386-pc-sco3.2v5.0.5 > checking how to run the C preprocessor... gcc -E > checking for ranlib... : > checking for a BSD compatible install... /usr/bin/X11/scoinst -c > checking for ar... ar > checking for perl... /usr/local/bin/perl > checking for ent... no > checking for filepriv... no > checking for login... /bin/login > checking for inline... inline > checking for deflate in -lz... no > configure: error: *** zlib missing - please install first *** > crow:~/openssh-2.3.0p1$ Do you have the zlib libraries on your system? They do not come with Open Server 2.3.0p1 configures just fine on my Sco3.2v5.0.4 machine. But it won't compile because the SCO compiler doesn't support 64bit int. > > > ### config.log snip #####configure:1776: checking for deflate in -lz > configure:1795: gcc -o conftest -g -O2 -Wall -I. -I. > -I/usr/local/include -L/u > sr/local/lib conftest.c -lz -lgen -lsocket -lprot -lx 1>&5 > Undefined first referenced > symbol in file > setupterm /lib/libprot.so > ceil /lib/libprot.so > log /lib/libprot.so > cur_term /lib/libprot.so > reset_shell_mode /lib/libprot.so > conftest: fatal error: Symbol referencing errors. No output written to > conftest > collect2: ld returned 1 exit status > configure: failed program was: > #line 1784 "configure" > #include "confdefs.h" > /* Override any gcc2 internal prototype to avoid an error. */ > /* We use char because int might match the return type of a gcc2 > builtin and then its argument prototype would still apply. */ > char deflate(); > > int main() { > deflate() > ; return 0; } > > > -- > ================================================ > Robert Brady > robert at cfs.net.au > ================================================ > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From roth at feep.net Wed Nov 15 15:52:28 2000 From: roth at feep.net (Mark D. Roth) Date: Tue, 14 Nov 2000 22:52:28 -0600 Subject: Makefile objdirs patch Message-ID: <20001114225228.A1497@yorktown.isdn.uiuc.edu> I've attached a patch which fixes a minor Makefile glitch when building in a different directory than the source directory. The patch is relative to OpenSSH 2.3.0p1. Please let me know if you have any questions or problems. -- Mark D. Roth http://www.feep.net/~roth/ -------------- next part -------------- --- Makefile.in.orig Tue Nov 14 22:50:08 2000 +++ Makefile.in Tue Nov 14 22:48:48 2000 @@ -164,18 +164,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 "" ; \ + ./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 "" ; \ + ./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 "" + ./ssh-keygen -b 1024 -f $(DESTDIR)$(sysconfdir)/ssh_host_key -N "" + ./ssh-keygen -d -f $(DESTDIR)$(sysconfdir)/ssh_host_dsa_key -N "" uninstallall: uninstall -rm -f $(DESTDIR)$(sysconfdir)/ssh_config From gert at greenie.muc.de Wed Nov 15 18:09:39 2000 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 15 Nov 2000 08:09:39 +0100 Subject: New snapshot In-Reply-To: <20001115.105625.35035532.sen_ml@eccosys.com>; from sen_ml@eccosys.com on Wed, Nov 15, 2000 at 10:56:25AM +0900 References: <20001114214941.G3489@greenie.muc.de> <20001115.105625.35035532.sen_ml@eccosys.com> Message-ID: <20001115080939.A14222@greenie.muc.de> Hi, On Wed, Nov 15, 2000 at 10:56:25AM +0900, sen_ml at eccosys.com wrote: > > I can somewhat understand the RSA/DSA issue (RSA patent?) but having a > > third key, RSA again but incompatible to ssh1 makes this really confusing. > > iirc, no more rsa patent, so imo that's not the reason. i don't know > the reason for a second type of rsa key. perhaps that has already been > mentioned or will be touched upon. I hope so. > however, concerning multiple public key algorithm choice, consider the > following scenario...one day you wake up to find that rsa algorithm > has been broken. what are you going to do? oh look, we've also got > the choice of using dsa. good thing we're able to use alternative > algorithms in our protocol! ;-) Well, I have no problem with having a *choice* of adding a second key to enable another algorithm. My gripe is being *forced* to create multiple different host keys (or disable protocol 2). 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 djm at mindrot.org Wed Nov 15 19:16:28 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 15 Nov 2000 19:16:28 +1100 (EST) Subject: openssh-2.1.1p1: ssh-keygen.1 In-Reply-To: <3A11668A.30667.1C97107@localhost> Message-ID: On Tue, 14 Nov 2000, Ulrich Windl wrote: > The manual page for ssh-keygen hides option "-d" almost: It's not > listed in the usual way: It is deprecated in the snapshot 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 djm at mindrot.org Wed Nov 15 19:40:03 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 15 Nov 2000 19:40:03 +1100 (EST) Subject: New snapshot In-Reply-To: <20001115080939.A14222@greenie.muc.de> Message-ID: On Wed, 15 Nov 2000, Gert Doering wrote: > My gripe is being *forced* to create multiple different host keys (or > disable protocol 2). You are not forced to do anything. To enable protocol 2, you need either a SSH2 DSA key, a SSH2 RSA key or both. RSA has a couple of advantages over DSA: - Generating a DSA signature requires 160 bits of entropy (k), if these bits are ever recovered or guessed by an attacker, then they can be used to determine your private key[1]. - The keys are shorter (you don't need to ship parameters about with the key as you do with DSA) - Key generation is quicker (DSA parameter generation is slow and computationally intensive) - Verification of signatures (and thus authentication) can be an order of magnitude faster with RSA. Signing is a little slower. OpenSSL speaks best here: sign verify sign/s verify/s rsa 1024 bits 0.0165s 0.0009s 60.8 1138.9 dsa 1024 bits 0.0084s 0.0099s 118.7 101.1 Regards, Damien Miller [1] _Applied Cryptography_, Bruce Schneier, p. 492 -- | ``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 JSO at EUROPAY.COM Wed Nov 15 20:39:31 2000 From: JSO at EUROPAY.COM (=?iso-8859-1?Q?SOETE_Jo=EBl?=) Date: Wed, 15 Nov 2000 10:39:31 +0100 Subject: Openssh-2.3.0p1 protocol 2 problem Message-ID: Hi all, I just implemented (compiled from tarball) Openssh-2.3.0p1 on two different platform: an HP-UX 11.00 (the client) and a Redhat 6.2 (the server). On server (Linux RH-6.2) side the following compile options are considered: # CC="egcs" \ > ./configure \ > --prefix=/opt/openssh \ > --sysconfdir=/etc/opt/openssh \ > --with-tcp-wrappers \ > --with-ipv4-default \ > --with-ssl-dir=/opt/openssl \ > --disable-gnome-askpass OpenSSH configured has been configured with the following options. User binaries: /opt/openssh/bin User binaries: /opt/openssh/bin System binaries: /opt/openssh/sbin Configuration files: /etc/opt/openssh Askpass program: /opt/openssh/libexec/ssh-askpass Manual pages: /opt/openssh/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: no TCP Wrappers support: yes MD5 password support: no IP address in $DISPLAY hack: no Use IPv4 by default hack: yes Translate v4 in v6 hack: yes Host: i586-pc-linux-gnu Compiler: egcs Compiler flags: -O3 -funroll-loops -ffast-math -malign-double -mcpu=pentium -march=pentium -fomit-frame-pointer -fforce-mem -fforce-addr -fno-exceptions -Wall -I. -I. -I/opt/openssl/include Linker flags: -L/opt/openssl/lib -L/opt/openssl Libraries: -ldl -lnsl -lz -lutil -lpam -lcrypto -lwrap and the server sshd_config file is: # This is ssh server systemwide configuration file. Port 22 Protocol 2,1 ListenAddress 0.0.0.0 #ListenAddress :: HostKey /etc/opt/openssh/ssh_host_key ServerKeyBits 1024 LoginGraceTime 600 KeyRegenerationInterval 3600 PermitRootLogin no # # Don't read ~/.rhosts and ~/.shosts files IgnoreRhosts yes # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication IgnoreUserKnownHosts yes StrictModes yes X11Forwarding no X11DisplayOffset 10 PrintMotd yes KeepAlive yes # Logging SyslogFacility AUTH LogLevel INFO #obsoletes QuietMode and FascistLogging RhostsAuthentication no # # For this to work you will also need host keys in /etc/opt/openssh/ssh_known_hosts RhostsRSAAuthentication no # RSAAuthentication yes # To disable tunneled clear text passwords, change to no here! PasswordAuthentication yes PermitEmptyPasswords no # Uncomment to disable s/key passwords #SkeyAuthentication no #KbdInteractiveAuthentication yes # To change Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #AFSTokenPassing no #KerberosTicketCleanup no # Kerberos TGT Passing does only work with the AFS kaserver #KerberosTgtPassing yes CheckMail no #UseLogin no # Uncomment if you want to enable sftp #Subsystem sftp /opt/openssh/libexec/sftp-server #MaxStartups 10:30:60 On client (HP-UX 11.00) the following compile options were foreseen: ./configure --prefix=/opt/openssh \ --sysconfdir=/etc/opt/openssh \ --localstatedir=/var/opt/openssh \ --without-pam --without-shadow \ --with-egd-pool=/etc/egd/entropy \ --with-ssl-dir=/opt/openssl \ --disable-gnome-askpass OpenSSH configured has been configured with the following options. User binaries: /opt/openssh/bin User binaries: /opt/openssh/bin System binaries: /opt/openssh/sbin Configuration files: /etc/opt/openssh Askpass program: /opt/openssh/libexec/ssh-askpass Manual pages: /opt/openssh/man/catX PID file: /var/run Random number collection: EGD (/etc/egd/entropy) Manpage format: cat PAM support: disabled KerberosIV support: no AFS support: no S/KEY support: no TCP Wrappers support: no MD5 password support: no IP address in $DISPLAY hack: yes Use IPv4 by default hack: no Translate v4 in v6 hack: no Host: hppa1.1-hp-hpux11.00 Compiler: gcc Compiler flags: -O2 -I/opt/zlib/include -Wall -I. -I. -D_HPUX_SOURCE -I/opt/openssl/include Linker flags: -L/opt/zlib/lib -L/opt/openssl/lib -L/opt/openssl Libraries: -lnsl -lz -lsec -lcrypto and the client ssh_config file is: # This is ssh client systemwide configuration file. This file provides # defaults for users, and the values can be changed in per-user configuration # files or on the command line. # Configuration data is parsed as follows: # 1. command line options # 2. user-specific file # 3. system-wide file # Any configuration value is only changed the first time it is set. # Thus, host-specific definitions should be at the beginning of the # configuration file, and defaults at the end. # Site-wide defaults for various options Host * ForwardAgent no ForwardX11 no RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication yes PasswordAuthentication yes FallBackToRsh no UseRsh no BatchMode no CheckHostIP yes StrictHostKeyChecking no IdentityFile ~/.ssh/identity Port 22 # Protocol 2,1 Cipher blowfish EscapeChar ~ # Debug Log LogLevel DEBUG Well everything works fine with protocol 1 but failed with protocol 2. And here is some debug info: [client] > ssh -v -2 me at server # being login as user "me" SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090600f). debug: Reading configuration data /etc/opt/openssh/ssh_config debug: Applying options for * debug: ssh_connect: getuid 375 geteuid 0 anon 1 debug: Connecting to wslin [172.16.250.170] port 22. 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 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-group-exchange-sha1,diffie-hellman-group1-sha1 debug: got kexinit: ssh-dss debug: got kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,r ijndael128-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,r ijndael128-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 blowfish-cbc hmac-sha1 none debug: kex: client->server blowfish-cbc hmac-sha1 none debug: Sending SSH2_MSG_KEX_DH_GEX_REQUEST. debug: Wait SSH2_MSG_KEX_DH_GEX_GROUP. 2f 65 74 63 2f 6f 70 74 Disconnecting: Bad packet length 795178083. debug: Calling cleanup 0x40009332(0x0) NOTES: As I change default configuration files I do regenerate server keys with make host-key-force as well as I generate user ("me") keys after those changes. I used openssl-0.9.6 ssl libraries with compile options: client > ./Configure hpux-parisc-gcc -D_REENTRANT --prefix=/opt/openssl --openssldir=/etc/opt/openssl server > ./Configure linux-elf --prefix=/opt/openssl --openssldir=/etc/opt/openssl no-asm no-shared. Is somebody as some idea regarding this problem? Thanks in advance for help, Joel NB: which ftp client could be used with sftp_server? ********************************************************************** This e-mail and any attachments to it may contain confidential information which is strictly intended for the use of the authorised recipient. If you have received this e-mail in error, please delete it and notify the sender by replying to this e-mail. Thank you for your co-operation. ********************************************************************** From jhuuskon at messi.uku.fi Wed Nov 15 20:46:11 2000 From: jhuuskon at messi.uku.fi (Jarno Huuskonen) Date: Wed, 15 Nov 2000 11:46:11 +0200 Subject: having some trouble using another user's RSA/DSA keys In-Reply-To: <20001114195555.W21597@alongtheway.com>; from jamesb-lists@alongtheway.com on Tue, Nov 14, 2000 at 07:55:55PM +0000 References: <2D00AD0E4D36D411BD300008C786E424229963@Denntex021.qwest.net> <20001025214650.T27161@alongtheway.com> <20001112211947.H21597@conflict.net> <20001113210844.H7859@folly> <20001114195555.W21597@alongtheway.com> Message-ID: <20001115114611.A23665@laivuri63.uku.fi> On Tue, Nov 14, Jim Breton wrote: > Thanks. :) I am now running OpenSSH-2.3.0 and authenticating against > an ssh.com server, however I believe there is some problem with the > OpenSSH client code. The problem of the unnecessary warnings seems to > have gone away with this release, but I still am unable to use someone > else's key for authentication. > > If I use the following command line: > > root at tarkin:~# ssh -v -2 -l jamesb -i /home/jamesb/.ssh/id_dsa remotehost > > I would expect root to connect to "remotehost," as userid "jamesb," > using jamesb's id_dsa key. AFAIK the -i option works only for protocol 1 (it says rsa-keys in ssh man page). I think as a workaround you could use -o "IdentityFile2 /home/jamesb/.ssh/id_dsa" (Hmm, after testing ssh complains that the id_dsa has bad ownership or bad mode(0600)...) -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 aspa at kronodoc.fi Thu Nov 16 00:57:51 2000 From: aspa at kronodoc.fi (Marko Asplund) Date: Wed, 15 Nov 2000 15:57:51 +0200 (EET) Subject: ssh command & valid cipher names In-Reply-To: Message-ID: On Fri, 10 Nov 2000, Marko Asplund wrote: > i thought that it would be useful to make ssh command to print valid > cipher names in case an unknown cipher has been specified by the user for > example the command 'ssh -c list' would print: > > Unknown cipher type 'list' > valid cipher names: none, des, 3des, blowfish, 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 regarding the issue of cipher selection, shouldn't there be a mechanism for sys admins to enforce site security policy by being able to choose the ciphers which sshd allows clients to use? for example i'd like to disallow clients connecting with ciphers none and des to our ssh servers. -- aspa From preining at logic.at Thu Nov 16 01:03:44 2000 From: preining at logic.at (Norbert Preining) Date: Wed, 15 Nov 2000 15:03:44 +0100 Subject: openssh directory permissions bug or feature? Message-ID: <20001115150344.A31607@alpha.logic.tuwien.ac.at> [please Cc: to me since I am not subscribed to the list] Dear Security gurus! I have installed openssh-2.3.0p1 on a lan and want to allow various users to log in as user staff on the server machine, the users are sitting on diskless clients. (All linux) But: RhostRSAAuthentication only works when the PARENT directory of the home-directory of the user to whom we want to log on is at least world executable. I.e. if we have server:/home/maingroup permissions 750 and server:/home/maingroup/staff And server:/home/maingroup/staff/.rhost foo.domain.org preining and from preining at client: ssh -l staff server Then the RhostsRSAAuthentication fails and I have to type in the passwd. BUT when I change th epermissions of server:/home/maingroup from 750 to 751 it is working well. I think that this must be because the sshd changes to uid nobody most of the times, and only when accessing various sysfiles it changes to root and back. Is this a bug? or a feature? Because we have reasons to have the permissions set to 750. Best wishes Norbert Preining -- ciao norb +-------------------------------------------------------------------+ | Norbert Preining http://www.logic.at/people/preining | | University of Technology Vienna, Austria preining at logic.at | | DSA: 0x09C5B094 (RSA: 0xCF1FA165) mail subject: get [DSA|RSA]-key | +-------------------------------------------------------------------+ From john at jhorne.csd.plymouth.ac.uk Thu Nov 16 01:31:02 2000 From: john at jhorne.csd.plymouth.ac.uk (John Horne) Date: Wed, 15 Nov 2000 14:31:02 -0000 (GMT) Subject: [PATCH]: nchan.c : internal error: we do not read, but chan_read Message-ID: Attached is the patch I've been using to fix the error message seen in the subject line. It seems (!) to have caused no problems with the previous openssh snapshot version openssh-SNAP-20001016, 2.3.0p1 and the latest snapshot (openssh-SNAP-20001114). The patch adds 3 lines to nchan.c in a switch stmt (line 100). It simply caters for the cases where the input channel state is CHAN_INPUT_WAIT_DRAIN or CHAN_INPUT_CLOSED. In these cases it simply exits (breaks) from the switch stmt. This seems to be necessary now because an earlier fix caused nchan to be called twice when closing a session. The first time is okay, but the second (with the channel now in one of the above states) causes the error message. 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 -------------- next part -------------- *** nchan.c.orig Wed Nov 15 12:50:04 2000 --- nchan.c Wed Nov 15 12:53:17 2000 *************** *** 98,103 **** --- 98,106 ---- { debug("channel %d: read failed", c->self); switch (c->istate) { + case CHAN_INPUT_WAIT_DRAIN: + case CHAN_INPUT_CLOSED: + break; case CHAN_INPUT_OPEN: debug("channel %d: input open -> drain", c->self); chan_shutdown_read(c); From res at shore.net Thu Nov 16 03:49:11 2000 From: res at shore.net (Richard E. Silverman) Date: Wed, 15 Nov 2000 11:49:11 -0500 (EST) Subject: Openssh-2.3.0p1 protocol 2 problem In-Reply-To: Message-ID: > Disconnecting: Bad packet length 795178083. This usually happens because something injects garbage into the protocol stream. For instance, it typically happens when people use sftp but have a remote shell startup file that prints text to stdout even on non-interactive logins. The text gets interpreted by the sftp client as part of a packet. This doesn't usually happen when starting a remote shell. However, notice: 795178083 decimal = 2F657463 hex = 2F 65 74 63 = "/etc" in ASCII This too much of a coincidence. Are you starting sshd from inetd? Maybe sshd is dying suddenly with an error message that's getting into the protocol stream (this would be a bug). > NB: which ftp client could be used with sftp_server? Any of the sftp clients, e.g. the command-line one with ssh.com-2.3.0, or in the ssh.com or F-Secure Windows clients. -- Richard Silverman slade at shore.net From JSO at EUROPAY.COM Thu Nov 16 05:15:56 2000 From: JSO at EUROPAY.COM (=?iso-8859-1?Q?SOETE_Jo=EBl?=) Date: Wed, 15 Nov 2000 19:15:56 +0100 Subject: Openssh-2.3.0p1 protocol 2 problem Message-ID: Hi all again, In the mean time I do additional test. It works now if I do not launch server sshd with inetd. Hopping this experience could be helpful, Joel > -----Original Message----- > From: SOETE Jo?l > Sent: Wednesday, November 15, 2000 10:40 AM > To: 'openssh-unix-dev at mindrot.org' > Subject: Openssh-2.3.0p1 protocol 2 problem > > Hi all, > > I just implemented (compiled from tarball) Openssh-2.3.0p1 on > two different platform: an HP-UX 11.00 (the client) and a > Redhat 6.2 (the server). > ... > > Well everything works fine with protocol 1 but failed with protocol 2. > And here is some debug info: > > [client] > ssh -v -2 me at server # being login as user "me" > SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. ... > Disconnecting: Bad packet length 795178083. > > Thanks in advance for help, > Joel > > NB: which ftp client could be used with sftp_server? > > ********************************************************************** This e-mail and any attachments to it may contain confidential information which is strictly intended for the use of the authorised recipient. If you have received this e-mail in error, please delete it and notify the sender by replying to this e-mail. Thank you for your co-operation. ********************************************************************** From markus.friedl at informatik.uni-erlangen.de Wed Nov 15 11:08:49 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 15 Nov 2000 01:08:49 +0100 Subject: logical path to current dir lost during login In-Reply-To: <14865.37693.48287.955520@bill.physik.TU-Berlin.DE>; from amann@physik.tu-berlin.de on Tue, Nov 14, 2000 at 08:32:13PM +0100 References: <14865.37693.48287.955520@bill.physik.TU-Berlin.DE> Message-ID: <20001115010848.A23459@folly> IMHO, setting $PWD is the job of the shell. there are even some shells that do not need $PWD nor care about symlinks. On Tue, Nov 14, 2000 at 08:32:13PM +0100, Andreas Amann wrote: > Hello, > > I use openssh-2.3.0p1 under linux-2.2.16 with standard settings and > experience the following annoying problem: After I login the current > directory is not set to the $HOME directory as expected, but to the > _resolved_ path-name of the $HOME directory, where links and > automounter dirs are expanded. To be specific, my $HOME is > "/home/amann" but since /home is a link to the automounter directory > /net/hservnlds/home/, my current working directory after login is > "/tmp_mnt/hservnlds/home/amann". The reason for this is that sshd does > not set the $PWD variable correctly. > > In order to fix this bug, I propose the following patch: > > diff -u ../../sb/openssh-2.3.0p1/session.c ./session.c > --- ../../sb/openssh-2.3.0p1/session.c Sat Oct 28 05:19:58 2000 > +++ ./session.c Tue Nov 14 16:07:54 2000 > @@ -1293,6 +1293,8 @@ > if (login_getcapbool(lc, "requirehome", 0)) > exit(1); > #endif > + } else { > + child_set_env(&env, &envsize, "PWD", pw->pw_dir); > } > > /* > > > > Disclaimer: This patch fixes the problem for me. Since I am not at all > familiar with security-critical programming, please check twice > before you apply this patch. It might also be considered to set $PWD > already before $HOME/.ssh/environment is read. > (BTW, why is there no global /etc/environment file, I really miss it). > > > > CU, > > Andreas > From mstone at cs.loyola.edu Thu Nov 16 06:14:27 2000 From: mstone at cs.loyola.edu (Michael Stone) Date: Wed, 15 Nov 2000 14:14:27 -0500 Subject: New snapshot In-Reply-To: <20001114095518.O17700@justice.loyola.edu>; from mstone@cs.loyola.edu on Tue, Nov 14, 2000 at 09:55:18AM -0500 References: <20001114095518.O17700@justice.loyola.edu> Message-ID: <20001115141427.Q17700@justice.loyola.edu> Wrong patch for moving WITH_IRIX_AUDIT to session.c. This one should work. -- Mike Stone -------------- next part -------------- --- uidswap.c.orig Tue Nov 14 09:38:44 2000 +++ uidswap.c Tue Nov 14 09:42:53 2000 @@ -16,9 +16,6 @@ #include "ssh.h" #include "uidswap.h" -#ifdef WITH_IRIX_AUDIT -#include -#endif /* WITH_IRIX_AUDIT */ /* * Note: all these functions must work in all of the following cases: @@ -91,14 +88,6 @@ void permanently_set_uid(uid_t uid) { -#ifdef WITH_IRIX_AUDIT - if (sysconf(_SC_AUDIT)) { - debug("Setting sat id to %d", (int) uid); - if (satsetid(uid)) - debug("error setting satid: %.100s", strerror(errno)); - } -#endif /* WITH_IRIX_AUDIT */ - if (setuid(uid) < 0) debug("setuid %u: %.100s", (u_int) uid, strerror(errno)); } --- session.c.orig Tue Nov 14 09:38:20 2000 +++ session.c Tue Nov 14 09:43:15 2000 @@ -57,7 +57,10 @@ #endif /* WITH_IRIX_PROJECT */ #ifdef WITH_IRIX_JOBS #include -#endif +#endif +#ifdef WITH_IRIX_AUDIT +#include +#endif /* WITH_IRIX_AUDIT */ #if defined(HAVE_USERSEC_H) #include @@ -1104,7 +1107,6 @@ strerror(errno)); } # endif /* WITH_IRIX_JOBS */ - # ifdef WITH_IRIX_ARRAY /* initialize array session */ if (jid == 0) { @@ -1123,6 +1125,14 @@ fatal("Failed to initialize project %d for %s: %.100s", (int)projid, pw->pw_name, strerror(errno)); # endif /* WITH_IRIX_PROJECT */ +#ifdef WITH_IRIX_AUDIT + if (sysconf(_SC_AUDIT)) { + debug("Setting sat id to %d", (int) pw->pw_uid); + if (satsetid(pw->pw_uid)) + debug("error setting satid: %.100s", strerror(errno)); + } +#endif /* WITH_IRIX_AUDIT */ + /* Permanently switch to the desired uid. */ permanently_set_uid(pw->pw_uid); # endif /* HAVE_LOGIN_CAP */ From markus.friedl at informatik.uni-erlangen.de Thu Nov 16 06:19:06 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 15 Nov 2000 20:19:06 +0100 Subject: New snapshot In-Reply-To: ; from djm@mindrot.org on Wed, Nov 15, 2000 at 07:40:03PM +1100 References: <20001115080939.A14222@greenie.muc.de> Message-ID: <20001115201906.E4511@folly> On Wed, Nov 15, 2000 at 07:40:03PM +1100, Damien Miller wrote: > - Verification of signatures (and thus authentication) can be an order > of magnitude faster with RSA. Signing is a little slower. OpenSSL > speaks best here: note also that DSA signatures need randomness for _every_ sign operation. -m From markus.friedl at informatik.uni-erlangen.de Thu Nov 16 06:20:04 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 15 Nov 2000 20:20:04 +0100 Subject: New snapshot In-Reply-To: <20001114214941.G3489@greenie.muc.de>; from gert@greenie.muc.de on Tue, Nov 14, 2000 at 09:49:41PM +0100 References: <20001114214941.G3489@greenie.muc.de> Message-ID: <20001115202004.F4511@folly> On Tue, Nov 14, 2000 at 09:49:41PM +0100, Gert Doering wrote: > I can somewhat understand the RSA/DSA issue (RSA patent?) but having a > third key, RSA again but incompatible to ssh1 makes this really confusing. RSA keys are used for different operations in SSH1 vs. SSH2 (encrypt vs. sign) and you should _not_ use the same key for both operations. -m From markus.friedl at informatik.uni-erlangen.de Thu Nov 16 06:21:24 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 15 Nov 2000 20:21:24 +0100 Subject: having some trouble using another user's RSA/DSA keys In-Reply-To: <20001115114611.A23665@laivuri63.uku.fi>; from jhuuskon@messi.uku.fi on Wed, Nov 15, 2000 at 11:46:11AM +0200 References: <2D00AD0E4D36D411BD300008C786E424229963@Denntex021.qwest.net> <20001025214650.T27161@alongtheway.com> <20001112211947.H21597@conflict.net> <20001113210844.H7859@folly> <20001114195555.W21597@alongtheway.com> <20001115114611.A23665@laivuri63.uku.fi> Message-ID: <20001115202124.G4511@folly> On Wed, Nov 15, 2000 at 11:46:11AM +0200, Jarno Huuskonen wrote: > AFAIK the -i option works only for protocol 1 (it says rsa-keys in ssh > man page). > > I think as a workaround you could use > -o "IdentityFile2 /home/jamesb/.ssh/id_dsa" -i should work for all types of keys in the recent snapshot, and IdentityFile2 is deprecated. From markus.friedl at informatik.uni-erlangen.de Thu Nov 16 06:28:02 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 15 Nov 2000 20:28:02 +0100 Subject: ssh command & valid cipher names In-Reply-To: ; from aspa@kronodoc.fi on Wed, Nov 15, 2000 at 03:57:51PM +0200 References: Message-ID: <20001115202802.H4511@folly> On Wed, Nov 15, 2000 at 03:57:51PM +0200, Marko Asplund wrote: > On Fri, 10 Nov 2000, Marko Asplund wrote: > > > i thought that it would be useful to make ssh command to print valid > > cipher names in case an unknown cipher has been specified by the user for > > example the command 'ssh -c list' would print: > > > > Unknown cipher type 'list' > > valid cipher names: none, des, 3des, blowfish, 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 > > regarding the issue of cipher selection, shouldn't there be a mechanism > for sys admins to enforce site security policy by being able to choose the > ciphers which sshd allows clients to use? for example i'd like to disallow > clients connecting with ciphers none and des to our ssh servers. use Ciphers in sshd_config. this applies to SSH-2, only. note also that the cipher 'none' is only valid for encrypting host keys. 'des' is only available to the client in SSH-1 (e.g. if you connect to cisco machines). -m From markus.friedl at informatik.uni-erlangen.de Thu Nov 16 06:30:55 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 15 Nov 2000 20:30:55 +0100 Subject: Openssh-2.3.0p1 protocol 2 problem In-Reply-To: ; from JSO@EUROPAY.COM on Wed, Nov 15, 2000 at 07:15:56PM +0100 References: Message-ID: <20001115203055.I4511@folly> On Wed, Nov 15, 2000 at 07:15:56PM +0100, SOETE Jo?l wrote: > Hi all again, > > In the mean time I do additional test. It works now if I do not launch > server sshd with inetd. > > Hopping this experience could be helpful, does sshd start from inetd.conf if you do touch /etc/primes ? From amann at physik.tu-berlin.de Thu Nov 16 06:46:11 2000 From: amann at physik.tu-berlin.de (Andreas Amann) Date: Wed, 15 Nov 2000 20:46:11 +0100 Subject: logical path to current dir lost during login In-Reply-To: <20001115010848.A23459@folly> References: <14865.37693.48287.955520@bill.physik.TU-Berlin.DE> <20001115010848.A23459@folly> Message-ID: <14866.59395.890787.101860@bill.physik.TU-Berlin.DE> Markus Friedl writes: > IMHO, setting $PWD is the job of the shell. > > there are even some shells that do not need $PWD nor > care about symlinks. > >From "man 3 getcwd" (man-pages-1.31.): If the environment variable PWD is set, and its value is correct, then that value will be returned. IMHO, that means that any program, that changes the current working directory should also update $PWD, so that it?s child processes can make a proper getcwd() call. Otherwise the child will not be able to recover the logical path of the current working directory, but only the resolved path, which is usually not what they want, especially when using automounting fs. Note that $PWD is not a shell-specific, but a glibc specific variable. Since the shell does usually not change the working directory at startup, it is not its task to set or change $PWD (how should it know the correct value anyway, if not via $PWD from its parent?) -- Andreas Amann Institut fuer theoretische Physik, TU Berlin From gert at greenie.muc.de Thu Nov 16 08:21:43 2000 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 15 Nov 2000 22:21:43 +0100 Subject: New snapshot In-Reply-To: <20001115202004.F4511@folly>; from Markus Friedl on Wed, Nov 15, 2000 at 08:20:04PM +0100 References: <20001114214941.G3489@greenie.muc.de> <20001115202004.F4511@folly> Message-ID: <20001115222143.B28997@greenie.muc.de> Hi, On Wed, Nov 15, 2000 at 08:20:04PM +0100, Markus Friedl wrote: > On Tue, Nov 14, 2000 at 09:49:41PM +0100, Gert Doering wrote: > > I can somewhat understand the RSA/DSA issue (RSA patent?) but having a > > third key, RSA again but incompatible to ssh1 makes this really confusing. > > RSA keys are used for different operations in SSH1 vs. SSH2 (encrypt > vs. sign) and you should _not_ use the same key for both operations. Hmmm. How does ssh1 signature operations? (I'm asking because I'm curious). 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 Thu Nov 16 09:02:06 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 15 Nov 2000 23:02:06 +0100 Subject: Port forwarding on Solaris 8 remains broken in openssh-2.3.0p1 (fwd) Message-ID: <20001115230206.F4547@folly> -------------- next part -------------- An embedded message was scrubbed... From: Joe Rhett Subject: Port forwarding on Solaris 8 remains broken in openssh-2.3.0p1 Date: Sun, 12 Nov 2000 16:51:24 -0800 Size: 5666 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001115/bb8e3971/attachment.mht From mouring at etoh.eviladmin.org Thu Nov 16 14:43:33 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 15 Nov 2000 21:43:33 -0600 (CST) Subject: Makefile objdirs patch In-Reply-To: <20001114225228.A1497@yorktown.isdn.uiuc.edu> Message-ID: Applied. On Tue, 14 Nov 2000, Mark D. Roth wrote: > I've attached a patch which fixes a minor Makefile glitch when > building in a different directory than the source directory. The > patch is relative to OpenSSH 2.3.0p1. > > Please let me know if you have any questions or problems. > > From JSO at EUROPAY.COM Thu Nov 16 17:38:34 2000 From: JSO at EUROPAY.COM (=?iso-8859-1?Q?SOETE_Jo=EBl?=) Date: Thu, 16 Nov 2000 07:38:34 +0100 Subject: Openssh-2.3.0p1 protocol 2 problem Message-ID: Hello Markus, You have right, it start from inetd if I "touch" (in this my case) '/etc/opt/openssh/primes'. Thanks a lot, Joel Markus Friedl wrote: >does sshd start from inetd.conf if you do > touch /etc/primes >? ********************************************************************** This e-mail and any attachments to it may contain confidential information which is strictly intended for the use of the authorised recipient. If you have received this e-mail in error, please delete it and notify the sender by replying to this e-mail. Thank you for your co-operation. ********************************************************************** From JSO at EUROPAY.COM Thu Nov 16 18:37:23 2000 From: JSO at EUROPAY.COM (=?iso-8859-1?Q?SOETE_Jo=EBl?=) Date: Thu, 16 Nov 2000 08:37:23 +0100 Subject: OpenSSH-2.2.0p1 + SecurID. Message-ID: Hello Theo, > > > Could you let me know where this test patch would be available. > > > > Try: > > http://www.omniti.com/~jesus/SecurID/ > > > > -- Regarding your patch, did you continue the integration (mainly: Handle PIN creation and changing ...)? Do you foreseen to transport it in new release 2.3.0p1? Kind regards, Joel ********************************************************************** This e-mail and any attachments to it may contain confidential information which is strictly intended for the use of the authorised recipient. If you have received this e-mail in error, please delete it and notify the sender by replying to this e-mail. Thank you for your co-operation. ********************************************************************** From ETARDIEU at CPR.FR Thu Nov 16 21:52:17 2000 From: ETARDIEU at CPR.FR (TARDIEU Emmanuel) Date: Thu, 16 Nov 2000 11:52:17 +0100 Subject: ssh.com and openssh Message-ID: <5BF932D2CD05D211B54800805FE60FEB08F529C4@serv-hermes.systeme.cpr.fr> Things are looking great : sftp server is included in openssh 2.3.0p1, and it works quite well with ssh.com winNT client. So, we are going to move our ssh.com sshd to openssh sshd, which should be a major leap to more stability (inifinite loops in sshd 2.0.13 were definitely going on everyone's nerves...). Short of adding comments to the authorized_keys2 file, is there a way to extratct the names of the ssh.com dsa keys that were used to create the file ? Or is it just not implemented in the ssh2 protocol ? We have a lot of keys to convert, and I must say the multi files system used by ssh.com (identity, authorization, foobar.pub) was easier to script and check. Regards, Emmanuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001116/2b56eef9/attachment.html From Ulrich.Windl at rz.uni-regensburg.de Thu Nov 16 22:36:09 2000 From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl) Date: Thu, 16 Nov 2000 12:36:09 +0100 Subject: HP-UX 11.00: baudrate set to 300 Baud Message-ID: <3A13D4B4.25926.FCAFD5@localhost> Hello, GNU Emacs suffers from poor performance because the baud rate in HP-UX 11.00 is set to 300 baud when connecting via OpenSSH 2.1.1p1. Can anybody tell why? Maybe ssh should modify some termio bits when logging in? Regards, Ulrich From Bianca.Koller at infineon.com Thu Nov 16 22:47:39 2000 From: Bianca.Koller at infineon.com (Koller Bianca (ISS ITO R)) Date: Thu, 16 Nov 2000 12:47:39 +0100 Subject: openssh zlib error Message-ID: hi all, my system: hpux 10.20 zlib 1.1.3 -> /opt/zlib openssl-0.9.6 ->/opt/openssl added LD_LIBRARY_PATH /opt/zlib added PATH /opt/zlib try to configure openssh ./configure --prefix=/opt/openssh --with-ssl-dir=/opt/openssl Error: zlib missing Where can i specify the path where zlib is installed? regards Koller Bianca From Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Nov 16 23:01:28 2000 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Thu, 16 Nov 2000 13:01:28 +0100 Subject: openssh zlib error In-Reply-To: ; from Bianca.Koller@infineon.com on Thu, Nov 16, 2000 at 12:47:39PM +0100 References: Message-ID: <20001116130128.A23858@ws01.aet.tu-cottbus.de> This should make it into the FAQ as it is asked every other day... On Thu, Nov 16, 2000 at 12:47:39PM +0100, Koller Bianca (ISS ITO R) wrote: > hi all, > > my system: > > hpux 10.20 > zlib 1.1.3 -> /opt/zlib > openssl-0.9.6 ->/opt/openssl > > added LD_LIBRARY_PATH /opt/zlib LD_LIBRARY_PATH has no meaning on HP-UX 10.20 (only in 11.xx 64bit mode). > added PATH /opt/zlib PATH influences the search for executables, not libraries. > try to configure openssh > > ./configure --prefix=/opt/openssh --with-ssl-dir=/opt/openssl > > > Error: zlib missing > > > Where can i specify the path where zlib is installed? CPPFLAGS="/opt/zlib/include" LDFLAGS="-L/opt/zlib/lib" ./configure ... or use the flags provided by configure, see ./configure --help 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 vinschen at redhat.com Thu Nov 16 23:58:44 2000 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 16 Nov 2000 13:58:44 +0100 Subject: New snapshot References: Message-ID: <3A13DA04.D0304805@redhat.com> Damien Miller wrote: > I have just uploaded a new snapshot to: > > http://www.mindrot.org/misc/openssh/openssh-SNAP-20001114.tar.gz > > This snapshot includes Markus Friedl's new SSH2 RSA authentication work > and -R portforwarding for SSH2. Please give these a good test. Host: i686-pc-cygwin Compiler: gcc Compiler flags: -g -O2 -Wall -I. -I. -I/usr/include Linker flags: -L/usr/lib -L/usr Libraries: -lz -lregex /usr/lib/textmode.o -lcrypto Works OOTB. SSH2 RSA works. I have a problem with sftp-server (this isn't related to the current snapshot but to 2.3.0p1 as well). As long as the user doesn't call `cd' on the sftp commandline for the first time, a call to `pwd' returns an error "PWD failed". After `cd' is called, that problem disappears. I have tracked that down to the point that in sftp-server.c, function process_realpath() the line path = get_string(NULL); returns an empty string as long as no `cd' is called. This results in an error in the following call to realpath(). I'm not sure how to solve that problem except for a hack like `if (!*path) path = ".";' but the base problem is somewhere else. I tried that by using sftp on ssh.com 2.3.0 [i686-pc-linux-gnu]. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin at sources.redhat.com Red Hat, Inc. mailto:vinschen at redhat.com From Stephan.Hendl at lds.brandenburg.de Fri Nov 17 00:06:10 2000 From: Stephan.Hendl at lds.brandenburg.de (Stephan Hendl) Date: Thu, 16 Nov 2000 14:06:10 +0100 Subject: Antw: openssh zlib error Message-ID: hi, either copy the files from /opt/zlib/lib to /usr/lib and /opt/zlib/include to /usr/include, respectively or create some links. That is not fine but it works. I am interestet in a general solution too. 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 >>> "Koller Bianca (ISS ITO R)" 16.11.2000 12:47:39 >>> hi all, my system: hpux 10.20 zlib 1.1.3 -> /opt/zlib openssl-0.9.6 ->/opt/openssl added LD_LIBRARY_PATH /opt/zlib added PATH /opt/zlib try to configure openssh ./configure --prefix=/opt/openssh --with-ssl-dir=/opt/openssl Error: zlib missing Where can i specify the path where zlib is installed? regards Koller Bianca From Philippe.WILLEM at urssaf.fr Fri Nov 17 00:15:18 2000 From: Philippe.WILLEM at urssaf.fr (Philippe WILLEM) Date: Thu, 16 Nov 2000 14:15:18 +0100 Subject: =?iso-8859-1?Q?R=E9f._:_Antw:_openssh_zlib_error?= Message-ID: <41256999.00496336.00@contact31.cirso.fr> ./configure --prefix=$RUN_SSH --with-ldflags=-L$PATH_ZLIB --with-ssl-dir=$PATH_SSL --with-cflags="-I$PATH_ZLIB_INCLUDE" "Stephan Hendl" sur 16/11/2000 14:06:10 Pour : openssh-unix-dev at mindrot.org cc : (ccc : Philippe WILLEM/CER59/REC) Objet : Antw: openssh zlib error hi, either copy the files from /opt/zlib/lib to /usr/lib and /opt/zlib/include to /usr/include, respectively or create some links. That is not fine but it works. I am interestet in a general solution too. 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 >>> "Koller Bianca (ISS ITO R)" 16.11.2000 12:47:39 >>> hi all, my system: hpux 10.20 zlib 1.1.3 -> /opt/zlib openssl-0.9.6 ->/opt/openssl added LD_LIBRARY_PATH /opt/zlib added PATH /opt/zlib try to configure openssh ./configure --prefix=/opt/openssh --with-ssl-dir=/opt/openssl Error: zlib missing Where can i specify the path where zlib is installed? regards Koller Bianca From naddy at mips.inka.de Fri Nov 17 03:24:16 2000 From: naddy at mips.inka.de (Christian Weisgerber) Date: Thu, 16 Nov 2000 16:24:16 +0000 (UTC) Subject: New snapshot References: <20001115080939.A14222@greenie.muc.de> Message-ID: <8v11ng$748$1@kemoauc.mips.inka.de> Damien Miller wrote: > - Key generation is quicker (DSA parameter generation is slow and > computationally intensive) > > - Verification of signatures (and thus authentication) can be an order > of magnitude faster with RSA. Signing is a little slower. FWIW, I have SSH2/RSA up and running on two OpenBSD boxes, and it appears to work fine. Unfortunately, SSH2 connection setup is still unusably slow on slower machines. For some reason I always tend to have some old machines at hand. One of my current toys is a Cyrix 486DX2-66 box that may yet end up as a console server. Starting up an SSH2 connection to that machine takes forever. From "ssh -v", the computationally intensive part is here: ... 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: 1037/2049 debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. debug: Got SSH2_MSG_KEXDH_REPLY. ... Those "Wait..." bits take more than a minute each. -- Christian "naddy" Weisgerber naddy at mips.inka.de From theos at cnds.jhu.edu Fri Nov 17 04:12:00 2000 From: theos at cnds.jhu.edu (Theo E. Schlossnagle) Date: Thu, 16 Nov 2000 12:12:00 -0500 Subject: OpenSSH-2.2.0p1 + SecurID. References: Message-ID: <3A141560.F864128F@cnds.jhu.edu> SOETE Jo?l wrote: > > > > Could you let me know where this test patch would be available. > > > > > > http://www.omniti.com/~jesus/SecurID/ > > Regarding your patch, did you continue the integration (mainly: Handle PIN > creation and changing ...)? Actually, I have set up users to "log" directly into the SecurID server for that one. Of course their log in fails after they update/create their PIN -- becuase the shell is non-existent. I don't see any problems with adding creation in, it is just clunky, because you have to run ssh -v to see the interaction -- I didn't see any other way to do this. So, the answer is "no, I didn't finish with the integration." > Do you foreseen to transport it in new release 2.3.0p1? I would like to to just build it on top of the keyboard-interactive mode that, but most of our client run ssh-1.2.27 and not openssh, so it makes it hard. I will eventually port it to 2.3.0p1 -- but patch patches are welcome :-) I imagine making what I have right now work on 2.3.0p1 would be only a few minutes of work. I'll post back once I have those few minutes and actually make the changes and test it. -- 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 JSO at EUROPAY.COM Fri Nov 17 04:25:24 2000 From: JSO at EUROPAY.COM (=?iso-8859-1?Q?SOETE_Jo=EBl?=) Date: Thu, 16 Nov 2000 18:25:24 +0100 Subject: OpenSSH-2.2.0p1 + SecurID. Message-ID: Thanks for info Theo and will advise of my progress. But do not promise anything because, as you, I do not have much time to work on. Regards, Joel > -----Original Message----- > From: Theo E. Schlossnagle [mailto:theos at cnds.jhu.edu] > Sent: Thursday, November 16, 2000 6:12 PM > To: SOETE Jo?l > Cc: openssh-unix-dev at mindrot.org > Subject: Re: OpenSSH-2.2.0p1 + SecurID. > > > SOETE Jo?l wrote: > > > > > Could you let me know where this test patch would be > available. > > > > > > > > http://www.omniti.com/~jesus/SecurID/ > > > > Regarding your patch, did you continue the integration > (mainly: Handle PIN > > creation and changing ...)? > > Actually, I have set up users to "log" directly into the > SecurID server for > that one. Of course their log in fails after they > update/create their PIN -- > becuase the shell is non-existent. > > I don't see any problems with adding creation in, it is just > clunky, because > you have to run ssh -v to see the interaction -- I didn't see > any other way to > do this. > > So, the answer is "no, I didn't finish with the integration." > > > Do you foreseen to transport it in new release 2.3.0p1? > > I would like to to just build it on top of the > keyboard-interactive mode that, > but most of our client run ssh-1.2.27 and not openssh, so it > makes it hard. I > will eventually port it to 2.3.0p1 -- but patch patches are > welcome :-) I > imagine making what I have right now work on 2.3.0p1 would be > only a few > minutes of work. I'll post back once I have those few > minutes and actually > make the changes and test it. > > -- > 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 > ********************************************************************** This e-mail and any attachments to it may contain confidential information which is strictly intended for the use of the authorised recipient. If you have received this e-mail in error, please delete it and notify the sender by replying to this e-mail. Thank you for your co-operation. ********************************************************************** From markus.friedl at informatik.uni-erlangen.de Fri Nov 17 04:59:21 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 16 Nov 2000 18:59:21 +0100 Subject: New snapshot In-Reply-To: <8v11ng$748$1@kemoauc.mips.inka.de>; from naddy@mips.inka.de on Thu, Nov 16, 2000 at 04:24:16PM +0000 References: <20001115080939.A14222@greenie.muc.de> <8v11ng$748$1@kemoauc.mips.inka.de> Message-ID: <20001116185921.A13@folly> On Thu, Nov 16, 2000 at 04:24:16PM +0000, Christian Weisgerber wrote: > Damien Miller wrote: > > > - Key generation is quicker (DSA parameter generation is slow and > > computationally intensive) > > > > - Verification of signatures (and thus authentication) can be an order > > of magnitude faster with RSA. Signing is a little slower. > > FWIW, I have SSH2/RSA up and running on two OpenBSD boxes, and it > appears to work fine. > > Unfortunately, SSH2 connection setup is still unusably slow on > slower machines. For some reason I always tend to have some old > machines at hand. One of my current toys is a Cyrix 486DX2-66 box > that may yet end up as a console server. Starting up an SSH2 > connection to that machine takes forever. From "ssh -v", the > computationally intensive part is here: just remove /etc/primes and try again... From markus.friedl at informatik.uni-erlangen.de Fri Nov 17 05:01:25 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 16 Nov 2000 19:01:25 +0100 Subject: ssh.com and openssh In-Reply-To: <5BF932D2CD05D211B54800805FE60FEB08F529C4@serv-hermes.systeme.cpr.fr>; from ETARDIEU@CPR.FR on Thu, Nov 16, 2000 at 11:52:17AM +0100 References: <5BF932D2CD05D211B54800805FE60FEB08F529C4@serv-hermes.systeme.cpr.fr> Message-ID: <20001116190125.B13@folly> On Thu, Nov 16, 2000 at 11:52:17AM +0100, TARDIEU Emmanuel wrote: > Short of adding comments to the authorized_keys2 file, is there a way to > extratct the names of the ssh.com dsa keys that were used to create the file > ? Or is it just not implemented in the ssh2 protocol ? sorry, comments are not supported for ssh2-keys in openssh. who want's to give it a try? -markus From markus.friedl at informatik.uni-erlangen.de Fri Nov 17 05:05:29 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 16 Nov 2000 19:05:29 +0100 Subject: New snapshot In-Reply-To: <20001115222143.B28997@greenie.muc.de>; from gert@greenie.muc.de on Wed, Nov 15, 2000 at 10:21:43PM +0100 References: <20001114214941.G3489@greenie.muc.de> <20001115202004.F4511@folly> <20001115222143.B28997@greenie.muc.de> Message-ID: <20001116190529.D13@folly> On Wed, Nov 15, 2000 at 10:21:43PM +0100, Gert Doering wrote: > Hi, > > On Wed, Nov 15, 2000 at 08:20:04PM +0100, Markus Friedl wrote: > > On Tue, Nov 14, 2000 at 09:49:41PM +0100, Gert Doering wrote: > > > I can somewhat understand the RSA/DSA issue (RSA patent?) but having a > > > third key, RSA again but incompatible to ssh1 makes this really confusing. > > > > RSA keys are used for different operations in SSH1 vs. SSH2 (encrypt > > vs. sign) and you should _not_ use the same key for both operations. > > Hmmm. How does ssh1 signature operations? (I'm asking because I'm > curious). SSH1 does encryption with RSA keys, there are no signature operations in SSH1. basically, the client generated a random session key. this key is encrypted with both the host and the server key and sent back to the client. in SSH2 the private keys (DSA or RSA) are used to sign a value derived from the session id. so it's encryption vs. signing with the same keys. From naddy at mips.inka.de Fri Nov 17 06:14:24 2000 From: naddy at mips.inka.de (Christian Weisgerber) Date: Thu, 16 Nov 2000 19:14:24 +0000 (UTC) Subject: New snapshot References: <20001115080939.A14222@greenie.muc.de> <8v11ng$748$1@kemoauc.mips.inka.de> <20001116185921.A13@folly> Message-ID: <8v1bmg$gte$1@kemoauc.mips.inka.de> Markus Friedl wrote: > > Unfortunately, SSH2 connection setup is still unusably slow on > > slower machines. [...] > > just remove /etc/primes and try again... What is this file? It's not documented in sshd(8)--nor OpenBSD's man pages in general. Anyway, I did, and the situation improved. From "ssh -v" I gather that whatever this Diffie-Hellman Group Exchange exchanges is down from 2048 to 1024 bits, resulting in a connection setup time of 25+ seconds. (Still a pain for practical use, of course. Protocol 1 takes about five seconds.) -- Christian "naddy" Weisgerber naddy at mips.inka.de From jphollan at earthlink.net Fri Nov 17 07:48:12 2000 From: jphollan at earthlink.net (Jason Holland) Date: Thu, 16 Nov 2000 14:48:12 -0600 Subject: Strange channel 0 error Message-ID: hello, i'm getting a very strange error in my system logs. maybe someone can help out. the server is an hp-ux 11.00 box, running openssh 2.3.0p1, and the client is a redhat 6.2 box running the same version. running 'ssh -l root espage ls' from the hp box to the linux box yields this jem in the syslog. Nov 16 14:41:49 espage sshd[23974]: error: channel 0: internal error: we do not read, but chan_read_failed for istate 8 making that connection is slow, 45 seconds to get the output from the above command. from the linux box to the hp box, there is no problem. is this error related to the slowdown?? or are they 2 seperate beasts?? any clues. i appreciate the help! Jason From rob at hagopian.net Fri Nov 17 09:43:21 2000 From: rob at hagopian.net (Rob Hagopian) Date: Thu, 16 Nov 2000 17:43:21 -0500 (EST) Subject: Strange channel 0 error In-Reply-To: Message-ID: The chan_read_failed has been discussed here recently, but I haven't heard a solution (or even a full description of the cause) yet... It shouldn't affect connection speed though, I get tons of them and haven't noticed any real problems (like slow connections)... -Rob On Thu, 16 Nov 2000, Jason Holland wrote: > hello, > i'm getting a very strange error in my system logs. maybe someone can > help out. the server is an hp-ux 11.00 box, running openssh 2.3.0p1, and > the client is a redhat 6.2 box running the same version. running 'ssh -l > root espage ls' from the hp box to the linux box yields this jem in the > syslog. > > Nov 16 14:41:49 espage sshd[23974]: error: channel 0: internal error: we do > not read, but chan_read_failed for istate 8 > > making that connection is slow, 45 seconds to get the output from the above > command. from the linux box to the hp box, there is no problem. is this > error related to the slowdown?? or are they 2 seperate beasts?? any clues. > i appreciate the help! > > Jason > > From vinschen at redhat.com Fri Nov 17 10:20:01 2000 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 17 Nov 2000 00:20:01 +0100 Subject: Makefile objdirs patch References: Message-ID: <3A146BA1.9B7B1FC@redhat.com> mouring at etoh.eviladmin.org wrote: > > Applied. > > On Tue, 14 Nov 2000, Mark D. Roth wrote: > > > I've attached a patch which fixes a minor Makefile glitch when > > building in a different directory than the source directory. The > > patch is relative to OpenSSH 2.3.0p1. The Makefile.in of the current snapshot openssh-SNAP-20001114 has one more glitch when installing `primes'. Patch attached. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin at sources.redhat.com Red Hat, Inc. mailto:vinschen at redhat.com -------------- next part -------------- Index: Makefile.in =================================================================== RCS file: /src/cvsroot/openssh-20001114/Makefile.in,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Makefile.in --- Makefile.in 2000/11/16 12:12:57 1.1.1.1 +++ Makefile.in 2000/11/16 23:15:30 @@ -169,7 +169,7 @@ install-files: fi ; \ fi if [ ! -f $(DESTDIR)$(sysconfdir)/primes ]; then \ - $(INSTALL) -m 644 primes $(DESTDIR)$(sysconfdir)/primes; \ + $(INSTALL) -m 644 $(srcdir)/primes $(DESTDIR)$(sysconfdir)/primes; \ else \ echo "$(DESTDIR)$(sysconfdir)/primes already exists, install will not overwrite"; \ fi From marya at st.jip.co.jp Fri Nov 17 14:33:15 2000 From: marya at st.jip.co.jp (Shinichi Maruyama) Date: Fri, 17 Nov 2000 12:33:15 +0900 (JST) Subject: setproctitle Message-ID: <20001117.123315.97297755.marya@st.jip.co.jp> I use openssh-2.3.0p1 in FreeBSD 4.X? In config.h, HAVE_SETPROCTITLE is defined, but ignored in bsd-setproctitle.c. Patch attached. -- marya at st.jip.co.jp -------------- next part -------------- --- bsd-setproctitle.c.orig Wed Oct 18 22:11:44 2000 +++ bsd-setproctitle.c Thu Nov 16 23:53:20 2000 @@ -38,9 +38,9 @@ static char rcsid[] = "$OpenBSD: setproctitle.c,v 1.7 1999/02/25 22:10:12 art Exp $"; #endif /* LIBC_SCCS and not lint */ -#ifndef HAVE_SETPROCTITLE - #include "includes.h" + +#ifndef HAVE_SETPROCTITLE #define SPT_NONE 0 #define SPT_PSTAT 1 From mouring at etoh.eviladmin.org Fri Nov 17 15:44:56 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 16 Nov 2000 22:44:56 -0600 (CST) Subject: setproctitle In-Reply-To: <20001117.123315.97297755.marya@st.jip.co.jp> Message-ID: Thanks. Applied. - Ben On Fri, 17 Nov 2000, Shinichi Maruyama wrote: > I use openssh-2.3.0p1 in FreeBSD 4.X$B!#(B > In config.h, HAVE_SETPROCTITLE is defined, but ignored in > bsd-setproctitle.c. > Patch attached. > > From mouring at etoh.eviladmin.org Fri Nov 17 16:02:51 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 16 Nov 2000 23:02:51 -0600 (CST) Subject: To Do list... Message-ID: This is just portable todo list. From the sounds of it Markus has his own to do list. But can everyone review and let me know if there is anything missing from this list. (Note.. I'm not looking for 'SSH should support XYZ feature.' unless it's directly related to portability.) Or if there is anything on this list that has been completed. (Namely Tru64 SIA support?) Thanks. -Ben Programming: - Replacement for setproctitle() - HP/UX support only currently - Improve PAM support (a pam_lastlog module will cause sshd to exit) - Complete Tru64 SIA support Documentation: - More and better - Install FAQ? - General FAQ on S/Key, TIS, RSA, RSA2, DSA, etc and suggestions on when it would be best to use them. - Create a Documentation/ directory? Clean up configure/makefiles: - Clean up configure.in - There are a few double #defined variables left to do. HAVE_LOGIN is one of them. Consider NOT looking for information in wtmpx or utmpx or any of that stuff if it's not detected from the start - Replace the whole u_intXX_t evilness in acconfig.h with something better??? - Move all "openbsd-compat" files to it's own directory. Consider doing the same with libssh. I don't think we need to split ssh, sshd, etc into their own directory. From roth at feep.net Fri Nov 17 15:22:53 2000 From: roth at feep.net (Mark D. Roth) Date: Thu, 16 Nov 2000 22:22:53 -0600 Subject: To Do list... In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Nov 16, 2000 at 11:02:51PM -0600 References: Message-ID: <20001116222253.A2271@yorktown.isdn.uiuc.edu> On Thu Nov 16 23:02 2000 -0600, mouring at etoh.eviladmin.org wrote: > Clean up configure/makefiles: > - Clean up configure.in - There are a few double #defined variables > left to do. HAVE_LOGIN is one of them. Consider NOT looking for information > in wtmpx or utmpx or any of that stuff if it's not detected from the start > - Replace the whole u_intXX_t evilness in acconfig.h with something better??? > - Move all "openbsd-compat" files to it's own directory. Consider doing the > same with libssh. I don't think we need to split ssh, sshd, etc into their > own directory. This is a fairly minor point, but it would be nice if the Makefile did all of the manpage substitution stuff in the default target, so that it didn't have to write any files to the build directory during "make install". The reason for this is that if you build as a non-root user on an NFS-mounted filesystem which was not exported with root access, and then you become root to do the "make install", it will fail if it needs to write files to the build directory. -- Mark D. Roth http://www.feep.net/~roth/ From gert at greenie.muc.de Fri Nov 17 18:35:40 2000 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 17 Nov 2000 08:35:40 +0100 Subject: New snapshot In-Reply-To: <20001116190529.D13@folly>; from Markus Friedl on Thu, Nov 16, 2000 at 07:05:29PM +0100 References: <20001114214941.G3489@greenie.muc.de> <20001115202004.F4511@folly> <20001115222143.B28997@greenie.muc.de> <20001116190529.D13@folly> Message-ID: <20001117083540.B25763@greenie.muc.de> Hi, On Thu, Nov 16, 2000 at 07:05:29PM +0100, Markus Friedl wrote: > > Hmmm. How does ssh1 signature operations? (I'm asking because I'm > > curious). > > SSH1 does encryption with RSA keys, there are no signature > operations in SSH1. basically, the client generated > a random session key. this key is encrypted with both the > host and the server key and sent back to the client. > > in SSH2 the private keys (DSA or RSA) are used to sign > a value derived from the session id. Thanks for explaining. > so it's encryption vs. signing with the same keys. Could anyone send me a pointer where to read up why this is "bad"? I know (mostly) how public key crypto works, but haven't yet understood these small bits - I've seen that a few people have separate PGP keys for "sign" and "crypt", but didn't understnad that either. 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 Fri Nov 17 20:27:31 2000 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 17 Nov 2000 10:27:31 +0100 Subject: To Do list... References: Message-ID: <3A14FA03.809313CF@redhat.com> mouring at etoh.eviladmin.org wrote: > Clean up configure/makefiles: > - Clean up configure.in - There are a few double #defined variables > left to do. HAVE_LOGIN is one of them. Consider NOT looking for information > in wtmpx or utmpx or any of that stuff if it's not detected from the start - configure.in fails to configure correctly when trying a cross build. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin at sources.redhat.com Red Hat, Inc. mailto:vinschen at redhat.com From J.Horne at plymouth.ac.uk Fri Nov 17 21:12:33 2000 From: J.Horne at plymouth.ac.uk (John Horne) Date: Fri, 17 Nov 2000 10:12:33 -0000 (GMT) Subject: Strange channel 0 error In-Reply-To: Message-ID: On 16-Nov-00 at 22:43:21 Rob Hagopian wrote: > The chan_read_failed has been discussed here recently, but I haven't heard > a solution (or even a full description of the cause) yet... > I submitted a patch for the error to this list a couple of days ago, and a sort of description of the problem. I am not certain that it is the 'correct' fix, but it has caused no problems with us using it. If others would like to test it and verify that it is 'ok' then I'd say it should be included in the next release. The patch was made against the latest snapshot, but consists of only 3 lines to the nchan.c file, so you should be able to manaully apply if necessary. 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 GILBERT.R.LOOMIS at saic.com Fri Nov 17 22:46:20 2000 From: GILBERT.R.LOOMIS at saic.com (Loomis, Rip) Date: Fri, 17 Nov 2000 06:46:20 -0500 Subject: To Do list... Message-ID: <791BD3CB503DD411A6510008C7CF6477F8C29B@COL-581-EXS01> Ben-- These are all "to-do" items on my personal list--the recent BIND issues took up enough time that I haven't gotten patches out this week, but I hope to this coming week: 1. Update Solaris packaging scripts and data in contrib/solaris to reflect user comments and things I've tripped over (new initscript, postinstall now needs to generate additional RSA keys for SSH2, etc.) 2. Finish integrating code to generate kernel-level audit events on IRIX and Solaris (previously developed here against SSH 1.2.26). Note that the current code sets the user's sat id so that IRIX audit data gets generated properly for post-login events, but does not (unless I've missed a recent change) actually generate an audit event for the start and stop of each user session. 3. Once the above is complete and if no one else has done it by then, provide the necessary scripts in contrib/hpux to build "DEPOT" packages for HP-UX. If any of the above is OBE, someone please tell me--I've not had a chance to even download the 2.3.0P1 release until today. 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: mouring at etoh.eviladmin.org [mailto:mouring at etoh.eviladmin.org] > Sent: Friday, November 17, 2000 12:03 AM > To: openssh-unix-dev at mindrot.org > Subject: To Do list... > > > > This is just portable todo list. From the sounds of it > Markus has his own > to do list. But can everyone review and let me know if there > is anything > missing from this list. (Note.. I'm not looking for 'SSH > should support > XYZ feature.' unless it's directly related to portability.) > Or if there > is anything on this list that has been completed. (Namely Tru64 SIA > support?) > > Thanks. > > -Ben > > > Programming: > - Replacement for setproctitle() - HP/UX support only currently > - Improve PAM support (a pam_lastlog module will cause sshd to exit) > - Complete Tru64 SIA support > > Documentation: > - More and better > - Install FAQ? > - General FAQ on S/Key, TIS, RSA, RSA2, DSA, etc and > suggestions on when it > would be best to use them. > - Create a Documentation/ directory? > > Clean up configure/makefiles: > - Clean up configure.in - There are a few double #defined variables > left to do. HAVE_LOGIN is one of them. Consider NOT > looking for information > in wtmpx or utmpx or any of that stuff if it's not detected > from the start > - Replace the whole u_intXX_t evilness in acconfig.h with > something better??? > - Move all "openbsd-compat" files to it's own directory. > Consider doing the > same with libssh. I don't think we need to split ssh, sshd, > etc into their > own directory. > > > From nico at sonycom.com Sat Nov 18 00:15:19 2000 From: nico at sonycom.com (Nico De Ranter) Date: Fri, 17 Nov 2000 14:15:19 +0100 Subject: Why does ssh try to run df, netstat, arp ...? Message-ID: <20001117141519.S27811@immortelle.sonytel.be> Howdy, I recently had a problem with one of our servers (crashed due to power failure :-). While this shouldn't have been a problem for most of the workstations and servers on the network I noticed that I wasn't able to use ssh anymore. Ssh would simply hang during the connection. rsh and telnet however were able to connect without problem so there was no problem with the destination or the environment of the user. I noticed that for some strange reason ssh tries to run arp, netstat and df during the connection (I can understand the use of arp and netstat but why on earth df). Unfortunately df blocks when it tries to measure the size of a filesystem which is mounted (e.g. by automount) but unavailable (since the server crashed) I guess this is the reason why the ssh connection failed. Ofcourse having my whole network unreachable by ssh just because one server goes down is totaly unacceptable (I might as well start using Windows). How can I turn this behaviour off or can anybody give me a really really good reason why ssh would need df? Thanks in advance, Nico -------------------------------------------------------- "It has been said that there are only two businesses refer to customers as users: illegal drug trade and the computer industry." -------------------------------------------------------- Nico De Ranter Sony Service Center (SDCE/NEE-B) Sint Stevens Woluwestraat 55 (Rue de Woluwe-Saint-Etienne) 1130 Brussel (Bruxelles), Belgium, Europe, Earth Telephone: +32 2 724 86 41 Telefax: +32 2 726 26 86 e-mail: nico.deranter at sonycom.com From Lutz.Jaenicke at aet.TU-Cottbus.DE Sat Nov 18 00:22:56 2000 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Fri, 17 Nov 2000 14:22:56 +0100 Subject: Why does ssh try to run df, netstat, arp ...? In-Reply-To: <20001117141519.S27811@immortelle.sonytel.be>; from nico@sonycom.com on Fri, Nov 17, 2000 at 02:15:19PM +0100 References: <20001117141519.S27811@immortelle.sonytel.be> Message-ID: <20001117142256.A9667@serv01.aet.tu-cottbus.de> On Fri, Nov 17, 2000 at 02:15:19PM +0100, Nico De Ranter wrote: ... > one server goes down is totaly unacceptable (I might as well start using > Windows). How can I turn this behaviour off or can anybody give me a > really really good reason why ssh would need df? In order to collect entropy for seeding the PRNG (like the other commands). Have a look into $SSHETC/ssh_prng_commands and comment out the line(s) utilizing "df". Or recompile and change to another entropy source like EGD. 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 a.d.stribblehill at durham.ac.uk Sat Nov 18 00:32:17 2000 From: a.d.stribblehill at durham.ac.uk (Andrew Stribblehill) Date: Fri, 17 Nov 2000 13:32:17 +0000 Subject: Why does ssh try to run df, netstat, arp ...? In-Reply-To: <20001117141519.S27811@immortelle.sonytel.be>; from nico@sonycom.com on Fri, Nov 17, 2000 at 02:15:19PM +0100 References: <20001117141519.S27811@immortelle.sonytel.be> Message-ID: <20001117133217.D3972@womble.dur.ac.uk> Quoting Nico De Ranter : > Howdy, > > I recently had a problem with one of our servers (crashed due to power > failure :-). While this shouldn't have been a problem for most > of the workstations and servers on the network I noticed that I > wasn't able to use ssh anymore. Ssh would simply hang during the connection. > rsh and telnet however were able to connect without problem so there > was no problem with the destination or the environment of the user. > I noticed that for some strange reason ssh tries to run arp, netstat and df > during the connection (I can understand the use of arp and netstat but why on > earth df). Unfortunately df blocks when it tries to measure the size > of a filesystem which is mounted (e.g. by automount) but unavailable (since > the server crashed) I guess this is the reason why the ssh connection > failed. Ofcourse having my whole network unreachable by ssh just because > one server goes down is totaly unacceptable (I might as well start using > Windows). How can I turn this behaviour off or can anybody give me a > really really good reason why ssh would need df? ssh and sshd need to get some randomness into their system somehow. For machines with a /dev/random, this is easy. However, the way ssh gets round it with less pleasant systems, is that it runs a set of commands whose output varies, hopefully from one execution to the next. You can find the file containing these commands in /etc/ssh_prng_commands. Simply remove the offending lines. Cheerio, Andrew Stribblehill Systems programmer, IT Service, University of Durham, England From Pete.Chown at skygate.co.uk Sat Nov 18 01:39:56 2000 From: Pete.Chown at skygate.co.uk (Pete Chown) Date: Fri, 17 Nov 2000 14:39:56 +0000 Subject: New snapshot In-Reply-To: <20001117083540.B25763@greenie.muc.de>; from gert@greenie.muc.de on Fri, Nov 17, 2000 at 08:35:40AM +0100 References: <20001114214941.G3489@greenie.muc.de> <20001115202004.F4511@folly> <20001115222143.B28997@greenie.muc.de> <20001116190529.D13@folly> <20001117083540.B25763@greenie.muc.de> Message-ID: <20001117143956.D3775@hyena.skygate.co.uk> Gert Doering wrote: > Could anyone send me a pointer where to read up why [encrypting and > signing with the same key] is "bad"? Firstly you are restricted to RSA or ElGamal keys, because DSA keys can't easily be used for encryption. No one uses ElGamal much, so essentially you have to use RSA for everything. This may or may not matter depending on your application. Secondly, with RSA, signing and decrypting are the same operation. So if someone can get you to decrypt an arbitrary message and disclose the results, you can be made to sign arbitrary messages too. You normally wouldn't sign arbitrary messages, but if you did the attack would work that way round as well -- you could be tricked into decrypting something without realising. There are various ways round these attacks, but in many ways the simplest is just to use different keys. > I've seen that a few people have separate PGP keys for "sign" > and "crypt", but didn't understnad that either. That is really for a different reason. It means that you can replace your confidentiality key regularly while keeping the signing key the same. This means that you get a long-lived signing key which can participate in the web of trust. At the same time you have a short-lived encryption key, so less damage is done if it is compromised. -- Pete From GILBERT.R.LOOMIS at saic.com Fri Nov 17 22:46:20 2000 From: GILBERT.R.LOOMIS at saic.com (Loomis, Rip) Date: Fri, 17 Nov 2000 06:46:20 -0500 Subject: To Do list... Message-ID: <791BD3CB503DD411A6510008C7CF6477F8C29B@COL-581-EXS01> Ben-- These are all "to-do" items on my personal list--the recent BIND issues took up enough time that I haven't gotten patches out this week, but I hope to this coming week: 1. Update Solaris packaging scripts and data in contrib/solaris to reflect user comments and things I've tripped over (new initscript, postinstall now needs to generate additional RSA keys for SSH2, etc.) 2. Finish integrating code to generate kernel-level audit events on IRIX and Solaris (previously developed here against SSH 1.2.26). Note that the current code sets the user's sat id so that IRIX audit data gets generated properly for post-login events, but does not (unless I've missed a recent change) actually generate an audit event for the start and stop of each user session. 3. Once the above is complete and if no one else has done it by then, provide the necessary scripts in contrib/hpux to build "DEPOT" packages for HP-UX. If any of the above is OBE, someone please tell me--I've not had a chance to even download the 2.3.0P1 release until today. 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: mouring at etoh.eviladmin.org [mailto:mouring at etoh.eviladmin.org] > Sent: Friday, November 17, 2000 12:03 AM > To: openssh-unix-dev at mindrot.org > Subject: To Do list... > > > > This is just portable todo list. From the sounds of it > Markus has his own > to do list. But can everyone review and let me know if there > is anything > missing from this list. (Note.. I'm not looking for 'SSH > should support > XYZ feature.' unless it's directly related to portability.) > Or if there > is anything on this list that has been completed. (Namely Tru64 SIA > support?) > > Thanks. > > -Ben > > > Programming: > - Replacement for setproctitle() - HP/UX support only currently > - Improve PAM support (a pam_lastlog module will cause sshd to exit) > - Complete Tru64 SIA support > > Documentation: > - More and better > - Install FAQ? > - General FAQ on S/Key, TIS, RSA, RSA2, DSA, etc and > suggestions on when it > would be best to use them. > - Create a Documentation/ directory? > > Clean up configure/makefiles: > - Clean up configure.in - There are a few double #defined variables > left to do. HAVE_LOGIN is one of them. Consider NOT > looking for information > in wtmpx or utmpx or any of that stuff if it's not detected > from the start > - Replace the whole u_intXX_t evilness in acconfig.h with > something better??? > - Move all "openbsd-compat" files to it's own directory. > Consider doing the > same with libssh. I don't think we need to split ssh, sshd, > etc into their > own directory. > > > From GILBERT.R.LOOMIS at saic.com Sat Nov 18 00:20:24 2000 From: GILBERT.R.LOOMIS at saic.com (Loomis, Rip) Date: Fri, 17 Nov 2000 08:20:24 -0500 Subject: OpenSSH entropy/PRNG (was: Why does ssh try to run df, netstat, arp ...?) Message-ID: <791BD3CB503DD411A6510008C7CF6477F8C29D@COL-581-EXS01> Nico-- SSH is trying to "get entropy" by taking the (somewhat-deterministic) output of a bunch of system commands, on those OSs that don't provide a /dev/random or its equivalent. The commands that it uses are in /etc/ssh_prng_cmds or its equivalent on your system; just comment out any of the lines (and stop/restart SSHd) in order to change which system commands are used as inputs to the Pseudo Random Noise Generator. For our network here, for example, I have commented out the call to arp since that one change decreases SSH session startup time significantly on our Solaris boxen. Related question: Is anyone actively trying to get Yarrow or some other algorithmic source of entropy into OpenSSH? I suppose this is really a question for the OpenSSL folks... 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: Nico De Ranter [mailto:nico at sonycom.com] > Sent: Friday, November 17, 2000 8:15 AM > To: openssh-unix-dev at mindrot.org > Subject: Why does ssh try to run df, netstat, arp ...? > > > Howdy, > > > I recently had a problem with one of our servers (crashed due to power > failure :-). While this shouldn't have been a problem for most > of the workstations and servers on the network I noticed that I > wasn't able to use ssh anymore. Ssh would simply hang during > the connection. > rsh and telnet however were able to connect without problem so there > was no problem with the destination or the environment of the user. > I noticed that for some strange reason ssh tries to run arp, > netstat and df > during the connection (I can understand the use of arp and > netstat but why on > earth df). Unfortunately df blocks when it tries to measure the size > of a filesystem which is mounted (e.g. by automount) but > unavailable (since > the server crashed) I guess this is the reason why the ssh connection > failed. Ofcourse having my whole network unreachable by ssh > just because > one server goes down is totaly unacceptable (I might as well > start using > Windows). How can I turn this behaviour off or can anybody give me a > really really good reason why ssh would need df? > > Thanks in advance, > > Nico > > > -------------------------------------------------------- > "It has been said that there are only two businesses > refer to customers as users: illegal drug trade and > the computer industry." > -------------------------------------------------------- > Nico De Ranter > Sony Service Center (SDCE/NEE-B) > Sint Stevens Woluwestraat 55 (Rue de Woluwe-Saint-Etienne) > 1130 Brussel (Bruxelles), Belgium, Europe, Earth > Telephone: +32 2 724 86 41 Telefax: +32 2 726 26 86 > e-mail: nico.deranter at sonycom.com > > From tim at multitalents.net Sat Nov 18 04:48:39 2000 From: tim at multitalents.net (Tim Rice) Date: Fri, 17 Nov 2000 09:48:39 -0800 (PST) Subject: To Do list... In-Reply-To: Message-ID: On Thu, 16 Nov 2000 mouring at etoh.eviladmin.org wrote: > > This is just portable todo list. From the sounds of it Markus has his own > to do list. But can everyone review and let me know if there is anything > missing from this list. (Note.. I'm not looking for 'SSH should support > XYZ feature.' unless it's directly related to portability.) Or if there > is anything on this list that has been completed. (Namely Tru64 SIA > support?) > > Thanks. > > -Ben > > > Programming: > - Replacement for setproctitle() - HP/UX support only currently > - Improve PAM support (a pam_lastlog module will cause sshd to exit) > - Complete Tru64 SIA support Support systems that do not have 64bit int and do not have long long. > > Documentation: > - More and better > - Install FAQ? > - General FAQ on S/Key, TIS, RSA, RSA2, DSA, etc and suggestions on when it > would be best to use them. > - Create a Documentation/ directory? > > Clean up configure/makefiles: > - Clean up configure.in - There are a few double #defined variables > left to do. HAVE_LOGIN is one of them. Consider NOT looking for information > in wtmpx or utmpx or any of that stuff if it's not detected from the start > - Replace the whole u_intXX_t evilness in acconfig.h with something better??? > - Move all "openbsd-compat" files to it's own directory. Consider doing the > same with libssh. I don't think we need to split ssh, sshd, etc into their > own directory. > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From speno at isc.upenn.edu Sat Nov 18 06:12:06 2000 From: speno at isc.upenn.edu (John P Speno) Date: Fri, 17 Nov 2000 14:12:06 -0500 Subject: To Do list... In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Nov 16, 2000 at 11:02:51PM -0600 References: Message-ID: <20001117141206.A12082@isc.upenn.edu> > XYZ feature.' unless it's directly related to portability.) Or if there > is anything on this list that has been completed. (Namely Tru64 SIA > support?) Chris Adams posted a new version of his Tru64 SIA support code within the past month or so which is much better than the previous version. But, I don't think it made it into the latest releases. Please correct me if I'm wrong. From stevev at darkwing.uoregon.edu Sat Nov 18 06:17:20 2000 From: stevev at darkwing.uoregon.edu (Steve VanDevender) Date: Fri, 17 Nov 2000 11:17:20 -0800 Subject: To Do list... In-Reply-To: <20001117141206.A12082@isc.upenn.edu> References: <20001117141206.A12082@isc.upenn.edu> Message-ID: <14869.33856.605008.491304@darkwing.uoregon.edu> John P Speno writes: > > XYZ feature.' unless it's directly related to portability.) Or if there > > is anything on this list that has been completed. (Namely Tru64 SIA > > support?) > > Chris Adams posted a new version of his Tru64 SIA support code within > the past month or so which is much better than the previous version. > > But, I don't think it made it into the latest releases. Please correct > me if I'm wrong. It hasn't yet, and I too would like to see it get into Portable OpenSSH eventually. I was trying to merge that last posted Digital UNIX SIA patch with the last snapshot before 2.3.0p1, but a lot of the code that it patched has changed significantly and I wasn't able to get it working before I had to move on to other things. From markus.friedl at informatik.uni-erlangen.de Sat Nov 18 07:19:56 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 17 Nov 2000 21:19:56 +0100 Subject: New snapshot In-Reply-To: <8v1bmg$gte$1@kemoauc.mips.inka.de>; from naddy@mips.inka.de on Thu, Nov 16, 2000 at 07:14:24PM +0000 References: <20001115080939.A14222@greenie.muc.de> <8v11ng$748$1@kemoauc.mips.inka.de> <20001116185921.A13@folly> <8v1bmg$gte$1@kemoauc.mips.inka.de> Message-ID: <20001117211956.A29481@folly> On Thu, Nov 16, 2000 at 07:14:24PM +0000, Christian Weisgerber wrote: > Markus Friedl wrote: > > > > Unfortunately, SSH2 connection setup is still unusably slow on > > > slower machines. [...] > > > > just remove /etc/primes and try again... > > What is this file? It's not documented in sshd(8)--nor OpenBSD's > man pages in general. see http://www.ietf.org/internet-drafts/draft-provos-secsh-dh-group-exchange-00.txt for info on the 'Diffie-Hellman Group Exchange' > Anyway, I did, and the situation improved. From "ssh -v" I gather > that whatever this Diffie-Hellman Group Exchange exchanges is down > from 2048 to 1024 bits, resulting in a connection setup time of > 25+ seconds. (Still a pain for practical use, of course. Protocol 1 > takes about five seconds.) there is no faster (and secure) alternative to the 1024 bit DH group. -m From gert at greenie.muc.de Sat Nov 18 08:24:12 2000 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 17 Nov 2000 22:24:12 +0100 Subject: To Do list... In-Reply-To: ; from Tim Rice on Fri, Nov 17, 2000 at 09:48:39AM -0800 References: Message-ID: <20001117222412.G18488@greenie.muc.de> Hi, On Fri, Nov 17, 2000 at 09:48:39AM -0800, Tim Rice wrote: > > Programming: > > - Replacement for setproctitle() - HP/UX support only currently > > - Improve PAM support (a pam_lastlog module will cause sshd to exit) > > - Complete Tru64 SIA support > > Support systems that do not have 64bit int and do not have long long. This would uglify such code massively. Are there systems that have a reasonable user base and can not use gcc (which has long long on all 32 bit platforms)? 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 tim at multitalents.net Sat Nov 18 11:27:10 2000 From: tim at multitalents.net (Tim Rice) Date: Fri, 17 Nov 2000 16:27:10 -0800 (PST) Subject: To Do list... In-Reply-To: <20001117222412.G18488@greenie.muc.de> Message-ID: On Fri, 17 Nov 2000, Gert Doering wrote: > Hi, > > On Fri, Nov 17, 2000 at 09:48:39AM -0800, Tim Rice wrote: > > > Programming: > > > - Replacement for setproctitle() - HP/UX support only currently > > > - Improve PAM support (a pam_lastlog module will cause sshd to exit) > > > - Complete Tru64 SIA support > > > > Support systems that do not have 64bit int and do not have long long. > > This would uglify such code massively. Are there systems that have a > reasonable user base and can not use gcc (which has long long on all 32 > bit platforms)? I really don't have a clue about the size of the user base. The platforms I know about are the vendor supplied compilers for UnixWare 2.0x, UnixWare 2.1.x & SCO Open Server 5. I just don't like the idea of requiring gcc when the system allready has a perfectly good C compiler. In the case ot SCO Open Server 5, the compiler is an additional cost item so many people will just load gcc. I purposly do not load gcc on my systems that I have the vendor's development system on so I can make sure that software works with the vendor's compiler. I have gcc on SCO 3.2v4.2, Solaris 7, Caldera eDesktop 2.x, & RedHat 6.2. But I use the vendor's development system on UnixWare 2.03, UnixWare 2.1.3, UnixWare 7.1.0, & SCO Open Server 5.0.4. I usually don't send any portability patches untill i've tested on all of those systems. But now three of them will not even compile the first program. > > gert > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mouring at etoh.eviladmin.org Sat Nov 18 12:44:05 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 17 Nov 2000 19:44:05 -0600 (CST) Subject: To Do list... In-Reply-To: Message-ID: On Fri, 17 Nov 2000, Tim Rice wrote: > On Fri, 17 Nov 2000, Gert Doering wrote: > > > Hi, > > > > On Fri, Nov 17, 2000 at 09:48:39AM -0800, Tim Rice wrote: > > > > Programming: > > > > - Replacement for setproctitle() - HP/UX support only currently > > > > - Improve PAM support (a pam_lastlog module will cause sshd to exit) > > > > - Complete Tru64 SIA support > > > > > > Support systems that do not have 64bit int and do not have long long. > > > > This would uglify such code massively. Are there systems that have a > > reasonable user base and can not use gcc (which has long long on all 32 > > bit platforms)? > > I really don't have a clue about the size of the user base. > The platforms I know about are the vendor supplied compilers > for UnixWare 2.0x, UnixWare 2.1.x & SCO Open Server 5. > I just don't like the idea of requiring gcc when the system > allready has a perfectly good C compiler. I'm sure you have more of a user base then the NeXT Port. =) I can count all of them on almost one hand. > In the case ot SCO Open Server 5, the compiler is an additional > cost item so many people will just load gcc. > I purposly do not load gcc on my systems that I have the vendor's > development system on so I can make sure that software works with > the vendor's compiler. I have gcc on SCO 3.2v4.2, Solaris 7, Caldera > eDesktop 2.x, & RedHat 6.2. But I use the vendor's development > system on UnixWare 2.03, UnixWare 2.1.3, UnixWare 7.1.0, & SCO Open > Server 5.0.4. > > I usually don't send any portability patches untill i've tested > on all of those systems. But now three of them will not even > compile the first program. > What does SCO's compiler use for 64bit? Only sftp-server.c uses 64bit integers. I guess one could disable sftp-server for platforms like SCO that lack a current 64bit integer implementation. I'm not a fan of temporary patches. They don't always get cleaned out, but I think it may be better then just outright failing. - Ben From provos at citi.umich.edu Sun Nov 19 00:07:43 2000 From: provos at citi.umich.edu (Niels Provos) Date: Sat, 18 Nov 2000 08:07:43 -0500 Subject: New snapshot In-Reply-To: Christian Weisgerber, Thu, 16 Nov 2000 19:14:24 GMT Message-ID: <20001118130743.41898207C1@citi.umich.edu> In message <8v1bmg$gte$1 at kemoauc.mips.inka.de>, Christian Weisgerber writes: >What is this file? It's not documented in sshd(8)--nor OpenBSD's >man pages in general. I will fix that. >Anyway, I did, and the situation improved. From "ssh -v" I gather >that whatever this Diffie-Hellman Group Exchange exchanges is down >from 2048 to 1024 bits, resulting in a connection setup time of >25+ seconds. (Still a pain for practical use, of course. Protocol 1 >takes about five seconds.) SSHv2 computes an authenticated Diffie-Hellman key exchange. It requires more modular exponentation than in the simple RSA case. And an additional signature verification. In SSHv1 you just have to deal with RSA, where at least the encryption part is quite fast for the exponents in use. The Diffie-Hellman group exchange allows the server to send new DH groups to the client, which make precomputation undesirable. Read http://www.citi.umich.edu/u/provos/tmp/dh-group-exchange-2.txt for more information. Niels. From pekkas at netcore.fi Sun Nov 19 00:15:28 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 18 Nov 2000 15:15:28 +0200 (EET) Subject: To Do list... In-Reply-To: Message-ID: On Thu, 16 Nov 2000 mouring at etoh.eviladmin.org wrote: > Documentation: > - More and better > - Install FAQ? > - General FAQ on S/Key, TIS, RSA, RSA2, DSA, etc and suggestions on when it > would be best to use them. > - Create a Documentation/ directory? - Add man pages to configure so that pathnames will be correct, not the defaults. -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From tlewis at secureworks.net Sun Nov 19 05:19:55 2000 From: tlewis at secureworks.net (Todd Lewis) Date: Sat, 18 Nov 2000 13:19:55 -0500 (EST) Subject: patch to support local address binding Message-ID: Greetings. I have modified openssh to support explicitly binding to a local IP address. This addition was driven by the requirement that only certain IPs can ssh into target machines of ours, and these IP addresses are interface aliases which float among various server machines. By default, without explicitly binding, the originating address of outbound ssh connections, like all other unbound sockets, is determined by the kernel, which usually defaults to the primary IP of the interface from which it sends the traffic. The syntax for specifying this option is "-A ". Of course, this must be a configured address on the machine. I would have no problem with changing the name of this option from "-A" to something else. Another potential change is to specify the local port to which to bind. Since I did not have a need for this, I did not do it, but others might. If they do, then the function opt_bind_socket() could be extended to support this as well. I figured that other people may also have this problem, and so I have made a patch with my changes and am submitting it for inclusion into the openssh distribution. This code is copyright by myself, Todd Lewis, and I provide it under the terms of the standard openssh license as specified in section 4 of the "LICENSE" file in the openssh-2.3.0p1 release. I ask that this functionality be included in the main openssh distribution. -- Todd Lewis tlewis at secureworks.net Director of Technical Operations SecureWorks, Inc. From mouring at etoh.eviladmin.org Sun Nov 19 06:19:22 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 18 Nov 2000 13:19:22 -0600 (CST) Subject: To Do list... In-Reply-To: Message-ID: On Sat, 18 Nov 2000, Pekka Savola wrote: > On Thu, 16 Nov 2000 mouring at etoh.eviladmin.org wrote: > > Documentation: > > - More and better > > - Install FAQ? > > - General FAQ on S/Key, TIS, RSA, RSA2, DSA, etc and suggestions on when it > > would be best to use them. > > - Create a Documentation/ directory? > > - Add man pages to configure so that pathnames will be correct, not the >defaults. > You looking for a --with-manpath= type option so you can install the manpages within the /usr/man/manX location intend of locating it with the rest of the package? - Ben From pekkas at netcore.fi Sun Nov 19 05:38:21 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 18 Nov 2000 20:38:21 +0200 (EET) Subject: To Do list... In-Reply-To: Message-ID: On Sat, 18 Nov 2000 mouring at etoh.eviladmin.org wrote: > On Sat, 18 Nov 2000, Pekka Savola wrote: > > > On Thu, 16 Nov 2000 mouring at etoh.eviladmin.org wrote: > > > Documentation: > > > - More and better > > > - Install FAQ? > > > - General FAQ on S/Key, TIS, RSA, RSA2, DSA, etc and suggestions on when it > > > would be best to use them. > > > - Create a Documentation/ directory? > > > > - Add man pages to configure so that pathnames will be correct, not the > >defaults. > > > > You looking for a --with-manpath= type option so you can install the > manpages within the /usr/man/manX location intend of locating it with the > rest of the package? No, I meant that configure should replace all instances of e.g. /etc/sshd_config with $sysconfdir/sshd_config etc. This shouldn't be too difficult to do if you can assume perl can be used at compile time (I guess it can) [1]. Or maybe not too difficult, otherwise, either. [1] perl -pi -e s"|@@SYSCONFDIR@@|$sysconfdir|g manpages or the like It looks like the original OpenSSH isn't autoconfized, though, so this might create a small rift for manpages. -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From tlewis at secureworks.net Sun Nov 19 05:39:30 2000 From: tlewis at secureworks.net (Todd Lewis) Date: Sat, 18 Nov 2000 13:39:30 -0500 (EST) Subject: patch to support local address binding In-Reply-To: Message-ID: It might be useful if I actually included the patch. 8^) Here it is. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/octet-stream Size: 1546 bytes Desc: Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001118/bb721176/attachment.obj From djm at mindrot.org Sun Nov 19 11:30:34 2000 From: djm at mindrot.org (Damien Miller) Date: Sun, 19 Nov 2000 11:30:34 +1100 (EST) Subject: OpenSSH entropy/PRNG (was: Why does ssh try to run df, netstat, arp ...?) In-Reply-To: <791BD3CB503DD411A6510008C7CF6477F8C29D@COL-581-EXS01> Message-ID: On Fri, 17 Nov 2000, Loomis, Rip wrote: > Related question: > Is anyone actively trying to get Yarrow or some other > algorithmic source of entropy into OpenSSH? I suppose > this is really a question for the OpenSSL folks... Yarrow provides a similar infrastructure to the RAND_* functions in OpenSSL - an entropy pool. You still have to come up with an appropriate number of random bits. Hassle your vendor for /dev/random support in their OS :) -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 Nov 19 11:54:59 2000 From: djm at mindrot.org (Damien Miller) Date: Sun, 19 Nov 2000 11:54:59 +1100 (EST) Subject: To Do list... In-Reply-To: Message-ID: On Sat, 18 Nov 2000, Pekka Savola wrote: > No, I meant that configure should replace all instances of e.g. > /etc/sshd_config with $sysconfdir/sshd_config etc. It does already! Can you give specific examples of where it fails? > This shouldn't be too difficult to do if you can assume perl can be used > at compile time (I guess it can) [1]. Or maybe not too > difficult, otherwise, either. We are using the 'fixpaths' script which is called from the makefile to do these substitutions. -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 pekkas at netcore.fi Sun Nov 19 12:37:44 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 19 Nov 2000 03:37:44 +0200 (EET) Subject: To Do list... In-Reply-To: Message-ID: On Sun, 19 Nov 2000, Damien Miller wrote: > On Sat, 18 Nov 2000, Pekka Savola wrote: > > > No, I meant that configure should replace all instances of e.g. > > /etc/sshd_config with $sysconfdir/sshd_config etc. > > It does already! Can you give specific examples of where it fails? Nice! I had missed that feature addition :-) Anyway, it looks rather complete. Going through man pages: 1) added /etc/sshrc to the list 2) /usr/X11R6/bin/xauth might be a good candidate, but it isn't exported in Makefile.. 3) /etc/rc is mentioned a lot on the pages, but as there is no uniform alternative, so it's probably best to leave that alone. -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" -------------- next part -------------- --- Makefile.in.orig Mon Nov 13 14:17:53 2000 +++ Makefile.in Sun Nov 19 03:17:24 2000 @@ -49,7 +49,7 @@ 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 +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 FIXPATHSCMD = $(PERL) $(srcdir)/fixpaths $(PATHSUBS) From Stephan.Hendl at lds.brandenburg.de Mon Nov 20 18:25:08 2000 From: Stephan.Hendl at lds.brandenburg.de (Stephan Hendl) Date: Mon, 20 Nov 2000 08:25:08 +0100 Subject: openssh kills the stty values? Message-ID: Hi all, I found that on some HP-UX 11 machines running openssh-2.3.0p1 the default values for intr in stty don't work. The problem is that stty shows the correct values but they don' work and I cannot det the values to others. Once I connect via telnet or rlogin I can use the intr-sequence. Any ideas? Thanks 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 robbie at serendipity.palo-alto.ca.us Mon Nov 20 20:04:06 2000 From: robbie at serendipity.palo-alto.ca.us (Robbie Stone) Date: Mon, 20 Nov 2000 01:04:06 -0800 Subject: Why does ssh try to run df, netstat, arp ...? References: <20001117141519.S27811@immortelle.sonytel.be> <20001117133217.D3972@womble.dur.ac.uk> Message-ID: <3A18E906.90F6B9A5@serendipity.palo-alto.ca.us> Andrew Stribblehill wrote: YES!!!!! I am running OpenSSH under Ultrix and lemme tell ya, that half this shit we take for granite on a modern Unix system is non-existant. It's not cool to re-link your kernel every time you change your root device for example. This solved major problems with random data (/dev/random under Ultrix, yeah right!) Robbie > > Quoting Nico De Ranter : > > Howdy, > > > > I recently had a problem with one of our servers (crashed due to power > > failure :-). While this shouldn't have been a problem for most > > of the workstations and servers on the network I noticed that I > > wasn't able to use ssh anymore. Ssh would simply hang during the connection. > > rsh and telnet however were able to connect without problem so there > > was no problem with the destination or the environment of the user. > > I noticed that for some strange reason ssh tries to run arp, netstat and df > > during the connection (I can understand the use of arp and netstat but why on > > earth df). Unfortunately df blocks when it tries to measure the size > > of a filesystem which is mounted (e.g. by automount) but unavailable (since > > the server crashed) I guess this is the reason why the ssh connection > > failed. Ofcourse having my whole network unreachable by ssh just because > > one server goes down is totaly unacceptable (I might as well start using > > Windows). How can I turn this behaviour off or can anybody give me a > > really really good reason why ssh would need df? > > ssh and sshd need to get some randomness into their system > somehow. For machines with a /dev/random, this is easy. However, > the way ssh gets round it with less pleasant systems, is that it > runs a set of commands whose output varies, hopefully from one > execution to the next. > > You can find the file containing these commands in > /etc/ssh_prng_commands. Simply remove the offending lines. > > Cheerio, > > Andrew Stribblehill > Systems programmer, IT Service, University of Durham, England -- Robbie Stone Serendipity Simplex From peterb at telerama.com Mon Nov 20 23:39:00 2000 From: peterb at telerama.com (Peter Berger) Date: Mon, 20 Nov 2000 07:39:00 -0500 (EST) Subject: OpenSSH Security bug: port forwarding Message-ID: Hi. OpenSSH 2.3.0p1 exhibits the following behavior on Linux 2.2.5. I believe this is a bug. Can anyone else replicate this? On any given SSH machine (let's call it 'test'), start ssh like this: ./ssh -L2526:mail.blah.com:25 -f mail.blah.com sleep 1000 (where mail.blah.com is some machine running sendmail, you have a login account, etc.) In a just world (and this works with f-secure SSH1), you should be able to do this on test: telnet 127.0.0.1 2526 and connect to mail.blah.com port 25 over the secure channel. This works. But if I am sitting on -some other machine- and type: telnet test.blah.com 2526 the connection should be rejected -unless- I have given ssh the -g option (again, this works 'right' with f-secure ssh1). OpenSSH accepts non-local connections whether or not I give the -g option. This is pretty broken. Put another way: ssh is clearly binding to addresses other than localhost, even without the -g option. I am looking for feedback to determine: 1) Is this bug repeatable for others on Linux? 2) Is it repeatable on other OS's? 3) Am I simply misunderstanding the use of this feature completely, and this is not in fact a bug? If so, I'd like an example of correct use. I'm not on the list, so carbon copies would be appreciated. Thanks! Peter Berger Network Dilettante http://peterb.telerama.com From pekkas at netcore.fi Tue Nov 21 00:24:49 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 20 Nov 2000 15:24:49 +0200 (EET) Subject: OpenSSH Security bug: port forwarding In-Reply-To: Message-ID: On Mon, 20 Nov 2000, Peter Berger wrote: > Hi. OpenSSH 2.3.0p1 exhibits the following behavior on Linux 2.2.5. I > believe this is a bug. Can anyone else replicate this? > > On any given SSH machine (let's call it 'test'), start ssh like > this: > > ./ssh -L2526:mail.blah.com:25 -f mail.blah.com sleep 1000 > > (where mail.blah.com is some machine running sendmail, you have a login > account, etc.) > > In a just world (and this works with f-secure SSH1), you should be able to > do this on test: > > telnet 127.0.0.1 2526 > > and connect to mail.blah.com port 25 over the secure channel. This works. > > But if I am sitting on -some other machine- and type: > > telnet test.blah.com 2526 Works fine for me (RHL 7.0, 2.4 kernel, the latest ssh-2.3.0p2 snapshot; also tested RHL 6.0, 2.2.16-3 kernel, ssh-2.3.0p1): --- debug: Connections to local port 2526 forwarded to remote address netcore.fi:25 debug: Local forwarding listening on 127.0.0.1 port 2456. --- --- tcp 0 0 127.0.0.1:2526 0.0.0.0:* LISTEN --- You haven't defined GatewayPorts in ssh configuration by mistake, have you? -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From morten at ngb.se Tue Nov 21 01:38:52 2000 From: morten at ngb.se (Morten Hulden) Date: Mon, 20 Nov 2000 15:38:52 +0100 (CET) Subject: Openssh-2.3.0p1 (Linux), sftp fails with F-secure client Message-ID: Hi list, openssh-2.3.0p1 (compiled from sources) under Linux RH kernel 2.2.16 with this line in sshd-conf: Subsystem sftp sftp-server fails when trying to connect from F-secure SSH sftp client (FTP 4.1 Build 12). Connection is immediately terminated, with following error message in the log: > Nov 20 14:31:30 tor sshd[23159]: subsystem request for sftp Nov 20 > 14:31:30 tor sshd[23159]: error: channel 0: internal error: we do not > read, but chan_read_failed for istate 8 Any ideas? MHu From Markus.Friedl at informatik.uni-erlangen.de Tue Nov 21 01:53:25 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 20 Nov 2000 15:53:25 +0100 Subject: Openssh-2.3.0p1 (Linux), sftp fails with F-secure client In-Reply-To: ; from morten@ngb.se on Mon, Nov 20, 2000 at 03:38:52PM +0100 References: Message-ID: <20001120155324.B26256@faui02.informatik.uni-erlangen.de> did you specify the full pathname to the sftp-server? always use pathnames.. -m On Mon, Nov 20, 2000 at 03:38:52PM +0100, Morten Hulden wrote: > > Hi list, > > openssh-2.3.0p1 (compiled from sources) under Linux RH kernel 2.2.16 > with this line in sshd-conf: > Subsystem sftp sftp-server > > fails when trying to connect from F-secure SSH sftp client (FTP 4.1 > Build 12). Connection is immediately terminated, with following error > message in the log: > > > Nov 20 14:31:30 tor sshd[23159]: subsystem request for sftp Nov 20 > > 14:31:30 tor sshd[23159]: error: channel 0: internal error: we do not > > read, but chan_read_failed for istate 8 > > Any ideas? > > MHu > > > From peterb at telerama.com Tue Nov 21 01:59:33 2000 From: peterb at telerama.com (Peter Berger) Date: Mon, 20 Nov 2000 09:59:33 -0500 (EST) Subject: OpenSSH Security bug: port forwarding In-Reply-To: <20001120153305.A29829@laivuri63.uku.fi> Message-ID: Yes, I had GatewayPorts set to 'no' -- this is clearly not a bug in ssh, but in the version of Linux I'm using. When I debugged, ssh was binding to 0.0.0.0. Oh well. We shouldn't be using Linux as a firewall anyway. -p On Mon, 20 Nov 2000, Jarno Huuskonen wrote: > On Mon, Nov 20, Peter Berger wrote: > > > > > > Hi. OpenSSH 2.3.0p1 exhibits the following behavior on Linux 2.2.5. I > > believe this is a bug. Can anyone else replicate this? > > > > On any given SSH machine (let's call it 'test'), start ssh like > > this: > > > > ./ssh -L2526:mail.blah.com:25 -f mail.blah.com sleep 1000 > > > > (where mail.blah.com is some machine running sendmail, you have a login > > account, etc.) > > > > In a just world (and this works with f-secure SSH1), you should be able to > > do this on test: > > > > telnet 127.0.0.1 2526 > > > > and connect to mail.blah.com port 25 over the secure channel. This works. > > > > But if I am sitting on -some other machine- and type: > > > > telnet test.blah.com 2526 > > > > the connection should be rejected -unless- I have given ssh the -g option > > (again, this works 'right' with f-secure ssh1). OpenSSH accepts > > non-local connections whether or not I give the -g option. This is pretty > > broken. Put another way: ssh is clearly binding to addresses other than > > localhost, even without the -g option. > > I couldn't reproduce this. For me OpenSSH 2.3.0p1 works correctly. > You can use lsof -i tcp to check what processes are listening. For me > I can see > ssh 29854 jhuuskon 7u IPv4 215895 TCP localhost:5000 (LISTEN) > when using ssh -L5000:xxx:110 or whatever. > > Did you check your/system ssh_config ? > Does it have GatewayPorts set to yes ? > > -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 morten at ngb.se Tue Nov 21 03:02:50 2000 From: morten at ngb.se (Morten Hulden) Date: Mon, 20 Nov 2000 17:02:50 +0100 (CET) Subject: Openssh-2.3.0p1 (Linux), sftp fails with F-secure client In-Reply-To: <20001120155324.B26256@faui02.informatik.uni-erlangen.de> Message-ID: On Mon, 20 Nov 2000, Markus Friedl wrote: > did you specify the full pathname to the sftp-server? > always use pathnames.. -m Thanks. It now works after I changed the line in sshd-config to: Subsystem sftp /usr/local/libexec/sftp-server MHu From pekkas at netcore.fi Tue Nov 21 03:17:43 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 20 Nov 2000 18:17:43 +0200 (EET) Subject: OpenSSH Security bug: port forwarding In-Reply-To: Message-ID: On Mon, 20 Nov 2000, Peter Berger wrote: > Yes, I had GatewayPorts set to 'no' -- this is clearly not a bug in ssh, > but in the version of Linux I'm using. When I debugged, ssh was binding > to 0.0.0.0. > > Oh well. We shouldn't be using Linux as a firewall anyway. Try upgrading the kernel and/or glibc; that should be done for stability, security and speed reasons anyway. getaddrinfo as defined in fake-getaddrinfo.c is failing for you, probably. -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From gombasg at inf.elte.hu Tue Nov 21 03:38:27 2000 From: gombasg at inf.elte.hu (GOMBAS Gabor) Date: Mon, 20 Nov 2000 17:38:27 +0100 Subject: Minor installation bug Message-ID: <20001120173827.I18686@valerie.inf.elte.hu> Hello, The Makefile.in of openssh-2.3.0p1 looks for ssh-keygen in the source directory when generating the host key at 'make install'. But if the source and the build directories are different, it will fail... Gabor -- Gabor Gombas Eotvos Lorand University E-mail: gombasg at inf.elte.hu Hungary From mouring at etoh.eviladmin.org Tue Nov 21 04:43:09 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 20 Nov 2000 11:43:09 -0600 (CST) Subject: Minor installation bug In-Reply-To: <20001120173827.I18686@valerie.inf.elte.hu> Message-ID: Issue was noted after p1 was released. So it should be resolved when 2.3.0p2 is released. - Ben On Mon, 20 Nov 2000, GOMBAS Gabor wrote: > Hello, > > The Makefile.in of openssh-2.3.0p1 looks for ssh-keygen in the source > directory when generating the host key at 'make install'. But if the > source and the build directories are different, it will fail... > > Gabor > > From djm at mindrot.org Tue Nov 21 14:30:25 2000 From: djm at mindrot.org (Damien Miller) Date: Tue, 21 Nov 2000 14:30:25 +1100 (EST) Subject: OpenSSH Security bug: port forwarding In-Reply-To: Message-ID: On Mon, 20 Nov 2000, Peter Berger wrote: > > > Hi. OpenSSH 2.3.0p1 exhibits the following behavior on Linux 2.2.5. I > believe this is a bug. Can anyone else replicate this? > > On any given SSH machine (let's call it 'test'), start ssh like > this: > > ./ssh -L2526:mail.blah.com:25 -f mail.blah.com sleep 1000 > > (where mail.blah.com is some machine running sendmail, you have a login > account, etc.) > > In a just world (and this works with f-secure SSH1), you should be able to > do this on test: > > telnet 127.0.0.1 2526 > > and connect to mail.blah.com port 25 over the secure channel. This works. > > But if I am sitting on -some other machine- and type: > > telnet test.blah.com 2526 > > the connection should be rejected -unless- I have given ssh the -g option > (again, this works 'right' with f-secure ssh1). OpenSSH accepts > non-local connections whether or not I give the -g option. This is pretty > broken. Put another way: ssh is clearly binding to addresses other than > localhost, even without the -g option. > > I am looking for feedback to determine: > 1) Is this bug repeatable for others on Linux? I am unable to repeat this problem on Linux with the current snapshot, nor on OpenSSH-2.1 as shipped with OpenBSD 2.7. Do you have a 'GatewayPorts yes' in your ssh_config or ~/.ssh/config? 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 Tue Nov 21 14:36:36 2000 From: djm at mindrot.org (Damien Miller) Date: Tue, 21 Nov 2000 14:36:36 +1100 (EST) Subject: OpenSSH Security bug: port forwarding In-Reply-To: Message-ID: On Tue, 21 Nov 2000, Damien Miller wrote: > Do you have a 'GatewayPorts yes' in your ssh_config or ~/.ssh/config? That should be a 'GatewayPorts no'. -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 garrick at james.net Tue Nov 21 16:42:13 2000 From: garrick at james.net (Garrick James) Date: Mon, 20 Nov 2000 21:42:13 -0800 (PST) Subject: openssh kills the stty values? In-Reply-To: Message-ID: I do not have any hpux machines, but I cannot help wondering if this is like the same problem we have (or had?) on Solaris (don't know if it was ever fixed, but a work-around exists). On Solaris, you end up with the same thing sometimes. Namely, your intr key combination doesn't work. It turns out that this is only the case if intr does not work in the environment from which sshd is launched (like from a cron/at job or an ssh session in which the problem exists, for example). The work-around on Solaris is to make sure that sshd starts up in an environment in which intr already works (i.e. at system startup, at the console, or in a telnet session). Once sshd is "bootstrapped" in this manner, intr works fine in ssh sessions. I have my system init script for openssh (/etc/init.d/openssh) written so that it takes the argument "restart" in addition to "start" and "stop". With the restart argument, the script simply does: /etc/init.d/openssh stop /etc/init.d/openssh start This makes it nice so that from within an ssh session that has a working intr, I can issue: nohup /etc/init.d/openssh restart I get booted out, of course, but sshd starts up again with intr working. Anyway, I don't know for sure that you are seeing the same problem, but I hope this helped. BTW, anyone know if this problem was ever fixed on Solaris? I remember reading a message that someone tracked down in the source were the problem was, but I cannot remember if a patch was ever submitted and integrated. -Garrick James On Mon, 20 Nov 2000, Stephan Hendl wrote: > Hi all, > > I found that on some HP-UX 11 machines running openssh-2.3.0p1 the > default values for intr in stty don't work. The problem is that stty > shows the correct values but they don' work and I cannot det the > values to others. Once I connect via telnet or rlogin I can use the > intr-sequence. > > Any ideas? > > Thanks > 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 jmknoble at jmknoble.cx Tue Nov 21 17:02:57 2000 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Tue, 21 Nov 2000 01:02:57 -0500 Subject: Repost: PATCH: OpenSSH-2.3.0p1: specfile trivia Message-ID: <20001121010257.C563@quipu.half.pint-stowp.cx> This doesn't appear to have made it to the list (although i still appear to be subscribed...). Bcc'ed to Damien for good measure. -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ -------------- next part -------------- An embedded message was scrubbed... From: Jim Knoble Subject: PATCH: OpenSSH-2.3.0p1: specfile trivia Date: Sun, 19 Nov 2000 01:46:00 -0500 Size: 10348 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001121/8e8012f5/attachment.mht From pekkas at netcore.fi Tue Nov 21 19:27:12 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 21 Nov 2000 10:27:12 +0200 (EET) Subject: Irix joblimits failure (was: Re: New snapshot) In-Reply-To: <20001114095518.O17700@justice.loyola.edu> Message-ID: On Tue, 14 Nov 2000, Michael Stone wrote: > The IRIX job limits patch will only build on IRIX >= 6.5.7. I hacked up > configure to do the checking, but I'm not sure of the configure.in > syntax. Does this look legal? > > *-*-irix6*) > CFLAGS="$CFLAGS -I/usr/local/include" > LDFLAGS="$LDFLAGS" > PATH="$PATH:/usr/etc" > MANTYPE='$(CATMAN)' > AC_DEFINE(WITH_IRIX_ARRAY) > AC_DEFINE(WITH_IRIX_PROJECT) > AC_DEFINE(WITH_IRIX_AUDIT) > > IFS=.fm > set `uname -r` > if test $2 -ge 5 ; then > set `uname -R` > if test $3 -gt 5 -o $4 -gt 7 ; then > AC_DEFINE(WITH_IRIX_JOBS) > fi > fi > unset IFS > > no_libsocket=1 > no_libnsl=1 > AC_DEFINE(BROKEN_INET_NTOA) > ;; For me, compilation on Irix (uname -R: 6.5 6.5.9m) fails with: --- ld32: ERROR 33 : Unresolved text symbol "jlimit_startjob" -- 1st referenced by session.o. Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: INFO 152: Output file removed because of error. --- And relating: --- session.c:1101: warning: implicit declaration of function 'limit_startjob' --- Apparently not all people have job limits even though they may have rather recent systems... -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From mouring at etoh.eviladmin.org Tue Nov 21 20:37:44 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 21 Nov 2000 03:37:44 -0600 (CST) Subject: Irix joblimits failure (was: Re: New snapshot) In-Reply-To: Message-ID: Will this resolve the issue cleanly? - Ben --- ../openssh/configure.in Sat Nov 11 12:58:31 2000 +++ configure.in Tue Nov 21 03:33:53 2000 @@ -111,7 +111,7 @@ AC_DEFINE(WITH_IRIX_ARRAY) AC_DEFINE(WITH_IRIX_PROJECT) AC_DEFINE(WITH_IRIX_AUDIT) - AC_DEFINE(WITH_IRIX_JOBS) + AC_CHECK_FUNC(jlimit_startjob, [AC_DEFINE(WITH_IRIX_JOBS)]) no_libsocket=1 no_libnsl=1 AC_DEFINE(BROKEN_INET_NTOA) On Tue, 21 Nov 2000, Pekka Savola wrote: > On Tue, 14 Nov 2000, Michael Stone wrote: > > > The IRIX job limits patch will only build on IRIX >= 6.5.7. I hacked up > > configure to do the checking, but I'm not sure of the configure.in > > syntax. Does this look legal? > > > > *-*-irix6*) > > CFLAGS="$CFLAGS -I/usr/local/include" > > LDFLAGS="$LDFLAGS" > > PATH="$PATH:/usr/etc" > > MANTYPE='$(CATMAN)' > > AC_DEFINE(WITH_IRIX_ARRAY) > > AC_DEFINE(WITH_IRIX_PROJECT) > > AC_DEFINE(WITH_IRIX_AUDIT) > > > > IFS=.fm > > set `uname -r` > > if test $2 -ge 5 ; then > > set `uname -R` > > if test $3 -gt 5 -o $4 -gt 7 ; then > > AC_DEFINE(WITH_IRIX_JOBS) > > fi > > fi > > unset IFS > > > > no_libsocket=1 > > no_libnsl=1 > > AC_DEFINE(BROKEN_INET_NTOA) > > ;; > > For me, compilation on Irix (uname -R: 6.5 6.5.9m) fails with: > > --- > ld32: ERROR 33 : Unresolved text symbol "jlimit_startjob" -- 1st referenced by session.o. > Use linker option -v to see when and which objects, archives and dsos are loaded. > ld32: INFO 152: Output file removed because of error. > --- > > And relating: > --- > session.c:1101: warning: implicit declaration of function 'limit_startjob' > --- > > Apparently not all people have job limits even though they may have rather > recent systems... > > From pekkas at netcore.fi Tue Nov 21 20:11:06 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 21 Nov 2000 11:11:06 +0200 (EET) Subject: Irix joblimits failure (was: Re: New snapshot) In-Reply-To: Message-ID: On Tue, 21 Nov 2000 mouring at etoh.eviladmin.org wrote: > Will this resolve the issue cleanly? Works for me; doesn't define WITH_IRIX_JOBS as it shouldn't. > --- ../openssh/configure.in Sat Nov 11 12:58:31 2000 > +++ configure.in Tue Nov 21 03:33:53 2000 > @@ -111,7 +111,7 @@ > AC_DEFINE(WITH_IRIX_ARRAY) > AC_DEFINE(WITH_IRIX_PROJECT) > AC_DEFINE(WITH_IRIX_AUDIT) > - AC_DEFINE(WITH_IRIX_JOBS) > + AC_CHECK_FUNC(jlimit_startjob, [AC_DEFINE(WITH_IRIX_JOBS)]) > no_libsocket=1 > no_libnsl=1 > AC_DEFINE(BROKEN_INET_NTOA) > > > On Tue, 21 Nov 2000, Pekka Savola wrote: > > > On Tue, 14 Nov 2000, Michael Stone wrote: > > > > > The IRIX job limits patch will only build on IRIX >= 6.5.7. I hacked up > > > configure to do the checking, but I'm not sure of the configure.in > > > syntax. Does this look legal? > > > > > > *-*-irix6*) > > > CFLAGS="$CFLAGS -I/usr/local/include" > > > LDFLAGS="$LDFLAGS" > > > PATH="$PATH:/usr/etc" > > > MANTYPE='$(CATMAN)' > > > AC_DEFINE(WITH_IRIX_ARRAY) > > > AC_DEFINE(WITH_IRIX_PROJECT) > > > AC_DEFINE(WITH_IRIX_AUDIT) > > > > > > IFS=.fm > > > set `uname -r` > > > if test $2 -ge 5 ; then > > > set `uname -R` > > > if test $3 -gt 5 -o $4 -gt 7 ; then > > > AC_DEFINE(WITH_IRIX_JOBS) > > > fi > > > fi > > > unset IFS > > > > > > no_libsocket=1 > > > no_libnsl=1 > > > AC_DEFINE(BROKEN_INET_NTOA) > > > ;; > > > > For me, compilation on Irix (uname -R: 6.5 6.5.9m) fails with: > > > > --- > > ld32: ERROR 33 : Unresolved text symbol "jlimit_startjob" -- 1st referenced by session.o. > > Use linker option -v to see when and which objects, archives and dsos are loaded. > > ld32: INFO 152: Output file removed because of error. > > --- > > > > And relating: > > --- > > session.c:1101: warning: implicit declaration of function 'limit_startjob' > > --- > > > > Apparently not all people have job limits even though they may have rather > > recent systems... > > > > > > -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From J.Horne at plymouth.ac.uk Tue Nov 21 22:26:04 2000 From: J.Horne at plymouth.ac.uk (John Horne) Date: Tue, 21 Nov 2000 11:26:04 -0000 (GMT) Subject: openssh kills the stty values? In-Reply-To: Message-ID: On 21-Nov-00 at 05:42:13 Garrick James wrote: > I do not have any hpux machines, but I cannot help wondering if this is > like the same problem we have (or had?) on Solaris (don't know if it was > ever fixed, but a work-around exists). > Yes, this was fixed for Solaris (in openssh 2.2.0?). > On Solaris, you end up with the same thing sometimes. Namely, your intr > key combination doesn't work. It turns out that this is only the case if > intr does not work in the environment from which sshd is launched (like > from a cron/at job or an ssh session in which the problem exists, for > example). > The problem for Solaris was that the control-c didn't work once you had logged in (as you say). The code was missing setting INTR to its default value. I.e. a previous disabling of INTR (or INT?) was still effective. (As far as I remember that is a vague description of the problem :-) The archives will have the details.) However, I have no idea about HPUX (don't use it here), although the problem does sound similar. Sorry. 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 mstone at cs.loyola.edu Tue Nov 21 22:57:53 2000 From: mstone at cs.loyola.edu (Michael Stone) Date: Tue, 21 Nov 2000 06:57:53 -0500 Subject: Irix joblimits failure (was: Re: New snapshot) In-Reply-To: ; from pekkas@netcore.fi on Tue, Nov 21, 2000 at 10:27:12AM +0200 References: <20001114095518.O17700@justice.loyola.edu> Message-ID: <20001121065753.Y17700@justice.loyola.edu> On Tue, Nov 21, 2000 at 10:27:12AM +0200, Pekka Savola wrote: > For me, compilation on Irix (uname -R: 6.5 6.5.9m) fails with: Ok. That was the next question. I wasn't sure if it would be in a maintenance release--apparantly it's not. :) Someone with a deeper knowledge of autoconf seems to have posted a working solution. -- Mike Stone From bjacke at suse.de Tue Nov 21 23:29:27 2000 From: bjacke at suse.de (=?iso-8859-1?Q?Bj=F6rn_Jacke?=) Date: Tue, 21 Nov 2000 13:29:27 +0100 Subject: blanks in filenames Message-ID: <20001121132927.A26686@suse.de> Hi, When there is a blank in the name scp doesn't work correctly: bjacke at lamarr:~ > scp -v telefon.cgi lamarr:a\ directory/ Executing: program /usr/bin/ssh host lamarr, user (unspecified), command scp -v -t ein directory/ Enter passphrase for RSA key 'unon at rzstud1': scp: ambiguous target bjacke at lamarr:~ > By the way ... -v seems to be broken for scp in openssh 2.3. I use openssh 2.3.0p1. Another problem which looks a bit more complicated to me are IPv6 IPs. They have : as delimiter so that this makes big problems if one wants to use a IPv6 IP (e.g. you don't have a name for a host but just the IP) and ssh also uses : for seperation of host and file name. Has anyone a good idea how to solve this problem? Ciao, Bj?rn -- Bj?rn Jacke ? E-Mail: bjacke at suse.de SuSE GmbH ? Schanz?ckerstr. 10 ? 90443 N?rnberg ? Germany -------------- 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/20001121/00c96249/attachment.bin From Ulrich.Windl at rz.uni-regensburg.de Tue Nov 21 23:46:27 2000 From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl) Date: Tue, 21 Nov 2000 13:46:27 +0100 Subject: openssh-2.3.0p1: problem with configure Message-ID: <3A1A7CAD.24444.1384CA4@localhost> I have two problems with configure in 2.3.0p1: zlib is installed in /usr/local on HP-UX 11.00, and configure fails to detect that. Worse, after "setenv LDFLAGS -L/usr/local/lib" configure is happy, but during make the zlib include file is not found. "setenv CFLAGS -I/usr/local/include" fixes that, but I feel that configure could be that smart too. Regards, Ulrich From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Nov 22 01:09:28 2000 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 21 Nov 2000 15:09:28 +0100 Subject: openssh-2.3.0p1: problem with configure In-Reply-To: <3A1A7CAD.24444.1384CA4@localhost>; from Ulrich.Windl@rz.uni-regensburg.de on Tue, Nov 21, 2000 at 01:46:27PM +0100 References: <3A1A7CAD.24444.1384CA4@localhost> Message-ID: <20001121150928.A19523@serv01.aet.tu-cottbus.de> On Tue, Nov 21, 2000 at 01:46:27PM +0100, Ulrich Windl wrote: > I have two problems with configure in 2.3.0p1: > > zlib is installed in /usr/local on HP-UX 11.00, and configure fails to > detect that. > > Worse, after "setenv LDFLAGS -L/usr/local/lib" configure is happy, but > during make the zlib include file is not found. > > "setenv CFLAGS -I/usr/local/include" fixes that, but I feel that > configure could be that smart too. That's a common limitation for automatic configuration. /usr/local is not a part of the usual search process of the HP-UX compiler and linker tools (I have gcc installed in /usr/local and it seems to automatically search /usr/local). Hence, configure fails to find packages located in /usr/local and you have to explicitely specify this either using--with-c/ldflags or by doing CC=cc CFLAGS="-Ae +O3 +DAportable" CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" ./configure (The CFLAGS my be different for you, but I already have this in my $HOME/bin for packages using autoconf :-) Having this said, zlib tends to be in /opt/zlib-something when installed from the HPUX Software and Porting Archive, so it probably makes not too much sense to try and search for it too many places and have the user specify it :-) 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 katzj at linuxpower.org Wed Nov 22 02:01:04 2000 From: katzj at linuxpower.org (Jeremy Katz) Date: Tue, 21 Nov 2000 07:01:04 -0800 Subject: blanks in filenames In-Reply-To: <20001121132927.A26686@suse.de>; from bjacke@suse.de on Tue, Nov 21, 2000 at 01:29:27PM +0100 References: <20001121132927.A26686@suse.de> Message-ID: <20001121070104.F16539@kotako.analogself.com> On Tuesday, November 21 2000, Bj?rn Jacke said: > When there is a blank in the name scp doesn't work correctly: > > bjacke at lamarr:~ > scp -v telefon.cgi lamarr:a\ directory/ > Executing: program /usr/bin/ssh host lamarr, user (unspecified), command > scp -v -t ein directory/ > Enter passphrase for RSA key 'unon at rzstud1': > scp: ambiguous target > bjacke at lamarr:~ > You need to double escape the space. Otherwise, your escaping only affects the local shell and not the shell invoked on the remote machine. So use something like scp -v telefon.cgi lamarr:a\\\ directory/ Cheers, Jeremy -- Jeremy Katz katzj at linuxpower.org | jlkatz at eos.ncsu.edu http://linuxpower.org | Developer, NCSU Realm Kit for Red Hat Linux GPG fingerprint: 367E 8B6B 5E57 2BDB 972A 4D73 C83C B4E8 89FE 392D QOTD: After years of research, scientists recently reported that there is, indeed, arroz in Spanish Harlem. -------------- 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/20001121/0c8d096f/attachment.bin From dcp at sgi.com Wed Nov 22 02:07:52 2000 From: dcp at sgi.com (Dennis Parker) Date: Tue, 21 Nov 2000 09:07:52 -0600 Subject: Irix joblimits failure (was: Re: New snapshot) References: Message-ID: <3A1A8FC8.6AA53264@sgi.com> mouring at etoh.eviladmin.org wrote: > > Will this resolve the issue cleanly? > > - Ben > > --- ../openssh/configure.in Sat Nov 11 12:58:31 2000 > +++ configure.in Tue Nov 21 03:33:53 2000 > @@ -111,7 +111,7 @@ > AC_DEFINE(WITH_IRIX_ARRAY) > AC_DEFINE(WITH_IRIX_PROJECT) > AC_DEFINE(WITH_IRIX_AUDIT) > - AC_DEFINE(WITH_IRIX_JOBS) > + AC_CHECK_FUNC(jlimit_startjob, [AC_DEFINE(WITH_IRIX_JOBS)]) > no_libsocket=1 > no_libnsl=1 > AC_DEFINE(BROKEN_INET_NTOA) Job limits is present on Irix 6.5.7f or greater. It won't be present on any m stream system, regardless of the release level. That may account for some of the problems. Checking for the presence of the "jlimit_startjob" function should take care of all the situations I can think of. - Dennis Parker From Philippe.WILLEM at urssaf.fr Wed Nov 22 02:13:56 2000 From: Philippe.WILLEM at urssaf.fr (Philippe WILLEM) Date: Tue, 21 Nov 2000 16:13:56 +0100 Subject: =?iso-8859-1?Q?R=E9f._:_openssh-2.3.0p1:_problem_with_configure?= Message-ID: <4125699E.0053B2C9.00@contact31.cirso.fr> As I post it earlier on the list you can specify this with args to configure: ./configure --prefix=$RUN_SSH --with-ldflags=-L$PATH_ZLIB --with-ssl-dir=$PATH_SSL --with-cflags="-I$PATH_ZLIB_INCLUDE" In fact, I do compile openssh this way. I put all my params and action in a personal makefile that compile all : openssl, zlib & openssh but a simple shell can do almost the same job. "Ulrich Windl" sur 21/11/2000 13:46:27 Pour : openssh-unix-dev at mindrot.org cc : (ccc : Philippe WILLEM/CER59/REC) Objet : openssh-2.3.0p1: problem with configure I have two problems with configure in 2.3.0p1: zlib is installed in /usr/local on HP-UX 11.00, and configure fails to detect that. Worse, after "setenv LDFLAGS -L/usr/local/lib" configure is happy, but during make the zlib include file is not found. "setenv CFLAGS -I/usr/local/include" fixes that, but I feel that configure could be that smart too. Regards, Ulrich From bjacke at suse.de Wed Nov 22 02:18:08 2000 From: bjacke at suse.de (=?iso-8859-1?Q?Bj=F6rn_Jacke?=) Date: Tue, 21 Nov 2000 16:18:08 +0100 Subject: blanks in filenames In-Reply-To: <20001121070104.F16539@kotako.analogself.com>; from katzj@linuxpower.org on Tue, Nov 21, 2000 at 07:01:04 -0800 References: <20001121132927.A26686@suse.de> <20001121070104.F16539@kotako.analogself.com> Message-ID: <20001121161808.A7463@suse.de> On 2000-11-21 at 07:01 -0800 Jeremy Katz sent off: > You need to double escape the space. Otherwise, your escaping only > affects the local shell and not the shell invoked on the remote machine. > So use something like > scp -v telefon.cgi lamarr:a\\\ directory/ great, that works but it's a realy weird way to do such simple things. Almost no one will have the idea to do it this way. The commercial ssh also just need a simple quotation. Wouldn't it be a good idea to let openssh do the quoting for the remote machine? Cheers Bj?rn -- Bj?rn Jacke ? E-Mail: bjacke at suse.de SuSE GmbH ? Schanz?ckerstr. 10 ? 90443 N?rnberg ? Germany -------------- 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/20001121/7e2d46dc/attachment.bin From hans.plesser at itf.nlh.no Wed Nov 22 03:31:39 2000 From: hans.plesser at itf.nlh.no (Hans Ekkehard Plesser) Date: Tue, 21 Nov 2000 17:31:39 +0100 (MET) Subject: sftp client for OpenSSH / Emacs Ange-FTP Message-ID: <14874.41835.465617.559053@itfhep.nlh.no> Hi! Fine that OpenSSH has sftp server support now. But what client to use? I'd particularly like one that smoothlessly integrates with ange-ftp in emacs. Thanks in advance for any hints! Hans --------------------------------------------------------------------- Dr. Hans Ekkehard Plesser Tel. : +47 6494 8832 Institutt for tekniske fag Fax : +47 6494 8810 Norges landbruksh?gskole e-mail: hans.plesser at itf.nlh.no N-1432 ?s, Norway WWW : arken.nlh.no/~itfhep --------------------------------------------------------------------- From xercist at lammah.com Wed Nov 22 04:06:57 2000 From: xercist at lammah.com (xercist) Date: Tue, 21 Nov 2000 10:06:57 -0700 Subject: identd w/ openssh Message-ID: <20001121100657.A27361@lammah.com> I've just realised that when a user uses ssh to connect to a machine, then sets up a port forward and uses it, the resulting connection is reported by identd as belonging to root. While I realise ident is not any kind of secure authentication, it doesn't make much sense to make it even less so by letting any user create connections reported to be made by root. The sshd should drop all root privs and use only the connecting user's id before setting up the process that forwards the connection. Your opinions? -- -*% % % % % % % % % % % % % % % % *- -* xercist *- -* xercist at mindless.com *- -* % % % % % % % % % % % % % % % %*- -------------- 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/20001121/5d528335/attachment.bin From OPoplawski at cqg.com Wed Nov 22 04:31:23 2000 From: OPoplawski at cqg.com (Orion Poplawski) Date: Tue, 21 Nov 2000 10:31:23 -0700 Subject: Openssh-2.2.0pl1 for UnixWare 7.1 Message-ID: UnixWare (not sure when, 7? 7.1?) introduces a new sockaddr_in structure that splits the 16 bit family entity into an 8-bit length and an 8-bit familiy memember: (from in.h): struct sockaddr_in { #ifdef __NEW_SOCKADDR__ sa_len_t sin_len; /* 8-bit structure length */ #endif sa_family_t sin_family; /* 8/16-bit address family (AF_INET) */ in_port_t sin_port; /* 16-bit port number */ struct in_addr sin_addr; /* 32-bit internet address */ unsigned char sin_zero[8]; /* optional with TLI */ }; This causes problems with the getaddrinfo() call in canohost.c, since the family it uses is incorrect. I'm not sure what the best way to support this in fake-socket.h is, but I thought I'd point it out. - Orion ----------------------------------------------------------------------- Orion Poplawski, OPoplawski at cqg.com, Tel: (303) 440-4462x17, Fax: -4507 CQG, Inc., 250 Arapahoe Avenue, Boulder, CO 80302 From mouring at etoh.eviladmin.org Wed Nov 22 08:00:42 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 21 Nov 2000 15:00:42 -0600 (CST) Subject: Openssh-2.2.0pl1 for UnixWare 7.1 In-Reply-To: Message-ID: OpenSSH 2.3.0p1 has been released.. With a snapshot of 2.3.0p2 at: http://www.mindrot.org/misc/openssh/. Please retest using either of theses two newer releases. - Ben On Tue, 21 Nov 2000, Orion Poplawski wrote: > UnixWare (not sure when, 7? 7.1?) introduces a new sockaddr_in structure > that splits the 16 bit family entity into an 8-bit length and an 8-bit > familiy memember: (from in.h): > > struct sockaddr_in { > #ifdef __NEW_SOCKADDR__ > sa_len_t sin_len; /* 8-bit structure length */ > #endif > sa_family_t sin_family; /* 8/16-bit address family (AF_INET) */ > in_port_t sin_port; /* 16-bit port number */ > struct in_addr sin_addr; /* 32-bit internet address */ > unsigned char sin_zero[8]; /* optional with TLI */ > }; > > This causes problems with the getaddrinfo() call in canohost.c, since the > family it uses is incorrect. > > I'm not sure what the best way to support this in fake-socket.h is, but I > thought I'd point it out. > > - Orion > > ----------------------------------------------------------------------- > Orion Poplawski, OPoplawski at cqg.com, Tel: (303) 440-4462x17, Fax: -4507 > CQG, Inc., 250 Arapahoe Avenue, Boulder, CO 80302 > > > From OPoplawski at cqg.com Wed Nov 22 07:49:24 2000 From: OPoplawski at cqg.com (Orion Poplawski) Date: Tue, 21 Nov 2000 13:49:24 -0700 Subject: Openssh-2.2.0pl1 for UnixWare 7.1 In-Reply-To: Message-ID: Fixed in the snap shot. Thanks. - Orion > -----Original Message----- > From: mouring at etoh.eviladmin.org [mailto:mouring at etoh.eviladmin.org] > Sent: Martes 21 de Noviembre de 2000 2:01 PM > To: Orion Poplawski > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Openssh-2.2.0pl1 for UnixWare 7.1 > > > > OpenSSH 2.3.0p1 has been released.. With a snapshot of 2.3.0p2 > at: http://www.mindrot.org/misc/openssh/. Please retest using either of > theses two newer releases. > > - Ben > > On Tue, 21 Nov 2000, Orion Poplawski wrote: > > > UnixWare (not sure when, 7? 7.1?) introduces a new sockaddr_in structure > > that splits the 16 bit family entity into an 8-bit length and an 8-bit > > familiy memember: (from in.h): > > > > struct sockaddr_in { > > #ifdef __NEW_SOCKADDR__ > > sa_len_t sin_len; /* 8-bit structure length */ > > #endif > > sa_family_t sin_family; /* 8/16-bit address family (AF_INET) */ > > in_port_t sin_port; /* 16-bit port number */ > > struct in_addr sin_addr; /* 32-bit internet address */ > > unsigned char sin_zero[8]; /* optional with TLI */ > > }; > > > > This causes problems with the getaddrinfo() call in canohost.c, > since the > > family it uses is incorrect. > > > > I'm not sure what the best way to support this in fake-socket.h > is, but I > > thought I'd point it out. > > > > - Orion > > > > ----------------------------------------------------------------------- > > Orion Poplawski, OPoplawski at cqg.com, Tel: (303) 440-4462x17, Fax: -4507 > > CQG, Inc., 250 Arapahoe Avenue, Boulder, CO 80302 > > > > > > > From Stephan.Hendl at lds.brandenburg.de Wed Nov 22 16:38:21 2000 From: Stephan.Hendl at lds.brandenburg.de (Stephan Hendl) Date: Wed, 22 Nov 2000 06:38:21 +0100 Subject: Antw: Re: openssh kills the stty values? Message-ID: Hi, thanks for your answer. I can reproduce your error in my HP-UX system and solved it ;-)). I built socalled software-depots for distributing the openssh-package and put the start command in the postinstall-script. The shell of this postinstall script has the bahavior that intr ^C won't work properly. So I did your trick with "/sbin/init.d/sshd stop/start" from a shell where ^C works and everything is ok now. Thanks oncemore 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 >>> Garrick James 21.11.2000 06:42:13 >>> I do not have any hpux machines, but I cannot help wondering if this is like the same problem we have (or had?) on Solaris (don't know if it was ever fixed, but a work-around exists). On Solaris, you end up with the same thing sometimes. Namely, your intr key combination doesn't work. It turns out that this is only the case if intr does not work in the environment from which sshd is launched (like from a cron/at job or an ssh session in which the problem exists, for example). The work-around on Solaris is to make sure that sshd starts up in an environment in which intr already works (i.e. at system startup, at the console, or in a telnet session). Once sshd is "bootstrapped" in this manner, intr works fine in ssh sessions. I have my system init script for openssh (/etc/init.d/openssh) written so that it takes the argument "restart" in addition to "start" and "stop". With the restart argument, the script simply does: /etc/init.d/openssh stop /etc/init.d/openssh start This makes it nice so that from within an ssh session that has a working intr, I can issue: nohup /etc/init.d/openssh restart I get booted out, of course, but sshd starts up again with intr working. Anyway, I don't know for sure that you are seeing the same problem, but I hope this helped. BTW, anyone know if this problem was ever fixed on Solaris? I remember reading a message that someone tracked down in the source were the problem was, but I cannot remember if a patch was ever submitted and integrated. -Garrick James On Mon, 20 Nov 2000, Stephan Hendl wrote: > Hi all, > > I found that on some HP-UX 11 machines running openssh-2.3.0p1 the > default values for intr in stty don't work. The problem is that stty > shows the correct values but they don' work and I cannot det the > values to others. Once I connect via telnet or rlogin I can use the > intr-sequence. > > Any ideas? > > Thanks > 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 pekkas at netcore.fi Wed Nov 22 17:57:00 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 22 Nov 2000 08:57:00 +0200 (EET) Subject: Irix joblimits failure (was: Re: New snapshot) In-Reply-To: <3A1A8FC8.6AA53264@sgi.com> Message-ID: On Tue, 21 Nov 2000, Dennis Parker wrote: > Job limits is present on Irix 6.5.7f or greater. It won't be present on > any m stream system, regardless of the release level. That may account > for some of the problems. Checking for the presence of the > "jlimit_startjob" function should take care of all the situations I can > think of. Another Irix issue entirely: There is a bug number 802838 in SGI DB opened on 09/25/00 requesting the inclusion of /dev/{u,}random. Is this being worked on? :-) -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From JSO at EUROPAY.COM Wed Nov 22 18:03:13 2000 From: JSO at EUROPAY.COM (=?iso-8859-1?Q?SOETE_Jo=EBl?=) Date: Wed, 22 Nov 2000 08:03:13 +0100 Subject: sftp client for OpenSSH / Emacs Ange-FTP Message-ID: Hello Hans, Trying to find the same thing, I found this: http://www.la-samhna.de/hsftp/index.html Sincerely, I not yet try but seems very interesting. Joel ********************************************************************** This e-mail and any attachments to it may contain confidential information which is strictly intended for the use of the authorised recipient. If you have received this e-mail in error, please delete it and notify the sender by replying to this e-mail. Thank you for your co-operation. ********************************************************************** From pekkas at netcore.fi Wed Nov 22 18:12:50 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 22 Nov 2000 09:12:50 +0200 (EET) Subject: sftp client for OpenSSH / Emacs Ange-FTP In-Reply-To: Message-ID: On Wed, 22 Nov 2000, SOETE Jo?l wrote: > Trying to find the same thing, I found this: > > http://www.la-samhna.de/hsftp/index.html > > Sincerely, I not yet try but seems very interesting. AFAIK, there are some utils with 'sftp' in their names that have nothing in common with the SSH.COM sftp protocol except that they use ssh as a tunnel. I'd be rather surprised if that one worked with sftp-server. There's an sftp client in SSH.COM's SSH 2.3.0 (which is ~GPL for Linux etc.). It requires some tweaking. --- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From JSO at EUROPAY.COM Wed Nov 22 18:22:16 2000 From: JSO at EUROPAY.COM (=?iso-8859-1?Q?SOETE_Jo=EBl?=) Date: Wed, 22 Nov 2000 08:22:16 +0100 Subject: sftp client for OpenSSH / Emacs Ange-FTP Message-ID: Hello, > There's an sftp client in SSH.COM's SSH 2.3.0 (which is ~GPL for Linux > etc.). It requires some tweaking. Nice to learn. Thanks a lot, Joel ********************************************************************** This e-mail and any attachments to it may contain confidential information which is strictly intended for the use of the authorised recipient. If you have received this e-mail in error, please delete it and notify the sender by replying to this e-mail. Thank you for your co-operation. ********************************************************************** From mouring at etoh.eviladmin.org Wed Nov 22 19:33:13 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 22 Nov 2000 02:33:13 -0600 (CST) Subject: sftp client for OpenSSH / Emacs Ange-FTP In-Reply-To: Message-ID: On Wed, 22 Nov 2000, Pekka Savola wrote: > On Wed, 22 Nov 2000, SOETE Jo?l wrote: > > Trying to find the same thing, I found this: > > > > http://www.la-samhna.de/hsftp/index.html > > > > Sincerely, I not yet try but seems very interesting. > > AFAIK, there are some utils with 'sftp' in their names that have nothing > in common with the SSH.COM sftp protocol except that they use ssh > as a tunnel. > > I'd be rather surprised if that one worked with sftp-server. > > There's an sftp client in SSH.COM's SSH 2.3.0 (which is ~GPL for Linux > etc.). It requires some tweaking. > Umm... and where is this 'magical' GPL licensing for Linux? All licensing I see is the extremely restrict 'If you use this for anything that even SORTA smells like commerical.. you owe us bigtime'. I'd love to see anything differently. I even just downloaded the source to verify. Because if sftp was under GPL style licensing then it could be folded into the OpenSSH with of course Theo's permission. =) "find . -type f -print | xargs grep GPL" Only shows up lib/sshcrypt/des.c which is under dual license. For reference to the SSH.com's licensing see: http://www.ssh.com/products/ssh/ssh_license_agreement.html - Ben From pekkas at netcore.fi Wed Nov 22 18:47:44 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 22 Nov 2000 09:47:44 +0200 (EET) Subject: sftp client for OpenSSH / Emacs Ange-FTP In-Reply-To: Message-ID: On Wed, 22 Nov 2000 mouring at etoh.eviladmin.org wrote: > On Wed, 22 Nov 2000, Pekka Savola wrote: > > > On Wed, 22 Nov 2000, SOETE Jo?l wrote: > > > Trying to find the same thing, I found this: > > > > > > http://www.la-samhna.de/hsftp/index.html > > > > > > Sincerely, I not yet try but seems very interesting. > > > > AFAIK, there are some utils with 'sftp' in their names that have nothing > > in common with the SSH.COM sftp protocol except that they use ssh > > as a tunnel. > > > > I'd be rather surprised if that one worked with sftp-server. > > > > There's an sftp client in SSH.COM's SSH 2.3.0 (which is ~GPL for Linux > > etc.). It requires some tweaking. > > > Umm... and where is this 'magical' GPL licensing for Linux? All licensing > I see is the extremely restrict 'If you use this for anything that even > SORTA smells like commerical.. you owe us bigtime'. > > I'd love to see anything differently. I even just downloaded the source > to verify. Because if sftp was under GPL style licensing then it could be > folded into the OpenSSH with of course Theo's permission. =) They announced a new license for 2.3.0, and I somehow associated that with GPL because they wouldn't charge anything for it on Linux or *BSD. At the time time there was talk about the licensing restrictions wrt. patching. Of course, GPL is really not about the price tag. My mistake, sorry. -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From Ulrich.Windl at rz.uni-regensburg.de Wed Nov 22 19:41:45 2000 From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl) Date: Wed, 22 Nov 2000 09:41:45 +0100 Subject: 2.3.0p1: terminal baud rate is 300 Message-ID: <3A1B94D3.10566.676B1A@localhost> When using OpenSSH 2.3.0p1 on HP-UX 11.00 the terminal's baud rate is 300, causing non-desired effects in vi and Emacs: vi only shows a few lines, and Emacs adds a huge delay after each line of output. When connecting via TELNET, I get at least 9600 baud. Should the login procedure mess with the baud rate? Regards, Ulrich P.S. I'm not subscribed to the list. From Markus.Friedl at informatik.uni-erlangen.de Wed Nov 22 20:03:23 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 22 Nov 2000 10:03:23 +0100 Subject: sftp client for OpenSSH / Emacs Ange-FTP In-Reply-To: ; from pekkas@netcore.fi on Wed, Nov 22, 2000 at 09:12:50AM +0200 References: Message-ID: <20001122100323.A19277@faui02.informatik.uni-erlangen.de> On Wed, Nov 22, 2000 at 09:12:50AM +0200, Pekka Savola wrote: > There's an sftp client in SSH.COM's SSH 2.3.0 (which is ~GPL for Linux > etc.). It requires some tweaking. it's not GPL at all and even if it was, it would never be included in openssh. the source is too different and the clicese conflict. if you need a sftp for unix, just try sftp from xbill.org (different protocol, same name) or hack the ssh.com-sftp protocol into this client. openssh's sftp-server is tartgetedintended for windows users. unix users have more ways for transfering files. -markus From jfulmer at appin.org Thu Nov 23 02:20:58 2000 From: jfulmer at appin.org (John Fulmer) Date: Wed, 22 Nov 2000 09:20:58 -0600 (CST) Subject: SSH1 tunneling problems. In-Reply-To: Message-ID: I've noticed this same problemm using local forwarding via OpenSSH in SSH1 mode, both 2.3.0p1 and 2.2.0p1. The problem is that the tunnel (actually the entire ssh session) freezes periodically if the tunnel has several TCP connections initiated within a short period of time, and the ssh session must be broken and restarted. The best example is if tunneling from a browser to a HTTP proxy server on the other end. I have the following in my ssh_config: Host mull LocalForward 2143 skye:143 LocalForward 2125 skye:25 LocalForward 9119 skye:9119 ForwardAgent no ForwardX11 no 'mull' is a gateway machine, while 'skye' is my e-mail/http proxy server. I connect to mull, and then point my browser to "localhost port 9119" for my HTTP proxy. After an indeterminate amount of time, maybe 5 mintues, maybe an hour, the ssh session will freeze, usually after many 'endpoint not connected' error messages. The only appears to happen when using a locally forwarded port and only if that port is loaded by multiple connections. This problem does not appear using SSH2, which is what I am happily using right now. The client and server are Linux 2.2.17, although the server is a DEC Alpha running Redhat, while the client is i386. I have also experienced this with a i386 Linux server, running 2.2.14. Thanks, jf From dcp at sgi.com Thu Nov 23 03:28:36 2000 From: dcp at sgi.com (Dennis Parker) Date: Wed, 22 Nov 2000 10:28:36 -0600 Subject: Irix joblimits failure (was: Re: New snapshot) References: <3A1A8FC8.6AA53264@sgi.com> Message-ID: <3A1BF434.D3D4B10B@sgi.com> Dennis Parker wrote: > > mouring at etoh.eviladmin.org wrote: > > > > Will this resolve the issue cleanly? > > > > - Ben > > > > --- ../openssh/configure.in Sat Nov 11 12:58:31 2000 > > +++ configure.in Tue Nov 21 03:33:53 2000 > > @@ -111,7 +111,7 @@ > > AC_DEFINE(WITH_IRIX_ARRAY) > > AC_DEFINE(WITH_IRIX_PROJECT) > > AC_DEFINE(WITH_IRIX_AUDIT) > > - AC_DEFINE(WITH_IRIX_JOBS) > > + AC_CHECK_FUNC(jlimit_startjob, [AC_DEFINE(WITH_IRIX_JOBS)]) > > no_libsocket=1 > > no_libnsl=1 > > AC_DEFINE(BROKEN_INET_NTOA) > > Job limits is present on Irix 6.5.7f or greater. It won't be present on > any m stream system, regardless of the release level. That may account > for some of the problems. Checking for the presence of the > "jlimit_startjob" function should take care of all the situations I can > think of. I want to add one more clarification. You must have an Irix 6.5.7f or greater system to build ssh with job limits enabled. Once built, the resultant ssh should work properly on any Irix 6.5.x m or f system. It will use job limits on systems where it's installed and will silently ignore the job limits stuff on systems where it is not installed. - Dennis From gert at greenie.muc.de Thu Nov 23 04:40:15 2000 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 22 Nov 2000 18:40:15 +0100 Subject: 2.3.0p1: terminal baud rate is 300 In-Reply-To: <3A1B94D3.10566.676B1A@localhost>; from Ulrich Windl on Wed, Nov 22, 2000 at 09:41:45AM +0100 References: <3A1B94D3.10566.676B1A@localhost> Message-ID: <20001122184015.B26709@greenie.muc.de> Hi, On Wed, Nov 22, 2000 at 09:41:45AM +0100, Ulrich Windl wrote: > When using OpenSSH 2.3.0p1 on HP-UX 11.00 the terminal's baud rate is > 300, causing non-desired effects in vi and Emacs: vi only shows a few > lines, and Emacs adds a huge delay after each line of output. > > When connecting via TELNET, I get at least 9600 baud. > > Should the login procedure mess with the baud rate? I'd say that setting up a pty "should" (in the RFC sense) include setting a few things to decent values, like the baud rate. So yes, sshd should do this. Login itself doesn't (usually) do this, because it gets called on a tty that is already set up, for example by "getty" on serial lines/console. 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 ms at speakeasy.org Thu Nov 23 09:14:52 2000 From: ms at speakeasy.org (michael salmon) Date: Wed, 22 Nov 2000 14:14:52 -0800 Subject: implementing port forward restrictions Message-ID: <00112214145203.24300@is10.6x4.org> hi folks, right now im implementing a quick hack to restrict ports the server will allow to be forwarded. This is to heighten security from clients accessing a server behind a firewall and as far as I could tell this is not possible with ssh so far. I think this is a reasonable feature for a release and shouldnt be too hard to implement in a way that follows the setup already used in the config and sshd handling of connections. I searched the mailing-list archives and found a few small references to it but none implied it was being worked on. When I finish this if the list wants the diffs I'd be happy to supply them. I'd like the opinion of the other developers as to a key in the sshd_config that would be obvious yet not too long to define the ports, and the layout. I was thinking HostAllowsPortsForwarded 143 2401 etc... space delimited numbers. cheers, michael salmon From markus.friedl at informatik.uni-erlangen.de Thu Nov 23 08:27:09 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 22 Nov 2000 22:27:09 +0100 Subject: 2.3.0p1: terminal baud rate is 300 In-Reply-To: <3A1B94D3.10566.676B1A@localhost>; from Ulrich.Windl@rz.uni-regensburg.de on Wed, Nov 22, 2000 at 09:41:45AM +0100 References: <3A1B94D3.10566.676B1A@localhost> Message-ID: <20001122222709.C7352@folly> does this happen with protocol 1 or 2? openssh's protocol 2 implementation does not transfer the tty modes to the server side (protocol 1 does, who wants to implement this?). -markus On Wed, Nov 22, 2000 at 09:41:45AM +0100, Ulrich Windl wrote: > When using OpenSSH 2.3.0p1 on HP-UX 11.00 the terminal's baud rate is > 300, causing non-desired effects in vi and Emacs: vi only shows a few > lines, and Emacs adds a huge delay after each line of output. > > When connecting via TELNET, I get at least 9600 baud. > > Should the login procedure mess with the baud rate? > > Regards, > Ulrich > P.S. I'm not subscribed to the list. > > From markus.friedl at informatik.uni-erlangen.de Thu Nov 23 08:23:25 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 22 Nov 2000 22:23:25 +0100 Subject: identd w/ openssh In-Reply-To: <20001121100657.A27361@lammah.com>; from xercist@lammah.com on Tue, Nov 21, 2000 at 10:06:57AM -0700 References: <20001121100657.A27361@lammah.com> Message-ID: <20001122222325.A7352@folly> On Tue, Nov 21, 2000 at 10:06:57AM -0700, xercist wrote: > The sshd should drop all root privs and use only the connecting user's id > before setting up the process that forwards the connection. Your opinions? go on, if you can provide a portable patch for this problem :) -markus From andreas.hartmann at rwg.de Thu Nov 23 00:50:36 2000 From: andreas.hartmann at rwg.de (Andreas Hartmann) Date: Wed, 22 Nov 2000 14:50:36 +0100 Subject: openssh 2.3.0p1: chan_read_failed for istate 8 Message-ID: <3A1BCF2C.A3BC5D72@rwg.de> Hallo all! I've found a repeatable problem concerning openssh 2.3.0p1 running on a Linux-box with kernel 2.2.17. I compiled ssh from sources with pam-support. Let me describe what I'm doing: rsync -e ssh --delete --exclude "/Daten/test*" --exclude /Daten/anonymous --exclude /Daten/comp_logs --exclude /Daten/ehemalige_rwgsysm/cache --exclude /Daten/CONFIGMAN/DATAIN/CONFIGMAN/DATAIN -va root at sysman-ftp:/Daten /Daten After some time of running rsync, I get in /var/log/warn of the ssh-server the following message: sshd[16709]: error: channel 0: internal error: we do not read, but chan_read_failed for istate 8 and the session has been broken (it breakes at different points, not always at the same position). In the mailinglist, I found a patch from John Horne (15.11.2000), which I applied. But the problem consists even with the patch, but now without the message in warnings. Now, I enabled debugging in ssh_config. This is what ssh-client with debugging says (with the above command; a lot of output (more than 10.000 files) of normal working rsync cutted): debug: Seeding random number generator debug: ssh_connect: getuid 0 geteuid 0 anon 0 debug: Connecting to sysman-ftp [10.48.1.77] port 22. debug: Seeding random number generator debug: Allocated local port 630. 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 debug: Local version string SSH-2.0-OpenSSH_2.3.0p1 debug: send KEXINIT debug: done debug: wait KEXINIT debug: got kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha 1 debug: got kexinit: ssh-dss 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 lysa tor.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 lysa tor.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 3des-cbc hmac-sha1 none debug: kex: client->server 3des-cbc 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: 524/1024 debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. debug: Got SSH2_MSG_KEXDH_REPLY. debug: Host 'sysman-ftp' is known and matches the DSA host key. debug: bits set: 535/1024 debug: len 55 datafellows 0 debug: dsa_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 debug: next auth method to try is publickey debug: try pubkey: /root/.ssh/id_dsa debug: read DSA private key done [now, the rsync-command is running and datas are sent ...] debug: client_input_channel_req: rtype exit-status reply 0 debug: channel 0: rcvd eof debug: channel 0: output open -> drain debug: channel 0: rcvd close debug: channel 0: input open -> closed debug: channel 0: close_read debug: channel 0: obuf empty debug: channel 0: output drain -> closed debug: channel 0: close_write debug: channel 0: send close debug: channel 0: full closed2 debug: channel_free: channel 0: status: The following connections are open: #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1) debug: Transferred: stdin 0, stdout 0, stderr 0 bytes in 5.1 seconds debug: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug: Exit status 0 unexpected EOF in read_timeout I'm wondering about the message of ssh debug, that no data has been transferred. This is not correct. There has been a lot of data transferred until this message! I'm using this command for about half a year (some versions of ssh ago) and had no problems until the last change of the version from 2.2.0p1 to 2.3.0p1. Could you please help me? If you have some more questions, feel free to ask. I can do tests for you if you want to! Thanks in advance Kind regards Andreas Hartmann From markus.friedl at informatik.uni-erlangen.de Thu Nov 23 08:14:42 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 22 Nov 2000 22:14:42 +0100 Subject: fds closed after SIGCHLD bug still in newest version (fwd) Message-ID: <20001122221442.D1226@folly> can someone confirm this? it does not happen on openbsd. -------------- next part -------------- An embedded message was scrubbed... From: Florian Wunderlich Subject: Re: fds closed after SIGCHLD bug still in newest version Date: Wed, 22 Nov 2000 14:44:17 +0100 Size: 3926 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001122/c2ab2a31/attachment.mht From markus.friedl at informatik.uni-erlangen.de Thu Nov 23 08:24:46 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 22 Nov 2000 22:24:46 +0100 Subject: SSH1 tunneling problems. In-Reply-To: ; from jfulmer@appin.org on Wed, Nov 22, 2000 at 09:20:58AM -0600 References: Message-ID: <20001122222446.B7352@folly> what does ssh -v say? does it happen for ssh-2, too? On Wed, Nov 22, 2000 at 09:20:58AM -0600, John Fulmer wrote: > I've noticed this same problemm using local forwarding via OpenSSH in SSH1 > mode, both 2.3.0p1 and 2.2.0p1. The problem is that the tunnel (actually > the entire ssh session) freezes periodically if the tunnel has several TCP > connections initiated within a short period of time, and the ssh session > must be broken and restarted. > > The best example is if tunneling from a browser to a HTTP proxy server on > the other end. I have the following in my ssh_config: > > Host mull > LocalForward 2143 skye:143 > LocalForward 2125 skye:25 > LocalForward 9119 skye:9119 > ForwardAgent no > ForwardX11 no > > > 'mull' is a gateway machine, while 'skye' is my e-mail/http proxy server. > I connect to mull, and then point my browser to "localhost port 9119" for > my HTTP proxy. > > After an indeterminate amount of time, maybe 5 mintues, maybe an hour, the > ssh session will freeze, usually after many 'endpoint not connected' error > messages. The only appears to happen when using a locally forwarded port > and only if that port is loaded by multiple connections. This problem > does not appear using SSH2, which is what I am happily using right now. > > The client and server are Linux 2.2.17, although the server is a DEC Alpha > running Redhat, while the client is i386. I have also experienced this > with a i386 Linux server, running 2.2.14. > > Thanks, > > jf > > > From linuxfreak at partition.com Thu Nov 23 06:42:56 2000 From: linuxfreak at partition.com (Terry Wilson) Date: 22 Nov 2000 19:42:56 -0000 Subject: possible portability bug in bsd-getcwd.c Message-ID: <20001122194256.24274.qmail@callisto.nitronet.net> I have Red Hat Linux 6.2; kernel 2.2.14; glibc 2.1.3, and downloaded portable OpenSSH 2.3.0. make choked on lines 172, 189, 209, 210 on the "dp->d_namlen" expression. dp is a pointer to an object of dirent type declared in my /usr/src/linux/include/linux/dirent.h header file. The downside is that struct dirent in that file does not have a d_namlen member. Based on the name, and two associated calls to bcopy() function, it seems like d_namlen describes the length of the dirent member d_name. I have noted in my dirent.h that d_name is a char array of explicit length 256. I'm thinking about attempting to compensate by regex replacing dp->d_namlen with a #defined constant of 255, unless there is something better. I'm a little worried that 255 might somehow frag up bup or bpt as I am not that familiar with this code. Any comments or suggestions? Terry Wilson aka Tux the Linux Freak ______________________________________________________________________ Get Your Own Private, Free Email Account at http://www.dotcomemail.com Now With Over 1,500 Com, Net, and Org Domains to Choose From! From karn at ka9q.net Thu Nov 23 10:36:45 2000 From: karn at ka9q.net (Phil Karn) Date: Wed, 22 Nov 2000 15:36:45 -0800 Subject: SSH1 tunneling problems. In-Reply-To: (message from John Fulmer on Wed, 22 Nov 2000 09:20:58 -0600 (CST)) References: Message-ID: <200011222336.PAA04785@homer.ka9q.net> >I've noticed this same problemm using local forwarding via OpenSSH in SSH1 >mode, both 2.3.0p1 and 2.2.0p1. The problem is that the tunnel (actually >the entire ssh session) freezes periodically if the tunnel has several TCP >connections initiated within a short period of time, and the ssh session >must be broken and restarted. As I regularly websurf over a SSH tunnel, I've seen this exact problem occur *many many* times, and for many OpenSSH versions prior to 2.3.0. In fact, it has occurred ever since I switched from the original SSH to OpenSSH. This is also on Linux 2.2.17. Good to hear that using ssh2 is a workaround; I'll try that. Phil From pekkas at netcore.fi Thu Nov 23 11:55:40 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 23 Nov 2000 02:55:40 +0200 (EET) Subject: fds closed after SIGCHLD bug still in newest version (fwd) In-Reply-To: <20001122221442.D1226@folly> Message-ID: On Wed, 22 Nov 2000, Markus Friedl wrote: > can someone confirm this? it does not happen on openbsd. Confirmed. This happens only when using SSH2. FreeBSD OpenSSH 2.2.0 -> RHL 6.2 OpenSSH 2.3.0p2 (SNAP) fail as well as RHL 7.0 OpenSSH 2.3.0p1 -> RHL 6.2 OpenSSH 2.3.0p2 (SNAP). Some output from RHL <-> RHL: --- working ssh1 session --- debug1: PAM establishing creds debug1: Entering interactive session. debug1: fd 7 setting O_NONBLOCK debug1: fd 7 IS O_NONBLOCK debug1: fd 9 setting O_NONBLOCK debug1: server_init_dispatch_13 debug1: server_init_dispatch_15 debug1: Received SIGCHLD. debug1: tvp!=NULL kid 1 mili 100 [snip a lot of these] debug1: End of interactive session; stdin 0, stdout (read 194560, sent 194560), stderr 243 bytes. debug1: Command exited with status 0. debug1: Received exit confirmation. --- --- non-working ssh2, client side --- debug: client_input_channel_req: rtype exit-status reply 0 debug: channel 0: rcvd eof debug: channel 0: output open -> drain debug: channel 0: rcvd close debug: channel 0: input open -> closed debug: channel 0: close_read debug: channel 0: obuf empty debug: channel 0: output drain -> closed debug: channel 0: close_write debug: channel 0: send close debug: channel 0: full closed2 debug: channel_free: channel 0: status: The following connections are open: #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1) debug: !channel_still_open. debug: Transferred: stdin 0, stdout 0, stderr 0 bytes in 3.2 seconds debug: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug: Exit status 0 tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now --- --- non-working server side w/ maximal debugging --- ebug1: PAM establishing creds debug1: fd 7 setting O_NONBLOCK debug1: fd 7 IS O_NONBLOCK debug1: fd 9 setting O_NONBLOCK debug2: callback done debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug2: channel 0: read 199 from efd 9 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug2: channel 0: read 5 from efd 9 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug2: channel 0: read 38 from efd 9 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug2: channel 0: read 1 from efd 9 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug2: channel 0: rcvd adjust 24819 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug2: channel 0: rcvd adjust 30720 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug1: Received SIGCHLD. debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug3: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug1: tvp!=NULL kid 1 mili 100 debug1: session_by_pid: pid 28167 debug1: session_exit_message: session 0 channel 0 pid 28167 debug1: session_exit_message: release channel 0 debug1: channel 0: write failed debug1: channel 0: output open -> closed debug1: channel 0: close_write debug1: channel 0: read failed debug1: channel 0: input open -> drain debug1: channel 0: close_read debug1: session_free: session 0 pid 28167 debug3: channel 0: chan_delete_if_full_closed2: istate 2 ostate 128 debug3: channel 0: chan_delete_if_full_closed2: istate 2 ostate 128 debug3: channel 0: chan_delete_if_full_closed2: istate 2 ostate 128 debug3: channel 0: chan_delete_if_full_closed2: istate 2 ostate 128 debug3: channel 0: chan_delete_if_full_closed2: istate 2 ostate 128 debug2: channel 0: rcvd adjust 32768 debug3: channel 0: chan_delete_if_full_closed2: istate 2 ostate 128 debug2: channel 0: read 0 from efd 9 debug1: channel 0: closing efd 9 debug3: channel 0: chan_delete_if_full_closed2: istate 2 ostate 128 debug1: channel 0: ibuf empty debug1: channel 0: input drain -> closed debug1: channel 0: send eof debug3: channel 0: chan_delete_if_full_closed2: istate 8 ostate 128 debug1: channel 0: send close debug3: channel 0: chan_delete_if_full_closed2: istate 8 ostate 128 debug3: channel 0: chan_delete_if_full_closed2: istate 8 ostate 128 debug3: channel 0: chan_delete_if_full_closed2: istate 8 ostate 128 debug1: channel 0: rcvd close debug3: channel 0: chan_delete_if_full_closed2: istate 8 ostate 128 debug1: channel 0: full closed2 debug1: channel_free: channel 0: status: The following connections are open: #0 server-session (t4 r0 i8/0 o128/0 fd 7/7) Connection closed by remote host. --- HTH, -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From mouring at etoh.eviladmin.org Thu Nov 23 13:03:17 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 22 Nov 2000 20:03:17 -0600 (CST) Subject: fds closed after SIGCHLD bug still in newest version (fwd) In-Reply-To: Message-ID: On Thu, 23 Nov 2000, Pekka Savola wrote: > On Wed, 22 Nov 2000, Markus Friedl wrote: > > can someone confirm this? it does not happen on openbsd. > > Confirmed. This happens only when using SSH2. FreeBSD OpenSSH 2.2.0 -> > RHL 6.2 OpenSSH 2.3.0p2 (SNAP) fail as well as RHL 7.0 OpenSSH 2.3.0p1 -> > RHL 6.2 OpenSSH 2.3.0p2 (SNAP). > Hmm... Does not fail under 2.4.0-test10 using Redhat 7.0 - Ben From pekkas at netcore.fi Thu Nov 23 12:28:45 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 23 Nov 2000 03:28:45 +0200 (EET) Subject: fds closed after SIGCHLD bug still in newest version (fwd) In-Reply-To: Message-ID: On Wed, 22 Nov 2000 mouring at etoh.eviladmin.org wrote: > On Thu, 23 Nov 2000, Pekka Savola wrote: > > > On Wed, 22 Nov 2000, Markus Friedl wrote: > > > can someone confirm this? it does not happen on openbsd. > > > > Confirmed. This happens only when using SSH2. FreeBSD OpenSSH 2.2.0 -> > > RHL 6.2 OpenSSH 2.3.0p2 (SNAP) fail as well as RHL 7.0 OpenSSH 2.3.0p1 -> > > RHL 6.2 OpenSSH 2.3.0p2 (SNAP). > > > Hmm... Does not fail under 2.4.0-test10 using Redhat 7.0 RHL 7.0 with '2.4.0-0.37' kernel (test10) fails here, whether it's server or client. -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From rob at hagopian.net Thu Nov 23 13:28:30 2000 From: rob at hagopian.net (Rob Hagopian) Date: Wed, 22 Nov 2000 21:28:30 -0500 (EST) Subject: [PATCH]: nchan.c : internal error: we do not read, but chan_read In-Reply-To: Message-ID: I haven't seen further about this patch - is this expected to go into the next version? -Rob On Wed, 15 Nov 2000, John Horne wrote: > Attached is the patch I've been using to fix the error message seen in the > subject line. It seems (!) to have caused no problems with the > previous openssh snapshot version openssh-SNAP-20001016, 2.3.0p1 and the > latest snapshot (openssh-SNAP-20001114). > > The patch adds 3 lines to nchan.c in a switch stmt (line 100). It simply > caters for the cases where the input channel state is CHAN_INPUT_WAIT_DRAIN > or CHAN_INPUT_CLOSED. In these cases it simply exits (breaks) from the switch > stmt. This seems to be necessary now because an earlier fix caused nchan to > be called twice when closing a session. The first time is okay, but the > second (with the channel now in one of the above states) causes the error > message. > > 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 djm at mindrot.org Thu Nov 23 16:27:42 2000 From: djm at mindrot.org (Damien Miller) Date: Thu, 23 Nov 2000 16:27:42 +1100 (EST) Subject: fds closed after SIGCHLD bug still in newest version (fwd) In-Reply-To: Message-ID: On Wed, 22 Nov 2000 mouring at etoh.eviladmin.org wrote: > On Thu, 23 Nov 2000, Pekka Savola wrote: > > > On Wed, 22 Nov 2000, Markus Friedl wrote: > > > can someone confirm this? it does not happen on openbsd. > > > > Confirmed. This happens only when using SSH2. FreeBSD OpenSSH 2.2.0 -> > > RHL 6.2 OpenSSH 2.3.0p2 (SNAP) fail as well as RHL 7.0 OpenSSH 2.3.0p1 -> > > RHL 6.2 OpenSSH 2.3.0p2 (SNAP). > > > Hmm... Does not fail under 2.4.0-test10 using Redhat 7.0 This is my understanding of the problem: The problem is caused by my workaround for the sshd hand upon logout when background processes with open std{in,out,err} fd open. On OpenBSD, when the child of sshd (which has children of its own) exits, the stdout fd is marked as readable in the serverloop.c:wait_until_we_can_do_something select() and a subsequent read completes with a return value of 0. On Linux, nothing is reported on the select() unit all grandchildren have exited (and thus closed their std* fds), then the child stdout fd is marked as readable, but a subsequent read returns with a -1 and errno=EIO. The workaround in the portable version was to allow a single pass through through the select (grep for child_has_selected in serverlop.c) and then simulate a read failed on the channel (grep for djm in session.c). The problem is that data may not have fully drained from the child before the output is forcibly removed. The current strategy of giving the child a chance to drain is broken: under high load, it may take a long time for all the data to make it through, so any timelimit is arbitrary. Can anyone suggest a better solution? -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 Ulrich.Windl at rz.uni-regensburg.de Thu Nov 23 18:24:40 2000 From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl) Date: Thu, 23 Nov 2000 08:24:40 +0100 Subject: 2.3.0p1: terminal baud rate is 300 In-Reply-To: <20001122222709.C7352@folly> References: <3A1B94D3.10566.676B1A@localhost>; from Ulrich.Windl@rz.uni-regensburg.de on Wed, Nov 22, 2000 at 09:41:45AM +0100 Message-ID: <3A1CD442.25273.17A224@localhost> On 22 Nov 2000, at 22:27, Markus Friedl wrote: > does this happen with protocol 1 or 2? The protocol is the default one, thus "1". > > openssh's protocol 2 implementation does not transfer > the tty modes to the server side (protocol 1 does, who > wants to implement this?). > > -markus Regards, Ulrich From Markus.Friedl at informatik.uni-erlangen.de Thu Nov 23 19:16:23 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 23 Nov 2000 09:16:23 +0100 Subject: [PATCH]: nchan.c : internal error: we do not read, but chan_read In-Reply-To: ; from rob@hagopian.net on Wed, Nov 22, 2000 at 09:28:30PM -0500 References: Message-ID: <20001123091623.A694@faui02.informatik.uni-erlangen.de> On Wed, Nov 22, 2000 at 09:28:30PM -0500, Rob Hagopian wrote: > I haven't seen further about this patch - is this expected to go into the > next version? no. removing the error message does not fix the error. From fwunderlich at devbrain.de Thu Nov 23 10:01:52 2000 From: fwunderlich at devbrain.de (Florian Wunderlich) Date: Thu, 23 Nov 2000 00:01:52 +0100 Subject: fds closed after SIGCHLD bug still in newest version References: <3A1AC2C4.8432F4DF@devbrain.de> <20001122095144.A18665@faui02.informatik.uni-erlangen.de> <3A1BCDB1.5CFF246F@hq.factor3.com> <20001122221522.E1226@folly> Message-ID: <3A1C5060.AE848740@hq.factor3.com> Attached is the stderr output of ssh -v -v -v faxdial "dd if=/dev/zero bs=1c count=1000" 2> log1 | wc -c which leads to 423 (this time, it varies) on stdout, which should obviously be 1000 instead. Markus Friedl wrote: > > could you please try with 'ssh -v' > > i cannot reproduce this on openbsd. > > post the results to openssh-unix-dev at mindrot.org, please. > > -markus > > On Wed, Nov 22, 2000 at 02:44:17PM +0100, Florian Wunderlich wrote: > > Markus Friedl wrote: > > > > > > are you using protocol 1 or 2? how big is the tar file? > > > > Protocol 2, although I do not think this make a difference. > > > > The smallest tar locally created was just 64k (exactly, 65535c), where > > it should be around 80k. The size of the file that is locally created > > varies randomly; most often it is around 72k. A better check for the > > actual size is probably this: > > > > main:~$ dd if=/dev/zero bs=1c count=1000 | wc -c > > 1000+0 records in > > 1000+0 records out > > 1000 > > main:~$ ssh faxdial "dd if=/dev/zero bs=1c count=1000" | wc -c > > 436 > > main:~$ ssh faxdial "dd if=/dev/zero bs=1c count=1000" | wc -c > > 184 > > main:~$ ssh faxdial "dd if=/dev/zero bs=1c count=1000" | wc -c > > 181 > > > > main:~$ ssh faxdial "dd if=/dev/zero bs=1c count=200" | wc -c > > 200+0 records in > > 200+0 records out > > 200 > > main:~$ ssh faxdial "dd if=/dev/zero bs=1c count=200" | wc -c > > 176 > > main:~$ ssh faxdial "dd if=/dev/zero bs=1c count=200" | wc -c > > 181 > > main:~$ ssh faxdial "dd if=/dev/zero bs=1c count=200" | wc -c > > 200+0 records in > > 200+0 records out > > 200 > > > > This is at home, where I also have Linux, and the same thing happens. > > > > main:~$ uname -r ; ssh faxdial uname -r > > 2.2.17 > > 2.2.17 > > > > > is it between two openssh versions? what operating systems? > > > > yes, both times the newest portable version, OpenSSH_2.3.0p1, on > > Linux-2.2.x. > > > > > is USE_PIPE defined? > > > > USE_PIPES, with an S at the end, I assume. > > After configure, no. > > I defined it manually after having a quick look at the source, in > > config.h, but it didn't make a difference. Just to check, I inserted a > > #error in a #ifdef USE_PIPES block, and it showed up, so it really was > > defined. > > > > > -m > > > > > > On Tue, Nov 21, 2000 at 07:45:24PM +0100, Florian Wunderlich wrote: > > > > A bug which leads to exactly the same behaviour as described in > > > > > > > > http://marc.theaimsgroup.com/?l=secure-shell&m=95451481631163&w=2 > > > > > > > > still occurs in OpenSSH_2.3.0p1. > > > > > > > > For example, when doing > > > > > > > > ssh somehost "tar cf - /usr/var" | tar tf - > > > > > > > > I get some data, and then "tar: Unexpected EOF on archive file". > > > > > > > > When I do > > > > > > > > ssh somehost "tar cf - /usr/var ; sleep 1" | tar tf - > > > > > > > > it works fine. > > > > -------------- next part -------------- SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090600f). debug: Reading configuration data /etc/openssh/ssh_config debug: Seeding random number generator debug: ssh_connect: getuid 500 geteuid 0 anon 0 debug: Connecting to faxdial [192.168.1.1] port 22. debug: Seeding random number generator debug: Allocated local port 959. debug: Connection established. debug: Remote protocol version 2.0, remote software version OpenSSH_2.3.0p1 debug: no match: OpenSSH_2.3.0p1 Enabling compatibility mode for protocol 2.0 debug: Local version string SSH-2.0-OpenSSH_2.3.0p1 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 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 3des-cbc hmac-sha1 none debug: kex: client->server 3des-cbc 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: 526/1024 debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. debug: Got SSH2_MSG_KEXDH_REPLY. debug: Host 'faxdial' is known and matches the DSA host key. debug: bits set: 518/1024 debug: len 55 datafellows 0 debug: dsa_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 debug: start over, passed a different list debug: authmethod_lookup publickey debug: authmethod_is_enabled publickey debug: next auth method to try is publickey debug: try pubkey: /home/florian/.ssh/id_dsa debug: read DSA private key done debug: sig size 20 20 debug: we sent a publickey packet, wait for reply debug: ssh-userauth2 successfull: method publickey debug: fd 5 setting O_NONBLOCK debug: fd 6 setting O_NONBLOCK debug: channel 0: new [client-session] debug: send channel open 0 debug: Entering interactive session. debug: callback start debug: client_init id 0 arg 0 debug: Requesting X11 forwarding with authentication spoofing. debug: Sending command: dd if=/dev/zero bs=1c count=1000 debug: client_set_session_ident: id 0 debug: callback done debug: channel 0: open confirm rwindow 0 rmax 16384 debug: channel 0: rcvd adjust 32768 debug: callback start debug: client_input_channel_req: rtype exit-status reply 0 debug: callback done debug: channel 0: rcvd eof debug: channel 0: output open -> drain debug: channel 0: rcvd close debug: channel 0: input open -> closed debug: channel 0: close_read debug: channel 0: obuf empty debug: channel 0: output drain -> closed debug: channel 0: close_write debug: channel 0: send close debug: channel 0: full closed2 debug: channel_free: channel 0: status: The following connections are open: #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1) debug: !channel_still_open. debug: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.2 seconds debug: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug: Exit status 0 From J.Horne at plymouth.ac.uk Thu Nov 23 23:20:37 2000 From: J.Horne at plymouth.ac.uk (John Horne) Date: Thu, 23 Nov 2000 12:20:37 -0000 (GMT) Subject: [PATCH]: nchan.c : internal error: we do not read, but chan_ In-Reply-To: <20001123091623.A694@faui02.informatik.uni-erlangen.de> Message-ID: On 23-Nov-00 at 08:16:23 Markus Friedl wrote: > On Wed, Nov 22, 2000 at 09:28:30PM -0500, Rob Hagopian wrote: >> I haven't seen further about this patch - is this expected to go into the >> next version? > > no. > > removing the error message does not fix the error. > Well it didn't exactly 'remove' the error message. It merely intercepted a second calling of nchan which was caused by a previous fix. As far as I could determine the mechanism by which nchan was called the second time was valid, but the error message nchan produced was invalid at that time. Hence it is intercepted by the additional switch arguments. An alternative is to detect further up the sequence of events that nchan is about to be called again and then prevent it - this seemed a lot messier. However, I await the correct fix :-) 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 markus.friedl at informatik.uni-erlangen.de Fri Nov 24 06:40:41 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 23 Nov 2000 20:40:41 +0100 Subject: implementing port forward restrictions In-Reply-To: <00112214145203.24300@is10.6x4.org>; from ms@speakeasy.org on Wed, Nov 22, 2000 at 02:14:52PM -0800 References: <00112214145203.24300@is10.6x4.org> Message-ID: <20001123204041.A30873@folly> for -R or -L style forwarding? these kind of policy configurations should be implmented with keynote (see rfc2704). -markus On Wed, Nov 22, 2000 at 02:14:52PM -0800, michael salmon wrote: > hi folks, > right now im implementing a quick hack to restrict ports the server will > allow to be forwarded. This is to heighten security from clients accessing a > server behind a firewall and as far as I could tell this is not possible with > ssh so far. > I think this is a reasonable feature for a release and shouldnt be too hard > to implement in a way that follows the setup already used in the config and > sshd handling of connections. I searched the mailing-list archives and found > a few small references to it but none implied it was being worked on. > When I finish this if the list wants the diffs I'd be happy to supply them. > I'd like the opinion of the other developers as to a key in the sshd_config > that would be obvious yet not too long to define the ports, and the layout. > I was thinking > HostAllowsPortsForwarded 143 2401 etc... space delimited numbers. > > cheers, > michael salmon > From markus.friedl at informatik.uni-erlangen.de Fri Nov 24 06:42:46 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 23 Nov 2000 20:42:46 +0100 Subject: SSH1 tunneling problems. In-Reply-To: ; from jfulmer@appin.org on Wed, Nov 22, 2000 at 09:20:58AM -0600 References: <200011222336.PAA04785@homer.ka9q.net> Message-ID: <20001123204246.B30873@folly> On Wed, Nov 22, 2000 at 09:20:58AM -0600, John Fulmer wrote: > I've noticed this same problemm using local forwarding via OpenSSH in SSH1 > mode, both 2.3.0p1 and 2.2.0p1. The problem is that the tunnel (actually > the entire ssh session) freezes periodically if the tunnel has several TCP > connections initiated within a short period of time, and the ssh session > must be broken and restarted. On Wed, Nov 22, 2000 at 03:36:45PM -0800, Phil Karn wrote: > As I regularly websurf over a SSH tunnel, I've seen this exact problem > occur *many many* times, and for many OpenSSH versions prior to > 2.3.0. In fact, it has occurred ever since I switched from the > original SSH to OpenSSH. This is also on Linux 2.2.17. what does '~#' say for frozen connections? i use -L forwarding for traffic to webproxies without any problems (on openbsd only). -markus From ms at speakeasy.org Fri Nov 24 07:50:40 2000 From: ms at speakeasy.org (michael salmon) Date: Thu, 23 Nov 2000 12:50:40 -0800 Subject: implementing port forward restrictions In-Reply-To: <20001123204041.A30873@folly> References: <00112214145203.24300@is10.6x4.org> <20001123204041.A30873@folly> Message-ID: <00112312504004.30011@is10.6x4.org> My original need is to have it only for -L but -R could be done also, just in a different manner. I noticed in the mail archives the reference to keynote and did take a look at it. For my first pass I'll just do it without it, then later read rfc 2704 and see about implementing it that way. -ms- (this list-serv is reaaaaallllllyyy sllooowwww) On Thursday 23 November 2000 12:47, Markus Friedl wrote: > for -R or -L style forwarding? > > these kind of policy configurations should be implmented > with keynote (see rfc2704). > > -markus > > On Wed, Nov 22, 2000 at 02:14:52PM -0800, michael salmon wrote: > > hi folks, > > right now im implementing a quick hack to restrict ports the server will > > allow to be forwarded. This is to heighten security from clients > > accessing a server behind a firewall and as far as I could tell this is > > not possible with ssh so far. > > I think this is a reasonable feature for a release and shouldnt be too > > hard to implement in a way that follows the setup already used in the > > config and sshd handling of connections. I searched the mailing-list > > archives and found a few small references to it but none implied it was > > being worked on. When I finish this if the list wants the diffs I'd be > > happy to supply them. I'd like the opinion of the other developers as to > > a key in the sshd_config that would be obvious yet not too long to define > > the ports, and the layout. I was thinking > > HostAllowsPortsForwarded 143 2401 etc... space delimited numbers. > > > > cheers, > > michael salmon From ms at speakeasy.org Fri Nov 24 07:50:40 2000 From: ms at speakeasy.org (michael salmon) Date: Thu, 23 Nov 2000 12:50:40 -0800 Subject: implementing port forward restrictions In-Reply-To: <20001123204041.A30873@folly> References: <00112214145203.24300@is10.6x4.org> <20001123204041.A30873@folly> Message-ID: <00112312504004.30011@is10.6x4.org> My original need is to have it only for -L but -R could be done also, just in a different manner. I noticed in the mail archives the reference to keynote and did take a look at it. For my first pass I'll just do it without it, then later read rfc 2704 and see about implementing it that way. -ms- (this list-serv is reaaaaallllllyyy sllooowwww) On Thursday 23 November 2000 12:47, Markus Friedl wrote: > for -R or -L style forwarding? > > these kind of policy configurations should be implmented > with keynote (see rfc2704). > > -markus > > On Wed, Nov 22, 2000 at 02:14:52PM -0800, michael salmon wrote: > > hi folks, > > right now im implementing a quick hack to restrict ports the server will > > allow to be forwarded. This is to heighten security from clients > > accessing a server behind a firewall and as far as I could tell this is > > not possible with ssh so far. > > I think this is a reasonable feature for a release and shouldnt be too > > hard to implement in a way that follows the setup already used in the > > config and sshd handling of connections. I searched the mailing-list > > archives and found a few small references to it but none implied it was > > being worked on. When I finish this if the list wants the diffs I'd be > > happy to supply them. I'd like the opinion of the other developers as to > > a key in the sshd_config that would be obvious yet not too long to define > > the ports, and the layout. I was thinking > > HostAllowsPortsForwarded 143 2401 etc... space delimited numbers. > > > > cheers, > > michael salmon From gert at greenie.muc.de Fri Nov 24 08:03:04 2000 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 23 Nov 2000 22:03:04 +0100 Subject: implementing port forward restrictions In-Reply-To: <00112312504004.30011@is10.6x4.org>; from michael salmon on Thu, Nov 23, 2000 at 12:50:40PM -0800 References: <00112214145203.24300@is10.6x4.org> <20001123204041.A30873@folly> <00112312504004.30011@is10.6x4.org> Message-ID: <20001123220304.A29672@greenie.muc.de> Hi, On Thu, Nov 23, 2000 at 12:50:40PM -0800, michael salmon wrote: > (this list-serv is reaaaaallllllyyy sllooowwww) If necessary, we would be willing to host the openssh list (Munich, Germany, but fairly well-connected - "mail.space.net"). 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 djm at mindrot.org Fri Nov 24 08:16:18 2000 From: djm at mindrot.org (Damien Miller) Date: Fri, 24 Nov 2000 08:16:18 +1100 (EST) Subject: implementing port forward restrictions In-Reply-To: <00112312504004.30011@is10.6x4.org> Message-ID: On Thu, 23 Nov 2000, michael salmon wrote: > (this list-serv is reaaaaallllllyyy sllooowwww) Quite so - I am in Australia, which has recently lost 60% of its international bandwidth to a boat anchor or somesuch. With >2sec international RTTs, getting all the mail out takes a while :( ETA for fix is early next week. -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 Fri Nov 24 09:20:42 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 23 Nov 2000 16:20:42 -0600 (CST) Subject: implementing port forward restrictions In-Reply-To: Message-ID: On Fri, 24 Nov 2000, Damien Miller wrote: > On Thu, 23 Nov 2000, michael salmon wrote: > > > (this list-serv is reaaaaallllllyyy sllooowwww) > > Quite so - I am in Australia, which has recently lost 60% of its > international bandwidth to a boat anchor or somesuch. > Hmm.. Is this the new backbone to Australia or the old one? They just finished a large self-healing backbone within the last week. - Ben From ccsanady at iastate.edu Fri Nov 24 17:58:51 2000 From: ccsanady at iastate.edu (Chris) Date: Fri, 24 Nov 2000 00:58:51 -0600 Subject: /etc/issue possible? Message-ID: <3A1E11AB.316C7ECC@iastate.edu> 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. Chris From ETARDIEU at CPR.FR Fri Nov 24 20:01:43 2000 From: ETARDIEU at CPR.FR (TARDIEU Emmanuel) Date: Fri, 24 Nov 2000 10:01:43 +0100 Subject: problems with key conversions Message-ID: <5BF932D2CD05D211B54800805FE60FEB08F52A10@serv-hermes.systeme.cpr.fr> I have found a slight bug in openssh 2.3.0p1 when converting dsa keys generated by ssh 2.0.13 with an empty passphrase. openssh prompts for a passphrase, and hitting return key denies login. I have generated a dsa key with openssh 2.3.0p1 with an empty passphrase, and then I can login without restrictions to the openssh server. I think I recall reading a similar problem on the list a while ago (maybe?). Emmanuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001124/a722f337/attachment.html From Nigel.Metheringham at VData.co.uk Fri Nov 24 20:52:12 2000 From: Nigel.Metheringham at VData.co.uk (Nigel Metheringham) Date: Fri, 24 Nov 2000 09:52:12 +0000 Subject: Use of /etc/primes & DH group exchange In-Reply-To: Message from Markus Friedl of "Fri, 17 Nov 2000 21:19:56 +0100." <20001117211956.A29481@folly> Message-ID: Marcus, I am still a little confused as to the purpose of the file of "safe" primes stashed in /etc/primes (or /etc/ssh/primes) and what should be used to generate this. The IETF document you referenced on the list - http://www.ietf.org/internet-drafts/draft-provos-secsh-dh-group-exchange-00.txt indicates that a system should be generating primes for future use in the background, however this file of primes appears to be externally generated (I see no code that writes the file in 2.3.0p1), and certainly in the case of the latest RH RPMs (see current BugTraq posting & RHSA-2000:111-03) is fixed for all their installs. Is having everyone singing from the same prime songsheet whats intended, or should these primes be unique per box? [or do I not understand any of this :-) ] 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 gilesc at hyperlink.com Fri Nov 24 22:22:37 2000 From: gilesc at hyperlink.com (Giles Constant) Date: 24 Nov 2000 11:22:37 GMT Subject: Password/phrase from commandline with -oPassword Message-ID: Hi there, I've been trying to get rsync working from Unix to NT via ssh in a script file, and after discovering that the NT version of sshd refuses to log you on without entering the NT domain password, I figured the only way around this was to add a "-oPassword" option to the ssh client. I've now done this and it works nicely. Obviously, it's not secure if someone on the box is able to do a ps listing, but in this case, if someone unscrupulous is on the box for which this has been written, we have a problem anyway :-) I understand that mysql with the -p option actually somehow removes the text from the cmdline string. I'm not sure if this is done simply by overwriting argv[0], but I'll look into it. Anyway, if you want a diff, gimme a shout. Cheers, Giles From mfinks at exchange.telekom.lv Fri Nov 24 22:46:36 2000 From: mfinks at exchange.telekom.lv (Maris Finks) Date: Fri, 24 Nov 2000 13:46:36 +0200 Subject: ssh for digital unix un compaq hardware Message-ID: <8DDC477A0538D2119A2800A0C9D16FF3096012CF@exchange1.telekom.lv> Hello, what can i try to use for digital unix un compaq hardware? Please mail private. 10x thnx Ppzz From Florian.Weimer at RUS.Uni-Stuttgart.DE Fri Nov 24 23:32:58 2000 From: Florian.Weimer at RUS.Uni-Stuttgart.DE (Florian Weimer) Date: 24 Nov 2000 13:32:58 +0100 Subject: implementing port forward restrictions In-Reply-To: <00112214145203.24300@is10.6x4.org> References: <00112214145203.24300@is10.6x4.org> Message-ID: michael salmon writes: > right now im implementing a quick hack to restrict ports the server > will allow to be forwarded. We've already done that. At the moment, I'm porting our modifications to the current (portable) OpenSSH version. After that, it will be released to the general public. You can have the old version (based on 1.2.3), if you want to. Here's a manpage excerpt: CONFIGURATION FILE ... ForwardingControl Specifies the global forwarding control file (default /etc/sshd_forward). See the PORT-FORWARDING FILE FORMAT section for details. This option can be used to restrict port forwarding to specific hosts and ports. It is safe only if the remote user is not able to gain interactive access on the server machine and to execute arbitrary commands. The file is not processed if a user-specific or RSA-key-specific forwarding control file is pre- sent. ... AUTHORIZED_KEYS FILE FORMAT ... port-forwarding-file="FILE" Specifies a file which controls port forwarding. The quotes are optional. If the file name does not start with a slash `/', it is assumed that the file is located in the directory $HOME/.ssh. See the PORT-FORWARDING FILE FORMAT section for details. This option can be used to restrict port forwarding to specific hosts and ports. It is safe only if the remote user is not able to gain interactive access on the server machine and to execute ar- bitrary commands. ... PORT-FORWARDING FILE FORMAT The file controlling port forwarding is read each time a port forwarding request is received from the client and is processed line by line. Lines starting with `#' and empty lines are ignored as comments. Each line which is not a comment consists of two parts, separated by a colon `:', a host list and a port list. Host list This part lists several host names or IP addresses, seperated by spaces, and optionally prefixed by an exclamation mark `!', after which whitespace may follow. An entry without a leading `!' is called postive, if a `!' prefix character is present, the entry is called negative. A host is said to match an entry in the host list if one or more of the following conditions are met (a leading `!' is ig- nored): o The entry specifies the IP address (either in IPv4/dot or IPv6/colon notation) of that host. o The entry is a shell pattern which matches the IP address of that host (in IPv4/dot or IPv6/colon notation, respec- tively). o (This condition applies only to IPv4 hosts.) The entry is an IPv4 address, given in dotted-quad style, followed by a slash `/' and decimal number specifying the number of set bits in the netmask; and that host lies within this net- work. o The entry is a host name, and one of the corresponding IP addresses matches that of the the given host. A host matches the entire host list if and only if at least one entry matches, and the last (or rightmost) matching entry is positive. Port list This part lists one several TCP ports or port ranges. A deci- mal number from 1 to 65535 specifies a TCP port, two decimal numbers in this range, the first one less than the second one, and both separated by `-', specify a TCP port range. Each en- try can be prefixed with an exclamation mark `!', after which whitespace may follow. Again, a given port is said to match the port list if it is contained in the list or lies within a specified port range. The match is called positive if the last (or rightmost) matching entry is not prefixed with a `!', otherwise, the match is called negative. To determine whether a port forwarding request to a given host and port is legal, each non-comment line is processed as follows: If (and only if) the host list matches positively, the port list is examined, and if the port list matches positively or negatively, this fact is remembered. A port forwarding request is granted if the last remember port list match was a positive one, the request is denied if the last match was negative or there was not any match at all. Examples The following port-forwarding file permits forwarding to host somehost on port 80, and to any host in the 192.168.2.0/24 class C net, but not to 192.168.2.1; port forwarding for these hosts is restricted to unprivi- leged TCP ports, excluding port 2049. In addition, forwarding is denied for port 27456 on host 129.168.2.2. somehost : 80 192.168.2.0/24 !192.168.2.1 : 1024-65536 !2049 192.168.2.2 : !27456 ... $HOME/.ssh/forward If this file exists, port forwarding control requests are matched against its contents (see section PORT-FORWARDING FILE FORMAT above for a description of the file format). In the $HOME/.ssh/authorized_keys file, an alternative file name can be specified on a per-key basis. /etc/sshd_forward Like $HOME/.ssh/forward, this file is used to control port for- warding. A forwarding request is matched against this file if it is present, and no user-specific or RSA-key-specific forwarding control file is given. -- 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 Florian.Weimer at RUS.Uni-Stuttgart.DE Sat Nov 25 02:52:11 2000 From: Florian.Weimer at RUS.Uni-Stuttgart.DE (Florian Weimer) Date: 24 Nov 2000 16:52:11 +0100 Subject: serverloop.c:server_loop() Message-ID: This function seems to be dead code. Or has it got some hidden function? -- 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 Markus.Friedl at informatik.uni-erlangen.de Sat Nov 25 03:11:13 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 24 Nov 2000 17:11:13 +0100 Subject: serverloop.c:server_loop() In-Reply-To: ; from Florian.Weimer@RUS.Uni-Stuttgart.DE on Fri, Nov 24, 2000 at 04:52:11PM +0100 References: Message-ID: <20001124171112.A4482@faui02.informatik.uni-erlangen.de> it is called from session.c server_loop() is called for ssh1 server_loop2() is called for ssh2 On Fri, Nov 24, 2000 at 04:52:11PM +0100, Florian Weimer wrote: > This function seems to be dead code. Or has it got some hidden > function? > > -- > 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 Florian.Weimer at RUS.Uni-Stuttgart.DE Sat Nov 25 03:09:09 2000 From: Florian.Weimer at RUS.Uni-Stuttgart.DE (Florian Weimer) Date: 24 Nov 2000 17:09:09 +0100 Subject: serverloop.c:server_loop() In-Reply-To: <20001124171112.A4482@faui02.informatik.uni-erlangen.de> References: <20001124171112.A4482@faui02.informatik.uni-erlangen.de> Message-ID: Markus Friedl writes: > it is called from session.c > > server_loop() is called for ssh1 > > server_loop2() is called for ssh2 Oh, silly me. Didn't read the grep output carefully enough -- the calls are interspersed with comment lines. :-/ -- 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 Florian.Weimer at RUS.Uni-Stuttgart.DE Sat Nov 25 04:19:58 2000 From: Florian.Weimer at RUS.Uni-Stuttgart.DE (Florian Weimer) Date: 24 Nov 2000 18:19:58 +0100 Subject: Getting the authctxt Message-ID: My port forwarding changes require an authorization (authentication) context in channel_connect_to(). I'd like to change the dispatch_* functions so that they accept an Authctxt * instead of a void * (this parameter is already used this way). In addition, I'd have to pass the authctxt all the way down to channel_connect_to(). As a side effect, it's possible to get rid of the global variable x_authctxt (which seems to be sort of a hack), because it's easy to provide the authctxt information in all places where auth_get_user() is currently called. In addition, server_loop() would be changed to accept a struct passwd * and build a fake authctxt for it, to be compatible with the v2 code path. Thoughts? -- 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 markus.friedl at informatik.uni-erlangen.de Sat Nov 25 06:09:44 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 24 Nov 2000 20:09:44 +0100 Subject: Getting the authctxt In-Reply-To: ; from Florian.Weimer@RUS.Uni-Stuttgart.DE on Fri, Nov 24, 2000 at 06:19:58PM +0100 References: Message-ID: <20001124200944.A18719@folly> On Fri, Nov 24, 2000 at 06:19:58PM +0100, Florian Weimer wrote: > My port forwarding changes require an authorization (authentication) > context in channel_connect_to(). I'd like to change the dispatch_* > functions so that they accept an Authctxt * instead of a void * (this > parameter is already used this way). void * should be replaced by a more general Context structure. this will be necessary for the implementation of rekeying in SSH2. moreover, i'd like to add a more general 'policy API' to ssh, see example below. this should include not only port, but also agent and X11 forwarding. > In addition, I'd have to pass > the authctxt all the way down to channel_connect_to(). As a side > effect, it's possible to get rid of the global variable x_authctxt > (which seems to be sort of a hack), because it's easy to provide the > authctxt information in all places where auth_get_user() is currently > called. yes, this would be nice. i think that the Authctxt will be passed to. do_authenticated(Authctxt *a); do_authenticated2(Authctxt *a); or something similar. more integration is definitly needed (e.g. usage of Authctxt for ssh1, too). > In addition, server_loop() would be changed to accept a struct passwd * > and build a fake authctxt for it, to be compatible with the v2 code > path. > > Thoughts? -markus #ifndef _POLICY_H #define _POLICY_H typedef struct { char *cipher_send; char *cipher_receive; } transport_info_t; int policy_login(const char *user, const char *version, const char *service, const char *clienthost, const char *clientip, const char *serverhost, const char *serverip, transport_info_t *tinfo, char **allowed_auths, struct passwd **pw); void policy_init(const char *user, const char *version, const char *authmethod, const char *clienthost, const char *clientip, const char *serverhost, const char *serverip); int policy_portforward_local(const char *dsthost, int dstport, const char *originhost, int originport); int policy_portforward_remote(const char *listenhost, int listenport); int policy_portforward_x11(int single, const char *proto); int policy_forward_agent(void); int policy_cmd(const char *type, const char *arg1, const char *arg2); #endif /* _POLICY_H */ From Florian.Weimer at RUS.Uni-Stuttgart.DE Sat Nov 25 08:26:34 2000 From: Florian.Weimer at RUS.Uni-Stuttgart.DE (Florian Weimer) Date: 24 Nov 2000 22:26:34 +0100 Subject: Getting the authctxt In-Reply-To: <20001124200944.A18719@folly> References: <20001124200944.A18719@folly> Message-ID: Markus Friedl writes: > On Fri, Nov 24, 2000 at 06:19:58PM +0100, Florian Weimer wrote: > > My port forwarding changes require an authorization (authentication) > > context in channel_connect_to(). I'd like to change the dispatch_* > > functions so that they accept an Authctxt * instead of a void * (this > > parameter is already used this way). > > void * should be replaced by a more general Context structure. > this will be necessary for the implementation of rekeying in SSH2. I see. In addition, the client code requires a different structure. I didn't notice that. Probably some kind of union has to be used instead. -- 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 Sat Nov 25 09:47:14 2000 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 25 Nov 2000 00:47:14 +0200 (EET) Subject: KbdInteract not mentioned on sshd.8, cryptocard? Message-ID: Hello all, I just noticed that 'KbdInteractiveAuthentication' is not mentioned in sshd.8 or anywhere else on the man page. Someone with better knowledge about it than me, please fix this :-) Also, there were talks about supporting cryptocards about 3 months ago. Is there work being done on this? -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola at netcore.fi not those you stumble over and fall" From gert at greenie.muc.de Sat Nov 25 10:17:49 2000 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 25 Nov 2000 00:17:49 +0100 Subject: Getting the authctxt In-Reply-To: <20001124200944.A18719@folly>; from Markus Friedl on Fri, Nov 24, 2000 at 08:09:44PM +0100 References: <20001124200944.A18719@folly> Message-ID: <20001125001749.H20415@greenie.muc.de> Hi, On Fri, Nov 24, 2000 at 08:09:44PM +0100, Markus Friedl wrote: > moreover, i'd like to add a more general 'policy API' to ssh, > see example below. this should include not only port, but also > agent and X11 forwarding. Even further: to be able to qualify authentication methods by remote hosts would be *very* important for us ("hosts coming from *this* network may do RhostsRSAAuthentication or PasswortAuthentication, everybody else has to do SKeyAuthentication"). 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 Sat Nov 25 11:49:16 2000 From: wyodlows at andromeda.rutgers.edu (William Yodlowsky) Date: Fri, 24 Nov 2000 19:49:16 -0500 Subject: /etc/nologin & Solaris Message-ID: <20001124194916.A24716@andromeda.rutgers.edu> I know this has come up before and I even saw a patch from Niklas Edmundsson for 2.1.1p2 (see http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=96316919430887&w=2 ) I had the (mis)fortune recently of realizing that if PAM is defined, /etc/nologin is not honored. session.c tells me that pam_nologin is supposed to take care of this, and that's nice, except that it's a Linux Thing. It doesn't exist on the platform I'm using (Solaris). I really don't like local hacks and I'm sure there are other Solaris people out there who aren't too happy about this situation... how can this be remedied (other than undefining PAM, of course)? And finally, thanks for the great software, developers. You make all our work that much more secure :-) From markus.friedl at informatik.uni-erlangen.de Sat Nov 25 22:27:29 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 25 Nov 2000 12:27:29 +0100 Subject: Getting the authctxt In-Reply-To: <20001125001749.H20415@greenie.muc.de>; from gert@greenie.muc.de on Sat, Nov 25, 2000 at 12:17:49AM +0100 References: <20001124200944.A18719@folly> <20001125001749.H20415@greenie.muc.de> Message-ID: <20001125122729.A6525@folly> On Sat, Nov 25, 2000 at 12:17:49AM +0100, Gert Doering wrote: > Hi, > > On Fri, Nov 24, 2000 at 08:09:44PM +0100, Markus Friedl wrote: > > moreover, i'd like to add a more general 'policy API' to ssh, > > see example below. this should include not only port, but also > > agent and X11 forwarding. > > Even further: to be able to qualify authentication methods by remote hosts > would be *very* important for us ("hosts coming from *this* network may do > RhostsRSAAuthentication or PasswortAuthentication, everybody else has to > do SKeyAuthentication"). well i think this is what keynote is for: http://www.cis.upenn.edu/~angelos/keynote.html From jhuuskon at messi.uku.fi Mon Nov 27 20:18:15 2000 From: jhuuskon at messi.uku.fi (Jarno Huuskonen) Date: Mon, 27 Nov 2000 11:18:15 +0200 Subject: /var/log/btmp logging ? Message-ID: <20001127111815.A18230@laivuri63.uku.fi> Hi, Openssh doesn't log failed logins to /var/log/btmp like login does (if btmp exists). This is on RH6.2. Is there a specific reason for not logging to btmp ? I think that logging to btmp would be a 'good thing'(tm). What about other unices ? Do they have /var/log/btmp or something similar (AIX has something like that and I think openssh already logs the failed attempts). AFAIK it wouldn't be too much work to get btmp logging to openssh. Here are some ideas that came to mind: - add a failure call to auth1.c and auth2.c (there's already AIX specific loginfailed). - modify loginrec.c so there's a routine to write an entry to btmp ( propably just modify wtmp_write_entry so it can take a filename parameter and then add write_bad_login-function ) Is somebody interested in this kind of btmp feature ? And any chances of getting this included in the portable version ? -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 andrew.back at iomart.com Tue Nov 28 01:55:16 2000 From: andrew.back at iomart.com (Andrew Back) Date: Mon, 27 Nov 2000 14:55:16 -0000 Subject: X.509 support & key lookup. Message-ID: <006d01c05882$0dd353c0$0b02070a@iomart.com> Hi, Just wondered if anyone had got the following to work or if there are any plans to add this functionality. * X.509 certificate support for authentication. As used in the likes of stunnel, mod_ssl etc for client auth. * Directory based (LDAP) key lookup. Either for X.509 public certs or standard ssh public key. Many thanks, Andrew _______________________ Andrew Back Messaging & Directory Services Architect Iomart Tel: 0141 931 7046 http://www.iomart.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2239 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20001127/4fdc2e05/attachment.bin From Nigel.Metheringham at VData.co.uk Tue Nov 28 02:41:23 2000 From: Nigel.Metheringham at VData.co.uk (Nigel Metheringham) Date: Mon, 27 Nov 2000 15:41:23 +0000 Subject: StrictHostKeyChecking Message-ID: Long ago, when I wrote the ssh config file on my desktop box, ssh (which might have been the non-openssh one) took 3 possible values for the StrictHostKeyChecking option - yes, no & ask. Today, when I attempted to connect to a new machine, with no DNS entries (so using IP address) from my desktop box, ssh (now 2.3.0p1) SEGVed. Looks like there is some subtle interaction between having an illegal value for StrictHostKeyChecking, an ip address target (I am sure I have done this before with named hosts) and a host that is not in known_hosts. 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 Florian.Weimer at RUS.Uni-Stuttgart.DE Tue Nov 28 03:01:26 2000 From: Florian.Weimer at RUS.Uni-Stuttgart.DE (Florian Weimer) Date: 27 Nov 2000 17:01:26 +0100 Subject: Getting the authctxt In-Reply-To: References: Message-ID: Florian Weimer writes: > My port forwarding changes require an authorization (authentication) > context in channel_connect_to(). I'd like to change the dispatch_* > functions so that they accept an Authctxt * instead of a void * (this > parameter is already used this way). In addition, I'd have to pass > the authctxt all the way down to channel_connect_to(). I've finished these changes and integrated our old port forwarding control patches (in a bit hackish way :-/). The current version is still not in production use here ;-), but some initial test were quite promising. A diff to portable OpenSSH 2.3.0p1 and an OpenPGP signature is avaliable at: http://cert.uni-stuttgart.de/files/openssh/openssh-2.3.0p1-RUS-CERT-1.diff http://cert.uni-stuttgart.de/files/openssh/openssh-2.3.0p1-RUS-CERT-1.diff.sig Updates/improvements/bug fixes will be announced at: http://cert.uni-stuttgart.de/projects/openssh.php Of course, it would be nice if this patch (or a modified version) would find its way into the official source tree, so that we don't have to keep track of OpenSSH and patch in our modifications each time a new version is released. Directions regarding patch submission are therefore greatly appreciated. -- 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 markus.friedl at informatik.uni-erlangen.de Tue Nov 28 07:14:57 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 27 Nov 2000 21:14:57 +0100 Subject: X.509 support & key lookup. In-Reply-To: <006d01c05882$0dd353c0$0b02070a@iomart.com>; from andrew.back@iomart.com on Mon, Nov 27, 2000 at 02:55:16PM -0000 References: <006d01c05882$0dd353c0$0b02070a@iomart.com> Message-ID: <20001127211457.A1916@folly> On Mon, Nov 27, 2000 at 02:55:16PM -0000, Andrew Back wrote: > * X.509 certificate support for authentication. As used in the likes of > stunnel, mod_ssl etc for client auth. if someone adds support for keynote this should be easy, too. (cf. isakmpd from openbsd). -markus From Ulrich.Windl at rz.uni-regensburg.de Tue Nov 28 18:42:28 2000 From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl) Date: Tue, 28 Nov 2000 08:42:28 +0100 Subject: OpenSSH_2.3.0p1: Change request regarding "authorized_keys" Message-ID: <3A236FED.10583.243FDB@localhost> Hello, in OpenSSH_2.3.0p1 multiple keys can be added to .ssh/authorized_keys, and they actually work. However it would be desirable to know _which_ key led to authorization. Currently the syslog only says: sshd[...]: Accepted rsa for ROOT from 192.168.0.15 port 964 Should/could the fingerprint of the key or at least the index of the key (line number) in authorized_keys be shown? Or is it a security risk to display such information? Regards, Ulrich From christian at cintra.com Wed Nov 29 04:16:41 2000 From: christian at cintra.com (Christian Chiaverini) Date: Tue, 28 Nov 2000 12:16:41 -0500 Subject: No subject Message-ID: <000401c0595e$fa003790$4b273b40@cchiaverini> I have a problem compiling openssh 2.3.0p1 The configure script runs fine then if you see below; when I compile it dies: Manual pages: /usr/local/man/manX PID file: /usr/local/etc Random number collection: Builtin (timeout 200) Manpage format: man PAM support: yes 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: no Host: sparc-sun-solaris2.7 Compiler: gcc Compiler flags: -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openss l/include Linker flags: -L/usr/local/lib -R/usr/local/lib -L/usr/ucblib -R/usr/ucbli b -L/usr/local/openssl/lib -L/usr/local/openssl -R/usr/local/openssl/lib -R/ usr/ local/openssl Libraries: -ldl -lsocket -lnsl -lz -lpam -lcrypto WARNING: you are using the builtin random number collection service. Please read WARNING.RNG and request that your OS vendor includes /dev/random in future versions of their OS. # make gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-arc4random.c gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-base64.c gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-bindresvport.c bsd-bindresvport.c: In function `bindresvport_af': bsd-bindresvport.c:59: warning: `error' might be used uninitialized in this func tion gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-daemon.c gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-getcwd.c gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-inet_aton.c bsd-inet_aton.c: In function `inet_aton': bsd-inet_aton.c:117: warning: subscript has type `char' bsd-inet_aton.c:128: warning: subscript has type `char' bsd-inet_aton.c:131: warning: subscript has type `char' bsd-inet_aton.c:133: warning: subscript has type `char' bsd-inet_aton.c:155: warning: subscript has type `char' gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-inet_ntoa.c gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-misc.c gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-mktemp.c bsd-mktemp.c: In function `_gettemp': bsd-mktemp.c:167: warning: subscript has type `char' gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-realpath.c gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-rresvport.c bsd-rresvport.c: In function `rresvport_af': bsd-rresvport.c:64: warning: implicit declaration of function `bzero' gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-setenv.c bsd-setenv.c: In function `setenv': bsd-setenv.c:125: warning: implicit declaration of function `bcopy' gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-sigaction.c gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-snprintf.c gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-strlcat.c gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-strlcpy.c gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-strsep.c gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-strtok.c gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-vis.c gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-setproctitle.c bsd-setproctitle.c:62: warning: `__progname' defined but not used gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-waitpid.c gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c fake-getaddrinfo.c gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c fake-getnameinfo.c gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - DETC DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE FAUL T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c next-posix.c rv libopenbsd-compat.a bsd-arc4random.o bsd-base64.o bsd-bindresvport.o bsd-daem on.o bsd-getcwd.o bsd-inet_aton.o bsd-inet_ntoa.o bsd-misc.o bsd-mktemp.o bsd-re alpath.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-wait pid.o fake-getaddrinfo.o fake-getnameinfo.o next-posix.o sh: rv: not found *** Error code 1 make: Fatal error: Command failed for target `libopenbsd-compat.a' # Any suggestions.... -Christian From rcaetano at linux.ime.usp.br Wed Nov 29 04:50:59 2000 From: rcaetano at linux.ime.usp.br (Rafael Caetano dos Santos) Date: Tue, 28 Nov 2000 15:50:59 -0200 Subject: dubious behavior during login Message-ID: <20001128155059.D17973@linux.ime.usp.br> Hi, I'm running openssh-2.3.0p1 under Tru64 4.0. I've got the sources and built it whithout additional options. The `problem' happens when a login from a non-existing user is attempted: $ ssh bogus at foo.com Connection closed by foo.com It doesn't even ask the password. So anyone can test whether this host has a user called bogus. I'm not sure whether this is a bug, but I guess it's not advisable to give away such information. I also run ssh 2.2.0p1 under Debian GNU/Linux, but its behavior is different (and correct, I suppose): $ ssh bogus at foo.com bogus at foo's password: Permission denied, please try again. Please cc: me, since I'm not subscribed to the list. Thanks in advance. bye Rafael Caetano From Florian.Weimer at RUS.Uni-Stuttgart.DE Wed Nov 29 06:04:13 2000 From: Florian.Weimer at RUS.Uni-Stuttgart.DE (Florian Weimer) Date: 28 Nov 2000 20:04:13 +0100 Subject: none In-Reply-To: <000401c0595e$fa003790$4b273b40@cchiaverini> References: <000401c0595e$fa003790$4b273b40@cchiaverini> Message-ID: "Christian Chiaverini" writes: > sh: rv: not found The ar(1) binary was probably not found by ./configure. Is it installed? Could you examine the output of ./configure in this regard? -- 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 mouring at etoh.eviladmin.org Wed Nov 29 12:01:45 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 28 Nov 2000 19:01:45 -0600 (CST) Subject: your mail In-Reply-To: <000401c0595e$fa003790$4b273b40@cchiaverini> Message-ID: Add in /usr/ccs/bin in your path. If you are luckly and installed the right core Solaris development tools this problem will disappear. It's having problems find 'ar' command, and that is the standard location on solaris for it. On Tue, 28 Nov 2000, Christian Chiaverini wrote: > > I have a problem compiling openssh 2.3.0p1 > The configure script runs fine then if you see below; when I compile it > dies: > > > Manual pages: /usr/local/man/manX > PID file: /usr/local/etc > Random number collection: Builtin (timeout 200) > Manpage format: man > PAM support: yes > 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: no > > Host: sparc-sun-solaris2.7 > Compiler: gcc > Compiler > flags: -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openss > l/include > Linker > flags: -L/usr/local/lib -R/usr/local/lib -L/usr/ucblib -R/usr/ucbli > b -L/usr/local/openssl/lib -L/usr/local/openssl -R/usr/local/openssl/lib -R/ > usr/ > local/openssl > Libraries: -ldl -lsocket -lnsl -lz -lpam -lcrypto > > WARNING: you are using the builtin random number collection service. > Please read WARNING.RNG and request that your OS vendor includes > /dev/random in future versions of their OS. > > # make > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-arc4random.c > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-base64.c > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-bindresvport.c > bsd-bindresvport.c: In function `bindresvport_af': > bsd-bindresvport.c:59: warning: `error' might be used uninitialized in this > func > tion > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-daemon.c > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-getcwd.c > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-inet_aton.c > bsd-inet_aton.c: In function `inet_aton': > bsd-inet_aton.c:117: warning: subscript has type `char' > bsd-inet_aton.c:128: warning: subscript has type `char' > bsd-inet_aton.c:131: warning: subscript has type `char' > bsd-inet_aton.c:133: warning: subscript has type `char' > bsd-inet_aton.c:155: warning: subscript has type `char' > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-inet_ntoa.c > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-misc.c > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-mktemp.c > bsd-mktemp.c: In function `_gettemp': > bsd-mktemp.c:167: warning: subscript has type `char' > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-realpath.c > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-rresvport.c > bsd-rresvport.c: In function `rresvport_af': > bsd-rresvport.c:64: warning: implicit declaration of function `bzero' > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-setenv.c > bsd-setenv.c: In function `setenv': > bsd-setenv.c:125: warning: implicit declaration of function `bcopy' > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-sigaction.c > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-snprintf.c > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-strlcat.c > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-strlcpy.c > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-strsep.c > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-strtok.c > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-vis.c > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-setproctitle.c > bsd-setproctitle.c:62: warning: `__progname' defined but not used > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-waitpid.c > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c fake-getaddrinfo.c > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c fake-getnameinfo.c > gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - > DETC > DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DE > FAUL > T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c next-posix.c > rv libopenbsd-compat.a bsd-arc4random.o bsd-base64.o bsd-bindresvport.o > bsd-daem > on.o bsd-getcwd.o bsd-inet_aton.o bsd-inet_ntoa.o bsd-misc.o bsd-mktemp.o > bsd-re > alpath.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-wait > pid.o fake-getaddrinfo.o fake-getnameinfo.o next-posix.o > sh: rv: not found > *** Error code 1 > make: Fatal error: Command failed for target `libopenbsd-compat.a' > # > > Any suggestions.... > > -Christian > > From mouring at etoh.eviladmin.org Wed Nov 29 12:14:21 2000 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 28 Nov 2000 19:14:21 -0600 (CST) Subject: dubious behavior during login In-Reply-To: <20001128155059.D17973@linux.ime.usp.br> Message-ID: Can we get a ssh -v -v on the Tru64 machine please? On Tue, 28 Nov 2000, Rafael Caetano dos Santos wrote: > Hi, > > I'm running openssh-2.3.0p1 under Tru64 4.0. > I've got the sources and built it whithout additional options. > The `problem' happens when a login from a non-existing user is attempted: > > $ ssh bogus at foo.com > Connection closed by foo.com > > It doesn't even ask the password. So anyone can test whether this > host has a user called bogus. > I'm not sure whether this is a bug, but I guess it's not advisable to > give away such information. > > I also run ssh 2.2.0p1 under Debian GNU/Linux, but its behavior > is different (and correct, I suppose): > > $ ssh bogus at foo.com > bogus at foo's password: > Permission denied, please try again. > > Please cc: me, since I'm not subscribed to the list. > > Thanks in advance. > > bye > Rafael Caetano > From djm at mindrot.org Wed Nov 29 13:30:11 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 29 Nov 2000 13:30:11 +1100 (EST) Subject: To Do list... In-Reply-To: Message-ID: On Sun, 19 Nov 2000, Pekka Savola wrote: > Anyway, it looks rather complete. Going through man pages: > 1) added /etc/sshrc to the list > 2) /usr/X11R6/bin/xauth might be a good candidate, but it isn't exported > in Makefile.. > 3) /etc/rc is mentioned a lot on the pages, but as there is no uniform > alternative, so it's probably best to leave that alone. I have applied your patch and have added the xauth path as well. Thanks again, 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 Nov 29 17:19:55 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 29 Nov 2000 17:19:55 +1100 (EST) Subject: Snapshot Message-ID: I have just uploaded a new snapshot to http://www.mindrot.org/misc/openssh/ Snapshot production is now automated - new snapshots will be made at about 4:30 am (Australian Eastern time) and will be available from the URL above. This snapshot consists of mainly minor fixes over the previous. The race when sshd exits which was causing data loss (as evidenced by "ssh localhost dd if=/dev/zero bs=10000 count=1 | wc -c") has been avoided by reverting to the previous behaviour of stalling until all child processes have exited. This will cause ssh sessions to hang on logout if there are background processes with open fds, but it is better than data loss. Investigation on how to best fix this problem is continuing and assistance would be appreciated. Changelog: 20001129 - (djm) Back out all the serverloop.c hacks. sshd will now hang again if there are background children with open fds. - (djm) bsd-rresvport.c bzero -> memset - (djm) Don't fail in defines.h on absence of 64 bit types (we will still fail during compilation of sftp-server). - (djm) Fail if ar is not found during configure - (djm) OpenBSD CVS updates: - provos at cvs.openbsd.org 2000/11/22 08:38:31 [sshd.8] talk about /etc/primes, okay markus@ - markus at cvs.openbsd.org 2000/11/23 14:03:48 [ssh.c sshconnect1.c sshconnect2.c] complain about invalid ciphers for ssh1/ssh2, fall back to reasonable defaults - markus at cvs.openbsd.org 2000/11/25 09:42:53 [sshconnect1.c] reorder check for illegal ciphers, bugreport from espie@ - markus at cvs.openbsd.org 2000/11/25 10:19:34 [ssh-keygen.c ssh.h] print keytype when generating a key. reasonable defaults for RSA1/RSA/DSA keys. - (djm) Patch from Pekka Savola to include a few more manpage paths in fixpaths calls - (djm) Also add xauth path at Pekka's suggestion. - (djm) Add Redhat RPM patch for AUTHPRIV SyslogFacility 20001125 - (djm) Give up privs when reading seed file 20001123 - (bal) Merge OpenBSD changes: - markus at cvs.openbsd.org 2000/11/15 22:31:36 [auth-options.c] case insensitive key options; from stevesk at sweeden.hp.com - markus at cvs.openbsd.org 2000/11/16 17:55:43 [dh.c] do not use perror() in sshd, after child is forked() - markus at cvs.openbsd.org 2000/11/14 23:42:40 [auth-rsa.c] parse option only if key matches; fix some confusing seen by the client - markus at cvs.openbsd.org 2000/11/14 23:44:19 [session.c] check no_agent_forward_flag for ssh-2, too - markus at cvs.openbsd.org 2000/11/15 [ssh-agent.1] reorder SYNOPSIS; typo, use .It - markus at cvs.openbsd.org 2000/11/14 23:48:55 [ssh-agent.c] do not reorder keys if a key is removed - markus at cvs.openbsd.org 2000/11/15 19:58:08 [ssh.c] just ignore non existing user keys - millert at cvs.openbsd.org 200/11/15 20:24:43 [ssh-keygen.c] Add missing \n at end of error message. 20001122 - (bal) Minor patch to ensure platforms lacking IRIX job limit supports are compilable. - (bal) Updated TODO as of 11/18/2000 with known things to resolve. 20001117 - (bal) Changed from 'primes' to 'primes.out' for consistancy sake. It has no affect the output. Patch by Corinna Vinschen - (stevek) Reworked progname support. - (bal) Misplaced #include "includes.h" in bsd-setproctitle.c. Patch by Shinichi Maruyama 20001116 - (bal) Added in MAXSYMLINK test in bsd-realpath.c. Required for some SCO releases. - (bal) Make builds work outside of source tree. Patch by Mark D. Roth 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 Ulrich.Windl at rz.uni-regensburg.de Wed Nov 29 21:24:59 2000 From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl) Date: Wed, 29 Nov 2000 11:24:59 +0100 Subject: RPC exception: "Who are you failed (dce / rpc)" Message-ID: <3A24E784.15555.BB277C@localhost> Hello, with OpenSSH_2.3.0p1 running in HP-UX 11.00 I noticed that the "SD commands" (like "swcopy") produce the following error when being logged in via SSH: ERROR: RPC exception: "Who are you failed (dce / rpc)" 11/29/00 11:20:18 MET Ideas? Regards, Ulrich P.S. Not subscribed to the list From wpilorz at bdk.pl Wed Nov 29 22:13:00 2000 From: wpilorz at bdk.pl (Wojtek Pilorz) Date: Wed, 29 Nov 2000 12:13:00 +0100 (CET) Subject: RPC exception: "Who are you failed (dce / rpc)" In-Reply-To: <3A24E784.15555.BB277C@localhost> Message-ID: On Wed, 29 Nov 2000, Ulrich Windl wrote: > Date: Wed, 29 Nov 2000 11:24:59 +0100 > From: Ulrich Windl > To: openssh-unix-dev at mindrot.org > Subject: RPC exception: "Who are you failed (dce / rpc)" > > Hello, > > with OpenSSH_2.3.0p1 running in HP-UX 11.00 I noticed that the "SD > commands" (like "swcopy") produce the following error when being logged > in via SSH: > > ERROR: RPC exception: "Who are you failed (dce / rpc)" 11/29/00 > 11:20:18 MET > Maybe you choose such a command with a relatively few system calls, and run it via truss/strace over ssh and over transport which works correctly (telnet?), and then compare truss/strace outputs to see what is failing... > Ideas? > > Regards, > Ulrich > P.S. Not subscribed to the list > Best regards, Wojtek From djm at mindrot.org Wed Nov 29 23:03:25 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 29 Nov 2000 23:03:25 +1100 (EST) Subject: RPC exception: "Who are you failed (dce / rpc)" In-Reply-To: <3A24E784.15555.BB277C@localhost> Message-ID: On Wed, 29 Nov 2000, Ulrich Windl wrote: > Hello, > > with OpenSSH_2.3.0p1 running in HP-UX 11.00 I noticed that the "SD > commands" (like "swcopy") produce the following error when being logged > in via SSH: > > ERROR: RPC exception: "Who are you failed (dce / rpc)" 11/29/00 > 11:20:18 MET Is there a difference in the environment that is set up by login vs ssh? -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 Ulrich.Windl at rz.uni-regensburg.de Thu Nov 30 00:51:02 2000 From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl) Date: Wed, 29 Nov 2000 14:51:02 +0100 Subject: RPC exception: "Who are you failed (dce / rpc)" In-Reply-To: References: <3A24E784.15555.BB277C@localhost> Message-ID: <3A2517CF.13626.177D222@localhost> On 29 Nov 2000, at 23:03, Damien Miller wrote: > On Wed, 29 Nov 2000, Ulrich Windl wrote: > > > Hello, > > > > with OpenSSH_2.3.0p1 running in HP-UX 11.00 I noticed that the "SD > > commands" (like "swcopy") produce the following error when being logged > > in via SSH: > > > > ERROR: RPC exception: "Who are you failed (dce / rpc)" 11/29/00 > > 11:20:18 MET > > Is there a difference in the environment that is set up by login vs ssh? Not very much as it seems: rkdvmhp6:windl(22) % diff /tmp/e{1,2} |more 1,2d0 < USER=windl < LOGNAME=windl 5,9c3 < MAIL=/var/mail/windl < SHELL=/usr/bin/csh < TZ=MET-1METDST < SSH_CLIENT=132.199.176.211 1037 22 < SSH_TTY=/dev/pts/0 --- > LOGNAME=windl 10a5,6 > SHELL=/usr/bin/csh > MAIL=/var/mail/windl 13a10,11 > TZ=MET-1METDST > USER=windl And the "wgo" seems to work, too: windl pts/0 Nov 29 10:45 root pts/1 Nov 29 10:46 windl pts/tb Nov 29 13:50 windl pts/4 Nov 21 12:38 Regards, Ulrich From jphollan at earthlink.net Thu Nov 30 01:38:01 2000 From: jphollan at earthlink.net (Jason Holland) Date: Wed, 29 Nov 2000 08:38:01 -0600 Subject: HP-UX 11.00 truncating remote commands Message-ID: hello all, i hope someone can help me out with this little nasty. i have openssh 2.3.0p1 installed on some hp-ux 11.00 boxes and a single linux box. i'm trying desperately to replace trusted hosts on these machines with something a little more secure. running some remote commands between the hp boxes, i'm getting different results with ssh than with remsh. root at hp1# remsh hp2 cat /etc/passwd | wc 649 2750 44210 root at hp1# ssh hp2 cat /etc/passwd | wc 607 2636 40960 root at hp1# that output should be the same. its basically chopping off 42 lines for some odd reason. i looked at the output, and though it does chop it off at the same place everytime, its not a strange character, just a /. has anyone seen this before?? when i run a similar command against the linux box, it works perfectly root at hp1# remsh linux1 cat /etc/passwd | awk -F: '{print $3}' | wc 23 23 67 root at hp1# ssh linux1 cat /etc/passwd | awk -F: '{print $3}' | wc 23 23 67 root at hp1# any ideas why the hp boxes would be truncating some of the output from my remote command, but the linux server does not??? i wish i had another platform to test this against, maybe its just an hp issue? thanks for any ideas! Jason From Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Nov 30 02:19:23 2000 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Wed, 29 Nov 2000 16:19:23 +0100 Subject: HP-UX 11.00 truncating remote commands In-Reply-To: ; from jphollan@earthlink.net on Wed, Nov 29, 2000 at 08:38:01AM -0600 References: Message-ID: <20001129161922.A27727@serv01.aet.tu-cottbus.de> On Wed, Nov 29, 2000 at 08:38:01AM -0600, Jason Holland wrote: > i hope someone can help me out with this little nasty. i have openssh > 2.3.0p1 installed on some hp-ux 11.00 boxes and a single linux box. i'm > trying desperately to replace trusted hosts on these machines with something > a little more secure. running some remote commands between the hp boxes, > i'm getting different results with ssh than with remsh. > > root at hp1# remsh hp2 cat /etc/passwd | wc > 649 2750 44210 > root at hp1# ssh hp2 cat /etc/passwd | wc > 607 2636 40960 > root at hp1# Hmm. First part of the answer: I just made some experiments and could not reproduce the behaviour on HP-UX 10.20. (This actually does not surprise me, as I run 2.3.0p1 in production since its release and I would have noted the behaviour you describe...) I only have a vague idea on what to look for: 40960 is 10x4096, this probably is not just coincidence. Especially when 10x4096=5x8192 and PIPE_BUF=8192... > root at hp1# remsh linux1 cat /etc/passwd | awk -F: '{print $3}' | wc > 23 23 67 > root at hp1# ssh linux1 cat /etc/passwd | awk -F: '{print $3}' | wc > 23 23 67 > root at hp1# Unfortunately, the size to be treated is different. Could you also try to run a larger file through "cat" and only pass it through wc? 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 J.Horne at plymouth.ac.uk Thu Nov 30 02:23:00 2000 From: J.Horne at plymouth.ac.uk (John Horne) Date: Wed, 29 Nov 2000 15:23:00 -0000 (GMT) Subject: Pseudo-tty allocation and -T option Message-ID: Hello, I've set up a cron job to use ssh with a remote forced command to delete the contents of a directory. System A has the cron job and uses a specific key for system B. No command as such is specified since the key on system B specifies 'command=/bin/rm -rf ...'. However, I am getting error messages back from the cron system (or rather from ssh) about it not allocating a tty since there is no controlling terminal - obviously not since the job is run through cron: Pseudo-terminal will not be allocated because stdin is not a terminal. I have tried using the -T option and specifying no_pty in the key options on system B, but I still get the error message. The man page for ssh says: -T Disable pseudo-tty allocation (protocol version 2 only). We are only using protocol 2; openssh 2.3.0p1. So is '-T' not working correctly, am I doing something wrong or is openssh correct in that it will always print out the message if used via cron? If the latter then how can I 'remove' the message since the output gets mailed back to the user (in this case the postmasters). I have thought about using: ssh .... 2>&1 | egrep -v "^Pseudo-terminal will not be" which seems to work but seems a bit messy. Using '-q' to ssh makes no difference either. My understanding from the man page is that -T should prevent it attempting to allocate a tty. Thanks for any help, 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 jphollan at earthlink.net Thu Nov 30 02:38:04 2000 From: jphollan at earthlink.net (Jason Holland) Date: Wed, 29 Nov 2000 09:38:04 -0600 Subject: HP-UX 11.00 truncating remote commands In-Reply-To: <20001129161922.A27727@serv01.aet.tu-cottbus.de> Message-ID: Ok, this is very weird. root at hp1# remsh hp2 cat /var/adm/syslog/xferlog | wc 220378 4187182 28622518 root at hp1# ssh hp2 cat /var/adm/syslog/xferlog | wc 220378 4187182 28622518 root at hp1# that worked! and whats stranger is going to the linux box root at hp1# ssh linux1 cat /var/log/cron | wc 1788 13212 164864 root at hp1# remsh linux1 cat /var/log/cron | wc 2342 17275 215496 root at hp1# that didn't work! :) i don't understand this. could this be a problem with my clients on the hp side? from the linux box, to an hp box, it works root at linux1# ssh hp1 cat /var/adm/syslog/xferlog | wc 28440 540360 3859990 root at linux1# rsh hp1 cat /var/adm/syslog/xferlog | wc 28440 540360 3859990 root at linux1# ??? i used gcc 2.95.2 and openssl 0.95a to compile openssh on my hp boxes. i have no clue, this is just too weird. Jason > > On Wed, Nov 29, 2000 at 08:38:01AM -0600, Jason Holland wrote: > > i hope someone can help me out with this little nasty. i have openssh > > 2.3.0p1 installed on some hp-ux 11.00 boxes and a single linux box. i'm > > trying desperately to replace trusted hosts on these machines > with something > > a little more secure. running some remote commands between the > hp boxes, > > i'm getting different results with ssh than with remsh. > > > > root at hp1# remsh hp2 cat /etc/passwd | wc > > 649 2750 44210 > > root at hp1# ssh hp2 cat /etc/passwd | wc > > 607 2636 40960 > > root at hp1# > > Hmm. First part of the answer: I just made some experiments and could not > reproduce the behaviour on HP-UX 10.20. (This actually does not surprise > me, as I run 2.3.0p1 in production since its release and I would > have noted > the behaviour you describe...) > > I only have a vague idea on what to look for: 40960 is 10x4096, > this probably > is not just coincidence. Especially when 10x4096=5x8192 and > PIPE_BUF=8192... > > > root at hp1# remsh linux1 cat /etc/passwd | awk -F: '{print $3}' | wc > > 23 23 67 > > root at hp1# ssh linux1 cat /etc/passwd | awk -F: '{print $3}' | wc > > 23 23 67 > > root at hp1# > > Unfortunately, the size to be treated is different. Could you also try to > run a larger file through "cat" and only pass it through wc? > > 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 Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Nov 30 02:48:36 2000 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Wed, 29 Nov 2000 16:48:36 +0100 Subject: HP-UX 11.00 truncating remote commands In-Reply-To: ; from jphollan@earthlink.net on Wed, Nov 29, 2000 at 09:38:04AM -0600 References: <20001129161922.A27727@serv01.aet.tu-cottbus.de> Message-ID: <20001129164836.A28172@serv01.aet.tu-cottbus.de> On Wed, Nov 29, 2000 at 09:38:04AM -0600, Jason Holland wrote: > root at hp1# remsh hp2 cat /var/adm/syslog/xferlog | wc > 220378 4187182 28622518 > root at hp1# ssh hp2 cat /var/adm/syslog/xferlog | wc > 220378 4187182 28622518 > root at hp1# > > that worked! and whats stranger is going to the linux box > > root at hp1# ssh linux1 cat /var/log/cron | wc > 1788 13212 164864 > root at hp1# remsh linux1 cat /var/log/cron | wc > 2342 17275 215496 > root at hp1# > > that didn't work! :) i don't understand this. could this be a problem > with my clients on the hp side? from the linux box, to an hp box, it works Yes, one could come to the impression that it has something to do with the client side. > ??? i used gcc 2.95.2 and openssl 0.95a to compile openssh on my hp boxes. > i have no clue, this is just too weird. That's weird indeed. I have not seen a single failure (HP ANSI-C, OpenSSL 0.9.6). I run OpenSSH in default (ssh1) mode, do you also run protocol 1? This _could_ make a significatn difference. 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 jphollan at earthlink.net Thu Nov 30 02:53:20 2000 From: jphollan at earthlink.net (Jason Holland) Date: Wed, 29 Nov 2000 09:53:20 -0600 Subject: HP-UX 11.00 truncating remote commands In-Reply-To: <20001129164836.A28172@serv01.aet.tu-cottbus.de> Message-ID: I only run protocol 2. Would that make a difference? > > On Wed, Nov 29, 2000 at 09:38:04AM -0600, Jason Holland wrote: > > root at hp1# remsh hp2 cat /var/adm/syslog/xferlog | wc > > 220378 4187182 28622518 > > root at hp1# ssh hp2 cat /var/adm/syslog/xferlog | wc > > 220378 4187182 28622518 > > root at hp1# > > > > that worked! and whats stranger is going to the linux box > > > > root at hp1# ssh linux1 cat /var/log/cron | wc > > 1788 13212 164864 > > root at hp1# remsh linux1 cat /var/log/cron | wc > > 2342 17275 215496 > > root at hp1# > > > > that didn't work! :) i don't understand this. could this be a problem > > with my clients on the hp side? from the linux box, to an hp > box, it works > > Yes, one could come to the impression that it has something to do with > the client side. > > > ??? i used gcc 2.95.2 and openssl 0.95a to compile openssh on > my hp boxes. > > i have no clue, this is just too weird. > > That's weird indeed. I have not seen a single failure (HP ANSI-C, OpenSSL > 0.9.6). I run OpenSSH in default (ssh1) mode, do you also run protocol 1? > This _could_ make a significatn difference. > > 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 Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Nov 30 03:10:32 2000 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Wed, 29 Nov 2000 17:10:32 +0100 Subject: HP-UX 11.00 truncating remote commands In-Reply-To: ; from jphollan@earthlink.net on Wed, Nov 29, 2000 at 09:53:20AM -0600 References: <20001129164836.A28172@serv01.aet.tu-cottbus.de> Message-ID: <20001129171032.A21757@ws01.aet.tu-cottbus.de> On Wed, Nov 29, 2000 at 09:53:20AM -0600, Jason Holland wrote: > I only run protocol 2. Would that make a difference? Yes. In this case your problem was already discussed on the list as "fds closed after SIGCHLD bug still in newest version" 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 jphollan at earthlink.net Thu Nov 30 03:12:49 2000 From: jphollan at earthlink.net (Jason Holland) Date: Wed, 29 Nov 2000 10:12:49 -0600 Subject: HP-UX 11.00 truncating remote commands In-Reply-To: <20001129171032.A21757@ws01.aet.tu-cottbus.de> Message-ID: Ah, I missed that thread. Well, as it turns out, I switched all the boxes over to protocol version 1 and it works! Yippee! Thanks much for your help again Lutz! I'll keep an eye out for the fix to that bug in the near future. Jason > > On Wed, Nov 29, 2000 at 09:53:20AM -0600, Jason Holland wrote: > > I only run protocol 2. Would that make a difference? > > Yes. In this case your problem was already discussed on the list as > "fds closed after SIGCHLD bug still in newest version" > > 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 christian at cintra.com Thu Nov 30 04:24:56 2000 From: christian at cintra.com (Christian Chiaverini) Date: Wed, 29 Nov 2000 12:24:56 -0500 Subject: ssh problem Message-ID: <000401c05a29$4b514470$4b273b40@cchiaverini> It was simple, I left out /usr/ccs/bin out of my path during compilation. Thanks, Christian -----Original Message----- From: mdb at juniper.net [mailto:mdb at juniper.net] Sent: Tuesday, November 28, 2000 2:03 PM To: Christian Chiaverini Subject: Re: It looks to me like the $(AR) make macro is giving the empty string. You probably want it to be /usr/ccs/bin/ar Let openssh-unix-dev at mindrot.org know if/when you solve the problem. -- Mark >From: "Christian Chiaverini" >To: >Subject: >Date: Tue, 28 Nov 2000 12:16:41 -0500 > >I have a problem compiling openssh 2.3.0p1 >The configure script runs fine then if you see below; when I compile it >dies: > > > Manual pages: /usr/local/man/manX > PID file: /usr/local/etc > Random number collection: Builtin (timeout 200) > Manpage format: man > PAM support: yes > 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: no > > Host: sparc-sun-solaris2.7 > Compiler: gcc > Compiler >flags: -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openss >l/include > Linker >flags: -L/usr/local/lib -R/usr/local/lib -L/usr/ucblib -R/usr/ucbli >b -L/usr/local/openssl/lib -L/usr/local/openssl -R/usr/local/openssl/lib -R / >usr/ >local/openssl > Libraries: -ldl -lsocket -lnsl -lz -lpam -lcrypto > >WARNING: you are using the builtin random number collection service. >Please read WARNING.RNG and request that your OS vendor includes >/dev/random in future versions of their OS. > ># make >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-arc4random.c >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-base64.c >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-bindresvport.c >bsd-bindresvport.c: In function `bindresvport_af': >bsd-bindresvport.c:59: warning: `error' might be used uninitialized in this >func >tion >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-daemon.c >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-getcwd.c >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-inet_aton.c >bsd-inet_aton.c: In function `inet_aton': >bsd-inet_aton.c:117: warning: subscript has type `char' >bsd-inet_aton.c:128: warning: subscript has type `char' >bsd-inet_aton.c:131: warning: subscript has type `char' >bsd-inet_aton.c:133: warning: subscript has type `char' >bsd-inet_aton.c:155: warning: subscript has type `char' >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-inet_ntoa.c >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-misc.c >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-mktemp.c >bsd-mktemp.c: In function `_gettemp': >bsd-mktemp.c:167: warning: subscript has type `char' >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-realpath.c >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-rresvport.c >bsd-rresvport.c: In function `rresvport_af': >bsd-rresvport.c:64: warning: implicit declaration of function `bzero' >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-setenv.c >bsd-setenv.c: In function `setenv': >bsd-setenv.c:125: warning: implicit declaration of function `bcopy' >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-sigaction.c >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-snprintf.c >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-strlcat.c >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-strlcpy.c >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-strsep.c >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-strtok.c >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-vis.c >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-setproctitle.c >bsd-setproctitle.c:62: warning: `__progname' defined but not used >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c bsd-waitpid.c >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c fake-getaddrinfo.c >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c fake-getnameinfo.c >gcc -g -O2 -Wall -I. -I. -I/usr/local/include -I/usr/local/openssl/include - >DETC >DIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_D E >FAUL >T=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c next-posix.c >rv libopenbsd-compat.a bsd-arc4random.o bsd-base64.o bsd-bindresvport.o >bsd-daem >on.o bsd-getcwd.o bsd-inet_aton.o bsd-inet_ntoa.o bsd-misc.o bsd-mktemp.o >bsd-re >alpath.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-wait >pid.o fake-getaddrinfo.o fake-getnameinfo.o next-posix.o >sh: rv: not found >*** Error code 1 >make: Fatal error: Command failed for target `libopenbsd-compat.a' ># > >Any suggestions.... > >-Christian > > From stevesk at sweden.hp.com Thu Nov 30 09:24:45 2000 From: stevesk at sweden.hp.com (Kevin Steves) Date: Wed, 29 Nov 2000 23:24:45 +0100 (CET) Subject: RPC exception: "Who are you failed (dce / rpc)" In-Reply-To: Message-ID: <200011292219.XAA16936@b0fh.sweden.hp.com> On Wed, 29 Nov 2000, Wojtek Pilorz wrote: : > with OpenSSH_2.3.0p1 running in HP-UX 11.00 I noticed that the "SD : > commands" (like "swcopy") produce the following error when being logged : > in via SSH: : > : > ERROR: RPC exception: "Who are you failed (dce / rpc)" 11/29/00 : > 11:20:18 MET Is swagentd running? : Maybe you choose such a command with a relatively few system calls, : and run it via truss/strace over ssh and over transport which works : correctly (telnet?), and then compare truss/strace outputs to see what is : failing... The truss/trace on HP-UX 11 would be tusc, and is at: ftp://ftp.cup.hp.com/dist/networking/misc/tusc.shar From markus.friedl at informatik.uni-erlangen.de Thu Nov 30 18:02:08 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 30 Nov 2000 08:02:08 +0100 Subject: Pseudo-tty allocation and -T option In-Reply-To: ; from J.Horne@plymouth.ac.uk on Wed, Nov 29, 2000 at 03:23:00PM -0000 References: Message-ID: <20001130080208.A8115@folly> try the patch or ssh host dummy instead of ssh host -markus Index: ssh.c =================================================================== RCS file: /home/markus/cvs/ssh/ssh.c,v retrieving revision 1.74 diff -u -r1.74 ssh.c --- ssh.c 2000/11/23 21:03:47 1.74 +++ ssh.c 2000/11/30 07:00:38 @@ -504,15 +504,15 @@ if (buffer_len(&command) == 0) tty_flag = 1; + /* Force no tty*/ + if (no_tty_flag) + tty_flag = 0; /* Do not allocate a tty if stdin is not a tty. */ if (!isatty(fileno(stdin))) { if (tty_flag) fprintf(stderr, "Pseudo-terminal will not be allocated because stdin is not a terminal.\n"); tty_flag = 0; } - /* force */ - if (no_tty_flag) - tty_flag = 0; /* Get user data. */ pw = getpwuid(original_real_uid); On Wed, Nov 29, 2000 at 03:23:00PM -0000, John Horne wrote: > Hello, > > I've set up a cron job to use ssh with a remote forced command to delete the > contents of a directory. System A has the cron job and uses a specific key > for system B. No command as such is specified since the key on system B > specifies 'command=/bin/rm -rf ...'. However, I am getting error messages > back from the cron system (or rather from ssh) about it not allocating a tty > since there is no controlling terminal - obviously not since the job is run > through cron: > > Pseudo-terminal will not be allocated because stdin is not a terminal. > > I have tried using the -T option and specifying no_pty in the > key options on system B, but I still get the error message. The man page for > ssh says: > > -T Disable pseudo-tty allocation (protocol version 2 only). > > We are only using protocol 2; openssh 2.3.0p1. So is '-T' not working > correctly, am I doing something wrong or is openssh correct in that it will > always print out the message if used via cron? If the latter then how can I > 'remove' the message since the output gets mailed back to the user (in this > case the postmasters). I have thought about using: > > ssh .... 2>&1 | egrep -v "^Pseudo-terminal will not be" > > which seems to work but seems a bit messy. Using '-q' to ssh makes no > difference either. My understanding from the man page is that -T should > prevent it attempting to allocate a tty. > > Thanks for any help, > > 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 gilesc at hyperlink.com Thu Nov 30 21:04:55 2000 From: gilesc at hyperlink.com (Giles Constant) Date: Thu, 30 Nov 2000 10:04:55 +0000 (GMT) Subject: Pseudo-tty allocation and -T option In-Reply-To: <20001130080208.A8115@folly> Message-ID: Failing that, I have a patch (well, I have a hacked version of ssh - i can make a patch :-)) that has a "-oPassword=foo" option. I haven't got round to making it clear the cmdline string out of the ps listing yet, but provided there's noone on your box capable of reading the ps listing it's safe. On Thu, 30 Nov 2000, Markus Friedl wrote: > try the patch or > ssh host dummy > instead of > ssh host > -markus > > Index: ssh.c > =================================================================== > RCS file: /home/markus/cvs/ssh/ssh.c,v > retrieving revision 1.74 > diff -u -r1.74 ssh.c > --- ssh.c 2000/11/23 21:03:47 1.74 > +++ ssh.c 2000/11/30 07:00:38 > @@ -504,15 +504,15 @@ > if (buffer_len(&command) == 0) > tty_flag = 1; > > + /* Force no tty*/ > + if (no_tty_flag) > + tty_flag = 0; > /* Do not allocate a tty if stdin is not a tty. */ > if (!isatty(fileno(stdin))) { > if (tty_flag) > fprintf(stderr, "Pseudo-terminal will not be allocated because stdin is not a terminal.\n"); > tty_flag = 0; > } > - /* force */ > - if (no_tty_flag) > - tty_flag = 0; > > /* Get user data. */ > pw = getpwuid(original_real_uid); > > > > On Wed, Nov 29, 2000 at 03:23:00PM -0000, John Horne wrote: > > Hello, > > > > I've set up a cron job to use ssh with a remote forced command to delete the > > contents of a directory. System A has the cron job and uses a specific key > > for system B. No command as such is specified since the key on system B > > specifies 'command=/bin/rm -rf ...'. However, I am getting error messages > > back from the cron system (or rather from ssh) about it not allocating a tty > > since there is no controlling terminal - obviously not since the job is run > > through cron: > > > > Pseudo-terminal will not be allocated because stdin is not a terminal. > > > > I have tried using the -T option and specifying no_pty in the > > key options on system B, but I still get the error message. The man page for > > ssh says: > > > > -T Disable pseudo-tty allocation (protocol version 2 only). > > > > We are only using protocol 2; openssh 2.3.0p1. So is '-T' not working > > correctly, am I doing something wrong or is openssh correct in that it will > > always print out the message if used via cron? If the latter then how can I > > 'remove' the message since the output gets mailed back to the user (in this > > case the postmasters). I have thought about using: > > > > ssh .... 2>&1 | egrep -v "^Pseudo-terminal will not be" > > > > which seems to work but seems a bit messy. Using '-q' to ssh makes no > > difference either. My understanding from the man page is that -T should > > prevent it attempting to allocate a tty. > > > > Thanks for any help, > > > > 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 uk at ap.univie.ac.at Thu Nov 30 21:06:13 2000 From: uk at ap.univie.ac.at (Ulrich Kiermayr) Date: Thu, 30 Nov 2000 11:06:13 +0100 (CET) Subject: Problem and Patch: Multiple keys in ssh.com V2 agent Message-ID: Hello! I recently discoverd a problem with ssh.com's ssh-agent2 and OpenSSH: 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. I have patched a little at auth2.c and auth.h [1], but I am absoluteley not sure if that patch is 100% ok and does not cause any other Problems. For me it works fine :) The errors in the sshd: debug1: userauth-request for user XXXXXX service ssh-connection method none debug1: attempt #1 debug1: Starting up PAM with username "XXXXXX" Failed none for XXXXXX from XXX.XXX.XXX.XXX port 34257 ssh2 debug1: userauth-request for user XXXXXX service ssh-connection method publickey debug1: attempt #2 debug1: test whether pkalg/pkblob are acceptable Failed publickey for XXXXXX from XXX.XXX.XXX.XXX port 34257 ssh2 debug1: userauth-request for user XXXXXX service ssh-connection method publickey debug1: attempt #3 debug1: test whether pkalg/pkblob are acceptable Failed publickey for XXXXXX from XXX.XXX.XXX.XXX port 34257 ssh2 debug1: userauth-request for user XXXXXX service ssh-connection method publickey debug1: attempt #4 debug1: test whether pkalg/pkblob are acceptable Failed publickey for XXXXXX from XXX.XXX.XXX.XXX port 34257 ssh2 debug1: userauth-request for user XXXXXX service ssh-connection method publickey debug1: attempt #5 debug1: test whether pkalg/pkblob are acceptable Failed publickey for XXXXXX from XXX.XXX.XXX.XXX port 34257 ssh2 debug1: userauth-request for user XXXXXX service ssh-connection method none debug1: attempt #6 Failed none for XXXXXX from XXX.XXX.XXX.XXX port 34257 ssh2 Disconnecting: too many failed userauth_requests debug1: Calling cleanup 0x12000c640(0x0) debug1: Calling cleanup 0x120029180(0x0) For the Record: Client: ssh: SSH Secure Shell 2.3.0 (non-commercial version) on i686-pc-linux-gnu RedHat Linux 6.2 (i386) Server: sshd version OpenSSH_2.3.0p1 RedHat Linux 6.2 (alpha) [1] My crude solution is not to increment the counter, if method is pubkey. I am not sure if this is a good idea, but at least i am able to log into that machine again without 'ssh-add -L' before. The main problem is that I have no way of testing that patch under other Platforms than Linux. P.S.: the same proble occurs if OpenSSH 2.1 under AIX is server. P.P.S.: If this bug was addressed before, please tell me where to find a fix and forget the rest :) 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 -------------- next part -------------- diff -ru openssh-2.3.0p1.orig/auth.h openssh-2.3.0p1/auth.h --- openssh-2.3.0p1.orig/auth.h Thu Nov 30 08:59:39 2000 +++ openssh-2.3.0p1/auth.h Thu Nov 30 10:32:54 2000 @@ -45,8 +45,8 @@ int allowed_user(struct passwd * pw); struct passwd * auth_get_user(void); -#define AUTH_FAIL_MAX 6 -#define AUTH_FAIL_LOG (AUTH_FAIL_MAX/2) +#define AUTH_FAIL_MAX 5 +#define AUTH_FAIL_LOG AUTH_FAIL_MAX #define AUTH_FAIL_MSG "Too many authentication failures for %.100s" #endif diff -ru openssh-2.3.0p1.orig/auth2.c openssh-2.3.0p1/auth2.c --- openssh-2.3.0p1.orig/auth2.c Thu Nov 30 08:59:39 2000 +++ openssh-2.3.0p1/auth2.c Thu Nov 30 10:37:56 2000 @@ -189,21 +189,14 @@ char *user, *service, *method; int authenticated = 0; + authctxt->attempt++; if (authctxt == NULL) fatal("input_userauth_request: no authctxt"); - if (authctxt->attempt++ >= AUTH_FAIL_MAX) { -#ifdef WITH_AIXAUTHENTICATE - loginfailed(authctxt->user?authctxt->user:"NOUSER", - get_canonical_hostname(), "ssh"); -#endif /* WITH_AIXAUTHENTICATE */ - packet_disconnect("too many failed userauth_requests"); - } - user = packet_get_string(NULL); service = packet_get_string(NULL); method = packet_get_string(NULL); debug("userauth-request for user %s service %s method %s", user, service, method); - debug("attempt #%d", authctxt->attempt); + debug("attempt #%d of %d", authctxt->attempt, AUTH_FAIL_MAX); if (authctxt->attempt == 1) { /* setup auth context */ @@ -254,6 +247,18 @@ if (authenticated && authctxt->user && !do_pam_account(authctxt->user, NULL)) authenticated = 0; #endif /* USE_PAM */ + + if (authenticated == 0 && authctxt->attempt >= AUTH_FAIL_MAX) { +#ifdef WITH_AIXAUTHENTICATE + loginfailed(authctxt->user?authctxt->user:"NOUSER", + get_canonical_hostname(), "ssh"); +#endif /* WITH_AIXAUTHENTICATE */ + packet_disconnect("too many failed userauth_requests"); + } + if ( strcmp(method,"publickey") == 0 ) { + authctxt->attempt--; + } + /* Log before sending the reply */ userauth_log(authctxt, authenticated, method); From Markus.Friedl at informatik.uni-erlangen.de Thu Nov 30 22:59:40 2000 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 30 Nov 2000 12:59:40 +0100 Subject: Pseudo-tty allocation and -T option In-Reply-To: ; from gilesc@hyperlink.com on Thu, Nov 30, 2000 at 10:04:55AM +0000 References: <20001130080208.A8115@folly> Message-ID: <20001130125939.A17888@faui02.informatik.uni-erlangen.de> On Thu, Nov 30, 2000 at 10:04:55AM +0000, Giles Constant wrote: > Failing that, I have a patch (well, I have a hacked version of ssh - i can > make a patch :-)) that has a "-oPassword=foo" option. I haven't got round > to making it clear the cmdline string out of the ps listing yet, but > provided there's noone on your box capable of reading the ps listing it's > safe. 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. -markus From markus.weis at d2mannesmann.de Wed Nov 29 19:30:26 2000 From: markus.weis at d2mannesmann.de (Markus Weis) Date: Wed, 29 Nov 2000 09:30:26 +0100 Subject: Bug Openssh v2.3.0 Message-ID: <3A24BEA1.BC71ABDD@d2mannesmann.de> Hello together, we have very often a problem using OpenSSH v2.3.0 on Solaris 2.6. The daemon hangs up and it is not possible to login in. The -v option for ssh displays the following: # ssh -v zvadm1 SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090600f). debug: Reading configuration data /etc/ssh_config debug: Seeded RNG with 34 bytes from programs debug: Seeded RNG with 3 bytes from system calls debug: ssh_connect: getuid 31194 geteuid 0 anon 1 debug: Connecting to zvadm1 [139.7.180.119] port 22. debug: Connection established. But no connection is possible. The system displays the following messages: /var/adm/messages ... Nov 29 09:00:01 zvadm1 sshd[6447]: error: select: Bad file number Nov 29 09:00:01 zvadm1 sshd[6447]: error: select: Bad file number Nov 29 09:00:01 zvadm1 sshd[6447]: error: select: Bad file number Nov 29 09:00:01 zvadm1 sshd[6447]: error: select: Bad file number Nov 29 09:00:01 zvadm1 sshd[6447]: error: select: Bad file number Nov 29 09:00:01 zvadm1 sshd[6447]: error: select: Bad file number Nov 29 09:00:01 zvadm1 sshd[6447]: error: select: Bad file number Nov 29 09:00:01 zvadm1 sshd[6447]: error: select: Bad file number Nov 29 09:00:01 zvadm1 sshd[6447]: error: select: Bad file number Nov 29 09:00:01 zvadm1 sshd[6447]: error: select: Bad file number Nov 29 09:00:33 zvadm1 sshd[6447]: error: select: Bad file number Nov 29 09:01:33 zvadm1 sshd[6447]: error: select: Bad file number Nov 29 09:02:34 zvadm1 sshd[6447]: error: select: Bad file number Nov 29 09:03:04 zvadm1 sshd[6447]: error: select: Bad file number Nov 29 09:03:34 zvadm1 sshd[6447]: error: select: Bad file number ... After a kill of all sshd on the system and a new start it is possible to login to the system. Can somebody help us? -- Mit freundlichen Gr??en / Best regards Markus Weis __________________________________ Markus Weis Mannesmann Mobilfunk GmbH Abt. FIUS (Unix) Am Seestern 4 40547 D?sseldorf Tel: +49 (0)211 5355-9703 Fax: +49 (0)211 5400721 __________________________________ From zvo at ldh.org Thu Nov 30 09:26:29 2000 From: zvo at ldh.org (zvo) Date: Wed, 29 Nov 2000 23:26:29 +0100 Subject: problem under debian w/ kernel 2.4.-test11 Message-ID: <3A258295.8C03D6B2@ldh.org> just to let you know: the authentication doesn't work correctly under linux: Nov 29 22:35:06 zobi sshd[11661]: Server listening on 0.0.0.0 port 22. Nov 29 22:35:06 zobi sshd[11661]: Generating 768 bit RSA key. Nov 29 22:35:07 zobi sshd[11661]: RSA key generation complete. Nov 29 22:36:11 zobi sshd[11668]: Failed password for zvo from 127.0.0.1 port 738 Nov 29 22:36:18 zobi sshd[11668]: Failed password for zvo from 127.0.0.1 port 738 Nov 29 22:36:19 zobi sshd[11668]: Failed password for zvo from 127.0.0.1 port 738 Nov 29 22:36:19 zobi sshd[11668]: Connection closed by 127.0.0.1 as suggested in your faqs, this is fixed by adding -lcrypt in the makefile (NB: this doesn't work on the command line w/ "LIBS=-lcrypt", one has to explicitely change this once the Makefile has been created by .configure) now this works great. tx for your attention, and also for your invaluable work. Cheers, z *^_-* From gei at cfa.harvard.edu Wed Nov 22 12:25:12 2000 From: gei at cfa.harvard.edu (Dr. Guenther Eichhorn) Date: Tue, 21 Nov 2000 20:25:12 -0500 Subject: problem with installing openssh on HP/UX Message-ID: <3A1B2077.2ACA14A6@cfa.harvard.edu> Hi, I am trying to install openssh on an HP: acro-284> uname -a HP-UX niit1 A.09.01 A 9000/730 2015353714 two-user license There were a couple of problems during compiling: 1. The system doesn't have seteuid or setreuid. It has setresuid. I had to define HAVE_SETREUID and modify bsd-misc.c to be: #if !defined(HAVE_SETEUID) && defined(HAVE_SETREUID) int seteuid(uid_t euid) { /* return(setreuid(-1,euid));*/ return(setresuid(-1,euid,-1)); } #endif /* !defined(HAVE_SETEUID) && defined(HAVE_SETREUID) */ 2. The file auth-passwd.c tries to include #ifdef __hpux # include # include #endif and further down uses functions that don't exist on the system. I prevented this by: #undef __hpux 3. The system doesn't have the function utimes. I put the following in bsd-misc.c: int utimes(const char *path, const struct timeval *times) { struct utimbuf tv ; tv.actime = times[0].tv_sec ; tv.modtime = times[1].tv_sec ; return(utime(path,&tv)) ; } These changes got make to work, but make install doesn't work. It fails when making the host-key: # make install ... ... if [ -z "" ] ; then \ if [ -f "/usr/local/etc/ssh_host_key" ] ; then \ echo "/usr/local/etc/ssh_host_key already exists, skipping." ; \ else \ ./ssh-keygen -b 1024 -f /usr/local/etc/ssh_host_key -N "" ; \ fi ; \ if [ -f /usr/local/etc/ssh_host_dsa_key ] ; then \ echo "/usr/local/etc/ssh_host_dsa_key already exists, skipping." ; \ else \ ./ssh-keygen -d -f /usr/local/etc/ssh_host_dsa_key -N "" ; \ fi ; \ fi ; PRNG initialisation failed -- exiting. *** Error code 255 Stop. # Any idea what I can do to make it work? Guenther --------------------------------------------------- Dr. Guenther Eichhorn | gei at cfa.harvard.edu Project Scientist | Phone: 617-495-7260 Astrophysics Data System | Fax: 617-496-7577 Smithsonian Astrophysical Observatory 60 Garden Street, MS-83, Cambridge, MA 02138, USA From theron at tock.com Thu Nov 30 16:13:43 2000 From: theron at tock.com (Theron Tock) Date: Wed, 29 Nov 2000 21:13:43 -0800 Subject: Hang with openssh when using rsync on redhat 6.2 References: Message-ID: <3A25E207.BBE48018@tock.com> Damien Miller wrote: > > On Tue, 28 Nov 2000, Theron Tock wrote: > > > I'm using rsync over ssh to do some backups from a redhat 6.2 machine > > and I found that I was able to semi-reproducibly get openssh to hang. > > Using strace and gdb, it seemed that the problem was due to a too-large > > call to write. > > What kernel are you using? kernel: Linux version 2.2.14-5.0smp (root at porky.devel.redhat.com) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Tue Mar 7 21:01:40 EST 2000 > > Can you discern anything from an strace of a failing client? > Yes -- the rsync client calls write() with somewhere around 50K of data and the call never returns. It's not 100% repeatable, though it happens almost every time (but at different points in the rsync). I do have a theory for why it might be happening. Rsync is communicating with ssh via a pipe, and rsync is busy shoveling large amounts of data through ssh to the remote rsync. The pipe fills up and the local rsync goes to sleep waiting for the pipe to get cleared. Meanwhile, ssh gets a response from the remote rsync and tries to write it back to the local rsync, but the fact that the write is so large (50K) and that the read side (from ssh's perspective) of the pipe is full causes the kernel to go to sleep waiting for the pipe to clear. Hence the deadlock. It sounds sort of hokey since I would have expected the read and write buffers of a pipe to be completely independent of eachother, but if they are somehow shared for writes >32K then that would explain the problem. The fact that it happens at different points of the rsync does support the theory though. One interesting thing is that if I attach to ssh with strace and then kill strace by hitting ^C, then ssh picks up and everything merrily resumes. I'm guessing that killing strace causes the system call to return with a partial write and everything can then proceed -- similar to if the write were done with a smaller buffer in the first place. -Theron From ajk at iu.edu Tue Nov 21 00:48:21 2000 From: ajk at iu.edu (Andrew J. Korty) Date: Mon, 20 Nov 2000 08:48:21 -0500 (EST) Subject: pam_ssh Message-ID: Greetings. Last year I completed a PAM module that provides single sign-on behavior for UNIX using SSH. Users are authenticated by decrypting their SSH private keys with the password provided (probably to XDM). In the PAM session phase, an ssh-agent process is started and any successfully decrypted private keys are added. Hence, users only type their logins and passwords once at the beginning of a session. As a side benefit, system administrators can elect to rid the password database of authentication data. At the time I wrote pam_ssh, Theo de Raadt said he wanted to keep the OpenSSH code base tightly-controlled, so my patches were not imported. FreeBSD was interested, however, and pam_ssh has been part of the core ever since. Now that the code has been performing well for a year in FreeBSD, would you consider importing it into OpenSSH (where it truly belongs, IMO)? Btw, I recently added support for DSA keys, though the changes have not yet been committed into FreeBSD. I noticed that, even though ssh-agent is able to cache DSA keys, ssh still doesn't seem to be able to grab them from the agent. I tried this with pam_ssh as well as starting ssh-agent and running ssh-add manually. Am I confused, or is full DSA support still in the works? -- Andrew J. Korty, Principal Security Engineer Office of the Vice President for Information Technology Indiana University From pnguyen at raileurope.com Wed Nov 29 06:55:47 2000 From: pnguyen at raileurope.com (Phong Nguyen) Date: Tue, 28 Nov 2000 14:55:47 -0500 Subject: No subject Message-ID: Hi I don't know if you can help me out, I try to install openssh 2.3.0p1, I did the ./configure it's ran ok, when I do make to complies, it keep spit out something like this make: rv: Command not found make: *** [libopenbsd-compat.a] Error 127 I am running Solaris 2.6 with perl 5.6 and openssl 0.9 gcc -g -O2 -Wall -I. -I. -I/usr/local/include -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 -o fake-getnameinfo.o fake-getnameinfo.c gcc -g -O2 -Wall -I. -I. -I/usr/local/include -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 -o next-posix.o next-posix.c rv libopenbsd-compat.a 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 make: rv: Command not found make: *** [libopenbsd-compat.a] Error 127 thanks Phong