From roumen.petrov at skalasoft.com Thu Feb 1 00:07:08 2001 From: roumen.petrov at skalasoft.com (Roumen Petrov) Date: Wed, 31 Jan 2001 15:07:08 +0200 Subject: PTY References: <3A77F620.10806@skalasoft.com> Message-ID: <3A780DFC.3010303@skalasoft.com> OPPS this no_dev_ptmx=1 is obsolete for linux kernel 2.2.x *-*-linux*) no_dev_ptmx=1 check_for_libcrypt_later=1 In attachment is my patch for PTY defines I remove in configure.in check for function "openpty", "_getpty" and for files "/dev/ptmx", "/dev/ptc" and HARD CODE no_dev_ptmx=1 with this code : AC_MSG_CHECKING([for PTYs]) AC_MSG_RESULT() AC_CHECK_FUNC(openpty, AC_DEFINE(HAVE_OPENPTY), AC_CHECK_FUNC(_getpty, AC_DEFINE(HAVE__GETPTY), AC_CHECK_FILE("/dev/ptmx", AC_DEFINE(HAVE_DEV_PTMX), AC_CHECK_FILE("/dev/ptc", AC_DEFINE_UNQUOTED(HAVE_DEV_PTS_AND_PTC), AC_MSG_ERROR(No PTY support for your system) ) ) ) ) AC_MSG_RESULT(OpenSSH support your PTY) -------------------------- For linux user who want to use /dev/ptmx : undef HAVE_OPENPTY and add -D_GNU_SOURCE to CFLAGS. -------------------------- What is more portable: openpty () method or /dev/ptmx ? -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.in.patch.gz Type: application/gzip Size: 1374 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010131/a9fdd795/attachment.bin From Markus.Friedl at informatik.uni-erlangen.de Thu Feb 1 01:16:23 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 31 Jan 2001 15:16:23 +0100 Subject: I: [PATCH] ssh-keygen In-Reply-To: <20010129064410.A25690@LDV.fandra.org>; from ldv@fandra.org on Mon, Jan 29, 2001 at 06:44:10AM +0300 References: <20010129064410.A25690@LDV.fandra.org> Message-ID: <20010131151623.A21391@faui02.informatik.uni-erlangen.de> On Mon, Jan 29, 2001 at 06:44:10AM +0300, Dmitry V. Levin wrote: > Greetings! > > According to documentation, "-x" and "-X" options of ssh-keygen designed > to work only with DSA keys. It means that key_type_name variable have to > be initialized to "dsa" if any of these options were specified. no, they should work for ssh-2 rsa keys, too. From Markus.Friedl at informatik.uni-erlangen.de Thu Feb 1 01:17:11 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 31 Jan 2001 15:17:11 +0100 Subject: list address In-Reply-To: <20010129093624.B15669@moni.msci.memphis.edu>; from mw@moni.msci.memphis.edu on Mon, Jan 29, 2001 at 09:36:24AM -0600 References: <20010129093624.B15669@moni.msci.memphis.edu> Message-ID: <20010131151711.A21480@faui02.informatik.uni-erlangen.de> no, i bounced some relevant messages. On Mon, Jan 29, 2001 at 09:36:24AM -0600, Mate Wierdl wrote: > Hi, > > I must have missed something; it seems that all messages sent to the > ssh list get forwarded to the openssh list. > > Thx > > Mate > -- > --- > Mate Wierdl | Dept. of Math. Sciences | University of Memphis > From SBrennan at eircom.ie Thu Feb 1 01:58:30 2001 From: SBrennan at eircom.ie (SBrennan at eircom.ie) Date: Wed, 31 Jan 2001 14:58:30 -0000 Subject: SCP slow transfers Message-ID: <97DF80028F6FD411BA9600D0B7847D02029FA2@nts_ctmsgp1.eircom.ie> Hello, I'm running openssh 2.3 on AIX 4.3.3. SCP file transfers are extremely slow. I am achieving a transfer rate of approx 170 kbs on a 100/mb network. Using native ftp I can achieve up to 10 times that rate. Any suggestions ? Regards \|/ (@^@) ----------------oOO-(_)-OOo--------------- Se?n Brennan sbrennan at eircom.ie -------------------|_|-|_|--------------------- **************************************************************** The information transmitted in this email is intended for the addressee only and may contain confidential and/or privileged material. Any review, retransmission,dissemination,reliance upon or other use of, this information by persons or entities other than the addressee is prohibited.If you received this in error, please contact the sender and delete the material. This message has been swept by Anti-Virus software **************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010131/6e95552a/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Blank Bkgrd.gif Type: image/gif Size: 145 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010131/6e95552a/attachment.gif From daniel.brandt at meridium.se Thu Feb 1 03:30:03 2001 From: daniel.brandt at meridium.se (Daniel Brandt) Date: Wed, 31 Jan 2001 17:30:03 +0100 Subject: OpenSSH on PalmOS possible? Message-ID: <4AFF51C45DD05A4E9F2DE28C114AA758032F2E@KARUBIN.meridium.se> A thought has been bugging me for a month or so, but I don't know where to look for the answer. Would it be possible to port the OpenSSH ssh client to PalmOS and other handheld OS'es like Symbian (EPOC) or PocketPC? Is the processor on PDA's fast enough? Would many libraries have to be ported aswell? I know that PalmOS and EPOC has an IP stack implemented.. Since the development tools and documentation is freely available (at least for PalmOS) a ported version would be able to be distributed without restrictions, and would be very useful for those emergency situations when you _have_ to get to the shell when you are out travelling or whatever.. I know I've missed it a lot of times.. Ideas? Ongoing projects in this direction? I'd love to hear about it.. Thanks.. Daniel Brandt Software Consultant daniel.brandt at meridium.se Tel: +46-(0)480-42 60 69 Mobil: +46-(0)73-330 01 32 Meridium AB N:a L?ngg. 1, 392 32 Tel: +46-(0)480-42 60 60 Fax: +46-(0)480-42 60 59 www.meridium.se Meridium AB - G?teborg, Kalmar, Stockholm From tom at avatar.itc.nrcs.usda.gov Thu Feb 1 03:33:39 2001 From: tom at avatar.itc.nrcs.usda.gov (Tom Rudnick) Date: Wed, 31 Jan 2001 09:33:39 -0700 (MST) Subject: dsa_verify signature incorrect In-Reply-To: <20010131110806.A27720@faui02.informatik.uni-erlangen.de> from "Markus Friedl" at Jan 31, 2001 11:08:06 AM Message-ID: <200101311633.JAA01231@avatar.itc.nrcs.usda.gov> > > On Tue, Jan 30, 2001 at 01:32:13PM -0700, Tom Rudnick wrote: > > > > I am building version 2.3.0p1 of openssh on a UnixWare 2.03 system > > and am unable to connect with SSH 2. The error I get is: > > > > debug: len 55 datafellows 0 > > debug: dsa_verify: signature incorrect > > dsa_verify failed for server_host_key > > > > The build environment is as follows: > > > > gcc 2.95.1 > > openssl-0.9.6-beta2 > > openssl-0.9.6-beta2 is broken. > > Yep. that was it. I rebuilt with openssl-0.9.6, relinked and it connected. Now, it hangs after establishing the interactive session. When I kill it I get: error: grantpt: Interrupted system call error: session_pty_req: session 0 alloc failed error: session_by_pid: unknown pid 27578 on the server side. The odd thing is that ssh-1 sessions work just fine. Is the session establishment and pty stuff the same for 1 and 2? -Tom -- ----------------/---------------------------------------------- Tom Rudnick | USDA Natural Resources Conservation Service Fort Collins,CO | tom at avatar.itc.nrcs.usda.gov (970) 295-5427 ** The 3rd Millennium starts Jan 1, 2001. see: ** ** http://aa.usno.navy.mil/AA/faq/docs/millennium.html ** -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From ddulek at fastenal.com Thu Feb 1 06:01:43 2001 From: ddulek at fastenal.com (David Dulek) Date: Wed, 31 Jan 2001 13:01:43 -0600 Subject: DG/UX R4.20MU05 port of 2.3.0p1 Message-ID: <01013113014306.17611@penelope> DG/UX does not impliment the regcomp, regexec functions. They suggest using regex and regcmp. The only place that I see that regexec and regcomp are used is in compat.c. Can someone help me out with the difference between regex and regexec and the differences between regcmp and regex. This should also help any other OS that does not have regexec. -- Dave Dulek From sunil at redback.com Thu Feb 1 06:20:51 2001 From: sunil at redback.com (Sunil K. Vallamkonda) Date: Wed, 31 Jan 2001 11:20:51 -0800 (PST) Subject: could not read dsa key. In-Reply-To: Message-ID: I am experiencing following problem. I had sent an email earlier but did not get any response on the problem. Problem: Could not load host key: ssh_host_dsa_key: Bad file descriptor The file exists, permissions are okay, etc. (from my last email..) Debugging on this, I see: poking futher into this, I find error while reading private host dsa key - I see decode error: EVP_DecodeFinal(...) calls EVP_DecodeBlock(..) which returns error. And the function call tree is: load_private_key_autodetect (...) at sshd.c:482 load_private_key (...) at authfile.c:538 load_private_key_ssh2 (...) at authfile.c:451 PEM_read_PrivateKey (...) at pem_all.c:200 PEM_ASN1_read (d2i=0x6eb40 , name=0x5fb34 "ANY PRIVATE KEY", fp=0x105a04, x=0x0, cb=0, u=0x1106) at pem_lib.c:180 PEM_ASN1_read_bio (d2i=0x6eb40 , name=0x5fb34 "ANY PRIVATE KEY", bp=0x117300, x=0x0, cb=0, u=0x1106) at pem_lib.c:238 PEM_read_bio (...) at pem_lib.c:774 DecodeFinal (...) at encode.c:395 ques: Is there a bug in ssh-keygen: generation of private host dsa key - which could be causing a read/decode error ? Any suggestions ? Thank you. Sunil. From mouring at etoh.eviladmin.org Thu Feb 1 07:17:37 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 31 Jan 2001 14:17:37 -0600 (CST) Subject: DG/UX R4.20MU05 port of 2.3.0p1 In-Reply-To: <01013113014306.17611@penelope> Message-ID: On Wed, 31 Jan 2001, David Dulek wrote: > DG/UX does not impliment the regcomp, regexec functions. They suggest using > regex and regcmp. The only place that I see that regexec and regcomp are > used is in compat.c. Can someone help me out with the difference between > regex and regexec and the differences between regcmp and regex. This should > also help any other OS that does not have regexec. > > regexec/regcomp is the POSIX form of regex/regcmp. Take from INSTALL from OpenSSH portable: [..] pcre (POSIX Regular Expression library): ftp://ftp.cus.cam.ac.uk/pub/software/programs/pcre/ Most platforms do not required this. However older 4.3 BSD do not have a posix regex library. [..] I added supported for pcre (GNU rx works with a tweak or two) after the change to compat.c was done to allow NeXT to compile. - Ben From markus.friedl at informatik.uni-erlangen.de Thu Feb 1 06:44:30 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 31 Jan 2001 20:44:30 +0100 Subject: How much is OpenSSH v2.3.0p1 sftp-server working? (fwd) Message-ID: <20010131204430.C19039@folly> fyi -------------- next part -------------- An embedded message was scrubbed... From: Markus Friedl Subject: How much is OpenSSH v2.3.0p1 sftp-server working? Date: Wed, 31 Jan 2001 17:05:17 +0100 (MET) Size: 2436 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010131/4c9ed716/attachment.mht From djm at mindrot.org Thu Feb 1 07:23:01 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 1 Feb 2001 07:23:01 +1100 (EST) Subject: could not read dsa key. In-Reply-To: Message-ID: On Wed, 31 Jan 2001, Sunil K. Vallamkonda wrote: > > I am experiencing following problem. > I had sent an email earlier but did not > get any response on the problem. > > Problem: > Could not load host key: ssh_host_dsa_key: Bad file descriptor I have never seen this error - have you made modifications to openssh? -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From djm at mindrot.org Thu Feb 1 07:30:28 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 1 Feb 2001 07:30:28 +1100 (EST) Subject: PTY In-Reply-To: <3A780DFC.3010303@skalasoft.com> Message-ID: On Wed, 31 Jan 2001, Roumen Petrov wrote: > What is more portable: openpty () method or /dev/ptmx ? ptmx is more portable, but openpty is nicer as it does most of the work in a libc function. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From markus.friedl at informatik.uni-erlangen.de Thu Feb 1 07:30:48 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 31 Jan 2001 21:30:48 +0100 Subject: OpenSSH on PalmOS possible? In-Reply-To: <4AFF51C45DD05A4E9F2DE28C114AA758032F2E@KARUBIN.meridium.se>; from daniel.brandt@meridium.se on Wed, Jan 31, 2001 at 05:30:03PM +0100 References: <4AFF51C45DD05A4E9F2DE28C114AA758032F2E@KARUBIN.meridium.se> Message-ID: <20010131213048.A18864@folly> check out http://www.isaac.cs.berkeley.edu/pilot/ openssh is overkill for palmos. From djm at mindrot.org Thu Feb 1 07:36:53 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 1 Feb 2001 07:36:53 +1100 (EST) Subject: OpenSSH on PalmOS possible? In-Reply-To: <4AFF51C45DD05A4E9F2DE28C114AA758032F2E@KARUBIN.meridium.se> Message-ID: On Wed, 31 Jan 2001, Daniel Brandt wrote: > A thought has been bugging me for a month or so, but I don't know where to > look for the answer. Would it be possible to port the OpenSSH ssh client to > PalmOS and other handheld OS'es like Symbian (EPOC) or PocketPC? There is a free (software) SSH implementation for PalmOS available at http://www.ai/~iang/TGssh/ I think it is only protocol 1. Porting OpenSSH would be a moderately difficult task because it is pretty closely tied to POSIX and Berkeley sockets, which (IIRC) is quite far from the Palm API. > Is the processor on PDA's fast enough? Would many libraries have to be > ported aswell? I know that PalmOS and EPOC has an IP stack implemented.. Memory may be an issue, but cipher speed probably wouldn't. The slow serial speeds and the much slower speed of entering characers by graffiti will give the CPU plenty of time to catch up. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From djm at mindrot.org Thu Feb 1 07:38:39 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 1 Feb 2001 07:38:39 +1100 (EST) Subject: dsa_verify signature incorrect In-Reply-To: <200101311633.JAA01231@avatar.itc.nrcs.usda.gov> Message-ID: On Wed, 31 Jan 2001, Tom Rudnick wrote: > Yep. that was it. I rebuilt with openssl-0.9.6, relinked and > it connected. > > Now, it hangs after establishing the interactive session. When > I kill it I get: > > error: grantpt: Interrupted system call > error: session_pty_req: session 0 alloc failed > error: session_by_pid: unknown pid 27578 > > on the server side. Can you strace or truss the server at this point? > The odd thing is that ssh-1 sessions work just fine. Is the session > establishment and pty stuff the same for 1 and 2? Pretty close. -s -- | ``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 Thu Feb 1 08:31:55 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 31 Jan 2001 23:31:55 +0200 (EET) Subject: OpenSSH 2.4? Message-ID: Hi, Earlier, there were some talks about a pending 2.4.0 release. Apparently that didn't happen ;-). Are there any new plans for a new release any time soon? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From ddulek at fastenal.com Thu Feb 1 09:03:12 2001 From: ddulek at fastenal.com (David Dulek) Date: Wed, 31 Jan 2001 16:03:12 -0600 Subject: DG/UX R4.20MU05 port of 2.3.0p1 In-Reply-To: References: Message-ID: <01013116031207.17611@penelope> Slight problem on DG/UX though. The OS has a regexec and regcomp. From what I understand and from what I am seeing, the DG/UX version of regcomp always returns -1. This kind of makes it useless in compat.c. I am kind of braindead today so please be patient. How do I get OpenSSH to use the prce regexec and regcomp instead of the OS ones? On Wednesday 31 January 2001 14:17, mouring at etoh.eviladmin.org wrote: >On Wed, 31 Jan 2001, David Dulek wrote: >> DG/UX does not impliment the regcomp, regexec functions. They suggest >> using regex and regcmp. The only place that I see that regexec and >> regcomp are used is in compat.c. Can someone help me out with the >> difference between regex and regexec and the differences between regcmp >> and regex. This should also help any other OS that does not have regexec. > >regexec/regcomp is the POSIX form of regex/regcmp. > >Take from INSTALL from OpenSSH portable: >[..] >pcre (POSIX Regular Expression library): >ftp://ftp.cus.cam.ac.uk/pub/software/programs/pcre/ > >Most platforms do not required this. However older 4.3 BSD do not >have a posix regex library. >[..] > > >I added supported for pcre (GNU rx works with a tweak or two) after the >change to compat.c was done to allow NeXT to compile. > > >- Ben -- Dave Dulek System Administration Fastenal Company E-mail: ddulek at fastenal.com Phone: (507) 453-8149 Fax: (507) 453-8333 ========================================================= "...Microsoft follows standards. In much the same manner that fish follow migrating caribou." "Now I have this image in my mind of a fish embracing and extending a caribou." --- Paul Tomblin and Christian Bauernfeind in a.s.r From mouring at etoh.eviladmin.org Thu Feb 1 10:32:23 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 31 Jan 2001 17:32:23 -0600 (CST) Subject: OpenSSH 2.4? In-Reply-To: Message-ID: On Wed, 31 Jan 2001, Pekka Savola wrote: > Hi, > > Earlier, there were some talks about a pending 2.4.0 release. Apparently > that didn't happen ;-). Are there any new plans for a new release any > time soon? > Time table was pushed back.=) I'll defer to Markus as to when he think OpenBSD will release a 2.4.0. BTW.. I just commited a reorder patch. All the bsd-*, fake-*, next-*, and cygwin* files have been moved to openbsd-compat/. (Something I've been wanting to do for months .) So if anyone has problems let me know. Current list of problems I know of: * Cray & HP/UX -- sigaction vs signal * SCO w/ native compiler -- No sftp-server due to lack of 64bit * NeXTStep -- Report it's broken, no verification yet. (No compile warnings) * DG/UX -- regcomp/regexec issues(?) ?? More ?? - Ben From mouring at etoh.eviladmin.org Thu Feb 1 10:35:26 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 31 Jan 2001 17:35:26 -0600 (CST) Subject: DG/UX R4.20MU05 port of 2.3.0p1 In-Reply-To: <01013116031207.17611@penelope> Message-ID: On Wed, 31 Jan 2001, David Dulek wrote: > Slight problem on DG/UX though. The OS has a regexec and regcomp. From what > I understand and from what I am seeing, the DG/UX version of regcomp always > returns -1. This kind of makes it useless in compat.c. I am kind of > braindead today so please be patient. How do I get OpenSSH to use the prce > regexec and regcomp instead of the OS ones? > Hmm.. Very good question. There currently is no --with-pcre flag. And the choice was to prefer the native regcomp/regexec over pcre. So until such a thing is written there is no way to use the pcre libraries correctly. - Ben From rachit at ensim.com Thu Feb 1 09:44:47 2001 From: rachit at ensim.com (Rachit Siamwalla) Date: Wed, 31 Jan 2001 14:44:47 -0800 Subject: OpenSSH 2.4? References: Message-ID: <3A78955F.FA5AAA66@ensim.com> > Current list of problems I know of: > > * Cray & HP/UX -- sigaction vs signal > * SCO w/ native compiler -- No sftp-server due to lack of 64bit > * NeXTStep -- Report it's broken, no verification yet. (No compile > warnings) > * DG/UX -- regcomp/regexec issues(?) > > ?? More ?? Linux sleep 10000 & exit hang problem (i believe this is in some TODO or readme in the snapshots -- or has it been fixed already)? From tom at avatar.itc.nrcs.usda.gov Thu Feb 1 10:10:43 2001 From: tom at avatar.itc.nrcs.usda.gov (Tom Rudnick) Date: Wed, 31 Jan 2001 16:10:43 -0700 (MST) Subject: pty problems w/ Unixware In-Reply-To: from "Damien Miller" at Feb 01, 2001 07:38:39 AM Message-ID: <200101312310.QAA08423@avatar.itc.nrcs.usda.gov> > > On Wed, 31 Jan 2001, Tom Rudnick wrote: > > > Now, it hangs after establishing the interactive session. When > > I kill it I get: > > > > error: grantpt: Interrupted system call > > error: session_pty_req: session 0 alloc failed > > error: session_by_pid: unknown pid 27578 > > > > on the server side. > > Can you strace or truss the server at this point? > Here's debug output from sshd -d -d -d plus truss output from the same point. After the client hangs, I send a kill -INT to it at which point it closes the connection. Hope this is illuminating... I have the full truss output, but I think this is most relevant. Accepted password for user52 from 192.168.29.7 port 4109 ssh2 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 32768 max 16384 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 pty-req reply 0 debug1: Received SIGCHLD. error: grantpt: Interrupted system call error: session_pty_req: session 0 alloc failed debug2: callback done debug2: callback start debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 channel 0 request shell reply 0 [truss ends here] debug1: fd 12 setting O_NONBLOCK debug1: fd 12 IS O_NONBLOCK debug1: fd 14 setting O_NONBLOCK debug2: callback done debug1: tvp!=NULL kid 1 mili 100 debug1: session_by_pid: pid 3887 error: session_by_pid: unknown pid 3887 debug1: dump: used 1 session 0 80ea9a0 channel 0 pid 3889 debug1: dump: used 0 session 1 80eaa2c channel 0 pid 0 debug1: dump: used 0 session 2 80eaab8 channel 0 pid 0 debug1: dump: used 0 session 3 80eab44 channel 0 pid 0 debug1: dump: used 0 session 4 80eabd0 channel 0 pid 0 debug1: dump: used 0 session 5 80eac5c channel 0 pid 0 debug1: dump: used 0 session 6 80eace8 channel 0 pid 0 debug1: dump: used 0 session 7 80ead74 channel 0 pid 0 debug1: dump: used 0 session 8 80eae00 channel 0 pid 0 debug1: dump: used 0 session 9 80eae8c channel 0 pid 0 debug1: session_close_by_pid: no session for pid 0 debug2: channel 0: read 13 from efd 14 debug2: channel 0: read 42 from efd 14 debug2: channel 0: read 92 from efd 14 debug2: channel 0: read 36 from efd 14 Connection closed by remote host. debug1: Calling cleanup 0x805b394(0x0) debug1: Calling cleanup 0x806185c(0x0) debug1: Calling cleanup 0x806699c(0x0) debug1: writing PRNG seed to file //.ssh/prng_seed --- output from truss starting at the same point. It appears that lvlproc() (whatever that is) is failing and resulting in no pty being allocated. 3794: write(2, " A c c e p t e d p a s".., 61) = 61 3794: write(6, "FF j 6 XDD839507 & cC1D0".., 36) = 36 3794: alarm(0) = 0 3794: write(2, " d e b u g 1 : E n t e".., 47) = 47 3794: signal(SIGCLD, 0x0805323C) = SIG_DFL 3794: signal(SIGPIPE, SIG_IGN) = SIG_DFL 3794: write(2, " d e b u g 1 : s e r v".., 32) = 32 3794: poll(0x08045530, 1, -1) = 1 3794: read(6, "CB !85AC T vC4D7FDD3 _1A".., 16384) = 60 3794: write(2, " d e b u g 1 : s e r v".., 76) = 76 3794: write(2, "\n", 1) = 1 3794: write(2, " d e b u g 1 : o p e n".., 21) = 21 3794: brk(0x08105060) = 0 3794: write(2, " d e b u g 1 : c h a n".., 40) = 40 3794: write(2, " d e b u g 1 : s e s s".., 26) = 26 3794: write(2, " d e b u g 1 : s e s s".., 31) = 31 3794: write(2, " d e b u g 1 : s e s s".., 32) = 32 3794: write(2, " d e b u g 1 : s e s s".., 53) = 53 3794: write(2, " d e b u g 1 : c o n f".., 24) = 24 3794: poll(0x08045530, 1, -1) = 1 3794: write(6, " A88F182 b kE5BB AA U".., 52) = 52 3794: poll(0x08045530, 1, -1) = 1 3794: read(6, " u7FFBE4E4 b V {94D4FD94".., 16384) = 120 3794: write(2, " d e b u g 2 : c a l l".., 23) = 23 3794: write(2, " d e b u g 1 : s e s s".., 48) = 48 3794: write(2, " d e b u g 1 : s e s s".., 78) = 78 3794: write(2, "\n", 1) = 1 3794: open("/dev/ptmx", 04002, 01001072224) = 9 3794: fork1() = 3887 3887: *** Expected fork SYSEXIT 3887: fork1() (returning as child ...) = 3794 3887: execve("/usr/lib/pt_chmod", 0x08047440, 0x08047CB0) argc = 2 3887: open("/usr/lib/ns.so.1", O_RDONLY, 01) Err#2 ENOENT 3887: brk(0x08302D84) = 0 3887: open("/etc/group", O_RDONLY, 0666) = 10 3887: ioctl(10, TCGETA, 0x080479BE) Err#25 ENOTTY 3887: fxstat(2, 10, 0x080479EC) = 0 3887: brk(0x08305D84) = 0 3887: read(10, " r o o t : : 0 : r o o t".., 8192) = 324 3887: close(10) = 0 3887: ioctl(9, I_STR, 0x08047A14) = 0 3887: fxstat(2, 9, 0x08047AAC) = 0 3887: access("/dev/pts/0", 0) = 0 3887: xstat(2, "/dev/pts/0", 0x08047A24) = 0 3887: xstat(2, "/dev/ptmx", 0x08047BD8) = 0 3887: fxstat(2, 9, 0x08047B50) = 0 3887: lvlproc(1, 0x08047C8C) Err#65 ENOPKG 3887: getuid() = 0 [ 0 ] 3887: chown("/dev/pts/0", 0, 7) = 0 3887: chmod("/dev/pts/0", 0620) = 0 3887: _exit(0) 3794: Received signal #18, SIGCLD, in waitsys() [caught] 3794: siginfo: SIGCLD CLD_EXITED pid=3887 uid=0 status=0x0000 3794: waitsys(P_PID, 3887, 0x080473B8, WEXITED|WTRAPPED) Err#4 EINTR 3794: write(2, " d e b u g 1 : R e c e".., 26) = 26 3794: write(2, " e r r o r : g r a n t".., 40) = 40 3794: write(2, " e r r o r : s e s s i".., 47) = 47 3794: write(2, " d e b u g 2 : c a l l".., 22) = 22 3794: write(2, " d e b u g 2 : c a l l".., 23) = 23 3794: write(2, " d e b u g 1 : s e s s".., 48) = 48 3794: write(2, " d e b u g 1 : s e s s".., 76) = 76 3794: write(2, "\n", 1) = 1 ... -- ----------------/---------------------------------------------- Tom Rudnick | USDA Natural Resources Conservation Service Fort Collins,CO | tom at avatar.itc.nrcs.usda.gov (970) 295-5427 ** The 3rd Millennium starts Jan 1, 2001. see: ** ** http://aa.usno.navy.mil/AA/faq/docs/millennium.html ** -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From djm at mindrot.org Thu Feb 1 11:02:21 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 1 Feb 2001 11:02:21 +1100 (EST) Subject: pty problems w/ Unixware In-Reply-To: <200101312310.QAA08423@avatar.itc.nrcs.usda.gov> Message-ID: On Wed, 31 Jan 2001, Tom Rudnick wrote: > > Can you strace or truss the server at this point? > > > > Here's debug output from sshd -d -d -d plus truss output from the > same point. After the client hangs, I send a kill -INT to it at > which point it closes the connection. > > Hope this is illuminating... It is: > 3887: _exit(0) > 3794: Received signal #18, SIGCLD, in waitsys() [caught] > 3794: siginfo: SIGCLD CLD_EXITED pid=3887 uid=0 status=0x0000 > 3794: waitsys(P_PID, 3887, 0x080473B8, WEXITED|WTRAPPED) Err#4 EINTR This looks like another candidate for Kevin's mysignal() stuff. Kevin? -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 sunil at redback.com Thu Feb 1 11:46:28 2001 From: sunil at redback.com (Sunil K. Vallamkonda) Date: Wed, 31 Jan 2001 16:46:28 -0800 (PST) Subject: could not read dsa key. In-Reply-To: Message-ID: I have made some modifications, more specific to my requirements, but nothing related to keys - generation or retrieval etc. Anyone else seen this problem ? Here is debug output: sshd version OpenSSH_2.3.1p1 load_private_key_autodetect: type 0 RSA1 PEM_read_PrivateKey failed read SSH2 private key done: name success 0 Could not load host key: /usr/siara/config/ssh_host_dsa_key: Bad file descriptor Disabling protocol version 2. Could not load host key Thank you. On Thu, 1 Feb 2001, Damien Miller wrote: > On Wed, 31 Jan 2001, Sunil K. Vallamkonda wrote: > > > > > I am experiencing following problem. > > I had sent an email earlier but did not > > get any response on the problem. > > > > Problem: > > Could not load host key: ssh_host_dsa_key: Bad file descriptor > > I have never seen this error - have you made modifications to openssh? > > -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 ddulek at fastenal.com Thu Feb 1 11:54:22 2001 From: ddulek at fastenal.com (David Dulek) Date: Wed, 31 Jan 2001 18:54:22 -0600 Subject: DG/UX R4.20MU05 port of 2.3.0p1 In-Reply-To: References: Message-ID: <01013118542200.22763@penelope> A small tweak to the pcre libraries and a small tweak of the config.h and the Makefile and I believe I have a working version of OpenSSH 2.3.0p1 for DG/UX. Now that I have it compiled I need to take it over to the test box to actually run the daemon. The client seems to work great though. On Wednesday 31 January 2001 17:35, you wrote: >On Wed, 31 Jan 2001, David Dulek wrote: >> Slight problem on DG/UX though. The OS has a regexec and regcomp. From >> what I understand and from what I am seeing, the DG/UX version of regcomp >> always returns -1. This kind of makes it useless in compat.c. I am kind >> of braindead today so please be patient. How do I get OpenSSH to use the >> prce regexec and regcomp instead of the OS ones? > >Hmm.. Very good question. There currently is no --with-pcre flag. And >the choice was to prefer the native regcomp/regexec over pcre. > >So until such a thing is written there is no way to use the pcre libraries >correctly. > >- Ben -- Dave Dulek From ddulek at fastenal.com Thu Feb 1 11:58:16 2001 From: ddulek at fastenal.com (David Dulek) Date: Wed, 31 Jan 2001 18:58:16 -0600 Subject: ssh-keygen -l not recognizing dsa key file Message-ID: <01013118581601.22763@penelope> machine:user:~/.ssh> ssh-keygen -l -f identity.pub 1024 91:b1:d2:81:23:85:ee:82:46:af:01:37:89:53:79:46 user at machine machine:user:~/.ssh> ssh-keygen -l -f id_dsa.pub id_dsa.pub is not a valid key file. Is there any way to get the same info from the dsa key? -- Dave Dulek System Administration Fastenal Company E-mail: ddulek at fastenal.com Phone: (507) 453-8149 Fax: (507) 453-8333 ========================================================= "...Microsoft follows standards. In much the same manner that fish follow migrating caribou." "Now I have this image in my mind of a fish embracing and extending a caribou." --- Paul Tomblin and Christian Bauernfeind in a.s.r From roumen.petrov at skalasoft.com Thu Feb 1 22:50:44 2001 From: roumen.petrov at skalasoft.com (Roumen Petrov) Date: Thu, 01 Feb 2001 13:50:44 +0200 Subject: linux and _GNU_SOURCE define Message-ID: <3A794D94.2080409@skalasoft.com> I find that adding -D_GNU_SOURCE is useful for linux. This define enable more features from header files. First) i found that define enable declaration/definition of following methods - grantpt(...) - unlockpt(...) - ptsname(...) for device "/dev/ptmx" ( support for ptys, preferred is method openpty (...) ) Second) _GNU_SOURCE enable use of utmpx and wtmpx ( support for login recording, preferred is USE_LOGIN and syslogin_write_entry ) Three) ? at this time i don't know. From francesco.munaretto at altavista.net Thu Feb 1 22:50:57 2001 From: francesco.munaretto at altavista.net (Francesco Munaretto) Date: Thu, 1 Feb 2001 12:50:57 +0100 Subject: warnings on aix325 Message-ID: <00bf01c08c45$533750a0$5a592ac1@pcmunaretto> Hi, I'm trying to compile openssh2.3.0p1 on aix3.2.5. Can I ignore this list of warning messages? bsd-bindresvport.c: In function `bindresvport_af': bsd-bindresvport.c:94: warning: implicit declaration of function `bind' bsd-rresvport.c: In function `rresvport_af': bsd-rresvport.c:64: warning: implicit declaration of function `bzero' bsd-rresvport.c:82: warning: implicit declaration of function `socket' bsd-rresvport.c:88: warning: implicit declaration of function `bind' bsd-setenv.c: In function `setenv': bsd-setenv.c:125: warning: implicit declaration of function `bcopy' bsd-setproctitle.c:62: warning: `__progname' defined but not used authfd.c: In function `ssh_get_authentication_socket': authfd.c:84: warning: implicit declaration of function `socket' authfd.c:93: warning: implicit declaration of function `connect' authfile.c: In function `load_private_key': authfile.c:494: warning: unsigned int format, long unsigned int arg (arg 2) canohost.c: In function `get_remote_hostname': canohost.c:39: warning: implicit declaration of function `getpeername' canohost.c:150: warning: implicit declaration of function `getsockopt' canohost.c: In function `get_sock_port': canohost.c:247: warning: implicit declaration of function `getsockname' channels.c: In function `channel_free': channels.c:318: warning: implicit declaration of function `shutdown' channels.c: In function `channel_post_x11_listener': channels.c:543: warning: implicit declaration of function `accept' channels.c: In function `channel_request_local_forwarding': channels.c:1484: warning: implicit declaration of function `socket' channels.c:1494: warning: implicit declaration of function `setsockopt' channels.c:1501: warning: implicit declaration of function `bind' channels.c:1512: warning: implicit declaration of function `listen' channels.c: In function `channel_connect_to': channels.c:1642: warning: implicit declaration of function `connect' channels.c: In function `x11_create_display_inet': channels.c:1819: warning: implicit declaration of function `gethostname' cipher.c: In function `cipher_by_name': cipher.c:450: warning: implicit declaration of function `strcasecmp' log.c: In function `log_facility_number': log.c:224: warning: implicit declaration of function `strcasecmp' nchan.c: In function `chan_shutdown_write': nchan.c:464: warning: implicit declaration of function `shutdown' packet.c: In function `packet_connection_is_on_socket': packet.c:196: warning: implicit declaration of function `getpeername' packet.c: In function `packet_connection_is_ipv4': packet.c:218: warning: implicit declaration of function `getsockname' packet.c: In function `packet_close': packet.c:265: warning: implicit declaration of function `shutdown' packet.c: In function `packet_read': packet.c:691: warning: implicit declaration of function `bzero' packet.c: In function `packet_set_interactive': packet.c:1240: warning: implicit declaration of function `setsockopt' entropy.c: In function `stir_gettimeofday': entropy.c:302: warning: implicit declaration of function `gettimeofday' entropy.c: In function `stir_rusage': entropy.c:331: warning: implicit declaration of function `getrusage' entropy.c: In function `hash_output_from_command': entropy.c:426: warning: implicit declaration of function `bzero' entropy.c: In function `prng_check_seedfile': entropy.c:532: warning: int format, long int arg (arg 3) entropy.c: In function `prng_write_seedfile': entropy.c:557: warning: int format, long int arg (arg 2) entropy.c: In function `prng_read_seedfile': entropy.c:596: warning: int format, long int arg (arg 2) uidswap.c: In function `temporarily_use_uid': uidswap.c:54: warning: implicit declaration of function `seteuid' ssh.c: In function `main': ssh.c:252: warning: implicit declaration of function `setrlimit' ssh.c: In function `ssh_session': ssh.c:802: warning: implicit declaration of function `ioctl' sshconnect.c: In function `ssh_create_socket': sshconnect.c:169: warning: implicit declaration of function `socket' sshconnect.c: In function `ssh_connect': sshconnect.c:265: warning: implicit declaration of function `connect' sshconnect.c:279: warning: implicit declaration of function `shutdown' sshconnect.c:305: warning: implicit declaration of function `setsockopt' sshconnect.c: In function `ssh_login': sshconnect.c:683: warning: unsigned int format, uid_t arg (arg 2) readconf.c: In function `parse_token': readconf.c:220: warning: implicit declaration of function `strcasecmp' clientloop.c: In function `get_current_time': clientloop.c:232: warning: implicit declaration of function `gettimeofday' clientloop.c: In function `client_check_window_change': clientloop.c:337: warning: implicit declaration of function `ioctl' clientloop.c: In function `client_wait_until_can_do_something': clientloop.c:368: warning: implicit declaration of function `bzero' sshd.c: In function `main': sshd.c:702: warning: implicit declaration of function `ioctl' sshd.c:758: warning: implicit declaration of function `socket' sshd.c:775: warning: implicit declaration of function `setsockopt' sshd.c:785: warning: implicit declaration of function `bind' sshd.c:797: warning: implicit declaration of function `listen' sshd.c:897: warning: implicit declaration of function `accept' auth-rhosts.c: In function `check_rhosts_file': auth-rhosts.c:110: warning: implicit declaration of function `innetgr' auth-rhosts.c:113: warning: implicit declaration of function `strcasecmp' pty.c: In function `pty_make_controlling_tty': pty.c:222: warning: implicit declaration of function `ioctl' pty.c: In function `pty_setowner': pty.c:312: warning: int format, long int arg (arg 3) pty.c:312: warning: int format, long int arg (arg 4) pty.c:315: warning: unsigned int format, mode_t arg (arg 3) log-server.c: In function `do_log': log-server.c:174: warning: implicit declaration of function `openlog' log-server.c:175: warning: implicit declaration of function `syslog' log-server.c:176: warning: implicit declaration of function `closelog' loginrec.c: In function `login_set_current_time': loginrec.c:376: warning: implicit declaration of function `gettimeofday' loginrec.c:721: warning: implicit declaration of function `setutent' loginrec.c:722: warning: implicit declaration of function `pututline' servconf.c: In function `parse_token': servconf.c:272: warning: implicit declaration of function `strcasecmp' serverloop.c: In function `wait_until_can_do_something': serverloop.c:197: warning: implicit declaration of function `bzero' serverloop.c: In function `process_output': serverloop.c:350: warning: implicit declaration of function `shutdown' In file included from session.c:60: /usr/include/usersec.h:88: warning: `struct userpw' declared inside parameter list /usr/include/usersec.h:88: warning: its scope is only this definition or declaration, /usr/include/usersec.h:88: warning: which is probably not what you want. session.c: In function `do_exec_no_pty': session.c:474: warning: implicit declaration of function `socketpair' session.c:493: warning: passing arg 1 of `log_init' discards `const' from pointer target type session.c: In function `do_exec_pty': session.c:606: warning: passing arg 1 of `log_init' discards `const' from pointer target type session.c: In function `do_login': session.c:707: warning: implicit declaration of function `getpeername' session.c: In function `set_limit': session.c:925: warning: implicit declaration of function `getrlimit' session.c:967: warning: implicit declaration of function `setrlimit' session.c: In function `do_child': session.c:1084: warning: implicit declaration of function `initgroups' session.c:1277: warning: implicit declaration of function `endpwent' ssh-keygen.c: In function `main': ssh-keygen.c:616: warning: implicit declaration of function `gethostname' ssh-agent.c: In function `process_message': ssh-agent.c:464: warning: implicit declaration of function `shutdown' ssh-agent.c: In function `after_select': ssh-agent.c:585: warning: implicit declaration of function `accept' ssh-agent.c: In function `main': ssh-agent.c:753: warning: implicit declaration of function `socket' ssh-agent.c:761: warning: implicit declaration of function `bind' ssh-agent.c:765: warning: implicit declaration of function `listen' ssh-agent.c:822: warning: implicit declaration of function `bzero' scp.c: In function `sink': scp.c:808: warning: implicit declaration of function `utimes' scp.c: In function `alarmtimer': scp.c:1103: warning: implicit declaration of function `setitimer' scp.c: In function `foregroundproc': scp.c:1132: warning: implicit declaration of function `ioctl' scp.c: In function `progressmeter': scp.c:1150: warning: implicit declaration of function `gettimeofday' sftp-server.c: In function `process_setstat': sftp-server.c:706: warning: implicit declaration of function `utimes' sftp-server.c: In function `main': sftp-server.c:1033: warning: implicit declaration of function `bzero' Thanks for any help. francesco From Jarno.Huuskonen at uku.fi Thu Feb 1 23:30:21 2001 From: Jarno.Huuskonen at uku.fi (Jarno Huuskonen) Date: Thu, 1 Feb 2001 14:30:21 +0200 Subject: ssh-keygen -l not recognizing dsa key file In-Reply-To: <01013118581601.22763@penelope>; from ddulek@fastenal.com on Wed, Jan 31, 2001 at 06:58:16PM -0600 References: <01013118581601.22763@penelope> Message-ID: <20010201143021.B181618@messi.uku.fi> On Wed, Jan 31, David Dulek wrote: > machine:user:~/.ssh> ssh-keygen -l -f identity.pub > 1024 91:b1:d2:81:23:85:ee:82:46:af:01:37:89:53:79:46 user at machine > machine:user:~/.ssh> ssh-keygen -l -f id_dsa.pub > id_dsa.pub is not a valid key file. > > Is there any way to get the same info from the dsa key? Have you tested the latest snapshots ? I think that the snapshots ssh-keygen -l works for dsa keys as well ... -Jarno -- Jarno Huuskonen - System Administrator | Jarno.Huuskonen at uku.fi University of Kuopio - Computer Center | Work: +358 17 162822 PO BOX 1627, 70211 Kuopio, Finland | Mobile: +358 40 5388169 From roumen.petrov at skalasoft.com Thu Feb 1 23:34:31 2001 From: roumen.petrov at skalasoft.com (Roumen Petrov) Date: Thu, 01 Feb 2001 14:34:31 +0200 Subject: linux and _GNU_SOURCE define References: <3A794D94.2080409@skalasoft.com> Message-ID: <3A7957D7.3070301@skalasoft.com> P.P. In this case linux has getline method ( stdio.h ) ! Place rename getline method in ssh-keyscan.c to Linebuf_getline ! From roumen.petrov at skalasoft.com Fri Feb 2 00:11:59 2001 From: roumen.petrov at skalasoft.com (Roumen Petrov) Date: Thu, 01 Feb 2001 15:11:59 +0200 Subject: OpenSSH 2.4? Message-ID: <3A79609F.6090209@skalasoft.com> Ben this is patch for makefile ( CVS 01 feb 2001 ). This patch stop rebuild of executables if nothing is changed and make is run again. -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.in.patch.gz Type: application/gzip Size: 617 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010201/584fa92b/attachment.bin From mouring at etoh.eviladmin.org Fri Feb 2 02:02:11 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 1 Feb 2001 09:02:11 -0600 (CST) Subject: OpenSSH 2.4? In-Reply-To: <3A79609F.6090209@skalasoft.com> Message-ID: On Thu, 1 Feb 2001, Roumen Petrov wrote: > Ben this is patch for makefile ( CVS 01 feb 2001 ). > This patch stop rebuild of executables if nothing is changed and make > is run again. > Thanks, Applied. - Ben From ddulek at fastenal.com Fri Feb 2 01:24:24 2001 From: ddulek at fastenal.com (David Dulek) Date: Thu, 1 Feb 2001 08:24:24 -0600 Subject: ssh-keygen -l not recognizing dsa key file In-Reply-To: <20010201143021.B181618@messi.uku.fi> References: <01013118581601.22763@penelope> <20010201143021.B181618@messi.uku.fi> Message-ID: <01020108242400.04367@penelope> No. I just wanted to make sure I was not being a bonehead. Also since this is for work, I need to keep it to the official releases. On Thursday 01 February 2001 06:30, Jarno Huuskonen wrote: >On Wed, Jan 31, David Dulek wrote: >> machine:user:~/.ssh> ssh-keygen -l -f identity.pub >> 1024 91:b1:d2:81:23:85:ee:82:46:af:01:37:89:53:79:46 user at machine >> machine:user:~/.ssh> ssh-keygen -l -f id_dsa.pub >> id_dsa.pub is not a valid key file. >> >> Is there any way to get the same info from the dsa key? > >Have you tested the latest snapshots ? I think that the snapshots >ssh-keygen -l works for dsa keys as well ... > >-Jarno -- Dave Dulek System Administration Fastenal Company E-mail: ddulek at fastenal.com Phone: (507) 453-8149 Fax: (507) 453-8333 ========================================================= "...Microsoft follows standards. In much the same manner that fish follow migrating caribou." "Now I have this image in my mind of a fish embracing and extending a caribou." --- Paul Tomblin and Christian Bauernfeind in a.s.r From jones at hpc.utexas.edu Fri Feb 2 01:36:56 2001 From: jones at hpc.utexas.edu (William L. Jones) Date: Thu, 01 Feb 2001 08:36:56 -0600 Subject: Access to daily snap shots Message-ID: <4.2.0.58.20010201083354.01c534e0@127.0.0.1> I get a prompt for a user number and password when I try to access the daily snap shots. Is this intended? If so how do I get a user number and password to access the daily snap shots. Bill Jones From jones at hpc.utexas.edu Fri Feb 2 08:33:26 2001 From: jones at hpc.utexas.edu (William L. Jones) Date: Thu, 01 Feb 2001 15:33:26 -0600 Subject: patch to sereverloop.c Message-ID: <4.2.0.58.20010201151641.01c6ddd0@127.0.0.1> This is a repost of a patch that I submitted earlier. It is in unified diff format this time. If move the reinstallation of the SIGCHLD signal handler from isgchld_handler2 back in the server2 loop. AIX and IRIX both will keep calling the sigchld_handler2 open the return from sigchld_handler2 if the SIGCHLD signal is reinstalled in sigchld_handler2 since both os expact that all children will be reaped in the SIGCHLD signal handler. The causes a infinite loop were the sigchld_handler2 is called until openssh runs out of stack space a core dumps on logout when the ssh version 2 protocol is used. Bill Jones -------------- next part -------------- --- serverloop.c.orig Thu Feb 1 14:56:30 2001+++ serverloop.c Thu Feb 1 14:57:31 2001@@ -110,7 +110,6 @@ int save_errno = errno; debug("Received SIGCHLD."); child_terminated = 1;- signal(SIGCHLD, sigchld_handler2); errno = save_errno; } @@ -664,6 +663,7 @@ while ((pid = waitpid(-1, &status, WNOHANG)) > 0) session_close_by_pid(pid, status); child_terminated = 0;+ signal(SIGCHLD, sigchld_handler2); } channel_after_select(readset, writeset); process_input(readset); From stevesk at sweden.hp.com Fri Feb 2 08:50:42 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Thu, 1 Feb 2001 22:50:42 +0100 (MET) Subject: pty problems w/ Unixware In-Reply-To: Message-ID: On Thu, 1 Feb 2001, Damien Miller wrote: : This looks like another candidate for Kevin's mysignal() stuff. Kevin? the mysignal() idea is from markus. i implemented it with a change that checks whether we're re-installing the prior handler, and if so noops. i've been using this patch for the protocol 2 SIGCHLD problem on hp-ux. a s/signal/mysignal/ would be a next step. Index: misc.c =================================================================== RCS file: /var/cvs/openssh/misc.c,v retrieving revision 1.1 diff -u -r1.1 misc.c --- misc.c 2001/01/22 05:34:42 1.1 +++ misc.c 2001/01/23 16:55:27 @@ -27,6 +27,7 @@ #include "includes.h" RCSID("$OpenBSD: util.c,v 1.6 2000/10/27 07:32:19 markus Exp $"); +#include "misc.h" #include "ssh.h" #include "log.h" @@ -94,4 +95,26 @@ *s += strspn(*s + 1, WHITESPACE) + 1; return (old); +} + +mysig_t +mysignal(int sig, mysig_t act) +{ +#ifdef HAVE_SIGACTION + struct sigaction sa, osa; + + if (sigaction(sig, 0, &osa) == -1) + return (mysig_t) -1; + if (osa.sa_handler != act) { + memset(&sa, 0, sizeof sa); + sigemptyset(&sa.sa_mask); + sa.sa_flags = 0; + sa.sa_handler = act; + if (sigaction(sig, &sa, 0) == -1) + return (mysig_t) -1; + } + return (osa.sa_handler); +#else + return (signal(sig, act)); +#endif } Index: misc.h =================================================================== RCS file: /var/cvs/openssh/misc.h,v retrieving revision 1.1 diff -u -r1.1 misc.h --- misc.h 2001/01/22 05:34:42 1.1 +++ misc.h 2001/01/23 16:55:27 @@ -17,3 +17,7 @@ /* set filedescriptor to non-blocking */ void set_nonblock(int fd); + +/* wrapper for signal interface */ +typedef void (*mysig_t)(int); +mysig_t mysignal(int sig, mysig_t act); Index: serverloop.c =================================================================== RCS file: /var/cvs/openssh/serverloop.c,v retrieving revision 1.37 diff -u -r1.37 serverloop.c --- serverloop.c 2001/01/22 05:34:43 1.37 +++ serverloop.c 2001/01/23 16:55:33 @@ -111,7 +111,7 @@ int save_errno = errno; debug("Received SIGCHLD."); child_terminated = 1; - signal(SIGCHLD, sigchld_handler2); + mysignal(SIGCHLD, sigchld_handler2); errno = save_errno; } @@ -645,7 +645,7 @@ debug("Entering interactive session for SSH2."); - signal(SIGCHLD, sigchld_handler2); + mysignal(SIGCHLD, sigchld_handler2); signal(SIGPIPE, SIG_IGN); child_terminated = 0; connection_in = packet_get_connection_in(); From pekkas at netcore.fi Fri Feb 2 08:53:52 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 1 Feb 2001 23:53:52 +0200 (EET) Subject: OpenSSH 2.4? In-Reply-To: Message-ID: On Wed, 31 Jan 2001 mouring at etoh.eviladmin.org wrote: > On Wed, 31 Jan 2001, Pekka Savola wrote: > > > Hi, > > > > Earlier, there were some talks about a pending 2.4.0 release. Apparently > > that didn't happen ;-). Are there any new plans for a new release any > > time soon? > > > Time table was pushed back.=) I'll defer to Markus as to when he > think OpenBSD will release a 2.4.0. > > BTW.. I just commited a reorder patch. All the bsd-*, fake-*, next-*, > and cygwin* files have been moved to openbsd-compat/. (Something I've > been wanting to do for months .) So if anyone has problems let > me know. 'cvs update' I did nuked bsd-* fake-* next-* etc., but didn't (and won't) create openbsd-compat. Something wrong? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From mouring at etoh.eviladmin.org Fri Feb 2 09:51:51 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 1 Feb 2001 16:51:51 -0600 (CST) Subject: OpenSSH 2.4? In-Reply-To: Message-ID: On Thu, 1 Feb 2001, Pekka Savola wrote: > On Wed, 31 Jan 2001 mouring at etoh.eviladmin.org wrote: > > On Wed, 31 Jan 2001, Pekka Savola wrote: > > > > > Hi, > > > > > > Earlier, there were some talks about a pending 2.4.0 release. Apparently > > > that didn't happen ;-). Are there any new plans for a new release any > > > time soon? > > > > > Time table was pushed back.=) I'll defer to Markus as to when he > > think OpenBSD will release a 2.4.0. > > > > BTW.. I just commited a reorder patch. All the bsd-*, fake-*, next-*, > > and cygwin* files have been moved to openbsd-compat/. (Something I've > > been wanting to do for months .) So if anyone has problems let > > me know. > > 'cvs update' I did nuked bsd-* fake-* next-* etc., but didn't (and won't) > create openbsd-compat. Something wrong? > > cvs update -dP it should resolve all your issues. From djm at mindrot.org Fri Feb 2 09:39:54 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 2 Feb 2001 09:39:54 +1100 (EST) Subject: pty problems w/ Unixware In-Reply-To: Message-ID: On Thu, 1 Feb 2001, Kevin Steves wrote: > On Thu, 1 Feb 2001, Damien Miller wrote: > : This looks like another candidate for Kevin's mysignal() stuff. Kevin? > > the mysignal() idea is from markus. i implemented it with a change that > checks whether we're re-installing the prior handler, and if so noops. > > i've been using this patch for the protocol 2 SIGCHLD problem on hp-ux. > a s/signal/mysignal/ would be a next step. Looks good to me. Doing this: - sa.sa_flags = 0; + sa.sa_flags = SA_RESTART; Might also help the Unixware problem. -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 vinschen at redhat.com Fri Feb 2 09:49:50 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 1 Feb 2001 23:49:50 +0100 Subject: OpenSSH 2.4? In-Reply-To: ; from mouring@etoh.eviladmin.org on Wed, Jan 31, 2001 at 05:32:23PM -0600 References: Message-ID: <20010201234950.F19867@cygbert.vinschen.de> On Wed, Jan 31, 2001 at 05:32:23PM -0600, mouring at etoh.eviladmin.org wrote: > Current list of problems I know of: > > * Cray & HP/UX -- sigaction vs signal > * SCO w/ native compiler -- No sftp-server due to lack of 64bit > * NeXTStep -- Report it's broken, no verification yet. (No compile > warnings) > * DG/UX -- regcomp/regexec issues(?) > > ?? More ?? Yep. The openbsd-compat subdirectory doesn't build if the builddir is not the sourcedir: /src/openssh/bin[41]$ make (cd `dirname openbsd-compat/libopenbsd-compat.a`; make) make[1]: Entering directory `/src/openssh/bin/openbsd-compat' make[1]: *** No rule to make target `bsd-arc4random.o', needed by `libopenbsd-compat.a'. Stop. make[1]: Leaving directory `/src/openssh/bin/openbsd-compat' make: *** [openbsd-compat/libopenbsd-compat.a] Error 2 Patch attached. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com -------------- next part -------------- Index: Makefile.in =================================================================== RCS file: /cvs/openssh_cvs/Makefile.in,v retrieving revision 1.139 diff -u -p -r1.139 Makefile.in --- Makefile.in 2001/02/01 14:06:11 1.139 +++ Makefile.in 2001/02/01 22:48:11 @@ -19,7 +19,7 @@ CC=@CC@ LD=@LD@ PATHS=-DETCDIR=\"$(sysconfdir)\" -D_PATH_SSH_PROGRAM=\"$(SSH_PROGRAM)\" -D_PATH_SSH_ASKPASS_DEFAULT=\"$(ASKPASS_PROGRAM)\" CFLAGS=@CFLAGS@ -CPPFLAGS=@CPPFLAGS@ -I. -Iopenbsd-compat/ -I$(srcdir) $(PATHS) @DEFS@ +CPPFLAGS=@CPPFLAGS@ -I. -I$(srcdir)/openbsd-compat -I$(srcdir) $(PATHS) @DEFS@ LIBS=@LIBS@ AR=@AR@ RANLIB=@RANLIB@ Index: openbsd-compat/Makefile.in =================================================================== RCS file: /cvs/openssh_cvs/openbsd-compat/Makefile.in,v retrieving revision 1.1 diff -u -p -r1.1 Makefile.in --- openbsd-compat/Makefile.in 2001/01/31 21:52:03 1.1 +++ openbsd-compat/Makefile.in 2001/02/01 22:48:11 @@ -3,10 +3,11 @@ piddir=@piddir@ srcdir=@srcdir@ top_srcdir=@top_srcdir@ +VPATH=@srcdir@ CC=@CC@ LD=@LD@ CFLAGS=@CFLAGS@ -CPPFLAGS=@CPPFLAGS@ -I. -I.. -I$(srcdir) @DEFS@ +CPPFLAGS=@CPPFLAGS@ -I. -I.. -I$(srcdir) -I$(srcdir)/.. @DEFS@ LIBS=@LIBS@ AR=@AR@ RANLIB=@RANLIB@ From vinschen at redhat.com Fri Feb 2 10:07:18 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 2 Feb 2001 00:07:18 +0100 Subject: OpenSSH 2.4? In-Reply-To: <20010201234950.F19867@cygbert.vinschen.de>; from vinschen@redhat.com on Thu, Feb 01, 2001 at 11:49:50PM +0100 References: <20010201234950.F19867@cygbert.vinschen.de> Message-ID: <20010202000718.H19867@cygbert.vinschen.de> On Thu, Feb 01, 2001 at 11:49:50PM +0100, Corinna Vinschen wrote: > On Wed, Jan 31, 2001 at 05:32:23PM -0600, mouring at etoh.eviladmin.org wrote: > > Current list of problems I know of: > > > > * Cray & HP/UX -- sigaction vs signal > > * SCO w/ native compiler -- No sftp-server due to lack of 64bit > > * NeXTStep -- Report it's broken, no verification yet. (No compile > > warnings) > > * DG/UX -- regcomp/regexec issues(?) > > > > ?? More ?? > > Yep. The openbsd-compat subdirectory doesn't build if the builddir > is not the sourcedir: > [...] ... and ssh-keyscan doesn't build: /src/openssh/bin[65]$ make gcc -g -O2 -Wall -I. -I../src/openbsd-compat -I../src -DETCDIR=\"/etc\" -D_PATH_SSH_PROGRAM=\"/usr/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/sbin/ssh-askpass\" -DHAVE_CONFIG_H -c ../src/ssh-keyscan.c ../src/ssh-keyscan.c:16: bsd-queue.h: No such file or directory make: *** [ssh-keyscan.o] Error 1 Where is bsd-queue.h??? I have the latest from CVS. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From vinschen at redhat.com Fri Feb 2 10:18:17 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 2 Feb 2001 00:18:17 +0100 Subject: OpenSSH 2.4? In-Reply-To: ; from mouring@etoh.eviladmin.org on Wed, Jan 31, 2001 at 05:32:23PM -0600 References: Message-ID: <20010202001817.I19867@cygbert.vinschen.de> On Wed, Jan 31, 2001 at 05:32:23PM -0600, mouring at etoh.eviladmin.org wrote: > Current list of problems I know of: > > * Cray & HP/UX -- sigaction vs signal > * SCO w/ native compiler -- No sftp-server due to lack of 64bit > * NeXTStep -- Report it's broken, no verification yet. (No compile > warnings) > * DG/UX -- regcomp/regexec issues(?) > > ?? More ?? Just build the latest ssh from CVS, Cygwin version: Connecting using V2 protocol to a Linux box running OpenSSH-2.3.0p2 which worked before now fails: /src/openssh/bin[81]$ ./ssh -v cygbert SSH Version OpenSSH_2.3.1p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090581f). debug: Reading configuration data /home/corinna/.ssh/config debug: Applying options for cygbert [...] debug: Remote protocol version 1.99, remote software version OpenSSH_2.3.0p2 debug: match: OpenSSH_2.3.0p2 pat ^OpenSSH_2\.3\.0 Enabling compatibility mode for protocol 2.0 debug: Local version string SSH-2.0-OpenSSH_2.3.1p1 [...] 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: 1062/2049 debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. debug: Got SSH2_MSG_KEXDH_REPLY. debug: Host 'cygbert' is known and matches the RSA host key. debug: Found key in /home/corinna/.ssh/known_hosts2:8 debug: bits set: 1049/2049 ssh_rsa_verify: n too small: 6 bits key_verify failed for server_host_key debug: Calling cleanup 0x418ba4(0x0) That's it. What's going on here? Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From djm at mindrot.org Fri Feb 2 10:20:57 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 2 Feb 2001 10:20:57 +1100 (EST) Subject: OpenSSH 2.4? In-Reply-To: <20010202001817.I19867@cygbert.vinschen.de> Message-ID: On Fri, 2 Feb 2001, Corinna Vinschen wrote: > ssh_rsa_verify: n too small: 6 bits > key_verify failed for server_host_key > debug: Calling cleanup 0x418ba4(0x0) > > That's it. What's going on here? This was announced a few weeks ago - you need to recreate your SSH2 RSA keys as their encoding has changed to match the internet-draft. -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 vinschen at redhat.com Fri Feb 2 10:26:15 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 2 Feb 2001 00:26:15 +0100 Subject: OpenSSH 2.4? In-Reply-To: ; from djm@mindrot.org on Fri, Feb 02, 2001 at 10:20:57AM +1100 References: <20010202001817.I19867@cygbert.vinschen.de> Message-ID: <20010202002615.J19867@cygbert.vinschen.de> On Fri, Feb 02, 2001 at 10:20:57AM +1100, Damien Miller wrote: > On Fri, 2 Feb 2001, Corinna Vinschen wrote: > > > ssh_rsa_verify: n too small: 6 bits > > key_verify failed for server_host_key > > debug: Calling cleanup 0x418ba4(0x0) > > > > That's it. What's going on here? > > This was announced a few weeks ago - you need to recreate your SSH2 > RSA keys as their encoding has changed to match the internet-draft. Urgh. I had completely forgotten about that. Sorry and thanks for the reply. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From mouring at etoh.eviladmin.org Fri Feb 2 11:57:13 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 1 Feb 2001 18:57:13 -0600 (CST) Subject: OpenSSH 2.4? In-Reply-To: <20010201234950.F19867@cygbert.vinschen.de> Message-ID: Thanks, I was expecting this to come up. Applied. - Ben On Thu, 1 Feb 2001, Corinna Vinschen wrote: > On Wed, Jan 31, 2001 at 05:32:23PM -0600, mouring at etoh.eviladmin.org wrote: > > Current list of problems I know of: > > > > * Cray & HP/UX -- sigaction vs signal > > * SCO w/ native compiler -- No sftp-server due to lack of 64bit > > * NeXTStep -- Report it's broken, no verification yet. (No compile > > warnings) > > * DG/UX -- regcomp/regexec issues(?) > > > > ?? More ?? > > Yep. The openbsd-compat subdirectory doesn't build if the builddir > is not the sourcedir: > > /src/openssh/bin[41]$ make > (cd `dirname openbsd-compat/libopenbsd-compat.a`; make) > make[1]: Entering directory `/src/openssh/bin/openbsd-compat' > make[1]: *** No rule to make target `bsd-arc4random.o', needed by `libopenbsd-compat.a'. Stop. > make[1]: Leaving directory `/src/openssh/bin/openbsd-compat' > make: *** [openbsd-compat/libopenbsd-compat.a] Error 2 > > Patch attached. > > Corinna > > From mouring at etoh.eviladmin.org Fri Feb 2 12:01:46 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 1 Feb 2001 19:01:46 -0600 (CST) Subject: OpenSSH 2.4? In-Reply-To: <20010202000718.H19867@cygbert.vinschen.de> Message-ID: On Fri, 2 Feb 2001, Corinna Vinschen wrote: > On Thu, Feb 01, 2001 at 11:49:50PM +0100, Corinna Vinschen wrote: > > On Wed, Jan 31, 2001 at 05:32:23PM -0600, mouring at etoh.eviladmin.org wrote: > > > Current list of problems I know of: > > > > > > * Cray & HP/UX -- sigaction vs signal > > > * SCO w/ native compiler -- No sftp-server due to lack of 64bit > > > * NeXTStep -- Report it's broken, no verification yet. (No compile > > > warnings) > > > * DG/UX -- regcomp/regexec issues(?) > > > > > > ?? More ?? > > > > Yep. The openbsd-compat subdirectory doesn't build if the builddir > > is not the sourcedir: > > [...] > > ... and ssh-keyscan doesn't build: > > /src/openssh/bin[65]$ make > gcc -g -O2 -Wall -I. -I../src/openbsd-compat -I../src -DETCDIR=\"/etc\" -D_PATH_SSH_PROGRAM=\"/usr/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/sbin/ssh-askpass\" -DHAVE_CONFIG_H -c ../src/ssh-keyscan.c > ../src/ssh-keyscan.c:16: bsd-queue.h: No such file or directory > make: *** [ssh-keyscan.o] Error 1 > > Where is bsd-queue.h??? I have the latest from CVS. > Hmm.. Missed that one... It was moved to openbsd-compat/queue.h Try this and see if it resolves the problem. If it does I'll apply it to the tree. diff -ur openssh/ssh-keyscan.c ossh/ssh-keyscan.c --- openssh/ssh-keyscan.c Sun Jan 21 23:34:43 2001 +++ ossh/ssh-keyscan.c Thu Feb 1 18:59:45 2001 @@ -13,7 +13,7 @@ #if defined(HAVE_SYS_QUEUE_H) && !defined(HAVE_BOGUS_SYS_QUEUE_H) #include #else -#include "bsd-queue.h" +#include "openbsd-compat/queue.h" #endif #include From tim at multitalents.net Fri Feb 2 16:52:58 2001 From: tim at multitalents.net (Tim Rice) Date: Thu, 1 Feb 2001 21:52:58 -0800 (PST) Subject: OpenSSH 2.4? In-Reply-To: Message-ID: On Wed, 31 Jan 2001 mouring at etoh.eviladmin.org wrote: [snip] > BTW.. I just commited a reorder patch. All the bsd-*, fake-*, next-*, > and cygwin* files have been moved to openbsd-compat/. (Something I've > been wanting to do for months .) So if anyone has problems let > me know. Here is a patch for Makefile.in that changes make to $(MAKE) for those of us that use gmake because our make is broken > > Current list of problems I know of: > > * Cray & HP/UX -- sigaction vs signal > * SCO w/ native compiler -- No sftp-server due to lack of 64bit > * NeXTStep -- Report it's broken, no verification yet. (No compile > warnings) > * DG/UX -- regcomp/regexec issues(?) Don't forget the test -S problem. > > ?? More ?? > > - Ben > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- Makefile.in.old Thu Feb 1 16:00:54 2001 +++ Makefile.in Thu Feb 1 21:45:50 2001 @@ -79,7 +79,7 @@ LIBCOMPAT=openbsd-compat/libopenbsd-compat.a $(LIBCOMPAT): - (cd `dirname $@`; make) + (cd `dirname $@`; $(MAKE)) libssh.a: $(LIBSSH_OBJS) $(AR) rv $@ $(LIBSSH_OBJS) @@ -117,12 +117,12 @@ $(FIXPATHSCMD) $(srcdir)/$@ clean: - (cd openbsd-compat; make clean) + (cd openbsd-compat; $(MAKE) clean) rm -f *.o *.a $(TARGETS) logintest config.cache config.log rm -f *.out core distclean: clean - (cd openbsd-compat; make distclean) + (cd openbsd-compat; $(MAKE) distclean) rm -f Makefile config.h config.status ssh_prng_cmds *~ mrproper: distclean From vinschen at redhat.com Fri Feb 2 18:29:55 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 2 Feb 2001 08:29:55 +0100 Subject: OpenSSH 2.4? In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Feb 01, 2001 at 07:01:46PM -0600 References: <20010202000718.H19867@cygbert.vinschen.de> Message-ID: <20010202082955.K19867@cygbert.vinschen.de> On Thu, Feb 01, 2001 at 07:01:46PM -0600, mouring at etoh.eviladmin.org wrote: > > ... and ssh-keyscan doesn't build: > > > > /src/openssh/bin[65]$ make > > gcc -g -O2 -Wall -I. -I../src/openbsd-compat -I../src -DETCDIR=\"/etc\" -D_PATH_SSH_PROGRAM=\"/usr/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/sbin/ssh-askpass\" -DHAVE_CONFIG_H -c ../src/ssh-keyscan.c > > ../src/ssh-keyscan.c:16: bsd-queue.h: No such file or directory > > make: *** [ssh-keyscan.o] Error 1 > > > > Where is bsd-queue.h??? I have the latest from CVS. > > > Hmm.. Missed that one... It was moved to openbsd-compat/queue.h > > Try this and see if it resolves the problem. If it does I'll apply it to > the tree. > > diff -ur openssh/ssh-keyscan.c ossh/ssh-keyscan.c > --- openssh/ssh-keyscan.c Sun Jan 21 23:34:43 2001 > +++ ossh/ssh-keyscan.c Thu Feb 1 18:59:45 2001 > @@ -13,7 +13,7 @@ > #if defined(HAVE_SYS_QUEUE_H) && !defined(HAVE_BOGUS_SYS_QUEUE_H) > #include > #else > -#include "bsd-queue.h" > +#include "openbsd-compat/queue.h" > #endif > #include That helps, thanks. However, includes.h does include bsd-*.h files without explicitly mentioning the openbsd-compat directory, as in #include "bsd-nextstep.h" I think it's better doing it everywhere the same so I would change ssh-keyscan.c this way: diff -u -p -r1.14 ssh-keyscan.c --- ssh-keyscan.c 2001/01/22 05:34:43 1.14 +++ ssh-keyscan.c 2001/02/02 07:02:41 @@ -13,7 +13,7 @@ RCSID("$OpenBSD: ssh-keyscan.c,v 1.11 20 #if defined(HAVE_SYS_QUEUE_H) && !defined(HAVE_BOGUS_SYS_QUEUE_H) #include #else -#include "bsd-queue.h" +#include "queue.h" #endif #include Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From mouring at etoh.eviladmin.org Fri Feb 2 22:09:42 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 2 Feb 2001 05:09:42 -0600 (CST) Subject: OpenSSH 2.4? In-Reply-To: <20010202082955.K19867@cygbert.vinschen.de> Message-ID: On Fri, 2 Feb 2001, Corinna Vinschen wrote: [..] > > That helps, thanks. However, includes.h does include bsd-*.h files > without explicitly mentioning the openbsd-compat directory, as in > > #include "bsd-nextstep.h" > > I think it's better doing it everywhere the same so I would change > ssh-keyscan.c this way: > My main concern was include space clashes. If you have a that is bogus and if we are only refering to the header as "queue.h" we may end up picking up stuff we did not want. Which is why I did it that way. Maybe it would be better to rename queue.h to fake-queue.h then we would not have to worry about such things. - Ben From mouring at etoh.eviladmin.org Fri Feb 2 22:12:47 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 2 Feb 2001 05:12:47 -0600 (CST) Subject: OpenSSH 2.4? In-Reply-To: Message-ID: Thanks, applied. - Ben On Thu, 1 Feb 2001, Tim Rice wrote: > On Wed, 31 Jan 2001 mouring at etoh.eviladmin.org wrote: > > [snip] > > BTW.. I just commited a reorder patch. All the bsd-*, fake-*, next-*, > > and cygwin* files have been moved to openbsd-compat/. (Something I've > > been wanting to do for months .) So if anyone has problems let > > me know. > > Here is a patch for Makefile.in that changes make to $(MAKE) > for those of us that use gmake because our make is broken > > > > > Current list of problems I know of: > > > > * Cray & HP/UX -- sigaction vs signal > > * SCO w/ native compiler -- No sftp-server due to lack of 64bit > > * NeXTStep -- Report it's broken, no verification yet. (No compile > > warnings) > > * DG/UX -- regcomp/regexec issues(?) > > Don't forget the test -S problem. > > > > > ?? More ?? > > > > - Ben > > > > > > From Roumen.Petrov at SkalaSoft.com Fri Feb 2 21:20:47 2001 From: Roumen.Petrov at SkalaSoft.com (Roumen Petrov) Date: Fri, 2 Feb 2001 12:20:47 +0200 Subject: OpenSSH 2.4? Message-ID: Are you sure that Makefile is recreated from new Makefile.in ! I don't have this problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1242 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010202/3e01e522/attachment.bin From vinschen at redhat.com Fri Feb 2 21:28:30 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 2 Feb 2001 11:28:30 +0100 Subject: OpenSSH 2.4? In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Feb 02, 2001 at 05:09:42AM -0600 References: <20010202082955.K19867@cygbert.vinschen.de> Message-ID: <20010202112830.P19867@cygbert.vinschen.de> On Fri, Feb 02, 2001 at 05:09:42AM -0600, mouring at etoh.eviladmin.org wrote: > Maybe it would be better to rename queue.h to fake-queue.h then we > would not have to worry about such things. I agree. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From vinschen at redhat.com Fri Feb 2 21:37:58 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 2 Feb 2001 11:37:58 +0100 Subject: OpenSSH 2.4? In-Reply-To: ; from Roumen.Petrov@SkalaSoft.com on Fri, Feb 02, 2001 at 12:20:47PM +0200 References: Message-ID: <20010202113758.Q19867@cygbert.vinschen.de> On Fri, Feb 02, 2001 at 12:20:47PM +0200, Roumen Petrov wrote: > Are you sure that Makefile is recreated from new Makefile.in ! > I don't have this problem. What exactly are you talking about? When I've built OpenSSH yesterday I created a new clean build directory and called $(srcdir)/configure. You will not see this problem when building in the source tree. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From vinschen at redhat.com Sat Feb 3 01:46:17 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 2 Feb 2001 15:46:17 +0100 Subject: A simple cleanup Message-ID: <20010202154617.R19867@cygbert.vinschen.de> Hi, I have attached a patch which eliminates two "#ifdef HAVE_CYGWIN". In scp.c I have replaced it by "#ifdef HAVE_TCGETPGRP". tcgetpgrp(3) is the correct way to get the controlling tty anyway, according to POSIX.1 and SUSv2. The HAVE_CYGWIN in includes.h can be dropped because Cygwin got a netinet/tcp.h in the meantime. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com -------------- next part -------------- Index: configure.in =================================================================== RCS file: /cvs/openssh_cvs/configure.in,v retrieving revision 1.228 diff -u -p -r1.228 configure.in --- configure.in 2001/01/31 21:52:03 1.228 +++ configure.in 2001/02/02 14:37:12 @@ -316,7 +316,7 @@ AC_CHECK_FUNC(utimes, 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 regex.h shadow.h security/pam_appl.h sys/bitypes.h sys/bsdtty.h sys/cdefs.h sys/poll.h sys/queue.h sys/select.h sys/stat.h sys/stropts.h sys/sysmacros.h sys/time.h sys/ttcompat.h sys/un.h stddef.h time.h ttyent.h usersec.h util.h utime.h utmp.h utmpx.h vis.h) dnl Checks for library functions. -AC_CHECK_FUNCS(arc4random atexit b64_ntop bcopy bindresvport_sa clock fchmod freeaddrinfo futimes gai_strerror getcwd getaddrinfo getgrouplist getnameinfo getrlimit getrusage getttyent inet_aton inet_ntoa innetgr login_getcapbool md5_crypt memmove mkdtemp on_exit openpty realpath rresvport_af setdtablesize setenv seteuid setlogin setproctitle setreuid setrlimit setsid sigaction sigvec snprintf strerror strlcat strlcpy strmode strsep strtok_r sysconf utimes vsnprintf vhangup vis waitpid _getpty __b64_ntop) +AC_CHECK_FUNCS(arc4random atexit b64_ntop bcopy bindresvport_sa clock fchmod freeaddrinfo futimes gai_strerror getcwd getaddrinfo getgrouplist getnameinfo getrlimit getrusage getttyent inet_aton inet_ntoa innetgr login_getcapbool md5_crypt memmove mkdtemp on_exit openpty realpath rresvport_af setdtablesize setenv seteuid setlogin setproctitle setreuid setrlimit setsid sigaction sigvec snprintf strerror strlcat strlcpy strmode strsep strtok_r sysconf tcgetpgrp utimes vsnprintf vhangup vis waitpid _getpty __b64_ntop) dnl Checks for time functions AC_CHECK_FUNCS(gettimeofday time) dnl Checks for libutil functions Index: includes.h =================================================================== RCS file: /cvs/openssh_cvs/includes.h,v retrieving revision 1.43 diff -u -p -r1.43 includes.h --- includes.h 2001/01/31 21:52:03 1.43 +++ includes.h 2001/02/02 14:37:12 @@ -29,9 +29,7 @@ static /**/const char *const rcsid[] = { #include #include -#ifndef HAVE_CYGWIN #include -#endif #include #include Index: scp.c =================================================================== RCS file: /cvs/openssh_cvs/scp.c,v retrieving revision 1.47 diff -u -p -r1.47 scp.c --- scp.c 2001/01/22 05:34:42 1.47 +++ scp.c 2001/02/02 14:37:14 @@ -1111,11 +1111,7 @@ foregroundproc() if (pgrp == -1) pgrp = getpgrp(); -#ifdef HAVE_CYGWIN - /* - * Cygwin only supports tcgetpgrp() for getting the controlling tty - * currently. - */ +#ifdef HAVE_TCGETPGRP return ((ctty_pgrp = tcgetpgrp(STDOUT_FILENO)) != -1 && ctty_pgrp == pgrp); #else From mouring at etoh.eviladmin.org Sat Feb 3 08:20:31 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 2 Feb 2001 15:20:31 -0600 (CST) Subject: A simple cleanup In-Reply-To: <20010202154617.R19867@cygbert.vinschen.de> Message-ID: Applied On Fri, 2 Feb 2001, Corinna Vinschen wrote: > Hi, > > I have attached a patch which eliminates two "#ifdef HAVE_CYGWIN". > > In scp.c I have replaced it by "#ifdef HAVE_TCGETPGRP". tcgetpgrp(3) > is the correct way to get the controlling tty anyway, according to > POSIX.1 and SUSv2. > > The HAVE_CYGWIN in includes.h can be dropped because Cygwin got a > netinet/tcp.h in the meantime. > > Corinna > > From tom at avatar.itc.nrcs.usda.gov Sat Feb 3 07:34:52 2001 From: tom at avatar.itc.nrcs.usda.gov (Tom Rudnick) Date: Fri, 2 Feb 2001 13:34:52 -0700 (MST) Subject: pty problems w/ Unixware In-Reply-To: from "Kevin Steves" at Feb 01, 2001 10:50:42 PM Message-ID: <200102022034.NAA24495@avatar.itc.nrcs.usda.gov> > > i've been using this patch for the protocol 2 SIGCHLD problem on hp-ux. > a s/signal/mysignal/ would be a next step. > > Index: misc.c > =================================================================== > RCS file: /var/cvs/openssh/misc.c,v I can't apply this patch because I don't have misc.h or misc.c in the source for 2.3.0p1. Is this only in the cvs w/ unreleased code? -Tom -- ----------------/---------------------------------------------- Tom Rudnick | USDA Natural Resources Conservation Service Fort Collins,CO | tom at avatar.itc.nrcs.usda.gov (970) 295-5427 ** The 3rd Millennium starts Jan 1, 2001. see: ** ** http://aa.usno.navy.mil/AA/faq/docs/millennium.html ** -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From mouring at etoh.eviladmin.org Sat Feb 3 08:33:20 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 2 Feb 2001 15:33:20 -0600 (CST) Subject: pty problems w/ Unixware In-Reply-To: <200102022034.NAA24495@avatar.itc.nrcs.usda.gov> Message-ID: On Fri, 2 Feb 2001, Tom Rudnick wrote: > > > > i've been using this patch for the protocol 2 SIGCHLD problem on hp-ux. > > a s/signal/mysignal/ would be a next step. > > > > Index: misc.c > > =================================================================== > > RCS file: /var/cvs/openssh/misc.c,v > > I can't apply this patch because I don't have misc.h or misc.c in > the source for 2.3.0p1. Is this only in the cvs w/ unreleased code? > util.[ch] was rename to misc.[ch] in the current CVS tree. From markus.friedl at informatik.uni-erlangen.de Sat Feb 3 20:59:56 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 3 Feb 2001 10:59:56 +0100 Subject: Key fingerprint feature request In-Reply-To: <20010115190339.A25822@laivuri63.uku.fi>; from jhuuskon@messi.uku.fi on Mon, Jan 15, 2001 at 07:03:39PM +0200 References: <20010112100924.A4380@laivuri63.uku.fi> <20010112094406.A9799@faui02.informatik.uni-erlangen.de> <20010115190339.A25822@laivuri63.uku.fi> Message-ID: <20010203105956.B18919@folly> On Mon, Jan 15, 2001 at 07:03:39PM +0200, Jarno Huuskonen wrote: > On Fri, Jan 12, Markus Friedl wrote: > > i think it would be nice if the commercial ssh could print > > out the host keys fingerprint in same format as OpenSSH :) > > I'm not very optimistic that commercial ssh is going to change to > md5/hex fingerprint :) i tried to document our fingerprint format and sent this to the ietf-secsh list. http://wwwcip.informatik.uni-erlangen.de/~msfriedl/fp.txt From jason at dfmm.org Sat Feb 3 23:19:59 2001 From: jason at dfmm.org (Jason Stone) Date: Sat, 3 Feb 2001 04:19:59 -0800 (PST) Subject: Key fingerprint feature request In-Reply-To: <20010203105956.B18919@folly> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > I'm not very optimistic that commercial ssh is going to change to > > md5/hex fingerprint :) > > i tried to document our fingerprint format and > sent this to the ietf-secsh list. Except that isn't md5 deprecated in favor of sha1? The collision resistance of md5 has been shown to be substancially less than was originally believed, while sha1 is still believed (to my knowledge) to be secure. Additionally, there new fips standards extending sha1 to other lengths than 160 bits to match the movement to much longer keys/hashes/moduli that started with AES, which may be desirable in the future. Cryptography aside, sha1 is a federal standard, and is standard in f-secure, as well as non-related products like GnuPG. Wouldn't it make sense for us to also use (or at least support) sha1? -Jason --------------------------- If the Revolution comes to grief, it will be because you and those you lead have become alarmed at your own brutality. --John Gardner -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE6e/dzswXMWWtptckRAgPEAJ99yfM3XtSJr83WbIf1kgA5icK6mACgqmjd 52SUQRNA+llkvTMs+X0HIo8= =hY10 -----END PGP SIGNATURE----- From stevesk at sweden.hp.com Sun Feb 4 02:26:56 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Sat, 3 Feb 2001 16:26:56 +0100 (MET) Subject: pty problems w/ Unixware In-Reply-To: Message-ID: On Fri, 2 Feb 2001 mouring at etoh.eviladmin.org wrote: : > > Index: misc.c : > > =================================================================== : > > RCS file: /var/cvs/openssh/misc.c,v : > : > I can't apply this patch because I don't have misc.h or misc.c in : > the source for 2.3.0p1. Is this only in the cvs w/ unreleased code? : : util.[ch] was rename to misc.[ch] in the current CVS tree. and that patch isn't needed for 2.3.0p1 because things were done differently. From gert at greenie.muc.de Sun Feb 4 03:08:40 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 3 Feb 2001 17:08:40 +0100 Subject: OpenSSH 2.4? In-Reply-To: ; from Tim Rice on Thu, Feb 01, 2001 at 09:52:58PM -0800 References: Message-ID: <20010203170840.A1769@greenie.muc.de> hi, On Thu, Feb 01, 2001 at 09:52:58PM -0800, Tim Rice wrote: > Don't forget the test -S problem. Just tried openssh_cvs "up-to-date" on SCO 3.2v4.2, and "test -S" is still there... (configure redone by "autoconf" after "cvs update -d"). There is another problem in configure with the library order when testing for s/key - it tries the following: configure:6996: gcc -o conftest -g -O2 -Wall -Dftruncate=chsize -I/usr/local/include -I/usr/local/ssl/include -L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/ssl conftest.c -lintl -lz -lsocket -lgen -lsocket -los -lprot -lx -ltinfo -lm -lcrypto -lskey 1>&5 which bombs with: undefined first referenced symbol in file strftime /usr/local/lib/libskey.a nap /usr/local/lib/libskey.a gethostname /usr/local/lib/libskey.a ld fatal: Symbol referencing errors. No output written to conftest because those are in -lintl (strftime), -lx (nap) and -lsocket (gethostname), which have to be linked *after* -lskey. So maybe -lskey should come first in the library search order that "configure" is trying? (It will at least make configure run through :-) ). 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 Feb 4 03:39:49 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 3 Feb 2001 17:39:49 +0100 Subject: OpenSSH 2.4? In-Reply-To: <20010203170840.A1769@greenie.muc.de>; from Gert Doering on Sat, Feb 03, 2001 at 05:08:40PM +0100 References: <20010203170840.A1769@greenie.muc.de> Message-ID: <20010203173949.B1769@greenie.muc.de> Hi, On Sat, Feb 03, 2001 at 05:08:40PM +0100, Gert Doering wrote: > > Don't forget the test -S problem. > > Just tried openssh_cvs "up-to-date" on SCO 3.2v4.2, and "test -S" is still > there... (configure redone by "autoconf" after "cvs update -d"). To followup on myself: - openbsd-compat/strtok.c includes "bsd-strtok.h" but the file is called "strtok.h" -> renaming to bsd-strtok.h makes it compile (but breaks openbsd-compat.h, which includes "strtok.h"). - configure fails to detect HAVE_CLOCK_T, which leads to compiler warnings - harmless, but looks scary :-) In file included from ../config.h:648, from strtok.c:34: ../defines.h:210: warning: redefinition of `clock_t' /usr/include/sys/types.h:147: warning: `clock_t' previously declared here In file included from ../defines.h:404, from ../config.h:648, from strtok.c:34: - Makefile contains the line: $(LIBOPENBSD_COMPAT_OBJS): config.h which makes SCO make choke, as LIBOPENBSD_COMPAT_OBJS is not defined. - openbsd-compat/Makefile contains a similar line: $(BSDCOMPAT): ../config.h which doesn't work either - I think it should be $(COMPAT) or $(OPENBSD) - maybe both. [With GNU make, both are ignored] - compilation of "log.c" with "gcc -g -O2" (gcc 2.7.2.3) breaks. I can't see any obvious reason for this, though: gcc -g -O2 -Wall -Dftruncate=chsize -I/usr/local/include -I/usr/local/ssl/include -I. -I./openbsd-compat -I. -DETCDIR=\"/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c log.c In file included from defines.h:404, from config.h:681, from includes.h:22, from log.c:38: log.c: In function `log_facility_number': log.c:227: warning: implicit declaration of function `strcasecmp' /usr/tmp/cca13925.s:1007: FATAL:C_EFCN symbol out of scope gmake: *** [log.o] Error 1 compiling without "-g" makes log.c compile just fine. So maybe this is something that just cannot be fixed without me upgrading my gcc :-) - linking ssh bombs out with: gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o log-client.o readconf.o clientloop.o -L. -Lopenbsd-compat/ -L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/ssl -lssh -lopenbsd-compat -lskey -lintl -lz -lsocket -lgen -lsocket -los -lprot -lx -ltinfo -lm -lcrypto ld crtbegin.o: too many -L options, 6 allowed which is fixed by removing "/usr/local/lib" (gcc inserts that anyway) and also "/usr/local/ssl" (the library is in /usr/local/ssl/lib). - linking scp bombs with "unreferenced utimes()" - this has been discussed before - what's the status of this? ... after hacking all these things, ssh, sshd & co compile and link fine. This means you've done very good work on the portability side - SCO 3.0 is *old*, and very "different". Can't comment on "work" yet, will test now... 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 shorty at getuid.de Sun Feb 4 04:26:59 2001 From: shorty at getuid.de (Christian Kurz) Date: Sat, 3 Feb 2001 18:26:59 +0100 Subject: Detection of identical file doesn't work for localhost: In-Reply-To: <20010130114438.A16866@faui02.informatik.uni-erlangen.de> References: <20010130082749.T17538@seteuid.getuid.de> <20010130114438.A16866@faui02.informatik.uni-erlangen.de> Message-ID: <20010203182659.V17538@seteuid.getuid.de> On 01-01-30 Markus Friedl wrote: > > I had to notice that scp is able to detect if a file is copied to itself > > if you use "scp foo /path/to/foo" or "scp foo .". If you type in "scp > > foo localhost:/path/to/foo" it will still overwrite the old version of > > foo. Is it possible to change this behaviour of scp? > how could 'scp' tell that it's really the identical file? I have no idea and and that's why I asked here, if it would be possible to detect localhost and then invoke the other method for doing a file-copy. But as Damien pointed out, there far to many things to test for, so I also agree that openssh shouldn't be changed. Ciao Christian -- When it is incorrect, it is, at least *authoritatively* incorrect. -- Hitchiker's Guide To The Galaxy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010203/a632d385/attachment.bin From mouring at etoh.eviladmin.org Sun Feb 4 09:57:30 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 3 Feb 2001 16:57:30 -0600 (CST) Subject: OpenSSH 2.4? In-Reply-To: <20010203173949.B1769@greenie.muc.de> Message-ID: On Sat, 3 Feb 2001, Gert Doering wrote: > Hi, > > On Sat, Feb 03, 2001 at 05:08:40PM +0100, Gert Doering wrote: > > > Don't forget the test -S problem. > > > > Just tried openssh_cvs "up-to-date" on SCO 3.2v4.2, and "test -S" is still > > there... (configure redone by "autoconf" after "cvs update -d"). > No one has given me an acceptable replace for 'test -S'... So I'm not personally inclined to muck with it.=) > To followup on myself: > > - openbsd-compat/strtok.c includes "bsd-strtok.h" but the file is > called "strtok.h" -> renaming to bsd-strtok.h makes it compile > (but breaks openbsd-compat.h, which includes "strtok.h"). > The last two bsd-* in the openbsd-compat/ should be resolved. ( I just submitted it) > - configure fails to detect HAVE_CLOCK_T, which leads to compiler > warnings - harmless, but looks scary :-) > Did this fail before? I've not seen HAVE_CLOCK_T issues on any of my machine for a while. > > - Makefile contains the line: > > $(LIBOPENBSD_COMPAT_OBJS): config.h > > which makes SCO make choke, as LIBOPENBSD_COMPAT_OBJS is not defined. > Fixed. > - openbsd-compat/Makefile contains a similar line: > > $(BSDCOMPAT): ../config.h > > which doesn't work either - I think it should be $(COMPAT) or > $(OPENBSD) - maybe both. [With GNU make, both are ignored] > Should be both.. in an earier version of this change over I had grouped everything together, but later decided that it would make more sense to split them. It gives you another place to realize what is OpenBSD based source code, and home-brewed stuff. > - compilation of "log.c" with "gcc -g -O2" (gcc 2.7.2.3) breaks. I can't > see any obvious reason for this, though: > > gcc -g -O2 -Wall -Dftruncate=chsize -I/usr/local/include -I/usr/local/ssl/include -I. -I./openbsd-compat -I. -DETCDIR=\"/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c log.c > In file included from defines.h:404, > from config.h:681, > from includes.h:22, > from log.c:38: > log.c: In function `log_facility_number': > log.c:227: warning: implicit declaration of function `strcasecmp' > /usr/tmp/cca13925.s:1007: FATAL:C_EFCN symbol out of scope > gmake: *** [log.o] Error 1 > > compiling without "-g" makes log.c compile just fine. So maybe this > is something that just cannot be fixed without me upgrading my gcc :-) > Don't know anything about that. Sorry. Which GCC release? > - linking ssh bombs out with: > > gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o log-client.o readconf.o clientloop.o -L. -Lopenbsd-compat/ -L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/ssl -lssh -lopenbsd-compat -lskey -lintl -lz -lsocket -lgen -lsocket -los -lprot -lx -ltinfo -lm -lcrypto > ld crtbegin.o: too many -L options, 6 allowed > > which is fixed by removing "/usr/local/lib" (gcc inserts that anyway) and > also "/usr/local/ssl" (the library is in /usr/local/ssl/lib). > > - linking scp bombs with "unreferenced utimes()" - this has been discussed > before - what's the status of this? > Hmm... utimes() was resolved a while ago. 20010115 - (bal) utimes() support via utime() interface on machine that lack utimes(). openbsd-compat/bsd-misc.c:int utimes(char *filename, struct timeval *tvp) Are you sure you regenerated your 'configure'? Do a './configure | grep utimes' and see wh > ... after hacking all these things, ssh, sshd & co compile and link fine. > This means you've done very good work on the portability side - SCO 3.0 > is *old*, and very "different". > > Can't comment on "work" yet, will test now... > - Ben From jones at hpc.utexas.edu Sun Feb 4 11:54:53 2001 From: jones at hpc.utexas.edu (William L. Jones) Date: Sat, 03 Feb 2001 18:54:53 -0600 Subject: minor aix patch to auth1.c Message-ID: <4.2.0.58.20010203185315.01cbd960@127.0.0.1> --- auth1.c.orig Sat Feb 3 18:17:53 2001 Bringa AIX modes in line with latest changes to auth1.c +++ auth1.c Sat Feb 3 18:19:15 2001 @@ -347,7 +347,7 @@ if (authctxt->failures++ > AUTH_FAIL_MAX) { #ifdef WITH_AIXAUTHENTICATE - loginfailed(user,get_canonical_hostname(),"ssh"); + loginfailed(authctxt->user,get_canonical_hostname(),"ssh"); #endif /* WITH_AIXAUTHENTICATE */ packet_disconnect(AUTH_FAIL_MSG, authctxt->user); } From djm at mindrot.org Sun Feb 4 11:54:56 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 4 Feb 2001 11:54:56 +1100 (EST) Subject: Detection of identical file doesn't work for localhost: In-Reply-To: <20010203182659.V17538@seteuid.getuid.de> Message-ID: On Sat, 3 Feb 2001, Christian Kurz wrote: > I have no idea and and that's why I asked here, if it would be possible > to detect localhost and then invoke the other method for doing a > file-copy. But as Damien pointed out, there far to many things to test > for, so I also agree that openssh shouldn't be changed. Another way around the problem would be to make scp write to a temporary file and then do a rename() as the last step. This would prevent people from clobbering files. -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 Feb 4 11:56:53 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 4 Feb 2001 11:56:53 +1100 (EST) Subject: OpenSSH 2.4? In-Reply-To: Message-ID: On Sat, 3 Feb 2001 mouring at etoh.eviladmin.org wrote: > No one has given me an acceptable replace for 'test -S'... So I'm not > personally inclined to muck with it.=) What platforms do/don't support 'test -S' (without the addition of the GNU tools)? If it is just one or two, then we could disable the test for them at the expense of losing autodetection of the EGD socket. The alternative it to write a little test program which stats the file. -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 tlewis at secureworks.net Sun Feb 4 12:03:20 2001 From: tlewis at secureworks.net (Todd Lewis) Date: Sat, 3 Feb 2001 20:03:20 -0500 (EST) Subject: OpenSSH 2.4? In-Reply-To: Message-ID: FWIW, support for '-S' is not mandated in the POSIX 1003.2 definition of the 'test' utility. (I've got the first edition, 1993-12-22; YMMV.) -- Todd Lewis tlewis at secureworks.net God grant me the courage not to give up what I think is right, even though I think it is hopeless. - Admiral Chester W. Nimitz On Sun, 4 Feb 2001, Damien Miller wrote: > On Sat, 3 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > No one has given me an acceptable replace for 'test -S'... So I'm not > > personally inclined to muck with it.=) > > What platforms do/don't support 'test -S' (without the addition of the > GNU tools)? > > If it is just one or two, then we could disable the test for them at > the expense of losing autodetection of the EGD socket. > > The alternative it to write a little test program which stats the file. > > -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 lists at fips.de Sun Feb 4 12:06:07 2001 From: lists at fips.de (Philipp Buehler) Date: Sun, 4 Feb 2001 02:06:07 +0100 Subject: OpenSSH 2.4? In-Reply-To: ; "Damien Miller" on 04.02.2001 @ 01:56:53 MET References: Message-ID: <20010204020606.A15280@pohl.fips.de> On 04/02/2001, Damien Miller wrote To mouring at etoh.eviladmin.org: > > No one has given me an acceptable replace for 'test -S'... So I'm not > > personally inclined to muck with it.=) > > What platforms do/don't support 'test -S' (without the addition of the > GNU tools)? HP-UX (10.20) understands test -S [and -O], but it's not documented in the manpage :} ciao -- Philipp Buehler, aka fips | sysfive.com GmbH | BOfH | NUCH | #1: We are Luser of Borg... the assimilator doesn't wooooork #2: Already had buzzword confuseritis ? From tim at multitalents.net Sun Feb 4 12:13:08 2001 From: tim at multitalents.net (Tim Rice) Date: Sat, 3 Feb 2001 17:13:08 -0800 (PST) Subject: Detection of identical file doesn't work for localhost: In-Reply-To: Message-ID: On Sun, 4 Feb 2001, Damien Miller wrote: > On Sat, 3 Feb 2001, Christian Kurz wrote: > > > I have no idea and and that's why I asked here, if it would be possible > > to detect localhost and then invoke the other method for doing a > > file-copy. But as Damien pointed out, there far to many things to test > > for, so I also agree that openssh shouldn't be changed. > > Another way around the problem would be to make scp write to a temporary > file and then do a rename() as the last step. This would prevent people > from clobbering files. I the file has links, that will break them. > > -d > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Sun Feb 4 12:21:55 2001 From: tim at multitalents.net (Tim Rice) Date: Sat, 3 Feb 2001 17:21:55 -0800 (PST) Subject: OpenSSH 2.4? In-Reply-To: Message-ID: On Sun, 4 Feb 2001, Damien Miller wrote: > On Sat, 3 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > No one has given me an acceptable replace for 'test -S'... So I'm not > > personally inclined to muck with it.=) > > What platforms do/don't support 'test -S' (without the addition of the > GNU tools)? In the do not catagory All versions of SCO All versions of UnixWare > > If it is just one or two, then we could disable the test for them at > the expense of losing autodetection of the EGD socket. > > The alternative it to write a little test program which stats the file. I'm in to process of looking into this option. > > -d > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From djm at mindrot.org Sun Feb 4 12:59:42 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 4 Feb 2001 12:59:42 +1100 (EST) Subject: Detection of identical file doesn't work for localhost: In-Reply-To: Message-ID: On Sat, 3 Feb 2001, Tim Rice wrote: > On Sun, 4 Feb 2001, Damien Miller wrote: > > > Another way around the problem would be to make scp write to a temporary > > file and then do a rename() as the last step. This would prevent people > > from clobbering files. > > I the file has links, that will break them. Still better than truncating it :) -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 Sun Feb 4 21:42:54 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 4 Feb 2001 04:42:54 -0600 (CST) Subject: next build In-Reply-To: <20010204003826.A17897@golem.ph.utexas.edu> Message-ID: > *** openbsd-compat/bsd-nextstep.h.orig Sun Feb 4 00:16:16 2001 > --- openbsd-compat/bsd-nextstep.h Sun Feb 4 00:19:09 2001 > *************** > *** 48,52 **** > --- 48,56 ---- > speed_t cfgetispeed(const struct termios *t); > int cfsetospeed(struct termios *t, int speed); > int cfsetispeed(struct termios *t, int speed); > + > + /* LIMITS */ > + #define NGROUPS_MAX 16 > + Hey, Steve.. since you put together the group access patch to OpenBSD. Do you recomend a better place or a better value for NGROUPS_MAX? It's not defined within the NeXTStep headers. Otherwise I'd perfer to put it in defines.h as a fall back incase NGROUPS_MAX is not found. - Ben From gert at greenie.muc.de Sun Feb 4 21:51:02 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 4 Feb 2001 11:51:02 +0100 Subject: OpenSSH 2.4? In-Reply-To: ; from mouring@etoh.eviladmin.org on Sat, Feb 03, 2001 at 04:57:30PM -0600 References: <20010203173949.B1769@greenie.muc.de> Message-ID: <20010204115102.A878@greenie.muc.de> Hi, On Sat, Feb 03, 2001 at 04:57:30PM -0600, mouring at etoh.eviladmin.org wrote: > > > > Don't forget the test -S problem. > > > > > > Just tried openssh_cvs "up-to-date" on SCO 3.2v4.2, and "test -S" is still > > > there... (configure redone by "autoconf" after "cvs update -d"). > > No one has given me an acceptable replace for 'test -S'... So I'm not > personally inclined to muck with it.=) There is no portable way to do an "is this a socket?" test - there are quite a number of systems that do not have unix sockets, and thus no way to do "test -S". One *could* do something like if test -f $socket then if [ "`ls -l $socket | cut -c1`" = "s" ] ; then echo "socket found" fi fi but that's ugly as hell (and I'm sure it's not portable to some other system). Hmmm. One could run a test program in C to see "is this a socket, and is there egd running on it", that would be even better... > > To followup on myself: > > > > - openbsd-compat/strtok.c includes "bsd-strtok.h" but the file is > > called "strtok.h" -> renaming to bsd-strtok.h makes it compile > > (but breaks openbsd-compat.h, which includes "strtok.h"). > > > > The last two bsd-* in the openbsd-compat/ should be resolved. ( I just > submitted it) Thanks. > > - configure fails to detect HAVE_CLOCK_T, which leads to compiler > > warnings - harmless, but looks scary :-) > > Did this fail before? I can't say for sure - last time I tried this on SCO 3.0, I got lots of warnings as well, but didn't really care to sort out which ones are "configure" related and which ones are just SCO weirdness. > I've not seen HAVE_CLOCK_T issues on any of my machine for a while. Hmm. [..] > > - compilation of "log.c" with "gcc -g -O2" (gcc 2.7.2.3) breaks. I can't > > see any obvious reason for this, though: > > > > gcc -g -O2 -Wall -Dftruncate=chsize -I/usr/local/include -I/usr/local/ssl/include -I. -I./openbsd-compat -I. -DETCDIR=\"/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c log.c > > In file included from defines.h:404, > > from config.h:681, > > from includes.h:22, > > from log.c:38: > > log.c: In function `log_facility_number': > > log.c:227: warning: implicit declaration of function `strcasecmp' > > /usr/tmp/cca13925.s:1007: FATAL:C_EFCN symbol out of scope > > gmake: *** [log.o] Error 1 > > > > compiling without "-g" makes log.c compile just fine. So maybe this > > is something that just cannot be fixed without me upgrading my gcc :-) > > > Don't know anything about that. Sorry. Which GCC release? 2.7.2.3. But actually it's the assembler choking on something GCC produced. Maybe this is just something for the FAQ - "if you see an error like this on SCO, compile the offending module without '-g'". [..] > > - linking scp bombs with "unreferenced utimes()" - this has been discussed > > before - what's the status of this? > > > Hmm... utimes() was resolved a while ago. > > 20010115 > - (bal) utimes() support via utime() interface on machine that lack > utimes(). > > openbsd-compat/bsd-misc.c:int utimes(char *filename, struct timeval *tvp) > > Are you sure you regenerated your 'configure'? Do a './configure | grep > utimes' and see wh Interesting enough, it *was* compiled into libopenbsd-compat.a, at least it shows up in "nm": $ nm openbsd-compat/libopenbsd-compat.a |grep utimes utimes | 68|extern| int( )| 34| |.text Nevertheless it's not found when linking - this is weird. AH!! From an old run, I had an "libopenbsd-compat.a" lying around in the main build directory, and the link stage is done with "-L. -Lopenbsd-compat", so it was linking the old and stale one. Removed that, utimes() issue solved, scp links fine. "make clean" didn't remove the old library, 'cause the Makefile was already upgraded, and forgot everything about ./libopenbsd-compat.a ... So I should have done make clean cvs update -d autoheader autoconf ./configure - noted, for the next time. 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 Feb 4 21:51:59 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 4 Feb 2001 11:51:59 +0100 Subject: OpenSSH 2.4? In-Reply-To: ; from Damien Miller on Sun, Feb 04, 2001 at 11:56:53AM +1100 References: Message-ID: <20010204115159.B878@greenie.muc.de> Hi, On Sun, Feb 04, 2001 at 11:56:53AM +1100, Damien Miller wrote: > > No one has given me an acceptable replace for 'test -S'... So I'm not > > personally inclined to muck with it.=) > > What platforms do/don't support 'test -S' (without the addition of the > GNU tools)? > > If it is just one or two, then we could disable the test for them at > the expense of losing autodetection of the EGD socket. For SCO 3.0, there are NO unix sockets at all, so you can safely disable everything unix-socket-related anyway. 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 Sun Feb 4 22:02:24 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 4 Feb 2001 22:02:24 +1100 (EST) Subject: OpenSSH 2.4? In-Reply-To: <20010204115159.B878@greenie.muc.de> Message-ID: On Sun, 4 Feb 2001, Gert Doering wrote: > For SCO 3.0, there are NO unix sockets at all, so you can safely disable > everything unix-socket-related anyway. Ouch! so ssh-agent won't even compile? What is the ./configure 'host system type' for this? -- | ``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 gert at greenie.muc.de Sun Feb 4 22:06:35 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 4 Feb 2001 12:06:35 +0100 Subject: OpenSSH 2.4? In-Reply-To: ; from Damien Miller on Sun, Feb 04, 2001 at 10:02:24PM +1100 References: <20010204115159.B878@greenie.muc.de> Message-ID: <20010204120635.E878@greenie.muc.de> Hi, On Sun, Feb 04, 2001 at 10:02:24PM +1100, Damien Miller wrote: > > For SCO 3.0, there are NO unix sockets at all, so you can safely disable > > everything unix-socket-related anyway. > Ouch! so ssh-agent won't even compile? Yes, it does :-) - seems it fell back to using pipes (did not look closely into it, and didn't try it either). If I try ssh.com's ssh-agent on this system, it refuses cooperation with: $ ssh-agent xterm socket: Protocol not supported > What is the ./configure 'host system type' for this? checking host system type... i586-pc-sco3.2v4.2 ... 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: /etc Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/man/catX PID file: /var/run Random number collection: Builtin (timeout 200) 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: i586-pc-sco3.2v4.2 Compiler: gcc Compiler flags: -g -O2 -Wall Preprocessor flags: -Dftruncate=chsize -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: -lskey -lintl -lz -lsocket -lgen -lsocket -los -lprot -lx -ltinfo -lm -lcrypto 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 Sun Feb 4 23:40:15 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Sun, 4 Feb 2001 13:40:15 +0100 (MET) Subject: next build In-Reply-To: Message-ID: On Sun, 4 Feb 2001 mouring at etoh.eviladmin.org wrote: : Hey, Steve.. since you put together the group access patch to OpenBSD. Do : you recomend a better place or a better value for NGROUPS_MAX? It's not : defined within the NeXTStep headers. Otherwise I'd perfer to put it in : defines.h as a fall back incase NGROUPS_MAX is not found. i think defines.h is a good place, but it should probably be 0 if not defined, which indicates that supplementary groups are not supported: #ifndef NGROUPS_MAX #define NGROUPS_MAX 0 #endif the groupaccess code does handle this case, and you get the old behaviour of using just the primary group. From Lutz.Jaenicke at aet.TU-Cottbus.DE Mon Feb 5 03:20:58 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Sun, 4 Feb 2001 17:20:58 +0100 Subject: OpenSSH 2.4? In-Reply-To: <20010204115102.A878@greenie.muc.de>; from gert@greenie.muc.de on Sun, Feb 04, 2001 at 11:51:02AM +0100 References: <20010203173949.B1769@greenie.muc.de> <20010204115102.A878@greenie.muc.de> Message-ID: <20010204172058.B28940@serv01.aet.tu-cottbus.de> On Sun, Feb 04, 2001 at 11:51:02AM +0100, Gert Doering wrote: > On Sat, Feb 03, 2001 at 04:57:30PM -0600, mouring at etoh.eviladmin.org wrote: > > > > > Don't forget the test -S problem. > > > > > > > > Just tried openssh_cvs "up-to-date" on SCO 3.2v4.2, and "test -S" is still > > > > there... (configure redone by "autoconf" after "cvs update -d"). > > > > No one has given me an acceptable replace for 'test -S'... So I'm not > > personally inclined to muck with it.=) > > There is no portable way to do an "is this a socket?" test - there are > quite a number of systems that do not have unix sockets, and thus no way > to do "test -S". > > One *could* do something like > > if test -f $socket > then > if [ "`ls -l $socket | cut -c1`" = "s" ] ; then > echo "socket found" > fi > fi > > but that's ugly as hell (and I'm sure it's not portable to some other > system). > > Hmmm. One could run a test program in C to see "is this a socket, and > is there egd running on it", that would be even better... On the OpenSSL list we were just tracking down a similar problem. In this case we were struggling with Unixware 7 (I already fighted against it for PRNGD): It seems that Unixware 7 supports sockets; these are however flagged as FIFOs in the filesystem (prwx...). Doesn't make things easier, does it? You cannot distinguish them from the filesystem point of view, so using a test program to connect() to it might be the only way to find out... 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 tim at multitalents.net Mon Feb 5 06:25:34 2001 From: tim at multitalents.net (Tim Rice) Date: Sun, 4 Feb 2001 11:25:34 -0800 (PST) Subject: OpenSSH 2.4? In-Reply-To: Message-ID: On Wed, 31 Jan 2001 mouring at etoh.eviladmin.org wrote: > BTW.. I just commited a reorder patch. All the bsd-*, fake-*, next-*, > and cygwin* files have been moved to openbsd-compat/. (Something I've > been wanting to do for months .) So if anyone has problems let > me know. SCO Open Server 3 Feb 3 CVS The reorder patch adds another -L which breaks the linker. ... gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o log-client.o readconf. o clientloop.o -L. -Lopenbsd-compat/ -L/usr/local/lib -L/usr/local/ssl/lib -L/u sr/local/ssl -lssh -lopenbsd-compat -lintl -lz -lsocket -lgen -lsocket -los -lp rot -lx -ltinfo -lm -lcrypto ld crtbegin.o: too many -L options, 6 allowed gmake: *** [ssh] Error 1 ... Do we really need -L/usr/local/ssl ? It's not needed here. Does anyone know why it's there? -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mouring at etoh.eviladmin.org Mon Feb 5 08:16:41 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 4 Feb 2001 15:16:41 -0600 (CST) Subject: OpenSSH 2.4? In-Reply-To: Message-ID: On Sun, 4 Feb 2001, Tim Rice wrote: > On Wed, 31 Jan 2001 mouring at etoh.eviladmin.org wrote: > > > BTW.. I just commited a reorder patch. All the bsd-*, fake-*, next-*, > > and cygwin* files have been moved to openbsd-compat/. (Something I've > > been wanting to do for months .) So if anyone has problems let > > me know. > > SCO Open Server 3 > Feb 3 CVS > > The reorder patch adds another -L which breaks the linker. > ... > gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o log-client.o readconf. > o clientloop.o -L. -Lopenbsd-compat/ -L/usr/local/lib -L/usr/local/ssl/lib -L/u > sr/local/ssl -lssh -lopenbsd-compat -lintl -lz -lsocket -lgen -lsocket -los -lp > rot -lx -ltinfo -lm -lcrypto > ld crtbegin.o: too many -L options, 6 allowed > gmake: *** [ssh] Error 1 > ... > > Do we really need -L/usr/local/ssl ? > It's not needed here. > Does anyone know why it's there? > Try this patch. I'm not sure why /usr/local/ssl. But I suspect it's to detect a broken install that puts it's libraries in $ssldir instad of $ssldir/lib. But there should be a better way then just putting both into the LDFLAGS. - Ben --- ../openssh/configure.in Sat Feb 3 17:04:03 2001 +++ configure.in Sun Feb 4 15:09:31 2001 @@ -431,10 +431,10 @@ for ssldir in $tryssldir "" /usr/local/openssl /usr/lib/openssl /usr/local/ssl /usr/lib/ssl /usr/local /usr/pkg /opt /opt/openssl ; do if test ! -z "$ssldir" -a "x$ssldir" != "x/usr"; then - LDFLAGS="$saved_LDFLAGS -L$ssldir/lib -L$ssldir" + LDFLAGS="$saved_LDFLAGS -L$ssldir/lib" CPPFLAGS="$saved_CPPFLAGS -I$ssldir/include" if test ! -z "$need_dash_r" ; then - LDFLAGS="$LDFLAGS -R$ssldir/lib -R$ssldir" + LDFLAGS="$LDFLAGS -R$ssldir/lib" fi else LDFLAGS="$saved_LDFLAGS" @@ -484,9 +484,9 @@ if test ! -z "$ssldir" -a "x$ssldir" != "x/usr"; then CPPFLAGS="$saved_CPPFLAGS -I$ssldir/include" - LDFLAGS="$saved_LDFLAGS -L$ssldir/lib -L$ssldir" + LDFLAGS="$saved_LDFLAGS -L$ssldir/lib" if test ! -z "$need_dash_r" ; then - LDFLAGS="$LDFLAGS -R$ssldir/lib -R$ssldir" + LDFLAGS="$LDFLAGS -R$ssldir/lib" fi if test ! -z "$blibpath" ; then blibpath="$blibpath:$ssldir:$ssldir/lib" From mouring at etoh.eviladmin.org Mon Feb 5 08:21:53 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 4 Feb 2001 15:21:53 -0600 (CST) Subject: next build In-Reply-To: Message-ID: On Sun, 4 Feb 2001, Kevin Steves wrote: > On Sun, 4 Feb 2001 mouring at etoh.eviladmin.org wrote: > : Hey, Steve.. since you put together the group access patch to OpenBSD. Do > : you recomend a better place or a better value for NGROUPS_MAX? It's not > : defined within the NeXTStep headers. Otherwise I'd perfer to put it in > : defines.h as a fall back incase NGROUPS_MAX is not found. > > i think defines.h is a good place, but it should probably be 0 if not > defined, which indicates that supplementary groups are not supported: > > #ifndef NGROUPS_MAX > #define NGROUPS_MAX 0 > #endif > > the groupaccess code does handle this case, and you get the old > behaviour of using just the primary group. > Makes sense to me. Commited. - Ben From jones at hpc.utexas.edu Mon Feb 5 07:55:14 2001 From: jones at hpc.utexas.edu (William L. Jones) Date: Sun, 04 Feb 2001 14:55:14 -0600 Subject: 'test -S' In-Reply-To: <20010204020606.A15280@pohl.fips.de> References: Message-ID: <4.2.0.58.20010204145255.01c90220@127.0.0.1> it looks like Sunos up to 5.7 does not have a -S test. At 02:06 AM 2/4/01 +0100, Philipp Buehler wrote: >On 04/02/2001, Damien Miller wrote To >mouring at etoh.eviladmin.org: > > > No one has given me an acceptable replace for 'test -S'... So I'm not > > > personally inclined to muck with it.=) > > > > What platforms do/don't support 'test -S' (without the addition of the > > GNU tools)? >HP-UX (10.20) understands test -S [and -O], but it's not documented in >the manpage :} > >ciao >-- >Philipp Buehler, aka fips | sysfive.com GmbH | BOfH | NUCH | > >#1: We are Luser of Borg... the assimilator doesn't wooooork >#2: Already had buzzword confuseritis ? From mouring at etoh.eviladmin.org Mon Feb 5 09:50:22 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 4 Feb 2001 16:50:22 -0600 (CST) Subject: minor aix patch to auth1.c In-Reply-To: <4.2.0.58.20010203185315.01cbd960@127.0.0.1> Message-ID: Thanks, Applied. On Sat, 3 Feb 2001, William L. Jones wrote: > --- auth1.c.orig Sat Feb 3 18:17:53 2001 > Bringa AIX modes in line with latest changes to auth1.c > > +++ auth1.c Sat Feb 3 18:19:15 2001 > @@ -347,7 +347,7 @@ > > if (authctxt->failures++ > AUTH_FAIL_MAX) { > #ifdef WITH_AIXAUTHENTICATE > - loginfailed(user,get_canonical_hostname(),"ssh"); > + > loginfailed(authctxt->user,get_canonical_hostname(),"ssh"); > #endif /* WITH_AIXAUTHENTICATE */ > packet_disconnect(AUTH_FAIL_MSG, authctxt->user); > } > From distler at golem.ph.utexas.edu Mon Feb 5 09:31:02 2001 From: distler at golem.ph.utexas.edu (Jacques Distler) Date: Sun, 4 Feb 2001 16:31:02 -0600 Subject: next build In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- At 4:42 AM -0600 2/4/01, mouring at etoh.eviladmin.org wrote: >> *** openbsd-compat/bsd-nextstep.h.orig Sun Feb 4 00:16:16 2001 >> --- openbsd-compat/bsd-nextstep.h Sun Feb 4 00:19:09 2001 >> *************** >> *** 48,52 **** >> --- 48,56 ---- >> speed_t cfgetispeed(const struct termios *t); >> int cfsetospeed(struct termios *t, int speed); >> int cfsetispeed(struct termios *t, int speed); >> + >> + /* LIMITS */ >> + #define NGROUPS_MAX 16 >> + > >Hey, Steve.. since you put together the group access patch to OpenBSD. Do >you recomend a better place or a better value for NGROUPS_MAX? It's not >defined within the NeXTStep headers. Otherwise I'd perfer to put it in >defines.h as a fall back incase NGROUPS_MAX is not found. > >- Ben To be more precise, NGROUPS_MAX *is* defined (as above) in the NeXTStep headers if _POSIX_SOURCE is defined, but undefined otherwise. >The daemon still runs, but does no logging except for the mysterious > > Feb 4 00:23:45 golem sshd[17861]: error: Hm, dispatch protocol > error: type 50 plen 516 > Feb 4 00:23:45 golem sshd[17861]: error: Hm, dispatch protocol > error: type 50 plen 550 >errors, which get logged to /usr/adm/messages, but not LOCAL0, where >they are supposed to go. Please submit this logging issue to the openssh mailinglist. Last time I looked at NeXT's syslogd it was massively brain damaged and I could not get any code to correctly log events to it. However others may have a better idea on what to look at or try. OK. here goes . . . Somewhere between the 20010119 and the 20010126 snapshots, the NeXTStep build developed an issue. I have sshd configured to log to LOCAL0. With the 20010119 snapshot and earlier, it works fine. With later builds, the daemon seems to function OK, but *nothing* gets logged to LOCAL0. Instead, I get the following error messages logged to /usr/adm/mesages every time a client connects to the daemon: Feb 4 00:23:45 golem sshd[17861]: error: Hm, dispatch protocol error: type 50 plen 516 Feb 4 00:23:45 golem sshd[17861]: error: Hm, dispatch protocol error: type 50 plen 550 I have not had any of Ben's troubles with NeXT's syslogd. In fact, up to and including the 20010119 build, logging has worked fine. I realize there's a week's worth of changes between 20010119 and 20010126. If there is strong motivation, I could try to narrow down exactly when things broke. But some ideas as to what might be going on would be helpful. Jacques -----BEGIN PGP SIGNATURE----- Version: PGP Comment: Public Key - http://golem.ph.utexas.edu/~distler/distler.asc iQCVAwUBOn3YOaIBi34rsX+ZAQF2IwQAz8HZlRhZ7b83I6vJ8It2gox2q4AyC+TM SLGYCZQoztbqbOh+CVQTlwx31VCu7KERn2ooU7eqWQ+Zxex1G47kOdsazuXzCHQk 9F2YRoAZYwnIAmRqM3xbKOwE0EBTE28ap8FATxXeEJLP5yaSKHzIrZQa8l9q+rl7 MsUsAWjYyao= =9+nd -----END PGP SIGNATURE----- From djm at mindrot.org Mon Feb 5 09:38:49 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 5 Feb 2001 09:38:49 +1100 (EST) Subject: minor aix patch to auth1.c In-Reply-To: Message-ID: On Sun, 4 Feb 2001 mouring at etoh.eviladmin.org wrote: > > Thanks, Applied. Careful, get_canonical_hostname() now takes an integer argument, > On Sat, 3 Feb 2001, William L. Jones wrote: > > > --- auth1.c.orig Sat Feb 3 18:17:53 2001 > > Bringa AIX modes in line with latest changes to auth1.c > > > > +++ auth1.c Sat Feb 3 18:19:15 2001 > > @@ -347,7 +347,7 @@ > > > > if (authctxt->failures++ > AUTH_FAIL_MAX) { > > #ifdef WITH_AIXAUTHENTICATE > > - loginfailed(user,get_canonical_hostname(),"ssh"); > > + > > loginfailed(authctxt->user,get_canonical_hostname(),"ssh"); > > #endif /* WITH_AIXAUTHENTICATE */ > > packet_disconnect(AUTH_FAIL_MSG, authctxt->user); > > } > > > > > -- | ``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 Darren.Moffat at eng.sun.com Mon Feb 5 09:42:42 2001 From: Darren.Moffat at eng.sun.com (Darren J Moffat) Date: Sun, 04 Feb 2001 14:42:42 -0800 Subject: 'test -S' References: <4.2.0.58.20010204145255.01c90220@127.0.0.1> Message-ID: <3A7DDAE2.3F62B4A4@Eng.Sun.COM> "William L. Jones" wrote: > > it looks like Sunos up to 5.7 does not have a -S test. 5.5.1 is the first time that -S is documented in if(1) It existed in 5.1 which is when ksh first appeared. Note that -S exists only in ksh not in sh. But /usr/bin/test will use ksh rather than sh. /usr/bin/test first appeared in 5.5. -- Darren J Moffat From jones at hpc.utexas.edu Mon Feb 5 10:15:13 2001 From: jones at hpc.utexas.edu (William L. Jones) Date: Sun, 04 Feb 2001 17:15:13 -0600 Subject: 'test -S' In-Reply-To: <3A7DDAE2.3F62B4A4@Eng.Sun.COM> References: <4.2.0.58.20010204145255.01c90220@127.0.0.1> Message-ID: <4.2.0.58.20010204171344.01c63730@127.0.0.1> Yes but ./configure has a #! /bin/sh in it. ksh has -S but sh up to sunos 5.7 does not. I don't about any other of the sun system. I just edit ./configure to use bash my self to get around the problem on suns :) At 02:42 PM 2/4/01 -0800, Darren J Moffat wrote: >"William L. Jones" wrote: > > > > it looks like Sunos up to 5.7 does not have a -S test. > >5.5.1 is the first time that -S is documented in if(1) > >It existed in 5.1 which is when ksh first appeared. Note that -S exists >only in ksh not in sh. > >But /usr/bin/test will use ksh rather than sh. /usr/bin/test first >appeared in 5.5. > >-- >Darren J Moffat From mouring at etoh.eviladmin.org Mon Feb 5 14:23:07 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 4 Feb 2001 21:23:07 -0600 (CST) Subject: More clean up. In-Reply-To: Message-ID: I assume you don't have too much of a problem with this change? I ran accross it recently. --- ../openssh/auth-passwd.c Sun Jan 21 23:34:40 2001 +++ auth-passwd.c Sun Feb 4 21:18:29 2001 @@ -112,8 +112,7 @@ #ifndef HAVE_CYGWIN if (pw->pw_uid == 0 && options.permit_root_login == 2) return 0; -#endif -#ifdef HAVE_CYGWIN +#else /* * Empty password is only possible on NT if the user has _really_ * an empty password and authentication is done, though. From vinschen at redhat.com Mon Feb 5 18:46:17 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 5 Feb 2001 08:46:17 +0100 Subject: More clean up. In-Reply-To: ; from mouring@etoh.eviladmin.org on Sun, Feb 04, 2001 at 09:23:07PM -0600 References: Message-ID: <20010205084616.A15373@cygbert.vinschen.de> On Sun, Feb 04, 2001 at 09:23:07PM -0600, mouring at etoh.eviladmin.org wrote: > > I assume you don't have too much of a problem with this change? I ran > accross it recently. > > --- ../openssh/auth-passwd.c Sun Jan 21 23:34:40 2001 > +++ auth-passwd.c Sun Feb 4 21:18:29 2001 > @@ -112,8 +112,7 @@ > #ifndef HAVE_CYGWIN > if (pw->pw_uid == 0 && options.permit_root_login == 2) > return 0; > -#endif > -#ifdef HAVE_CYGWIN > +#else > /* > * Empty password is only possible on NT if the user has _really_ > * an empty password and authentication is done, though. The reason _not_ to use #else was that both parts of the code are not causal related. Both parts could change independent of the other so I assumed an #else as unsuitable. However, the patch wouldn't change the behaviour so you can decide it by yourself. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From roumen.petrov at skalasoft.com Mon Feb 5 19:58:33 2001 From: roumen.petrov at skalasoft.com (Roumen Petrov) Date: Mon, 05 Feb 2001 10:58:33 +0200 Subject: getline Message-ID: <3A7E6B39.4090202@skalasoft.com> Some system have getline method. Place rename 'getline' to 'Linebuf_getline' in ssh-keyscan.c ! From villapla at si.uji.es Mon Feb 5 19:59:04 2001 From: villapla at si.uji.es (Juan Jose Villaplana Querol) Date: Mon, 5 Feb 2001 09:59:04 +0100 (MET) Subject: sshd can't access user files Message-ID: Hi We have detected a problem in sshd when trying to access user files in order to authenticate a user via public key. In our system, each unix group has a separate home directory with 0750 permissions owned by root.group, therefore a user can access his home directory thanks to his group ownership. After installing OpenSSH 2.3.0p1 on this system we noticed that public key authentication only worked for root. After doing some debugging we noticed that "user_dsa_key_allowed" (in auth2.c) uses "temporarily_use_uid" to access files in the home directory of the target user, this means that sshd tries to access ~/.ssh/authorized_keys2 as target_user.system (on AIX), not as target_user.group as it should, as the home directory parent can't be accessed with efective group "system", pubkey authentication silently fails. It seems that setting also the effective group id will solve this problem. It also would be nice to log the failed attempt to access to ~/.ssh/authorized_keys2, because putting sshd in debug level 3 says nothing about te reason the user was not authenticated. Tanks for developing this great product. Best regards, Juanjo PS: Excuse my poor english. -- Juan Jose Villaplana Querol villapla at si.uji.es Computer Center University Jaume I Castellon (SPAIN) From bill at billsnet.com Tue Feb 6 00:58:00 2001 From: bill at billsnet.com (bill at billsnet.com) Date: Mon, 5 Feb 2001 08:58:00 -0500 (EST) Subject: I have an odd OpenSSH compatablity issue Message-ID: I am on Solaris 2.8 with openssh 2.3.0p1 and openssl 0.9.6. The remote machine is running ssh.com 1.2.20 and Solaris 2.6. I think the problem has to do with the 1.2.20 KeyRegeneration, because in the next hour I will beable to get into the machine ok with openssh and then later in the day I will not beable to ssh in again for another hour. ssh -v -v sa at myhost.com SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090600f). debug: Reading configuration data /home1/sa/.ssh/config debug: Applying options for * debug: Reading configuration data /opt/PSIssh/etc/ssh_config debug: Applying options for * debug: Command 'ls -alni /proc' timed out debug: Command 'ps -efl' timed out debug: Command 'ipcs -a' timed out debug: Seeded RNG with 38 bytes from programs debug: Seeded RNG with 3 bytes from system calls debug: ssh_connect: getuid 412 geteuid 412 anon 1 debug: Connecting to bulkstats.troy.psi.com [136.161.21.6] port 22. debug: Connection established. debug: Remote protocol version 1.5, remote software version 1.2.20 debug: no match: 1.2.20 debug: Local version string SSH-1.5-OpenSSH_2.3.0p1 debug: Waiting for server public key. Warning: Server lies about size of server public key: actual size is 895 bits vs. announced 896. Warning: This may be due to an old implementation of ssh. debug: Received server public key (895 bits) and host key (768 bits). debug: Host 'bulkstats.troy.psi.com' is known and matches the RSA host key. debug: Command 'ls -alni /proc' disabled (badness 2) debug: Command 'ps -efl' disabled (badness 2) debug: Command 'ipcs -a' disabled (badness 2) debug: Seeded RNG with 35 bytes from programs debug: Seeded RNG with 3 bytes from system calls respond_to_rsa_challenge: public_key 895 < host_key 768 + SSH_KEY_BITS_RESERVED 128 debug: Calling cleanup 0x3a08c(0x0) debug: Calling cleanup 0x3f4b0(0x0) debug: writing PRNG seed to file /home1/sa/.ssh/prng_seed From Markus.Friedl at informatik.uni-erlangen.de Tue Feb 6 01:04:21 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 5 Feb 2001 15:04:21 +0100 Subject: I have an odd OpenSSH compatablity issue In-Reply-To: ; from bill@billsnet.com on Mon, Feb 05, 2001 at 08:58:00AM -0500 References: Message-ID: <20010205150421.C29499@faui02.informatik.uni-erlangen.de> what is ServerKeyBits ? there should be at least 128 bits difference between the server and the hostkey. but i don't remember why. (perhaps because of RSAREF?). -markus On Mon, Feb 05, 2001 at 08:58:00AM -0500, bill at billsnet.com wrote: > > I am on Solaris 2.8 with openssh 2.3.0p1 and openssl 0.9.6. > The remote machine is running ssh.com 1.2.20 and Solaris 2.6. > > I think the problem has to do with the 1.2.20 KeyRegeneration, because in > the next hour I will beable to get into the machine ok with openssh and > then later in the day I will not beable to ssh in again for another hour. > > ssh -v -v sa at myhost.com > SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. > Compiled with SSL (0x0090600f). > debug: Reading configuration data /home1/sa/.ssh/config > debug: Applying options for * > debug: Reading configuration data /opt/PSIssh/etc/ssh_config > debug: Applying options for * > debug: Command 'ls -alni /proc' timed out > debug: Command 'ps -efl' timed out > debug: Command 'ipcs -a' timed out > debug: Seeded RNG with 38 bytes from programs > debug: Seeded RNG with 3 bytes from system calls > debug: ssh_connect: getuid 412 geteuid 412 anon 1 > debug: Connecting to bulkstats.troy.psi.com [136.161.21.6] port 22. > debug: Connection established. > debug: Remote protocol version 1.5, remote software version 1.2.20 > debug: no match: 1.2.20 > debug: Local version string SSH-1.5-OpenSSH_2.3.0p1 > debug: Waiting for server public key. > Warning: Server lies about size of server public key: actual size is 895 > bits vs. announced 896. > Warning: This may be due to an old implementation of ssh. > debug: Received server public key (895 bits) and host key (768 bits). > debug: Host 'bulkstats.troy.psi.com' is known and matches the RSA host > key. > debug: Command 'ls -alni /proc' disabled (badness 2) > debug: Command 'ps -efl' disabled (badness 2) > debug: Command 'ipcs -a' disabled (badness 2) > debug: Seeded RNG with 35 bytes from programs > debug: Seeded RNG with 3 bytes from system calls > respond_to_rsa_challenge: public_key 895 < host_key 768 + > SSH_KEY_BITS_RESERVED 128 > debug: Calling cleanup 0x3a08c(0x0) > debug: Calling cleanup 0x3f4b0(0x0) > debug: writing PRNG seed to file /home1/sa/.ssh/prng_seed > > > From william.wilson at NAU.EDU Tue Feb 6 02:52:00 2001 From: william.wilson at NAU.EDU (William Wilson) Date: Mon, 05 Feb 2001 08:52:00 -0700 Subject: Could not find working SSLeay? Message-ID: <4.1.20010205085152.00bd8180@jan.ucc.nau.edu> I'm installing openssl 0.9.5a and openssh 2.3.0p1 on an Ultra 5 running Solaris 8 with the latest cluster patch. Openssl installed without any problems. When I do a configure for openssh I get: Checking for OpenSSL directory. . . configure: error: Could not find working SSLeay / OpenSSL libraries, please install I've reinstalled openssl and everything is there. As a note I've installed this on a number of Solaris 2.6 machines without any problems. Any ideas? ************************************************************************** * William Wilson - Northern AZ Univ * william.wilson at nau.edu *** http://jan.ucc.nau.edu/~wew From mouring at etoh.eviladmin.org Tue Feb 6 05:35:15 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 5 Feb 2001 12:35:15 -0600 (CST) Subject: getline In-Reply-To: <3A7E6B39.4090202@skalasoft.com> Message-ID: On Mon, 5 Feb 2001, Roumen Petrov wrote: > Some system have getline method. > Place rename 'getline' to 'Linebuf_getline' in ssh-keyscan.c ! > > Rename 'getline' to 'Linebug_getline' for consistany and portablity. --- ../openssh/ssh-keyscan.c Mon Feb 5 11:54:56 2001 +++ ssh-keyscan.c Mon Feb 5 12:32:40 2001 @@ -146,7 +146,7 @@ } static inline char * -getline(Linebuf * lb) +Linebuf_getline(Linebuf * lb) { int n = 0; @@ -547,7 +547,7 @@ error("ignoring invalid/misplaced option `%s'", argv[argno++]); } else { char *line; - line = getline(lb); + line = Linebuf_getline(lb); if (line) return (line); Linebuf_free(lb); From tim at multitalents.net Tue Feb 6 04:45:53 2001 From: tim at multitalents.net (Tim Rice) Date: Mon, 5 Feb 2001 09:45:53 -0800 (PST) Subject: OpenSSH 2.4? In-Reply-To: Message-ID: > > Do we really need -L/usr/local/ssl ? > > It's not needed here. > > Does anyone know why it's there? > > > > Try this patch. I'm not sure why /usr/local/ssl. But I suspect it's to > detect a broken install that puts it's libraries in $ssldir instad of > $ssldir/lib. > > But there should be a better way then just putting both into the LDFLAGS. > > The patch works fine. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mouring at etoh.eviladmin.org Tue Feb 6 06:33:44 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 5 Feb 2001 13:33:44 -0600 (CST) Subject: Minor configure.in check Message-ID: It was brought up that on Solaris 2.7 that 'ar' may not be found when it steps into openbsd-compat/. I've not heard of this bug before but this is the following fix. Any particle reason for us not to commit this? - Ben --- ../openssh/configure.in Sat Feb 3 17:04:03 2001 +++ configure.in Mon Feb 5 13:24:41 2001 @@ -8,7 +8,7 @@ AC_PROG_CPP AC_PROG_RANLIB AC_PROG_INSTALL -AC_CHECK_PROG(AR, ar, ar) +AC_PATH_PROG(AR, ar) AC_PATH_PROG(PERL, perl) AC_SUBST(PERL) AC_PATH_PROG(ENT, ent) From ptw at callitrope.com Tue Feb 6 06:15:16 2001 From: ptw at callitrope.com (P T Withington) Date: Mon, 05 Feb 2001 14:15:16 -0500 Subject: OpenSSH 2.3.0 on OpenBSD 2.6? Message-ID: Is this possible? I have a machine that I cannot upgrade to later OpenBSD right away (but I have it, and I am a OpenBSD supporter), but I need to run latest OpenSSH. The patch file for OpenSSH 2.2.0 on OpenBSD 2.6 seems to have disappeared from ftp.openbsd.org. From acox at cv.telegroup.com Tue Feb 6 06:04:50 2001 From: acox at cv.telegroup.com (Aran Cox) Date: Mon, 5 Feb 2001 13:04:50 -0600 Subject: SCO Open Server 3 (SCO report) In-Reply-To: ; from tim@multitalents.net on Sat, Jan 27, 2001 at 12:31:24PM -0800 References: Message-ID: <20010205130450.D18567@benway.cv.telegroup.com> On Sat, Jan 27, 2001 at 12:31:24PM -0800, Tim Rice wrote: > On Fri, 26 Jan 2001 mouring at etoh.eviladmin.org wrote: > > If Aran is having problems and USE_PIPES fixes it, I say put it back in. I can't say for sure that USE_PIPES fixes my issues, but right now without USE_PIPES, I'm definately seeing some problems, mostly related to ssh just hanging there. I'm looking into it now... From william.wilson at NAU.EDU Tue Feb 6 10:04:27 2001 From: william.wilson at NAU.EDU (William Wilson) Date: Mon, 05 Feb 2001 16:04:27 -0700 Subject: Could not find working SSLeay? Message-ID: <4.1.20010205160421.00bf56c0@jan.ucc.nau.edu> I've done some more digging around and here's some output in the config.log ld: warning: file /nau/local/lib/libcrypto.a(rand_lib.o): wrong ELF class: ELFCLASS64 Undefined first referenced symbol in file RAND_add /var/tmp/ccdKC58n.o RAND_status /var/tmp/ccdKC58n.o ld: fatal: Symbol referencing errors. No output written to conftest collect2: ld returned 1 exit status configure: failed program was: #line 3200 "configure" We have done installs on a number of Solaris 2.6 machines without a hitch. When working on a couple of our Solaris 2.8 machines we get this error. At 05:16 PM 2/5/01 -0500, you wrote: >On Mon, 5 Feb 2001, William Wilson wrote: > >> I'm installing openssl 0.9.5a and openssh 2.3.0p1 on an Ultra 5 running >> Solaris 8 with the latest cluster patch. Openssl installed without any >> problems. When I do a configure for openssh I get: >> >> Checking for OpenSSL directory. . . configure: error: Could not find >> working SSLeay / >> OpenSSL libraries, please install > > >do you have /usr/local/lib in your LD path? > >-- > Blue Lang, Unix Voodoo Priest http://www.gator.net/~blue > 202 Ashe Ave, Apt 3, Raleigh, NC. 919 835 1540 > "A computer is a state machine. Threads are for people who can't program > state machines." - Alan Cox, From Larry McVoy's quote page > ************************************************************************** * William Wilson - Northern AZ Univ * william.wilson at nau.edu *** http://jan.ucc.nau.edu/~wew From mouring at etoh.eviladmin.org Tue Feb 6 11:49:40 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 5 Feb 2001 18:49:40 -0600 (CST) Subject: Could not find working SSLeay? In-Reply-To: <4.1.20010205160421.00bf56c0@jan.ucc.nau.edu> Message-ID: On Mon, 5 Feb 2001, William Wilson wrote: > I've done some more digging around and here's some output in the config.log > > ld: warning: file /nau/local/lib/libcrypto.a(rand_lib.o): wrong ELF class: > ELFCLASS64 > Undefined first referenced > symbol in file > RAND_add /var/tmp/ccdKC58n.o > RAND_status /var/tmp/ccdKC58n.o > ld: fatal: Symbol referencing errors. No output written to conftest > collect2: ld returned 1 exit status > configure: failed program was: > #line 3200 "configure" > > We have done installs on a number of Solaris 2.6 machines without a hitch. > When working on a couple of our Solaris 2.8 machines we get this error. > > > At 05:16 PM 2/5/01 -0500, you wrote: > >On Mon, 5 Feb 2001, William Wilson wrote: > > > >> I'm installing openssl 0.9.5a and openssh 2.3.0p1 on an Ultra 5 running > >> Solaris 8 with the latest cluster patch. Openssl installed without any > >> problems. When I do a configure for openssh I get: > >> > >> Checking for OpenSSL directory. . . configure: error: Could not find > >> working SSLeay / > >> OpenSSL libraries, please install > > > > > >do you have /usr/local/lib in your LD path? > > > >-- > > Blue Lang, Unix Voodoo Priest http://www.gator.net/~blue > > 202 Ashe Ave, Apt 3, Raleigh, NC. 919 835 1540 > > "A computer is a state machine. Threads are for people who can't program > > state machines." - Alan Cox, From Larry McVoy's quote page > > > > ************************************************************************** > * William Wilson - Northern AZ Univ > * william.wilson at nau.edu *** http://jan.ucc.nau.edu/~wew > > > From acox at cv.telegroup.com Tue Feb 6 11:13:21 2001 From: acox at cv.telegroup.com (Aran Cox) Date: Mon, 5 Feb 2001 18:13:21 -0600 Subject: SCO 5.0.5 (i686-pc-sco3.2v5.0.5), scp and the -n option Message-ID: <20010205181321.E18567@benway.cv.telegroup.com> Ok, using openssh-SNAP-20010126.tar.gz, two versions of the server both compiled with the configure commands as below, one with USE_PIPES defined and one without. This is on SCO OpenServer 5.0.5 (using SCO dev environment, SCO make, etc.) The client is always linux, openssh 2.3.0p1. export CCFLAGS='-L/usr/local/lib -I/usr/local/include' ./configure --sysconfdir=/etc/ssh --with-rsh=/usr/bin/rcmd \ --exec-prefix=/usr --without-egd-pool Host: i686-pc-sco3.2v5.0.5 I used two versions of a simple shell script to invoke ssh and scp repeatedly, the first does not specify the -n option to ssh, and second version uses -n on all the ssh invocations. The commands: ls -ld . ssh -V 'cat /etc/hosts|grep localhost' scp /etc/hosts root@$host:/tmp/hosts.foo /usr/bin/X11/xterm -sb -sl 1000 -T $host -e '/tmp/test-scr.sh' (The /tmp/test-scr.sh script just runs find /etc and sleeps for 2 seconds.) Now, on the machine without USE_PIPES (that is the unmodified snap 20010126) the non -n script runs just fine repeatedly... except that although execution of the script continues past the invocation of scp, scp doesn't exit, they just pile up on the client side. The sshd for scp doesn't exit either until you kill ssh on the client side. When the non -n script is run against a server with USE_PIPES, everything seems to run just fine, scp exits and leaves no residue. Now, if I run the -n version of the script, On the server without USE_PIPES, every command invoked hangs and the script won't continue executing unless you kill the corresponding sshd or ssh process. Sometimes it hangs before I get my input back, sometimes not. Strangely, I seem to only get input back from ssh -V, and not ls or the cat|grep command. scp does copy the file as expected. (scp behaves as above to this server) The xterm does appear, and close, but the sshd still hangs around along with the ssh. If I try the -n version of the script on the USE_PIPES server, everything works absolutely fine. Essentially I've reported these same type of problems in August, but now the command hangs instead of dying with a Disconnecting: Command terminated on signal 13. error message. (USE_PIPES fixed it for me then, too.) The real question (for me) here is in what circumstances do I need to use -n? I would swear that in the past, I have needed -n to keep shell scripts from hanging on invocations of rsh/rcmd. Now, I can't duplicate that to save me. (Either with rsh/rcmd or ssh.) It appears that I don't even need -n to get X applications to work correctly. If it weren't for the problems with scp hanging around I would just drop the -n and forget about USE_PIPE entirely, but -n ought to work. However, since I can't seem to find a concrete use for the option, that point may be moot. I would really like to see if anyone can duplicate this. Alternately you could just take my word for it and put USE_PIPES back into the configure.in script for *-*-sco3.2v5* ;) Aran From mouring at etoh.eviladmin.org Tue Feb 6 13:12:45 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 5 Feb 2001 20:12:45 -0600 (CST) Subject: SCO 5.0.5 (i686-pc-sco3.2v5.0.5), scp and the -n option In-Reply-To: <20010205181321.E18567@benway.cv.telegroup.com> Message-ID: On Mon, 5 Feb 2001, Aran Cox wrote: [..] > I would really like to see if anyone can duplicate this. Alternately you > could just take my word for it and put USE_PIPES back into the > configure.in script for *-*-sco3.2v5* ;) > USE_PIPES went back into sco3.2v5 on 1/28/2001. Please verify against the latest snapshot. - Ben From djm at mindrot.org Tue Feb 6 15:53:34 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 6 Feb 2001 15:53:34 +1100 (EST) Subject: sftp client Message-ID: As of Sunday evening, OpenSSH has an interactive sftp client. It should be in the more recent snapshots. It would be appreciated if you could test new client and find all the bugs :) Please also have a read of the manpage and ensure that it matches what is implemented. I am working on fixing the ones that I know about, so please try to stay up to date with the snapshots. Thanks, 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 josb at cncdsl.com Tue Feb 6 16:25:04 2001 From: josb at cncdsl.com (Jos Backus) Date: Mon, 5 Feb 2001 21:25:04 -0800 Subject: sftp client In-Reply-To: ; from djm@mindrot.org on Tue, Feb 06, 2001 at 03:53:12PM +1100 References: Message-ID: <20010205212504.A52414@lizzy.bugworks.com> On Tue, Feb 06, 2001 at 03:53:12PM +1100, Damien Miller wrote: > As of Sunday evening, OpenSSH has an interactive sftp client. It should > be in the more recent snapshots. That's great Damien! Now, how hard would it be to turn this into a non-interactive client? This would yield the functionality of scp without having to grant shell access. Thanks, -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From djm at mindrot.org Tue Feb 6 16:40:45 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 6 Feb 2001 16:40:45 +1100 (EST) Subject: sftp client In-Reply-To: <20010205212504.A52414@lizzy.bugworks.com> Message-ID: On Mon, 5 Feb 2001, Jos Backus wrote: > That's great Damien! > > Now, how hard would it be to turn this into a non-interactive client? This > would yield the functionality of scp without having to grant shell access. There is a quick and dirty way you can do this now, it probably wouldn't be too much work to make this into a real commandline mode: echo -e "ls\nget /tmp/somefile /tmp/localfile" | sftp user at host -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 josb at cncdsl.com Tue Feb 6 16:54:11 2001 From: josb at cncdsl.com (Jos Backus) Date: Mon, 5 Feb 2001 21:54:11 -0800 Subject: sftp client In-Reply-To: ; from djm@mindrot.org on Tue, Feb 06, 2001 at 04:40:23PM +1100 References: <20010205212504.A52414@lizzy.bugworks.com> Message-ID: <20010205215411.B52414@lizzy.bugworks.com> On Tue, Feb 06, 2001 at 04:40:23PM +1100, Damien Miller wrote: > There is a quick and dirty way you can do this now, it probably > wouldn't be too much work to make this into a real commandline mode: I see, just like regular ftp. I'll definitely fiddle with this (I work on a project at work which could easily take advantage of this mechanism) when the next release arrives. Thanks again, -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From devon at admin2.gisnetworks.com Tue Feb 6 17:02:37 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Mon, 5 Feb 2001 22:02:37 -0800 Subject: sftp client References: <20010205212504.A52414@lizzy.bugworks.com> <20010205215411.B52414@lizzy.bugworks.com> Message-ID: <01d101c09002$6833e660$1900a8c0@devn> shouldn't be too hard to write a perl or shell script to do this sort of thing... devon ----- Original Message ----- From: "Jos Backus" To: Sent: Monday, February 05, 2001 9:54 PM Subject: Re: sftp client > On Tue, Feb 06, 2001 at 04:40:23PM +1100, Damien Miller wrote: > > There is a quick and dirty way you can do this now, it probably > > wouldn't be too much work to make this into a real commandline mode: > > I see, just like regular ftp. I'll definitely fiddle with this (I work on a > project at work which could easily take advantage of this mechanism) when the > next release arrives. > > Thanks again, > -- > Jos Backus _/ _/_/_/ "Modularity is not a hack." > _/ _/ _/ -- D. J. Bernstein > _/ _/_/_/ > _/ _/ _/ _/ > josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; > > From katzj at linuxpower.org Tue Feb 6 18:35:50 2001 From: katzj at linuxpower.org (Jeremy Katz) Date: Mon, 5 Feb 2001 23:35:50 -0800 Subject: sftp client In-Reply-To: ; from djm@mindrot.org on Tue, Feb 06, 2001 at 03:53:34PM +1100 References: Message-ID: <20010205233550.U21495@kotako.analogself.com> On Tuesday, February 06 2001, Damien Miller said: > As of Sunday evening, OpenSSH has an interactive sftp client. It should > be in the more recent snapshots. Yay! One more nail in the coffin of insecure protocols :) > It would be appreciated if you could test new client and find all the > bugs :) Please also have a read of the manpage and ensure that it > matches what is implemented. Unfortunately, hitting some bugs with current CVS against sftp-server from the same CVS checkout. If you try to change to a non-existent directory, your next command always leads to a "xfree: NULL pointer given as argument" and sftp exiting Trying to GET any files gives me "Couldn't close file: No Such File" Versus the sftp-server in 2.3.0p1, the client just fails horribly, hanging at the end of an ls, and showing the same symptoms as against the current CVS sftp-server for a get. Not sure if that's expected or not :) 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 -------------- 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/20010205/89dd0087/attachment.bin From djm at mindrot.org Tue Feb 6 20:17:24 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 6 Feb 2001 20:17:24 +1100 (EST) Subject: sftp client In-Reply-To: <20010205233550.U21495@kotako.analogself.com> Message-ID: On Mon, 5 Feb 2001, Jeremy Katz wrote: > Unfortunately, hitting some bugs with current CVS against sftp-server > from the same CVS checkout. > > If you try to change to a non-existent directory, your next command > always leads to a "xfree: NULL pointer given as argument" and sftp > exiting This is a known problem, it will be fixed shortly. > Trying to GET any files gives me "Couldn't close file: No Such File" Is this after a bad chdir? > Versus the sftp-server in 2.3.0p1, the client just fails horribly, > hanging at the end of an ls, and showing the same symptoms as against > the current CVS sftp-server for a get. Not sure if that's expected or > not :) Can you turn on verbose debugging? "sftp -v -v -v" -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 vinschen at redhat.com Tue Feb 6 21:21:24 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 6 Feb 2001 11:21:24 +0100 Subject: sftp client In-Reply-To: ; from djm@mindrot.org on Tue, Feb 06, 2001 at 08:17:24PM +1100 References: <20010205233550.U21495@kotako.analogself.com> Message-ID: <20010206112124.L15821@cygbert.vinschen.de> On Tue, Feb 06, 2001 at 08:17:24PM +1100, Damien Miller wrote: > On Mon, 5 Feb 2001, Jeremy Katz wrote: > > > Unfortunately, hitting some bugs with current CVS against sftp-server > > from the same CVS checkout. > > > > If you try to change to a non-existent directory, your next command > > always leads to a "xfree: NULL pointer given as argument" and sftp > > exiting > > This is a known problem, it will be fixed shortly. > > > Trying to GET any files gives me "Couldn't close file: No Such File" > > Is this after a bad chdir? No. This also happens immediately: /src/openssh/bin[2]$ ./sftp localhost Connecting to localhost... sftp> get x.c Couldn't close file: No Such File However, the file is successfully copied. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From vinschen at redhat.com Tue Feb 6 21:28:26 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 6 Feb 2001 11:28:26 +0100 Subject: sftp client In-Reply-To: ; from djm@mindrot.org on Tue, Feb 06, 2001 at 08:17:24PM +1100 References: <20010205233550.U21495@kotako.analogself.com> Message-ID: <20010206112826.M15821@cygbert.vinschen.de> On Tue, Feb 06, 2001 at 08:17:24PM +1100, Damien Miller wrote: > Can you turn on verbose debugging? "sftp -v -v -v" I just did this to get debug output related to the "No such file" problem. I have cleaned out the `channel 0' messages: Sent message SSH2_FXP_OPEN I:-1546759979 P:/home/corinna/x.c debug: Sent message SSH2_FXP_READ I:-1546759978 O:0 S:8192 debug: Received reply T:103 I:-1546759978 debug: In read loop, got 1270 offset 0 Sent message SSH2_FXP_READ I:-1546759977 O:1270 S:8192 debug: Received reply T:101 I:-1546759977 debug: Sent message SSH2_FXP_CLOSE I:621892334 debug: SSH2_FXP_STATUS 2 Couldn't close file: No Such File You see that in the SSH2_FXP_CLOSE message suddenly the id changes? Hope, that helps, Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From Lutz.Jaenicke at aet.TU-Cottbus.DE Tue Feb 6 21:33:50 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 6 Feb 2001 11:33:50 +0100 Subject: sftp client In-Reply-To: ; from djm@mindrot.org on Tue, Feb 06, 2001 at 03:53:34PM +1100 References: Message-ID: <20010206113350.A26560@ws01.aet.tu-cottbus.de> On Tue, Feb 06, 2001 at 03:53:34PM +1100, Damien Miller wrote: > As of Sunday evening, OpenSSH has an interactive sftp client. It should > be in the more recent snapshots. > > It would be appreciated if you could test new client and find all the > bugs :) Please also have a read of the manpage and ensure that it > matches what is implemented. Hmm, I just wanted to download the snapshot, but on bass.directhit.com I am only asked for username/password authenication for "c1hvd"... 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 vinschen at redhat.com Tue Feb 6 21:46:16 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 6 Feb 2001 11:46:16 +0100 Subject: sftp client In-Reply-To: <20010206112124.L15821@cygbert.vinschen.de>; from vinschen@redhat.com on Tue, Feb 06, 2001 at 11:21:24AM +0100 References: <20010205233550.U21495@kotako.analogself.com> <20010206112124.L15821@cygbert.vinschen.de> Message-ID: <20010206114616.N15821@cygbert.vinschen.de> On Tue, Feb 06, 2001 at 11:21:24AM +0100, Corinna Vinschen wrote: > > > Trying to GET any files gives me "Couldn't close file: No Such File" > > > > Is this after a bad chdir? > > No. This also happens immediately: > > /src/openssh/bin[2]$ ./sftp localhost > Connecting to localhost... > sftp> get x.c > Couldn't close file: No Such File > > However, the file is successfully copied. Found the reason: in `do_download' and `do_upload', handle and msg are given up before do_close is called. Patch attached. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com -------------- next part -------------- Index: sftp-client.c =================================================================== RCS file: /cvs/openssh_cvs/sftp-client.c,v retrieving revision 1.3 diff -u -p -r1.3 sftp-client.c --- sftp-client.c 2001/02/05 15:39:22 1.3 +++ sftp-client.c 2001/02/06 10:44:32 @@ -553,6 +553,7 @@ do_download(int fd_in, int fd_out, char char *handle; Buffer msg; Attrib junk, *a; + int ret; a = do_stat(fd_in, fd_out, remote_path); if (a == NULL) @@ -672,11 +673,12 @@ do_download(int fd_in, int fd_out, char offset += len; xfree(data); } - xfree(handle); - buffer_free(&msg); close(local_fd); - return(do_close(fd_in, fd_out, handle, handle_len)); + ret = do_close(fd_in, fd_out, handle, handle_len); + xfree(handle); + buffer_free(&msg); + return ret; } int @@ -690,6 +692,7 @@ do_upload(int fd_in, int fd_out, char *l Buffer msg; struct stat sb; Attrib a; + int ret; if ((local_fd = open(local_path, O_RDONLY, 0)) == -1) { error("Couldn't open local file \"%s\" for reading: %s", @@ -780,8 +783,6 @@ do_upload(int fd_in, int fd_out, char *l offset += len; } - xfree(handle); - buffer_free(&msg); if (close(local_fd) == -1) { error("Couldn't close local file \"%s\": %s", local_path, @@ -790,5 +791,8 @@ do_upload(int fd_in, int fd_out, char *l return(-1); } - return(do_close(fd_in, fd_out, handle, handle_len)); + ret = do_close(fd_in, fd_out, handle, handle_len); + xfree(handle); + buffer_free(&msg); + return ret; } From vinschen at redhat.com Tue Feb 6 22:58:42 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 6 Feb 2001 12:58:42 +0100 Subject: sftp client In-Reply-To: ; from djm@mindrot.org on Tue, Feb 06, 2001 at 03:53:34PM +1100 References: Message-ID: <20010206125842.P15821@cygbert.vinschen.de> On Tue, Feb 06, 2001 at 03:53:34PM +1100, Damien Miller wrote: > As of Sunday evening, OpenSSH has an interactive sftp client. It should > be in the more recent snapshots. > > It would be appreciated if you could test new client and find all the > bugs :) Please also have a read of the manpage and ensure that it > matches what is implemented. > > I am working on fixing the ones that I know about, so please try to > stay up to date with the snapshots. Just hit another problem. When connecting with openssh-sftp to the sftp-server the sftp-server process remains in memory after exiting the client, waiting for input. sftp-server on i686-pc-cygwin, sftp-client on i686-pc-cygwin and i686-pc-linux-gnu The same does not happen when using the ssh.com sftp client. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From roumen.petrov at skalasoft.com Tue Feb 6 23:11:24 2001 From: roumen.petrov at skalasoft.com (Roumen Petrov) Date: Tue, 06 Feb 2001 14:11:24 +0200 Subject: sftp client References: <20010206113350.A26560@ws01.aet.tu-cottbus.de> Message-ID: <3A7FE9EC.5060809@skalasoft.com> Lutz Jaenicke wrote: > Hmm, I just wanted to download the snapshot, but on > bass.directhit.com > I am only asked for username/password authenication for "c1hvd"... > hmm !?!?!, --------------------------------- #!/bin/sh cd `dirname $0` pwd cvs -d :pserver:cvs at bass.directhit.com:/cvs login cvs -d :pserver:cvs at bass.directhit.com:/cvs co openssh_cvs cvs -d :pserver:cvs at bass.directhit.com:/cvs logout --------------------------------- just pres enter for password From Lutz.Jaenicke at aet.TU-Cottbus.DE Tue Feb 6 23:55:16 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 6 Feb 2001 13:55:16 +0100 Subject: sftp client In-Reply-To: <3A7FE9EC.5060809@skalasoft.com>; from roumen.petrov@skalasoft.com on Tue, Feb 06, 2001 at 02:11:24PM +0200 References: <20010206113350.A26560@ws01.aet.tu-cottbus.de> <3A7FE9EC.5060809@skalasoft.com> Message-ID: <20010206135516.A27305@ws01.aet.tu-cottbus.de> On Tue, Feb 06, 2001 at 02:11:24PM +0200, Roumen Petrov wrote: > Lutz Jaenicke wrote: > > > > Hmm, I just wanted to download the snapshot, but on > > bass.directhit.com > > I am only asked for username/password authenication for "c1hvd"... > > > > hmm !?!?!, > --------------------------------- > > #!/bin/sh > > cd `dirname $0` > pwd > > cvs -d :pserver:cvs at bass.directhit.com:/cvs login > cvs -d :pserver:cvs at bass.directhit.com:/cvs co openssh_cvs > cvs -d :pserver:cvs at bass.directhit.com:/cvs logout > --------------------------------- > just pres enter for password http://bass.directhit.com/openssh_snap/ Authorization box opens up and asks for username/password... Some days ago it did work. Authorization Required This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required. Apache/1.3.14 Server at c1hvd.directhit.com Port 80 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 roumen.petrov at skalasoft.com Wed Feb 7 00:24:31 2001 From: roumen.petrov at skalasoft.com (Roumen Petrov) Date: Tue, 06 Feb 2001 15:24:31 +0200 Subject: sftp client References: <20010206125842.P15821@cygbert.vinschen.de> Message-ID: <3A7FFB0F.4030608@skalasoft.com> Corinna Vinschen wrote: > On Tue, Feb 06, 2001 at 03:53:34PM +1100, Damien Miller wrote: ..... > Just hit another problem. When connecting with openssh-sftp to > the sftp-server the sftp-server process remains in memory after > exiting the client, waiting for input. .... slack linux after 'sftp localhost': #ps axf ...... 113 ? S 0:00 /usr/sbin/sshd 267 ? S 0:00 \_ /usr/sbin/sshd 271 ? S 0:00 \_ /usr/libexec/sftp-server ...... after exit/quit is sftp client: #ps axf ...... 113 ? S 0:00 /usr/sbin/sshd ..... No child process ( no sftp-server as process ). What is '... the sftp-server process remains in memory after ...' ? Is this like 'ps command show sftp-server as process' ? From Jarno.Huuskonen at uku.fi Wed Feb 7 01:00:31 2001 From: Jarno.Huuskonen at uku.fi (Jarno Huuskonen) Date: Tue, 6 Feb 2001 16:00:31 +0200 Subject: sftp client In-Reply-To: <20010206135516.A27305@ws01.aet.tu-cottbus.de>; from Lutz.Jaenicke@aet.TU-Cottbus.DE on Tue, Feb 06, 2001 at 01:55:16PM +0100 References: <20010206113350.A26560@ws01.aet.tu-cottbus.de> <3A7FE9EC.5060809@skalasoft.com> <20010206135516.A27305@ws01.aet.tu-cottbus.de> Message-ID: <20010206160031.A47358@messi.uku.fi> On Tue, Feb 06, Lutz Jaenicke wrote: > http://bass.directhit.com/openssh_snap/ > > Authorization box opens up and asks for username/password... > Some days ago it did work. > > Authorization Required > > This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply > the credentials required. I had the same problem with http during the weekend. cvs worked just fine ... -Jarno -- Jarno Huuskonen - System Administrator | Jarno.Huuskonen at uku.fi University of Kuopio - Computer Center | Work: +358 17 162822 PO BOX 1627, 70211 Kuopio, Finland | Mobile: +358 40 5388169 From vinschen at redhat.com Wed Feb 7 01:09:51 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 6 Feb 2001 15:09:51 +0100 Subject: sftp client In-Reply-To: <3A7FFB0F.4030608@skalasoft.com>; from roumen.petrov@skalasoft.com on Tue, Feb 06, 2001 at 03:24:31PM +0200 References: <20010206125842.P15821@cygbert.vinschen.de> <3A7FFB0F.4030608@skalasoft.com> Message-ID: <20010206150951.T15821@cygbert.vinschen.de> On Tue, Feb 06, 2001 at 03:24:31PM +0200, Roumen Petrov wrote: > Corinna Vinschen wrote: > > > On Tue, Feb 06, 2001 at 03:53:34PM +1100, Damien Miller wrote: > ..... > > Just hit another problem. When connecting with openssh-sftp to > > the sftp-server the sftp-server process remains in memory after > > exiting the client, waiting for input. > What is '... the sftp-server process remains in memory after ...' ? > Is this like 'ps command show sftp-server as process' ? Yep. As I mentioned before, this doesn't happen when connecting with ssh.com's sftp client. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From roumen.petrov at skalasoft.com Wed Feb 7 02:17:06 2001 From: roumen.petrov at skalasoft.com (Roumen Petrov) Date: Tue, 06 Feb 2001 17:17:06 +0200 Subject: sftp client References: <20010206113350.A26560@ws01.aet.tu-cottbus.de> <3A7FE9EC.5060809@skalasoft.com> Message-ID: <3A801572.80004@skalasoft.com> sftp as non root user -> Received message too long 1752132965 and part of log is: ----------------------------------------- ................. 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: Sending subsystem: sftp debug: clientloop_set_session_ident: id 0 debug: callback done debug: channel 0: open confirm rwindow 0 rmax 16384 debug: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 ...... debug: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug: channel 0: rcvd adjust 32768 debug: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 ...... debug: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 Received message too long 1752132965 debug: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug: channel 0: read<=0 rfd 4 len 0 debug: channel 0: read failed debug: channel 0: input open -> drain debug: channel 0: close_read debug: channel 0: input: no drain shortcut debug: channel 0: ibuf empty debug: channel 0: input drain -> closed debug: channel 0: send eof debug: channel 0: chan_delete_if_full_closed2: istate 8 ostate 16 ...... debug: channel 0: chan_delete_if_full_closed2: istate 8 ostate 16 debug: channel 0: write failed debug: channel 0: output open -> closed debug: channel 0: close_write debug: channel 0: chan_delete_if_full_closed2: istate 8 ostate 128 debug: channel 0: send close debug: channel 0: chan_delete_if_full_closed2: istate 8 ostate 128 ...... debug: channel 0: chan_delete_if_full_closed2: istate 8 ostate 128 debug: channel 0: rcvd close debug: channel 0: chan_delete_if_full_closed2: istate 8 ostate 128 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) ...................... From william.wilson at NAU.EDU Wed Feb 7 03:39:42 2001 From: william.wilson at NAU.EDU (William Wilson) Date: Tue, 06 Feb 2001 09:39:42 -0700 Subject: Could not find working SSLeay? Message-ID: <4.1.20010206093924.00bbf100@jan.ucc.nau.edu> OK. Came to a resolution. Under Solaris 8 and using the new Forte 6 compilers you need to make sure to use the solaris-sparcv9-gcc configure option when setting up openssl. This produces libraries that will work with openssh so that the configure will complete for openssh. At 03:48 PM 2/5/01 -0700, you wrote: >I've done some more digging around and here's some output in the config.log > >ld: warning: file /nau/local/lib/libcrypto.a(rand_lib.o): wrong ELF class: >ELFCLASS64 >Undefined first referenced > symbol in file >RAND_add /var/tmp/ccdKC58n.o >RAND_status /var/tmp/ccdKC58n.o >ld: fatal: Symbol referencing errors. No output written to conftest >collect2: ld returned 1 exit status >configure: failed program was: >#line 3200 "configure" > >We have done installs on a number of Solaris 2.6 machines without a hitch. >When working on a couple of our Solaris 2.8 machines we get this error. > > >At 05:16 PM 2/5/01 -0500, you wrote: >>On Mon, 5 Feb 2001, William Wilson wrote: >> >>> I'm installing openssl 0.9.5a and openssh 2.3.0p1 on an Ultra 5 running >>> Solaris 8 with the latest cluster patch. Openssl installed without any >>> problems. When I do a configure for openssh I get: >>> >>> Checking for OpenSSL directory. . . configure: error: Could not find >>> working SSLeay / >>> OpenSSL libraries, please install >> >> >>do you have /usr/local/lib in your LD path? >> >>-- >> Blue Lang, Unix Voodoo Priest http://www.gator.net/~blue >> 202 Ashe Ave, Apt 3, Raleigh, NC. 919 835 1540 >> "A computer is a state machine. Threads are for people who can't program >> state machines." - Alan Cox, From Larry McVoy's quote page >> > >************************************************************************** >* William Wilson - Northern AZ Univ >* william.wilson at nau.edu *** http://jan.ucc.nau.edu/~wew > > ************************************************************************** * William Wilson - Northern AZ Univ * william.wilson at nau.edu *** http://jan.ucc.nau.edu/~wew From mouring at etoh.eviladmin.org Wed Feb 7 06:19:53 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 6 Feb 2001 13:19:53 -0600 (CST) Subject: RNG not initialised for sftp only under Solaris. Message-ID: Out of the box on Solaris 2.7 using the internal entropy system. I am able to login but as soon as I get past the password prompt it dies because it claims the RNG is not initialised. Transcript: [..] debug: got SSH2_MSG_SERVICE_ACCEPT You have entered the land of dragons and mystical creatures. This server does not exist. debug: authentications that can continue: publickey,keyboard-interactive,password debug: next auth method to try is publickey debug: key does not exist: /home/lindstro/.ssh/id_dsa debug: next auth method to try is keyboard-interactive Password: debug: ssh-userauth2 successful: method keyboard-interactive debug: fd 6 setting O_NONBLOCK debug: fd 7 IS O_NONBLOCK debug: channel 0: new [client-session] debug: send channel open 0 debug: Entering interactive session. debug: client_init id 0 arg 0 debug: Sending subsystem: sftp debug: channel 0: open confirm rwindow 0 rmax 16384 RNG not initialised [..] The solution is to add 'init_prng();' to the main() of sftp.c. Why sftp is caring about such things boggles my mind. =) Scp sure does not nor does sftp-server, and it was my impression (by glacing at the code) that sftp.c pretty much piggy backing ontop of ssh like scp. Looks to be somewhere in the interactive_loop() code. - Ben From mouring at etoh.eviladmin.org Wed Feb 7 06:23:08 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 6 Feb 2001 13:23:08 -0600 (CST) Subject: RNG not initialised for sftp only under Solaris. In-Reply-To: Message-ID: Ahh.. a moment of truth. the init_rng(); does being in sftp.c due to: sftp-client.c: id = arc4random(); sftp-client.c: id = arc4random(); sftp-client.c: id = arc4random(); sftp-client.c: id = arc4random(); sftp-client.c: id = arc4random(); sftp-client.c: id = arc4random(); sftp-client.c: id = arc4random(); sftp-client.c: id = arc4random(); sftp-client.c: id = arc4random(); sftp-client.c: id = arc4random(); sftp-client.c: expected_id = id = arc4random(); sftp-client.c: id = arc4random(); sftp-client.c: id = arc4random(); sftp-client.c: id = arc4random(); Ok.. This makes much more sense.=) - Ben On Tue, 6 Feb 2001 mouring at etoh.eviladmin.org wrote: > > Out of the box on Solaris 2.7 using the internal entropy system. I am > able to login but as soon as I get past the password prompt it dies > because it claims the RNG is not initialised. > > Transcript: > [..] > debug: got SSH2_MSG_SERVICE_ACCEPT > You have entered the land of dragons and mystical creatures. This server > does not exist. > debug: authentications that can continue: publickey,keyboard-interactive,password > debug: next auth method to try is publickey > debug: key does not exist: /home/lindstro/.ssh/id_dsa > debug: next auth method to try is keyboard-interactive > Password: > debug: ssh-userauth2 successful: method keyboard-interactive > debug: fd 6 setting O_NONBLOCK > debug: fd 7 IS O_NONBLOCK > debug: channel 0: new [client-session] > debug: send channel open 0 > debug: Entering interactive session. > debug: client_init id 0 arg 0 > debug: Sending subsystem: sftp > debug: channel 0: open confirm rwindow 0 rmax 16384 > RNG not initialised > [..] > > The solution is to add 'init_prng();' to the main() of sftp.c. > > Why sftp is caring about such things boggles my mind. =) Scp sure does > not nor does sftp-server, and it was my impression (by glacing at the > code) that sftp.c pretty much piggy backing ontop of ssh like scp. > > > Looks to be somewhere in the interactive_loop() code. > > - Ben > > From pekkas at netcore.fi Wed Feb 7 05:46:43 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 6 Feb 2001 20:46:43 +0200 (EET) Subject: sftp client In-Reply-To: Message-ID: On Tue, 6 Feb 2001, Damien Miller wrote: Minor manpage error: --- sftp.1~ Sun Feb 4 14:20:19 2001 +++ sftp.1 Tue Feb 6 20:44:41 2001 @@ -60,8 +60,8 @@ .Xr ssh 1 . .El .Sh INTERACTIVE COMMANDS -Once in interactive mode -.Nm , +Once in interactive mode, +.Nm understands a set of commands similar to those of .Xr ftp 1 . Commands are case insensitive. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From rob at hagopian.net Wed Feb 7 06:28:44 2001 From: rob at hagopian.net (Rob Hagopian) Date: Tue, 6 Feb 2001 14:28:44 -0500 (EST) Subject: sftp client In-Reply-To: <20010206113350.A26560@ws01.aet.tu-cottbus.de> Message-ID: Yep, my fault (I was protecting other pages on the site), it should be all fixed now! -Rob On Tue, 6 Feb 2001, Lutz Jaenicke wrote: > On Tue, Feb 06, 2001 at 03:53:34PM +1100, Damien Miller wrote: > > As of Sunday evening, OpenSSH has an interactive sftp client. It should > > be in the more recent snapshots. > > > > It would be appreciated if you could test new client and find all the > > bugs :) Please also have a read of the manpage and ensure that it > > matches what is implemented. > > Hmm, I just wanted to download the snapshot, but on > bass.directhit.com > I am only asked for username/password authenication for "c1hvd"... > > Best regards, > lutz > From josb at cncdsl.com Wed Feb 7 07:17:40 2001 From: josb at cncdsl.com (Jos Backus) Date: Tue, 6 Feb 2001 12:17:40 -0800 Subject: argv[0] => host feature considered harmful Message-ID: <20010206121740.B59281@lizzy.bugworks.com> OpenSSH still has this feature, SSH-1.2.27 no longer has it. Admittedly it can be useful sometimes, even though I'd prefer this to be done using a trivial shell wrapper, which would be the UNIX way of doing things. Not being able to call OpenSSH's ssh by another name (say ``ssh1'') can get in the way when having to maintain two versions of ssh in parallel because the ``ssh -> ssh1'' symlink trick doesn't work (ssh gives a ``bad hostname: ssh1'' error message). How do others feel about at least conditionalizing this feature? I can come up with a patch if needed. Thanks, -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From djm at mindrot.org Wed Feb 7 08:12:10 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 7 Feb 2001 08:12:10 +1100 (EST) Subject: sftp client In-Reply-To: <20010206113350.A26560@ws01.aet.tu-cottbus.de> Message-ID: On Tue, 6 Feb 2001, Lutz Jaenicke wrote: > On Tue, Feb 06, 2001 at 03:53:34PM +1100, Damien Miller wrote: > > As of Sunday evening, OpenSSH has an interactive sftp client. It should > > be in the more recent snapshots. > > > > It would be appreciated if you could test new client and find all the > > bugs :) Please also have a read of the manpage and ensure that it > > matches what is implemented. > > Hmm, I just wanted to download the snapshot, but on > bass.directhit.com > I am only asked for username/password authenication for "c1hvd"... It should be fixed now. -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 Feb 7 08:13:30 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 7 Feb 2001 08:13:30 +1100 (EST) Subject: sftp client In-Reply-To: <3A801572.80004@skalasoft.com> Message-ID: On Tue, 6 Feb 2001, Roumen Petrov wrote: > sftp as non root user -> Received message too long 1752132965 > and part of log is: > ----------------------------------------- > ................. > 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: Sending subsystem: sftp > debug: clientloop_set_session_ident: id 0 > debug: callback done > debug: channel 0: open confirm rwindow 0 rmax 16384 > debug: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 > ...... > debug: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 > debug: channel 0: rcvd adjust 32768 > debug: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 > ...... > debug: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 What does "ssh user at yourhost /bin/true" say? Do you have anything being printed in your .bashrc? -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 dpo at club-internet.fr Wed Feb 7 08:33:41 2001 From: dpo at club-internet.fr (Dimitri Papadopoulos) Date: Tue, 06 Feb 2001 22:33:41 +0100 Subject: OpenSSH 2.3.0p1: bla bla Message-ID: <3A806DB5.6DE562FE@club-internet.fr> Hi, I get the following SSH error message while trying to access an HTTP server tunnelled through SSH 2: channel_open_failure: 5: reason 1: bla bla I see the code is in serverloop.c and looks like packet_put_int(SSH2_OPEN_ADMINISTRATIVELY_PROHIBITED); packet_put_cstring("bla bla"); which seems to indicate the server is badly configurated. However I think a more informative message would be more appropriate... Thanks, Dimitri From jmknoble at jmknoble.cx Wed Feb 7 08:35:09 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Tue, 6 Feb 2001 16:35:09 -0500 Subject: argv[0] => host feature considered harmful In-Reply-To: <20010206121740.B59281@lizzy.bugworks.com>; from josb@cncdsl.com on Tue, Feb 06, 2001 at 12:17:40PM -0800 References: <20010206121740.B59281@lizzy.bugworks.com> Message-ID: <20010206163509.B3981@shell.ntrnet.net> 2001-Feb-06 12:17:40 -0800 dixit Jos Backus: : OpenSSH still has this feature, SSH-1.2.27 no longer has it. : Admittedly it can be useful sometimes, even though I'd prefer this : to be done using a trivial shell wrapper, which would be the UNIX : way of doing things. : : Not being able to call OpenSSH's ssh by another name (say ``ssh1'') : can get in the way when having to maintain two versions of ssh in : parallel because the ``ssh -> ssh1'' symlink trick doesn't work (ssh : gives a ``bad hostname: ssh1'' error message). : : How do others feel about at least conditionalizing this feature? I : can come up with a patch if needed. I have no opinion about the hostname => "ssh hostname" feature, but the attached patch is one that i use when i build OpenSSH. It does the following: (1) Enables both ssh and scp to be called as 'ssh1' or 'ssh2' (or 'scp1' or 'scp2') and force the corresponding protocol version. (2) Implements a '-1' option for both ssh and scp (as well as '-2' for scp) for symmetry with the '-2' option of ssh. (Yes, i'm aware there's been discussion about this before, but i implemented it for my own use, so i don't care whether anyone likes it. :) (3) Documents the new options in [2] above. The patch is against OpenSSH-2.3.0p1. Go wild. -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ -------------- next part -------------- --- ./scp.c.orig-protoargs Fri Oct 27 23:19:58 2000 +++ ./scp.c Tue Jan 9 15:38:13 2001 @@ -248,16 +248,46 @@ char *targ; extern char *optarg; extern int optind; + char *cp; + int protoflag = 0; args.list = NULL; addargs("ssh"); /* overwritten with ssh_program */ addargs("-x"); addargs("-oFallBackToRsh no"); + cp = strchr(argv[0], '/'); + if (NULL == cp) + cp = argv[0]; +#ifdef HAVE_CYGWIN + if (!strcasecmp(cp, "scp1") || !strcasecmp(cp, "scp1.exe")) +#else + if (!strcmp(cp, "scp1")) +#endif + { + protoflag = 1; + addargs("-oProtocol %c", '1'); + } +#ifdef HAVE_CYGWIN + else if (!strcasecmp(cp, "scp2") || !strcasecmp(cp, "scp2.exe")) +#else + else if (!strcmp(cp, "scp2")) +#endif + { + protoflag = 2; + addargs("-oProtocol %c", '2'); + } + fflag = tflag = 0; - while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q46S:o:")) != EOF) + while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q1246S:o:")) != EOF) switch (ch) { /* User-visible flags. */ + case '1': + case '2': + if (!protoflag) { + addargs("-oProtocol %c", ch); + } + break; case '4': case '6': case 'C': @@ -961,7 +991,7 @@ usage() { (void) fprintf(stderr, "usage: scp " - "[-pqrvC46] [-S ssh] [-P port] [-c cipher] [-i identity] f1 f2; or:\n" + "[-pqrvC1246] [-S ssh] [-P port] [-c cipher] [-i identity] f1 f2; or:\n" " scp [options] f1 ... fn directory\n"); exit(1); } --- ./ssh.c.orig-protoargs Fri Oct 27 23:19:58 2000 +++ ./ssh.c Tue Jan 9 15:38:27 2001 @@ -173,9 +173,10 @@ fprintf(stderr, " -C Enable compression.\n"); fprintf(stderr, " -N Do not execute a shell or command.\n"); fprintf(stderr, " -g Allow remote hosts to connect to forwarded ports.\n"); + fprintf(stderr, " -1 Force protocol version 1.\n"); + fprintf(stderr, " -2 Force protocol version 2.\n"); fprintf(stderr, " -4 Use IPv4 only.\n"); fprintf(stderr, " -6 Use IPv6 only.\n"); - fprintf(stderr, " -2 Force protocol version 2.\n"); fprintf(stderr, " -o 'option' Process the option as if it was read from a configuration file.\n"); exit(1); } @@ -286,16 +287,44 @@ cp = av0; #ifdef HAVE_CYGWIN if (strcasecmp(cp, "rsh") && strcasecmp(cp, "ssh") && + strcasecmp(cp, "ssh1") && strcasecmp(cp, "ssh2") && strcasecmp(cp, "rlogin") && strcasecmp(cp, "slogin") && + strcasecmp(cp, "slogin1") && strcasecmp(cp, "slogin2") && strcasecmp(cp, "remsh") && strcasecmp(cp, "rsh.exe") && strcasecmp(cp, "ssh.exe") && + strcasecmp(cp, "ssh1.exe") && strcasecmp(cp, "ssh2.exe") && strcasecmp(cp, "rlogin.exe") && strcasecmp(cp, "slogin.exe") && + strcasecmp(cp, "slogin1.exe") && strcasecmp(cp, "slogin2.exe") && strcasecmp(cp, "remsh.exe")) #else if (strcmp(cp, "rsh") && strcmp(cp, "ssh") && strcmp(cp, "rlogin") && + strcmp(cp, "ssh1") && strcmp(cp, "ssh2") && + strcmp(cp, "slogin1") && strcmp(cp, "slogin2") && strcmp(cp, "slogin") && strcmp(cp, "remsh")) #endif host = cp; +#ifdef HAVE_CYGWIN + else if (!strcasecmp(cp, "ssh1") || + !strcasecmp(cp, "slogin1") || + !strcasecmp(cp, "ssh1.exe") || + !strcasecmp(cp, "slogin1.exe")) +#else + else if (!strcmp(cp, "ssh1") || !strcmp(cp, "slogin1")) +#endif + { + options.protocol = SSH_PROTO_1; + } +#ifdef HAVE_CYGWIN + else if (!strcasecmp(cp, "ssh2") || + !strcasecmp(cp, "slogin2") || + !strcasecmp(cp, "ssh2.exe") || + !strcasecmp(cp, "slogin2.exe")) +#else + else if (!strcmp(cp, "ssh2") || !strcmp(cp, "slogin2")) +#endif + { + options.protocol = SSH_PROTO_2; + } for (optind = 1; optind < ac; optind++) { if (av[optind][0] != '-') { @@ -327,6 +356,9 @@ optarg = NULL; } switch (opt) { + case '1': + options.protocol = SSH_PROTO_1; + break; case '2': options.protocol = SSH_PROTO_2; break; --- ./ssh.1.orig-protoargs Fri Oct 27 23:19:58 2000 +++ ./ssh.1 Tue Jan 9 15:40:01 2001 @@ -48,7 +48,7 @@ .Op Ar command .Pp .Nm ssh -.Op Fl afgknqtvxACNPTX246 +.Op Fl afgknqtvxACNPTX1246 .Op Fl c Ar cipher_spec .Op Fl e Ar escape_char .Op Fl i Ar identity_file @@ -539,6 +539,10 @@ Port forwardings can also be specified in the configuration file. Privileged ports can be forwarded only when logging in as root on the remote machine. +.It Fl 1 +Forces +.Nm +to try protocol version 1 only. .It Fl 2 Forces .Nm --- ./scp.1.orig-protoargs Sun Nov 5 20:39:34 2000 +++ ./scp.1 Tue Jan 9 15:41:18 2001 @@ -19,7 +19,7 @@ .Nd secure copy (remote file copy program) .Sh SYNOPSIS .Nm scp -.Op Fl pqrvC46 +.Op Fl pqrvC1246 .Op Fl S Ar program .Op Fl P Ar port .Op Fl c Ar cipher @@ -110,6 +110,14 @@ .It Fl o Ar option The given option is directly passed to .Xr ssh 1 . +.It Fl 1 +Forces +.Nm +to try protocol version 1 only. +.It Fl 2 +Forces +.Nm +to try protocol version 2 only. .It Fl 4 Forces .Nm From djm at mindrot.org Wed Feb 7 09:34:35 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 7 Feb 2001 09:34:35 +1100 (EST) Subject: sftp client In-Reply-To: Message-ID: On Tue, 6 Feb 2001, Pekka Savola wrote: > On Tue, 6 Feb 2001, Damien Miller wrote: > > Minor manpage error: > > --- sftp.1~ Sun Feb 4 14:20:19 2001 > +++ sftp.1 Tue Feb 6 20:44:41 2001 > @@ -60,8 +60,8 @@ > .Xr ssh 1 . > .El > .Sh INTERACTIVE COMMANDS > -Once in interactive mode > -.Nm , > +Once in interactive mode, > +.Nm Thanks - applied. -- | ``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 Feb 7 09:40:40 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 7 Feb 2001 09:40:40 +1100 (EST) Subject: Minor configure.in check In-Reply-To: Message-ID: On Mon, 5 Feb 2001 mouring at etoh.eviladmin.org wrote: > > It was brought up that on Solaris 2.7 that 'ar' may not be found when it > steps into openbsd-compat/. I've not heard of this bug before but this > is the following fix. Any particle reason for us not to commit this? Looks ok to me. -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 Feb 7 09:43:53 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 7 Feb 2001 09:43:53 +1100 (EST) Subject: sftp client In-Reply-To: <20010206125842.P15821@cygbert.vinschen.de> Message-ID: On Tue, 6 Feb 2001, Corinna Vinschen wrote: > On Tue, Feb 06, 2001 at 03:53:34PM +1100, Damien Miller wrote: > > As of Sunday evening, OpenSSH has an interactive sftp client. It should > > be in the more recent snapshots. > > > > It would be appreciated if you could test new client and find all the > > bugs :) Please also have a read of the manpage and ensure that it > > matches what is implemented. > > > > I am working on fixing the ones that I know about, so please try to > > stay up to date with the snapshots. > > Just hit another problem. When connecting with openssh-sftp to > the sftp-server the sftp-server process remains in memory after > exiting the client, waiting for input. > > sftp-server on i686-pc-cygwin, > sftp-client on i686-pc-cygwin and i686-pc-linux-gnu > > The same does not happen when using the ssh.com sftp client. Does the parent sshd exit? Can you turn on debugging in the sftp-server by editing the #define TRACE to use log instead of debug. I would like to see whether ssh.com sftp sends an explicit close message. -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 Feb 7 09:46:06 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 7 Feb 2001 09:46:06 +1100 (EST) Subject: RNG not initialised for sftp only under Solaris. In-Reply-To: Message-ID: On Tue, 6 Feb 2001 mouring at etoh.eviladmin.org wrote: > > Ahh.. a moment of truth. the init_rng(); does being in sftp.c due to: > > sftp-client.c: id = arc4random(); My bad - i put these in for debugging and will take them out now. The ID doesn't need to be random. -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 acox at cv.telegroup.com Wed Feb 7 10:19:53 2001 From: acox at cv.telegroup.com (Aran Cox) Date: Tue, 6 Feb 2001 17:19:53 -0600 Subject: SCO 5.0.5 (i686-pc-sco3.2v5.0.5), scp and the -n option In-Reply-To: <20010205181321.E18567@benway.cv.telegroup.com>; from acox@cv.telegroup.com on Mon, Feb 05, 2001 at 06:13:21PM -0600 References: <20010205181321.E18567@benway.cv.telegroup.com> Message-ID: <20010206171953.H10295@benway.cv.telegroup.com> On Mon, Feb 05, 2001 at 06:13:21PM -0600, Aran Cox wrote: > > The real question (for me) here is in what circumstances do I need to > use -n? I would swear that in the past, I have needed -n to keep > shell scripts from hanging on invocations of rsh/rcmd. Now, I can't > duplicate that to save me. (Either with rsh/rcmd or ssh.) It appears > that I don't even need -n to get X applications to work correctly. If > it weren't for the problems with scp hanging around I would just drop > the -n and forget about USE_PIPE entirely, but -n ought to > work. However, since I can't seem to find a concrete use for the > option, that point may be moot. > Ok, I went out and answered my own question. If you write a script like this: while read host; do [rs]sh $host ls -ld . done And pass a list of hosts via stdin, only the first host gets [rs]sh run on it. Then the script just exits. [rs]sh sucks up the rest of stdin, unless you prevent it from doing so with the -n option. I don't quite understand why ssh or rsh would read stdin until it's empty without the executed program on the other end requesting anything of stdin. Would doing it otherwise have been needlessly complex? Or was that just the behaviour of rsh and hence the behaviour of ssh? Aran From djm at mindrot.org Wed Feb 7 13:02:49 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 7 Feb 2001 13:02:49 +1100 (EST) Subject: SCO 5.0.5 (i686-pc-sco3.2v5.0.5), scp and the -n option In-Reply-To: <20010206171953.H10295@benway.cv.telegroup.com> Message-ID: On Tue, 6 Feb 2001, Aran Cox wrote: > Ok, I went out and answered my own question. If you write a script like > this: > > while read host; do > [rs]sh $host ls -ld . > done > > And pass a list of hosts via stdin, only the first host gets > [rs]sh run on it. Then the script just exits. [rs]sh sucks up > the rest of stdin, unless you prevent it from doing so with the > -n option. > > I don't quite understand why ssh or rsh would read stdin until > it's empty without the executed program on the other end > requesting anything of stdin. There is no way for ssh to know whether the remote program needs data other than to actually send it. To get the behaviour you want do: while read host; do ssh $host ls -ld . < /dev/null done -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 roth+openssh at feep.net Wed Feb 7 17:00:40 2001 From: roth+openssh at feep.net (Mark D. Roth) Date: Wed, 7 Feb 2001 00:00:40 -0600 Subject: Patch for unformatted manpages Message-ID: <20010207000040.A15349@yorktown.isdn.uiuc.edu> The attached patch (relative to the current CVS snapshot) uses a perl script to convert the OpenSSH manpages from the BSD -mdoc format to the -man format used by other systems. This allows the unformatted manpages to be installed normally, rather than defaulting to preformatted pages. I'd like to see this patch integrated into the portable version of OpenSSH. Please let me know what you think about this. Thanks! -- Mark D. Roth http://www.feep.net/~roth/ -------------- next part -------------- diff -urN openssh_cvs/Makefile.in openssh_work/Makefile.in --- openssh_cvs/Makefile.in Sun Feb 4 07:54:23 2001 +++ openssh_work/Makefile.in Tue Feb 6 23:42:49 2001 @@ -6,7 +6,6 @@ sbindir=@sbindir@ libexecdir=@libexecdir@ mandir=@mandir@ -mansubdir=@mansubdir@ sysconfdir=@sysconfdir@ piddir=@piddir@ srcdir=@srcdir@ @@ -45,9 +44,7 @@ SSHDOBJS= sshd.o auth.o auth1.o auth2.o auth-chall.o auth2-chall.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth2-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o dh.o pty.o log-server.o login.o loginrec.o servconf.o serverloop.o md5crypt.o session.o groupaccess.o -TROFFMAN = scp.1 ssh-add.1 ssh-agent.1 ssh-keygen.1 ssh-keyscan.1 ssh.1 sshd.8 sftp-server.8 sftp.1 -CATMAN = scp.0 ssh-add.0 ssh-agent.0 ssh-keygen.0 ssh-keyscan.0 ssh.0 sshd.0 sftp-server.0 sftp.0 -MANPAGES = @MANTYPE@ +MANPAGES = scp.1 ssh-add.1 ssh-agent.1 ssh-keygen.1 ssh-keyscan.1 ssh.1 sshd.8 sftp-server.8 sftp.1 CONFIGFILES=sshd_config ssh_config primes @@ -67,6 +64,8 @@ FIXPATHSCMD = $(PERL) $(srcdir)/fixpaths $(PATHSUBS) +MDOC2MANCMD = $(PERL) $(srcdir)/mdoc2man.pl + all: $(TARGETS) $(CONFIGFILES) manpages: $(MANPAGES) @@ -118,8 +117,12 @@ logintest: logintest.o $(LIBCOMPAT) libssh.a log-client.o loginrec.o $(LD) -o $@ logintest.o $(LDFLAGS) loginrec.o -lopenbsd-compat -lssh log-client.o $(LIBS) -$(MANPAGES) $(CONFIGFILES):: +$(CONFIGFILES):: + $(FIXPATHSCMD) $(srcdir)/$@ + +$(MANPAGES):: $(FIXPATHSCMD) $(srcdir)/$@ + $(MDOC2MANCMD) < $@.out > $@.out2 && mv $@.out2 $@.out clean: (cd openbsd-compat; $(MAKE) clean) @@ -152,8 +155,8 @@ $(srcdir)/mkinstalldirs $(DESTDIR)$(bindir) $(srcdir)/mkinstalldirs $(DESTDIR)$(sbindir) $(srcdir)/mkinstalldirs $(DESTDIR)$(mandir) - $(srcdir)/mkinstalldirs $(DESTDIR)$(mandir)/$(mansubdir)1 - $(srcdir)/mkinstalldirs $(DESTDIR)$(mandir)/$(mansubdir)8 + $(srcdir)/mkinstalldirs $(DESTDIR)$(mandir)/man1 + $(srcdir)/mkinstalldirs $(DESTDIR)$(mandir)/man8 $(srcdir)/mkinstalldirs $(DESTDIR)$(libexecdir) $(INSTALL) -m $(SSH_MODE) -s ssh $(DESTDIR)$(bindir)/ssh $(INSTALL) -m 0755 -s scp $(DESTDIR)$(bindir)/scp @@ -164,19 +167,19 @@ $(INSTALL) -m 0755 -s sshd $(DESTDIR)$(sbindir)/sshd @NO_SFTP@$(INSTALL) -m 0755 -s sftp $(DESTDIR)$(bindir)/sftp @NO_SFTP@$(INSTALL) -m 0755 -s sftp-server $(DESTDIR)$(libexecdir)/sftp-server - $(INSTALL) -m 644 ssh.[01].out $(DESTDIR)$(mandir)/$(mansubdir)1/ssh.1 - $(INSTALL) -m 644 scp.[01].out $(DESTDIR)$(mandir)/$(mansubdir)1/scp.1 - $(INSTALL) -m 644 ssh-add.[01].out $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-add.1 - $(INSTALL) -m 644 ssh-agent.[01].out $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-agent.1 - $(INSTALL) -m 644 ssh-keygen.[01].out $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-keygen.1 - $(INSTALL) -m 644 ssh-keyscan.[01].out $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-keyscan.1 - $(INSTALL) -m 644 sshd.[08].out $(DESTDIR)$(mandir)/$(mansubdir)8/sshd.8 - @NO_SFTP@$(INSTALL) -m 644 sftp.[01].out $(DESTDIR)$(mandir)/$(mansubdir)1/sftp.1 - @NO_SFTP@$(INSTALL) -m 644 sftp-server.[08].out $(DESTDIR)$(mandir)/$(mansubdir)8/sftp-server.8 + $(INSTALL) -m 644 ssh.1.out $(DESTDIR)$(mandir)/man1/ssh.1 + $(INSTALL) -m 644 scp.1.out $(DESTDIR)$(mandir)/man1/scp.1 + $(INSTALL) -m 644 ssh-add.1.out $(DESTDIR)$(mandir)/man1/ssh-add.1 + $(INSTALL) -m 644 ssh-agent.1.out $(DESTDIR)$(mandir)/man1/ssh-agent.1 + $(INSTALL) -m 644 ssh-keygen.1.out $(DESTDIR)$(mandir)/man1/ssh-keygen.1 + $(INSTALL) -m 644 ssh-keyscan.1.out $(DESTDIR)$(mandir)/man1/ssh-keyscan.1 + $(INSTALL) -m 644 sshd.8.out $(DESTDIR)$(mandir)/man8/sshd.8 + @NO_SFTP@$(INSTALL) -m 644 sftp.1.out $(DESTDIR)$(mandir)/man1/sftp.1 + @NO_SFTP@$(INSTALL) -m 644 sftp-server.8.out $(DESTDIR)$(mandir)/man8/sftp-server.8 -rm -f $(DESTDIR)$(bindir)/slogin ln -s ssh$(EXEEXT) $(DESTDIR)$(bindir)/slogin - -rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/slogin.1 - ln -s ssh.1 $(DESTDIR)$(mandir)/$(mansubdir)1/slogin.1 + -rm -f $(DESTDIR)$(mandir)/man1/slogin.1 + ln -s ssh.1 $(DESTDIR)$(mandir)/man1/slogin.1 @FILEPRIV@ -f dev,filesys,driver $(DESTDIR)$(bindir)/ssh $(DESTDIR)$(bindir)/slogin if [ ! -d $(DESTDIR)$(sysconfdir) ]; then \ $(srcdir)/mkinstalldirs $(DESTDIR)$(sysconfdir); \ @@ -236,8 +239,8 @@ -rmdir $(DESTDIR)$(sysconfdir) -rmdir $(DESTDIR)$(bindir) -rmdir $(DESTDIR)$(sbindir) - -rmdir $(DESTDIR)$(mandir)/$(mansubdir)1 - -rmdir $(DESTDIR)$(mandir)/$(mansubdir)8 + -rmdir $(DESTDIR)$(mandir)/man1 + -rmdir $(DESTDIR)$(mandir)/man8 -rmdir $(DESTDIR)$(mandir) -rmdir $(DESTDIR)$(libexecdir) @@ -252,14 +255,14 @@ -rm -f $(DESTDIR)$(bindir)/sftp$(EXEEXT) -rm -f $(DESTDIR)$(sbindir)/sshd$(EXEEXT) -rm -r $(DESTDIR)$(libexecdir)/sftp-server$(EXEEXT) - -rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/ssh.1 - -rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/scp.1 - -rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-add.1 - -rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-agent.1 - -rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-keygen.1 - -rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/sftp.1 - -rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-keyscan.1 - -rm -f $(DESTDIR)$(mandir)/$(mansubdir)8/sshd.8 - -rm -f $(DESTDIR)$(mandir)/$(mansubdir)8/sftp-server.8 - -rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/slogin.1 + -rm -f $(DESTDIR)$(mandir)/man1/ssh.1 + -rm -f $(DESTDIR)$(mandir)/man1/scp.1 + -rm -f $(DESTDIR)$(mandir)/man1/ssh-add.1 + -rm -f $(DESTDIR)$(mandir)/man1/ssh-agent.1 + -rm -f $(DESTDIR)$(mandir)/man1/ssh-keygen.1 + -rm -f $(DESTDIR)$(mandir)/man1/sftp.1 + -rm -f $(DESTDIR)$(mandir)/man1/ssh-keyscan.1 + -rm -f $(DESTDIR)$(mandir)/man8/sshd.8 + -rm -f $(DESTDIR)$(mandir)/man8/sftp-server.8 + -rm -f $(DESTDIR)$(mandir)/man1/slogin.1 -rm -f $(DESTDIR)${ASKPASS_PROGRAM} diff -urN openssh_cvs/configure.in openssh_work/configure.in --- openssh_cvs/configure.in Tue Feb 6 16:54:31 2001 +++ openssh_work/configure.in Tue Feb 6 23:22:02 2001 @@ -52,12 +52,8 @@ fi AC_CHECK_FUNC(authenticate, [AC_DEFINE(WITH_AIXAUTHENTICATE)]) AC_DEFINE(BROKEN_GETADDRINFO) - MANTYPE='$(CATMAN)' - mansubdir=cat dnl AIX handles lastlog as part of its login message AC_DEFINE(DISABLE_LASTLOG) - MANTYPE='$(CATMAN)' - mansubdir=cat ;; *-*-cygwin*) LIBS="$LIBS -lregex /usr/lib/textmode.o" @@ -80,8 +76,6 @@ AC_DEFINE(DISABLE_UTMP) AC_DEFINE(SPT_TYPE,SPT_PSTAT) LIBS="$LIBS -lsec" - MANTYPE='$(CATMAN)' - mansubdir=cat ;; *-*-hpux11*) CPPFLAGS="$CPPFLAGS -D_HPUX_SOURCE" @@ -92,14 +86,11 @@ AC_DEFINE(DISABLE_UTMP) AC_DEFINE(SPT_TYPE,SPT_PSTAT) LIBS="$LIBS -lsec" - MANTYPE='$(CATMAN)' - mansubdir=cat ;; *-*-irix5*) CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS" PATH="$PATH:/usr/etc" - MANTYPE='$(CATMAN)' no_libsocket=1 no_libnsl=1 AC_DEFINE(BROKEN_INET_NTOA) @@ -108,7 +99,6 @@ CPPFLAGS="$CPPFLAGS -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) @@ -116,7 +106,6 @@ no_libsocket=1 no_libnsl=1 AC_DEFINE(BROKEN_INET_NTOA) - mansubdir=man ;; *-*-linux*) no_dev_ptmx=1 @@ -171,46 +160,34 @@ conf_wtmp_location=/var/adm/wtmp conf_lastlog_location=/var/adm/lastlog AC_DEFINE(USE_PIPES) - MANTYPE='$(CATMAN)' - mansubdir=cat ;; *-sni-sysv*) CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib -L/usr/ucblib" - MANTYPE='$(CATMAN)' IPADDR_IN_DISPLAY=yes AC_DEFINE(USE_PIPES) AC_DEFINE(IP_TOS_IS_BROKEN) - mansubdir=cat LIBS="$LIBS -lgen -lnsl -lucb" ;; *-*-sysv4.2*) CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib" - MANTYPE='$(CATMAN)' - mansubdir=cat enable_suid_ssh=no ;; *-*-sysv5*) CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib" - MANTYPE='$(CATMAN)' - mansubdir=cat enable_suid_ssh=no ;; *-*-sysv*) CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib" - MANTYPE='$(CATMAN)' - mansubdir=cat LIBS="$LIBS -lgen -lsocket" ;; *-*-sco3.2v4*) AC_DEFINE(USE_PIPES) CPPFLAGS="$CPPFLAGS -Dftruncate=chsize -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib" - MANTYPE='$(CATMAN)' - mansubdir=cat LIBS="$LIBS -lgen -lsocket -los -lprot -lx -ltinfo -lm" no_dev_ptmx=1 RANLIB=true @@ -224,8 +201,6 @@ AC_DEFINE(USE_PIPES) CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib" - MANTYPE='$(CATMAN)' - mansubdir=cat LIBS="$LIBS -lprot -lx -ltinfo -lm" no_dev_ptmx=1 rsh_path="/usr/bin/rcmd" @@ -1117,25 +1092,6 @@ AC_SUBST(INSTALL_SSH_PRNG_CMDS) -AC_ARG_WITH(catman, - [ --with-catman=man|cat Install preformatted manpages[no]], - [ - MANTYPE='$(CATMAN)' - if test x"$withval" != x"yes" ; then - mansubdir=$withval - else - mansubdir=cat - fi - ], [ - if test -z "$MANTYPE" ; then - MANTYPE='$(TROFFMAN)' - mansubdir=man - fi - ] -) -AC_SUBST(MANTYPE) -AC_SUBST(mansubdir) - # Check whether user wants Kerberos support KRB4_MSG="no" AC_ARG_WITH(kerberos4, @@ -1645,11 +1601,6 @@ # Print summary of options -if test x$MANTYPE = x'$(CATMAN)' ; then - MAN_MSG=cat -else - MAN_MSG=man -fi if test ! -z "$RANDOM_POOL" ; then RAND_MSG="Device ($RANDOM_POOL)" else @@ -1667,7 +1618,7 @@ C=`eval echo ${sbindir}` ; C=`eval echo ${C}` D=`eval echo ${sysconfdir}` ; D=`eval echo ${D}` E=`eval echo ${libexecdir}/ssh-askpass` ; E=`eval echo ${E}` -F=`eval echo ${mandir}/${mansubdir}X` ; F=`eval echo ${F}` +F=`eval echo ${mandir}/manX` ; F=`eval echo ${F}` G=`eval echo ${piddir}` ; G=`eval echo ${G}` echo "" @@ -1680,7 +1631,6 @@ echo " Manual pages: $F" echo " PID file: $G" echo " Random number collection: $RAND_MSG" -echo " Manpage format: $MAN_MSG" echo " PAM support: ${PAM_MSG}" echo " KerberosIV support: $KRB4_MSG" echo " AFS support: $AFS_MSG" diff -urN openssh_cvs/mdoc2man.pl openssh_work/mdoc2man.pl --- openssh_cvs/mdoc2man.pl Wed Dec 31 18:00:00 1969 +++ openssh_work/mdoc2man.pl Tue Feb 6 23:17:10 2001 @@ -0,0 +1,329 @@ +#!/usr/local/bin/perl + +use strict; + +my ($name, $date, $id); +my ($line); +my ($optlist, $nospace, $enum, $synopsis); + + +$optlist = 0; ### 1 = bullet, 2 = enum, 3 = tag +$nospace = 0; +$synopsis = 0; + +while ($line = ) +{ + if ($line !~ /^\./) + { + print $line; + next; + } + + $line =~ s/^\.//; + + next + if ($line =~ m/\\"/); + + $line = ParseMacro($line); + print($line) + if (defined $line); +} + + + +sub ParseMacro # ($line) +{ + my ($line) = @_; + my (@words, $retval, $option, $parens, $arg); + + @words = split(/\s+/, $line); + $retval = ''; + $option = 0; + $parens = 0; + $arg = 0; + +# print('@words = ', scalar(@words), ': ', join(' ', @words), "\n"); + + while ($_ = shift @words) + { +# print "WORD: $_\n"; + + next + if (/^(Li|Pf|X[oc])$/); + + if (/^Ns/) + { + $nospace = 1 + if (! $nospace); + $retval =~ s/ $//; + next; + } + + if (/^No/) + { + $retval =~ s/ $//; + $retval .= shift @words; + next; + } + + if (/^Dq$/) { + $retval .= '``' . (shift @words) . '\'\''; + $nospace = 1 + if (! $nospace && $words[0] =~ m/^[\.,]/); + next; + } + + if (/^(Sq|Ql)$/) { + $retval .= '`' . (shift @words) . '\''; + $nospace = 1 + if (! $nospace && $words[0] =~ m/^[\.,]/); + next; + } + + $retval .= ' ' + if (! $nospace && $retval ne '' && $retval !~ m/[\n ]$/); + $nospace = 0 + if ($nospace == 1); + + if (/^Dd$/) { + $date = join(' ', @words); + return undef; + } + + if (/^Dt$/) { + $id = join(' ', @words); + return undef; + } + + if (/^Os$/) { + $retval .= '.TH ' + . $id + . " \"$date\" \"" + . join(' ', @words) + . "\""; + last; + } + + if (/^Sh$/) { + $retval .= '.SH'; + if ($words[0] eq 'SYNOPSIS') + { + $synopsis = 1; + } + else + { + $synopsis = 0; + } + next; + } + + if (/^Xr$/) { + $retval .= '\\fB' . (shift @words) . + '\\fR(' . (shift @words) . ')' + . (shift @words); + last; + } + + if (/^Nm$/) { + $name = shift @words + if (@words > 0); + $retval .= ".br\n" + if ($synopsis); + $retval .= "\\fB$name\\fR"; + $nospace = 1 + if (! $nospace && $words[0] =~ m/^[\.,]/); + next; + } + + if (/^Nd$/) { + $retval .= '\\-'; + next; + } + + if (/^Fl$/) { + $retval .= '\\fB\\-' . (shift @words) . '\\fR'; + $nospace = 1 + if (! $nospace && $words[0] =~ m/^[\.,]/); + next; + } + + if (/^Ar$/) { + $retval .= '\\fI'; + if (! defined $words[0]) + { + $retval .= 'file ...\\fR'; + } + $arg = 1; + $nospace = 1 + if (! $nospace); + next; + } + + if (/^Cm$/) { + $retval .= '\\fB' . (shift @words) . '\\fR'; + next; + } + + if (/^Op$/) { + $option = 1; + $nospace = 1 + if (! $nospace); + $retval .= '['; + next; + } + + if (/^Oo$/) { + $retval .= "[\\c\n"; + next; + } + + if (/^Oc$/) { + $retval .= ']'; + next; + } + + if (/^Pp$/) { + if ($optlist) { + $retval .= "\n"; + } else { + $retval .= '.LP'; + } + next; + } + + if (/^Ss$/) { + $retval .= '.SS'; + next; + } + + if (/^Pa$/ && ! $option) { + $retval .= '\\fI'; + $retval .= '\\&' + if ($words[0] =~ m/^\./); + $retval .= (shift @words) . '\\fR'; + $nospace = 1 + if (! $nospace && $words[0] =~ m/^[\.,]/); + next; + } + + if (/^Dv$/) { + $retval .= '.BR'; + next; + } + + if (/^(Em|Ev)$/) { + $retval .= '.IR'; + next; + } + + if (/^Pq$/) { + $retval .= '('; + $nospace = 1; + $parens = 1; + next; + } + + if (/^(S[xy])$/) { + $retval .= '.B ' . join(' ', @words); + last; + } + + if (/^Ic$/) + { + $retval .= '\\fB'; + while (defined $words[0] + && $words[0] !~ m/^[\.,]/) + { + $retval .= shift @words; + $retval .= ' ' + if (! $nospace); + } + $retval =~ s/ $//; + $retval .= '\\fR'; + $retval .= shift @words + if (defined $words[0]); + last; + } + + if (/^Bl$/) { + if ($words[0] eq '-bullet') { + $optlist = 1; + } elsif ($words[0] eq '-enum') { + $optlist = 2; + $enum = 0; + } elsif ($words[0] eq '-tag') { + $optlist = 3; + } + last; + } + + if (/^El$/) { + $optlist = 0; + next; + } + + if ($optlist && /^It$/) { + if ($optlist == 1) { + # bullets + $retval .= '.IP \\(bu'; + next; + } + + if ($optlist == 2) { + # enum + $retval .= '.IP ' . (++$enum) . '.'; + next; + } + + if ($optlist == 3) { + # tags + $retval .= ".TP\n"; + if ($words[0] =~ m/^(Pa|Ev)$/) + { + shift @words; + $retval .= '.B'; + } + next; + } + + next; + } + + if (/^Sm$/) { + if ($words[0] eq 'off') { + $nospace = 2; + } elsif ($words[0] eq 'on') { + $retval .= "\n"; + $nospace = 0; + } + shift @words; + next; + } + + $retval .= "$_"; + } + + return undef + if ($retval eq '.'); + + $retval =~ s/^\.([^a-zA-Z])/$1/; + $retval =~ s/ $//; + + $retval .= ')' + if ($parens == 1); + + $retval .= ']' + if ($option == 1); + + $retval .= '\\fR' + if ($arg); + + $retval .= '\\c' + if ($nospace && $retval ne '' && $retval !~ m/\n$/); + + $retval .= "\n" + if ($retval ne '' && $retval !~ m/\n$/); + + return $retval; +} + From djm at mindrot.org Wed Feb 7 17:32:39 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 7 Feb 2001 17:32:39 +1100 (EST) Subject: Patch for unformatted manpages In-Reply-To: <20010207000040.A15349@yorktown.isdn.uiuc.edu> Message-ID: On Wed, 7 Feb 2001, Mark D. Roth wrote: > The attached patch (relative to the current CVS snapshot) uses a perl > script to convert the OpenSSH manpages from the BSD -mdoc format to > the -man format used by other systems. This allows the unformatted > manpages to be installed normally, rather than defaulting to > preformatted pages. Looks very nice! Can people who have had problems with manpages try the perl script out and report back? > I'd like to see this patch integrated into the portable version of > OpenSSH. Please let me know what you think about this. Thanks! I am all for it. Just a bit of feedback to bring us closer to this point: Is there a license on the perl script? It needs one. I would prefer not to remove the preformatted pages altogether, but instead alter --with-catman to take either 'mandoc', 'man' or 'cat' arguments. Some similar configure.in magic would be required. I can do this if required. -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 gert at greenie.muc.de Wed Feb 7 18:47:57 2001 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 7 Feb 2001 08:47:57 +0100 Subject: Patch for unformatted manpages In-Reply-To: <20010207000040.A15349@yorktown.isdn.uiuc.edu>; from Mark D. Roth on Wed, Feb 07, 2001 at 12:00:40AM -0600 References: <20010207000040.A15349@yorktown.isdn.uiuc.edu> Message-ID: <20010207084757.C28949@greenie.muc.de> Hi, On Wed, Feb 07, 2001 at 12:00:40AM -0600, Mark D. Roth wrote: > The attached patch (relative to the current CVS snapshot) uses a perl > script to convert the OpenSSH manpages from the BSD -mdoc format to > the -man format used by other systems. This allows the unformatted > manpages to be installed normally, rather than defaulting to > preformatted pages. Great idea! (Having no -mdoc here, and without, the BSD man pages are plain ugly) 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 Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Feb 7 20:41:42 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Wed, 7 Feb 2001 10:41:42 +0100 Subject: sftp client In-Reply-To: ; from rob@hagopian.net on Tue, Feb 06, 2001 at 02:28:44PM -0500 References: <20010206113350.A26560@ws01.aet.tu-cottbus.de> Message-ID: <20010207104142.B2239@serv01.aet.tu-cottbus.de> On Tue, Feb 06, 2001 at 02:28:44PM -0500, Rob Hagopian wrote: > Yep, my fault (I was protecting other pages on the site), it should be all > fixed now! > -Rob Sorry, the problem is still not solved. When testing make sure to exit Netscape, as it caches authentication data and there is no other way to re-initialize than exiting. I have switched to CVS access now. 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 roumen.petrov at skalasoft.com Wed Feb 7 22:10:28 2001 From: roumen.petrov at skalasoft.com (Roumen Petrov) Date: Wed, 07 Feb 2001 13:10:28 +0200 Subject: getline References: Message-ID: <3A812D24.2060600@skalasoft.com> all dates in ChangeLog are bad for feb 2001 From roumen.petrov at skalasoft.com Wed Feb 7 23:01:03 2001 From: roumen.petrov at skalasoft.com (Roumen Petrov) Date: Wed, 07 Feb 2001 14:01:03 +0200 Subject: ChangeLog dates References: <3A812D24.2060600@skalasoft.com> Message-ID: <3A8138FF.2070401@skalasoft.com> Bad dates in ChangeLog for feb 2001 ------------- 20010107 -> must be 20010207 - (bal) Save the whole path to AR in configure. Some Solaris 2.7 installs seem lose track of it while in openbsd-compat/ (two confirmed reports) ............. 20010106 -> 20010206 ........ 20010101 -> 20010201 ------------- From roumen.petrov at skalasoft.com Wed Feb 7 23:14:17 2001 From: roumen.petrov at skalasoft.com (Roumen Petrov) Date: Wed, 07 Feb 2001 14:14:17 +0200 Subject: sftp client References: Message-ID: <3A813C19.4060907@skalasoft.com> 1752132969 is 'home' as string - problem is not in sftp client - problem is not in sftp subsystem from sshd ( exist in SNAP from 15 jan 2001 ). scp2 from ssh.com use sftp subsystem and cannot copy to another user except root !?!?!? - problem is before execution of sftp-server ( sftp-server is not started ) Damien Miller wrote: > On Tue, 6 Feb 2001, Roumen Petrov wrote: ... >> sftp as non root user -> Received message too long 1752132965 ... > What does "ssh user at yourhost /bin/true" say? Do you have anything > being printed in your .bashrc? ... My .bash_profile print some messages but all begin with string '~/profile'. ssh from OpenSSH and SSH.com work with any user name . Problem is in function do_child(...) from session.c From djm at mindrot.org Wed Feb 7 23:19:09 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 7 Feb 2001 23:19:09 +1100 (EST) Subject: sftp client In-Reply-To: <3A813C19.4060907@skalasoft.com> Message-ID: On Wed, 7 Feb 2001, Roumen Petrov wrote: > > 1752132969 is 'home' as string What does "ssh -s user at yourhost sftp" say? -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 roumen.petrov at skalasoft.com Wed Feb 7 23:36:55 2001 From: roumen.petrov at skalasoft.com (Roumen Petrov) Date: Wed, 07 Feb 2001 14:36:55 +0200 Subject: sftp client References: Message-ID: <3A814167.2010205@skalasoft.com> I don't know what to say. Look in patch. subsystem work only with 'sh' and not with 'bash' sh command is link to bash and bash is: bash --version GNU bash, version 2.04.0(1)-release (i386-slackware-linux-gnu) Copyright 1999 Free Software Foundation, Inc. ---------------------------------------------------------------------- Damien Miller wrote: > On Wed, 7 Feb 2001, Roumen Petrov wrote: > > >> 1752132969 is 'home' as string > > > What does "ssh -s user at yourhost sftp" say? print baner prompt for password and after -s stop -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: OOPS.diff Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010207/6d8a58ec/attachment.ksh From djm at mindrot.org Wed Feb 7 23:49:39 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 7 Feb 2001 23:49:39 +1100 (EST) Subject: sftp client In-Reply-To: <3A814167.2010205@skalasoft.com> Message-ID: On Wed, 7 Feb 2001, Roumen Petrov wrote: > > What does "ssh -s user at yourhost sftp" say? > print baner What banner? What does it say? > prompt for password > and after -s stop -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From mouring at etoh.eviladmin.org Thu Feb 8 02:00:15 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 7 Feb 2001 09:00:15 -0600 (CST) Subject: sftp client In-Reply-To: <3A814167.2010205@skalasoft.com> Message-ID: On Wed, 7 Feb 2001, Roumen Petrov wrote: > I don't know what to say. Look in patch. > > subsystem work only with 'sh' and not with 'bash' > sh command is link to bash and bash is: > They do? Funny.. [mouring at etoh openssh]$ bash --version GNU bash, version 2.04.11(1)-release (i386-redhat-linux-gnu) Copyright 1999 Free Software Foundation, Inc. Works just perfectly fine to me. There has to be another reason. I have sftp-server working with bash, ksh, ssh, and even csh/tsch. However if you have *ANYTHING* printing from your .bashrc and friends it will spew out that type of error. [mouring at etoh openssh]$ ssh -s localhost sftp mouring at localhost's password: usage: sftp [-vC] [-osshopt=value] [user@]host If you get anything between the password prompt and the usage: prompt then you have to start digging around for what is interjecting text. - Ben From roumen.petrov at skalasoft.com Thu Feb 8 01:23:39 2001 From: roumen.petrov at skalasoft.com (Roumen Petrov) Date: Wed, 07 Feb 2001 16:23:39 +0200 Subject: sftp client References: Message-ID: <3A815A6B.4010104@skalasoft.com> Damien Miller wrote: > yOn Wed, 7 Feb 2001, Roumen Petrov wrote: > > >>> What banner? What does it say? >> >> Damien problem is very strange. >> if first argument to execve is bash I receive 'home+real data' for . >> if first argumennon root users is sh all is ok ( only real data ) . > > > Are you sure there is nothin in /etc/profile, /etc/bashrc or ~/.bashrc > which might be printing this? IIRC bash may source different files > depending on what name it is called by. > > -d You has right execve execute interactive shell ( not login shell ) I check only /etc/profile and $HOME/.bash_profile. but my .bashrc for interactive shell print some messages. Damien, has you idea what is broken ( see atached C file ) bash only by test 3 print to stdout echo commands from $HOME/.bashrc PROBLEM is in BASH and SSH_CLIENT env.var. !!!!!!!!! -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xx.c Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010207/375b3100/attachment.c From roumen.petrov at skalasoft.com Thu Feb 8 01:56:06 2001 From: roumen.petrov at skalasoft.com (Roumen Petrov) Date: Wed, 07 Feb 2001 16:56:06 +0200 Subject: Makefile.in Message-ID: <3A816206.30509@skalasoft.com> remove last line in Makefile.in -rm -f $(DESTDIR)${ASKPASS_PROGRAM} ----------------------------------------- ${ASKPASS_PROGRAM} is external program 'make uninstall' don't needed to remove it From roth+openssh at feep.net Thu Feb 8 02:31:14 2001 From: roth+openssh at feep.net (Mark D. Roth) Date: Wed, 7 Feb 2001 09:31:14 -0600 Subject: Patch for unformatted manpages In-Reply-To: ; from djm@mindrot.org on Wed, Feb 07, 2001 at 05:32:39PM +1100 References: <20010207000040.A15349@yorktown.isdn.uiuc.edu> Message-ID: <20010207093113.A15890@yorktown.isdn.uiuc.edu> On Wed Feb 07 17:32 2001 +1100, Damien Miller wrote: > Looks very nice! Can people who have had problems with manpages try > the perl script out and report back? They're welcome to do so, but there is one caveat: I only added support for the particular -mdoc macros which are actually used in the OpenSSH manpages, so it won't work right on manpages which use other macros. Ideally, of course, the script should be a general-purpose converter. I don't have time right now to extend it to that point myself, but I'd be happy to accept patches or bug reports from people as they encounter problems. Also, if there is any interest in the script as a general-purpose tool, I can distribute it seperately (in which case we should work out a way to keep the copy in the OpenSSH CVS tree updated with the master version). > Is there a license on the perl script? It needs one. Good point. Please insert this text at the top of the script: ### ### Copyright (c) 2001 University of Illinois Board of Trustees ### Copyright (c) 2001 Mark D. Roth ### 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. All advertising materials mentioning features or use of this software ### must display the following acknowledgement: ### This product includes software developed by the University of ### Illinois at Urbana, and their contributors. ### 4. The University nor the names of their ### contributors may be used to endorse or promote products derived from ### this software without specific prior written permission. ### ### THIS SOFTWARE IS PROVIDED BY THE TRUSTEES AND CONTRIBUTORS ``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 TRUSTEES OR CONTRIBUTORS 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. ### > I would prefer not to remove the preformatted pages altogether, but > instead alter --with-catman to take either 'mandoc', 'man' or 'cat' > arguments. Some similar configure.in magic would be required. I > can do this if required. IMHO, the default behavior should be to install the converted unformatted man pages, since that's the expected action on most platforms. Other than that, please feel free to muck with the autoconf setup as you see fit. Thanks for the feedback. Please let me know if you have any further questions or problems. -- Mark D. Roth http://www.feep.net/~roth/ From roumen.petrov at skalasoft.com Thu Feb 8 02:50:12 2001 From: roumen.petrov at skalasoft.com (Roumen Petrov) Date: Wed, 07 Feb 2001 17:50:12 +0200 Subject: sftp client References: Message-ID: <3A816EB4.6030506@skalasoft.com> Q: Has bash '--norc' option for other/all platforms ? If this is true attached file is my patch. Strange is that only first four bytes form $HOME/.bashrc are send to client !?!? P.P.: with system bashrc is not tested ! -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: session.c.diff Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010207/bd8b6513/attachment.ksh From mhw at wittsend.com Thu Feb 8 03:13:14 2001 From: mhw at wittsend.com (Michael H. Warfield) Date: Wed, 7 Feb 2001 11:13:14 -0500 Subject: DSA Fingerprints... Message-ID: <20010207111314.E420@alcove.wittsend.com> Hello, Questions, observations, and curiosities. Maybe this is something stupid or maybe I'm doing something wrong... But... In light of the Kurt Seifried paper on SSH and SSL, I was looking for the finger prints on my various servers and known hosts files to have a little crib sheet and maybe plug the list into a database on my palm pilot. I found that ssh-keygen lists out the fingerprints of the RSA keys just fine but fails when I try to list out fingerprints for the DSA keys, claiming that this is not a valid key file. ] [root at alcove /root]# ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pub ] /etc/ssh/ssh_host_dsa_key.pub is not a valid key file. ] You have new mail in /var/spool/mail/mhw ] [root at alcove /root]# ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key ] /etc/ssh/ssh_host_dsa_key is not a valid key file. ] [root at alcove /root]# ssh-keygen -d -l -f /etc/ssh/ssh_host_dsa_key.pub ] /etc/ssh/ssh_host_dsa_key.pub is not a valid key file. ] [root at alcove /root]# ssh-keygen -d -l -f /etc/ssh/ssh_host_dsa_key ] /etc/ssh/ssh_host_dsa_key is not a valid key file. ] [mhw at alcove mhw]$ ssh-keygen -l -f .ssh/known_hosts2 ] ssh-keygen -l -f .ssh/known_hosts2 ] .ssh/known_hosts2 is not a valid key file. Tried against both the public and private key and both with and without the -d option. (Which should only be required for generating keys anyways, right?) Plus I tried it against a personal known_hosts2 file. The man page says nothing about the "-l" option being for RSA keys only. Is this just "not applicable" (yes, I know the KS paper only referred to the SSH 1 protocol, and this is for the SSH 2 protocol) or should I be doing something else, or has something gotten missed in ssh-keygen? I also thought that OpenSSH is suppose to display the system fingerprint the first time you connect to a system: From my workstation Alcove to my Sparc Station Valley: ] [mhw at alcove mhw]$ ssh -V ] SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. ] [mhw at alcove mhw]$ rm .ssh/known_hosts ] You have new mail in /var/spool/mail/mhw ] Compiled with SSL (0x0090600f). ] [mhw at alcove mhw]$ ssh valley.wittsend.com ] Warning: Permanently added 'valley.wittsend.com,130.205.0.39' (RSA) to the list of known hosts. ] mhw at valley.wittsend.com's password: ] [mhw at alcove mhw]$ ssh -2 valley.wittsend.com ] Warning: Permanently added 'valley.wittsend.com,130.205.0.39' (DSA) to the list of known hosts. ] mhw at valley.wittsend.com's password: Tried from another systems: From my server Wittsend to my Sparc Station Valley: ] [mhw at wittsend mhw]$ ssh -V ] SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. ] Compiled with SSL (0x0090581f). ] [mhw at wittsend mhw]$ ssh valley.wittsend.com ] The authenticity of host 'valley.wittsend.com' can't be established. ] RSA key fingerprint is c8:0a:8c:43:de:66:2c:6b:2d:94:71:64:4e:21:60:b8. ] Are you sure you want to continue connecting (yes/no)? yes ] Warning: Permanently added 'valley.wittsend.com,130.205.0.39' (RSA) to the list of known hosts ] mhw at valley.wittsend.com's password: ] [mhw at wittsend mhw]$ ssh -2 valley.wittsend.com ] The authenticity of host 'valley.wittsend.com' can't be established. ] DSA key fingerprint is 21:db:c5:53:54:5c:97:f8:2e:45:5d:57:7d:f7:19:27. ] Are you sure you want to continue connecting (yes/no)? yes ] Warning: Permanently added 'valley.wittsend.com,130.205.0.39' (DSA) to the list of known hosts. ] mhw at valley.wittsend.com's password: So why did one system display the fingerprints (both protocols) and the other system didn't (neither protocols)? Valley is unknown in the global known_hosts file in each case and in each case I get an announcement about adding the host to the know_hosts file. I can't find any difference in my configurations that would prompt this difference in behavior, either. Concerning the known_hosts files... I've found that occasionally I end up with multiple lines with the same key (just different host names or addresses) and sometimes I end up with single lines with multiple names separated by commas, and sometimes both. Is either format preferable over the other? Any reason why NOT to collapse entries with identical keys to a single line? Any reason why NOT to expand all of them to one name or address per line? My personal known_hosts file has over 100 entries and, in a few cases, has duplicate entries (identical lines in every respect including whitespace. In one particular case, I have four consecutive identical lines in that file. ] [mhw at alcove mhw]$ sort -u < .ssh/known_hosts > .ssh/known_hosts.u ] [mhw at alcove mhw]$ wc .ssh/known_hosts .ssh/known_hosts.u ] 104 416 34670 .ssh/known_hosts ] 93 372 31002 .ssh/known_hosts.u ] 197 788 65672 total Any clue why this might happen? This is currently with OpenSSH 2.3.0p1, but I've been using SSH since ssh-1.1.8 (yes, 1.1, not 1.2) days, so there may be some hold over data (like 1023 bit keys and such) from previous ancient versions. Last question... Given SecureDNS as a predicate (ok... Oxymoron with most of the DNS out there, but I have several in several zones.) and given that we can publish keys in the DNS, can OpenSSH use them to validate the host keys? I can do with with FreeS/WAN (Linux IPSec) where I specify to use the host public key from DNS, I was just wondering if that is possible or planned for SSH as well. For zones under my total control, that simplifies my host key management immensely (which is a point in the KS paper). Regards, Mike -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From Jarno.Huuskonen at uku.fi Thu Feb 8 03:24:33 2001 From: Jarno.Huuskonen at uku.fi (Jarno Huuskonen) Date: Wed, 7 Feb 2001 18:24:33 +0200 Subject: DSA Fingerprints... In-Reply-To: <20010207111314.E420@alcove.wittsend.com>; from mhw@wittsend.com on Wed, Feb 07, 2001 at 11:13:14AM -0500 References: <20010207111314.E420@alcove.wittsend.com> Message-ID: <20010207182433.A105608@messi.uku.fi> On Wed, Feb 07, Michael H. Warfield wrote: > Hello, > > Questions, observations, and curiosities. > > Maybe this is something stupid or maybe I'm doing something wrong... > But... In light of the Kurt Seifried paper on SSH and SSL, I was looking > for the finger prints on my various servers and known hosts files to have > a little crib sheet and maybe plug the list into a database on my palm pilot. > I found that ssh-keygen lists out the fingerprints of the RSA keys just fine > but fails when I try to list out fingerprints for the DSA keys, claiming > that this is not a valid key file. AFAIK openssh-2.3.0 ssh-keygen doesn't show the fingerprints for dsa keys. OpenSSH ssh-keygen from the snapshots prints dsa fingerprints just fine. -Jarno -- Jarno Huuskonen - System Administrator | Jarno.Huuskonen at uku.fi University of Kuopio - Computer Center | Work: +358 17 162822 PO BOX 1627, 70211 Kuopio, Finland | Mobile: +358 40 5388169 From mhw at wittsend.com Thu Feb 8 03:32:01 2001 From: mhw at wittsend.com (Michael H. Warfield) Date: Wed, 7 Feb 2001 11:32:01 -0500 Subject: DSA Fingerprints... In-Reply-To: <20010207182433.A105608@messi.uku.fi>; from Jarno.Huuskonen@uku.fi on Wed, Feb 07, 2001 at 06:24:33PM +0200 References: <20010207111314.E420@alcove.wittsend.com> <20010207182433.A105608@messi.uku.fi> Message-ID: <20010207113201.A21100@alcove.wittsend.com> On Wed, Feb 07, 2001 at 06:24:33PM +0200, Jarno Huuskonen wrote: > On Wed, Feb 07, Michael H. Warfield wrote: > > Hello, > > Questions, observations, and curiosities. BTW... I meant to change that subject to be more than just DSA fingerprints after adding all those other questions. :-( Hit the send too fast. > > Maybe this is something stupid or maybe I'm doing something wrong... > > But... In light of the Kurt Seifried paper on SSH and SSL, I was looking > > for the finger prints on my various servers and known hosts files to have > > a little crib sheet and maybe plug the list into a database on my palm pilot. > > I found that ssh-keygen lists out the fingerprints of the RSA keys just fine > > but fails when I try to list out fingerprints for the DSA keys, claiming > > that this is not a valid key file. > AFAIK openssh-2.3.0 ssh-keygen doesn't show the fingerprints for dsa keys. > OpenSSH ssh-keygen from the snapshots prints dsa fingerprints just fine. Great! That means I'm not loosing my mind (well, maybe) and I can expect it in 2.4.0! :-) I go to the bleeding edge snapshots and I get prompted for a user id and password. Seems like I've gotten snapshots before. Maybe that was when the snapshots were on the main ftp site. Or maybe I just went straight to CVS... That's possible too. What's with the password on the snapshots? > -Jarno > -- > Jarno Huuskonen - System Administrator | Jarno.Huuskonen at uku.fi > University of Kuopio - Computer Center | Work: +358 17 162822 > PO BOX 1627, 70211 Kuopio, Finland | Mobile: +358 40 5388169 Mike -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From tom at avatar.itc.nrcs.usda.gov Thu Feb 8 04:29:37 2001 From: tom at avatar.itc.nrcs.usda.gov (Tom Rudnick) Date: Wed, 7 Feb 2001 10:29:37 -0700 (MST) Subject: 'test -S' In-Reply-To: <4.2.0.58.20010204145255.01c90220@127.0.0.1> from "William L. Jones" at Feb 04, 2001 02:55:14 PM Message-ID: <200102071729.KAA19934@avatar.itc.nrcs.usda.gov> > > > What platforms do/don't support 'test -S' (without the addition of the > > > GNU tools)? UnixWare v2.x does not support "test -S" in /bin/sh. It is included in ksh, however. I don't know about UnixWare 7. -- ----------------/---------------------------------------------- Tom Rudnick | USDA Natural Resources Conservation Service Fort Collins,CO | tom at avatar.itc.nrcs.usda.gov (970) 295-5427 ** The 3rd Millennium starts Jan 1, 2001. see: ** ** http://aa.usno.navy.mil/AA/faq/docs/millennium.html ** -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From Darren.Moffat at eng.sun.com Thu Feb 8 05:01:50 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Wed, 7 Feb 2001 10:01:50 -0800 (PST) Subject: DSA Fingerprints... Message-ID: <200102071801.f17I1oR685919@jurassic.eng.sun.com> > Last question... Given SecureDNS as a predicate (ok... Oxymoron >with most of the DNS out there, but I have several in several zones.) and >given that we can publish keys in the DNS, can OpenSSH use them to validate >the host keys? I can do with with FreeS/WAN (Linux IPSec) where I specify >to use the host public key from DNS, I was just wondering if that is >possible or planned for SSH as well. For zones under my total control, >that simplifies my host key management immensely (which is a point in >the KS paper). Currently under discussion in the IETF working group just now as draft-griffin-ssh-host-keys-in-dns-00.txt Got to www.ietf.org to get a copy of the text -- Darren J Moffat From djm at mindrot.org Thu Feb 8 08:27:41 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 8 Feb 2001 08:27:41 +1100 (EST) Subject: sftp client In-Reply-To: <3A816EB4.6030506@skalasoft.com> Message-ID: On Wed, 7 Feb 2001, Roumen Petrov wrote: > Q: Has bash '--norc' option for other/all platforms ? > If this is true attached file is my patch. > > Strange is that only first four bytes form $HOME/.bashrc are send to > client !?!? No - we need to source the shell rc files so we pick up the user's default umask, etc. Please review you shell rc file - no-one else has reported problems using bash as a shell and I have tested it pretty thoroughly. The only time we have found problems is when people have shell init scripts which generate output for non-interactive sessions. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From djm at mindrot.org Thu Feb 8 08:30:21 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 8 Feb 2001 08:30:21 +1100 (EST) Subject: DSA Fingerprints... In-Reply-To: <200102071801.f17I1oR685919@jurassic.eng.sun.com> Message-ID: On Wed, 7 Feb 2001, Darren Moffat wrote: > > Last question... Given SecureDNS as a predicate (ok... Oxymoron > >with most of the DNS out there, but I have several in several zones.) and > >given that we can publish keys in the DNS, can OpenSSH use them to validate > >the host keys? I can do with with FreeS/WAN (Linux IPSec) where I specify > >to use the host public key from DNS, I was just wondering if that is > >possible or planned for SSH as well. For zones under my total control, > >that simplifies my host key management immensely (which is a point in > >the KS paper). > > Currently under discussion in the IETF working group just now as > > draft-griffin-ssh-host-keys-in-dns-00.txt > > Got to www.ietf.org to get a copy of the text I don't know if it is related, but these guys have a working implementation of OpenSSH with DNSSEC key retrieval: http://www.cs.jhu.edu/~smang/sshproject.html -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 wgriffin at tislabs.com Thu Feb 8 09:13:44 2001 From: wgriffin at tislabs.com (Wesley Griffin) Date: Wed, 7 Feb 2001 17:13:44 -0500 Subject: DSA Fingerprints... In-Reply-To: ; from djm@mindrot.org on Thu, Feb 08, 2001 at 08:30:21AM +1100 References: <200102071801.f17I1oR685919@jurassic.eng.sun.com> Message-ID: <20010207171343.Y13249@tislabs.com> * Damien Miller [02/07/01 16:32]: > On Wed, 7 Feb 2001, Darren Moffat wrote: > > > > Last question... Given SecureDNS as a predicate (ok... Oxymoron > > >with most of the DNS out there, but I have several in several zones.) and > > >given that we can publish keys in the DNS, can OpenSSH use them to validate > > >the host keys? I can do with with FreeS/WAN (Linux IPSec) where I specify > > >to use the host public key from DNS, I was just wondering if that is > > >possible or planned for SSH as well. For zones under my total control, > > >that simplifies my host key management immensely (which is a point in > > >the KS paper). > > > > Currently under discussion in the IETF working group just now as > > > > draft-griffin-ssh-host-keys-in-dns-00.txt > > > > Got to www.ietf.org to get a copy of the text > > I don't know if it is related, but these guys have a working implementation > of OpenSSH with DNSSEC key retrieval: > > http://www.cs.jhu.edu/~smang/sshproject.html No, its not related, and I haven't had a chance to look at their code. We're still looking at different ways to do DNSSEC key retrieval with OpenSSH. In our first iteration, we did full DNSSEC verification in the client. It was very messy and not easy to do. Currently we're looking at using BIND9 to do the verification and using TSIG in the ssh client to verify the nameserver query and response. At some point I'm hoping to have some patches to submit that could be considered for inclusion. -- Wesley Griffin NAI Labs wgriffin at tislabs.com 443.259.2388 From tim at multitalents.net Thu Feb 8 09:26:03 2001 From: tim at multitalents.net (Tim Rice) Date: Wed, 7 Feb 2001 14:26:03 -0800 (PST) Subject: 'test -S' In-Reply-To: <200102071729.KAA19934@avatar.itc.nrcs.usda.gov> Message-ID: On Wed, 7 Feb 2001, Tom Rudnick wrote: > > > > What platforms do/don't support 'test -S' (without the addition of the > > > > GNU tools)? > > UnixWare v2.x does not support "test -S" in /bin/sh. > It is included in ksh, however. Ahh, I think I have an idea. (... modify configure.in, test ...) OK, here is a patch that should make the test -S stuff portable. I also added "-o -p $egdsock" to the test for UnixWare. It might not work for everything but it should work for a lot more systems. > > I don't know about UnixWare 7. > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- openssh_cvs/configure.in.old Tue Feb 6 14:54:31 2001 +++ openssh_cvs/configure.in Wed Feb 7 14:00:30 2001 @@ -14,6 +14,9 @@ AC_PATH_PROG(ENT, ent) AC_SUBST(ENT) AC_PATH_PROGS(FILEPRIV, filepriv, true, /sbin:/usr/sbin) +AC_PATH_PROG(TEST_MINUS_S_SH, bash) +AC_PATH_PROG(TEST_MINUS_S_SH, ksh) +AC_PATH_PROG(TEST_MINUS_S_SH, sh) if test -z "$AR" ; then AC_MSG_ERROR([*** 'ar' missing, please install or fix your \$PATH ***]) @@ -1079,8 +1082,8 @@ if test -z "$RANDOM_POOL" ; then AC_MSG_CHECKING(for PRNGD/EGD socket) # Insert other locations here - for egdsock in /var/run/egd-pool /etc/entropy ; do - if test -S $egdsock ; then + for egdsock in /var/run/egd-pool /etc/entropy /tmp/entropy ; do + if $TEST_MINUS_S_SH -c "test -S $egdsock -o -p $egdsock" ; then EGD_SOCKET="$egdsock" AC_DEFINE_UNQUOTED(EGD_SOCKET, "$EGD_SOCKET") AC_MSG_RESULT($egdsock) From mmokrejs at natur.cuni.cz Tue Feb 6 09:01:21 2001 From: mmokrejs at natur.cuni.cz (=?iso-8859-2?Q?Martin_MOKREJ=A9?=) Date: Mon, 5 Feb 2001 23:01:21 +0100 (MET) Subject: Problem compiling openssh on Solaris 2.6 with AFS-krb4 Message-ID: Heelo, I'm trying to copmpile openssh-2.3.0p1 against KTH-KRB dist. (ftp.pdc.kth.se/pub/krb/src) of kerberosIV and AFS 3.6. However, I get two errors: 1. redifinition of types, conflicting with krb.h (which #includes ktypes.h) - removing temporarily the u_int code from ktypes.h helped 2. send_afs_tokens() - in the sshconnect1.c show both problems, although the redefinition problems occured at the early beginning of compilation. Are there any patches available? TIA $ uname -a SunOS pf-i400 5.6 Generic_105181-23 sun4u sparc $ gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gcc version 2.8.1 $ /usr/local/bin/gcc -I/usr/athena/include -L/usr/athena/lib -I/usr/local/include -L/usr/local/lib -I/software/@sys/usr/local/include -L/software/@sys/usr/local/lib -Wall -I. -I. -I/usr/local/include -I/software/@sys/usr/local/include -I/usr/athena/include -I/usr/afsws/include -DETCDIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -DHAVE_CONFIG_H -c sshconnect1.c -o sshconnect1.o In file included from /usr/athena/include/krb.h:17, from ssh.h:523, from sshconnect1.c:25: /usr/athena/include/ktypes.h:14: redefinition of `u_int8_t' defines.h:142: `u_int8_t' previously declared here /usr/athena/include/ktypes.h:15: redefinition of `u_int16_t' defines.h:143: `u_int16_t' previously declared here /usr/athena/include/ktypes.h:16: redefinition of `u_int32_t' defines.h:144: `u_int32_t' previously declared here sshconnect1.c: In function `send_afs_tokens': sshconnect1.c:543: warning: implicit declaration of function `_IOW' sshconnect1.c:543: parse error before `struct' make: *** [sshconnect1.o] Error 1 -- Martin Mokrejs - PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs Faculty of Science, The Charles University From markus.friedl at informatik.uni-erlangen.de Thu Feb 8 09:44:33 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 7 Feb 2001 23:44:33 +0100 Subject: getline In-Reply-To: ; from mouring@etoh.eviladmin.org on Mon, Feb 05, 2001 at 12:35:15PM -0600 References: <3A7E6B39.4090202@skalasoft.com> Message-ID: <20010207234433.H583@folly> On Mon, Feb 05, 2001 at 12:35:15PM -0600, mouring at etoh.eviladmin.org wrote: > > On Mon, 5 Feb 2001, Roumen Petrov wrote: > > > Some system have getline method. > > Place rename 'getline' to 'Linebuf_getline' in ssh-keyscan.c ! > > > > > > > Rename 'getline' to 'Linebug_getline' for consistany and portablity. done. From nathan at rtfm.net Sun Feb 4 06:42:03 2001 From: nathan at rtfm.net (Nathan Dorfman) Date: Sat, 3 Feb 2001 14:42:03 -0500 Subject: OpenSSH 2.3.0p1 on Solaris Message-ID: <20010203144203.A9757@rtfm.net> This appears to have been asked a few times on the mailing lists but never answered/fixed entirely. Running 2.3.0p1 on Solaris 7, I am trying to use the UseLogin server directive (I want /bin/login to be used). The connection succeeds, sshd tries to exec login(1), and I get this: No utmpx entry. You must exec "login" from the lowest level "shell". Connection to x.x.x.x closed. The sshd from ssh-1.2.28 works fine with this directive. Is this a bug or am I missing something? Thanks. -- Nathan Dorfman [http://www.rtfm.net] "The light at the end of the tunnel is the headlight of an approaching train." --/usr/games/fortune From mw at moni.msci.memphis.edu Thu Feb 8 09:59:50 2001 From: mw at moni.msci.memphis.edu (Mate Wierdl) Date: Wed, 7 Feb 2001 16:59:50 -0600 Subject: DSA Fingerprints... In-Reply-To: ; from djm@mindrot.org on Thu, Feb 08, 2001 at 08:30:21AM +1100 References: <200102071801.f17I1oR685919@jurassic.eng.sun.com> Message-ID: <20010207165950.C17027@moni.msci.memphis.edu> On Thu, Feb 08, 2001 at 08:30:21AM +1100, Damien Miller wrote: > I don't know if it is related, but these guys have a working implementation > of OpenSSH with DNSSEC key retrieval: > > http://www.cs.jhu.edu/~smang/sshproject.html I different view on DNSSEC (and other related stuff): http://cr.yp.to/djbdns/forgery.html Mate From djm at mindrot.org Thu Feb 8 10:08:27 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 8 Feb 2001 10:08:27 +1100 (EST) Subject: 'test -S' In-Reply-To: Message-ID: On Wed, 7 Feb 2001, Tim Rice wrote: > On Wed, 7 Feb 2001, Tom Rudnick wrote: > > > > > > What platforms do/don't support 'test -S' (without the addition of the > > > > > GNU tools)? > > > > UnixWare v2.x does not support "test -S" in /bin/sh. > > It is included in ksh, however. > > Ahh, I think I have an idea. (... modify configure.in, test ...) > > OK, here is a patch that should make the test -S stuff portable. > I also added "-o -p $egdsock" to the test for UnixWare. > > It might not work for everything but it should work for a lot more systems. Applied. I would still prefer a truely portable way to detect the socket though. -d -- | Damien Miler \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From tlewis at mindspring.com Thu Feb 8 10:11:18 2001 From: tlewis at mindspring.com (Todd Lewis) Date: Wed, 7 Feb 2001 18:11:18 -0500 (EST) Subject: 'test -S' In-Reply-To: Message-ID: On Thu, 8 Feb 2001, Damien Miller wrote: > I would still prefer a truely portable way to detect the socket though. Not to be old-fashioned or anything, but what about stat(2)? -- 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 From rob at hagopian.net Thu Feb 8 10:19:10 2001 From: rob at hagopian.net (Rob Hagopian) Date: Wed, 7 Feb 2001 18:19:10 -0500 (EST) Subject: sftp client In-Reply-To: <20010207104142.B2239@serv01.aet.tu-cottbus.de> Message-ID: It was fixed, but the .htaccess file got wiped when it resynced... I made the change in apache's conf file so it should stick this time :-) -Rob On Wed, 7 Feb 2001, Lutz Jaenicke wrote: > On Tue, Feb 06, 2001 at 02:28:44PM -0500, Rob Hagopian wrote: > > Yep, my fault (I was protecting other pages on the site), it should be all > > fixed now! > > -Rob > > Sorry, the problem is still not solved. When testing make sure to exit > Netscape, as it caches authentication data and there is no other way to > re-initialize than exiting. > > I have switched to CVS access now. > > Best regards, > Lutz > From djm at mindrot.org Thu Feb 8 10:47:52 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 8 Feb 2001 10:47:52 +1100 (EST) Subject: 'test -S' In-Reply-To: Message-ID: On Wed, 7 Feb 2001, Todd Lewis wrote: > On Thu, 8 Feb 2001, Damien Miller wrote: > > > I would still prefer a truely portable way to detect the socket though. > > Not to be old-fashioned or anything, but what about stat(2)? This is exactly what I had in mind, it is in the TODO now. -d -- | Damien Miler \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From mhw at wittsend.com Thu Feb 8 14:49:14 2001 From: mhw at wittsend.com (Michael H. Warfield) Date: Wed, 7 Feb 2001 22:49:14 -0500 Subject: Daily snapshots... Message-ID: <20010207224914.B12224@alcove.wittsend.com> All, How can I get at the daily snapshots? When I go to the website, www.openssh.com, and follow the Linux link to portable.html and then go to request the daily snapshot from http://bass.directhit.com/openssh_snap/, I get prompted for a user id and password. Needless to say, I ain't got. That's real useful. Use to be, I could get the snapshots from the ftp site. Then things changed and the snapshots were no longer available from the ftp site and I had to go through the web site. Now I can't get them there either. Is there some reason why the daily snaps just keep getting buried deeper and deeper away? IAC... I've also tried cvs and THAT was worse. I could get to cvs and could get the sources, but they currently do not build on my RedHat 6.2 system. After running autoconf and then configure, this is what I get from make: ] [root at alcove openssh_cvs]# make ] (cd openbsd-compat; make) ] make[1]: Entering directory `/mnt1/src/openssh_cvs/openbsd-compat' ] gcc -g -O2 -Wall -I/usr/lib/include -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c -o bsd-arc4random.o bsd-arc4random.c ] In file included from openbsd-compat.h:30, ] from ../includes.h:95, ] from bsd-arc4random.c:25: ] bsd-waitpid.h:38: warning: `WEXITSTATUS' redefined ] /usr/include/sys/wait.h:83: warning: this is the location of the previous definition ] bsd-waitpid.h:39: warning: `WTERMSIG' redefined ] /usr/include/sys/wait.h:84: warning: this is the location of the previous definition ] bsd-waitpid.h:40: warning: `WCOREFLAG' redefined ] /usr/include/sys/wait.h:91: warning: this is the location of the previous definition ] bsd-waitpid.h:41: warning: `WCOREDUMP' redefined ] /usr/include/sys/wait.h:92: warning: this is the location of the previous definition ] In file included from openbsd-compat.h:35, ] from ../includes.h:95, ] from bsd-arc4random.c:25: ] fake-socket.h:9: warning: `_SS_PADSIZE' redefined ] /usr/include/bits/socket.h:151: warning: this is the location of the previous definition ] In file included from openbsd-compat.h:20, ] from ../includes.h:95, ] from bsd-arc4random.c:25: ] strsep.h:7: parse error before `__extension__' ] strsep.h:7: parse error before `(' ] In file included from openbsd-compat.h:21, ] from ../includes.h:95, ] from bsd-arc4random.c:25: ] strtok.h:7: parse error before `__extension__' ] In file included from openbsd-compat.h:28, ] from ../includes.h:95, ] from bsd-arc4random.c:25: ] bsd-misc.h:60: redefinition of `struct timeval' ] bsd-misc.h:66: two or more data types in declaration of `utimes' ] In file included from openbsd-compat.h:35, ] from ../includes.h:95, ] from bsd-arc4random.c:25: ] fake-socket.h:11: redefinition of `struct sockaddr_storage' ] fake-socket.h:25: redefinition of `struct in6_addr' ] fake-socket.h:26: warning: no semicolon at end of struct or union ] fake-socket.h:26: parse error before `.' ] fake-socket.h:31: redefinition of `struct sockaddr_in6' ] make[1]: *** [bsd-arc4random.o] Error 1 ] make[1]: Leaving directory `/mnt1/src/openssh_cvs/openbsd-compat' ] make: *** [openbsd-compat/libopenbsd-compat.a] Error 2 This was my configure command: ./configure --prefix=/usr --sysconfdir=/etc/ssh --with-tcp-wrappers --with-ipv4-default --with-pam --with-skey=/usr/lib (Taken from the RedHat Spec file from the 2.3.0p1 source rpm) This is what it reports when it's finished configuring: ] OpenSSH configured has been configured with the following options. ] User binaries: /usr/bin ] User binaries: /usr/bin ] System binaries: /usr/sbin ] Configuration files: /etc/ssh ] Askpass program: /usr/libexec/ssh-askpass ] Manual pages: /usr/man/manX ] PID file: /var/run ] Random number collection: Device (/dev/urandom) ] Manpage format: man ] PAM support: yes ] KerberosIV support: no ] AFS support: no ] S/KEY support: yes ] TCP Wrappers support: yes ] MD5 password support: no ] IP address in $DISPLAY hack: no ] Use IPv4 by default hack: yes ] Translate v4 in v6 hack: yes ] ] Host: i586-pc-linux-gnu ] Compiler: gcc ] Compiler flags: -g -O2 -Wall ] Preprocessor flags: -I/usr/lib/include ] Linker flags: -L/usr/lib/lib ] Libraries: -lskey -lpam -ldl -lz -lnsl -lutil -lcrypto -lwrap ] ] PAM is enabled. You may need to install a PAM control file for sshd, ] otherwise password authentication may fail. Example PAM control files ] can be found in the contrib/ subdirectory So cvs is no joy here either. Anyone with some suggestions... Mike -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From djm at mindrot.org Thu Feb 8 15:33:15 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 8 Feb 2001 15:33:15 +1100 (EST) Subject: Daily snapshots... In-Reply-To: <20010207224914.B12224@alcove.wittsend.com> Message-ID: On Wed, 7 Feb 2001, Michael H. Warfield wrote: > ] [root at alcove openssh_cvs]# make > ] (cd openbsd-compat; make) > ] make[1]: Entering directory `/mnt1/src/openssh_cvs/openbsd-compat' > ] gcc -g -O2 -Wall -I/usr/lib/include -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c -o bsd-arc4random.o bsd-arc4random.c > ] In file included from openbsd-compat.h:30, > ] from ../includes.h:95, > ] from bsd-arc4random.c:25: > ] bsd-waitpid.h:38: warning: `WEXITSTATUS' redefined > ] /usr/include/sys/wait.h:83: warning: this is the location of the previous definition Could you send in the full output of a ./configure run? Thanks, Damien -- | Damien Miler \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From mhw at wittsend.com Thu Feb 8 16:16:08 2001 From: mhw at wittsend.com (Michael H. Warfield) Date: Thu, 8 Feb 2001 00:16:08 -0500 Subject: Daily snapshots... In-Reply-To: ; from djm@mindrot.org on Thu, Feb 08, 2001 at 03:33:15PM +1100 References: <20010207224914.B12224@alcove.wittsend.com> Message-ID: <20010208001608.C12224@alcove.wittsend.com> On Thu, Feb 08, 2001 at 03:33:15PM +1100, Damien Miller wrote: > On Wed, 7 Feb 2001, Michael H. Warfield wrote: > > ] [root at alcove openssh_cvs]# make > > ] (cd openbsd-compat; make) > > ] make[1]: Entering directory `/mnt1/src/openssh_cvs/openbsd-compat' > > ] gcc -g -O2 -Wall -I/usr/lib/include -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c -o bsd-arc4random.o bsd-arc4random.c > > ] In file included from openbsd-compat.h:30, > > ] from ../includes.h:95, > > ] from bsd-arc4random.c:25: > > ] bsd-waitpid.h:38: warning: `WEXITSTATUS' redefined > > ] /usr/include/sys/wait.h:83: warning: this is the location of the previous definition > Could you send in the full output of a ./configure run? You got it... Attached... Output of the following command is attached below: ./configure --prefix=/usr --sysconfdir=/etc/ssh --with-tcp-wrappers --with-ipv4-default --with-pam --with-skey=/usr/lib > /tmp/config.out 2>&1 > Thanks, > Damien > -- > | Damien Miler \ ``E-mail attachments are the poor man's > | http://www.mindrot.org / distributed filesystem'' - Dan Geer Mike -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! -------------- next part -------------- creating 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... i586-pc-linux-gnu checking how to run the C preprocessor... gcc -E checking for ranlib... ranlib checking for a BSD compatible install... /usr/bin/install -c checking for ar... /usr/bin/ar checking for perl... /usr/bin/perl checking for ent... no checking for filepriv... no checking for bash... /bin/bash checking for ksh... (cached) /bin/bash checking for sh... (cached) /bin/bash checking for login... /bin/login checking for inline... inline checking for yp_match in -lnsl... yes checking for main in -lsocket... no checking for getspnam in -lgen... no checking for deflate in -lz... yes checking for login in -lutil... yes checking for regcomp... yes checking for strcasecmp... yes checking for utimes... yes checking for bstring.h... no checking for endian.h... yes checking for floatingpoint.h... no checking for getopt.h... yes checking for lastlog.h... yes checking for limits.h... yes checking for login.h... no checking for login_cap.h... no checking for maillock.h... no checking for netdb.h... yes checking for netgroup.h... no checking for netinet/in_systm.h... yes checking for paths.h... yes checking for poll.h... yes checking for pty.h... yes checking for regex.h... yes checking for shadow.h... yes checking for security/pam_appl.h... yes checking for sys/bitypes.h... yes checking for sys/bsdtty.h... no checking for sys/cdefs.h... yes checking for sys/poll.h... yes checking for sys/queue.h... yes checking for sys/select.h... yes checking for sys/stat.h... yes checking for sys/stropts.h... yes checking for sys/sysmacros.h... yes checking for sys/time.h... yes checking for sys/ttcompat.h... no checking for sys/un.h... yes checking for stddef.h... yes checking for time.h... yes checking for ttyent.h... yes checking for usersec.h... no checking for util.h... no checking for utime.h... yes checking for utmp.h... yes checking for utmpx.h... yes checking for vis.h... no checking for arc4random... no checking for atexit... yes checking for b64_ntop... no checking for bcopy... yes checking for bindresvport_sa... no checking for clock... yes checking for fchmod... yes checking for freeaddrinfo... yes checking for futimes... no checking for gai_strerror... yes checking for getcwd... yes checking for getaddrinfo... yes checking for getgrouplist... no checking for getnameinfo... yes checking for getrlimit... yes checking for getrusage... yes checking for getttyent... yes checking for inet_aton... yes checking for inet_ntoa... yes checking for innetgr... yes checking for login_getcapbool... no checking for md5_crypt... no checking for memmove... yes checking for mkdtemp... no checking for on_exit... yes checking for openpty... yes checking for realpath... yes checking for rresvport_af... no checking for setdtablesize... no checking for setenv... yes checking for seteuid... yes checking for setlogin... no checking for setproctitle... no checking for setreuid... yes checking for setrlimit... yes checking for setsid... yes checking for sigaction... yes checking for sigvec... yes checking for snprintf... yes checking for strerror... yes checking for strlcat... no checking for strlcpy... no checking for strmode... no checking for strsep... yes checking for strtok_r... yes checking for sysconf... yes checking for tcgetpgrp... yes checking for utimes... (cached) yes checking for vsnprintf... yes checking for vhangup... yes checking for vis... no checking for waitpid... yes checking for _getpty... no checking for __b64_ntop... no checking for gettimeofday... yes checking for time... yes checking for libutil.h... no checking for login... yes checking for logout... yes checking for updwtmp... yes checking for logwtmp... yes checking for endutent... yes checking for getutent... yes checking for getutid... yes checking for getutline... yes checking for pututline... yes checking for setutent... yes checking for utmpname... yes checking for endutxent... yes checking for getutxent... yes checking for getutxid... yes checking for getutxline... yes checking for pututxline... yes checking for setutxent... yes checking for utmpxname... yes checking for getuserattr... no checking for getuserattr in -ls... no checking for login... (cached) yes checking for daemon... yes checking for getpagesize... yes checking whether snprintf correctly terminates long strings... yes checking whether getpgrp takes no argument... yes checking for strftime... yes checking for dlopen in -ldl... yes checking for pam_set_item in -lpam... yes checking for pam_getenvlist... yes checking whether pam_strerror takes only one argument... no checking for OpenSSL directory... /usr checking for RSA support... yes checking size of char... 1 checking size of short int... 2 checking size of int... 4 checking size of long int... 4 checking size of long long int... 8 checking for u_int type... yes checking for intXX_t types... yes checking for int64_t type... yes checking for u_intXX_t types... yes checking for u_int64_t types... yes checking for socklen_t... yes checking for size_t... yes checking for ssize_t... yes checking for clock_t... yes checking for sa_family_t... yes checking for pid_t... yes checking for mode_t... yes checking for struct sockaddr_storage... yes checking for struct sockaddr_in6... yes checking for struct in6_addr... yes checking for struct addrinfo... yes checking for struct timeval... yes checking for ut_host field in utmp.h... yes checking for ut_host field in utmpx.h... yes checking for syslen field in utmpx.h... no checking for ut_pid field in utmp.h... yes checking for ut_type field in utmp.h... yes checking for ut_type field in utmpx.h... yes checking for ut_tv field in utmp.h... yes checking for ut_id field in utmp.h... yes checking for ut_id field in utmpx.h... yes checking for ut_addr field in utmp.h... yes checking for ut_addr field in utmpx.h... yes checking for ut_addr_v6 field in utmp.h... yes checking for ut_addr_v6 field in utmpx.h... yes checking for ut_exit field in utmp.h... yes checking for ut_time field in utmp.h... no checking for ut_time field in utmpx.h... no checking for ut_tv field in utmpx.h... yes checking for st_blksize in struct stat... yes checking for sun_len field in struct sockaddr_un... no checking for ss_family field in struct sockaddr_storage... no checking for __ss_family field in struct sockaddr_storage... yes checking for pw_class field in struct passwd... no checking if libc defines __progname... yes checking if libc defines sys_errlist... yes checking if libc defines sys_nerr... yes checking for rsh... /usr/kerberos/bin/rsh checking for xauth... /usr/X11R6/bin/xauth checking for /dev/ptc... no checking for /dev/urandom... yes checking for skey_keyinfo... yes checking for libwrap... yes checking if we need to convert IPv4 in IPv6-mapped addresses... yes (default) checking whether to install ssh as suid root... yes checking if your system defines LASTLOG_FILE... no checking if your system defines _PATH_LASTLOG... yes checking if your system defines UTMP_FILE... yes checking if your system defines WTMP_FILE... yes checking if your system defines UTMPX_FILE... no checking if your system defines WTMPX_FILE... no checking for Cygwin environment... no checking for mingw32 environment... no checking for executable suffix... no updating cache ./config.cache creating ./config.status creating Makefile creating openbsd-compat/Makefile creating ssh_prng_cmds creating config.h cat: ./config.h.in: No such file or directory OpenSSH configured has been configured with the following options. User binaries: /usr/bin User binaries: /usr/bin System binaries: /usr/sbin Configuration files: /etc/ssh Askpass program: /usr/libexec/ssh-askpass Manual pages: /usr/man/manX PID file: /var/run Random number collection: Device (/dev/urandom) Manpage format: man PAM support: yes KerberosIV support: no AFS support: no S/KEY support: yes TCP Wrappers support: yes MD5 password support: no IP address in $DISPLAY hack: no Use IPv4 by default hack: yes Translate v4 in v6 hack: yes Host: i586-pc-linux-gnu Compiler: gcc Compiler flags: -g -O2 -Wall Preprocessor flags: -I/usr/lib/include Linker flags: -L/usr/lib/lib Libraries: -lskey -lpam -ldl -lz -lnsl -lutil -lcrypto -lwrap PAM is enabled. You may need to install a PAM control file for sshd, otherwise password authentication may fail. Example PAM control files can be found in the contrib/ subdirectory From rob at hagopian.net Thu Feb 8 18:26:09 2001 From: rob at hagopian.net (Rob Hagopian) Date: Thu, 8 Feb 2001 02:26:09 -0500 (EST) Subject: Daily snapshots... In-Reply-To: <20010207224914.B12224@alcove.wittsend.com> Message-ID: OK, I finally fixed this for good by rearranging stuff on the site... The URL you have hasn't changed... sorry for the screw up! -Rob On Wed, 7 Feb 2001, Michael H. Warfield wrote: > All, > > How can I get at the daily snapshots? > > When I go to the website, www.openssh.com, and follow the Linux > link to portable.html and then go to request the daily snapshot from > http://bass.directhit.com/openssh_snap/, I get prompted for a user id > and password. Needless to say, I ain't got. > > That's real useful. Use to be, I could get the snapshots from > the ftp site. Then things changed and the snapshots were no longer > available from the ftp site and I had to go through the web site. Now > I can't get them there either. Is there some reason why the daily > snaps just keep getting buried deeper and deeper away? > > IAC... I've also tried cvs and THAT was worse. I could get to > cvs and could get the sources, but they currently do not build on my > RedHat 6.2 system. After running autoconf and then configure, this > is what I get from make: > > ] [root at alcove openssh_cvs]# make > ] (cd openbsd-compat; make) > ] make[1]: Entering directory `/mnt1/src/openssh_cvs/openbsd-compat' > ] gcc -g -O2 -Wall -I/usr/lib/include -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c -o bsd-arc4random.o bsd-arc4random.c > ] In file included from openbsd-compat.h:30, > ] from ../includes.h:95, > ] from bsd-arc4random.c:25: > ] bsd-waitpid.h:38: warning: `WEXITSTATUS' redefined > ] /usr/include/sys/wait.h:83: warning: this is the location of the previous definition > ] bsd-waitpid.h:39: warning: `WTERMSIG' redefined > ] /usr/include/sys/wait.h:84: warning: this is the location of the previous definition > ] bsd-waitpid.h:40: warning: `WCOREFLAG' redefined > ] /usr/include/sys/wait.h:91: warning: this is the location of the previous definition > ] bsd-waitpid.h:41: warning: `WCOREDUMP' redefined > ] /usr/include/sys/wait.h:92: warning: this is the location of the previous definition > ] In file included from openbsd-compat.h:35, > ] from ../includes.h:95, > ] from bsd-arc4random.c:25: > ] fake-socket.h:9: warning: `_SS_PADSIZE' redefined > ] /usr/include/bits/socket.h:151: warning: this is the location of the previous definition > ] In file included from openbsd-compat.h:20, > ] from ../includes.h:95, > ] from bsd-arc4random.c:25: > ] strsep.h:7: parse error before `__extension__' > ] strsep.h:7: parse error before `(' > ] In file included from openbsd-compat.h:21, > ] from ../includes.h:95, > ] from bsd-arc4random.c:25: > ] strtok.h:7: parse error before `__extension__' > ] In file included from openbsd-compat.h:28, > ] from ../includes.h:95, > ] from bsd-arc4random.c:25: > ] bsd-misc.h:60: redefinition of `struct timeval' > ] bsd-misc.h:66: two or more data types in declaration of `utimes' > ] In file included from openbsd-compat.h:35, > ] from ../includes.h:95, > ] from bsd-arc4random.c:25: > ] fake-socket.h:11: redefinition of `struct sockaddr_storage' > ] fake-socket.h:25: redefinition of `struct in6_addr' > ] fake-socket.h:26: warning: no semicolon at end of struct or union > ] fake-socket.h:26: parse error before `.' > ] fake-socket.h:31: redefinition of `struct sockaddr_in6' > ] make[1]: *** [bsd-arc4random.o] Error 1 > ] make[1]: Leaving directory `/mnt1/src/openssh_cvs/openbsd-compat' > ] make: *** [openbsd-compat/libopenbsd-compat.a] Error 2 > > This was my configure command: > > ./configure --prefix=/usr --sysconfdir=/etc/ssh --with-tcp-wrappers --with-ipv4-default --with-pam --with-skey=/usr/lib > > (Taken from the RedHat Spec file from the 2.3.0p1 source rpm) > > This is what it reports when it's finished configuring: > > > ] OpenSSH configured has been configured with the following options. > ] User binaries: /usr/bin > ] User binaries: /usr/bin > ] System binaries: /usr/sbin > ] Configuration files: /etc/ssh > ] Askpass program: /usr/libexec/ssh-askpass > ] Manual pages: /usr/man/manX > ] PID file: /var/run > ] Random number collection: Device (/dev/urandom) > ] Manpage format: man > ] PAM support: yes > ] KerberosIV support: no > ] AFS support: no > ] S/KEY support: yes > ] TCP Wrappers support: yes > ] MD5 password support: no > ] IP address in $DISPLAY hack: no > ] Use IPv4 by default hack: yes > ] Translate v4 in v6 hack: yes > ] > ] Host: i586-pc-linux-gnu > ] Compiler: gcc > ] Compiler flags: -g -O2 -Wall > ] Preprocessor flags: -I/usr/lib/include > ] Linker flags: -L/usr/lib/lib > ] Libraries: -lskey -lpam -ldl -lz -lnsl -lutil -lcrypto -lwrap > ] > ] PAM is enabled. You may need to install a PAM control file for sshd, > ] otherwise password authentication may fail. Example PAM control files > ] can be found in the contrib/ subdirectory > > So cvs is no joy here either. > > Anyone with some suggestions... > > Mike > From roumen.petrov at skalasoft.com Thu Feb 8 21:40:18 2001 From: roumen.petrov at skalasoft.com (Roumen Petrov) Date: Thu, 08 Feb 2001 12:40:18 +0200 Subject: sftp client References: Message-ID: <3A827792.3090303@skalasoft.com> 1.) test.c: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ #include #define MAX_ARR 5 char *argv[MAX_ARR]; char *env[MAX_ARR]; main () { char **p; argv[0] = "bash"; argv[1] = "-c"; argv[2] = "ls ~/.bashrc"; argv[3] = 0; env[0] = "SSH_CLIENT="; env[1] = 0; for ( p = env; *p; p++ ) printf ( "env:%s\n", *p ); printf ( "-----------------------------\n" ); execve("/bin/bash", argv, env); return 1; } ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2.) Ben what is result result from this program, if $HOME/.bashrc has line with echo ? Example for ~/.bashrc: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ echo "Executing $HOME/.bashrc ..." ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3.) My result is: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ env:SSH2_CLIENT= ----------------------------- Executing /.bashrc ... /root/.bashrc ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.) And result from 'sftp localhost' is: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Connecting to localhost... ...... Received message too long 1165518179 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 5.) info: 1165518179 = 0x45786563 = "Exec" !!!! Damien Miller wrote: > On Wed, 7 Feb 2001, Roumen Petrov wrote: > > >> Q: Has bash '--norc' option for other/all platforms ? >> If this is true attached file is my patch. >> >> Strange is that only first four bytes form $HOME/.bashrc are send to >> client !?!? > > > No - we need to source the shell rc files so we pick up the user's > default umask, etc. > > Please review you shell rc file - no-one else has reported problems > using bash as a shell and I have tested it pretty thoroughly. The only > time we have found problems is when people have shell init scripts > which generate output for non-interactive sessions. > > -d From Jarno.Huuskonen at uku.fi Thu Feb 8 22:31:14 2001 From: Jarno.Huuskonen at uku.fi (Jarno Huuskonen) Date: Thu, 8 Feb 2001 13:31:14 +0200 Subject: ssh1 keyexchange problem ? Message-ID: <20010208133114.A71432@messi.uku.fi> Hi, Has anybody produced diffs for openssh-2.3.0p1 for the rsa keyexchange problem that Core-SDI described ? ( I noticed that fix is already in openbsd tree ). -Jarno -- Jarno Huuskonen - System Administrator | Jarno.Huuskonen at uku.fi University of Kuopio - Computer Center | Work: +358 17 162822 PO BOX 1627, 70211 Kuopio, Finland | Mobile: +358 40 5388169 From Markus.Friedl at informatik.uni-erlangen.de Fri Feb 9 00:05:17 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 8 Feb 2001 14:05:17 +0100 Subject: next build In-Reply-To: ; from distler@golem.ph.utexas.edu on Sun, Feb 04, 2001 at 04:31:02PM -0600 References: Message-ID: <20010208140517.A8818@faui02.informatik.uni-erlangen.de> On Sun, Feb 04, 2001 at 04:31:02PM -0600, Jacques Distler wrote: > I have sshd configured to log to LOCAL0. With the 20010119 snapshot > and earlier, it works fine. With later builds, the daemon seems to > function OK, but *nothing* gets logged to LOCAL0. Instead, I get the > following error messages logged to /usr/adm/mesages every time a > client connects to the daemon: > > Feb 4 00:23:45 golem sshd[17861]: error: Hm, dispatch protocol > error: type 50 plen 516 > Feb 4 00:23:45 golem sshd[17861]: error: Hm, dispatch protocol > error: type 50 plen 550 what client versions? do you have ssh -v and/or sshd -d output? -m From mhw at wittsend.com Fri Feb 9 00:25:51 2001 From: mhw at wittsend.com (Michael H. Warfield) Date: Thu, 8 Feb 2001 08:25:51 -0500 Subject: Daily snapshots... In-Reply-To: ; from rob@hagopian.net on Thu, Feb 08, 2001 at 02:26:09AM -0500 References: <20010207224914.B12224@alcove.wittsend.com> Message-ID: <20010208082551.F12224@alcove.wittsend.com> On Thu, Feb 08, 2001 at 02:26:09AM -0500, Rob Hagopian wrote: > OK, I finally fixed this for good by rearranging stuff on the site... The > URL you have hasn't changed... sorry for the screw up! > -Rob Got it! Thanks! [...] Mike -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From Markus.Friedl at informatik.uni-erlangen.de Fri Feb 9 00:31:29 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 8 Feb 2001 14:31:29 +0100 Subject: argv[0] => host feature considered harmful In-Reply-To: <20010206121740.B59281@lizzy.bugworks.com>; from josb@cncdsl.com on Tue, Feb 06, 2001 at 12:17:40PM -0800 References: <20010206121740.B59281@lizzy.bugworks.com> Message-ID: <20010208143129.A9974@faui02.informatik.uni-erlangen.de> hi, do we care about 'argv[0] => host'. i don't like it but it seems to be to late to drop this rlogin-compatible feature. a new option seems the only good option. On Tue, Feb 06, 2001 at 12:17:40PM -0800, Jos Backus wrote: > OpenSSH still has this feature, SSH-1.2.27 no longer has it. Admittedly it > can be useful sometimes, even though I'd prefer this to be done using a > trivial shell wrapper, which would be the UNIX way of doing things. > > Not being able to call OpenSSH's ssh by another name (say ``ssh1'') can get in > the way when having to maintain two versions of ssh in parallel because the > ``ssh -> ssh1'' symlink trick doesn't work (ssh gives a ``bad hostname: ssh1'' > error message). > > How do others feel about at least conditionalizing this feature? I can come up > with a patch if needed. > > Thanks, > -- > Jos Backus _/ _/_/_/ "Modularity is not a hack." > _/ _/ _/ -- D. J. Bernstein > _/ _/_/_/ > _/ _/ _/ _/ > josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From deraadt at cvs.openbsd.org Fri Feb 9 00:33:18 2001 From: deraadt at cvs.openbsd.org (Theo de Raadt) Date: Thu, 8 Feb 2001 06:33:18 -0700 (MST) Subject: argv[0] => host feature considered harmful Message-ID: <200102081333.f18DXIp18996@cvs.openbsd.org> >do we care about 'argv[0] => host'. >i don't like it but it seems to be to late to drop this >rlogin-compatible feature. a new option seems the only >good option. I would have no problem with seeing it go away. From douglas.manton at uk.ibm.com Fri Feb 9 00:36:04 2001 From: douglas.manton at uk.ibm.com (douglas.manton at uk.ibm.com) Date: Thu, 8 Feb 2001 13:36:04 +0000 Subject: sshd hanging after multiple successive logons Message-ID: <802569ED.004ABFAE.00@d06mta05.portsmouth.uk.ibm.com> Damien, I was able to confirm this problem was caused by a deadlock when key regeneration began during a client logon. I set the key regeneration interval to 15 seconds and kicked-off the logon script. It took between 2 and 4 minutes for sshd to hang! The good news is that I ran the latest snapshot under the same conditions. It has been working for two hours and still going strong. Prognosis: cured. I look forward to the next release :-) Thanks for your help, -------------------------------------------------------- Doug Manton, AT&T EMEA Firewall and Security Solutions E: demanton at att.com -------------------------------------------------------- "If privacy is outlawed, only outlaws will have privacy" From Markus.Friedl at informatik.uni-erlangen.de Fri Feb 9 00:46:14 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 8 Feb 2001 14:46:14 +0100 Subject: OpenSSH 2.3.0p1: bla bla In-Reply-To: <3A806DB5.6DE562FE@club-internet.fr>; from dpo@club-internet.fr on Tue, Feb 06, 2001 at 10:33:41PM +0100 References: <3A806DB5.6DE562FE@club-internet.fr> Message-ID: <20010208144614.A11231@faui02.informatik.uni-erlangen.de> On Tue, Feb 06, 2001 at 10:33:41PM +0100, Dimitri Papadopoulos wrote: > I see the code is in serverloop.c and looks like > packet_put_int(SSH2_OPEN_ADMINISTRATIVELY_PROHIBITED); > packet_put_cstring("bla bla"); > which seems to indicate the server is badly configurated. However I > think a more informative message would be more appropriate... yes, i did not care when i wrote these lines. just replace "bla bla" with "". -m From Markus.Friedl at informatik.uni-erlangen.de Fri Feb 9 00:53:59 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 8 Feb 2001 14:53:59 +0100 Subject: ssh1 keyexchange problem ? In-Reply-To: <20010208133114.A71432@messi.uku.fi>; from Jarno.Huuskonen@uku.fi on Thu, Feb 08, 2001 at 01:31:14PM +0200 References: <20010208133114.A71432@messi.uku.fi> Message-ID: <20010208145359.A11705@faui02.informatik.uni-erlangen.de> On Thu, Feb 08, 2001 at 01:31:14PM +0200, Jarno Huuskonen wrote: > Hi, > > Has anybody produced diffs for openssh-2.3.0p1 for the rsa keyexchange > problem that Core-SDI described ? ( I noticed that fix is already > in openbsd tree ). > > -Jarno > > -- > Jarno Huuskonen - System Administrator | Jarno.Huuskonen at uku.fi > University of Kuopio - Computer Center | Work: +358 17 162822 > PO BOX 1627, 70211 Kuopio, Finland | Mobile: +358 40 5388169 > this one should help. the fix from the advisory should help, too (just move the 'kill' to rsa.c). Index: rsa.c =================================================================== RCS file: /home/markus/cvs/ssh/rsa.c,v retrieving revision 1.18 diff -u -r1.18 rsa.c --- rsa.c 2000/12/19 23:17:57 1.18 +++ rsa.c 2001/01/20 18:59:12 @@ -94,7 +94,7 @@ xfree(inbuf); } -void +int rsa_private_decrypt(BIGNUM *out, BIGNUM *in, RSA *key) { u_char *inbuf, *outbuf; @@ -108,13 +108,14 @@ BN_bn2bin(in, inbuf); if ((len = RSA_private_decrypt(ilen, inbuf, outbuf, key, - RSA_PKCS1_PADDING)) <= 0) - fatal("rsa_private_decrypt() failed"); - - BN_bin2bn(outbuf, len, out); - + RSA_PKCS1_PADDING)) <= 0) { + error("rsa_private_decrypt() failed"); + } else { + BN_bin2bn(outbuf, len, out); + } memset(outbuf, 0, olen); memset(inbuf, 0, ilen); xfree(outbuf); xfree(inbuf); + return len; } Index: rsa.h =================================================================== RCS file: /home/markus/cvs/ssh/rsa.h,v retrieving revision 1.9 diff -u -r1.9 rsa.h --- rsa.h 2000/11/12 19:50:38 1.9 +++ rsa.h 2001/01/20 17:12:23 @@ -20,6 +20,6 @@ #include void rsa_public_encrypt __P((BIGNUM * out, BIGNUM * in, RSA * prv)); -void rsa_private_decrypt __P((BIGNUM * out, BIGNUM * in, RSA * prv)); +int rsa_private_decrypt __P((BIGNUM * out, BIGNUM * in, RSA * prv)); #endif /* RSA_H */ Index: ssh-agent.c =================================================================== RCS file: /home/markus/cvs/ssh/ssh-agent.c,v retrieving revision 1.46 diff -u -r1.46 ssh-agent.c --- ssh-agent.c 2001/01/11 21:37:30 1.46 +++ ssh-agent.c 2001/01/20 18:59:26 @@ -195,7 +195,8 @@ private = lookup_private_key(key, NULL, 1); if (private != NULL) { /* Decrypt the challenge using the private key. */ - rsa_private_decrypt(challenge, challenge, private->rsa); + if (rsa_private_decrypt(challenge, challenge, private->rsa) <= 0) + goto failure; /* The response is MD5 of decrypted challenge plus session id. */ len = BN_num_bytes(challenge); Index: sshconnect1.c =================================================================== RCS file: /home/markus/cvs/ssh/sshconnect1.c,v retrieving revision 1.17 diff -u -r1.17 sshconnect1.c --- sshconnect1.c 2001/01/19 15:55:12 1.17 +++ sshconnect1.c 2001/01/20 18:59:31 @@ -153,14 +153,17 @@ int i, len; /* Decrypt the challenge using the private key. */ - rsa_private_decrypt(challenge, challenge, prv); + /* XXX think about Bleichenbacher, too */ + if (rsa_private_decrypt(challenge, challenge, prv) <= 0) + packet_disconnect( + "respond_to_rsa_challenge: rsa_private_decrypt failed"); /* Compute the response. */ /* The response is MD5 of decrypted challenge plus session id. */ len = BN_num_bytes(challenge); if (len <= 0 || len > sizeof(buf)) - packet_disconnect("respond_to_rsa_challenge: bad challenge length %d", - len); + packet_disconnect( + "respond_to_rsa_challenge: bad challenge length %d", len); memset(buf, 0, sizeof(buf)); BN_bn2bin(challenge, buf + sizeof(buf) - len); Index: sshd.c =================================================================== RCS file: /home/markus/cvs/ssh/sshd.c,v retrieving revision 1.154 diff -u -r1.154 sshd.c --- sshd.c 2001/01/19 15:55:12 1.154 +++ sshd.c 2001/01/20 20:32:29 @@ -1163,6 +1163,7 @@ { int i, len; int plen, slen; + int rsafail = 0; BIGNUM *session_key_int; u_char session_key[SSH_SESSION_KEY_LENGTH]; u_char cookie[8]; @@ -1273,7 +1274,7 @@ * with larger modulus first). */ if (BN_cmp(sensitive_data.server_key->rsa->n, sensitive_data.ssh1_host_key->rsa->n) > 0) { - /* Private key has bigger modulus. */ + /* Server key has bigger modulus. */ if (BN_num_bits(sensitive_data.server_key->rsa->n) < BN_num_bits(sensitive_data.ssh1_host_key->rsa->n) + SSH_KEY_BITS_RESERVED) { fatal("do_connection: %s: server_key %d < host_key %d + SSH_KEY_BITS_RESERVED %d", @@ -1282,10 +1283,12 @@ BN_num_bits(sensitive_data.ssh1_host_key->rsa->n), SSH_KEY_BITS_RESERVED); } - rsa_private_decrypt(session_key_int, session_key_int, - sensitive_data.server_key->rsa); - rsa_private_decrypt(session_key_int, session_key_int, - sensitive_data.ssh1_host_key->rsa); + if (rsa_private_decrypt(session_key_int, session_key_int, + sensitive_data.server_key->rsa) <= 0) + rsafail++; + if (rsa_private_decrypt(session_key_int, session_key_int, + sensitive_data.ssh1_host_key->rsa) <= 0) + rsafail++; } else { /* Host key has bigger modulus (or they are equal). */ if (BN_num_bits(sensitive_data.ssh1_host_key->rsa->n) < @@ -1296,10 +1299,12 @@ BN_num_bits(sensitive_data.server_key->rsa->n), SSH_KEY_BITS_RESERVED); } - rsa_private_decrypt(session_key_int, session_key_int, - sensitive_data.ssh1_host_key->rsa); - rsa_private_decrypt(session_key_int, session_key_int, - sensitive_data.server_key->rsa); + if (rsa_private_decrypt(session_key_int, session_key_int, + sensitive_data.ssh1_host_key->rsa) < 0) + rsafail++; + if (rsa_private_decrypt(session_key_int, session_key_int, + sensitive_data.server_key->rsa) < 0) + rsafail++; } compute_session_id(session_id, cookie, @@ -1314,15 +1319,29 @@ * least significant 256 bits of the integer; the first byte of the * key is in the highest bits. */ - BN_mask_bits(session_key_int, sizeof(session_key) * 8); - len = BN_num_bytes(session_key_int); - if (len < 0 || len > sizeof(session_key)) - fatal("do_connection: bad len from %s: session_key_int %d > sizeof(session_key) %d", - get_remote_ipaddr(), - len, sizeof(session_key)); - memset(session_key, 0, sizeof(session_key)); - BN_bn2bin(session_key_int, session_key + sizeof(session_key) - len); - + if (!rsafail) { + BN_mask_bits(session_key_int, sizeof(session_key) * 8); + len = BN_num_bytes(session_key_int); + if (len < 0 || len > sizeof(session_key)) { + error("do_connection: bad session key len from %s: " + "session_key_int %d > sizeof(session_key) %d", + get_remote_ipaddr(), len, sizeof(session_key)); + rsafail++; + } else { + memset(session_key, 0, sizeof(session_key)); + BN_bn2bin(session_key_int, + session_key + sizeof(session_key) - len); + } + } + if (rsafail) { + log("do_connection: generating a fake encryption key"); + for (i = 0; i < SSH_SESSION_KEY_LENGTH; i++) { + if (i % 4 == 0) + rand = arc4random(); + session_key[i] = rand & 0xff; + rand >>= 8; + } + } /* Destroy the decrypted integer. It is no longer needed. */ BN_clear_free(session_key_int); From tatjana.svizensky at arcs.ac.at Fri Feb 9 00:56:18 2001 From: tatjana.svizensky at arcs.ac.at (tatjana.svizensky at arcs.ac.at) Date: Thu, 8 Feb 2001 14:56:18 +0100 Subject: question re:scp Message-ID: <20010208145618.I18379@inuyasha.arcs.ac.at> I'm forwarding this as instructed ;) ----- Forwarded message from Markus Friedl ----- Date: Thu, 8 Feb 2001 14:56:20 +0100 From: Markus Friedl To: tatjana.svizensky at arcs.ac.at Subject: Re: ssh question re: scp In-Reply-To: <20010208145142.G18379 at inuyasha.arcs.ac.at>; from tatjana.svizensky at arcs.ac.at on Thu, Feb 08, 2001 at 02:51:42PM +0100 ok, please this report send to openssh-unix-dev at mindrot.org thanks, -m On Thu, Feb 08, 2001 at 02:51:42PM +0100, tatjana.svizensky at arcs.ac.at wrote: > > > > > On Thu, Feb 08, 2001 at 02:09:49PM +0100, Markus Friedl wrote: > > > > > > hi, > > > > does > > $ ssh host 'cat file' > file > > > > work for files > 1GB > > > Don't see why not, as ssh host 'tar cvf - somefiles' | dd of=someotherfile.tar works just fine. > The problem is with: > > inuyasha:/mnt/vortex/backup # scp ttsrvun1:/mnt/storage/backup/zditf2usrusers.dump . > zditf2usrusers.dump 0% | | 0 --:-- ETA > protocol error: expected control record > Write failed flushing stdout buffer. > write stdout: Broken pipe > > where strace has the following to say at this point: > fstat64(6, {st_mode=S_IFIFO|0600, st_size=1, ...}) = 0 > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 > _llseek(6, 0, 0xbfffebc4, SEEK_CUR) = -1 ESPIPE (Illegal seek) > > so the correct fstat for files >2G is taken, but llseek instead of llseek64. > > *shrug* > > it's not a bug or something, and the solution via ssh host command and pipe is viable, > I just wanted to know whether I'm doing something very wrong here, that's all :) > > > I'm not trying to be a pain in the neck here, I just thought I'd ask if anyone else ever > had that problem. > > > best, > Tatjana Svizensky > > > > > > > On Thu, Feb 08, 2001 at 01:25:41PM +0100, tatjana.svizensky at arcs.ac.at wrote: > > > Hello, > > > > > > I am very sorry if this has come up before and I missed in the FAQs etc, but... > > > > > > is there any way that openssh can support 64bit filehandles in Linux? > > > I'm rather new at using the LFS patch under Linux, but usually it is enough to recompile > > > with the #define _FILE_OFFSET_BITS 64 line if the source supports it. > > > scp does seem to be restricted to files <="G though. Or did I miss something? > > > And yes, I know it's not really relevant and such...it would be very convenient, though. > > > > > > best, > > > Tatjana Svizensky From rjmooney at mediaone.net Fri Feb 9 01:44:46 2001 From: rjmooney at mediaone.net (Robert Mooney) Date: Thu, 8 Feb 2001 09:44:46 -0500 Subject: openbsd-compat/vis.c fails to build (patch) In-Reply-To: Message-ID: vis.c from the 20010208 snap fails to build under OpenBSD 2.8. apply the following in the openssh root to fix: --- openbsd-compat/vis.c.old Thu Feb 8 09:21:18 2001 +++ openbsd-compat/vis.c Thu Feb 8 09:21:26 2001 @@ -35,9 +35,9 @@ static char rcsid[] = "$OpenBSD: vis.c,v 1.5 2000/07/19 15:25:13 deraadt Exp $"; #endif /* LIBC_SCCS and not lint */ -#ifndef HAVE_VIS - #include "includes.h" + +#ifndef HAVE_VIS #define isoctal(c) From emarshall at mercantec.com Fri Feb 9 02:51:35 2001 From: emarshall at mercantec.com (Edward S. Marshall) Date: Thu, 8 Feb 2001 09:51:35 -0600 (CST) Subject: OpenSSH 2.3.0p4/2.2.0p1, Solaris 8, ssh-keygen bus error Message-ID: Hi, I'm having a problem with ssh-keygen on Solaris 8; upon running, it produces a bus error due to a function call in OpenSSL (RC4_set_key): [...] (gdb) where #0 0x3440c in RC4_set_key () #1 0x2b890 in arc4random_stir () at /merc/tools/src/openssh-2.3.0p1/bsd-arc4random.c:65 #2 0x23ca8 in main (ac=1, av=0xffbefb94) at /merc/tools/src/openssh-2.3.0p1/ssh-keygen.c:720 I get identical results with any combination of: - gcc 2.95.2/binutils 2.10.1, or just gcc with Sun's as/ld (I do not have a WorkShop C licence), either built from source or obtained from Sun's "companion" CD (gcc only; they don't ship binutils). - OpenSSL 0.9.5a and 0.9.6, built from source. - OpenSSH 2.3.0p4 and 2.2.0p1, built from source. I'm using the ANDIrand (http://www.cosy.sbg.ac.at/~andi/) package to provide /dev/random, rather than EGD or SUNWski. ssh and sshd appear to be working as advertised, but key generation fails consistantly. I'm planning on trying the 10/00 Solaris 8 release as soon as I get a chance to download it from Sun. Suggestions? This looks like an openssl problem, but I'd think I wouldn't be the only one seeing this (the archives didn't indicate anyone else having this kind of problem)... -- Edward S. Marshall UNIX Administrator http://www.nyx.net/~emarshal/ Mercantec, Inc. From stevesk at sweden.hp.com Fri Feb 9 03:33:16 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Thu, 8 Feb 2001 17:33:16 +0100 (MET) Subject: argv[0] => host feature considered harmful In-Reply-To: <20010208143129.A9974@faui02.informatik.uni-erlangen.de> Message-ID: On Thu, 8 Feb 2001, Markus Friedl wrote: : do we care about 'argv[0] => host'. : i don't like it but it seems to be to late to drop this : rlogin-compatible feature. a new option seems the only : good option. i wouldn't mind seeing it removed. From mouring at etoh.eviladmin.org Fri Feb 9 04:29:59 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 8 Feb 2001 11:29:59 -0600 (CST) Subject: openbsd-compat/vis.c fails to build (patch) In-Reply-To: Message-ID: Thanks, I'll apply it shortly. Out of interest why are you not using the src/usr.bin/ssh/ from the OpenBSD tree? - Ben On Thu, 8 Feb 2001, Robert Mooney wrote: > > vis.c from the 20010208 snap fails to build under OpenBSD 2.8. apply the following in the openssh root to fix: > > --- openbsd-compat/vis.c.old Thu Feb 8 09:21:18 2001 > +++ openbsd-compat/vis.c Thu Feb 8 09:21:26 2001 > @@ -35,9 +35,9 @@ > static char rcsid[] = "$OpenBSD: vis.c,v 1.5 2000/07/19 15:25:13 deraadt Exp $"; > #endif /* LIBC_SCCS and not lint */ > > -#ifndef HAVE_VIS > - > #include "includes.h" > + > +#ifndef HAVE_VIS > > #define isoctal(c) > > From Lutz.Jaenicke at aet.TU-Cottbus.DE Fri Feb 9 04:52:15 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Thu, 8 Feb 2001 18:52:15 +0100 Subject: sftp / latest snapshot Message-ID: <20010208185215.A1481@ws01.aet.tu-cottbus.de> Hi! I have just played around a little bit with the actual CVS on HP-UX 10.20. - In openbsd-compat/Makefile.in the .c.o default rule is missing: .c.o: $(CC) $(CFLAGS) $(CPPFLAGS) -c $< - Linking sftp fails, because seed_rng() cannot be resolved. Actually it is in entropy.c (libssh) and needed by arc4random.c. A similar problem has been discussed several days ago and the problem should be solved by removing arc4random calls from sftp-client.c. In the ChangeLog there is: 20010208 - (djm) Fix linking of sftp, don't need arc4random any more. But sftp-client is dated Feb 5 and still contains the calls. Maybe the check-in was forgotten!? - I am not sure whether piddir (explicitly specified) should be set to sysconfdir just like that without a comment if piddir does not exist. Wouldn't it be better to create piddr during "make install"? -> configure.in - At the end of configure.in echo " User binaries: $B" is contained twice. Having this said, I could connect and transfer some files using sftp and sftp-server. However: opening the connections was abysmally slow (20 seconds), I don't know yet the reason. I can reproduce it by a simple slogin and comparing with other hosts using 2.3.0p1 it seems to be caused by the server side. So much for now, 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 distler at golem.ph.utexas.edu Fri Feb 9 05:26:10 2001 From: distler at golem.ph.utexas.edu (Jacques Distler) Date: Thu, 8 Feb 2001 12:26:10 -0600 Subject: next build In-Reply-To: <20010208140517.A8818@faui02.informatik.uni-erlangen.de> References: <20010208140517.A8818@faui02.informatik.uni-erlangen.de> Message-ID: <200102081826.f18IQLP11304@golem.ph.utexas.edu> -----BEGIN PGP SIGNED MESSAGE----- Markus Friedl wrote: >On Sun, Feb 04, 2001 at 04:31:02PM -0600, Jacques Distler wrote: >> I have sshd configured to log to LOCAL0. With the 20010119 snapshot >> and earlier, it works fine. With later builds, the daemon seems to >> function OK, but *nothing* gets logged to LOCAL0. Instead, I get the >> following error messages logged to /usr/adm/mesages every time a >> client connects to the daemon: >> >> Feb 4 00:23:45 golem sshd[17861]: error: Hm, dispatch protocol >> error: type 50 plen 516 >> Feb 4 00:23:45 golem sshd[17861]: error: Hm, dispatch protocol >> error: type 50 plen 550 > >what client versions? > >do you have ssh -v and/or sshd -d output? Here is with the latest snapshot. We no longer get a "dispatch protocol error". We don't get anything logged at all (either in LOCAL0 or in /usr/adm/messages). golem.ph.utexas.edu:9# sshd -d debug1: sshd version OpenSSH_2.3.1p1 debug1: load_private_key_autodetect: type 0 RSA1 debug1: read SSH2 private key done: name rsa w/o comment success 1 debug1: load_private_key_autodetect: type 1 RSA debug1: read SSH2 private key done: name dsa w/o comment success 1 debug1: load_private_key_autodetect: type 2 DSA 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 RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 127.0.0.1 port 898 debug1: Client protocol version 1.5; client software version OpenSSH_2.3.1p1 debug1: match: OpenSSH_2.3.1p1 pat ^OpenSSH debug1: Local version string SSH-1.99-OpenSSH_2.3.1p1 debug1: Sent 768 bit server key and 1024 bit host key. debug1: Encryption type: 3des debug1: Received session key; encryption turned on. debug1: Installing crc compensation attack detector. debug1: Attempting authentication for distler. Failed rsa for distler from 127.0.0.1 port 898 Accepted password for distler from 127.0.0.1 port 898 debug1: session_new: init debug1: session_new: session 0 debug1: Allocating pty. debug1: Entering interactive session. debug1: fd 3 setting O_NONBLOCK debug1: fd 7 IS O_NONBLOCK debug1: server_init_dispatch_13 debug1: server_init_dispatch_15 debug1: End of interactive session; stdin 9, stdout (read 2277, sent 2277), stderr 0 bytes. debug1: Received SIGCHLD. debug1: Command exited with status 0. debug1: Received exit confirmation. debug1: session_pty_cleanup: session 0 release /dev/ttyp3 Closing connection to 127.0.0.1 and 46> ssh -v localhost SSH Version OpenSSH_2.3.1p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090581f). debug: Reading configuration data /usr/local/etc/ssh_config debug: Applying options for * debug: ssh_connect: getuid 0 geteuid 0 anon 0 debug: Connecting to localhost [127.0.0.1] port 22. debug: Seeding random number generator debug: Allocated local port 898. debug: Connection established. debug: identity file /distler/.ssh/identity type 0 debug: identity file /distler/.ssh/id_dsa type 3 debug: Remote protocol version 1.99, remote software version OpenSSH_2.3.1p1 debug: match: OpenSSH_2.3.1p1 pat ^OpenSSH debug: Local version string SSH-1.5-OpenSSH_2.3.1p1 debug: Waiting for server public key. debug: Received server public key (768 bits) and host key (1024 bits). debug: Forcing accepting of host key for loopback/localhost. debug: Seeding random number generator debug: Encryption type: 3des debug: Sent encrypted session key. debug: Installing crc compensation attack detector. debug: Received encrypted confirmation. debug: Trying RSA authentication with key 'distler at golem.ph.utexas.edu' debug: Server refused our key. debug: Doing password authentication. distler at localhost's password: debug: Requesting pty. debug: Requesting shell. debug: Entering interactive session. Last login: Thu Feb 8 11:26:46 2001 from localhost Jacques - -- PGP public key: http://golem.ph.utexas.edu/~distler/distler.asc -----BEGIN PGP SIGNATURE----- Version: PGP Charset: noconv iQCVAwUBOoLky6IBi34rsX+ZAQHyjwP/WEMHgGyY+5TDOc6RyROsAQymXm1gTZte npxxArqZIg+HGxgfU13G88Bcesh6GAtig+A1thMygrQXyQ3XS+YIyZxtWAQHHsbQ cS7RgJb64I9EO0/e0thfxbwyW8xcYON2WrfNS0PhV1T9ehx0nR/p1PPtcTvbF1eJ H2VTpaS9Fgc= =VH5x -----END PGP SIGNATURE----- From mouring at etoh.eviladmin.org Fri Feb 9 06:36:26 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 8 Feb 2001 13:36:26 -0600 (CST) Subject: sftp / latest snapshot In-Reply-To: <20010208185215.A1481@ws01.aet.tu-cottbus.de> Message-ID: On Thu, 8 Feb 2001, Lutz Jaenicke wrote: > Hi! > > I have just played around a little bit with the actual CVS on HP-UX 10.20. > - In openbsd-compat/Makefile.in the .c.o default rule is missing: > .c.o: > $(CC) $(CFLAGS) $(CPPFLAGS) -c $< Some how this does not suprise me.. I've been dragging that change forward for almost two months now. It should be in now. > - Linking sftp fails, because seed_rng() cannot be resolved. Actually it > is in entropy.c (libssh) and needed by arc4random.c. A similar problem > has been discussed several days ago and the problem should be solved by > removing arc4random calls from sftp-client.c. In the ChangeLog there is: > 20010208 > - (djm) Fix linking of sftp, don't need arc4random any more. > But sftp-client is dated Feb 5 and still contains the calls. Maybe the > check-in was forgotten!? I have to assume that sftp-client.c was not synced. I saw this but did not think much about it at the time. (Because I've been too busy dealing with a video editing project to compile the latest version) > - I am not sure whether piddir (explicitly specified) should be set to > sysconfdir just like that without a comment if piddir does not exist. > Wouldn't it be better to create piddr during "make install"? > -> configure.in > - At the end of configure.in > echo " User binaries: $B" > is contained twice. > Fixed. Thanks. > Having this said, I could connect and transfer some files using sftp > and sftp-server. However: opening the connections was abysmally slow > (20 seconds), I don't know yet the reason. I can reproduce it by a simple > slogin and comparing with other hosts using 2.3.0p1 it seems to be caused > by the server side. > - Ben From distler at golem.ph.utexas.edu Fri Feb 9 05:58:51 2001 From: distler at golem.ph.utexas.edu (Jacques Distler) Date: Thu, 8 Feb 2001 12:58:51 -0600 Subject: next build In-Reply-To: <20010208140517.A8818@faui02.informatik.uni-erlangen.de> References: <20010208140517.A8818@faui02.informatik.uni-erlangen.de> Message-ID: <200102081858.f18Iwt011689@golem.ph.utexas.edu> -----BEGIN PGP SIGNED MESSAGE----- Markus Friedl wrote: >On Sun, Feb 04, 2001 at 04:31:02PM -0600, Jacques Distler wrote: >> I have sshd configured to log to LOCAL0. With the 20010119 snapshot >> and earlier, it works fine. With later builds, the daemon seems to >> function OK, but *nothing* gets logged to LOCAL0. Ooops! That would appear to be my screwup -- a problem with an include file. I recompiled log-server.c and logging seems to be working fine now. Now that the "dispatch protocol error" business seems to be resolved, the NeXT build is working fine. Jacques - -- PGP public key: http://golem.ph.utexas.edu/~distler/distler.asc -----BEGIN PGP SIGNATURE----- Version: PGP Charset: noconv iQCVAwUBOoLsbaIBi34rsX+ZAQEJ8QQAyBqMa+sI4dWd1i15kKm5R6cJLQDtK+7H 4JsRcwXAAvwrKxTlqD9ShWSJIcBCkexM5lJsdeWY8gLY8Q8SoSyKo6Ac9AK+45Zf JvOsFMhj5SE2GDONa2rraaWMBaw9V/DfAs0CaiLHq0evtAdyIZjI2uIP/vOxXfqy LoPXrKP/MuI= =WKR+ -----END PGP SIGNATURE----- From sunil at redback.com Fri Feb 9 06:07:58 2001 From: sunil at redback.com (Sunil K. Vallamkonda) Date: Thu, 8 Feb 2001 11:07:58 -0800 (PST) Subject: sshd question: In-Reply-To: <200102081858.f18Iwt011689@golem.ph.utexas.edu> Message-ID: Hello, I have sshd version:SSH_VERSION "OpenSSH_2.3.1p1" When I run (using inted.conf), at client-side I get error: Bad remote protocol version identification: 'sshd: no hostkeys available -- exiting. What is the solution to above problem ? Thank you. From sunil at redback.com Fri Feb 9 06:10:13 2001 From: sunil at redback.com (Sunil K. Vallamkonda) Date: Thu, 8 Feb 2001 11:10:13 -0800 (PST) Subject: sshd question: Message-ID: Hello, I have sshd version:SSH_VERSION "OpenSSH_2.3.1p1" When I run (using inted.conf), at client-side I get error: Bad remote protocol version identification: 'sshd: no hostkeys available -- exiting. I have client: SSH Version 1.2.27 [i386--netbsd], protocol version 1.5. Compiled with RSAREF. What is the solution to above problem ? Thank you. From vinschen at redhat.com Fri Feb 9 06:13:59 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 8 Feb 2001 20:13:59 +0100 Subject: sftp client In-Reply-To: ; from djm@mindrot.org on Wed, Feb 07, 2001 at 09:43:53AM +1100 References: <20010206125842.P15821@cygbert.vinschen.de> Message-ID: <20010208201359.E910@cygbert.vinschen.de> On Wed, Feb 07, 2001 at 09:43:53AM +1100, Damien Miller wrote: > On Tue, 6 Feb 2001, Corinna Vinschen wrote: > > Just hit another problem. When connecting with openssh-sftp to > > the sftp-server the sftp-server process remains in memory after > > exiting the client, waiting for input. > > > > sftp-server on i686-pc-cygwin, > > sftp-client on i686-pc-cygwin and i686-pc-linux-gnu > > > > The same does not happen when using the ssh.com sftp client. > > Does the parent sshd exit? Yes. > Can you turn on debugging in the sftp-server by editing the #define TRACE > to use log instead of debug. I would like to see whether ssh.com sftp > sends an explicit close message. Session: $ sftp cvaio sftp> pwd /home/corinna sftp> ^D Log with ssh.com sftp: sftp-server : Cygwin Process Id = 0x63C : client version 2 sftp-server : Cygwin Process Id = 0x63C : realpath id 0 path . sftp-server : Cygwin Process Id = 0x63C : sent names id 0 count 1 Log with openssh sftp: sftp-server : Cygwin Process Id = 0x5D4 : client version 2 sftp-server : Cygwin Process Id = 0x5D4 : realpath id -1560921021 path . sftp-server : Cygwin Process Id = 0x5D4 : sent names id -1560921021 count 1 Is that helpful?!? Corinna BTW: What's about the patch to sftp-client.c I sent two days ago which solves the "Couldn't close file: No Such File" problem? -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From sagi at aresworld.net Fri Feb 9 06:25:45 2001 From: sagi at aresworld.net (Sagi Bashari) Date: Thu, 8 Feb 2001 21:25:45 +0200 (IST) Subject: openssh2.3.0p1 and /etc/limits Message-ID: Hi! I wrote a small patch to enable /etc/limits support in openssh. nice thing when you don't have PAM installed.. It is based on Ultor's openssh 1.x patch (http://marc.theaimsgroup.com/?l=secure-shell&m=96427677022741&w=2) Works fine on slackware7.1. define USE_ETC_LIMITS in config.h , and compile as usual. Sagi -------------- next part -------------- diff -N -u openssh-2.3.0p1.orig/Makefile.in openssh-2.3.0p1/Makefile.in --- openssh-2.3.0p1.orig/Makefile.in Wed Feb 7 22:24:35 2001 +++ openssh-2.3.0p1/Makefile.in Wed Feb 7 22:43:55 2001 @@ -41,7 +41,7 @@ SSHOBJS= ssh.o sshconnect.o sshconnect1.o sshconnect2.o log-client.o readconf.o clientloop.o -SSHDOBJS= sshd.o auth.o auth1.o auth2.o auth-skey.o auth2-skey.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o dh.o pty.o log-server.o login.o loginrec.o servconf.o serverloop.o md5crypt.o session.o +SSHDOBJS= sshd.o auth.o auth1.o auth2.o auth-skey.o auth2-skey.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o dh.o pty.o log-server.o login.o loginrec.o servconf.o serverloop.o md5crypt.o session.o limits.o TROFFMAN = scp.1 ssh-add.1 ssh-agent.1 ssh-keygen.1 ssh.1 sshd.8 sftp-server.8 CATMAN = scp.0 ssh-add.0 ssh-agent.0 ssh-keygen.0 ssh.0 sshd.0 sftp-server.0 diff -N -u openssh-2.3.0p1.orig/config.h.in openssh-2.3.0p1/config.h.in --- openssh-2.3.0p1.orig/config.h.in Wed Feb 7 22:24:36 2001 +++ openssh-2.3.0p1/config.h.in Wed Feb 7 22:43:55 2001 @@ -5,6 +5,8 @@ /* Generated automatically from acconfig.h by autoheader. */ /* Please make your changes there */ +/* use /etc/limits*/ +#undef USE_ETC_LIMITS /* Define if the `getpgrp' function takes no argument. */ #undef GETPGRP_VOID Common subdirectories: openssh-2.3.0p1.orig/contrib and openssh-2.3.0p1/contrib diff -N -u openssh-2.3.0p1.orig/limits.c openssh-2.3.0p1/limits.c --- openssh-2.3.0p1.orig/limits.c Thu Jan 1 02:00:00 1970 +++ openssh-2.3.0p1/limits.c Wed Feb 7 22:43:55 2001 @@ -0,0 +1,340 @@ +/* + * Copyright 1989 - 1994, Julianne Frances Haugh + * 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. Neither the name of Julianne F. Haugh nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY JULIE HAUGH AND CONTRIBUTORS ``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 JULIE HAUGH OR CONTRIBUTORS 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. + */ + +/* + * Separated from setup.c. --marekm + * Resource limits thanks to Cristian Gafton. + */ + +#include +#include +#include + +#include +#include +#include + +#include +#define LIMITS + +#ifdef LIMITS + +#ifndef LIMITS_FILE +#define LIMITS_FILE "/etc/limits" +#endif + +#define memzero(ptr, size) memset((void *)(ptr), 0, (size)) + +#define LOGIN_ERROR_RLIMIT 1 +#define LOGIN_ERROR_LOGIN 2 + +/* Set a limit on a resource */ +/* + * rlimit - RLIMIT_XXXX + * value - string value to be read + * multiplier - value*multiplier is the actual limit + */ +static int +setrlimit_value(unsigned int rlimit, const char *value, unsigned int multiplier) +{ + struct rlimit rlim; + long limit; + char **endptr = (char **) &value; + const char *value_orig = value; + + limit = strtol(value, endptr, 10); + if (limit == 0 && value_orig == *endptr) /* no chars read */ + return 0; + limit *= multiplier; + rlim.rlim_cur = limit; + rlim.rlim_max = limit; + if (setrlimit(rlimit, &rlim)) + return LOGIN_ERROR_RLIMIT; + return 0; +} + + +static int +set_prio(const char *value) +{ + int prio; + char **endptr = (char **) &value; + + prio = strtol(value, endptr, 10); + if ((prio == 0) && (value == *endptr)) + return 0; + if (setpriority(PRIO_PROCESS, 0, prio)) + return LOGIN_ERROR_RLIMIT; + return 0; +} + + +/* Counts the number of user logins and check against the limit */ +static int +check_logins(const char *name, const char *maxlogins) +{ + struct utmp *ut; + unsigned int limit, count; + char **endptr = (char **) &maxlogins; + const char *ml_orig = maxlogins; + + limit = strtol(maxlogins, endptr, 10); + if (limit == 0 && ml_orig == *endptr) /* no chars read */ + return 0; + + if (limit == 0) /* maximum 0 logins ? */ { + syslog(LOG_WARNING, "No logins allowed for `%s'\n", name); + return LOGIN_ERROR_LOGIN; + } + + setutent(); + count = 0; + while ((ut = getutent())) { +// if (ut->ut_type != USER_PROCESS) +// continue; + if (ut->ut_user[0] == '\0') + continue; + if (strncmp(name, ut->ut_user, sizeof(ut->ut_user)) != 0) + continue; + if (++count > limit) + break; + } + endutent(); + /* + * This is called after setutmp(), so the number of logins counted + * includes the user who is currently trying to log in. + */ + + if (count > limit) { + printf("Too many logins (max %d).\n",count); + syslog(LOG_WARNING, "Too many logins (max %d) for %s\n",limit, name); + return LOGIN_ERROR_LOGIN; + } + + return 0; +} + +/* Function setup_user_limits - checks/set limits for the curent login + * Original idea from Joel Katz's lshell. Ported to shadow-login + * by Cristian Gafton - gafton at sorosis.ro + * + * We are passed a string of the form ('BASH' constants for ulimit) + * [Aa][Cc][Dd][Ff][Mm][Nn][Rr][Ss][Tt][Uu][Ll][Pp] + * (eg. 'C2F256D2048N5' or 'C2 F256 D2048 N5') + * where: + * [Aa]: a = RLIMIT_AS max address space (KB) + * [Cc]: c = RLIMIT_CORE max core file size (KB) + * [Dd]: d = RLIMIT_DATA max data size (KB) + * [Ff]: f = RLIMIT_FSIZE Maximum filesize (KB) + * [Mm]: m = RLIMIT_MEMLOCK max locked-in-memory address space (KB) + * [Nn]: n = RLIMIT_NOFILE max number of open files + * [Rr]: r = RLIMIT_RSS max resident set size (KB) + * [Ss]: s = RLIMIT_STACK max stack size (KB) + * [Tt]: t = RLIMIT_CPU max CPU time (MIN) + * [Uu]: u = RLIMIT_NPROC max number of processes + * [Ll]: l = max number of logins for this user + * [Pp]: p = process priority -20..20 (negative = high priority) + * + * Return value: + * 0 = okay, of course + * LOGIN_ERROR_RLIMIT = error setting some RLIMIT + * LOGIN_ERROR_LOGIN = error - too many logins for this user + * + * buf - the limits string + * name - the username + */ +static int +do_user_limits(const char *buf, const char *name) +{ + const char *pp; + int retval = 0; + + pp = buf; + + while (*pp != '\0') switch(*pp++) { +#ifdef RLIMIT_AS + case 'a': + case 'A': + /* RLIMIT_AS - max address space (KB) */ + retval |= setrlimit_value(RLIMIT_AS, pp, 1024); +#endif +#ifdef RLIMIT_CPU + case 't': + case 'T': + /* RLIMIT_CPU - max CPU time (MIN) */ + retval |= setrlimit_value(RLIMIT_CPU, pp, 60); + break; +#endif +#ifdef RLIMIT_DATA + case 'd': + case 'D': + /* RLIMIT_DATA - max data size (KB) */ + retval |= setrlimit_value(RLIMIT_DATA, pp, 1024); + break; +#endif +#ifdef RLIMIT_FSIZE + case 'f': + case 'F': + /* RLIMIT_FSIZE - Maximum filesize (KB) */ + retval |= setrlimit_value(RLIMIT_FSIZE, pp, 1024); + break; +#endif +#ifdef RLIMIT_NPROC + case 'u': + case 'U': + /* RLIMIT_NPROC - max number of processes */ + retval |= setrlimit_value(RLIMIT_NPROC, pp, 1); + break; +#endif +#ifdef RLIMIT_CORE + case 'c': + case 'C': + /* RLIMIT_CORE - max core file size (KB) */ + retval |= setrlimit_value(RLIMIT_CORE, pp, 1024); + break; +#endif +#ifdef RLIMIT_MEMLOCK + case 'm': + case 'M': + /* RLIMIT_MEMLOCK - max locked-in-memory address space (KB) */ + retval |= setrlimit_value(RLIMIT_MEMLOCK, pp, 1024); + break; +#endif +#ifdef RLIMIT_NOFILE + case 'n': + case 'N': + /* RLIMIT_NOFILE - max number of open files */ + retval |= setrlimit_value(RLIMIT_NOFILE, pp, 1); + break; +#endif +#ifdef RLIMIT_RSS + case 'r': + case 'R': + /* RLIMIT_RSS - max resident set size (KB) */ + retval |= setrlimit_value(RLIMIT_RSS, pp, 1024); + break; +#endif +#ifdef RLIMIT_STACK + case 's': + case 'S': + /* RLIMIT_STACK - max stack size (KB) */ + retval |= setrlimit_value(RLIMIT_STACK, pp, 1024); + break; +#endif + case 'l': + case 'L': + /* LIMIT the number of concurent logins */ + retval |= check_logins(name, pp); + break; + case 'p': + case 'P': + retval |= set_prio(pp); + break; + } + return retval; +} + +static int +setup_user_limits(const char *uname) +{ + /* TODO: allow and use @group syntax --cristiang */ + FILE *fil; + char buf[1024]; + char name[1024]; + char limits[1024]; + char deflimits[1024]; + char tempbuf[1024]; + + /* init things */ + memzero(buf, sizeof(buf)); + memzero(name, sizeof(name)); + memzero(limits, sizeof(limits)); + memzero(deflimits, sizeof(deflimits)); + memzero(tempbuf, sizeof(tempbuf)); + + /* start the checks */ + fil = fopen(LIMITS_FILE, "r"); + if (fil == NULL) { +#if 0 /* no limits file is ok, not everyone is a BOFH :-). --marekm */ + syslog(LOG_WARNING, NO_LIMITS, uname, LIMITS_FILE); +#endif + return 0; + } + /* The limits file have the following format: + * - '#' (comment) chars only as first chars on a line; + * - username must start on first column + * A better (smarter) checking should be done --cristiang */ + while (fgets(buf, 1024, fil) != NULL) { + if (buf[0]=='#' || buf[0]=='\n') + continue; + memzero(tempbuf, sizeof(tempbuf)); + /* a valid line should have a username, then spaces, + * then limits + * we allow the format: + * username L2 D2048 R4096 + * where spaces={' ',\t}. Also, we reject invalid limits. + * Imposing a limit should be done with care, so a wrong + * entry means no care anyway :-). A '-' as a limits + * strings means no limits --cristiang */ + if (sscanf(buf, "%s%[ACDFMNRSTULPacdfmnrstulp0-9 \t-]", + name, tempbuf) == 2) { + if (strcmp(name, uname) == 0) { + strcpy(limits, tempbuf); + break; + } else if (strcmp(name, "*") == 0) { + strcpy(deflimits, tempbuf); + } + } + } + fclose(fil); + if (limits[0] == '\0') { + /* no user specific limits */ + if (deflimits[0] == '\0') /* no default limits */ + return 0; + strcpy(limits, deflimits); /* use the default limits */ + } + return do_user_limits(limits, uname); +} + +#endif /* LIMITS */ + +/* + * set the process nice, ulimit, and umask from the password file entry + */ + +void setup_limits(const struct passwd *info) { + char *cp; + int i; + long l; + + if (info->pw_uid) if (setup_user_limits(info->pw_name) & LOGIN_ERROR_LOGIN) { + sleep(2); + exit(1); + } +} diff -N -u openssh-2.3.0p1.orig/session.c openssh-2.3.0p1/session.c --- openssh-2.3.0p1.orig/session.c Wed Feb 7 22:24:35 2001 +++ openssh-2.3.0p1/session.c Wed Feb 7 22:43:55 2001 @@ -599,6 +599,10 @@ do_pam_session(pw->pw_name, s->tty); do_pam_setcred(); #endif /* USE_PAM */ + +#ifdef USE_ETC_LIMITS + setup_limits(pw); +#endif /* USE_ETC_LIMITS */ /* Fork the child. */ if ((pid = fork()) == 0) { From shorty at getuid.de Fri Feb 9 07:24:00 2001 From: shorty at getuid.de (Christian Kurz) Date: Thu, 8 Feb 2001 21:24:00 +0100 Subject: username check in scp Message-ID: <20010208212400.D10759@seteuid.getuid.de> Hi a fellow debian developer pointed it out to me, that ssh itself does not check the username that is provided for login into a remote host, but that scp checks it. I could verify that the current openssh code from cvs still has a check for the username in scp.c but not in ssh.c. So I created the attached small patch to remove the username check from scp. I hope ?t's correct and that you apply it to the source. If it's wrong, please point me to my mistake, so that I can learn from it. If you don't want to apply it, then please tell me why. Thank you. Ciao Christian -- When it is incorrect, it is, at least *authoritatively* incorrect. -- Hitchiker's Guide To The Galaxy -------------- next part -------------- --- scp.c.orig Thu Feb 8 21:20:50 2001 +++ scp.c Thu Feb 8 21:21:21 2001 @@ -207,7 +207,6 @@ char *colon(char *); void lostconn(int); void nospace(void); -int okname(char *); void run_err(const char *,...); void verifydir(char *); @@ -371,8 +370,6 @@ tuser = argv[argc - 1]; if (*tuser == '\0') tuser = NULL; - else if (!okname(tuser)) - exit(1); } else { thost = argv[argc - 1]; tuser = NULL; @@ -395,8 +392,6 @@ suser = argv[i]; if (*suser == '\0') suser = pwd->pw_name; - else if (!okname(suser)) - continue; sprintf(bp, "%s%s -x -o'FallBackToRsh no' -n -l %s %s %s %s '%s%s%s:%s'", ssh_program, verbose_mode ? " -v" : "", @@ -468,8 +463,6 @@ suser = argv[i]; if (*suser == '\0') suser = pwd->pw_name; - else if (!okname(suser)) - continue; } host = cleanhostname(host); len = strlen(src) + CMDNEEDS + 20; @@ -1017,28 +1010,6 @@ } run_err("%s: %s", cp, strerror(errno)); exit(1); -} - -int -okname(cp0) - char *cp0; -{ - int c; - char *cp; - - cp = cp0; - do { - c = *cp; - if (c & 0200) - goto bad; - if (!isalpha(c) && !isdigit(c) && - c != '_' && c != '-' && c != '.' && c != '+') - goto bad; - } while (*++cp); - return (1); - -bad: fprintf(stderr, "%s: invalid user name\n", cp0); - return (0); } BUF * -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 241 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010208/c4f07a36/attachment.bin From iarce at core-sdi.com Fri Feb 9 09:49:06 2001 From: iarce at core-sdi.com (=?iso-8859-1?Q?Iv=E1n_Arce?=) Date: Thu, 8 Feb 2001 19:49:06 -0300 Subject: [CORE SDI ADVISORY] SSH1 CRC-32 compensation attack detector vulnerability Message-ID: <060501c09221$57784610$2e58a8c0@ffornicario> CORE SDI http://www.core-sdi.com SSH1 CRC-32 compensation attack detector vulnerability Date Published: 2001-02-08 Advisory ID: CORE-20010207 Bugtraq ID: 2347 CVE CAN: CAN-2001-0144 Title: SSH1 CRC-32 compensation attack detector vulnerability Class: Boundary Error Condition Remotely Exploitable: Yes Locally Exploitable: Yes Release Mode: FORCED RELEASE Vulnerability Description: SSH is a widely used client-server application for authentication and encryption of network communications. In 1998 Ariel Futoransky and Emiliano Kargieman [2] discovered a design flaw in the SSH1 protocol (protocol 1.5) that could lead an attacker to inject malicious packets into an SSH encrypted stream that would allow execution of arbitrary commands on either client or server. The problem was not fixable without breaking the protocol 1.5 semantics and thus a patch was devised that would detect an attack that exploited the vulnerability found. The attack detection is done in the file deattack.c from the SSH1 source distribution. A vulnerability was found in the attack detection code that could lead to the execution of arbitrary code in SSH servers and clients that incorporated the patch. Vulnerable Packages/Systems: This problem affects both SSH servers and clients. All versions of SSH supporting the protocol 1 (1.5) that use the CRC compensation attack detector are vulnerable See below for vendor specific information. OpenSSH OpenSSH versions prior to 2.3.0 are vulnerable. OpenSSH versions 2.3.0 and above are not vulnerable, source changes in deattack.c that fix this problem were incorporated into the source tree on October 31st, 2000. SSH.com ssh-1.2.24 up to , and including, ssh-1.2.31 are vulnerable. Versions prior to 1.2.24 did not include the CRC compensation attack detector. The official response from SSH.com follows: - SSH-2.x is not vulnerable - SSH1 is deprecated, and not supported, upgrade to SSH2 - Nonetheless the proposed patch has been applied to the ssh-1.2.x source tree, future releases of ssh-1.2.x will have the bug closed. F-Secure SSH F-Secure SSH-1.3.x is vulnerable. Contact the vendor for a fix. AppGate The default configuration of the AppGate server is not vulnerable since it has SSH-1 support disabled. However customers who need ssh1-support can contact support at appgate.com to get patches. Mindbright The MindtTerm client does not have this vulnerability. TTSSH Not vulnerable. All version that incorporated the attack detector are not vulnerable. LSH Not. vulnerable. LSH does not support SSH protocol 1. JavaSSH Not vulnerable. The Java Telnet/SSH Applet (http://www.mud.de/se/jta/) does not include CRC attack detection. A security note regarding Java SSH plugin can be found on: http://www.mud.de/se/jta/doc/plugins/SSH.html OSSH (by Bjoern Groenvall) OSSH 1.5.7 and below is vulnerable. The problem has been fixed in version 1.5.8 Cisco SSH Cisco SSH does not appear to be vulnerable. Solution/Vendor Information/Workaround: The patch included should be applied to the file deattack.c from the ssh-1.2.31 (and below) source distribution. Contact your SSH vendor for a fix if source code is not available. Additionally, advisories and information on security issues in SSH can be obtained from: http://www.core-sdi.com/advisories/ssh1_sessionkey_recovery.htm http://www.core-sdi.com/advisories/buffer_over_ing.htm http://www.core-sdi.com/advisories/ssh-advisory.htm http://www.securityfocus.com.com/bid/2347 http://www.securityfocus.com.com/bid/2222 http://www.securityfocus.com.com/bid/2117 http://www.securityfocus.com.com/bid/1949 http://www.securityfocus.com/bid/1426 http://www.securityfocus.com/bid/1323 http://www.securityfocus.com/bid/1006 http://www.securityfocus.com/bid/843 http://www.securityfocus.com/bid/660 --------------------- begin dettack patch ------------------ This is the patch for ssh-1.2.31 package. Using the patch: Copy the ssh-1.2.31.tar.gz package and the ssh-1.2.31-deattack.patch in a directory. Decompress the ssh-1.2.31.tar.gz package: tar xzvf ssh-1.2.31.tar.gz Apply the patch: patch < ssh-1.2.31-deattach.patch Compile the ssh package. --- ssh-1.2.31/deattack.c-old Wed Feb 7 19:45:16 2001 +++ ssh-1.2.31/deattack.c Wed Feb 7 19:54:11 2001 @@ -79,7 +79,7 @@ detect_attack(unsigned char *buf, word32 len, unsigned char *IV) { static word16 *h = (word16 *) NULL; - static word16 n = HASH_MINSIZE / HASH_ENTRYSIZE; + static word32 n = HASH_MINSIZE / HASH_ENTRYSIZE; register word32 i, j; word32 l; register unsigned char *c; --------------------- end deattack patch ------------------- Vendors notified on: 2001-02-07 This advisory has been released early due to the disclosure of information regarding the problem in public forums. Credits: This vulnerability was found by Michal Zalewski of the Bindview RAZOR Team. We thank Scott Blake and Steve Manzuik of the Bindview RAZOR Team for their cooperation coordinating the report and release process of this advisory. This advisory and other CORE SDI security advisories can be obtained from http://www.core-sdi.com/publications.htm Technical Description - Exploit/Concept Code: Most SSH distributions incorporated the file deattack.c released by CORE SDI in 1998. The file implements an algorithm to detect attempts to exploit the CRC-32 compensation attack by passing the ssh packets received from the network to the detect_attack() function in deattack.c ... /* detect_attack Detects a crc32 compensation attack on a packet */ int detect_attack(unsigned char *buf, word32 len, unsigned char *IV) { static word16 *h = (word16 *) NULL; (*) static word16 n = HASH_MINSIZE / HASH_ENTRYSIZE; register word32 i, j; word32 l; ... buf is the ssh packet received, len is the length of that packet The received packet is comprised of several blocks of ciphertext of size SSH_BLOCKSIZE and each of them is checked against the others to verify that different packets dont have the same CRC value, such behavior is symptom of an attack. The detection is done using a hash table that is dynamically allocated based on the size of the received packet. ... for (l = n; l < HASH_FACTOR(len / SSH_BLOCKSIZE); l = l << 2); if (h == NULL) { debug("Installing crc compensation attack detector."); n = l; h = (word16 *) xmalloc(n * sizeof(word16)); } else ... Due to the improper declaration of 'n' above (it should be a word32) by sending crafted large ssh packets (length > 2^16) it is possible to make the vulnerable code perform a call to xmalloc() with an argument of 0, which will return a pointer into the program's address space. It is worth mentioning that existing standards promote two possible behaviours for malloc() when it is called with an argument of 0: - Failure, returning NULL - Success, returning a valid address pointing at a zero-sized object. Most modern systems implement the later behaviour and are thus vulnerable. Systems which have the older behaviour will abort the connection due to checks within xmalloc() It is then possible to abuse the following code to in order write to arbitrary memory locations in the program (ssh server or client) address space, thus allowing an attacker to execute arbitrary code on the vulnerable machine, see lines marked with (*): for (c = buf, j = 0; c < (buf + len); c += SSH_BLOCKSIZE, j++) { (*) for (i = HASH(c) & (n - 1); h[i] != HASH_UNUSED; i = (i + 1) & (n - 1)) { if (h[i] == HASH_IV) { if (!CMP(c, IV)) { if (check_crc(c, buf, len, IV)) return (DEATTACK_DETECTED); else break; } } else if (!CMP(c, buf + h[i] * SSH_BLOCKSIZE)) { if (check_crc(c, buf, len, IV)) return (DEATTACK_DETECTED); else break; } } (*) h[i] = j; } A would-be attacker does not need to authenticate to the SSH server first or to have the packets encrypted in a meaningful way to perform the attack. Even if that was the case, the session key used for encrypting is choosen by the ssh client and it is therefore trivial to implement an exploit (in the sense of the cryptography knowledge required to do it). However, a small degree of knowledge in exploit code development would be needed to implement a working exploit. References [1] http://www.core-sdi.com/soft/ssh/ssh.pdf Copyright notice The contents of this advisory are copyright (c) 2000 CORE SDI Inc. and may be distributed freely provided that no fee is charged for this distribution and the authors are given credit. All the product names mentioned herein are trademarks of their respective owners. $Id: SSH1-deattack-advisory.txt,v 1.9 2001/02/08 22:46:53 iarce Exp $ --- "Understanding. A cerebral secretion that enables one having it to know a house from a horse by the roof on the house, Its nature and laws have been exhaustively expounded by Locke, who rode a house, and Kant, who lived in a horse." - Ambrose Bierce ==================[ CORE Seguridad de la Informacion S.A. ]========= Iv?n Arce Presidente PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1 F65A email : iarce at core-sdi.com http://www.core-sdi.com Florida 141 2do cuerpo Piso 7 C1005AAC Buenos Aires, Argentina. Tel/Fax : +(54-11) 4331-5402 ===================================================================== From svaughan at asterion.com Fri Feb 9 09:53:18 2001 From: svaughan at asterion.com (svaughan) Date: Thu, 8 Feb 2001 14:53:18 -0800 (PST) Subject: SCO 5.0.5 question (username not known) In-Reply-To: <20010208082551.F12224@alcove.wittsend.com> Message-ID: Hello, I am running OpenSSH_2.2.0p1 on SCO 5.0.5. Everything is running just fine but I am experiencing a little problem when I go to change my password remotely. After logging in, if I go to change my password with the command passwd, I get the following error. bash-2.01$ passwd Setting password for user: (null) Password request denied. Reason: your identity is not known. I can get around this by relogging in with the su command. su - myloginname then it knows who I am. I have tried to change UseLogin to yes in the config file but SCO doesn't like that very much. I was wondering if anyone has experienced this. Any help would be greatly appreciated. Thanks, Sam From advisory+ssh1crc at bos.bindview.com Fri Feb 9 10:05:39 2001 From: advisory+ssh1crc at bos.bindview.com (BindView Security Advisory) Date: 08 Feb 2001 18:05:39 -0500 Subject: BindView advisory: sshd remote root (bug in deattack.c) Message-ID: Remote vulnerability in SSH daemon crc32 compensation attack detector ----------------------------------------------------------------------- Issue date: 8 February 2001 Author: Michal Zalewski Contact: Scott Blake CVE: CAN-2001-0144 Topic: Remotely exploitable vulnerability condition exists in most ssh daemon installations (F-SECURE, OpenSSH, SSH from ssh.com, OSSH). Tested against: ** Vulnerable: SSH 1.2.x (ssh.com) -- all recent releases F-SECURE SSH 1.3.x -- all recent releases OpenSSH prior to 2.3.0 (unless SSH protocol 1 support is disabled) OSSH 1.5.7 (by Bjoern Groenvall) and other ssh1/OpenSSH derived daemons ** Not vulnerable: SSH2 (ssh.com): all 2.x releases NOTE: SSH2 installations with SSH1 fallback support are vulnerable OpenSSH 2.3.0 (problem fixed) SSH1 releases prior to 1.2.24 (vulnerable to crc attacks) Cisco SSH (own implementation) LSH (SSH protocol 1 not supported) ** Other SSH daemons: not tested Overview: An integer-overflow problem is present in common code of recent ssh daemons, deattack.c, which was developed by CORE SDI to protect against cryptographic attacks on SSH protocol. Impact: Insufficient range control calculations (16-bit unsigned variable is used instead of 32-bit, which causes integer overflow) in the detect_attack() function leads to table index overflow bug. This effectively allows an attacker to overwrite arbitrary portions of memory. The altered memory locations affect code that is executed by the daemon with uid 0, and this can be leveraged to obtain general root access to the system. Details: When the condition described above occurs, a 32-bit local variable, which is set to 65536 for large input buffers, is assigned to a 16-bit local variable, effectively causing it to be set to 0. Due to specific malloc(0) behavior, memory allocation routine will be passed, creating buffer of size (malloc_usable_size) 12. Next: for (i = HASH(c) & (n - 1); h[i] != HASH_UNUSED; We can see n-1 here, and n is equal to 0. Because i is an unsigned 32-bit integer, it would cause integer overflow. This code will be equal to i = HASH(c) & 0xffffffff. Binary AND operator reduces this to i = HASH(c). Pointer 'c' is referencing client-provided cryptographic packet, and HASH function is simply responsible for changing byte order in input stream. Then, detect_attack() routine is trying to access h[i], causing segmentation fault due to table index overflow bug. To reproduce this condition, run your sshd server on localhost under gdb with '-d' switch (to avoid forking). Then try (using OpenSSH client - ssh.com client software crops the login name): $ ssh -v -l `perl -e '{print "A"x88000}'` localhost Program received signal SIGSEGV, Segmentation fault. 0x806cfbd in detect_attack ( ..., len=88016, IV=0x0) at deattack.c:138 136 for (i = HASH(c) & (n - 1); h[i] != HASH_UNUSED; We can inspect the table index (SEGV happened during h[i] != HASH_UNSIGNED comparsion): (gdb) printf "%x\n",i Results may vary with every connection, depending on the entropy seed used by the client, crypto keys, etc. You can easily produce a wide 32-bit range of indexes by changing client parameters or simply reconnecting. It is obvious there wouldn't be a problem to specify very large index that would point outside our table, but will cause address space wrap to point accessible memory (stack or another segment). Then, few lines below, in the same loop, we can find following statement: h[i] = j; ...where j is a simple block counter. Conclusion: By carefully preparing encrypted data, an attacker can point used, accessible memory (that would pass check in line 136 without SEGV), and then, he will able to alter dword at chosen address, replacing it with value of j. The attacker can alter stack variables, alter malloc structures, etc, and attack later due to improper execution of daemon code. This condition is relatively difficult to exploit, but there are no technical reasons that would make this impossible. Currently, we are not aware of working exploits for this vulnerability. Note that the attacker needs to make a TCP connection from an IP address for which sshd will enter into a key-exchange dialogue. If the attacker's packets have a source IP address that is disallowed by (for example) DenyHosts in the sshd configuration file, the key exchange will not happen and the attacker will not have an opportunity to compose the required exploit data. Solution: Included are a few patches for various versions/implementations of SSH. This is not meant to be an all-inclusive list, as there are a number of implementers of SSH daemons that are not open source. If you *do* have the source code for SSH, it should be fairly simply to study the patches below, see what has been done, and patch your own code. Note that this is a fix for the one issue that we've found, and should not be construed as the results of a complete audit of the code. SSH1 software: 8<---------------------patch for ssh-1.2.31--------------------------- --- deattack.c.orig Wed Feb 7 13:53:47 2001 +++ deattack.c Wed Feb 7 13:54:24 2001 @@ -79,7 +79,7 @@ detect_attack(unsigned char *buf, word32 len, unsigned char *IV) { static word16 *h = (word16 *) NULL; - static word16 n = HASH_MINSIZE / HASH_ENTRYSIZE; + static word32 n = HASH_MINSIZE / HASH_ENTRYSIZE; register word32 i, j; word32 l; register unsigned char *c; 8<---------------------patch for ssh-1.2.31--------------------------- Bjoern Groenvall's ossh (ftp://ftp.pdc.kth.se/pub/krypto/ossh/): 8<---------------------patch for ossh-1.5.7--------------------------- --- deattack.c.orig Wed Feb 7 14:11:23 2001 +++ deattack.c Wed Feb 7 14:11:46 2001 @@ -91,7 +91,7 @@ detect_attack(const unsigned char *buf, word32 len) { static u_int16_t *h = (u_int16_t *) NULL; - static u_int16_t n = HASH_MINSIZE / HASH_ENTRYSIZE; + static u_int32_t n = HASH_MINSIZE / HASH_ENTRYSIZE; register word32 i, j; word32 l; const unsigned char *c, *d; 8<---------------------patch for ossh-1.5.7--------------------------- OpenSSH: Upgrade to 2.3.0 or above. If you have 2.2.0: 8<-------------------patch for openssh-2.2.0-------------------------- --- deattack.c.orig Wed Feb 7 14:18:23 2001 +++ deattack.c Wed Feb 7 14:19:33 2001 @@ -84,7 +84,7 @@ detect_attack(unsigned char *buf, u_int32_t len, unsigned char *IV) { static u_int16_t *h = (u_int16_t *) NULL; - static u_int16_t n = HASH_MINSIZE / HASH_ENTRYSIZE; + static u_int32_t n = HASH_MINSIZE / HASH_ENTRYSIZE; register u_int32_t i, j; u_int32_t l; register unsigned char *c; 8<-------------------patch for openssh-2.2.0-------------------------- Vendor Response: CORE SDI has issued their own advisory detailing fix information and has also pointed out that SSH1 clients are also vulnerable. Bjorn Gronvall - OSSH Fixed in version ossh-1.5.8 AppGate The default configuration of the AppGate server is not vulnerable since it has SSH-1 support disabled. However customers who need ssh1-support can contact support at appgate.com to get patches. Mindbright The MindTerm client does not have this vulnerability. SSH Current release 2.4.0 is not vulnerable. Previous versions of SSH1 are not supported but a fix has been commited to the source tree. SSH recommends customers upgrade to SSH2. F-Secure Unfortunately, after many attempts to contact F-Secure via email and telephone no response has been received. Thanks: Special thanks to Mark Loveless for his significant contributions to the Fix section. Thanks to RAZOR team members Todd Sabin, Scott Blake, and Steve Manzuik for their assistance with this issue. Thanks also to Ivan Arce of CORE SDI for his patience with us. From stevesk at sweden.hp.com Fri Feb 9 10:55:27 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Fri, 9 Feb 2001 00:55:27 +0100 (MET) Subject: Authentication By-Pass Vulnerability in OpenSSH 2.3.1 (devel snapshot) (fwd) Message-ID: fyi for those running snapshots. the latest portable cvs has the fix and the version is 2.3.2p1. Kevin ---------- Forwarded message ---------- Date: Thu, 08 Feb 2001 18:15:00 -0500 From: Niels Provos To: security-announce at openbsd.org Subject: Authentication By-Pass Vulnerability in OpenSSH 2.3.1 (devel snapshot) ---------------------------------------------------------------------------- OpenBSD Security Advisory February 8, 2001 Authentication By-Pass Vulnerability in OpenSSH-2.3.1 ---------------------------------------------------------------------------- SYNOPSIS OpenSSH-2.3.1, a development snapshot, only checked if a public key for public key authentication was permitted. In the protocol 2 part of the server, the challenge-response step that ensures that the connecting client is in possession of the corresponding private key has been omitted. As a result, anyone who could obtain the public key listed in the users authorized_keys file could log in as that user without authentication. A fix for this problem was committed on Februrary 8th. The problem was introduced on January 18th. This is a three week time window. ---------------------------------------------------------------------------- AFFECTED SYSTEMS This vulnerability affects only OpenSSH version 2.3.1 with support for protocol 2 enabled. The latest official release OpenSSH 2.3.0 is not affected by this problem. The latest snapshot version OpenSSH 2.3.2 is not affected either. ---------------------------------------------------------------------------- RESOLUTION If you installed the OpenSSH 2.3.1 development snapshot, install the latest snapshot. Currently, the latest snapshot is OpenSSH 2.3.2 which is available via http://www.openssh.com/. ---------------------------------------------------------------------------- From djm at mindrot.org Fri Feb 9 11:18:53 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 9 Feb 2001 11:18:53 +1100 (EST) Subject: argv[0] => host feature considered harmful In-Reply-To: <200102081333.f18DXIp18996@cvs.openbsd.org> Message-ID: On Thu, 8 Feb 2001, Theo de Raadt wrote: > >do we care about 'argv[0] => host'. > >i don't like it but it seems to be to late to drop this > >rlogin-compatible feature. a new option seems the only > >good option. > > I would have no problem with seeing it go away. Ditto. -d -- | Damien Miler \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From rjmooney at mediaone.net Fri Feb 9 11:55:44 2001 From: rjmooney at mediaone.net (Robert Mooney) Date: Thu, 8 Feb 2001 19:55:44 -0500 Subject: 0 length snapshots!@ In-Reply-To: Message-ID: Not good, considering the advisory just released! :) http://bass.directhit.com/openssh_snap/ - Rob From djm at mindrot.org Fri Feb 9 13:16:30 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 9 Feb 2001 13:16:30 +1100 (EST) Subject: sftp client In-Reply-To: <3A827792.3090303@skalasoft.com> Message-ID: On Thu, 8 Feb 2001, Roumen Petrov wrote: > 3.) > My result is: > ----------------------------- > Executing /.bashrc ... > /root/.bashrc > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 4.) > And result from 'sftp localhost' is: > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Connecting to localhost... > ...... > Received message too long 1165518179 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 5.) > info: 1165518179 = 0x45786563 = "Exec" !!!! This is what I have been trying to tell you, note that the above will also break r{sh,exec} based programs and sftp. Your shell initialisation should not print *anything* if your shell is not interactive. -d -- | Damien Miler \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Fri Feb 9 13:19:06 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 9 Feb 2001 13:19:06 +1100 (EST) Subject: question re:scp In-Reply-To: <20010208145618.I18379@inuyasha.arcs.ac.at> Message-ID: On Thu, 8 Feb 2001 tatjana.svizensky at arcs.ac.at wrote: > > The problem is with: > > > > inuyasha:/mnt/vortex/backup # scp ttsrvun1:/mnt/storage/backup/zditf2usrusers.dump . > > zditf2usrusers.dump 0% | | 0 --:-- ETA > > protocol error: expected control record > > Write failed flushing stdout buffer. > > write stdout: Broken pipe > > > > where strace has the following to say at this point: > > fstat64(6, {st_mode=S_IFIFO|0600, st_size=1, ...}) = 0 > > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 > > _llseek(6, 0, 0xbfffebc4, SEEK_CUR) = -1 ESPIPE (Illegal seek) > > > > so the correct fstat for files >2G is taken, but llseek instead of llseek64. Someone needs to implement support for the (ugly IMO) llseek64 interface in openssh. Anyone? -d -- | Damien Miler \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From carl at bl.echidna.id.au Fri Feb 9 13:19:06 2001 From: carl at bl.echidna.id.au (carl at bl.echidna.id.au) Date: Fri, 9 Feb 2001 13:19:06 +1100 (EST) Subject: sftp client Message-ID: <200102090219.f192J6I13358@rollcage.bl.echidna.id.au> This is a good thing to have in a csh .cshrc .. I guess you'd do similar for those evil SV based shells :) if ($?USER == 0 || $?prompt == 0) exit Carl > From: Damien Miller > To: Roumen Petrov > Cc: mouring at etoh.eviladmin.org, openssh-unix-dev at mindrot.org > > On Thu, 8 Feb 2001, Roumen Petrov wrote: > > > > 3.) > > My result is: > > ----------------------------- > > Executing /.bashrc ... > > /root/.bashrc > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > 4.) > > And result from 'sftp localhost' is: > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Connecting to localhost... > > ...... > > Received message too long 1165518179 > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > 5.) > > info: 1165518179 = 0x45786563 = "Exec" !!!! > > This is what I have been trying to tell you, note that the above will > also break r{sh,exec} based programs and sftp. > > Your shell initialisation should not print *anything* if your shell is > not interactive. > > -d > > -- > | Damien Miler \ ``E-mail attachments are the poor man's > | http://www.mindrot.org / distributed filesystem'' - Dan Geer > > > From djm at mindrot.org Fri Feb 9 13:20:24 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 9 Feb 2001 13:20:24 +1100 (EST) Subject: OpenSSH 2.3.0p4/2.2.0p1, Solaris 8, ssh-keygen bus error In-Reply-To: Message-ID: On Thu, 8 Feb 2001, Edward S. Marshall wrote: > Hi, > > I'm having a problem with ssh-keygen on Solaris 8; upon running, it > produces a bus error due to a function call in OpenSSL (RC4_set_key): Could you please turn on very verbose debugging "ssh -v -v -v " and report the output? Thanks -d -- | Damien Miler \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Fri Feb 9 13:23:31 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 9 Feb 2001 13:23:31 +1100 (EST) Subject: sshd question: In-Reply-To: Message-ID: On Thu, 8 Feb 2001, Sunil K. Vallamkonda wrote: > > > Hello, > > I have sshd version:SSH_VERSION "OpenSSH_2.3.1p1" > > When I run (using inted.conf), > at client-side I get error: > > Bad remote protocol version identification: 'sshd: no hostkeys available > -- exiting. Your server is misconfigured and is reporting the error message over the inetd socket. Telnet to your server port 22 to see the full error message. -d -- | Damien Miler \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Fri Feb 9 13:26:00 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 9 Feb 2001 13:26:00 +1100 (EST) Subject: sftp client In-Reply-To: <20010208201359.E910@cygbert.vinschen.de> Message-ID: On Thu, 8 Feb 2001, Corinna Vinschen wrote: > > Can you turn on debugging in the sftp-server by editing the #define TRACE > > to use log instead of debug. I would like to see whether ssh.com sftp > > sends an explicit close message. > > Session: > > $ sftp cvaio > sftp> pwd > /home/corinna > sftp> ^D > > Log with ssh.com sftp: > > sftp-server : Cygwin Process Id = 0x63C : client version 2 > sftp-server : Cygwin Process Id = 0x63C : realpath id 0 path . > sftp-server : Cygwin Process Id = 0x63C : sent names id 0 count 1 > > Log with openssh sftp: > > sftp-server : Cygwin Process Id = 0x5D4 : client version 2 > sftp-server : Cygwin Process Id = 0x5D4 : realpath id -1560921021 path . > sftp-server : Cygwin Process Id = 0x5D4 : sent names id -1560921021 count 1 > > Is that helpful?!? Not really :( They are doing exactly the same thing. Perhaps there is a difference in how they close the underlying ssh session. > BTW: What's about the patch to sftp-client.c I sent two days ago which > solves the "Couldn't close file: No Such File" problem? It is in the OpenBSD tree and will be synced soon with portable. -d -- | Damien Miler \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Fri Feb 9 13:30:18 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 9 Feb 2001 13:30:18 +1100 (EST) Subject: Authentication By-Pass Vulnerability in OpenSSH 2.3.1 (devel snapshot) (fwd) In-Reply-To: Message-ID: On Fri, 9 Feb 2001, Kevin Steves wrote: fyi I have zeroed out all the broken snapshots to prevent people downloading the vulnerable code. The next snapshot will have the fix included. -d > fyi for those running snapshots. the latest portable cvs has the fix > and the version is 2.3.2p1. > > Kevin > > ---------- Forwarded message ---------- > Date: Thu, 08 Feb 2001 18:15:00 -0500 > From: Niels Provos > To: security-announce at openbsd.org > Subject: Authentication By-Pass Vulnerability in OpenSSH 2.3.1 (devel > snapshot) > > ---------------------------------------------------------------------------- > > OpenBSD Security Advisory > > February 8, 2001 > > Authentication By-Pass Vulnerability in OpenSSH-2.3.1 > > ---------------------------------------------------------------------------- > > SYNOPSIS > > OpenSSH-2.3.1, a development snapshot, only checked if a public key > for public key authentication was permitted. In the protocol 2 part > of the server, the challenge-response step that ensures that the > connecting client is in possession of the corresponding private key > has been omitted. As a result, anyone who could obtain the public key > listed in the users authorized_keys file could log in as that user > without authentication. > > A fix for this problem was committed on Februrary 8th. The problem > was introduced on January 18th. This is a three week time window. > > ---------------------------------------------------------------------------- > > AFFECTED SYSTEMS > > This vulnerability affects only OpenSSH version 2.3.1 with support for > protocol 2 enabled. The latest official release OpenSSH 2.3.0 is not > affected by this problem. The latest snapshot version OpenSSH 2.3.2 > is not affected either. > > ---------------------------------------------------------------------------- > > RESOLUTION > > If you installed the OpenSSH 2.3.1 development snapshot, install the > latest snapshot. Currently, the latest snapshot is OpenSSH 2.3.2 which > is available via http://www.openssh.com/. > > ---------------------------------------------------------------------------- > > > -- | Damien Miler \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From mouring at etoh.eviladmin.org Fri Feb 9 14:54:13 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 8 Feb 2001 21:54:13 -0600 (CST) Subject: sftp / latest snapshot In-Reply-To: Message-ID: On Thu, 8 Feb 2001 mouring at etoh.eviladmin.org wrote: > On Thu, 8 Feb 2001, Lutz Jaenicke wrote: [..] > > - Linking sftp fails, because seed_rng() cannot be resolved. Actually it > > is in entropy.c (libssh) and needed by arc4random.c. A similar problem > > has been discussed several days ago and the problem should be solved by > > removing arc4random calls from sftp-client.c. In the ChangeLog there is: > > 20010208 > > - (djm) Fix linking of sftp, don't need arc4random any more. > > But sftp-client is dated Feb 5 and still contains the calls. Maybe the > > check-in was forgotten!? > > I have to assume that sftp-client.c was not synced. I saw this but did > not think much about it at the time. (Because I've been too busy dealing > with a video editing project to compile the latest version) > I synced up sftp-client.c enough to compile. If someone does not get it before me. I'll deal with the rest tomorrow night. I really have to get at this video editing projects before some people kill me. =) - Ben From mouring at etoh.eviladmin.org Fri Feb 9 14:57:48 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 8 Feb 2001 21:57:48 -0600 (CST) Subject: sftp client In-Reply-To: Message-ID: On Fri, 9 Feb 2001, Damien Miller wrote: > On Thu, 8 Feb 2001, Roumen Petrov wrote: > > > > 3.) > > My result is: > > ----------------------------- > > Executing /.bashrc ... > > /root/.bashrc > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > 4.) > > And result from 'sftp localhost' is: > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Connecting to localhost... > > ...... > > Received message too long 1165518179 > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > 5.) > > info: 1165518179 = 0x45786563 = "Exec" !!!! > > This is what I have been trying to tell you, note that the above will > also break r{sh,exec} based programs and sftp. > > Your shell initialisation should not print *anything* if your shell is > not interactive. > I have to agree here. This goes for any shell.. csh, tcsh, bash, ksh, ksh93, etc.. I really wish we could drop the requirement for the user's shell for subsystem and require the admin to build a sane {PREFIX}/etc/enviroment file (and let users override things in their ~/.ssh/enviroment. Because the subsystems can't really use the shell for anything useful. It just sucks off the enviroment variables. - Ben From Darren.Moffat at eng.sun.com Fri Feb 9 14:10:42 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Thu, 8 Feb 2001 19:10:42 -0800 (PST) Subject: sftp client Message-ID: <200102090310.f193AhR203613@jurassic.eng.sun.com> >> > info: 1165518179 = 0x45786563 = "Exec" !!!! >> >> This is what I have been trying to tell you, note that the above will >> also break r{sh,exec} based programs and sftp. >> >> Your shell initialisation should not print *anything* if your shell is >> not interactive. >> >I have to agree here. This goes for any shell.. csh, tcsh, bash, ksh, >ksh93, etc.. > >I really wish we could drop the requirement for the user's shell for >subsystem and require the admin to build a sane {PREFIX}/etc/enviroment >file (and let users override things in their ~/.ssh/enviroment. Because >the subsystems can't really use the shell for anything useful. It just >sucks off the enviroment variables. Can you please go and voice that point of view on the ietf mailing list (if you haven't already done so) for SSH in reference to subsystems in general and the file-xfer draft in particular. In case you don't know the list is at ietf-ssh at clinet.fi. I am of the same opnion as I believe it is an implmenation issue but some people were trying to say it should be advice in the draft that subsystems do it. Personally I'm dead against it, normal ftp doesn't do it so why should sftp. Ta -- Darren J Moffat From djm at mindrot.org Fri Feb 9 14:30:43 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 9 Feb 2001 14:30:43 +1100 (EST) Subject: sftp client In-Reply-To: <200102090310.f193AhR203613@jurassic.eng.sun.com> Message-ID: On Thu, 8 Feb 2001, Darren Moffat wrote: > Can you please go and voice that point of view on the ietf mailing list > (if you haven't already done so) for SSH in reference to subsystems in > general and the file-xfer draft in particular. In case you don't know > the list is at ietf-ssh at clinet.fi. I can't even get messages through to the ietf-ssh at clinet.fi list. Messages to owner-ietf-ssh@ and postmaster@ have not been replied to :( -d -- | Damien Miler \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From provos at CITI.UMICH.EDU Fri Feb 9 11:19:53 2001 From: provos at CITI.UMICH.EDU (Niels Provos) Date: Thu, 8 Feb 2001 19:19:53 -0500 Subject: Authentication By-Pass Vulnerability in OpenSSH-2.3.1 (devel snapshot) Message-ID: <20010209001953.7A804207C1@citi.umich.edu> Please, check http://www.openssh.com/security.html for a full summary of security related issues in OpenSSH. ---------------------------------------------------------------------------- OpenBSD Security Advisory February 8, 2001 Authentication By-Pass Vulnerability in OpenSSH-2.3.1 ---------------------------------------------------------------------------- SYNOPSIS OpenSSH-2.3.1, a development snapshot, only checked if a public key for public key authentication was permitted. In the protocol 2 part of the server, the challenge-response step that ensures that the connecting client is in possession of the corresponding private key has been omitted. As a result, anyone who could obtain the public key listed in the users authorized_keys file could log in as that user without authentication. A fix for this problem was committed on Februrary 8th. The problem was introduced on January 18th. This is a three week time window. ---------------------------------------------------------------------------- AFFECTED SYSTEMS This vulnerability affects only OpenSSH version 2.3.1 with support for protocol 2 enabled. The latest official release OpenSSH 2.3.0 is not affected by this problem. The latest snapshot version OpenSSH 2.3.2 is not affected either. ---------------------------------------------------------------------------- RESOLUTION If you installed the OpenSSH 2.3.1 development snapshot, install the latest snapshot. Currently, the latest snapshot is OpenSSH 2.3.2 which is available via http://www.openssh.com/. ---------------------------------------------------------------------------- From Lutz.Jaenicke at aet.TU-Cottbus.DE Fri Feb 9 20:36:57 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Fri, 9 Feb 2001 10:36:57 +0100 Subject: sftp / latest snapshot In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Feb 08, 2001 at 09:54:13PM -0600 References: Message-ID: <20010209103657.A5055@serv01.aet.tu-cottbus.de> On Thu, Feb 08, 2001 at 09:54:13PM -0600, mouring at etoh.eviladmin.org wrote: > I synced up sftp-client.c enough to compile. If someone does not get it > before me. I'll deal with the rest tomorrow night. I really have to get > at this video editing projects before some people kill me. =) Thanks. Good luck with your projects. Lutz PS. There is not _PATH_TTY on HP-UX... -- 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 Fri Feb 9 21:24:56 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Fri, 9 Feb 2001 11:24:56 +0100 Subject: Nessus / 2.3.0p1 Message-ID: <20010209112456.A7378@ws01.aet.tu-cottbus.de> Hi! Our computer center is currently examining registered servers (offering services passing the firewall) using Nessus. Yesterday I had a ssh-connection closing on one host. Today I have seen serv01 155: channel 0: istate 4 != open channel 0: ostate 64 != open popping up, the connection survived however... In both cases the client host was not scanned but the server host (one was Linux, one was HP-UX). Any ideas what's going on? 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 djm at mindrot.org Fri Feb 9 22:55:08 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 9 Feb 2001 22:55:08 +1100 (EST) Subject: sftp / latest snapshot In-Reply-To: <20010209103657.A5055@serv01.aet.tu-cottbus.de> Message-ID: On Fri, 9 Feb 2001, Lutz Jaenicke wrote: > On Thu, Feb 08, 2001 at 09:54:13PM -0600, mouring at etoh.eviladmin.org wrote: > > I synced up sftp-client.c enough to compile. If someone does not get it > > before me. I'll deal with the rest tomorrow night. I really have to get > > at this video editing projects before some people kill me. =) > > Thanks. Good luck with your projects. > Lutz > PS. There is not _PATH_TTY on HP-UX... I am committing this: Index: defines.h =================================================================== RCS file: /var/cvs/openssh/defines.h,v retrieving revision 1.53 diff -u -r1.53 defines.h --- defines.h 2001/02/09 01:55:36 1.53 +++ defines.h 2001/02/09 11:54:36 @@ -303,6 +303,10 @@ #define XAUTH_PATH "/usr/X11R6/bin/xauth" #endif /* XAUTH_PATH */ +#ifndef _PATH_TTY +# define _PATH_TTY "/dev/tty" +#endif + /* Macros */ #if defined(HAVE_LOGIN_GETCAPBOOL) && defined(HAVE_LOGIN_CAP_H) -- | Damien Miler \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From Lutz.Jaenicke at aet.TU-Cottbus.DE Fri Feb 9 23:51:59 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Fri, 9 Feb 2001 13:51:59 +0100 Subject: sftp / latest snapshot In-Reply-To: ; from djm@mindrot.org on Fri, Feb 09, 2001 at 10:55:08PM +1100 References: <20010209103657.A5055@serv01.aet.tu-cottbus.de> Message-ID: <20010209135159.A9900@serv01.aet.tu-cottbus.de> On Fri, Feb 09, 2001 at 10:55:08PM +1100, Damien Miller wrote: > On Fri, 9 Feb 2001, Lutz Jaenicke wrote: > > PS. There is not _PATH_TTY on HP-UX... > +#ifndef _PATH_TTY > +# define _PATH_TTY "/dev/tty" > +#endif That helps, thanks, 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 han.holl at prismant.nl Sat Feb 10 00:31:25 2001 From: han.holl at prismant.nl (Han Holl) Date: Fri, 9 Feb 2001 14:31:25 +0100 Subject: Bug in auth-options.c Message-ID: <01020914312500.12971@bever.palga.uucp> Hi, There's a nasty bug in auth-open.c that causes all options in a line of authorized_keys to be applied to all subsequent lines without options. IMNSHO this clearly shows the evil of global variables, and using extern whatever as a means of information sharing. Cheers, Han Holl --- auth-options.c.orig Fri Feb 9 14:14:51 2001 +++ auth-options.c Fri Feb 9 14:18:43 2001 @@ -57,11 +57,12 @@ auth_parse_options(struct passwd *pw, char *options, unsigned long linenum) { const char *cp; - if (!options) - return 1; /* reset options */ auth_clear_options(); + + if (!options) + return 1; while (*options && *options != ' ' && *options != '\t') { cp = "no-port-forwarding"; From Markus.Friedl at informatik.uni-erlangen.de Sat Feb 10 00:39:05 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 9 Feb 2001 14:39:05 +0100 Subject: Bug in auth-options.c In-Reply-To: <01020914312500.12971@bever.palga.uucp>; from han.holl@prismant.nl on Fri, Feb 09, 2001 at 02:31:25PM +0100 References: <01020914312500.12971@bever.palga.uucp> Message-ID: <20010209143905.A1485@faui02.informatik.uni-erlangen.de> On Fri, Feb 09, 2001 at 02:31:25PM +0100, Han Holl wrote: > There's a nasty bug in auth-open.c that causes all options in a line > of authorized_keys to be applied to all subsequent lines without > options. thanks. > IMNSHO this clearly shows the evil of global variables, and using > extern whatever as a means of information sharing. sure, you are right, but there are many more things to fix in the code and nobody bothered to remove all the globals inherited from ssh-1.2.12. -m From roumen.petrov at skalasoft.com Sat Feb 10 01:52:34 2001 From: roumen.petrov at skalasoft.com (Roumen Petrov) Date: Fri, 09 Feb 2001 16:52:34 +0200 Subject: sftp client References: Message-ID: <3A840432.6010009@skalasoft.com> Damien Miller wrote: > On Thu, 8 Feb 2001, Roumen Petrov wrote: > ... >> Received message too long 1165518179 ... > This is what I have been trying to tell you, note that the above will > also break r{sh,exec} based programs and sftp. > > Your shell initialisation should not print *anything* if your shell is > not interactive. > I found very useful my $HOME/.bashrc to print some messages ! From Markus.Friedl at informatik.uni-erlangen.de Sat Feb 10 02:18:49 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 9 Feb 2001 16:18:49 +0100 Subject: sftp client In-Reply-To: <3A840432.6010009@skalasoft.com>; from roumen.petrov@skalasoft.com on Fri, Feb 09, 2001 at 04:52:34PM +0200 References: <3A840432.6010009@skalasoft.com> Message-ID: <20010209161849.B8990@faui02.informatik.uni-erlangen.de> On Fri, Feb 09, 2001 at 04:52:34PM +0200, Roumen Petrov wrote: > > > Damien Miller wrote: > > > On Thu, 8 Feb 2001, Roumen Petrov wrote: > > > ... > > >> Received message too long 1165518179 > ... > > > This is what I have been trying to tell you, note that the above will > > also break r{sh,exec} based programs and sftp. > > > > Your shell initialisation should not print *anything* if your shell is > > not interactive. > > > I found very useful my $HOME/.bashrc to print some messages ! but only for interactive shells. if .bashrc prints messages it will break: rcp scp rsync cvs and so on. From Markus.Friedl at informatik.uni-erlangen.de Sat Feb 10 02:19:18 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 9 Feb 2001 16:19:18 +0100 Subject: sftp client In-Reply-To: <3A840432.6010009@skalasoft.com>; from roumen.petrov@skalasoft.com on Fri, Feb 09, 2001 at 04:52:34PM +0200 References: <3A840432.6010009@skalasoft.com> Message-ID: <20010209161917.C8990@faui02.informatik.uni-erlangen.de> On Fri, Feb 09, 2001 at 04:52:34PM +0200, Roumen Petrov wrote: > I found very useful my $HOME/.bashrc to print some messages ! try printing to stderr if you need to print. From roumen.petrov at skalasoft.com Sat Feb 10 02:32:51 2001 From: roumen.petrov at skalasoft.com (Roumen Petrov) Date: Fri, 09 Feb 2001 17:32:51 +0200 Subject: sftp client References: <3A840432.6010009@skalasoft.com> <20010209161849.B8990@faui02.informatik.uni-erlangen.de> Message-ID: <3A840DA3.1040005@skalasoft.com> Markus Friedl wrote: > On Fri, Feb 09, 2001 at 04:52:34PM +0200, Roumen Petrov wrote: > >> >> Damien Miller wrote: >> >> >>> On Thu, 8 Feb 2001, Roumen Petrov wrote: >>> >> >> ... >> >> >>>> Received message too long 1165518179 >>> >> ... >> >> >>> This is what I have been trying to tell you, note that the above will >>> also break r{sh,exec} based programs and sftp. >>> >>> Your shell initialisation should not print *anything* if your shell is >>> not interactive. >>> >> >> I found very useful my $HOME/.bashrc to print some messages ! > > > but only for interactive shells. > > if .bashrc prints messages it will break: > rcp > scp > rsync > cvs > > and so on. Printing some messages from $HOME/.bashrc break only OpenSSH utilites and not SSH.COM !!! I might use in future ssh from ssh.com. From Markus.Friedl at informatik.uni-erlangen.de Sat Feb 10 02:44:39 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 9 Feb 2001 16:44:39 +0100 Subject: sftp client In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Feb 08, 2001 at 09:57:48PM -0600 References: Message-ID: <20010209164439.A9117@faui02.informatik.uni-erlangen.de> On Thu, Feb 08, 2001 at 09:57:48PM -0600, mouring at etoh.eviladmin.org wrote: > I really wish we could drop the requirement for the user's shell for > subsystem no, i don't want to drop this. the shell sets umask or is used for access control, e.g. /bin/false. -m From Markus.Friedl at informatik.uni-erlangen.de Sat Feb 10 02:58:42 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 9 Feb 2001 16:58:42 +0100 Subject: sftp client In-Reply-To: <3A840DA3.1040005@skalasoft.com>; from roumen.petrov@skalasoft.com on Fri, Feb 09, 2001 at 05:32:51PM +0200 References: <3A840432.6010009@skalasoft.com> <20010209161849.B8990@faui02.informatik.uni-erlangen.de> <3A840DA3.1040005@skalasoft.com> Message-ID: <20010209165842.A10768@faui02.informatik.uni-erlangen.de> On Fri, Feb 09, 2001 at 05:32:51PM +0200, Roumen Petrov wrote: > > if .bashrc prints messages it will break: > > rcp > > scp > > rsync > > cvs > > > > and so on. > > Printing some messages from $HOME/.bashrc break only OpenSSH utilites > and not SSH.COM !!! > I might use in future ssh from ssh.com. are you sure? % cat /home/msfriedl/.bashrc echo hallo % telnet localhost 20005 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. SSH-1.99-2.4.0 SSH Secure Shell (non-commercial) ^] telnet> Connection closed. % rsync msfriedl at local24:/bsd /tmp/bsdx msfriedl at localhost's password: protocol version mismatch - is your shell clean? (see the rsync man page for an explanation) [2] so how can ssh from ssh.com help you in the future? From mouring at etoh.eviladmin.org Sat Feb 10 04:33:09 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 9 Feb 2001 11:33:09 -0600 (CST) Subject: sftp client In-Reply-To: <20010209164439.A9117@faui02.informatik.uni-erlangen.de> Message-ID: On Fri, 9 Feb 2001, Markus Friedl wrote: > On Thu, Feb 08, 2001 at 09:57:48PM -0600, mouring at etoh.eviladmin.org wrote: > > I really wish we could drop the requirement for the user's shell for > > subsystem > > no, i don't want to drop this. > > the shell sets umask or is used for access control, e.g. /bin/false. > Using shells as access control has always been an ugly hack to me, and as a result I was glad to see User/Group Access List appear. If 'umask' is the only other argument for shell around then I'd be happy to submit a patch to make .ssh/environment smart enough to detect 'umask' variable and set the umask so we can drop the shell. Otherwise, there has to be a better reason for it. - Ben From Markus.Friedl at informatik.uni-erlangen.de Sat Feb 10 03:44:06 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 9 Feb 2001 17:44:06 +0100 Subject: sftp client In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Feb 09, 2001 at 11:33:09AM -0600 References: <20010209164439.A9117@faui02.informatik.uni-erlangen.de> Message-ID: <20010209174406.E10768@faui02.informatik.uni-erlangen.de> On Fri, Feb 09, 2001 at 11:33:09AM -0600, mouring at etoh.eviladmin.org wrote: > Using shells as access control has always been an ugly hack to me, and as > a result I was glad to see User/Group Access List appear. > > If 'umask' is the only other argument for shell around then I'd be happy > to submit a patch to make .ssh/environment smart enough to detect 'umask' > variable and set the umask so we can drop the shell. Otherwise, there has > to be a better reason for it. this is an ugly hack. i don't like .ssh/environment at all. i don't see the reason for dropping the shell. From devon at admin2.gisnetworks.com Sat Feb 10 04:02:06 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Fri, 9 Feb 2001 09:02:06 -0800 Subject: sftp client References: <20010209164439.A9117@faui02.informatik.uni-erlangen.de> <20010209174406.E10768@faui02.informatik.uni-erlangen.de> Message-ID: <004f01c092ba$084efae0$1900a8c0@devn> i personally would like to see the requirement of a valid shell (defined by a shell that you can execute commands with, not an entry in /etc/shells) dropped. i work for a hosting company, and being able to give a user sftp access while not giving them shell access would be invaluable. (if i can keep 'em from leaving their home directory, well, even better!) IMO, shell access and (s)ftp access should be two entirely seperate issues. devon ----- Original Message ----- From: "Markus Friedl" To: Cc: Sent: Friday, February 09, 2001 8:44 AM Subject: Re: sftp client > On Fri, Feb 09, 2001 at 11:33:09AM -0600, mouring at etoh.eviladmin.org wrote: > > Using shells as access control has always been an ugly hack to me, and as > > a result I was glad to see User/Group Access List appear. > > > > If 'umask' is the only other argument for shell around then I'd be happy > > to submit a patch to make .ssh/environment smart enough to detect 'umask' > > variable and set the umask so we can drop the shell. Otherwise, there has > > to be a better reason for it. > > this is an ugly hack. i don't like .ssh/environment at all. > > i don't see the reason for dropping the shell. > > From Markus.Friedl at informatik.uni-erlangen.de Sat Feb 10 04:02:07 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 9 Feb 2001 18:02:07 +0100 Subject: sftp client In-Reply-To: <004f01c092ba$084efae0$1900a8c0@devn>; from devon@admin2.gisnetworks.com on Fri, Feb 09, 2001 at 09:02:06AM -0800 References: <20010209164439.A9117@faui02.informatik.uni-erlangen.de> <20010209174406.E10768@faui02.informatik.uni-erlangen.de> <004f01c092ba$084efae0$1900a8c0@devn> Message-ID: <20010209180207.C14279@faui02.informatik.uni-erlangen.de> On Fri, Feb 09, 2001 at 09:02:06AM -0800, Devon Bleak wrote: > i personally would like to see the requirement of a valid shell (defined by > a shell that you can execute commands with, not an entry in /etc/shells) > dropped. i work for a hosting company, and being able to give a user sftp > access while not giving them shell access would be invaluable. (if i can > keep 'em from leaving their home directory, well, even better!) give them a shell that does chroot and exec of sftp-server -m From josb at cncdsl.com Sat Feb 10 05:14:59 2001 From: josb at cncdsl.com (Jos Backus) Date: Fri, 9 Feb 2001 10:14:59 -0800 Subject: sftp client In-Reply-To: <20010209180207.C14279@faui02.informatik.uni-erlangen.de>; from Markus.Friedl@informatik.uni-erlangen.de on Fri, Feb 09, 2001 at 06:01:45PM +0100 References: <20010209164439.A9117@faui02.informatik.uni-erlangen.de> <20010209174406.E10768@faui02.informatik.uni-erlangen.de> <004f01c092ba$084efae0$1900a8c0@devn> <20010209180207.C14279@faui02.informatik.uni-erlangen.de> Message-ID: <20010209101459.A6536@lizzy.bugworks.com> On Fri, Feb 09, 2001 at 06:01:45PM +0100, Markus Friedl wrote: > On Fri, Feb 09, 2001 at 09:02:06AM -0800, Devon Bleak wrote: > > i personally would like to see the requirement of a valid shell (defined by > > a shell that you can execute commands with, not an entry in /etc/shells) > > dropped. i work for a hosting company, and being able to give a user sftp > > access while not giving them shell access would be invaluable. (if i can > > keep 'em from leaving their home directory, well, even better!) I agree. > give them a shell that does chroot and exec of sftp-server This has the disadvantage that one needs to set up an evironment in which sftp-server can run chrooted, for each customer. -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From Darren.Moffat at eng.sun.com Sat Feb 10 06:22:57 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Fri, 9 Feb 2001 11:22:57 -0800 (PST) Subject: sftp client Message-ID: <200102091922.f19JMvR339628@jurassic.eng.sun.com> >On Thu, Feb 08, 2001 at 09:57:48PM -0600, mouring at etoh.eviladmin.org wrote: >> I really wish we could drop the requirement for the user's shell for >> subsystem > >no, i don't want to drop this. > >the shell sets umask or is used for access control, e.g. /bin/false. Would you agree that the only reason to run the users shell is to set the umask ? Since you don't like the suggestion of using .ssh/environment (which I agree with since umask is not an environment variable). What about having the umask set in .ssh/rc ? As for the access control I would have to say that this is an abuse of the name service getpwnam() call. This is what PAM was designed for and also what the User/Group list support in sshd is for. Or do you have other reasons for wanting the shell to be run ? -- Darren J Moffat From mhpower at bos.bindview.com Sat Feb 10 06:38:02 2001 From: mhpower at bos.bindview.com (Matt Power) Date: Fri, 9 Feb 2001 14:38:02 -0500 Subject: severe error in SSH session key recovery patch Message-ID: <200102091938.OAA25451@theta.bos.bindview.com> http://www.core-sdi.com/advisories/ssh1_sessionkey_recovery.htm includes the line of code: kill(SIGALRM, getppid()); This is contained within what is listed as an "unsupported and untested patch" developed by SSH.com. The problem is that the arguments to "kill" are in the wrong order. In other words, to obtain the effect that was apparently intended, the line of code should have been kill(getppid(), SIGALRM); One effect is that the patch does not, in any way, help reduce the risks associated with the session key recovery vulnerability, since the parent process will not receive an ALRM signal and thus will not regenerate a server key. The other possible effect is that there might be a process whose pid is equal to the numerical value of SIGALRM, and the value of getppid() might be a signal number that, if sent, would have an adverse effect on that process and consequently an adverse effect on system stability. (The call to "kill" is fine in the rare case where SIGALRM and getppid() happen to be numerically equal.) (This posting is intended to point out the error in the "kill" line of that patch; it is not intended to provide a recommendation that the patch be used if the "kill" line is corrected.) To determine whether the corrected patch seems appropriate for one's intended application, here are a few other factors to consider: -- if sshd is run from tcpserver (see http://cr.yp.to/ucspi-tcp/tcpserver.html) using a command line such as "tcpserver 0 ssh /usr/local/sbin/sshd -i", the "kill(getppid(), SIGALRM);" will cause the tcpserver process to terminate. Unless another process exists that will automatically restart that tcpserver process, access to the system via ssh will be no longer available. There may be a version of inetd or an inetd derivative that will also terminate upon receiving an ALRM signal. However, it is commonly the case that an inetd process will not terminate if it receives an ALRM signal. It happens to be the case that the patch involving "kill(getppid(), SIGALRM);" is not needed if sshd is run from either tcpserver or inetd. Still, some organizations may be deploying a version of sshd with this patch onto systems where tcpserver is used, especially if they are using an sshd package that was put together without this tcpserver issue in mind. It is not a bug in tcpserver that the process terminates when it receives an ALRM signal. Any "normal" program started by tcpserver will not be sending an ALRM signal to getppid(), so one shouldn't expect the design of tcpserver to anticipate that. Running an sshd supporting SSH protocol 1.5 from inetd/tcpserver rather than standalone is a tradeoff between DoS concerns and session-key-recovery concerns. The right decision will not be the same in all environments. -- With the patch, the lifespan of the server key still does not go below one minute. As mentioned in CORE SDI's advisory, the number of server connections necessary to carry out the attack is normally very large but "the number of connections given is for the average case and specifics cases will fall below the average". This suggests that is not entirely out of the question for the attack to succeed within one minute. If that risk is not appropriate in one's environment, then other measures (which may include inetd/tcpserver but may also include desupporting use of SSH protocol 1.5) are needed. Matt Power BindView Corporation, RAZOR Team mhpower at bos.bindview.com From mattl at livecapital.com Sat Feb 10 07:05:56 2001 From: mattl at livecapital.com (Lewandowsky, Matt) Date: Fri, 9 Feb 2001 12:05:56 -0800 Subject: argv[0] => host feature considered harmful Message-ID: <9F8E2B3F8CBAD411AAC4009027DCFDC8074836@exchange.aprivate.com> Could it at least be conditionalized as suggested earlier? If not, I have no problems seeing it go away, either. --Matt -----Original Message----- From: Damien Miller [mailto:djm at mindrot.org] Sent: Thursday, February 08, 2001 4:19 PM To: Theo de Raadt Cc: Markus.Friedl at informatik.uni-erlangen.de; openssh at openSSH.com; openssh-unix-dev at mindrot.org Subject: Re: argv[0] => host feature considered harmful On Thu, 8 Feb 2001, Theo de Raadt wrote: > >do we care about 'argv[0] => host'. > >i don't like it but it seems to be to late to drop this > >rlogin-compatible feature. a new option seems the only > >good option. > > I would have no problem with seeing it go away. Ditto. -d -- | Damien Miler \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010209/fc6211af/attachment.html From ancelmo at siia.umich.mx Sat Feb 10 07:05:53 2001 From: ancelmo at siia.umich.mx (Ancelmo Rodriguez Parra) Date: Fri, 9 Feb 2001 14:05:53 -0600 (CST) Subject: I don't know if this is the right place Message-ID: I don't know if this is the right place for my problem, but couldn't find any other place. I am trying to install OpenSSH in a HPUX system, I installed OpenSSL and Zlibzlib-1.1.3, but when I execute configure, get the following: # ./configure loading cache ./config.cache checking for gcc... cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross-compiler... no checking whether we are using GNU C... no checking whether cc accepts -g... no checking host system type... hppa2.0n-hp-hpux11.00 checking how to run the C preprocessor... cc -E checking for ranlib... ranlib checking for a BSD compatible install... ./install-sh -c checking for ar... ar checking for perl... /opt/perl5/bin//perl checking for ent... no checking for login... /usr/bin/login checking for inline... no checking for HPUX trusted system password database... yes configure: warning: This configuration is untested checking for deflate in -lz... no configure: error: *** zlib missing - please install first *** can you help me? if not, please also tell me. From stevesk at sweden.hp.com Sat Feb 10 07:16:53 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Fri, 9 Feb 2001 21:16:53 +0100 (MET) Subject: I don't know if this is the right place In-Reply-To: Message-ID: On Fri, 9 Feb 2001, Ancelmo Rodriguez Parra wrote: : checking for HPUX trusted system password database... yes : configure: warning: This configuration is untested : checking for deflate in -lz... no : configure: error: *** zlib missing - please install first *** : : can you help me? if not, please also tell me. if your zlib isn't in a place the compiler and linker will find headers and lib, you need to tell them where they are; i do this: VER=openssh-2.3.0p1 SRC=/usr/src CFLAGS="+w1 +W 486,474 +O3 +ESlit +Optrs_strongly_typed \ -I$SRC/zlib/zlib-1.1.3/ -I$SRC/tcp_wrappers/tcp_wrappers_7.6" \ LDFLAGS="-L$SRC/zlib/zlib-1.1.3 -L$SRC/tcp_wrappers/tcp_wrappers_7.6" \ ./configure --prefix=/opt/${VER} \ --sysconfdir=/etc/opt/openssh \ --with-default-path="/usr/bin:/usr/sbin:/opt/${VER}/bin" \ --with-ssl-dir=$SRC/openssl/openssl-0.9.6 \ --with-tcp-wrappers \ --disable-suid-ssh \ --with-egd-pool=/etc/opt/egd/entropy \ --with-pam From tom at avatar.itc.nrcs.usda.gov Sat Feb 10 07:39:30 2001 From: tom at avatar.itc.nrcs.usda.gov (Tom Rudnick) Date: Fri, 9 Feb 2001 13:39:30 -0700 (MST) Subject: pty problems w/ Unixware In-Reply-To: from "Damien Miller" at Feb 02, 2001 09:39:54 AM Message-ID: <200102092039.NAA08725@avatar.itc.nrcs.usda.gov> > > Looks good to me. Doing this: > > - sa.sa_flags = 0; > + sa.sa_flags = SA_RESTART; > > Might also help the Unixware problem. > > -d Yes! That fixed it. I made the change to todays misc.c version from the cvs and rebuilt. This should fix all of the UnixWare platforms (2.0, 2.1, 7.x) I believe. Now... are there any implications at other locations in the code or for other platforms? Can we make this change for everybody? -Tom -- ----------------/---------------------------------------------- Tom Rudnick | USDA Natural Resources Conservation Service Fort Collins,CO | tom at avatar.itc.nrcs.usda.gov (970) 295-5427 ** The 3rd Millennium starts Jan 1, 2001. see: ** ** http://aa.usno.navy.mil/AA/faq/docs/millennium.html ** -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From ancelmo at siia.umich.mx Sat Feb 10 07:46:05 2001 From: ancelmo at siia.umich.mx (Ancelmo Rodriguez Parra) Date: Fri, 9 Feb 2001 14:46:05 -0600 (CST) Subject: I don't know if this is the right place In-Reply-To: Message-ID: > On Fri, 9 Feb 2001, Ancelmo Rodriguez Parra wrote: > : checking for HPUX trusted system password database... yes > : configure: warning: This configuration is untested > : checking for deflate in -lz... no > : configure: error: *** zlib missing - please install first *** > : > : can you help me? if not, please also tell me. > > if your zlib isn't in a place the compiler and linker will find headers > and lib, you need to tell them where they are; i do this: > > VER=openssh-2.3.0p1 > SRC=/usr/src > > CFLAGS="+w1 +W 486,474 +O3 +ESlit +Optrs_strongly_typed \ > -I$SRC/zlib/zlib-1.1.3/ -I$SRC/tcp_wrappers/tcp_wrappers_7.6" \ > LDFLAGS="-L$SRC/zlib/zlib-1.1.3 -L$SRC/tcp_wrappers/tcp_wrappers_7.6" \ > ./configure --prefix=/opt/${VER} \ > --sysconfdir=/etc/opt/openssh \ > --with-default-path="/usr/bin:/usr/sbin:/opt/${VER}/bin" \ > --with-ssl-dir=$SRC/openssl/openssl-0.9.6 \ > --with-tcp-wrappers \ > --disable-suid-ssh \ > --with-egd-pool=/etc/opt/egd/entropy \ > --with-pam > I did the following: **************************************** VER=openssh-2.3.0p1 SRC=/usr/src CFLAGS="+w1 +W 486,474 +O3 +ESlit +Optrs_strongly_typed \ -I /opt/zlib/include/ " LDFLAGS="-L /opt/zlib/lib/" ./configure --prefix=/opt/${VER} \ --sysconfdir=/etc/opt/openssh \ --with-default-path="/usr/bin:/usr/sbin:/opt/${VER}/bin" \ --with-ssl-dir=/opt/openssl/lib/ \ --disable-suid-ssh \ --with-egd-pool=/etc/opt/egd/entropy \ --with-pam # ls /opt/zlib doc include lib ************************************************************** and it still doesn't work :( From djm at mindrot.org Sat Feb 10 10:03:36 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 10 Feb 2001 10:03:36 +1100 (EST) Subject: sftp client In-Reply-To: <3A840432.6010009@skalasoft.com> Message-ID: On Fri, 9 Feb 2001, Roumen Petrov wrote: > > Your shell initialisation should not print *anything* if your shell is > > not interactive. > > > I found very useful my $HOME/.bashrc to print some messages ! It is broken. Use .profile to print stuff. -d -- | Damien Miler \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From gem at rellim.com Sat Feb 10 11:05:08 2001 From: gem at rellim.com (Gary E. Miller) Date: Fri, 9 Feb 2001 16:05:08 -0800 (PST) Subject: SNAP 20010209 fails to compile sftp on Slackware Message-ID: Yo All! openssh-SNAP-20010209.tar.gz fails to compile on Slackware. Patch at the end of this message. Here is the error: gcc -o sftp sftp.o sftp-client.o sftp-common.o sftp-int.o log-client.o -L. -Lopenbsd-compat/ -L/usr/local/ssl/lib -L/usr/local/ssl -lssh -lopenbsd-compat -lcrypt -lz -lnsl -lutil -lcrypto -lwrap openbsd-compat//libopenbsd-compat.a(bsd-arc4random.o): In function `arc4random_stir': /usr/local/src/openssh-SNAP-02082001/openbsd-compat/bsd-arc4random.c:61: undefined reference to `seed_rng' collect2: ld returned 1 exit status make: *** [sftp] Error 1 Here is my configure: ./configure --with-tcp-wrappers --with-md5-passwords --with-default-path=$PATH OpenSSH configured has been configured with the following options. User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /usr/local/etc Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/man/manX PID file: /var/run 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 Preprocessor flags: -I/usr/local/ssl/include Linker flags: -L/usr/local/ssl/lib -L/usr/local/ssl Libraries: -lcrypt -lz -lnsl -lutil -lcrypto -lwrap The quick fix is to add entropy.o to the link of sftp: --- Makefile.in.DIST Fri Feb 9 15:59:44 2001 +++ Makefile.in Fri Feb 9 16:00:04 2001 @@ -111,7 +111,7 @@ $(LD) -o $@ sftp-server.o sftp-common.o log-server.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) sftp$(EXEEXT): $(LIBCOMPAT) libssh.a sftp.o sftp-client.o sftp-int.o sftp-common.o log-client.o - $(LD) -o $@ sftp.o sftp-client.o sftp-common.o sftp-int.o log-client.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) + $(LD) -o $@ sftp.o entropy.o sftp-client.o sftp-common.o sftp-int.o log-client.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) # test driver for the loginrec code - not built by default logintest: logintest.o $(LIBCOMPAT) libssh.a log-client.o loginrec.o I am sure there is a better way, don't know what it may break... 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 From mouring at etoh.eviladmin.org Sat Feb 10 12:00:57 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 9 Feb 2001 19:00:57 -0600 (CST) Subject: SNAP 20010209 fails to compile sftp on Slackware In-Reply-To: Message-ID: It's been resolved in the current tree. - Ben On Fri, 9 Feb 2001, Gary E. Miller wrote: > Yo All! > > openssh-SNAP-20010209.tar.gz fails to compile on Slackware. Patch at > the end of this message. > > Here is the error: > > gcc -o sftp sftp.o sftp-client.o sftp-common.o sftp-int.o log-client.o -L. -Lopenbsd-compat/ -L/usr/local/ssl/lib -L/usr/local/ssl -lssh -lopenbsd-compat -lcrypt -lz -lnsl -lutil -lcrypto -lwrap > openbsd-compat//libopenbsd-compat.a(bsd-arc4random.o): In function `arc4random_stir': > /usr/local/src/openssh-SNAP-02082001/openbsd-compat/bsd-arc4random.c:61: undefined reference to `seed_rng' > collect2: ld returned 1 exit status > make: *** [sftp] Error 1 > > Here is my configure: > > ./configure --with-tcp-wrappers --with-md5-passwords --with-default-path=$PATH > > OpenSSH configured has been configured with the following options. > User binaries: /usr/local/bin > System binaries: /usr/local/sbin > Configuration files: /usr/local/etc > Askpass program: /usr/local/libexec/ssh-askpass > Manual pages: /usr/local/man/manX > PID file: /var/run > 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 > Preprocessor flags: -I/usr/local/ssl/include > Linker flags: -L/usr/local/ssl/lib -L/usr/local/ssl > Libraries: -lcrypt -lz -lnsl -lutil -lcrypto -lwrap > > The quick fix is to add entropy.o to the link of sftp: > > --- Makefile.in.DIST Fri Feb 9 15:59:44 2001 > +++ Makefile.in Fri Feb 9 16:00:04 2001 > @@ -111,7 +111,7 @@ > $(LD) -o $@ sftp-server.o sftp-common.o log-server.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) > > sftp$(EXEEXT): $(LIBCOMPAT) libssh.a sftp.o sftp-client.o sftp-int.o sftp-common.o log-client.o > - $(LD) -o $@ sftp.o sftp-client.o sftp-common.o sftp-int.o log-client.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) > + $(LD) -o $@ sftp.o entropy.o sftp-client.o sftp-common.o sftp-int.o log-client.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) > > # test driver for the loginrec code - not built by default > logintest: logintest.o $(LIBCOMPAT) libssh.a log-client.o loginrec.o > > > I am sure there is a better way, don't know what it may break... > > 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 > > > From djm at mindrot.org Sat Feb 10 11:15:59 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 10 Feb 2001 11:15:59 +1100 (EST) Subject: SNAP 20010209 fails to compile sftp on Slackware In-Reply-To: Message-ID: On Fri, 9 Feb 2001, Gary E. Miller wrote: > Yo All! > > openssh-SNAP-20010209.tar.gz fails to compile on Slackware. Patch at > the end of this message. > > Here is the error: > /usr/local/src/openssh-SNAP-02082001/openbsd-compat/bsd-arc4random.c:61: undefined reference to `seed_rng' Bad me broke the build - the 20010210 snapshot is fixed. -d -- | Damien Miler \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From mouring at etoh.eviladmin.org Sat Feb 10 12:17:27 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 9 Feb 2001 19:17:27 -0600 (CST) Subject: sftp-client.c warning clean up. Message-ID: --- ../openssh/sftp-client.c Fri Feb 9 08:44:24 2001 +++ sftp-client.c Fri Feb 9 19:14:01 2001 @@ -331,7 +331,7 @@ error("Couldn't read directory: %s", fx2txt(status)); do_close(fd_in, fd_out, handle, handle_len); - return(NULL); + return(0); } } else if (type != SSH2_FXP_NAME) fatal("Expected SSH2_FXP_NAME(%d) packet, got %d", From djm at mindrot.org Sat Feb 10 11:32:17 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 10 Feb 2001 11:32:17 +1100 (EST) Subject: sftp-client.c warning clean up. In-Reply-To: Message-ID: On Fri, 9 Feb 2001 mouring at etoh.eviladmin.org wrote: It is in the queue for OpenBSD already. :) Go for it in the meantime. > > > --- ../openssh/sftp-client.c Fri Feb 9 08:44:24 2001 > +++ sftp-client.c Fri Feb 9 19:14:01 2001 > @@ -331,7 +331,7 @@ > error("Couldn't read directory: %s", > fx2txt(status)); > do_close(fd_in, fd_out, handle, handle_len); > - return(NULL); > + return(0); > } > } else if (type != SSH2_FXP_NAME) > fatal("Expected SSH2_FXP_NAME(%d) packet, got %d", > > -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From abartlet at pcug.org.au Sat Feb 10 15:25:42 2001 From: abartlet at pcug.org.au (Andrew Bartlett) Date: Sat, 10 Feb 2001 15:25:42 +1100 Subject: [PATCH] Tell PAM about remote host earlier Message-ID: <3A84C2C6.C7DA7583@pcug.org.au> I was browsing the OpenSSH sources (which are very readable, thankyou very much) and noticed that PAM was only being told what host the user is logging in from for account processing - not for password processing. As I can see no reason not to put this in start_pam this is exactly what I have done - and attached a patch to this effect. This allows PAM to fill in rhost= in its audit messages (pam_unix), and may in fact be used in some module, somewhere. (The patch is against RedHat's patched 2.3.0p1, and looks very slightly odd because the last 2 lines it adds are the the same as the 2 lines before the patch.) -- Andrew Bartlett abartlet at pcug.org.au -------------- next part -------------- --- auth-pam.c.orig Sat Feb 10 13:01:35 2001 +++ auth-pam.c Sat Feb 10 14:14:53 2001 @@ -191,14 +191,6 @@ { int pam_retval; - debug("PAM setting rhost to \"%.200s\"", get_canonical_hostname()); - pam_retval = pam_set_item(pamh, PAM_RHOST, - get_canonical_hostname()); - if (pam_retval != PAM_SUCCESS) { - fatal("PAM set rhost failed[%d]: %.200s", - pam_retval, PAM_STRERROR(pamh, pam_retval)); - } - if (remote_user != NULL) { debug("PAM setting ruser to \"%.200s\"", remote_user); pam_retval = pam_set_item(pamh, PAM_RUSER, remote_user); @@ -310,6 +302,14 @@ if (pam_retval != PAM_SUCCESS) { fatal("PAM initialisation failed[%d]: %.200s", + pam_retval, PAM_STRERROR(pamh, pam_retval)); + } + + debug("PAM setting rhost to \"%.200s\"", get_canonical_hostname()); + pam_retval = pam_set_item(pamh, PAM_RHOST, + get_canonical_hostname()); + if (pam_retval != PAM_SUCCESS) { + fatal("PAM set rhost failed[%d]: %.200s", pam_retval, PAM_STRERROR(pamh, pam_retval)); } From josb at cncdsl.com Sat Feb 10 16:28:58 2001 From: josb at cncdsl.com (Jos Backus) Date: Fri, 9 Feb 2001 21:28:58 -0800 Subject: Handling of failed connect()s when ssh-agent is busy Message-ID: <20010209212858.A22657@lizzy.bugworks.com> We have an application, running under ssh-agent, which fires off a large number of ssh processes, all of which try to talk to the agent through the UNIX domain socket under /tmp. When the agent is slow to respond and the listen queue fills up, connect()s start to fail with ECONNREFUSED, and ssh exits (agent authentication being used exclusively). To some extent this problem can be mitigated by increasing the listen queue in ssh-agent.c, but it only masks the problem: the client should retry a number of times, possibly forever, when the connect() fails temporarily and is likely to succeed in the future. With SSH-1.2.27's ssh this happens in authfd.c, line 372; if the connect() fails (because of ECONNREFUSED), ssh silently gives up trying to talk to the agent: sock = socket(AF_UNIX, SOCK_STREAM, 0); if (sock < 0) { error("Socket failed"); if (newauthsockdir != NULL) { unlink(authsocket); chdir("/"); rmdir(newauthsockdir); xfree(newauthsockdir); } xfree(authsocketdir); return -1; } if (connect(sock, (struct sockaddr *)&sunaddr, AF_UNIX_SIZE(sunaddr)) < 0) { close(sock); if (newauthsockdir != NULL) { unlink(authsocket); chdir("/"); rmdir(newauthsockdir); xfree(newauthsockdir); } xfree(authsocketdir); return -1; } We fixed SSH-1.2.27 by wrapping this part of the code in a while-loop (looping if errno == ECONNREFUSED), and this appears to work well, solving our immediate problem. In OpenSSH, it looks like ssh_get_authentication_socket() in authfd.c could easily be made to act in a similar fashion. It would be great if OpenSSH would handle this situation more gracefully as well. Thanks, -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From craigl at begeek.com Sat Feb 10 17:16:31 2001 From: craigl at begeek.com (Craig Longman) Date: Sat, 10 Feb 2001 01:16:31 -0500 Subject: compiling 2.3 src RPMs Message-ID: <20010210011631.A31977@gamera.begeek.com> i'm have some trouble rebuilding src rpms for 2.3 on a (mostly) redhat 6.2 machine. i have updated a few of the libraries, and am running rpm version 3.0.4-0.48, which is pretty recent i think. the problem is that the openssh rpm doesn't seem to actually produce an rpm file(s). i run it, everything seems to compile ok, it looks like it tries to build the rpms, but then i can find nothing in the /usr/src/redhat/RPMS/i386 directory. it's very strange indeed. there is no usr/bin directory in the tmp dir either. however, the files do look they were actually compiled in the /usr/src/redhat/BUILD/openssh-xxx directory. i have attached the full output from the build in case there is anything useful in there. i'm not really sure what is going on. i see the line to compile then link sshd (for eg) but then the next reference to it is near the end where it says it can't find in in the /tmp/openssh-xxx/usr/bin directory, which is quite accurate. any help would be greatly appreciated. btw, the command i'm using to rebuild is: rpm --rebuild openssh-xxx.src.rpm the build log also shows the actual command. -- CraigL->Thx(); Be Developer ID: 5852 Check out ! -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-build.log.gz Type: application/x-gzip Size: 5859 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010210/32428811/attachment.bin From craigl at begeek.com Sat Feb 10 17:44:01 2001 From: craigl at begeek.com (Craig Longman) Date: Sat, 10 Feb 2001 01:44:01 -0500 Subject: more rpm problems... Message-ID: <20010210014401.A4557@gamera.begeek.com> i know this isn't probably the best place, but i'm getting very desparate to get at least one server up and running with openssh-2.3 here. i have an old redhat-5.2 machine that i was trying to recompile the 2.3 src rpm on, and after fighting for hours to get the various -devel rpms that it required, i have a problem now where the openssh rpm isn't using the older gnome include directories, which seem to have been in /opt/gnome/include in the 1.0.xx days. is there any way to: a) tell the rpm --rebuild to not build the gnome stuff b) pass extra include directories to the rpm --rebuild process c) anything else that can magically get this to work???!!! any help would be very, very much appreciated at this point... -- CraigL->Thx(); Be Developer ID: 5852 Check out ! -------------- 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/20010210/9ffe2a35/attachment.bin From gleblanc at cu-portland.edu Sat Feb 10 19:22:14 2001 From: gleblanc at cu-portland.edu (Gregory Leblanc) Date: 10 Feb 2001 00:22:14 -0800 Subject: compiling 2.3 src RPMs In-Reply-To: <20010210011631.A31977@gamera.begeek.com> Message-ID: <200102100823.f1A8NUe12487@mail2.aracnet.com> On 09 Feb 2001 22:16:31 -0800, Craig Longman wrote: > > i'm have some trouble rebuilding src rpms for 2.3 on a > (mostly) redhat 6.2 machine. i have updated a few of > the libraries, and am running rpm version 3.0.4-0.48, > which is pretty recent i think. > > the problem is that the openssh rpm doesn't seem to actually > produce an rpm file(s). i run it, everything seems to > compile ok, it looks like it tries to build the rpms, but > then i can find nothing in the /usr/src/redhat/RPMS/i386 > directory. it's very strange indeed. there is no usr/bin > directory in the tmp dir either. however, the files do > look they were actually compiled in the > /usr/src/redhat/BUILD/openssh-xxx directory. Here's your problem: Processing files: openssh-server-2.3.0p1-1 File not found: /tmp/openssh-2.3.0p1-buildroot/usr/sbin/sshd File not found: /tmp/openssh-2.3.0p1-buildroot/usr/libexec/openssh/sftp-server File not found by glob: /tmp/openssh-2.3.0p1-buildroot/usr/man/man8/sshd.8* File not found by glob: /tmp/openssh-2.3.0p1-buildroot/usr/man/man8/sftp-server.8* File not found: /tmp/openssh-2.3.0p1-buildroot/usr/etc/ssh/sshd_config If you're not already, I'd strongly recomend that you upgrade to RPM 3.0.5, and see if any of these go away. For some reason, those files aren't showing up where RPM has been told to expect them, and so RPM is not writing an RPM. Greg From gert at greenie.muc.de Sat Feb 10 23:05:59 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 10 Feb 2001 13:05:59 +0100 Subject: SCO 5.0.5 question (username not known) In-Reply-To: ; from svaughan on Thu, Feb 08, 2001 at 02:53:18PM -0800 References: <20010208082551.F12224@alcove.wittsend.com> Message-ID: <20010210130559.B23574@greenie.muc.de> Hi, On Thu, Feb 08, 2001 at 02:53:18PM -0800, svaughan wrote: > I am running OpenSSH_2.2.0p1 on SCO 5.0.5. Everything is > running just fine but I am experiencing a little problem when I go to > change my password remotely. After logging in, if I go to change my > password with the command passwd, I get the following error. > > bash-2.01$ passwd > Setting password for user: (null) This might be a problem with the login user id (luid) on C2 systems. Could you show us the result of "id -l" on a "normal" login and on a SSH login, 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 abartlet at pcug.org.au Sat Feb 10 23:20:59 2001 From: abartlet at pcug.org.au (Andrew Bartlett) Date: Sat, 10 Feb 2001 23:20:59 +1100 Subject: more rpm problems... References: <20010210014401.A4557@gamera.begeek.com> Message-ID: <3A85322B.12341E9A@pcug.org.au> Craig Longman wrote: > > i know this isn't probably the best place, but i'm getting > very desparate to get at least one server up and running with > openssh-2.3 here. i have an old redhat-5.2 machine that i > was trying to recompile the 2.3 src rpm on, and after fighting > for hours to get the various -devel rpms that it required, i > have a problem now where the openssh rpm isn't using the older > gnome include directories, which seem to have been in > /opt/gnome/include in the 1.0.xx days. > > is there any way to: > a) tell the rpm --rebuild to not build the gnome stuff > b) pass extra include directories to the rpm --rebuild process > c) anything else that can magically get this to work???!!! > > any help would be very, very much appreciated at this point... > I usually work with the RedHat RPMS, and just modify the spec file to set the variables provided to skip all the X stuff. To get the spec just install the srpm (rpm -U openssh*.src.rpm and edit the spec file in /usr/src/redhat/SPECS. To rebuild run rpm -ba on the modified spec file. > -- > > CraigL->Thx(); > Be Developer ID: 5852 > Check out ! > > ------------------------------------------------------------------------ > Part 1.2Type: application/pgp-signature -- Andrew Bartlett abartlet at pcug.org.au From pekkas at netcore.fi Sat Feb 10 23:49:55 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 10 Feb 2001 14:49:55 +0200 (EET) Subject: more rpm problems... In-Reply-To: <20010210014401.A4557@gamera.begeek.com> Message-ID: On Sat, 10 Feb 2001, Craig Longman wrote: > is there any way to: > a) tell the rpm --rebuild to not build the gnome stuff The way .spec file is done, this is impossible, because %if's in there override take what's defined in the specfile and don't consider what's given in the command line. In RH pine packages, you can do like: rpm --rebuild pine-*.src.rpm --define 'nokerberos 1' The difference is like: %{!?no_x11_askpass:%setup -q -a 1} vs %if ! %{no_x11_askpass} %setup -q -a 1 %else However, the former construct won't work with e.g. SourceX: files. It's just easier to rpm -Uvh *.src.rpm, edit the .spec file and rpm -ba that. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From tomoyuki at pobox.com Sun Feb 11 02:32:01 2001 From: tomoyuki at pobox.com (Tomoyuki Murakami) Date: Sun, 11 Feb 2001 00:32:01 +0900 (JST) Subject: Protocol 2 remote forwarding patch Message-ID: <20010211.003202.41680942.tomoyuki@pobox.com> Hi all, I'm very new in this list, as looking for codes to plug up the lack of functionality of "Protocol 2 Remote Forwardig". Fortunately, I could find it in MARC's archive. Mr. Jarno Huuskonen posted the codes in Sept, last year, and I tried applying it to my FreeBSD box environment. I couldn't apply an original patch, of course, for incompatibility of virsion. The original is openssh-2.2.0p1 and my is openssh-2.3.0 in FreeBSD souce tree(src/crypto/openssh). I made some fix to it to do with my FreeBSD and confirmed work in a base line. An attachment is a patch for FreeBSD-current(4.2) but, applying to main source-stream(openssh-2.3.0.tgz) is also available. I do not have an OpenBSD environment, and I have not tested in. Thanks, -- Tomo. -------------- next part -------------- diff -ru openssh.orig/auth2.c openssh/auth2.c --- openssh.orig/auth2.c Wed Dec 6 20:11:25 2000 +++ openssh/auth2.c Sat Feb 10 00:06:24 2001 @@ -60,6 +60,7 @@ extern ServerOptions options; extern unsigned char *session_id2; extern int session_id2_len; +extern int user_authenticated_as_root; /* Jarno: from channels.c */ static Authctxt *x_authctxt = NULL; static int one = 1; @@ -282,6 +283,13 @@ /* Log before sending the reply */ userauth_log(authctxt, authenticated, method); userauth_reply(authctxt, authenticated); + + if (authenticated == 1 && + authctxt->pw && authctxt->pw->pw_uid == (uid_t)0) { + user_authenticated_as_root = 1; + } else { + user_authenticated_as_root = 0; + } xfree(service); xfree(user); diff -ru openssh.orig/channels.c openssh/channels.c --- openssh.orig/channels.c Tue Dec 5 20:11:48 2000 +++ openssh/channels.c Sat Feb 10 00:00:54 2001 @@ -73,6 +73,8 @@ */ static Channel *channels = NULL; +int user_authenticated_as_root; /* set to true if user is root. */ + /* * Size of the channel array. All slots of the array must always be * initialized (at least the type field); unused slots are marked with type @@ -608,13 +610,17 @@ "connect from %.200s port %d", c->listening_port, c->path, c->host_port, remote_hostname, remote_port); - newch = channel_new("direct-tcpip", + newch = channel_new((c->type == SSH2_CHANNEL_PORT_LISTENER) ? + "forwarded-tcpip" : "direct-tcpip", SSH_CHANNEL_OPENING, newsock, newsock, -1, c->local_window_max, c->local_maxpacket, 0, xstrdup(buf), 1); if (compat20) { packet_start(SSH2_MSG_CHANNEL_OPEN); - packet_put_cstring("direct-tcpip"); + if (c->type == SSH2_CHANNEL_PORT_LISTENER) + packet_put_cstring("forwarded-tcpip"); + else + packet_put_cstring("direct-tcpip"); packet_put_int(newch); packet_put_int(c->local_window_max); packet_put_int(c->local_maxpacket); @@ -820,10 +826,12 @@ channel_pre[SSH_CHANNEL_OPEN] = &channel_pre_open_20; channel_pre[SSH_CHANNEL_X11_OPEN] = &channel_pre_x11_open; channel_pre[SSH_CHANNEL_PORT_LISTENER] = &channel_pre_listener; + channel_pre[SSH2_CHANNEL_PORT_LISTENER] = &channel_pre_listener; channel_pre[SSH_CHANNEL_X11_LISTENER] = &channel_pre_listener; channel_post[SSH_CHANNEL_OPEN] = &channel_post_open_2; channel_post[SSH_CHANNEL_PORT_LISTENER] = &channel_post_port_listener; + channel_post[SSH2_CHANNEL_PORT_LISTENER] = &channel_post_port_listener; channel_post[SSH_CHANNEL_X11_LISTENER] = &channel_post_x11_listener; } @@ -1309,6 +1317,96 @@ c->remote_window += adjust; } +/* Jarno Huuskonen: This is called when server receives + * SSH2_MSG_GLOBAL_REQUEST. Handles both "tcpip-forward" and + * "cancel-tcpip-forward" requests. + */ +void +channel_server_global_request(int type, int plen, void *ctxt) +{ + char *rtype; + char want_reply; + int success = 0; + + rtype = packet_get_string(NULL); + want_reply = packet_get_char(); + + if ( strcmp(rtype, "tcpip-forward") == 0 ) { + char *address_to_bind; + int port_to_bind; + + address_to_bind = packet_get_string(NULL); + port_to_bind = packet_get_int(); + + /* Check if the client is allowed to forward (this port) */ + if ( port_to_bind < IPPORT_RESERVED && !user_authenticated_as_root ) { + log("User tries to forward privileged port %d", port_to_bind); + packet_send_debug("Requested forwarding of port %d but user is not root.", port_to_bind); + success = 0; + } + else { + /* Start listening on the port */ + channel_request_local_forwarding( port_to_bind, address_to_bind, + port_to_bind, 1, + 1 /* ssh2_remote_fwd*/); + /* NOT REACHED if error (disconnects). + * Note: if error xfree not called + * for address_to_bind + */ + success = 1; + } + + xfree( address_to_bind ); + } + + /* TODO: This is untested !!! create some test code !!!*/ + if ( strcmp(rtype, "cancel-tcpip-forward") == 0 ) { + char *address_to_bind; + int port_to_bind; + int chan; + + address_to_bind = packet_get_string(NULL); + port_to_bind = packet_get_int(); + + /* Lookup the channel listening for this port: + First see if the channel type is SSH2_CHANNEL_PORT_LISTENER and then + compare port/addr. + TODO: Is it safe to use strcmp on address_to_bind ? + */ + for (chan = 0; chan < channels_alloc; chan++) { + if ( channels[chan].type == SSH2_CHANNEL_PORT_LISTENER ) { + if ( channels[chan].listening_port == port_to_bind && + (strcmp(address_to_bind, channels[chan].path) == 0) ) + break; + } + } + + if ( chan < channels_alloc ) { + /* We have a winner --> close the channel*/ + channel_free( channels[chan].self ); + success = 1; + } + else { + debug("Invalid cancel-tcpip-forward request: Couldn't find channel."); + } + xfree( address_to_bind ); + } + + /* Client requested a reply */ + if ( want_reply ) { + if ( success ) { + packet_start(SSH2_MSG_REQUEST_SUCCESS); + } + else { + packet_start(SSH2_MSG_REQUEST_FAILURE); + } + /* Now send the SUCCESS/FAILURE */ + packet_send(); + packet_write_wait(); + } + xfree(rtype); +} + /* * Stops listening for channels, and removes any unix domain sockets that we * might have. @@ -1326,6 +1424,7 @@ channel_free(i); break; case SSH_CHANNEL_PORT_LISTENER: + case SSH2_CHANNEL_PORT_LISTENER: case SSH_CHANNEL_X11_LISTENER: close(channels[i].sock); channel_free(i); @@ -1369,6 +1468,7 @@ case SSH_CHANNEL_FREE: case SSH_CHANNEL_X11_LISTENER: case SSH_CHANNEL_PORT_LISTENER: + case SSH2_CHANNEL_PORT_LISTENER: case SSH_CHANNEL_CLOSED: case SSH_CHANNEL_AUTH_SOCKET: continue; @@ -1414,6 +1514,7 @@ case SSH_CHANNEL_FREE: case SSH_CHANNEL_X11_LISTENER: case SSH_CHANNEL_PORT_LISTENER: + case SSH2_CHANNEL_PORT_LISTENER: case SSH_CHANNEL_CLOSED: case SSH_CHANNEL_AUTH_SOCKET: continue; @@ -1449,7 +1550,8 @@ void channel_request_local_forwarding(u_short port, const char *host, - u_short host_port, int gateway_ports) + u_short host_port, int gateway_ports, + int ssh2_remote_fwd) { int success, ch, sock, on = 1; struct addrinfo hints, *ai, *aitop; @@ -1512,7 +1614,8 @@ } /* Allocate a channel number for the socket. */ ch = channel_new( - "port listener", SSH_CHANNEL_PORT_LISTENER, + "port listener", ssh2_remote_fwd ? + SSH2_CHANNEL_PORT_LISTENER : SSH_CHANNEL_PORT_LISTENER, sock, sock, -1, CHAN_TCP_WINDOW_DEFAULT, CHAN_TCP_PACKET_DEFAULT, 0, xstrdup("port listener"), 1); @@ -1536,15 +1639,12 @@ u_short port_to_connect) { int payload_len; + int type; + int success = 0; /* Record locally that connection to this host/port is permitted. */ if (num_permitted_opens >= SSH_MAX_FORWARDS_PER_DIRECTION) fatal("channel_request_remote_forwarding: too many forwards"); - permitted_opens[num_permitted_opens].host_to_connect = xstrdup(host_to_connect); - permitted_opens[num_permitted_opens].port_to_connect = port_to_connect; - permitted_opens[num_permitted_opens].listen_port = listen_port; - num_permitted_opens++; - /* Send the forward request to the remote side. */ if (compat20) { const char *address_to_bind = "0.0.0.0"; @@ -1553,19 +1653,109 @@ packet_put_char(0); /* boolean: want reply */ packet_put_cstring(address_to_bind); packet_put_int(listen_port); - } else { + packet_send(); + packet_write_wait(); + success = 1; /* assume that server accepts the request and put + the forward request to permitted_opens */ + } else { /* protocol 1 */ packet_start(SSH_CMSG_PORT_FORWARD_REQUEST); packet_put_int(listen_port); packet_put_cstring(host_to_connect); packet_put_int(port_to_connect); packet_send(); packet_write_wait(); - /* - * Wait for response from the remote side. It will send a disconnect - * message on failure, and we will never see it here. + /* Jarno: Server can send SSH_SMSG_FAILURE if it won't do port + * forwardings. Read the server reply. */ - packet_read_expect(&payload_len, SSH_SMSG_SUCCESS); + type = packet_read(&payload_len); + switch (type) { + case SSH_SMSG_SUCCESS: + success = 1; + break; + case SSH_SMSG_FAILURE: + log("Warning: Server doesn't do port forwarding."); + break; + default: + /* Unknown packet */ + packet_disconnect("Protocol error for port forward request: received packet type %d.", type); + } + } + + if ( success ) { + permitted_opens[num_permitted_opens].host_to_connect = xstrdup(host_to_connect); + permitted_opens[num_permitted_opens].port_to_connect = port_to_connect; + permitted_opens[num_permitted_opens].listen_port = listen_port; + num_permitted_opens++; + } +} + +/* Jarno Huuskonen: + * This gets called after ssh client has received + * SSH2_MSG_GLOBAL_REQUEST type "forwarded-tcpip". + * + * returns new channel if OK or NULL for failure. + */ +Channel* +client_forwarded_tcpip_request(const char *request_type, int rchan, + int rwindow, int rmaxpack) +{ + Channel* c = NULL; + int sock; + char *listen_address; /* Remote (server) address that is listening + for the connection */ + int listen_port; + char* originator_address; /* Address of the client connecting to + listen_address */ + int originator_port; /* Client port */ + + unsigned int client_len, connected_len; + + int newch; + int i; + + debug("ssh2 server tries to open forwarded-tcpip channel."); + + /* Get rest of the packet */ + listen_address = packet_get_string(&connected_len); + listen_port = packet_get_int(); + originator_address = packet_get_string(&client_len); + originator_port = packet_get_int(); + packet_done(); + + /* Check if we have requested this remote forwarding + * Note: this is not fool proof, because we don't ask the server to + * acknowledge our remote forward request. + */ + for (i = 0; i= num_permitted_opens ) { + log("Received request to open remote forwarded channel (%d) but the request was denied", rchan); + return NULL; } + + /* TODO: Somekind of access control ?? + * Maybe tcp_wrappers/username/group based access control ?? + */ + + /* Open socket and allocate a channel for it */ + sock = channel_connect_to(permitted_opens[i].host_to_connect, + permitted_opens[i].port_to_connect); + + if ( sock >= 0 ) { + newch = channel_new("forwarded-tcpip", SSH_CHANNEL_OPEN, + sock, sock, -1, 4*1024, 32*1024, 0, + xstrdup(originator_address), 1); + c = channel_lookup( newch ); + } + /* client_input_channel_open calls xfree(request_type) Don't call it here */ + xfree(originator_address); + xfree(listen_address); + return c; } /* @@ -1595,7 +1785,11 @@ /* * Initiate forwarding, */ - channel_request_local_forwarding(port, hostname, host_port, gateway_ports); + /* Jarno: the last parameter is used to signal if this is protocol 2 + * server listening for remote forward --> false + */ + channel_request_local_forwarding(port, hostname, host_port, + gateway_ports, 0); /* Free the argument string. */ xfree(hostname); diff -ru openssh.orig/channels.h openssh/channels.h --- openssh.orig/channels.h Tue Dec 5 20:11:48 2000 +++ openssh/channels.h Sat Feb 10 00:01:29 2001 @@ -49,7 +49,8 @@ #define SSH_CHANNEL_INPUT_DRAINING 8 /* sending remaining data to conn */ #define SSH_CHANNEL_OUTPUT_DRAINING 9 /* sending remaining data to app */ #define SSH_CHANNEL_LARVAL 10 /* larval session */ -#define SSH_CHANNEL_MAX_TYPE 11 +#define SSH2_CHANNEL_PORT_LISTENER 11 +#define SSH_CHANNEL_MAX_TYPE 12 /* * Data structure for channel data. This is iniailized in channel_allocate @@ -149,6 +150,9 @@ void channel_input_window_adjust(int type, int plen, void *ctxt); void channel_input_open(int type, int plen, void *ctxt); +/* Jarno Huuskonen: */ +void channel_server_global_request(int type, int plen, void *ctxt); + /* Sets specific protocol options. */ void channel_set_options(int hostname_in_open); @@ -205,9 +209,12 @@ * channel to host:port from remote side. This never returns if there was an * error. */ +/* Jarno: added ssh2_remote_fwd flag. used when protocol 2 server gets + * tcpip-forward request. + */ void channel_request_local_forwarding(u_short port, const char *host, - u_short remote_port, int gateway_ports); + u_short remote_port, int gateway_ports, int ssh2_remote_fwd); /* * Initiate forwarding of connections to port "port" on remote host through @@ -218,6 +225,12 @@ void channel_request_remote_forwarding(u_short port, const char *host, u_short remote_port); + +/* Jarno Huuskonen: + */ +Channel * +client_forwarded_tcpip_request(const char *request_type, int rchan, + int rwindow, int rmaxpack); /* * Permits opening to any host/port in SSH_MSG_PORT_OPEN. This is usually diff -ru openssh.orig/clientloop.c openssh/clientloop.c --- openssh.orig/clientloop.c Tue Dec 5 20:11:49 2000 +++ openssh/clientloop.c Fri Feb 9 23:14:48 2001 @@ -1036,6 +1036,11 @@ debug("client_input_channel_open: ctype %s rchan %d win %d max %d", ctype, rchan, rwindow, rmaxpack); + /* Jarno: check if ssh2 server tries to open remote forward channel. + */ + if (strcmp(ctype, "forwarded-tcpip") == 0) { + c = client_forwarded_tcpip_request(ctype, rchan, rwindow, rmaxpack); + } if (strcmp(ctype, "x11") == 0 && options.forward_x11) { int sock; char *originator; diff -ru openssh.orig/serverloop.c openssh/serverloop.c --- openssh.orig/serverloop.c Tue Dec 5 20:11:55 2000 +++ openssh/serverloop.c Fri Feb 9 23:20:21 2001 @@ -738,6 +738,8 @@ /* XXX check permission */ if (no_port_forwarding_flag || !options.allow_tcp_forwarding) { + packet_send_debug("Server configuration rejects port forwardings."); + debug("Port forwarding disabled in server configuration."); xfree(target); xfree(originator); return -1; @@ -836,6 +838,7 @@ dispatch_set(SSH2_MSG_CHANNEL_OPEN_FAILURE, &channel_input_open_failure); dispatch_set(SSH2_MSG_CHANNEL_REQUEST, &channel_input_channel_request); dispatch_set(SSH2_MSG_CHANNEL_WINDOW_ADJUST, &channel_input_window_adjust); + dispatch_set(SSH2_MSG_GLOBAL_REQUEST, &channel_server_global_request); } void server_init_dispatch_13() diff -ru openssh.orig/ssh.c openssh/ssh.c --- openssh.orig/ssh.c Tue Dec 5 20:11:58 2000 +++ openssh/ssh.c Fri Feb 9 23:27:08 2001 @@ -851,7 +851,7 @@ channel_request_local_forwarding(options.local_forwards[i].port, options.local_forwards[i].host, options.local_forwards[i].host_port, - options.gateway_ports); + options.gateway_ports, 0); } /* Initiate remote TCP/IP port forwardings. */ @@ -907,7 +907,25 @@ channel_request_local_forwarding(options.local_forwards[i].port, options.local_forwards[i].host, options.local_forwards[i].host_port, - options.gateway_ports); + options.gateway_ports, 0); + } +} + +/* Jarno Huuskonen: ssh2 client calls this to initiate remote port forwarding + * requests. + */ +void +init_remote_fwd(void) +{ + int i; + for (i = 0; i < options.num_remote_forwards; i++) { + debug("Connections to remote port %d forwarded to local address %.200s:%d", + options.remote_forwards[i].port, + options.remote_forwards[i].host, + options.remote_forwards[i].host_port); + channel_request_remote_forwarding(options.remote_forwards[i].port, + options.remote_forwards[i].host, + options.remote_forwards[i].host_port); } } @@ -997,6 +1015,7 @@ /* should be pre-session */ init_local_fwd(); + init_remote_fwd(); /* If requested, let ssh continue in the background. */ if (fork_after_authentication_flag) From pekkas at netcore.fi Sun Feb 11 02:48:09 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 10 Feb 2001 17:48:09 +0200 (EET) Subject: Protocol 2 remote forwarding patch In-Reply-To: <20010211.003202.41680942.tomoyuki@pobox.com> Message-ID: On Sun, 11 Feb 2001, Tomoyuki Murakami wrote: > I'm very new in this list, as looking for codes to plug up the lack of > functionality of "Protocol 2 Remote Forwardig". > Fortunately, I could find it in MARC's archive. Mr. Jarno Huuskonen > posted the codes in Sept, last year, and I tried applying it to my > FreeBSD box environment. > I couldn't apply an original patch, of course, for incompatibility of > virsion. The original is openssh-2.2.0p1 and my is openssh-2.3.0 in > FreeBSD souce tree(src/crypto/openssh). I made some fix to it to do > with my FreeBSD and confirmed work in a base line. > > An attachment is a patch for FreeBSD-current(4.2) but, applying to > main source-stream(openssh-2.3.0.tgz) is also available. > I do not have an OpenBSD environment, and I have not tested in. This has been integrated with OpenSSH for a long time now, just no new official releases have been put out in a couple of months. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From Markus.Friedl at informatik.uni-erlangen.de Sun Feb 11 03:00:47 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 10 Feb 2001 17:00:47 +0100 Subject: Protocol 2 remote forwarding patch In-Reply-To: ; from pekkas@netcore.fi on Sat, Feb 10, 2001 at 05:48:09PM +0200 References: <20010211.003202.41680942.tomoyuki@pobox.com> Message-ID: <20010210170047.A11713@faui02.informatik.uni-erlangen.de> On Sat, Feb 10, 2001 at 05:48:09PM +0200, Pekka Savola wrote: > This has been integrated with OpenSSH for a long time now, just no > new official releases have been put out in a couple of months. there are several reasons for the delay of the next release, but you should expect OpenSSH 2.5 soon (< 1 week). From Markus.Friedl at informatik.uni-erlangen.de Sun Feb 11 03:04:18 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 10 Feb 2001 17:04:18 +0100 Subject: Protocol 2 remote forwarding patch In-Reply-To: <20010211.003202.41680942.tomoyuki@pobox.com>; from tomoyuki@pobox.com on Sun, Feb 11, 2001 at 12:32:01AM +0900 References: <20010211.003202.41680942.tomoyuki@pobox.com> Message-ID: <20010210170418.B11713@faui02.informatik.uni-erlangen.de> On Sun, Feb 11, 2001 at 12:32:01AM +0900, Tomoyuki Murakami wrote: > An attachment is a patch for FreeBSD-current(4.2) but, applying to > main source-stream(openssh-2.3.0.tgz) is also available. > I do not have an OpenBSD environment, and I have not tested in. i'm sorry to have to tell you, but a patch based on the same original diff has been integrated in OpenSSH-current.... From svaughan at asterion.com Sun Feb 11 09:29:50 2001 From: svaughan at asterion.com (svaughan) Date: Sat, 10 Feb 2001 14:29:50 -0800 (PST) Subject: SCO 5.0.5 question (username not known) In-Reply-To: <20010210130559.B23574@greenie.muc.de> Message-ID: Yes that looks to be it. Here is the output for a normal telnet and then an ssh connection. luid is not being set. How can I correct this? from a normal telnet : id -l uid=244(svaughan) gid=102(udt) luid=244(svaughan) groups=102(udt) from an ssh : id -l uid=244(svaughan) gid=102(udt) luid=-1(not set) groups=102(udt) Thanks for you help! Sam -- Sam Vaughan Senior Systems Administrator On Sat, 10 Feb 2001, Gert Doering wrote: > Hi, > > On Thu, Feb 08, 2001 at 02:53:18PM -0800, svaughan wrote: > > I am running OpenSSH_2.2.0p1 on SCO 5.0.5. Everything is > > running just fine but I am experiencing a little problem when I go to > > change my password remotely. After logging in, if I go to change my > > password with the command passwd, I get the following error. > > > > bash-2.01$ passwd > > Setting password for user: (null) > > This might be a problem with the login user id (luid) on C2 systems. > > Could you show us the result of "id -l" on a "normal" login and on a SSH > login, 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 Feb 11 10:37:45 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 11 Feb 2001 00:37:45 +0100 Subject: SCO 5.0.5 question (username not known) In-Reply-To: ; from svaughan on Sat, Feb 10, 2001 at 02:29:50PM -0800 References: <20010210130559.B23574@greenie.muc.de> Message-ID: <20010211003745.B5723@greenie.muc.de> Hi, On Sat, Feb 10, 2001 at 02:29:50PM -0800, svaughan wrote: > Yes that looks to be it. Here is the output for a normal telnet and then > an ssh connection. luid is not being set. How can I correct this? > > > from a normal telnet : > id -l > uid=244(svaughan) gid=102(udt) luid=244(svaughan) groups=102(udt) > > from an ssh : > id -l > uid=244(svaughan) gid=102(udt) luid=-1(not set) groups=102(udt) Yep. C2 security striking again... To Svaughan: I know where it comes from, but can't fix it in the code (no time to really dig into uid/gid handling right now). But maybe I can explain it to the OpenSSH people so that the fix is obvious to one of them :-) To the OpenSSH team: SCO (and maybe others) has a so-called "login uid". It's something that can only be set *once*, usually by login (or telnetd or whatever), and will then be passed on to all children, even to suid children. There is no way a process can change its LUID. "Init" runs with luid "unset" (which is a distinctive state, shown as "-1", and is also inherited by all children). The first process doing authentication should then set the luid. The system call required is "setluid(uid_t)", and should be done at the place in sshd where the user ID is set, all root privileges are revoked, and the user shell is "to be called". Caveat: if sshd is run from the command line, like "make ; make install; sshd", setluid() will fail - but there's nothing we can do, except recommend to run sshd only from /etc/inittab (":once:" settings). I have appended the setluid man page below (from SCO 3.0). The sentence about "unless the LUID is set, setuid/setgid will fail" is not true here, which seems to be related to "relaxed security settings" being in place. gert ---- setluid(S) 6 January 1993 setluid(S) Name setluid - set login user ID Syntax cc . . . -lprot #include #include #include #include int setluid (uid) unsigned short uid; Description The setluid routine is used to set the login user ID of the calling pro- cess. The login user ID, or LUID, should be set at login time. Only the super user can set the LUID. Once set, the LUID cannot be reset, even by the super user. Until the LUID is set, the setuid(S) and setgid(S) routines fail. This ensures that the LUID is set before any identity changes in the other (effective and real) user IDs. The setluid routine is invoked by the login(C) program just prior to the identity changes caused by setuid(S) and setgid(S) calls. It is also used by at(C) and crontab(C) job entries before starting a non- interactive session for a user. The LUID is an accurate representation of the user who logged into the system and cannot be altered during the session. The LUID is needed because both the effective and real user IDs can be altered by use of setuid(S) or the setuid bits on an executable file, and consequently, at times during a session, do not accurately reflect the login user. The LUID is inherited by all children of the process. If the LUID was not set before a fork(S), the child would also contain an unset LUID. Return value Upon successful completion, the setluid routine returns a value of 0. Otherwise, a value of -1 is returned and errno is set to indicate the appropriate error. Diagnostics If one of the following conditions occurs, the setluid routine fails and errno is set to the corresponding value: [EINVAL] user ID is out of range. [EPERM] The LUID has already been set for this process or some ancestor of this process. See also getluid(S), getuid(S), setuid(S), setgid(S), stat(S) Standards conformance The setluid routine is an extension of AT&T System V provided by the Santa Cruz Operation. -- 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 Darren.Moffat at eng.sun.com Sun Feb 11 10:58:48 2001 From: Darren.Moffat at eng.sun.com (Darren J Moffat) Date: Sat, 10 Feb 2001 15:58:48 -0800 Subject: SCO 5.0.5 question (username not known) References: <20010210130559.B23574@greenie.muc.de> <20010211003745.B5723@greenie.muc.de> Message-ID: <3A85D5B8.54DB1AD9@Eng.Sun.COM> Gert Doering wrote: > To the OpenSSH team: SCO (and maybe others) has a so-called "login uid". Solaris has this concept as well execpt is is called the audit uid and the corresponding call is setauid() -- Darren J Moffat From valverde at gemini.jpl.nasa.gov Sun Feb 11 21:29:55 2001 From: valverde at gemini.jpl.nasa.gov (Michael Valverde) Date: Sun, 11 Feb 2001 02:29:55 -0800 (PST) Subject: compile with tcp-wrappers and AFS Message-ID: <200102111029.CAA12123@gemini.jpl.nasa.gov> To the openssh team: When I try to compile openssh-2.3.0p1 with both tcp-wrappers and AFS, I get compile errors. I can compile with just AFS or just tcp-wrappers, but not both. Is there a fix to this? The error I get is during the configure stage. I get the error, Can't find libwrap, but it is there. Could you please help me out. Thanks. Mike From djm at mindrot.org Sun Feb 11 22:35:40 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 11 Feb 2001 22:35:40 +1100 (EST) Subject: [PATCH] Tell PAM about remote host earlier In-Reply-To: <3A84C2C6.C7DA7583@pcug.org.au> Message-ID: On Sat, 10 Feb 2001, Andrew Bartlett wrote: > I was browsing the OpenSSH sources (which are very readable, > thankyou very much) and noticed that PAM was only being told what > host the user is logging in from for account processing - not for > password processing. As I can see no reason not to put this in > start_pam this is exactly what I have done - and attached a patch to > this effect. > > This allows PAM to fill in rhost= in its audit messages (pam_unix), > and may in fact be used in some module, somewhere. Applied - thanks. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sun Feb 11 22:38:27 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 11 Feb 2001 22:38:27 +1100 (EST) Subject: compiling 2.3 src RPMs In-Reply-To: <20010210011631.A31977@gamera.begeek.com> Message-ID: On Sat, 10 Feb 2001, Craig Longman wrote: > > i'm have some trouble rebuilding src rpms for 2.3 on a > (mostly) redhat 6.2 machine. i have updated a few of > the libraries, and am running rpm version 3.0.4-0.48, > which is pretty recent i think. Here is you problem: + %{makeinstall} sysconfdir=/tmp/openssh-2.3.0p1-buildroot/usr/etc/ssh libexecdir=/tmp/openssh-2.3.0p1-buildroot/usr/libexec/openssh DESTDIR=/ fg: no job control Upgrade to rpm-3.0.5-9.6x -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sun Feb 11 22:42:52 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 11 Feb 2001 22:42:52 +1100 (EST) Subject: more rpm problems... In-Reply-To: Message-ID: On Sat, 10 Feb 2001, Pekka Savola wrote: > On Sat, 10 Feb 2001, Craig Longman wrote: > > is there any way to: > > a) tell the rpm --rebuild to not build the gnome stuff > > The way .spec file is done, this is impossible, because %if's in there > override take what's defined in the specfile and don't consider what's > given in the command line. > > In RH pine packages, you can do like: > > rpm --rebuild pine-*.src.rpm --define 'nokerberos 1' > > > The difference is like: > > %{!?no_x11_askpass:%setup -q -a 1} Could you do something like: %{!?no_x11_askpass:%define skip_x11_askpass 1} %if ! %{skip_x11_askpass} i.e can you nest defines inside the conditionals like that? ? -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From mats at mindbright.se Sun Feb 11 21:57:51 2001 From: mats at mindbright.se (Mats Andersson) Date: Sun, 11 Feb 2001 11:57:51 +0100 (MET) Subject: sftp client In-Reply-To: <20010209180207.C14279@faui02.informatik.uni-erlangen.de> Message-ID: Hi, On Fri, 9 Feb 2001, Markus Friedl wrote: > > On Fri, Feb 09, 2001 at 09:02:06AM -0800, Devon Bleak wrote: i > > personally would like to see the requirement of a valid shell dropped. > > give them a shell that does chroot and exec of sftp-server Though I can understand the implementation pros and cons of having a user shell exec the subsystem in general, and the sftp-server in particular. It is IMHO bad that the discussion of running the subsystem in a shell or not have to be dealt with in the first place. If an implementation chooses to run subsystems from a shell, fine, it should take care of all kinds of problems that might occur too and/or cope with lusers "breaking" the protocol running on top of it (it is unfortunate that the drafts says that subsystems are normally run in a shell, it seems to implicate that subsystems are in fact just yet another way to do rsh with ssh). There is three kinds of session channels, "shell", "exec", and "subsystem". If one would want a shell for this kind of stuff one would choose "exec" (i.e. the rsh equivalent, e.g. for running scp). As it is now, there is not much benefit in having the sftp protocol run as a subsystem. It might aswell run as an "exec" session (the only benefit is of course that the client doesn't have to know the name of the sftp-server program but that seems quite minor...). One benefit of having it run as a subsystem might for example be that the subsystem itself knows something about what users can and can't do independantly of the shell which happens to be in effect. This is of course just a subtle config/implementation issue as to how to handle user configuration, though it seems nice to be as flexible as possible with the given choices for how to do things (i.e. in this case how one can utilize the "shell", "exec", "subsystem" sessions of ssh2). Cheers, /Mats From Markus.Friedl at informatik.uni-erlangen.de Sun Feb 11 23:21:32 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sun, 11 Feb 2001 13:21:32 +0100 Subject: sftp client In-Reply-To: ; from mats@mindbright.se on Sun, Feb 11, 2001 at 11:57:51AM +0100 References: <20010209180207.C14279@faui02.informatik.uni-erlangen.de> Message-ID: <20010211132132.B27585@faui02.informatik.uni-erlangen.de> As i see the drafts "subsystem" is the same as "exec" plus one additional level of indirection. Moreover, since having .bashrc print out things breaks many things in Unix, it's not really sshd's job to add code that fixes broken installations. On Sun, Feb 11, 2001 at 11:57:51AM +0100, Mats Andersson wrote: > There is three kinds of session channels, "shell", "exec", and > "subsystem". If one would want a shell for this kind of stuff one would > choose "exec" (i.e. the rsh equivalent, e.g. for running scp). As it is > now, there is not much benefit in having the sftp protocol run as a > subsystem. It might aswell run as an "exec" session (the only benefit is > of course that the client doesn't have to know the name of the sftp-server > program but that seems quite minor...). this is a big issue with scp, see all the questions about "why does scp fail". > One benefit of having it run as a > subsystem might for example be that the subsystem itself knows something > about what users can and can't do independantly of the shell which happens > to be in effect. This is of course just a subtle config/implementation > issue as to how to handle user configuration, though it seems nice to be > as flexible as possible with the given choices for how to do things (i.e. > in this case how one can utilize the "shell", "exec", "subsystem" sessions > of ssh2). yes, this would be nice to have. -m From pekkas at netcore.fi Mon Feb 12 01:41:39 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 11 Feb 2001 16:41:39 +0200 (EET) Subject: more rpm problems... In-Reply-To: Message-ID: On Sun, 11 Feb 2001, Damien Miller wrote: > On Sat, 10 Feb 2001, Pekka Savola wrote: > > > On Sat, 10 Feb 2001, Craig Longman wrote: > > > is there any way to: > > > a) tell the rpm --rebuild to not build the gnome stuff > > > > The way .spec file is done, this is impossible, because %if's in there > > override take what's defined in the specfile and don't consider what's > > given in the command line. > > > > In RH pine packages, you can do like: > > > > rpm --rebuild pine-*.src.rpm --define 'nokerberos 1' > > > > > > The difference is like: > > > > %{!?no_x11_askpass:%setup -q -a 1} > > Could you do something like: > > %{!?no_x11_askpass:%define skip_x11_askpass 1} > > %if ! %{skip_x11_askpass} > > i.e can you nest defines inside the conditionals like that? Yes. With e.g. the following: --- redhat.orig/openssh.spec Fri Feb 9 16:56:41 2001 +++ redhat/openssh.spec Sun Feb 11 16:35:51 2001 @@ -10,6 +10,10 @@ # Do we want to disable building of gnome-askpass? (1=yes 0=no) %define no_gnome_askpass 0 +# Reserve options to override askpass settings with rpm -ba|--rebuild --define +%{?skip_x11_askpass:%define no_x11_askpass 1} +%{?skip_gnome_askpass:%define no_gnome_askpass 1} + Summary: OpenSSH free Secure Shell (SSH) implementation Name: openssh Version: %{oversion} ----8<--- you can do 'rpm --rebuild openssh*.src.rpm --define 'skip_gnome_askpass 1'. Ie. %defines put in .spec file can't be overridden by --define, and %if requires you use %define in .spec file. Also, it'd be probably good idea to add rpm >= 3.0.5 Requires and/or BuildRequires so people don't wonder why their non-updated RHL6x can't cope with --rebuild. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From craigl at begeek.com Mon Feb 12 03:26:15 2001 From: craigl at begeek.com (Craig Longman) Date: Sun, 11 Feb 2001 11:26:15 -0500 Subject: more rpm problems... In-Reply-To: ; from pekkas@netcore.fi on Sun, Feb 11, 2001 at 04:41:39PM +0200 References: Message-ID: <20010211112615.A17308@gamera.begeek.com> much thanks to Gregory, Andrew, Pekka & Damien for their various suggestions which eventually got me ablt to build on both the old redhat-5.2 and the redhat-6.2 machines. upgrading to rpm-3.0.5 was critical in both cases, it solved the problem on the 6.2 machine easily. the suggestion to manually edit the spec file got me in the right direction to eventually figure out what i was being told to do, find and edit the spec file, then rebuild only the packages i needed. much thanks to the author of the spec file for putting the options to not compile the graphical versions of askpass. On Sun, Feb 11, 2001 at 04:41:39PM +0200, Pekka Savola wrote: > Also, it'd be probably good idea to add rpm >= 3.0.5 Requires > and/or BuildRequires so people don't wonder why their non-updated > RHL6x can't cope with --rebuild. it sure would. i was very confused about the problems i had; the fact that the /tmp/openssh/bin dir wasn't being created, as well as very confused when on another machine without 3.0.5, i got a very strange error telling me i need openssl >= 0.9.5, when i had 0.9.5a installed. but, upgrading to rpm-3.0.5 fixed that also. -- CraigL->Thx(); Be Developer ID: 5852 Check out ! -------------- 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/20010211/34eadea0/attachment.bin From mouring at etoh.eviladmin.org Mon Feb 12 07:42:13 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 11 Feb 2001 14:42:13 -0600 (CST) Subject: sshd.c and saved_argc. In-Reply-To: <200102091922.f19JMvR339628@jurassic.eng.sun.com> Message-ID: Can anyone give me a reason not to apply this patch? I can't find any reason for saved_argc. - Ben --- openssh/sshd.c Sat Feb 10 16:18:11 2001 +++ ossh/sshd.c Sun Feb 11 14:36:08 2001 @@ -123,7 +123,6 @@ /* Saved arguments to main(). */ char **saved_argv; -int saved_argc; /* * The sockets that the server is listening; this is used in the SIGHUP @@ -568,7 +567,6 @@ init_rng(); /* Save argv. */ - saved_argc = ac; saved_argv = av; /* Initialize configuration options to their default values. */ From stevesk at sweden.hp.com Mon Feb 12 06:56:57 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Sun, 11 Feb 2001 20:56:57 +0100 (MET) Subject: sshd.c and saved_argc. In-Reply-To: Message-ID: that's used by HAVE_OSF_SIA code (which i know nothing about). On Sun, 11 Feb 2001 mouring at etoh.eviladmin.org wrote: : Can anyone give me a reason not to apply this patch? I can't find any : reason for saved_argc. : : - Ben : : --- openssh/sshd.c Sat Feb 10 16:18:11 2001 : +++ ossh/sshd.c Sun Feb 11 14:36:08 2001 : @@ -123,7 +123,6 @@ : : /* Saved arguments to main(). */ : char **saved_argv; : -int saved_argc; : : /* : * The sockets that the server is listening; this is used in the SIGHUP : @@ -568,7 +567,6 @@ : init_rng(); : : /* Save argv. */ : - saved_argc = ac; : saved_argv = av; : : /* Initialize configuration options to their default values. */ From abartlet at pcug.org.au Mon Feb 12 08:52:29 2001 From: abartlet at pcug.org.au (Andrew Bartlett) Date: Mon, 12 Feb 2001 08:52:29 +1100 Subject: [PATCH] Tell PAM about remote host earlier References: Message-ID: <3A87099D.82663BCD@pcug.org.au> Damien Miller wrote: > > On Sat, 10 Feb 2001, Andrew Bartlett wrote: > > > I was browsing the OpenSSH sources (which are very readable, > > thankyou very much) and noticed that PAM was only being told what > > host the user is logging in from for account processing - not for > > password processing. As I can see no reason not to put this in > > start_pam this is exactly what I have done - and attached a patch to > > this effect. > > > > This allows PAM to fill in rhost= in its audit messages (pam_unix), > > and may in fact be used in some module, somewhere. > > Applied - thanks. > > -d > I also noticed that OpenSSH 'closes' the session for users who don't authenticate themselves successfully, creating misleading entries in the logs (session closed for user abartlet) when abartlet never opened a session. This patch corrects the situation. Hope its useful, Andrew Bartlett > -- > | Damien Miller \ ``E-mail attachments are the poor man's > | http://www.mindrot.org / distributed filesystem'' - Dan Geer -- Andrew Bartlett abartlet at pcug.org.au -------------- next part -------------- --- auth-pam.c.orig Sat Feb 10 13:01:35 2001 +++ auth-pam.c Sun Feb 11 23:40:59 2001 @@ -55,6 +55,10 @@ /* remember whether pam_acct_mgmt() returned PAM_NEWAUTHTOK_REQD */ static int password_change_required = 0; +/* remember if we actualy set up a session, so we don't close + as session we never opened */ +static int session_opened = 0; + /* * PAM conversation function. * There are two states this can run in. @@ -137,12 +141,13 @@ if (pamh != NULL) { + if (session_opened) { pam_retval = pam_close_session(pamh, 0); if (pam_retval != PAM_SUCCESS) { log("Cannot close PAM session[%d]: %.200s", pam_retval, PAM_STRERROR(pamh, pam_retval)); } - + } pam_retval = pam_setcred(pamh, PAM_DELETE_CRED); if (pam_retval != PAM_SUCCESS) { debug("Cannot delete credentials[%d]: %.200s", @@ -246,6 +243,7 @@ fatal("PAM session setup failed[%d]: %.200s", pam_retval, PAM_STRERROR(pamh, pam_retval)); } + session_opened = 1; } /* Set PAM credentials */ From djm at mindrot.org Mon Feb 12 09:40:11 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 12 Feb 2001 09:40:11 +1100 (EST) Subject: more rpm problems... In-Reply-To: Message-ID: On Sun, 11 Feb 2001, Pekka Savola wrote: > +# Reserve options to override askpass settings with rpm -ba|--rebuild --define > +%{?skip_x11_askpass:%define no_x11_askpass 1} > +%{?skip_gnome_askpass:%define no_gnome_askpass 1} > + > Summary: OpenSSH free Secure Shell (SSH) implementation > Name: openssh > Version: %{oversion} > ----8<--- > Also, it'd be probably good idea to add rpm >= 3.0.5 Requires and/or > BuildRequires so people don't wonder why their non-updated RHL6x can't > cope with --rebuild. Thanks - both of these are in. The Redhat spec file now can do rpm -ba openssh.spec --define "skip_x11_askpass 1" --define "skip_gnome_askpass 1" --define "rh7 1" The rh7 define uses the newer pam_stack stuff in /etc/pam.d/sshd -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From vinschen at redhat.com Mon Feb 12 09:56:42 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 11 Feb 2001 23:56:42 +0100 Subject: Protocol 2 remote forwarding patch In-Reply-To: <20010210170047.A11713@faui02.informatik.uni-erlangen.de>; from Markus.Friedl@informatik.uni-erlangen.de on Sat, Feb 10, 2001 at 05:00:47PM +0100 References: <20010211.003202.41680942.tomoyuki@pobox.com> <20010210170047.A11713@faui02.informatik.uni-erlangen.de> Message-ID: <20010211235642.B2107@cygbert.vinschen.de> On Sat, Feb 10, 2001 at 05:00:47PM +0100, Markus Friedl wrote: > On Sat, Feb 10, 2001 at 05:48:09PM +0200, Pekka Savola wrote: > > This has been integrated with OpenSSH for a long time now, just no > > new official releases have been put out in a couple of months. > > there are several reasons for the delay of the next release, but you > should expect OpenSSH 2.5 soon (< 1 week). Just being curious. What's the reason for skipping 2.4? Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From thewizarddon at yahoo.com Mon Feb 12 14:45:09 2001 From: thewizarddon at yahoo.com (Don Bragg) Date: Sun, 11 Feb 2001 22:45:09 -0500 Subject: Compiled and running on NCR SVR4 UNIX (MP-RAS) Message-ID: <3A875C45.82F86B8A@yahoo.com> To whomever is interested, I have compiled and am running OpenSSH under NCR UNIX using the following procedure: 1. Compile and install zlib to the default location. gunzip zlib*.gz tar -xvfo zlib*tar cd zlib-* ./configure make make install 2. Compile and install openssl to the default location. gunzip openssl*.gz tar -xvfo openssl*tar cd openssl-* ./Configure -I/usr/include -lc89 ncr-scde make make test make install 3. Modify, compile, and install openssh as below: a. gunzip openssh*.gz b. tar -xvfo openssh*.tar c. cd openssh* d. Make the following changes to the "configure" file for OpenSSH: Search for the final occurence of "sysv". Change the "LIBS" field to the following: LIBS="$LIBS -lc89 -lnsl -lgen -lsocket" e. Add the following line to OpenSSH's includes.h file: #include "limits.h" (following the config.h include line). f. Run the configure command as below: sh ./configure --host=i686-ncr-sysv g. Compile OpenSSH with the following command: make h. Install the compiled module, as below: make install i. Edit the /etc/services file to include the following line: ssh 22/tcp # Secure Shell daemon j. Edit the /etc/inet/inetd.conf file to include the following line: ssh stream tcp nowait root /usr/local/sbin/sshd sshd -i Add the same line to /etc/inet/inetd.local so it will be included if tcpconfig is re-run at a later date. k. Determine the process of the inetd master network process with the following command : ps -eaf | grep inetd | grep -v grep l. Force inetd.conf to re-read it's config files by the following command: kill -HUP 9999 ( where 9999 is inetd's process ID) 4. Test the installation by logging in with a SSH client. You will need to create an environment file for each user in ~/.ssh/environment to use "scp". It should resemble the following: PATH=$PATH:/usr/local/bin Hope it helps. Don Bragg Systems Manager SBS Data Services From mib at unimelb.edu.au Mon Feb 12 16:14:39 2001 From: mib at unimelb.edu.au (Mike Battersby) Date: Mon, 12 Feb 2001 16:14:39 +1100 Subject: OSF_SIA bug in 2.3.0p1 Message-ID: <200102120514.f1C5Eex16051@ariel.ucs.unimelb.edu.au> Is anyone maintaining the OSF_SIA support in openssh? This seems to be an obvious bug triggered if you try to connect as a non-existant user. >From auth1.c line 459 #elif defined(HAVE_OSF_SIA) (sia_validate_user(NULL, saved_argc, saved_argv, get_canonical_hostname(), pw->pw_name, NULL, 0, NULL, "") == SIASUCCESS)) { #else /* !HAVE_OSF_SIA && !USE_PAM */ At this stage pw could be NULL so obviously pw->pw_name isn't a valid thing to do. Should this just be 'user'? I'm not even 100% sure of the validity of passing NULL as collect function (acceptable in 4.0g manpage, not mentioned in 4.0d manpage). - Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 979 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010212/9e65098d/attachment.bin From djm at mindrot.org Mon Feb 12 16:46:13 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 12 Feb 2001 16:46:13 +1100 (EST) Subject: OSF_SIA bug in 2.3.0p1 In-Reply-To: <200102120514.f1C5Eex16051@ariel.ucs.unimelb.edu.au> Message-ID: On Mon, 12 Feb 2001, Mike Battersby wrote: > > Is anyone maintaining the OSF_SIA support in openssh? This seems to be an > obvious bug triggered if you try to connect as a non-existant user. > > >From auth1.c line 459 > > #elif defined(HAVE_OSF_SIA) > (sia_validate_user(NULL, saved_argc, saved_argv, > get_canonical_hostname(), pw->pw_name, NULL, 0, > NULL, "") == SIASUCCESS)) { > #else /* !HAVE_OSF_SIA && !USE_PAM */ > > At this stage pw could be NULL so obviously pw->pw_name isn't a valid > thing to do. Should this just be 'user'? I'm not even 100% sure of the > validity of passing NULL as collect function (acceptable in 4.0g manpage, > not mentioned in 4.0d manpage). Not having a DEC box, I can't comment on the usage of the sia_ functions, but this may make the above more correct. Index: auth1.c =================================================================== RCS file: /var/cvs/openssh/auth1.c,v retrieving revision 1.29 diff -u -r1.29 auth1.c --- auth1.c 2001/02/10 21:27:11 1.29 +++ auth1.c 2001/02/12 05:44:44 @@ -267,9 +267,9 @@ /* Do SIA auth with password */ if (sia_validate_user(NULL, saved_argc, saved_argv, get_canonical_hostname(options.reverse_mapping_check), - pw->pw_name, NULL, 0, NULL, password) == SIASUCCESS) { + authctxt->user, NULL, 0, NULL, + password) == SIASUCCESS) authenticated = 1; - } #else /* !USE_PAM && !HAVE_OSF_SIA */ /* Try authentication with the password. */ authenticated = auth_password(pw, password); -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From jmknoble at jmknoble.cx Mon Feb 12 16:59:34 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Mon, 12 Feb 2001 00:59:34 -0500 Subject: SCO 5.0.5 question (username not known) In-Reply-To: <20010211003745.B5723@greenie.muc.de>; from gert@greenie.muc.de on Sun, Feb 11, 2001 at 12:37:45AM +0100 References: <20010210130559.B23574@greenie.muc.de> <20010211003745.B5723@greenie.muc.de> Message-ID: <20010212005934.A1415@quipu.half.pint-stowp.cx> Circa 2001-Feb-11 00:37:45 +0100 dixit Gert Doering: : The system call required is "setluid(uid_t)", and should be done at the : place in sshd where the user ID is set, all root privileges are revoked, : and the user shell is "to be called". Caveat: if sshd is run from the : command line, like "make ; make install; sshd", setluid() will fail - but : there's nothing we can do, except recommend to run sshd only from : /etc/inittab (":once:" settings). Actually, what sshd probably wants to do is something like the following: #ifdef HAVE_SETLUID if (-1 == getluid()) { setluid(my_uid); } #else #ifdef HAVE_SETAUID /* Similar stuff for Solaris or other systems with setauid(). */ #endif #endif -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From djm at mindrot.org Mon Feb 12 17:25:52 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 12 Feb 2001 17:25:52 +1100 (EST) Subject: SCO 5.0.5 question (username not known) In-Reply-To: <20010212005934.A1415@quipu.half.pint-stowp.cx> Message-ID: On Mon, 12 Feb 2001, Jim Knoble wrote: > Circa 2001-Feb-11 00:37:45 +0100 dixit Gert Doering: > > : The system call required is "setluid(uid_t)", and should be done at the > : place in sshd where the user ID is set, all root privileges are revoked, > : and the user shell is "to be called". Caveat: if sshd is run from the > : command line, like "make ; make install; sshd", setluid() will fail - but > : there's nothing we can do, except recommend to run sshd only from > : /etc/inittab (":once:" settings). > > Actually, what sshd probably wants to do is something like the following: > > #ifdef HAVE_SETLUID > if (-1 == getluid()) { > setluid(my_uid); > } > #else > #ifdef HAVE_SETAUID > /* Similar stuff for Solaris or other systems with setauid(). */ > #endif > #endif Would it be possible for someone with access to one of these systems to turn the above into a patch and test it? You want to start in the do_child() function in session.c. Be careful, there is a lot of OS-dependant stuff in that function. If noone steps up, then I can create a patch, but I don't have ready access to a C2 system and would thus be flying blind. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From svaughan at asterion.com Mon Feb 12 17:34:30 2001 From: svaughan at asterion.com (svaughan) Date: Sun, 11 Feb 2001 22:34:30 -0800 (PST) Subject: SCO 5.0.5 question (username not known) In-Reply-To: Message-ID: Damien, I would be glad too. I should have some free time this week. thanks Sam On Mon, 12 Feb 2001, Damien Miller wrote: > On Mon, 12 Feb 2001, Jim Knoble wrote: > > > Circa 2001-Feb-11 00:37:45 +0100 dixit Gert Doering: > > > > : The system call required is "setluid(uid_t)", and should be done at the > > : place in sshd where the user ID is set, all root privileges are revoked, > > : and the user shell is "to be called". Caveat: if sshd is run from the > > : command line, like "make ; make install; sshd", setluid() will fail - but > > : there's nothing we can do, except recommend to run sshd only from > > : /etc/inittab (":once:" settings). > > > > Actually, what sshd probably wants to do is something like the following: > > > > #ifdef HAVE_SETLUID > > if (-1 == getluid()) { > > setluid(my_uid); > > } > > #else > > #ifdef HAVE_SETAUID > > /* Similar stuff for Solaris or other systems with setauid(). */ > > #endif > > #endif > > Would it be possible for someone with access to one of these systems to > turn the above into a patch and test it? > > You want to start in the do_child() function in session.c. Be careful, > there is a lot of OS-dependant stuff in that function. > > If noone steps up, then I can create a patch, but I don't have ready > access to a C2 system and would thus be flying blind. > > -d > > > -- > | Damien Miller \ ``E-mail attachments are the poor man's > | http://www.mindrot.org / distributed filesystem'' - Dan Geer > From maf at appgate.com Mon Feb 12 18:15:41 2001 From: maf at appgate.com (Martin Forssen) Date: Mon, 12 Feb 2001 08:15:41 +0100 (MET) Subject: sftp client In-Reply-To: <20010211132132.B27585@faui02.informatik.uni-erlangen.de> Message-ID: <20010212071524.172AF317AF@pelee.firedoor.se> On 11 Feb, Markus Friedl wrote: > Moreover, since having .bashrc print out things breaks > many things in Unix, it's not really sshd's job to > add code that fixes broken installations. Unfortunately I think we would save people a lot of grief if this was handled by sshd. So the pragmatic solution would be for sshd to handle it. I would probably solve the problem by adding a small helper program (ssh_subsystem_executer:-) whose only task in life is to print a small cookie and then to exec the real subsystem (after modifying argv and argc suitably). The sshd just executes this helper using the users shell and give sutiable arguments for the subsystem, then it discards everything up to and including the cookie. This should solve the problem without the need to add magic things to the protocols and without subsystem modification. This does not solve the problems for those users which starts things in the background which later output things, but for those users I reccommend castration:-) /MaF From mouring at etoh.eviladmin.org Mon Feb 12 19:22:41 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 12 Feb 2001 02:22:41 -0600 (CST) Subject: Compiled and running on NCR SVR4 UNIX (MP-RAS) In-Reply-To: <3A875C45.82F86B8A@yahoo.com> Message-ID: On Sun, 11 Feb 2001, Don Bragg wrote: > To whomever is interested, I have compiled and am running OpenSSH under > NCR UNIX using the following procedure: > > 1. Compile and install zlib to the default location. > gunzip zlib*.gz > tar -xvfo zlib*tar > cd zlib-* > ./configure > make > make install > > 2. Compile and install openssl to the default location. > gunzip openssl*.gz > tar -xvfo openssl*tar > cd openssl-* > ./Configure -I/usr/include -lc89 ncr-scde > make > make test > make install > > 3. Modify, compile, and install openssh as below: > > a. gunzip openssh*.gz > b. tar -xvfo openssh*.tar > c. cd openssh* > d. Make the following changes to the "configure" file for OpenSSH: > > Search for the final occurence of "sysv". Change the "LIBS" > field > to the following: > > LIBS="$LIBS -lc89 -lnsl -lgen -lsocket" > I think it would be better to add in a *-ncr-sysv* section. I'm unsure what else uses the generic 'sysv'. (Which I'll commit right now along with the change to includes.h) Can you compile without defining the 'host=' line? Does the configure system guess your system? If so is it different then *-ncr-sysv*? [..] > j. Edit the /etc/inet/inetd.conf file to include the following line: > > ssh stream tcp nowait root /usr/local/sbin/sshd > sshd -i > *PLEASE* don't encourage people to run sshd from inetd. =) - Ben From gert at greenie.muc.de Mon Feb 12 19:08:12 2001 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 12 Feb 2001 09:08:12 +0100 Subject: SCO 5.0.5 question (username not known) In-Reply-To: <20010212005934.A1415@quipu.half.pint-stowp.cx>; from Jim Knoble on Mon, Feb 12, 2001 at 12:59:34AM -0500 References: <20010210130559.B23574@greenie.muc.de> <20010211003745.B5723@greenie.muc.de> <20010212005934.A1415@quipu.half.pint-stowp.cx> Message-ID: <20010212090812.A10105@greenie.muc.de> Hi, On Mon, Feb 12, 2001 at 12:59:34AM -0500, Jim Knoble wrote: > Actually, what sshd probably wants to do is something like the following: > > #ifdef HAVE_SETLUID > if (-1 == getluid()) { > setluid(my_uid); > } > #else Yes. Or just doing "setluid(my_uid)" and ignoring errors :-) 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 Feb 12 20:37:00 2001 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 12 Feb 2001 10:37:00 +0100 Subject: Handling of failed connect()s when ssh-agent is busy In-Reply-To: <20010209212858.A22657@lizzy.bugworks.com>; from Jos Backus on Fri, Feb 09, 2001 at 09:28:58PM -0800 References: <20010209212858.A22657@lizzy.bugworks.com> Message-ID: <20010212103700.G10859@greenie.muc.de> Hi, On Fri, Feb 09, 2001 at 09:28:58PM -0800, Jos Backus wrote: [..] > We fixed SSH-1.2.27 by wrapping this part of the code in a while-loop (looping > if errno == ECONNREFUSED), and this appears to work well, solving our > immediate problem. Hmmm. What happens if the agent is not running at all, but the socket exists (leftover, for example, after the agent has died for whatever reason)? For me this sounds like your change would create an infinite loop - no good. 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 Tue Feb 13 01:56:23 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Mon, 12 Feb 2001 15:56:23 +0100 (MET) Subject: add scp path to _PATH_STDPATH Message-ID: what do you think about this patch to add the path to scp to _PATH_STDPATH? is there a better or cleaner way to do this? i'm hoping to ward off 'scp doesn't work' questions for the next release. i did *not* add this to a --with-default-path path, because if a user specifies that, they should control its value completely. Index: Makefile.in =================================================================== RCS file: /var/cvs/openssh/Makefile.in,v retrieving revision 1.150 diff -u -r1.150 Makefile.in --- Makefile.in 2001/02/09 13:40:03 1.150 +++ Makefile.in 2001/02/12 14:47:51 @@ -17,11 +17,13 @@ SSH_PROGRAM=@bindir@/ssh ASKPASS_PROGRAM=$(libexecdir)/ssh-askpass SFTP_SERVER=$(libexecdir)/sftp-server +PATH_SCP=$(bindir) PATHS= -DETCDIR=\"$(sysconfdir)\" \ -D_PATH_SSH_PROGRAM=\"$(SSH_PROGRAM)\" \ -D_PATH_SSH_ASKPASS_DEFAULT=\"$(ASKPASS_PROGRAM)\" \ - -D_PATH_SFTP_SERVER=\"$(SFTP_SERVER)\" + -D_PATH_SFTP_SERVER=\"$(SFTP_SERVER)\" \ + -D_PATH_SCP=\"$(PATH_SCP)\" CC=@CC@ LD=@LD@ Index: defines.h =================================================================== RCS file: /var/cvs/openssh/defines.h,v retrieving revision 1.54 diff -u -r1.54 defines.h --- defines.h 2001/02/09 11:55:17 1.54 +++ defines.h 2001/02/12 14:47:53 @@ -267,7 +267,7 @@ #endif #ifndef _PATH_STDPATH -# define _PATH_STDPATH "/usr/bin:/bin:/usr/sbin:/sbin" +# define _PATH_STDPATH "/usr/bin:/bin:/usr/sbin:/sbin" ":" _PATH_SCP #endif #ifndef _PATH_DEVNULL From Lutz.Jaenicke at aet.TU-Cottbus.DE Tue Feb 13 02:15:11 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Mon, 12 Feb 2001 16:15:11 +0100 Subject: OpenSSH (CVS) performance observations Message-ID: <20010212161511.A16182@serv01.aet.tu-cottbus.de> Hi! I have experimented a bit with the latest OpenSSH from the CVS archive. I could realize some connections succesfully, but I experienced performance problem during the connection phase. It seems, that the client needs quite some computer time just after debug: Got SSH2_MSG_KEX_DH_GEX_GROUP. By inserting test-printouts, I verifyed that the dh_gen_key(dh); call seems to take that long. On a HP C180 it takes around 8 seconds. OpenSSH is built without optimization but as far as I could see, the time is spent in the OpenSSL library (built with maximum optimization). There are other places in which 3-4 seconds are spent each. Can somebody verify these observations? Setup is the default setting. 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 Markus.Friedl at informatik.uni-erlangen.de Tue Feb 13 02:20:54 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 12 Feb 2001 16:20:54 +0100 Subject: OpenSSH (CVS) performance observations In-Reply-To: <20010212161511.A16182@serv01.aet.tu-cottbus.de>; from Lutz.Jaenicke@aet.TU-Cottbus.DE on Mon, Feb 12, 2001 at 04:15:11PM +0100 References: <20010212161511.A16182@serv01.aet.tu-cottbus.de> Message-ID: <20010212162054.C14899@faui02.informatik.uni-erlangen.de> yes, i can verify that SSH2_MSG_KEX_DH_GEX_GROUP is slow, but it should spend all the time in openssl (or waiting for the peer). On Mon, Feb 12, 2001 at 04:15:11PM +0100, Lutz Jaenicke wrote: > Hi! > > I have experimented a bit with the latest OpenSSH from the CVS archive. > I could realize some connections succesfully, but I experienced performance > problem during the connection phase. > It seems, that the client needs quite some computer time just after > debug: Got SSH2_MSG_KEX_DH_GEX_GROUP. > By inserting test-printouts, I verifyed that the dh_gen_key(dh); call > seems to take that long. On a HP C180 it takes around 8 seconds. > OpenSSH is built without optimization but as far as I could see, the > time is spent in the OpenSSL library (built with maximum optimization). > There are other places in which 3-4 seconds are spent each. > > Can somebody verify these observations? > Setup is the default setting. > > Best regards, > Lutz > -- > Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE > BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ > Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 > Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 > From mouring at etoh.eviladmin.org Tue Feb 13 03:23:38 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 12 Feb 2001 10:23:38 -0600 (CST) Subject: openssh bugs in snapshot for nextstep (fwd) Message-ID: I was sent this from Mark Miller. Should we be using MAXPATHLEN instead of PATH_MAX in the upstream tree? Not all systems define PATH_MAX. - Ben --- sftp-int.c.orig Sat Feb 10 13:56:08 2001 +++ sftp-int.c Sun Feb 11 23:33:26 2001 @@ -435,5 +435,5 @@ unsigned long n_arg; Attrib a, *aa; - char path_buf[PATH_MAX]; + char path_buf[MAXPATHLEN]; path1 = path2 = NULL; -- _/ mark miller _/ markm at swoon.net _/ _/ NeXTmail OK From cmadams at hiwaay.net Tue Feb 13 04:22:24 2001 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 12 Feb 2001 11:22:24 -0600 Subject: OSF_SIA bug in 2.3.0p1 In-Reply-To: <200102120514.f1C5Eex16051@ariel.ucs.unimelb.edu.au>; from mib@unimelb.edu.au on Mon, Feb 12, 2001 at 04:14:39PM +1100 References: <200102120514.f1C5Eex16051@ariel.ucs.unimelb.edu.au> Message-ID: <20010212112224.F7301@HiWAAY.net> Once upon a time, Mike Battersby said: > Is anyone maintaining the OSF_SIA support in openssh? This seems to be an > obvious bug triggered if you try to connect as a non-existant user. Well, I wrote the current code, and yeah, I missed that. > >From auth1.c line 459 > > #elif defined(HAVE_OSF_SIA) > (sia_validate_user(NULL, saved_argc, saved_argv, > get_canonical_hostname(), pw->pw_name, NULL, 0, > NULL, "") == SIASUCCESS)) { > #else /* !HAVE_OSF_SIA && !USE_PAM */ > > At this stage pw could be NULL so obviously pw->pw_name isn't a valid > thing to do. Should this just be 'user'? I'm not even 100% sure of the > validity of passing NULL as collect function (acceptable in 4.0g manpage, > not mentioned in 4.0d manpage). The 4.0F manpage says collect can be NULL, but I've read in other places it is a bad idea, and found out why. Someone already did a "quick fix" to CVS on the first problem. Here is a patch against CVS that fixes the collect problem as well as some other things (like not really blocking locked and expired accounts and not returning the correct messages to the user). This patch pulls the SIA stuff out into a separate file that provides two functions: one to check the username/password and one to setup a session. There may still be a problem with information going back to the user. Someone reported to me that on Tru64 5.1, the last login times are printed when connecting to an account that is locked. It doesn't happen under 4.0F, so I haven't been able to track down what is happening (don't have 5.x installed here yet - CDs are still on the bookshelf). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. diff -urN openssh_cvs/Makefile.in openssh/Makefile.in --- openssh_cvs/Makefile.in Fri Feb 9 07:40:03 2001 +++ openssh/Makefile.in Mon Feb 12 11:19:30 2001 @@ -48,7 +48,7 @@ SSHOBJS= ssh.o sshconnect.o sshconnect1.o sshconnect2.o log-client.o readconf.o clientloop.o -SSHDOBJS= sshd.o auth.o auth1.o auth2.o auth-chall.o auth2-chall.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth2-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o dh.o pty.o log-server.o login.o loginrec.o servconf.o serverloop.o md5crypt.o session.o groupaccess.o +SSHDOBJS= sshd.o auth.o auth1.o auth2.o auth-chall.o auth2-chall.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth2-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o auth-sia.o dh.o pty.o log-server.o login.o loginrec.o servconf.o serverloop.o md5crypt.o session.o groupaccess.o TROFFMAN = scp.1 ssh-add.1 ssh-agent.1 ssh-keygen.1 ssh-keyscan.1 ssh.1 sshd.8 sftp-server.8 sftp.1 CATMAN = scp.0 ssh-add.0 ssh-agent.0 ssh-keygen.0 ssh-keyscan.0 ssh.0 sshd.0 sftp-server.0 sftp.0 diff -urN openssh_cvs/auth-sia.c openssh/auth-sia.c --- openssh_cvs/auth-sia.c Wed Dec 31 18:00:00 1969 +++ openssh/auth-sia.c Mon Feb 12 11:20:03 2001 @@ -0,0 +1,106 @@ +#include "includes.h" + +#ifdef HAVE_OSF_SIA +#include "ssh.h" +#include "auth-sia.h" +#include "log.h" +#include "servconf.h" +#include "canohost.h" + +#include +#include +#include +#include +#include +#include +#include +#include + +extern ServerOptions options; +extern int saved_argc; +extern char **saved_argv; + +extern int errno; + +int +auth_sia_password (user, pass) + char *user; + char *pass; +{ + int ret; + SIAENTITY *ent = NULL; + const char *host + = get_canonical_hostname (options.reverse_mapping_check); + + if (! user || ! pass) + return 0; + + if (sia_ses_init (&ent, saved_argc, saved_argv, host, user, NULL, 0, + NULL) != SIASUCCESS) + return 0; + + if ((ret = sia_ses_authent (NULL, pass, ent)) != SIASUCCESS) { + error ("couldn't authenticate %s from %s", user, host); + if (ret & SIASTOP) + sia_ses_release (&ent); + return 0; + } + + sia_ses_release (&ent); + + return 1; +} + +int +session_setup_sia (user, tty) + char *user; + char *tty; +{ + int ret; + struct passwd *pw; + SIAENTITY *ent = NULL; + const char *host + = get_canonical_hostname (options.reverse_mapping_check); + + if (sia_ses_init (&ent, saved_argc, saved_argv, host, user, tty, 0, + NULL) != SIASUCCESS) + return 0; + + if ((pw = getpwnam (user)) == NULL) { + error ("getpwnam(%s) failed", user); + sia_ses_release (&ent); + return 0; + } + if (sia_make_entity_pwd (pw, ent) != SIASUCCESS) { + sia_ses_release (&ent); + return 0; + } + + ent->authtype = SIA_A_NONE; + if (sia_ses_estab (sia_collect_trm, ent) != SIASUCCESS) { + error ("couldn't establish session for %s from %s", user, + host); + return 0; + } + + if (setpriority (PRIO_PROCESS, 0, 0) == -1) { + error ("setpriority failed: %s", strerror (errno)); + sia_ses_release (&ent); + return 0; + } + + if (sia_ses_launch (sia_collect_trm, ent) != SIASUCCESS) { + error ("couldn't launch session for %s from %s", user, host); + return 0; + } + sia_ses_release (&ent); + + if (setreuid(geteuid(), geteuid()) < 0) { + error ("setreuid failed: %s", strerror (errno)); + return 0; + } + + return 1; +} + +#endif /* HAVE_OSF_SIA */ diff -urN openssh_cvs/auth-sia.h openssh/auth-sia.h --- openssh_cvs/auth-sia.h Wed Dec 31 18:00:00 1969 +++ openssh/auth-sia.h Mon Feb 12 11:19:30 2001 @@ -0,0 +1,8 @@ +#include "includes.h" + +#ifdef HAVE_OSF_SIA + +int auth_sia_password(char *user, char *pass); +int session_setup_sia(char *user, char *tty); + +#endif /* HAVE_OSF_SIA */ diff -urN openssh_cvs/auth1.c openssh/auth1.c --- openssh_cvs/auth1.c Mon Feb 12 01:02:24 2001 +++ openssh/auth1.c Mon Feb 12 11:19:30 2001 @@ -12,11 +12,6 @@ #include "includes.h" RCSID("$OpenBSD: auth1.c,v 1.15 2001/02/07 22:35:45 markus Exp $"); -#ifdef HAVE_OSF_SIA -# include -# include -#endif - #include "xmalloc.h" #include "rsa.h" #include "ssh1.h" @@ -36,10 +31,6 @@ #ifdef WITH_AIXAUTHENTICATE extern char *aixloginmsg; #endif /* WITH_AIXAUTHENTICATE */ -#ifdef HAVE_OSF_SIA -extern int saved_argc; -extern char **saved_argv; -#endif /* HAVE_OSF_SIA */ /* * convert ssh auth msg type into description @@ -98,6 +89,8 @@ #endif #ifdef USE_PAM auth_pam_password(pw, password)) { +#elif defined(HAVE_OSF_SIA) + 0) { #else auth_password(pw, "")) { #endif @@ -265,11 +258,7 @@ authenticated = auth_pam_password(pw, password); #elif defined(HAVE_OSF_SIA) /* Do SIA auth with password */ - if (sia_validate_user(NULL, saved_argc, saved_argv, - get_canonical_hostname(options.reverse_mapping_check), - authctxt->user?authctxt->user:"NOUSER", NULL, - 0, NULL, password) == SIASUCCESS) - authenticated = 1; + authenticated = auth_sia_password(authctxt->user, password); #else /* !USE_PAM && !HAVE_OSF_SIA */ /* Try authentication with the password. */ authenticated = auth_password(pw, password); diff -urN openssh_cvs/auth2.c openssh/auth2.c --- openssh_cvs/auth2.c Sat Feb 10 15:31:53 2001 +++ openssh/auth2.c Mon Feb 12 11:19:30 2001 @@ -25,11 +25,6 @@ #include "includes.h" RCSID("$OpenBSD: auth2.c,v 1.40 2001/02/10 12:52:02 markus Exp $"); -#ifdef HAVE_OSF_SIA -# include -# include -#endif - #include #include "ssh2.h" @@ -61,10 +56,6 @@ #ifdef WITH_AIXAUTHENTICATE extern char *aixloginmsg; #endif -#ifdef HAVE_OSF_SIA -extern int saved_argc; -extern char **saved_argv; -#endif static Authctxt *x_authctxt = NULL; static int one = 1; @@ -346,10 +337,7 @@ #ifdef USE_PAM return auth_pam_password(authctxt->pw, ""); #elif defined(HAVE_OSF_SIA) - return (sia_validate_user(NULL, saved_argc, saved_argv, - get_canonical_hostname(options.reverse_mapping_check), - authctxt->user?authctxt->user:"NOUSER", NULL, 0, - NULL, "") == SIASUCCESS); + return 0; #else /* !HAVE_OSF_SIA && !USE_PAM */ return auth_password(authctxt->pw, ""); #endif /* USE_PAM */ @@ -374,10 +362,7 @@ #ifdef USE_PAM auth_pam_password(authctxt->pw, password) == 1) #elif defined(HAVE_OSF_SIA) - sia_validate_user(NULL, saved_argc, saved_argv, - get_canonical_hostname(options.reverse_mapping_check), - authctxt->user?authctxt->user:"NOUSER", NULL, 0, NULL, - password) == SIASUCCESS) + auth_sia_password(authctxt->user, password) == 1) #else /* !USE_PAM && !HAVE_OSF_SIA */ auth_password(authctxt->pw, password) == 1) #endif /* USE_PAM */ diff -urN openssh_cvs/session.c openssh/session.c --- openssh_cvs/session.c Mon Feb 12 11:06:02 2001 +++ openssh/session.c Mon Feb 12 11:19:30 2001 @@ -72,11 +72,6 @@ #include #endif -#ifdef HAVE_OSF_SIA -# include -# include -#endif - #ifdef HAVE_CYGWIN #include #include @@ -1060,21 +1055,9 @@ switch, so we let login(1) to this for us. */ if (!options.use_login) { #ifdef HAVE_OSF_SIA - extern char **saved_argv; - extern int saved_argc; - char *host = get_canonical_hostname(options.reverse_mapping_check); - - if (sia_become_user(NULL, saved_argc, saved_argv, host, - pw->pw_name, ttyname, 0, NULL, NULL, SIA_BEU_SETLUID) != - SIASUCCESS) { - perror("sia_become_user"); - exit(1); - } - if (setreuid(geteuid(), geteuid()) < 0) { - perror("setreuid"); - exit(1); - } #else /* HAVE_OSF_SIA */ + if (session_setup_sia(pw->pw_name, ttyname) != 1) + exit(1); #ifdef HAVE_CYGWIN if (is_winnt) { #else From tim at multitalents.net Tue Feb 13 04:53:41 2001 From: tim at multitalents.net (Tim Rice) Date: Mon, 12 Feb 2001 09:53:41 -0800 (PST) Subject: Compiled and running on NCR SVR4 UNIX (MP-RAS) In-Reply-To: Message-ID: On Mon, 12 Feb 2001 mouring at etoh.eviladmin.org wrote: > On Sun, 11 Feb 2001, Don Bragg wrote: > > > To whomever is interested, I have compiled and am running OpenSSH under > > NCR UNIX using the following procedure: [snip] > > 3. Modify, compile, and install openssh as below: > > > > a. gunzip openssh*.gz > > b. tar -xvfo openssh*.tar > > c. cd openssh* > > d. Make the following changes to the "configure" file for OpenSSH: > > > > Search for the final occurence of "sysv". Change the "LIBS" > > field > > to the following: > > > > LIBS="$LIBS -lc89 -lnsl -lgen -lsocket" What version of openssh is this? There has been a lot of changes in the snapshots to autodetect libraries. I'm working on a patch right not to clean this up even further as some platforms that compile will fail if you configure with --with-tcp-wrappers > > > > I think it would be better to add in a *-ncr-sysv* section. I'm unsure > what else uses the generic 'sysv'. (Which I'll commit right now along > with the change to includes.h) > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From pekkas at netcore.fi Tue Feb 13 05:12:52 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 12 Feb 2001 20:12:52 +0200 (EET) Subject: more rpm problems... In-Reply-To: Message-ID: On Mon, 12 Feb 2001, Damien Miller wrote: > On Sun, 11 Feb 2001, Pekka Savola wrote: > > > > +# Reserve options to override askpass settings with rpm -ba|--rebuild --define > > +%{?skip_x11_askpass:%define no_x11_askpass 1} > > +%{?skip_gnome_askpass:%define no_gnome_askpass 1} > > + > > Summary: OpenSSH free Secure Shell (SSH) implementation > > Name: openssh > > Version: %{oversion} > > ----8<--- > > Also, it'd be probably good idea to add rpm >= 3.0.5 Requires and/or > > BuildRequires so people don't wonder why their non-updated RHL6x can't > > cope with --rebuild. > > Thanks - both of these are in. The Redhat spec file now can do > > rpm -ba openssh.spec --define "skip_x11_askpass 1" > --define "skip_gnome_askpass 1" > --define "rh7 1" > > The rh7 define uses the newer pam_stack stuff in /etc/pam.d/sshd Actually, that system-auth thing is also in RH62 pam errata -- 0.72 is enough for it. Works fine here on RHL62, at least. So it could be enabled by default too, but then Requires: pam >= 0.72 or Requires: /etc/pam.d/system-auth would be needed to clear up potential confusion. These mods are good for centralized access control (identical with telnet, console etc.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From josb at cncdsl.com Tue Feb 13 05:19:55 2001 From: josb at cncdsl.com (Jos Backus) Date: Mon, 12 Feb 2001 10:19:55 -0800 Subject: Handling of failed connect()s when ssh-agent is busy In-Reply-To: <20010212103700.G10859@greenie.muc.de>; from gert@greenie.muc.de on Mon, Feb 12, 2001 at 10:36:38AM +0100 References: <20010209212858.A22657@lizzy.bugworks.com> <20010212103700.G10859@greenie.muc.de> Message-ID: <20010212101955.B85623@lizzy.bugworks.com> Hallo Gert, On Mon, Feb 12, 2001 at 10:36:38AM +0100, Gert Doering wrote: > On Fri, Feb 09, 2001 at 09:28:58PM -0800, Jos Backus wrote: > [..] > > We fixed SSH-1.2.27 by wrapping this part of the code in a while-loop (looping > > if errno == ECONNREFUSED), and this appears to work well, solving our > > immediate problem. > > Hmmm. What happens if the agent is not running at all, but the socket > exists (leftover, for example, after the agent has died for whatever > reason)? I thought about that too. Isn't there a way to distinguish between these cases? We clearly only want to retry when we have reason to believe that the agent is indeed still listening. > For me this sounds like your change would create an infinite loop - no good. Agreed. Thanks, -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From gert at greenie.muc.de Tue Feb 13 05:27:41 2001 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 12 Feb 2001 19:27:41 +0100 Subject: Handling of failed connect()s when ssh-agent is busy In-Reply-To: <20010212101955.B85623@lizzy.bugworks.com>; from Jos Backus on Mon, Feb 12, 2001 at 10:19:55AM -0800 References: <20010209212858.A22657@lizzy.bugworks.com> <20010212103700.G10859@greenie.muc.de> <20010212101955.B85623@lizzy.bugworks.com> Message-ID: <20010212192741.D21697@greenie.muc.de> Hi, On Mon, Feb 12, 2001 at 10:19:55AM -0800, Jos Backus wrote: > > [..] > > > We fixed SSH-1.2.27 by wrapping this part of the code in a while-loop (looping > > > if errno == ECONNREFUSED), and this appears to work well, solving our > > > immediate problem. > > > > Hmmm. What happens if the agent is not running at all, but the socket > > exists (leftover, for example, after the agent has died for whatever > > reason)? > > I thought about that too. Isn't there a way to distinguish between these > cases? We clearly only want to retry when we have reason to believe that the > agent is indeed still listening. To my knowledge, no - if the socket exists, but nothing is there, ECONNREFUSED *is* the error message to be returned... What I'd do is to try, say, 10 times, with a random delay in between, something like "10-20 ms" or so - to give the agent time to recover if too many ssh clients are beating onto it. If it didn't work in 10 times, give up. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From ishikawa at yk.rim.or.jp Tue Feb 13 05:52:31 2001 From: ishikawa at yk.rim.or.jp (Ishikawa) Date: Tue, 13 Feb 2001 03:52:31 +0900 Subject: log-server.c patch: adding tag to every log output. Message-ID: <3A8830EF.7BC54BDE@yk.rim.or.jp> The attached modification to log-server.c add a "tag" to all the syslog output. The tag is a composite of the internal verbose level names used in sshd and the external syslogd names. The form of the tag is as follows. ssh_internal_name(syslog_priority) This might be instructive for a learning sysadmin trying to setup syslog for sshd logging. (I have posted earlier about the mimsatch of the symbolic names used in sshd_config to control verbosity, and the symbolic priority names used in syslog.conf. This confused me quite a lot during syslogd setup. Documented at : http://www.yk.rim.or.jp/~ishikawa/ssh-log-dir/ssh-log-patch.html In a nutshell, the confusion may stem from the usage of syslog-priority names for both the verbosity control and trying to use it for syslog(). Anyway, the current state seems to be much better than the original ssh where the control was very primitive. I wish it can now become much easier to configure for the sysadmin to set up syslogd properly. It may not be easy to change the symblic names used in sshd_config now that openssh seems to be used by very many users. So I haven't touch the code in this post to modify the names used for sshd_config. RCS file: RCS/log-server.c,v retrieving revision 1.1 diff -c -r1.1 log-server.c *** log-server.c 2001/01/15 09:07:44 1.1 --- log-server.c 2001/01/25 05:56:57 *************** *** 122,127 **** --- 122,140 ---- #define MSGBUFSIZ 1024 + /* CI: verbose tag to show the difference between the internal + priority level and the syslog priority. + + */ + #if 0 + #define TAGSTR(orig,pri) orig + #else + /* Verbose: + * ssh_internal_name(priority) + */ + #define TAGSTR(orig,pri) orig "(" pri ")" + #endif + void do_log(LogLevel level, const cAr *fmt, va_list args) { *************** *** 133,169 **** if (level > log_level) return; switch (level) { - case SYSLOG_LEVEL_ERROR: - txt = "error"; - pri = LOG_ERR; - break; case SYSLOG_LEVEL_FATAL: ! txt = "fatal"; pri = LOG_ERR; break; case SYSLOG_LEVEL_INFO: case SYSLOG_LEVEL_VERBOSE: pri = LOG_INFO; break; case SYSLOG_LEVEL_DEBUG1: ! txt = "debug1"; pri = LOG_DEBUG; break; ! case SYSLOG_LEVEL_DEBUG2: ! txt = "debug2"; pri = LOG_DEBUG; break; case SYSLOG_LEVEL_DEBUG3: ! txt = "debug3"; pri = LOG_DEBUG; break; default: ! txt = "internal error"; pri = LOG_ERR; break; } if (txt != NULL) { ! snprintf(fmtbuf, sizeof(fmtbuf), "%s: %s", txt, fmt); vsnprintf(msgbuf, sizeof(msgbuf), fmtbuf, args); } else { vsnprintf(msgbuf, sizeof(msgbuf), fmt, args); --- 146,187 ---- if (level > log_level) return; switch (level) { case SYSLOG_LEVEL_FATAL: ! /* CI: ssh_internal_name(priority) */ ! txt = TAGSTR("fatal", "CRIT"); /* CI */ ! pri = LOG_CRIT; ! break; ! case SYSLOG_LEVEL_ERROR: ! txt = TAGSTR("error", "ERR"); /* CI */ pri = LOG_ERR; break; case SYSLOG_LEVEL_INFO: + txt = TAGSTR("info", "NOTICE"); /* CI */ + pri = LOG_NOTICE; + break; case SYSLOG_LEVEL_VERBOSE: + txt = TAGSTR("verbose", "INFO"); /* CI */ pri = LOG_INFO; break; case SYSLOG_LEVEL_DEBUG1: ! txt = TAGSTR("debug1", "DEBUG"); /* CI */ pri = LOG_DEBUG; break; ! case SYSLOG_LEVEL_DEBUG2: ! txt = TAGSTR("debug2", "DEBUG"); /* CI */ pri = LOG_DEBUG; break; case SYSLOG_LEVEL_DEBUG3: ! txt = TAGSTR("debug3", "DEBUG"); /* CI */ pri = LOG_DEBUG; break; default: ! txt = TAGSTR("internal error", "ERR"); /* CI */ pri = LOG_ERR; break; } if (txt != NULL) { ! snprintf(fmtbuf, sizeof(fmtbuf), "%.16s: %s", txt, fmt); vsnprintf(msgbuf, sizeof(msgbuf), fmtbuf, args); } else { vsnprintf(msgbuf, sizeof(msgbuf), fmt, args); =================================================================== The above would generate the following sshd log lines. Feb 11 23:06:23 A sshd[1225]: info(NOTICE): Generating new 768 bit RSA key. Feb 11 23:06:23 A sshd[1225]: info(NOTICE): Generating new 768 bit RSA key. Feb 11 23:06:26 A sshd[1225]: info(NOTICE): RSA key generation complete. Feb 11 23:06:26 A sshd[1225]: info(NOTICE): RSA key generation complete. Feb 11 23:13:21 A sshd[17947]: verbose(INFO): Connection from 192.168.1.10 port 43027 Feb 11 23:13:31 A sshd[17947]: info(NOTICE): Accepted password for gnu from 192.168.1.10 port 43027 Feb 11 23:13:31 A sshd[17947]: info(NOTICE): Accepted password for gnu from 192.168.1.10 port 43027 Feb 11 23:20:02 A sshd[17947]: verbose(INFO): Connection closed by remote host. Feb 11 23:21:56 A sshd[18336]: verbose(INFO): Connection from 192.168.1.10 port 43045 Feb 11 23:21:59 A sshd[18336]: info(NOTICE): Accepted password for gnu from 192.168.1.10 port 43045 Feb 11 23:21:59 A sshd[18336]: info(NOTICE): Accepted password for gnu from 192.168.1.10 port 43045 Feb 11 23:32:45 A sshd[18336]: verbose(INFO): Connection closed by remote host. Feb 11 23:35:45 A sshd[18571]: verbose(INFO): Connection from 192.168.1.10 port 43057 Feb 11 23:35:49 A sshd[18571]: info(NOTICE): Accepted password for gnu from 192.168.1.10 port 43057 Feb 11 23:35:49 A sshd[18571]: info(NOTICE): Accepted password for gnu from 192.168.1.10 port 43057 Feb 11 23:38:43 A sshd[18571]: verbose(INFO): Connection closed by remote host. From stevesk at sweden.hp.com Tue Feb 13 06:03:15 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Mon, 12 Feb 2001 20:03:15 +0100 (MET) Subject: pam protocol 1 fix Message-ID: is this ok? symptom is: debug1: Starting up PAM with username "stevesk" debug1: Trying to reverse map address 127.0.0.1. debug1: PAM setting rhost to "localhost" debug1: Attempting authentication for stevesk. debug1: PAM Password authentication for "stevesk" failed[9]: Authentication failed Failed rsa for stevesk from 127.0.0.1 port 49568 Index: auth1.c =================================================================== RCS file: /var/cvs/openssh/auth1.c,v retrieving revision 1.30 diff -u -r1.30 auth1.c --- auth1.c 2001/02/12 07:02:24 1.30 +++ auth1.c 2001/02/12 18:58:22 @@ -97,7 +97,7 @@ (!options.kerberos_authentication || options.kerberos_or_local_passwd) && #endif #ifdef USE_PAM - auth_pam_password(pw, password)) { + auth_pam_password(pw, "")) { #else auth_password(pw, "")) { #endif From tom at avatar.itc.nrcs.usda.gov Tue Feb 13 07:04:55 2001 From: tom at avatar.itc.nrcs.usda.gov (tom at avatar.itc.nrcs.usda.gov) Date: Mon, 12 Feb 2001 13:04:55 -0700 (MST) Subject: patches for UnixWare v2.x pty (misc.c,configure.in) Message-ID: <1941_15779_982008293_7@avatar> I have attached two patches to the current source code. The first addresses the pty problems with UnixWare 2.x with connecting with SSH2. It sets the sigaction to SA_RESTART. This fixes UnixWare v2.x, but haven't heard any feedback as to effects on other OS'. The first patch is against misc.c. The second patch adds a section "*-*-sysv4.2uw2*" to configure to set the TEST_MINUS_S_SH shell and define USE_PIPES. I suspect these same fixes apply to UnixWare 7.x, but I don't have access to that build platform, or I would include them in the config as well. Let me know whether these can be applied against the current source tree. Thank you, -Tom Rudnick ----------------/---------------------------------------------- Tom Rudnick | USDA Natural Resources Conservation Service Fort Collins,CO | tom at avatar.itc.nrcs.usda.gov (970) 295-5427 ** The 3rd Millennium started Jan 1, 2001. see: ** ** http://aa.usno.navy.mil/AA/faq/docs/millennium.html ** -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -------------- next part -------------- --- misc.c.1.6 Mon Feb 12 11:11:15 2001 +++ misc.c Sun Feb 11 22:33:22 2001 @@ -107,7 +107,7 @@ if (osa.sa_handler != act) { memset(&sa, 0, sizeof sa); sigemptyset(&sa.sa_mask); - sa.sa_flags = 0; + sa.sa_flags = SA_RESTART; sa.sa_handler = act; if (sigaction(sig, &sa, 0) == -1) return (mysig_t) -1; -------------- next part -------------- --- configure.in.1.235 Mon Feb 12 11:09:14 2001 +++ configure.in Mon Feb 12 09:13:34 2001 @@ -196,6 +196,15 @@ mansubdir=cat LIBS="$LIBS -lgen -lnsl -lucb" ;; +*-*-sysv4.2uw2*) + CPPFLAGS="$CPPFLAGS -I/usr/local/include" + LDFLAGS="$LDFLAGS -L/usr/local/lib" + MANTYPE='$(CATMAN)' + AC_DEFINE(USE_PIPES) + TEST_MINUS_S_SHELL="/usr/bin/ksh" + mansubdir=cat + enable_suid_ssh=no + ;; *-*-sysv4.2*) CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib" From josb at cncdsl.com Tue Feb 13 07:13:42 2001 From: josb at cncdsl.com (Jos Backus) Date: Mon, 12 Feb 2001 12:13:42 -0800 Subject: Handling of failed connect()s when ssh-agent is busy In-Reply-To: <20010212192741.D21697@greenie.muc.de>; from gert@greenie.muc.de on Mon, Feb 12, 2001 at 07:27:19PM +0100 References: <20010209212858.A22657@lizzy.bugworks.com> <20010212103700.G10859@greenie.muc.de> <20010212101955.B85623@lizzy.bugworks.com> <20010212192741.D21697@greenie.muc.de> Message-ID: <20010212121342.A87877@lizzy.bugworks.com> On Mon, Feb 12, 2001 at 07:27:19PM +0100, Gert Doering wrote: > To my knowledge, no - if the socket exists, but nothing is there, > ECONNREFUSED *is* the error message to be returned... Bummer. Sounds like a protocol deficiency to me, not being able to distinguish between these two situations. > What I'd do is to try, say, 10 times, with a random delay in between, > something like "10-20 ms" or so - to give the agent time to recover if too > many ssh clients are beating onto it. If it didn't work in 10 times, give > up. Yes. There are three parameters involved: - The ssh-agent listen queue depth, currently set at 5. - The maximum number of contact attempts ssh makes (default=1). - The (randomized) sleep period (default=don't sleep). These together determine how many ssh sessions can be run at the same time. It would be great it these were build-time configurable. This could be done in such a way that the current behavior is still the default, i.e. 5, 1, 0 (no delay). I'm sure other people deploying ssh for mass-distribution are running into the same problem, so this would be useful to them as well. I can come up with a patch if needed. Thanks, -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From tim at multitalents.net Tue Feb 13 07:21:13 2001 From: tim at multitalents.net (Tim Rice) Date: Mon, 12 Feb 2001 12:21:13 -0800 (PST) Subject: patches for UnixWare v2.x pty (misc.c,configure.in) In-Reply-To: <1941_15779_982008293_7@avatar> Message-ID: On Mon, 12 Feb 2001 tom at avatar.itc.nrcs.usda.gov wrote: > > I have attached two patches to the current source code. The first > addresses the pty problems with UnixWare 2.x with connecting with > SSH2. It sets the sigaction to SA_RESTART. This fixes UnixWare v2.x, > but haven't heard any feedback as to effects on other OS'. > > The first patch is against misc.c. > > The second patch adds a section "*-*-sysv4.2uw2*" to configure to > set the TEST_MINUS_S_SH shell and define USE_PIPES. Why the TEST_MINUS_S_SH change? It's autodetected just fine on UnixWare I tested on UnixWare 2.03, UnixWare 2.13, UnixWare 7.1.0 What are you seeing that USE_PIPES fixes? Ie. How can I duplicate the problem here. > > I suspect these same fixes apply to UnixWare 7.x, but I don't have > access to that build platform, or I would include them in the config > as well. > > Let me know whether these can be applied against the current source > tree. > > Thank you, > -Tom Rudnick > > ----------------/---------------------------------------------- > Tom Rudnick | USDA Natural Resources Conservation Service > Fort Collins,CO | tom at avatar.itc.nrcs.usda.gov (970) 295-5427 > ** The 3rd Millennium started Jan 1, 2001. see: ** > ** http://aa.usno.navy.mil/AA/faq/docs/millennium.html ** > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tom at avatar.itc.nrcs.usda.gov Tue Feb 13 08:27:14 2001 From: tom at avatar.itc.nrcs.usda.gov (Tom Rudnick) Date: Mon, 12 Feb 2001 14:27:14 -0700 (MST) Subject: patches for UnixWare v2.x pty (misc.c,configure.in) In-Reply-To: from "Tim Rice" at Feb 12, 2001 12:21:13 PM Message-ID: <200102122127.OAA17660@avatar.itc.nrcs.usda.gov> > > The second patch adds a section "*-*-sysv4.2uw2*" to configure to > > set the TEST_MINUS_S_SH shell and define USE_PIPES. > > Why the TEST_MINUS_S_SH change? > It's autodetected just fine on UnixWare > I tested on UnixWare 2.03, UnixWare 2.13, UnixWare 7.1.0 ...Hmm, yes it is. I just re-tested without the manual define and it autodetected flawlessly. When I first ran configure with the TEST_MINUS_S_SH in it, I got a munged output line for that test. (it ran together with the "testing for ls..." line after it.) I quickly added a manual define and it went away. Now that I take the manual define out and re-configure, it looks fine too. It appears that I moved on too quickly. Drop that change. > > What are you seeing that USE_PIPES fixes? > Ie. How can I duplicate the problem here. > I brought forward USE_PIPES from scp hanging problems in 2.3.0p1. They still exist in the version I just built from today's cvs. After completing a copy, the client returns a prompt, but the session is still active (still has "sh -c scp -t file", "scp -t file", and "sshd" active on the server, plus ssh command on client). Typing an INTR on the client returns an error of "Killed by signal 2", at which point everything exits. To test it, I ran: scp file localhost:file.2 I also tested scp from a remote 2.3.0p1 client with the same results. Let me know if you can duplicate this or not. -Tom -- ----------------/---------------------------------------------- Tom Rudnick | USDA Natural Resources Conservation Service Fort Collins,CO | tom at avatar.itc.nrcs.usda.gov (970) 295-5427 ** The 3rd Millennium started Jan 1, 2001. see: ** ** http://aa.usno.navy.mil/AA/faq/docs/millennium.html ** -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From tim at multitalents.net Tue Feb 13 08:41:52 2001 From: tim at multitalents.net (Tim Rice) Date: Mon, 12 Feb 2001 13:41:52 -0800 (PST) Subject: roundup not portable (CVS 02/10/01) Message-ID: SCO has no roundup() ... cc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o log-client.o readconf.o clientloop.o -L. -Lopenbsd-compat/ -L/usr/local/lib -L/usr/local/ssl/lib -L/us r/local/ssl -lssh -lopenbsd-compat -lwrap -lcrypto -lz -lgen -lprot -lx -ltinfo -lm -lsocket undefined first referenced symbol in file roundup sshconnect1.o i386ld fatal: Symbol referencing errors. No output written to ssh gmake: *** [ssh] Error 13 ... Is roundup a define on all the platforms that support it? Can we safely do #ifndef roundup #define roundup(x, y) ((((x)+((y)-1))/(y))*(y)) #endif It seems to be a define on Solaris, UnixWare, & Linux. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Tue Feb 13 09:55:34 2001 From: tim at multitalents.net (Tim Rice) Date: Mon, 12 Feb 2001 14:55:34 -0800 (PST) Subject: SCO OS3 build broken (CVS 01/12/01) Message-ID: It looks like something got broken in openbsd-compat/bsd-snprintf.c ... gcc -g -O2 -Wall -Dftruncate=chsize -I/usr/local/include -I/usr/local/ssl/includ e -I. -I.. -I../src/openbsd-compat -I../src/openbsd-compat/.. -DHAVE_CONFIG_H -c ../src/openbsd-compat/bsd-snprintf.c In file included from ../src/openbsd-compat/bsd-snprintf.c:72: /usr/local/lib/gcc-lib/i486-unknown-sco3.2v4.2/2.7.2.1/include/varargs.h:88: war ning: `va_start' redefined /usr/local/lib/gcc-lib/i486-unknown-sco3.2v4.2/2.7.2.1/include/stdarg.h:72: warn ing: this is the location of the previous definition ./src/openbsd-compat/bsd-snprintf.c: In function `snprintf': ./src/openbsd-compat/bsd-snprintf.c:725: argument `__builtin_va_alist' doesn't match prototype ./src/openbsd-compat/bsd-snprintf.h:11: prototype declaration ./src/openbsd-compat/bsd-snprintf.c:725: number of arguments doesn't match prot otype ./src/openbsd-compat/bsd-snprintf.h:11: prototype declaration gmake[1]: *** [bsd-snprintf.o] Error 1 gmake[1]: Leaving directory `/usr2/src/networking/openssh/openbsd-compat' gmake: *** [openbsd-compat/libopenbsd-compat.a] Error 2 ... -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mouring at etoh.eviladmin.org Tue Feb 13 10:48:23 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 12 Feb 2001 17:48:23 -0600 (CST) Subject: SCO OS3 build broken (CVS 01/12/01) In-Reply-To: Message-ID: Ok... This is the second report. It's occured on NeXT Also. In bsd-snprintf.c put in: #define HAVE_STDARG_H and see if that solves it. On Mon, 12 Feb 2001, Tim Rice wrote: > > It looks like something got broken in openbsd-compat/bsd-snprintf.c > ... > gcc -g -O2 -Wall -Dftruncate=chsize -I/usr/local/include -I/usr/local/ssl/includ > e -I. -I.. -I../src/openbsd-compat -I../src/openbsd-compat/.. -DHAVE_CONFIG_H -c > ../src/openbsd-compat/bsd-snprintf.c > In file included from ../src/openbsd-compat/bsd-snprintf.c:72: > /usr/local/lib/gcc-lib/i486-unknown-sco3.2v4.2/2.7.2.1/include/varargs.h:88: war > ning: `va_start' redefined > /usr/local/lib/gcc-lib/i486-unknown-sco3.2v4.2/2.7.2.1/include/stdarg.h:72: warn > ing: this is the location of the previous definition > ./src/openbsd-compat/bsd-snprintf.c: In function `snprintf': > ./src/openbsd-compat/bsd-snprintf.c:725: argument `__builtin_va_alist' doesn't > match prototype > ./src/openbsd-compat/bsd-snprintf.h:11: prototype declaration > ./src/openbsd-compat/bsd-snprintf.c:725: number of arguments doesn't match prot > otype > ./src/openbsd-compat/bsd-snprintf.h:11: prototype declaration > gmake[1]: *** [bsd-snprintf.o] Error 1 > gmake[1]: Leaving directory `/usr2/src/networking/openssh/openbsd-compat' > gmake: *** [openbsd-compat/libopenbsd-compat.a] Error 2 > ... > > From djm at mindrot.org Tue Feb 13 10:07:42 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 13 Feb 2001 10:07:42 +1100 (EST) Subject: pam protocol 1 fix In-Reply-To: Message-ID: On Mon, 12 Feb 2001, Kevin Steves wrote: > is this ok? looks good. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From brent at phys.ufl.edu Tue Feb 13 11:05:03 2001 From: brent at phys.ufl.edu (Brent A Nelson) Date: Mon, 12 Feb 2001 19:05:03 -0500 (EST) Subject: host based authentication in protocol version 2 Message-ID: Well, after trying repeatedly to get an ssh version 2 client to connect to an openssh server as a trusted host, and searching throughout the Internet and the openssh mailing list archives, I finally discovered the following statement at http://www.snailbook.com/faq/trusted-host-howto.auto.html: "Note that OpenSSH does not implement hostbased authentication in its protocol 2 support." Doh! Well, that certainly explains the problem! ;-) So, I guess we can force all our clients or servers to be version 1 for now, but does anyone have any idea when hostbased authentication will be implemented in the version 2 support? Also, the openssh documentation implies that this SHOULD work (talks about ssh_known_hosts and ssh_known_hosts2 quite interchangeably). Any chance that the documentation can be ammended until version 2 support for trusted-host authentication is actually added? It might save some frustration... Many thanks, Brent Nelson Sys. Manager Dept. of Physics University of Florida From mouring at etoh.eviladmin.org Tue Feb 13 12:40:07 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 12 Feb 2001 19:40:07 -0600 (CST) Subject: bsd-snprintf.c w/out varargs In-Reply-To: Message-ID: There is alot of other stuff I'd like to do with bsd-snprintf.c, but if you use this patch does things compile better? (And they will be done, but I doubt wants a patch that reformats the whole bsd-snprintf.c in their mailbox. =) I pretty much removed 'varargs' and expanded the macros which did a simple clean up. Before people start yelling about the lack of 'varargs' in my defence.. We don't support them anywhere else.. Therefor it seems silly to support them in bsd-snprintf.c. =) - Ben --- ../../openssh/openbsd-compat/bsd-snprintf.c Thu Feb 8 20:57:55 2001 +++ bsd-snprintf.c Mon Feb 12 19:35:53 2001 @@ -50,39 +50,6 @@ #if !defined(HAVE_SNPRINTF) || !defined(HAVE_VSNPRINTF) -#include -# include -#include - -/* Define this as a fall through, HAVE_STDARG_H is probably already set */ - -#define HAVE_VARARGS_H - -/* varargs declarations: */ - -#if defined(HAVE_STDARG_H) -# include -# define HAVE_STDARGS /* let's hope that works everywhere (mj) */ -# define VA_LOCAL_DECL va_list ap -# define VA_START(f) va_start(ap, f) -# define VA_SHIFT(v,t) ; /* no-op for ANSI */ -# define VA_END va_end(ap) -#else -# if defined(HAVE_VARARGS_H) -# include -# undef HAVE_STDARGS -# define VA_LOCAL_DECL va_list ap -# define VA_START(f) va_start(ap) /* f is ignored! */ -# define VA_SHIFT(v,t) v = va_arg(ap,t) -# define VA_END va_end(ap) -# else -/*XX ** NO VARARGS ** XX*/ -# endif -#endif - -/*int snprintf (char *str, size_t count, const char *fmt, ...);*/ -/*int vsnprintf (char *str, size_t count, const char *fmt, va_list arg);*/ - static void dopr (char *buffer, size_t maxlen, const char *format, va_list args); static void fmtstr (char *buffer, size_t *currlen, size_t maxlen, @@ -718,27 +685,15 @@ #endif /* !HAVE_VSNPRINTF */ #ifndef HAVE_SNPRINTF -/* VARARGS3 */ -#ifdef HAVE_STDARGS int snprintf (char *str,size_t count,const char *fmt,...) -#else -int snprintf (va_alist) va_dcl -#endif { -#ifndef HAVE_STDARGS - char *str; - size_t count; - char *fmt; -#endif - VA_LOCAL_DECL; - - VA_START (fmt); - VA_SHIFT (str, char *); - VA_SHIFT (count, size_t ); - VA_SHIFT (fmt, char *); - (void) vsnprintf(str, count, fmt, ap); - VA_END; - return(strlen(str)); + va_list ap; + + va_start(ap, fmt); + (void) vsnprintf(str, count, fmt, ap); + va_end(ap); + + return(strlen(str)); } #ifdef TEST_SNPRINTF From tim at multitalents.net Tue Feb 13 11:52:46 2001 From: tim at multitalents.net (Tim Rice) Date: Mon, 12 Feb 2001 16:52:46 -0800 (PST) Subject: SCO OS3 build broken (CVS 01/12/01) In-Reply-To: Message-ID: On Mon, 12 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > Ok... This is the second report. It's occured on NeXT Also. > > In bsd-snprintf.c put in: > > #define HAVE_STDARG_H > > and see if that solves it. It turns out the simply adding stdarg.h to the AC_CHECK_HEADERS test in configure.in solves the problem. > On Mon, 12 Feb 2001, Tim Rice wrote: > > > > > It looks like something got broken in openbsd-compat/bsd-snprintf.c [snip] -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Tue Feb 13 12:10:15 2001 From: tim at multitalents.net (Tim Rice) Date: Mon, 12 Feb 2001 17:10:15 -0800 (PST) Subject: bsd-snprintf.c w/out varargs In-Reply-To: Message-ID: On Mon, 12 Feb 2001 mouring at etoh.eviladmin.org wrote: > > There is alot of other stuff I'd like to do with bsd-snprintf.c, but if > you use this patch does things compile better? (And they will be done, > but I doubt wants a patch that reformats the whole bsd-snprintf.c in their > mailbox. =) > > I pretty much removed 'varargs' and expanded the macros which did a simple > clean up. > This works. Or just add stdarg.h to AC_CHECK_HEADERS in configure.in -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Tue Feb 13 12:34:09 2001 From: tim at multitalents.net (Tim Rice) Date: Mon, 12 Feb 2001 17:34:09 -0800 (PST) Subject: fchown() in sftp-server.c (CVS 01/12/01) In-Reply-To: Message-ID: No fchown() on SCO Open Server 3 Patch attached -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- openssh_cvs/configure.in.old Mon Feb 12 14:04:32 2001 +++ openssh_cvs/configure.in Mon Feb 12 17:21:15 2001 @@ -325,10 +325,10 @@ ) # Checks for header files. -AC_CHECK_HEADERS(bstring.h endian.h floatingpoint.h getopt.h lastlog.h limits.h login.h login_cap.h maillock.h netdb.h netgroup.h netinet/in_systm.h paths.h poll.h pty.h regex.h shadow.h security/pam_appl.h sys/bitypes.h sys/bsdtty.h sys/cdefs.h sys/poll.h sys/queue.h sys/select.h sys/stat.h sys/stropts.h sys/sysmacros.h sys/time.h sys/ttcompat.h sys/un.h stddef.h time.h ttyent.h usersec.h util.h utime.h utmp.h utmpx.h vis.h) +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 regex.h shadow.h security/pam_appl.h sys/bitypes.h sys/bsdtty.h sys/cdefs.h sys/poll.h sys/queue.h sys/select.h sys/stat.h sys/stropts.h sys/sysmacros.h sys/time.h sys/ttcompat.h sys/un.h stdarg.h stddef.h time.h ttyent.h usersec.h util.h utime.h utmp.h utmpx.h vis.h) dnl Checks for library functions. -AC_CHECK_FUNCS(arc4random atexit b64_ntop bcopy bindresvport_sa clock fchmod freeaddrinfo futimes gai_strerror getcwd getaddrinfo getgrouplist getnameinfo getrlimit getrusage getttyent inet_aton inet_ntoa innetgr login_getcapbool md5_crypt memmove mkdtemp on_exit openpty realpath rresvport_af setdtablesize setenv seteuid setlogin setproctitle setreuid setrlimit setsid sigaction sigvec snprintf strerror strlcat strlcpy strmode strsep strtok_r sysconf tcgetpgrp utimes vsnprintf vhangup vis waitpid _getpty __b64_ntop) +AC_CHECK_FUNCS(arc4random atexit b64_ntop bcopy bindresvport_sa clock fchown fchmod freeaddrinfo futimes gai_strerror getcwd getaddrinfo getgrouplist getnameinfo getrlimit getrusage getttyent inet_aton inet_ntoa innetgr login_getcapbool md5_crypt memmove mkdtemp on_exit openpty realpath rresvport_af setdtablesize setenv seteuid setlogin setproctitle setreuid setrlimit setsid sigaction sigvec snprintf strerror strlcat strlcpy strmode strsep strtok_r sysconf tcgetpgrp utimes vsnprintf vhangup vis waitpid _getpty __b64_ntop) dnl Checks for time functions AC_CHECK_FUNCS(gettimeofday time) dnl Checks for libutil functions --- openssh_cvs/sftp-server.c.old Sat Feb 10 19:39:44 2001 +++ openssh_cvs/sftp-server.c Mon Feb 12 17:30:38 2001 @@ -609,7 +609,11 @@ status = errno_to_portable(errno); } if (a->flags & SSH2_FILEXFER_ATTR_UIDGID) { +#ifdef HAVE_FCHOWN ret = fchown(fd, a->uid, a->gid); +#else + ret = chown(name, a->uid, a->gid); +#endif if (ret == -1) status = errno_to_portable(errno); } From mouring at etoh.eviladmin.org Tue Feb 13 14:34:25 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 12 Feb 2001 21:34:25 -0600 (CST) Subject: fchown() in sftp-server.c (CVS 01/12/01) In-Reply-To: Message-ID: Applied On Mon, 12 Feb 2001, Tim Rice wrote: > > No fchown() on SCO Open Server 3 > > Patch attached > > From tim at multitalents.net Tue Feb 13 16:22:22 2001 From: tim at multitalents.net (Tim Rice) Date: Mon, 12 Feb 2001 21:22:22 -0800 (PST) Subject: patches for UnixWare v2.x pty (misc.c,configure.in) In-Reply-To: <200102122127.OAA17660@avatar.itc.nrcs.usda.gov> Message-ID: On Mon, 12 Feb 2001, Tom Rudnick wrote: > > > The second patch adds a section "*-*-sysv4.2uw2*" to configure to > > > set the TEST_MINUS_S_SH shell and define USE_PIPES. > > [snip] > > What are you seeing that USE_PIPES fixes? > > Ie. How can I duplicate the problem here. It looks like USE_PIPES is needed. Now that I think of it, all my scp usage has been from UnixWare to some other non UnixWare platform. I can duplicate the problem on UnixWare 2.03, UnixWare 2.13, and UnixWare 7.1.0 (*-*-sysv5*) I do not think "*-*-sysv4.2uw2*" is needed. I would be suprised if other sysv4.2 did not also have this problem. > > > I brought forward USE_PIPES from scp hanging problems in 2.3.0p1. > They still exist in the version I just built from today's cvs. > > After completing a copy, the client returns a prompt, but the > session is still active (still has "sh -c scp -t file", > "scp -t file", and "sshd" active on the server, plus ssh command > on client). > > Typing an INTR on the client returns an error of "Killed by signal 2", > at which point everything exits. > > To test it, I ran: > > scp file localhost:file.2 > > I also tested scp from a remote 2.3.0p1 client with the same results. > > Let me know if you can duplicate this or not. > > -Tom > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Tue Feb 13 17:02:03 2001 From: tim at multitalents.net (Tim Rice) Date: Mon, 12 Feb 2001 22:02:03 -0800 (PST) Subject: configure.in reorder patch Message-ID: Feb 12 CVS (sort of, see warning below) I've had to change around some of the code in configure.in to get some platforms to compile with the --with-tcp-wrappers option. Basicly I have set it up to check headers check system libraries check for optional packages check functions I have also tried to clean up the library order as it is important on some platforms. This patch works on Solaris 8 UnixWare 2.03 UnixWare 2.1.3 UnixWare 7.1.0 SCO Open Server 3 (3.2v4.2) SCO Open Server 5.0.4 Caldera 2.4 Redhat 6.2 Warning: This patch has stdargs.h added to AC_CHECK_HEADERS and fchown added to AC_CHECK_FUNCS. They were recently applied but as of Mon Feb 12 21:37:00 PST 2001 they don't show up in the CVS Make sure the AC_CHECK_HEADERS and AC_CHECK_FUNCS sections match what is in the patch or the patch will fail. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- openssh_cvs/configure.in.orig Mon Feb 12 17:47:05 2001 +++ openssh_cvs/configure.in Mon Feb 12 17:47:55 2001 @@ -223,7 +223,7 @@ LDFLAGS="$LDFLAGS -L/usr/local/lib" MANTYPE='$(CATMAN)' mansubdir=cat - LIBS="$LIBS -lgen -lsocket -los -lprot -lx -ltinfo -lm" + LIBS="$LIBS -los -lprot -lx -ltinfo -lm" no_dev_ptmx=1 RANLIB=true AC_DEFINE(BROKEN_SYS_TERMIO_H) @@ -295,93 +295,41 @@ ] ) +# Checks for header files. +AC_CHECK_HEADERS(bstring.h endian.h floatingpoint.h getopt.h lastlog.h limits.h login.h login_cap.h maillock.h netdb.h netgroup.h netinet/in_systm.h paths.h poll.h pty.h regex.h shadow.h security/pam_appl.h sys/bitypes.h sys/bsdtty.h sys/cdefs.h sys/poll.h sys/queue.h sys/select.h sys/stat.h sys/stropts.h sys/sysmacros.h sys/time.h sys/ttcompat.h sys/un.h stdarg.h stddef.h time.h ttyent.h usersec.h util.h utime.h utmp.h utmpx.h vis.h) + +saved_LIBS="$LIBS" # Checks for libraries. -if test -z "$no_libsocket" ; then - AC_CHECK_LIB(nsl, yp_match, , ) -fi if test -z "$no_libnsl" ; then - AC_CHECK_LIB(socket, main, , ) + AC_CHECK_LIB(nsl, yp_match, LIBS="$LIBS -lnsl") fi +if test -z "$no_libsocket" ; then + AC_CHECK_LIB(socket, main, + [ + if test "$saved_LIBS" = "$LIBS" ; then + LIBS="$LIBS -lsocket" + else + LIBS="$saved_LIBS -lsocket -lnsl" + fi + ] ) +fi + +dnl SCO OS3 needs this for libwrap +AC_CHECK_LIB(rpc, innetgr, LIBS="-lrpc -lyp -lrpc $LIBS" , , -lyp -lrpc) -AC_CHECK_LIB(gen, getspnam, LIBS="$LIBS -lgen") +AC_CHECK_LIB(gen, getspnam) AC_CHECK_LIB(z, deflate, ,AC_MSG_ERROR([*** zlib missing - please install first ***])) -AC_CHECK_LIB(util, login, AC_DEFINE(HAVE_LIBUTIL_LOGIN) LIBS="$LIBS -lutil") +AC_CHECK_LIB(util, login, AC_DEFINE(HAVE_LIBUTIL_LOGIN) LIBS="-lutil $LIBS") AC_CHECK_FUNC(regcomp, [ AC_DEFINE(HAVE_REGCOMP)], [ AC_CHECK_LIB(pcre, pcre_info, - AC_DEFINE(HAVE_LIBPCRE) LIBS="$LIBS -lpcreposix -lpcre") + AC_DEFINE(HAVE_LIBPCRE) LIBS="-lpcreposix -lpcre $LIBS") ] ) -dnl UnixWare 2.x -AC_CHECK_FUNC(strcasecmp, - [], [ AC_CHECK_LIB(resolv, strcasecmp, LIBS="$LIBS -lresolv") ] -) -AC_CHECK_FUNC(utimes, - [], [ AC_CHECK_LIB(c89, utimes, LIBS="$LIBS -lc89") ] -) - -# Checks for header files. -AC_CHECK_HEADERS(bstring.h endian.h floatingpoint.h getopt.h lastlog.h limits.h login.h login_cap.h maillock.h netdb.h netgroup.h netinet/in_systm.h paths.h poll.h pty.h regex.h shadow.h security/pam_appl.h sys/bitypes.h sys/bsdtty.h sys/cdefs.h sys/poll.h sys/queue.h sys/select.h sys/stat.h sys/stropts.h sys/sysmacros.h sys/time.h sys/ttcompat.h sys/un.h stdarg.h stddef.h time.h ttyent.h usersec.h util.h utime.h utmp.h utmpx.h vis.h) - -dnl Checks for library functions. -AC_CHECK_FUNCS(arc4random atexit b64_ntop bcopy bindresvport_sa clock fchown fchmod freeaddrinfo futimes gai_strerror getcwd getaddrinfo getgrouplist getnameinfo getrlimit getrusage getttyent inet_aton inet_ntoa innetgr login_getcapbool md5_crypt memmove mkdtemp on_exit openpty realpath rresvport_af setdtablesize setenv seteuid setlogin setproctitle setreuid setrlimit setsid sigaction sigvec snprintf strerror strlcat strlcpy strmode strsep strtok_r sysconf tcgetpgrp utimes vsnprintf vhangup vis waitpid _getpty __b64_ntop) -dnl Checks for time functions -AC_CHECK_FUNCS(gettimeofday time) -dnl Checks for libutil functions -AC_CHECK_HEADERS(libutil.h) -AC_CHECK_FUNCS(login logout updwtmp logwtmp) -dnl Checks for utmp functions -AC_CHECK_FUNCS(endutent getutent getutid getutline pututline setutent) -AC_CHECK_FUNCS(utmpname) -dnl Checks for utmpx functions -AC_CHECK_FUNCS(endutxent getutxent getutxid getutxline pututxline ) -AC_CHECK_FUNCS(setutxent utmpxname) - -AC_CHECK_FUNC(getuserattr, - [AC_DEFINE(HAVE_GETUSERATTR)], - [AC_CHECK_LIB(s, getuserattr, [LIBS="$LIBS -ls"; AC_DEFINE(HAVE_GETUSERATTR)])] -) - -AC_CHECK_FUNC(login, - [AC_DEFINE(HAVE_LOGIN)], - [AC_CHECK_LIB(bsd, login, [LIBS="$LIBS -lbsd"; AC_DEFINE(HAVE_LOGIN)])] -) - -AC_CHECK_FUNC(daemon, - [AC_DEFINE(HAVE_DAEMON)], - [AC_CHECK_LIB(bsd, daemon, [LIBS="$LIBS -lbsd"; AC_DEFINE(HAVE_DAEMON)])] -) - -AC_CHECK_FUNC(getpagesize, - [AC_DEFINE(HAVE_GETPAGESIZE)], - [AC_CHECK_LIB(ucb, getpagesize, [LIBS="$LIBS -lucb"; AC_DEFINE(HAVE_GETPAGESIZE)])] -) - -# Check for broken snprintf -if test "x$ac_cv_func_snprintf" = "xyes" ; then - AC_MSG_CHECKING([whether snprintf correctly terminates long strings]) - AC_TRY_RUN( - [ -#include -int main(void){char b[5];snprintf(b,5,"123456789");return(b[4]!='\0');} - ], - [AC_MSG_RESULT(yes)], - [ - AC_MSG_RESULT(no) - AC_DEFINE(BROKEN_SNPRINTF) - AC_MSG_WARN([****** Your snprintf() function is broken, complain to your vendor]) - ] - ) -fi - -AC_FUNC_GETPGRP - -AC_FUNC_STRFTIME - # Check for PAM libs PAM_MSG="no" AC_ARG_WITH(pam, @@ -452,7 +400,7 @@ LDFLAGS="$saved_LDFLAGS" fi - LIBS="$saved_LIBS -lcrypto" + LIBS="-lcrypto $saved_LIBS" # Basic test to check for compatible version and correct linking # *does not* test for RSA - that comes later. @@ -505,7 +453,7 @@ fi fi fi -LIBS="$saved_LIBS -lcrypto" +LIBS="-lcrypto $saved_LIBS" # Now test RSA support saved_LIBS="$LIBS" @@ -514,7 +462,7 @@ if test -z "$WANTS_RSAREF" ; then LIBS="$saved_LIBS" else - LIBS="$saved_LIBS -lRSAglue -lrsaref" + LIBS="-lRSAglue -lrsaref $saved_LIBS" fi AC_TRY_RUN([ #include @@ -552,7 +500,7 @@ else RSA_MSG="yes (using RSAref)" AC_MSG_RESULT(using RSAref) - LIBS="$saved_LIBS -lcrypto -lRSAglue -lrsaref" + LIBS="-lcrypto -lRSAglue -lrsaref $saved_LIBS" fi fi fi @@ -568,6 +516,189 @@ LIBS="$LIBS -liberty"; fi +dnl UnixWare 2.x +AC_CHECK_FUNC(strcasecmp, + [], [ AC_CHECK_LIB(resolv, strcasecmp, LIBS="$LIBS -lresolv") ] +) +AC_CHECK_FUNC(utimes, + [], [ AC_CHECK_LIB(c89, utimes, LIBS="$LIBS -lc89") ] +) + +# Check whether user wants Kerberos support +KRB4_MSG="no" +AC_ARG_WITH(kerberos4, + [ --with-kerberos4=PATH Enable Kerberos 4 support], + [ + if test "x$withval" != "xno" ; then + + if test "x$withval" != "xyes" ; then + CPPFLAGS="$CPPFLAGS -I${withval}/include" + LDFLAGS="$LDFLAGS -L${withval}/lib" + if test ! -z "$need_dash_r" ; then + LDFLAGS="$LDFLAGS -R${withval}/lib" + fi + if test ! -z "$blibpath" ; then + blibpath="$blibpath:${withval}/lib" + fi + else + if test -d /usr/include/kerberosIV ; then + CPPFLAGS="$CPPFLAGS -I/usr/include/kerberosIV" + fi + fi + + AC_CHECK_HEADERS(krb.h) + AC_CHECK_LIB(krb, main) + if test "$ac_cv_header_krb_h" != yes; then + AC_MSG_WARN([Cannot find krb.h, build may fail]) + fi + if test "$ac_cv_lib_krb_main" != yes; then + AC_MSG_WARN([Cannot find libkrb, build may fail]) + fi + + KLIBS="-lkrb -ldes" + AC_CHECK_LIB(resolv, dn_expand, , ) + KRB4=yes + KRB4_MSG="yes" + AC_DEFINE(KRB4) + fi + ] +) + +# Check whether user wants AFS support +AFS_MSG="no" +AC_ARG_WITH(afs, + [ --with-afs=PATH Enable AFS support], + [ + if test "x$withval" != "xno" ; then + + if test "x$withval" != "xyes" ; then + CPPFLAGS="$CPPFLAGS -I${withval}/include" + LDFLAGS="$LDFLAGS -L${withval}/lib" + fi + + if test -z "$KRB4" ; then + AC_MSG_WARN([AFS requires Kerberos IV support, build may fail]) + fi + + LIBS="$LIBS -lkafs" + if test ! -z "$AFS_LIBS" ; then + LIBS="$LIBS $AFS_LIBS" + fi + AC_DEFINE(AFS) + AFS_MSG="yes" + fi + ] +) +LIBS="$LIBS $KLIBS" + +# Check whether user wants S/Key support +SKEY_MSG="no" +AC_ARG_WITH(skey, + [ --with-skey=PATH Enable S/Key support], + [ + if test "x$withval" != "xno" ; then + + if test "x$withval" != "xyes" ; then + CPPFLAGS="$CPPFLAGS -I${withval}/include" + LDFLAGS="$LDFLAGS -L${withval}/lib" + fi + + AC_DEFINE(SKEY) + LIBS="-lskey $LIBS" + SKEY_MSG="yes" + + AC_CHECK_FUNC(skey_keyinfo, + [], + [ + AC_MSG_ERROR([** Incomplete or missing s/key libraries.]) + ]) + fi + ] +) + +# Check whether user wants TCP wrappers support +TCPW_MSG="no" +AC_ARG_WITH(tcp-wrappers, + [ --with-tcp-wrappers Enable tcpwrappers support], + [ + if test "x$withval" != "xno" ; then + saved_LIBS="$LIBS" + LIBS="-lwrap $LIBS" + AC_MSG_CHECKING(for libwrap) + AC_TRY_LINK( + [ +#include + int deny_severity = 0, allow_severity = 0; + ], + [hosts_access(0);], + [ + AC_MSG_RESULT(yes) + AC_DEFINE(LIBWRAP) + TCPW_MSG="yes" + ], + [ + AC_MSG_ERROR([*** libwrap missing]) + ] + ) + fi + ] +) + +dnl Checks for library functions. +AC_CHECK_FUNCS(arc4random atexit b64_ntop bcopy bindresvport_sa clock fchown fchmod freeaddrinfo futimes gai_strerror getcwd getaddrinfo getgrouplist getnameinfo getrlimit getrusage getttyent inet_aton inet_ntoa innetgr login_getcapbool md5_crypt memmove mkdtemp on_exit openpty realpath rresvport_af setdtablesize setenv seteuid setlogin setproctitle setreuid setrlimit setsid sigaction sigvec snprintf strerror strlcat strlcpy strmode strsep strtok_r sysconf tcgetpgrp utimes vsnprintf vhangup vis waitpid _getpty __b64_ntop) +dnl Checks for time functions +AC_CHECK_FUNCS(gettimeofday time) +dnl Checks for libutil functions +AC_CHECK_HEADERS(libutil.h) +AC_CHECK_FUNCS(login logout updwtmp logwtmp) +dnl Checks for utmp functions +AC_CHECK_FUNCS(endutent getutent getutid getutline pututline setutent) +AC_CHECK_FUNCS(utmpname) +dnl Checks for utmpx functions +AC_CHECK_FUNCS(endutxent getutxent getutxid getutxline pututxline ) +AC_CHECK_FUNCS(setutxent utmpxname) + +AC_CHECK_FUNC(getuserattr, + [AC_DEFINE(HAVE_GETUSERATTR)], + [AC_CHECK_LIB(s, getuserattr, [LIBS="$LIBS -ls"; AC_DEFINE(HAVE_GETUSERATTR)])] +) + +AC_CHECK_FUNC(login, + [AC_DEFINE(HAVE_LOGIN)], + [AC_CHECK_LIB(bsd, login, [LIBS="$LIBS -lbsd"; AC_DEFINE(HAVE_LOGIN)])] +) + +AC_CHECK_FUNC(daemon, + [AC_DEFINE(HAVE_DAEMON)], + [AC_CHECK_LIB(bsd, daemon, [LIBS="$LIBS -lbsd"; AC_DEFINE(HAVE_DAEMON)])] +) + +AC_CHECK_FUNC(getpagesize, + [AC_DEFINE(HAVE_GETPAGESIZE)], + [AC_CHECK_LIB(ucb, getpagesize, [LIBS="$LIBS -lucb"; AC_DEFINE(HAVE_GETPAGESIZE)])] +) + +# Check for broken snprintf +if test "x$ac_cv_func_snprintf" = "xyes" ; then + AC_MSG_CHECKING([whether snprintf correctly terminates long strings]) + AC_TRY_RUN( + [ +#include +int main(void){char b[5];snprintf(b,5,"123456789");return(b[4]!='\0');} + ], + [AC_MSG_RESULT(yes)], + [ + AC_MSG_RESULT(no) + AC_DEFINE(BROKEN_SNPRINTF) + AC_MSG_WARN([****** Your snprintf() function is broken, complain to your vendor]) + ] + ) +fi + +AC_FUNC_GETPGRP + +AC_FUNC_STRFTIME + # Checks for data types AC_CHECK_SIZEOF(char, 1) AC_CHECK_SIZEOF(short int, 2) @@ -1151,126 +1282,6 @@ ) AC_SUBST(MANTYPE) AC_SUBST(mansubdir) - -# Check whether user wants Kerberos support -KRB4_MSG="no" -AC_ARG_WITH(kerberos4, - [ --with-kerberos4=PATH Enable Kerberos 4 support], - [ - if test "x$withval" != "xno" ; then - - if test "x$withval" != "xyes" ; then - CPPFLAGS="$CPPFLAGS -I${withval}/include" - LDFLAGS="$LDFLAGS -L${withval}/lib" - if test ! -z "$need_dash_r" ; then - LDFLAGS="$LDFLAGS -R${withval}/lib" - fi - if test ! -z "$blibpath" ; then - blibpath="$blibpath:${withval}/lib" - fi - else - if test -d /usr/include/kerberosIV ; then - CPPFLAGS="$CPPFLAGS -I/usr/include/kerberosIV" - fi - fi - - AC_CHECK_HEADERS(krb.h) - AC_CHECK_LIB(krb, main) - if test "$ac_cv_header_krb_h" != yes; then - AC_MSG_WARN([Cannot find krb.h, build may fail]) - fi - if test "$ac_cv_lib_krb_main" != yes; then - AC_MSG_WARN([Cannot find libkrb, build may fail]) - fi - - KLIBS="-lkrb -ldes" - AC_CHECK_LIB(resolv, dn_expand, , ) - KRB4=yes - KRB4_MSG="yes" - AC_DEFINE(KRB4) - fi - ] -) - -# Check whether user wants AFS support -AFS_MSG="no" -AC_ARG_WITH(afs, - [ --with-afs=PATH Enable AFS support], - [ - if test "x$withval" != "xno" ; then - - if test "x$withval" != "xyes" ; then - CPPFLAGS="$CPPFLAGS -I${withval}/include" - LDFLAGS="$LDFLAGS -L${withval}/lib" - fi - - if test -z "$KRB4" ; then - AC_MSG_WARN([AFS requires Kerberos IV support, build may fail]) - fi - - LIBS="$LIBS -lkafs" - if test ! -z "$AFS_LIBS" ; then - LIBS="$LIBS $AFS_LIBS" - fi - AC_DEFINE(AFS) - AFS_MSG="yes" - fi - ] -) -LIBS="$LIBS $KLIBS" - -# Check whether user wants S/Key support -SKEY_MSG="no" -AC_ARG_WITH(skey, - [ --with-skey=PATH Enable S/Key support], - [ - if test "x$withval" != "xno" ; then - - if test "x$withval" != "xyes" ; then - CPPFLAGS="$CPPFLAGS -I${withval}/include" - LDFLAGS="$LDFLAGS -L${withval}/lib" - fi - - AC_DEFINE(SKEY) - LIBS="-lskey $LIBS" - SKEY_MSG="yes" - - AC_CHECK_FUNC(skey_keyinfo, - [], - [ - AC_MSG_ERROR([** Incomplete or missing s/key libraries.]) - ]) - fi - ] -) - -# Check whether user wants TCP wrappers support -TCPW_MSG="no" -AC_ARG_WITH(tcp-wrappers, - [ --with-tcp-wrappers Enable tcpwrappers support], - [ - if test "x$withval" != "xno" ; then - saved_LIBS="$LIBS" - LIBS="$LIBS -lwrap" - AC_MSG_CHECKING(for libwrap) - AC_TRY_LINK( - [ -#include - int deny_severity = 0, allow_severity = 0; - ], - [hosts_access(0);], - [ - AC_MSG_RESULT(yes) - AC_DEFINE(LIBWRAP) - TCPW_MSG="yes" - ], - [ - AC_MSG_ERROR([*** libwrap missing]) - ] - ) - fi - ] -) # Check whether to enable MD5 passwords MD5_MSG="no" From gert at greenie.muc.de Tue Feb 13 19:38:25 2001 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 13 Feb 2001 09:38:25 +0100 Subject: SCO OS3 build broken (CVS 01/12/01) In-Reply-To: ; from Tim Rice on Mon, Feb 12, 2001 at 02:55:34PM -0800 References: Message-ID: <20010213093825.A13859@greenie.muc.de> Hi, On Mon, Feb 12, 2001 at 02:55:34PM -0800, Tim Rice wrote: > /usr/local/lib/gcc-lib/i486-unknown-sco3.2v4.2/2.7.2.1/include/varargs.h:88: war > ning: `va_start' redefined > /usr/local/lib/gcc-lib/i486-unknown-sco3.2v4.2/2.7.2.1/include/stdarg.h:72: warn > ing: this is the location of the previous definition Looks like *both* varargs.h and stdarg.h are included, which is bad because they are incompatible (and result in a different syntax for functions with a varying number of arguments). 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 Tue Feb 13 22:36:58 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Tue, 13 Feb 2001 12:36:58 +0100 (MET) Subject: patches for UnixWare v2.x pty (misc.c,configure.in) In-Reply-To: <1941_15779_982008293_7@avatar> Message-ID: On Mon, 12 Feb 2001 tom at avatar.itc.nrcs.usda.gov wrote: : I have attached two patches to the current source code. The first : addresses the pty problems with UnixWare 2.x with connecting with : SSH2. It sets the sigaction to SA_RESTART. This fixes UnixWare v2.x, : but haven't heard any feedback as to effects on other OS'. i don't understand, why is SA_RESTART is needed? From thrawne at molcos.demon.co.uk Tue Feb 13 23:50:05 2001 From: thrawne at molcos.demon.co.uk (Shawn Phillips) Date: Tue, 13 Feb 2001 12:50:05 -0000 Subject: ZLIB Problems Message-ID: <001701c095bb$7d3b5fc0$4318989e@molcos> Hi, I am attempting to compile SSH under Sequent Dynix/ptx 4.4.7, After compiling and installing ZLIB to /usr/local/include and /usr/local/lib the ./configure command returns that ZLIB is not installed. Any ideas? Or should I be redirecting this question to the ZLIB mailing lists? Thanks T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010213/c583a51a/attachment.html From djm at mindrot.org Wed Feb 14 00:40:13 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Feb 2001 00:40:13 +1100 (EST) Subject: patches for UnixWare v2.x pty (misc.c,configure.in) In-Reply-To: Message-ID: On Tue, 13 Feb 2001, Kevin Steves wrote: > On Mon, 12 Feb 2001 tom at avatar.itc.nrcs.usda.gov wrote: > : I have attached two patches to the current source code. The first > : addresses the pty problems with UnixWare 2.x with connecting with > : SSH2. It sets the sigaction to SA_RESTART. This fixes UnixWare v2.x, > : but haven't heard any feedback as to effects on other OS'. > > i don't understand, why is SA_RESTART is needed? On Unixware 2.x grantpt (pty.c) was getting interrupted by SIGCHLD. On sysv systems syscalls aren't restarted by default after being interrupted by a signal. It is the default for BSD signal, so it makes sense to have it in there. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Wed Feb 14 00:46:48 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Feb 2001 00:46:48 +1100 (EST) Subject: [PATCH] Tell PAM about remote host earlier In-Reply-To: <3A87099D.82663BCD@pcug.org.au> Message-ID: On Mon, 12 Feb 2001, Andrew Bartlett wrote: > I also noticed that OpenSSH 'closes' the session for users who don't > authenticate themselves successfully, creating misleading entries in the > logs (session closed for user abartlet) when abartlet never opened a > session. This patch corrects the situation. Thanks again - I applied something similar which also checks for pam_setcred being successful before deleting creds. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Wed Feb 14 00:51:43 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Feb 2001 00:51:43 +1100 (EST) Subject: add scp path to _PATH_STDPATH In-Reply-To: Message-ID: On Mon, 12 Feb 2001, Kevin Steves wrote: > what do you think about this patch to add the path to scp to > _PATH_STDPATH? is there a better or cleaner way to do this? i'm hoping > to ward off 'scp doesn't work' questions for the next release. I have been a little suspicious of this in the past, because I don't like messing with PATH without being explicit. OTOH it would solve a lot of support questions from people who don't read the FAQ. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From mouring at etoh.eviladmin.org Wed Feb 14 01:48:28 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 13 Feb 2001 08:48:28 -0600 (CST) Subject: SCO OS3 build broken (CVS 01/12/01) In-Reply-To: <20010213093825.A13859@greenie.muc.de> Message-ID: On Tue, 13 Feb 2001, Gert Doering wrote: > Hi, > > On Mon, Feb 12, 2001 at 02:55:34PM -0800, Tim Rice wrote: > > /usr/local/lib/gcc-lib/i486-unknown-sco3.2v4.2/2.7.2.1/include/varargs.h:88: war > > ning: `va_start' redefined > > /usr/local/lib/gcc-lib/i486-unknown-sco3.2v4.2/2.7.2.1/include/stdarg.h:72: warn > > ing: this is the location of the previous definition > > Looks like *both* varargs.h and stdarg.h are included, which is bad > because they are incompatible (and result in a different syntax for > functions with a varying number of arguments). > > gert > bsd-snprintf.c has been stripped of all varargs support. So this is no longer an issue. - Ben From djm at mindrot.org Wed Feb 14 01:26:27 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Feb 2001 01:26:27 +1100 (EST) Subject: OSF_SIA bug in 2.3.0p1 In-Reply-To: <20010212112224.F7301@HiWAAY.net> Message-ID: On Mon, 12 Feb 2001, Chris Adams wrote: > The 4.0F manpage says collect can be NULL, but I've read in other places > it is a bad idea, and found out why. > > Someone already did a "quick fix" to CVS on the first problem. Here is > a patch against CVS that fixes the collect problem as well as some other > things (like not really blocking locked and expired accounts and not > returning the correct messages to the user). > > This patch pulls the SIA stuff out into a separate file that provides > two functions: one to check the username/password and one to setup a > session. Thanks - this makes the SIA support a great deal neater! Please check what I have committed to make sure I haven't broken your work :) -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From Todd.Miller at courtesan.com Wed Feb 14 01:37:33 2001 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Tue, 13 Feb 2001 07:37:33 -0700 Subject: issue with EGD in openssh Message-ID: <200102131437.f1DEbXr19575@xerxes.courtesan.com> There are a couple of issues regarding egd support in OpenSSH. 1) SIGPIPE is not ignored for the master listener daemon. I put the signal() call early on since it needs to be before get_random_bytes() is called but it could also be placed in the EGD version of get_random_bytes(). For some reason, with prngd I am getting SIGPIPE even though the prngd processes is not dying. get_random_bytes() also needs to check for EPIPE and reconnect to the daemon if it gets that. 2) If there are currently SOMAXCONN connections to the entropy daemon, further ones will return ECONNREFUSED. It seems like some kind of connect || sleep loop is needed here. I used usleep() which not all OSes support. I've included the usleep.c from OpenBSD which uses nanosleep() but since not every OS has that either, a version using select() should probably be used when the OS has no nanosleep. Also, the sleep is for only a total of 1 second before giving up. Perhaps it should be longer. I've included patches for these at the end of this message. /* * Copyright (c) 1989, 1993 * The Regents of the University of California. 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. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the University of * California, Berkeley and its contributors. * 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``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 REGENTS OR CONTRIBUTORS 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_USLEEP #if defined(LIBC_SCCS) && !defined(lint) static char rcsid[] = "$OpenBSD: usleep.c,v 1.7 1998/02/08 22:44:09 tholo Exp $"; #endif /* LIBC_SCCS and not lint */ /* XXX - if no nanosleep() just use select */ int usleep(useconds) unsigned int useconds; { struct timespec rqt; if (useconds == 0) return(0); rqt.tv_sec = useconds / 1000000; rqt.tv_nsec = (useconds % 1000000) * 1000; return(nanosleep(&rqt, NULL)); } #endif /* !HAVE_USLEEP */ --- sshd.c.DIST Mon Feb 12 07:38:08 2001 +++ sshd.c Mon Feb 12 07:36:18 2001 @@ -505,6 +505,9 @@ /* Initialize configuration options to their default values. */ initialize_server_options(&options); + /* Ignore SIGPIPE */ + signal(SIGPIPE, SIG_IGN); + /* Parse command-line arguments. */ while ((opt = getopt(ac, av, "f:p:b:k:h:g:V:u:diqQ46")) != EOF) { switch (opt) { --- entropy.c.DIST Mon Oct 16 03:13:43 2000 +++ entropy.c Mon Feb 12 11:00:53 2001 @@ -69,6 +69,7 @@ char msg[2]; struct sockaddr_un addr; int addr_len; + int i, rval; /* Sanity checks */ if (sizeof(EGD_SOCKET) > sizeof(addr.sun_path)) @@ -81,13 +82,25 @@ strlcpy(addr.sun_path, EGD_SOCKET, sizeof(addr.sun_path)); addr_len = offsetof(struct sockaddr_un, sun_path) + sizeof(EGD_SOCKET); +reopen: fd = socket(AF_UNIX, SOCK_STREAM, 0); if (fd == -1) { error("Couldn't create AF_UNIX socket: %s", strerror(errno)); return(0); } - if (connect(fd, (struct sockaddr*)&addr, addr_len) == -1) { + /* + * We may get ECONNREFUSED due to small SOMAXCONN in the daemon. + * This will retry for at most one second (XXX - longer?) + */ + for (i = 0; i < 1000 && + (rval == connect(fd, (struct sockaddr*)&addr, addr_len)) == -1 && + errno == ECONNREFUSED; + i++) { + usleep(1000); + } + + if (rval == -1) { error("Couldn't connect to EGD socket \"%s\": %s", addr.sun_path, strerror(errno)); close(fd); @@ -99,6 +112,10 @@ msg[1] = len; if (atomicio(write, fd, msg, sizeof(msg)) != sizeof(msg)) { + if (errno == EPIPE) { + close(fd); + goto reopen; + } error("Couldn't write to EGD socket \"%s\": %s", EGD_SOCKET, strerror(errno)); close(fd); @@ -106,6 +123,10 @@ } if (atomicio(read, fd, buf, len) != len) { + if (errno == EPIPE) { + close(fd); + goto reopen; + } error("Couldn't read from EGD socket \"%s\": %s", EGD_SOCKET, strerror(errno)); close(fd); From patl at curl.com Wed Feb 14 03:43:46 2001 From: patl at curl.com (Patrick J. LoPresti) Date: 13 Feb 2001 11:43:46 -0500 Subject: OpenSSH does not read /etc/environment ? Message-ID: We are trying to upgrade ourselves from SSH 1.2.26 to OpenSSH 2.3.0p1. For years, we have used /etc/environment to set system-wide variables for SSH logins (whether interactive and not). This works with SSH 1.2.26 on all platforms. But a quick browse of the OpenSSH sources suggests that it only reads /etc/environment on AIX. Is this difference in behavior a conscious design decision, or is it just an artifact of when the code base was forked? Would you accept patches to make OpenSSH read /etc/environment on all platforms? Thanks! - Pat From stevesk at sweden.hp.com Wed Feb 14 04:06:46 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Tue, 13 Feb 2001 18:06:46 +0100 (MET) Subject: OSF_SIA bug in 2.3.0p1 In-Reply-To: Message-ID: On Wed, 14 Feb 2001, Damien Miller wrote: : Thanks - this makes the SIA support a great deal neater! : : Please check what I have committed to make sure I haven't broken your : work :) one thing broke, and i think this is correct: Index: session.c =================================================================== RCS file: /var/cvs/openssh/session.c,v retrieving revision 1.72 diff -u -r1.72 session.c --- session.c 2001/02/13 14:25:23 1.72 +++ session.c 2001/02/13 17:05:46 @@ -1046,8 +1046,8 @@ switch, so we let login(1) to this for us. */ if (!options.use_login) { #ifdef HAVE_OSF_SIA -#else /* HAVE_OSF_SIA */ session_setup_sia(pw->pw_name, ttyname); +#else /* HAVE_OSF_SIA */ #ifdef HAVE_CYGWIN if (is_winnt) { #else From jmknoble at jmknoble.cx Wed Feb 14 04:11:35 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Tue, 13 Feb 2001 12:11:35 -0500 Subject: openssh bugs in snapshot for nextstep (fwd) In-Reply-To: ; from mouring@etoh.eviladmin.org on Mon, Feb 12, 2001 at 10:23:38AM -0600 References: Message-ID: <20010213121135.E1415@quipu.half.pint-stowp.cx> Circa 2001-Feb-12 10:23:38 -0600 dixit mouring at etoh.eviladmin.org: : I was sent this from Mark Miller. Should we be using MAXPATHLEN : instead of PATH_MAX in the upstream tree? Not all systems define : PATH_MAX. Isn't MAXPATHLEN the BSD name for PATH_MAX? I would suggest rather something like: #ifndef PATH_MAX # ifndef MAXPATHLEN # define MAXPATHLEN # endif # define PATH_MAX MAXPATHLEN #endif where is, if possible, guessed from the operating system, or at the very least chosen intelligently. -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From mouring at etoh.eviladmin.org Wed Feb 14 05:16:55 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 13 Feb 2001 12:16:55 -0600 (CST) Subject: openssh bugs in snapshot for nextstep (fwd) In-Reply-To: <20010213121135.E1415@quipu.half.pint-stowp.cx> Message-ID: On Tue, 13 Feb 2001, Jim Knoble wrote: > Circa 2001-Feb-12 10:23:38 -0600 dixit mouring at etoh.eviladmin.org: > > : I was sent this from Mark Miller. Should we be using MAXPATHLEN > : instead of PATH_MAX in the upstream tree? Not all systems define > : PATH_MAX. > > Isn't MAXPATHLEN the BSD name for PATH_MAX? I would suggest rather > something like: > > #ifndef PATH_MAX > # ifndef MAXPATHLEN > # define MAXPATHLEN > # endif > # define PATH_MAX MAXPATHLEN > #endif > > where is, if possible, guessed from the > operating system, or at the very least chosen intelligently. > > We are already doing this w/ MAXPATHLEN. It seems silly to do it for one occurance of PATH_MAX. Everywhere else in the upstream source we use MAXPATHLEN. - Ben From devon at admin2.gisnetworks.com Wed Feb 14 04:43:24 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Tue, 13 Feb 2001 09:43:24 -0800 Subject: cvs bulid breaks on slackware Message-ID: <006e01c095e4$773e2f20$1900a8c0@devn> cvs code from this morning (about 9am PST) breaks on slackware 7.1 w/ gcc 2.95.2.1 with an undefined reference to session_setup_sia in session.o. this seems to be the culprit here: #ifdef HAVE_OSF_SIA #else /* HAVE_OSF_SIA */ session_setup_sia(pw->pw_name, ttyname); since i have no idea what that's trying to accomplish (and seems to be a bit backwards to me from looking at the rest of the code dealing with sia), i figure i'll just let whoever wrote it sort it out. devon From jmknoble at jmknoble.cx Wed Feb 14 04:45:03 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Tue, 13 Feb 2001 12:45:03 -0500 Subject: openssh bugs in snapshot for nextstep (fwd) In-Reply-To: ; from mouring@etoh.eviladmin.org on Tue, Feb 13, 2001 at 12:16:55PM -0600 References: <20010213121135.E1415@quipu.half.pint-stowp.cx> Message-ID: <20010213124503.F1415@quipu.half.pint-stowp.cx> Circa 2001-Feb-13 12:16:55 -0600 dixit mouring at etoh.eviladmin.org: : We are already doing this w/ MAXPATHLEN. It seems silly to do it : for one occurance of PATH_MAX. Everywhere else in the upstream : source we use MAXPATHLEN. Ah. Then there ought not to be any additional problem doing as was originally suggested. I prefer consistency over cruft. -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From asgard at hellnet.cz Wed Feb 14 04:48:28 2001 From: asgard at hellnet.cz (Jan Samohyl) Date: Tue, 13 Feb 2001 18:48:28 +0100 (CET) Subject: problem compiling openssh-2.3.0p1 with openssl-0.9.6 Message-ID: Hello, I am using Redhat 6.1 on pentium. I have installed openssl-0.9.6 to /usr/local/ssl (default) because I wanted to install openssh. But openssh config script said "cannot find openssl libraries"; so I looked to the configure.in but the correct path was specified here. I also tried to move include files from /usr/local/ssl/include/openssl to /usr/local/ssl/include but it didn't worked anyway. What seems strange to me, in the configure.in there is additional -lcrypto option specified, but I don't have any such library on my system. Can anyone help ? Thank you Jan Samohyl From mouring at etoh.eviladmin.org Wed Feb 14 05:47:55 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 13 Feb 2001 12:47:55 -0600 (CST) Subject: cvs bulid breaks on slackware In-Reply-To: <006e01c095e4$773e2f20$1900a8c0@devn> Message-ID: On Tue, 13 Feb 2001, Devon Bleak wrote: > cvs code from this morning (about 9am PST) breaks on slackware 7.1 w/ gcc > 2.95.2.1 with an undefined reference to session_setup_sia in session.o. > > this seems to be the culprit here: > > #ifdef HAVE_OSF_SIA > #else /* HAVE_OSF_SIA */ > session_setup_sia(pw->pw_name, ttyname); > > since i have no idea what that's trying to accomplish (and seems to be a bit > backwards to me from looking at the rest of the code dealing with sia), i > figure i'll just let whoever wrote it sort it out. > This was reported a few moment ago by Kevin. [..snip of patch..] #ifdef HAVE_OSF_SIA -#else /* HAVE_OSF_SIA */ session_setup_sia(pw->pw_name, ttyname); +#else /* HAVE_OSF_SIA */ #ifdef HAVE_CYGWIN From jones at hpc.utexas.edu Wed Feb 14 05:05:21 2001 From: jones at hpc.utexas.edu (William L. Jones) Date: Tue, 13 Feb 2001 12:05:21 -0600 Subject: cvs bulid breaks on slackware In-Reply-To: <006e01c095e4$773e2f20$1900a8c0@devn> Message-ID: <4.2.0.58.20010213120432.01d793a0@127.0.0.1> It a problem when on irix systems too. At 09:43 AM 2/13/01 -0800, Devon Bleak wrote: >cvs code from this morning (about 9am PST) breaks on slackware 7.1 w/ gcc >2.95.2.1 with an undefined reference to session_setup_sia in session.o. > >this seems to be the culprit here: > >#ifdef HAVE_OSF_SIA >#else /* HAVE_OSF_SIA */ > session_setup_sia(pw->pw_name, ttyname); > >since i have no idea what that's trying to accomplish (and seems to be a bit >backwards to me from looking at the rest of the code dealing with sia), i >figure i'll just let whoever wrote it sort it out. > >devon From devon at admin2.gisnetworks.com Wed Feb 14 05:04:53 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Tue, 13 Feb 2001 10:04:53 -0800 Subject: cvs bulid breaks on slackware References: <006e01c095e4$773e2f20$1900a8c0@devn> Message-ID: <007801c095e7$7a80cfa0$1900a8c0@devn> before i do my shopping i'll just answer a few of the other questions: re: the fox machine. jordan sent an email to fox telling them about the larger apache process, but not recommending a memory upgrade, just saying "we'll keep a close watch on it to make sure that it doesn't become an issue." the memory IS going to become an issue. maybe not today, maybe not next week, but if fox does their job and promotes the movies and the websites with the movies, it's going to become an issue very quickly and pretty much without notice. which makes 'keeping a close watch on it' pretty pointless, especially considering the turnaround time it'd take to get a memory upgrade for the machine. IMO we need to hit 'em for it NOW, before it's even a baby issue. re: using the e450 as a db machine for miramax. the e450 is best known for its disk space and _amazing_ disk and network i/o. the network i/o isn't so much of a feature we'd want from a db machine as the disk space and i/o performance. large db's have to read large files every time someone wants some info from 'em. i think that the e450 will probably be better suited for fox as a dedicated db machine, but if miramax wants to pay for it as a dedicated db machine then i'm not going to complain. miramax could probably get away with a x86 machine with dual 800's, 2GB of ram, and some software raid5'd disk space (we'd need at least 5 disks in the machine: 2 mirrored OS drives, and 3+ 18GB raid5'd content drives, spread across at least 2 scsi ultra2 channels). the e450 would be total overkill for miramax to use as a dedicated db machine. as a shared machine, it just doesn't sound right, especially if we'd have to tell fox.com they're going on a shared db machine. if jordan hasn't told miramax they're going on a shared db machine, then there's really no damage done, as far as i can see. we just don't put anybody else on the e450 with 'em! we might also consider putting paramount's mailgun stuff on the e450. that nt machine just doesn't cut the mustard (even marcus agrees with me that we need to get that thing off of NT and onto something more stable and robust). i'll have some part no.s and specs on that ram for you shortly. devon ----- Original Message ----- From: "Devon Bleak" To: Sent: Tuesday, February 13, 2001 9:43 AM Subject: cvs bulid breaks on slackware > cvs code from this morning (about 9am PST) breaks on slackware 7.1 w/ gcc > 2.95.2.1 with an undefined reference to session_setup_sia in session.o. > > this seems to be the culprit here: > > #ifdef HAVE_OSF_SIA > #else /* HAVE_OSF_SIA */ > session_setup_sia(pw->pw_name, ttyname); > > since i have no idea what that's trying to accomplish (and seems to be a bit > backwards to me from looking at the rest of the code dealing with sia), i > figure i'll just let whoever wrote it sort it out. > > devon > > > From devon at admin2.gisnetworks.com Wed Feb 14 05:04:56 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Tue, 13 Feb 2001 10:04:56 -0800 Subject: cvs bulid breaks on slackware References: <006e01c095e4$773e2f20$1900a8c0@devn> Message-ID: <007901c095e7$7aeed3b0$1900a8c0@devn> before i do my shopping i'll just answer a few of the other questions: re: the fox machine. jordan sent an email to fox telling them about the larger apache process, but not recommending a memory upgrade, just saying "we'll keep a close watch on it to make sure that it doesn't become an issue." the memory IS going to become an issue. maybe not today, maybe not next week, but if fox does their job and promotes the movies and the websites with the movies, it's going to become an issue very quickly and pretty much without notice. which makes 'keeping a close watch on it' pretty pointless, especially considering the turnaround time it'd take to get a memory upgrade for the machine. IMO we need to hit 'em for it NOW, before it's even a baby issue. re: using the e450 as a db machine for miramax. the e450 is best known for its disk space and _amazing_ disk and network i/o. the network i/o isn't so much of a feature we'd want from a db machine as the disk space and i/o performance. large db's have to read large files every time someone wants some info from 'em. i think that the e450 will probably be better suited for fox as a dedicated db machine, but if miramax wants to pay for it as a dedicated db machine then i'm not going to complain. miramax could probably get away with a x86 machine with dual 800's, 2GB of ram, and some software raid5'd disk space (we'd need at least 5 disks in the machine: 2 mirrored OS drives, and 3+ 18GB raid5'd content drives, spread across at least 2 scsi ultra2 channels). the e450 would be total overkill for miramax to use as a dedicated db machine. as a shared machine, it just doesn't sound right, especially if we'd have to tell fox.com they're going on a shared db machine. if jordan hasn't told miramax they're going on a shared db machine, then there's really no damage done, as far as i can see. we just don't put anybody else on the e450 with 'em! we might also consider putting paramount's mailgun stuff on the e450. that nt machine just doesn't cut the mustard (even marcus agrees with me that we need to get that thing off of NT and onto something more stable and robust). i'll have some part no.s and specs on that ram for you shortly. devon ----- Original Message ----- From: "Devon Bleak" To: Sent: Tuesday, February 13, 2001 9:43 AM Subject: cvs bulid breaks on slackware > cvs code from this morning (about 9am PST) breaks on slackware 7.1 w/ gcc > 2.95.2.1 with an undefined reference to session_setup_sia in session.o. > > this seems to be the culprit here: > > #ifdef HAVE_OSF_SIA > #else /* HAVE_OSF_SIA */ > session_setup_sia(pw->pw_name, ttyname); > > since i have no idea what that's trying to accomplish (and seems to be a bit > backwards to me from looking at the rest of the code dealing with sia), i > figure i'll just let whoever wrote it sort it out. > > devon > > > From devon at admin2.gisnetworks.com Wed Feb 14 05:06:52 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Tue, 13 Feb 2001 10:06:52 -0800 Subject: cvs bulid breaks on slackware References: <006e01c095e4$773e2f20$1900a8c0@devn> <007801c095e7$7a80cfa0$1900a8c0@devn> Message-ID: <009901c095e7$be8cdae0$1900a8c0@devn> OOPS!!!!!!!!!!!! that _really_ went to the wrong people :(( my deepest apologies to all!!! devon ----- Original Message ----- From: "Devon Bleak" To: "Devon Bleak" ; Sent: Tuesday, February 13, 2001 10:04 AM Subject: Re: cvs bulid breaks on slackware > before i do my shopping i'll just answer a few of the other questions: > > re: the fox machine. jordan sent an email to fox telling them about the > larger apache process, but not recommending a memory upgrade, just saying > "we'll keep a close watch on it to make sure that it doesn't become an > issue." the memory IS going to become an issue. maybe not today, maybe not > next week, but if fox does their job and promotes the movies and the > websites with the movies, it's going to become an issue very quickly and > pretty much without notice. which makes 'keeping a close watch on it' > pretty pointless, especially considering the turnaround time it'd take to > get a memory upgrade for the machine. IMO we need to hit 'em for it NOW, > before it's even a baby issue. > > re: using the e450 as a db machine for miramax. the e450 is best known for > its disk space and _amazing_ disk and network i/o. the network i/o isn't so > much of a feature we'd want from a db machine as the disk space and i/o > performance. large db's have to read large files every time someone wants > some info from 'em. i think that the e450 will probably be better suited > for fox as a dedicated db machine, but if miramax wants to pay for it as a > dedicated db machine then i'm not going to complain. miramax could probably > get away with a x86 machine with dual 800's, 2GB of ram, and some software > raid5'd disk space (we'd need at least 5 disks in the machine: 2 mirrored OS > drives, and 3+ 18GB raid5'd content drives, spread across at least 2 scsi > ultra2 channels). the e450 would be total overkill for miramax to use as a > dedicated db machine. as a shared machine, it just doesn't sound right, > especially if we'd have to tell fox.com they're going on a shared db > machine. if jordan hasn't told miramax they're going on a shared db > machine, then there's really no damage done, as far as i can see. we just > don't put anybody else on the e450 with 'em! > > we might also consider putting paramount's mailgun stuff on the e450. that > nt machine just doesn't cut the mustard (even marcus agrees with me that we > need to get that thing off of NT and onto something more stable and robust). > > i'll have some part no.s and specs on that ram for you shortly. > > devon > > > > > ----- Original Message ----- > From: "Devon Bleak" > To: > Sent: Tuesday, February 13, 2001 9:43 AM > Subject: cvs bulid breaks on slackware > > > > cvs code from this morning (about 9am PST) breaks on slackware 7.1 w/ gcc > > 2.95.2.1 with an undefined reference to session_setup_sia in session.o. > > > > this seems to be the culprit here: > > > > #ifdef HAVE_OSF_SIA > > #else /* HAVE_OSF_SIA */ > > session_setup_sia(pw->pw_name, ttyname); > > > > since i have no idea what that's trying to accomplish (and seems to be a > bit > > backwards to me from looking at the rest of the code dealing with sia), i > > figure i'll just let whoever wrote it sort it out. > > > > devon > > > > > > > > > From cmadams at hiwaay.net Wed Feb 14 05:36:28 2001 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 13 Feb 2001 12:36:28 -0600 Subject: OSF_SIA bug in 2.3.0p1 In-Reply-To: ; from stevesk@sweden.hp.com on Tue, Feb 13, 2001 at 06:06:46PM +0100 References: Message-ID: <20010213123628.J29277@HiWAAY.net> Once upon a time, Kevin Steves said: > On Wed, 14 Feb 2001, Damien Miller wrote: > : Thanks - this makes the SIA support a great deal neater! > : > : Please check what I have committed to make sure I haven't broken your > : work :) > > one thing broke, and i think this is correct: > > Index: session.c > =================================================================== > RCS file: /var/cvs/openssh/session.c,v > retrieving revision 1.72 > diff -u -r1.72 session.c > --- session.c 2001/02/13 14:25:23 1.72 > +++ session.c 2001/02/13 17:05:46 > @@ -1046,8 +1046,8 @@ > switch, so we let login(1) to this for us. */ > if (!options.use_login) { > #ifdef HAVE_OSF_SIA > -#else /* HAVE_OSF_SIA */ > session_setup_sia(pw->pw_name, ttyname); > +#else /* HAVE_OSF_SIA */ > #ifdef HAVE_CYGWIN > if (is_winnt) { > #else Sorry, I got in too much of a hurry in updating my patch from 2.3.0p1 to the current CVS version. I only did partial testing, not full testing. Please apply the above patch, and I will do more thorough testing on this version and before submitting anything else. I plan to setup a Tru64 5.1 server here soon for testing as well. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From stevesk at sweden.hp.com Wed Feb 14 05:45:11 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Tue, 13 Feb 2001 19:45:11 +0100 (MET) Subject: OSF_SIA bug in 2.3.0p1 In-Reply-To: <20010213123628.J29277@HiWAAY.net> Message-ID: On Tue, 13 Feb 2001, Chris Adams wrote: : Please apply the above patch, and I will do more thorough testing on : this version and before submitting anything else. I plan to setup a : Tru64 5.1 server here soon for testing as well. done, thanks. From stevesk at sweden.hp.com Wed Feb 14 05:48:37 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Tue, 13 Feb 2001 19:48:37 +0100 (MET) Subject: add scp path to _PATH_STDPATH In-Reply-To: Message-ID: On Wed, 14 Feb 2001, Damien Miller wrote: : > what do you think about this patch to add the path to scp to : > _PATH_STDPATH? is there a better or cleaner way to do this? i'm hoping : > to ward off 'scp doesn't work' questions for the next release. : : I have been a little suspicious of this in the past, because I don't like : messing with PATH without being explicit. OTOH it would solve a lot of : support questions from people who don't read the FAQ. i've been wary as well, but i can't think of a reason not to add $prefix/bin to the default PATH. commit? better way to do this? From jt.kirk at earthling.net Tue Feb 13 06:30:25 2001 From: jt.kirk at earthling.net (Christian Fruth) Date: Mon, 12 Feb 2001 20:30:25 +0100 Subject: Little Bug under Win32 Message-ID: <001901c0952a$54c9a4c0$0a0a0a0a@wasserwerk> Hi I found a small Bug when compiling OpenSSH under Win32 using Cygwin. When you use SSH as a interactive Shell everthing looks normal but when you try to transfer binary data via SSH you will get only garbage. Example: ssh -l root -i ./.ssh/identity server1 cat /tmp/test.tar.gz > c:\test.tar.gz The problem is that stdout is opend as Text-File so every LF which comes from the SSH-Server (Unix) will be translated to CR LF on a Win32-Machine. The problem can be fixed by adding following line to the beginning of the clientloop-function: setmode(fileno(stdout), O_BINARY); Christian From ancelmo at siia.umich.mx Wed Feb 14 06:40:38 2001 From: ancelmo at siia.umich.mx (Ancelmo Rodriguez Parra) Date: Tue, 13 Feb 2001 13:40:38 -0600 (CST) Subject: problem installing openssh Message-ID: I am still trying to install openssh, I did like Kevin told me but it didn't work, I tried it like this: VER=openssh-2.3.0p1 SRC=/usr/src CFLAGS="+w1 +W 486,474 +O3 +ESlit +Optrs_strongly_typed \ > -I/opt/zlib/include/" LDFLAGS="-L/opt/zlib/lib/" # ./configure --prefix=/opt/${VER} \ > --sysconfdir=/etc/opt/openssh \ > --with-default-path="/usr/bin:/usr/sbin:/opt/${VER}/bin" \ > --with-ssl-dir=/opt/openssl/lib/ \ > --disable-suid-ssh \ > --without-pam However, I got the following error: checking for deflate in -lz... no configure: error: *** zlib missing - please install first *** I have already instaled zlib: # ls /opt/zlib/lib libz.a libz.sl and openssl, any help? -- \ | _ \ __ \ __| _ \ | __ _ \ _ \ ___ \ | | ( __/ | | | | ( | _/ _\_| _|\___|\___|_|_| _| _|\___/ "En los momento de crisis solo la imaginacion es mas importante que el conocimiento" - Albert Einstein - From rachit at ensim.com Wed Feb 14 06:47:46 2001 From: rachit at ensim.com (Rachit Siamwalla) Date: Tue, 13 Feb 2001 11:47:46 -0800 Subject: problem installing openssh References: Message-ID: <3A898F62.451CA8D3@ensim.com> you need to either export CFLAGS / LDFLAGS or run it in the same command as ./configure Ancelmo Rodriguez Parra wrote: > > I am still trying to install openssh, I did like Kevin told me but it > didn't work, I tried it like this: > > VER=openssh-2.3.0p1 > SRC=/usr/src > > CFLAGS="+w1 +W 486,474 +O3 +ESlit +Optrs_strongly_typed \ > > -I/opt/zlib/include/" > LDFLAGS="-L/opt/zlib/lib/" > > # ./configure --prefix=/opt/${VER} \ > > --sysconfdir=/etc/opt/openssh \ > > --with-default-path="/usr/bin:/usr/sbin:/opt/${VER}/bin" \ > > --with-ssl-dir=/opt/openssl/lib/ \ > > --disable-suid-ssh \ > > --without-pam > > However, I got the following error: > checking for deflate in -lz... no > configure: error: *** zlib missing - please install first *** > > I have already instaled zlib: > # ls /opt/zlib/lib > libz.a libz.sl > > and openssl, any help? > -- > \ | > _ \ __ \ __| _ \ | __ _ \ _ \ > ___ \ | | ( __/ | | | | ( | > _/ _\_| _|\___|\___|_|_| _| _|\___/ > > "En los momento de crisis solo la imaginacion es mas > importante que el conocimiento" > - Albert Einstein - From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Feb 14 07:13:53 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 13 Feb 2001 21:13:53 +0100 Subject: issue with EGD in openssh In-Reply-To: <200102131437.f1DEbXr19575@xerxes.courtesan.com>; from Todd.Miller@courtesan.com on Tue, Feb 13, 2001 at 07:37:33AM -0700 References: <200102131437.f1DEbXr19575@xerxes.courtesan.com> Message-ID: <20010213211353.A11946@serv01.aet.tu-cottbus.de> On Tue, Feb 13, 2001 at 07:37:33AM -0700, Todd C. Miller wrote: > 1) SIGPIPE is not ignored for the master listener daemon. I put > the signal() call early on since it needs to be before > get_random_bytes() is called but it could also be placed in the > EGD version of get_random_bytes(). For some reason, with prngd > I am getting SIGPIPE even though the prngd processes is not > dying. get_random_bytes() also needs to check for EPIPE and > reconnect to the daemon if it gets that. Hmm, I have not yet seen this behaviour. On what platform do you see this behaviour? 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 Todd.Miller at courtesan.com Wed Feb 14 07:18:27 2001 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Tue, 13 Feb 2001 13:18:27 -0700 Subject: issue with EGD in openssh In-Reply-To: Your message of "Tue, 13 Feb 2001 21:13:53 +0100." <20010213211353.A11946@serv01.aet.tu-cottbus.de> References: <200102131437.f1DEbXr19575@xerxes.courtesan.com> <20010213211353.A11946@serv01.aet.tu-cottbus.de> Message-ID: <200102132018.f1DKIRi01588@xerxes.courtesan.com> In message <20010213211353.A11946 at serv01.aet.tu-cottbus.de> so spake Lutz Jaenicke (Lutz.Jaenicke): > Hmm, I have not yet seen this behaviour. On what platform do you see > this behaviour? I see it on SunOS, Solaris, and Digital UNIX. - todd From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Feb 14 07:35:24 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 13 Feb 2001 21:35:24 +0100 Subject: issue with EGD in openssh In-Reply-To: <200102132018.f1DKIRi01588@xerxes.courtesan.com>; from Todd.Miller@courtesan.com on Tue, Feb 13, 2001 at 01:18:27PM -0700 References: <200102131437.f1DEbXr19575@xerxes.courtesan.com> <20010213211353.A11946@serv01.aet.tu-cottbus.de> <200102132018.f1DKIRi01588@xerxes.courtesan.com> Message-ID: <20010213213524.A12289@serv01.aet.tu-cottbus.de> On Tue, Feb 13, 2001 at 01:18:27PM -0700, Todd C. Miller wrote: > In message <20010213211353.A11946 at serv01.aet.tu-cottbus.de> > so spake Lutz Jaenicke (Lutz.Jaenicke): > > > Hmm, I have not yet seen this behaviour. On what platform do you see > > this behaviour? > > I see it on SunOS, Solaris, and Digital UNIX. I am somewhat surprised. If you see a SIGPIPE in OpenSSH, PRNGD must be closing the connection. This should not happen, since several queries can be made over the same connection. The only reason for PRNGD to close the connection is when PRNGD itself experiences a problem with the read/write operations... I have not seen this on HP-UX or Linux (the platforms I am using)... I have an idea to track it down and might prepare a test version, that I would like to send you a little bit later by private mail... 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 tim at multitalents.net Wed Feb 14 07:58:20 2001 From: tim at multitalents.net (Tim Rice) Date: Tue, 13 Feb 2001 12:58:20 -0800 (PST) Subject: SCO OS3 build broken (CVS 01/12/01) In-Reply-To: <20010213093825.A13859@greenie.muc.de> Message-ID: The solution was to put stdarg.h in AC_CHECK_HEADERS Z On Tue, 13 Feb 2001, Gert Doering wrote: > Hi, > > On Mon, Feb 12, 2001 at 02:55:34PM -0800, Tim Rice wrote: > > /usr/local/lib/gcc-lib/i486-unknown-sco3.2v4.2/2.7.2.1/include/varargs.h:88: war > > ning: `va_start' redefined > > /usr/local/lib/gcc-lib/i486-unknown-sco3.2v4.2/2.7.2.1/include/stdarg.h:72: warn > > ing: this is the location of the previous definition > > Looks like *both* varargs.h and stdarg.h are included, which is bad > because they are incompatible (and result in a different syntax for > functions with a varying number of arguments). > > gert > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Wed Feb 14 08:28:38 2001 From: tim at multitalents.net (Tim Rice) Date: Tue, 13 Feb 2001 13:28:38 -0800 (PST) Subject: add scp path to _PATH_STDPATH In-Reply-To: Message-ID: On Tue, 13 Feb 2001, Kevin Steves wrote: > On Wed, 14 Feb 2001, Damien Miller wrote: > : > what do you think about this patch to add the path to scp to > : > _PATH_STDPATH? is there a better or cleaner way to do this? i'm hoping > : > to ward off 'scp doesn't work' questions for the next release. > : > : I have been a little suspicious of this in the past, because I don't like > : messing with PATH without being explicit. OTOH it would solve a lot of > : support questions from people who don't read the FAQ. > > i've been wary as well, but i can't think of a reason not to add > $prefix/bin to the default PATH. > > commit? better way to do this? > I have a good patch in my 2.2.0p1 code that I can bring forward. I probably will not be able to work on it until the weekend. > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From robert.pouliot at bell.ca Tue Feb 13 06:43:52 2001 From: robert.pouliot at bell.ca (Robert Pouliot) Date: Mon, 12 Feb 2001 14:43:52 -0500 Subject: OpenSSH 2.3.0p1 bug with SCO UnixWare 7.1.0 Message-ID: <3A883CF8.D85DA000@bell.ca> I wasn't sur if you're the right person to send the bug reports to... SCO Unixware 7.1.0 (uname: UnixWare) and probably the 2.1.x versions (uname: UNIX_SV) requires also to have USE_PIPES defined. Also when compiling with tcpwrap it doesn't link due to the fact that UW doesn't have setenv() and libwrap have one built-in (duplicate symbols)... Also when using the SSH2 protocol to connect to a UnixWare 7.1.0 machine the connection hang after sending the password. See attached client side report. -------------- next part -------------- goldorak:~> ssh -2 -v applab02 SSH Version OpenSSH_2.1.1, protocol versions 1.5/2.0. Compiled with SSL (0x0090581f). debug: Reading configuration data /etc/ssh/ssh_config debug: Applying options for * debug: ssh_connect: getuid 475 geteuid 0 anon 0 debug: Connecting to APPLAB02 [142.120.93.251] port 22. debug: Seeding random number generator debug: Allocated local port 744. debug: Connection established. debug: Remote protocol version 1.5, remote software version OpenSSH_2.3.0p1 Protocol major versions differ: 2 vs. 1 debug: Calling cleanup 0x805bfe0(0x0) goldorak:~> ssh -2 -v appque01 SSH Version OpenSSH_2.1.1, protocol versions 1.5/2.0. Compiled with SSL (0x0090581f). debug: Reading configuration data /etc/ssh/ssh_config debug: Applying options for * debug: ssh_connect: getuid 475 geteuid 0 anon 0 debug: Connecting to SCYC2h.QC.BELL.CA [142.120.104.139] port 22. debug: Seeding random number generator debug: Allocated local port 652. debug: Connection established. debug: Remote protocol version 1.99, remote software version OpenSSH_2.1.1 Enabling compatibility mode for protocol 2.0 debug: Local version string SSH-2.0-OpenSSH_2.1.1 debug: send KEXINIT debug: done debug: wait KEXINIT debug: got kexinit: diffie-hellman-group1-sha1 debug: got kexinit: ssh-dss debug: got kexinit: 3des-cbc,blowfish-cbc,arcfour,cast128-cbc debug: got kexinit: 3des-cbc,blowfish-cbc,arcfour,cast128-cbc 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: zlib,none debug: got kexinit: zlib,none 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_KEXDH_INIT. debug: bits set: 500/1024 debug: Wait SSH2_MSG_KEXDH_REPLY. debug: Got SSH2_MSG_KEXDH_REPLY. debug: keytype ssh-dss debug: keytype ssh-dss debug: keytype ssh-dss debug: Host 'scyc2h.qc.bell.ca' is known and matches the DSA host key. debug: bits set: 499/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: key does not exist: /home/users/rpouliot/.ssh/id_dsa rpouliot at scyc2h.qc.bell.ca's password: debug: ssh-userauth2 successfull debug: no set_nonblock for tty fd 4 debug: no set_nonblock for tty fd 5 debug: no set_nonblock for tty fd 6 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: channel request 0: shell debug: client_set_session_ident: id 0 debug: callback done debug: channel 0: open confirm rwindow 0 rmax 32768 debug: channel 0: rcvd adjust 16384 From john at zlilo.com Tue Feb 13 14:55:44 2001 From: john at zlilo.com (john) Date: Mon, 12 Feb 2001 19:55:44 -0800 Subject: scp not found - OpenSSH 2.3.0p1 on slack 7 Message-ID: <20010212195544.L942@pain..cp.net> hi, let me start by saying ive tried everything i can think of with the --with-default-path configure flag. USER_PATH in config.h is correctly getting the value of this flag. i am installing to the default locations (user binaries to /usr/local/bin). ssh works fine, (after i did the LIBS=-lcrypt thing) but now, no matter what i do, i get "sh: scp: command not found" whenever i try to scp. i can think of nothing more to do...send help. here are the details: LIBS=-lcrypt ./configure --with-default-path=/usr/local/bin:/usr/bin:/bin OpenSSH configured has been configured with the following options. User binaries: /usr/local/bin User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /usr/local/etc Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/man/manX PID file: /var/run Random number collection: Device (/dev/urandom) Manpage format: man PAM support: no KerberosIV support: no AFS support: no S/KEY support: no TCP Wrappers support: no MD5 password support: no IP address in $DISPLAY hack: no Use IPv4 by default hack: no Translate v4 in v6 hack: yes Host: i686-pc-linux-gnu Compiler: /usr/local/egcs-1.1.2/bin/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 -lcrypt -lutil -lcrypto config.h:#define USER_PATH "/usr/local/bin:/usr/bin:/bin" -rwxr-xr-x 1 root root 20704 Feb 13 13:33 /usr/local/bin/scp -rws--x--x 1 root root 664308 Feb 13 13:33 /usr/local/bin/ssh -rwxr-xr-x 1 root root 613592 Feb 13 13:33 /usr/local/sbin/sshd /usr/local/sbin/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 xxx.xxx.xxx.xxx port 972 debug1: Client protocol version 1.5; client software version OpenSSH_2.3.0p1 debug1: no match: OpenSSH_2.3.0p1 debug1: Local version string SSH-1.99-OpenSSH_2.3.0p1 debug1: Sent 768 bit public key and 1024 bit host key. debug1: Encryption type: 3des debug1: Received session key; encryption turned on. debug1: Installing crc compensation attack detector. debug1: Attempting authentication for john. Failed rsa for john from xxx.xxx.xxx.xxx port 972 Accepted password for john from xxx.xxx.xxx.xxx port 972 debug1: session_new: init debug1: session_new: session 0 debug1: Exec command 'scp -f whoo.jpg' 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: End of interactive session; stdin 1, stdout (read 0, sent 0), stderr 194 bytes. debug1: Command exited with status 127. debug1: Received exit confirmation. Closing connection to xxx.xxx.xxx.xxx on the client side, i just get the scp not found error after i authenticate. i just went from ssh-1.2.27 to openssh-2.3.0p1 on a bunch of hosts...i'd hate to have to go back... -j From stevesk at sweden.hp.com Wed Feb 14 09:03:20 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Tue, 13 Feb 2001 23:03:20 +0100 (MET) Subject: add scp path to _PATH_STDPATH In-Reply-To: Message-ID: On Tue, 13 Feb 2001, Tim Rice wrote: : I have a good patch in my 2.2.0p1 code that I can bring forward. : I probably will not be able to work on it until the weekend. how was it different from the patch i posted? Index: Makefile.in =================================================================== RCS file: /var/cvs/openssh/Makefile.in,v retrieving revision 1.150 diff -u -r1.150 Makefile.in --- Makefile.in 2001/02/09 13:40:03 1.150 +++ Makefile.in 2001/02/12 14:47:51 @@ -17,11 +17,13 @@ SSH_PROGRAM=@bindir@/ssh ASKPASS_PROGRAM=$(libexecdir)/ssh-askpass SFTP_SERVER=$(libexecdir)/sftp-server +PATH_SCP=$(bindir) PATHS= -DETCDIR=\"$(sysconfdir)\" \ -D_PATH_SSH_PROGRAM=\"$(SSH_PROGRAM)\" \ -D_PATH_SSH_ASKPASS_DEFAULT=\"$(ASKPASS_PROGRAM)\" \ - -D_PATH_SFTP_SERVER=\"$(SFTP_SERVER)\" + -D_PATH_SFTP_SERVER=\"$(SFTP_SERVER)\" \ + -D_PATH_SCP=\"$(PATH_SCP)\" CC=@CC@ LD=@LD@ Index: defines.h =================================================================== RCS file: /var/cvs/openssh/defines.h,v retrieving revision 1.54 diff -u -r1.54 defines.h --- defines.h 2001/02/09 11:55:17 1.54 +++ defines.h 2001/02/12 14:47:53 @@ -267,7 +267,7 @@ #endif #ifndef _PATH_STDPATH -# define _PATH_STDPATH "/usr/bin:/bin:/usr/sbin:/sbin" +# define _PATH_STDPATH "/usr/bin:/bin:/usr/sbin:/sbin" ":" _PATH_SCP #endif #ifndef _PATH_DEVNULL From ruf at tik.ee.ethz.ch Wed Feb 14 09:09:29 2001 From: ruf at tik.ee.ethz.ch (Lukas Ruf) Date: Tue, 13 Feb 2001 23:09:29 +0100 Subject: scp not found - OpenSSH 2.3.0p1 on slack 7 In-Reply-To: <20010212195544.L942@pain..cp.net>; from john@zlilo.com on Mon, Feb 12, 2001 at 19:55:44 -0800 References: <20010212195544.L942@pain..cp.net> Message-ID: <20010213230929.A15492@tik.ee.ethz.ch> what is reported when you run ssh echo \$PATH ? --lpr On Mon, 12 Feb 2001, john wrote: > hi, > let me start by saying ive tried everything i can think of with the --with-default-path configure flag. > > USER_PATH in config.h is correctly getting the value of this flag. > > i am installing to the default locations (user binaries to /usr/local/bin). > > ssh works fine, (after i did the LIBS=-lcrypt thing) but now, no matter what i do, i get "sh: scp: command not found" whenever i try to scp. i can think of nothing more to do...send help. > > here are the details: > > LIBS=-lcrypt ./configure --with-default-path=/usr/local/bin:/usr/bin:/bin > > OpenSSH configured has been configured with the following options. > User binaries: /usr/local/bin > User binaries: /usr/local/bin > System binaries: /usr/local/sbin > Configuration files: /usr/local/etc > Askpass program: /usr/local/libexec/ssh-askpass > Manual pages: /usr/local/man/manX > PID file: /var/run > Random number collection: Device (/dev/urandom) > Manpage format: man > PAM support: no > KerberosIV support: no > AFS support: no > S/KEY support: no > TCP Wrappers support: no > MD5 password support: no > IP address in $DISPLAY hack: no > Use IPv4 by default hack: no > Translate v4 in v6 hack: yes > > Host: i686-pc-linux-gnu > Compiler: /usr/local/egcs-1.1.2/bin/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 -lcrypt -lutil -lcrypto > > config.h:#define USER_PATH "/usr/local/bin:/usr/bin:/bin" > > -rwxr-xr-x 1 root root 20704 Feb 13 13:33 /usr/local/bin/scp > -rws--x--x 1 root root 664308 Feb 13 13:33 /usr/local/bin/ssh > -rwxr-xr-x 1 root root 613592 Feb 13 13:33 /usr/local/sbin/sshd > > /usr/local/sbin/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 xxx.xxx.xxx.xxx port 972 > debug1: Client protocol version 1.5; client software version OpenSSH_2.3.0p1 > debug1: no match: OpenSSH_2.3.0p1 > debug1: Local version string SSH-1.99-OpenSSH_2.3.0p1 > debug1: Sent 768 bit public key and 1024 bit host key. > debug1: Encryption type: 3des > debug1: Received session key; encryption turned on. > debug1: Installing crc compensation attack detector. > debug1: Attempting authentication for john. > Failed rsa for john from xxx.xxx.xxx.xxx port 972 > Accepted password for john from xxx.xxx.xxx.xxx port 972 > debug1: session_new: init > debug1: session_new: session 0 > debug1: Exec command 'scp -f whoo.jpg' > 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: End of interactive session; stdin 1, stdout (read 0, sent 0), stderr 194 bytes. > debug1: Command exited with status 127. > debug1: Received exit confirmation. > Closing connection to xxx.xxx.xxx.xxx > > on the client side, i just get the scp not found error after i authenticate. > i just went from ssh-1.2.27 to openssh-2.3.0p1 on a bunch of hosts...i'd hate to have to go back... > -j From djm at mindrot.org Wed Feb 14 09:24:45 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Feb 2001 09:24:45 +1100 (EST) Subject: add scp path to _PATH_STDPATH In-Reply-To: Message-ID: On Tue, 13 Feb 2001, Kevin Steves wrote: > i've been wary as well, but i can't think of a reason not to add > $prefix/bin to the default PATH. > > commit? better way to do this? OK, but please add a --disable- option to prevent it. I wonder if it would be possible to check whether SCP_PATH is already in PATH and, if so, not add it again (just to be tidy). -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From vinschen at redhat.com Wed Feb 14 09:28:03 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 13 Feb 2001 23:28:03 +0100 Subject: Little Bug under Win32 In-Reply-To: <001901c0952a$54c9a4c0$0a0a0a0a@wasserwerk>; from jt.kirk@earthling.net on Mon, Feb 12, 2001 at 08:30:25PM +0100 References: <001901c0952a$54c9a4c0$0a0a0a0a@wasserwerk> Message-ID: <20010213232802.B17568@cygbert.vinschen.de> On Mon, Feb 12, 2001 at 08:30:25PM +0100, Christian Fruth wrote: > Hi > > I found a small Bug when compiling OpenSSH under Win32 using Cygwin. > > When you use SSH as a interactive Shell everthing looks normal but when > you try to transfer binary data via SSH you will get only garbage. > > Example: > ssh -l root -i ./.ssh/identity server1 cat /tmp/test.tar.gz > > c:\test.tar.gz > > The problem is that stdout is opend as Text-File so every LF which comes > from the SSH-Server (Unix) will be translated to CR LF > on a Win32-Machine. > > The problem can be fixed by adding following line to the beginning of > the clientloop-function: > > setmode(fileno(stdout), O_BINARY); Sorry, no. That's incorrect. You are moving a typical and heavily discussed problem of stdout filemode in Cygwin to ssh. Ssh can't and must not decide about the mode of stdout. The same problem as it's for `cat'. The mode of stdout is dependent of the mode of the underlying mount point of the file written to (if any). You will find this discussed in detail in the Cygwin mailing list archive. If you want to be sure to copy binary use scp. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From djm at mindrot.org Wed Feb 14 09:51:42 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Feb 2001 09:51:42 +1100 (EST) Subject: ZLIB Problems In-Reply-To: <001701c095bb$7d3b5fc0$4318989e@molcos> Message-ID: On Tue, 13 Feb 2001, Shawn Phillips wrote: > Hi, > > I am attempting to compile SSH under Sequent Dynix/ptx 4.4.7, > > After compiling and installing ZLIB to /usr/local/include and > /usr/local/lib the ./configure command returns that ZLIB is not > installed. Have a look at the end of config.log - it is likely that there is some other error. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Wed Feb 14 09:54:46 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Feb 2001 09:54:46 +1100 (EST) Subject: problem compiling openssh-2.3.0p1 with openssl-0.9.6 In-Reply-To: Message-ID: On Tue, 13 Feb 2001, Jan Samohyl wrote: > Hello, > I am using Redhat 6.1 on pentium. I have installed openssl-0.9.6 to > /usr/local/ssl (default) because I wanted to install openssh. But openssh > config script said "cannot find openssl libraries"; so I looked to the > configure.in but the correct path was specified here. I also tried to move > include files from /usr/local/ssl/include/openssl to > /usr/local/ssl/include but it didn't worked anyway. What seems strange to > me, in the configure.in there is additional -lcrypto option specified, but Have a look at config.log, there should be a more detailed error message there. -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Wed Feb 14 09:57:17 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Feb 2001 09:57:17 +1100 (EST) Subject: problem installing openssh In-Reply-To: Message-ID: On Tue, 13 Feb 2001, Ancelmo Rodriguez Parra wrote: > However, I got the following error: > checking for deflate in -lz... no > configure: error: *** zlib missing - please install first *** Please look in config.log, it usually has more detailed error messages. We really must fix these error to tell people to do that. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From Todd.Miller at courtesan.com Wed Feb 14 10:16:43 2001 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Tue, 13 Feb 2001 16:16:43 -0700 Subject: issue with EGD in openssh In-Reply-To: Your message of "Tue, 13 Feb 2001 21:35:24 +0100." <20010213213524.A12289@serv01.aet.tu-cottbus.de> References: <200102131437.f1DEbXr19575@xerxes.courtesan.com> <20010213211353.A11946@serv01.aet.tu-cottbus.de> <200102132018.f1DKIRi01588@xerxes.courtesan.com> <20010213213524.A12289@serv01.aet.tu-cottbus.de> Message-ID: <200102132316.f1DNGiA20467@xerxes.courtesan.com> Yes, I was surprised too. I have not seen this happen on HP-UX either. However, this is still something openssh needs to deal with as it should be possible to restart the entropy daemon w/o having sshd die. - todd From tim at multitalents.net Wed Feb 14 12:06:35 2001 From: tim at multitalents.net (Tim Rice) Date: Tue, 13 Feb 2001 17:06:35 -0800 (PST) Subject: add scp path to _PATH_STDPATH In-Reply-To: Message-ID: On Tue, 13 Feb 2001, Kevin Steves wrote: > On Tue, 13 Feb 2001, Tim Rice wrote: > : I have a good patch in my 2.2.0p1 code that I can bring forward. > : I probably will not be able to work on it until the weekend. > > how was it different from the patch i posted? > [patch snipped] > It sets the default patch to be same as rshd (on platforms I know) It only adds to the PATH if the path to scp is not in PATH. And it displays what the PATH is going to be at the end of configure. And it works correctly if you chang any of these. --prefix=PREFIX install architecture-independent files in PREFIX --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX --bindir=DIR user executables in DIR [EPREFIX/bin] --with-default-path=PATH Specify default $PATH environment for server -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Wed Feb 14 12:06:46 2001 From: tim at multitalents.net (Tim Rice) Date: Tue, 13 Feb 2001 17:06:46 -0800 (PST) Subject: OpenSSH 2.3.0p1 bug with SCO UnixWare 7.1.0 In-Reply-To: <3A883CF8.D85DA000@bell.ca> Message-ID: On Mon, 12 Feb 2001, Robert Pouliot wrote: > I wasn't sur if you're the right person to send the bug reports to... > > SCO Unixware 7.1.0 (uname: UnixWare) and probably the 2.1.x versions > (uname: UNIX_SV) > requires also to have USE_PIPES defined. This has been reported already. > > Also when compiling with tcpwrap it doesn't link due to the fact that UW > doesn't have setenv() and libwrap have one built-in (duplicate > symbols)... I just sent in a configure.in reorder patch that solves this. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Wed Feb 14 12:06:58 2001 From: tim at multitalents.net (Tim Rice) Date: Tue, 13 Feb 2001 17:06:58 -0800 (PST) Subject: add scp path to _PATH_STDPATH In-Reply-To: Message-ID: On Wed, 14 Feb 2001, Damien Miller wrote: > On Tue, 13 Feb 2001, Kevin Steves wrote: > > > i've been wary as well, but i can't think of a reason not to add > > $prefix/bin to the default PATH. > > > > commit? better way to do this? > > OK, but please add a --disable- option to prevent it. I wonder if it would > be possible to check whether SCP_PATH is already in PATH and, if so, > not add it again (just to be tidy). That's what my patch does. > > -d > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From ancelmo at siia.umich.mx Wed Feb 14 12:33:35 2001 From: ancelmo at siia.umich.mx (Ancelmo Rodriguez Parra) Date: Tue, 13 Feb 2001 19:33:35 -0600 (CST) Subject: problem installing openssh In-Reply-To: Message-ID: I finally compiled ssh!! the problem was that linker couldn't load libz.a, so the solution was to do: # cp -rp /usr/local/include/* /usr/include/ # cp -rp /usr/local/lib/* /usr/lib/ thanks to all of you. > On Tue, 13 Feb 2001, Ancelmo Rodriguez Parra wrote: > > > > However, I got the following error: > > checking for deflate in -lz... no > > configure: error: *** zlib missing - please install first *** > > Please look in config.log, it usually has more detailed error messages. > > We really must fix these error to tell people to do that. > > -d > > -- \ | _ \ __ \ __| _ \ | __ _ \ _ \ ___ \ | | ( __/ | | | | ( | _/ _\_| _|\___|\___|_|_| _| _|\___/ "En los momento de crisis solo la imaginacion es mas importante que el conocimiento" - Albert Einstein - From ylo at ssh.com Wed Feb 14 12:36:19 2001 From: ylo at ssh.com (Tatu Ylonen) Date: Wed, 14 Feb 2001 03:36:19 +0200 Subject: SSH trademarks and the OpenSSH product name Message-ID: <200102140136.DAA03479@mystery.acr.fi> Friends, Sorry to write this to a developer mailing list. I have already approached some OpenSSH/OpenBSD core members on this, including Markus Friedl, Theo de Raadt, and Niels Provos, but they have chosen not to bring the issue up on the mailing list. I am not aware of any other forum where I would reach the OpenSSH developers, so I will post this here. As you know, I have been using the SSH trademark as the brand name of my SSH (Secure Shell) secure remote login product and related technology ever since I released the first version in July 1995. I have explicitly claimed them as trademarks at least from early 1996. In December 1995, I started SSH Communications Security Corp to support and further develop the SSH (Secure Shell) secure remote login products and to develop other network security solutions (especially in the IPSEC and PKI areas). SSH Communications Security Corp is now publicly listed in the Helsinki Exchange, employs 180 people working in various areas of cryptographic network security, and our products are distributed directly and indirectly by hundreds of licensed distributors and OEMs worldwide using the SSH brand name. There are several million users of products that we have licensed under the SSH brand. To protect the SSH trademark I (or SSH Communications Security Corp, to be more accurate) registered the SSH mark in the United States and European Union in 1996 (others pending). We also have a registration pending on the Secure Shell mark. The SSH mark is a significant asset of SSH Communications Security and the company strives to protect its valuable rights in the SSH? name and mark. SSH Communications Security has made a substantial investment in time and money in its SSH mark, such that end users have come to recognize that the mark represents SSH Communications Security as the source of the high quality products offered under the mark. This resulting goodwill is of vital importance to SSH Communications Security Corp. We have also been distributing free versions of SSH Secure Shell under the SSH brand since 1995. The latest version, ssh-2.4.0, is free for any use on the Linux, FreeBSD, NetBSD, and OpenBSD operating systems, as well as for universities and charity organizations, and for personal hobby/recreational use by individuals. We have been including trademark markings in SSH distributions, on the www.ssh.fi, www.ssh.com, and www.ssh.org web sites, IETF standards documents, license/readme files and product packaging long before the OpenSSH group was formed. Accordingly, we would like you to understand the importance of the SSH mark to us, and, by necessity, our need to protect the trademark against the unauthorized use by others. Many of you are (and the initiators of the OpenSSH group certainly should have been) well aware of the existence of the trademark. Some of the OpenBSD/OpenSSH developers/sponsors have also received a formal legal notice about the infringement earlier. I have started receiving a significant amount of e-mail where people are confusing OpenSSH as either my product or my company's product, or are confusing or misrepresenting the meaning of the SSH and Secure Shell trademarks. I have also been informed of several recent press articles and outright advertisements that are further confusing the origin and meaning of the trademark. The confusion is made even worse by the fact that OpenSSH is also a derivative of my original SSH Secure Shell product, and it still looks very much like my product (without my approval for any of it, by the way). The old SSH1 protocol and implementation are known to have fundamental security problems, some of which have been described in recent CERT vulnerability notices and various conference papers. OpenSSH is doing a disservice to the whole Internet security community by lengthing the life cycle of the fundamentally broken SSH1 protocols. The use of the SSH trademark by OpenSSH is in violation of my company's intellectual property rights, and is causing me, my company, our licensees, and our products considerable financial and other damage. I would thus like to ask you to change the name OpenSSH to something else that doesn't infringe the SSH or Secure Shell trademarks, basically to something that is clearly different and doesn't cause confusion. Also, please understand that I have nothing against independent implementations of the SSH Secure Shell protocols. I started and fully support the IETF SECSH working group in its standardization efforts, and we have offered certain licenses to use the SSH mark to refer to the protocol and to indicate that a product complies with the standard. Anyone can implement the IETF SECSH working group standard without requiring any special licenses from us. It is the use of the "SSH" and "Secure Shell" trademarks in product names or in otherwise confusing manner that we wish to prevent. Please also try to look at this from my viewpoint. I developed SSH (Secure Shell), started using the name for it, established a company using the name, all of our products are marketed using the SSH brand, and we have created a fairly widely known global brand using the name. Unauthorized use of the SSH mark by the OpenSSH group is threathening to destroy everything I have built on it during the last several years. I want to be able to continue using the SSH and Secure Shell names as identifying my own and my company's products and technologies, which the unlawful use of the SSH name by OpenSSH is making very hard. Therefore, I am asking you to please choose another name for the OpenSSH product and stop using the SSH mark in your product name and in otherwise confusing manner. Regards, Tatu Ylonen SSH Communications Security http://www.ssh.com/ SSH IPSEC Toolkit http://www.ipsec.com/ SSH(R) Secure Shell(TM) http://www.ssh.com/products/ssh From mhw at wittsend.com Wed Feb 14 13:13:06 2001 From: mhw at wittsend.com (Michael H. Warfield) Date: Tue, 13 Feb 2001 21:13:06 -0500 Subject: SSH trademarks and the OpenSSH product name In-Reply-To: <200102140136.DAA03479@mystery.acr.fi>; from ylo@ssh.com on Wed, Feb 14, 2001 at 03:36:19AM +0200 References: <200102140136.DAA03479@mystery.acr.fi> Message-ID: <20010213211306.A2145@alcove.wittsend.com> Tatu, On Wed, Feb 14, 2001 at 03:36:19AM +0200, Tatu Ylonen wrote: > Friends, > Sorry to write this to a developer mailing list. I have already > approached some OpenSSH/OpenBSD core members on this, including Markus > Friedl, Theo de Raadt, and Niels Provos, but they have chosen not to > bring the issue up on the mailing list. I am not aware of any other > forum where I would reach the OpenSSH developers, so I will post this > here. [...] I understand what you have written. I wonder if you understand what you have just done. You've probably done yourself far more damage than any since the ssh 2.x licensing debacle. Probably far more damage than any security attack. I was a contributor back in the early days of ssh. I can now say that, what ever name it is named, I will support the OpenSSH project and recommend, both personally and profesionally against the use of the commercial version of SSH in any environment. I find that the use of trademarks in this maner to be intellectually and ethically offensive in a maner which detracts severely from my confidence in your product. Security, apparently, now plays second fiddle at SSH Communications behind marketing and bully business practices. If that's the effect you want to achieve, I hope you enjoy the consequences. I hope that you have informed the IETF of your efforts to trademark SSH and Secure Shell and have given them time to remove any and all reference from the RFCs. With luck, they'll change the RFC's sufficiently (to protect your trade mark) to render your version incompatible with the standard. You should also now notify IANA of your actions to have their allocation of port 22 to ssh to be revoked. After all, we can't have your trademarked sullied by association with other inferior products through the use of a common port bearing your trademarked name. Or are you also going to demand that they (OpenSSH, psst, lsh, and IETF) change port numbers as well since port 22 would link their products to your trademark? After all, your trademark is branded into almost every /etc/services file in many flavors of Unix/Linux/BSD. I suppose you will now require that they change the name of the binaries as well. No more running ssh to connect to other systems or sshd to serve those connections. Well, we've seen what happened when RSA tried that. When RC4 became known and they tried to claim IP rights over the name. The public implimentation became arcfour (for Aledged RC4). Based on that premiss, I propose the term assh and asshd. That way all of us will be reminded of the people who originated ssh. Our appreciation for that inventiveness and innovation. Our regrets for the ill turn of affairs. It will not be forgotten. Regretable and sad. Unfortunately, I suppose, also inevitable. > Regards, > Tatu Ylonen > SSH Communications Security http://www.ssh.com/ > SSH IPSEC Toolkit http://www.ipsec.com/ > SSH(R) Secure Shell(TM) http://www.ssh.com/products/ssh Mike -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From dbt at meat.net Wed Feb 14 13:30:35 2001 From: dbt at meat.net (David Terrell) Date: Tue, 13 Feb 2001 18:30:35 -0800 Subject: SSH trademarks and the OpenSSH product name In-Reply-To: <200102140136.DAA03479@mystery.acr.fi>; from ylo@ssh.com on Wed, Feb 14, 2001 at 03:36:19AM +0200 References: <200102140136.DAA03479@mystery.acr.fi> Message-ID: <20010213183034.A14078@pianosa.catch22.org> On Wed, Feb 14, 2001 at 03:36:19AM +0200, Tatu Ylonen wrote: > Friends, > > Sorry to write this to a developer mailing list. I have already > approached some OpenSSH/OpenBSD core members on this, including Markus > Friedl, Theo de Raadt, and Niels Provos, but they have chosen not to > bring the issue up on the mailing list. I am not aware of any other > forum where I would reach the OpenSSH developers, so I will post this > here. > > As you know, I have been using the SSH trademark as the brand name of > my SSH (Secure Shell) secure remote login product and related > technology ever since I released the first version in July 1995. I > have explicitly claimed them as trademarks at least from early 1996. Tatu - I'm sure nobody bears your company or its employees any ill will. We can understand wanting to protect your investment of time, money, and will into your company. However, I think you're at a decision point with your trademark of the SSH name. Either it's a protocol and it's a standard name, or it's your company's name and it's proprietary. I think that asking a protocol to go to internet draft standard status and THEN, after last call, calling reserved words of that protocol proprietary is unfair and dishonest. Is it 'ok' to use the three letters 'SSH' in the initial version exchange "SSH-1.5-OpenSOMETHINGELSE_2.3.2"? Should we even have to think about it? -- David Terrell | If a crypto algorithm is cracked in a forest Nebcorp Prime Minister | and a tree falls on a mime, does microsoft dbt at meat.net | need to publish an advisory on it? http://wwn.nebcorp.com/ From stevev at darkwing.uoregon.edu Wed Feb 14 13:40:16 2001 From: stevev at darkwing.uoregon.edu (Steve VanDevender) Date: Tue, 13 Feb 2001 18:40:16 -0800 Subject: SSH trademarks and the OpenSSH product name In-Reply-To: <200102140136.DAA03479@mystery.acr.fi> References: <200102140136.DAA03479@mystery.acr.fi> Message-ID: <14985.61456.851610.690165@darkwing.uoregon.edu> Tatu Ylonen writes: > The confusion is made even worse by the fact that OpenSSH is also a > derivative of my original SSH Secure Shell product, and it still looks > very much like my product (without my approval for any of it, by the > way). The old SSH1 protocol and implementation are known to have > fundamental security problems, some of which have been described in > recent CERT vulnerability notices and various conference papers. > OpenSSH is doing a disservice to the whole Internet security community > by lengthing the life cycle of the fundamentally broken SSH1 > protocols. OpenSSH makes it quite clear that it's a derivative of your code by including your original READMEs and license information, as indicated by this excerpt from the LICENCE file distributed with it: * Copyright (c) 1995 Tatu Ylonen , Espoo, Finland * All rights reserved * * As far as I am concerned, the code I have written for this software * can be used freely for any purpose. Any derived versions of this * software must be clearly marked as such, and if the derived work is * incompatible with the protocol description in the RFC file, it must be * called by a name other than "ssh" or "Secure Shell". Apparently you've forgotten the original licensing terms under which you distributed SSH, and the rights you specifically granted to those who would derive works from it. It's too late for you to call those back now. While I definitely agree that people should be encouraged to migrate away from SSH 1, even your company continues to distribute an SSH 1 client and server and continues to allow for fallback support in your SSH 2 server. OpenSSH is no more promoting the "fundamentally broken" SSH 1 protocol than your company is. From mouring at etoh.eviladmin.org Wed Feb 14 14:42:34 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 13 Feb 2001 21:42:34 -0600 (CST) Subject: SSH trademarks and the OpenSSH product name In-Reply-To: <200102140136.DAA03479@mystery.acr.fi> Message-ID: On Wed, 14 Feb 2001, Tatu Ylonen wrote: > Friends, > [..] > The confusion is made even worse by the fact that OpenSSH is also a > derivative of my original SSH Secure Shell product, and it still looks > very much like my product (without my approval for any of it, by the > way). The old SSH1 protocol and implementation are known to have [..] No disrespect, but I must point out a few things. 1) SSH Protocol 1 exists because people use it. There is a larger SSH v1 user base then v2 at this point. To just 'drop' a protocol without building a migration path is in extremely poor taste (it's something I expect from Microsoft or Intel). 2) The OpenSSH/OSSH source base came from a version of SSH that was under pure BSD licensing. And thus does not require your blessing nor "approval" to use. That is the whole point behind BSD licensing. > Also, please understand that I have nothing against independent > implementations of the SSH Secure Shell protocols. I started and > fully support the IETF SECSH working group in its standardization > efforts, and we have offered certain licenses to use the SSH mark to > refer to the protocol and to indicate that a product complies with the > standard. Anyone can implement the IETF SECSH working group standard > without requiring any special licenses from us. It is the use of the > "SSH" and "Secure Shell" trademarks in product names or in otherwise > confusing manner that we wish to prevent. > I suggest you go through your IEFT draft and change all 'SSH' references to 'SECSH'. Because as it stands it stats that 'SSH' is the protocol name. Which is confusing and also weakens your position. [..] > Therefore, I am asking you to please choose another name for the > OpenSSH product and stop using the SSH mark in your product name and > in otherwise confusing manner. > I urge you to consider what you are currently doing. This is currently still contained. This will be a very bad PR move if this continues, and it would not suprise me if this causes a backlash of hate from the Internet Community as a whole. - Ben From drosih at rpi.edu Wed Feb 14 13:52:05 2001 From: drosih at rpi.edu (Garance A Drosihn) Date: Tue, 13 Feb 2001 21:52:05 -0500 Subject: SSH trademarks and the OpenSSH product name In-Reply-To: <200102140136.DAA03479@mystery.acr.fi> References: <200102140136.DAA03479@mystery.acr.fi> Message-ID: At 3:36 AM +0200 2/14/01, Tatu Ylonen wrote: >I would thus like to ask you to change the name OpenSSH >to something else that doesn't infringe the SSH or Secure >Shell trademarks, basically to something that is clearly >different and doesn't cause confusion. > >Also, please understand that I have nothing against independent >implementations of the SSH Secure Shell protocols. I started and >fully support the IETF SECSH working group in its standardization >efforts, [...]. It is the use of the "SSH" and "Secure Shell" >trademarks in product names or in otherwise confusing manner >that we wish to prevent. Does this just effect the name of the product, such as OpenSSH or FreSSH (assuming they capitalize it that way), or does it go down to the command names to? Ie, are you saying that the command typed at the unix prompt needs to be something other than 'ssh', and the daemon should not be called 'sshd'? [disclaimer: I'm not an openssh developer, I am just on this list to keep track of it's development] -- Garance Alistair Drosehn = gad at eclipse.acs.rpi.edu Senior Systems Programmer or gad at freebsd.org Rensselaer Polytechnic Institute or drosih at rpi.edu From ylo at ssh.com Wed Feb 14 14:09:47 2001 From: ylo at ssh.com (Tatu Ylonen) Date: Wed, 14 Feb 2001 05:09:47 +0200 (EET) Subject: SSH trademarks and the OpenSSH product name In-Reply-To: <20010213183034.A14078@pianosa.catch22.org> Message-ID: > However, I think you're at a decision point with your trademark of > the SSH name. Either it's a protocol and it's a standard name, or > it's your company's name and it's proprietary. I think that asking > a protocol to go to internet draft standard status and THEN, after > last call, calling reserved words of that protocol proprietary is > unfair and dishonest. Is it 'ok' to use the three letters 'SSH' > in the initial version exchange "SSH-1.5-OpenSOMETHINGELSE_2.3.2"? > Should we even have to think about it? I have proposed to the IETF working group that the name of the standard be changed. It is better if the standard name is something neutral. The floor is open for proposals :-) There is no problem with the bits on the wire. If needed, SSH Communications Security Corp is willing to grant to the IETF an explicit trademark license that allows the bits of the IETF protocol to remain unchanged without any implementor needing separate licensing. The trademark issue has been plain and clear indicated in the "Intellectual Property Issues" section of the IETF drafts for a long time. It has also been discussed with the area directors and working group chair on several occasions over the years. Tatu SSH Communications Security http://www.ssh.com/ SSH IPSEC Toolkit http://www.ipsec.com/ SSH(R) Secure Shell(TM) http://www.ssh.com/products/ssh From kuro at soum.co.jp Wed Feb 14 14:14:08 2001 From: kuro at soum.co.jp (Seiji Kurosawa) Date: Wed, 14 Feb 2001 12:14:08 +0900 Subject: environmental variables MAIL on solaris Message-ID: <20010214121408O.kuro@soum.co.jp> Hello. I found a Bug in openssh-2.3.0p1. OS is solaris 2.6. When I login to sshd of openssh-2.3.0p1 , I found double slashed MAIL environmental variables like bellow. % ssh -V SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090600f). % env |grep MAIL MAIL=/var/mail//s-kurosa When using emacs20 RMAIL, RMAIL can not get mail from spool Directory. Other openssh version set normal MAIL environmental variables. % ssh -V SSH Version OpenSSH_2.2.0 NetBSD_Secure_Shell-20001003, protocol versions 1.5/2.0. Compiled with OpenSSL (0x0090581f). % env | grep MAIL MAIL=/var/mail/s-kurosa Regards. -------------- Seiji Kurosawa From djm at mindrot.org Wed Feb 14 17:08:44 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Feb 2001 17:08:44 +1100 (EST) Subject: SSH trademarks and the OpenSSH product name In-Reply-To: <200102140136.DAA03479@mystery.acr.fi> Message-ID: On Wed, 14 Feb 2001, Tatu Ylonen wrote: > Friends, > > Sorry to write this to a developer mailing list. I have already > approached some OpenSSH/OpenBSD core members on this, including Markus > Friedl, Theo de Raadt, and Niels Provos, but they have chosen not to > bring the issue up on the mailing list. I am not aware of any other > forum where I would reach the OpenSSH developers, so I will post this > here. As I understand it, the OpenBSD team is still waiting on a letter from your lawyer. > As you know, I have been using the SSH trademark as the brand name of > my SSH (Secure Shell) secure remote login product and related > technology ever since I released the first version in July 1995. I > have explicitly claimed them as trademarks at least from early 1996. To my knowledge you have not contacted any of the other implementors of SSH clients and servers who use 'SSH' in the name of there product (there are several). Why are you 1) making an issue now, when there have been SSH implementations using 'SSH' in their names for several years? and 2) targeting the OpenSSH team only? > In December 1995, I started SSH Communications Security Corp to > support and further develop the SSH (Secure Shell) secure remote login > products and to develop other network security solutions (especially > in the IPSEC and PKI areas). SSH Communications Security Corp is now > publicly listed in the Helsinki Exchange, employs 180 people working > in various areas of cryptographic network security, and our products > are distributed directly and indirectly by hundreds of licensed > distributors and OEMs worldwide using the SSH brand name. There are > several million users of products that we have licensed under the > SSH brand. > > To protect the SSH trademark I (or SSH Communications Security Corp, > to be more accurate) registered the SSH mark in the United States and > European Union in 1996 (others pending). We also have a registration > pending on the Secure Shell mark. This should be of interest to the IETF. It would be better for other implementers if every SSH implementation did not have to bear an advertisement for your company. > The SSH mark is a significant asset of SSH Communications Security and > the company strives to protect its valuable rights in the SSH? name > and mark. SSH Communications Security has made a substantial > investment in time and money in its SSH mark, such that end users have > come to recognize that the mark represents SSH Communications Security > as the source of the high quality products offered under the mark. > This resulting goodwill is of vital importance to SSH Communications > Security Corp. > > We have also been distributing free versions of SSH Secure Shell under > the SSH brand since 1995. The latest version, ssh-2.4.0, is free for > any use on the Linux, FreeBSD, NetBSD, and OpenBSD operating systems, > as well as for universities and charity organizations, and for > personal hobby/recreational use by individuals. > > We have been including trademark markings in SSH distributions, on the > www.ssh.fi, www.ssh.com, and www.ssh.org web sites, IETF standards > documents, license/readme files and product packaging long before the > OpenSSH group was formed. Accordingly, we would like you to > understand the importance of the SSH mark to us, and, by necessity, > our need to protect the trademark against the unauthorized use by > others. Recognise also that SSH has been a generic term to describe the protocol well before your attempt to trademark it. > Many of you are (and the initiators of the OpenSSH group certainly > should have been) well aware of the existence of the trademark. Some > of the OpenBSD/OpenSSH developers/sponsors have also received a formal > legal notice about the infringement earlier. > > I have started receiving a significant amount of e-mail where people > are confusing OpenSSH as either my product or my company's product, or > are confusing or misrepresenting the meaning of the SSH and Secure > Shell trademarks. I can relate to this - a receive a fair bit of email from users asking for help with your products. > I have also been informed of several recent press > articles and outright advertisements that are further confusing the > origin and meaning of the trademark. Surely this is a matter should be resolved with the authors of said articles. > The confusion is made even worse by the fact that OpenSSH is also a > derivative of my original SSH Secure Shell product, and it still looks > very much like my product (without my approval for any of it, by the > way). This is unfair and more than a little disingenuous, as you must recall the license that you released ssh-1.2.12 under: ``As far as I am concerned, the code I have written for this software can be used freely for any purpose. Any derived versions of this software must be clearly marked as such, and if the derived work is incompatible with the protocol description in the RFC file, it must be called by a name other than "ssh" or "Secure Shell".'' > The old SSH1 protocol and implementation are known to have > fundamental security problems, some of which have been described in > recent CERT vulnerability notices and various conference papers. > OpenSSH is doing a disservice to the whole Internet security community > by lengthing the life cycle of the fundamentally broken SSH1 > protocols. This is being uncharitable in the extreme. OpenSSH is providing a smooth migration path from SSH1 to SSH2. A near-future release of OpenSSH will be making protocol 2 the default. As a security professional, you must surely be aware of the human factors pertaining to software uptake, specifically the tendency of people to refuse to upgrade if the immediate costs of doing so are too high. Furthermore it is hypocritical to accuse us of doing a "disservice to the whole Internet security community" when you are still distributing ssh-1.x from ftp://ftp.ssh.com/ Please reconsider this approach, I think that the antipathy generated by pursuing a free software project will cost your company a lot more than a trademark. -d > The use of the SSH trademark by OpenSSH is in violation of my > company's intellectual property rights, and is causing me, my company, > our licensees, and our products considerable financial and other > damage. > > I would thus like to ask you to change the name OpenSSH to something > else that doesn't infringe the SSH or Secure Shell trademarks, > basically to something that is clearly different and doesn't cause > confusion. > > Also, please understand that I have nothing against independent > implementations of the SSH Secure Shell protocols. I started and > fully support the IETF SECSH working group in its standardization > efforts, and we have offered certain licenses to use the SSH mark to > refer to the protocol and to indicate that a product complies with the > standard. Anyone can implement the IETF SECSH working group standard > without requiring any special licenses from us. It is the use of the > "SSH" and "Secure Shell" trademarks in product names or in otherwise > confusing manner that we wish to prevent. > > Please also try to look at this from my viewpoint. I developed SSH > (Secure Shell), started using the name for it, established a company > using the name, all of our products are marketed using the SSH brand, > and we have created a fairly widely known global brand using the name. > Unauthorized use of the SSH mark by the OpenSSH group is threathening > to destroy everything I have built on it during the last several > years. I want to be able to continue using the SSH and Secure Shell > names as identifying my own and my company's products and > technologies, which the unlawful use of the SSH name by OpenSSH is > making very hard. > > Therefore, I am asking you to please choose another name for the > OpenSSH product and stop using the SSH mark in your product name and > in otherwise confusing manner. > > Regards, > > Tatu Ylonen -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From Matthew_Weigel at ursa-minor.fac.cs.cmu.edu Wed Feb 14 18:15:07 2001 From: Matthew_Weigel at ursa-minor.fac.cs.cmu.edu (Matthew Weigel) Date: Wed, 14 Feb 2001 02:15:07 -0500 Subject: SSH trademarks and the OpenSSH product name In-Reply-To: Your message of "Wed, 14 Feb 2001 03:36:19 +0200." <200102140136.DAA03479@mystery.acr.fi> Message-ID: <20010214071531.A67E41A42C@toad.mindrot.org> > As you know, I have been using the SSH trademark as the brand name of > my SSH (Secure Shell) secure remote login product and related > technology ever since I released the first version in July 1995. I > have explicitly claimed them as trademarks at least from early 1996. Didn't know that, since I've never seen it credited. See http://www.fsecure.com/products/ssh/client/index.html as an example; no mention I can find that "F-Secure SSH Client" is in any way related to a trademarked name. Curious that a business doesn't seem to be getting pushed about it, when they could actually pay licensing fees. > The SSH mark is a significant asset of SSH Communications Security and > the company strives to protect its valuable rights in the SSH name > and mark. SSH Communications Security has made a substantial > investment in time and money in its SSH mark, such that end users have > come to recognize that the mark represents SSH Communications Security > as the source of the high quality products offered under the mark. Nah- I've come to recognize SSH Communications Security as the purveyor of commercial security software that, generally speaking, can't keep up with free stuff. Just out of curiosity, when the bug in RSAREF was discovered, was SSHCS's ssh-1 software vulnerable? Was OpenSSH? > We have also been distributing free versions of SSH Secure Shell under > the SSH brand since 1995. The latest version, ssh-2.4.0, is free for > any use on the Linux, FreeBSD, NetBSD, and OpenBSD operating systems, > as well as for universities and charity organizations, and for > personal hobby/recreational use by individuals. Does that mean to imply that you have significant good will towards free software/open source software? Clearly it isn't the case here, if you're leaning on OpenSSH but not F-Secure. As of this moment, I'm writing this thanks to the free ssh client, Nifty Telnet SSH. No mention on the web page of the guy who added SSH support (http://www.lysator.liu.se/~jonasw/freeware/niftyssh/) that you're giving *him* trouble, nor any mention of the trademark you're claiming. Why is it that you're apparently not going after him? > Many of you are (and the initiators of the OpenSSH group certainly > should have been) well aware of the existence of the trademark. Some > of the OpenBSD/OpenSSH developers/sponsors have also received a formal > legal notice about the infringement earlier. Is it legal infringement when the license is clear that if the derived work is "incompatible with the protocol description in the RFC file, it must be called by a name other than "ssh" or "Secure Shell""? I don't have a copy of that RFC file, but I'm willing to bet OpenSSH is compatible with it. > Shell trademarks. I have also been informed of several recent press > articles and outright advertisements that are further confusing the > origin and meaning of the trademark. Blame stupid media. > The confusion is made even worse by the fact that OpenSSH is also a > derivative of my original SSH Secure Shell product, and it still looks > very much like my product (without my approval for any of it, by the > way). Yeah, well, that's what happens when you make something nice available for free (thank you by the way) and then try to restrict it. People take that free release and run with it. > The use of the SSH trademark by OpenSSH is in violation of my > company's intellectual property rights, and is causing me, my company, > our licensees, and our products considerable financial and other > damage. Oh please. Because OpenSSH is better? Well, OK, that makes sense. But not because people are confused; just because they prefer a free, quality product to a not-free, not-so-quality product. > I would thus like to ask you to change the name OpenSSH to something > else that doesn't infringe the SSH or Secure Shell trademarks, > basically to something that is clearly different and doesn't cause > confusion. Yeah. OpenSSH is open, but it's based on SSH. SSH is, well, SSH. I fail to see the confusion. > Also, please understand that I have nothing against independent > implementations of the SSH Secure Shell protocols. No, but it sounds like you have a problem, from your above comments and related facts, that you've got something against implementations based on your own code. Which, frankly, doesn't make sense, since you gave us the code in the first place. > I started and > fully support the IETF SECSH working group in its standardization > efforts, and we have offered certain licenses to use the SSH mark to > refer to the protocol and to indicate that a product complies with the > standard. Anyone can implement the IETF SECSH working group standard > without requiring any special licenses from us. It is the use of the > "SSH" and "Secure Shell" trademarks in product names or in otherwise > confusing manner that we wish to prevent. Does that mean we can't even use ssh for the binary name? Yeesh. > Please also try to look at this from my viewpoint. I developed SSH > (Secure Shell), started using the name for it, established a company > using the name, all of our products are marketed using the SSH brand, > and we have created a fairly widely known global brand using the name. Oh? I didn't even know about the company for quite some time after I first started using it -- all I knew about was this hacker who'd realized telnet wasn't enough. > Unauthorized use of the SSH mark by the OpenSSH group is threathening > to destroy everything I have built on it during the last several > years. I want to be able to continue using the SSH and Secure Shell > names as identifying my own and my company's products and > technologies, which the unlawful use of the SSH name by OpenSSH is > making very hard. Ummm... but OpenSSH *does* identify your (the singular, Tatu Ylonen form of you) product: it's based on your code, given unto the Internet community. Just because other people own copyright to some of the code, since they've added it, doesn't seem so bad, does it? Why you're not chasing after other people's products, just your own, is strange. > Therefore, I am asking you to please choose another name for the > OpenSSH product and stop using the SSH mark in your product name and > in otherwise confusing manner. I like the name OpenSSH. Short, simple, to the point. There are more worthy causes for the money I have to donate (like helping battered women) than OpenSSH, don't make me spend it -- and encourage other people to spend theirs -- to give all the help we can to OpenSSH. -- Matthew Weigel Research Systems Programmer mcweigel+ at cs.cmu.edu From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Feb 14 20:33:13 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Wed, 14 Feb 2001 10:33:13 +0100 Subject: issue with EGD in openssh In-Reply-To: <200102132316.f1DNGiA20467@xerxes.courtesan.com>; from Todd.Miller@courtesan.com on Tue, Feb 13, 2001 at 04:16:43PM -0700 References: <200102131437.f1DEbXr19575@xerxes.courtesan.com> <20010213211353.A11946@serv01.aet.tu-cottbus.de> <200102132018.f1DKIRi01588@xerxes.courtesan.com> <20010213213524.A12289@serv01.aet.tu-cottbus.de> <200102132316.f1DNGiA20467@xerxes.courtesan.com> Message-ID: <20010214103313.A27459@ws01.aet.tu-cottbus.de> On Tue, Feb 13, 2001 at 04:16:43PM -0700, Todd C. Miller wrote: > Yes, I was surprised too. I have not seen this happen on HP-UX either. > However, this is still something openssh needs to deal with as it should > be possible to restart the entropy daemon w/o having sshd die. I agree. I had this problem quite some time ago with older versions of OpenSSH which kept the connection to EGD open all the time and were not prepared to deal with EGD-restarts. ... 20000626 ... - (djm) Make EGD failures non-fatal if OpenSSL's entropy pool is still OK based on patch from Lutz Jaenicke - (djm) Fix fixed EGD code. ... Based on what you write here, more work must be done to make sure that EGD failure must not lead to sshd failures. EGD or PRNGD can be shut down and restarted in a not synchronized way at any time, so that SSHD failure must be prevented. (Investigation of possible PRNGD caused problems will continue independently.) 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 jmknoble at jmknoble.cx Wed Feb 14 20:48:03 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Wed, 14 Feb 2001 04:48:03 -0500 Subject: ANNOUNCE: x11-ssh-askpass v1.2.0 Message-ID: <20010214044803.G1415@quipu.half.pint-stowp.cx> x11-ssh-askpass version 1.2.0 (code name: Love Me Tender) 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.2.0 are as follows: - Adds the ability to display passphrase prompts with more than one line (needed for challenge-response authentication types). Requested by Markus Friedl of the OpenSSH project. - Fixes minor buglet where the *grabServer resource was actually setting the value for the *grabPointer resource (does anyone use either of those? I thought not). - Now installs in /usr/local/libexec/openssh/, to conform to recent releases of the portable OpenSSH. This release of x11-ssh-askpass has received cursory testing. Although the changes are relatively small and contained, well ... so is knee surgery, but that doesn't mean the patient can walk right afterward. Please bludgeon this release severely and send me the corpse. It would be nice for this to go into the next round of portable OpenSSH RPM packages. Cheers. -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From djm at mindrot.org Wed Feb 14 20:54:14 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Feb 2001 20:54:14 +1100 (EST) Subject: ANNOUNCE: x11-ssh-askpass v1.2.0 In-Reply-To: <20010214044803.G1415@quipu.half.pint-stowp.cx> Message-ID: On Wed, 14 Feb 2001, Jim Knoble wrote: > - Adds the ability to display passphrase prompts with more than one > line (needed for challenge-response authentication types). > Requested by Markus Friedl of the OpenSSH project. Could you explain this a little more? I should update the GNOME askpass to match. > This release of x11-ssh-askpass has received cursory testing. Although > the changes are relatively small and contained, well ... so is knee > surgery, but that doesn't mean the patient can walk right afterward. > Please bludgeon this release severely and send me the corpse. It would > be nice for this to go into the next round of portable OpenSSH RPM > packages. To this end, could interested parties please give this a good thrashing ASAP? -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From jmknoble at jmknoble.cx Wed Feb 14 21:15:08 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Wed, 14 Feb 2001 05:15:08 -0500 Subject: ANNOUNCE: x11-ssh-askpass v1.2.0 In-Reply-To: ; from djm@mindrot.org on Wed, Feb 14, 2001 at 08:54:14PM +1100 References: <20010214044803.G1415@quipu.half.pint-stowp.cx> Message-ID: <20010214051508.A5307@quipu.half.pint-stowp.cx> Circa 2001-Feb-14 20:54:14 +1100 dixit Damien Miller: : On Wed, 14 Feb 2001, Jim Knoble wrote: : : > - Adds the ability to display passphrase prompts with more than one : > line (needed for challenge-response authentication types). : > Requested by Markus Friedl of the OpenSSH project. : : Could you explain this a little more? I should update the GNOME askpass : to match. Sure; a rough explanation is in the included man page and in the ChangeLog. Prior versions of x11-ssh-askpass would accept a single argument on the command line (not including the standard X toolkit options). The argument would be displayed as text as the dialog prompt. The only thing different in this version is that it properly interprets newlines ('\n') embedded in the argument, so that the argument can be displayed on multiple lines. For example: $ /usr/local/libexec/openssh/x11-ssh-askpass 'line 1 > line 2 > line 3' used to look like this: +------------------------+ | | | line 1 line 2 line 3 | | | | == == == == == == == | | | | +-------+ +--------+ | | | OK | | Cancel | | | +-------+ +--------+ | +------------------------+ and now it looks like this: +------------------------+ | | | line 1 | | line 2 | | line 3 | | | | == == == == == == == | | | | +-------+ +--------+ | | | OK | | Cancel | | | +-------+ +--------+ | +------------------------+ (This also works for labels specified in the app-defaults file, including the labels on the OK and Cancel buttons). -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From djm at mindrot.org Wed Feb 14 21:17:42 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Feb 2001 21:17:42 +1100 (EST) Subject: ANNOUNCE: x11-ssh-askpass v1.2.0 In-Reply-To: <20010214051508.A5307@quipu.half.pint-stowp.cx> Message-ID: On Wed, 14 Feb 2001, Jim Knoble wrote: > Sure; a rough explanation is in the included man page and in the > ChangeLog. Prior versions of x11-ssh-askpass would accept a single > argument on the command line (not including the standard X toolkit > options). The argument would be displayed as text as the dialog prompt. > > The only thing different in this version is that it properly interprets > newlines ('\n') embedded in the argument, so that the argument can be > displayed on multiple lines. For example: last time I checked this is a PITA to do with GNOME. Any GNOME hackers on the list, please raise your hands! -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From bfriday at LaSierra.edu Thu Feb 15 01:54:32 2001 From: bfriday at LaSierra.edu (Brian Friday) Date: Wed, 14 Feb 2001 06:54:32 -0800 (PST) Subject: SSH trademarks and the OpenSSH product name In-Reply-To: <200102140136.DAA03479@mystery.acr.fi> Message-ID: I have used secure shell, SSH 1, 2 and now recently SFTP in the administering and normal use of my servers. Our campus like many others has made a concerted effort to completely remove insecure protocols and connection methods. The catch in migrations is getting users to move in a relatively painless manner. In late 1998 when I decided to try out SSH2 I had the unfortunate time of trying to get a straight and complete answer on how and when I could or could not use SSH in my daily duties. The license included appeared dense confusing and contradictory. No one I talked with (which included ssh.com people) had any answer to my questions only rumor and assumption. I was left with the decision to move to "free" SSH.com products with possible dubious licenses or remain in the status quo of using clear text services and protocols. It was a tuff decision but we stuck with the enemy we knew, SSH was available for our Computer Science and academic people. I like to play by the rules and because your company continued to release license after license that gave the educational user/reader the "impression" of usability, but continually avoid specific language to that effect. I could never justify the cost of having a lawyer review and explain in detail the "wherefore and what-nots" contained therein. The F-Secure/Data-fellows/SSH.com's products thus have never been supported by our campus. I harbor no ill will to you or your associates Mr. Ylonen but as stated in at least one e-mail the appearance of OpenSSH was not only a godsend but allowed me to begin moving our whole campus to secure protocols. While this process has not completed, through the efforts of OpenSSH developers, testers and users to believe it to be an attainable goal. Your recent posts to BUGTRAQ have been disturbing as they appear to be a intense effort force users to SSH2 and alienate users of SSH1 by not providing a clear upgrade path. Thus OpenSSH is again a better product for our campus as it supports both 1 & 2 in the same daemon which while perhaps not as "secure" as the dueling daemons needed to provide the same functionality in SSH.com products. It certainly gives me a viable solution for our campus. I think you have chosen a poor way of announcing your intentions, I also think you'll find more ill will directed to you and your company because of your message and your attitude. That will be your burden to bear and I wish you luck as life can be extremely hard when you have to fight your own words. Sincerely, Brian Friday Systems Administrator La Sierra University (909) 785-2554 x2 From sxw at dcs.ed.ac.uk Thu Feb 15 02:58:41 2001 From: sxw at dcs.ed.ac.uk (Simon Wilkinson) Date: Wed, 14 Feb 2001 15:58:41 GMT Subject: Kerberos/GSSAPI support Message-ID: <200102141558.PAA14715@canna.dcs.ed.ac.uk> Hi, Just wondering if anyone was looking at implementing draft-ietf-secsh-gsskeyex-00 in OpenSSH? My patches for SSH version 1 Kerberos 5 support (heavily based upon work done by Dan Kouril) are now available from http://www.sxw.org.uk/computing/patches/ Is there any interest in integrating these into the distribution? If so, I'd be happy to update them to the development version. Cheers, Simon From ajh3 at hecubus.bsdonline.org Thu Feb 15 03:11:45 2001 From: ajh3 at hecubus.bsdonline.org (Andrew Hesford) Date: Wed, 14 Feb 2001 10:11:45 -0600 Subject: OpenSSH Trademark Infringement Message-ID: <20010214101144.A94246@cec.wustl.edu> Just thought I'd put my two cents in about the trademark infringement issue. I ran the true SSH for about a month some time back. When I learned of OpenSSH, I dropped the official product and built OpenSSH. Quite frankly, OpenSSH is a superior package. It is cleaner, commercially unencumbered, and with its affiliation to the OpenBSD team, I feel more secure about the code quality. When somebody mentions SSH, I don't think about the people behind ssh.com, I think about OpenSSH, which runs continuously on my workstation, serving as my only remote entry point. To me, and I imagine to many others, SSH is not a corporate product, but instead a generic name, reserving a phrase similar to "the official SSH" for the corporate product. I have never confused OpenSSH with the official SSH, and never will. However, the OpenSSH name may infringe upon copyrights against SSH, but I believe that SSH Communications Security has already lost control of the SSH trademark. If the OpenSSH team can show this, there will be no need for a name change. Good luck. -- Andrew Hesford - ajh3 at chmod.ath.cx "355/113 -- Not the famous irrational number PI, but an incredible simulation!" From ian at zeroknowledge.com Thu Feb 15 03:35:28 2001 From: ian at zeroknowledge.com (Ian Goldberg) Date: Wed, 14 Feb 2001 11:35:28 -0500 Subject: SSH trademarks and the OpenSSH product name Message-ID: <200102141635.LAA11637@iang.zks.net> Damien Miller wrote: > To my knowledge you have not contacted any of the other implementors of > SSH clients and servers who use 'SSH' in the name of there product > (there are several). Why are you 1) making an issue now, when there have > been SSH implementations using 'SSH' in their names for several years? > and 2) targeting the OpenSSH team only? [Note: I'm not actually subscribed to this list; I was pointed to the web archive...] So I guess I should throw in my CA$0.02. IANAL, so I'm going to restrict this message to facts, and not opinions. When I wrote an independent implementation of the RFC file contained in the ssh distribution (a version for the Palm Pilot, called Top Gun ssh), I used "ssh" in the name because that was the name of the protocol, as outlined in the RFC. Certainly TGssh was not a derived work of ssh in the copyright sense; it was merely an implementation of the ssh protocol. This was in the summer of 1997. I exchanged email with Tatu, Camillo Sars, and Kalle Kaukonen at the time (I had found discrepancies between the ssh RFC and the ssh deployed software); Tatu even asked me if I'd be willing to do an implementation of the 2.0 protocol. No one ever asked me to not use the "ssh" name in the program title. - Ian From roc+ at cs.cmu.edu Thu Feb 15 05:48:10 2001 From: roc+ at cs.cmu.edu (Robert O'Callahan) Date: Wed, 14 Feb 2001 13:48:10 -0500 Subject: TTSSH and the SSH trademark Message-ID: <3A8AD2E9.C2C88E73@cs.cmu.edu> Hi everyone. I want to point out some facts about TTSSH that may be relevant to the claims of trademark infringement by OpenSSH. I'll confine my opinions to another message :-). I released my product, which has always been named "Teraterm SSH" and is usually abbreviated to "TTSSH", to the public in May 1998. TTSSH is a free software Windows client for the SSH1 protocol. The release was announced on the ssh at clinet.fi mailing list. There is no way to tell how many people are using TTSSH, but the number of users seems to be substantial, and I estimate it to be more than 100,000 (based on the fact that my three TTSSH Web pages get 2,000-3,000 hits per day most days). TTSSH has also been distributed through many channels other than Web-based downloads. Many universities have been distributing TTSSH to their students. It has also been distributed on CD software collections, including the CD included with the book "Unix Secure Shell" (published in 1999), written by Anne Carasik, an employee of SSH Communications Security. >From the public announcement in May 1998 until today, I have never been contacted by SSH Communications Security or any of their representatives --- or indeed anyone else --- alleging that the name "TTSSH" infringes on any trademarks. Also, since May 1998, in the TTSSH source code and binary code, its documentation, my Web pages, and all my correspondence, I have consistently used the name "SSH" to refer to the generic SSH protocol suite and the SSH1 protocol in particular. If there's ever a lawsuit, I'll be happy to testify to the above. Sincerely, Robert O'Callahan -- [Robert O'Callahan http://www.cs.cmu.edu/~roc 7th year CMU CS PhD student "Now when Joshua was near Jericho, he looked up and saw a man standing in front of him with a drawn sword in his hand. Joshua went up to him and asked, 'Are you for us or for our enemies?' 'Neither,' he replied, 'but as commander of the army of the LORD I have now come.'" - Joshua 5:13-14] From roc+ at cs.cmu.edu Thu Feb 15 06:05:34 2001 From: roc+ at cs.cmu.edu (Robert O'Callahan) Date: Wed, 14 Feb 2001 14:05:34 -0500 Subject: More on TTSSH and the SSH trademark Message-ID: <3A8AD6FE.E6FEDF57@cs.cmu.edu> I would also like to mention that when I released TTSSH in May 1998, I had no concerns about violating any trademarks because I observed that the name "SSH" was already being used by several different parties for different purposes --- as the name of Ylonen's original SSH package and its derivatives, as the name of the protocol, and as a component of names of other implementations and proposed implementations (e.g., FiSSH). It never occurred to me to check out the legal situation and since no one has ever bothered me about it, I've never worried about it. And now that I look at the license for ssh-1.2.12, I'm pretty confident that (since TTSSH is compatible with the SSH1 draft RFC) it was perfectly legitimate to incorporate the name "ssh" into the name of my system. Overall I think it's clear that for nearly three years, SSH Communications has made no effort to prevent large-scale "infringement" of their trademark by TTSSH and other parties, and therefore the name "SSH" has passed into the public domain. Of course I'm not a lawyer, but I'll be willing to hire one if they come after me. Also, looking at the situation from more of a moral point of view, although I appreciate what Tatu Ylonen and others have done for the security community, I think pushing these trademark claims is pretty sleazy. The IETF drafts all use the word "SSH" extensively and that's obviously the name that everyone uses to talk about the protocols. It's not fair that one party can incorporate the protocol name in their product name but everyone else can't. If SSH Communications want to distinguish themselves from OpenSSH --- which is a perfectly reasonable desire --- they should change the name of their product and company. In the future it would be good for the IETF to reject drafts that incorporate trademarked names to stop this kind of thing happening again. Rob -- [Robert O'Callahan http://www.cs.cmu.edu/~roc 7th year CMU CS PhD student "Now when Joshua was near Jericho, he looked up and saw a man standing in front of him with a drawn sword in his hand. Joshua went up to him and asked, 'Are you for us or for our enemies?' 'Neither,' he replied, 'but as commander of the army of the LORD I have now come.'" - Joshua 5:13-14] From asgard at hellnet.cz Thu Feb 15 06:17:02 2001 From: asgard at hellnet.cz (Jan Samohyl) Date: Wed, 14 Feb 2001 20:17:02 +0100 (CET) Subject: Update: problem compiling openssh-2.3.0p1 with openssl-0.9.6 In-Reply-To: Message-ID: On Wed, 14 Feb 2001, Damien Miller wrote: > Have a look at config.log, there should be a more detailed error message > there. Thank you, but it's yet more strange. In config.log I found something that should work, I tried to compile it separately, and it compiled (except '1>&5'). So I don't quite understand why configure says it failed. I found the following: configure:3214: gcc -o conftest -g -O2 -Wall -I. -I. -I/usr/local/ssl/include -L/usr/local/ssl/lib -L/usr/local/ssl conftest.c -ldl -lnsl -lz -lutil -lpam -lcrypto 1>&5 configure: failed program was: #line 3200 "configure" #include "confdefs.h" #include #include int main(void) { char a[2048]; memset(a, 0, sizeof(a)); RAND_add(a, sizeof(a), sizeof(a)); return(RAND_status() <= 0); } From jeff at ollie.clive.ia.us Thu Feb 15 07:28:06 2001 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Wed, 14 Feb 2001 14:28:06 -0600 Subject: More on TTSSH and the SSH trademark In-Reply-To: <3A8AD6FE.E6FEDF57@cs.cmu.edu>; from roc+@cs.cmu.edu on Wed, Feb 14, 2001 at 02:05:34PM -0500 References: <3A8AD6FE.E6FEDF57@cs.cmu.edu> Message-ID: <20010214142806.B12539@ollie.clive.ia.us> On Wed, Feb 14, 2001 at 02:05:34PM -0500, Robert O'Callahan wrote: > > In the future it would be good for the IETF to reject drafts that > incorporate trademarked names to stop this kind of thing happening > again. See RFC 2026 section 10 (dated October 1996) and RFC 1602 section 5 (dated March 1994) regarding the treatment of intellectual property rights by the IETF. Also, the fact that much of the early work on SSH was done by Tatu Ylonen at the Helsinki University of Technology may have an effect on the situation. Jeff From shorty at getuid.de Thu Feb 15 07:35:04 2001 From: shorty at getuid.de (Christian Kurz) Date: Wed, 14 Feb 2001 21:35:04 +0100 Subject: username check in scp In-Reply-To: <20010208212400.D10759@seteuid.getuid.de> References: <20010208212400.D10759@seteuid.getuid.de> Message-ID: <20010214213504.J600@seteuid.getuid.de> On 01-02-08 Christian Kurz wrote: [..] > that scp checks it. I could verify that the current openssh code from > cvs still has a check for the username in scp.c but not in ssh.c. So I > created the attached small patch to remove the username check from scp. > I hope ?t's correct and that you apply it to the source. If it's wrong, > please point me to my mistake, so that I can learn from it. If you don't [...] Hm, I still received no comment from anyone of you about this patch and the problematic code still exits in scp. Would please anyone comments on this and maybe add my patch or change scp? Ciao Christian -- Love is the process of my leading you gently back to yourself. -- Saint Exupery -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 241 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010214/722f13c1/attachment.bin From Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Feb 15 08:12:14 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Wed, 14 Feb 2001 22:12:14 +0100 Subject: issue with EGD in openssh In-Reply-To: <20010214103313.A27459@ws01.aet.tu-cottbus.de>; from Lutz.Jaenicke@aet.TU-Cottbus.DE on Wed, Feb 14, 2001 at 10:33:13AM +0100 References: <200102131437.f1DEbXr19575@xerxes.courtesan.com> <20010213211353.A11946@serv01.aet.tu-cottbus.de> <200102132018.f1DKIRi01588@xerxes.courtesan.com> <20010213213524.A12289@serv01.aet.tu-cottbus.de> <200102132316.f1DNGiA20467@xerxes.courtesan.com> <20010214103313.A27459@ws01.aet.tu-cottbus.de> Message-ID: <20010214221214.A14299@serv01.aet.tu-cottbus.de> On Wed, Feb 14, 2001 at 10:33:13AM +0100, Lutz Jaenicke wrote: > On Tue, Feb 13, 2001 at 04:16:43PM -0700, Todd C. Miller wrote: > > Yes, I was surprised too. I have not seen this happen on HP-UX either. > > However, this is still something openssh needs to deal with as it should > > be possible to restart the entropy daemon w/o having sshd die. > > I agree. I had this problem quite some time ago with older versions of > OpenSSH which kept the connection to EGD open all the time and were not > prepared to deal with EGD-restarts. > ... > 20000626 > ... > - (djm) Make EGD failures non-fatal if OpenSSL's entropy pool is still OK > based on patch from Lutz Jaenicke > - (djm) Fix fixed EGD code. > ... > Based on what you write here, more work must be done to make sure that > EGD failure must not lead to sshd failures. > EGD or PRNGD can be shut down and restarted in a not synchronized way at > any time, so that SSHD failure must be prevented. Update: I have made some changes to I/O handling (EINTR, EAGAIN..)in PRNGD and sent them to Todd Miller. He is now testing the changes and I hope it will help (second attempt now since I shot myself into the foot during the first attempt). Independant of that I would propose to change the EGD query code to protect against SIGPIPE by wrapping it with: struct sigaction sa, osa; memset(&sa, 0, sizeof(sa)); sa.sa_handler = SIG_IGN; sigaction(SIGPIPE, &sa, &osa); ... sigaction(SIGPIPE, &osa, NULL); I would write a patch, but I don't know what signal handling to use. There was a discussion about using sigaction() but I did not follow close enough.. 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 djm at mindrot.org Thu Feb 15 09:36:15 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 15 Feb 2001 09:36:15 +1100 (EST) Subject: Update: problem compiling openssh-2.3.0p1 with openssl-0.9.6 In-Reply-To: Message-ID: On Wed, 14 Feb 2001, Jan Samohyl wrote: > > On Wed, 14 Feb 2001, Damien Miller wrote: > > Have a look at config.log, there should be a more detailed error message > > there. > > Thank you, but it's yet more strange. > In config.log I found something that should work, I tried to compile it > separately, and it compiled (except '1>&5'). So I don't quite understand > why configure says it failed. Are there any other error messages around this? What was the exit status of the test program? do "./testprog ; echo $?" -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From i.palsenberg at jdimedia.nl Thu Feb 15 11:17:02 2001 From: i.palsenberg at jdimedia.nl (Igmar Palsenberg) Date: Thu, 15 Feb 2001 01:17:02 +0100 (CET) Subject: The SSH trademark issue part #1 Message-ID: Hi, I usually stay away from issues like this, basically because I'm not a lawyer (and don't want to be one), and I don't have a real interest in these issues. Quoting Tatu : > We also have a trademark pending on the Secure Shell mark This seriously undermines the IETF standard draft. It's the same as registering 'milk' as a trademark. Both Secure and Shell are common used words, so this trademark doesn't make sense to me. I personally also find it strange that this trademark issue has been playing for 6 years now, and nobody complained using this period. Now that thing are getting big attention, someone stands up and says 'hey, that's mine !!!'. I personally call this screwing developers. By naming the IETF standard the same as the trademark, SSH Corp. strongly undermines it's (legal) position, and I seriously doubt that the trademark will hold in court. Luckely I'm not a laywer, so I could be wrong. > I started receiving a significant amount of e-mail where people are > confising OpenSSH as either my product or my company's product, or are > confusing the meaning of the SSH and Secure Shell trademarks Well, since most people don't read documentation, I'm not suprised. I once wrong a MySQL mapper class for sendmail, and I get mail asking thing about either sendmail, or thing that look alike the mapper class I wrote. I usually answer the question when I can, or point them at the apropriate mailinglists / webpages. That's life. Since SSH named their trademark after the IETF standard (or the other way around), I'm not suprised that people get confused. But can we blame the OpenSSH initiators and developers for this ? No, don't think so. Since I created some patches for OpenSSH, this also means that my ass is on the line here, so I will do some legal inquiries, to see what my rights are, and what the rights of SSH Corp are in this case. This also mean that two version of the SSH protocol will arise : One which is compatible with the SSH Corp line of product, and one which obeys the IETF standard. No a very pleasant situation, both for SSH Corp and the other parties. Licensing the use of 'SSH' in the protocol to the IETF does NOT solve this issue, since it sill means that those who actually use it need to get a license to use 'SSH'. Really sick situation in my opinion. To prevent legal problems I'll remove all reference to the name 'SSH' from my website, and advice all my customers to drop SSH version from SSH Corp. Discussion are welcome, in private please. Regards, Igmar Palsenberg JDI Media Solutions -- -- Igmar Palsenberg JDI Media Solutions Jansplaats 11 6811 GB Arnhem The Netherlands mailto: i.palsenberg at jdimedia.nl PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar From djm at mindrot.org Thu Feb 15 11:44:38 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 15 Feb 2001 11:44:38 +1100 (EST) Subject: PAM namespace. In-Reply-To: <200101301733.f0UHXU9656456@jurassic.eng.sun.com> Message-ID: On Tue, 30 Jan 2001, Darren Moffat wrote: > auth-pam.c declares some new functions in the pam_ namespace that are not > part of PAM. > > pam_password_change_required() > pam_msg_cat() > pam_cleanup_proc() > > Purely to avoid any possible future problems I would suggest changing > these so they do not being with pam_ Done. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From jimd at starshine.org Thu Feb 15 12:16:23 2001 From: jimd at starshine.org (Jim Dennis) Date: Wed, 14 Feb 2001 17:16:23 -0800 Subject: Tatu Ylonen's message to the OpenSSH developers Message-ID: <200102150116.RAA09565@mars.starshine.org> A non-text attachment was scrubbed... Name: not available Type: application/pgp Size: 3562 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010214/5489bfec/attachment.bin From stend+openssh at sten.org Thu Feb 15 12:39:37 2001 From: stend+openssh at sten.org (Sten) Date: 14 Feb 2001 19:39:37 -0600 Subject: SSH trademarks and the OpenSSH product name In-Reply-To: Tatu Ylonen's message of "Wed, 14 Feb 2001 03:36:19 +0200" References: <200102140136.DAA03479@mystery.acr.fi> Message-ID: >>>>> Tatu Ylonen writes: TY> To protect the SSH trademark I (or SSH Communications Security TY> Corp, to be more accurate) registered the SSH mark in the United TY> States and European Union in 1996 (others pending). We also have TY> a registration pending on the Secure Shell mark. Mr Ylonen, you do not have a registered trademark in the United States for the term 'SSH'. You have a registered trademark for a specific stylized form of the letters 'SSH' (registration number 2141991). There is a "typed drawing" mark registered for SSH, but that belongs to Fairchild Industries. As for your obtaining a "typed drawing" registered mark, you may wish to refer to Section 2 paragraph e of the Trademark Act (15 USC 1052), which indicates that a mark may be denied if the mark is merely descriptive of the product. If you wish to claim that that the term "secure shell" and its abbreviation 'ssh' are not descriptive of your product, please feel free to do so. -- What country can preserve its liberties if its rulers are not warned from time to time that their people preserve the spirit of resistance? Let them take arms. The remedy is to set them right as to facts, pardon and pacify them. -- Thomas Jefferson to William Stephens Smith, 1787. ME 6:373, Papers 12:356 From mouring at etoh.eviladmin.org Thu Feb 15 14:12:03 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 14 Feb 2001 21:12:03 -0600 (CST) Subject: Tatu Ylonen's message to the OpenSSH developers In-Reply-To: <200102150116.RAA09565@mars.starshine.org> Message-ID: On Wed, 14 Feb 2001, Jim Dennis wrote: [..] > However, it's equally a pity that no one has come out with a fully > independent protocol compatible re-implementation. Tatu published > his sources, and a full description of the protocols (both versions?) > and has actively encouraged (through his participation in the IETF) > an independent implementation. (IETF guidelines strongly suggest, > nigh onto *require* multiple independent and interoperable > implementations of all new Internet standards). lsh/psst > (http://www.net.lut.ac.uk/psst/) seems to be a moribund project; the > fact that it hasn't even become available as a Debian package in > unstable is testimony to that. > I'm sorry, but this feels like a massive sales pitch. And I'm not buying the your 'Evil OpenBSD group' story. First off.. Why are you discounting the other implementations and trying to 'sell' psst? What about FreSSH? Mindterm? The Java(tm) Telnet Application/Applet? And more.. Just I'm too busy to look them up. Please don't attempt to feed people the crap that 'Oh there is only three implementation and one is not "independent"'. Secondly, you can't tell me that all we did was "steal all of Tatu's work" and then sat around going "Oh we did a great job. Oh we are such wonderful people." Markus has spent a lot of hours re-implementing v2. Not counting the hours of clean up v1 protocol. Stripping out the crude that has accumated over the years. Allowing the portable group to carely add in multiple platform support in a sane and auditable way. Please push your political non-sense somewhere else. We have development to actually do. If you feel psst is so much better (as your email states) then I suggest you go and help them improve their product and then let the public decide which one they will trust and use. - Ben From joden at eworld.wox.org Thu Feb 15 14:28:24 2001 From: joden at eworld.wox.org (James Oden) Date: Wed, 14 Feb 2001 22:28:24 -0500 (EST) Subject: Tatu Ylonen's message to the OpenSSH developers In-Reply-To: <200102150116.RAA09565@mars.starshine.org> from "Jim Dennis" at Feb 14, 2001 05:16:23 PM Message-ID: <200102150328.WAA25931@eworld.wox.org> > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I personally applaud Tatu Ylonen's restraint and tact in his message > to the OpenSSH developers list. I think it's long overdue. > Even though I privately answered him as an irate customer, I will give him that he expressed his intentions in an appropriate professional manner despite the fact that I believe his intentions were inappropriate and unprofessional. > It's a pity that SSH(TM) isn't completely free. It's a pity that > Tatu hasn't found a revenue model that would allow him to release > under the GPL or BSD licenses, or to create a DFSG compliant license. > Obviously, revenue models are a hard problem for free software -- and > some people do need to live off their programming labors. I can't > begrudge Tatu (or others) that. > No one that I know of has faulted Tatu and his company for making his product closed source. That is not the argument. The argument is against: a) His claim of ssh as trademark. b) His claiming that ssh used within another word sullies his trademark. c) Claiming the use of this trademark causes confusion and thus pain to his company. Concerning a) I must say that I find it amazing for many reasons that any legal system would allow him the trademark: a) It is in common use and has been in use for years as a description of a protocol not a companies product. b) The term ssh was actually used by borne type shell before "ssh" as we know it came arround. Concerning point b) and c), it is clear beyond a shadow of doubt that OpenSSH and some of the other SSH's out there are not Yatu's product, and it is certainly not the intent of any project developing ssh protocols (that's what they are called in the RFC's) to make users believe that they are Tatu's product. Their only wish is to develop efficient secure applications that are complient with the RFC's concerning the protocol SSH. You will also note as he has decided to call his product the same as the protocol it conforms to, he falls into the same situation as the countless companies that produce telnet and ftp programs that do the telent and ftp protocols. Long ago I was a tech at Serial Comm. Company, and I can assure you that I got emails and phone calls for xmodem, ymodem, and zmodem implementations that we did not produce. Its the nature of the business. > Unfortunately I think that Tatu will be castigated for his message > and I'd like to go on record as saying that all the complainers > should stuff it! Go help Martin Hamilton and the rest of the psst > team if you insist a fullly GPL version of an ssh(TM) compatible > package. (Or help get InterNIC to adopt a secure DNS version of BIND > *and* to publish keys and sign their top level zone data --- and > otherwise help us realize IPSec). > Of course he should unless he changes his mind. First of all if he wants to differentiate himself from the rest, it is the area of service that he will be able to do so. If he wants to differentiate his products from other products that do the SSH protocol, than provide the easiest, most documented, most feature rich product that does SSH protocol. Provide solutions for business, not a trademark (not that a business should not have a trademark). > Meanwhile the OpenSSH [sic] team should probably consider renaming > their package OpenSecsh (possibly to be pronounced like a drunk > commenting on "promiscuous sex"). I suspect that Tatu would have no > complaint about their use of the IETF name for the protocol --- and > he hasn't even asked them/us to change the name of the binary. > I am not a member of the team, but I sincerely hope they do not unless forced to do so. This definately a case of straining gnats and swallowing camels whole...james From mouring at etoh.eviladmin.org Thu Feb 15 15:49:50 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 14 Feb 2001 22:49:50 -0600 (CST) Subject: environmental variables MAIL on solaris In-Reply-To: <20010214121408O.kuro@soum.co.jp> Message-ID: On Wed, 14 Feb 2001, Seiji Kurosawa wrote: > Hello. > > I found a Bug in openssh-2.3.0p1. > OS is solaris 2.6. > Can you please verify this against either the current CVS tree or against a more recent snapshot? http://bass.directhit.com/openssh_snap/ - Ben From mouring at etoh.eviladmin.org Thu Feb 15 15:57:10 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 14 Feb 2001 22:57:10 -0600 (CST) Subject: configure.in reorder patch In-Reply-To: Message-ID: On Mon, 12 Feb 2001, Tim Rice wrote: > > Feb 12 CVS (sort of, see warning below) > > I've had to change around some of the code in configure.in > to get some platforms to compile with the --with-tcp-wrappers option. > Is there a way to cut down in some of the changes in this patch. We are getting pretty close to a release (I can say this for sure now =) and I don't think we can fully test this large of change in such a short time. - Ben From Markus.Friedl at informatik.uni-erlangen.de Thu Feb 15 19:13:41 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 15 Feb 2001 09:13:41 +0100 Subject: OpenSSH is _not_ vulnerable the several known problems in SSH-1 Message-ID: <20010215091341.A16340@faui02.informatik.uni-erlangen.de> ----------------------------------------------------------------------- Special OpenBSD Security Note February 14, 2001 OpenSSH is _not_ vulnerable the several known problems in SSH-1 ----------------------------------------------------------------------- The CERT Coordination Center has published the following notes about weaknesses in various SSH protocol version 1 implementations. Since many people using OpenSSH are worried about these issues, we decided to publish these notes. 1) http://www.kb.cert.org/vuls/id/565052 "Passwords sent via SSH encrypted with RC4 can be easily cracked" 2) http://www.kb.cert.org/vuls/id/665372 "SSH connections using RC4 and password authentication can be replayed" 3) http://www.kb.cert.org/vuls/id/25309 "Weak CRC allows RC4 encrypted SSH packets to be modified without notice" 4) http://www.kb.cert.org/vuls/id/684820 "SSH allows client authentication to be forwarded if encryption is disabled" 5) http://www.kb.cert.org/vuls/id/315308 "Last block of IDEA-encrypted SSH packet can be changed without notice" 6) http://www.kb.cert.org/vuls/id/786900 "SSH host key authentication can be bypassed when DNS is used to resolve localhost" 7) http://www.kb.cert.org/vuls/id/118892 "Older SSH clients do not allow users to disable X11 forwarding" OpenSSH is _not_ vulnerable to #1, #2 and #3 since OpenSSH does not allow RC4 in its SSH protocol 1 implementation. OpenSSH is _not_ vulnerable to #4 since OpenSSH does not allow encryption to be disabled. OpenSSH is _not_ vulnerable to #5 since OpenSSH does not support IDEA. OpenSSH is _not_ vulnerable to #6 since OpenSSH does not resolve "localhost". OpenSSH uses the resolved IP-address and disables the host key authentication for 127.0.0.1 only. OpenSSH is _not_ vulnerable to #7 since OpenSSH permits users to disable X11 forwarding, and this is the default configuration in the OpenSSH client. The SSH protocol version 2 (a.k.a. SecSH) is not affected by problems #1, #2, #3, #4 and #5. The OpenSSH client currenly defaults to preferring SSH-1 protocol over SSH-2 protocol, but in a future release the default will soon change, since the SSH-2 protocol support has improved considerably. ----------------------------------------------------------------------- From svaughan at asterion.com Thu Feb 15 19:38:33 2001 From: svaughan at asterion.com (svaughan) Date: Thu, 15 Feb 2001 00:38:33 -0800 (PST) Subject: SCO 5.0.5 setluid patch In-Reply-To: Message-ID: Sorry it took me a while to get some free time this week :-) below is the small patch for SCO 5.0.x. to set the luid. I have tested it out and it seems to work good. I won't have access to a solaris box for a little while to test out the setauid(), so I didn't include that. Thanks, Sam *** openssh/session.c Sun Feb 11 06:12:08 2001 --- openssh_patch/session.c Wed Feb 14 23:41:48 2001 *************** *** 1030,1035 **** #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) --- 1030,1040 ---- #endif /* WITH_IRIX_ARRAY */ #endif /* WITH_IRIX_JOBS */ + #ifdef HAVE_SCO_SETLUID + /* Sets login uid for accounting*/ + if(setluid(pw->pw_uid) == -1) + perror("Unable to set luid!"); + #endif /* HAVE_SCO_SETLUID */ /* login(1) is only called if we execute the login shell */ if (options.use_login && command != NULL) *** openssh/configure.in Thu Feb 8 17:55:36 2001 --- openssh_patch/configure.in Wed Feb 14 01:56:19 2001 *************** *** 237,242 **** AC_DEFINE(HAVE_SCO_PROTECTED_PW) AC_DEFINE(DISABLE_SHADOW) AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) ;; *-dec-osf*) # This is untested --- 237,243 ---- AC_DEFINE(HAVE_SCO_PROTECTED_PW) AC_DEFINE(DISABLE_SHADOW) AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) + AC_CHECK_FUNC(setluid, [AC_DEFINE(HAVE_SCO_SETLUID)]) ;; *-dec-osf*) # This is untested *** openssh/config.h.in Sun Feb 11 09:30:28 2001 --- openssh_patch/config.h.in Wed Feb 14 13:20:55 2001 *************** *** 31,36 **** /* Define if you have SCO protected password database */ #undef HAVE_SCO_PROTECTED_PW /* If your header files don't define LOGIN_PROGRAM, then use this (detected) */ /* from environment and PATH */ #undef LOGIN_PROGRAM_FALLBACK --- 31,39 ---- /* Define if you have SCO protected password database */ #undef HAVE_SCO_PROTECTED_PW + /* Define if you have SCO setluid function */ + #undef HAVE_SCO_SETLUID + /* If your header files don't define LOGIN_PROGRAM, then use this (detected) */ /* from environment and PATH */ #undef LOGIN_PROGRAM_FALLBACK > > Would it be possible for someone with access to one of these systems to > turn the above into a patch and test it? > > You want to start in the do_child() function in session.c. Be careful, > there is a lot of OS-dependant stuff in that function. > > If noone steps up, then I can create a patch, but I don't have ready > access to a C2 system and would thus be flying blind. > > -d > > > -- > | Damien Miller \ ``E-mail attachments are the poor man's > | http://www.mindrot.org / distributed filesystem'' - Dan Geer > From paulo at nlink.com.br Thu Feb 15 23:11:49 2001 From: paulo at nlink.com.br (Paulo Fragoso) Date: Thu, 15 Feb 2001 10:11:49 -0200 (EDT) Subject: SSH-2 hostbased auth Message-ID: Hi, We've changed all opennssh config to use only protocol 2. Some hosts was connecting without password. Is possible to do this using openssh (Protocol 2)? Paulo. -- __O _-\<,_ Why drive when you can bike? (_)/ (_) From jean-marc.beroud at ubs.com Fri Feb 16 03:51:29 2001 From: jean-marc.beroud at ubs.com (Jean-Marc Beroud) Date: Thu, 15 Feb 2001 17:51:29 +0100 Subject: SSH2 PATH problem Message-ID: <3A8C0911.6D064542@ubs.com> Hello, I have the following behaviour with openssh-2.3.0p1 # ssh host 'echo $PATH' (SSH1 protocol, works fine) /bin:/sbin:/usr/bin:/usr/sbin:/usr/ucb:/usr/opt/SUNWmd/sbin # ssh -2 host 'echo $PATH' (force SSH2 protocol, PATH env var is not set) I can't execute a remote command with the SSH2 protocol. Any clue? Greets, Jean-Marc From asgard at hellnet.cz Fri Feb 16 04:00:20 2001 From: asgard at hellnet.cz (Jan Samohyl) Date: Thu, 15 Feb 2001 18:00:20 +0100 (CET) Subject: Update: problem compiling openssh-2.3.0p1 with openssl-0.9.6 In-Reply-To: Message-ID: Thank you, I finally got it working. The problem was I installed openssl with shared libraries, and forgot to add the path to /etc/ld.conf after the instalation. Jan Samohyl From mark at knm.org Fri Feb 16 04:03:19 2001 From: mark at knm.org (Mark Lehrer) Date: Thu, 15 Feb 2001 10:03:19 -0700 Subject: Name Change Message-ID: <200102151703.KAA10107@home.knm.org> I'm not sure where to put in my $.02 on this, but I think the best thing to do is pick a different name; I like "fresh". my $.02 of course, Mark From jweaver at aens.net Fri Feb 16 05:44:59 2001 From: jweaver at aens.net (John Weaver) Date: Thu, 15 Feb 2001 18:44:59 +0000 (GMT) Subject: Name Change In-Reply-To: <200102151703.KAA10107@home.knm.org> Message-ID: > I'm not sure where to put in my $.02 on this, but I think the best > thing to do is pick a different name; I like "fresh". Not to be militant, but "ssh" works just fine for me. IANAL. There are a few issues that make it look like the company SSH really doesn't have a leg to stand on. In my personal opinion, the term "SSH" has already been diluted. Anymore of my waxings are just preaching to the converted. -- john weaver -- jweaver at aens.net | Systems Administrator From larry.jones at sdrc.com Fri Feb 16 07:55:24 2001 From: larry.jones at sdrc.com (Larry Jones) Date: Thu, 15 Feb 2001 15:55:24 -0500 (EST) Subject: Configure suggestion Message-ID: <200102152055.PAA00515@thor.sdrc.com> I just downloaded and build 2.3.0p1 on BSD/OS 4.0.1 and 4.1 with no problems. Good job, guys! I did notice that although configure looks for both LASTLOG_FILE and _PATH_LASTLOG, it only looks for UTMP_FILE and WTMP_FILE. BSD/OS doesn't define those, but it does define _PATH_UTMP and _PATH_WTMP (in , same as _PATH_LASTLOG), so you may want to have configure check for them, too. (It's not a problem since BSD/OS keeps them in one of the standard places that configure looks when the macros aren't defined, but it would be cleaner.) -Larry Jones The surgeon general should issue a warning about playing with girls. -- Calvin From john at zlilo.com Fri Feb 16 08:14:06 2001 From: john at zlilo.com (john) Date: Thu, 15 Feb 2001 13:14:06 -0800 Subject: openssh-2.3.0p1 installation problem (still) Message-ID: <20010215131406.B3025@pain.cp.net> i posted here a couple days ago with a fairly minor (depending on how you look at it) installation problem and while ive used string and duct tape to fix it, i have not heard anything back about it. the problem is if you ./configure --with-default-path=/yourpath it doesnt seem to actually work. scp was not working for me and after checking the faq, i saw this was my problem as scp was installed to /usr/local/bin. so i made distclean and configured --with-default-path=/bin:/usr/bin:/usr/local/bin and rebuilt. after this didnt work (several times), i followed a suggestion that someone sent to me and i 'ssh [myhost] echo \$PATH'. this was the output: /usr/bin:/bin:/usr/sbin:/sbin i thought i was doing something wrong until i did the same thing on a friend's box and it was the same. how was his scp working? a symlink in /bin. while i knew that would fix the problem, i was avoiding doing that because, well, it should work the RIGHT way. but i did the symlink thing and now it works, but i still think its lame. so i just wanted to know. am i doing something wrong or is this indeed a bug in the configuration/installation? also, if i was doing some strange security lockdown and i really cared what the default path was, i might be upset that this didnt work...as it is, im fine with it working, i just want to know if its something im doing or what. -j From tim at multitalents.net Fri Feb 16 09:39:20 2001 From: tim at multitalents.net (Tim Rice) Date: Thu, 15 Feb 2001 14:39:20 -0800 (PST) Subject: configure.in reorder patch In-Reply-To: Message-ID: On Wed, 14 Feb 2001 mouring at etoh.eviladmin.org wrote: > On Mon, 12 Feb 2001, Tim Rice wrote: > > > > Feb 12 CVS (sort of, see warning below) > > > > I've had to change around some of the code in configure.in > > to get some platforms to compile with the --with-tcp-wrappers option. > > Is there a way to cut down in some of the changes in this patch. We are > getting pretty close to a release (I can say this for sure now =) and I > don't think we can fully test this large of change in such a short time. See if you like this one better. > > - Ben > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- openssh_cvs/configure.in.old Tue Feb 13 17:18:46 2001 +++ openssh_cvs/configure.in Thu Feb 15 12:47:14 2001 @@ -327,6 +327,126 @@ # Checks for header files. AC_CHECK_HEADERS(bstring.h endian.h floatingpoint.h getopt.h lastlog.h limits.h login.h login_cap.h maillock.h netdb.h netgroup.h netinet/in_systm.h paths.h poll.h pty.h regex.h shadow.h security/pam_appl.h sys/bitypes.h sys/bsdtty.h sys/cdefs.h sys/poll.h sys/queue.h sys/select.h sys/stat.h sys/stropts.h sys/sysmacros.h sys/time.h sys/ttcompat.h sys/un.h stdarg.h stddef.h time.h ttyent.h usersec.h util.h utime.h utmp.h utmpx.h vis.h) +# Check whether user wants Kerberos support +KRB4_MSG="no" +AC_ARG_WITH(kerberos4, + [ --with-kerberos4=PATH Enable Kerberos 4 support], + [ + if test "x$withval" != "xno" ; then + + if test "x$withval" != "xyes" ; then + CPPFLAGS="$CPPFLAGS -I${withval}/include" + LDFLAGS="$LDFLAGS -L${withval}/lib" + if test ! -z "$need_dash_r" ; then + LDFLAGS="$LDFLAGS -R${withval}/lib" + fi + if test ! -z "$blibpath" ; then + blibpath="$blibpath:${withval}/lib" + fi + else + if test -d /usr/include/kerberosIV ; then + CPPFLAGS="$CPPFLAGS -I/usr/include/kerberosIV" + fi + fi + + AC_CHECK_HEADERS(krb.h) + AC_CHECK_LIB(krb, main) + if test "$ac_cv_header_krb_h" != yes; then + AC_MSG_WARN([Cannot find krb.h, build may fail]) + fi + if test "$ac_cv_lib_krb_main" != yes; then + AC_MSG_WARN([Cannot find libkrb, build may fail]) + fi + + KLIBS="-lkrb -ldes" + AC_CHECK_LIB(resolv, dn_expand, , ) + KRB4=yes + KRB4_MSG="yes" + AC_DEFINE(KRB4) + fi + ] +) + +# Check whether user wants AFS support +AFS_MSG="no" +AC_ARG_WITH(afs, + [ --with-afs=PATH Enable AFS support], + [ + if test "x$withval" != "xno" ; then + + if test "x$withval" != "xyes" ; then + CPPFLAGS="$CPPFLAGS -I${withval}/include" + LDFLAGS="$LDFLAGS -L${withval}/lib" + fi + + if test -z "$KRB4" ; then + AC_MSG_WARN([AFS requires Kerberos IV support, build may fail]) + fi + + LIBS="$LIBS -lkafs" + if test ! -z "$AFS_LIBS" ; then + LIBS="$LIBS $AFS_LIBS" + fi + AC_DEFINE(AFS) + AFS_MSG="yes" + fi + ] +) +LIBS="$LIBS $KLIBS" + +# Check whether user wants S/Key support +SKEY_MSG="no" +AC_ARG_WITH(skey, + [ --with-skey=PATH Enable S/Key support], + [ + if test "x$withval" != "xno" ; then + + if test "x$withval" != "xyes" ; then + CPPFLAGS="$CPPFLAGS -I${withval}/include" + LDFLAGS="$LDFLAGS -L${withval}/lib" + fi + + AC_DEFINE(SKEY) + LIBS="-lskey $LIBS" + SKEY_MSG="yes" + + AC_CHECK_FUNC(skey_keyinfo, + [], + [ + AC_MSG_ERROR([** Incomplete or missing s/key libraries.]) + ]) + fi + ] +) + +# Check whether user wants TCP wrappers support +TCPW_MSG="no" +AC_ARG_WITH(tcp-wrappers, + [ --with-tcp-wrappers Enable tcpwrappers support], + [ + if test "x$withval" != "xno" ; then + saved_LIBS="$LIBS" + LIBS="-lwrap $LIBS" + AC_MSG_CHECKING(for libwrap) + AC_TRY_LINK( + [ +#include + int deny_severity = 0, allow_severity = 0; + ], + [hosts_access(0);], + [ + AC_MSG_RESULT(yes) + AC_DEFINE(LIBWRAP) + TCPW_MSG="yes" + ], + [ + AC_MSG_ERROR([*** libwrap missing]) + ] + ) + fi + ] +) + dnl Checks for library functions. AC_CHECK_FUNCS(arc4random atexit b64_ntop bcopy bindresvport_sa clock fchown fchmod freeaddrinfo futimes gai_strerror getcwd getaddrinfo getgrouplist getnameinfo getrlimit getrusage getttyent inet_aton inet_ntoa innetgr login_getcapbool md5_crypt memmove mkdtemp on_exit openpty realpath rresvport_af setdtablesize setenv seteuid setlogin setproctitle setreuid setrlimit setsid sigaction sigvec snprintf strerror strlcat strlcpy strmode strsep strtok_r sysconf tcgetpgrp utimes vsnprintf vhangup vis waitpid _getpty __b64_ntop) dnl Checks for time functions @@ -1151,126 +1271,6 @@ ) AC_SUBST(MANTYPE) AC_SUBST(mansubdir) - -# Check whether user wants Kerberos support -KRB4_MSG="no" -AC_ARG_WITH(kerberos4, - [ --with-kerberos4=PATH Enable Kerberos 4 support], - [ - if test "x$withval" != "xno" ; then - - if test "x$withval" != "xyes" ; then - CPPFLAGS="$CPPFLAGS -I${withval}/include" - LDFLAGS="$LDFLAGS -L${withval}/lib" - if test ! -z "$need_dash_r" ; then - LDFLAGS="$LDFLAGS -R${withval}/lib" - fi - if test ! -z "$blibpath" ; then - blibpath="$blibpath:${withval}/lib" - fi - else - if test -d /usr/include/kerberosIV ; then - CPPFLAGS="$CPPFLAGS -I/usr/include/kerberosIV" - fi - fi - - AC_CHECK_HEADERS(krb.h) - AC_CHECK_LIB(krb, main) - if test "$ac_cv_header_krb_h" != yes; then - AC_MSG_WARN([Cannot find krb.h, build may fail]) - fi - if test "$ac_cv_lib_krb_main" != yes; then - AC_MSG_WARN([Cannot find libkrb, build may fail]) - fi - - KLIBS="-lkrb -ldes" - AC_CHECK_LIB(resolv, dn_expand, , ) - KRB4=yes - KRB4_MSG="yes" - AC_DEFINE(KRB4) - fi - ] -) - -# Check whether user wants AFS support -AFS_MSG="no" -AC_ARG_WITH(afs, - [ --with-afs=PATH Enable AFS support], - [ - if test "x$withval" != "xno" ; then - - if test "x$withval" != "xyes" ; then - CPPFLAGS="$CPPFLAGS -I${withval}/include" - LDFLAGS="$LDFLAGS -L${withval}/lib" - fi - - if test -z "$KRB4" ; then - AC_MSG_WARN([AFS requires Kerberos IV support, build may fail]) - fi - - LIBS="$LIBS -lkafs" - if test ! -z "$AFS_LIBS" ; then - LIBS="$LIBS $AFS_LIBS" - fi - AC_DEFINE(AFS) - AFS_MSG="yes" - fi - ] -) -LIBS="$LIBS $KLIBS" - -# Check whether user wants S/Key support -SKEY_MSG="no" -AC_ARG_WITH(skey, - [ --with-skey=PATH Enable S/Key support], - [ - if test "x$withval" != "xno" ; then - - if test "x$withval" != "xyes" ; then - CPPFLAGS="$CPPFLAGS -I${withval}/include" - LDFLAGS="$LDFLAGS -L${withval}/lib" - fi - - AC_DEFINE(SKEY) - LIBS="-lskey $LIBS" - SKEY_MSG="yes" - - AC_CHECK_FUNC(skey_keyinfo, - [], - [ - AC_MSG_ERROR([** Incomplete or missing s/key libraries.]) - ]) - fi - ] -) - -# Check whether user wants TCP wrappers support -TCPW_MSG="no" -AC_ARG_WITH(tcp-wrappers, - [ --with-tcp-wrappers Enable tcpwrappers support], - [ - if test "x$withval" != "xno" ; then - saved_LIBS="$LIBS" - LIBS="$LIBS -lwrap" - AC_MSG_CHECKING(for libwrap) - AC_TRY_LINK( - [ -#include - int deny_severity = 0, allow_severity = 0; - ], - [hosts_access(0);], - [ - AC_MSG_RESULT(yes) - AC_DEFINE(LIBWRAP) - TCPW_MSG="yes" - ], - [ - AC_MSG_ERROR([*** libwrap missing]) - ] - ) - fi - ] -) # Check whether to enable MD5 passwords MD5_MSG="no" From djm at mindrot.org Fri Feb 16 09:39:04 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 16 Feb 2001 09:39:04 +1100 (EST) Subject: SSH2 PATH problem In-Reply-To: <3A8C0911.6D064542@ubs.com> Message-ID: On Thu, 15 Feb 2001, Jean-Marc Beroud wrote: > Hello, > > I have the following behaviour with openssh-2.3.0p1 > > # ssh host 'echo $PATH' (SSH1 protocol, works fine) > /bin:/sbin:/usr/bin:/usr/sbin:/usr/ucb:/usr/opt/SUNWmd/sbin > > # ssh -2 host 'echo $PATH' (force SSH2 protocol, PATH env var is not > set) > > > I can't execute a remote command with the SSH2 protocol. I can't replicate this here - can anyone else? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From tim at multitalents.net Fri Feb 16 09:46:31 2001 From: tim at multitalents.net (Tim Rice) Date: Thu, 15 Feb 2001 14:46:31 -0800 (PST) Subject: SCO 5.0.5 setluid patch In-Reply-To: Message-ID: On Thu, 15 Feb 2001, svaughan wrote: > > Sorry it took me a while to get some free time this week :-) > > > below is the small patch for SCO 5.0.x. to set the luid. I have tested it > out and it seems to work good. I won't have access to a solaris box for a > little while to test out the setauid(), so I didn't include that. > > + AC_CHECK_FUNC(setluid, [AC_DEFINE(HAVE_SCO_SETLUID)]) I think the setluid test should be done in the main AC_CHECK_FUNCS() section and + #ifdef HAVE_SETLUID + /* Sets login uid for accounting*/ + if(setluid(pw->pw_uid) == -1) + perror("Unable to set luid!"); + #endif /* HAVE_SETLUID */ It's not really SCO specific. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mouring at etoh.eviladmin.org Fri Feb 16 10:42:45 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 15 Feb 2001 17:42:45 -0600 (CST) Subject: SSH2 PATH problem In-Reply-To: Message-ID: On Fri, 16 Feb 2001, Damien Miller wrote: > On Thu, 15 Feb 2001, Jean-Marc Beroud wrote: > > > Hello, > > > > I have the following behaviour with openssh-2.3.0p1 > > > > # ssh host 'echo $PATH' (SSH1 protocol, works fine) > > /bin:/sbin:/usr/bin:/usr/sbin:/usr/ucb:/usr/opt/SUNWmd/sbin > > > > # ssh -2 host 'echo $PATH' (force SSH2 protocol, PATH env var is not > > set) > > > > > > I can't execute a remote command with the SSH2 protocol. > > I can't replicate this here - can anyone else? > Nope.. I can't replicate it under the -CURRENT branch under Solaris 7 nor Linux. Nor can I replicate it under 2.1.1 under solaris 2.5.1. Sorry. - Ben From svaughan at asterion.com Fri Feb 16 10:08:40 2001 From: svaughan at asterion.com (svaughan) Date: Thu, 15 Feb 2001 15:08:40 -0800 (PST) Subject: SCO 5.0.5 setluid patch In-Reply-To: Message-ID: Here is an updated patch. Sorry, I thought setluid was SCO specific. > I think the setluid test should be done in the main AC_CHECK_FUNCS() > section and > + #ifdef HAVE_SETLUID > + /* Sets login uid for accounting*/ > + if(setluid(pw->pw_uid) == -1) > + perror("Unable to set luid!"); > + #endif /* HAVE_SETLUID */ > > It's not really SCO specific. Thanks, Sam *** openssh/session.c Sun Feb 11 06:12:08 2001 --- openssh_patch/session.c Thu Feb 15 15:02:49 2001 *************** *** 1030,1035 **** #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) --- 1030,1040 ---- #endif /* WITH_IRIX_ARRAY */ #endif /* WITH_IRIX_JOBS */ + #ifdef HAVE_SETLUID + /* Sets login uid for accounting*/ + if(setluid(pw->pw_uid) == -1) + perror("Unable to set luid!"); + #endif /* HAVE_SETLUID */ /* login(1) is only called if we execute the login shell */ if (options.use_login && command != NULL) *************** *** 333,338 **** dnl Checks for utmpx functions AC_CHECK_FUNCS(endutxent getutxent getutxid getutxline pututxline ) AC_CHECK_FUNCS(setutxent utmpxname) AC_CHECK_FUNC(getuserattr, [AC_DEFINE(HAVE_GETUSERATTR)], --- 333,340 ---- dnl Checks for utmpx functions AC_CHECK_FUNCS(endutxent getutxent getutxid getutxline pututxline ) AC_CHECK_FUNCS(setutxent utmpxname) + + AC_CHECK_FUNC(setluid, [AC_DEFINE(HAVE_SETLUID)]) AC_CHECK_FUNC(getuserattr, [AC_DEFINE(HAVE_GETUSERATTR)], *** openssh/config.h.in Sun Feb 11 09:30:28 2001 --- openssh_patch/config.h.in Thu Feb 15 15:05:41 2001 *************** *** 31,36 **** /* Define if you have SCO protected password database */ #undef HAVE_SCO_PROTECTED_PW /* If your header files don't define LOGIN_PROGRAM, then use this (detected) */ /* from environment and PATH */ #undef LOGIN_PROGRAM_FALLBACK --- 31,39 ---- /* Define if you have SCO protected password database */ #undef HAVE_SCO_PROTECTED_PW + /* Define if you have SCO setluid function */ + #undef HAVE_SETLUID + /* If your header files don't define LOGIN_PROGRAM, then use this (detected) */ /* from environment and PATH */ #undef LOGIN_PROGRAM_FALLBACK From brent at phys.ufl.edu Fri Feb 16 10:50:30 2001 From: brent at phys.ufl.edu (Brent A Nelson) Date: Thu, 15 Feb 2001 18:50:30 -0500 (EST) Subject: SSH-2 hostbased auth Message-ID: Wow, I asked the same question of the openssh list just two days before! The answer is no, openssh doesn't support version 2 hostbased authentication. Markus Friedl responded that he thought it likely that it would be implemented in the release after next, however. If you need it now, you might have to switch back to protocol 1 or use the real SSH product. Thanks, Brent Nelson Sys. Manager Dept. of Physics University of Florida From aggarwaa at cs.pdx.edu Fri Feb 16 10:52:46 2001 From: aggarwaa at cs.pdx.edu (Alok Aggarwal) Date: Thu, 15 Feb 2001 15:52:46 -0800 (PST) Subject: Patch for Authentication By-Pass Vulnerability in OpenSSH-2.3.1 Message-ID: Does someone have the diffs for this development snapshot? In protocol 2, authentication could be bypassed if public key authentication was permitted. This problem does exist only in OpenSSH 2.3.1. OpenSSH 2.3.0 and versions newer than 2.3.1 are not vulnerable to this problem. From shmit at kublai.com Fri Feb 16 10:58:19 2001 From: shmit at kublai.com (Brian Cully) Date: Thu, 15 Feb 2001 18:58:19 -0500 Subject: Kerb5 Support? Message-ID: <5.0.0.25.2.20010215185522.00ab1520@imap.mrf.mail.rcn.net> Hey, I just subscribed to this list, so apologies in advance if this has been asked already (although I haven't found mention in the archives after a cursory search). I notice that there's no Kerb5 support in 2.3.0p1. Is anyone working on getting support in there for v1 and v2 connections, or is this something I'm going to have to do myself? Also, I've just completed SecurID patches for 2.3.0p1 (v1 connects only, ATM, I'm still looking at how to get v2 working on the client and server), who would I go to in order to get 'em checked out and imported into the tree if possible? -bjc From djm at mindrot.org Fri Feb 16 11:02:32 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 16 Feb 2001 11:02:32 +1100 (EST) Subject: SCO 5.0.5 setluid patch In-Reply-To: Message-ID: On Thu, 15 Feb 2001, svaughan wrote: > Here is an updated patch. Sorry, I thought setluid was SCO specific. I have modified your patch a little. Can you please give the below one a try? It does not try to do setluid for non-OpenServer systems. From docs.sco.com it says that Unixware also offers the get/setluid syscalls, but they will always fail. Index: configure.in =================================================================== RCS file: /var/cvs/openssh/configure.in,v retrieving revision 1.241 diff -u -r1.241 configure.in --- configure.in 2001/02/15 23:18:12 1.241 +++ configure.in 2001/02/16 00:00:46 @@ -234,6 +234,7 @@ AC_DEFINE(HAVE_SCO_PROTECTED_PW) AC_DEFINE(DISABLE_SHADOW) AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) + AC_CHECK_FUNCS(getluid setluid) ;; *-*-sco3.2v5*) AC_DEFINE(USE_PIPES) @@ -247,9 +248,9 @@ AC_DEFINE(HAVE_SCO_PROTECTED_PW) AC_DEFINE(DISABLE_SHADOW) AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) + AC_CHECK_FUNCS(getluid setluid) ;; *-dec-osf*) -# This is untested if test ! -z "USE_SIA" ; then AC_MSG_CHECKING(for Digital Unix Security Integration Architecture) if test -f /etc/sia/matrix.conf; then Index: session.c =================================================================== RCS file: /var/cvs/openssh/session.c,v retrieving revision 1.75 diff -u -r1.75 session.c --- session.c 2001/02/15 00:51:32 1.75 +++ session.c 2001/02/16 00:00:46 @@ -881,7 +881,6 @@ } #endif /* USE_PAM */ - #ifdef HAVE_CYGWIN void copy_environment(char ***env, int *envsize) { @@ -1117,6 +1116,12 @@ # endif /* HAVE_LOGIN_CAP */ } #endif /* HAVE_OSF_SIA */ + +#if defined(HAVE_GETLUID) && defined(HAVE_SETLUID) + /* Sets login uid for accounting */ + if (getluid() == -1 && setluid(pw->pw_uid) == -1) + error("setluid: %s", strerror(errno)); +#endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */ #ifdef HAVE_CYGWIN if (is_winnt) -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From tom at avatar.itc.nrcs.usda.gov Fri Feb 16 11:15:25 2001 From: tom at avatar.itc.nrcs.usda.gov (Tom Rudnick) Date: Thu, 15 Feb 2001 17:15:25 -0700 (MST) Subject: patches for UnixWare v2.x pty (misc.c,configure.in) In-Reply-To: from "Damien Miller" at Feb 14, 2001 12:40:13 AM Message-ID: <200102160015.RAA26978@avatar.itc.nrcs.usda.gov> > > i don't understand, why is SA_RESTART is needed? > > On Unixware 2.x grantpt (pty.c) was getting interrupted by SIGCHLD. > On sysv systems syscalls aren't restarted by default after being > interrupted by a signal. It is the default for BSD signal, so it makes > sense to have it in there. > > -d > what is the status of committing this patch to the tree? Let me know what is required of me. :| The configure.in patch has devolved into adding USE_PIPES to the *-*-sysv4.2* and *-*-sysv5* sections I'xpect. Tim, comments? -Tom -- ----------------/---------------------------------------------- Tom Rudnick | USDA Natural Resources Conservation Service Fort Collins,CO | tom at avatar.itc.nrcs.usda.gov (970) 295-5427 ** The 3rd Millennium started Jan 1, 2001. see: ** ** http://aa.usno.navy.mil/AA/faq/docs/millennium.html ** -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From sxw at dcs.ed.ac.uk Fri Feb 16 11:18:36 2001 From: sxw at dcs.ed.ac.uk (Simon Wilkinson) Date: Fri, 16 Feb 2001 00:18:36 GMT Subject: Kerb5 Support? In-Reply-To: Brian Cully's message of Thu, 15 Feb 2001 18:58:19 -0500 Message-ID: <200102160018.AAA12703@canna.dcs.ed.ac.uk> > I notice that there's no Kerb5 support in 2.3.0p1. Is anyone > working on getting support in there for v1 and v2 connections, or is this > something I'm going to have to do myself? I'm maintaining some patches for Kerberos v5 support in the version 1 protocol. They're available from http://www.sxw.org.uk/computing/patches/ These are being used successfully built against MIT Kerberos (Heimdal should also work, but hasn't been tested recently). AFAIK there is no support for Kerberos in the version 2 protocol currently. There is however, an Internet Draft describing how such support could be implemented (for GSSAPI). I'm currently investigating this. Cheers, Simon From tim at multitalents.net Fri Feb 16 11:42:19 2001 From: tim at multitalents.net (Tim Rice) Date: Thu, 15 Feb 2001 16:42:19 -0800 (PST) Subject: SSH2 PATH problem In-Reply-To: Message-ID: On Fri, 16 Feb 2001, Damien Miller wrote: > On Thu, 15 Feb 2001, Jean-Marc Beroud wrote: > > > Hello, > > > > I have the following behaviour with openssh-2.3.0p1 > > > > # ssh host 'echo $PATH' (SSH1 protocol, works fine) > > /bin:/sbin:/usr/bin:/usr/sbin:/usr/ucb:/usr/opt/SUNWmd/sbin > > > > # ssh -2 host 'echo $PATH' (force SSH2 protocol, PATH env var is not > > set) > > > > > > I can't execute a remote command with the SSH2 protocol. > > I can't replicate this here - can anyone else? I can. openssh-2.3.0p1 on Solaris 8 > > -d > > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Fri Feb 16 11:47:53 2001 From: tim at multitalents.net (Tim Rice) Date: Thu, 15 Feb 2001 16:47:53 -0800 (PST) Subject: patches for UnixWare v2.x pty (misc.c,configure.in) In-Reply-To: <200102160015.RAA26978@avatar.itc.nrcs.usda.gov> Message-ID: On Thu, 15 Feb 2001, Tom Rudnick wrote: > what is the status of committing this patch to the tree? Let me > know what is required of me. :| > > The configure.in patch has devolved into adding USE_PIPES to the > *-*-sysv4.2* and *-*-sysv5* sections I'xpect. Tim, comments? Yes, add AC_DEFINE(USE_PIPES) to those sections. > > -Tom > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From djm at mindrot.org Fri Feb 16 11:50:56 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 16 Feb 2001 11:50:56 +1100 (EST) Subject: SSH2 PATH problem In-Reply-To: Message-ID: On Thu, 15 Feb 2001, Tim Rice wrote: > > > # ssh -2 host 'echo $PATH' (force SSH2 protocol, PATH env var is not > > > set) > > > > > > > > > I can't execute a remote command with the SSH2 protocol. > > > > I can't replicate this here - can anyone else? > > I can. > openssh-2.3.0p1 on Solaris 8 I can't immediatly see how this can happen :( Can you try running a "sshd -d -d -p 2222" and logging into it with "ssh -p 2222"? I am interested in the output from the client. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Fri Feb 16 11:53:15 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 16 Feb 2001 11:53:15 +1100 (EST) Subject: patches for UnixWare v2.x pty (misc.c,configure.in) In-Reply-To: Message-ID: On Thu, 15 Feb 2001, Tim Rice wrote: > On Thu, 15 Feb 2001, Tom Rudnick wrote: > > > what is the status of committing this patch to the tree? Let me > > know what is required of me. :| > > > > The configure.in patch has devolved into adding USE_PIPES to the > > *-*-sysv4.2* and *-*-sysv5* sections I'xpect. Tim, comments? > > Yes, add AC_DEFINE(USE_PIPES) to those sections. Done. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From mouring at etoh.eviladmin.org Fri Feb 16 12:54:55 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 15 Feb 2001 19:54:55 -0600 (CST) Subject: patches for UnixWare v2.x pty (misc.c,configure.in) In-Reply-To: Message-ID: On Fri, 16 Feb 2001, Damien Miller wrote: > On Thu, 15 Feb 2001, Tim Rice wrote: > > > On Thu, 15 Feb 2001, Tom Rudnick wrote: > > > > > what is the status of committing this patch to the tree? Let me > > > know what is required of me. :| > > > > > > The configure.in patch has devolved into adding USE_PIPES to the > > > *-*-sysv4.2* and *-*-sysv5* sections I'xpect. Tim, comments? > > > > Yes, add AC_DEFINE(USE_PIPES) to those sections. > > Done. > And about the RA_RESTART in the mysignal() ? - Ben From djm at mindrot.org Fri Feb 16 12:02:28 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 16 Feb 2001 12:02:28 +1100 (EST) Subject: patches for UnixWare v2.x pty (misc.c,configure.in) In-Reply-To: Message-ID: On Thu, 15 Feb 2001 mouring at etoh.eviladmin.org wrote: > And about the RA_RESTART in the mysignal() ? Markus and Kevin had some issues with that - can either of you comment? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From svaughan at asterion.com Fri Feb 16 11:59:48 2001 From: svaughan at asterion.com (svaughan) Date: Thu, 15 Feb 2001 16:59:48 -0800 (PST) Subject: SCO 5.0.5 setluid patch In-Reply-To: Message-ID: This worked just fine for me on SCO 5.0.5. I did have to add the #undef HAVE_GETLUID and HAVE_SETLUID to config.h.in for it to compile and work. (should I need to do this?) Sam On Fri, 16 Feb 2001, Damien Miller wrote: > On Thu, 15 Feb 2001, svaughan wrote: > > > Here is an updated patch. Sorry, I thought setluid was SCO specific. > > I have modified your patch a little. Can you please give the below one > a try? > > It does not try to do setluid for non-OpenServer systems. From docs.sco.com > it says that Unixware also offers the get/setluid syscalls, but they will > always fail. > > > Index: configure.in > =================================================================== > RCS file: /var/cvs/openssh/configure.in,v > retrieving revision 1.241 > diff -u -r1.241 configure.in > --- configure.in 2001/02/15 23:18:12 1.241 > +++ configure.in 2001/02/16 00:00:46 > @@ -234,6 +234,7 @@ > AC_DEFINE(HAVE_SCO_PROTECTED_PW) > AC_DEFINE(DISABLE_SHADOW) > AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) > + AC_CHECK_FUNCS(getluid setluid) > ;; > *-*-sco3.2v5*) > AC_DEFINE(USE_PIPES) > @@ -247,9 +248,9 @@ > AC_DEFINE(HAVE_SCO_PROTECTED_PW) > AC_DEFINE(DISABLE_SHADOW) > AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) > + AC_CHECK_FUNCS(getluid setluid) > ;; > *-dec-osf*) > -# This is untested > if test ! -z "USE_SIA" ; then > AC_MSG_CHECKING(for Digital Unix Security Integration Architecture) > if test -f /etc/sia/matrix.conf; then > Index: session.c > =================================================================== > RCS file: /var/cvs/openssh/session.c,v > retrieving revision 1.75 > diff -u -r1.75 session.c > --- session.c 2001/02/15 00:51:32 1.75 > +++ session.c 2001/02/16 00:00:46 > @@ -881,7 +881,6 @@ > } > #endif /* USE_PAM */ > > - > #ifdef HAVE_CYGWIN > void copy_environment(char ***env, int *envsize) > { > @@ -1117,6 +1116,12 @@ > # endif /* HAVE_LOGIN_CAP */ > } > #endif /* HAVE_OSF_SIA */ > + > +#if defined(HAVE_GETLUID) && defined(HAVE_SETLUID) > + /* Sets login uid for accounting */ > + if (getluid() == -1 && setluid(pw->pw_uid) == -1) > + error("setluid: %s", strerror(errno)); > +#endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */ > > #ifdef HAVE_CYGWIN > if (is_winnt) > > > > -- > | Damien Miller \ ``E-mail attachments are the poor man's > | http://www.mindrot.org / distributed filesystem'' - Dan Geer > > From djm at mindrot.org Fri Feb 16 12:09:30 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 16 Feb 2001 12:09:30 +1100 (EST) Subject: SCO 5.0.5 setluid patch In-Reply-To: Message-ID: On Thu, 15 Feb 2001, svaughan wrote: > > > This worked just fine for me on SCO 5.0.5. > > I did have to add the #undef HAVE_GETLUID and HAVE_SETLUID to config.h.in > for it to compile and work. (should I need to do this?) or you can run autoheader if you have autoconf installed -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From Markus.Friedl at informatik.uni-erlangen.de Fri Feb 16 19:24:20 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 16 Feb 2001 09:24:20 +0100 Subject: patches for UnixWare v2.x pty (misc.c,configure.in) In-Reply-To: ; from djm@mindrot.org on Fri, Feb 16, 2001 at 12:02:28PM +1100 References: Message-ID: <20010216092420.C27630@faui02.informatik.uni-erlangen.de> On Fri, Feb 16, 2001 at 12:02:28PM +1100, Damien Miller wrote: > On Thu, 15 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > And about the RA_RESTART in the mysignal() ? > > Markus and Kevin had some issues with that - can either of you comment? don't use RA_RESTART in clientloop, since select MUST be interrupted by SIGWINCH. -m From djm at mindrot.org Fri Feb 16 19:53:53 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 16 Feb 2001 19:53:53 +1100 (EST) Subject: patches for UnixWare v2.x pty (misc.c,configure.in) In-Reply-To: <20010216092420.C27630@faui02.informatik.uni-erlangen.de> Message-ID: On Fri, 16 Feb 2001, Markus Friedl wrote: > > > And about the RA_RESTART in the mysignal() ? > > > > Markus and Kevin had some issues with that - can either of you comment? > > don't use RA_RESTART in clientloop, since select MUST be > interrupted by SIGWINCH. I am pretty sure that SA_RESTART doesn't affect select. This is supported by Stevens and the Solaris manpages. It also seems to work ok when I try it (SIGWINCH is received and processed). -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From ylo at ssh.com Fri Feb 16 21:51:06 2001 From: ylo at ssh.com (Tatu Ylonen) Date: Fri, 16 Feb 2001 12:51:06 +0200 Subject: ssh(R) trademark issues: comments and proposal Message-ID: <200102161051.MAA09237@mystery.acr.fi> I'd like to address several issues raised by people in relation to my notice of the ssh(R) trademark to the OpenSSH group. Also, I would like to make a proposal to the community for resolving this issue (included at the end). First, I'll answer a number of questions and arguments presented in the discussion. > "the SSH Corp trademark registration in the US is for a logo only" It is for the lowercase word "ssh" (I was mistaken earlier in saying that it was for the uppercase word "SSH"). As many people obviously know, trademark registrations in the USA are a matter of public record and it is open to anyone to review the details of SSH Corp's trademark portfolio. Under US law, a trademark registration entitles the owner to exclusive use of the trademark as it is registered, in relation to the goods and/or services for which it is registered. Trademark infringement occurs when another person uses the same, or a substantially identical mark, for the same or related goods or services, in a manner which is likely to cause consumer confusion. Consequently, use of the uppercase word "SSH" or a name containing the "ssh" or "SSH" mark will likely amount to trademark infringement under US law, if it is in relation to goods or services within the same field of use covered by our ssh(R) trademark. Of course, there are many possible non-infringing uses of "SSH", for example, anyone might have a brand of chocolade called "SSH". > "A license was granted in 1995 that allows free use of the trademarks" This is not accurate, but refers to the following language in ssh-1.2.12 COPYING file: As far as I am concerned, the code I have written for this software can be used freely for any purpose. Any derived versions of this software must be clearly marked as such, and if the derived work is incompatible with the protocol description in the RFC file, it must be called by a name other than "ssh" or "Secure Shell". First, this is a copyright license ("the CODE can be used..."), with an additional restriction on naming. It is not a trademark license. Also, this text is from the COPYING file from ssh-1.2.12, dated Nov 17, 1995. The trademark claims were made in 1996 (ssh-1.2.13 was the first release claiming them, released on Feb 11, 1996), and this license provision would not have covered them anyway. Ever since, our policy has been not to allow unauthorized use of the trademarks. The trademark claims have been made consistently in every release ever since. > "no-one has ever been notified of infringement" For example, I notified Van Dyke of the trademark a few years ago when they used the SSH mark on their web site inappropriately. We discussed it, they were very co-operative, and immediately added trademark markings and acknowledgement on their website. Issue solved. (They were not using it in a product name.) Basically, anyone we have ever really encountered in the marketplace has either been notified or is a licensee of ours. > "F-Secure SSH has been using the name for years" F-Secure (formerly Data Fellows) is our distributor/VAR, and they are using the SSH trademark in their product name under a separate written trademark license agreement. All of the F-Secure SSH products are SSH Communication Security Corp's products, some verbatim and some with modifications by F-Secure. > (reference to FiSSH, TTSSH, Top Gun ssh, etc.) These are all non-commercial academic projects made at universities. We have never really encountered any one of these in the marketplace. We have tried to notify commercial people who have been using the trademark inappropriately. OpenSSH was the first non-commercial implementation to raise to the radar screen. > "why did you notify OpenSSH now" The reason OpenSSH was contacted now was that they have only become more visible during the last months, and I have recently seen a significant increase in e-mails confusing the meaning of the SSH trademarks and using them inappropriately. I have also recently received quite a few e-mails confusing OpenSSH as my product. > "how about the 'ssh' command name under Unix/Linux?" This relates to the proposal I want to make. Basically, I am willing to work out a way that will allow anyone to use the "ssh" command name on Unix/Linux. It appears that there are ways to do it without exposing our trademarks to unnecessary risk. The arrangement I am proposing would be as follows. - We (SSH Corp) would allow the use of "ssh" (and sshd, etc) as a command name on Unix/Linux under the following restrictions: - Any product where the command name "ssh" is used must only be licensed under a valid license (i.e., must not be in the public domain). E.g. BSD license, GPL, and normal commercial licenses would all be ok. - An acknowledgement of our ownership of the ssh(R) and Secure Shell(TM) trademarks must be included in the software (help text, documentation, license). It would not need to be printed out every time the program is normally run, but would need to be included in e.g. in an appropriate place on man pages and in help texts. - The SSH Corp trademarks cannot be used in product names without a separate trademark license from us (which we would not normally grant, unless we see a valid business case for it, and then only for products using a compatible protocol). - A new unencumbered name is created for the protocol, which can be used by any vendor without creating confusion. The IETF standard would be renamed to use the new protocol name, and the community would work to cease using "SSH" as a protocol name and would instead start using the new name. The new name would need to be unencumbered, and the xx.com, xx.net, and xx.org domain names would be made to permanently point to e.g. the IETF main page. My own proposal would be to change the name to SECSH, provided that Van Dyke is willing to contribute their currently unused secsh.com domain name for this purpose. We would be willing to contribute our secsh.org and secsh.net domains on the same basis. - We would submit an official statement to the IETF that we will make no trademark claims about the "bits on the wire" in the protocol (e.g., the protocol version strings or the various names used in the protocol). - We would need to reach agreement with the OpenSSH group to change their product name and to otherwise cease using the SSH trademarks inappropriately. We appreciate that some people have brought the non-commercial university group use to our attention. We are carefully reviewing this situation. Let's discuss the exact terms if I get a preliminary "ok, looks fine, let's try to get this resolved along those lines" from the community and the relevant parties. Please let us know what you think. Best regards, Tatu Ylonen Chairman and CTO, SSH Communications Security Corp PS. For reference, if someone hasn't seen it yet, I'll include my original e-mail to the OpenSSH mailing list. >From ylo Wed Feb 14 03:36:19 +0200 2001 From: Tatu Ylonen To: openssh-unix-dev at mindrot.org Subject: SSH trademarks and the OpenSSH product name Organization: SSH Communications Security, Finland Friends, Sorry to write this to a developer mailing list. I have already approached some OpenSSH/OpenBSD core members on this, including Markus Friedl, Theo de Raadt, and Niels Provos, but they have chosen not to bring the issue up on the mailing list. I am not aware of any other forum where I would reach the OpenSSH developers, so I will post this here. As you know, I have been using the SSH trademark as the brand name of my SSH (Secure Shell) secure remote login product and related technology ever since I released the first version in July 1995. I have explicitly claimed them as trademarks at least from early 1996. In December 1995, I started SSH Communications Security Corp to support and further develop the SSH (Secure Shell) secure remote login products and to develop other network security solutions (especially in the IPSEC and PKI areas). SSH Communications Security Corp is now publicly listed in the Helsinki Exchange, employs 180 people working in various areas of cryptographic network security, and our products are distributed directly and indirectly by hundreds of licensed distributors and OEMs worldwide using the SSH brand name. There are several million users of products that we have licensed under the SSH brand. To protect the SSH trademark I (or SSH Communications Security Corp, to be more accurate) registered the SSH mark in the United States and European Union in 1996 (others pending). We also have a registration pending on the Secure Shell mark. The SSH mark is a significant asset of SSH Communications Security and the company strives to protect its valuable rights in the SSH? name and mark. SSH Communications Security has made a substantial investment in time and money in its SSH mark, such that end users have come to recognize that the mark represents SSH Communications Security as the source of the high quality products offered under the mark. This resulting goodwill is of vital importance to SSH Communications Security Corp. We have also been distributing free versions of SSH Secure Shell under the SSH brand since 1995. The latest version, ssh-2.4.0, is free for any use on the Linux, FreeBSD, NetBSD, and OpenBSD operating systems, as well as for universities and charity organizations, and for personal hobby/recreational use by individuals. We have been including trademark markings in SSH distributions, on the www.ssh.fi, www.ssh.com, and www.ssh.org web sites, IETF standards documents, license/readme files and product packaging long before the OpenSSH group was formed. Accordingly, we would like you to understand the importance of the SSH mark to us, and, by necessity, our need to protect the trademark against the unauthorized use by others. Many of you are (and the initiators of the OpenSSH group certainly should have been) well aware of the existence of the trademark. Some of the OpenBSD/OpenSSH developers/sponsors have also received a formal legal notice about the infringement earlier. I have started receiving a significant amount of e-mail where people are confusing OpenSSH as either my product or my company's product, or are confusing or misrepresenting the meaning of the SSH and Secure Shell trademarks. I have also been informed of several recent press articles and outright advertisements that are further confusing the origin and meaning of the trademark. The confusion is made even worse by the fact that OpenSSH is also a derivative of my original SSH Secure Shell product, and it still looks very much like my product (without my approval for any of it, by the way). The old SSH1 protocol and implementation are known to have fundamental security problems, some of which have been described in recent CERT vulnerability notices and various conference papers. OpenSSH is doing a disservice to the whole Internet security community by lengthing the life cycle of the fundamentally broken SSH1 protocols. The use of the SSH trademark by OpenSSH is in violation of my company's intellectual property rights, and is causing me, my company, our licensees, and our products considerable financial and other damage. I would thus like to ask you to change the name OpenSSH to something else that doesn't infringe the SSH or Secure Shell trademarks, basically to something that is clearly different and doesn't cause confusion. Also, please understand that I have nothing against independent implementations of the SSH Secure Shell protocols. I started and fully support the IETF SECSH working group in its standardization efforts, and we have offered certain licenses to use the SSH mark to refer to the protocol and to indicate that a product complies with the standard. Anyone can implement the IETF SECSH working group standard without requiring any special licenses from us. It is the use of the "SSH" and "Secure Shell" trademarks in product names or in otherwise confusing manner that we wish to prevent. Please also try to look at this from my viewpoint. I developed SSH (Secure Shell), started using the name for it, established a company using the name, all of our products are marketed using the SSH brand, and we have created a fairly widely known global brand using the name. Unauthorized use of the SSH mark by the OpenSSH group is threathening to destroy everything I have built on it during the last several years. I want to be able to continue using the SSH and Secure Shell names as identifying my own and my company's products and technologies, which the unlawful use of the SSH name by OpenSSH is making very hard. Therefore, I am asking you to please choose another name for the OpenSSH product and stop using the SSH mark in your product name and in otherwise confusing manner. Regards, Tatu Ylonen SSH Communications Security http://www.ssh.com/ SSH IPSEC Toolkit http://www.ipsec.com/ SSH(R) Secure Shell(TM) http://www.ssh.com/products/ssh From jean-marc.beroud at ubs.com Fri Feb 16 22:40:53 2001 From: jean-marc.beroud at ubs.com (Jean-Marc Beroud) Date: Fri, 16 Feb 2001 12:40:53 +0100 Subject: SSH2 PATH problem References: Message-ID: <3A8D11C5.3F8F4723@ubs.com> djm at mindrot.org wrote: > > On Thu, 15 Feb 2001, Tim Rice wrote: > > > > > # ssh -2 host 'echo $PATH' (force SSH2 protocol, PATH env var is not > > > > set) > > > > > > > > > > > > I can't execute a remote command with the SSH2 protocol. > > > > > > I can't replicate this here - can anyone else? > > > > I can. > > openssh-2.3.0p1 on Solaris 8 > > I can't immediatly see how this can happen :( > > Can you try running a "sshd -d -d -p 2222" and logging into it with > "ssh -p 2222"? I am interested in the output from the client. The client get this error: select: Bad file number BTW I use openssh on Solaris 7 (compiled with gcc 2.95.2) Greets, /jm From paulo at nlink.com.br Sat Feb 17 00:25:36 2001 From: paulo at nlink.com.br (Paulo Fragoso) Date: Fri, 16 Feb 2001 11:25:36 -0200 (EDT) Subject: SSH-2 hostbased auth In-Reply-To: Message-ID: Thanks for answer, I've subscribed since yesterday. On Thu, 15 Feb 2001, Brent A Nelson wrote: > Wow, I asked the same question of the openssh list just two days before! > > The answer is no, openssh doesn't support version 2 hostbased > authentication. Markus Friedl responded that he thought it likely that it > would be implemented in the release after next, however. > > If you need it now, you might have to switch back to protocol 1 or use the > real SSH product. > > Thanks, > > Brent Nelson > Sys. Manager > Dept. of Physics > University of Florida > > -- __O _-\<,_ Why drive when you can bike? (_)/ (_) From stevesk at sweden.hp.com Sat Feb 17 00:59:57 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Fri, 16 Feb 2001 14:59:57 +0100 (MET) Subject: patches for UnixWare v2.x pty (misc.c,configure.in) In-Reply-To: Message-ID: On Fri, 16 Feb 2001, Damien Miller wrote: : On Fri, 16 Feb 2001, Markus Friedl wrote: : > > Markus and Kevin had some issues with that - can either of you comment? : > : > don't use RA_RESTART in clientloop, since select MUST be : > interrupted by SIGWINCH. : : I am pretty sure that SA_RESTART doesn't affect select. This is : supported by Stevens and the Solaris manpages. It also seems to work : ok when I try it (SIGWINCH is received and processed). it's my understanding that we can't have select() automatically restarted in clientloop, because we won't then get to check the SIGWINCH handler flag immediately. this is what hp-ux 11.0 select() says: [EINTR] The select() function was interrupted before any of the selected events occurred and before the timeout interval expired. If SA_RESTART has been set for the interrupting signal, it is implementation-dependent whether select() restarts or returns with EINTR. and hp-ux select *does* restart select when SA_RESTART. also, i changed the SIGWINCH handler to use mysignal (without SA_RESTART) and it fixed the problem noticed by itojun about having to enter a character before SIGWINCH was processed. that's interesting. so if we plan to move signal()->mysignal() everywhere, we can't just always set SA_RESTART. From djm at mindrot.org Sat Feb 17 01:14:58 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 17 Feb 2001 01:14:58 +1100 (EST) Subject: patches for UnixWare v2.x pty (misc.c,configure.in) In-Reply-To: Message-ID: On Fri, 16 Feb 2001, Kevin Steves wrote: > it's my understanding that we can't have select() automatically > restarted in clientloop, because we won't then get to check the SIGWINCH > handler flag immediately. > > this is what hp-ux 11.0 select() says: > > [EINTR] The select() function was interrupted before any > of the selected events occurred and before the > timeout interval expired. If SA_RESTART has been > set for the interrupting signal, it is > implementation-dependent whether select() > restarts or returns with EINTR. > > and hp-ux select *does* restart select when SA_RESTART. Damn. Solaris & Linux don't, I suspect that SCO doesn't either. We might have to make it platform specific - we can't go wrapping every syscall in while ret==EINTR loops. > also, i changed the SIGWINCH handler to use mysignal (without > SA_RESTART) and it fixed the problem noticed by itojun about having to > enter a character before SIGWINCH was processed. that's interesting. Are you sure? Mine started working correctly when I updated all my systems the other day - I thought that this was due to Theo's twiddling with the clientloop.c stuff. > so if we plan to move signal()->mysignal() everywhere, we can't just > always set SA_RESTART. Could we set it by signal? "if (signum == SIGCHLD) flags |= SA_RESTART"? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From gert at greenie.muc.de Sat Feb 17 01:15:05 2001 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 16 Feb 2001 15:15:05 +0100 Subject: CVS and AIX Message-ID: <20010216151505.A12060@greenie.muc.de> Hi, trying "current CVS" on AIX 4.3.3, yields: gcc -O2 -Wall -I/usr/local/include -I/gnulocal/include -I/gnu/include -I. -I./openbsd-compat -I. -DETCDIR=\"/etc\" -D_PATH_SSH_PROGRAM=\"/gnu/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/gnu/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/gnu/libexec/sftp-server\" -DHAVE_CONFIG_H -c auth.c auth.c: In function `allowed_user': auth.c:145: warning: implicit declaration of function `loginrestrictions' auth.c:145: `S_RLOGIN' undeclared (first use in this function) auth.c:145: (Each undeclared identifier is reported only once auth.c:145: for each function it appears in.) gmake: *** [auth.o] Error 1 S_RLOGIN is declared in /usr/include/login.c. config.h has "#define HAVE_LOGIN_H 1", but the #include statement at top of auth.c includes "./login.c" due to the -I. line. Why do we need -I. ? Shouldn't those things be included with #include "something.h", as opposed to #include ? Should we rename ./login.h to ssh-login.h? 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 Sat Feb 17 01:16:01 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 17 Feb 2001 01:16:01 +1100 (EST) Subject: SSH2 PATH problem In-Reply-To: <3A8D11C5.3F8F4723@ubs.com> Message-ID: On Fri, 16 Feb 2001, Jean-Marc Beroud wrote: > > Can you try running a "sshd -d -d -p 2222" and logging into it with > > "ssh -p 2222"? I am interested in the output from the client. > > The client get this error: > > select: Bad file number > > BTW I use openssh on Solaris 7 (compiled with gcc 2.95.2) Could you send _all_ the output? Thanks, Damien Miller -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From gert at greenie.muc.de Sat Feb 17 01:20:13 2001 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 16 Feb 2001 15:20:13 +0100 Subject: CVS and AIX In-Reply-To: <20010216151505.A12060@greenie.muc.de>; from Gert Doering on Fri, Feb 16, 2001 at 03:15:05PM +0100 References: <20010216151505.A12060@greenie.muc.de> Message-ID: <20010216152013.C11830@greenie.muc.de> Hi, On Fri, Feb 16, 2001 at 03:15:05PM +0100, Gert Doering wrote: > config.h has "#define HAVE_LOGIN_H 1", but the #include > statement at top of auth.c includes "./login.c" due to the -I. line. > > Why do we need -I. ? Shouldn't those things be included with > #include "something.h", as opposed to #include ? > > Should we rename ./login.h to ssh-login.h? login.h is only included from session.c - renaming it to ssh-login.h and changing session.c makes it compile... 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 Sat Feb 17 01:20:59 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Fri, 16 Feb 2001 15:20:59 +0100 (MET) Subject: patches for UnixWare v2.x pty (misc.c,configure.in) In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Damien Miller wrote: : > and hp-ux select *does* restart select when SA_RESTART. : : Damn. Solaris & Linux don't, I suspect that SCO doesn't either. : : We might have to make it platform specific - we can't go wrapping : every syscall in while ret==EINTR loops. : : > also, i changed the SIGWINCH handler to use mysignal (without : > SA_RESTART) and it fixed the problem noticed by itojun about having to : > enter a character before SIGWINCH was processed. that's interesting. : : Are you sure? Mine started working correctly when I updated all my : systems the other day - I thought that this was due to Theo's twiddling : with the clientloop.c stuff. you're right, it works with just signal() as well. i didn't know it had been fixed. : > so if we plan to move signal()->mysignal() everywhere, we can't just : > always set SA_RESTART. : : Could we set it by signal? "if (signum == SIGCHLD) flags |= SA_RESTART"? yes, let's do that. i'll commit a change shortly. From james.mcininch at cereon.com Sat Feb 17 01:50:43 2001 From: james.mcininch at cereon.com (James D. McIninch) Date: Fri, 16 Feb 2001 09:50:43 -0500 Subject: Regarding Trademark Dispute. Message-ID: <3A8D3E43.4CA0BCA6@cereon.com> I received the following e-mail in response to an e-mail I had sent to SSH communications questioning the wisdom of their requesting OpenSSH to change it's name. Contained in the message is that statement that SSH Communications did not exert their trademark rights earlier becuase it's only recently that OpenSSH has become more visible. In the United States, this would invalidate the trademark because the US requires that a trademark holder exercise due dilligence in protecting the mark -- and that due dilligence has always been intrepretted as notifying infringers immediately of the infringment and making an claim if the infringement is not stopped. Any lapse in exercising the rights is interpretted, under US Law, as an abandonment of the mark. Please find attached the response from SSH that I received. If the matter should come to court, it should be sufficient evidence that SSH is no longer under trademark protection: Received: by ems2165-01.monsanto.com id <01C09823.2677DA00 at ems2165-01.monsanto.com>; Fri, 16 Feb 2001 09:17:10-0500 Message-ID: <8D7A3D2453C7D2119CD800A0C9EAF09702750899 at ems2165-01.monsanto.com> From: "ylo at mystery.acr.fi at INTERNET" To: james.mcininch at cereon.com Subject: OpenSSH and trademark Date: Fri, 16 Feb 2001 09:13:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mozilla-Status: 8003 X-Mozilla-Status2: 00000000 X-UIDL: AAQmIUnAAAwlwreygCA2cGh0HPFJ9oXj Hi, Please find my comments and proposal for resolving the issue below. Best regards, Tatu Ylonen -- SSH Communications Security http://www.ssh.com/ SSH IPSEC Toolkit http://www.ipsec.com/ SSH(R) Secure Shell(TM) http://www.ssh.com/products/ssh To: openssh-unix-dev, ssh at clinet,fi, ietf-ssh at clinet.fi mailing lists Subject: ssh(R) trademark issues: comments and proposal I'd like to address several issues raised by people in relation to my notice of the ssh(R) trademark to the OpenSSH group. Also, I would like to make a proposal to the community for resolving this issue (included at the end). First, I'll answer a number of questions and arguments presented in the discussion. > "the SSH Corp trademark registration in the US is for a logo only" It is for the lowercase word "ssh" (I was mistaken earlier in saying that it was for the uppercase word "SSH"). As many people obviously know, trademark registrations in the USA are a matter of public record and it is open to anyone to review the details of SSH Corp's trademark portfolio. Under US law, a trademark registration entitles the owner to exclusive use of the trademark as it is registered, in relation to the goods and/or services for which it is registered. Trademark infringement occurs when another person uses the same, or a substantially identical mark, for the same or related goods or services, in a manner which is likely to cause consumer confusion. Consequently, use of the uppercase word "SSH" or a name containing the "ssh" or "SSH" mark will likely amount to trademark infringement under US law, if it is in relation to goods or services within the same field of use covered by our ssh(R) trademark. Of course, there are many possible non-infringing uses of "SSH", for example, anyone might have a brand of chocolade called "SSH". > "A license was granted in 1995 that allows free use of the trademarks" This is not accurate, but refers to the following language in ssh-1.2.12 COPYING file: As far as I am concerned, the code I have written for this software can be used freely for any purpose. Any derived versions of this software must be clearly marked as such, and if the derived work is incompatible with the protocol description in the RFC file, it must be called by a name other than "ssh" or "Secure Shell". First, this is a copyright license ("the CODE can be used..."), with an additional restriction on naming. It is not a trademark license. Also, this text is from the COPYING file from ssh-1.2.12, dated Nov 17, 1995. The trademark claims were made in 1996 (ssh-1.2.13 was the first release claiming them, released on Feb 11, 1996), and this license provision would not have covered them anyway. Ever since, our policy has been not to allow unauthorized use of the trademarks. The trademark claims have been made consistently in every release ever since. > "no-one has ever been notified of infringement" For example, I notified Van Dyke of the trademark a few years ago when they used the SSH mark on their web site inappropriately. We discussed it, they were very co-operative, and immediately added trademark markings and acknowledgement on their website. Issue solved. (They were not using it in a product name.) Basically, anyone we have ever really encountered in the marketplace has either been notified or is a licensee of ours. > "F-Secure SSH has been using the name for years" F-Secure (formerly Data Fellows) is our distributor/VAR, and they are using the SSH trademark in their product name under a separate written trademark license agreement. All of the F-Secure SSH products are SSH Communication Security Corp's products, some verbatim and some with modifications by F-Secure. > (reference to FiSSH, TTSSH, Top Gun ssh, etc.) These are all non-commercial academic projects made at universities. We have never really encountered any one of these in the marketplace. We have tried to notify commercial people who have been using the trademark inappropriately. OpenSSH was the first non-commercial implementation to raise to the radar screen. > "why did you notify OpenSSH now" The reason OpenSSH was contacted now was that they have only become more visible during the last months, and I have recently seen a significant increase in e-mails confusing the meaning of the SSH trademarks and using them inappropriately. I have also recently received quite a few e-mails confusing OpenSSH as my product. > "how about the 'ssh' command name under Unix/Linux?" This relates to the proposal I want to make. Basically, I am willing to work out a way that will allow anyone to use the "ssh" command name on Unix/Linux. It appears that there are ways to do it without exposing our trademarks to unnecessary risk. The arrangement I am proposing would be as follows. - We (SSH Corp) would allow the use of "ssh" (and sshd, etc) as a command name on Unix/Linux under the following restrictions: - Any product where the command name "ssh" is used must only be licensed under a valid license (i.e., must not be in the public domain). E.g. BSD license, GPL, and normal commercial licenses would all be ok. - An acknowledgement of our ownership of the ssh(R) and Secure Shell(TM) trademarks must be included in the software (help text, documentation, license). It would not need to be printed out every time the program is normally run, but would need to be included in e.g. in an appropriate place on man pages and in help texts. - The SSH Corp trademarks cannot be used in product names without a separate trademark license from us (which we would not normally grant, unless we see a valid business case for it, and then only for products using a compatible protocol). - A new unencumbered name is created for the protocol, which can be used by any vendor without creating confusion. The IETF standard would be renamed to use the new protocol name, and the community would work to cease using "SSH" as a protocol name and would instead start using the new name. The new name would need to be unencumbered, and the xx.com, xx.net, and xx.org domain names would be made to permanently point to e.g. the IETF main page. My own proposal would be to change the name to SECSH, provided that Van Dyke is willing to contribute their currently unused secsh.com domain name for this purpose. We would be willing to contribute our secsh.org and secsh.net domains on the same basis. - We would submit an official statement to the IETF that we will make no trademark claims about the "bits on the wire" in the protocol (e.g., the protocol version strings or the various names used in the protocol). - We would need to reach agreement with the OpenSSH group to change their product name and to otherwise cease using the SSH trademarks inappropriately. We appreciate that some people have brought the non-commercial university group use to our attention. We are carefully reviewing this situation. Let's discuss the exact terms if I get a preliminary "ok, looks fine, let's try to get this resolved along those lines" from the community and the relevant parties. Please let us know what you think. Best regards, Tatu Ylonen Chairman and CTO, SSH Communications Security Corp PS. For reference, if someone hasn't seen it yet, I'll include my original e-mail to the OpenSSH mailing list. >From ylo Wed Feb 14 03:36:19 +0200 2001 From: Tatu Ylonen To: openssh-unix-dev at mindrot.org Subject: SSH trademarks and the OpenSSH product name Organization: SSH Communications Security, Finland Friends, Sorry to write this to a developer mailing list. I have already approached some OpenSSH/OpenBSD core members on this, including Markus Friedl, Theo de Raadt, and Niels Provos, but they have chosen not to bring the issue up on the mailing list. I am not aware of any other forum where I would reach the OpenSSH developers, so I will post this here. As you know, I have been using the SSH trademark as the brand name of my SSH (Secure Shell) secure remote login product and related technology ever since I released the first version in July 1995. I have explicitly claimed them as trademarks at least from early 1996. In December 1995, I started SSH Communications Security Corp to support and further develop the SSH (Secure Shell) secure remote login products and to develop other network security solutions (especially in the IPSEC and PKI areas). SSH Communications Security Corp is now publicly listed in the Helsinki Exchange, employs 180 people working in various areas of cryptographic network security, and our products are distributed directly and indirectly by hundreds of licensed distributors and OEMs worldwide using the SSH brand name. There are several million users of products that we have licensed under the SSH brand. To protect the SSH trademark I (or SSH Communications Security Corp, to be more accurate) registered the SSH mark in the United States and European Union in 1996 (others pending). We also have a registration pending on the Secure Shell mark. The SSH mark is a significant asset of SSH Communications Security and the company strives to protect its valuable rights in the SSH name and mark. SSH Communications Security has made a substantial investment in time and money in its SSH mark, such that end users have come to recognize that the mark represents SSH Communications Security as the source of the high quality products offered under the mark. This resulting goodwill is of vital importance to SSH Communications Security Corp. We have also been distributing free versions of SSH Secure Shell under the SSH brand since 1995. The latest version, ssh-2.4.0, is free for any use on the Linux, FreeBSD, NetBSD, and OpenBSD operating systems, as well as for universities and charity organizations, and for personal hobby/recreational use by individuals. We have been including trademark markings in SSH distributions, on the www.ssh.fi, www.ssh.com, and www.ssh.org web sites, IETF standards documents, license/readme files and product packaging long before the OpenSSH group was formed. Accordingly, we would like you to understand the importance of the SSH mark to us, and, by necessity, our need to protect the trademark against the unauthorized use by others. Many of you are (and the initiators of the OpenSSH group certainly should have been) well aware of the existence of the trademark. Some of the OpenBSD/OpenSSH developers/sponsors have also received a formal legal notice about the infringement earlier. I have started receiving a significant amount of e-mail where people are confusing OpenSSH as either my product or my company's product, or are confusing or misrepresenting the meaning of the SSH and Secure Shell trademarks. I have also been informed of several recent press articles and outright advertisements that are further confusing the origin and meaning of the trademark. The confusion is made even worse by the fact that OpenSSH is also a derivative of my original SSH Secure Shell product, and it still looks very much like my product (without my approval for any of it, by the way). The old SSH1 protocol and implementation are known to have fundamental security problems, some of which have been described in recent CERT vulnerability notices and various conference papers. OpenSSH is doing a disservice to the whole Internet security community by lengthing the life cycle of the fundamentally broken SSH1 protocols. The use of the SSH trademark by OpenSSH is in violation of my company's intellectual property rights, and is causing me, my company, our licensees, and our products considerable financial and other damage. I would thus like to ask you to change the name OpenSSH to something else that doesn't infringe the SSH or Secure Shell trademarks, basically to something that is clearly different and doesn't cause confusion. Also, please understand that I have nothing against independent implementations of the SSH Secure Shell protocols. I started and fully support the IETF SECSH working group in its standardization efforts, and we have offered certain licenses to use the SSH mark to refer to the protocol and to indicate that a product complies with the standard. Anyone can implement the IETF SECSH working group standard without requiring any special licenses from us. It is the use of the "SSH" and "Secure Shell" trademarks in product names or in otherwise confusing manner that we wish to prevent. Please also try to look at this from my viewpoint. I developed SSH (Secure Shell), started using the name for it, established a company using the name, all of our products are marketed using the SSH brand, and we have created a fairly widely known global brand using the name. Unauthorized use of the SSH mark by the OpenSSH group is threathening to destroy everything I have built on it during the last several years. I want to be able to continue using the SSH and Secure Shell names as identifying my own and my company's products and technologies, which the unlawful use of the SSH name by OpenSSH is making very hard. Therefore, I am asking you to please choose another name for the OpenSSH product and stop using the SSH mark in your product name and in otherwise confusing manner. Regards, Tatu Ylonen SSH Communications Security http://www.ssh.com/ SSH IPSEC Toolkit http://www.ipsec.com/ SSH(R) Secure Shell(TM) http://www.ssh.com/products/ssh From jean-marc.beroud at ubs.com Sat Feb 17 02:05:52 2001 From: jean-marc.beroud at ubs.com (Jean-Marc Beroud) Date: Fri, 16 Feb 2001 16:05:52 +0100 Subject: SSH2 PATH problem References: Message-ID: <3A8D41D0.7A1535A7@ubs.com> djm at mindrot.org wrote: > > On Fri, 16 Feb 2001, Jean-Marc Beroud wrote: > > > > Can you try running a "sshd -d -d -p 2222" and logging into it with > > > "ssh -p 2222"? I am interested in the output from the client. > > > > The client get this error: > > > > select: Bad file number > > > > BTW I use openssh on Solaris 7 (compiled with gcc 2.95.2) > > Could you send _all_ the output? Sorry. Here are the logs from the client and sshd Greets, Jean-Marc # ssh -v -v -2 -p 2222 pkgme hostid SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090600f). debug: Reading configuration data /etc/ssh/ssh_config debug: ssh_connect: getuid 5006 geteuid 5006 anon 1 debug: Connecting to pkgme [192.168.66.31] port 2222. 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: Command 'arp -a -n' timed out debug: Seeded RNG with 38 bytes from programs debug: Seeded RNG with 3 bytes from system calls 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: 486/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 'pkgme' is known and matches the DSA host key. debug: bits set: 495/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: /home/szhbjx/.ssh/id_dsa debug: PEM_read_bio_DSAPrivateKey failed debug: read DSA private key done Enter passphrase for DSA key '/home/szhbjx/.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: 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: hostid 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: channel 0: rcvd ext data 476 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) select: Bad file number debug: Transferred: stdin 0, stdout 0, stderr 25 bytes in 0.3 seconds debug: Bytes per second: stdin 0.0, stdout 0.0, stderr 72.5 debug: Exit status 0 debug: writing PRNG seed to file /home/szhbjx/.ssh/prng_seed # /opt/firewall/sbin/sshd -d -d -p 2222 debug1: sshd version OpenSSH_2.3.0p1 debug1: Seeded RNG with 33 bytes from programs debug1: Seeded RNG with 3 bytes from system calls debug1: read DSA private key done debug1: Seeded RNG with 33 bytes from programs debug1: Seeded RNG with 3 bytes from system calls debug1: Bind to port 2222 on 0.0.0.0. Server listening on 0.0.0.0 port 2222. Generating 768 bit RSA key. debug1: Seeded RNG with 33 bytes from programs debug1: Seeded RNG with 3 bytes from system calls debug1: Seeded RNG with 33 bytes from programs debug1: Seeded RNG with 3 bytes from system calls RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 192.168.66.94 port 34425 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: none debug1: got kexinit: none debug1: got kexinit: debug1: got kexinit: debug1: first kex follow: 0 debug1: reserved: 0 debug1: done debug1: kex: client->server 3des-cbc hmac-sha1 none debug1: kex: server->client 3des-cbc hmac-sha1 none debug1: Wait SSH2_MSG_KEX_DH_GEX_REQUEST. /etc/ssh/primes: No such file or directory WARNING: /etc/ssh/primes does not exist, using old prime debug1: bits set: 495/1024 debug1: Sending SSH2_MSG_KEX_DH_GEX_GROUP. debug1: Wait SSH2_MSG_KEX_DH_GEX_INIT. debug1: bits set: 486/1024 debug1: sig size 20 20 debug1: send SSH2_MSG_NEWKEYS. debug1: done: send SSH2_MSG_NEWKEYS. debug1: Wait SSH2_MSG_NEWKEYS. debug1: GOT SSH2_MSG_NEWKEYS. debug1: done: KEX2. debug1: userauth-request for user szhbjx service ssh-connection method none debug1: attempt #1 debug2: input_userauth_request: setting up authctxt for szhbjx debug1: Starting up PAM with username "szhbjx" debug2: input_userauth_request: try method none Failed none for szhbjx from 192.168.66.94 port 34425 ssh2 debug1: userauth-request for user szhbjx service ssh-connection method publickey debug1: attempt #2 debug2: input_userauth_request: try method publickey debug1: matching key found: file /home/szhbjx/.ssh/authorized_keys2, line 1 debug1: len 55 datafellows 0 debug1: dsa_verify: signature correct debug1: PAM setting rhost to "bilbo.ubinet.ubs.com" Accepted publickey for szhbjx from 192.168.66.94 port 34425 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 x11-req reply 0 debug1: Received request for X11 forwarding with auth spoofing. debug1: fd 5 setting O_NONBLOCK debug1: fd 5 IS O_NONBLOCK debug1: channel 1: new [X11 inet listener] debug2: callback done 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 10 setting O_NONBLOCK debug1: fd 10 IS O_NONBLOCK debug1: fd 12 setting O_NONBLOCK debug2: callback done debug2: channel 0: read 476 from efd 12 debug1: Received SIGCHLD. debug1: tvp!=NULL kid 1 mili 100 debug1: session_by_pid: pid 1135 debug1: session_exit_message: session 0 channel 0 pid 1135 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: 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 1135 debug2: channel 0: read 26 from efd 12 debug1: channel 0: send close debug2: channel 0: read 0 from efd 12 debug1: channel 0: closing efd 12 Connection closed by remote host. debug1: Calling cleanup 0x30fc8(0xec9e8) debug1: xauthfile_cleanup_proc called debug1: Calling cleanup 0x37ca0(0x0) debug1: channel_free: channel 1: status: The following connections are open: #0 server-session (t4 r0 i8/9 o128/0 fd 10/10) debug1: Calling cleanup 0x2ba28(0x0) debug1: Cannot delete credentials[7]: Permission denied debug1: Calling cleanup 0x3e3b4(0x0) debug1: Calling cleanup 0x437d8(0x0) debug1: writing PRNG seed to file /root/.ssh/prng_seed From mhw at wittsend.com Sat Feb 17 03:13:56 2001 From: mhw at wittsend.com (Michael H. Warfield) Date: Fri, 16 Feb 2001 11:13:56 -0500 Subject: ssh(R) trademark issues: comments and proposal In-Reply-To: <200102161051.MAA09237@mystery.acr.fi>; from ylo@ssh.com on Fri, Feb 16, 2001 at 12:51:06PM +0200 References: <200102161051.MAA09237@mystery.acr.fi> Message-ID: <20010216111356.A28833@alcove.wittsend.com> On Fri, Feb 16, 2001 at 12:51:06PM +0200, Tatu Ylonen wrote: > I'd like to address several issues raised by people in relation to my > notice of the ssh(R) trademark to the OpenSSH group. Also, I would > like to make a proposal to the community for resolving this issue > (included at the end). > First, I'll answer a number of questions and arguments presented in > the discussion. > > "the SSH Corp trademark registration in the US is for a logo only" > It is for the lowercase word "ssh" (I was mistaken earlier in saying > that it was for the uppercase word "SSH"). As many people obviously > know, trademark registrations in the USA are a matter of public record > and it is open to anyone to review the details of SSH Corp's trademark > portfolio. > Under US law, a trademark registration entitles the owner to exclusive > use of the trademark as it is registered, in relation to the goods > and/or services for which it is registered. Trademark infringement > occurs when another person uses the same, or a substantially identical > mark, for the same or related goods or services, in a manner which is > likely to cause consumer confusion. Consequently, use of the > uppercase word "SSH" or a name containing the "ssh" or "SSH" mark will > likely amount to trademark infringement under US law, if it is in > relation to goods or services within the same field of use covered by > our ssh(R) trademark. Of course, there are many possible > non-infringing uses of "SSH", for example, anyone might have a brand > of chocolade called "SSH". Counter point... Containing a sequence of letters within another word does not necessarily constitute trademark infringement or Microsoft would have been all over the X Consortium for violating their trademark for "Windows" by the term "X-Windows". I think they would have a MUCH stronger leg to stand on than OpenSSH vs ssh. I think I remember some of the controversy over that, years ago, and the arguments regarding trademarking of common terms and whether the actual trademark is for MS-Windows or Windows. Someone else can research the details on that one if they really like. You, yourself, have now even contradicted yourself. In the paragraphs above, you have confirmed that the trademark is for the lower case "ssh" and NOT for the uppercase "SSH". Therefore OpenSSH does not incorporate your trademark (lowercase ssh). I will leave to others the arguement of the style and design of the lowercase ssh, but you made it clear right here: "I was mistaken earlier in saying that it was for the uppercase word "SSH"". That should close that issue, but you go on to put forth the non-sequitar that "Consequently, use of the uppercase word "SSH" or a name containing the "ssh" or "SSH" mark will likely amount to trademark infringement under US law..." That directly contradicts your statement that "SSH" is not part of the registration as a trademark. The question is whether "OpenSSH" as opposed to "ssh" is substantially different enough to distinguish between the two. IMHO, the very term "Open"SSH establishes a boundry of distinction that it is separate and unique and that it is set apart from "SSH(r)". [Skipping the license point] [Skipping the notification point] > > "how about the 'ssh' command name under Unix/Linux?" > This relates to the proposal I want to make. > Basically, I am willing to work out a way that will allow anyone to use > the "ssh" command name on Unix/Linux. It appears that there are > ways to do it without exposing our trademarks to unnecessary risk. > The arrangement I am proposing would be as follows. > - We (SSH Corp) would allow the use of "ssh" (and sshd, etc) as a > command name on Unix/Linux under the following restrictions: > - Any product where the command name "ssh" is used must only be > licensed under a valid license (i.e., must not be in the > public domain). E.g. BSD license, GPL, and normal commercial > licenses would all be ok. I don't see how you could possibly enforce that. Quite frankly, that doesn't even seem to make sense. If someone puts something into public domain, anyone can rename it to anything they want. But that's totally non-relevant to this discussion anyways, since OpenSSH is not "public domain". > - An acknowledgement of our ownership of the ssh(R) and Secure > Shell(TM) trademarks must be included in the software (help > text, documentation, license). It would not need to be > printed out every time the program is normally run, but would > need to be included in e.g. in an appropriate place on man > pages and in help texts. Just for the name of the command? Can you quote some precedence for that? I can certainly see adding some changes to the acknowledgements THAT ALREADY EXIST: ] AUTHORS ] OpenSSH is a derivative of the original and free ssh 1.2.12 release by ] Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo ] de Raadt and Dug Song removed many bugs, re-added newer features and cre? ] ated OpenSSH. Markus Friedl contributed the support for SSH protocol ] versions 1.5 and 2.0. Fine... I could see placing a trademark acknowledgement in there. That would seem perfectly reasonable and appropriate. By "help texts" I assume you mean things like Windows help files and info files and READMEs. Seems like they already acknowledge authorship and acknowledging trade mark on "lower case ssh" sounds reasonable as well. I would vote for that. > - The SSH Corp trademarks cannot be used in product names > without a separate trademark license from us (which we would > not normally grant, unless we see a valid business case for > it, and then only for products using a compatible protocol). Not sure were the relevance of this is. That would be between you and those other parties. No connection with OpenSSH under discussion now. > - A new unencumbered name is created for the protocol, which can be > used by any vendor without creating confusion. The IETF standard > would be renamed to use the new protocol name, and the community > would work to cease using "SSH" as a protocol name and would > instead start using the new name. The new name would need to be > unencumbered, and the xx.com, xx.net, and xx.org domain names > would be made to permanently point to e.g. the IETF main page. My > own proposal would be to change the name to SECSH, provided that > Van Dyke is willing to contribute their currently unused secsh.com > domain name for this purpose. We would be willing to contribute > our secsh.org and secsh.net domains on the same basis. You pushed this effort within the IETF and you obtained the registration from IANA. Now maybe you realize your mistake and you want to tell everybody you just want to take it back. Your credibility with the IETF is certain shot to hell from the sounds of the comments on that list. IANAL... Considering that the comoditization of your term "ssh" is largely the result of your efforts with IANA and IETF and your promotion of other implimentation as required by the IETF (what, you only expected non-commercial implimentations?), I can't see where you have a position you can even bring to court. This was a self inflicted injury on your part. IMPO... The use of ssh as the protocol name vs the use of ssh as the command name vs the use of "SSH" encapsulated as a substring within another string are three totally separate issues. Right now, it looks like the IETF is pulling back their draft for a rework as a direct result of YOUR SCREWUP. They are rightfully and justifyably pissed at the under handed double dealing you've just pulled. IANA is another matter. IANA still says that port 22/tcp is registered to "ssh" (all lower case). I have never heard of ANY single instance where a port allocation was changed due to a trademark infringement, and there are LOTS of trademarks in the port-numbers document. Just search for "Oracle" or "SQL*NET" (sql*net) or SNA. Say! SNA is a good one, isn't that an IBM trademark? We've got all kinds of Cisco stuff and Unisys stuff in there. We (where I work) have implimented code which utilizes the "sql*net" protocol without infrinding on trademarks and there is even open source code for a lot of these protocols. A significant percentage of that document seems to be trademark stuff. I don't think you've got any justification for renaming the port or protocol. Changing the name of the protocol is also outside the scope of this mailing list as well. If you convince IANA and IETF to change the name and then magically get all the /etc/services files updated and get everyone else to agree to the new symbolic name for the protocol, then OpenSSH would have no choice but to follow. So OpenSSH can't change it on their own and, if the other bodies change it, OpenSSH would have to change it. That makes the decision here neither necessary nor sufficient. > - We would submit an official statement to the IETF that we will make no > trademark claims about the "bits on the wire" in the protocol (e.g., > the protocol version strings or the various names used in the > protocol). To avoid them totally shooting you out the tubes and telling everyone to just go home because it was just one big mistake. Yes, that would be nice and a minimum just to protect your own investment in that process. > - We would need to reach agreement with the OpenSSH group to change > their product name and to otherwise cease using the SSH > trademarks inappropriately. We appreciate that some people have > brought the non-commercial university group use to our attention. > We are carefully reviewing this situation. So far, with OpenSSH you've only got the name of the project (but that's not using your lower case "ssh"), the name of the protocol (which there is no precedence or justification for changing the name and plenty of precedence for not), and references in the documentation. I would vote for adding appropriate remarks to the documentation but the command name and the already non-infringing project name, not. How far are you going to take the name thing. Would HSS conflict (in the great XINU tradition - XINU is not UNIX)? What about S-S-H? or "Security-Shell". At what point do you stop dangling a sword over everyone's head or can we expect more noise like the same before every stockholder's meeting? > Let's discuss the exact terms if I get a preliminary "ok, looks fine, > let's try to get this resolved along those lines" from the community > and the relevant parties. IMPO... The acknowledgements are reasonable and should be done as soon as possible in any case. Changing the name of the protocol has no precedence and there are plenty of registered protocols carrying names which are also trademark names, so that's not a reasonable requirement. Updating the IETF draft to clarify the trademark status, is reasonable and taking place now. By your own statement about the wording of your trademark registration, OpenSSH, the name, is not literally conflicting with the trademark "ssh", so I don't see that as reasonable either, but the choice of the project name is best left up to the project team. > Please let us know what you think. > Best regards, > Tatu Ylonen > Chairman and CTO, SSH Communications Security Corp > PS. For reference, if someone hasn't seen it yet, I'll include my > original e-mail to the OpenSSH mailing list. [Skipping original letter] > Regards, > Tatu Ylonen > SSH Communications Security http://www.ssh.com/ > SSH IPSEC Toolkit http://www.ipsec.com/ > SSH(R) Secure Shell(TM) http://www.ssh.com/products/ssh Interesting... You just told us that the trademark is only for "ssh" and not "SSH". Now you are trying to convince us that "SSH" is also a registered trademark in direct contradiction of your earlier statements. I think it's also significant to note that this is a recent trend (less than a year) of yours. I have mail from you going back years. Here's your signature from one back in late 1998: ] -- ] SSH Communications Security http://www.ssh.fi/ ] SSH IPSEC Toolkit http://www.ipsec.com/ ] Free Unix SSH http://www.ssh.fi/sshprotocols2/ Hmmm... No claims of trademark there... Here it is from 4/14/2000 on the ssh mailing list: ] SSH Secure Shell http://www.ssh.com/ ] - The real and the original SSH, directly from the people who invented ] the SSH protocol. Later that very day, your current signature with the (R) and (TM) claims appeared. Mike -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From mw at moni.msci.memphis.edu Sat Feb 17 03:19:42 2001 From: mw at moni.msci.memphis.edu (Mate Wierdl) Date: Fri, 16 Feb 2001 10:19:42 -0600 Subject: ssh(R) trademark issues: comments and proposal In-Reply-To: <200102161051.MAA09237@mystery.acr.fi>; from ylo@ssh.com on Fri, Feb 16, 2001 at 12:51:06PM +0200 References: <200102161051.MAA09237@mystery.acr.fi> Message-ID: <20010216101942.C25793@moni.msci.memphis.edu> On Fri, Feb 16, 2001 at 12:51:06PM +0200, Tatu Ylonen wrote: > - Any product where the command name "ssh" is used must only be > licensed under a valid license (i.e., must not be in the > public domain). E.g. BSD license, GPL, and normal commercial > licenses would all be ok. > > - An acknowledgement of our ownership of the ssh(R) and Secure > Shell(TM) trademarks must be included in the software (help > text, documentation, license). It would not need to be > printed out every time the program is normally run, but would > need to be included in e.g. in an appropriate place on man > pages and in help texts. > I wonder now if grep, sed, sh, and other unix commands must be similarly carefully treated. What if I have been distributing my little Unix like OS for 20 years, and this OS has a script called s.sh? Now you are telling me to change this script's name? What if openssh changes its name to opensafesh (but opensafe sounds better---it even sounds like a challenge), the executable is called safesh, and INSTALL has as a final step, run ln -s safesh ssh ln -s safeshd sshd ln -s safecp scp # just to be a on the safeside ln -s safeftp sftp # ditto > would work to cease using "SSH" as a protocol name and would > instead start using the new name. The new name would need to be > unencumbered, and the xx.com, xx.net, and xx.org domain names > would be made to permanently point to e.g. the IETF main page. My > own proposal would be to change the name to SECSH, provided that > Van Dyke is willing to contribute their currently unused secsh.com > domain name for this purpose. We would be willing to contribute > our secsh.org and secsh.net domains on the same basis. Until somebody comes along, and trademarks/copyrights this name as well, so we have to start removing secsh from our boxes. Do people know for sure that `sh' has not been trademarked in some obscure coutry? > > - We would submit an official statement to the IETF that we will make no > trademark claims about the "bits on the wire" in the protocol (e.g., > the protocol version strings or the various names used in the > protocol). Again, somebody else will come and trademark the name. They *will* succeed. People might even succeed just trademarking the letter `s' in places where it might imply `secure'. In any case, I am not sure anymore if I can say "ssssh" to my crying 7 months old. --- Mate Wierdl | Dept. of Math. Sciences | University of Memphis From mhw at wittsend.com Sat Feb 17 03:40:24 2001 From: mhw at wittsend.com (Michael H. Warfield) Date: Fri, 16 Feb 2001 11:40:24 -0500 Subject: [beldridg@best.com: Re: [fw-wiz] SecureID vs Certificates] Message-ID: <20010216114024.B28833@alcove.wittsend.com> Hmmm... You guys aware of this project to incorporate Smart Cards into ssh-agent? I remember hearing about some stuff for OpenSSL, but I don't recall hearing about this on the OpenSSH list or on the Muscle list. This would be a really nice thing... :-) Mike -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! ----- Forwarded message from beldridg at best.com ----- Delivered-To: firewall-wizards at fraggle.nfr.net Delivered-To: firewall-wizards at nfr.net Date: Thu, 15 Feb 2001 15:09:32 -0800 (PST) From: To: "Marcus J. Ranum" Cc: Darren Reed , Crist Clark , , , Subject: Re: [fw-wiz] SecureID vs Certificates In-Reply-To: <5.0.2.1.2.20010215153231.00a590c0 at fraggle.nfr.com> Errors-To: firewall-wizards-admin at nfr.com X-BeenThere: firewall-wizards at nfr.com X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Firewall Wizards Security Mailing List On Thu, 15 Feb 2001, Marcus J. Ranum wrote: > This is kind of what a smart card is all about. Do the signature on > the card, so the secret never leaves it, etc. Amazingly cool > technology but it's just never caught on particularly well here. agreed. i'm still watching what the umich folks are doing with ssh-agent and the cryptoflex cards. i think it is the right approach. any updates guys? http://www.citi.umich.edu/projects/smartcard/ssh-sc.html http://www-personal.engin.umich.edu/~itoi/openssh/patch-openssh2.3.0-smartcard they are also working on a crypto filesystem with the keys stored on a smartcard. - brett _______________________________________________ firewall-wizards mailing list firewall-wizards at nfr.com http://www.nfr.com/mailman/listinfo/firewall-wizards ----- End forwarded message ----- From roc+ at cs.cmu.edu Sat Feb 17 03:54:29 2001 From: roc+ at cs.cmu.edu (Robert O'Callahan) Date: Fri, 16 Feb 2001 11:54:29 -0500 Subject: ssh(R) trademark issues: comments and proposal Message-ID: <3A8D5B45.66B0D0AA@cs.cmu.edu> Tatu Ylonen wrote: > > > "A license was granted in 1995 that allows free use of the > > trademarks" > > This is not accurate, but refers to the following language in > ssh-1.2.12 COPYING file: > > As far as I am concerned, the code I have written for this software > can be used freely for any purpose. Any derived versions of this > software must be clearly marked as such, and if the derived work is > incompatible with the protocol description in the RFC file, it must > be called by a name other than "ssh" or "Secure Shell". > > First, this is a copyright license ("the CODE can be used..."), with an > additional restriction on naming. It is not a trademark license. Of course, because you didn't have the trademark then. However, your statement presumes that the word "ssh" is in the public domain and that others will be able to use it ... otherwise you wouldn't need this clause at all. > Also, this text is from the COPYING file from ssh-1.2.12, dated Nov > 17, 1995. The trademark claims were made in 1996 (ssh-1.2.13 was the > first release claiming them, released on Feb 11, 1996), and this > license provision would not have covered them anyway. Ever since, our > policy has been not to allow unauthorized use of the trademarks. The > trademark claims have been made consistently in every release ever > since. The fact remains that in 1995 you stated your intention to allow people to use the name "ssh" for their derived works, with no indication of limited duration or other terms, and then in Feb 1996 you decided to rescind that right. Even if you could legally do that, which I doubt, that's pretty low. > > "no-one has ever been notified of infringement" > > For example, I notified Van Dyke of the trademark a few years ago when > they used the SSH mark on their web site inappropriately. We > discussed it, they were very co-operative, and immediately added > trademark markings and acknowledgement on their website. Issue > solved. (They were not using it in a product name.) No-one (or at least, none of the posts I've read) claimed "no-one has ever been notified of infringement". The claim is that there are major users of the word "SSH" who have never been notified. > > (reference to FiSSH, TTSSH, Top Gun ssh, etc.) > > These are all non-commercial academic projects made at universities. > We have never really encountered any one of these in the marketplace. FiSSH never really existed and Top Gun doesn't seem to be used much, but there are a lot of TTSSH users. Try searching for "TTSSH" in Google and observe how many universities, labs, ISPs, etc have set up Web pages to tell their students/customers/employees about it. It's a very long list*. Now, it may not be commercially significant to you, since I never got a dime and a lot of those people wouldn't pay for your client anyway. And of course you can stretch your definition of "really encountered" to fit whatever scenario you need. The fact remains that (except for my ego) it doesn't matter what you "really encountered" or what is "commercially significant", because under trademark law you have to protect your mark against all comers, not just the ones you don't like or the ones you think are important. Note that searching for "Windows SSH client" in Google, the first hit is TTSSH, and the second hit is PuTTY, which uses the word "SSH" prominently in its Web page without attribution. If that's not trademark dilution, I don't know what is. * Also, searching for "TTSSH" in Google gets about 5,600 hits, whereas "SecureCRT" gets around 8,100. Your threshold of "really encountered" seems to be quite finely tuned. > > "how about the 'ssh' command name under Unix/Linux?" > > This relates to the proposal I want to make. ... > Let's discuss the exact terms if I get a preliminary "ok, looks fine, > let's try to get this resolved along those lines" from the community > and the relevant parties. It would be a fair proposal if your trademark was defensible, but I think it could hardly be more clear that you have failed to protect the mark and that it has passed into the public domain. So I'm not very interested in your proposal. If you can somehow get the community to go along with it, I'll follow, otherwise, I won't bother. This is a sad situation because I think by not pursuing your trademark in the past, you did a good and reasonable thing. It feels a bit like you're now being punished for that. However, the truth is that you are being punished because you have stopped being reasonable. If you planned to ever enforce your trademark, then it would have been better for everyone (and required by law) for you to have enforced it from the beginning. Rob -- [Robert O'Callahan http://www.cs.cmu.edu/~roc 7th year CMU CS PhD student "Now when Joshua was near Jericho, he looked up and saw a man standing in front of him with a drawn sword in his hand. Joshua went up to him and asked, 'Are you for us or for our enemies?' 'Neither,' he replied, 'but as commander of the army of the LORD I have now come.'" - Joshua 5:13-14] From bg at sics.se Sat Feb 17 05:01:23 2001 From: bg at sics.se (Bjoern Groenvall) Date: 16 Feb 2001 19:01:23 +0100 Subject: SSH and trademarks Message-ID: Dear SSH community, It has been brought to my attention that is has been disputed whether the term "SSH" can be used freely as a term to describe implementations compatible with the "SSH" protocols, due to trademark issues. In particular, the owner of the "SSH" trademark argues that implementations compatible with the "SSH" protocols shall no longer be allowed to have names that in any way can be related to "SSH". This is most undesirable. "SSH" has been coined as a term that describes a particular computer communications protocol. As such, it is natural for protocol-compatible implementations to have names that can be associated with "SSH". Restricting the use of the term "SSH" is doing a disservice to the Internet community. In the Internet draft draft-ylonen-ssh-protocol-00.txt authored by T. Ylonen and dated November 15 1995 the string "SSH" is used 6 times as a name for a computer communications protocol. The title of the document is "The SSH (Secure Shell) Remote Login Protocol". All protocol constants have names that start with the substring "SSH_". In a more recent Internet draft, coauthored by T. Ylonen and named "SSH Protocol Architecture" (draft-ietf-secsh-architecture-07.txt) the term "SSH" is used 14 times to denote a computer communications protocol. For more than 5 years "SSH" has been used by T. Ylonen and others as a name for a computer communications protocol. The Internet community should be allowed to continue to do so, and also to name compatible implementations accordingly. As the creator of OSSH I would like to add that OSSH has been distributed since May 4:th 1999. So far, none of T. Ylonen's associaties have notified me of any unlawful use of the "SSH" trademark. Sincerely, Bj?rn Gr?nvall -- _ _ ,_______________. Bjorn Gronvall (Bj?rn Gr?nvall) /_______________/| Swedish Institute of Computer Science | || PO Box 1263, S-164 29 Kista, Sweden | Schroedingers || Email: bg at sics.se, Phone +46 -8 633 15 25 | Cat |/ Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30 `---------------' From emarshall at mercantec.com Fri Feb 16 06:11:38 2001 From: emarshall at mercantec.com (Edward S. Marshall) Date: Thu, 15 Feb 2001 13:11:38 -0600 (CST) Subject: Name Change In-Reply-To: Message-ID: On Thu, 15 Feb 2001, John Weaver wrote: > Not to be militant, but "ssh" works just fine for me. Agreed here. Sorry, but "SSH" is a common-use acronym at this point. No enforcement of your trademark means no recourse when it's used in common practice. *shrug* (I'm not a lawyer, this isn't legal advice, yadda, yadda, yadda. By the way, has anyone actually had their legal people weigh in on this? Is there an accounting of who has actually received legal notice of infringement? Should someone perhaps put a statement of the issues at www.openssh.com? ) -- Edward S. Marshall UNIX Administrator http://www.nyx.net/~emarshal/ Mercantec, Inc. From emarshall at mercantec.com Sat Feb 10 01:38:33 2001 From: emarshall at mercantec.com (Edward S. Marshall) Date: Fri, 9 Feb 2001 08:38:33 -0600 (CST) Subject: OpenSSH 2.3.0p4/2.2.0p1, Solaris 8, ssh-keygen bus error In-Reply-To: Message-ID: On Fri, 9 Feb 2001, Damien Miller wrote: > Could you please turn on very verbose debugging "ssh -v -v -v " and > report the output? As I said, ssh and sshd appear to be behaving correctly; it's only ssh-keygen that's failing. That said, here's the results you asked for: [...snip...] [emarshal at sparc05 ~]$ ./ssh -v -v -v emarshal at maelstrom SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090600f). debug: Seeding random number generator debug: ssh_connect: getuid 0 geteuid 0 anon 0 debug: Connecting to maelstrom [172.16.64.201] port 22. debug: Allocated local port 1016. debug: Connection established. debug: Remote protocol version 1.99, remote software version OpenSSH_2.3.0p1 debug: no match: OpenSSH_2.3.0p1 debug: Local version string SSH-1.5-OpenSSH_2.3.0p1 debug: Waiting for server public key. debug: Received server public key (768 bits) and host key (1024 bits). The authenticity of host 'maelstrom' can't be established. RSA key fingerprint is 0d:7a:82:8a:de:03:e0:e5:e9:79:86:9a:04:f2:62:e1. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'maelstrom,172.16.64.201' (RSA) to the list of known hosts. debug: Seeding random number generator debug: Encryption type: 3des debug: Sent encrypted session key. debug: Installing crc compensation attack detector. debug: Received encrypted confirmation. debug: Doing password authentication. emarshal at maelstrom's password: debug: Requesting pty. debug: Requesting shell. debug: Entering interactive session. Last login: Tue Feb 6 08:12:59 2001 [emarshal at maelstrom ~]$ exit Connection to maelstrom closed. debug: Transferred: stdin 0, stdout 139, stderr 33 bytes in 59.5 seconds debug: Bytes per second: stdin 0.0, stdout 2.3, stderr 0.6 debug: Exit status 0 [...snip...] Hope this helps. -- Edward S. Marshall UNIX Administrator http://www.nyx.net/~emarshal/ Mercantec, Inc. From emarshall at mercantec.com Sat Feb 10 08:08:35 2001 From: emarshall at mercantec.com (Edward S. Marshall) Date: Fri, 9 Feb 2001 15:08:35 -0600 (CST) Subject: OpenSSH 2.3.0p4/2.2.0p1, Solaris 8, ssh-keygen bus error In-Reply-To: Message-ID: On Fri, 9 Feb 2001, Damien Miller wrote: > Could you please turn on very verbose debugging "ssh -v -v -v " and > report the output? A little more information; sshd is failing with a bus error as well (the client seems fine so far in light use): # gdb ./sshd GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.8"... (gdb) set args -ddd (gdb) run Starting program: /merc/tools/obj/openssh-2.3.0p4/./sshd -ddd 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 172.16.64.201 port 1022 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: none debug1: got kexinit: none debug1: got kexinit: debug1: got kexinit: debug1: first kex follow: 0 debug1: reserved: 0 debug1: done debug1: kex: client->server 3des-cbc hmac-sha1 none debug1: kex: server->client 3des-cbc hmac-sha1 none debug1: Wait SSH2_MSG_KEX_DH_GEX_REQUEST. Program received signal SIGSEGV, Segmentation fault. 0x4de9c in DH_new_method () (gdb) where #0 0x4de9c in DH_new_method () #1 0x4e16c in DH_new () #2 0x2fb30 in dh_new_group (gen=0xe5498, modulus=0xe54b8) at /merc/tools/src/openssh-2.3.0p1/kex.c:178 #3 0x209d8 in choose_dh (minbits=4096) at /merc/tools/src/openssh-2.3.0p1/dh.c:156 #4 0x1cbfc in ssh_dhgex_server (kex=0xdaa88, client_kexinit=0xdd250, server_kexinit=0xdd2b0) at /merc/tools/src/openssh-2.3.0p1/sshd.c:1511 #5 0x1c918 in do_ssh2_kex () at /merc/tools/src/openssh-2.3.0p1/sshd.c:1332 #6 0x1c320 in main (ac=2, av=0xd2000) at /merc/tools/src/openssh-2.3.0p1/sshd.c:1084 (gdb) Any ideas? -- Edward S. Marshall UNIX Administrator http://www.nyx.net/~emarshal/ Mercantec, Inc. From djm at web.us.uu.net Sat Feb 17 05:14:25 2001 From: djm at web.us.uu.net (David J. MacKenzie) Date: Fri, 16 Feb 2001 13:14:25 -0500 (EST) Subject: OpenSSH 2.3.0p1 port to BSDI BSD/OS Message-ID: <14989.28161.846650.358750@jenkins.web.us.uu.net> BSD/OS 4.2 comes with OpenSSH 2.1.1p4, patched to support BSDI's authentication library. However, BSDI's patches have several problems: 1. They don't run the approval phase, so they can allow users to login who aren't supposed to be able to. 2. They don't patch configure to automatically detect the BSDI auth system, so they're not ready to use in a general portable distribution. 3. They change the path to krb.h unconditionally, making it unportable. Here is a patch derived from BSDI's, updated for OpenSSH 2.3.0p1, which fixes those problems, and also fixes a misplaced #ifdef in the OpenSSH distribution in bsd-vis.c. After applying this patch, run "autoreconf". Index: auth1.c --- auth1.c 2001/02/13 07:43:16 1.1 +++ auth1.c 2001/02/13 22:00:06 @@ -28,6 +28,12 @@ #include "auth.h" #include "session.h" +#ifdef HAVE_BSD_AUTH_H +# include +# include +static char *bsduser=NULL; /* XXX -- ugly, but we need the original */ +#endif + /* import */ extern ServerOptions options; extern char *forced_command; @@ -258,7 +264,10 @@ NULL, password) == SIASUCCESS) { authenticated = 1; } -#else /* !USE_PAM && !HAVE_OSF_SIA */ +#elif defined(HAVE_BSD_AUTH_H) + authenticated = auth_userokay(bsduser, NULL, + "auth-ssh", password); +#else /* !USE_PAM && !HAVE_OSF_SIA && !HAVE_BSD_AUTH_H */ /* Try authentication with the password. */ authenticated = auth_password(pw, password); #endif /* USE_PAM */ @@ -362,6 +371,10 @@ if (authenticated && !do_pam_account(pw->pw_name, client_user)) authenticated = 0; #endif +#ifdef HAVE_BSD_AUTH_H + if (authenticated && !auth_approval(NULL, NULL, pw->pw_name, "ssh")) + authenticated = 0; +#endif /* HAVE_BSD_AUTH_H */ if (client_user != NULL) { xfree(client_user); @@ -415,6 +428,15 @@ #endif /* AFS */ /* Verify that the user is a valid user. */ +#ifdef HAVE_BSD_AUTH_H + /* we may have an auth type in the user name we need to strip */ + { + char *p; + bsduser = xstrdup(user); + if ((p = strchr(user, ':')) != NULL) + *p = '\0'; + } +#endif pw = getpwnam(user); if (pw && allowed_user(pw)) { /* Take a copy of the returned structure. */ @@ -460,7 +482,9 @@ (sia_validate_user(NULL, saved_argc, saved_argv, get_canonical_hostname(), pw->pw_name, NULL, 0, NULL, "") == SIASUCCESS)) { -#else /* !HAVE_OSF_SIA && !USE_PAM */ +#elif defined(HAVE_BSD_AUTH_H) + auth_userokay(bsduser, NULL, "auth-ssh", "" )) { +#else /* !HAVE_OSF_SIA && !USE_PAM && !HAVE_BSD_AUTH_H */ auth_password(pw, "")) { #endif /* USE_PAM */ /* Authentication with empty password succeeded. */ @@ -474,6 +498,13 @@ } if (pw == NULL) fatal("internal error, authentication successfull for user '%.100s'", user); + +#ifdef HAVE_BSD_AUTH_H + if (bsduser != NULL) { + xfree(bsduser); + bsduser = NULL; + } +#endif /* The user has been authenticated and accepted. */ packet_start(SSH_SMSG_SUCCESS); Index: auth2.c --- auth2.c 2001/02/13 07:43:16 1.1 +++ auth2.c 2001/02/13 22:00:06 @@ -56,6 +56,11 @@ #include "uidswap.h" #include "auth-options.h" +#ifdef HAVE_BSD_AUTH_H +# include +# include +#endif + /* import */ extern ServerOptions options; extern unsigned char *session_id2; @@ -209,7 +214,19 @@ /* setup auth context */ struct passwd *pw = NULL; setproctitle("%s", user); +#ifdef HAVE_BSD_AUTH_H + { + /* user may contain requested auth type */ + char *p; + if ((p = strchr(user, ':')) != NULL) + *p = '\0'; + pw = getpwnam(user); + if (p != NULL) + *p = ':'; + } +#else pw = getpwnam(user); +#endif if (pw && allowed_user(pw) && strcmp(service, "ssh-connection")==0) { authctxt->pw = pwcopy(pw); authctxt->valid = 1; @@ -254,6 +271,10 @@ if (authenticated && authctxt->user && !do_pam_account(authctxt->user, NULL)) authenticated = 0; #endif /* USE_PAM */ +#ifdef HAVE_BSD_AUTH_H + if (authenticated && authctxt->user && !auth_approval(NULL, NULL, authctxt->user, "ssh")) + authenticated = 0; +#endif /* HAVE_BSD_AUTH_H */ /* Log before sending the reply */ userauth_log(authctxt, authenticated, method); @@ -353,7 +374,9 @@ return (sia_validate_user(NULL, saved_argc, saved_argv, get_canonical_hostname(), authctxt->user?authctxt->user:"NOUSER", NULL, 0, NULL, "") == SIASUCCESS); -#else /* !HAVE_OSF_SIA && !USE_PAM */ +#elif defined(HAVE_BSD_AUTH_H) + return auth_userokay(authctxt->user?authctxt->user:"NOUSER", NULL, "auth-ssh", ""); +#else /* !HAVE_OSF_SIA && !USE_PAM && !HAVE_BSD_AUTH_H */ return auth_password(authctxt->pw, ""); #endif /* USE_PAM */ } @@ -380,7 +403,9 @@ sia_validate_user(NULL, saved_argc, saved_argv, get_canonical_hostname(), authctxt->user?authctxt->user:"NOUSER", NULL, 0, NULL, password) == SIASUCCESS) -#else /* !USE_PAM && !HAVE_OSF_SIA */ +#elif defined(HAVE_BSD_AUTH_H) + auth_userokay(authctxt->user?authctxt->user:"NOUSER", NULL, "auth-ssh", password) != 0) +#else /* !USE_PAM && !HAVE_OSF_SIA && !HAVE_BSD_AUTH_H */ auth_password(authctxt->pw, password) == 1) #endif /* USE_PAM */ authenticated = 1; Index: bsd-vis.c --- bsd-vis.c 2001/02/13 07:43:16 1.1 +++ bsd-vis.c 2001/02/13 07:45:46 1.2 @@ -35,9 +35,9 @@ static char rcsid[] = "$OpenBSD: vis.c,v 1.5 2000/07/19 15:25:13 deraadt Exp $"; #endif /* LIBC_SCCS and not lint */ -#ifndef HAVE_VIS - #include "includes.h" + +#ifndef HAVE_VIS #define isoctal(c) (((u_char)(c)) >= '0' && ((u_char)(c)) <= '7') Index: session.c --- session.c 2001/02/13 07:43:17 1.1 +++ session.c 2001/02/13 07:45:46 1.2 @@ -1155,7 +1155,9 @@ child_set_env(&env, &envsize, "HOME", pw->pw_dir); #ifdef HAVE_LOGIN_CAP (void) setusercontext(lc, pw, pw->pw_uid, LOGIN_SETPATH); - child_set_env(&env, &envsize, "PATH", getenv("PATH")); + /* update the path to the one setusercontext set for us */ + if (getenv("PATH")) + child_set_env(&env, &envsize, "PATH", getenv("PATH")); #else /* HAVE_LOGIN_CAP */ # ifndef HAVE_CYGWIN /* Index: ssh.h --- ssh.h 2001/02/13 07:43:17 1.1 +++ ssh.h 2001/02/13 22:00:07 @@ -520,7 +520,12 @@ ssize_t atomicio(ssize_t (*f)(), int fd, void *s, size_t n); #ifdef KRB4 +#ifdef HAVE_BSD_AUTH_H +#define DES_DEFS /* prevent BSD/OS krb.h from including kerberosIV/des.h */ +#include +#else /* !HAVE_BSD_AUTH_H */ #include +#endif /* HAVE_BSD_AUTH_H */ /* * Performs Kerberos v4 mutual authentication with the client. This returns 0 * if the client could not be authenticated, and 1 if authentication was Index: configure.in --- configure.in 2001/02/13 07:43:16 1.1 +++ configure.in 2001/02/13 22:00:07 @@ -284,7 +284,7 @@ fi # Checks for header files. -AC_CHECK_HEADERS(bstring.h endian.h floatingpoint.h getopt.h lastlog.h limits.h login.h login_cap.h maillock.h netdb.h netgroup.h netinet/in_systm.h paths.h poll.h pty.h shadow.h security/pam_appl.h sys/bitypes.h sys/bsdtty.h sys/cdefs.h sys/poll.h sys/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) +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 bsd_auth.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) From brhamon at cisco.com Sat Feb 17 05:42:00 2001 From: brhamon at cisco.com (Brian Hamon) Date: Fri, 16 Feb 2001 12:42:00 -0600 Subject: Trademark infringement (silly) Message-ID: <4.3.2.7.2.20010216122112.00bace30@3rdclass.cisco.com> G(R)e(R)n(R)t(R)l(R)em(R)en, I(R)t is(R) w(R)ith(R) g(R)r(R)ea(R)t regret that I mu(R)st inf(R)o(R)rm y(R)ou that I hav(R)e registered(R) trademark(R)s on most of the letters of the English alp(R)hab(R)et. Your unauthoriz(R)ed use of these trademarks has c(R)aused considerable confusion and cost me considerable effort. After all, I am forced to answer questions from people who, confused by your malapropisms, come to me for help. This costs me considerably. Henceforth, restrict your written communications to non-trademarked letters X and J. Thank you. From mouring at etoh.eviladmin.org Sat Feb 17 06:46:37 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 16 Feb 2001 13:46:37 -0600 (CST) Subject: OpenSSH 2.3.0p1 port to BSDI BSD/OS In-Reply-To: <14989.28161.846650.358750@jenkins.web.us.uu.net> Message-ID: Could you please port up the latest snapshot at: http://bass.directhit.com/openssh_snap? We are coming close to a 2.5.0p1 release so timing is pretty critical. Thanks, - Ben On Fri, 16 Feb 2001, David J. MacKenzie wrote: > BSD/OS 4.2 comes with OpenSSH 2.1.1p4, patched to support BSDI's > authentication library. However, BSDI's patches have several > problems: > > 1. They don't run the approval phase, so they can allow users to login > who aren't supposed to be able to. > 2. They don't patch configure to automatically detect the BSDI auth > system, so they're not ready to use in a general portable > distribution. > 3. They change the path to krb.h unconditionally, making it unportable. > > Here is a patch derived from BSDI's, updated for OpenSSH 2.3.0p1, > which fixes those problems, and also fixes a misplaced #ifdef in the > OpenSSH distribution in bsd-vis.c. > > After applying this patch, run "autoreconf". > > Index: auth1.c > --- auth1.c 2001/02/13 07:43:16 1.1 > +++ auth1.c 2001/02/13 22:00:06 > @@ -28,6 +28,12 @@ > #include "auth.h" > #include "session.h" > > +#ifdef HAVE_BSD_AUTH_H > +# include > +# include > +static char *bsduser=NULL; /* XXX -- ugly, but we need the original */ > +#endif > + > /* import */ > extern ServerOptions options; > extern char *forced_command; > @@ -258,7 +264,10 @@ > NULL, password) == SIASUCCESS) { > authenticated = 1; > } > -#else /* !USE_PAM && !HAVE_OSF_SIA */ > +#elif defined(HAVE_BSD_AUTH_H) > + authenticated = auth_userokay(bsduser, NULL, > + "auth-ssh", password); > +#else /* !USE_PAM && !HAVE_OSF_SIA && !HAVE_BSD_AUTH_H */ > /* Try authentication with the password. */ > authenticated = auth_password(pw, password); > #endif /* USE_PAM */ > @@ -362,6 +371,10 @@ > if (authenticated && !do_pam_account(pw->pw_name, client_user)) > authenticated = 0; > #endif > +#ifdef HAVE_BSD_AUTH_H > + if (authenticated && !auth_approval(NULL, NULL, pw->pw_name, "ssh")) > + authenticated = 0; > +#endif /* HAVE_BSD_AUTH_H */ > > if (client_user != NULL) { > xfree(client_user); > @@ -415,6 +428,15 @@ > #endif /* AFS */ > > /* Verify that the user is a valid user. */ > +#ifdef HAVE_BSD_AUTH_H > + /* we may have an auth type in the user name we need to strip */ > + { > + char *p; > + bsduser = xstrdup(user); > + if ((p = strchr(user, ':')) != NULL) > + *p = '\0'; > + } > +#endif > pw = getpwnam(user); > if (pw && allowed_user(pw)) { > /* Take a copy of the returned structure. */ > @@ -460,7 +482,9 @@ > (sia_validate_user(NULL, saved_argc, saved_argv, > get_canonical_hostname(), pw->pw_name, NULL, 0, > NULL, "") == SIASUCCESS)) { > -#else /* !HAVE_OSF_SIA && !USE_PAM */ > +#elif defined(HAVE_BSD_AUTH_H) > + auth_userokay(bsduser, NULL, "auth-ssh", "" )) { > +#else /* !HAVE_OSF_SIA && !USE_PAM && !HAVE_BSD_AUTH_H */ > auth_password(pw, "")) { > #endif /* USE_PAM */ > /* Authentication with empty password succeeded. */ > @@ -474,6 +498,13 @@ > } > if (pw == NULL) > fatal("internal error, authentication successfull for user '%.100s'", user); > + > +#ifdef HAVE_BSD_AUTH_H > + if (bsduser != NULL) { > + xfree(bsduser); > + bsduser = NULL; > + } > +#endif > > /* The user has been authenticated and accepted. */ > packet_start(SSH_SMSG_SUCCESS); > Index: auth2.c > --- auth2.c 2001/02/13 07:43:16 1.1 > +++ auth2.c 2001/02/13 22:00:06 > @@ -56,6 +56,11 @@ > #include "uidswap.h" > #include "auth-options.h" > > +#ifdef HAVE_BSD_AUTH_H > +# include > +# include > +#endif > + > /* import */ > extern ServerOptions options; > extern unsigned char *session_id2; > @@ -209,7 +214,19 @@ > /* setup auth context */ > struct passwd *pw = NULL; > setproctitle("%s", user); > +#ifdef HAVE_BSD_AUTH_H > + { > + /* user may contain requested auth type */ > + char *p; > + if ((p = strchr(user, ':')) != NULL) > + *p = '\0'; > + pw = getpwnam(user); > + if (p != NULL) > + *p = ':'; > + } > +#else > pw = getpwnam(user); > +#endif > if (pw && allowed_user(pw) && strcmp(service, "ssh-connection")==0) { > authctxt->pw = pwcopy(pw); > authctxt->valid = 1; > @@ -254,6 +271,10 @@ > if (authenticated && authctxt->user && !do_pam_account(authctxt->user, NULL)) > authenticated = 0; > #endif /* USE_PAM */ > +#ifdef HAVE_BSD_AUTH_H > + if (authenticated && authctxt->user && !auth_approval(NULL, NULL, authctxt->user, "ssh")) > + authenticated = 0; > +#endif /* HAVE_BSD_AUTH_H */ > > /* Log before sending the reply */ > userauth_log(authctxt, authenticated, method); > @@ -353,7 +374,9 @@ > return (sia_validate_user(NULL, saved_argc, saved_argv, > get_canonical_hostname(), authctxt->user?authctxt->user:"NOUSER", > NULL, 0, NULL, "") == SIASUCCESS); > -#else /* !HAVE_OSF_SIA && !USE_PAM */ > +#elif defined(HAVE_BSD_AUTH_H) > + return auth_userokay(authctxt->user?authctxt->user:"NOUSER", NULL, "auth-ssh", ""); > +#else /* !HAVE_OSF_SIA && !USE_PAM && !HAVE_BSD_AUTH_H */ > return auth_password(authctxt->pw, ""); > #endif /* USE_PAM */ > } > @@ -380,7 +403,9 @@ > sia_validate_user(NULL, saved_argc, saved_argv, > get_canonical_hostname(), authctxt->user?authctxt->user:"NOUSER", > NULL, 0, NULL, password) == SIASUCCESS) > -#else /* !USE_PAM && !HAVE_OSF_SIA */ > +#elif defined(HAVE_BSD_AUTH_H) > + auth_userokay(authctxt->user?authctxt->user:"NOUSER", NULL, "auth-ssh", password) != 0) > +#else /* !USE_PAM && !HAVE_OSF_SIA && !HAVE_BSD_AUTH_H */ > auth_password(authctxt->pw, password) == 1) > #endif /* USE_PAM */ > authenticated = 1; > Index: bsd-vis.c > --- bsd-vis.c 2001/02/13 07:43:16 1.1 > +++ bsd-vis.c 2001/02/13 07:45:46 1.2 > @@ -35,9 +35,9 @@ > static char rcsid[] = "$OpenBSD: vis.c,v 1.5 2000/07/19 15:25:13 deraadt Exp $"; > #endif /* LIBC_SCCS and not lint */ > > -#ifndef HAVE_VIS > - > #include "includes.h" > + > +#ifndef HAVE_VIS > > #define isoctal(c) (((u_char)(c)) >= '0' && ((u_char)(c)) <= '7') > > Index: session.c > --- session.c 2001/02/13 07:43:17 1.1 > +++ session.c 2001/02/13 07:45:46 1.2 > @@ -1155,7 +1155,9 @@ > child_set_env(&env, &envsize, "HOME", pw->pw_dir); > #ifdef HAVE_LOGIN_CAP > (void) setusercontext(lc, pw, pw->pw_uid, LOGIN_SETPATH); > - child_set_env(&env, &envsize, "PATH", getenv("PATH")); > + /* update the path to the one setusercontext set for us */ > + if (getenv("PATH")) > + child_set_env(&env, &envsize, "PATH", getenv("PATH")); > #else /* HAVE_LOGIN_CAP */ > # ifndef HAVE_CYGWIN > /* > Index: ssh.h > --- ssh.h 2001/02/13 07:43:17 1.1 > +++ ssh.h 2001/02/13 22:00:07 > @@ -520,7 +520,12 @@ > ssize_t atomicio(ssize_t (*f)(), int fd, void *s, size_t n); > > #ifdef KRB4 > +#ifdef HAVE_BSD_AUTH_H > +#define DES_DEFS /* prevent BSD/OS krb.h from including kerberosIV/des.h */ > +#include > +#else /* !HAVE_BSD_AUTH_H */ > #include > +#endif /* HAVE_BSD_AUTH_H */ > /* > * Performs Kerberos v4 mutual authentication with the client. This returns 0 > * if the client could not be authenticated, and 1 if authentication was > Index: configure.in > --- configure.in 2001/02/13 07:43:16 1.1 > +++ configure.in 2001/02/13 22:00:07 > @@ -284,7 +284,7 @@ > fi > > # Checks for header files. > -AC_CHECK_HEADERS(bstring.h endian.h floatingpoint.h getopt.h lastlog.h limits.h login.h login_cap.h maillock.h netdb.h netgroup.h netinet/in_systm.h paths.h poll.h pty.h shadow.h security/pam_appl.h sys/bitypes.h sys/bsdtty.h sys/cdefs.h sys/poll.h sys/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) > +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 bsd_auth.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) > From Matthew_Weigel at ursa-minor.fac.cs.cmu.edu Sat Feb 17 06:21:05 2001 From: Matthew_Weigel at ursa-minor.fac.cs.cmu.edu (Matthew Weigel) Date: Fri, 16 Feb 2001 14:21:05 -0500 Subject: ssh(R) trademark issues: comments and proposal In-Reply-To: Your message of "Fri, 16 Feb 2001 12:51:06 +0200." <200102161051.MAA09237@mystery.acr.fi> Message-ID: <20010216192121.0DE821A1CB@toad.mindrot.org> > > "A license was granted in 1995 that allows free use of the trademarks" > > This is not accurate, but refers to the following language in > ssh-1.2.12 COPYING file: That's a mischaracterization of the argument: a license was granted in 1995 that allows derivative works to use of the term ssh, when in compliance with the SSH-1.3 protocol. Note the result of the trademark of Linux(R). While you are certainly not in the same position as Della Croce, who attempted to establish a trademark for something with which he had no connection, you are in a similar position as to the prior existance and use of the term within the markets the trademark is active. > Also, this text is from the COPYING file from ssh-1.2.12, dated Nov > 17, 1995. The trademark claims were made in 1996 (ssh-1.2.13 was the > first release claiming them, released on Feb 11, 1996), and this > license provision would not have covered them anyway. Ever since, our > policy has been not to allow unauthorized use of the trademarks. The > trademark claims have been made consistently in every release ever > since. But it clearly delineates that software, not from SSH Corp, has been using the mark since before the trademark was in existance or claimed. Thus, by not preventing these non-SSH Corp products from using the trademark, I think you've given it up. > > "no-one has ever been notified of infringement" > > For example, I notified Van Dyke of the trademark a few years ago when > they used the SSH mark on their web site inappropriately. We > discussed it, they were very co-operative, and immediately added > trademark markings and acknowledgement on their website. Issue > solved. (They were not using it in a product name.) > > Basically, anyone we have ever really encountered in the marketplace > has either been notified or is a licensee of ours. > > > "F-Secure SSH has been using the name for years" > > F-Secure (formerly Data Fellows) is our distributor/VAR, and they are > using the SSH trademark in their product name under a separate written > trademark license agreement. All of the F-Secure SSH products are SSH > Communication Security Corp's products, some verbatim and some with > modifications by F-Secure. But trademark is not claimed, regardless -- note the web pages I previously referenced. > > (reference to FiSSH, TTSSH, Top Gun ssh, etc.) > > These are all non-commercial academic projects made at universities. Irrelevant. They are still "Computer programs and software for preventing unauthorized access to computer networks and for providing secure connections to computer networks." > We have never really encountered any one of these in the marketplace. But you make an SSH for MacOS. Haven't you encountered Nifty Telnet SSH there? Hint: I use Nifty Telnet SSH, and specifically avoid the SSH for MacOS from F-Secure because of it. So you have. > We have tried to notify commercial people who have been using the > trademark inappropriately. OpenSSH was the first non-commercial > implementation to raise to the radar screen. Well, you clearly can't claim lack of knowledge about some of these other products, so can you explain what is required to 'raise to the radar screen'? These other products diluted the trademark, since they fall under the description of the purpose of the trademark as delineated in your trademark registration. > > "why did you notify OpenSSH now" > > The reason OpenSSH was contacted now was that they have only become > more visible during the last months, and I have recently seen a > significant increase in e-mails confusing the meaning of the SSH > trademarks and using them inappropriately. I have also recently > received quite a few e-mails confusing OpenSSH as my product. Sorry, that can be annoying. But then, you misuse the ssh mark as well, since you use it in a form other than "ssh-brand secsh [or whatever]." > > "how about the 'ssh' command name under Unix/Linux?" > > This relates to the proposal I want to make. > > Basically, I am willing to work out a way that will allow anyone to use > the "ssh" command name on Unix/Linux. It appears that there are > ways to do it without exposing our trademarks to unnecessary risk. But are you in a position to offer this? That is, can you enforce it, or is it just a description of what you'd like to happen? > The arrangement I am proposing would be as follows. > > - We (SSH Corp) would allow the use of "ssh" (and sshd, etc) as a > command name on Unix/Linux under the following restrictions: What about under Windows, Plan 9, OS/2.... I'm all for an amicable conclusion. Unfortunately, I also think that the ssh trademark is indefensible and a poor idea. -- Matthew Weigel Research Systems Programmer mcweigel+ at cs.cmu.edu From jmknoble at jmknoble.cx Sat Feb 17 06:48:07 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Fri, 16 Feb 2001 14:48:07 -0500 Subject: PATCH: make contrib/redhat/sshd.init work with older RH releases Message-ID: <20010216144807.A25687@quipu.half.pint-stowp.cx> Damien-- Attached is a patch to contrib/redhat/sshd.init which eliminates the dependency on the success() and failure() functions from initscripts>=4.16. This allows sshd.init to be used for both early and recent releases of Red Hat Linux (i've confirmed it works on both 4.2 and 5.2 as well as 6.2). The patch also removes the 'Requires: initscripts >= 4.16' line from contrib/redhat/openssh.spec. After inspecting and applying, you ought to be able to remove contrib/redhat/sshd.init-5.x. Hang in there. -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From sommerfeld at east.sun.com Sat Feb 17 07:05:29 2001 From: sommerfeld at east.sun.com (Bill Sommerfeld) Date: Fri, 16 Feb 2001 15:05:29 -0500 Subject: ssh(R) trademark issues: comments and proposal In-Reply-To: Your message of "Fri, 16 Feb 2001 14:21:05 EST." <200102161921.VAA19959@mail.clinet.fi> Message-ID: <200102162005.f1GK5T923344@thunk.east.sun.com> Matthew (and others): Please do not CC: discussions of the validity of the ssh trademark to the IETF Secure Shell protocol working group list ; they're out of scope for the working group. Thank you for your cooperation. - Bill From jmknoble at jmknoble.cx Sat Feb 17 07:07:12 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Fri, 16 Feb 2001 15:07:12 -0500 Subject: PATCH: make contrib/redhat/sshd.init work with older RH releases In-Reply-To: <20010216144807.A25687@quipu.half.pint-stowp.cx>; from jmknoble@jmknoble.cx on Fri, Feb 16, 2001 at 02:48:07PM -0500 References: <20010216144807.A25687@quipu.half.pint-stowp.cx> Message-ID: <20010216150712.C25687@quipu.half.pint-stowp.cx> if (ENOATTACH == ret) { flog_sender(); } -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ Circa 2001-Feb-16 14:48:07 -0500 dixit Jim Knoble: : Damien-- : : Attached is a patch to contrib/redhat/sshd.init which eliminates the : dependency on the success() and failure() functions from : initscripts>=4.16. This allows sshd.init to be used for both early and : recent releases of Red Hat Linux (i've confirmed it works on both 4.2 : and 5.2 as well as 6.2). : : The patch also removes the 'Requires: initscripts >= 4.16' line from : contrib/redhat/openssh.spec. : : After inspecting and applying, you ought to be able to remove : contrib/redhat/sshd.init-5.x. : : Hang in there. -------------- next part -------------- --- ./contrib/redhat/openssh.spec.orig-init Wed Feb 14 23:33:17 2001 +++ ./contrib/redhat/openssh.spec Fri Feb 16 14:41:50 2001 @@ -57,7 +57,6 @@ Group: System Environment/Daemons Obsoletes: ssh-server PreReq: openssh = %{version}-%{release}, chkconfig >= 0.9 -Requires: initscripts >= 4.16 %package askpass Summary: OpenSSH X11 passphrase dialog --- ./contrib/redhat/sshd.init.orig-init Mon Nov 13 06:57:27 2000 +++ ./contrib/redhat/sshd.init Fri Feb 16 14:39:25 2001 @@ -23,14 +23,46 @@ RSA_KEY=/etc/ssh/ssh_host_rsa_key DSA_KEY=/etc/ssh/ssh_host_dsa_key PID_FILE=/var/run/sshd.pid +my_success() { + local msg + if [ $# -gt 1 ]; then + msg="$2" + else + msg="done" + fi + case "`type -type success`" in + function) + success "$1" + ;; + *) + echo -n "${msg}" + ;; + esac +} +my_failure() { + local msg + if [ $# -gt 1 ]; then + msg="$2" + else + msg="FAILED" + fi + case "`type -type failure`" in + function) + failure "$1" + ;; + *) + echo -n "${msg}" + ;; + esac +} do_rsa1_keygen() { if ! test -f $RSA1_KEY ; then echo -n "Generating SSH1 RSA host key: " if $KEYGEN -q -t rsa1 -f $RSA1_KEY -C '' -N '' >&/dev/null; then - success "RSA1 key generation" + my_success "RSA1 key generation" echo else - failure "RSA1 key generation" + my_failure "RSA1 key generation" echo exit 1 fi @@ -40,10 +72,10 @@ if ! test -f $RSA_KEY ; then echo -n "Generating SSH2 RSA host key: " if $KEYGEN -q -t rsa -f $RSA_KEY -C '' -N '' >&/dev/null; then - success "RSA key generation" + my_success "RSA key generation" echo else - failure "RSA key generation" + my_failure "RSA key generation" echo exit 1 fi @@ -53,10 +85,10 @@ if ! test -f $DSA_KEY ; then echo -n "Generating SSH2 DSA host key: " if $KEYGEN -q -t dsa -f $DSA_KEY -C '' -N '' >&/dev/null; then - success "DSA key generation" + my_success "DSA key generation" echo else - failure "DSA key generation" + my_failure "DSA key generation" echo exit 1 fi @@ -75,10 +107,10 @@ sshd RETVAL=$? if [ "$RETVAL" = "0" ] ; then - success "sshd startup" + my_success "sshd startup" "sshd" touch /var/lock/subsys/sshd else - failure "sshd startup" + my_failure "sshd startup" "" fi fi echo From mouring at etoh.eviladmin.org Sat Feb 17 08:09:26 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 16 Feb 2001 15:09:26 -0600 (CST) Subject: OpenSSH 2.5.0p1 Message-ID: Known issues: 1) Linux 'sleep 20' -- Unfixable before 2.5.0 (known work around) 2) HP/UX signal issue -- Patched and HP/UX 11 works in v2 3) SCO 2/ Native Compiler -- Unfixable before 2.5.0 (known work around) 4) NeXTStep -- Resynced, MAX_GROUPS vs NGROUPS unresolved (not major) 5) DG/UX regcomp/regexec -- Fixed. 6) Cray signal issues -- ??? 7) Solaris '$PATH' issue -- ?? (Unfixable before 2.5.0?) [I'm getting more reports of this. I'll present them when they get their facts together] I guess what needs to be asked... Is what needs to OCCUR in the next 3 to 4 days to assure we have a stable project on majority of the platforms? - Ben From mouring at etoh.eviladmin.org Sat Feb 17 08:12:08 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 16 Feb 2001 15:12:08 -0600 (CST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Fri, 16 Feb 2001 mouring at etoh.eviladmin.org wrote: > > Known issues: > > 1) Linux 'sleep 20' -- Unfixable before 2.5.0 (known work around) > 2) HP/UX signal issue -- Patched and HP/UX 11 works in v2 > 3) SCO 2/ Native Compiler -- Unfixable before 2.5.0 (known work around) > 4) NeXTStep -- Resynced, MAX_GROUPS vs NGROUPS unresolved (not major) > 5) DG/UX regcomp/regexec -- Fixed. > 6) Cray signal issues -- ??? > 7) Solaris '$PATH' issue -- ?? (Unfixable before 2.5.0?) [I'm getting > more reports of this. I'll present them when they get their facts > together] > > I guess what needs to be asked... Is what needs to OCCUR in the next 3 > to 4 days to assure we have a stable project on majority of the platforms? > > - Ben > > Ermm.. Oops.. forgot two. 8) BSDi updates -- ?? post 2.5.0 ?? 9) AIX, 'login.h' and -I -- ?? Hmm... - Ben From pekkas at netcore.fi Sat Feb 17 07:29:25 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 16 Feb 2001 22:29:25 +0200 (EET) Subject: PATCH: make contrib/redhat/sshd.init work with older RH releases In-Reply-To: <20010216144807.A25687@quipu.half.pint-stowp.cx> Message-ID: On Fri, 16 Feb 2001, Jim Knoble wrote: > Attached is a patch to contrib/redhat/sshd.init which eliminates the > dependency on the success() and failure() functions from > initscripts>=4.16. This allows sshd.init to be used for both early and > recent releases of Red Hat Linux (i've confirmed it works on both 4.2 > and 5.2 as well as 6.2). Speaking of sshd.init.. I think it might be a good idea to mave some stuff under 'case' to their own functions as Red Hat has done in their own openssh package. Maintainability in both directions would be better, and the file hopefully cleaner. I can volunteer for some merging (in pre-2.5.0 timeline) if this is thought to be desirable. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From djm at web.us.uu.net Sat Feb 17 07:33:51 2001 From: djm at web.us.uu.net (David J. MacKenzie) Date: Fri, 16 Feb 2001 15:33:51 -0500 Subject: OpenSSH 2.3.0p1 port to BSDI BSD/OS In-Reply-To: Message from of "Fri, 16 Feb 2001 13:46:37 CST." Message-ID: <20010216203351.6DE1112685@jenkins.web.us.uu.net> > Could you please port up the latest snapshot > at: http://bass.directhit.com/openssh_snap? > > We are coming close to a 2.5.0p1 release so timing > is pretty critical. Here's a patch against CVS. It also applies to the latest snapshot. The mess regarding des.h on BSD/OS should probably be centralized somewhere. Sorry about the timing. Index: auth.h =================================================================== --- auth.h 2001/02/15 03:08:27 1.11 +++ auth.h 2001/02/16 20:22:32 @@ -82,7 +82,13 @@ int auth_rsa_challenge_dialog(RSA *pk); #ifdef KRB4 -#include +# include "cipher.h" +# ifdef HAVE_BSD_AUTH_H +# define DES_DEFS /* prevent BSD/OS krb.h from including kerberosIV/des.h */ +# include +# else /* !HAVE_BSD_AUTH_H */ +# include +# endif /* HAVE_BSD_AUTH_H */ /* * Performs Kerberos v4 mutual authentication with the client. This returns 0 * if the client could not be authenticated, and 1 if authentication was Index: auth1.c =================================================================== --- auth1.c 2001/02/15 03:14:11 1.34 +++ auth1.c 2001/02/16 20:22:32 @@ -24,6 +24,11 @@ #include "auth.h" #include "session.h" +#ifdef HAVE_BSD_AUTH_H +# include +# include +#endif + /* import */ extern ServerOptions options; extern char *forced_command; @@ -91,6 +96,8 @@ auth_pam_password(pw, "")) { #elif defined(HAVE_OSF_SIA) 0) { +#elif defined(HAVE_BSD_AUTH_H) + auth_userokay(authctxt->user, authctxt->style, "auth-ssh", "" )) { #else auth_password(pw, "")) { #endif @@ -260,7 +267,10 @@ /* Do SIA auth with password */ authenticated = auth_sia_password(authctxt->user, password); -#else /* !USE_PAM && !HAVE_OSF_SIA */ +#elif defined(HAVE_BSD_AUTH_H) + authenticated = auth_userokay(authctxt->user, authctxt->style, + "auth-ssh", password); +#else /* !USE_PAM && !HAVE_OSF_SIA && !HAVE_BSD_AUTH_H */ /* Try authentication with the password. */ authenticated = auth_password(pw, password); #endif /* USE_PAM */ @@ -324,6 +334,10 @@ if (authenticated && !do_pam_account(pw->pw_name, client_user)) authenticated = 0; #endif +#ifdef HAVE_BSD_AUTH_H + if (authenticated && !auth_approval(NULL, NULL, pw->pw_name, "ssh")) + authenticated = 0; +#endif /* HAVE_BSD_AUTH_H */ /* Log before sending the reply */ auth_log(authctxt, authenticated, get_authname(type), info); Index: auth2.c =================================================================== --- auth2.c 2001/02/16 03:17:59 1.42 +++ auth2.c 2001/02/16 20:22:32 @@ -48,6 +48,11 @@ #include "uidswap.h" #include "auth-options.h" +#ifdef HAVE_BSD_AUTH_H +# include +# include +#endif + /* import */ extern ServerOptions options; extern u_char *session_id2; @@ -239,6 +244,10 @@ NULL)) authenticated = 0; #endif /* USE_PAM */ +#ifdef HAVE_BSD_AUTH_H + if (authenticated && authctxt->user && !auth_approval(NULL, NULL, authctxt->user, "ssh")) + authenticated = 0; +#endif /* HAVE_BSD_AUTH_H */ /* Log before sending the reply */ auth_log(authctxt, authenticated, method, " ssh2"); @@ -340,7 +349,9 @@ return auth_pam_password(authctxt->pw, ""); #elif defined(HAVE_OSF_SIA) return 0; -#else /* !HAVE_OSF_SIA && !USE_PAM */ +#elif defined(HAVE_BSD_AUTH_H) + return auth_userokay(authctxt->user, authctxt->style, "auth-ssh", ""); +#else /* !HAVE_OSF_SIA && !USE_PAM && !HAVE_BSD_AUTH_H */ return auth_password(authctxt->pw, ""); #endif /* USE_PAM */ } @@ -365,7 +376,9 @@ auth_pam_password(authctxt->pw, password) == 1) #elif defined(HAVE_OSF_SIA) auth_sia_password(authctxt->user, password) == 1) -#else /* !USE_PAM && !HAVE_OSF_SIA */ +#elif defined(HAVE_BSD_AUTH_H) + auth_userokay(authctxt->user, authctxt->style, "auth-ssh", password) != 0) +#else /* !USE_PAM && !HAVE_OSF_SIA && !HAVE_BSD_AUTH_H */ auth_password(authctxt->pw, password) == 1) #endif /* USE_PAM */ authenticated = 1; Index: configure.in =================================================================== --- configure.in 2001/02/16 01:12:41 1.243 +++ configure.in 2001/02/16 20:22:32 @@ -354,7 +354,7 @@ ) # Checks for header files. -AC_CHECK_HEADERS(bstring.h endian.h floatingpoint.h getopt.h lastlog.h limits.h login.h login_cap.h maillock.h netdb.h netgroup.h netinet/in_systm.h paths.h poll.h pty.h regex.h shadow.h security/pam_appl.h sys/bitypes.h sys/bsdtty.h sys/cdefs.h sys/poll.h sys/queue.h sys/select.h sys/stat.h sys/stropts.h sys/sysmacros.h sys/time.h sys/ttcompat.h sys/un.h stddef.h time.h ttyent.h usersec.h util.h utime.h utmp.h utmpx.h vis.h) +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 regex.h shadow.h security/pam_appl.h sys/bitypes.h sys/bsdtty.h sys/cdefs.h sys/poll.h sys/queue.h sys/select.h sys/stat.h sys/stropts.h sys/sysmacros.h sys/time.h sys/ttcompat.h sys/un.h stddef.h time.h ttyent.h usersec.h util.h utime.h utmp.h utmpx.h vis.h bsd_auth.h) # Check whether user wants Kerberos support KRB4_MSG="no" Index: servconf.c =================================================================== --- servconf.c 2001/02/15 03:08:27 1.40 +++ servconf.c 2001/02/16 20:22:32 @@ -13,7 +13,13 @@ RCSID("$OpenBSD: servconf.c,v 1.67 2001/02/12 16:16:23 markus Exp $"); #ifdef KRB4 -#include +# include "cipher.h" +# ifdef HAVE_BSD_AUTH_H +# define DES_DEFS /* prevent BSD/OS krb.h from including kerberosIV/des.h */ +# include +# else /* !HAVE_BSD_AUTH_H */ +# include +# endif /* HAVE_BSD_AUTH_H */ #endif #ifdef AFS #include Index: session.c =================================================================== --- session.c 2001/02/16 16:02:14 1.77 +++ session.c 2001/02/16 20:22:32 @@ -1176,7 +1176,9 @@ child_set_env(&env, &envsize, "HOME", pw->pw_dir); #ifdef HAVE_LOGIN_CAP (void) setusercontext(lc, pw, pw->pw_uid, LOGIN_SETPATH); - child_set_env(&env, &envsize, "PATH", getenv("PATH")); + /* Update the path to the one setusercontext set for us */ + if (getenv("PATH")) + child_set_env(&env, &envsize, "PATH", getenv("PATH")); #else /* HAVE_LOGIN_CAP */ # ifndef HAVE_CYGWIN /* Index: sshconnect1.c =================================================================== --- sshconnect1.c 2001/02/16 01:34:57 1.24 +++ sshconnect1.c 2001/02/16 20:22:32 @@ -19,7 +19,12 @@ #include #ifdef KRB4 -#include +# ifdef HAVE_BSD_AUTH_H +# define DES_DEFS /* prevent BSD/OS krb.h from including kerberosIV/des.h */ +# include +# else /* !HAVE_BSD_AUTH_H */ +# include +# endif /* HAVE_BSD_AUTH_H */ #endif #ifdef AFS #include From djm at web.us.uu.net Sat Feb 17 07:47:38 2001 From: djm at web.us.uu.net (David J. MacKenzie) Date: Fri, 16 Feb 2001 15:47:38 -0500 Subject: OpenSSH 2.3.0p1 port to BSDI BSD/OS In-Reply-To: Message from "David J. MacKenzie" of "Fri, 16 Feb 2001 15:33:51 EST." <20010216203351.6DE1112685@jenkins.web.us.uu.net> Message-ID: <20010216204738.324AA12685@jenkins.web.us.uu.net> BTW, the KRB4 parts of the BSD/OS patch are independent of the others. Feel free to apply the rest of it, which I think it clean, if you don't want to deal with the KRB4 mess right now. It's only needed anyway when configuring --with-kerberos4=/usr which isn't so important on a system that has a pluggable authentication mechanism anyway. From drosih at rpi.edu Sat Feb 17 07:50:18 2001 From: drosih at rpi.edu (Garance A Drosihn) Date: Fri, 16 Feb 2001 15:50:18 -0500 Subject: ssh(R) trademark issues: comments and proposal In-Reply-To: <200102161051.MAA09237@mystery.acr.fi> References: <200102161051.MAA09237@mystery.acr.fi> Message-ID: At 12:51 PM +0200 2/16/01, Tatu Ylonen wrote: >I'd like to address several issues raised by people in relation >to my notice of the ssh(R) trademark to the OpenSSH group. Also, >I would like to make a proposal to the community for resolving >this issue (included at the end). I think Tatu has done a great service for the internet community by creating an encrypted alternative to telnet, one which became good enough, available widely enough, and promoted well enough that we can now talk about machines where telnetd is completely disabled. Part of the reason it caught on so well was the initial licensing. If the code had come out in 1994 with all of these trademark issues explicitly stated, then people would have shied away from it, and it would not have caught on as well. Witness, for instance, how much more reluctant people are to install ssh2 than the original ssh, even though everyone seems to agree that the ssh2 protocol is superior to ssh1's. The difference is in the licensing. I state that as fact, not opinion, because I know why WE (RPI) have not deployed ssh2 anywhere, except for machines which have openssh installed. While I can appreciate the challenge of running a company on software, I really don't see how you can retroactively change the original license. I find the following excerpt particularly ludicrous: >The confusion is made even worse by the fact that OpenSSH is >also a derivative of my original SSH Secure Shell product, >and it still looks very much like my product (without my >approval for any of it, by the way). The original license EXPLICITLY said: As far as I am concerned, the code I have written for this software can be used freely for any purpose. Any derived versions of this software must be clearly marked as such, and if the derived work is incompatible with the protocol description in the RFC file, it must be called by a name other than "ssh" or "Secure Shell". The openssh project took that paragraph literally. They used it to create another ssh. They clearly indicate that their work is a derivative of yours, because YOU EXPLICITLY ASKED people to do that. The result IS compatible with the RFC, and thus they do NOT have to change the name from 'ssh' and 'secure shell' to comply with the above paragraph. You EXPLICITLY said that "this software can be used FREELY for any purpose", so it's pretty odd that you now imply that people were supposed to ask for "your approval" before creating a derivative work. Part of your proposal states: - A new unencumbered name is created for the protocol, which can be used by any vendor without creating confusion. The IETF standard would be renamed to use the new protocol name, and the community would work to cease using "SSH" as a protocol name and would instead start using the new name. The new name would need to be unencumbered, and ... I think this just proves the fact that the name 'ssh' is already a generic term. It IS being used generically. You want to STOP that generic use, claiming that 'ssh' should be your trademark. However, it became a generic term BEFORE you had it registered as a trademark, which to me implies the problem is in the trademark, and not in its use as a generic term. So, I'm no lawyer, but I would be interested in hearing how your current position is legally defensible, given the actual history of events. As I say, I appreciate that you're trying to run a company, and I wish you no ill-will in that endeavor. However, I maintain that part of the reason for the success of ssh (the protocol) was the original licensing, and I don't appreciate that you are now trying to subvert that original license. In your message, you also claim: >The reason OpenSSH was contacted now was that they have only >become more visible during the last months, and I have recently >seen a significant increase in e-mails confusing the meaning of >the SSH trademarks and using them inappropriately. In your earlier message, you mentioned: >We have also been distributing free versions of SSH Secure Shell >under the SSH brand since 1995. The latest version, ssh-2.4.0, >is free for any use on the Linux, FreeBSD, NetBSD, and OpenBSD >operating systems, ... Funny how ssh2 is available for free for these operating systems, ALL OF WHICH now ship with openssh (although I guess NetBSD might soon change). I must admit that I do not know your current license, but back when OpenSSH was just starting to appear I am pretty certain that we could NOT use ssh2 "for any use" on OpenBSD or FreeBSD. How is it that you now know these operating systems well enough to list them in your license, but you were not aware that OpenSSH was available for all of them? I think you will have trouble proving "due diligence" in protecting your trademark, under these circumstances. Speaking of "due diligence", you should also note: ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/pkgsrc/security/fressh/README.html ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/pkgsrc/security/fressh/pkg/DESCR which talks about "fressh", a clean-room implementation of the ssh protocols. You'll need to go after them, too, I would think. At 12:51 PM +0200 2/16/01, Tatu Ylonen wrote: >Please also try to look at this from my viewpoint. I developed >SSH (Secure Shell), started using the name for it, established >a company using the name, all of our products are marketed >using the SSH brand, and we have created a fairly widely known >global brand using the name. When did you start using the SSH brand for your company products? As far as I'm aware, I initially bought your products thru a company called DataFellows, under a brand name of 'F-Secure'. (and yes, I did buy Mac clients thru there). It is only in the last year or two that I was aware that ssh.com sold clients of it's own. By then, openssh and teraterm ssh were well known. In the Mac world, there's also "MacSSH" and "NiftyTelnet SSH" (check www.macorchard.com, under the 'Terminal' section). You will also need to go after all of those, if you have problems with OpenSSH infringing on your trademark. You also wrote: > > "the SSH Corp trademark registration in the US is for a logo only" > >It is for the lowercase word "ssh" (I was mistaken earlier in >saying that it was for the uppercase word "SSH"). Note that here you claim it is explicitly for the LOWERCASE word 'ssh'. >Under US law, a trademark registration entitles the owner to >exclusive use of the trademark as it is registered, in relation >to the goods and/or services for which it is registered. [...]. >Consequently, use of the uppercase word "SSH" or a name >containing the "ssh" or "SSH" mark will likely amount to >trademark infringement under US law, if it is in relation >to goods or services within the same field of use covered by >our ssh(R) trademark. And here you claim that the uppercase word is also "likely" covered by it. Another legal point which seems odd to me. If the uppercase word is covered, then why wouldn't the trademark be for "ssh" instead of "the lowercase word 'ssh'". Perhaps this is one of those nuances of law that I just don't understand. Still, if you CAN get the IETF and everyone else to go along with this, then I don't have much reason to object. I do think it is inappropriate, and something of a waste of time. I know you think that 'ssh' as a trademark is valuable, but if you do change the name then you can be pretty sure that everyone that you have irritated will do their best to put that value into the new, generic and unencumbered name. I would think that we would make sure that 'ssh' is not referenced anywhere, in any man pages or other documentation. We would only use generic names, to make sure we do not ever hear from your lawyers again. However, it does seem to me that you should need to get IETF to agree, and to MAKE all the necessary changes, before you expect the OpenSSH project to consider changing it's name. Right now, OpenSSH is just an implementation of the generic protocol known as ssh. I don't see a problem. I also wonder how you can guarantee the new name will remain unencumbered. I mean, we used 'ssh' because we thought IT was unencumbered, as long as we made something compatible with the ssh protocol. If we use 'secsh', how do we know that Van Dyke won't pull the same stunt a few years from now, and claim that we owe THEM something due to copyright infringement? If we do pick some new term, then I suggest that we only consider alternatives which are brought up by someone who we can trust to leave that term as a generic term. I'm afraid to say that I doubt we can trust ssh.com to do that. Disclaimer: while I happen to have an account at freebsd.org, please note that all of the above are my own personal thoughts, and should not be taken as the position of "the freebsd project" or much of anyone else. In a separate message, which just came in as I was about to hit "send" on this, Bill Sommerfeld wrote: >Please do not CC: discussions of the validity of the ssh >trademark to the IETF Secure Shell protocol working group list >; they're out of scope for the working group. I appreciate this, except that Tatu claims the IETF will be asked to change the protocol name. If the working group is planning on a name change, then it is relevant to this debate. More importantly, if the working group has NO intention of changing the name, then it seems to me that openssh is just an implementation of a generic protocol named 'ssh'. This message (this one here, the one I am writing) is a reply to Tatu Ylonen, and it was Tatu who felt this was appropriate for the ietf-ssh mailing list. Perhaps that is the wrong list, but I don't know what else in the ietf would be the correct alternative. So, it is not that I'm trying to ignore Bill's request, but I don't know who else is supposed to clarify IETF's position on this. -- Garance Alistair Drosehn = gad at eclipse.acs.rpi.edu Senior Systems Programmer or gad at freebsd.org Rensselaer Polytechnic Institute or drosih at rpi.edu From mouring at etoh.eviladmin.org Sat Feb 17 08:47:56 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 16 Feb 2001 15:47:56 -0600 (CST) Subject: OpenSSH 2.3.0p1 port to BSDI BSD/OS In-Reply-To: <20010216204738.324AA12685@jenkins.web.us.uu.net> Message-ID: On Fri, 16 Feb 2001, David J. MacKenzie wrote: > > BTW, the KRB4 parts of the BSD/OS patch are independent of the others. > Feel free to apply the rest of it, which I think it clean, if you > don't want to deal with the KRB4 mess right now. It's only needed > anyway when configuring --with-kerberos4=/usr which isn't so important > on a system that has a pluggable authentication mechanism anyway. > I assume you are refering to the two blocks of code that look like: #ifdef KRB4 -#include +# include "cipher.h" +# ifdef HAVE_BSD_AUTH_H +# define DES_DEFS /* prevent BSD/OS krb.h from including kerberosIV/des.h */ +# include +# else /* !HAVE_BSD_AUTH_H */ +# include +# endif /* HAVE_BSD_AUTH_H */ #endif #ifdef AFS #include From gert at greenie.muc.de Sat Feb 17 08:02:22 2001 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 16 Feb 2001 22:02:22 +0100 Subject: OpenSSH 2.5.0p1 In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Feb 16, 2001 at 03:12:08PM -0600 References: Message-ID: <20010216220222.A19644@greenie.muc.de> Hi, On Fri, Feb 16, 2001 at 03:12:08PM -0600, mouring at etoh.eviladmin.org wrote: > 9) AIX, 'login.h' and -I -- ?? Hmm... The "easy" way would be just to rename login.h. We can then check the necessity of "-I." for 2.6.* (-I.. is definitely needed for openbsd-compat/, and -I$(srcdir) might be necessary when building in a different tree than the source tree, so I'd opt for just renaming login.h) 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 web.us.uu.net Sat Feb 17 08:02:36 2001 From: djm at web.us.uu.net (David J. MacKenzie) Date: Fri, 16 Feb 2001 16:02:36 -0500 Subject: OpenSSH 2.3.0p1 port to BSDI BSD/OS In-Reply-To: Message from of "Fri, 16 Feb 2001 15:47:56 CST." Message-ID: <20010216210236.3827112685@jenkins.web.us.uu.net> > I assume you are refering to the two blocks of code that look like: Yes (actually there are 3 such blocks). > #ifdef KRB4 > -#include > +# include "cipher.h" > +# ifdef HAVE_BSD_AUTH_H > +# define DES_DEFS /* prevent BSD/OS krb.h from including > kerberosIV/des.h */ > +# include > +# else /* !HAVE_BSD_AUTH_H */ > +# include > +# endif /* HAVE_BSD_AUTH_H */ > #endif > #ifdef AFS > #include > > > > From djm at mindrot.org Sat Feb 17 08:10:32 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 17 Feb 2001 08:10:32 +1100 (EST) Subject: OpenSSH 2.3.0p4/2.2.0p1, Solaris 8, ssh-keygen bus error In-Reply-To: Message-ID: On Fri, 9 Feb 2001, Edward S. Marshall wrote: > On Fri, 9 Feb 2001, Damien Miller wrote: > > Could you please turn on very verbose debugging "ssh -v -v -v " and > > report the output? > > A little more information; sshd is failing with a bus error as well (the > client seems fine so far in light use): This looks like a crash in OpenSSL. Are you using the same version of OpenSSL that you compiled OpenSSH against? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sat Feb 17 08:16:05 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 17 Feb 2001 08:16:05 +1100 (EST) Subject: OpenSSH 2.5.0p1 In-Reply-To: <20010216220222.A19644@greenie.muc.de> Message-ID: On Fri, 16 Feb 2001, Gert Doering wrote: > Hi, > > On Fri, Feb 16, 2001 at 03:12:08PM -0600, mouring at etoh.eviladmin.org wrote: > > 9) AIX, 'login.h' and -I -- ?? Hmm... > > The "easy" way would be just to rename login.h. We can then check the > necessity of "-I." for 2.6.* > > (-I.. is definitely needed for openbsd-compat/, and -I$(srcdir) might be > necessary when building in a different tree than the source tree, so I'd > opt for just renaming login.h) Can we just detect [ $(srcdir) = "." ] and not do the -I? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From gert at greenie.muc.de Sat Feb 17 08:19:50 2001 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 16 Feb 2001 22:19:50 +0100 Subject: OpenSSH 2.5.0p1 In-Reply-To: ; from Damien Miller on Sat, Feb 17, 2001 at 08:16:05AM +1100 References: <20010216220222.A19644@greenie.muc.de> Message-ID: <20010216221950.B19644@greenie.muc.de> Hi, On Sat, Feb 17, 2001 at 08:16:05AM +1100, Damien Miller wrote: > > On Fri, Feb 16, 2001 at 03:12:08PM -0600, mouring at etoh.eviladmin.org wrote: > > > 9) AIX, 'login.h' and -I -- ?? Hmm... > > > > The "easy" way would be just to rename login.h. We can then check the > > necessity of "-I." for 2.6.* > > > > (-I.. is definitely needed for openbsd-compat/, and -I$(srcdir) might be > > necessary when building in a different tree than the source tree, so I'd > > opt for just renaming login.h) > > Can we just detect [ $(srcdir) = "." ] and not do the -I? Won't help - this will make AIX build if $srcdir=., but will make it break when $srcdir != . - nothing gained. I can't see a way to get #include to ignore a local copy of that file *AND* make "building in a separate bin tree" work. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From mouring at etoh.eviladmin.org Sat Feb 17 08:25:30 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 16 Feb 2001 15:25:30 -0600 (CST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Damien Miller wrote: > On Fri, 16 Feb 2001, Gert Doering wrote: > > > Hi, > > > > On Fri, Feb 16, 2001 at 03:12:08PM -0600, mouring at etoh.eviladmin.org wrote: > > > 9) AIX, 'login.h' and -I -- ?? Hmm... > > > > The "easy" way would be just to rename login.h. We can then check the > > necessity of "-I." for 2.6.* > > > > (-I.. is definitely needed for openbsd-compat/, and -I$(srcdir) might be > > necessary when building in a different tree than the source tree, so I'd > > opt for just renaming login.h) > > Can we just detect [ $(srcdir) = "." ] and not do the -I? > That was my thought. But I was not sure if it would go into configure.in or the Makefile.in file. - Ben From markus.friedl at informatik.uni-erlangen.de Sat Feb 17 08:21:47 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 16 Feb 2001 22:21:47 +0100 Subject: OpenSSH 2.3.0p1 port to BSDI BSD/OS In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Feb 16, 2001 at 01:46:37PM -0600 References: <14989.28161.846650.358750@jenkins.web.us.uu.net> Message-ID: <20010216222147.A17387@folly> this patch adds support for BSD_AUTH to openssh it's against OpenBSD' current cvs and will be probably integrated if BSD_AUTH is in the openbsd tree. this should work on BSD/OS, too, but i did not yet test. Index: auth-chall.c =================================================================== RCS file: /home/markus/cvs/ssh/auth-chall.c,v retrieving revision 1.4 diff -u -r1.4 auth-chall.c --- auth-chall.c 2001/02/04 15:32:22 1.4 +++ auth-chall.c 2001/02/05 18:12:48 @@ -26,7 +26,47 @@ RCSID("$OpenBSD: auth-chall.c,v 1.4 2001/02/04 15:32:22 stevesk Exp $"); #include "auth.h" +#include "log.h" +#ifdef BSD_AUTH +char * +get_challenge(Authctxt *authctxt, char *devs) +{ + char *challenge; + + if (authctxt->as != NULL) { + debug("try reuse session"); + challenge = auth_getitem(authctxt->as, AUTHV_CHALLENGE); + if (challenge != NULL) { + debug2("reuse bsd auth session"); + return challenge; + } + auth_close(authctxt->as); + authctxt->as = NULL; + } + debug2("new bsd auth session"); + if (devs && strlen(devs) == 0) + devs = NULL; + authctxt->as = auth_userchallenge(authctxt->user, devs, "auth-ssh", + &challenge); + if (authctxt->as == NULL) + return NULL; + debug2("get_challenge: <%s>", challenge ? challenge : "EMPTY"); + return challenge; +} +int +verify_response(Authctxt *authctxt, char *response) +{ + int authok; + + if (authctxt->as == 0) + error("verify_response: no bsd auth session"); + authok = auth_userresponse(authctxt->as, response, 0); + authctxt->as = NULL; + debug("verify_response: <%s> = <%d>", response, authok); + return authok != 0; +} +#else #ifdef SKEY #include @@ -59,4 +99,5 @@ { return 0; } +#endif #endif Index: auth-passwd.c =================================================================== RCS file: /home/markus/cvs/ssh/auth-passwd.c,v retrieving revision 1.21 diff -u -r1.21 auth-passwd.c --- auth-passwd.c 2001/02/12 16:16:23 1.21 +++ auth-passwd.c 2001/02/16 21:15:50 @@ -61,6 +61,12 @@ return 0; if (*password == '\0' && options.permit_empty_passwd == 0) return 0; +#ifdef BSD_AUTH + if (auth_userokay(pw->pw_name, NULL, "auth-ssh", (char *)password) == 0) + return 0; + else + return 1; +#endif #ifdef KRB4 if (options.kerberos_authentication == 1) { Index: auth.h =================================================================== RCS file: /home/markus/cvs/ssh/auth.h,v retrieving revision 1.11 diff -u -r1.11 auth.h --- auth.h 2001/02/12 16:16:23 1.11 +++ auth.h 2001/02/16 21:15:50 @@ -28,6 +28,13 @@ #include +#ifdef HAVE_LOGIN_CAP +#include +#endif +#ifdef BSD_AUTH +#include +#endif + typedef struct Authctxt Authctxt; struct Authctxt { int success; @@ -39,6 +46,9 @@ char *service; struct passwd *pw; char *style; +#ifdef BSD_AUTH + auth_session_t *as; +#endif }; /* Index: auth1.c =================================================================== RCS file: /home/markus/cvs/ssh/auth1.c,v retrieving revision 1.17 diff -u -r1.17 auth1.c --- auth1.c 2001/02/13 22:49:40 1.17 +++ auth1.c 2001/02/16 21:15:50 @@ -284,6 +284,12 @@ log("Unknown message during authentication: type %d", type); break; } +#ifdef BSD_AUTH + if (authctxt->as) { + auth_close(authctxt->as); + authctxt->as = NULL; + } +#endif if (!authctxt->valid && authenticated) fatal("INTERNAL ERROR: authenticated invalid user %s", authctxt->user); Index: auth2.c =================================================================== RCS file: /home/markus/cvs/ssh/auth2.c,v retrieving revision 1.42 diff -u -r1.42 auth2.c --- auth2.c 2001/02/13 22:49:40 1.42 +++ auth2.c 2001/02/16 21:15:51 @@ -208,6 +208,12 @@ /* reset state */ dispatch_set(SSH2_MSG_USERAUTH_INFO_RESPONSE, &protocol_error); authctxt->postponed = 0; +#ifdef BSD_AUTH + if (authctxt->as) { + auth_close(authctxt->as); + authctxt->as = NULL; + } +#endif /* try to authenticate user */ m = authmethod_lookup(method); Index: session.c =================================================================== RCS file: /home/markus/cvs/ssh/session.c,v retrieving revision 1.56 diff -u -r1.56 session.c --- session.c 2001/02/16 14:03:43 1.56 +++ session.c 2001/02/16 21:15:54 @@ -58,10 +58,6 @@ #include "canohost.h" #include "session.h" -#ifdef HAVE_LOGIN_CAP -#include -#endif - /* types */ #define TTYSZ 64 @@ -837,8 +833,13 @@ (LOGIN_SETALL & ~LOGIN_SETPATH)) < 0) { perror("unable to set user context"); exit(1); - } +#ifdef BSD_AUTH + if (auth_approval(NULL, lc, pw->pw_name, "auth-ssh") <= 0) { + perror("Approval failure"); + exit(1); + } +#endif #else if (setlogin(pw->pw_name) < 0) error("setlogin failed: %s", strerror(errno)); Index: sshd/Makefile =================================================================== RCS file: /home/markus/cvs/ssh/sshd/Makefile,v retrieving revision 1.35 diff -u -r1.35 Makefile --- sshd/Makefile 2001/01/29 01:58:23 1.35 +++ sshd/Makefile 2001/01/31 17:32:43 @@ -7,7 +7,7 @@ BINMODE=555 BINDIR= /usr/sbin MAN= sshd.8 -CFLAGS+=-DHAVE_LOGIN_CAP +CFLAGS+=-DHAVE_LOGIN_CAP -DBSD_AUTH SRCS= sshd.c auth-rhosts.c auth-passwd.c auth-rsa.c auth-rh-rsa.c \ pty.c log-server.c login.c servconf.c serverloop.c \ From djm at mindrot.org Sat Feb 17 08:23:32 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 17 Feb 2001 08:23:32 +1100 (EST) Subject: OpenSSH 2.5.0p1 In-Reply-To: <20010216221950.B19644@greenie.muc.de> Message-ID: On Fri, 16 Feb 2001, Gert Doering wrote: > Won't help - this will make AIX build if $srcdir=., but will make it break > when $srcdir != . - nothing gained. > > I can't see a way to get #include to ignore a local copy of that > file *AND* make "building in a separate bin tree" work. If you are using gcc, then you can use -idirafter instead of -i -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at web.us.uu.net Sat Feb 17 08:38:03 2001 From: djm at web.us.uu.net (David J. MacKenzie) Date: Fri, 16 Feb 2001 16:38:03 -0500 Subject: OpenSSH 2.3.0p1 port to BSDI BSD/OS In-Reply-To: Message from Markus Friedl of "Fri, 16 Feb 2001 22:21:47 +0100." <20010216222147.A17387@folly> Message-ID: <20010216213803.2A02512685@jenkins.web.us.uu.net> > this should work on BSD/OS, too, but i did not yet test. It compiles on BSD/OS 4.0.1 when applied to the CVS version. However I see a few shortcomings: > --- auth-passwd.c 2001/02/12 16:16:23 1.21 > +++ auth-passwd.c 2001/02/16 21:15:50 > @@ -61,6 +61,12 @@ > return 0; > if (*password == '\0' && options.permit_empty_passwd == 0) > return 0; > +#ifdef BSD_AUTH > + if (auth_userokay(pw->pw_name, NULL, "auth-ssh", (char *)password) == 0) > + return 0; > + else > + return 1; > +#endif > > #ifdef KRB4 > if (options.kerberos_authentication == 1) { That ignores any style specified by the user. As in, "ssh -l djm:skey host" or "-l djm:passwd". The NULL should be authctxt->style, except that the auth context isn't passed to that function. > Index: session.c > @@ -837,8 +833,13 @@ > (LOGIN_SETALL & ~LOGIN_SETPATH)) < 0) { > perror("unable to set user context"); > exit(1); > - > } > +#ifdef BSD_AUTH > + if (auth_approval(NULL, lc, pw->pw_name, "auth-ssh") <= 0) { > + perror("Approval failure"); > + exit(1); > + } > +#endif > #else > if (setlogin(pw->pw_name) < 0) > error("setlogin failed: %s", strerror(errno)); The arg to auth_approval shouldn't start with "auth-" on BSD/OS. It should be either just "ssh" or "approve-ssh", because auth_approval() does this: if (!type) type = LOGIN_DEFSERVICE; else { if (strncmp(type, "approve-", 8) == 0) type += 8; snprintf(path, sizeof(path), "approve-%s", type); } From djm at mindrot.org Sat Feb 17 08:53:11 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 17 Feb 2001 08:53:11 +1100 (EST) Subject: PATCH: make contrib/redhat/sshd.init work with older RH releases In-Reply-To: Message-ID: On Fri, 16 Feb 2001, Pekka Savola wrote: > Speaking of sshd.init.. I think it might be a good idea to mave some stuff > under 'case' to their own functions as Red Hat has done in their own > openssh package. > > Maintainability in both directions would be better, and the file hopefully > cleaner. > > I can volunteer for some merging (in pre-2.5.0 timeline) if this is > thought to be desirable. That would be great, thanks. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From Markus.Friedl at informatik.uni-erlangen.de Sat Feb 17 08:58:49 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 16 Feb 2001 22:58:49 +0100 Subject: OpenSSH 2.3.0p1 port to BSDI BSD/OS In-Reply-To: <20010216213803.2A02512685@jenkins.web.us.uu.net>; from djm@web.us.uu.net on Fri, Feb 16, 2001 at 04:38:03PM -0500 References: <20010216213803.2A02512685@jenkins.web.us.uu.net> Message-ID: <20010216225848.A7973@faui02.informatik.uni-erlangen.de> On Fri, Feb 16, 2001 at 04:38:03PM -0500, David J. MacKenzie wrote: > > +#ifdef BSD_AUTH > > + if (auth_userokay(pw->pw_name, NULL, "auth-ssh", (char *)password) == 0) > > + return 0; > > + else > > + return 1; > > +#endif > > > > #ifdef KRB4 > > if (options.kerberos_authentication == 1) { > > That ignores any style specified by the user. it does not, see below. > As in, "ssh -l djm:skey host" or "-l djm:passwd". > The NULL should be authctxt->style, except that the auth context > isn't passed to that function. skey is handled in auth-chall.c turn on 'challengeresponseauthentication=yes' in .ssh/config 1) in SSH1: ssh -l markus:skey host 2) in SSH2: ssh -l markus -o 'kbdinteractivedevice=crypto' host i'll change that to markus:crypto in ssh2, too. > > Index: session.c > > @@ -837,8 +833,13 @@ > > (LOGIN_SETALL & ~LOGIN_SETPATH)) < 0) { > > perror("unable to set user context"); > > exit(1); > > - > > } > > +#ifdef BSD_AUTH > > + if (auth_approval(NULL, lc, pw->pw_name, "auth-ssh") <= 0) { > > + perror("Approval failure"); > > + exit(1); > > + } > > +#endif > > #else > > if (setlogin(pw->pw_name) < 0) > > error("setlogin failed: %s", strerror(errno)); > > The arg to auth_approval shouldn't start with "auth-" on BSD/OS. > It should be either just "ssh" or "approve-ssh", because auth_approval() yes, you are right, i was unsure about this. any other problem? both cryptocard or skey work fine with the patch, in ssh1 and ssh2. -markus From emarshall at mercantec.com Sat Feb 17 09:15:14 2001 From: emarshall at mercantec.com (Edward S. Marshall) Date: Fri, 16 Feb 2001 16:15:14 -0600 (CST) Subject: OpenSSH 2.3.0p4/2.2.0p1, Solaris 8, ssh-keygen bus error In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Damien Miller wrote: > This looks like a crash in OpenSSL. Are you using the same version of > OpenSSL that you compiled OpenSSH against? Yep; I've even tried this with both OpenSSL 0.9.5a and 0.9.6 (with clean removals of one before trying the other). The interesting thing to note is that an OpenSSL/OpenSSH combo packaged up under Solaris 7 works just peachy on this machine; it's only the native build on Solaris 8 that's failing. Very weird. -- Edward S. Marshall UNIX Administrator http://www.nyx.net/~emarshal/ Mercantec, Inc. From djm at mindrot.org Sat Feb 17 09:21:37 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 17 Feb 2001 09:21:37 +1100 (EST) Subject: OpenSSH 2.3.0p4/2.2.0p1, Solaris 8, ssh-keygen bus error In-Reply-To: Message-ID: On Fri, 16 Feb 2001, Edward S. Marshall wrote: > Yep; I've even tried this with both OpenSSL 0.9.5a and 0.9.6 (with clean > removals of one before trying the other). > > The interesting thing to note is that an OpenSSL/OpenSSH combo packaged up > under Solaris 7 works just peachy on this machine; it's only the native > build on Solaris 8 that's failing. Very weird. Does OpenSSL "make test" run without error? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at web.us.uu.net Sat Feb 17 09:30:34 2001 From: djm at web.us.uu.net (David J. MacKenzie) Date: Fri, 16 Feb 2001 17:30:34 -0500 Subject: OpenSSH 2.3.0p1 port to BSDI BSD/OS In-Reply-To: Message from Markus Friedl of "Fri, 16 Feb 2001 22:58:49 +0100." <20010216225848.A7973@faui02.informatik.uni-erlangen.de> Message-ID: <20010216223034.6032E12685@jenkins.web.us.uu.net> > > That ignores any style specified by the user. > > it does not, see below. It ignores some styles, then. I applied it to the openssh_cvs tree from :pserver:cvs at bass.directhit.com:/cvs and here's what happened. I'll use our actual situation, though it's more complicated. We have a locally written /usr/libexec/login_krb5 and in /etc/login.conf our "default" entry has: :auth=krb5,kerberos,passwd,activ,crypto,skey:\ The only styles we really use are krb5 and passwd, though, that doesn't matter. After installing your patch and restarting sshd, I tried "ssh -l djm:passwd" to that host, and it only accepted my krb5 password, not my master.passwd one. "ssh -l djm:foo" had the same effect, instead of rejecting all passwords. With the patch I submitted, "-l djm:passwd" and "-l djm:krb5" only accept the master.passwd and krb5 passwords respectively, and "-l djm:foo" accepts neither. > any other problem? I don't see any. From Markus.Friedl at informatik.uni-erlangen.de Sat Feb 17 09:53:09 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 16 Feb 2001 23:53:09 +0100 Subject: OpenSSH 2.3.0p1 port to BSDI BSD/OS In-Reply-To: <20010216223034.6032E12685@jenkins.web.us.uu.net>; from djm@web.us.uu.net on Fri, Feb 16, 2001 at 05:30:34PM -0500 References: <20010216223034.6032E12685@jenkins.web.us.uu.net> Message-ID: <20010216235309.F7973@faui02.informatik.uni-erlangen.de> On Fri, Feb 16, 2001 at 05:30:34PM -0500, David J. MacKenzie wrote: > With the patch I submitted, "-l djm:passwd" and "-l djm:krb5" > only accept the master.passwd and krb5 passwords respectively, > and "-l djm:foo" accepts neither. yes i see. in auth1.c the authctxt should be passed to auth_password and not pw. this way authctxt->style can be used by auth_userok From emarshall at mercantec.com Sat Feb 17 09:56:25 2001 From: emarshall at mercantec.com (Edward S. Marshall) Date: Fri, 16 Feb 2001 16:56:25 -0600 (CST) Subject: OpenSSH 2.3.0p4/2.2.0p1, Solaris 8, ssh-keygen bus error In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Damien Miller wrote: > Does OpenSSL "make test" run without error? I just re-ran the test with 0.9.6 to be sure; no errors reported: [...snip...] OpenSSL 0.9.6 24 Sep 2000 built on: Tue Feb 6 11:06:44 CST 2001 platform: solaris-sparcv9-gcc options: bn(32,32) md2(int) rc4(ptr,int) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: gcc -fPIC -DTHREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -mcpu=ultrasparc -O3 -fomit-frame-pointer -Wall -DB_ENDIAN -DBN_DIV2W -DULTRASPARC -DMD5_ASM [...snip...] I'm going to try a hybrid of OpenSSL 0.9.6 from Solaris 7 with OpenSSH 2.3.0p1 from Solaris 8; if that works, then I've eliminated one possible variable. -- Edward S. Marshall UNIX Administrator http://www.nyx.net/~emarshal/ Mercantec, Inc. From djm at mindrot.org Sat Feb 17 09:56:58 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 17 Feb 2001 09:56:58 +1100 (EST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Fri, 16 Feb 2001 mouring at etoh.eviladmin.org wrote: > > Can we just detect [ $(srcdir) = "." ] and not do the -I? > > That was my thought. But I was not sure if it would go into configure.in > or the Makefile.in file. Here is a patch that does this. Unfortunately as Gert pointed out, this doesn't fix it for the builddir != srcdir case. Index: Makefile.in =================================================================== RCS file: /var/cvs/openssh/Makefile.in,v retrieving revision 1.152 diff -u -r1.152 Makefile.in --- Makefile.in 2001/02/15 03:01:59 1.152 +++ Makefile.in 2001/02/16 22:54:02 @@ -26,7 +26,7 @@ CC=@CC@ LD=@LD@ CFLAGS=@CFLAGS@ -CPPFLAGS=@CPPFLAGS@ -I. -I$(srcdir)/openbsd-compat -I$(srcdir) $(PATHS) @DEFS@ +CPPFLAGS=@CPPFLAGS@ -I$(srcdir)/openbsd-compat $(PATHS) @DEFS@ LIBS=@LIBS@ AR=@AR@ RANLIB=@RANLIB@ Index: configure.in =================================================================== RCS file: /var/cvs/openssh/configure.in,v retrieving revision 1.243 diff -u -r1.243 configure.in --- configure.in 2001/02/16 01:12:41 1.243 +++ configure.in 2001/02/16 22:54:03 @@ -20,6 +20,10 @@ AC_PATH_PROG(TEST_MINUS_S_SH, ksh) AC_PATH_PROG(TEST_MINUS_S_SH, sh) +if test -z "${srcdir}" -o "x${srcdir}" != "x." ; then + CPPFLAGS="-I. -I${srcdir} $CPPFLAGS"; +fi + if test -z "$AR" ; then AC_MSG_ERROR([*** 'ar' missing, please install or fix your \$PATH ***]) fi Index: openbsd-compat/Makefile.in =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/Makefile.in,v retrieving revision 1.5 diff -u -r1.5 Makefile.in --- openbsd-compat/Makefile.in 2001/02/09 01:55:36 1.5 +++ openbsd-compat/Makefile.in 2001/02/16 22:54:03 @@ -9,7 +9,7 @@ CC=@CC@ LD=@LD@ CFLAGS=@CFLAGS@ -CPPFLAGS=@CPPFLAGS@ -I. -I.. -I$(srcdir) -I$(srcdir)/.. @DEFS@ +CPPFLAGS=@CPPFLAGS@ -I$(srcdir) -I$(srcdir)/.. @DEFS@ LIBS=@LIBS@ AR=@AR@ RANLIB=@RANLIB@ Index: openbsd-compat/base64.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/base64.h,v retrieving revision 1.2 diff -u -r1.2 base64.h --- openbsd-compat/base64.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/base64.h 2001/02/16 22:54:03 @@ -3,8 +3,6 @@ #ifndef _BSD_BASE64_H #define _BSD_BASE64_H -#include "config.h" - #ifndef HAVE___B64_NTOP # ifndef HAVE_B64_NTOP int b64_ntop(u_char const *src, size_t srclength, char *target, Index: openbsd-compat/bindresvport.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/bindresvport.h,v retrieving revision 1.2 diff -u -r1.2 bindresvport.h --- openbsd-compat/bindresvport.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/bindresvport.h 2001/02/16 22:54:03 @@ -3,8 +3,6 @@ #ifndef _BSD_BINDRESVPORT_H #define _BSD_BINDRESVPORT_H -#include "config.h" - #ifndef HAVE_BINDRESVPORT_SA int bindresvport_sa(int sd, struct sockaddr *sa); #endif /* !HAVE_BINDRESVPORT_SA */ Index: openbsd-compat/bsd-arc4random.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/bsd-arc4random.h,v retrieving revision 1.2 diff -u -r1.2 bsd-arc4random.h --- openbsd-compat/bsd-arc4random.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/bsd-arc4random.h 2001/02/16 22:54:03 @@ -27,8 +27,6 @@ #ifndef _BSD_ARC4RANDOM_H #define _BSD_ARC4RANDOM_H -#include "config.h" - #ifndef HAVE_ARC4RANDOM unsigned int arc4random(void); void arc4random_stir(void); Index: openbsd-compat/bsd-cygwin_util.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/bsd-cygwin_util.h,v retrieving revision 1.2 diff -u -r1.2 bsd-cygwin_util.h --- openbsd-compat/bsd-cygwin_util.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/bsd-cygwin_util.h 2001/02/16 22:54:03 @@ -15,8 +15,6 @@ /* $Id: bsd-cygwin_util.h,v 1.2 2001/02/09 01:55:36 djm Exp $ */ -#include "config.h" - #ifdef HAVE_CYGWIN int binary_open(const char *filename, int flags, ...); Index: openbsd-compat/bsd-misc.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/bsd-misc.h,v retrieving revision 1.2 diff -u -r1.2 bsd-misc.h --- openbsd-compat/bsd-misc.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/bsd-misc.h 2001/02/16 22:54:03 @@ -27,8 +27,6 @@ #ifndef _BSD_MISC_H #define _BSD_MISC_H -#include "config.h" - char *get_progname(char *argv0); #ifndef HAVE_SETSID Index: openbsd-compat/bsd-snprintf.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/bsd-snprintf.h,v retrieving revision 1.2 diff -u -r1.2 bsd-snprintf.h --- openbsd-compat/bsd-snprintf.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/bsd-snprintf.h 2001/02/16 22:54:03 @@ -3,8 +3,6 @@ #ifndef _BSD_SNPRINTF_H #define _BSD_SNPRINTF_H -#include "config.h" - #include /* For size_t */ #ifndef HAVE_SNPRINTF Index: openbsd-compat/daemon.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/daemon.h,v retrieving revision 1.2 diff -u -r1.2 daemon.h --- openbsd-compat/daemon.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/daemon.h 2001/02/16 22:54:03 @@ -3,7 +3,6 @@ #ifndef _BSD_DAEMON_H #define _BSD_DAEMON_H -#include "config.h" #ifndef HAVE_DAEMON int daemon(int nochdir, int noclose); #endif /* !HAVE_DAEMON */ Index: openbsd-compat/fake-getaddrinfo.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/fake-getaddrinfo.h,v retrieving revision 1.2 diff -u -r1.2 fake-getaddrinfo.h --- openbsd-compat/fake-getaddrinfo.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/fake-getaddrinfo.h 2001/02/16 22:54:03 @@ -3,8 +3,6 @@ #ifndef _FAKE_GETADDRINFO_H #define _FAKE_GETADDRINFO_H -#include "config.h" - #include "fake-gai-errnos.h" #ifndef AI_PASSIVE Index: openbsd-compat/fake-getnameinfo.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/fake-getnameinfo.h,v retrieving revision 1.2 diff -u -r1.2 fake-getnameinfo.h --- openbsd-compat/fake-getnameinfo.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/fake-getnameinfo.h 2001/02/16 22:54:03 @@ -3,8 +3,6 @@ #ifndef _FAKE_GETNAMEINFO_H #define _FAKE_GETNAMEINFO_H -#include "config.h" - #ifndef HAVE_GETNAMEINFO int getnameinfo(const struct sockaddr *sa, size_t salen, char *host, size_t hostlen, char *serv, size_t servlen, int flags); Index: openbsd-compat/fake-socket.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/fake-socket.h,v retrieving revision 1.2 diff -u -r1.2 fake-socket.h --- openbsd-compat/fake-socket.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/fake-socket.h 2001/02/16 22:54:03 @@ -3,7 +3,6 @@ #ifndef _FAKE_SOCKET_H #define _FAKE_SOCKET_H -#include "config.h" #include "sys/types.h" #ifndef HAVE_STRUCT_SOCKADDR_STORAGE Index: openbsd-compat/getcwd.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/getcwd.h,v retrieving revision 1.2 diff -u -r1.2 getcwd.h --- openbsd-compat/getcwd.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/getcwd.h 2001/02/16 22:54:03 @@ -2,7 +2,6 @@ #ifndef _BSD_GETCWD_H #define _BSD_GETCWD_H -#include "config.h" #if !defined(HAVE_GETCWD) Index: openbsd-compat/getgrouplist.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/getgrouplist.h,v retrieving revision 1.2 diff -u -r1.2 getgrouplist.h --- openbsd-compat/getgrouplist.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/getgrouplist.h 2001/02/16 22:54:03 @@ -3,8 +3,6 @@ #ifndef _BSD_GETGROUPLIST_H #define _BSD_GETGROUPLIST_H -#include "config.h" - #ifndef HAVE_GETGROUPLIST #include Index: openbsd-compat/inet_aton.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/inet_aton.h,v retrieving revision 1.2 diff -u -r1.2 inet_aton.h --- openbsd-compat/inet_aton.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/inet_aton.h 2001/02/16 22:54:03 @@ -3,8 +3,6 @@ #ifndef _BSD_INET_ATON_H #define _BSD_INET_ATON_H -#include "config.h" - #ifndef HAVE_INET_ATON int inet_aton(const char *cp, struct in_addr *addr); #endif /* HAVE_INET_ATON */ Index: openbsd-compat/inet_ntoa.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/inet_ntoa.h,v retrieving revision 1.2 diff -u -r1.2 inet_ntoa.h --- openbsd-compat/inet_ntoa.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/inet_ntoa.h 2001/02/16 22:54:03 @@ -3,8 +3,6 @@ #ifndef _BSD_INET_NTOA_H #define _BSD_INET_NTOA_H -#include "config.h" - #if defined(BROKEN_INET_NTOA) || !defined(HAVE_INET_NTOA) char *inet_ntoa(struct in_addr in); #endif /* defined(BROKEN_INET_NTOA) || !defined(HAVE_INET_NTOA) */ Index: openbsd-compat/mktemp.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/mktemp.h,v retrieving revision 1.2 diff -u -r1.2 mktemp.h --- openbsd-compat/mktemp.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/mktemp.h 2001/02/16 22:54:03 @@ -3,7 +3,6 @@ #ifndef _BSD_MKTEMP_H #define _BSD_MKTEMP_H -#include "config.h" #ifndef HAVE_MKDTEMP int mkstemps(char *path, int slen); int mkstemp(char *path); Index: openbsd-compat/openbsd-compat.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/openbsd-compat.h,v retrieving revision 1.2 diff -u -r1.2 openbsd-compat.h --- openbsd-compat/openbsd-compat.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/openbsd-compat.h 2001/02/16 22:54:03 @@ -3,8 +3,6 @@ #ifndef _OPENBSD_H #define _OPENBSD_H -#include "config.h" - /* OpenBSD function replacements */ #include "bindresvport.h" #include "getcwd.h" Index: openbsd-compat/realpath.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/realpath.h,v retrieving revision 1.2 diff -u -r1.2 realpath.h --- openbsd-compat/realpath.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/realpath.h 2001/02/16 22:54:03 @@ -3,8 +3,6 @@ #ifndef _BSD_REALPATH_H #define _BSD_REALPATH_H -#include "config.h" - #if !defined(HAVE_REALPATH) || defined(BROKEN_REALPATH) char *realpath(const char *path, char *resolved); Index: openbsd-compat/rresvport.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/rresvport.h,v retrieving revision 1.2 diff -u -r1.2 rresvport.h --- openbsd-compat/rresvport.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/rresvport.h 2001/02/16 22:54:03 @@ -3,8 +3,6 @@ #ifndef _BSD_RRESVPORT_H #define _BSD_RRESVPORT_H -#include "config.h" - #ifndef HAVE_RRESVPORT_AF int rresvport_af(int *alport, sa_family_t af); #endif /* !HAVE_RRESVPORT_AF */ Index: openbsd-compat/setenv.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/setenv.h,v retrieving revision 1.2 diff -u -r1.2 setenv.h --- openbsd-compat/setenv.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/setenv.h 2001/02/16 22:54:03 @@ -3,8 +3,6 @@ #ifndef _BSD_SETENV_H #define _BSD_SETENV_H -#include "config.h" - #ifndef HAVE_SETENV int setenv(register const char *name, register const char *value, int rewrite); Index: openbsd-compat/setproctitle.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/setproctitle.h,v retrieving revision 1.2 diff -u -r1.2 setproctitle.h --- openbsd-compat/setproctitle.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/setproctitle.h 2001/02/16 22:54:03 @@ -3,8 +3,6 @@ #ifndef _BSD_SETPROCTITLE_H #define _BSD_SETPROCTITLE_H -#include "config.h" - #ifndef HAVE_SETPROCTITLE void setproctitle(const char *fmt, ...); #endif Index: openbsd-compat/strlcat.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/strlcat.h,v retrieving revision 1.2 diff -u -r1.2 strlcat.h --- openbsd-compat/strlcat.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/strlcat.h 2001/02/16 22:54:03 @@ -3,7 +3,6 @@ #ifndef _BSD_STRLCAT_H #define _BSD_STRLCAT_H -#include "config.h" #ifndef HAVE_STRLCAT #include size_t strlcat(char *dst, const char *src, size_t siz); Index: openbsd-compat/strlcpy.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/strlcpy.h,v retrieving revision 1.2 diff -u -r1.2 strlcpy.h --- openbsd-compat/strlcpy.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/strlcpy.h 2001/02/16 22:54:03 @@ -3,7 +3,6 @@ #ifndef _BSD_STRLCPY_H #define _BSD_STRLCPY_H -#include "config.h" #ifndef HAVE_STRLCPY #include size_t strlcpy(char *dst, const char *src, size_t siz); Index: openbsd-compat/strsep.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/strsep.h,v retrieving revision 1.2 diff -u -r1.2 strsep.h --- openbsd-compat/strsep.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/strsep.h 2001/02/16 22:54:03 @@ -3,8 +3,6 @@ #ifndef _BSD_STRSEP_H #define _BSD_STRSEP_H -#include "config.h" - #ifndef HAVE_STRSEP char *strsep(char **stringp, const char *delim); #endif /* HAVE_STRSEP */ Index: openbsd-compat/strtok.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/strtok.h,v retrieving revision 1.2 diff -u -r1.2 strtok.h --- openbsd-compat/strtok.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/strtok.h 2001/02/16 22:54:03 @@ -3,8 +3,6 @@ #ifndef _BSD_STRTOK_H #define _BSD_STRTOK_H -#include "config.h" - #ifndef HAVE_STRTOK_R char *strtok_r(char *s, const char *delim, char **last); #endif /* HAVE_STRTOK_R */ Index: openbsd-compat/vis.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/vis.h,v retrieving revision 1.2 diff -u -r1.2 vis.h --- openbsd-compat/vis.h 2001/02/09 01:55:37 1.2 +++ openbsd-compat/vis.h 2001/02/16 22:54:03 @@ -3,8 +3,6 @@ #ifndef _BSD_VIS_H #define _BSD_VIS_H -#include "config.h" - #ifndef HAVE_VIS /* -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sat Feb 17 10:15:17 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 17 Feb 2001 10:15:17 +1100 (EST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Fri, 16 Feb 2001 mouring at etoh.eviladmin.org wrote: > > Known issues: > > 1) Linux 'sleep 20' -- Unfixable before 2.5.0 (known work around) Post 2.5.0, I'd really appreciate some more eyes on this - I have been beating my head against it for a while without much luck. > 3) SCO 2/ Native Compiler -- Unfixable before 2.5.0 (known work around) What was this? > 4) NeXTStep -- Resynced, MAX_GROUPS vs NGROUPS unresolved (not major) > 6) Cray signal issues -- ??? This should be fixed by Kevin's mysignal() stuff. > 7) Solaris '$PATH' issue -- ?? (Unfixable before 2.5.0?) [I'm getting > more reports of this. I'll present them when they get their facts > together] Still waiting on a full report. 8) Build failures on AIX. Please test the patch that I sent ~15 mins ago. Look at renaming files post 2.8 -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sat Feb 17 10:19:45 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 17 Feb 2001 10:19:45 +1100 (EST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Damien Miller wrote: > 8) Build failures on AIX. Please test the patch that I sent ~15 mins > ago. Look at renaming files post 2.8 This should be 2.5.0 of course -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From mouring at etoh.eviladmin.org Sat Feb 17 10:24:56 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 16 Feb 2001 17:24:56 -0600 (CST) Subject: SSH2 PATH problem In-Reply-To: Message-ID: On Thu, 15 Feb 2001, Tim Rice wrote: > On Fri, 16 Feb 2001, Damien Miller wrote: > > > On Thu, 15 Feb 2001, Jean-Marc Beroud wrote: > > > > > Hello, > > > > > > I have the following behaviour with openssh-2.3.0p1 > > > > > > # ssh host 'echo $PATH' (SSH1 protocol, works fine) > > > /bin:/sbin:/usr/bin:/usr/sbin:/usr/ucb:/usr/opt/SUNWmd/sbin > > > > > > # ssh -2 host 'echo $PATH' (force SSH2 protocol, PATH env var is not > > > set) > > > > > > > > > I can't execute a remote command with the SSH2 protocol. > > > > I can't replicate this here - can anyone else? > > I can. > openssh-2.3.0p1 on Solaris 8 > Question.. Has either one of you modified your /etc/pam.conf ? I left OpenSSH to be dealt with by the 'other' clause. - Ben From mouring at etoh.eviladmin.org Sat Feb 17 10:26:54 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 16 Feb 2001 17:26:54 -0600 (CST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Damien Miller wrote: > On Fri, 16 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > Known issues: > > > > 1) Linux 'sleep 20' -- Unfixable before 2.5.0 (known work around) > > Post 2.5.0, I'd really appreciate some more eyes on this - I have been > beating my head against it for a while without much luck. > > > 3) SCO 2/ Native Compiler -- Unfixable before 2.5.0 (known work around) > > What was this? > This si the fact that SCO native Compiler is brain damaged and lacks 64bit 'long long' support on 32bit platforms. Therefor sftp/sftp-server will not compile. > > 4) NeXTStep -- Resynced, MAX_GROUPS vs NGROUPS unresolved (not major) > > > 6) Cray signal issues -- ??? > > This should be fixed by Kevin's mysignal() stuff. > I was hoping to get conformation. > > 7) Solaris '$PATH' issue -- ?? (Unfixable before 2.5.0?) [I'm getting > > more reports of this. I'll present them when they get their facts > > together] > > Still waiting on a full report. > > 8) Build failures on AIX. Please test the patch that I sent ~15 mins > ago. Look at renaming files post 2.8 > > -d > > - Ben From vinschen at redhat.com Sat Feb 17 10:52:53 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 17 Feb 2001 00:52:53 +0100 Subject: OpenSSH 2.5.0p1 In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Feb 16, 2001 at 03:12:08PM -0600 References: Message-ID: <20010217005253.M13748@cygbert.vinschen.de> On Fri, Feb 16, 2001 at 03:12:08PM -0600, mouring at etoh.eviladmin.org wrote: > On Fri, 16 Feb 2001 mouring at etoh.eviladmin.org wrote: > > Known issues: > > > > 1) Linux 'sleep 20' -- Unfixable before 2.5.0 (known work around) > > 2) HP/UX signal issue -- Patched and HP/UX 11 works in v2 > > 3) SCO 2/ Native Compiler -- Unfixable before 2.5.0 (known work around) > > 4) NeXTStep -- Resynced, MAX_GROUPS vs NGROUPS unresolved (not major) > > 5) DG/UX regcomp/regexec -- Fixed. > > 6) Cray signal issues -- ??? > > 7) Solaris '$PATH' issue -- ?? (Unfixable before 2.5.0?) [I'm getting > > more reports of this. I'll present them when they get their facts > > together] > > > > I guess what needs to be asked... Is what needs to OCCUR in the next 3 > > to 4 days to assure we have a stable project on majority of the platforms? > > > > - Ben > > > > > > Ermm.. Oops.. forgot two. > > 8) BSDi updates -- ?? post 2.5.0 ?? > 9) AIX, 'login.h' and -I -- ?? Hmm... Just got the latest from CVS. Damien has made a change to the openbsd-compat/bsd-cygwin_util.c file which broke the Cygwin build. You must not include bsd-cygwin_util.h in bsd-cygwin_util.c because of the dangerous redefinitions of open and pipe. Unfortunately bsd-cygwin_util.c now includes includes.h which in turn includes bsd-cygwin_util.h. I have changed bsd-cygwin_util.[ch] so that an additional define is used to control including the affected defines. By the way I have corrected the definition of `binary_open' to conform to the declaration in the header. Patch attached. However, I have only tested to be able to build and a call to scp. More testing will follow tomorrow. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com -------------- next part -------------- Index: bsd-cygwin_util.c =================================================================== RCS file: /cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.c,v retrieving revision 1.2 diff -u -p -r1.2 bsd-cygwin_util.c --- bsd-cygwin_util.c 2001/02/09 01:55:36 1.2 +++ bsd-cygwin_util.c 2001/02/16 23:50:21 @@ -13,8 +13,12 @@ * binary mode on Windows systems. */ +#define INSIDE_BSD_CYGWIN_UTIL + #include "includes.h" +#undef INSIDE_BSD_CYGWIN_UTIL + RCSID("$Id: bsd-cygwin_util.c,v 1.2 2001/02/09 01:55:36 djm Exp $"); #ifdef HAVE_CYGWIN @@ -24,10 +28,17 @@ RCSID("$Id: bsd-cygwin_util.c,v 1.2 2001 #include #include #include +#include #define is_winnt (GetVersion() < 0x80000000) -int binary_open(const char *filename, int flags, mode_t mode) +int binary_open(const char *filename, int flags, ...) { + va_list ap; + mode_t mode; + + va_start(ap, flags); + mode = va_arg(ap, mode_t); + va_end(ap); return open(filename, flags | O_BINARY, mode); } Index: bsd-cygwin_util.h =================================================================== RCS file: /cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.h,v retrieving revision 1.2 diff -u -p -r1.2 bsd-cygwin_util.h --- bsd-cygwin_util.h 2001/02/09 01:55:36 1.2 +++ bsd-cygwin_util.h 2001/02/16 23:50:21 @@ -24,7 +24,9 @@ int binary_pipe(int fd[2]); int check_nt_auth(int pwd_authenticated, uid_t uid); int check_ntsec(const char *filename); +#ifndef INSIDE_BSD_CYGWIN_UTIL #define open binary_open #define pipe binary_pipe +#endif /* INSIDE_BSD_CYGWIN_UTIL */ #endif /* HAVE_CYGWIN */ From wendyp at cray.com Sat Feb 17 10:58:12 2001 From: wendyp at cray.com (Wendy Palm) Date: Fri, 16 Feb 2001 17:58:12 -0600 Subject: OpenSSH 2.5.0p1 References: Message-ID: <3A8DBE94.3E6BDDB@cray.com> mouring at etoh.eviladmin.org wrote: > > On Sat, 17 Feb 2001, Damien Miller wrote: > > > On Fri, 16 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > 6) Cray signal issues -- ??? > > > > This should be fixed by Kevin's mysignal() stuff. > > > I was hoping to get conformation. sorry about that. i'm checking it out now. will send a note asap. -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From djm at mindrot.org Sat Feb 17 11:01:45 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 17 Feb 2001 11:01:45 +1100 (EST) Subject: OpenSSH 2.5.0p1 In-Reply-To: <20010217005253.M13748@cygbert.vinschen.de> Message-ID: On Sat, 17 Feb 2001, Corinna Vinschen wrote: > Just got the latest from CVS. Damien has made a change to the > openbsd-compat/bsd-cygwin_util.c file which broke the Cygwin build. > You must not include bsd-cygwin_util.h in bsd-cygwin_util.c > because of the dangerous redefinitions of open and pipe. Sorry! Does this fix? Index: openbsd-compat/bsd-cygwin_util.c =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/bsd-cygwin_util.c,v retrieving revision 1.2 diff -u -r1.2 bsd-cygwin_util.c --- openbsd-compat/bsd-cygwin_util.c 2001/02/09 01:55:36 1.2 +++ openbsd-compat/bsd-cygwin_util.c 2001/02/17 00:01:10 @@ -26,6 +26,13 @@ #include #define is_winnt (GetVersion() < 0x80000000) +#if defined(open) && open == binary_open +# undef open +#endif +#if defined(pipe) && open == binary_pipe +# undef pipe +#endif + int binary_open(const char *filename, int flags, mode_t mode) { return open(filename, flags | O_BINARY, mode); Index: openbsd-compat/bsd-cygwin_util.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/bsd-cygwin_util.h,v retrieving revision 1.2 diff -u -r1.2 bsd-cygwin_util.h --- openbsd-compat/bsd-cygwin_util.h 2001/02/09 01:55:36 1.2 +++ openbsd-compat/bsd-cygwin_util.h 2001/02/17 00:01:10 @@ -15,7 +15,8 @@ /* $Id: bsd-cygwin_util.h,v 1.2 2001/02/09 01:55:36 djm Exp $ */ -#include "config.h" +#ifndef _BSD_CYGWIN_UTIL_H +#define _BSD_CYGWIN_UTIL_H #ifdef HAVE_CYGWIN @@ -28,3 +29,5 @@ #define pipe binary_pipe #endif /* HAVE_CYGWIN */ + +#endif /* _BSD_CYGWIN_UTIL_H */ -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From mouring at etoh.eviladmin.org Sat Feb 17 11:45:36 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 16 Feb 2001 18:45:36 -0600 (CST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Damien Miller wrote: > On Fri, 16 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > Can we just detect [ $(srcdir) = "." ] and not do the -I? > > > > That was my thought. But I was not sure if it would go into configure.in > > or the Makefile.in file. > > Here is a patch that does this. Unfortunately as Gert pointed out, this > doesn't fix it for the builddir != srcdir case. > May I suggest a smaller patch. Instead of assuming that we can do both AIX and builddir != srcdir. Lets value the platform support over the latter case and enable builddir != srcdir via a ./configure option. I'll give you the fact that "--with-export-src" may not be the best option name, but somewhere in the back of my mind that is what a few other projects have used. Then just document that some platforms (IE 'aix') may not support --with-export-src at this time. - Ben diff -ur openssh/Makefile.in ossh/Makefile.in --- openssh/Makefile.in Wed Feb 14 21:01:59 2001 +++ ossh/Makefile.in Fri Feb 16 18:17:45 2001 @@ -26,7 +26,7 @@ CC=@CC@ LD=@LD@ CFLAGS=@CFLAGS@ -CPPFLAGS=@CPPFLAGS@ -I. -I$(srcdir)/openbsd-compat -I$(srcdir) $(PATHS) @DEFS@ +CPPFLAGS=@CPPFLAGS@ -I$(srcdir)/openbsd-compat $(PATHS) @DEFS@ LIBS=@LIBS@ AR=@AR@ RANLIB=@RANLIB@ diff -ur openssh/configure.in ossh/configure.in --- openssh/configure.in Thu Feb 15 21:39:35 2001 +++ ossh/configure.in Fri Feb 16 18:38:26 2001 @@ -267,6 +267,14 @@ ;; esac +# Allow user to enable compiling outside the source tree +AC_ARG_WITH(export-src, + [ --with-export-src Compile outside the source directory], + [ + CPPFLAGS="$CPPFLAGS -I. -I${srcdir}" + ] +) + # Allow user to specify flags AC_ARG_WITH(cflags, [ --with-cflags Specify additional flags to pass to compiler], diff -ur openssh/openbsd-compat/Makefile.in ossh/openbsd-compat/Makefile.in --- openssh/openbsd-compat/Makefile.in Thu Feb 8 20:57:54 2001 +++ ossh/openbsd-compat/Makefile.in Fri Feb 16 18:19:41 2001 @@ -9,7 +9,7 @@ CC=@CC@ LD=@LD@ CFLAGS=@CFLAGS@ -CPPFLAGS=@CPPFLAGS@ -I. -I.. -I$(srcdir) -I$(srcdir)/.. @DEFS@ +CPPFLAGS=@CPPFLAGS@ -I$(srcdir) -I$(srcdir)/.. @DEFS@ LIBS=@LIBS@ AR=@AR@ RANLIB=@RANLIB@ From tim at multitalents.net Sat Feb 17 13:01:53 2001 From: tim at multitalents.net (Tim Rice) Date: Fri, 16 Feb 2001 18:01:53 -0800 (PST) Subject: SSH2 PATH problem In-Reply-To: Message-ID: On Fri, 16 Feb 2001 mouring at etoh.eviladmin.org wrote: > On Thu, 15 Feb 2001, Tim Rice wrote: > > > On Fri, 16 Feb 2001, Damien Miller wrote: > > > > > On Thu, 15 Feb 2001, Jean-Marc Beroud wrote: > > > > > > > Hello, > > > > > > > > I have the following behaviour with openssh-2.3.0p1 > > > > > > > > # ssh host 'echo $PATH' (SSH1 protocol, works fine) > > > > /bin:/sbin:/usr/bin:/usr/sbin:/usr/ucb:/usr/opt/SUNWmd/sbin > > > > > > > > # ssh -2 host 'echo $PATH' (force SSH2 protocol, PATH env var is not > > > > set) > > > > > > > > > > > > I can't execute a remote command with the SSH2 protocol. > > > > > > I can't replicate this here - can anyone else? > > > > I can. > > openssh-2.3.0p1 on Solaris 8 > > > > Question.. Has either one of you modified your /etc/pam.conf ? Not here. > > I left OpenSSH to be dealt with by the 'other' clause. > > - Ben > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Sat Feb 17 13:12:45 2001 From: tim at multitalents.net (Tim Rice) Date: Fri, 16 Feb 2001 18:12:45 -0800 (PST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: I don't like the idea of having to do something extra just to build outside to the source tree. Building outside of the source tree is the default here. One server holds all the source and the 8 other platforms build from that source. Or am I not reading the patch right? On Fri, 16 Feb 2001 mouring at etoh.eviladmin.org wrote: > > On Sat, 17 Feb 2001, Damien Miller wrote: > > On Fri, 16 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > Can we just detect [ $(srcdir) = "." ] and not do the -I? > > > > > > That was my thought. But I was not sure if it would go into configure.in > > > or the Makefile.in file. > > > > Here is a patch that does this. Unfortunately as Gert pointed out, this > > doesn't fix it for the builddir != srcdir case. > > > > May I suggest a smaller patch. Instead of assuming that we can do both > AIX and builddir != srcdir. Lets value the platform support over the > latter case and enable builddir != srcdir via a ./configure option. > > I'll give you the fact that "--with-export-src" may not be the best > option name, but somewhere in the back of my mind that is what a few > other projects have used. > > Then just document that some platforms (IE 'aix') may not support > --with-export-src at this time. > > - Ben > > diff -ur openssh/Makefile.in ossh/Makefile.in > --- openssh/Makefile.in Wed Feb 14 21:01:59 2001 > +++ ossh/Makefile.in Fri Feb 16 18:17:45 2001 > @@ -26,7 +26,7 @@ > CC=@CC@ > LD=@LD@ > CFLAGS=@CFLAGS@ > -CPPFLAGS=@CPPFLAGS@ -I. -I$(srcdir)/openbsd-compat -I$(srcdir) $(PATHS) @DEFS@ > +CPPFLAGS=@CPPFLAGS@ -I$(srcdir)/openbsd-compat $(PATHS) @DEFS@ > LIBS=@LIBS@ > AR=@AR@ > RANLIB=@RANLIB@ > diff -ur openssh/configure.in ossh/configure.in > --- openssh/configure.in Thu Feb 15 21:39:35 2001 > +++ ossh/configure.in Fri Feb 16 18:38:26 2001 > @@ -267,6 +267,14 @@ > ;; > esac > > +# Allow user to enable compiling outside the source tree > +AC_ARG_WITH(export-src, > + [ --with-export-src Compile outside the source directory], > + [ > + CPPFLAGS="$CPPFLAGS -I. -I${srcdir}" > + ] > +) > + > # Allow user to specify flags > AC_ARG_WITH(cflags, > [ --with-cflags Specify additional flags to pass to compiler], > diff -ur openssh/openbsd-compat/Makefile.in ossh/openbsd-compat/Makefile.in > --- openssh/openbsd-compat/Makefile.in Thu Feb 8 20:57:54 2001 > +++ ossh/openbsd-compat/Makefile.in Fri Feb 16 18:19:41 2001 > @@ -9,7 +9,7 @@ > CC=@CC@ > LD=@LD@ > CFLAGS=@CFLAGS@ > -CPPFLAGS=@CPPFLAGS@ -I. -I.. -I$(srcdir) -I$(srcdir)/.. @DEFS@ > +CPPFLAGS=@CPPFLAGS@ -I$(srcdir) -I$(srcdir)/.. @DEFS@ > LIBS=@LIBS@ > AR=@AR@ > RANLIB=@RANLIB@ > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From gem at rellim.com Sat Feb 17 14:39:30 2001 From: gem at rellim.com (Gary E. Miller) Date: Fri, 16 Feb 2001 19:39:30 -0800 (PST) Subject: SCO Unixware 7.1.0 Message-ID: Yo All! I just built openssh-SNAP-20010217 on Unixware 7.1.0. Dunno when it got fixed, but SSH2, sftp and sftp-server all work great! Thanks a lot guys! 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 From tim at multitalents.net Sat Feb 17 14:47:58 2001 From: tim at multitalents.net (Tim Rice) Date: Fri, 16 Feb 2001 19:47:58 -0800 (PST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Fri, 16 Feb 2001 mouring at etoh.eviladmin.org wrote: > > I guess what needs to be asked... Is what needs to OCCUR in the next 3 > to 4 days to assure we have a stable project on majority of the platforms? Attached is a patch that fixes SCO Open Server 3 It configures/builds fine without & with tcp-wrapers on Solaris 8 UnixWare 2.03 UnixWare 2.1.3 UnixWare 7.1.0 SCO 5.0.4 Caldera sDesktop 2.4 > > - Ben > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- openssh_cvs/configure.in.old Fri Feb 16 18:15:18 2001 +++ openssh_cvs/configure.in Fri Feb 16 18:39:16 2001 @@ -592,10 +592,10 @@ for ssldir in $tryssldir "" /usr/local/openssl /usr/lib/openssl /usr/local/ssl /usr/lib/ssl /usr/local /usr/pkg /opt /opt/openssl ; do if test ! -z "$ssldir" -a "x$ssldir" != "x/usr"; then - LDFLAGS="$saved_LDFLAGS -L$ssldir/lib -L$ssldir" + LDFLAGS="$saved_LDFLAGS -L$ssldir/lib" CPPFLAGS="$saved_CPPFLAGS -I$ssldir/include" if test ! -z "$need_dash_r" ; then - LDFLAGS="$LDFLAGS -R$ssldir/lib -R$ssldir" + LDFLAGS="$LDFLAGS -R$ssldir/lib" fi else LDFLAGS="$saved_LDFLAGS" @@ -645,12 +645,12 @@ if test ! -z "$ssldir" -a "x$ssldir" != "x/usr"; then CPPFLAGS="$saved_CPPFLAGS -I$ssldir/include" - LDFLAGS="$saved_LDFLAGS -L$ssldir/lib -L$ssldir" + LDFLAGS="$saved_LDFLAGS -L$ssldir/lib" if test ! -z "$need_dash_r" ; then - LDFLAGS="$LDFLAGS -R$ssldir/lib -R$ssldir" + LDFLAGS="$LDFLAGS -R$ssldir/lib" fi if test ! -z "$blibpath" ; then - blibpath="$blibpath:$ssldir:$ssldir/lib" + blibpath="$blibpath:$ssldir/lib" fi fi fi --- openssh_cvs/misc.c.old Fri Feb 16 18:15:19 2001 +++ openssh_cvs/misc.c Fri Feb 16 19:07:03 2001 @@ -108,8 +108,10 @@ memset(&sa, 0, sizeof sa); sigemptyset(&sa.sa_mask); sa.sa_flags = 0; +#ifdef SA_RESTART if (sig == SIGCHLD) sa.sa_flags |= SA_RESTART; +#endif sa.sa_handler = act; if (sigaction(sig, &sa, 0) == -1) return (mysig_t) -1; --- openssh_cvs/sftp-client.c.old Fri Feb 16 18:15:39 2001 +++ openssh_cvs/sftp-client.c Fri Feb 16 19:37:00 2001 @@ -662,7 +662,11 @@ status = do_close(fd_in, fd_out, handle, handle_len); /* Override umask and utimes if asked */ +#ifdef HAVE_FCHMOD if (pflag && fchmod(local_fd, mode) == -1) +#else /* HAVE_FCHMOD */ + if (pflag && chmod(local_path, mode) == -1) +#endif /* HAVE_FCHMOD */ error("Couldn't set mode on \"%s\": %s", local_path, strerror(errno)); if (pflag && (a->flags & SSH2_FILEXFER_ATTR_ACMODTIME)) { From djm at mindrot.org Sat Feb 17 14:52:52 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 17 Feb 2001 14:52:52 +1100 (EST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Fri, 16 Feb 2001 mouring at etoh.eviladmin.org wrote: > > On Sat, 17 Feb 2001, Damien Miller wrote: > > On Fri, 16 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > Can we just detect [ $(srcdir) = "." ] and not do the -I? > > > > > > That was my thought. But I was not sure if it would go into configure.in > > > or the Makefile.in file. > > > > Here is a patch that does this. Unfortunately as Gert pointed out, this > > doesn't fix it for the builddir != srcdir case. > > > > May I suggest a smaller patch. Instead of assuming that we can do both > AIX and builddir != srcdir. Lets value the platform support over the > latter case and enable builddir != srcdir via a ./configure option. You need to pass a configure option to do builddir != srcdir anyway (--src-dir). Have you tested your patch with builddir != srcdir, I had to modify all the openbsd-compat stuff to get this working. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From mouring at etoh.eviladmin.org Sat Feb 17 15:46:10 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 16 Feb 2001 22:46:10 -0600 (CST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Damien Miller wrote: > On Fri, 16 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > On Sat, 17 Feb 2001, Damien Miller wrote: > > > On Fri, 16 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > Can we just detect [ $(srcdir) = "." ] and not do the -I? > > > > > > > > That was my thought. But I was not sure if it would go into configure.in > > > > or the Makefile.in file. > > > > > > Here is a patch that does this. Unfortunately as Gert pointed out, this > > > doesn't fix it for the builddir != srcdir case. > > > > > > > May I suggest a smaller patch. Instead of assuming that we can do both > > AIX and builddir != srcdir. Lets value the platform support over the > > latter case and enable builddir != srcdir via a ./configure option. > > You need to pass a configure option to do builddir != srcdir anyway > (--src-dir). Have you tested your patch with builddir != srcdir, I had > to modify all the openbsd-compat stuff to get this working. > > -d > Yes I did test it. It worked fine under Linux. However I did not get any chance to test it under anything else. Before running ou the door. I never needed --src-dir to compile in a different location. But if that is needed then we should set the right -I via that if we can. Because we have other issues that are more hidden (pty.h and openpty() call). Tim, The choice is either we ignore AIX or we stop the default behavior of building out of the tree. Where the latter is anonying the form is unacceptable. - Ben From dbt at meat.net Sat Feb 17 16:21:26 2001 From: dbt at meat.net (David Terrell) Date: Fri, 16 Feb 2001 21:21:26 -0800 Subject: OpenSSH 2.5.0p1 In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Feb 16, 2001 at 10:46:10PM -0600 References: Message-ID: <20010216212126.A2563@pianosa.catch22.org> On Fri, Feb 16, 2001 at 10:46:10PM -0600, mouring at etoh.eviladmin.org wrote: > The choice is either we ignore AIX or we stop the default behavior of > building out of the tree. Where the latter is anonying the form is > unacceptable. Am I missing something, or wouldn't simply renaming login.h work? That seems like a fairly common word to use as a private header file anyway... -- David Terrell | "Any sufficiently advanced technology Prime Minister, Nebcorp | is indistinguishable from a rigged demo." dbt at meat.net | - Brian Swetland http://wwn.nebcorp.com/ From roth+openssh at feep.net Sat Feb 17 16:23:28 2001 From: roth+openssh at feep.net (Mark D. Roth) Date: Fri, 16 Feb 2001 23:23:28 -0600 Subject: Patch for unformatted manpages In-Reply-To: ; from djm@mindrot.org on Wed, Feb 07, 2001 at 05:32:39PM +1100 References: <20010207000040.A15349@yorktown.isdn.uiuc.edu> Message-ID: <20010216232328.A3773@yorktown.isdn.uiuc.edu> On Wed Feb 07 17:32 2001 +1100, Damien Miller wrote: > On Wed, 7 Feb 2001, Mark D. Roth wrote: > > I'd like to see this patch integrated into the portable version of > > OpenSSH. Please let me know what you think about this. Thanks! > > I am all for it. Just a bit of feedback to bring us closer to this > point: > > Is there a license on the perl script? It needs one. > > I would prefer not to remove the preformatted pages altogether, but > instead alter --with-catman to take either 'mandoc', 'man' or 'cat' > arguments. Some similar configure.in magic would be required. I > can do this if required. It looks like this isn't in the current CVS snapshot. Anyone know what's up with this? -- Mark D. Roth http://www.feep.net/~roth/ From roth+openssh at feep.net Sat Feb 17 16:28:48 2001 From: roth+openssh at feep.net (Mark D. Roth) Date: Fri, 16 Feb 2001 23:28:48 -0600 Subject: OpenSSH 2.5.0p1 In-Reply-To: <20010216212126.A2563@pianosa.catch22.org>; from dbt@meat.net on Fri, Feb 16, 2001 at 09:21:26PM -0800 References: <20010216212126.A2563@pianosa.catch22.org> Message-ID: <20010216232848.B3773@yorktown.isdn.uiuc.edu> On Fri Feb 16 21:21 2001 -0800, Dave Terrell wrote: > On Fri, Feb 16, 2001 at 10:46:10PM -0600, mouring at etoh.eviladmin.org wrote: > > The choice is either we ignore AIX or we stop the default behavior of > > building out of the tree. Where the latter is anonying the form is > > unacceptable. > > Am I missing something, or wouldn't simply renaming login.h work? That > seems like a fairly common word to use as a private header file anyway... FWIW, I would strongly prefer this solution. Speaking as someone who always builds outside of the source tree and needs to support AIX, any other solution would be really inconvenient. -- Mark D. Roth http://www.feep.net/~roth/ From vinschen at redhat.com Sat Feb 17 19:01:22 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 17 Feb 2001 09:01:22 +0100 Subject: OpenSSH 2.5.0p1 In-Reply-To: ; from djm@mindrot.org on Sat, Feb 17, 2001 at 11:01:45AM +1100 References: <20010217005253.M13748@cygbert.vinschen.de> Message-ID: <20010217090122.A16740@cygbert.vinschen.de> On Sat, Feb 17, 2001 at 11:01:45AM +1100, Damien Miller wrote: > On Sat, 17 Feb 2001, Corinna Vinschen wrote: > > > Just got the latest from CVS. Damien has made a change to the > > openbsd-compat/bsd-cygwin_util.c file which broke the Cygwin build. > > You must not include bsd-cygwin_util.h in bsd-cygwin_util.c > > because of the dangerous redefinitions of open and pipe. > > Sorry! > > Does this fix? > [...] It helps solving the define problem but it doesn't solve the non matching definition and declaration of binary_open. I have attached a new diff which includes your patch and the patch changing the definition of binary_open. Thanks, Corinna Index: bsd-cygwin_util.c =================================================================== RCS file: /cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.c,v retrieving revision 1.2 diff -u -p -r1.2 bsd-cygwin_util.c --- bsd-cygwin_util.c 2001/02/09 01:55:36 1.2 +++ bsd-cygwin_util.c 2001/02/17 07:56:14 @@ -26,8 +26,21 @@ RCSID("$Id: bsd-cygwin_util.c,v 1.2 2001 #include #define is_winnt (GetVersion() < 0x80000000) -int binary_open(const char *filename, int flags, mode_t mode) +#if defined(open) && open == binary_open +# undef open +#endif +#if defined(pipe) && open == binary_pipe +# undef pipe +#endif + +int binary_open(const char *filename, int flags, ...) { + va_list ap; + mode_t mode; + + va_start(ap, flags); + mode = va_arg(ap, mode_t); + va_end(ap); return open(filename, flags | O_BINARY, mode); } Index: bsd-cygwin_util.h =================================================================== RCS file: /cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.h,v retrieving revision 1.2 diff -u -p -r1.2 bsd-cygwin_util.h --- bsd-cygwin_util.h 2001/02/09 01:55:36 1.2 +++ bsd-cygwin_util.h 2001/02/17 07:56:14 @@ -15,7 +15,8 @@ /* $Id: bsd-cygwin_util.h,v 1.2 2001/02/09 01:55:36 djm Exp $ */ -#include "config.h" +#ifndef _BSD_CYGWIN_UTIL_H +#define _BSD_CYGWIN_UTIL_H #ifdef HAVE_CYGWIN @@ -28,3 +29,5 @@ int check_ntsec(const char *filename); #define pipe binary_pipe #endif /* HAVE_CYGWIN */ + +#endif /* _BSD_CYGWIN_UTIL_H */ From aspa at kronodoc.fi Sat Feb 17 21:25:48 2001 From: aspa at kronodoc.fi (Marko Asplund) Date: Sat, 17 Feb 2001 12:25:48 +0200 (EET) Subject: terminate on re-key request (patch) In-Reply-To: <20010212103700.G10859@greenie.muc.de> Message-ID: hi here's a small patch for making OpenSSH v2.3.0p1 client gracefully terminate the SSH2 connection when it receives a key re-exchange request from the server. the patch has been tested against SSH's v2.3.0 server on linux. -- aspa -------------- next part -------------- *** clientloop.c.orig Sat Feb 17 12:09:21 2001 --- clientloop.c Sat Feb 17 11:58:45 2001 *************** *** 1016,1021 **** --- 1016,1029 ---- quit_pending = 1; } + void + client_rekey_request(int type, int plen, void *ctxt) + { + quit_pending = 1; + debug("re-key request received from server. terminating."); + return; + } + /* XXXX move to generic input handler */ void client_input_channel_open(int type, int plen, void *ctxt) *************** *** 1097,1102 **** --- 1105,1112 ---- dispatch_set(SSH2_MSG_CHANNEL_OPEN_FAILURE, &channel_input_open_failure); dispatch_set(SSH2_MSG_CHANNEL_REQUEST, &channel_input_channel_request); dispatch_set(SSH2_MSG_CHANNEL_WINDOW_ADJUST, &channel_input_window_adjust); + dispatch_set(SSH2_MSG_KEXINIT, &client_rekey_request); + } void client_init_dispatch_13() From Antigen at mindrot.org Sat Feb 17 21:27:15 2001 From: Antigen at mindrot.org (Antigen at mindrot.org) Date: 17 Feb 2001 02:27:15 -0800 Subject: Antigen found Unknown (?) virus Message-ID: Antigen for Exchange found term_on_rekey_rq.patch infected with Unknown (?) virus. The file is currently Detected. The message, "terminate on re-key request (patch)", was sent from Marko Asplund and was discovered in SMTP Messages\Inbound located at Unknown/Unknown/MSMAIL. From pekkas at netcore.fi Sat Feb 17 21:46:02 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 17 Feb 2001 12:46:02 +0200 (EET) Subject: terminate on re-key request (patch) In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Marko Asplund wrote: > here's a small patch for making OpenSSH v2.3.0p1 client gracefully > terminate the SSH2 connection when it receives a key re-exchange request > from the server. the patch has been tested against SSH's v2.3.0 server on > linux. Better (AFAIS) patch is already in there: --- 20010128 - (bal) OpenBSD Sync - markus at cvs.openbsd.org 2001/01/28 10:15:34 [dispatch.c] re-keying is not supported; ok deraadt@ --- -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From stevesk at sweden.hp.com Sat Feb 17 22:14:00 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Sat, 17 Feb 2001 12:14:00 +0100 (MET) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Fri, 16 Feb 2001, Tim Rice wrote: : Attached is a patch that fixes SCO Open Server 3 this means that SCO has sigaction() but no SA_RESTART flag? --- openssh_cvs/misc.c.old Fri Feb 16 18:15:19 2001 +++ openssh_cvs/misc.c Fri Feb 16 19:07:03 2001 @@ -108,8 +108,10 @@ memset(&sa, 0, sizeof sa); sigemptyset(&sa.sa_mask); sa.sa_flags = 0; +#ifdef SA_RESTART if (sig == SIGCHLD) sa.sa_flags |= SA_RESTART; +#endif sa.sa_handler = act; if (sigaction(sig, &sa, 0) == -1) return (mysig_t) -1; From aspa at kronodoc.fi Sat Feb 17 22:34:59 2001 From: aspa at kronodoc.fi (Marko Asplund) Date: Sat, 17 Feb 2001 13:34:59 +0200 (EET) Subject: terminate on re-key request (patch) In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Pekka Savola wrote: > On Sat, 17 Feb 2001, Marko Asplund wrote: > > here's a small patch for making OpenSSH v2.3.0p1 client gracefully > > terminate the SSH2 connection when it receives a key re-exchange request > > from the server. the patch has been tested against SSH's v2.3.0 server on > > linux. > > Better (AFAIS) patch is already in there: > ... it doesn't seem to be working for me. OpenSSH client just says 'Hm, dispatch protocol error: type 20 plen 136' and the connection hangs when SSH's server sends a re-key request. this is the same behaviour as without the patch. the patch seems to be expecting SSH2_MSG_KEXDH_INIT packet and the SSH Transport Layer Protocol IETF draft spec speaks about using SSH_MSG_KEXINIT. should the packet type in the patch be SSH2_MSG_KEXINIT instead? is anyone working on re-key support, by the way? -- aspa From misiek at pld.ORG.PL Sun Feb 18 00:54:28 2001 From: misiek at pld.ORG.PL (Arkadiusz Miskiewicz) Date: Sat, 17 Feb 2001 14:54:28 +0100 Subject: Important fix (sshd && binding). Portable version only. Message-ID: <20010217145428.A17425@ikar.t17.ds.pwr.wroc.pl> If bind() fails we _always_ should close socket. I sent this patch while ago to djm but I still don't see this fix in openssh_cvs. diff -urN openssh-2.3.0p1.org/sshd.c openssh-2.3.0p1/sshd.c --- openssh-2.3.0p1.org/sshd.c Sat Jan 6 19:54:11 2001 +++ openssh-2.3.0p1/sshd.c Sat Jan 6 19:55:48 2001 @@ -782,10 +782,10 @@ debug("Bind to port %s on %s.", strport, ntop); /* Bind the socket to the desired port. */ - if ((bind(listen_sock, ai->ai_addr, ai->ai_addrlen) < 0) && - (!ai->ai_next)) { - error("Bind to port %s on %s failed: %.200s.", - strport, ntop, strerror(errno)); + if (bind(listen_sock, ai->ai_addr, ai->ai_addrlen) < 0) { + if (!ai->ai_next) + error("Bind to port %s on %s failed: %.200s.", + strport, ntop, strerror(errno)); close(listen_sock); continue; } -- Arkadiusz Mi?kiewicz, AM2-6BONE [ PLD GNU/Linux IPv6 ] http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/ [ enabled ] From pekkas at netcore.fi Sun Feb 18 01:46:49 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 17 Feb 2001 16:46:49 +0200 (EET) Subject: exit code weirdness in fatal() Message-ID: Hello all, I came across the following with the latest snapshot (and previous): (just trying to start sshd when it's already running) # ./sshd -d [snip] socket: Invalid argument debug1: Bind to port 22 on 0.0.0.0. fatal: Cannot bind any address. # echo $? 255 # ./sshd # echo $? 0 with './sshd', the same fatal message is printed to syslog. This seems critically wrong on systems that check what sshd's exit status was to see if it should have started running without problems. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From Jacek.Pliszka at fuw.edu.pl Sun Feb 18 02:01:41 2001 From: Jacek.Pliszka at fuw.edu.pl (Jacek Pliszka) Date: Sat, 17 Feb 2001 16:01:41 +0100 (CET) Subject: Name change Message-ID: Hi! I am sorry if I am senidng it an incorrect place. I heard about problems with ssh trademark. If it is not solve I propose name change to osh (Open Shell) or orsh (Open Remote Shell). There is no ssh included in name, yet names are short and similar to one used at the moment. Thank you for a great program!! Jacek From pekkas at netcore.fi Sun Feb 18 02:14:34 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 17 Feb 2001 17:14:34 +0200 (EET) Subject: PATCH: make contrib/redhat/sshd.init work with older RH releases In-Reply-To: <20010216144807.A25687@quipu.half.pint-stowp.cx> Message-ID: On Fri, 16 Feb 2001, Jim Knoble wrote: > Attached is a patch to contrib/redhat/sshd.init which eliminates the > dependency on the success() and failure() functions from > initscripts>=4.16. This allows sshd.init to be used for both early and > recent releases of Red Hat Linux (i've confirmed it works on both 4.2 > and 5.2 as well as 6.2). > > The patch also removes the 'Requires: initscripts >= 4.16' line from > contrib/redhat/openssh.spec. > > After inspecting and applying, you ought to be able to remove > contrib/redhat/sshd.init-5.x. IMO, this is a wrong way to do this. Rather, if we want to do this, I propose something like (sshd-funcs may not be the best name to describe this..): --- sshd~ Sat Feb 17 16:16:33 2001 +++ sshd Sat Feb 17 17:07:00 2001 @@ -15,6 +15,9 @@ # source function library . /etc/rc.d/init.d/functions +# source local sshd functions +. /etc/rc.d/init.d/sshd-funcs + RETVAL=0 prog="sshd" --- [no further changes in the main file!] Where sshd-funcs would redefine success, failure, action, and whatever other things that might come up, with something of it's own, like: --- if [ ! "`type -type success`" = "function" ]; then my_success "$*" fi if [ ! "`type -type failure`" = "function" ]; then my_failure "$*" fi my_success() { local msg if [ $# -gt 1 ]; then msg="$2" else msg="done" fi case "`type -type success`" in function) success "$1" ;; *) echo -n "${msg}" ;; esac } my_failure() { local msg if [ $# -gt 1 ]; then msg="$2" else msg="FAILED" fi case "`type -type failure`" in function) failure "$1" ;; *) echo -n "${msg}" ;; esac } --- -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From stevesk at sweden.hp.com Sun Feb 18 02:21:07 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Sat, 17 Feb 2001 16:21:07 +0100 (MET) Subject: exit code weirdness in fatal() In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Pekka Savola wrote: : # ./sshd -d : [snip] : socket: Invalid argument : debug1: Bind to port 22 on 0.0.0.0. : fatal: Cannot bind any address. : # echo $? : 255 : : # ./sshd : # echo $? : 0 : : with './sshd', the same fatal message is printed to syslog. this one has forked and detached from the terminal at the point of that error. its parent does exit(0) in daemon() which is what the shell sees. From ishikawa at yk.rim.or.jp Sun Feb 18 02:43:28 2001 From: ishikawa at yk.rim.or.jp (Ishikawa) Date: Sun, 18 Feb 2001 00:43:28 +0900 Subject: OpenSSH 2.5.0p1 References: Message-ID: <3A8E9C20.7330E90B@yk.rim.or.jp> mouring at etoh.eviladmin.org wrote: > Known issues: > > > 7) Solaris '$PATH' issue -- ?? (Unfixable before 2.5.0?) [I'm getting > more reports of this. I'll present them when they get their facts > together] Attached is a memo that contains the debug output when the problem is reproduced locally on our office machines. I think the afffected systems are at least solaris 7 and solaris 8 from what I gather from the post. The log below is generated when I tried the command against sshd 2.3.0p1 on a solaris 7 for x86 host. (without "-2", the command works.) "ssh -2 host 'echo $PATH' doesn't work against sshd on solaris7 for x86" *** *** server is solaris 7 for x86. We used sun cc compiler. *** for the server compilation. *** *** I think the key factors are solaris 7 and 8 from what *** I gathered by reading the posts. (The following log is a little complicated since the ssh connection is passed by a tcp-level gateway to a final sshd server on a remote host. But I have observed the same problem WITHOUT such proxy before.) First example. *** *** ssh -2 -v -v -v targethost 'echo $PATH' doesn't work. *** *** server is solaris 7 for x86. We used sun cc compiler. *** for the server compilation. *** *** ssh is invoked from a solaris 2.5.1 host. ishikawa at u45$ conn-www.sh -2 -v -v -v 'echo $PATH' # # host sun11 # -p 999 gateway to www-reserved. # echo "Timeout is 2 mins." ++ echo 'Timeout is 2 mins.' Timeout is 2 mins. ssh sun11.example.co.jp -p 999 -C -l gnu $* ++ ssh sun11.example.co.jp -p 999 -C -l gnu -2 -v -v -v echo '$PATH' SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090600f). debug: Reading configuration data /usr/local/etc/ssh_config debug: ssh_connect: getuid 12 geteuid 0 anon 0 debug: Connecting to sun11.example.co.jp [192.168.1.11] port 999. debug: Reading output from 'ls -alni /var/log' debug: Time elapsed: 27 msec debug: Got 1.61 bytes of entropy from 'ls -alni /var/log' debug: Reading output from 'ls -alni /var/adm' debug: Time elapsed: 29 msec ... ... lines from entropy gathering daemon. ... debug: Reading output from 'tail -200 /var/log/syslog' debug: Time elapsed: 7 msec debug: Got 0.00 bytes of entropy from 'tail -200 /var/log/syslog' debug: Reading output from 'tail -200 /var/adm/messages' debug: Time elapsed: 39 msec debug: Got 0.46 bytes of entropy from 'tail -200 /var/adm/messages' debug: Seeded RNG with 40 bytes from programs debug: Seeded RNG with 3 bytes from system calls debug: Allocated local port 663. 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 3des-cbc hmac-sha1 zlib debug: kex: client->server 3des-cbc hmac-sha1 zlib 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: 515/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 'sun11.example.co.jp' 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: Enabling compression at level 6. 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: start over, passed a different list debug: authmethod_lookup publickey debug: authmethod_is_enabled publickey debug: next auth method to try is publickey debug: key does not exist: /usr2/ishikawa/.ssh/id_dsa debug: we did not send a packet, disable method debug: authmethod_lookup publickey debug: authmethod_lookup password debug: authmethod_is_enabled password debug: next auth method to try is password gnu at sun11.example.co.jp's password: debug: we sent a password packet, wait for reply debug: ssh-userauth2 successfull: method password debug: channel 0: new [client-session] debug: send channel open 0 debug: Entering interactive session. <=== But no echo $PATH debug: callback start output follows... debug: client_init id 0 arg 0 debug: Sending command: echo $PATH 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.3 seconds debug: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug: Exit status 0 debug: compress outgoing: raw data 157, compressed 122, factor 0.78 debug: compress incoming: raw data 103, compressed 95, factor 0.92 debug: writing PRNG seed to file /usr2/ishikawa/.ssh/prng_seed I repeated the above one more time before attempting the fallback (no -2) connection. ************************* *** No -2 *** *** ssh -v -v -v targethost 'echo $PATH' DOES WORK. *** *** server is solaris 7 for x86. We used sun cc compiler. *** for the server compilation. *** *** ************************* ishikawa at u45$ conn-www.sh -v -v -v 'echo $PATH' # # host sun11 # -p 999 gateway to www-reserved. # echo "Timeout is 2 mins." ++ echo 'Timeout is 2 mins.' Timeout is 2 mins. ssh sun11.example.co.jp -p 999 -C -l gnu $* ++ ssh sun11.example.co.jp -p 999 -C -l gnu -v -v -v echo '$PATH' SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090600f). debug: Reading configuration data /usr/local/etc/ssh_config debug: Reading output from 'ls -alni /var/log' debug: Time elapsed: 59 msec debug: Got 1.61 bytes of entropy from 'ls -alni /var/log' ... ... ... debug: Got 0.00 bytes of entropy from 'tail -200 /var/log/syslog' debug: Reading output from 'tail -200 /var/adm/messages' debug: Time elapsed: 28 msec debug: Got 0.46 bytes of entropy from 'tail -200 /var/adm/messages' debug: Seeded RNG with 35 bytes from programs debug: Seeded RNG with 3 bytes from system calls debug: Allocated local port 670. debug: Connection established. debug: Remote protocol version 1.99, remote software version OpenSSH_2.3.0p1 debug: no match: OpenSSH_2.3.0p1 debug: Local version string SSH-1.5-OpenSSH_2.3.0p1 debug: Waiting for server public key. debug: Received server public key (768 bits) and host key (1024 bits). debug: Host 'sun11.example.co.jp' is known and matches the RSA host key. Warning: the RSA host key for 'sun11.example.co.jp' differs ***from the key for the IP address '192.168.1.11' debug: Reading output from 'ls -alni /var/log' debug: Time elapsed: 27 msec debug: Got 1.61 bytes of entropy from 'ls -alni /var/log' ... ... ... debug: Got 0.00 bytes of entropy from 'tail -200 /var/log/syslog' debug: Reading output from 'tail -200 /var/adm/messages' debug: Time elapsed: 28 msec debug: Got 0.46 bytes of entropy from 'tail -200 /var/adm/messages' debug: Seeded RNG with 35 bytes from programs debug: Seeded RNG with 3 bytes from system calls debug: Encryption type: 3des debug: Sent encrypted session key. debug: Installing crc compensation attack detector. debug: Received encrypted confirmation. debug: Doing password authentication. gnu at sun11.example.co.jp's password: debug: Requesting compression at level 6. debug: Enabling compression at level 6. debug: Sending command: echo $PATH debug: Entering interactive session. /usr/sbin:/usr/bin:/usr/local/bin <=== echo $PATH output! debug: Transferred: stdin 0, stdout 34, stderr 0 bytes in 0.2 seconds debug: Bytes per second: stdin 0.0, stdout 174.0, stderr 0.0 debug: Exit status 0 debug: compress outgoing: raw data 16, compressed 23, factor 1.44 debug: compress incoming: raw data 44, compressed 37, factor 0.84 debug: writing PRNG seed to file /usr2/ishikawa/.ssh/prng_seed On the server side. The log recoreded showed two "-2" connection attempts and then "NO -2" connection. Feb 17 19:37:07 www-reserved sshd[27487]: info(NOTICE): Accepted password for gnu from 192.168.2.10 port 58108 ssh2 Feb 17 19:37:07 www-reserved sshd[27487]: info(NOTICE): Accepted password for gnu from 192.168.2.10 port 58108 ssh2 Feb 17 19:37:08 www-reserved sshd[27487]: verbose(INFO): Connection closed by remote host. Feb 17 19:38:18 www-reserved sshd[27497]: verbose(INFO): Connection from 192.168.2.10 port 58111 Feb 17 19:38:18 www-reserved sshd[27497]: verbose(INFO): Enabling compatibility mode for protocol 2.0 Feb 17 19:38:18 www-reserved sshd[27497]: info(NOTICE): WARNING: /usr/local/etc/primes does not exist, using old prime Feb 17 19:38:18 www-reserved sshd[27497]: info(NOTICE): WARNING: /usr/local/etc/primes does not exist, using old prime Feb 17 19:38:21 www-reserved sshd[27497]: verbose(INFO): Failed none for gnu from 192.168.2.10 port 58111 ssh2 Feb 17 19:38:31 www-reserved sshd[27497]: info(NOTICE): Accepted password for gnu from 192.168.2.10 port 58111 ssh2 Feb 17 19:38:31 www-reserved sshd[27497]: info(NOTICE): Accepted password for gnu from 192.168.2.10 port 58111 ssh2 Feb 17 19:38:31 www-reserved sshd[27497]: verbose(INFO): Connection closed by remote host. Feb 17 19:38:54 www-reserved sshd[27499]: verbose(INFO): Connection from 192.168.2.10 port 58112 Feb 17 19:38:54 www-reserved sshd[27499]: verbose(INFO): Enabling compatibility mode for protocol 2.0 Feb 17 19:38:54 www-reserved sshd[27499]: info(NOTICE): WARNING: /usr/local/etc/primes does not exist, using old prime Feb 17 19:38:54 www-reserved sshd[27499]: info(NOTICE): WARNING: /usr/local/etc/primes does not exist, using old prime Feb 17 19:38:57 www-reserved sshd[27499]: verbose(INFO): Failed none for gnu from 192.168.2.10 port 58112 ssh2 Feb 17 19:39:00 www-reserved sshd[27499]: info(NOTICE): Accepted password for gnu from 192.168.2.10 port 58112 ssh2 Feb 17 19:39:00 www-reserved sshd[27499]: info(NOTICE): Accepted password for gnu from 192.168.2.10 port 58112 ssh2 Feb 17 19:39:00 www-reserved sshd[27499]: verbose(INFO): Connection closed by remote host. Above are "-2" connections. Below is the "No -2" connection. Feb 17 19:39:13 www-reserved sshd[27519]: verbose(INFO): Connection from 192.168.2.10 port 58113 Feb 17 19:39:18 www-reserved sshd[27519]: info(NOTICE): Accepted password for gnu from 192.168.2.10 port 58113 Feb 17 19:39:18 www-reserved sshd[27519]: info(NOTICE): Accepted password for gnu from 192.168.2.10 port 58113 Feb 17 19:39:18 www-reserved sshd[27519]: verbose(INFO): Closing connection to 192.168.2.10 Happy Hacking, Chiaki From stevesk at sweden.hp.com Sun Feb 18 02:44:44 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Sat, 17 Feb 2001 16:44:44 +0100 (MET) Subject: Important fix (sshd && binding). Portable version only. In-Reply-To: <20010217145428.A17425@ikar.t17.ds.pwr.wroc.pl> Message-ID: On Sat, 17 Feb 2001, Arkadiusz Miskiewicz wrote: : If bind() fails we _always_ should close socket. I sent this patch while ago : to djm but I still don't see this fix in openssh_cvs. i don't know why the test for !ai->ai_next was added? anyone? let's just sync with openbsd. commit? Index: sshd.c =================================================================== RCS file: /var/cvs/openssh/sshd.c,v retrieving revision 1.120 diff -u -r1.120 sshd.c --- sshd.c 2001/02/15 03:17:13 1.120 +++ sshd.c 2001/02/17 15:41:54 @@ -849,8 +849,7 @@ debug("Bind to port %s on %s.", strport, ntop); /* Bind the socket to the desired port. */ - if ((bind(listen_sock, ai->ai_addr, ai->ai_addrlen) < 0) && - (!ai->ai_next)) { + if (bind(listen_sock, ai->ai_addr, ai->ai_addrlen) < 0) { error("Bind to port %s on %s failed: %.200s.", strport, ntop, strerror(errno)); close(listen_sock); From pekkas at netcore.fi Sun Feb 18 02:45:09 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 17 Feb 2001 17:45:09 +0200 (EET) Subject: PATCH: make contrib/redhat/sshd.init work with older RH releases In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Damien Miller wrote: > On Fri, 16 Feb 2001, Pekka Savola wrote: > > > Speaking of sshd.init.. I think it might be a good idea to mave some stuff > > under 'case' to their own functions as Red Hat has done in their own > > openssh package. > > > > Maintainability in both directions would be better, and the file hopefully > > cleaner. > > > > I can volunteer for some merging (in pre-2.5.0 timeline) if this is > > thought to be desirable. > > That would be great, thanks. Ok, here's my initial work. I have yet to hear back from RH about my proposed modifications for their file, but I believe this shouldn't take too long. A few highlights: - $SSHD used (for path + name) instead of sshd - supports RHL'isque i18n in a backward-compatible manner (echo $"...) - testing for keys clarified, -s used. - start/stop functions used, also 'function' keyword for consistency - if [ ! -f $PID_FILE ] check removed. [This might be a bit controversial, but IMO it doesn't make much sense for stop, and start exits with errorlevel 0 if it's already running anyway] - add reload (does HUP) For the curious, my mods for RHL (against 2.3.0p1, mind) are also attached; its virtues: - define locations of ssh-keygen etc. - separate keygen functions - consistent tabbing/whitespacing in 'case' - message for reload, not just '[OK] or '[FAILED]' - missing RETVAL for status (I believe there should be one there) Comments are welcome, of course. If this doesn't go too badly, I might look a bit into other issues, like .spec file differences (post-2.5.0p1). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------- next part -------------- --- ../../openssh_cvs/contrib/redhat/sshd.init Mon Nov 13 13:57:27 2000 +++ sshd Sat Feb 17 17:22:38 2001 @@ -1,5 +1,5 @@ #!/bin/bash - +# # Init file for OpenSSH server daemon # # chkconfig: 2345 55 25 @@ -16,41 +16,67 @@ . /etc/rc.d/init.d/functions RETVAL=0 +prog="sshd" # Some functions to make the below more readable KEYGEN=/usr/bin/ssh-keygen +SSHD=/usr/sbin/sshd RSA1_KEY=/etc/ssh/ssh_host_key RSA_KEY=/etc/ssh/ssh_host_rsa_key DSA_KEY=/etc/ssh/ssh_host_dsa_key PID_FILE=/var/run/sshd.pid -do_rsa1_keygen() { - if ! test -f $RSA1_KEY ; then - echo -n "Generating SSH1 RSA host key: " + +function start() +{ + # Create keys if necessary + do_rsa1_keygen + do_rsa_keygen + do_dsa_keygen + + action $"Starting $prog: " $SSHD + RETVAL=$? + [ "$RETVAL" = 0 ] && touch /var/lock/subsys/sshd +} + +function stop() +{ + echo -n $"Stopping $prog: " + killproc $SSHD + RETVAL=$? + echo + [ "$RETVAL" = 0 ] && rm -f /var/lock/subsys/sshd +} + +function do_rsa1_keygen() { + if [ ! -s $RSA1_KEY ]; then + echo -n $"Generating SSH1 RSA host key: " if $KEYGEN -q -t rsa1 -f $RSA1_KEY -C '' -N '' >&/dev/null; then - success "RSA1 key generation" + success $"RSA1 key generation" echo else - failure "RSA1 key generation" + failure $"RSA1 key generation" echo exit 1 fi fi } -do_rsa_keygen() { - if ! test -f $RSA_KEY ; then - echo -n "Generating SSH2 RSA host key: " + +function do_rsa_keygen() { + if [ ! -s $RSA_KEY ]; then + echo -n $"Generating SSH2 RSA host key: " if $KEYGEN -q -t rsa -f $RSA_KEY -C '' -N '' >&/dev/null; then - success "RSA key generation" + success $"RSA key generation" echo else - failure "RSA key generation" + failure $"RSA key generation" echo exit 1 fi fi } -do_dsa_keygen() { - if ! test -f $DSA_KEY ; then + +function do_dsa_keygen() { + if [ ! -s $DSA_KEY ]; then echo -n "Generating SSH2 DSA host key: " if $KEYGEN -q -t dsa -f $DSA_KEY -C '' -N '' >&/dev/null; then success "DSA key generation" @@ -63,55 +89,36 @@ fi } + case "$1" in start) - # Create keys if necessary - do_rsa1_keygen; - do_rsa_keygen; - do_dsa_keygen; - - echo -n "Starting sshd: " - if [ ! -f $PID_FILE ] ; then - sshd - RETVAL=$? - if [ "$RETVAL" = "0" ] ; then - success "sshd startup" - touch /var/lock/subsys/sshd - else - failure "sshd startup" - fi - fi - echo + start ;; stop) - echo -n "Shutting down sshd: " - if [ -f $PID_FILE ] ; then - killproc sshd - RETVAL=$? - [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/sshd - fi - echo + stop ;; restart) - $0 stop - $0 start + stop + start + ;; + reload) + echo -n $"Reloading $prog: " + killproc $SSHD -HUP RETVAL=$? + echo ;; condrestart) if [ -f /var/lock/subsys/sshd ] ; then - $0 stop - $0 start - RETVAL=$? + stop + start fi ;; status) - status sshd + status $SSHD RETVAL=$? ;; *) - echo "Usage: sshd {start|stop|restart|status|condrestart}" - exit 1 - ;; + echo $"Usage: $0 {start|stop|restart|reload|condrestart|status}" + RETVAL=1 esac - exit $RETVAL -------------- next part -------------- --- openssh.init Sat Feb 17 00:10:59 2001 +++ sshd-2.3.0p1.init Sat Feb 17 10:15:44 2001 @@ -18,16 +18,21 @@ RETVAL=0 prog="sshd" +# Some functions to make the below more readable +KEYGEN=/usr/bin/ssh-keygen +SSHD=/usr/sbin/sshd +RSA1_KEY=/etc/ssh/ssh_host_key +RSA_KEY=/etc/ssh/ssh_host_rsa_key +DSA_KEY=/etc/ssh/ssh_host_dsa_key +PID_FILE=/var/run/sshd.pid + function start() { - if [ ! -s /etc/ssh/ssh_host_key ]; then - /usr/bin/ssh-keygen -b 1024 -f /etc/ssh/ssh_host_key -N "" - fi - if [ ! -s /etc/ssh/ssh_host_dsa_key ]; then - /usr/bin/ssh-keygen -d -f /etc/ssh/ssh_host_dsa_key -N "" - fi + # Create keys if necessary + do_rsa1_keygen + do_dsa_keygen - action $"Starting $prog: " /usr/sbin/sshd + action $"Starting $prog: " $SSHD RETVAL=$? [ "$RETVAL" = 0 ] && touch /var/lock/subsys/sshd } @@ -35,37 +40,70 @@ function stop() { echo -n $"Stopping $prog: " - killproc /usr/sbin/sshd + killproc $SSHD RETVAL=$? echo [ "$RETVAL" = 0 ] && rm -f /var/lock/subsys/sshd } -case "$1" in - start) - start - ;; - stop) - stop - ;; - restart) - stop - start - ;; - reload) - killproc /usr/sbin/sshd -HUP - ;; - condrestart) - if [ -f /var/lock/subsys/sshd ] ; then - stop - start +function do_rsa1_keygen() { + if [ ! -s $RSA1_KEY ]; then + echo -n $"Generating SSH1 RSA host key: " + if $KEYGEN -q -b 1024 -f $RSA1_KEY -C '' -N '' >&/dev/null; then + success $"RSA1 key generation" + echo + else + failure $"RSA1 key generation" + echo + exit 1 + fi fi - ;; - status) - status /usr/sbin/sshd - ;; - *) - echo $"Usage: $0 {start|stop|restart|reload|condrestart|status}" - RETVAL=1 +} + +function do_dsa_keygen() { + if [ ! -s $DSA_KEY ]; then + echo -n "Generating SSH2 DSA host key: " + if $KEYGEN -q -d -f $DSA_KEY -C '' -N '' >&/dev/null; then + success "DSA key generation" + echo + else + failure "DSA key generation" + echo + exit 1 + fi + fi +} + + +case "$1" in + start) + start + ;; + stop) + stop + ;; + restart) + stop + start + ;; + reload) + echo -n $"Reloading $prog: " + killproc $SSHD -HUP + RETVAL=$? + echo + ;; + condrestart) + if [ -f /var/lock/subsys/sshd ] ; then + stop + start + fi + ;; + status) + status $SSHD + RETVAL=$? + ;; + *) + echo $"Usage: $0 {start|stop|restart|reload|condrestart|status}" + RETVAL=1 esac exit $RETVAL From Todd.Miller at courtesan.com Sun Feb 18 02:43:15 2001 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Sat, 17 Feb 2001 08:43:15 -0700 Subject: OpenSSH 2.5.0p1 In-Reply-To: Your message of "Fri, 16 Feb 2001 15:09:26 CST." References: Message-ID: <200102171543.f1HFhGA22044@xerxes.courtesan.com> OpenSSH 2.5.0p1 should be more robust in the face of EGD problems and deal with SIGPIPE gracefully. Below is a more self-contained patch similar to the one I sent in before (and also similar to one Lutz Jaenicke posted in the past). This doesn't include the change to catch ECONNREFUSED and retry since that needs usleep. See: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=98207528123346&w=2 for those bits if you are interested. I do think that is a good idea as well but since I haven't whipped up a generic usleep() it's probably too late for that to be in 2.5.0p1. - todd --- entropy.c.DIST Mon Feb 5 05:42:17 2001 +++ entropy.c Sat Feb 17 08:47:18 2001 @@ -71,7 +71,8 @@ int fd; char msg[2]; struct sockaddr_un addr; - int addr_len; + int addr_len, rval, errors; + struct sigaction nsa, osa; /* Sanity checks */ if (sizeof(EGD_SOCKET) > sizeof(addr.sun_path)) @@ -84,17 +85,22 @@ strlcpy(addr.sun_path, EGD_SOCKET, sizeof(addr.sun_path)); addr_len = offsetof(struct sockaddr_un, sun_path) + sizeof(EGD_SOCKET); + memset(&nsa, 0, sizeof(nsa)); + nsa.sa_handler = SIG_IGN; + (void) sigaction(SIGPIPE, &nsa, &osa); + + errors = rval = 0; +reopen: fd = socket(AF_UNIX, SOCK_STREAM, 0); if (fd == -1) { error("Couldn't create AF_UNIX socket: %s", strerror(errno)); - return(0); + goto done; } if (connect(fd, (struct sockaddr*)&addr, addr_len) == -1) { error("Couldn't connect to EGD socket \"%s\": %s", addr.sun_path, strerror(errno)); - close(fd); - return(0); + goto done; } /* Send blocking read request to EGD */ @@ -102,22 +108,33 @@ msg[1] = len; if (atomicio(write, fd, msg, sizeof(msg)) != sizeof(msg)) { + if (errno == EPIPE && errors < 10) { + close(fd); + errors++; + goto reopen; + } error("Couldn't write to EGD socket \"%s\": %s", EGD_SOCKET, strerror(errno)); - close(fd); - return(0); + goto done; } if (atomicio(read, fd, buf, len) != len) { + if (errno == EPIPE && errors < 10) { + close(fd); + errors++; + goto reopen; + } error("Couldn't read from EGD socket \"%s\": %s", EGD_SOCKET, strerror(errno)); - close(fd); - return(0); + goto done; } - close(fd); - - return(1); + rval = 1; +done: + (void) sigaction(SIGPIPE, &osa, NULL); + if (fd != -1) + close(fd); + return(rval); } #else /* !EGD_SOCKET */ #ifdef RANDOM_POOL From mouring at etoh.eviladmin.org Sun Feb 18 03:05:13 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 17 Feb 2001 10:05:13 -0600 (CST) Subject: OpenSSH 2.5.0p1 In-Reply-To: <3A8E9C20.7330E90B@yk.rim.or.jp> Message-ID: This really need to be tested in the current snapshot. Because of the following: try: ssh site 'echo $PATH' then ssh site 'echo $PATH; sleep 1; The latter will work, but the former will not show anything. This is due to a work around that was removed in development that cause the data channel to prematurely close with data still in it. - Ben On Sun, 18 Feb 2001, Ishikawa wrote: > mouring at etoh.eviladmin.org wrote: > > > Known issues: > > > > > > 7) Solaris '$PATH' issue -- ?? (Unfixable before 2.5.0?) [I'm getting > > more reports of this. I'll present them when they get their facts > > together] > > Attached is a memo that contains the debug output > when the problem is reproduced locally on our office machines. > > I think the afffected systems are at least solaris 7 and solaris 8 from > what I gather from the post. The log below > is generated when I tried the command against sshd > 2.3.0p1 on a solaris 7 for x86 host. > (without "-2", the command works.) > > "ssh -2 host 'echo $PATH' doesn't work against sshd on solaris7 for x86" > > *** > *** server is solaris 7 for x86. We used sun cc compiler. > *** for the server compilation. > *** > *** I think the key factors are solaris 7 and 8 from what > *** I gathered by reading the posts. > > > (The following log is a little complicated since > the ssh connection is passed by a tcp-level gateway to > a final sshd server on a remote host. > But I have observed the same problem WITHOUT > such proxy before.) > > First example. > *** > *** ssh -2 -v -v -v targethost 'echo $PATH' doesn't work. > *** > *** server is solaris 7 for x86. We used sun cc compiler. > *** for the server compilation. > *** > *** > > ssh is invoked from a solaris 2.5.1 host. > > ishikawa at u45$ conn-www.sh -2 -v -v -v 'echo $PATH' > # > # host sun11 > # -p 999 gateway to www-reserved. > # > echo "Timeout is 2 mins." > ++ echo 'Timeout is 2 mins.' > Timeout is 2 mins. > ssh sun11.example.co.jp -p 999 -C -l gnu $* > ++ ssh sun11.example.co.jp -p 999 -C -l gnu -2 -v -v -v echo '$PATH' > SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. > Compiled with SSL (0x0090600f). > debug: Reading configuration data /usr/local/etc/ssh_config > debug: ssh_connect: getuid 12 geteuid 0 anon 0 > debug: Connecting to sun11.example.co.jp [192.168.1.11] port 999. > debug: Reading output from 'ls -alni /var/log' > debug: Time elapsed: 27 msec > debug: Got 1.61 bytes of entropy from 'ls -alni /var/log' > debug: Reading output from 'ls -alni /var/adm' > debug: Time elapsed: 29 msec > ... > ... lines from entropy gathering daemon. > ... > debug: Reading output from 'tail -200 /var/log/syslog' > debug: Time elapsed: 7 msec > debug: Got 0.00 bytes of entropy from 'tail -200 /var/log/syslog' > debug: Reading output from 'tail -200 /var/adm/messages' > debug: Time elapsed: 39 msec > debug: Got 0.46 bytes of entropy from 'tail -200 /var/adm/messages' > debug: Seeded RNG with 40 bytes from programs > debug: Seeded RNG with 3 bytes from system calls > debug: Allocated local port 663. > 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 3des-cbc hmac-sha1 zlib > debug: kex: client->server 3des-cbc hmac-sha1 zlib > 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: 515/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 'sun11.example.co.jp' 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: Enabling compression at level 6. > 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: start over, passed a different list > debug: authmethod_lookup publickey > debug: authmethod_is_enabled publickey > debug: next auth method to try is publickey > debug: key does not exist: /usr2/ishikawa/.ssh/id_dsa > debug: we did not send a packet, disable method > debug: authmethod_lookup publickey > debug: authmethod_lookup password > debug: authmethod_is_enabled password > debug: next auth method to try is password > gnu at sun11.example.co.jp's password: > debug: we sent a password packet, wait for reply > debug: ssh-userauth2 successfull: method password > debug: channel 0: new [client-session] > debug: send channel open 0 > debug: Entering interactive session. <=== But no echo $PATH > debug: callback start output follows... > debug: client_init id 0 arg 0 > debug: Sending command: echo $PATH > 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.3 seconds > debug: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 > debug: Exit status 0 > debug: compress outgoing: raw data 157, compressed 122, factor 0.78 > debug: compress incoming: raw data 103, compressed 95, factor 0.92 > debug: writing PRNG seed to file /usr2/ishikawa/.ssh/prng_seed > > > I repeated the above one more time before attempting > the fallback (no -2) connection. > > ************************* > *** No -2 > *** > *** ssh -v -v -v targethost 'echo $PATH' DOES WORK. > *** > *** server is solaris 7 for x86. We used sun cc compiler. > *** for the server compilation. > *** > *** > ************************* > ishikawa at u45$ conn-www.sh -v -v -v 'echo $PATH' > # > # host sun11 > # -p 999 gateway to www-reserved. > # > echo "Timeout is 2 mins." > ++ echo 'Timeout is 2 mins.' > Timeout is 2 mins. > ssh sun11.example.co.jp -p 999 -C -l gnu $* > ++ ssh sun11.example.co.jp -p 999 -C -l gnu -v -v -v echo '$PATH' > SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. > Compiled with SSL (0x0090600f). > debug: Reading configuration data /usr/local/etc/ssh_config > debug: Reading output from 'ls -alni /var/log' > debug: Time elapsed: 59 msec > debug: Got 1.61 bytes of entropy from 'ls -alni /var/log' > ... > ... > ... > debug: Got 0.00 bytes of entropy from 'tail -200 /var/log/syslog' > debug: Reading output from 'tail -200 /var/adm/messages' > debug: Time elapsed: 28 msec > debug: Got 0.46 bytes of entropy from 'tail -200 /var/adm/messages' > debug: Seeded RNG with 35 bytes from programs > debug: Seeded RNG with 3 bytes from system calls > debug: Allocated local port 670. > debug: Connection established. > debug: Remote protocol version 1.99, remote software version OpenSSH_2.3.0p1 > debug: no match: OpenSSH_2.3.0p1 > debug: Local version string SSH-1.5-OpenSSH_2.3.0p1 > debug: Waiting for server public key. > debug: Received server public key (768 bits) and host key (1024 bits). > debug: Host 'sun11.example.co.jp' is known and matches the RSA host key. > Warning: the RSA host key for 'sun11.example.co.jp' differs > ***from the key for the IP address '192.168.1.11' > debug: Reading output from 'ls -alni /var/log' > debug: Time elapsed: 27 msec > debug: Got 1.61 bytes of entropy from 'ls -alni /var/log' > ... > ... > ... > debug: Got 0.00 bytes of entropy from 'tail -200 /var/log/syslog' > debug: Reading output from 'tail -200 /var/adm/messages' > debug: Time elapsed: 28 msec > debug: Got 0.46 bytes of entropy from 'tail -200 /var/adm/messages' > debug: Seeded RNG with 35 bytes from programs > debug: Seeded RNG with 3 bytes from system calls > debug: Encryption type: 3des > debug: Sent encrypted session key. > debug: Installing crc compensation attack detector. > debug: Received encrypted confirmation. > debug: Doing password authentication. > gnu at sun11.example.co.jp's password: > debug: Requesting compression at level 6. > debug: Enabling compression at level 6. > debug: Sending command: echo $PATH > debug: Entering interactive session. > /usr/sbin:/usr/bin:/usr/local/bin <=== echo $PATH output! > debug: Transferred: stdin 0, stdout 34, stderr 0 bytes in 0.2 seconds > debug: Bytes per second: stdin 0.0, stdout 174.0, stderr 0.0 > debug: Exit status 0 > debug: compress outgoing: raw data 16, compressed 23, factor 1.44 > debug: compress incoming: raw data 44, compressed 37, factor 0.84 > debug: writing PRNG seed to file /usr2/ishikawa/.ssh/prng_seed > > > On the server side. > > The log recoreded showed two "-2" connection attempts and > then "NO -2" connection. > > Feb 17 19:37:07 www-reserved sshd[27487]: info(NOTICE): Accepted password for > gnu from 192.168.2.10 port 58108 ssh2 > Feb 17 19:37:07 www-reserved sshd[27487]: info(NOTICE): Accepted password for > gnu from 192.168.2.10 port 58108 ssh2 > Feb 17 19:37:08 www-reserved sshd[27487]: verbose(INFO): Connection closed by > remote host. > Feb 17 19:38:18 www-reserved sshd[27497]: verbose(INFO): Connection from > 192.168.2.10 port 58111 > Feb 17 19:38:18 www-reserved sshd[27497]: verbose(INFO): Enabling > compatibility mode for protocol 2.0 > Feb 17 19:38:18 www-reserved sshd[27497]: info(NOTICE): WARNING: > /usr/local/etc/primes does not exist, using old prime > Feb 17 19:38:18 www-reserved sshd[27497]: info(NOTICE): WARNING: > /usr/local/etc/primes does not exist, using old prime > Feb 17 19:38:21 www-reserved sshd[27497]: verbose(INFO): Failed none for gnu > from 192.168.2.10 port 58111 ssh2 > Feb 17 19:38:31 www-reserved sshd[27497]: info(NOTICE): Accepted password for > gnu from 192.168.2.10 port 58111 ssh2 > Feb 17 19:38:31 www-reserved sshd[27497]: info(NOTICE): Accepted password for > gnu from 192.168.2.10 port 58111 ssh2 > Feb 17 19:38:31 www-reserved sshd[27497]: verbose(INFO): Connection closed by > remote host. > Feb 17 19:38:54 www-reserved sshd[27499]: verbose(INFO): Connection from > 192.168.2.10 port 58112 > Feb 17 19:38:54 www-reserved sshd[27499]: verbose(INFO): Enabling > compatibility mode for protocol 2.0 > Feb 17 19:38:54 www-reserved sshd[27499]: info(NOTICE): WARNING: > /usr/local/etc/primes does not exist, using old prime > Feb 17 19:38:54 www-reserved sshd[27499]: info(NOTICE): WARNING: > /usr/local/etc/primes does not exist, using old prime > Feb 17 19:38:57 www-reserved sshd[27499]: verbose(INFO): Failed none for gnu > from 192.168.2.10 port 58112 ssh2 > Feb 17 19:39:00 www-reserved sshd[27499]: info(NOTICE): Accepted password for > gnu from 192.168.2.10 port 58112 ssh2 > Feb 17 19:39:00 www-reserved sshd[27499]: info(NOTICE): Accepted password for > gnu from 192.168.2.10 port 58112 ssh2 > Feb 17 19:39:00 www-reserved sshd[27499]: verbose(INFO): Connection closed by > remote host. > > Above are "-2" connections. > Below is the "No -2" connection. > > Feb 17 19:39:13 www-reserved sshd[27519]: verbose(INFO): Connection from > 192.168.2.10 port 58113 > Feb 17 19:39:18 www-reserved sshd[27519]: info(NOTICE): Accepted password for > gnu from 192.168.2.10 port 58113 > Feb 17 19:39:18 www-reserved sshd[27519]: info(NOTICE): Accepted password for > gnu from 192.168.2.10 port 58113 > Feb 17 19:39:18 www-reserved sshd[27519]: verbose(INFO): Closing connection > to 192.168.2.10 > > > > Happy Hacking, > > Chiaki > > From misiek at pld.ORG.PL Sun Feb 18 03:04:49 2001 From: misiek at pld.ORG.PL (Arkadiusz Miskiewicz) Date: Sat, 17 Feb 2001 17:04:49 +0100 Subject: Important fix (sshd && binding). Portable version only. In-Reply-To: ; from stevesk@sweden.hp.com on Sat, Feb 17, 2001 at 04:44:44PM +0100 References: <20010217145428.A17425@ikar.t17.ds.pwr.wroc.pl> Message-ID: <20010217170449.A18917@ikar.t17.ds.pwr.wroc.pl> On/Dnia Sat, Feb 17, 2001 at 04:44:44PM +0100, Kevin Steves wrote/napisa?(a) > On Sat, 17 Feb 2001, Arkadiusz Miskiewicz wrote: > : If bind() fails we _always_ should close socket. I sent this patch while ago > : to djm but I still don't see this fix in openssh_cvs. > > i don't know why the test for !ai->ai_next was added? anyone? It's to avoid error message > let's just sync with openbsd. commit? this will cause error message displayed with _proper_ sshd_config. On Linux you can't do: s1 = socket(AF_INET, ...) bind(s1, INADDR_ANY, port 22 ...); s2 = socket(AF_INET6, ...) bind(s2, in6addr_any, port22 ...); while on *BSD you can. BSD treats ipv4 and ipv6 separately while linux not. > /* Bind the socket to the desired port. */ > - if ((bind(listen_sock, ai->ai_addr, ai->ai_addrlen) < 0) && > - (!ai->ai_next)) { > + if (bind(listen_sock, ai->ai_addr, ai->ai_addrlen) < 0) { > error("Bind to port %s on %s failed: %.200s.", > strport, ntop, strerror(errno)); > close(listen_sock); -- Arkadiusz Mi?kiewicz, AM2-6BONE [ PLD GNU/Linux IPv6 ] http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/ [ enabled ] From marekm at amelek.gda.pl Sun Feb 18 03:30:13 2001 From: marekm at amelek.gda.pl (Marek Michalkiewicz) Date: Sat, 17 Feb 2001 17:30:13 +0100 (CET) Subject: Where is OpenSSH 2.5.0p1? Message-ID: Hi, it seems the 2.5.0p1 announcement on www.openssh.com went out a little bit too early ;). Just curious, why 2.4 was skipped? I don't believe this is just to have a higher version number than the competition ;). I see 2.5.0 is there, but no 2.5.0p1 yet even on ftp.openbsd.org itself. Looking at the CVS tree, I see the two bugs I reported to this list some time ago (with no response) are still there. Below is a patch to fix them, please tell me if you see anything wrong with it. (I have tested it on Debian woody, appears to work fine so far.) One bug is only swapped tests for no_libsocket and no_libnsl. The other bug looks more serious to me - quote from glibc manual: *Warning:* Using the `openpty' function with NAME not set to `NULL' is *very dangerous* because it provides no protection against overflowing the string NAME. You should use the `ttyname' function on the file descriptor returned in *SLAVE to find out the file name of the slave pseudo-terminal device instead. Thanks, and keep up the good work! Marek Index: configure.in =================================================================== RCS file: /cvs/openssh_cvs/configure.in,v retrieving revision 1.243 diff -u -r1.243 configure.in --- configure.in 2001/02/16 01:12:41 1.243 +++ configure.in 2001/02/17 16:06:48 @@ -317,10 +317,10 @@ ) # Checks for libraries. -if test -z "$no_libsocket" ; then +if test -z "$no_libnsl" ; then AC_CHECK_LIB(nsl, yp_match, , ) fi -if test -z "$no_libnsl" ; then +if test -z "$no_libsocket" ; then AC_CHECK_LIB(socket, main, , ) fi Index: pty.c =================================================================== RCS file: /cvs/openssh_cvs/pty.c,v retrieving revision 1.31 diff -u -r1.31 pty.c --- pty.c 2001/02/09 02:11:24 1.31 +++ pty.c 2001/02/17 16:06:49 @@ -49,15 +49,19 @@ { #if defined(HAVE_OPENPTY) || defined(BSD4_4) /* openpty(3) exists in OSF/1 and some other os'es */ - char buf[64]; + char *name; int i; - i = openpty(ptyfd, ttyfd, buf, NULL, NULL); + i = openpty(ptyfd, ttyfd, NULL, NULL, NULL); if (i < 0) { error("openpty: %.100s", strerror(errno)); return 0; } - strlcpy(namebuf, buf, namebuflen); /* possible truncation */ + name = ttyname(*ttyfd); + if (!name) + fatal("openpty returns device for which ttyname fails."); + + strlcpy(namebuf, name, namebuflen); /* possible truncation */ return 1; #else /* HAVE_OPENPTY */ #ifdef HAVE__GETPTY From stevesk at sweden.hp.com Sun Feb 18 03:31:53 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Sat, 17 Feb 2001 17:31:53 +0100 (MET) Subject: Important fix (sshd && binding). Portable version only. In-Reply-To: <20010217170449.A18917@ikar.t17.ds.pwr.wroc.pl> Message-ID: On Sat, 17 Feb 2001, Arkadiusz Miskiewicz wrote: : > i don't know why the test for !ai->ai_next was added? anyone? : It's to avoid error message that change is broken, because it skips displaying valid error messages, and also displays invalid error messages; in this case port 22 is already bound: # ./sshd -d debug1: sshd version OpenSSH_2.5.0p1 debug1: load_private_key_autodetect: type 0 RSA1 debug1: read SSH2 private key done: name dsa w/o comment success 1 debug1: load_private_key_autodetect: type 2 DSA debug1: Seeding random number generator debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug1: Bind to port 24 on 0.0.0.0. Server listening on 0.0.0.0 port 24. Generating 768 bit RSA key. debug1: Seeding random number generator RSA key generation complete. From mouring at etoh.eviladmin.org Sun Feb 18 03:43:43 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 17 Feb 2001 10:43:43 -0600 (CST) Subject: OpenSSH 2.5.0p1 In-Reply-To: <20010216212126.A2563@pianosa.catch22.org> Message-ID: On Fri, 16 Feb 2001, David Terrell wrote: > On Fri, Feb 16, 2001 at 10:46:10PM -0600, mouring at etoh.eviladmin.org wrote: > > The choice is either we ignore AIX or we stop the default behavior of > > building out of the tree. Where the latter is anonying the form is > > unacceptable. > > Am I missing something, or wouldn't simply renaming login.h work? That > seems like a fairly common word to use as a private header file anyway... > > If we did this I would perfer if Markus would provide the name for which he plans on moving it to in the OpenBSD tree (including pty.h/pty.c). Keeping trees in sync with different files names is not fun. =) If not, I would rather break builddir != srcdir for a single platform then revisit it post-2.5.0. Frankly, it really does not thrill me to see -I. when I do a ./configure;make inside the source directory. Mainly because of the fact that -I options are defined before your include path, and this has caused problems before that have not be address (pty.c/pty.h and openpty() function). But this is just my personal view. Take it for whatever it's worth. - Ben From mouring at etoh.eviladmin.org Sun Feb 18 04:17:05 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 17 Feb 2001 11:17:05 -0600 (CST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: I've applied the misc.c and sftp-client.c patch. However I know there was a reason for us -L$ssldir and -L$ssldir/lib. And I would rather see a solution that keeps both tests in place if possible. - Ben On Fri, 16 Feb 2001, Tim Rice wrote: > On Fri, 16 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > I guess what needs to be asked... Is what needs to OCCUR in the next 3 > > to 4 days to assure we have a stable project on majority of the platforms? > > Attached is a patch that fixes SCO Open Server 3 > > It configures/builds fine without & with tcp-wrapers on > Solaris 8 > UnixWare 2.03 > UnixWare 2.1.3 > UnixWare 7.1.0 > SCO 5.0.4 > Caldera sDesktop 2.4 > > > > > - Ben > > > > > > From misiek at pld.ORG.PL Sun Feb 18 04:14:31 2001 From: misiek at pld.ORG.PL (Arkadiusz Miskiewicz) Date: Sat, 17 Feb 2001 18:14:31 +0100 Subject: Important fix (sshd && binding). Portable version only. In-Reply-To: ; from stevesk@sweden.hp.com on Sat, Feb 17, 2001 at 05:31:53PM +0100 References: <20010217170449.A18917@ikar.t17.ds.pwr.wroc.pl> Message-ID: <20010217181431.A20044@ikar.t17.ds.pwr.wroc.pl> On/Dnia Sat, Feb 17, 2001 at 05:31:53PM +0100, Kevin Steves wrote/napisa?(a) > that change is broken, not exacly. You need to chose between two situations ... see below > because it skips displaying valid error messages, > and also displays invalid error messages; in this case port 22 is > already bound: so now remove all ListenAddress directives from config and run sshd on ipv6 ready kernel... It will try to bind on :: and then bind on 0.0.0.0. If you remove af_next check then second bind will cause error message but this is _proper_ configuration and _proper_ bind behavoiur at least on Linux. Problem exist due to different ipv6 implementations/rfc interpretations. You need to choose between geting error even on proper configurations or not showing it in some cases. > debug1: Bind to port 22 on 0.0.0.0. > Server listening on 0.0.0.0 port 22. > debug1: Bind to port 24 on 0.0.0.0. > Server listening on 0.0.0.0 port 24. > Generating 768 bit RSA key. -- Arkadiusz Mi?kiewicz, AM2-6BONE [ PLD GNU/Linux IPv6 ] http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/ [ enabled ] From pekkas at netcore.fi Sun Feb 18 04:15:48 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 17 Feb 2001 19:15:48 +0200 (EET) Subject: Where is OpenSSH 2.5.0p1? In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Marek Michalkiewicz wrote: > it seems the 2.5.0p1 announcement on www.openssh.com went out a little > bit too early ;). Just curious, why 2.4 was skipped? I don't believe > this is just to have a higher version number than the competition ;). > I see 2.5.0 is there, but no 2.5.0p1 yet even on ftp.openbsd.org itself. deraadt changed the web pages to reflect to both, 2.5.0 and 2.5.0p1, at the same time. I'm certain 2.5.0p1 will be cut very shortly :-). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From jmknoble at jmknoble.cx Sun Feb 18 05:34:59 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Sat, 17 Feb 2001 13:34:59 -0500 Subject: PATCH: make contrib/redhat/sshd.init work with older RH releases In-Reply-To: ; from pekkas@netcore.fi on Sat, Feb 17, 2001 at 05:45:09PM +0200 References: Message-ID: <20010217133459.E25687@quipu.half.pint-stowp.cx> Circa 2001-Feb-17 17:45:09 +0200 dixit Pekka Savola: : Ok, here's my initial work. I have yet to hear back from RH about my : proposed modifications for their file, but I believe this shouldn't take : too long. : : A few highlights: : - $SSHD used (for path + name) instead of sshd : - supports RHL'isque i18n in a backward-compatible manner (echo $"...) Bash-1.14.x doesn't handle the $"..." construct properly: $ /bin/bash $ echo $BASH_VERSION 1.14.7(1) $ echo $"Generating SSH1 RSA host key: " $Generating SSH1 RSA host key: ^^^ \ Note the spurious '$' character If you want to use the $"..." construct, then using the following function instead of plain 'echo' ought to work with both bash-1.14.7 and bash-2.x (so that this will work without modification under older releases): my_echo() { local args="" while [ $# -gt 0 ]; do case "$1" in --) break ;; -*) args="${args} $1" shift ;; *) break ;; esac done case "${BASH_VERSION}" in 1.*) echo ${args} "$@" ;; *) echo ${args} $"$@" ;; esac } : - testing for keys clarified, -s used. : - start/stop functions used, also 'function' keyword for consistency I think it would be better to call the start() and stop() functions by more specific names to avoid potential namespace conflict. Any of these would be better (i myself prefer the second): - start_sshd, stop_sshd - sshd_start, sshd_stop - start_ssh, stop_ssh - ssh_start, ssh_stop In fact, i would suggest prefixing all function names defined here with 'sshd_' or 'ssh_'. Also, if you're going to use the 'function' keyword, then please don't use parentheses: $ echo $BASH_VERSION 1.14.7(1) $ help function |head -1 function: function NAME { COMMANDS ; } or NAME () { COMMANDS ; } $ /bin/bash2 $ echo $BASH_VERSION 2.03.8(1)-release $ help function |head -1 function: function NAME { COMMANDS ; } or NAME () { COMMANDS ; } $ Using both is bad syntax, even though bash doesn't complain. : - if [ ! -f $PID_FILE ] check removed. : [This might be a bit controversial, but IMO it doesn't make much : sense for stop, and start exits with errorlevel 0 if it's already running : anyway] This is fine; sshd Does The Right Thing(R) when somebody is already bound to the relevant address+port, and it's possible for the PID file to disappear due to filesystem problems or operator error, so it's an unreliable indicator that sshd is or isn't running. : - add reload (does HUP) : : Comments are welcome, of course. It's a good thing. :) Good work, Pekka. -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From vinschen at redhat.com Sun Feb 18 05:46:05 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 17 Feb 2001 19:46:05 +0100 Subject: OpenSSH 2.5.0p1 In-Reply-To: ; from mouring@etoh.eviladmin.org on Sat, Feb 17, 2001 at 10:43:43AM -0600 References: <20010216212126.A2563@pianosa.catch22.org> Message-ID: <20010217194605.E16740@cygbert.vinschen.de> On Sat, Feb 17, 2001 at 10:43:43AM -0600, mouring at etoh.eviladmin.org wrote: > On Fri, 16 Feb 2001, David Terrell wrote: > > > On Fri, Feb 16, 2001 at 10:46:10PM -0600, mouring at etoh.eviladmin.org wrote: > > > The choice is either we ignore AIX or we stop the default behavior of > > > building out of the tree. Where the latter is anonying the form is > > > unacceptable. > > > > Am I missing something, or wouldn't simply renaming login.h work? That > > seems like a fairly common word to use as a private header file anyway... > > > > > If we did this I would perfer if Markus would provide the name for which > he plans on moving it to in the OpenBSD tree (including pty.h/pty.c). > Keeping trees in sync with different files names is not fun. =) > > If not, I would rather break builddir != srcdir for a single platform then > revisit it post-2.5.0. > > Frankly, it really does not thrill me to see -I. when I do a > ./configure;make inside the source directory. Mainly because of the IMO: builddir != srcdir is the standard case. builddir == srcdir is just a special case which moreover isn't a too clean way to build stuff. I think it isn't' worth to tweak configure to drop some -I for just one special case. Just my 2ct worth, Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From pekkas at netcore.fi Sun Feb 18 05:53:36 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 17 Feb 2001 20:53:36 +0200 (EET) Subject: OpenSSH 2.5.0p1 In-Reply-To: <20010217194605.E16740@cygbert.vinschen.de> Message-ID: On Sat, 17 Feb 2001, Corinna Vinschen wrote: > On Sat, Feb 17, 2001 at 10:43:43AM -0600, mouring at etoh.eviladmin.org wrote: > > On Fri, 16 Feb 2001, David Terrell wrote: > > > > > On Fri, Feb 16, 2001 at 10:46:10PM -0600, mouring at etoh.eviladmin.org wrote: > > > > The choice is either we ignore AIX or we stop the default behavior of > > > > building out of the tree. Where the latter is anonying the form is > > > > unacceptable. > > > > > > Am I missing something, or wouldn't simply renaming login.h work? That > > > seems like a fairly common word to use as a private header file anyway... > > > > > > > > If we did this I would perfer if Markus would provide the name for which > > he plans on moving it to in the OpenBSD tree (including pty.h/pty.c). > > Keeping trees in sync with different files names is not fun. =) > > > > If not, I would rather break builddir != srcdir for a single platform then > > revisit it post-2.5.0. > > > > Frankly, it really does not thrill me to see -I. when I do a > > ./configure;make inside the source directory. Mainly because of the > > IMO: builddir != srcdir is the standard case. builddir == srcdir > is just a special case which moreover isn't a too clean way to > build stuff. I think it isn't' worth to tweak configure to drop > some -I for just one special case. builddir == srcdir is a special case, true, but still.. I'd approximate over 95% if not 99% of users _do_ build software when builddir == srcdir. It's IMO a lot more important to get it right for the most commonly used case. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From jmknoble at jmknoble.cx Sun Feb 18 06:14:10 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Sat, 17 Feb 2001 14:14:10 -0500 Subject: PATCH: make contrib/redhat/sshd.init work with older RH releases In-Reply-To: ; from pekkas@netcore.fi on Sat, Feb 17, 2001 at 05:14:34PM +0200 References: <20010216144807.A25687@quipu.half.pint-stowp.cx> Message-ID: <20010217141410.F25687@quipu.half.pint-stowp.cx> Circa 2001-Feb-17 17:14:34 +0200 dixit Pekka Savola: : On Fri, 16 Feb 2001, Jim Knoble wrote: : > Attached is a patch to contrib/redhat/sshd.init which eliminates the : > dependency on the success() and failure() functions from : > initscripts>=4.16. This allows sshd.init to be used for both early and : > recent releases of Red Hat Linux (i've confirmed it works on both 4.2 : > and 5.2 as well as 6.2). : : IMO, this is a wrong way to do this. : : Rather, if we want to do this, I propose something like (sshd-funcs may : not be the best name to describe this..): What you suggest would make a lot more changes to the file; i was trying to keep the number of changes to a minimum, since it's right before release. If folks think it's a good idea to redo the whole thing, then by all means do it right. : --- sshd~ Sat Feb 17 16:16:33 2001 : +++ sshd Sat Feb 17 17:07:00 2001 : @@ -15,6 +15,9 @@ : # source function library : . /etc/rc.d/init.d/functions : : +# source local sshd functions : +. /etc/rc.d/init.d/sshd-funcs : + I think one of the following names is better (i myself prefer the first): sshd-functions sshd.functions functions.sshd Remember also that in RHL-7.0 (and in FHS >= 2.0), the location of 'init.d' changes. This looks more robust to me: SSHD_FUNCTIONS="" for i in \ /etc/init.d/sshd-functions \ /etc/rc.d/init.d/sshd-functions \ ; do if [ -f "${i}" ]; then SSHD_FUNCTIONS="${i}" . "${SSHD_FUNCTIONS}" break fi done if [ -z "${SSHD_FUNCTIONS}" -o $? -ne 0 ]; then exit 1 fi But it's rather complex. Even this would be acceptable: if [ -f /etc/init.d/sshd-functions ]; then . /etc/init.d/sshd-functions else . /etc/rc.d/init.d/sshd-functions fi if [ $? -ne 0 ]; then exit 1 fi : --- : [no further changes in the main file!] : : Where sshd-funcs would redefine success, failure, action, and whatever : other things that might come up, with something of it's own, like: The problem is with redefining the stock functions is that success() and failure() work slightly differently than the equivalent actions for RHL <= 5.2. That's why the my_success() and my_failure() functions i defined take an optional second argument, to make them Act The Right Way(R) for all RH releases. In RHL-6.2, success() and failure() only care about their first argument ($1), and it , but there's no guarantee that Red Hat won't change the functions in the future. Using our own functions avoids that potential problem. Note, though, that my main goal is to make one sshd.init work for RHL releases >= 4.2. However we can agree to do that properly is fine with me. -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From vinschen at redhat.com Sun Feb 18 06:24:18 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 17 Feb 2001 20:24:18 +0100 Subject: OpenSSH 2.5.0p1 In-Reply-To: ; from pekkas@netcore.fi on Sat, Feb 17, 2001 at 08:53:36PM +0200 References: <20010217194605.E16740@cygbert.vinschen.de> Message-ID: <20010217202418.F16740@cygbert.vinschen.de> On Sat, Feb 17, 2001 at 08:53:36PM +0200, Pekka Savola wrote: > On Sat, 17 Feb 2001, Corinna Vinschen wrote: > > On Sat, Feb 17, 2001 at 10:43:43AM -0600, mouring at etoh.eviladmin.org wrote: > > > On Fri, 16 Feb 2001, David Terrell wrote: > > > > > > > On Fri, Feb 16, 2001 at 10:46:10PM -0600, mouring at etoh.eviladmin.org wrote: > > > > > The choice is either we ignore AIX or we stop the default behavior of > > > > > building out of the tree. Where the latter is anonying the form is > > > > > unacceptable. > > > > > > > > Am I missing something, or wouldn't simply renaming login.h work? That > > > > seems like a fairly common word to use as a private header file anyway... > > > > > > > > > > > If we did this I would perfer if Markus would provide the name for which > > > he plans on moving it to in the OpenBSD tree (including pty.h/pty.c). > > > Keeping trees in sync with different files names is not fun. =) > > > > > > If not, I would rather break builddir != srcdir for a single platform then > > > revisit it post-2.5.0. > > > > > > Frankly, it really does not thrill me to see -I. when I do a > > > ./configure;make inside the source directory. Mainly because of the > > > > IMO: builddir != srcdir is the standard case. builddir == srcdir > > is just a special case which moreover isn't a too clean way to > > build stuff. I think it isn't' worth to tweak configure to drop > > some -I for just one special case. > > builddir == srcdir is a special case, true, but still.. I'd approximate > over 95% if not 99% of users _do_ build software when builddir == srcdir. > It's IMO a lot more important to get it right for the most commonly used > case. Ok. But that's no reason to treat builddir == srcdir special. Just treat it the same. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From stevesk at sweden.hp.com Sun Feb 18 06:25:53 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Sat, 17 Feb 2001 20:25:53 +0100 (MET) Subject: Important fix (sshd && binding). Portable version only. In-Reply-To: <20010217181431.A20044@ikar.t17.ds.pwr.wroc.pl> Message-ID: On Sat, 17 Feb 2001, Arkadiusz Miskiewicz wrote: : > because it skips displaying valid error messages, : > and also displays invalid error messages; in this case port 22 is : > already bound: : so now remove all ListenAddress directives from config and run sshd : on ipv6 ready kernel... It will try to bind on :: and then : bind on 0.0.0.0. If you remove af_next check then second bind will : cause error message but this is _proper_ configuration and _proper_ bind : behavoiur at least on Linux. Problem exist due to different ipv6 implementations/rfc : interpretations. You need to choose between geting error even on proper configurations : or not showing it in some cases. i don't have ipv6 configs to experiment with, but i do not agree with a change that drops valid error messages and logs erroneous success messages. i would like to sync with openbsd. can you come up with a patch that would be accepted in their tree that will log acceptably on all platforms? From vinschen at redhat.com Sun Feb 18 06:47:44 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 17 Feb 2001 20:47:44 +0100 Subject: OpenSSH 2.5.0p1 In-Reply-To: <20010217005253.M13748@cygbert.vinschen.de>; from vinschen@redhat.com on Sat, Feb 17, 2001 at 12:52:53AM +0100 References: <20010217005253.M13748@cygbert.vinschen.de> Message-ID: <20010217204744.G16740@cygbert.vinschen.de> On Sat, Feb 17, 2001 at 12:52:53AM +0100, Corinna Vinschen wrote: > However, I have only tested to be able to build and a call to > scp. More testing will follow tomorrow. ssh, sshd and scp work fine. Unfortunately I can't connect to sftp-server anymore, client and server both on Cygwin 1.1.8. What could be the reason here? ========== DEBUG ON ============ /home/corinna [2]$ sftp -v -v -v corinna Connecting to corinna... debug: SSH args "ssh -oProtocol=2 -s -oForwardAgent=no -oForwardX11=no -v -v -v corinna sftp" SSH Version OpenSSH_2.3.2p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090600f). debug: Reading configuration data /home/corinna/.ssh/config debug: Applying options for corinna debug: Applying options for * debug: Reading configuration data /etc/ssh_config debug: Applying options for * debug: ssh_connect: getuid 100 geteuid 100 anon 1 debug: Connecting to corinna [192.168.120.254] port 22. debug: Connection established. debug: Bad RSA1 key file /home/corinna/.ssh/id_dsa. debug: identity file /home/corinna/.ssh/id_dsa type 3 debug: identity file /home/corinna/.ssh/identity type 0 debug: Remote protocol version 1.99, remote software version OpenSSH_2.3.2p1 debug: match: OpenSSH_2.3.2p1 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug: Local version string SSH-2.0-OpenSSH_2.3.2p1 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,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,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 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: mac_init: found hmac-sha1 debug: kex: server->client 3des-cbc hmac-sha1 zlib debug: mac_init: found hmac-sha1 debug: kex: client->server 3des-cbc hmac-sha1 zlib 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: 1014/2049 debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. debug: Got SSH2_MSG_KEXDH_REPLY. debug: Host 'corinna' is known and matches the DSA host key. debug: Found key in /home/corinna/.ssh/known_hosts2:8 debug: bits set: 1046/2049 debug: len 55 datafellows 0 debug: ssh_dss_verify: signature correct debug: Wait SSH2_MSG_NEWKEYS. debug: Enabling compression at level 6. 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,keyboard-interactive 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/corinna/.ssh/id_dsa debug: read SSH2 private key done: name dsa w/o comment success 1 debug: sign_and_send_pubkey debug: sig size 20 20 debug: we sent a publickey packet, wait for reply debug: ssh-userauth2 successful: method publickey debug: fd 4 setting O_NONBLOCK 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: Sending subsystem: sftp debug: callback done debug: channel 0: open confirm rwindow 0 rmax 16384 debug: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 Request for subsystem 'sftp' failed on channel 0 debug: Calling cleanup 0x415f28(0x0) debug: Calling cleanup 0x419244(0x0) debug: compress outgoing: raw data 658, compressed 610, factor 0.93 debug: compress incoming: raw data 76, compressed 73, factor 0.96 Couldn't read packet: Connection reset by peer ========== DEBUG OFF ============ Corinna From markus.friedl at informatik.uni-erlangen.de Sun Feb 18 07:03:43 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 17 Feb 2001 21:03:43 +0100 Subject: OpenSSH 2.3.0p1 port to BSDI BSD/OS In-Reply-To: <20010216223034.6032E12685@jenkins.web.us.uu.net>; from djm@web.us.uu.net on Fri, Feb 16, 2001 at 05:30:34PM -0500 References: <20010216223034.6032E12685@jenkins.web.us.uu.net> Message-ID: <20010217210342.A10098@folly> hi, could you please try this, does kerberos+password work? does skey work? does user:style work with challenge- reposnse in ssh1 and ssh2? thanks, -m Index: auth-chall.c =================================================================== RCS file: /home/markus/cvs/ssh/auth-chall.c,v retrieving revision 1.4 diff -u -r1.4 auth-chall.c --- auth-chall.c 2001/02/04 15:32:22 1.4 +++ auth-chall.c 2001/02/17 19:15:46 @@ -26,7 +26,48 @@ RCSID("$OpenBSD: auth-chall.c,v 1.4 2001/02/04 15:32:22 stevesk Exp $"); #include "auth.h" +#include "log.h" +#ifdef BSD_AUTH +char * +get_challenge(Authctxt *authctxt, char *devs) +{ + char *challenge; + + if (authctxt->as != NULL) { + debug2("try reuse session"); + challenge = auth_getitem(authctxt->as, AUTHV_CHALLENGE); + if (challenge != NULL) { + debug2("reuse bsd auth session"); + return challenge; + } + auth_close(authctxt->as); + authctxt->as = NULL; + } + debug2("new bsd auth session"); + if (devs == NULL || strlen(devs) == 0) + devs = authctxt->style; + debug3("bsd auth: devs %s", devs ? devs : ""); + authctxt->as = auth_userchallenge(authctxt->user, devs, "auth-ssh", + &challenge); + if (authctxt->as == NULL) + return NULL; + debug2("get_challenge: <%s>", challenge ? challenge : "EMPTY"); + return challenge; +} +int +verify_response(Authctxt *authctxt, char *response) +{ + int authok; + + if (authctxt->as == 0) + error("verify_response: no bsd auth session"); + authok = auth_userresponse(authctxt->as, response, 0); + authctxt->as = NULL; + debug("verify_response: <%s> = <%d>", response, authok); + return authok != 0; +} +#else #ifdef SKEY #include @@ -59,4 +100,5 @@ { return 0; } +#endif #endif Index: auth-passwd.c =================================================================== RCS file: /home/markus/cvs/ssh/auth-passwd.c,v retrieving revision 1.21 diff -u -r1.21 auth-passwd.c --- auth-passwd.c 2001/02/12 16:16:23 1.21 +++ auth-passwd.c 2001/02/16 22:41:12 @@ -44,14 +44,17 @@ #include "servconf.h" #include "auth.h" + +extern ServerOptions options; + /* * Tries to authenticate the user using password. Returns true if * authentication succeeds. */ int -auth_password(struct passwd * pw, const char *password) +auth_password(Authctxt *authctxt, const char *password) { - extern ServerOptions options; + struct passwd * pw = authctxt->pw; char *encrypted_password; /* deny if no user. */ @@ -61,6 +64,13 @@ return 0; if (*password == '\0' && options.permit_empty_passwd == 0) return 0; +#ifdef BSD_AUTH + if (auth_userokay(pw->pw_name, authctxt->style, "auth-ssh", + (char *)password) == 0) + return 0; + else + return 1; +#endif #ifdef KRB4 if (options.kerberos_authentication == 1) { Index: auth.h =================================================================== RCS file: /home/markus/cvs/ssh/auth.h,v retrieving revision 1.11 diff -u -r1.11 auth.h --- auth.h 2001/02/12 16:16:23 1.11 +++ auth.h 2001/02/16 22:41:25 @@ -28,6 +28,13 @@ #include +#ifdef HAVE_LOGIN_CAP +#include +#endif +#ifdef BSD_AUTH +#include +#endif + typedef struct Authctxt Authctxt; struct Authctxt { int success; @@ -39,6 +46,9 @@ char *service; struct passwd *pw; char *style; +#ifdef BSD_AUTH + auth_session_t *as; +#endif }; /* @@ -59,7 +69,7 @@ * Tries to authenticate the user using password. Returns true if * authentication succeeds. */ -int auth_password(struct passwd * pw, const char *password); +int auth_password(Authctxt *authctxt, const char *password); /* * Performs the RSA authentication dialog with the client. This returns 0 if Index: auth1.c =================================================================== RCS file: /home/markus/cvs/ssh/auth1.c,v retrieving revision 1.17 diff -u -r1.17 auth1.c --- auth1.c 2001/02/13 22:49:40 1.17 +++ auth1.c 2001/02/16 22:55:47 @@ -83,7 +83,7 @@ #ifdef KRB4 (!options.kerberos_authentication || options.kerberos_or_local_passwd) && #endif - auth_password(pw, "")) { + auth_password(authctxt, "")) { auth_log(authctxt, 1, "without authentication", ""); return; } @@ -244,7 +244,7 @@ packet_integrity_check(plen, 4 + dlen, type); /* Try authentication with the password. */ - authenticated = auth_password(pw, password); + authenticated = auth_password(authctxt, password); memset(password, 0, strlen(password)); xfree(password); @@ -284,6 +284,12 @@ log("Unknown message during authentication: type %d", type); break; } +#ifdef BSD_AUTH + if (authctxt->as) { + auth_close(authctxt->as); + authctxt->as = NULL; + } +#endif if (!authctxt->valid && authenticated) fatal("INTERNAL ERROR: authenticated invalid user %s", authctxt->user); Index: auth2.c =================================================================== RCS file: /home/markus/cvs/ssh/auth2.c,v retrieving revision 1.42 diff -u -r1.42 auth2.c --- auth2.c 2001/02/13 22:49:40 1.42 +++ auth2.c 2001/02/16 22:41:52 @@ -208,6 +208,12 @@ /* reset state */ dispatch_set(SSH2_MSG_USERAUTH_INFO_RESPONSE, &protocol_error); authctxt->postponed = 0; +#ifdef BSD_AUTH + if (authctxt->as) { + auth_close(authctxt->as); + authctxt->as = NULL; + } +#endif /* try to authenticate user */ m = authmethod_lookup(method); @@ -305,7 +311,7 @@ m->enabled = NULL; packet_done(); userauth_banner(); - return authctxt->valid ? auth_password(authctxt->pw, "") : 0; + return authctxt->valid ? auth_password(authctxt, "") : 0; } int @@ -321,7 +327,7 @@ password = packet_get_string(&len); packet_done(); if (authctxt->valid && - auth_password(authctxt->pw, password) == 1) + auth_password(authctxt, password) == 1) authenticated = 1; memset(password, 0, len); xfree(password); Index: session.c =================================================================== RCS file: /home/markus/cvs/ssh/session.c,v retrieving revision 1.56 diff -u -r1.56 session.c --- session.c 2001/02/16 14:03:43 1.56 +++ session.c 2001/02/16 21:15:54 @@ -58,10 +58,6 @@ #include "canohost.h" #include "session.h" -#ifdef HAVE_LOGIN_CAP -#include -#endif - /* types */ #define TTYSZ 64 @@ -837,8 +833,13 @@ (LOGIN_SETALL & ~LOGIN_SETPATH)) < 0) { perror("unable to set user context"); exit(1); - } +#ifdef BSD_AUTH + if (auth_approval(NULL, lc, pw->pw_name, "auth-ssh") <= 0) { + perror("Approval failure"); + exit(1); + } +#endif #else if (setlogin(pw->pw_name) < 0) error("setlogin failed: %s", strerror(errno)); Index: sshd/Makefile =================================================================== RCS file: /home/markus/cvs/ssh/sshd/Makefile,v retrieving revision 1.35 diff -u -r1.35 Makefile --- sshd/Makefile 2001/01/29 01:58:23 1.35 +++ sshd/Makefile 2001/01/31 17:32:43 @@ -7,7 +7,7 @@ BINMODE=555 BINDIR= /usr/sbin MAN= sshd.8 -CFLAGS+=-DHAVE_LOGIN_CAP +CFLAGS+=-DHAVE_LOGIN_CAP -DBSD_AUTH SRCS= sshd.c auth-rhosts.c auth-passwd.c auth-rsa.c auth-rh-rsa.c \ pty.c log-server.c login.c servconf.c serverloop.c \ From pekkas at netcore.fi Sun Feb 18 07:14:37 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 17 Feb 2001 22:14:37 +0200 (EET) Subject: PATCH: make contrib/redhat/sshd.init work with older RH releases In-Reply-To: <20010217141410.F25687@quipu.half.pint-stowp.cx> Message-ID: On Sat, 17 Feb 2001, Jim Knoble wrote: > Remember also that in RHL-7.0 (and in FHS >= 2.0), the location of > 'init.d' changes. This looks more robust to me: > > SSHD_FUNCTIONS="" > for i in \ > /etc/init.d/sshd-functions \ > /etc/rc.d/init.d/sshd-functions \ > ; do > if [ -f "${i}" ]; then > SSHD_FUNCTIONS="${i}" > . "${SSHD_FUNCTIONS}" > break > fi > done > if [ -z "${SSHD_FUNCTIONS}" -o $? -ne 0 ]; then > exit 1 > fi > > But it's rather complex. Even this would be acceptable: > > if [ -f /etc/init.d/sshd-functions ]; then > . /etc/init.d/sshd-functions > else > . /etc/rc.d/init.d/sshd-functions > fi > if [ $? -ne 0 ]; then > exit 1 > fi IMO this is rather unnecessary thing to worry about yet. /etc/rc.d/init.d work just great too, because of symlinks. Those aren't going to be removed any time soon I think. No need to make this more complex than we have to. > The problem is with redefining the stock functions is that success() > and failure() work slightly differently than the equivalent actions for > RHL <= 5.2. > > That's why the my_success() and my_failure() functions i defined take > an optional second argument, to make them Act The Right Way(R) for all > RH releases. In RHL-6.2, success() and failure() only care about their > first argument ($1), and it , but there's no guarantee that Red Hat > won't change the functions in the future. Using our own functions > avoids that potential problem. It'd appear to me that your success()/failure() work differently from my proposal only if success/failure haven't been provided by initscripts at all. My concern is this: I wouldn't like a huge amount of development work going into versions only very few people use. There should be some sane limit of backward compatibility. That is, I'd like to be able to state: At the moment, we only support Red Hat Linux 6.x (all errata installed) and Red Hat Linux 7.x (all errata installed). And when a new feature is added, I wouldn't like to have to consider what might happen with a 3-year old system, where RPM is ancient, initscripts doesn't support anything, etc. Backward compatibility is OK, but 1) it shouldn't affect "currently supported" versions 2) it should be transparent That is why I'd prefer redefinitions of "echo", "success" etc. functions rather than new functions; those that have recent versions shouldn't use these at all (there are always issues; what will happen if you want to pass e.g. ssh-keygen -N '' to action or the like; you would be amazed at the number of \'s required..) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From pekkas at netcore.fi Sun Feb 18 07:17:07 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 17 Feb 2001 22:17:07 +0200 (EET) Subject: PATCH: make contrib/redhat/sshd.init work with older RH releases In-Reply-To: <20010217133459.E25687@quipu.half.pint-stowp.cx> Message-ID: On Sat, 17 Feb 2001, Jim Knoble wrote: > I think it would be better to call the start() and stop() functions by > more specific names to avoid potential namespace conflict. Any of > these would be better (i myself prefer the second): > > - start_sshd, stop_sshd > - sshd_start, sshd_stop > - start_ssh, stop_ssh > - ssh_start, ssh_stop > > In fact, i would suggest prefixing all function names defined here with > 'sshd_' or 'ssh_'. This is not a common practice among RH init scripts, and IMO we shouldn't worry about this. It's not like init.d/sshd is being sourced into other files where this might matter (ie: this will only come up if RH adds start/stop functions to initscripts) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From pekkas at netcore.fi Sun Feb 18 07:34:26 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 17 Feb 2001 22:34:26 +0200 (EET) Subject: dealing with RH initscripts backward compatibility In-Reply-To: <20010217133459.E25687@quipu.half.pint-stowp.cx> Message-ID: Hello all, Continuing the thread: Re: PATCH: make contrib/redhat/sshd.init work with older RH releases Attached are newer versions of initscripts. These are smaller and probably more readable than patches. Backward compability features haven't been tested that extensively. I think the issue of legacy initscripts support should be handled like with these patches (sshd-functions could be refined, of course), or in addition: * in openssh.spec, there would be a %define to enable "backward compability". There might even be autodetection for this using /etc/redhat-release. * with this defined, sshd-functions would be taken from contrib and installed in /etc/rc.d/init.d/. * this would give the implementor of sshd-functions more liberty at how he could redefine echo/failure/success/action/etc., because he would know that the changes would only kick in for users using RHL5.2 or earlier [currently] With this, there might be no need for the "do we require this" -checks (~30 first lines of sshd-functions). What do you think? IMO, I think the new idea is probably better because it allows for more freedom when it comes to the implementation. Also, there are other issues that will be version-specific (pam, ...). I could hack the spec file do that. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------- next part -------------- #!/bin/bash # # Init file for OpenSSH server daemon # # chkconfig: 2345 55 25 # description: OpenSSH server daemon # # processname: sshd # config: /etc/ssh/ssh_host_key # config: /etc/ssh/ssh_host_key.pub # config: /etc/ssh/ssh_random_seed # config: /etc/ssh/sshd_config # pidfile: /var/run/sshd.pid # source function library . /etc/rc.d/init.d/functions # source initscripts backward compatibility functions if they exist if [ -r /etc/rc.d/init.d/sshd-functions ]; then . /etc/rc.d/init.d/sshd-functions fi RETVAL=0 prog="sshd" # Some functions to make the below more readable KEYGEN=/usr/bin/ssh-keygen SSHD=/usr/sbin/sshd RSA1_KEY=/etc/ssh/ssh_host_key RSA_KEY=/etc/ssh/ssh_host_rsa_key DSA_KEY=/etc/ssh/ssh_host_dsa_key PID_FILE=/var/run/sshd.pid start() { # Create keys if necessary do_rsa1_keygen do_rsa_keygen do_dsa_keygen action $"Starting $prog: " $SSHD RETVAL=$? [ "$RETVAL" = 0 ] && touch /var/lock/subsys/sshd } stop() { echo -n $"Stopping $prog: " killproc $SSHD RETVAL=$? echo [ "$RETVAL" = 0 ] && rm -f /var/lock/subsys/sshd } do_rsa1_keygen() { if [ ! -s $RSA1_KEY ]; then echo -n $"Generating SSH1 RSA host key: " if $KEYGEN -q -t rsa1 -f $RSA1_KEY -C '' -N '' >&/dev/null; then success $"RSA1 key generation" echo else failure $"RSA1 key generation" echo exit 1 fi fi } do_rsa_keygen() { if [ ! -s $RSA_KEY ]; then echo -n $"Generating SSH2 RSA host key: " if $KEYGEN -q -t rsa -f $RSA_KEY -C '' -N '' >&/dev/null; then success $"RSA key generation" echo else failure $"RSA key generation" echo exit 1 fi fi } do_dsa_keygen() { if [ ! -s $DSA_KEY ]; then echo -n "Generating SSH2 DSA host key: " if $KEYGEN -q -t dsa -f $DSA_KEY -C '' -N '' >&/dev/null; then success "DSA key generation" echo else failure "DSA key generation" echo exit 1 fi fi } case "$1" in start) start ;; stop) stop ;; restart) stop start ;; reload) echo -n $"Reloading $prog: " killproc $SSHD -HUP RETVAL=$? echo ;; condrestart) if [ -f /var/lock/subsys/sshd ] ; then stop start fi ;; status) status $SSHD RETVAL=$? ;; *) echo $"Usage: $0 {start|stop|restart|reload|condrestart|status}" RETVAL=1 esac exit $RETVAL -------------- next part -------------- # Backward compability functions for initscripts, parts by Red Hat. # Find out whether we need to use the local functions # Unnecessary use should be avoided. if [ ! "`type -type success`" = "function" ]; then success() { my_success "$*" } fi if [ ! "`type -type failure`" = "function" ]; then failure() { my_failure "$*" } fi if [ ! "`type -type action`" = "function" ]; then action() { my_action "$*" } fi case "${BASH_VERSION}" in 1.*) echo() { my_echo "$*" } ;; esac # Required for old initscripts < 4.16 or so (RHL5.2) my_success() { local msg if [ $# -gt 1 ]; then msg="$2" else msg="done" fi case "`type -type success`" in function) success "$1" ;; *) echo -n "${msg}" ;; esac } # Required for old initscripts < 4.16 or so (RHL5.2) my_failure() { local msg if [ $# -gt 1 ]; then msg="$2" else msg="FAILED" fi case "`type -type failure`" in function) failure "$1" ;; *) echo -n "${msg}" ;; esac } # Required for old initscripts < 4.16 or so (RHL5.2) my_action() { STRING=$1 echo -n "$STRING " shift "$*" && success "$STRING" || failure "$STRING" rc=$? echo return $rc } # Required for bash1 (RHL6.2 if bash2 package not installed) my_echo() { local args="" while [ $# -gt 0 ]; do case "$1" in --) break ;; -*) args="${args} $1" shift ;; *) break ;; esac done case "${BASH_VERSION}" in 1.*) echo ${args} "$@" ;; *) echo ${args} $"$@" ;; esac } -------------- next part -------------- --- openssh.spec.orig Sat Feb 17 21:56:43 2001 +++ ossh Sat Feb 17 21:59:23 2001 @@ -194,6 +194,7 @@ %else install -m644 contrib/redhat/sshd.pam-7.x $RPM_BUILD_ROOT/etc/pam.d/sshd %endif +install -m644 contrib/redhat/sshd-functions $RPM_BUILD_ROOT/etc/rc.d/init.d/sshd-functions install -m755 contrib/redhat/sshd.init $RPM_BUILD_ROOT/etc/rc.d/init.d/sshd %if ! %{no_x11_askpass} @@ -261,6 +262,7 @@ %attr(0600,root,root) %config(noreplace) %{_sysconfdir}/sshd_config %attr(0600,root,root) %config(noreplace) /etc/pam.d/sshd %attr(0755,root,root) %config /etc/rc.d/init.d/sshd +%attr(0644,root,root) %config /etc/rc.d/init.d/sshd-functions %if ! %{no_x11_askpass} %files askpass From gert at greenie.muc.de Sun Feb 18 07:45:15 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 17 Feb 2001 21:45:15 +0100 Subject: OpenSSH 2.5.0p1 In-Reply-To: ; from mouring@etoh.eviladmin.org on Sat, Feb 17, 2001 at 11:17:05AM -0600 References: Message-ID: <20010217214515.A12395@greenie.muc.de> Hi, On Sat, Feb 17, 2001 at 11:17:05AM -0600, mouring at etoh.eviladmin.org wrote: > However I know there was a reason for us -L$ssldir and -L$ssldir/lib. And > I would rather see a solution that keeps both tests in place if possible. The double "-L" breaks the linker on SCO 3.0 (too many -L). Why not really *check* the -L path for "$ssldir/(lib/)?libcrypto.a", and use only the directory where it can be found? 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 Feb 18 07:47:28 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 17 Feb 2001 21:47:28 +0100 Subject: Name change In-Reply-To: ; from Jacek Pliszka on Sat, Feb 17, 2001 at 04:01:41PM +0100 References: Message-ID: <20010217214728.B12395@greenie.muc.de> Hi, On Sat, Feb 17, 2001 at 04:01:41PM +0100, Jacek Pliszka wrote: > I am sorry if I am senidng it an incorrect place. > > I heard about problems with ssh trademark. If it is not solve > I propose name change to osh (Open Shell) or orsh (Open Remote Shell). I don't like that. There's nothing special about having an "open" shell, or an "remote" shell - the thing that's special is that it's "secure". I'd just stick to OpenSSH. But then it's most likely upon Damien and Markus to decide whether they want to risk having lawyers upon their backs. 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 janfrode at parallab.uib.no Sun Feb 18 07:47:33 2001 From: janfrode at parallab.uib.no (Jan-Frode Myklebust) Date: Sat, 17 Feb 2001 21:47:33 +0100 Subject: snapshot sftpserver Message-ID: <20010217214733.A12145@ii.uib.no> I'm having some problems with the sftpserver from yesterdays snapshot. It's working fine on the machine I built it on, but the (supposedly) identical machines I rdisted it to fails (SGI O2, Irix 6.5.11m). The client says: % sftp buskfuru Connecting to buskfuru... Enter passphrase for key '/usr/people/jfm/.ssh/id_dsa': janfrode at buskfuru's password: Received message too long 1466004078 and 'sshd -d' tells me: debug1: sshd version OpenSSH_2.3.2p1 debug1: load_private_key_autodetect: type 0 RSA1 debug1: read SSH2 private key done: name dsa w/o comment success 1 debug1: load_private_key_autodetect: type 2 DSA debug1: Seeded RNG with 32 bytes from programs debug1: Seeded RNG with 3 bytes from system calls 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: Seeded RNG with 32 bytes from programs debug1: Seeded RNG with 3 bytes from system calls RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 129.177.20.36 port 2355 debug1: Client protocol version 2.0; client software version OpenSSH_2.3.2p1 debug1: match: OpenSSH_2.3.2p1 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_2.3.2p1 debug1: Rhosts Authentication disabled, originating port not trusted. debug1: list_hostkey_types: ssh-dss debug1: send KEXINIT debug1: done debug1: wait KEXINIT debug1: got kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug1: got kexinit: ssh-rsa,ssh-dss debug1: got kexinit: 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,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug1: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug1: got kexinit: none debug1: got kexinit: none debug1: got kexinit: debug1: got kexinit: debug1: first kex follow: 0 debug1: reserved: 0 debug1: done debug1: kex: client->server 3des-cbc hmac-sha1 none debug1: kex: server->client 3des-cbc hmac-sha1 none debug1: Wait SSH2_MSG_KEX_DH_GEX_REQUEST. debug1: Sending SSH2_MSG_KEX_DH_GEX_GROUP. debug1: bits set: 991/2049 debug1: Wait SSH2_MSG_KEX_DH_GEX_INIT. debug1: bits set: 1041/2049 debug1: sig size 20 20 debug1: send SSH2_MSG_NEWKEYS. debug1: done: send SSH2_MSG_NEWKEYS. debug1: Wait SSH2_MSG_NEWKEYS. debug1: GOT SSH2_MSG_NEWKEYS. debug1: done: KEX2. debug1: userauth-request for user janfrode service ssh-connection method none debug1: attempt 0 failures 0 Failed none for janfrode from 129.177.20.36 port 2355 ssh2 debug1: userauth-request for user janfrode service ssh-connection method password debug1: attempt 1 failures 1 Accepted password for janfrode from 129.177.20.36 port 2355 ssh2 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 32768 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 channel 0 request subsystem reply 1subsystem request for sftp debug1: subsystem: exec() /usr/openssh/libexec/sftp-server debug1: fd 9 setting O_NONBLOCK debug1: fd 9 IS O_NONBLOCK debug1: channel 0: rcvd eof debug1: channel 0: output open -> drain debug1: channel 0: obuf empty debug1: channel 0: output drain -> closed debug1: channel 0: close_write debug1: Received SIGCHLD. debug1: session_by_pid: pid 30778 debug1: session_exit_message: session 0 channel 0 pid 30778 debug1: session_exit_message: release channel 0 debug1: session_free: session 0 pid 30778 debug1: channel 0: read<=0 rfd 9 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 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 9/9) Connection closed by remote host. debug1: Calling cleanup 0x10043a30(0x0) debug1: Calling cleanup 0x1004e2d0(0x0) debug1: Calling cleanup 0x1004af80(0x0) debug1: writing PRNG seed to file //.ssh/prng_seed If I try to connect with sftp from ssh.com it says: % sftp buskfuru janfrode at bruse's password: sftp> Warning: ssh_packet_wrapper_input: invalid packet received: len 1466004082 closing the offending input channel. Any idea what's failing here? -jf From Jacek.Pliszka at fuw.edu.pl Sun Feb 18 08:40:28 2001 From: Jacek.Pliszka at fuw.edu.pl (Jacek Pliszka) Date: Sat, 17 Feb 2001 22:40:28 +0100 (CET) Subject: Name change In-Reply-To: <20010217214728.B12395@greenie.muc.de> Message-ID: Hi! On Sat, 17 Feb 2001, Gert Doering wrote: > I don't like that. There's nothing special about having an "open" shell, > or an "remote" shell - the thing that's special is that it's "secure". Well there is. Among all other ssh programs this is the one which Open. Of course the first quesion is whether one should be allowed to patent protocol names. I do not think so. Though, just in case, I sent my proposition. Best Regards, Jacek P.S. In addition, if name has changed, I think people would follow OpenSSH new name and SSH will loose it's value. From pekkas at netcore.fi Sun Feb 18 08:49:20 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 17 Feb 2001 23:49:20 +0200 (EET) Subject: [patch]: README and INSTALL fixes Message-ID: Hello all, I happened to glance through README/INSTALL quickly and noticed some things that have changed. There's probably more. Everything listed in the patch might not be really necessary. ssh-keygen parameters is something that should be changed, at least. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------- next part -------------- --- openssh/INSTALL Sat Feb 17 23:24:39 2001 +++ openssh.new/INSTALL Sat Feb 17 23:30:35 2001 @@ -9,7 +9,9 @@ OpenSSL 0.9.5a or greater: http://www.openssl.org/ -RPMs of OpenSSL are available at http://violet.ibs.com.au/openssh/files/support +RPMs of OpenSSL are available at http://violet.ibs.com.au/openssh/files/support. +For Red Hat Linux 6.2, they have been released as errata. RHL7 includes +these. OpenSSH can utilise Pluggable Authentication Modules (PAM) if your system supports it. PAM is standard on Redhat and Debian Linux, Solaris and @@ -93,7 +95,7 @@ control file as "/etc/pam.d/sshd" (or wherever your system prefers to keep them). A generic PAM configuration is included as "contrib/sshd.pam.generic", you may need to edit it before using it on -your system. If you are using a recent version of Redhat Linux, the +your system. If you are using a recent version of Red Hat Linux, the config file in contrib/redhat/sshd.pam should be more useful. Failure to install a valid PAM file may result in an inability to use password authentication. On HP-UX 11, the standard /etc/pam.conf @@ -107,8 +109,7 @@ may need to specify this option if rsh is not in your path or has a different name. ---without-pam will disable PAM support. PAM is automatically detected -and switched on if found. +--with-pam enables PAM support. --enable-gnome-askpass will build the GNOME passphrase dialog. You need a working installation of GNOME, including the development @@ -194,8 +195,9 @@ To generate a host key, run "make host-key". Alternately you can do so manually using the following commands: - ssh-keygen -b 1024 -f /etc/ssh/ssh_host_key -N "" - ssh-keygen -d -f /etc/ssh/ssh_host_dsa_key -N "" + ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N "" + ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N "" + ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N "" Replacing /etc/ssh with the correct path to the configuration directory. (${prefix}/etc or whatever you specified with --sysconfdir during --- openssh/README Sat Feb 17 23:43:07 2001 +++ openssh.new/README Fri Feb 9 16:56:34 2001 @@ -33,8 +33,8 @@ openssh-unix-dev at mindrot.org. The list is open to posting by unsubscribed users. -If you are a citizen of the USA or another country which restricts -export of cryptographic products, then please refrain from sending +If you are a citizen of an USA-embargoed country to which export of +cryptographic products is restricted, then please refrain from sending crypto-related code or patches to the list. We cannot accept them. Other code contribution are accepted, but please follow the OpenBSD style guidelines[6]. From djm at web.us.uu.net Sun Feb 18 09:58:38 2001 From: djm at web.us.uu.net (David J. MacKenzie) Date: Sat, 17 Feb 2001 17:58:38 -0500 Subject: OpenSSH 2.3.0p1 port to BSDI BSD/OS In-Reply-To: Message from Markus Friedl of "Sat, 17 Feb 2001 21:03:43 +0100." <20010217210342.A10098@folly> Message-ID: <20010217225838.5420612685@jenkins.web.us.uu.net> > could you please try this, does kerberos+password work? > does skey work? does user:style work with challenge- > reposnse in ssh1 and ssh2? I actually stopped using S/Key when ssh became prevalent, so I don't have it set up any more. However, the auth style stuff now works for passwd and krb5. The error message for approval is wrong, though. auth_approval() does not set errno, so it produces this sort of message: djm at air 397 $ ssh catapult djm at catapult's password: Approval failure: Undefined error: 0 Connection to catapult closed. It looks like you should be using error() instead of perror(). > Index: session.c > --- session.c 2001/02/16 14:03:43 1.56 > +++ session.c 2001/02/16 21:15:54 > @@ -837,8 +833,13 @@ > (LOGIN_SETALL & ~LOGIN_SETPATH)) < 0) { > perror("unable to set user context"); > exit(1); > - > } > +#ifdef BSD_AUTH > + if (auth_approval(NULL, lc, pw->pw_name, "auth-ssh") <= 0) { > + perror("Approval failure"); > + exit(1); > + } > +#endif > #else > if (setlogin(pw->pw_name) < 0) > error("setlogin failed: %s", strerror(errno)); From tim at multitalents.net Sun Feb 18 10:29:49 2001 From: tim at multitalents.net (Tim Rice) Date: Sat, 17 Feb 2001 15:29:49 -0800 (PST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Fri, 16 Feb 2001 mouring at etoh.eviladmin.org wrote: > > Yes I did test it. It worked fine under Linux. However I did not get any > chance to test it under anything else. Before running ou the door. > > I never needed --src-dir to compile in a different location. But if that > is needed then we should set the right -I via that if we can. Because we > have other issues that are more hidden (pty.h and openpty() call). > > Tim, > > The choice is either we ignore AIX or we stop the default behavior of > building out of the tree. Where the latter is anonying the form is > unacceptable. I'm not convinced we can't have both. Many projects build in and out of the source tree. Unfornatuly I don't have AIX here. (Maybe it's time to pick up an old RS6000) Can anyone provide me with ssh access to an AIX machine to look into this? > > - Ben > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From markus.friedl at informatik.uni-erlangen.de Sun Feb 18 10:31:25 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sun, 18 Feb 2001 00:31:25 +0100 Subject: OpenSSH 2.3.0p1 port to BSDI BSD/OS In-Reply-To: <20010217225838.5420612685@jenkins.web.us.uu.net>; from djm@web.us.uu.net on Sat, Feb 17, 2001 at 05:58:38PM -0500 References: <20010217225838.5420612685@jenkins.web.us.uu.net> Message-ID: <20010218003125.B28973@folly> On Sat, Feb 17, 2001 at 05:58:38PM -0500, David J. MacKenzie wrote: > > > could you please try this, does kerberos+password work? > > does skey work? does user:style work with challenge- > > reposnse in ssh1 and ssh2? > > I actually stopped using S/Key when ssh became prevalent, so I don't > have it set up any more. However, the auth style stuff now works > for passwd and krb5. > > The error message for approval is wrong, though. auth_approval() > does not set errno, so it produces this sort of message: > > djm at air 397 $ ssh catapult > djm at catapult's password: > Approval failure: Undefined error: 0 > Connection to catapult closed. > > It looks like you should be using error() instead of perror(). ok, it does now: if (auth_approval(NULL, lc, pw->pw_name, "auth-ssh") <= 0) { error("approval failure for %s", pw->pw_name); fprintf(stderr, "Approval failure"); exit(1); } error() for the log, fprintf for the user. anything else? From jones at hpc.utexas.edu Sun Feb 18 10:39:35 2001 From: jones at hpc.utexas.edu (William L. Jones) Date: Sat, 17 Feb 2001 17:39:35 -0600 Subject: Small aix patch to configure.in Message-ID: <4.2.0.58.20010217161918.01ccc980@127.0.0.1> The following aix patch to configure.in forces /usr/include to be searched before /usr/local/include on AIX systems only. This allows the normal include rules to untangle from "login.h" on AIX when using the AIX cc compiler or gcc. Please see that it gets applied to the current cvs source tree. It fixes the only compile time error the current cvs tree has on aix with out reaming the "login.h" include file. Bill Jones --- configure.in.orig Sat Feb 17 16:18:02 2001 +++ configure.in Sat Feb 17 16:26:06 2001 @@ -50,7 +50,7 @@ case "$host" in *-*-aix*) AFS_LIBS="-lld" - CPPFLAGS="$CPPFLAGS -I/usr/local/include" + CPPFLAGS="$CPPFLAGS -I/usr/include -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib" if (test "$LD" != "gcc" && test -z "$blibpath"); then blibpath="/usr/lib:/lib:/usr/local/lib" From markus.friedl at informatik.uni-erlangen.de Sun Feb 18 10:59:40 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sun, 18 Feb 2001 00:59:40 +0100 Subject: terminate on re-key request (patch) In-Reply-To: ; from aspa@kronodoc.fi on Sat, Feb 17, 2001 at 01:34:59PM +0200 References: Message-ID: <20010218005940.C10098@folly> On Sat, Feb 17, 2001 at 01:34:59PM +0200, Marko Asplund wrote: > On Sat, 17 Feb 2001, Pekka Savola wrote: > > > On Sat, 17 Feb 2001, Marko Asplund wrote: > > > here's a small patch for making OpenSSH v2.3.0p1 client gracefully > > > terminate the SSH2 connection when it receives a key re-exchange request > > > from the server. the patch has been tested against SSH's v2.3.0 server on > > > linux. > > > > Better (AFAIS) patch is already in there: > > ... > > it doesn't seem to be working for me. OpenSSH client just says 'Hm, > dispatch protocol error: type 20 plen 136' and the connection hangs when > SSH's server sends a re-key request. this is the same behaviour as without > the patch. well, you run openssh-2.3 and my change is in openssh-2.5 > is anyone working on re-key support, by the way? it's on my todo list. almost on the top. From tim at multitalents.net Sun Feb 18 11:07:33 2001 From: tim at multitalents.net (Tim Rice) Date: Sat, 17 Feb 2001 16:07:33 -0800 (PST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Kevin Steves wrote: > On Fri, 16 Feb 2001, Tim Rice wrote: > : Attached is a patch that fixes SCO Open Server 3 > > this means that SCO has sigaction() but no SA_RESTART flag? That's right. > > --- openssh_cvs/misc.c.old Fri Feb 16 18:15:19 2001 > +++ openssh_cvs/misc.c Fri Feb 16 19:07:03 2001 > @@ -108,8 +108,10 @@ > memset(&sa, 0, sizeof sa); > sigemptyset(&sa.sa_mask); > sa.sa_flags = 0; > +#ifdef SA_RESTART > if (sig == SIGCHLD) > sa.sa_flags |= SA_RESTART; > +#endif > sa.sa_handler = act; > if (sigaction(sig, &sa, 0) == -1) > return (mysig_t) -1; > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From markus.friedl at informatik.uni-erlangen.de Sun Feb 18 11:07:09 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sun, 18 Feb 2001 01:07:09 +0100 Subject: snapshot sftpserver In-Reply-To: <20010217214733.A12145@ii.uib.no>; from janfrode@parallab.uib.no on Sat, Feb 17, 2001 at 09:47:33PM +0100 References: <20010217214733.A12145@ii.uib.no> Message-ID: <20010218010709.D10098@folly> On Sat, Feb 17, 2001 at 09:47:33PM +0100, Jan-Frode Myklebust wrote: > % sftp buskfuru > Connecting to buskfuru... > Enter passphrase for key '/usr/people/jfm/.ssh/id_dsa': > janfrode at buskfuru's password: > Received message too long 1466004078 > % sftp buskfuru > janfrode at bruse's password: > sftp> Warning: ssh_packet_wrapper_input: invalid packet received: len > 1466004082 closing the offending input channel. > > Any idea what's failing here? you probably have broken .bashrc or whatever files, they should never every print to stdout if the shell is not interactive. From pekkas at netcore.fi Sun Feb 18 11:28:12 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 18 Feb 2001 02:28:12 +0200 (EET) Subject: Small aix patch to configure.in In-Reply-To: <4.2.0.58.20010217161918.01ccc980@127.0.0.1> Message-ID: On Sat, 17 Feb 2001, William L. Jones wrote: > The following aix patch to configure.in forces /usr/include to be searched > before /usr/local/include on AIX systems only. This allows the normal > include rules to untangle from "login.h" on AIX when using the AIX > cc compiler or gcc. Please see that it gets applied to the current cvs > source tree. It fixes the only compile time error the current cvs tree has > on aix with out reaming the "login.h" include file. Confirmed. This is necessary to build. OpenSSH configured has been configured with the following options. User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /usr/local/etc Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/man/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: rs6000-ibm-aix4.3.1.0 Compiler: gcc Compiler flags: -g -O2 -Wall Preprocessor flags: -I/usr/local/include -I/v/aix43_rs/comm/openssl/latest//include Linker flags: -L/usr/local/lib -Llibz/ -L/v/aix43_rs/comm/openssl/latest//lib -L/v/aix43_rs/comm/openssl/latest/ Libraries: -lz -lnsl -lcrypto Else you get: --- auth.c: In function `allowed_user': auth.c:145: warning: implicit declaration of function `loginrestrictions' auth.c:145: `S_RLOGIN' undeclared (first use in this function) auth.c:145: (Each undeclared identifier is reported only once auth.c:145: for each function it appears in.) --- Also, if someone is interested in warnings, I took down a few: --- channels.c: In function `channel_post_connecting': channels.c:719: warning: passing arg 5 of `getsockopt' from incompatible pointer type cipher.c: In function `cipher_by_name': cipher.c:440: warning: implicit declaration of function `strcasecmp' packet.c: In function `packet_read': packet.c:687: warning: implicit declaration of function `bzero' entropy.c: In function `init_rng': entropy.c:812: warning: implicit declaration of function `seteuid' uuencode.c: In function `uuencode': uuencode.c:37: warning: implicit declaration of function `b64_ntop' uuencode.c: In function `uudecode': uuencode.c:55: warning: implicit declaration of function `b64_pton' auth.c: In function `allowed_user': auth.c:145: warning: implicit declaration of function `loginrestrictions' auth2.c: In function `userauth_reply': auth2.c:297: warning: implicit declaration of function `loginsuccess' auth2.c:298: warning: implicit declaration of function `get_canonical_hostname' auth-passwd.c: In function `auth_password': auth-passwd.c:138: warning: implicit declaration of function `authenticate' auth-passwd.c:105: warning: unused variable `loginmsg' In file included from session.c:72: /usr/include/usersec.h:593: warning: `struct aud_rec' declared inside parameter list /usr/include/usersec.h:593: warning: its scope is only this definition or declaration, which is probably not what you want. /usr/include/usersec.h:594: warning: `struct aud_rec' declared inside parameter list session.c: In function `do_child': session.c:1082: warning: implicit declaration of function `initgroups' --- [ a lot of duplicates esp strcasecomp deleted ] I just compiled, didn't try the client/server itself. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From Todd.Miller at courtesan.com Sun Feb 18 12:02:59 2001 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Sat, 17 Feb 2001 18:02:59 -0700 Subject: OpenSSH 2.5.0p1 vs. SA_RESTART Message-ID: <200102180103.f1I130I03344@xerxes.courtesan.com> Not all OSes have SA_RESTART (for instance, SunOS does not). Also, for the non-SA_RESTART case in scp.c sa.sa_flags was not being initialized (noted by dworkin at village.org). - todd --- scp.c.DIST Sat Feb 17 17:56:33 2001 +++ scp.c Sat Feb 17 17:57:59 2001 @@ -1224,8 +1224,9 @@ struct sigaction sa; sa.sa_handler = updateprogressmeter; sigemptyset((sigset_t *)&sa.sa_mask); + sa.sa_flags = 0; #ifdef SA_RESTART - sa.sa_flags = SA_RESTART; + sa.sa_flags |= SA_RESTART; #endif sigaction(SIGALRM, &sa, NULL); alarmtimer(1); --- misc.c.DIST Fri Feb 16 07:58:12 2001 +++ misc.c Sat Feb 17 17:59:53 2001 @@ -108,8 +108,10 @@ memset(&sa, 0, sizeof sa); sigemptyset(&sa.sa_mask); sa.sa_flags = 0; +#ifdef SA_RESTART if (sig == SIGCHLD) sa.sa_flags |= SA_RESTART; +#endif sa.sa_handler = act; if (sigaction(sig, &sa, 0) == -1) return (mysig_t) -1; From jmknoble at jmknoble.cx Sun Feb 18 12:06:27 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Sat, 17 Feb 2001 20:06:27 -0500 Subject: PATCH: make contrib/redhat/sshd.init work with older RH releases In-Reply-To: ; from pekkas@netcore.fi on Sat, Feb 17, 2001 at 10:14:37PM +0200 References: <20010217141410.F25687@quipu.half.pint-stowp.cx> Message-ID: <20010217200627.I25687@quipu.half.pint-stowp.cx> Circa 2001-Feb-17 22:14:37 +0200 dixit Pekka Savola: : On Sat, 17 Feb 2001, Jim Knoble wrote: : > Remember also that in RHL-7.0 (and in FHS >= 2.0), the location of : > 'init.d' changes. This looks more robust to me: [...] : IMO this is rather unnecessary thing to worry about yet. : /etc/rc.d/init.d work just great too, because of symlinks. Those : aren't going to be removed any time soon I think. No need to make : this more complex than we have to. I disagree. If you want to fix it properly at this time, this is exactly the sort of thing to worry about. Are you certain RH will leave the compatibility symlink in RHL-7.1? I'm not. If you don't want to worry about this sort of thing right now, then i suggest that we leave well enough alone and fix things properly in the release after v2.5.0. : > The problem is with redefining the stock functions is that success() : > and failure() work slightly differently than the equivalent actions for : > RHL <= 5.2. [...] : : It'd appear to me that your success()/failure() work differently from my : proposal only if success/failure haven't been provided by initscripts at : all. You are correct in saying that, if success() is defined, the following are equivalent: my_success "Something happened" "Something" success "Something happened" However, in order to do the right thing with your suggested method, we would have to do: success "Something happened" "Something" which, although equivalent to the two above right now, since RH's success() ignores $2, may not work in the future. We have no guarantee that it will work even for the next release. my_success(), on the other hand, is guaranteed to work in that instance. : My concern is this: I wouldn't like a huge amount of development work : going into versions only very few people use. There should be some sane : limit of backward compatibility. There is. I didn't ask for compatibility with Red Hat Linux 3.0.3 or 2.x. ;) And i've already done most of the necessary work; additional work is cosmetic. : That is, I'd like to be able to state: : : At the moment, we only support Red Hat Linux 6.x (all errata installed) : and Red Hat Linux 7.x (all errata installed). Why abandon folks who have boxes that have been working successfully for some time and have no pressing need to upgrade (other than the sort of attitude you appear to be displaying)? Red Hat Linux 5.2 is no more obsolete than, say, NeXTstep 3.x or 4.x, HP-UX-10.x, IRIX-5.x, SunOS-4.x, all of which are listed in configure.in. The solution i've proposed will work fine on Red Hat Linux 5.2, and coincidentally on 4.2 as well, without posing any additional troubles to 6.x, 7.0, or subsequent releases. : And when a new feature is added, I wouldn't like to have to consider : what might happen with a 3-year old system, where RPM is ancient, : initscripts doesn't support anything, etc. RPM shouldn't be ancient for RHL-5.2; the current recommended level is 3.0.5-9.5x, same as for RHL-6.2. Same for RHL-4.2. And regardless, specfiles are much less important to get backwardly compatible than initscripts, which (even though in ./contrib/) are much closer to being part of the software. : Backward compatibility is OK, but : 1) it shouldn't affect "currently supported" versions What i've done doesn't. : 2) it should be transparent What i've done is. my_success() works everywhere. What's the problem? And don't forget: 0) compatibility should be resistant to potential future changes. and: 3) it should be obvious what's been done to achieve compatibility. Calling my_success() makes it obvious to the onlooker that something besides success() is necessary in certain cases. Calling success() doesn't. : That is why I'd prefer redefinitions of "echo", "success" etc. : functions rather than new functions; Redefine echo with a function? Surely you must be joking. That's as bad an idea as C++'s operator overloading: If '+' doesn't add two numbers, then don't call it '+'; call it something else. : those that have recent versions shouldn't use these at all (there : are always issues; what will happen if you want to pass e.g. : ssh-keygen -N '' to action or the like; you would be amazed at the : number of \'s required..) Do we use action()? Last i checked (SNAP-2001-0216), we didn't. I hope we don't; it's not very robust, at least in RHL-6.x. In particular, initlog's handling of command arguments is poorly designed. -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From Todd.Miller at courtesan.com Sun Feb 18 12:06:02 2001 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Sat, 17 Feb 2001 18:06:02 -0700 Subject: OpenSSH 2.5.0p1 vs. SA_RESTART In-Reply-To: Your message of "Sat, 17 Feb 2001 18:02:59 MST." <200102180103.f1I130I03344@xerxes.courtesan.com> References: <200102180103.f1I130I03344@xerxes.courtesan.com> Message-ID: <200102180106.f1I162D05104@xerxes.courtesan.com> I see the misc.c problem has already been fixed. The scp.c one still remains in today's snap. - todd From jmknoble at jmknoble.cx Sun Feb 18 12:08:48 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Sat, 17 Feb 2001 20:08:48 -0500 Subject: PATCH: make contrib/redhat/sshd.init work with older RH releases In-Reply-To: ; from pekkas@netcore.fi on Sat, Feb 17, 2001 at 10:17:07PM +0200 References: <20010217133459.E25687@quipu.half.pint-stowp.cx> Message-ID: <20010217200848.J25687@quipu.half.pint-stowp.cx> Circa 2001-Feb-17 22:17:07 +0200 dixit Pekka Savola: : > In fact, i would suggest prefixing all function names defined here with : > 'sshd_' or 'ssh_'. : : This is not a common practice among RH init scripts, and IMO we shouldn't : worry about this. Perhaps we should take the initiative and give good example, then. : It's not like init.d/sshd is being sourced into other files where : this might matter (ie: this will only come up if RH adds start/stop : functions to initscripts) "This will only come up if this code is still running after 1999." "This will only come up if the file grows larger than 2GB." -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From tim at multitalents.net Sun Feb 18 12:24:53 2001 From: tim at multitalents.net (Tim Rice) Date: Sat, 17 Feb 2001 17:24:53 -0800 (PST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: > > I guess what needs to be asked... Is what needs to OCCUR in the next 3 > to 4 days to assure we have a stable project on majority of the platforms? Here is a 2 line patch to configure.in so SCO Open Server 3 will compile with the --with-tcp-wrappers option. > > - Ben > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- openssh_cvs/configure.in.old Fri Feb 16 18:15:18 2001 +++ openssh_cvs/configure.in Sat Feb 17 17:15:17 2001 @@ -324,6 +331,9 @@ AC_CHECK_LIB(socket, main, , ) fi +dnl SCO OS3 needs this for libwrap +AC_CHECK_LIB(rpc, innetgr, LIBS="-lrpc -lyp -lrpc $LIBS" , , -lyp -lrpc) + AC_CHECK_LIB(gen, getspnam, LIBS="$LIBS -lgen") AC_CHECK_LIB(z, deflate, ,AC_MSG_ERROR([*** zlib missing - please install first or check config.log ***])) AC_CHECK_LIB(util, login, AC_DEFINE(HAVE_LIBUTIL_LOGIN) LIBS="$LIBS -lutil") From djm at mindrot.org Sun Feb 18 12:31:12 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Feb 2001 12:31:12 +1100 (EST) Subject: OpenSSH 2.5.0p1 In-Reply-To: <20010217090122.A16740@cygbert.vinschen.de> Message-ID: On Sat, 17 Feb 2001, Corinna Vinschen wrote: > It helps solving the define problem but it doesn't solve the > non matching definition and declaration of binary_open. > > I have attached a new diff which includes your patch and > the patch changing the definition of binary_open. Applied - thanks. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sun Feb 18 12:32:08 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Feb 2001 12:32:08 +1100 (EST) Subject: Antigen found Unknown (?) virus In-Reply-To: Message-ID: On 17 Feb 2001 Antigen at mindrot.org wrote: > Antigen for Exchange found term_on_rekey_rq.patch infected with > Unknown (?) virus. The file is currently Detected. The message, > "terminate on re-key request (patch)", was sent from Marko > Asplund and was discovered in SMTP Messages\Inbound located at > Unknown/Unknown/MSMAIL. heh - I never knew diff files were infectious. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sun Feb 18 12:33:10 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Feb 2001 12:33:10 +1100 (EST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Kevin Steves wrote: > On Fri, 16 Feb 2001, Tim Rice wrote: > : Attached is a patch that fixes SCO Open Server 3 > > this means that SCO has sigaction() but no SA_RESTART flag? Do you have SA_INTERRUPT? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From pekkas at netcore.fi Sun Feb 18 12:35:54 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 18 Feb 2001 03:35:54 +0200 (EET) Subject: PATCH: make contrib/redhat/sshd.init work with older RH releases In-Reply-To: <20010217200627.I25687@quipu.half.pint-stowp.cx> Message-ID: On Sat, 17 Feb 2001, Jim Knoble wrote: > Circa 2001-Feb-17 22:14:37 +0200 dixit Pekka Savola: > : IMO this is rather unnecessary thing to worry about yet. > : /etc/rc.d/init.d work just great too, because of symlinks. Those > : aren't going to be removed any time soon I think. No need to make > : this more complex than we have to. > > I disagree. If you want to fix it properly at this time, this is > exactly the sort of thing to worry about. Are you certain RH will > leave the compatibility symlink in RHL-7.1? I'm not. Yes. It will be there. > Why abandon folks who have boxes that have been working successfully > for some time and have no pressing need to upgrade (other than the sort > of attitude you appear to be displaying)? Red Hat Linux 5.2 is no more > obsolete than, say, NeXTstep 3.x or 4.x, HP-UX-10.x, IRIX-5.x, > SunOS-4.x, all of which are listed in configure.in. For most of these platforms, only something like 'add /usr/local/sbin/sshd in your rc.local' is given. This is a more complex matter. Also, the pace at where Linux vs e.g. Solaris is developing is quite different. I don't think it's feasible to assume a Linux box installed 4 years ago will still be running non-upgraded; for commercial systems, this is probably rather commonplace. > The solution i've proposed will work fine on Red Hat Linux 5.2, and > coincidentally on 4.2 as well, without posing any additional troubles > to 6.x, 7.0, or subsequent releases. Well, it all boils down to this: do we want to diverge from RH init scripts? Adding all kinds of 'my_success' etc. functions push toward complely separate scripts. I don't like it from the maintainability point of view. If we want to support really old systems, it's probably better to just provide them a _very_ simple init script which would have worked even with RHL 3.0.3. No fuss, nothing to maintain. Better than using a lot of time verifying every new bell & whistle that'd appear in newer init scripts, backporting them into earlier versions and bloating what most people use. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From djm at mindrot.org Sun Feb 18 12:36:57 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Feb 2001 12:36:57 +1100 (EST) Subject: Important fix (sshd && binding). Portable version only. In-Reply-To: <20010217145428.A17425@ikar.t17.ds.pwr.wroc.pl> Message-ID: On Sat, 17 Feb 2001, Arkadiusz Miskiewicz wrote: > If bind() fails we _always_ should close socket. I sent this patch > while ago to djm but I still don't see this fix in openssh_cvs. I don't recall seeing this, but thanks - applied. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sun Feb 18 12:37:46 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Feb 2001 12:37:46 +1100 (EST) Subject: exit code weirdness in fatal() In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Pekka Savola wrote: > Hello all, > > I came across the following with the latest snapshot (and previous): > > (just trying to start sshd when it's already running) > > # ./sshd -d > [snip] > socket: Invalid argument > debug1: Bind to port 22 on 0.0.0.0. > fatal: Cannot bind any address. > # echo $? > 255 > > # ./sshd > # echo $? > 0 > > with './sshd', the same fatal message is printed to syslog. > > This seems critically wrong on systems that check what sshd's exit > status was to see if it should have started running without problems. This is because sshd has already daemonised by that point. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sun Feb 18 12:40:08 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Feb 2001 12:40:08 +1100 (EST) Subject: OpenSSH 2.5.0p1 In-Reply-To: <3A8E9C20.7330E90B@yk.rim.or.jp> Message-ID: On Sun, 18 Feb 2001, Ishikawa wrote: > > 7) Solaris '$PATH' issue -- ?? (Unfixable before 2.5.0?) [I'm getting > > more reports of this. I'll present them when they get their facts > > together] > > Attached is a memo that contains the debug output > when the problem is reproduced locally on our office machines. Could you send the output of a client logging into a 'sshd -d -d -d'? This will turn on dumping of the env vars that the server sets and we should also see what PAM is doing to the environment. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sun Feb 18 12:40:44 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Feb 2001 12:40:44 +1100 (EST) Subject: Important fix (sshd && binding). Portable version only. In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Kevin Steves wrote: > On Sat, 17 Feb 2001, Arkadiusz Miskiewicz wrote: > : If bind() fails we _always_ should close socket. I sent this patch while ago > : to djm but I still don't see this fix in openssh_cvs. > > i don't know why the test for !ai->ai_next was added? anyone? It was a workaround for bugs in Linux's IPv6 support. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From tim at multitalents.net Sun Feb 18 12:47:17 2001 From: tim at multitalents.net (Tim Rice) Date: Sat, 17 Feb 2001 17:47:17 -0800 (PST) Subject: SSH2 PATH problem In-Reply-To: Message-ID: On Fri, 16 Feb 2001, Damien Miller wrote: > On Thu, 15 Feb 2001, Tim Rice wrote: > > > > > # ssh -2 host 'echo $PATH' (force SSH2 protocol, PATH env var is not > > > > set) > > > > > > > > > > > > I can't execute a remote command with the SSH2 protocol. > > > > > > I can't replicate this here - can anyone else? > > > > I can. > > openssh-2.3.0p1 on Solaris 8 > > I can't immediatly see how this can happen :( The problem seems to be gone in SSH Version OpenSSH_2.5.0p1 > > Can you try running a "sshd -d -d -p 2222" and logging into it with > "ssh -p 2222"? I am interested in the output from the client. > > -d > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From djm at mindrot.org Sun Feb 18 12:44:41 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Feb 2001 12:44:41 +1100 (EST) Subject: OpenSSH 2.5.0p1 In-Reply-To: <200102171543.f1HFhGA22044@xerxes.courtesan.com> Message-ID: On Sat, 17 Feb 2001, Todd C. Miller wrote: > OpenSSH 2.5.0p1 should be more robust in the face of EGD problems > and deal with SIGPIPE gracefully. Below is a more self-contained > patch similar to the one I sent in before (and also similar to one > Lutz Jaenicke posted in the past). Thanks - applied -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sun Feb 18 12:51:20 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Feb 2001 12:51:20 +1100 (EST) Subject: Where is OpenSSH 2.5.0p1? In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Marek Michalkiewicz wrote: > One bug is only swapped tests for no_libsocket and no_libnsl. > The other bug looks more serious to me - quote from glibc manual: > > *Warning:* Using the `openpty' function with NAME not set to > `NULL' is *very dangerous* because it provides no protection > against overflowing the string NAME. You should use the `ttyname' > function on the file descriptor returned in *SLAVE to find out the > file name of the slave pseudo-terminal device instead. I think that you would have a hard time causing any trouble with this - you would have to have a pretty messed up system if the path to your tty was more than 64 chars. Both applied. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From tim at multitalents.net Sun Feb 18 12:56:55 2001 From: tim at multitalents.net (Tim Rice) Date: Sat, 17 Feb 2001 17:56:55 -0800 (PST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Sun, 18 Feb 2001, Damien Miller wrote: > On Sat, 17 Feb 2001, Kevin Steves wrote: > > > On Fri, 16 Feb 2001, Tim Rice wrote: > > : Attached is a patch that fixes SCO Open Server 3 > > > > this means that SCO has sigaction() but no SA_RESTART flag? > > Do you have SA_INTERRUPT? Not on SCO Not on UnixWare > > -d > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From djm at mindrot.org Sun Feb 18 12:53:19 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Feb 2001 12:53:19 +1100 (EST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Sat, 17 Feb 2001 mouring at etoh.eviladmin.org wrote: > If we did this I would perfer if Markus would provide the name for which > he plans on moving it to in the OpenBSD tree (including pty.h/pty.c). > Keeping trees in sync with different files names is not fun. =) I am awaiting his response to this. I would certainly prefer to rename the files, but I don't want the maintenance hassles if the OpenBSD tree doesn't change too :) -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sun Feb 18 12:56:38 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Feb 2001 12:56:38 +1100 (EST) Subject: snapshot sftpserver In-Reply-To: <20010217214733.A12145@ii.uib.no> Message-ID: On Sat, 17 Feb 2001, Jan-Frode Myklebust wrote: > > I'm having some problems with the sftpserver from yesterdays snapshot. It's > working fine on the machine I built it on, but the (supposedly) identical > machines I rdisted it to fails (SGI O2, Irix 6.5.11m). > > The client says: > > % sftp buskfuru What does "ssh buskfuru /bin/true" say? i.e do you have any shell initialisation which prints stuff for non-interactive shells. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sun Feb 18 12:58:15 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Feb 2001 12:58:15 +1100 (EST) Subject: [patch]: README and INSTALL fixes In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Pekka Savola wrote: > Hello all, > > I happened to glance through README/INSTALL quickly and noticed some > things that have changed. There's probably more. Everything listed in > the patch might not be really necessary. > > ssh-keygen parameters is something that should be changed, at least. Applied - thanks. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sun Feb 18 13:00:32 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Feb 2001 13:00:32 +1100 (EST) Subject: Small aix patch to configure.in In-Reply-To: Message-ID: On Sun, 18 Feb 2001, Pekka Savola wrote: > On Sat, 17 Feb 2001, William L. Jones wrote: > > The following aix patch to configure.in forces /usr/include > > to be searched before /usr/local/include on AIX systems only. > > This allows the normal include rules to untangle from > > "login.h" on AIX when using the AIX cc compiler or gcc. Please > > see that it gets applied to the current cvs source tree. It fixes > > the only compile time error the current cvs tree has on aix with > > out reaming the "login.h" include file. > > > > Confirmed. This is necessary to build. Unfortunately this breaks some systems whose /usr/include definitions of varargs differ from the gcc ones. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sun Feb 18 13:05:01 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Feb 2001 13:05:01 +1100 (EST) Subject: OpenSSH 2.5.0p1 vs. SA_RESTART In-Reply-To: <200102180103.f1I130I03344@xerxes.courtesan.com> Message-ID: On Sat, 17 Feb 2001, Todd C. Miller wrote: > Not all OSes have SA_RESTART (for instance, SunOS does not). > Also, for the non-SA_RESTART case in scp.c sa.sa_flags > was not being initialized (noted by dworkin at village.org). Can you give this a try? It uses SA_INTERRUPT, my copy of Stevens tells me this does the same thing on SunOS. Index: misc.c =================================================================== RCS file: /var/cvs/openssh/misc.c,v retrieving revision 1.9 diff -u -r1.9 misc.c --- misc.c 2001/02/17 17:10:16 1.9 +++ misc.c 2001/02/18 02:03:36 @@ -112,6 +112,10 @@ if (sig == SIGCHLD) sa.sa_flags |= SA_RESTART; #endif +#ifdef SA_INTERRUPT + if (sig == SIGCHLD) + sa.sa_flags |= SA_INTERRUPT; +#endif sa.sa_handler = act; if (sigaction(sig, &sa, NULL) == -1) return (mysig_t) -1; Index: scp.c =================================================================== RCS file: /var/cvs/openssh/scp.c,v retrieving revision 1.54 diff -u -r1.54 scp.c --- scp.c 2001/02/11 14:19:40 1.54 +++ scp.c 2001/02/18 02:03:36 @@ -1224,8 +1224,12 @@ struct sigaction sa; sa.sa_handler = updateprogressmeter; sigemptyset((sigset_t *)&sa.sa_mask); + sa.sa_flags = 0; #ifdef SA_RESTART - sa.sa_flags = SA_RESTART; + sa.sa_flags |= SA_RESTART; +#endif +#ifdef SA_INTERRUPT + sa.sa_flags |= SA_INTERRUPT; #endif sigaction(SIGALRM, &sa, NULL); alarmtimer(1); -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sun Feb 18 13:09:00 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Feb 2001 13:09:00 +1100 (EST) Subject: SSH2 PATH problem In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Tim Rice wrote: > > I can't immediatly see how this can happen :( > > The problem seems to be gone in SSH Version OpenSSH_2.5.0p1 Can other people confirm this? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sun Feb 18 13:11:18 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Feb 2001 13:11:18 +1100 (EST) Subject: Important fix (sshd && binding). Portable version only. In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Kevin Steves wrote: > i don't have ipv6 configs to experiment with, but i do not agree with a > change that drops valid error messages and logs erroneous success > messages. > > i would like to sync with openbsd. can you come up with a patch that > would be accepted in their tree that will log acceptably on all > platforms? I think we should sync with OpenBSD - this problem is specific to Linux IPv6 (which is rare) and can be worked around by being careful with ListenAddress. We may need to ship a config with "ListenAddress 0.0.0.0" though. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From pekkas at netcore.fi Sun Feb 18 13:12:19 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 18 Feb 2001 04:12:19 +0200 (EET) Subject: Small aix patch to configure.in In-Reply-To: Message-ID: On Sun, 18 Feb 2001, Damien Miller wrote: > On Sun, 18 Feb 2001, Pekka Savola wrote: > > > On Sat, 17 Feb 2001, William L. Jones wrote: > > > The following aix patch to configure.in forces /usr/include > > > to be searched before /usr/local/include on AIX systems only. > > > This allows the normal include rules to untangle from > > > "login.h" on AIX when using the AIX cc compiler or gcc. Please > > > see that it gets applied to the current cvs source tree. It fixes > > > the only compile time error the current cvs tree has on aix with > > > out reaming the "login.h" include file. > > > > > > > > Confirmed. This is necessary to build. > > Unfortunately this breaks some systems whose /usr/include definitions > of varargs differ from the gcc ones. At least here, this seems to work just fine with 'cc' (VisualAge C++ Professional / C for AIX Compiler, Version 5) too. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From djm at mindrot.org Sun Feb 18 13:14:23 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Feb 2001 13:14:23 +1100 (EST) Subject: Small aix patch to configure.in In-Reply-To: Message-ID: On Sun, 18 Feb 2001, Pekka Savola wrote: > > Unfortunately this breaks some systems whose /usr/include definitions > > of varargs differ from the gcc ones. > > At least here, this seems to work just fine with 'cc' (VisualAge C++ > Professional / C for AIX Compiler, Version 5) too. What about when you use gcc? I hope to clear the problem up by renaming the offending source files. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From jones at hpc.utexas.edu Sun Feb 18 13:20:59 2001 From: jones at hpc.utexas.edu (William L. Jones) Date: Sat, 17 Feb 2001 20:20:59 -0600 Subject: Small aix patch to configure.in In-Reply-To: References: Message-ID: <4.2.0.58.20010217201545.01cf6310@127.0.0.1> I you mean by some "system non aix system" then the mod should be ok. The patch only applies to aix systems. The mod is targeted only for aix systems. At 01:00 PM 2/18/01 +1100, Damien Miller wrote: >On Sun, 18 Feb 2001, Pekka Savola wrote: > > > On Sat, 17 Feb 2001, William L. Jones wrote: > > > The following aix patch to configure.in forces /usr/include > > > to be searched before /usr/local/include on AIX systems only. > > > This allows the normal include rules to untangle from > > > "login.h" on AIX when using the AIX cc compiler or gcc. Please > > > see that it gets applied to the current cvs source tree. It fixes > > > the only compile time error the current cvs tree has on aix with > > > out reaming the "login.h" include file. > > > > > > > > Confirmed. This is necessary to build. > >Unfortunately this breaks some systems whose /usr/include definitions >of varargs differ from the gcc ones. > >-d > >-- >| Damien Miller \ ``E-mail attachments are the poor man's >| http://www.mindrot.org / distributed filesystem'' - Dan Geer From jones at hpc.utexas.edu Sun Feb 18 13:22:33 2001 From: jones at hpc.utexas.edu (William L. Jones) Date: Sat, 17 Feb 2001 20:22:33 -0600 Subject: OpenSSH 2.5.0p1 vs. SA_RESTART In-Reply-To: References: <200102180103.f1I130I03344@xerxes.courtesan.com> Message-ID: <4.2.0.58.20010217202210.01ce7700@127.0.0.1> Add unicos to the list of system that don't have SA_RESTART. At 01:05 PM 2/18/01 +1100, Damien Miller wrote: >On Sat, 17 Feb 2001, Todd C. Miller wrote: > > > Not all OSes have SA_RESTART (for instance, SunOS does not). > > Also, for the non-SA_RESTART case in scp.c sa.sa_flags > > was not being initialized (noted by dworkin at village.org). > >Can you give this a try? It uses SA_INTERRUPT, my copy of Stevens >tells me this does the same thing on SunOS. > >Index: misc.c >=================================================================== >RCS file: /var/cvs/openssh/misc.c,v >retrieving revision 1.9 >diff -u -r1.9 misc.c >--- misc.c 2001/02/17 17:10:16 1.9 >+++ misc.c 2001/02/18 02:03:36 >@@ -112,6 +112,10 @@ > if (sig == SIGCHLD) > sa.sa_flags |= SA_RESTART; > #endif >+#ifdef SA_INTERRUPT >+ if (sig == SIGCHLD) >+ sa.sa_flags |= SA_INTERRUPT; >+#endif > sa.sa_handler = act; > if (sigaction(sig, &sa, NULL) == -1) > return (mysig_t) -1; >Index: scp.c >=================================================================== >RCS file: /var/cvs/openssh/scp.c,v >retrieving revision 1.54 >diff -u -r1.54 scp.c >--- scp.c 2001/02/11 14:19:40 1.54 >+++ scp.c 2001/02/18 02:03:36 >@@ -1224,8 +1224,12 @@ > struct sigaction sa; > sa.sa_handler = updateprogressmeter; > sigemptyset((sigset_t *)&sa.sa_mask); >+ sa.sa_flags = 0; > #ifdef SA_RESTART >- sa.sa_flags = SA_RESTART; >+ sa.sa_flags |= SA_RESTART; >+#endif >+#ifdef SA_INTERRUPT >+ sa.sa_flags |= SA_INTERRUPT; > #endif > sigaction(SIGALRM, &sa, NULL); > alarmtimer(1); > > >-d > >-- >| Damien Miller \ ``E-mail attachments are the poor man's >| http://www.mindrot.org / distributed filesystem'' - Dan Geer From jones at hpc.utexas.edu Sun Feb 18 13:27:17 2001 From: jones at hpc.utexas.edu (William L. Jones) Date: Sat, 17 Feb 2001 20:27:17 -0600 Subject: Small aix patch to configure.in In-Reply-To: <4.2.0.58.20010217201545.01cf6310@127.0.0.1> References: Message-ID: <4.2.0.58.20010217202646.01d18e90@127.0.0.1> Err, I mean "If you mean ..." At 08:20 PM 2/17/01 -0600, William L. Jones wrote: >I you mean by some "system non aix system" then the mod should be ok. The >patch >only applies to aix systems. > >The mod is targeted only for aix systems. From mouring at etoh.eviladmin.org Sun Feb 18 13:40:21 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 17 Feb 2001 20:40:21 -0600 (CST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Pekka Savola wrote: [..] > > IMO: builddir != srcdir is the standard case. builddir == srcdir > > is just a special case which moreover isn't a too clean way to > > build stuff. I think it isn't' worth to tweak configure to drop > > some -I for just one special case. > > builddir == srcdir is a special case, true, but still.. I'd approximate > over 95% if not 99% of users _do_ build software when builddir == srcdir. > It's IMO a lot more important to get it right for the most commonly used > case. > I don't agree.. builddir == srcdir is more common now then builddir != srcdir for end users. However I will agree within a coperation or a multi-platform enviroment building outside the source dir is more common. The best choice is renaming login.[ch] and pty.[ch] is the best choice. However, doing it portable only is asking for a headache for us that have to sync the trees. - Ben From mouring at etoh.eviladmin.org Sun Feb 18 13:42:30 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 17 Feb 2001 20:42:30 -0600 (CST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Sat, 17 Feb 2001, Tim Rice wrote: > On Fri, 16 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > Yes I did test it. It worked fine under Linux. However I did not get any > > chance to test it under anything else. Before running ou the door. > > > > I never needed --src-dir to compile in a different location. But if that > > is needed then we should set the right -I via that if we can. Because we > > have other issues that are more hidden (pty.h and openpty() call). > > > > Tim, > > > > The choice is either we ignore AIX or we stop the default behavior of > > building out of the tree. Where the latter is anonying the form is > > unacceptable. > > I'm not convinced we can't have both. Many projects build in and out of > the source tree. Unfornatuly I don't have AIX here. (Maybe it's time > to pick up an old RS6000) > > Can anyone provide me with ssh access to an AIX machine to look into this? > I'm suggesting a solution that will allow us the max builds in the shortest time. Not a longterm solution. - Ben From jones at hpc.utexas.edu Sun Feb 18 13:46:34 2001 From: jones at hpc.utexas.edu (William L. Jones) Date: Sat, 17 Feb 2001 20:46:34 -0600 Subject: OpenSSH 2.5.0p1 In-Reply-To: References: Message-ID: <4.2.0.58.20010217204338.01d083c0@127.0.0.1> At 08:40 PM 2/17/01 -0600, mouring at etoh.eviladmin.org wrote: >On Sat, 17 Feb 2001, Pekka Savola wrote: > >[..] > > > IMO: builddir != srcdir is the standard case. builddir == srcdir > > > is just a special case which moreover isn't a too clean way to > > > build stuff. I think it isn't' worth to tweak configure to drop > > > some -I for just one special case. > > > > builddir == srcdir is a special case, true, but still.. I'd approximate > > over 95% if not 99% of users _do_ build software when builddir == srcdir. > > It's IMO a lot more important to get it right for the most commonly used > > case. > > > >I don't agree.. builddir == srcdir is more common now then builddir != >srcdir for end users. However I will agree within a coperation or a >multi-platform enviroment building outside the source dir is more common. > >The best choice is renaming login.[ch] and pty.[ch] is the best >choice. However, doing it portable only is asking for a headache for us >that have to sync the trees. > >- Ben I agree that renameing login.{ch} and pty.{ch} is the best choice. The -I/usr/include trick is just an attempt to work around the AIX problem until that can happen. Bill Jones From tim at multitalents.net Sun Feb 18 13:54:10 2001 From: tim at multitalents.net (Tim Rice) Date: Sat, 17 Feb 2001 18:54:10 -0800 (PST) Subject: add scp path to _PATH_STDPATH In-Reply-To: Message-ID: Try this patch out. In addition to the things mentioned below, it adds a line to sshd_config telling what PATH was compiled into sshd. On Tue, 13 Feb 2001, Tim Rice wrote: > On Tue, 13 Feb 2001, Kevin Steves wrote: > > > On Tue, 13 Feb 2001, Tim Rice wrote: > > : I have a good patch in my 2.2.0p1 code that I can bring forward. > > : I probably will not be able to work on it until the weekend. > > > > how was it different from the patch i posted? > > > [patch snipped] > > > It sets the default patch to be same as rshd (on platforms I know) > It only adds to the PATH if the path to scp is not in PATH. > And it displays what the PATH is going to be at the end of configure. > And it works correctly if you chang any of these. > --prefix=PREFIX install architecture-independent files in PREFIX > --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX > --bindir=DIR user executables in DIR [EPREFIX/bin] > --with-default-path=PATH Specify default $PATH environment for server > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- openssh_cvs/configure.in.old Fri Feb 16 18:15:18 2001 +++ openssh_cvs/configure.in Sat Feb 17 18:42:19 2001 @@ -46,6 +46,9 @@ CFLAGS="$CFLAGS -Wall" fi +# taken from defines.h +user_path="/usr/bin:/bin:/usr/sbin:/sbin" + # Check for some target-specific stuff case "$host" in *-*-aix*) @@ -170,6 +173,7 @@ else AC_MSG_RESULT(no) fi + user_path="/usr/sbin:/usr/bin" ;; *-*-sunos4*) CPPFLAGS="$CPPFLAGS -DSUNOS4" @@ -206,6 +210,7 @@ mansubdir=cat enable_suid_ssh=no AC_DEFINE(USE_PIPES) + user_path=":/bin:/usr/bin:/usr/X/bin" ;; *-*-sysv5*) CPPFLAGS="$CPPFLAGS -I/usr/local/include" @@ -214,6 +219,7 @@ mansubdir=cat enable_suid_ssh=no AC_DEFINE(USE_PIPES) + user_path=":/bin:/usr/bin:/usr/X/bin" ;; *-*-sysv*) CPPFLAGS="$CPPFLAGS -I/usr/local/include" @@ -237,6 +243,7 @@ AC_DEFINE(DISABLE_SHADOW) AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) AC_CHECK_FUNCS(getluid setluid) + user_path="/bin:/usr/bin:/usr/local/bin:" ;; *-*-sco3.2v5*) CPPFLAGS="$CPPFLAGS -I/usr/local/include" @@ -251,6 +258,7 @@ AC_DEFINE(DISABLE_SHADOW) AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) AC_CHECK_FUNCS(getluid setluid) + user_path="/bin:/usr/bin:/etc" ;; *-dec-osf*) if test ! -z "USE_SIA" ; then @@ -1366,12 +1377,31 @@ [ --with-default-path=PATH Specify default \$PATH environment for server], [ if test "x$withval" != "xno" ; then - AC_DEFINE_UNQUOTED(USER_PATH, "$withval") + user_path="$withval" SERVER_PATH_MSG="$withval" fi ] ) +# make sure $bindir is in USER_PATH so scp will work +t_bindir=`eval echo ${bindir}` +case $t_bindir in + NONE/*) t_bindir=`echo $t_bindir | sed "s~NONE~$prefix~"` ;; +esac +case $t_bindir in + NONE/*) t_bindir=`echo $t_bindir | sed "s~NONE~$ac_default_prefix~"` ;; +esac +echo $user_path | grep ":$t_bindir" > /dev/null 2>&1 +if test $? -ne 0 ; then + echo $user_path | grep "^$t_bindir" > /dev/null 2>&1 + if test $? -ne 0 ; then + user_path=$user_path:$t_bindir + AC_MSG_RESULT(Adding $t_bindir to USER_PATH so scp will work) + fi +fi +AC_DEFINE_UNQUOTED(USER_PATH, "$user_path") +AC_SUBST(user_path) + # Whether to force IPv4 by default (needed on broken glibc Linux) IPV4_HACK_MSG="no" AC_ARG_WITH(ipv4-default, @@ -1714,6 +1744,7 @@ E=`eval echo ${libexecdir}/ssh-askpass` ; E=`eval echo ${E}` F=`eval echo ${mandir}/${mansubdir}X` ; F=`eval echo ${F}` G=`eval echo ${piddir}` ; G=`eval echo ${G}` +H=`eval echo ${user_path}` ; H=`eval echo ${H}` echo "" echo "OpenSSH configured has been configured with the following options." @@ -1723,6 +1754,7 @@ echo " Askpass program: $E" echo " Manual pages: $F" echo " PID file: $G" +echo " sshd default user PATH: $H" echo " Random number collection: $RAND_MSG" echo " Manpage format: $MAN_MSG" echo " PAM support: ${PAM_MSG}" --- openssh_cvs/Makefile.in.old Fri Feb 16 18:15:07 2001 +++ openssh_cvs/Makefile.in Sat Feb 17 18:42:37 2001 @@ -68,7 +68,8 @@ -D/var/run/sshd.pid=$(piddir)/sshd.pid \ -D/etc/primes=$(sysconfdir)/primes \ -D/etc/sshrc=$(sysconfdir)/sshrc \ - -D/usr/X11R6/bin/xauth=$(XAUTH_PATH) + -D/usr/X11R6/bin/xauth=$(XAUTH_PATH) \ + -D/usr/bin:/bin:/usr/sbin:/sbin=@user_path@ FIXPATHSCMD = $(PERL) $(srcdir)/fixpaths $(PATHSUBS) --- openssh_cvs/sshd_config.old Sat Feb 10 19:40:00 2001 +++ openssh_cvs/sshd_config Sat Feb 17 18:29:35 2001 @@ -1,5 +1,7 @@ # $OpenBSD: sshd_config,v 1.32 2001/02/06 22:07:50 deraadt Exp $ +# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin + # This is the sshd server system-wide configuration file. See sshd(8) # for more information. From mdb at juniper.net Sun Feb 18 13:52:47 2001 From: mdb at juniper.net (Mark D. Baushke) Date: Sat, 17 Feb 2001 18:52:47 -0800 Subject: OpenSSH 2.5.0p1 In-Reply-To: Mail from "William L. Jones" dated Sat, 17 Feb 2001 20:46:34 CST <4.2.0.58.20010217204338.01d083c0@127.0.0.1> Message-ID: <200102180252.SAA28017@garnet.juniper.net> Would it make sense to have configure copy (or symlink) the login.{c,h} and pty.{c,h} to ssh-login.{c,h} and ssh-pty.{c,h} and have the files that need them include the ssh-{login,pty}.h ? This way the correct files are in our repository until they are renamed in the OpenBSD sources, but the portable version uses them as if they were under the new names. I really do NOT like the -I/usr/include trick as it does cause pain when using gcc as the compiler. -- Mark >Date: Sat, 17 Feb 2001 20:46:34 -0600 >From: "William L. Jones" > >>The best choice is renaming login.[ch] and pty.[ch] is the best >>choice. However, doing it portable only is asking for a headache for us >>that have to sync the trees. >> >>- Ben > >I agree that renameing login.{ch} and pty.{ch} is the best choice. The >-I/usr/include trick is just an attempt to work around the AIX problem >until that can happen. > >Bill Jones > From stevesk at sweden.hp.com Sun Feb 18 14:05:56 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Sun, 18 Feb 2001 04:05:56 +0100 (MET) Subject: Important fix (sshd && binding). Portable version only. In-Reply-To: Message-ID: On Sun, 18 Feb 2001, Damien Miller wrote: : > i don't have ipv6 configs to experiment with, but i do not agree with a : > change that drops valid error messages and logs erroneous success : > messages. : > : > i would like to sync with openbsd. can you come up with a patch that : > would be accepted in their tree that will log acceptably on all : > platforms? : : I think we should sync with OpenBSD - this problem is specific to : Linux IPv6 (which is rare) and can be worked around by being careful : with ListenAddress. : : We may need to ship a config with "ListenAddress 0.0.0.0" though. i don't understand this requirement--can you elaborate? From djm at mindrot.org Sun Feb 18 14:28:38 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Feb 2001 14:28:38 +1100 (EST) Subject: Important fix (sshd && binding). Portable version only. In-Reply-To: Message-ID: On Sun, 18 Feb 2001, Kevin Steves wrote: > On Sun, 18 Feb 2001, Damien Miller wrote: > : > i don't have ipv6 configs to experiment with, but i do not agree with a > : > change that drops valid error messages and logs erroneous success > : > messages. > : > > : > i would like to sync with openbsd. can you come up with a patch that > : > would be accepted in their tree that will log acceptably on all > : > platforms? > : > : I think we should sync with OpenBSD - this problem is specific to > : Linux IPv6 (which is rare) and can be worked around by being careful > : with ListenAddress. > : > : We may need to ship a config with "ListenAddress 0.0.0.0" though. > > i don't understand this requirement--can you elaborate? The default is to try and bind to both IPv4 and IPv6 sockets, which elicits the error message on Linux. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From Todd.Miller at courtesan.com Sun Feb 18 14:41:53 2001 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Sat, 17 Feb 2001 20:41:53 -0700 Subject: OpenSSH 2.5.0p1 In-Reply-To: Your message of "Sun, 18 Feb 2001 12:44:41 +1100." References: Message-ID: <200102180341.f1I3fsd26922@xerxes.courtesan.com> SunOS 4.x also needs to define HAVE_BOGUS_SYS_QUEUE_H as it has a that lacks the TAILQ_* macros. I wonder if it would not be better to just check for their existence in and avoid the special cases? - todd --- configure.in.DIST Thu Feb 15 18:12:41 2001 +++ configure.in Sat Feb 17 18:51:35 2001 @@ -175,6 +175,7 @@ CPPFLAGS="$CPPFLAGS -DSUNOS4" AC_CHECK_FUNCS(getpwanam) AC_DEFINE(PAM_SUN_CODEBASE) + AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) conf_utmp_location=/etc/utmp conf_wtmp_location=/var/adm/wtmp conf_lastlog_location=/var/adm/lastlog From Todd.Miller at courtesan.com Sun Feb 18 14:46:42 2001 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Sat, 17 Feb 2001 20:46:42 -0700 Subject: OpenSSH 2.5.0p1 vs. SA_RESTART In-Reply-To: Your message of "Sun, 18 Feb 2001 13:05:01 +1100." References: Message-ID: <200102180346.f1I3kgu29644@xerxes.courtesan.com> On SunOS, SA_INTERRUPT is the converse of SA_RESTART. Since the SA_RESTART behavior is the default so you don't really need to do anything. - todd From mw at moni.msci.memphis.edu Sun Feb 18 14:56:52 2001 From: mw at moni.msci.memphis.edu (Mate Wierdl) Date: Sat, 17 Feb 2001 21:56:52 -0600 Subject: Name change In-Reply-To: <20010217214728.B12395@greenie.muc.de>; from gert@greenie.muc.de on Sat, Feb 17, 2001 at 09:47:28PM +0100 References: <20010217214728.B12395@greenie.muc.de> Message-ID: <20010217215652.C13780@moni.msci.memphis.edu> On Sat, Feb 17, 2001 at 09:47:28PM +0100, Gert Doering wrote: > I'd just stick to OpenSSH. But then it's most likely upon Damien and > Markus to decide whether they want to risk having lawyers upon their > backs. If I were them, I would not change the name at all. But if they did, try opensafesh or just opensafe for kicks. But then again, somebody would trademark this name too---one more reason to leave the old name. Ylonen has to realize he is doing more damage to his co with his trademark claim. Paraphrasing Newton: just because he found a smooth rock does not mean the rock is his. A lawyer friend here tells me: the trademark case for `|grep -i ssh' is rather weak for reasons already discussed in this list. It does not mean, though, that it cannot be dragged on for months. It would be rather useful if the case went to court, and Ylonen lost. It would discourage people in the future. Mate From djm at mindrot.org Sun Feb 18 15:02:39 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Feb 2001 15:02:39 +1100 (EST) Subject: OpenSSH 2.5.0p1 vs. SA_RESTART In-Reply-To: <200102180346.f1I3kgu29644@xerxes.courtesan.com> Message-ID: On Sat, 17 Feb 2001, Todd C. Miller wrote: > On SunOS, SA_INTERRUPT is the converse of SA_RESTART. Since the > SA_RESTART behavior is the default so you don't really need to > do anything. You are correct and my patch is completely wrong. We should have what Stevens suggests: #if defined(SA_RESTART) if (sig == SIGCHLD) sa.sa_flags |= SA_RESTART; #endif #if defined(SA_INTERRUPT) if (sig == SIGALRM) sa.sa_flags |= SA_INTERRUPT; #endif -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From jones at hpc.utexas.edu Sun Feb 18 15:16:33 2001 From: jones at hpc.utexas.edu (William L. Jones) Date: Sat, 17 Feb 2001 22:16:33 -0600 Subject: OpenSSH 2.5.0p1 In-Reply-To: <200102180252.SAA28017@garnet.juniper.net> References: <4.2.0.58.20010217204338.01d083c0@127.0.0.1> Message-ID: <4.2.0.58.20010217221213.01ccc4a0@127.0.0.1> At 06:52 PM 2/17/01 -0800, Mark D. Baushke wrote: >I really do NOT like the -I/usr/include trick as it does cause pain >when using gcc as the compiler. > > -- Mark > Have you tried it with gcc on aix. I have and it didn't seem to cause any problems. What verions of AIX does it cause pain when compiling with gcc? Bill Jones From Todd.Miller at courtesan.com Sun Feb 18 15:14:00 2001 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Sat, 17 Feb 2001 21:14:00 -0700 Subject: OpenSSH 2.5.0p1 vs. SA_RESTART In-Reply-To: Your message of "Sun, 18 Feb 2001 15:02:39 +1100." References: Message-ID: <200102180414.f1I4E0Z05769@xerxes.courtesan.com> In message so spake Damien Miller (djm): > You are correct and my patch is completely wrong. We should have > what Stevens suggests: > > #if defined(SA_RESTART) > if (sig == SIGCHLD) > sa.sa_flags |= SA_RESTART; > #endif > #if defined(SA_INTERRUPT) > if (sig == SIGALRM) > sa.sa_flags |= SA_INTERRUPT; > #endif Yup, that looks correct to me. The BSD man pages claim that SA_RESTART is a Berkeley extension, which may explain why it is missing (or just not defined by default) on some OSes. - todd From devon at admin2.gisnetworks.com Sun Feb 18 17:07:05 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Sat, 17 Feb 2001 22:07:05 -0800 Subject: SSH2 PATH problem References: Message-ID: <00ea01c09971$05139ee0$1900a8c0@devn> still broken on solaris 7 with pam enabled (works fine with pam disabled). on another note, scp also appears to be broken when the server side is solaris 7 with pam enabled (works fine with pam disabled). i have ssh falling under 'other' in pam.conf. sshd -d -d -d output is attached for an scp attempt from a slackware 7.1 machine also running latest cvs code (sorry about any CRLF formatting issues, i created the files on a windows machine). devon ----- Original Message ----- From: "Damien Miller" To: "Tim Rice" Cc: "Jean-Marc Beroud" ; Sent: Saturday, February 17, 2001 6:09 PM Subject: Re: SSH2 PATH problem > On Sat, 17 Feb 2001, Tim Rice wrote: > > > > I can't immediatly see how this can happen :( > > > > The problem seems to be gone in SSH Version OpenSSH_2.5.0p1 > > Can other people confirm this? > > -d > > -- > | Damien Miller \ ``E-mail attachments are the poor man's > | http://www.mindrot.org / distributed filesystem'' - Dan Geer > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sshd-d-d-d.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010217/322bd001/attachment.txt From jmknoble at jmknoble.cx Sun Feb 18 17:06:25 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Sun, 18 Feb 2001 01:06:25 -0500 Subject: PATCH: make contrib/redhat/sshd.init work with older RH releases In-Reply-To: ; from pekkas@netcore.fi on Sun, Feb 18, 2001 at 03:35:54AM +0200 References: <20010217200627.I25687@quipu.half.pint-stowp.cx> Message-ID: <20010218010625.K25687@quipu.half.pint-stowp.cx> Circa 2001-Feb-18 03:35:54 +0200 dixit Pekka Savola: : On Sat, 17 Feb 2001, Jim Knoble wrote: : [About /etc/rc.d/init.d/ vs. /etc/init.d/] : > I disagree. If you want to fix it properly at this time, this is : > exactly the sort of thing to worry about. Are you certain RH will : > leave the compatibility symlink in RHL-7.1? I'm not. : : Yes. It will be there. How do you know? Do you know if it will be there in 7.2? 8.0? The FHS >= 2.0 clearly states where init.d is supposed to live (/etc/init.d), and RHL has a particularly poor track record at providing real compatibility with prior releases. : > Red Hat Linux 5.2 is no more obsolete than, say, NeXTstep 3.x or : > 4.x, HP-UX-10.x, IRIX-5.x, SunOS-4.x, all of which are listed in : > configure.in. : : For most of these platforms, only something like 'add : /usr/local/sbin/sshd in your rc.local' is given. This is a more : complex matter Only because you're making it complex. I gave a simple solution that works. You're the one who wants to rewrite everything from scratch. : Also, the pace at where Linux vs e.g. Solaris is developing is quite : different. I don't think it's feasible to assume a Linux box : installed 4 years ago will still be running non-upgraded; for : commercial systems, this is probably rather commonplace. Bullshit. I know of four separate instances, right now off the top of my head, where Red Hat Linux 5.2 or earlier is in place, functioning perfectly, with no need to upgrade the entire system. You only say that Linux is developing at a faster pace because you think that everyone downloads Red Hat Linux betas and moves to them as soon as they're available. If they want to continue using what they know works, without extra cost-of-ownership involved in upgrading, then *let them*, for goodness' sake! It's not so difficult! When i recently installed OpenSSH-2.3.0p1 on a Red Hat Linux 4.2 for a friend of mine, the only thing that was necessary for me to do, besides recompiling with --without-pam, was ... *FANFARE* modify sshd.init. Leaving folks in that situation in the dust is ignorant, short-sighted, and arrogant. : > The solution i've proposed will work fine on Red Hat Linux 5.2, and : > coincidentally on 4.2 as well, without posing any additional troubles : > to 6.x, 7.0, or subsequent releases. : : Well, it all boils down to this: do we want to diverge from RH init : scripts? OpenSSH *already* diverges from recent RH init scripts, for goodness' sake! Where else is something like do_dsa_keygen() or do_rsa_keygen() done? Nowhere! Where else is a daemon started without using the daemon() function? Virtually nowhere! Conforming to the shoddy, half-ass style that most RH init scripts are written in has never been a goal of mine. Making things work properly has been. : Adding all kinds of 'my_success' etc. functions push toward complely : separate scripts. Huh? It's not completely separate. In fact, it's grafted into the *provided* API, where that API exists, both for RHL >= 6.0 and for RHL <= 5.2. : I don't like it from the maintainability point of view. Sorry? If anything, what i've presented is *more* maintainable. At least it's immediately obvious what's been done, and what needs to be done to maintain compatibility. With your proposed solution, someone modifying the file could easily be blissfully ignorant of any compatibility needs and completely break things, then wonder why the hell they don't work anymore weeks or months down the road. For the purpose of maintainability, obvious is better than pretty. : If we want to support really old systems, it's probably better to just : provide them a _very_ simple init script which would have worked even : with RHL 3.0.3. No fuss, nothing to maintain. /^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ / This is exactly the attitude i take issue with. I provided a fix that required no fuss, and no extra file to maintain ... it just worked, in one file. What's the problem with that? You think it's not clean or pretty enough? Sorry if you feel that way, but making things work across releases sometimes requires code that feels a little gritty. That's life. If you think that there's nothing extra to maintain, look at the difference between sshd.init and sshd.init-5.x, and tell me why you think sshd.init-5.x isn't in sore need of maintenance. In particular, tell me why you think that it's a good idea to neglect to generate a host key at startup time when there's plenty of entropy available like the folks running RHL-6.x or later get to do. : Better than using a lot of time verifying every new bell & whistle : that'd appear in newer init scripts, backporting them into earlier : versions Isn't that what developing a "portable" version of OpenSSH is all about? : and bloating what most people use. Unless you can come up with a non-arbitrary quantitative definition of "bloat", then please stop using that argument. It's been a tired old argument ever since processors became faster than 16 MHz and had builtin MMUs and FPUs. If you mean "it's not how i would like it to look for my system", then please write that. Pekka, i'm not trying to be belligerent, but you're pressing all my hot-buttons. -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From jmknoble at jmknoble.cx Sun Feb 18 17:28:06 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Sun, 18 Feb 2001 01:28:06 -0500 Subject: dealing with RH initscripts backward compatibility In-Reply-To: ; from pekkas@netcore.fi on Sat, Feb 17, 2001 at 10:34:26PM +0200 References: <20010217133459.E25687@quipu.half.pint-stowp.cx> Message-ID: <20010218012806.L25687@quipu.half.pint-stowp.cx> Circa 2001-Feb-17 22:34:26 +0200 dixit Pekka Savola: : Hello all, : : Continuing the thread: : : Re: PATCH: make contrib/redhat/sshd.init work with older RH releases : : Attached are newer versions of initscripts. These are smaller and : probably more readable than patches. Backward compability features : haven't been tested that extensively. : : I think the issue of legacy initscripts support should be handled like : with these patches (sshd-functions could be refined, of course), or in : addition: : : * in openssh.spec, there would be a %define to enable "backward : compability". There might even be autodetection for this using : /etc/redhat-release. : : * with this defined, sshd-functions would be taken from contrib and : installed in /etc/rc.d/init.d/. : : * this would give the implementor of sshd-functions more liberty at how he : could redefine echo/failure/success/action/etc., because he would know : that the changes would only kick in for users using RHL5.2 or earlier : [currently] : : With this, there might be no need for the "do we require this" -checks : (~30 first lines of sshd-functions). : : What do you think? IMO, I think the new idea is probably better because : it allows for more freedom when it comes to the implementation. Also, : there are other issues that will be version-specific (pam, ...). : : I could hack the spec file do that. : : -- : Pekka Savola "Tell me of difficulties surmounted, : Netcore Oy not those you stumble over and fall" : Systems. Networks. Security. -- Robert Jordan: A Crown of Swords --------[file: sshd.init]-------- : #!/bin/bash : # : # Init file for OpenSSH server daemon : # : # chkconfig: 2345 55 25 : # description: OpenSSH server daemon : # : # processname: sshd : # config: /etc/ssh/ssh_host_key : # config: /etc/ssh/ssh_host_key.pub : # config: /etc/ssh/ssh_random_seed : # config: /etc/ssh/sshd_config : # pidfile: /var/run/sshd.pid : : # source function library : . /etc/rc.d/init.d/functions : : # source initscripts backward compatibility functions if they exist : if [ -r /etc/rc.d/init.d/sshd-functions ]; then : . /etc/rc.d/init.d/sshd-functions I don't like this at all. If this file goes away due to filesystem or operator error, things will unexplainably break. Having them break with an immediate message such as: bash: /etc/rc.d/init.d/sshd-functions: No such file or directory is much easier to diagnose. : fi : : RETVAL=0 : prog="sshd" : : # Some functions to make the below more readable /^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ / You probably mean to move this line down to where the functions are. : KEYGEN=/usr/bin/ssh-keygen : SSHD=/usr/sbin/sshd : RSA1_KEY=/etc/ssh/ssh_host_key : RSA_KEY=/etc/ssh/ssh_host_rsa_key : DSA_KEY=/etc/ssh/ssh_host_dsa_key : PID_FILE=/var/run/sshd.pid : : start() : { [...] : exit $RETVAL --------[file: sshd-functions]-------- : # Backward compability functions for initscripts, parts by Red Hat. : : # Find out whether we need to use the local functions : # Unnecessary use should be avoided. : : if [ ! "`type -type success`" = "function" ]; then : success() { : my_success "$*" /^^^^^^ / No, no no. Use "$@", not "$*". "$*" turns multiple arguments into one argument---this is almost never what you want, and certainly isn't here. : } : fi : : if [ ! "`type -type failure`" = "function" ]; then : failure() { : my_failure "$*" : } : fi : : if [ ! "`type -type action`" = "function" ]; then : action() { : my_action "$*" : } : fi : : : case "${BASH_VERSION}" in : 1.*) : echo() { : my_echo "$*" : } : ;; : esac : : : # Required for old initscripts < 4.16 or so (RHL5.2) : my_success() { : local msg : if [ $# -gt 1 ]; then : msg="$2" : else : msg="done" : fi : case "`type -type success`" in If you're going to go about things this way, why do you check whether 'success' is a function twice? Do it above, or here, but not both. : function) : success "$1" : ;; : *) : echo -n "${msg}" : ;; : esac : } : : # Required for old initscripts < 4.16 or so (RHL5.2) : my_failure() { : local msg : if [ $# -gt 1 ]; then : msg="$2" : else : msg="FAILED" : fi : case "`type -type failure`" in : function) : failure "$1" : ;; : *) : echo -n "${msg}" : ;; : esac : } : : # Required for old initscripts < 4.16 or so (RHL5.2) : my_action() { : STRING=$1 : echo -n "$STRING " /^^^^^^^^^^^^^^^^^^^^ / my_success() and my_failure() already echo their string . Why do you do it again here? : shift : "$*" && success "$STRING" || failure "$STRING" : rc=$? : echo : return $rc : } : : # Required for bash1 (RHL6.2 if bash2 package not installed) : my_echo() { : local args="" : while [ $# -gt 0 ]; do : case "$1" in : --) : break : ;; : -*) : args="${args} $1" : shift : ;; : *) : break : ;; : esac : done : case "${BASH_VERSION}" in Again, why do you do this twice? Pick one. : 1.*) : echo ${args} "$@" /^^^^^^ / This won't work at all they way you've done things. echo() is defined as my_echo(), which calls echo(), which calls ... ad finitum memoriae. : ;; : *) : echo ${args} $"$@" : ;; : esac : } -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From mouring at etoh.eviladmin.org Sun Feb 18 18:01:18 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 18 Feb 2001 01:01:18 -0600 (CST) Subject: OpenSSH 2.5.0p1 In-Reply-To: <20010217214515.A12395@greenie.muc.de> Message-ID: On Sat, 17 Feb 2001, Gert Doering wrote: > Hi, > > On Sat, Feb 17, 2001 at 11:17:05AM -0600, mouring at etoh.eviladmin.org wrote: > > However I know there was a reason for us -L$ssldir and -L$ssldir/lib. And > > I would rather see a solution that keeps both tests in place if possible. > > The double "-L" breaks the linker on SCO 3.0 (too many -L). > > Why not really *check* the -L path for "$ssldir/(lib/)?libcrypto.a", and > use only the directory where it can be found? > I was hoping someone else with this problem would provide the patch.. However. If this is acceptable to all parties... Grant I refuse to claim it's clean, pretty, what not.. It's almost 1am my time and I'm going to bed. I can state it works under Linux Redhat 7.0 and I've done no other other testing. If someone could tell my how to get AC_CACHE_CHECK to set two variables instead of one. I'd be much happier. I hate cheap awk tricks. - Ben --- configure.in Sun Feb 18 00:57:27 2001 +++ ../ossh/configure.in Sun Feb 18 00:54:15 2001 @@ -592,25 +592,27 @@ if test "x$prefix" != "xNONE" ; then tryssldir="$tryssldir $prefix" fi -AC_CACHE_CHECK([for OpenSSL directory], ac_cv_openssldir, [ +AC_CACHE_CHECK([for OpenSSL directory], ac_cv_openssl, [ - for ssldir in $tryssldir "" /usr/local/openssl /usr/lib/openssl /usr/local/ssl /usr/lib/ssl /usr/local /usr/pkg /opt /opt/openssl ; do - if test ! -z "$ssldir" -a "x$ssldir" != "x/usr"; then - LDFLAGS="$saved_LDFLAGS -L$ssldir/lib -L$ssldir" - CPPFLAGS="$saved_CPPFLAGS -I$ssldir/include" - if test ! -z "$need_dash_r" ; then - LDFLAGS="$LDFLAGS -R$ssldir/lib -R$ssldir" + for sslinc in $tryssldir "" /usr/local/openssl /usr/lib/openssl /usr/local/ssl /usr/lib/ssl /usr/local /usr/pkg /opt /opt/openssl ; do + for ssldir in $sslinc "$sslinc/lib"; do + if test ! -z "$sslinc" -a "x$sslinc" != "x/usr"; then + LDFLAGS="$saved_LDFLAGS -L$ssldir" + CPPFLAGS="$saved_CPPFLAGS -I$sslinc/include" + if test ! -z "$need_dash_r" ; then + LDFLAGS="$LDFLAGS -R$ssldir/lib" + fi + else + LDFLAGS="$saved_LDFLAGS" fi - else - LDFLAGS="$saved_LDFLAGS" - fi - LIBS="$saved_LIBS -lcrypto" + LIBS="$saved_LIBS -lcrypto" - # Basic test to check for compatible version and correct linking - # *does not* test for RSA - that comes later. - AC_TRY_RUN( - [ + # Basic test to check for compatible version and + # correct linking *does not* test for RSA - that + # comes later. + AC_TRY_RUN( + [ #include #include int main(void) @@ -620,16 +622,17 @@ RAND_add(a, sizeof(a), sizeof(a)); return(RAND_status() <= 0); } - ], - [ - found_crypto=1 - break; - ], [] - ) + ], + [ + found_crypto=1 + break; + ], [] + ) - if test ! -z "$found_crypto" ; then - break; - fi + if test ! -z "$found_crypto" ; then + break; + fi + done done if test -z "$found_crypto" ; then @@ -639,22 +642,24 @@ ssldir="(system)" fi - ac_cv_openssldir=$ssldir + ac_cv_openssl="$ssldir:$sslinc" ]) if (test ! -z "$ac_cv_openssldir" && test "x$ac_cv_openssldir" != "x(system)") ; then AC_DEFINE(HAVE_OPENSSL) - dnl Need to recover ssldir - test above runs in subshell - ssldir=$ac_cv_openssldir + dnl Need to recover ssldir and sslinc - test above runs in subshell + ssldir=`echo $ac_cv_openssl | awk -F: '{ print $1 }'` + sslinc=`echo $ac_ac_openssl | awk -F: '{ print $2 }'` + # Do we need to test for $sslinc ?? if test ! -z "$ssldir" -a "x$ssldir" != "x/usr"; then - CPPFLAGS="$saved_CPPFLAGS -I$ssldir/include" - LDFLAGS="$saved_LDFLAGS -L$ssldir/lib -L$ssldir" + CPPFLAGS="$saved_CPPFLAGS -I$sslinc/include" + LDFLAGS="$saved_LDFLAGS -L$ssldir/lib" if test ! -z "$need_dash_r" ; then - LDFLAGS="$LDFLAGS -R$ssldir/lib -R$ssldir" + LDFLAGS="$LDFLAGS -R$ssldir/lib" fi if test ! -z "$blibpath" ; then - blibpath="$blibpath:$ssldir:$ssldir/lib" + blibpath="$blibpath:$ssldir" fi fi fi From pekkas at netcore.fi Sun Feb 18 19:22:53 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 18 Feb 2001 10:22:53 +0200 (EET) Subject: dealing with RH initscripts backward compatibility In-Reply-To: <20010218012806.L25687@quipu.half.pint-stowp.cx> Message-ID: On Sun, 18 Feb 2001, Jim Knoble wrote: > Circa 2001-Feb-17 22:34:26 +0200 dixit Pekka Savola: > > : Hello all, > : > : Continuing the thread: > : > : Re: PATCH: make contrib/redhat/sshd.init work with older RH releases > : > : Attached are newer versions of initscripts. These are smaller and > : probably more readable than patches. Backward compability features > : haven't been tested that extensively. > : > : I think the issue of legacy initscripts support should be handled like > : with these patches (sshd-functions could be refined, of course), or in > : addition: > : > : * in openssh.spec, there would be a %define to enable "backward > : compability". There might even be autodetection for this using > : /etc/redhat-release. > : > : * with this defined, sshd-functions would be taken from contrib and > : installed in /etc/rc.d/init.d/. > : > : * this would give the implementor of sshd-functions more liberty at how he > : could redefine echo/failure/success/action/etc., because he would know > : that the changes would only kick in for users using RHL5.2 or earlier > : [currently] > : > : With this, there might be no need for the "do we require this" -checks > : (~30 first lines of sshd-functions). > : > : What do you think? IMO, I think the new idea is probably better because > : it allows for more freedom when it comes to the implementation. Also, > : there are other issues that will be version-specific (pam, ...). I'd like comments about this approach. > : # source initscripts backward compatibility functions if they exist > : if [ -r /etc/rc.d/init.d/sshd-functions ]; then > : . /etc/rc.d/init.d/sshd-functions > > I don't like this at all. If this file goes away due to filesystem or > operator error, things will unexplainably break. Having them break > with an immediate message such as: > > bash: /etc/rc.d/init.d/sshd-functions: No such file or directory > > is much easier to diagnose. The new idea was that sshd-functions would not need to be present on recent systems. With this approach, you could cut out the additional checks (below). > > : fi > : > : RETVAL=0 > : prog="sshd" > : > : # Some functions to make the below more readable > /^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > / > You probably mean to move this line down to where the functions are. Sorry, typo. I meant definitions. :-) > --------[file: sshd-functions]-------- > > : # Backward compability functions for initscripts, parts by Red Hat. > : > : # Find out whether we need to use the local functions > : # Unnecessary use should be avoided. > : > : if [ ! "`type -type success`" = "function" ]; then > : success() { > : my_success "$*" > /^^^^^^ > / > No, no no. Use "$@", not "$*". "$*" turns multiple arguments into one > argument---this is almost never what you want, and certainly isn't here. Ok. > : # Required for old initscripts < 4.16 or so (RHL5.2) > : my_success() { > : local msg > : if [ $# -gt 1 ]; then > : msg="$2" > : else > : msg="done" > : fi > : case "`type -type success`" in > > If you're going to go about things this way, why do you check whether > 'success' is a function twice? Do it above, or here, but not both. Well, I'm not sure which approach if preferable: 1) include sshd-functions for everyone 2) include sshd-functions for old os versions only I think changes to newer systems to newer systems should be weeded off as soon as possible, hence the checks in 30 first lines. Which to remove depends on the approach. > : # Required for old initscripts < 4.16 or so (RHL5.2) > : my_action() { > : STRING=$1 > : echo -n "$STRING " > /^^^^^^^^^^^^^^^^^^^^ > / > my_success() and my_failure() already echo their string . Why do you > do it again here? True. > : 1.*) > : echo ${args} "$@" > /^^^^^^ > / > This won't work at all they way you've done things. echo() is defined > as my_echo(), which calls echo(), which calls ... ad finitum memoriae. Changing to /bin/echo would fix this, not sure if that'd take advantage of $".." locales though. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From jmknoble at jmknoble.cx Sun Feb 18 19:26:03 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Sun, 18 Feb 2001 03:26:03 -0500 Subject: PATCH: Round 2: RH initscripts backward compatibility Message-ID: <20010218032603.M25687@quipu.half.pint-stowp.cx> I've cleaned up Pekka Savola's newly revised sshd.init and additional sshd-functions and modified them to work they way i've been arguing they should work. Compatibility functions are defined in ./contrib/redhat/sshd-functions, which should get installed no matter what release of Red Hat Linux OpenSSH is getting built for, to be consistent across releases. Specific changes from Pekka's scripts: - Look for .../init.d/functions and .../init.d/sshd-functions in both /etc/init.d/ and /etc/rc.d/init.d/. - Added LOCKFILE variable for /var/lock/subsys/sshd, so that all pathnames (except for stuff in .../init.d/) are referred to via shell variables. - Changed '>&/dev/null' syntax to '&>/dev/null' as recommended in bash-1.14.x and bash-2.x man pages. - Renamed all functions defined in sshd.init to begin with 'sshd_' prefix, so that it's obvious to the casual onlooker when we're calling a function that we define vs. one defined by Red Hat. - Use '"${variable_name}"' rather than simply '$variable_name' when referring to shell variables. It's the only way to consistently prevent errors caused by spaces in variable values and other similar mistakes caused by assumptions. - Fixed several minor errors (e.g., some strings were missing $"..."). The specfile is also modified to remove the dependency on initscripts>=4.16, and to install the new sshd-functions file. I've attached the modifications as diffs against openssh-SNAP-20010218, so that it's easy for Damien to see what's changed. Much credit goes to Pekka Savola for the work toward cleaning up, reorganizing, and improving the script. -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ -------------- next part -------------- --- ./openssh-SNAP-20010218/contrib/redhat/sshd.init.orig-init Mon Nov 13 06:57:27 2000 +++ ./openssh-SNAP-20010218/contrib/redhat/sshd.init Sun Feb 18 02:58:26 2001 @@ -1,5 +1,5 @@ #!/bin/bash - +# # Init file for OpenSSH server daemon # # chkconfig: 2345 55 25 @@ -13,105 +13,139 @@ # pidfile: /var/run/sshd.pid # source function library -. /etc/rc.d/init.d/functions +# If the file exists, but is not readable, it's an error. +# Likewise, if the fallback file doesn't exist, it's an error. +if [ -f /etc/init.d/sshd-functions ]; then + . /etc/init.d/functions +else + . /etc/rc.d/init.d/functions +fi +if [ $? -ne 0 ]; then + exit 1 +fi + +# Define compatibility functions used in this init script +# If the file exists, but is not readable, it's an error. +# Likewise, if the fallback file doesn't exist, it's an error. +if [ -f /etc/init.d/sshd-functions ]; then + . /etc/init.d/sshd-functions +else + . /etc/rc.d/init.d/sshd-functions +fi +if [ $? -ne 0 ]; then + exit 1 +fi RETVAL=0 -# Some functions to make the below more readable +PROG="sshd" +SSHD=/usr/sbin/sshd KEYGEN=/usr/bin/ssh-keygen RSA1_KEY=/etc/ssh/ssh_host_key RSA_KEY=/etc/ssh/ssh_host_rsa_key DSA_KEY=/etc/ssh/ssh_host_dsa_key PID_FILE=/var/run/sshd.pid -do_rsa1_keygen() { - if ! test -f $RSA1_KEY ; then - echo -n "Generating SSH1 RSA host key: " - if $KEYGEN -q -t rsa1 -f $RSA1_KEY -C '' -N '' >&/dev/null; then - success "RSA1 key generation" +LOCKFILE=/var/lock/subsys/sshd + +# Define some functions to make the below more readable +sshd_do_rsa1_keygen() { + if [ ! -s "${RSA1_KEY}" ]; then + echo -n $(localized $"Generating SSH1 RSA host key: ") + if "${KEYGEN}" -q -t rsa1 -f "${RSA1_KEY}" -C '' -N '' \ + &>/dev/null + then + my_success $"RSA1 key generation" echo else - failure "RSA1 key generation" + my_failure $"RSA1 key generation" echo exit 1 fi fi } -do_rsa_keygen() { - if ! test -f $RSA_KEY ; then - echo -n "Generating SSH2 RSA host key: " - if $KEYGEN -q -t rsa -f $RSA_KEY -C '' -N '' >&/dev/null; then - success "RSA key generation" + +sshd_do_rsa_keygen() { + if [ ! -s "${RSA_KEY}" ]; then + echo -n $(localized $"Generating SSH2 RSA host key: ") + if "${KEYGEN}" -q -t rsa -f "${RSA_KEY}" -C '' -N '' \ + &>/dev/null + then + my_success $"RSA key generation" echo else - failure "RSA key generation" + my_failure $"RSA key generation" echo exit 1 fi fi } -do_dsa_keygen() { - if ! test -f $DSA_KEY ; then - echo -n "Generating SSH2 DSA host key: " - if $KEYGEN -q -t dsa -f $DSA_KEY -C '' -N '' >&/dev/null; then - success "DSA key generation" + +sshd_do_dsa_keygen() { + if [ ! -s "${DSA_KEY}" ]; then + echo -n $(localized $"Generating SSH2 DSA host key: ") + if "${KEYGEN}" -q -t dsa -f "${DSA_KEY}" -C '' -N '' \ + &>/dev/null + then + my_success $"DSA key generation" echo else - failure "DSA key generation" + my_failure $"DSA key generation" echo exit 1 fi fi } +sshd_start() +{ + # Create keys if necessary + sshd_do_rsa1_keygen + sshd_do_rsa_keygen + sshd_do_dsa_keygen + + my_action $"Starting ${PROG}: " $"${PROG}" $"" "${SSHD}" + RETVAL=$? + [ "${RETVAL}" = 0 ] && touch "${LOCKFILE}" +} + +sshd_stop() +{ + echo -n $(localized $"Stopping ${PROG}: ") + killproc "${SSHD}" + RETVAL=$? + echo + [ "${RETVAL}" = 0 ] && rm -f "${LOCKFILE}" +} + case "$1" in start) - # Create keys if necessary - do_rsa1_keygen; - do_rsa_keygen; - do_dsa_keygen; - - echo -n "Starting sshd: " - if [ ! -f $PID_FILE ] ; then - sshd - RETVAL=$? - if [ "$RETVAL" = "0" ] ; then - success "sshd startup" - touch /var/lock/subsys/sshd - else - failure "sshd startup" - fi - fi - echo + sshd_start ;; stop) - echo -n "Shutting down sshd: " - if [ -f $PID_FILE ] ; then - killproc sshd - RETVAL=$? - [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/sshd - fi - echo + sshd_stop ;; restart) - $0 stop - $0 start + sshd_stop + sshd_start + ;; + reload) + echo -n $(localized $"Reloading ${PROG}: ") + killproc "${SSHD}" -HUP RETVAL=$? + echo ;; condrestart) - if [ -f /var/lock/subsys/sshd ] ; then - $0 stop - $0 start - RETVAL=$? + if [ -f "${LOCKFILE}" ] ; then + sshd_stop + sshd_start fi ;; status) - status sshd + status "${SSHD}" RETVAL=$? ;; *) - echo "Usage: sshd {start|stop|restart|status|condrestart}" - exit 1 - ;; + echo $(localized $"Usage: $0 {start|stop|restart|reload|condrestart|status}") + RETVAL=1 esac - -exit $RETVAL +exit ${RETVAL} --- ./openssh-SNAP-20010218/contrib/redhat/sshd-functions.orig-init Sun Feb 18 02:57:56 2001 +++ ./openssh-SNAP-20010218/contrib/redhat/sshd-functions Sun Feb 18 02:58:32 2001 @@ -0,0 +1,97 @@ +#!/bin/bash +# +# Compability functions for sshd initscript +# Parts of my_action() are derived from Red Hat Linux 6.x initscripts. + +# Handle arguments localized using $"..." construct, if that construct +# is not available in this version of bash. +localized() { + case "${BASH_VERSION}" in + 1.*) + # Remove leading '$' character. + echo "${@#$}" + ;; + *) + echo "$@" + ;; + esac +} + +# Indicate success, using success() function if available; +# otherwise, use method compatible with initscripts < 4.0 +# (Red Hat Linux <= 5.2). +# PARAMETERS: +# $1 => message to pass to success() +# $2 => message to display in compatibility mode, if different +# from default of "done" +my_success() { + local msg + if [ $# -gt 1 ]; then + msg="$2" + else + msg="done" + fi + case "$(type -type success)" in + function) + success "$(localized "$1")" + ;; + *) + echo -n "$(localized "${msg}")" + ;; + esac +} + +# Indicate failure, using failure() function if available; +# otherwise, use method compatible with initscripts < 4.0 +# (Red Hat Linux <= 5.2). +# PARAMETERS: +# $1 => message to pass to failure() +# $2 => message to display in compatibility mode, if different +# from default of "FAILED" +my_failure() { + local msg + if [ $# -gt 1 ]; then + msg="$2" + else + msg="FAILED" + fi + case "$(type -type failure)" in + function) + failure "$(localized "$1")" + ;; + *) + echo -n "$(localized "${msg}")" + ;; + esac +} + +# Perform an action, using the action() function (which logs output) +# if available. If unavailable, perform the action and indicate +# success or failure appropriately. +# PARAMETERS: +# $1 => message to display and log in action(), or to display +# while performing action in compatibility mode +# $2 => message to display on success in compatibility mode +# $3 => message to display on failure in compatibility mode +my_action() { + local status + local msg="$(localized "$1")" + local success_msg="$(localized "$2")" + local failure_msg="$(localized "$3")" + shift 3 + case "$(type -type action)" in + function) + action "${msg}" "$@" + status=$? + ;; + *) + echo -n "${msg}" + "$@" && my_success "${msg}" "${success_msg}" \ + || my_failure "${msg}" "${failure_msg}" + status=$? + echo + ;; + esac + return ${status} +} + --- ./openssh-SNAP-20010218/contrib/redhat/openssh.spec.orig-init Wed Feb 14 23:33:17 2001 +++ ./openssh-SNAP-20010218/contrib/redhat/openssh.spec Sun Feb 18 03:03:24 2001 @@ -57,7 +57,6 @@ Group: System Environment/Daemons Obsoletes: ssh-server PreReq: openssh = %{version}-%{release}, chkconfig >= 0.9 -Requires: initscripts >= 4.16 %package askpass Summary: OpenSSH X11 passphrase dialog @@ -195,6 +194,7 @@ install -m644 contrib/redhat/sshd.pam-7.x $RPM_BUILD_ROOT/etc/pam.d/sshd %endif install -m755 contrib/redhat/sshd.init $RPM_BUILD_ROOT/etc/rc.d/init.d/sshd +install -m644 contrib/redhat/sshd-functions $RPM_BUILD_ROOT/etc/rc.d/init.d/sshd-functions %if ! %{no_x11_askpass} install -s x11-ssh-askpass-%{aversion}/x11-ssh-askpass $RPM_BUILD_ROOT/usr/libexec/openssh/x11-ssh-askpass @@ -261,6 +261,7 @@ %attr(0600,root,root) %config(noreplace) %{_sysconfdir}/sshd_config %attr(0600,root,root) %config(noreplace) /etc/pam.d/sshd %attr(0755,root,root) %config /etc/rc.d/init.d/sshd +%attr(0644,root,root) %config /etc/rc.d/init.d/sshd-functions %if ! %{no_x11_askpass} %files askpass @@ -279,6 +280,9 @@ %endif %changelog +* Sun Feb 18 2001 Jim Knoble +- Added compatibility functions for sshd initscript in sshd-functions. +- Removed dependency on initscripts >= 4.16. * Mon Oct 18 2000 Damien Miller - Merge some of Nalin Dahyabhai changes from the Redhat 7.0 spec file From jmknoble at jmknoble.cx Sun Feb 18 20:26:49 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Sun, 18 Feb 2001 04:26:49 -0500 Subject: Fix: PATCH: Round 2: RH initscripts backward compatibility In-Reply-To: <20010218032603.M25687@quipu.half.pint-stowp.cx>; from jmknoble@jmknoble.cx on Sun, Feb 18, 2001 at 03:26:03AM -0500 References: <20010218032603.M25687@quipu.half.pint-stowp.cx> Message-ID: <20010218042649.N25687@quipu.half.pint-stowp.cx> Circa 2001-Feb-18 03:26:03 -0500 dixit Jim Knoble: : I've cleaned up Pekka Savola's newly revised sshd.init and additional : sshd-functions and modified them to work they way i've been arguing : they should work. : : Compatibility functions are defined in ./contrib/redhat/sshd-functions, : which should get installed no matter what release of Red Hat Linux : OpenSSH is getting built for, to be consistent across releases. There's a problem in the localized() function in ./contrib/redhat/sshd-functions (contained in the patch i submitted earlier), where trailing whitespace disappears under bash-1.14.x. The attached patch, applied after the earlier one, fixes the problem. -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ -------------- next part -------------- --- ./openssh-SNAP-20010218/contrib/redhat/sshd-functions.orig-localfix Sun Feb 18 02:58:32 2001 +++ ./openssh-SNAP-20010218/contrib/redhat/sshd-functions Sun Feb 18 04:18:10 2001 @@ -3,16 +3,18 @@ # Compability functions for sshd initscript # Parts of my_action() are derived from Red Hat Linux 6.x initscripts. -# Handle arguments localized using $"..." construct, if that construct +# Handle argument localized using $"..." construct, if that construct # is not available in this version of bash. +# PARAMETERS: +# $1 => string possibly containing leading '$' to remove localized() { case "${BASH_VERSION}" in 1.*) # Remove leading '$' character. - echo "${@#$}" + echo "${1#$}" ;; *) - echo "$@" + echo "$1" ;; esac } From misiek at pld.ORG.PL Sun Feb 18 21:09:13 2001 From: misiek at pld.ORG.PL (Arkadiusz Miskiewicz) Date: Sun, 18 Feb 2001 11:09:13 +0100 Subject: Important fix (sshd && binding). Portable version only. In-Reply-To: ; from djm@mindrot.org on Sun, Feb 18, 2001 at 12:40:44PM +1100 References: Message-ID: <20010218110913.A2786@ikar.t17.ds.pwr.wroc.pl> On/Dnia Sun, Feb 18, 2001 at 12:40:44PM +1100, Damien Miller wrote/napisa?(a) > > i don't know why the test for !ai->ai_next was added? anyone? > It was a workaround for bugs in Linux's IPv6 support. Bug? Why you call this ,,bug''. This is standard behaviour at least on Linux and differences between Linux and *BSD are _only_ due to different interpretations of RFC. Unfortunately there is no well defined standard behaviour (btw. BSD can be configured to work in the same way as Linux and Linux with USAGI patch can work it the same way as BSD currently ;-) > | Damien Miller \ ``E-mail attachments are the poor man's -- Arkadiusz Mi?kiewicz, AM2-6BONE [ PLD GNU/Linux IPv6 ] http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/ [ enabled ] From pekkas at netcore.fi Sun Feb 18 21:14:11 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 18 Feb 2001 12:14:11 +0200 (EET) Subject: PATCH: Round 2: RH initscripts backward compatibility In-Reply-To: <20010218032603.M25687@quipu.half.pint-stowp.cx> Message-ID: On Sun, 18 Feb 2001, Jim Knoble wrote: > - Fixed several minor errors (e.g., some strings were missing $"..."). : : + echo -n $(localized $"Generating SSH1 RSA host key: ") [among other lines] If this can't be done in an RH-compatible fashion, I think this should be reverted to the old form 'echo -n "Generating SSH1 RSA host key: " for clarity && maintainibility, removing all localization. It's not like there's any i18n work going on with OpenSSH at the moment ;-) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From gert at greenie.muc.de Sun Feb 18 21:54:34 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 18 Feb 2001 11:54:34 +0100 Subject: OpenSSH 2.5.0p1 vs. SA_RESTART In-Reply-To: ; from Damien Miller on Sun, Feb 18, 2001 at 01:05:01PM +1100 References: <200102180103.f1I130I03344@xerxes.courtesan.com> Message-ID: <20010218115434.A25035@greenie.muc.de> Hi, On Sun, Feb 18, 2001 at 01:05:01PM +1100, Damien Miller wrote: > @@ -112,6 +112,10 @@ > if (sig == SIGCHLD) > sa.sa_flags |= SA_RESTART; > #endif > +#ifdef SA_INTERRUPT > + if (sig == SIGCHLD) > + sa.sa_flags |= SA_INTERRUPT; > +#endif Shouldn't SA_INTERRUPT do the exact opposite of SA_RESTART? SA_RESTART = restart system calls after a signal SA_INTERRUPT = do *not* restart (= interrupt) system calls - this would be consistent with the default settings, which on SunOS and the older BSDs is "restart always", while on SysV, it's "interrupt always". 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 Feb 18 21:56:46 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 18 Feb 2001 11:56:46 +0100 Subject: OpenSSH 2.5.0p1 In-Reply-To: ; from Tim Rice on Sat, Feb 17, 2001 at 03:29:49PM -0800 References: Message-ID: <20010218115646.C25035@greenie.muc.de> Hi, On Sat, Feb 17, 2001 at 03:29:49PM -0800, Tim Rice wrote: > Can anyone provide me with ssh access to an AIX machine to look into this? As it's a machine belonging to a customer, I can't, sorry :-( But I can try to answer all your questions :-) 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 Sun Feb 18 23:12:09 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 18 Feb 2001 13:12:09 +0100 Subject: OpenSSH 2.5.0p1 In-Reply-To: <20010217204744.G16740@cygbert.vinschen.de>; from vinschen@redhat.com on Sat, Feb 17, 2001 at 08:47:44PM +0100 References: <20010217005253.M13748@cygbert.vinschen.de> <20010217204744.G16740@cygbert.vinschen.de> Message-ID: <20010218131209.A23099@cygbert.vinschen.de> On Sat, Feb 17, 2001 at 08:47:44PM +0100, Corinna Vinschen wrote: > On Sat, Feb 17, 2001 at 12:52:53AM +0100, Corinna Vinschen wrote: > > However, I have only tested to be able to build and a call to > > scp. More testing will follow tomorrow. > > ssh, sshd and scp work fine. Unfortunately I can't connect to > sftp-server anymore, client and server both on Cygwin 1.1.8. > > What could be the reason here? > > ========== DEBUG ON ============ > /home/corinna [2]$ sftp -v -v -v corinna > Connecting to corinna... Ooops, just a user error. Sorry for making waves. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From djm at mindrot.org Mon Feb 19 00:06:10 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 19 Feb 2001 00:06:10 +1100 (EST) Subject: SSH2 PATH problem In-Reply-To: <00ea01c09971$05139ee0$1900a8c0@devn> Message-ID: On Sat, 17 Feb 2001, Devon Bleak wrote: > still broken on solaris 7 with pam enabled (works fine with pam disabled). > > on another note, scp also appears to be broken when the server side is > solaris 7 with pam enabled (works fine with pam disabled). i have ssh > falling under 'other' in pam.conf. > sshd -d -d -d output is attached for an scp attempt from a slackware 7.1 > machine also running latest cvs code (sorry about any CRLF formatting > issues, i created the files on a windows machine). How does scp fail (as seen from the client end)? The $PATH stuff has got me stumped though - I suspect that it may be PAM related, but the only change to the PAM code in the timeframe where people started reporting problems was the moving of the "account" processing from before to after the fork() in session.c. Are there any subtle Solaris PAM implementation issues that I am missing? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Mon Feb 19 00:13:03 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 19 Feb 2001 00:13:03 +1100 (EST) Subject: SSH2 PATH problem In-Reply-To: <00ea01c09971$05139ee0$1900a8c0@devn> Message-ID: On Sat, 17 Feb 2001, Devon Bleak wrote: > still broken on solaris 7 with pam enabled (works fine with pam disabled). > > on another note, scp also appears to be broken when the server side is > solaris 7 with pam enabled (works fine with pam disabled). i have ssh > falling under 'other' in pam.conf. > sshd -d -d -d output is attached for an scp attempt from a slackware 7.1 > machine also running latest cvs code (sorry about any CRLF formatting > issues, i created the files on a windows machine). You could also send the output of the "ssh -v -v -v -2 yourhost" along with the output of "ssh -d -d -d" of one of these sessions with the missing $PATH? I still haven't seen a full debug trace from the client and the server. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From janfrode at parallab.uib.no Mon Feb 19 00:28:26 2001 From: janfrode at parallab.uib.no (Jan-Frode Myklebust) Date: Sun, 18 Feb 2001 14:28:26 +0100 Subject: snapshot sftpserver In-Reply-To: <20010218010709.D10098@folly>; from markus.friedl@informatik.uni-erlangen.de on Sun, Feb 18, 2001 at 01:07:09AM +0100 References: <20010217214733.A12145@ii.uib.no> <20010218010709.D10098@folly> Message-ID: <20010218142826.A16524@ii.uib.no> On Sun, Feb 18, 2001 at 01:07:09AM +0100, Markus Friedl wrote: > > > % sftp buskfuru > > janfrode at bruse's password: > > sftp> Warning: ssh_packet_wrapper_input: invalid packet received: len > > 1466004082 closing the offending input channel. > > > > Any idea what's failing here? > > you probably have broken .bashrc or whatever files, > they should never every print to stdout if the > shell is not interactive. > Of course.. thanks. -jf From pekkas at netcore.fi Mon Feb 19 01:57:53 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 18 Feb 2001 16:57:53 +0200 (EET) Subject: sftp enhancements Message-ID: Hello all, Just tested sftp for the first time. Looks neat, thanks for the work :-) However, there's still some stuff to be done before ftp can be thrown into the garbage bin and never taken out again, for example: - file name globbing with e.g. 'get' - tab completion with get etc. - ability to pass parameters to 'ls', e.g. 'ls -t' (I'm not sure if the protocol supports this) - [chroot to the homedir after user authentication, server side issue] - ... But still -- now there's a working, free client available which is the most important thing. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From vinschen at redhat.com Mon Feb 19 04:05:58 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 18 Feb 2001 18:05:58 +0100 Subject: sftp client In-Reply-To: ; from djm@mindrot.org on Fri, Feb 09, 2001 at 01:26:00PM +1100 References: <20010208201359.E910@cygbert.vinschen.de> Message-ID: <20010218180558.C23099@cygbert.vinschen.de> On Fri, Feb 09, 2001 at 01:26:00PM +1100, Damien Miller wrote: > On Thu, 8 Feb 2001, Corinna Vinschen wrote: > > Session: > > > > $ sftp cvaio > > sftp> pwd > > /home/corinna > > sftp> ^D > > > > Log with ssh.com sftp: > > > > sftp-server : Cygwin Process Id = 0x63C : client version 2 > > sftp-server : Cygwin Process Id = 0x63C : realpath id 0 path . > > sftp-server : Cygwin Process Id = 0x63C : sent names id 0 count 1 > > > > Log with openssh sftp: > > > > sftp-server : Cygwin Process Id = 0x5D4 : client version 2 > > sftp-server : Cygwin Process Id = 0x5D4 : realpath id -1560921021 path . > > sftp-server : Cygwin Process Id = 0x5D4 : sent names id -1560921021 count 1 > > > > Is that helpful?!? > > Not really :( They are doing exactly the same thing. Perhaps there is a > difference in how they close the underlying ssh session. I have now further investigated the problem and found a solution to avoid the sftp-server hanging around. The OpenSSH sftp closes the sockets/pipes (dependent of the value of USE_PIPES) and then kills it's underlying ssh by calling kill(ssh, SIGHUP). This `kill' kills the underlying ssh immediately instead of giving time to cleanup. This results in breaking the connection to the sshd which in turn misses to cleanup it's connection to the subsystem. This has probably soemthing to do with the signal handling in Cygwin but, uhm, Cygwin isn't an OS but only a layer which tries to react as similar to POSIX systems as possible. OTOH isn't that a general problem in sshd, too? It should close it's connections to the subsystem always in a graceful way but it doesn't, obviously. However, I thought it shouldn't be needed to kill ssh but instead, ssh should realize that sftp has closed the connection. So I applied the following patch to sftp.c: Index: sftp.c =================================================================== RCS file: /cvs/openssh_cvs/sftp.c,v retrieving revision 1.4 diff -u -p -r1.4 sftp.c --- sftp.c 2001/02/09 13:40:04 1.4 +++ sftp.c 2001/02/18 16:59:27 @@ -246,11 +246,18 @@ main(int argc, char **argv) interactive_loop(in, out); +#if defined(HAVE_CYGWIN) && !defined(USE_PIPES) + shutdown(in, SHUT_RDWR); + shutdown(out, SHUT_RDWR); +#endif + close(in); close(out); +#if !defined(HAVE_CYGWIN) if (kill(sshpid, SIGHUP) == -1) fatal("Couldn't terminate ssh process: %s", strerror(errno)); +#endif if (waitpid(sshpid, NULL, 0) == -1) fatal("Couldn't wait for ssh process: %s", strerror(errno)); =================================================================== This solved the problem for both, using socketpair and for using pipes. Isn't a graceful shutdown always better in case of using sockets? And what's the reason for killing ssh instead of simply awaiting it's own normal exit? Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From pekkas at netcore.fi Mon Feb 19 04:24:45 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 18 Feb 2001 19:24:45 +0200 (EET) Subject: OpenSSH 2.3.0p1 protocol 2 problem with AIX Message-ID: Hi, Connecting from RHL7 with OpenSSH 2.3.0p1 or 2.5.0p1 to OpenSSH 2.3.0p1 on AIX 4.3.1. Protocol 2 doesn't work if you specify 'Ciphers rijndael128-cbc' or Ciphers 'aes128-cbc'. sshd -d -d -d on the server shows _nothing_ about these connections. I'm not sure if rijndael has been left out from sshd somehow, but shouldn't the error message be a little more specific? Short version: $ ssh ibmsp e6 13 54 23 89 c2 61 07 df 51 1d 1b 17 d3 3e 8f Disconnecting: Bad packet length -434940893. Longer version: $ ssh -v -v -v ibmsp SSH Version OpenSSH_2.5.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090581f). debug: Reading configuration data /home/psavola/.ssh/config debug: Reading configuration data /etc/ssh/ssh_config debug: cipher ok: rijndael128-cbc [rijndael128-cbc,aes128-cbc,arcfour,blowfish-cbc] debug: cipher ok: aes128-cbc [rijndael128-cbc,aes128-cbc,arcfour,blowfish-cbc] debug: cipher ok: arcfour [rijndael128-cbc,aes128-cbc,arcfour,blowfish-cbc] debug: cipher ok: blowfish-cbc [rijndael128-cbc,aes128-cbc,arcfour,blowfish-cbc] debug: ciphers ok: [rijndael128-cbc,aes128-cbc,arcfour,blowfish-cbc] debug: ssh_connect: getuid 154 geteuid 0 anon 0 debug: Connecting to ibmsp [193.166.7.65] port 22. debug: Allocated local port 1020. debug: Connection established. debug: identity file /home/psavola/.ssh/identity type 0 debug: Bad RSA1 key file /home/psavola/.ssh/id_dsa. debug: identity file /home/psavola/.ssh/id_dsa type 3 debug: Remote protocol version 1.99, remote software version OpenSSH_2.3.0p1 debug: match: OpenSSH_2.3.0p1 pat ^OpenSSH_2\.3\.0 Enabling compatibility mode for protocol 2.0 debug: Local version string SSH-2.0-OpenSSH_2.5.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,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: mac_init: found hmac-sha1 debug: kex: server->client rijndael128-cbc hmac-sha1 none debug: mac_init: found hmac-sha1 debug: kex: client->server rijndael128-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: 501/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 'ibmsp' is known and matches the DSA host key. debug: Found key in /home/psavola/.ssh/known_hosts2:132 debug: bits set: 488/1024 debug: len 55 datafellows 128 debug: ssh_dss_verify: signature correct debug: Wait SSH2_MSG_NEWKEYS. debug: GOT SSH2_MSG_NEWKEYS. debug: send SSH2_MSG_NEWKEYS. debug: done: send SSH2_MSG_NEWKEYS. debug: done: KEX2. debug: send SSH2_MSG_SERVICE_REQUEST ac 29 cf 66 5a cf ac f6 58 62 9a c7 25 dc 5c bf Disconnecting: Bad packet length -1406546074. debug: Calling cleanup 0x8060690(0x0) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From devon at admin2.gisnetworks.com Mon Feb 19 04:34:18 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Sun, 18 Feb 2001 09:34:18 -0800 Subject: SSH2 PATH problem References: Message-ID: <005101c099d1$05acd000$1900a8c0@devn> when i do a -v on scp, i just get "connecting to host...\nlost connection". with multiple v's i get the same thing :/ devon at admin2:~$ scp -v -v -v openssh-20010217.tar.gz hollywood: Executing: program /usr/bin/ssh host hollywood, user (unspecified), command scp -v -t . lost connection devon ----- Original Message ----- From: "Damien Miller" To: "Devon Bleak" Cc: "Tim Rice" ; "Jean-Marc Beroud" ; Sent: Sunday, February 18, 2001 5:06 AM Subject: Re: SSH2 PATH problem > On Sat, 17 Feb 2001, Devon Bleak wrote: > > > still broken on solaris 7 with pam enabled (works fine with pam disabled). > > > > on another note, scp also appears to be broken when the server side is > > solaris 7 with pam enabled (works fine with pam disabled). i have ssh > > falling under 'other' in pam.conf. > > sshd -d -d -d output is attached for an scp attempt from a slackware 7.1 > > machine also running latest cvs code (sorry about any CRLF formatting > > issues, i created the files on a windows machine). > > How does scp fail (as seen from the client end)? > > The $PATH stuff has got me stumped though - I suspect that it may be PAM > related, but the only change to the PAM code in the timeframe where people > started reporting problems was the moving of the "account" processing from > before to after the fork() in session.c. Are there any subtle > Solaris PAM implementation issues that I am missing? > > -d > > -- > | Damien Miller \ ``E-mail attachments are the poor man's > | http://www.mindrot.org / distributed filesystem'' - Dan Geer > > From mhw at wittsend.com Mon Feb 19 04:56:06 2001 From: mhw at wittsend.com (Michael H. Warfield) Date: Sun, 18 Feb 2001 12:56:06 -0500 Subject: Minor request... Message-ID: <20010218125606.C13551@alcove.wittsend.com> Hey all, Was just on another mailing list clearing up some confusion about an error message that OpenSSH (and maybe others) often generates. The error message is this: > Feb 17 22:32:23 swshost sshd[2472]: Did not receive ident string from 210.104.181.1. People seem to commonly assume that the "ident string" is referring to identd/authd queries and not the client identification string. Since this is common with port scanning and telnet probes and is associated with security issues, this causes a few discussions and wild goose chases. Could we possibly have that reworded a bit to be a little less confusing? Maybe something like this: Did not receive ssh client identification string from... Or maybe add a remark about possible port probing or something. Would this cause any heartburn elsewhere (log monitors, sentries, etc...) or any compatibility problems? Would appear to me to be largely cosmetic (and, yes, low priority), but low risk and easy to change. Mike -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From devon at admin2.gisnetworks.com Mon Feb 19 05:12:17 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Sun, 18 Feb 2001 10:12:17 -0800 Subject: SSH2 PATH problem References: Message-ID: <00a201c099d6$542b9f90$1900a8c0@devn> both are attached. devon ----- Original Message ----- From: "Damien Miller" To: "Devon Bleak" Cc: "Tim Rice" ; "Jean-Marc Beroud" ; Sent: Sunday, February 18, 2001 5:13 AM Subject: Re: SSH2 PATH problem > On Sat, 17 Feb 2001, Devon Bleak wrote: > > > still broken on solaris 7 with pam enabled (works fine with pam disabled). > > > > on another note, scp also appears to be broken when the server side is > > solaris 7 with pam enabled (works fine with pam disabled). i have ssh > > falling under 'other' in pam.conf. > > sshd -d -d -d output is attached for an scp attempt from a slackware 7.1 > > machine also running latest cvs code (sorry about any CRLF formatting > > issues, i created the files on a windows machine). > > You could also send the output of the "ssh -v -v -v -2 yourhost" > along with the output of "ssh -d -d -d" of one of these sessions with the > missing $PATH? > > I still haven't seen a full debug trace from the client and the server. > > -d > > -- > | Damien Miller \ ``E-mail attachments are the poor man's > | http://www.mindrot.org / distributed filesystem'' - Dan Geer > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ssh-v-v-v.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010218/a8ddf4b3/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sshd-d-d-d2.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010218/a8ddf4b3/attachment-0001.txt From mouring at etoh.eviladmin.org Mon Feb 19 06:18:49 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 18 Feb 2001 13:18:49 -0600 (CST) Subject: AIX and login.[ch]/pty.[ch] Message-ID: I just commited a patch to change: login.[ch] -> sshlogin.[ch] pty.[ch] -> sshpty.[ch] This should resolve the AIX issues and the warnings about openpty() not being defined. - Ben From jmknoble at jmknoble.cx Mon Feb 19 07:50:38 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Sun, 18 Feb 2001 15:50:38 -0500 Subject: PATCH: Round 2: RH initscripts backward compatibility In-Reply-To: ; from pekkas@netcore.fi on Sun, Feb 18, 2001 at 12:14:11PM +0200 References: <20010218032603.M25687@quipu.half.pint-stowp.cx> Message-ID: <20010218155038.O25687@quipu.half.pint-stowp.cx> Circa 2001-Feb-18 12:14:11 +0200 dixit Pekka Savola: : On Sun, 18 Feb 2001, Jim Knoble wrote: : : + echo -n $(localized $"Generating SSH1 RSA host key: ") : [among other lines] : : If this can't be done in an RH-compatible fashion, I think this should be : reverted to the old form 'echo -n "Generating SSH1 RSA host key: " for : clarity && maintainibility, removing all localization. : : It's not like there's any i18n work going on with OpenSSH at the moment : ;-) Pekka, you're the one who wanted localized strings with $"...". I simply made them work everywhere. I don't see anything wrong with them (except that, as you point out, there doesn't appear to be any actual localized text to replace the strings with...). If you prefer, i can rename the localized() function to something less obvious, such as __(). Or if you don't want localiz(ed|able) strings, perhaps this could be made even less complex. I don't understand what you mean by "Red-Hat-compatible" ... it may look a little different than most init.d scripts, but, as i've pointed out before, it *already* looks a little different from most of them. In fact, as it turns out, doing things properly sometimes looks a bit different from what is implemented by Red Hat (or SuSE, or Caldera, or TurboLinux, or Connectiva, or the Linux Router Project, or your favorite unlisted distribution "vendor"). We should not be afraid to do things properly even if they're slightly different from what the OS vendor does. It can provide good example to the vendor. :) -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From djm at mindrot.org Mon Feb 19 09:33:08 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 19 Feb 2001 09:33:08 +1100 (EST) Subject: sftp enhancements In-Reply-To: Message-ID: On Sun, 18 Feb 2001, Pekka Savola wrote: > Hello all, > > Just tested sftp for the first time. Looks neat, thanks for the work :-) > > However, there's still some stuff to be done before ftp can be thrown into > the garbage bin and never taken out again, for example: This pretty much mirrors my TODO list: sftp - implement readahead for copies - globbed remote ls - recursive operations - commandline interface - fix up error reporting - use libedit for history - tab-completion (maybe?) -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Mon Feb 19 09:35:40 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 19 Feb 2001 09:35:40 +1100 (EST) Subject: SSH2 PATH problem In-Reply-To: <005101c099d1$05acd000$1900a8c0@devn> Message-ID: On Sun, 18 Feb 2001, Devon Bleak wrote: > when i do a -v on scp, i just get "connecting to host...\nlost connection". > with multiple v's i get the same thing :/ > > devon at admin2:~$ scp -v -v -v openssh-20010217.tar.gz hollywood: > Executing: program /usr/bin/ssh host hollywood, user (unspecified), command > scp -v -t . > lost connection Can you try ssh -v -v -v hollywood scp -v -t . and report what it says? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Mon Feb 19 09:43:36 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 19 Feb 2001 09:43:36 +1100 (EST) Subject: SSH2 PATH problem In-Reply-To: <00a201c099d6$542b9f90$1900a8c0@devn> Message-ID: On Sun, 18 Feb 2001, Devon Bleak wrote: > both are attached. Thanks, unfortunately I can't see the anything amiss in the traces. Could you send me the output of a "ssh -v -v -v yourhost" logging into a "sshd -d -d -d". Thanks -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From devon at admin2.gisnetworks.com Mon Feb 19 10:34:02 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Sun, 18 Feb 2001 15:34:02 -0800 Subject: SSH2 PATH problem References: Message-ID: <02e601c09a03$46e97be0$1900a8c0@devn> attached. devon ----- Original Message ----- From: "Damien Miller" To: "Devon Bleak" Cc: "Tim Rice" ; "Jean-Marc Beroud" ; Sent: Sunday, February 18, 2001 2:35 PM Subject: Re: SSH2 PATH problem > On Sun, 18 Feb 2001, Devon Bleak wrote: > > > when i do a -v on scp, i just get "connecting to host...\nlost connection". > > with multiple v's i get the same thing :/ > > > > devon at admin2:~$ scp -v -v -v openssh-20010217.tar.gz hollywood: > > Executing: program /usr/bin/ssh host hollywood, user (unspecified), command > > scp -v -t . > > lost connection > > Can you try > > ssh -v -v -v hollywood scp -v -t . > > and report what it says? > > -d > > -- > | Damien Miller \ ``E-mail attachments are the poor man's > | http://www.mindrot.org / distributed filesystem'' - Dan Geer > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ssh-v-v-v2.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010218/8b9e2f65/attachment.txt From devon at admin2.gisnetworks.com Mon Feb 19 10:38:12 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Sun, 18 Feb 2001 15:38:12 -0800 Subject: SSH2 PATH problem References: Message-ID: <02f501c09a03$dc04dee0$1900a8c0@devn> i've attached the output from both the client and server side. devon ----- Original Message ----- From: "Damien Miller" To: "Devon Bleak" Cc: "Tim Rice" ; "Jean-Marc Beroud" ; Sent: Sunday, February 18, 2001 2:43 PM Subject: Re: SSH2 PATH problem > On Sun, 18 Feb 2001, Devon Bleak wrote: > > > both are attached. > > Thanks, unfortunately I can't see the anything amiss in the traces. > > Could you send me the output of a "ssh -v -v -v yourhost" logging into > a "sshd -d -d -d". > > Thanks > > -d > > -- > | Damien Miller \ ``E-mail attachments are the poor man's > | http://www.mindrot.org / distributed filesystem'' - Dan Geer > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ssh-v-v-vlogin.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010218/90d9333b/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sshd-d-d-dlogin.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010218/90d9333b/attachment-0001.txt From djm at mindrot.org Mon Feb 19 10:41:27 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 19 Feb 2001 10:41:27 +1100 (EST) Subject: SSH2 PATH problem In-Reply-To: <02f501c09a03$dc04dee0$1900a8c0@devn> Message-ID: On Sun, 18 Feb 2001, Devon Bleak wrote: > i've attached the output from both the client and server side. Strange - PATH is definately getting set. What does a "env | grep PATH" say immediately after login? Do you have "UseLogin yes" set in your server config? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From pekkas at netcore.fi Mon Feb 19 12:43:14 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 19 Feb 2001 03:43:14 +0200 (EET) Subject: PATCH: Round 2: RH initscripts backward compatibility In-Reply-To: <20010218155038.O25687@quipu.half.pint-stowp.cx> Message-ID: On Sun, 18 Feb 2001, Jim Knoble wrote: > Circa 2001-Feb-18 12:14:11 +0200 dixit Pekka Savola: > > : On Sun, 18 Feb 2001, Jim Knoble wrote: > : : + echo -n $(localized $"Generating SSH1 RSA host key: ") > : [among other lines] > : > : If this can't be done in an RH-compatible fashion, I think this should be > : reverted to the old form 'echo -n "Generating SSH1 RSA host key: " for > : clarity && maintainibility, removing all localization. > : > : It's not like there's any i18n work going on with OpenSSH at the moment > : ;-) > > Pekka, you're the one who wanted localized strings with $"...". I > simply made them work everywhere. I don't see anything wrong with them > (except that, as you point out, there doesn't appear to be any actual > localized text to replace the strings with...). I don't really care too much about localization, but I do care if it looks the same as a "downstream" copy if there aren't obvious reasons why it shouldn't. The complexity of the above sickens me: echo -n $(localized $"Generating SSH1 RSA host key: ") vs. echo -n $"Generating SSH1 RSA host key: " vs. echo -n "Generating SSH1 RSA host key: " With the first form, when someone edits the file to add something, I can already see him forgetting the closing ')' etc. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From devon at admin2.gisnetworks.com Mon Feb 19 13:17:11 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Sun, 18 Feb 2001 18:17:11 -0800 Subject: SSH2 PATH problem References: Message-ID: <003301c09a1a$11ba67b0$1900a8c0@devn> $ env | grep PATH PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/ucb:/usr/ccs/bin i have '#UseLogin no' in the sshd_config. if i make it 'UseLogin yes' (uncomment it and s/no/yes/), it breaks with: devon at admin2:~$ ssh hollywood No utmpx entry. You must exec "login" from the lowest level "shell". Connection to hollywood closed. i have /bin/sh as my shell. i can post the full config file if you want (it's mostly just the default, with protocol 1 turned off, root login disallowed, and the sftp subsystem enabled), and the full pam.conf (solaris 7 default, afaik) if that'll help. (and more ssh -v's and sshd -d's ;) devon ----- Original Message ----- From: "Damien Miller" To: "Devon Bleak" Cc: "Tim Rice" ; "Jean-Marc Beroud" ; Sent: Sunday, February 18, 2001 3:41 PM Subject: Re: SSH2 PATH problem > On Sun, 18 Feb 2001, Devon Bleak wrote: > > > i've attached the output from both the client and server side. > > Strange - PATH is definately getting set. What does a "env | grep PATH" > say immediately after login? > > Do you have "UseLogin yes" set in your server config? > > -d > > -- > | Damien Miller \ ``E-mail attachments are the poor man's > | http://www.mindrot.org / distributed filesystem'' - Dan Geer > > > From alex at foogod.com Mon Feb 19 14:38:56 2001 From: alex at foogod.com (alex at foogod.com) Date: Sun, 18 Feb 2001 19:38:56 -0800 Subject: Dubious use of BN_num_bits in sshconnect1.c Message-ID: <20010218193856.D22936@draco.foogod.com> Hiho... I have recently encountered problems using OpenSSH 2.3.0p1 to connect to a SSH 1.2.20 server, with messages such as the following: Warning: Server lies about size of server public key: actual size is 1151 bits vs. announced 1152. Warning: This may be due to an old implementation of ssh. respond_to_rsa_challenge: public_key 1151 < host_key 1024 + SSH_KEY_BITS_RESERVED 128 ..and a resulting refusal to continue. I've done a bit of digging in the source, and have found the source of the problem to be the use of BN_num_bits to determine the length of the keys received in sshconnect1.c. The problem is that BN_num_bits does not return the number of significant bits of a given bignum, but rather the position of the most significant 1 bit, which is not necessarily the same thing. It is perfectly possible (and as demonstrated, does occur) for the remote end to generate an N-bit public key where the most significant bit is zero. When this occurs, BN_num_bits returns a smaller number than the actual key size, but this number is erroneously used to check against key size requirements. (this brings up a related flaw in the BN_rand/BN_pseudo_rand (which is the reason this bug doesn't show up with OpenSSH servers) in that when called to generate an N-bit (pseudo)random number, these functions actually return N-1 bits of random data, with the msb set to 1, instead of the N random bits promised, but that's a side issue) So.. I've put together a patch which I'm currently testing to fix this problem (it's taking a bit of time tho as the issue only pops up intermittently), but I have a couple of questions: 1) Am I missing something here which would make the use of BN_num_bits actually correct in this context, or is this just a bug? 2) Why are the checks for "Server lies about ..." present? I understand the need for the "respond_to_rsa_challenge" check, but I'm assuming the other key size validation attempts are due to some known issue with older SSH server implementations generating incorrectly-sized keys? Could someone provide some details of exactly what the issue is that prompted these checks? I also note that BN_num_bits appears to be used in several other places throughout the source. In many cases this is probably not an issue, but it's possible there are a few other places that could suffer from incorrect results because of this.. -alex From tim at multitalents.net Mon Feb 19 15:14:39 2001 From: tim at multitalents.net (Tim Rice) Date: Sun, 18 Feb 2001 20:14:39 -0800 (PST) Subject: SSH2 PATH problem In-Reply-To: Message-ID: Another data point. I did a truss of sshd while doing a "ssh -2 sun1 'echo $PATH'" from another machine This part looked strange. Maybe it will help, maybe not. ... 26814: fcntl(9, F_DUP2FD, 0x00000000) = 0 26814: fcntl(9, F_DUP2FD, 0x00000001) = 1 26814: fcntl(11, F_DUP2FD, 0x00000002) = 2 26814: stat64("/usr/lib/security/pam_unix.so.1", 0xEFFFE918) = 0 26814: door_info(4, 0xEFFFDCA8) = 0 26814: door_call(4, 0xEFFFDC90) = 0 26814: open("/var/adm/lastlog", O_RDWR|O_CREAT, 0444) = 6 26814: llseek(6, 868, SEEK_SET) = 868 26814: time() = 982551514 26814: Incurred fault #6, FLTBOUNDS %pc = 0xEF4B361C 26814: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000005 26814: Received signal #11, SIGSEGV [default] 26814: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000005 26814: *** process killed *** 26784: Received signal #18, SIGCLD [caught] 26784: siginfo: SIGCLD CLD_KILLED pid=26814 status=0x000B 26784: sigaction(SIGCLD, 0x00000000, 0xEFFFEF70) = 0 26784: setcontext(0xEFFFF0F0) 26784: getsockname(8, 0xEFFFF120, 0xEFFFF11C, 1) = 0 26784: setsockopt(8, 0, 3, 0xEFFFF294, 4, 1) = 0 26784: close(9) = 0 26784: close(11) = 0 ... -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From Markus.Friedl at informatik.uni-erlangen.de Mon Feb 19 19:39:19 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 19 Feb 2001 09:39:19 +0100 Subject: OpenSSH 2.3.0p1 protocol 2 problem with AIX In-Reply-To: ; from pekkas@netcore.fi on Sun, Feb 18, 2001 at 07:24:45PM +0200 References: Message-ID: <20010219093919.A14749@faui02.informatik.uni-erlangen.de> in 2.3.0p1 rindael/aes is broken on bigendian machines. On Sun, Feb 18, 2001 at 07:24:45PM +0200, Pekka Savola wrote: > Hi, > > Connecting from RHL7 with OpenSSH 2.3.0p1 or 2.5.0p1 to OpenSSH 2.3.0p1 on > AIX 4.3.1. Protocol 2 doesn't work if you specify 'Ciphers > rijndael128-cbc' or Ciphers 'aes128-cbc'. > > sshd -d -d -d on the server shows _nothing_ about these connections. > > I'm not sure if rijndael has been left out from sshd somehow, but > shouldn't the error message be a little more specific? > > Short version: > > $ ssh ibmsp > e6 13 54 23 89 c2 61 07 df 51 1d 1b 17 d3 3e 8f > Disconnecting: Bad packet length -434940893. > > Longer version: > > $ ssh -v -v -v ibmsp > SSH Version OpenSSH_2.5.0p1, protocol versions 1.5/2.0. > Compiled with SSL (0x0090581f). > debug: Reading configuration data /home/psavola/.ssh/config > debug: Reading configuration data /etc/ssh/ssh_config > debug: cipher ok: rijndael128-cbc > [rijndael128-cbc,aes128-cbc,arcfour,blowfish-cbc] > debug: cipher ok: aes128-cbc > [rijndael128-cbc,aes128-cbc,arcfour,blowfish-cbc] > debug: cipher ok: arcfour > [rijndael128-cbc,aes128-cbc,arcfour,blowfish-cbc] > debug: cipher ok: blowfish-cbc > [rijndael128-cbc,aes128-cbc,arcfour,blowfish-cbc] > debug: ciphers ok: [rijndael128-cbc,aes128-cbc,arcfour,blowfish-cbc] > debug: ssh_connect: getuid 154 geteuid 0 anon 0 > debug: Connecting to ibmsp [193.166.7.65] port 22. > debug: Allocated local port 1020. > debug: Connection established. > debug: identity file /home/psavola/.ssh/identity type 0 > debug: Bad RSA1 key file /home/psavola/.ssh/id_dsa. > debug: identity file /home/psavola/.ssh/id_dsa type 3 > debug: Remote protocol version 1.99, remote software version > OpenSSH_2.3.0p1 > debug: match: OpenSSH_2.3.0p1 pat ^OpenSSH_2\.3\.0 > Enabling compatibility mode for protocol 2.0 > debug: Local version string SSH-2.0-OpenSSH_2.5.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,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: mac_init: found hmac-sha1 > debug: kex: server->client rijndael128-cbc hmac-sha1 none > debug: mac_init: found hmac-sha1 > debug: kex: client->server rijndael128-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: 501/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 'ibmsp' is known and matches the DSA host key. > debug: Found key in /home/psavola/.ssh/known_hosts2:132 > debug: bits set: 488/1024 > debug: len 55 datafellows 128 > debug: ssh_dss_verify: signature correct > debug: Wait SSH2_MSG_NEWKEYS. > debug: GOT SSH2_MSG_NEWKEYS. > debug: send SSH2_MSG_NEWKEYS. > debug: done: send SSH2_MSG_NEWKEYS. > debug: done: KEX2. > debug: send SSH2_MSG_SERVICE_REQUEST > ac 29 cf 66 5a cf ac f6 58 62 9a c7 25 dc 5c bf > Disconnecting: Bad packet length -1406546074. > debug: Calling cleanup 0x8060690(0x0) > > > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > From carl at bl.echidna.id.au Mon Feb 19 19:45:11 2001 From: carl at bl.echidna.id.au (carl at bl.echidna.id.au) Date: Mon, 19 Feb 2001 19:45:11 +1100 (EST) Subject: 2.5.0p1 is listed, but doesn't exist Message-ID: <200102190845.f1J8jBW00895@rollcage.bl.echidna.id.au> I've been following a bit of the 2.5.0p1 threads, and checked out the openssh.org webpage today. 2.5.0 is out, and there's links to a non-existant 2.5.0p1, for all the archive sites. What's the story? I'm guessing that the web page is in error, should someone be asked to fix it? Carl From vinschen at redhat.com Mon Feb 19 20:36:41 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 19 Feb 2001 10:36:41 +0100 Subject: [PATCH]: Broken scp -p option Message-ID: <20010219103641.F908@cygbert.vinschen.de> Hi, I have found an serious problem when using 'scp -rp'. The usage of the static buffer "namebuf" together with calling `sink()' recursively results in overwriting the buffer np points to. This in turn results in a broken call to `ulimits()' and `chmod'. This patch solves the problem: Index: scp.c =================================================================== RCS file: /cvs/openssh_cvs/scp.c,v retrieving revision 1.56 diff -u -p -r1.56 scp.c --- scp.c 2001/02/18 03:55:16 1.56 +++ scp.c 2001/02/19 09:31:27 @@ -802,16 +802,16 @@ sink(argc, argv) } vect[0] = xstrdup(np); sink(1, vect); - if (vect[0]) - xfree(vect[0]); if (setimes) { setimes = 0; - if (utimes(np, tv) < 0) + if (utimes(vect[0], tv) < 0) run_err("%s: set times: %s", - np, strerror(errno)); + vect[0], strerror(errno)); } if (mod_flag) - (void) chmod(np, mode); + (void) chmod(vect[0], mode); + if (vect[0]) + xfree(vect[0]); continue; } omode = mode; Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From han.holl at prismant.nl Mon Feb 19 21:14:40 2001 From: han.holl at prismant.nl (Han Holl) Date: Mon, 19 Feb 2001 11:14:40 +0100 Subject: Restarting with kill -HUP Message-ID: <01021911144001.00458@bever.palga.uucp> Hi, If sshd is started with 'sshd', restarting with kill -HUP will fail. I've included the most obvious patch, but making sure that the full pathname is in saved_argv[0] just might be more secure. Cheers, Han Holl --- sshd.c.orig Mon Feb 19 10:55:54 2001 +++ sshd.c Mon Feb 19 10:56:15 2001 @@ -208,7 +208,7 @@ { log("Received SIGHUP; restarting."); close_listen_socks(); - execv(saved_argv[0], saved_argv); + execvp(saved_argv[0], saved_argv); log("RESTART FAILED: av0='%s', error: %s.", av0, strerror(errno)); exit(1); } From paulsen at orbiteam.de Mon Feb 19 21:10:56 2001 From: paulsen at orbiteam.de (Volker Paulsen) Date: Mon, 19 Feb 2001 11:10:56 +0100 Subject: SNAP 20010213 Bug: ssh-agent environment Message-ID: <20010219111056.A1600@mail.orbiteam.de> Hi, JFYI, I discovered the following bug in SNAP 20010213 ssh-agent: It does not inherit its environment if it is invoked as ssh-agent command > ssh-agent -V ssh-agent: illegal option -- V ssh-agent version OpenSSH_2.3.2p1 Usage: ssh-agent [-c | -s] [-k] [command {args...]] > ssh-agent /bin/sh $ env SSH_AGENT_PID=19437 $ I compiled ssh on: SunOS tarifa 5.8 Generic_108528-04 sun4u sparc SUNW,Ultra-5_10 Probably you already fixed this one, Regards, Volker Paulsen -- OrbiTeam Software GmbH http://www.orbiteam.de/ Rathausalle 10 phone: +49 2241 14-3704 D-53757 Sankt Augustin fax: +49 2241 14-3701 From djm at mindrot.org Mon Feb 19 21:26:41 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 19 Feb 2001 21:26:41 +1100 (EST) Subject: 2.5.0p1 is listed, but doesn't exist In-Reply-To: <200102190845.f1J8jBW00895@rollcage.bl.echidna.id.au> Message-ID: On Mon, 19 Feb 2001 carl at bl.echidna.id.au wrote: > > I've been following a bit of the 2.5.0p1 threads, and checked out the > openssh.org webpage today. Very soon. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Mon Feb 19 21:27:54 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 19 Feb 2001 21:27:54 +1100 (EST) Subject: SNAP 20010213 Bug: ssh-agent environment In-Reply-To: <20010219111056.A1600@mail.orbiteam.de> Message-ID: On Mon, 19 Feb 2001, Volker Paulsen wrote: > Hi, > > JFYI, I discovered the following bug in SNAP 20010213 ssh-agent: > > It does not inherit its environment if it is invoked as > > ssh-agent command > > > ssh-agent -V > ssh-agent: illegal option -- V > ssh-agent version OpenSSH_2.3.2p1 > Usage: ssh-agent [-c | -s] [-k] [command {args...]] > > ssh-agent /bin/sh > $ env > SSH_AGENT_PID=19437 Can't replicate this - I get a full env. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From jmknoble at jmknoble.cx Mon Feb 19 21:45:20 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Mon, 19 Feb 2001 05:45:20 -0500 Subject: PATCH: Round 3: RH initscripts backward compatibility In-Reply-To: ; from pekkas@netcore.fi on Mon, Feb 19, 2001 at 03:43:14AM +0200 References: <20010218155038.O25687@quipu.half.pint-stowp.cx> Message-ID: <20010219054520.T25687@quipu.half.pint-stowp.cx> Circa 2001-Feb-19 03:43:14 +0200 dixit Pekka Savola: : I don't really care too much about localization, but I do care if it : looks the same as a "downstream" copy if there aren't obvious : reasons why it shouldn't. Fine. Attached is Round 3, this time against SNAP-20010219. All of the $"..." constructs have been removed, as has the localized() function. Everything else is pretty much the same as Round 2 (quo vide), except: - ssd.init: 'reload' action moved to its own function, sshd_reload(), for consistency. - sshd.init: Removed double quotes around value of 'PROG' shell variable, also for consistency. -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From jmknoble at jmknoble.cx Mon Feb 19 21:48:13 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Mon, 19 Feb 2001 05:48:13 -0500 Subject: PATCH: Round 3: RH initscripts backward compatibility In-Reply-To: <20010219054520.T25687@quipu.half.pint-stowp.cx>; from jmknoble@jmknoble.cx on Mon, Feb 19, 2001 at 05:45:20AM -0500 References: <20010218155038.O25687@quipu.half.pint-stowp.cx> <20010219054520.T25687@quipu.half.pint-stowp.cx> Message-ID: <20010219054813.U25687@quipu.half.pint-stowp.cx> Circa 2001-Feb-19 05:45:20 -0500 dixit Jim Knoble: : Attached is Round 3 Except that the mail client forgot to check for the word 'attach' in the message text again, and allowed me to send it out attachmentless. :S -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ -------------- next part -------------- --- ./openssh-SNAP-20010219/contrib/redhat/sshd.init.orig-init Mon Nov 13 06:57:27 2000 +++ ./openssh-SNAP-20010219/contrib/redhat/sshd.init Mon Feb 19 05:40:17 2001 @@ -1,5 +1,5 @@ #!/bin/bash - +# # Init file for OpenSSH server daemon # # chkconfig: 2345 55 25 @@ -13,105 +13,144 @@ # pidfile: /var/run/sshd.pid # source function library -. /etc/rc.d/init.d/functions +# If the file exists, but is not readable, it's an error. +# Likewise, if the fallback file doesn't exist, it's an error. +if [ -f /etc/init.d/sshd-functions ]; then + . /etc/init.d/functions +else + . /etc/rc.d/init.d/functions +fi +if [ $? -ne 0 ]; then + exit 1 +fi + +# Define compatibility functions used in this init script +# If the file exists, but is not readable, it's an error. +# Likewise, if the fallback file doesn't exist, it's an error. +if [ -f /etc/init.d/sshd-functions ]; then + . /etc/init.d/sshd-functions +else + . /etc/rc.d/init.d/sshd-functions +fi +if [ $? -ne 0 ]; then + exit 1 +fi RETVAL=0 -# Some functions to make the below more readable +PROG=sshd +SSHD=/usr/sbin/sshd KEYGEN=/usr/bin/ssh-keygen RSA1_KEY=/etc/ssh/ssh_host_key RSA_KEY=/etc/ssh/ssh_host_rsa_key DSA_KEY=/etc/ssh/ssh_host_dsa_key PID_FILE=/var/run/sshd.pid -do_rsa1_keygen() { - if ! test -f $RSA1_KEY ; then +LOCKFILE=/var/lock/subsys/sshd + +# Define some functions to make the below more readable +sshd_do_rsa1_keygen() { + if [ ! -s "${RSA1_KEY}" ]; then echo -n "Generating SSH1 RSA host key: " - if $KEYGEN -q -t rsa1 -f $RSA1_KEY -C '' -N '' >&/dev/null; then - success "RSA1 key generation" + if "${KEYGEN}" -q -t rsa1 -f "${RSA1_KEY}" -C '' -N '' \ + &>/dev/null + then + my_success "RSA1 key generation" echo else - failure "RSA1 key generation" + my_failure "RSA1 key generation" echo exit 1 fi fi } -do_rsa_keygen() { - if ! test -f $RSA_KEY ; then + +sshd_do_rsa_keygen() { + if [ ! -s "${RSA_KEY}" ]; then echo -n "Generating SSH2 RSA host key: " - if $KEYGEN -q -t rsa -f $RSA_KEY -C '' -N '' >&/dev/null; then - success "RSA key generation" + if "${KEYGEN}" -q -t rsa -f "${RSA_KEY}" -C '' -N '' \ + &>/dev/null + then + my_success "RSA key generation" echo else - failure "RSA key generation" + my_failure "RSA key generation" echo exit 1 fi fi } -do_dsa_keygen() { - if ! test -f $DSA_KEY ; then + +sshd_do_dsa_keygen() { + if [ ! -s "${DSA_KEY}" ]; then echo -n "Generating SSH2 DSA host key: " - if $KEYGEN -q -t dsa -f $DSA_KEY -C '' -N '' >&/dev/null; then - success "DSA key generation" + if "${KEYGEN}" -q -t dsa -f "${DSA_KEY}" -C '' -N '' \ + &>/dev/null + then + my_success "DSA key generation" echo else - failure "DSA key generation" + my_failure "DSA key generation" echo exit 1 fi fi } +sshd_start() +{ + # Create keys if necessary + sshd_do_rsa1_keygen + sshd_do_rsa_keygen + sshd_do_dsa_keygen + + my_action "Starting ${PROG}: " "${PROG}" "" "${SSHD}" + RETVAL=$? + [ "${RETVAL}" = 0 ] && touch "${LOCKFILE}" +} + +sshd_stop() +{ + echo -n "Stopping ${PROG}: " + killproc "${SSHD}" + RETVAL=$? + echo + [ "${RETVAL}" = 0 ] && rm -f "${LOCKFILE}" +} + +sshd_reload() +{ + echo -n "Reloading ${PROG}: " + killproc "${SSHD}" -HUP + RETVAL=$? + echo +} + case "$1" in start) - # Create keys if necessary - do_rsa1_keygen; - do_rsa_keygen; - do_dsa_keygen; - - echo -n "Starting sshd: " - if [ ! -f $PID_FILE ] ; then - sshd - RETVAL=$? - if [ "$RETVAL" = "0" ] ; then - success "sshd startup" - touch /var/lock/subsys/sshd - else - failure "sshd startup" - fi - fi - echo + sshd_start ;; stop) - echo -n "Shutting down sshd: " - if [ -f $PID_FILE ] ; then - killproc sshd - RETVAL=$? - [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/sshd - fi - echo + sshd_stop ;; restart) - $0 stop - $0 start - RETVAL=$? + sshd_stop + sshd_start + ;; + reload) + sshd_reload ;; condrestart) - if [ -f /var/lock/subsys/sshd ] ; then - $0 stop - $0 start - RETVAL=$? + if [ -f "${LOCKFILE}" ] ; then + sshd_stop + sshd_start fi ;; status) - status sshd + status "${SSHD}" RETVAL=$? ;; *) - echo "Usage: sshd {start|stop|restart|status|condrestart}" - exit 1 - ;; + echo "Usage: $0 {start|stop|restart|reload|condrestart|status}" + RETVAL=1 esac - -exit $RETVAL +exit ${RETVAL} --- ./openssh-SNAP-20010219/contrib/redhat/openssh.spec.orig-init Sat Feb 17 23:43:07 2001 +++ ./openssh-SNAP-20010219/contrib/redhat/openssh.spec Mon Feb 19 05:24:02 2001 @@ -57,7 +57,6 @@ Group: System Environment/Daemons Obsoletes: ssh-server PreReq: openssh = %{version}-%{release}, chkconfig >= 0.9 -Requires: initscripts >= 4.16 %package askpass Summary: OpenSSH X11 passphrase dialog @@ -195,6 +194,7 @@ install -m644 contrib/redhat/sshd.pam-7.x $RPM_BUILD_ROOT/etc/pam.d/sshd %endif install -m755 contrib/redhat/sshd.init $RPM_BUILD_ROOT/etc/rc.d/init.d/sshd +install -m644 contrib/redhat/sshd-functions $RPM_BUILD_ROOT/etc/rc.d/init.d/sshd-functions %if ! %{no_x11_askpass} install -s x11-ssh-askpass-%{aversion}/x11-ssh-askpass $RPM_BUILD_ROOT/usr/libexec/openssh/x11-ssh-askpass @@ -261,6 +261,7 @@ %attr(0600,root,root) %config(noreplace) %{_sysconfdir}/sshd_config %attr(0600,root,root) %config(noreplace) /etc/pam.d/sshd %attr(0755,root,root) %config /etc/rc.d/init.d/sshd +%attr(0644,root,root) %config /etc/rc.d/init.d/sshd-functions %if ! %{no_x11_askpass} %files askpass @@ -279,6 +280,9 @@ %endif %changelog +* Mon Feb 19 2001 Jim Knoble +- Added compatibility functions for sshd initscript in sshd-functions. +- Removed dependency on initscripts >= 4.16. * Mon Oct 18 2000 Damien Miller - Merge some of Nalin Dahyabhai changes from the Redhat 7.0 spec file --- ./openssh-SNAP-20010219/contrib/redhat/sshd-functions.orig-init Mon Feb 19 05:22:40 2001 +++ ./openssh-SNAP-20010219/contrib/redhat/sshd-functions Mon Feb 19 05:22:33 2001 @@ -0,0 +1,83 @@ +#!/bin/bash +# +# Compability functions for sshd initscript +# Parts of my_action() are derived from Red Hat Linux 6.x initscripts. + +# Indicate success, using success() function if available; +# otherwise, use method compatible with initscripts < 4.0 +# (Red Hat Linux <= 5.2). +# PARAMETERS: +# $1 => message to pass to success() +# $2 => message to display in compatibility mode, if different +# from default of "done" +my_success() { + local msg + if [ $# -gt 1 ]; then + msg="$2" + else + msg="done" + fi + case "$(type -type success)" in + function) + success "$1" + ;; + *) + echo -n "${msg}" + ;; + esac +} + +# Indicate failure, using failure() function if available; +# otherwise, use method compatible with initscripts < 4.0 +# (Red Hat Linux <= 5.2). +# PARAMETERS: +# $1 => message to pass to failure() +# $2 => message to display in compatibility mode, if different +# from default of "FAILED" +my_failure() { + local msg + if [ $# -gt 1 ]; then + msg="$2" + else + msg="FAILED" + fi + case "$(type -type failure)" in + function) + failure "$1" + ;; + *) + echo -n "${msg}" + ;; + esac +} + +# Perform an action, using the action() function (which logs output) +# if available. If unavailable, perform the action and indicate +# success or failure appropriately. +# PARAMETERS: +# $1 => message to display and log in action(), or to display +# while performing action in compatibility mode +# $2 => message to display on success in compatibility mode +# $3 => message to display on failure in compatibility mode +my_action() { + local status + local msg="$1" + local success_msg="$2" + local failure_msg="$3" + shift 3 + case "$(type -type action)" in + function) + action "${msg}" "$@" + status=$? + ;; + *) + echo -n "${msg}" + "$@" && my_success "${msg}" "${success_msg}" \ + || my_failure "${msg}" "${failure_msg}" + status=$? + echo + ;; + esac + return ${status} +} + From glouis at dynamicro.on.ca Tue Feb 20 00:36:18 2001 From: glouis at dynamicro.on.ca (Greg Louis) Date: Mon, 19 Feb 2001 08:36:18 -0500 Subject: 2.5.1p1 Could not load host key Message-ID: <20010219083618.A20137@athame.dynamicro.on.ca> OpenSSH 2.5.1p1 was compiled on two different Linux machines, both with glibc 2.2, libz-1.1.3 and openssl-0.9.6. Both had been running 2.3.0p1 successfully. On both, the new sshd failed: # ./sshd -d -d -d -D debug1: sshd version OpenSSH_2.5.1p1 debug1: load_private_key_autodetect: type 0 RSA1 Disabling protocol version 2. Could not load host key RSA sessions worked. Generating a new DSA key pair made no difference. Configure options: --prefix=/usr --with-tcp-wrappers --with-md5-passwords OpenSSH configured has been configured with the following options. User binaries: /usr/bin System binaries: /usr/sbin Configuration files: /usr/etc Askpass program: /usr/libexec/ssh-askpass Manual pages: /usr/man/manX PID file: /var/run Random number collection: Device (/dev/urandom) Manpage format: man PAM support: 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 Preprocessor flags: Linker flags: Libraries: -lcrypt -lwrap -lz -lnsl -lutil -lcrypto Did I do something wrong or is this a bug? I'm not on the list, so please cc me with any replies. TIA........... -- | G r e g L o u i s | gpg public key: | | http://www.bgl.nu/~glouis | finger greg at bgl.nu | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 206 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010219/dee8b56b/attachment.bin From janfrode at parallab.uib.no Tue Feb 20 00:49:39 2001 From: janfrode at parallab.uib.no (Jan-Frode Myklebust) Date: Mon, 19 Feb 2001 14:49:39 +0100 Subject: 2.5.1p1 Could not load host key In-Reply-To: <20010219083618.A20137@athame.dynamicro.on.ca>; from glouis@dynamicro.on.ca on Mon, Feb 19, 2001 at 08:36:18AM -0500 References: <20010219083618.A20137@athame.dynamicro.on.ca> Message-ID: <20010219144939.A22300@ii.uib.no> On Mon, Feb 19, 2001 at 08:36:18AM -0500, Greg Louis wrote: > OpenSSH 2.5.1p1 was compiled on two different Linux machines, both with > glibc 2.2, libz-1.1.3 and openssl-0.9.6. Both had been running 2.3.0p1 > successfully. On both, the new sshd failed: > # ./sshd -d -d -d -D > debug1: sshd version OpenSSH_2.5.1p1 > debug1: load_private_key_autodetect: type 0 RSA1 > Disabling protocol version 2. Could not load host key Try pointing to your protocol 2 key in sshd_config: HostKey /etc/ssh_host_key HostKey /etc/ssh_host_dsa_key -jf -- Jan-Frode Myklebust, Para//ab, High Performance Computing Center From douglas.manton at uk.ibm.com Tue Feb 20 01:13:51 2001 From: douglas.manton at uk.ibm.com (douglas.manton at uk.ibm.com) Date: Mon, 19 Feb 2001 14:13:51 +0000 Subject: Packet integrity error. (34) Message-ID: <802569F8.004E2D14.00@d06mta05.portsmouth.uk.ibm.com> Hi, I am using Van Dyke SecureCRT 3.2.1 to access an AIX server running OpenSSH-2.5.0p1. Using ssh1 with X11 forwarding enabled, the server reports the following error (in the client session): Packet integrity error. (34) This problem was not evident in 2.3.0p1. Running sshd in debug gives the output: debug1: sshd version OpenSSH_2.5.1p1 debug1: load_private_key_autodetect: type 0 RSA1 debug1: read SSH2 private key done: name dsa w/o comment success 1 debug1: load_private_key_autodetect: type 2 DSA debug1: Seeded RNG with 38 bytes from programs debug1: Seeded RNG with 3 bytes from system calls 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: Seeded RNG with 38 bytes from programs debug1: Seeded RNG with 3 bytes from system calls RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 10.141.33.180 port 1522 debug1: Client protocol version 1.5; client software version 1.0 debug1: no match: 1.0 debug1: Local version string SSH-1.99-OpenSSH_2.5.1p1 debug1: Rhosts Authentication disabled, originating port not trusted. debug1: Sent 768 bit server key and 1024 bit host key. debug1: Encryption type: blowfish debug1: Received session key; encryption turned on. debug1: Installing crc compensation attack detector. debug1: Attempting authentication for someuser. Accepted rsa for someuser from 10.141.33.180 port 1522 debug1: Trying to reverse map address 10.141.33.180. debug1: session_new: init debug1: session_new: session 0 packet_set_maxsize: setting to 4096 debug1: Allocating pty. debug1: Ignoring unsupported tty mode opcode 13 (0xd) debug1: Received request for X11 forwarding with auth spoofing. Packet integrity error (46 != 42) at session.c:358 Disconnecting: Packet integrity error. (34) debug1: Calling cleanup 0x2000175c(0x2000aee0) debug1: pty_cleanup_proc: /dev/pts/7 debug1: Calling cleanup 0x200016c0(0x0) debug1: Calling cleanup 0x2000139c(0x0) debug1: writing PRNG seed to file /root/.ssh/prng_seed If this is a client issue, then please let me know and I will chase Van Dyke for a resolution. Disabling X11 forwarding and/or moving to ssh2 fixes the problem. Many thanks, -------------------------------------------------------- Doug Manton, AT&T EMEA Commercial Security Solutions demanton at att.com -------------------------------------------------------- "If privacy is outlawed, only outlaws will have privacy" From Markus.Friedl at informatik.uni-erlangen.de Tue Feb 20 01:27:39 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 19 Feb 2001 15:27:39 +0100 Subject: Packet integrity error. (34) In-Reply-To: <802569F8.004E2D14.00@d06mta05.portsmouth.uk.ibm.com>; from douglas.manton@uk.ibm.com on Mon, Feb 19, 2001 at 02:13:51PM +0000 References: <802569F8.004E2D14.00@d06mta05.portsmouth.uk.ibm.com> Message-ID: <20010219152739.A1062@faui02.informatik.uni-erlangen.de> could you please try sshd -d -d -d thanks, -m On Mon, Feb 19, 2001 at 02:13:51PM +0000, douglas.manton at uk.ibm.com wrote: > > > > Hi, > > I am using Van Dyke SecureCRT 3.2.1 to access an AIX server running > OpenSSH-2.5.0p1. Using ssh1 with X11 forwarding enabled, the server > reports the following error (in the client session): > > Packet integrity error. (34) > > This problem was not evident in 2.3.0p1. Running sshd in debug gives the > output: > > debug1: sshd version OpenSSH_2.5.1p1 > debug1: load_private_key_autodetect: type 0 RSA1 > debug1: read SSH2 private key done: name dsa w/o comment success 1 > debug1: load_private_key_autodetect: type 2 DSA > debug1: Seeded RNG with 38 bytes from programs > debug1: Seeded RNG with 3 bytes from system calls > 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: Seeded RNG with 38 bytes from programs > debug1: Seeded RNG with 3 bytes from system calls > RSA key generation complete. > debug1: Server will not fork when running in debugging mode. > Connection from 10.141.33.180 port 1522 > debug1: Client protocol version 1.5; client software version 1.0 > debug1: no match: 1.0 > debug1: Local version string SSH-1.99-OpenSSH_2.5.1p1 > debug1: Rhosts Authentication disabled, originating port not trusted. > debug1: Sent 768 bit server key and 1024 bit host key. > debug1: Encryption type: blowfish > debug1: Received session key; encryption turned on. > debug1: Installing crc compensation attack detector. > debug1: Attempting authentication for someuser. > Accepted rsa for someuser from 10.141.33.180 port 1522 > debug1: Trying to reverse map address 10.141.33.180. > debug1: session_new: init > debug1: session_new: session 0 > packet_set_maxsize: setting to 4096 > debug1: Allocating pty. > debug1: Ignoring unsupported tty mode opcode 13 (0xd) > debug1: Received request for X11 forwarding with auth spoofing. > Packet integrity error (46 != 42) at session.c:358 > Disconnecting: Packet integrity error. (34) > debug1: Calling cleanup 0x2000175c(0x2000aee0) > debug1: pty_cleanup_proc: /dev/pts/7 > debug1: Calling cleanup 0x200016c0(0x0) > debug1: Calling cleanup 0x2000139c(0x0) > debug1: writing PRNG seed to file /root/.ssh/prng_seed > > If this is a client issue, then please let me know and I will chase Van > Dyke for a resolution. Disabling X11 forwarding and/or moving to ssh2 > fixes the problem. > > Many thanks, > -------------------------------------------------------- > Doug Manton, AT&T EMEA Commercial Security Solutions > > demanton at att.com > -------------------------------------------------------- > "If privacy is outlawed, only outlaws will have privacy" > > > From tim at multitalents.net Tue Feb 20 02:07:13 2001 From: tim at multitalents.net (Tim Rice) Date: Mon, 19 Feb 2001 07:07:13 -0800 (PST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Sun, 18 Feb 2001 mouring at etoh.eviladmin.org wrote: > On Sat, 17 Feb 2001, Gert Doering wrote: > > > Hi, > > > > On Sat, Feb 17, 2001 at 11:17:05AM -0600, mouring at etoh.eviladmin.org wrote: > > > However I know there was a reason for us -L$ssldir and -L$ssldir/lib. And > > > I would rather see a solution that keeps both tests in place if possible. > > > > The double "-L" breaks the linker on SCO 3.0 (too many -L). > > > > Why not really *check* the -L path for "$ssldir/(lib/)?libcrypto.a", and > > use only the directory where it can be found? > > > I was hoping someone else with this problem would provide the > patch.. However. If this is acceptable to all parties... > > Grant I refuse to claim it's clean, pretty, what not.. It's almost 1am my > time and I'm going to bed. I can state it works under Linux Redhat 7.0 > and I've done no other other testing. [snip] > Well, that patch didn't work but this one does. > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- openssh_cvs/configure.in.old Sun Feb 18 11:04:38 2001 +++ openssh_cvs/configure.in Sun Feb 18 23:26:30 2001 @@ -596,10 +596,18 @@ for ssldir in $tryssldir "" /usr/local/openssl /usr/lib/openssl /usr/local/ssl /usr/lib/ssl /usr/local /usr/pkg /opt /opt/openssl ; do if test ! -z "$ssldir" -a "x$ssldir" != "x/usr"; then - LDFLAGS="$saved_LDFLAGS -L$ssldir/lib -L$ssldir" + if test -f "$ssldir/lib/libcrypto.a" -o -f "$ssldir/lib/libcrypto.so"; then + LDFLAGS="$saved_LDFLAGS -L$ssldir/lib" + else + LDFLAGS="$saved_LDFLAGS -L$ssldir" + fi CPPFLAGS="$saved_CPPFLAGS -I$ssldir/include" if test ! -z "$need_dash_r" ; then - LDFLAGS="$LDFLAGS -R$ssldir/lib -R$ssldir" + if test -f "$ssldir/lib/libcrypto.a" -o -f "$ssldir/lib/libcrypto.so"; then + LDFLAGS="$LDFLAGS -R$ssldir/lib" + else + LDFLAGS="$LDFLAGS -R$ssldir" + fi fi else LDFLAGS="$saved_LDFLAGS" @@ -649,9 +657,17 @@ if test ! -z "$ssldir" -a "x$ssldir" != "x/usr"; then CPPFLAGS="$saved_CPPFLAGS -I$ssldir/include" - LDFLAGS="$saved_LDFLAGS -L$ssldir/lib -L$ssldir" + if test -f "$ssldir/lib/libcrypto.a" -o -f "$ssldir/lib/libcrypto.so"; then + LDFLAGS="$saved_LDFLAGS -L$ssldir/lib" + else + LDFLAGS="$saved_LDFLAGS -L$ssldir" + fi if test ! -z "$need_dash_r" ; then - LDFLAGS="$LDFLAGS -R$ssldir/lib -R$ssldir" + if test -f "$ssldir/lib/libcrypto.a" -o -f "$ssldir/lib/libcrypto.so"; then + LDFLAGS="$LDFLAGS -R$ssldir/lib" + else + LDFLAGS="$LDFLAGS -R$ssldir" + fi fi if test ! -z "$blibpath" ; then blibpath="$blibpath:$ssldir:$ssldir/lib" From provos at citi.umich.edu Tue Feb 20 02:10:43 2001 From: provos at citi.umich.edu (Niels Provos) Date: Mon, 19 Feb 2001 10:10:43 -0500 Subject: Dubious use of BN_num_bits in sshconnect1.c (resend) Message-ID: <20010219151043.C89EE207C1@citi.umich.edu> ------- Forwarded Message Subject: Re: Dubious use of BN_num_bits in sshconnect1.c From: Niels Provos In-Reply-To: alex at foogod.com, Sun, 18 Feb 2001 19:38:56 PST To: alex at foogod.com Cc: openssh-unix-dev at mindrot.org Date: Mon, 19 Feb 2001 10:07:24 -0500 Sender: provos at citi.umich.edu Hi Alex, there is no problem in OpenSSH. In message <20010218193856.D22936 at draco.foogod.com>, alex at foogod.com writes: >Hiho... >I have recently encountered problems using OpenSSH 2.3.0p1 to connect to a SSH >1.2.20 server, with messages such as the following: You should seriously consider updating the ssh-1.2.20 server to something newer. >received in sshconnect1.c. The problem is that BN_num_bits does not return >the number of significant bits of a given bignum, but rather the position of >the most significant 1 bit, which is not necessarily the same thing. This is not a problem. This is how BN_num_bits wors and how it is supposed to be use. >It is perfectly possible (and as demonstrated, does occur) for the remote end >to generate an N-bit public key where the most significant bit is zero. You are confused. In an N-bit RSA modulus the Nth bit is the most significant bit. This is very different from an random integer taken from an N-bit range. OpenSSH uses BN_num_bits correctly. >(this brings up a related flaw in the BN_rand/BN_pseudo_rand (which is the >reason this bug doesn't show up with OpenSSH servers) in that when called to >generate an N-bit (pseudo)random number, these functions actually return N-1 >bits of random data, with the msb set to 1, instead of the N random bits >promised, but that's a side issue) There is no flaw in BN_[pseudo_]rand(), there is no such bug in OpenSSH. Please, if you do not understand a particular issue, you should not claim that somebody else is mistaken. Why don't you look at the man pages the next time? int BN_rand(BIGNUM *rnd, int bits, int top, int bottom); int BN_pseudo_rand(BIGNUM *rnd, int bits, int top, int bottom); [...] If top is true, the two most significant bits of the number will be set to 1, so that the product of two such random numbers will always have 2*bits length. If bottom is true, the number will be odd. Niels. ------- End of Forwarded Message From douglas.manton at uk.ibm.com Tue Feb 20 02:24:54 2001 From: douglas.manton at uk.ibm.com (douglas.manton at uk.ibm.com) Date: Mon, 19 Feb 2001 15:24:54 +0000 Subject: Packet integrity error. (34) Message-ID: <802569F8.0054AEAA.00@d06mta05.portsmouth.uk.ibm.com> Markus, As requested: debug1: sshd version OpenSSH_2.5.1p1 debug1: load_private_key_autodetect: type 0 RSA1 debug3: Bad RSA1 key file /etc/ssh/ssh_host_dsa_key. debug1: read SSH2 private key done: name dsa w/o comment success 1 debug1: load_private_key_autodetect: type 2 DSA debug3: Reading output from 'ls -alni /var/log' debug3: Time elapsed: 24 msec debug3: Got 0.15 bytes of entropy from 'ls -alni /var/log' debug3: Reading output from 'ls -alni /var/adm' debug3: Time elapsed: 19 msec debug3: Got 2.00 bytes of entropy from 'ls -alni /var/adm' debug3: Reading output from 'ls -alni /var/spool/mail' debug3: Time elapsed: 16 msec debug3: Got 0.53 bytes of entropy from 'ls -alni /var/spool/mail' debug3: Reading output from 'ls -alni /tmp' debug3: Time elapsed: 19 msec debug3: Got 2.00 bytes of entropy from 'ls -alni /tmp' debug3: Reading output from 'ls -alni /var/tmp' debug3: Time elapsed: 17 msec debug3: Got 0.15 bytes of entropy from 'ls -alni /var/tmp' debug3: Reading output from 'ls -alni /usr/tmp' debug3: Time elapsed: 18 msec debug3: Got 0.16 bytes of entropy from 'ls -alni /usr/tmp' debug3: Reading output from 'netstat -an' debug3: Time elapsed: 30 msec debug3: Got 2.00 bytes of entropy from 'netstat -an' debug3: Reading output from 'netstat -in' debug3: Time elapsed: 21 msec debug3: Got 2.00 bytes of entropy from 'netstat -in' debug3: Reading output from 'netstat -rn' debug3: Time elapsed: 24 msec debug3: Got 2.00 bytes of entropy from 'netstat -rn' debug3: Reading output from 'netstat -s' debug3: Time elapsed: 24 msec debug3: Got 2.00 bytes of entropy from 'netstat -s' debug3: Reading output from 'ifconfig -a' debug3: Time elapsed: 18 msec debug3: Got 0.88 bytes of entropy from 'ifconfig -a' debug3: Reading output from 'ps laxww' debug3: Time elapsed: 68 msec debug3: Got 2.00 bytes of entropy from 'ps laxww' debug3: Reading output from 'ps -al' debug3: Time elapsed: 41 msec debug3: Got 2.00 bytes of entropy from 'ps -al' debug3: Reading output from 'ps -efl' debug3: Time elapsed: 95 msec debug3: Got 2.00 bytes of entropy from 'ps -efl' debug3: Reading output from 'w' debug3: Time elapsed: 21 msec debug3: Got 1.02 bytes of entropy from 'w' debug3: Reading output from 'who -i' debug3: Time elapsed: 19 msec debug3: Got 0.07 bytes of entropy from 'who -i' debug3: Reading output from 'last' debug3: Time elapsed: 139 msec debug3: Got 2.00 bytes of entropy from 'last' debug3: Reading output from 'df' debug3: Time elapsed: 17 msec debug3: Got 1.16 bytes of entropy from 'df' debug3: Reading output from 'df -i' debug3: Time elapsed: 13 msec debug3: Got 1.16 bytes of entropy from 'df -i' debug3: Reading output from 'vmstat' debug3: Time elapsed: 54 msec debug3: Got 0.27 bytes of entropy from 'vmstat' debug3: Reading output from 'uptime' debug3: Time elapsed: 23 msec debug3: Got 0.07 bytes of entropy from 'uptime' debug3: Reading output from 'ipcs -a' debug3: Time elapsed: 150 msec debug3: Got 2.00 bytes of entropy from 'ipcs -a' debug3: Reading output from 'tail -200 /var/log/debug ' debug3: Time elapsed: 19 msec debug3: Got 2.00 bytes of entropy from 'tail -200 /var/log/debug ' debug3: Reading output from 'tail -200 /var/adm/wtmp' debug3: Time elapsed: 43 msec debug3: Got 2.00 bytes of entropy from 'tail -200 /var/adm/wtmp' debug3: Reading output from 'tail -200 /var/adm/sulog' debug3: Time elapsed: 18 msec debug3: Got 2.00 bytes of entropy from 'tail -200 /var/adm/sulog' debug1: Seeded RNG with 41 bytes from programs debug1: Seeded RNG with 3 bytes from system calls debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. debug3: Reading output from 'ls -alni /var/log' debug3: Time elapsed: 16 msec debug3: Got 0.15 bytes of entropy from 'ls -alni /var/log' debug3: Reading output from 'ls -alni /var/adm' debug3: Time elapsed: 26 msec debug3: Got 2.00 bytes of entropy from 'ls -alni /var/adm' debug3: Reading output from 'ls -alni /var/spool/mail' debug3: Time elapsed: 21 msec debug3: Got 0.53 bytes of entropy from 'ls -alni /var/spool/mail' debug3: Reading output from 'ls -alni /tmp' debug3: Time elapsed: 23 msec debug3: Got 2.00 bytes of entropy from 'ls -alni /tmp' debug3: Reading output from 'ls -alni /var/tmp' debug3: Time elapsed: 19 msec debug3: Got 0.15 bytes of entropy from 'ls -alni /var/tmp' debug3: Reading output from 'ls -alni /usr/tmp' debug3: Time elapsed: 27 msec debug3: Got 0.16 bytes of entropy from 'ls -alni /usr/tmp' debug3: Reading output from 'netstat -an' debug3: Time elapsed: 34 msec debug3: Got 2.00 bytes of entropy from 'netstat -an' debug3: Reading output from 'netstat -in' debug3: Time elapsed: 28 msec debug3: Got 2.00 bytes of entropy from 'netstat -in' debug3: Reading output from 'netstat -rn' debug3: Time elapsed: 27 msec debug3: Got 2.00 bytes of entropy from 'netstat -rn' debug3: Reading output from 'netstat -s' debug3: Time elapsed: 28 msec debug3: Got 2.00 bytes of entropy from 'netstat -s' debug3: Reading output from 'ifconfig -a' debug3: Time elapsed: 21 msec debug3: Got 0.88 bytes of entropy from 'ifconfig -a' debug3: Reading output from 'ps laxww' debug3: Time elapsed: 93 msec debug3: Got 2.00 bytes of entropy from 'ps laxww' debug3: Reading output from 'ps -al' debug3: Time elapsed: 41 msec debug3: Got 2.00 bytes of entropy from 'ps -al' debug3: Reading output from 'ps -efl' debug3: Time elapsed: 101 msec debug3: Got 2.00 bytes of entropy from 'ps -efl' debug3: Reading output from 'w' debug3: Time elapsed: 27 msec debug3: Got 1.02 bytes of entropy from 'w' debug3: Reading output from 'who -i' debug3: Time elapsed: 22 msec debug3: Got 0.07 bytes of entropy from 'who -i' debug3: Reading output from 'last' debug3: Time elapsed: 149 msec debug3: Got 2.00 bytes of entropy from 'last' debug3: Reading output from 'df' debug3: Time elapsed: 17 msec debug3: Got 1.16 bytes of entropy from 'df' debug3: Reading output from 'df -i' debug3: Time elapsed: 15 msec debug3: Got 1.16 bytes of entropy from 'df -i' debug3: Reading output from 'vmstat' debug3: Time elapsed: 60 msec debug3: Got 0.27 bytes of entropy from 'vmstat' debug3: Reading output from 'uptime' debug3: Time elapsed: 13 msec debug3: Got 0.07 bytes of entropy from 'uptime' debug3: Reading output from 'ipcs -a' debug3: Time elapsed: 181 msec debug3: Got 2.00 bytes of entropy from 'ipcs -a' debug3: Reading output from 'tail -200 /var/log/debug ' debug3: Time elapsed: 43 msec debug3: Got 2.00 bytes of entropy from 'tail -200 /var/log/debug ' debug3: Reading output from 'tail -200 /var/adm/wtmp' debug3: Time elapsed: 64 msec debug3: Got 2.00 bytes of entropy from 'tail -200 /var/adm/wtmp' debug3: Reading output from 'tail -200 /var/adm/sulog' debug3: Time elapsed: 21 msec debug3: Got 2.00 bytes of entropy from 'tail -200 /var/adm/sulog' debug1: Seeded RNG with 41 bytes from programs debug1: Seeded RNG with 3 bytes from system calls RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 10.141.33.180 port 1620 debug1: Client protocol version 1.5; client software version 1.0 debug1: no match: 1.0 debug1: Local version string SSH-1.99-OpenSSH_2.5.1p1 debug1: Rhosts Authentication disabled, originating port not trusted. debug1: Sent 768 bit server key and 1024 bit host key. debug1: Encryption type: blowfish debug1: Received session key; encryption turned on. debug1: Installing crc compensation attack detector. debug1: Attempting authentication for someuser. Accepted rsa for someuser from 10.141.33.180 port 1620 debug1: Trying to reverse map address 10.141.33.180. debug1: session_new: init debug1: session_new: session 0 packet_set_maxsize: setting to 4096 debug1: Allocating pty. debug1: Ignoring unsupported tty mode opcode 13 (0xd) debug1: Received request for X11 forwarding with auth spoofing. debug2: SSH_PROTOFLAG_SCREEN_NUMBER == false Packet integrity error (62 != 58) at session.c:358 Disconnecting: Packet integrity error. (34) debug1: Calling cleanup 0x2000175c(0x2000aee0) debug1: pty_cleanup_proc: /dev/pts/7 debug1: Calling cleanup 0x200016c0(0x0) debug1: Calling cleanup 0x2000139c(0x0) debug1: writing PRNG seed to file /root/.ssh/prng_seed Many thanks, -------------------------------------------------------- Doug Manton, AT&T EMEA Commercial Security Solutions E: demanton at att.com -------------------------------------------------------- "If privacy is outlawed, only outlaws will have privacy" From kschrade at engin.umich.edu Mon Feb 19 21:43:02 2001 From: kschrade at engin.umich.edu (Kurt Schrader) Date: Mon, 19 Feb 2001 05:43:02 -0500 (EST) Subject: Possible OpenBSD client side bug Message-ID: OS: Redhat 7.0 OpenSSH Version: 2.5.1p1 Summary: Trying to connect to any host from this machine using OpenSSH gives the message: [kschrade at cpddev3 kschrade]$ ssh cressida The authenticity of host 'cressida (141.213.25.159)' can't be established. RSA1 key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00. Are you sure you want to continue connecting (yes/no)? with a blank fingerprint as above. This happens with any host that I attempt to establish a secure shell connection to. Neils asked me to please e-mail you with this information. Please feel free to e-mail me if you need any other information. --------------------------- Kurt Schrader kschrade at engin.umich.edu From Markus.Friedl at informatik.uni-erlangen.de Tue Feb 20 02:44:17 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 19 Feb 2001 16:44:17 +0100 Subject: Packet integrity error. (34) In-Reply-To: <802569F8.004E2D14.00@d06mta05.portsmouth.uk.ibm.com>; from douglas.manton@uk.ibm.com on Mon, Feb 19, 2001 at 02:13:51PM +0000 References: <802569F8.0054AEAA.00@d06mta05.portsmouth.uk.ibm.com> <802569F8.0054AEAA.00@d06mta05.portsmouth.uk.ibm.com> <802569F8.004E2D14.00@d06mta05.portsmouth.uk.ibm.com> Message-ID: <20010219164417.A3530@faui02.informatik.uni-erlangen.de> On Mon, Feb 19, 2001 at 02:13:51PM +0000, douglas.manton at uk.ibm.com wrote: > If this is a client issue, then please let me know and I will chase Van > Dyke for a resolution. Disabling X11 forwarding and/or moving to ssh2 > fixes the problem. this is a client side bug. tell them that Markus Friedl from the OpenSSH project confirmed the bug :) > debug1: Allocating pty. > debug1: Ignoring unsupported tty mode opcode 13 (0xd) > debug1: Received request for X11 forwarding with auth spoofing. > debug2: SSH_PROTOFLAG_SCREEN_NUMBER == false > Packet integrity error (62 != 58) at session.c:358 > Disconnecting: Packet integrity error. (34) > debug1: Calling cleanup 0x2000175c(0x2000aee0) > debug1: pty_cleanup_proc: /dev/pts/7 it seems that SecureCRT sends a display 'screen' number in the x11 request packet, but did not set the matching protocol flag in an earlier message. this worked before because OpenSSH-2.3.0p1 was buggy and ignored the protocol flag.... -m From djm at mindrot.org Tue Feb 20 03:00:00 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 20 Feb 2001 03:00:00 +1100 (EST) Subject: Portable OpenSSH 2.5.1p1 Message-ID: <20010219160000.92A123C08B@mothra.mindrot.org> Portable OpenSSH 2.5.1p1 has just been uploaded. It will be available from the mirrors listed at http://www.openssh.com/portable.html shortly. OpenSSH is a 100% complete SSH 1.3 & 1.5 protocol implementation and a 99% SSH 2 protocol implementation, including sftp client and server support. This release contains many portability bug-fixes (listed in the ChangeLog) as well as several new features (listed below). OpenSSH 2.5.0p1 was skipped because of interoperability issues with ssh-1.2.18 => ssh-1.2.22. We would like to thank the OpenSSH community for their continued support and encouragement. Important Changes: ================== 1) Features added to the implementation of the SSH 2 protocol: * agent forwarding * support for -R forwarding * RSA host and userkeys * extended support for older SSH 2 protocol implementations OpenSSH still lacks support for rekeying, so you have to turn off rekeying if your server tries to force this feature. The next release of OpenSSH will probably support rekeying. 2) Damien Miller contributed an interactive sftp client. The sftp client works for both SSH protocol versions. 3) David Mazieres' ssh-keyscan has been added to the OpenSSH distribution. 4) Now there are three types of keys in OpenSSH: RSA1 is used by the SSH 1 protocol only, RSA and DSA keys are used by the SSH 2 protocol implementation. You can generate RSA keys for use with SSH 2 protocol with: $ ssh-keygen -t rsa -f /etc/ssh_host_rsa_key To use RSA or DSA keys in SSH 2 protocol, simply add the public keys to the .ssh/authorised_keys2 file. IdentityFile2, HostDsaKey and DSAAuthentication are obsolete: You can use multiple IdentityFile and HostKey options instead, e.g HostKey /etc/ssh_host_key HostKey /etc/ssh_host_dsa_key HostKey /etc/ssh_host_rsa_key in /etc/sshd_config The option DSAAuthentication has been replaced by PubkeyAuthentication. Fingerprinting works for all types of keys: $ ssh-keygen -l -f $HOME/.ssh/{authorized_keys,known_hosts}{,2} 5) Important changes in the implementation of SSH 1 protocol: The OpenSSH server does not require a privileged source port for RhostsRsaAuthentication, since it adds no additional security. Interoperation with SSH 1.4 protocol 6) New option HostKeyAlias This option allows the user to record the host key under a different name. This is useful for tunneling over forwarded connections or if you run multiple sshd's on different ports on the same machine. Alternatively you can use the UserKnownHostsFile or UserKnownHostsFile2 options to specify seperate host key files for the connection. 7) The ReverseMappingCheck is now optional in sshd_config. If you combine this with the 'sshd -u0' option the server will not do DNS lookups when a client connects. 8) Stricter Hostkey Checking 9) Option Change Summary: a) New or changed: ChallengeResponseAuthentication MACs PubkeyAuthentication HostkeyAlias (Client only) Banner (Server only) ReverseMappingCheck (Server only) PermitRootLogin {yes,without-password,forced-commands-only,no} {Allow,Deny}Groups now support supplementary groups sshd -D for monitoring scripts or inittab ssh -t multiple -t force tty allocation b) Obsolete: DsaAuthentication (use PubkeyAuthentication instead) HostDsaKey (use HostKey) Identityfile2 (use Identityfile or -i) SkeyAuthentication (use ChallengeResponseAuthentication) TisAuthentication (use ChallengeResponseAuthentication) OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller and Ben Lindstrom. -d -- | Damien Miler \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From mouring at etoh.eviladmin.org Tue Feb 20 03:09:21 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 19 Feb 2001 10:09:21 -0600 (CST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: Damien commited a different patch. So I get this is the end of the story unless there are problems with it. - Ben On Mon, 19 Feb 2001, Tim Rice wrote: > On Sun, 18 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > On Sat, 17 Feb 2001, Gert Doering wrote: > > > > > Hi, > > > > > > On Sat, Feb 17, 2001 at 11:17:05AM -0600, mouring at etoh.eviladmin.org wrote: > > > > However I know there was a reason for us -L$ssldir and -L$ssldir/lib. And > > > > I would rather see a solution that keeps both tests in place if possible. > > > > > > The double "-L" breaks the linker on SCO 3.0 (too many -L). > > > > > > Why not really *check* the -L path for "$ssldir/(lib/)?libcrypto.a", and > > > use only the directory where it can be found? > > > > > I was hoping someone else with this problem would provide the > > patch.. However. If this is acceptable to all parties... > > > > Grant I refuse to claim it's clean, pretty, what not.. It's almost 1am my > > time and I'm going to bed. I can state it works under Linux Redhat 7.0 > > and I've done no other other testing. > [snip] > > > > Well, that patch didn't work but this one does. > > > > > From Phil.Pennock at globnix.org Tue Feb 20 03:05:56 2001 From: Phil.Pennock at globnix.org (Phil Pennock) Date: Mon, 19 Feb 2001 17:05:56 +0100 Subject: "Junk data left to incoming packet buffer after all data processed" Message-ID: <20010219170556.A12244@globnix.org> [ After looking over the openssh.com website, this seems to be the list to use, including for OpenBSD users? I've subscribed. ] I'm using OpenSSH_2.5.0 as currently found in OpenBSD's OPENBSD_2_8 CVS branch. I'm now finding a strange error when I try to su, _within_ the connection. The client side is _not_ OpenSSH. Every single time that I type "su -", and local echo is disabled, after typing the second letter of the password I get: Local: Junk data left to incoming packet buffer after all data processed and the connection is closed. Cue putting a console on the box to get a root prompt ... Hopefully I haven't just revealed exactly how the root password starts ;^) When I use "ssh -v" I get no extra information. The client is running protocol 1.5, and is derived from the SSH.com product. Can anyone please say authoritatively if this is a client bug, or if the server is sending back bogus data? If there's any extra diagnostic information needed, let me know how and I'll be happy to co-operate. I'm looking towards migrating a number of service machines towards an OpenSSH based system; having problems with the currently deployed client will be a major hindrance. Thanks, -- Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work. From Markus.Friedl at informatik.uni-erlangen.de Tue Feb 20 03:23:49 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 19 Feb 2001 17:23:49 +0100 Subject: "Junk data left to incoming packet buffer after all data processed" In-Reply-To: <20010219170556.A12244@globnix.org>; from Phil.Pennock@globnix.org on Mon, Feb 19, 2001 at 05:05:56PM +0100 References: <20010219170556.A12244@globnix.org> Message-ID: <20010219172349.A5352@faui02.informatik.uni-erlangen.de> On Mon, Feb 19, 2001 at 05:05:56PM +0100, Phil Pennock wrote: > [ After looking over the openssh.com website, this seems to be the list > to use, including for OpenBSD users? I've subscribed. ] > > I'm using OpenSSH_2.5.0 as currently found in OpenBSD's OPENBSD_2_8 CVS > branch. I'm now finding a strange error when I try to su, _within_ the > connection. The client side is _not_ OpenSSH. OpenSSH-2.5.1 has just been released because OpenSSH-2.5.0 triggered a bug in ssh-1.2.18 up to ssh-1.2.22. > The client is running protocol 1.5, and is derived from the SSH.com > product. what version is it derived from? how does it announce itself? what does sshd -d -d -d print if this client connects? > Can anyone please say authoritatively if this is a client bug, or if the > server is sending back bogus data? If there's any extra diagnostic > information needed, let me know how and I'll be happy to co-operate. it's a client bug. > I'm looking towards migrating a number of service machines towards an > OpenSSH based system; having problems with the currently deployed client > will be a major hindrance. i can help you fixing the clients or adding bugcompat to openssh, but i need 'sshd -d -d -d' for this. if you want to fix the client look at the diffs between ssh-1.2.22 and ssh-1.2.23 for the file packet.c and the SSH_MSG_IGNORE handling. -markus From mw at moni.msci.memphis.edu Tue Feb 20 03:26:17 2001 From: mw at moni.msci.memphis.edu (Mate Wierdl) Date: Mon, 19 Feb 2001 10:26:17 -0600 Subject: PATCH: Round 2: RH initscripts backward compatibility In-Reply-To: <20010218032603.M25687@quipu.half.pint-stowp.cx>; from jmknoble@jmknoble.cx on Sun, Feb 18, 2001 at 03:26:03AM -0500 References: <20010218032603.M25687@quipu.half.pint-stowp.cx> Message-ID: <20010219102616.A24847@moni.msci.memphis.edu> On Sun, Feb 18, 2001 at 03:26:03AM -0500, Jim Knoble wrote: > +if [ -f /etc/init.d/sshd-functions ]; then > + . /etc/init.d/functions > +else > + . /etc/rc.d/init.d/functions > +fi So you check for the existence of sshd-functions, but you source functions? (I have not seen the whole init file just this patch, so maybe this is correct) Mate From Phil.Pennock at globnix.org Tue Feb 20 03:45:12 2001 From: Phil.Pennock at globnix.org (Phil Pennock) Date: Mon, 19 Feb 2001 17:45:12 +0100 Subject: "Junk data left to incoming packet buffer after all data processed" In-Reply-To: <20010219172349.A5352@faui02.informatik.uni-erlangen.de>; from Markus.Friedl@informatik.uni-erlangen.de on Mon, Feb 19, 2001 at 05:23:49PM +0100 References: <20010219170556.A12244@globnix.org> <20010219172349.A5352@faui02.informatik.uni-erlangen.de> Message-ID: <20010219174512.A23318@globnix.org> On 2001-02-19 at 17:23 +0100, Markus Friedl gifted us with: > > I'm using OpenSSH_2.5.0 as currently found in OpenBSD's OPENBSD_2_8 CVS > > branch. I'm now finding a strange error when I try to su, _within_ the > > connection. The client side is _not_ OpenSSH. > > OpenSSH-2.5.1 has just been released because OpenSSH-2.5.0 > triggered a bug in ssh-1.2.18 up to ssh-1.2.22. Yeah, I saw the announcement arrive in my mailbox several seconds after I sent off the request for help/info. :^/ : OpenSSH 2.5.0p1 was skipped because of interoperability issues with : ssh-1.2.18 => ssh-1.2.22. > > The client is running protocol 1.5, and is derived from the SSH.com > > product. > > what version is it derived from? 1.2.22. *sighs* It's internally modified to support some special stuff internal to my employer, which is not for external release; partly because it ties into a custom RADIUS system for staff cryptocard authentication. "1.2.22j4rad". > it's a client bug. :^( :^( > i can help you fixing the clients or adding bugcompat to openssh, Ow. I really dislike the idea of putting bug compatibility into otherwise clean software; however, if I'm to get our systems migrated to an OpenSSH based solution, so that we can migrate the staff to using version 2 clients, this may be necessary. :^( Thanks for being willing to do this. > but i need 'sshd -d -d -d' for this. Since you need it, no one else is likely to be interested, and it's got semi-sensitive (hah, right!) info in, I'll send this directly to you. > if you want to fix the client look at the diffs between ssh-1.2.22 and ssh-1.2.23 > for the file packet.c and the SSH_MSG_IGNORE handling. Hrm. This could be politically awkward, upgrading a couple hundred client machines, just so that we can later upgrade again. The logic is good, but actually getting it approved could be tricky. I can have a look. Where can I get those old tarballs from, to generate the diff? Thanks again for the help with this. This is going to be one of those weeks, especially since I'm on callout duty this week too. Maybe I should crawl under a rock. -- Modern technology puts enormously powerful tools in the hands of people without the mental and ethical training to use them properly. From Markus.Friedl at informatik.uni-erlangen.de Tue Feb 20 03:54:19 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 19 Feb 2001 17:54:19 +0100 Subject: "Junk data left to incoming packet buffer after all data processed" In-Reply-To: <20010219174512.A23318@globnix.org>; from Phil.Pennock@globnix.org on Mon, Feb 19, 2001 at 05:45:12PM +0100 References: <20010219170556.A12244@globnix.org> <20010219172349.A5352@faui02.informatik.uni-erlangen.de> <20010219174512.A23318@globnix.org> Message-ID: <20010219175419.A8296@faui02.informatik.uni-erlangen.de> On Mon, Feb 19, 2001 at 05:45:12PM +0100, Phil Pennock wrote: > > if you want to fix the client look at the diffs between ssh-1.2.22 and ssh-1.2.23 > > for the file packet.c and the SSH_MSG_IGNORE handling. > > Hrm. This could be politically awkward, upgrading a couple hundred > client machines, just so that we can later upgrade again. The logic is > good, but actually getting it approved could be tricky. I can have a > look. Where can I get those old tarballs from, to generate the diff? http://wwwcip.informatik.uni-erlangen.de/user/msfriedl/archive/ From mouring at etoh.eviladmin.org Tue Feb 20 04:04:33 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 19 Feb 2001 11:04:33 -0600 (CST) Subject: Possible OpenBSD client side bug In-Reply-To: Message-ID: On Mon, 19 Feb 2001, Kurt Schrader wrote: > > OS: Redhat 7.0 > OpenSSH Version: 2.5.1p1 > Summary: Trying to connect to any host from this machine using OpenSSH > gives the message: > > [kschrade at cpddev3 kschrade]$ ssh cressida > The authenticity of host 'cressida (141.213.25.159)' can't be established. > RSA1 key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00. > Are you sure you want to continue connecting (yes/no)? > Hmm... I don't see OpenSSH 2.5.1 -> 2.5.1 under Redhat 7.0. Can we get a ssh -v -v -v of the connection? - Ben From Phil.Pennock at globnix.org Tue Feb 20 05:19:47 2001 From: Phil.Pennock at globnix.org (Phil Pennock) Date: Mon, 19 Feb 2001 19:19:47 +0100 Subject: "Junk data left to incoming packet buffer after all data processed" In-Reply-To: <20010219172349.A5352@faui02.informatik.uni-erlangen.de>; from Markus.Friedl@informatik.uni-erlangen.de on Mon, Feb 19, 2001 at 05:23:49PM +0100 References: <20010219170556.A12244@globnix.org> <20010219172349.A5352@faui02.informatik.uni-erlangen.de> Message-ID: <20010219191947.A1185@globnix.org> On 2001-02-19 at 17:23 +0100, Markus Friedl gifted us with: > if you want to fix the client look at the diffs between ssh-1.2.22 and ssh-1.2.23 > for the file packet.c and the SSH_MSG_IGNORE handling. Works wonderfully, thanks. Now I can happily wait for the OpenBSD CVS servers to propagate the upgrade to 2.5.1 in the STABLE branch instead of fudging things. :^) Perhaps this week won't be so bad after all. -- I'm not paranoid! Which of my enemies told you this? From gert at greenie.muc.de Tue Feb 20 05:37:35 2001 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 19 Feb 2001 19:37:35 +0100 Subject: Portable OpenSSH 2.5.1p1 In-Reply-To: <20010219160000.92A123C08B@mothra.mindrot.org>; from Damien Miller on Tue, Feb 20, 2001 at 03:00:00AM +1100 References: <20010219160000.92A123C08B@mothra.mindrot.org> Message-ID: <20010219193735.A4074@greenie.muc.de> Hi, On Tue, Feb 20, 2001 at 03:00:00AM +1100, Damien Miller wrote: > 5) Important changes in the implementation of SSH 1 protocol: > > The OpenSSH server does not require a privileged source port for > RhostsRsaAuthentication, since it adds no additional security. I don't buy (understand?) that. Using RhostsRsaAuthentication, I can give user "A" the right to log into an account, but not user "B" on the same client machine. Requiring privileged ports for this means "user B can't compile his own ssh client that pretents he's user A", so user B can't easily hack into my account. Now if I don't trust "root" on the client machine, or if B can get root access, I'm lost anyway, that's true (but if they have root access, they can hijack my ssh sessions by fiddling with ttys, so in that case, I have lost in any case). But if no suid port is required, RostsRsaAuthentication is effectively useless if you're doing this on a multi-user system. 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 Tue Feb 20 05:45:30 2001 From: tim at multitalents.net (Tim Rice) Date: Mon, 19 Feb 2001 10:45:30 -0800 (PST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Mon, 19 Feb 2001 mouring at etoh.eviladmin.org wrote: > > Damien commited a different patch. So I get this is the end of the > story unless there are problems with it. It looks like a good patch. Too bad it doesn't work. It puts in -L/usr/local/ssl/lib twice. ... gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o log-client.o readconf. o clientloop.o -L. -Lopenbsd-compat/ -L/usr/local/lib -L/usr/local/ssl/lib -L/u sr/local/ssl/lib -lssh -lopenbsd-compat -lintl -lwrap -lz -lrpc -lyp -lrpc -lsoc ket -lgen -lsocket -los -lprot -lx -ltinfo -lm -lcrypto ld crtbegin.o: too many -L options, 6 allowed gmake: *** [ssh] Error 1 ... > > - Ben > > On Mon, 19 Feb 2001, Tim Rice wrote: > > > On Sun, 18 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > On Sat, 17 Feb 2001, Gert Doering wrote: > > > > > > > Hi, > > > > > > > > On Sat, Feb 17, 2001 at 11:17:05AM -0600, mouring at etoh.eviladmin.org wrote: > > > > > However I know there was a reason for us -L$ssldir and -L$ssldir/lib. And > > > > > I would rather see a solution that keeps both tests in place if possible. > > > > > > > > The double "-L" breaks the linker on SCO 3.0 (too many -L). > > > > > > > > Why not really *check* the -L path for "$ssldir/(lib/)?libcrypto.a", and > > > > use only the directory where it can be found? > > > > > > > I was hoping someone else with this problem would provide the > > > patch.. However. If this is acceptable to all parties... > > > > > > Grant I refuse to claim it's clean, pretty, what not.. It's almost 1am my > > > time and I'm going to bed. I can state it works under Linux Redhat 7.0 > > > and I've done no other other testing. > > [snip] > > > > > > > Well, that patch didn't work but this one does. > > > > > > > > > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mhw at wittsend.com Tue Feb 20 05:52:47 2001 From: mhw at wittsend.com (Michael H. Warfield) Date: Mon, 19 Feb 2001 13:52:47 -0500 Subject: Portable OpenSSH 2.5.1p1 In-Reply-To: <20010219193735.A4074@greenie.muc.de>; from gert@greenie.muc.de on Mon, Feb 19, 2001 at 07:37:35PM +0100 References: <20010219160000.92A123C08B@mothra.mindrot.org> <20010219193735.A4074@greenie.muc.de> Message-ID: <20010219135247.A5888@alcove.wittsend.com> On Mon, Feb 19, 2001 at 07:37:35PM +0100, Gert Doering wrote: > Hi, > On Tue, Feb 20, 2001 at 03:00:00AM +1100, Damien Miller wrote: > > 5) Important changes in the implementation of SSH 1 protocol: > > The OpenSSH server does not require a privileged source port for > > RhostsRsaAuthentication, since it adds no additional security. > I don't buy (understand?) that. > Using RhostsRsaAuthentication, I can give user "A" the right to log into an > account, but not user "B" on the same client machine. > Requiring privileged ports for this means "user B can't compile his own > ssh client that pretents he's user A", so user B can't easily hack into my > account. Now if I don't trust "root" on the client machine, or if B can > get root access, I'm lost anyway, that's true (but if they have root > access, they can hijack my ssh sessions by fiddling with ttys, so in > that case, I have lost in any case). > But if no suid port is required, RostsRsaAuthentication is effectively > useless if you're doing this on a multi-user system. I think the point here is that the reserved ports boundry is a Unix fiction that other operating systems don't have to adhere to. That means that access to your server is based on policies present on the client system over which you probably have no control. If you can't guarantee that the reserved port designation means anything at all to the client side, then using it to make security decisions doesn't really add anything to the security at all. > 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 Mike -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From dws at ee.ethz.ch Tue Feb 20 06:04:20 2001 From: dws at ee.ethz.ch (David Schweikert) Date: Mon, 19 Feb 2001 20:04:20 +0100 Subject: scp doesn't work with sshd 2.5.1p1 on Solaris 2.6 Message-ID: <20010219200420.B19445@ee.ethz.ch> scp with sshd 2.5.1p1 (scp host:file .) doesn't work for me on Solaris 2.6. The client says: Received disconnect from x.x.x.x: Command terminated on signal 11. truss of sshd excerpt: 629: stat64("/usr/lib/security/pam_unix.so.1", 0xEFFFEB10) = 0 627: sigaction(SIGCLD, 0xEFFFF360, 0xEFFFF3E0) = 0 627: sigaction(SIGPIPE, 0xEFFFF360, 0xEFFFF3E0) = 0 627: fcntl(8, F_GETFL, 0x00000000) = 2 629: door_info(3, 0xEFFFDEA0) = 0 627: fstat64(8, 0xEFFFF2A8) = 0 629: door_call(3, 0xEFFFDE88) = 0 627: getsockopt(8, 65535, 8192, 0xEFFFF3AC, 0xEFFFF3A4) = 0 629: open("/var/adm/lastlog", O_RDWR|O_CREAT, 0444) = 6 629: llseek(6, 14168, SEEK_SET) = 14168 627: fstat64(8, 0xEFFFF2A8) = 0 629: time() = 982608836 627: getsockopt(8, 65535, 8192, 0xEFFFF3AC, 0xEFFFF3A8) = 0 627: setsockopt(8, 65535, 8192, 0xEFFFF3AC, 4) = 0 629: Incurred fault #6, FLTBOUNDS %pc = 0xEF5A51BC 629: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000005 627: fcntl(8, F_SETFL, 0x00000082) = 0 629: Received signal #11, SIGSEGV [default] 629: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000005 629: *** process killed *** 627: fcntl(8, F_GETFL, 0x00000000) = 130 627: Received signal #18, SIGCLD [caught] 627: siginfo: SIGCLD CLD_KILLED pid=629 status=0x000B 627: wait() = 629 [0x000B] 627: sigaction(SIGCLD, 0xEFFFEE98, 0xEFFFEF18) = 0 I configured with: ./configure \ --with-pam \ --with-catman=cat \ --with-egd-pool=/var/adm/entropy \ --with-ssl-dir=$OPENSSL \ --with-pid-dir=/var/adm --with-rsh=/usr/bin/rsh \ --with-xauth=/usr/openwin/bin/xauth \ --with-lastlog=/var/adm/lastlog \ --with-default-path=/usr/bin:/usr/sbin:/usr/openwin/bin:/usr/sepp/bin \ --sysconfdir=/etc --prefix=/usr --libexecdir=/usr/bin \ --mandir=/usr/share/man The operating system is Solaris 2.6 with NIS+. Attached are the ssh_config and sshd_config. Hope this helps. I had to reinstall sshd 2.3.0p1... David -- _ __| |___ David Schweikert / _` / __| IT Support Group, EE-Dept, ETH-Zurich | (_| \__ \ Tel: +41(0)1-6327019 Room: ETL F24.1 \__,_|___/ http://ee-staff.ethz.ch/~dws -------------- next part -------------- # 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 yes # ForwardX11 yes # RhostsAuthentication yes # RhostsRSAAuthentication yes # RSAAuthentication yes # PasswordAuthentication yes # FallBackToRsh yes # UseRsh no # BatchMode no # CheckHostIP yes # StrictHostKeyChecking no # IdentityFile ~/.ssh/identity # Port 22 # Protocol 2,1 # Cipher 3des # EscapeChar ~ # Be paranoid by default Host * ForwardAgent no ForwardX11 yes FallBackToRsh no Cipher blowfish -------------- next part -------------- # This is ssh server systemwide configuration file. Port 22 ListenAddress 0.0.0.0 HostKey /etc/ssh_host_key HostKey /etc/ssh_host_dsa_key ServerKeyBits 768 LoginGraceTime 600 KeyRegenerationInterval 3600 PermitRootLogin yes IgnoreRhosts no StrictModes yes X11Forwarding yes X11DisplayOffset 10 PrintMotd no KeepAlive no SyslogFacility DAEMON RhostsAuthentication no RhostsRSAAuthentication yes RSAAuthentication yes PasswordAuthentication yes PermitEmptyPasswords no CheckMail no UseLogin no Subsystem sftp /usr/bin/sftp-server From mouring at etoh.eviladmin.org Tue Feb 20 06:14:08 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 19 Feb 2001 13:14:08 -0600 (CST) Subject: scp doesn't work with sshd 2.5.1p1 on Solaris 2.6 In-Reply-To: <20010219200420.B19445@ee.ethz.ch> Message-ID: If you compile without --with-pam do you still have scp fail? - Ben On Mon, 19 Feb 2001, David Schweikert wrote: > scp with sshd 2.5.1p1 (scp host:file .) doesn't work for me on > Solaris 2.6. The client says: > > Received disconnect from x.x.x.x: Command terminated on signal 11. > > truss of sshd excerpt: > > 629: stat64("/usr/lib/security/pam_unix.so.1", 0xEFFFEB10) = 0 > 627: sigaction(SIGCLD, 0xEFFFF360, 0xEFFFF3E0) = 0 > 627: sigaction(SIGPIPE, 0xEFFFF360, 0xEFFFF3E0) = 0 > 627: fcntl(8, F_GETFL, 0x00000000) = 2 > 629: door_info(3, 0xEFFFDEA0) = 0 > 627: fstat64(8, 0xEFFFF2A8) = 0 > 629: door_call(3, 0xEFFFDE88) = 0 > 627: getsockopt(8, 65535, 8192, 0xEFFFF3AC, 0xEFFFF3A4) = 0 > 629: open("/var/adm/lastlog", O_RDWR|O_CREAT, 0444) = 6 > 629: llseek(6, 14168, SEEK_SET) = 14168 > 627: fstat64(8, 0xEFFFF2A8) = 0 > 629: time() = 982608836 > 627: getsockopt(8, 65535, 8192, 0xEFFFF3AC, 0xEFFFF3A8) = 0 > 627: setsockopt(8, 65535, 8192, 0xEFFFF3AC, 4) = 0 > 629: Incurred fault #6, FLTBOUNDS %pc = 0xEF5A51BC > 629: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000005 > 627: fcntl(8, F_SETFL, 0x00000082) = 0 > 629: Received signal #11, SIGSEGV [default] > 629: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000005 > 629: *** process killed *** > 627: fcntl(8, F_GETFL, 0x00000000) = 130 > 627: Received signal #18, SIGCLD [caught] > 627: siginfo: SIGCLD CLD_KILLED pid=629 status=0x000B > 627: wait() = 629 [0x000B] > 627: sigaction(SIGCLD, 0xEFFFEE98, 0xEFFFEF18) = 0 > > I configured with: > > ./configure \ > --with-pam \ > --with-catman=cat \ > --with-egd-pool=/var/adm/entropy \ > --with-ssl-dir=$OPENSSL \ > --with-pid-dir=/var/adm --with-rsh=/usr/bin/rsh \ > --with-xauth=/usr/openwin/bin/xauth \ > --with-lastlog=/var/adm/lastlog \ > --with-default-path=/usr/bin:/usr/sbin:/usr/openwin/bin:/usr/sepp/bin \ > --sysconfdir=/etc --prefix=/usr --libexecdir=/usr/bin \ > --mandir=/usr/share/man > > The operating system is Solaris 2.6 with NIS+. > > Attached are the ssh_config and sshd_config. > > Hope this helps. I had to reinstall sshd 2.3.0p1... > > David > From dws at ee.ethz.ch Tue Feb 20 06:11:30 2001 From: dws at ee.ethz.ch (David Schweikert) Date: Mon, 19 Feb 2001 20:11:30 +0100 Subject: scp doesn't work with sshd 2.5.1p1 on Solaris 2.6 In-Reply-To: ; from mouring@etoh.eviladmin.org on Mon, Feb 19, 2001 at 01:14:08PM -0600 References: <20010219200420.B19445@ee.ethz.ch> Message-ID: <20010219201130.A19522@ee.ethz.ch> On Mon, Feb 19, 2001 at 13:14:08 -0600, mouring at etoh.eviladmin.org wrote: > > If you compile without --with-pam do you still have scp fail? No, it works. password authentication doesn't work anymore though (we have NIS+). David -- _ __| |___ David Schweikert / _` / __| IT Support Group, EE-Dept, ETH-Zurich | (_| \__ \ Tel: +41(0)1-6327019 Room: ETL F24.1 \__,_|___/ http://ee-staff.ethz.ch/~dws From mdb at juniper.net Tue Feb 20 06:19:44 2001 From: mdb at juniper.net (Mark D. Baushke) Date: Mon, 19 Feb 2001 11:19:44 -0800 Subject: FreeBSD 4.2 OpenSSH2.3.0 client vs Red Hat 6.2 OpenSSH2.5.1p1 sshd Message-ID: <200102191919.LAA88354@garnet.juniper.net> mdb-bsd is a FreeBSD 4.2-STABLE box morpheus is a Red Hat Linux 6.2 box with openssl 0.9.6 on it. Attempts to use SSHv2 fail. Using SSHv1 succeeds. sshd from OpenSSH2.5.1p1 is getting a fatal: xfree: NULL pointer given as argument Full client and server interaction given below. -- Mark Script started on Mon Feb 19 10:47:01 2001 1:mdb at mdb-bsd$ ssh -v -v -v -2 -x morpheus date SSH Version OpenSSH_2.3.0, protocol versions 1.5/2.0. Compiled with SSL (0x0090600f). debug: Reading configuration data /homes/mdb/.ssh/config debug: Applying options for * debug: Reading configuration data /etc/ssh/ssh_config debug: ssh_connect: getuid 1513 geteuid 1513 anon 1 debug: Connecting to dsl-mdb-home2.juniper.net [172.16.165.75] port 22. debug: Connection established. debug: Remote protocol version 1.99, remote software version OpenSSH_2.5.1p1 debug: no match: OpenSSH_2.5.1p1 Enabling compatibility mode for protocol 2.0 debug: Local version string SSH-2.0-OpenSSH_2.3.0 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,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 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: 1044/2049 debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. Connection closed by 172.16.165.75 debug: Calling cleanup 0x8058114(0x0) 2:mdb at mdb-bsd$ exit Script done on Mon Feb 19 10:47:24 2001 The above is the client and below is the server for the same transaction Script started on Mon Feb 19 10:46:39 2001 1:mdb at morpheus$ sudo /usr/sbin/sshd -d -d -d debug1: sshd version OpenSSH_2.5.1p1 debug1: load_private_key_autodetect: type 0 RSA1 debug3: Bad RSA1 key file /etc/ssh/ssh_host_dsa_key. debug1: read SSH2 private key done: name dsa w/o comment success 1 debug1: load_private_key_autodetect: type 2 DSA 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 RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 172.17.12.132 port 3160 debug1: Client protocol version 2.0; client software version OpenSSH_2.3.0 debug1: match: OpenSSH_2.3.0 pat ^OpenSSH_2\.3\.0 Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_2.5.1p1 debug1: Rhosts Authentication disabled, originating port not trusted. debug1: list_hostkey_types: ssh-dss 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: none debug1: got kexinit: none debug1: got kexinit: debug1: got kexinit: debug1: first kex follow: 0 debug1: reserved: 0 debug1: done debug2: mac_init: found hmac-sha1 debug1: kex: client->server 3des-cbc hmac-sha1 none debug2: mac_init: found hmac-sha1 debug1: kex: server->client 3des-cbc hmac-sha1 none debug1: Wait SSH2_MSG_KEX_DH_GEX_REQUEST. debug1: Sending SSH2_MSG_KEX_DH_GEX_GROUP. debug1: bits set: 1042/2049 debug1: Wait SSH2_MSG_KEX_DH_GEX_INIT. debug1: bits set: 1044/2049 fatal: xfree: NULL pointer given as argument debug1: Calling cleanup 0x80638a0(0x0) 2:mdb at morpheus$ exit Script done on Mon Feb 19 10:47:25 2001 From paulsen at orbiteam.de Tue Feb 20 06:30:55 2001 From: paulsen at orbiteam.de (Volker Paulsen) Date: Mon, 19 Feb 2001 20:30:55 +0100 Subject: SNAP 20010213 Bug: ssh-agent environment In-Reply-To: ; from djm@mindrot.org on Mon, Feb 19, 2001 at 09:27:54PM +1100 References: <20010219111056.A1600@mail.orbiteam.de> Message-ID: <20010219203055.A8233@mail.orbiteam.de> On Mon, Feb 19, 2001 at 09:27:54PM +1100, Damien Miller wrote: > > It does not inherit its environment if it is invoked as > > > > ssh-agent command > > > ssh-agent /bin/sh > > $ env > > SSH_AGENT_PID=19437 > > Can't replicate this - I get a full env. Finally, I tracked the problem down to openbsd-compat/setenv.c in SNAP 20010213: memmove() parameters were swapped. Probably this was already fixed in some newer SNAP? paulsen at tarifa 20:24 [openssh] diff -u openbsd-compat/setenv.c.orig openbsd-compat/setenv.c --- openbsd-compat/setenv.c.orig Mon Feb 19 20:24:00 2001 +++ openbsd-compat/setenv.c Mon Feb 19 20:24:14 2001 @@ -122,7 +122,7 @@ (cnt + 2))); if (!P) return (-1); - memmove(environ, P, cnt * sizeof(char *)); + memmove(P, environ, cnt * sizeof(char *)); environ = P; } environ[cnt + 1] = NULL; Regards, Volker Paulsen -- OrbiTeam Software GmbH http://www.orbiteam.de/ Rathausalle 10 phone: +49 2241 14-3704 D-53757 Sankt Augustin fax: +49 2241 14-3701 From pekkas at netcore.fi Tue Feb 20 06:32:00 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 19 Feb 2001 21:32:00 +0200 (EET) Subject: FreeBSD 4.2 OpenSSH2.3.0 client vs Red Hat 6.2 OpenSSH2.5.1p1 sshd In-Reply-To: <200102191919.LAA88354@garnet.juniper.net> Message-ID: On Mon, 19 Feb 2001, Mark D. Baushke wrote: > mdb-bsd is a FreeBSD 4.2-STABLE box morpheus is a Red Hat Linux 6.2 > box with openssl 0.9.6 on it. > > Attempts to use SSHv2 fail. Using SSHv1 succeeds. > > sshd from OpenSSH2.5.1p1 is getting a > fatal: xfree: NULL pointer given as argument Connecting from FreeBSD 4.2-STABLE with OpenSSH 2.3.0 on it to Red Hat Linux 6.2 w/ OpenSSH 2.5.1p1 compiled with OpenSSL 0.9.5a works here fine. Did you recompile OpenSSH on RHL6.2 (openssl incompatibility)? > > Full client and server interaction given below. > > -- Mark > > Script started on Mon Feb 19 10:47:01 2001 > 1:mdb at mdb-bsd$ ssh -v -v -v -2 -x morpheus date > SSH Version OpenSSH_2.3.0, protocol versions 1.5/2.0. > Compiled with SSL (0x0090600f). > debug: Reading configuration data /homes/mdb/.ssh/config > debug: Applying options for * > debug: Reading configuration data /etc/ssh/ssh_config > debug: ssh_connect: getuid 1513 geteuid 1513 anon 1 > debug: Connecting to dsl-mdb-home2.juniper.net [172.16.165.75] port 22. > debug: Connection established. > debug: Remote protocol version 1.99, remote software version OpenSSH_2.5.1p1 > debug: no match: OpenSSH_2.5.1p1 > Enabling compatibility mode for protocol 2.0 > debug: Local version string SSH-2.0-OpenSSH_2.3.0 > 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,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > 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: 1044/2049 > debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. > debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. > Connection closed by 172.16.165.75 > debug: Calling cleanup 0x8058114(0x0) > 2:mdb at mdb-bsd$ exit > Script done on Mon Feb 19 10:47:24 2001 > > The above is the client and below is the server for the same > transaction > > Script started on Mon Feb 19 10:46:39 2001 > 1:mdb at morpheus$ sudo /usr/sbin/sshd -d -d -d > debug1: sshd version OpenSSH_2.5.1p1 > debug1: load_private_key_autodetect: type 0 RSA1 > debug3: Bad RSA1 key file /etc/ssh/ssh_host_dsa_key. > debug1: read SSH2 private key done: name dsa w/o comment success 1 > debug1: load_private_key_autodetect: type 2 DSA > 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 > RSA key generation complete. > debug1: Server will not fork when running in debugging mode. > Connection from 172.17.12.132 port 3160 > debug1: Client protocol version 2.0; client software version OpenSSH_2.3.0 > debug1: match: OpenSSH_2.3.0 pat ^OpenSSH_2\.3\.0 > Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-1.99-OpenSSH_2.5.1p1 > debug1: Rhosts Authentication disabled, originating port not trusted. > debug1: list_hostkey_types: ssh-dss > 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: none > debug1: got kexinit: none > debug1: got kexinit: > debug1: got kexinit: > debug1: first kex follow: 0 > debug1: reserved: 0 > debug1: done > debug2: mac_init: found hmac-sha1 > debug1: kex: client->server 3des-cbc hmac-sha1 none > debug2: mac_init: found hmac-sha1 > debug1: kex: server->client 3des-cbc hmac-sha1 none > debug1: Wait SSH2_MSG_KEX_DH_GEX_REQUEST. > debug1: Sending SSH2_MSG_KEX_DH_GEX_GROUP. > debug1: bits set: 1042/2049 > debug1: Wait SSH2_MSG_KEX_DH_GEX_INIT. > debug1: bits set: 1044/2049 > fatal: xfree: NULL pointer given as argument > debug1: Calling cleanup 0x80638a0(0x0) > 2:mdb at morpheus$ exit > Script done on Mon Feb 19 10:47:25 2001 > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From mouring at etoh.eviladmin.org Tue Feb 20 06:56:18 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 19 Feb 2001 13:56:18 -0600 (CST) Subject: SNAP 20010213 Bug: ssh-agent environment In-Reply-To: <20010219203055.A8233@mail.orbiteam.de> Message-ID: On Mon, 19 Feb 2001, Volker Paulsen wrote: > On Mon, Feb 19, 2001 at 09:27:54PM +1100, Damien Miller wrote: > > > It does not inherit its environment if it is invoked as > > > > > > ssh-agent command > > > > ssh-agent /bin/sh > > > $ env > > > SSH_AGENT_PID=19437 > > > > Can't replicate this - I get a full env. > > Finally, I tracked the problem down to openbsd-compat/setenv.c in SNAP > 20010213: memmove() parameters were swapped. Probably this was already > fixed in some newer SNAP? > > paulsen at tarifa 20:24 [openssh] diff -u openbsd-compat/setenv.c.orig openbsd-compat/setenv.c Shoot me.. Shoot me now. The patch that did that occured Jan 5. It was when I moved from bcopy() to memmove(). And I forgot to swap the arguments. This patch includes your and a fix to getcwd.c which was the other place I fubared it. Wonder why I never ran into this under NeXT?! - Ben Index: openbsd-compat/getcwd.c =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/getcwd.c,v retrieving revision 1.1 diff -u -r1.1 getcwd.c --- openbsd-compat/getcwd.c 2001/01/31 21:52:03 1.1 +++ openbsd-compat/getcwd.c 2001/02/19 19:48:19 @@ -119,7 +119,7 @@ * path to the beginning of the buffer, but it's always * been that way and stuff would probably break. */ - memmove(bpt, pt, ept - bpt); + memmove(pt, bpt, ept - bpt); free(up); return (pt); } @@ -170,7 +170,7 @@ goto notfound; if (ISDOT(dp)) continue; - memmove(dp->d_name, bup, dp->d_namlen + 1); + memmove(bup, dp->d_name, dp->d_namlen + 1); /* Save the first error for later. */ if (lstat(up, &s)) { @@ -202,13 +202,13 @@ pt = npt; bpt = pt + off; ept = pt + ptsize; - memmove(bpt, ept - len, len); + memmove(ept - len, bpt, len); bpt = ept - len; } if (!first) *--bpt = '/'; bpt -= dp->d_namlen; - memmove(dp->d_name, bpt, dp->d_namlen); + memmove(bpt, dp->d_name, dp->d_namlen); (void)closedir(dir); /* Truncate any file name. */ Index: openbsd-compat/setenv.c =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/setenv.c,v retrieving revision 1.1 diff -u -r1.1 setenv.c --- openbsd-compat/setenv.c 2001/01/31 21:52:04 1.1 +++ openbsd-compat/setenv.c 2001/02/19 19:48:20 @@ -122,7 +122,7 @@ (cnt + 2))); if (!P) return (-1); - memmove(environ, P, cnt * sizeof(char *)); + memmove(P, environ, cnt * sizeof(char *)); environ = P; } environ[cnt + 1] = NULL; From mouring at etoh.eviladmin.org Tue Feb 20 07:04:43 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 19 Feb 2001 14:04:43 -0600 (CST) Subject: scp doesn't work with sshd 2.5.1p1 on Solaris 2.6 In-Reply-To: <20010219201130.A19522@ee.ethz.ch> Message-ID: On Mon, 19 Feb 2001, David Schweikert wrote: > On Mon, Feb 19, 2001 at 13:14:08 -0600, mouring at etoh.eviladmin.org wrote: > > > > If you compile without --with-pam do you still have scp fail? > > No, it works. > Out of interest.. If you apply this patch. Does scp work again with the --with-pam option? - Ben Index: openbsd-compat/getcwd.c =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/getcwd.c,v retrieving revision 1.1 diff -u -r1.1 getcwd.c --- openbsd-compat/getcwd.c 2001/01/31 21:52:03 1.1 +++ openbsd-compat/getcwd.c 2001/02/19 19:48:19 @@ -119,7 +119,7 @@ * path to the beginning of the buffer, but it's always * been that way and stuff would probably break. */ - memmove(bpt, pt, ept - bpt); + memmove(pt, bpt, ept - bpt); free(up); return (pt); } @@ -170,7 +170,7 @@ goto notfound; if (ISDOT(dp)) continue; - memmove(dp->d_name, bup, dp->d_namlen + 1); + memmove(bup, dp->d_name, dp->d_namlen + 1); /* Save the first error for later. */ if (lstat(up, &s)) { @@ -202,13 +202,13 @@ pt = npt; bpt = pt + off; ept = pt + ptsize; - memmove(bpt, ept - len, len); + memmove(ept - len, bpt, len); bpt = ept - len; } if (!first) *--bpt = '/'; bpt -= dp->d_namlen; - memmove(dp->d_name, bpt, dp->d_namlen); + memmove(bpt, dp->d_name, dp->d_namlen); (void)closedir(dir); /* Truncate any file name. */ Index: openbsd-compat/setenv.c =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/setenv.c,v retrieving revision 1.1 diff -u -r1.1 setenv.c --- openbsd-compat/setenv.c 2001/01/31 21:52:04 1.1 +++ openbsd-compat/setenv.c 2001/02/19 19:48:20 @@ -122,7 +122,7 @@ (cnt + 2))); if (!P) return (-1); - memmove(environ, P, cnt * sizeof(char *)); + memmove(P, environ, cnt * sizeof(char *)); environ = P; } environ[cnt + 1] = NULL; From marekm at amelek.gda.pl Tue Feb 20 06:25:25 2001 From: marekm at amelek.gda.pl (Marek Michalkiewicz) Date: Mon, 19 Feb 2001 20:25:25 +0100 (CET) Subject: Linux Unix98 ptys - was Re: Where is OpenSSH 2.5.0p1? In-Reply-To: from Damien Miller at "Feb 18, 2001 12:51:20 pm" Message-ID: > > *Warning:* Using the `openpty' function with NAME not set to > > `NULL' is *very dangerous* because it provides no protection > > against overflowing the string NAME. You should use the `ttyname' > > function on the file descriptor returned in *SLAVE to find out the > > file name of the slave pseudo-terminal device instead. > > I think that you would have a hard time causing any trouble with this > - you would have to have a pretty messed up system if the path to your > tty was more than 64 chars. These paths look like /dev/pts/ but the code in glibc tries hard to handle any length (realloc in a loop, etc.) - and later does strcpy to the buffer supplied to openpty(). Is there a reason why the HAVE_DEV_PTMX code (without the I_PUSH ioctl calls - as with HAVE_CYGWIN) is not used for Linux (glibc >= 2.1)? It is standard, works fine as far as I can tell, and avoids ttyname() which may be slow (the usual implementation is to search all of /dev/ for a matching device - not a noticeable delay on my box though). Not a bug, just a suggestion to consider for some future release - all the code is in place, only configure needs to be changed... > Both applied. Thanks. I see 2.5.1p1 really is there now :). Marek From paulsen at orbiteam.de Tue Feb 20 07:11:45 2001 From: paulsen at orbiteam.de (Volker Paulsen) Date: Mon, 19 Feb 2001 21:11:45 +0100 Subject: Question about ssh-add... Message-ID: <20010219211145.A8704@mail.orbiteam.de> Evenin', I would like to know, why "OpenSSH ssh-add" doesn't support the -p (pipe) option of "Ssh-1.2.X shh-add"? I used it several time within scripts, like ./whisperpassphrase | ssh-add -p Well, I know this is some kind of security by obscurity, but this has been proven to be handy. Regards, Volker Paulsen -- OrbiTeam Software GmbH http://www.orbiteam.de/ Rathausalle 10 phone: +49 2241 14-3704 D-53757 Sankt Augustin fax: +49 2241 14-3701 From mdb at juniper.net Tue Feb 20 07:21:36 2001 From: mdb at juniper.net (Mark D. Baushke) Date: Mon, 19 Feb 2001 12:21:36 -0800 Subject: FreeBSD 4.2 OpenSSH2.3.0 client vs Red Hat 6.2 OpenSSH2.5.1p1 sshd In-Reply-To: Mail from Pekka Savola dated Mon, 19 Feb 2001 21:32:00 +0200 Message-ID: <200102192021.MAA93685@garnet.juniper.net> > Date: Mon, 19 Feb 2001 21:32:00 +0200 (EET) > From: Pekka Savola > > On Mon, 19 Feb 2001, Mark D. Baushke wrote: > > > mdb-bsd is a FreeBSD 4.2-STABLE box morpheus is a Red Hat Linux 6.2 > > box with openssl 0.9.6 on it. > > > > Attempts to use SSHv2 fail. Using SSHv1 succeeds. > > > > sshd from OpenSSH2.5.1p1 is getting a > > fatal: xfree: NULL pointer given as argument > > Connecting from FreeBSD 4.2-STABLE with OpenSSH 2.3.0 on it to Red Hat > Linux 6.2 w/ OpenSSH 2.5.1p1 compiled with OpenSSL 0.9.5a works here fine. > > Did you recompile OpenSSH on RHL6.2 (openssl incompatibility)? No, I had not done that and it was indeed the problem. Building from the openssh_cvs tree sources worked. After rebuilding the openssh*2.5.1p1*.i386.rpm packagesthe problem went away. Thanks, -- Mark PS: I did have to install libtool-1.3.4-3.i386.rpm first so that the rpm-3.0.5-9.6x generated file /var/tmp/rpm-tmp. use of '[ -f configure.in ] && libtoolize --copy --force ;' command would work on my RH6.2 system. From michael at moria.de Tue Feb 20 07:58:53 2001 From: michael at moria.de (michael at moria.de) Date: 19 Feb 2001 20:58:53 -0000 Subject: Bug in 2.3.0p1 when using UseLogin Message-ID: <20010219205853.2304.qmail@mail.moria.de> Hello, I tried UseLogin, because ssh does not seem to propagate the tty controlling characters from the local to the remote tty and the login(1) on my system offers a config file to set them. Unfortunately, when using UseLogin, sshd does not run xauth. I can only guess that it does so, because it would have to drop privileges for doing so, but that makes UseLogin about useless. I am not subscribed to the list, so please send a cc of any replies to me. Michael From devon at admin2.gisnetworks.com Tue Feb 20 08:13:52 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Mon, 19 Feb 2001 13:13:52 -0800 Subject: scp doesn't work with sshd 2.5.1p1 on Solaris 2.6 References: Message-ID: <00fd01c09ab8$fbf34ce0$1900a8c0@devn> scp still fails on my system with that patch applied. devon ----- Original Message ----- From: To: "David Schweikert" Cc: Sent: Monday, February 19, 2001 12:04 PM Subject: Re: scp doesn't work with sshd 2.5.1p1 on Solaris 2.6 > On Mon, 19 Feb 2001, David Schweikert wrote: > > > On Mon, Feb 19, 2001 at 13:14:08 -0600, mouring at etoh.eviladmin.org wrote: > > > > > > If you compile without --with-pam do you still have scp fail? > > > > No, it works. > > > > Out of interest.. If you apply this patch. Does scp work again with the > --with-pam option? > > - Ben > > Index: openbsd-compat/getcwd.c > =================================================================== > RCS file: /var/cvs/openssh/openbsd-compat/getcwd.c,v > retrieving revision 1.1 > diff -u -r1.1 getcwd.c > --- openbsd-compat/getcwd.c 2001/01/31 21:52:03 1.1 > +++ openbsd-compat/getcwd.c 2001/02/19 19:48:19 > @@ -119,7 +119,7 @@ > * path to the beginning of the buffer, but it's always > * been that way and stuff would probably break. > */ > - memmove(bpt, pt, ept - bpt); > + memmove(pt, bpt, ept - bpt); > free(up); > return (pt); > } > @@ -170,7 +170,7 @@ > goto notfound; > if (ISDOT(dp)) > continue; > - memmove(dp->d_name, bup, dp->d_namlen + 1); > + memmove(bup, dp->d_name, dp->d_namlen + 1); > > /* Save the first error for later. */ > if (lstat(up, &s)) { > @@ -202,13 +202,13 @@ > pt = npt; > bpt = pt + off; > ept = pt + ptsize; > - memmove(bpt, ept - len, len); > + memmove(ept - len, bpt, len); > bpt = ept - len; > } > if (!first) > *--bpt = '/'; > bpt -= dp->d_namlen; > - memmove(dp->d_name, bpt, dp->d_namlen); > + memmove(bpt, dp->d_name, dp->d_namlen); > (void)closedir(dir); > > /* Truncate any file name. */ > Index: openbsd-compat/setenv.c > =================================================================== > RCS file: /var/cvs/openssh/openbsd-compat/setenv.c,v > retrieving revision 1.1 > diff -u -r1.1 setenv.c > --- openbsd-compat/setenv.c 2001/01/31 21:52:04 1.1 > +++ openbsd-compat/setenv.c 2001/02/19 19:48:20 > @@ -122,7 +122,7 @@ > (cnt + 2))); > if (!P) > return (-1); > - memmove(environ, P, cnt * sizeof(char *)); > + memmove(P, environ, cnt * sizeof(char *)); > environ = P; > } > environ[cnt + 1] = NULL; > > > From mouring at etoh.eviladmin.org Tue Feb 20 08:18:54 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 19 Feb 2001 15:18:54 -0600 (CST) Subject: Bug in 2.3.0p1 when using UseLogin In-Reply-To: <20010219205853.2304.qmail@mail.moria.de> Message-ID: 2.5.1p1 has been released, also we need to know what platform your attempting to do this on. - Ben On 19 Feb 2001 michael at moria.de wrote: > Hello, > > I tried UseLogin, because ssh does not seem to propagate the tty > controlling characters from the local to the remote tty and the login(1) > on my system offers a config file to set them. Unfortunately, when using > UseLogin, sshd does not run xauth. I can only guess that it does so, > because it would have to drop privileges for doing so, but that makes > UseLogin about useless. > > I am not subscribed to the list, so please send a cc of any replies to me. > > Michael > From markus.friedl at informatik.uni-erlangen.de Tue Feb 20 04:51:27 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 19 Feb 2001 18:51:27 +0100 Subject: "Junk data left to incoming packet buffer after all data processed" In-Reply-To: <20010219174512.A23318@globnix.org>; from Phil.Pennock@globnix.org on Mon, Feb 19, 2001 at 05:45:12PM +0100 References: <20010219170556.A12244@globnix.org> <20010219172349.A5352@faui02.informatik.uni-erlangen.de> <20010219174512.A23318@globnix.org> Message-ID: <20010219185127.A16976@folly> On Mon, Feb 19, 2001 at 05:45:12PM +0100, Phil Pennock wrote: > 1.2.22. *sighs* It's internally modified to support some special stuff > internal to my employer, which is not for external release; partly > because it ties into a custom RADIUS system for staff cryptocard > authentication. "1.2.22j4rad". just FYI, the auth-call.c files in OpenSSH-2.5.x allow easy integration of various ChallRespo methods into OpenSSH for both SSH protocol version 1 and 2. > > i can help you fixing the clients or adding bugcompat to openssh, > > Ow. I really dislike the idea of putting bug compatibility into > otherwise clean software; OpenSSH already has support for may different bugs, esp. for older SSH protocol 2 implementatins. > however, if I'm to get our systems migrated to > an OpenSSH based solution, great :) -markus From michael at moria.de Tue Feb 20 08:27:33 2001 From: michael at moria.de (michael at moria.de) Date: 19 Feb 2001 21:27:33 -0000 Subject: Bug in 2.3.0p1 when using UseLogin Message-ID: <20010219212733.7221.qmail@mail.moria.de> > 2.5.1p1 has been released, also we need to know what platform your > attempting to do this on. I installed 2.5.1p1, but it does not fix the bug. I use Linux, but the problem is platform-independent, see session.c:1124, where it changes to the users UID, which it doesn't do if UseLogin is in effect, because login(1) does so. Line 1332 protects running xauth(1) from running as root, but that breaks X11 forwarding when using UseLogin. Michael From gert at greenie.muc.de Tue Feb 20 08:29:42 2001 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 19 Feb 2001 22:29:42 +0100 Subject: Portable OpenSSH 2.5.1p1 In-Reply-To: <20010219135247.A5888@alcove.wittsend.com>; from Michael H. Warfield on Mon, Feb 19, 2001 at 01:52:47PM -0500 References: <20010219160000.92A123C08B@mothra.mindrot.org> <20010219193735.A4074@greenie.muc.de> <20010219135247.A5888@alcove.wittsend.com> Message-ID: <20010219222942.B8562@greenie.muc.de> Hi, On Mon, Feb 19, 2001 at 01:52:47PM -0500, Michael H. Warfield wrote: [..] > I think the point here is that the reserved ports boundry is > a Unix fiction that other operating systems don't have to adhere > to. That means that access to your server is based on policies present > on the client system over which you probably have no control. If you > can't guarantee that the reserved port designation means anything at all > to the client side, then using it to make security decisions doesn't > really add anything to the security at all. Ummm, well, yes. But that's the "I have to trust 'root' on the client system issue" in disguise. If there's a client system that has a trusted admin, an operating system that does have the notion of privileged ports, and I decide to permit a specific account on *that* system to use my .shosts, there is a big difference whether sshd checks for privileged ports or not. Without checking for privileged ports, you're effectively making RhostsRsaAuthentication completely useless, as every user can disguise as every other user, and should then better drop it completely. 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 jmknoble at jmknoble.cx Tue Feb 20 08:39:25 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Mon, 19 Feb 2001 16:39:25 -0500 Subject: Fix: PATCH: Round 3: RH initscripts backward compatibility In-Reply-To: <20010219102616.A24847@moni.msci.memphis.edu>; from mw@wierdlmpc.msci.memphis.edu on Mon, Feb 19, 2001 at 10:26:17AM -0600 References: <20010218032603.M25687@quipu.half.pint-stowp.cx> <20010219102616.A24847@moni.msci.memphis.edu> Message-ID: <20010219163925.W25687@quipu.half.pint-stowp.cx> Circa 2001-Feb-19 10:26:17 -0600 dixit Mate Wierdl: : On Sun, Feb 18, 2001 at 03:26:03AM -0500, Jim Knoble wrote: : > +if [ -f /etc/init.d/sshd-functions ]; then : > + . /etc/init.d/functions : > +else : > + . /etc/rc.d/init.d/functions : > +fi : : So you check for the existence of sshd-functions, but you source : functions? (I have not seen the whole init file just this patch, so : maybe this is correct) Urp---cut-n-paste error. Good eyes, Mate. Fix (against Round 3 patch) is attached (and yes, it's really attached---i just checked:). -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ -------------- next part -------------- --- ./openssh-SNAP-20010219/contrib/redhat/sshd.init.orig-fixinit Mon Feb 19 05:40:17 2001 +++ ./openssh-SNAP-20010219/contrib/redhat/sshd.init Mon Feb 19 16:36:29 2001 @@ -15,7 +15,7 @@ # source function library # If the file exists, but is not readable, it's an error. # Likewise, if the fallback file doesn't exist, it's an error. -if [ -f /etc/init.d/sshd-functions ]; then +if [ -f /etc/init.d/functions ]; then . /etc/init.d/functions else . /etc/rc.d/init.d/functions From markus.friedl at informatik.uni-erlangen.de Tue Feb 20 08:51:30 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 19 Feb 2001 22:51:30 +0100 Subject: Portable OpenSSH 2.5.1p1 In-Reply-To: <20010219193735.A4074@greenie.muc.de>; from gert@greenie.muc.de on Mon, Feb 19, 2001 at 07:37:35PM +0100 References: <20010219160000.92A123C08B@mothra.mindrot.org> <20010219193735.A4074@greenie.muc.de> Message-ID: <20010219225130.E21559@folly> On Mon, Feb 19, 2001 at 07:37:35PM +0100, Gert Doering wrote: > But if no suid port is required, RostsRsaAuthentication is effectively > useless if you're doing this on a multi-user system. no, rhostsrsa works only if the hostkey is readable for the ssh binary. -m From markus.friedl at informatik.uni-erlangen.de Tue Feb 20 08:56:36 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 19 Feb 2001 22:56:36 +0100 Subject: Portable OpenSSH 2.5.1p1 In-Reply-To: <20010219222942.B8562@greenie.muc.de>; from gert@greenie.muc.de on Mon, Feb 19, 2001 at 10:29:42PM +0100 References: <20010219160000.92A123C08B@mothra.mindrot.org> <20010219193735.A4074@greenie.muc.de> <20010219135247.A5888@alcove.wittsend.com> <20010219222942.B8562@greenie.muc.de> Message-ID: <20010219225636.F21559@folly> On Mon, Feb 19, 2001 at 10:29:42PM +0100, Gert Doering wrote: > Without checking for privileged ports, you're effectively making > RhostsRsaAuthentication completely useless, as every user can disguise as > every other user, and should then better drop it completely. no. only root can read the hostkey file, so the client is trusted because it knows the hostkey. no need for privileged ports nonsense. hostbased auth in ssh2 will not have the priv-ports requirement. -m From vader at conflict.net Tue Feb 20 09:15:03 2001 From: vader at conflict.net (Jim Breton) Date: Mon, 19 Feb 2001 22:15:03 +0000 Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) box Message-ID: <20010219221503.26739.qmail@conflict.net> I just compiled OpenSSH-2.5.1p1 from source on my Debian potato box using: --prefix=/usr/local/openssh --enable-gnome-askpass --with-tcp-wrappers --with-ipv4-default --with-ipaddr-display --libexecdir=/usr/local/openssh/lib --disable-suid-ssh --with-pam I am running OpenSSL-0.9.5a compiled from source with: --prefix=/usr/local/openssl --openssldir=/usr/local/openssl I can scp into my other Debian (woody/testing and potato/stable) boxes and my OpenBSD 2.8 box without issue. However, when trying to scp a file to an RH 6.0 or 7.0 (the only two available to me currently) machine, scp hangs after authentication. Even if I use -v, there is not much useful output: $ scp -v -v filelist (host): Executing: program /usr/local/openssh/bin/ssh (host) (host), user (unspecified), command scp -v -t . jimb@(host)'s password: (hangs here for a long while, 5 minutes or more) Read from remote host (host): Connection timed out lost connection (The username jimb is specified in .ssh/config for this server.) (I have also tried with the user at host: syntax.) Also an sshd process is left laying around on the server if I kill the client process with Ctrl+C (not sure if the same thing happens after a time-out). The two machines I'm connecting to are: RH6.0, OpenSSH-2.5.1p1 compiled from source: --prefix=/usr/local/openssh --with-tcp-wrappers --disable-suid-ssh --with-pam and OpenSSL-0.9.6 also compiled from source. RH7.0, OpenSSH-2.5.1p1 RPMs (from ftp.openbsd.org), and RH's OpenSSL RPMs (openssl-0.9.5a-14). I'm not on the -dev list so if anyone sees anything obvious which I'm doing wrong please do copy me on it. ;) I've been trying to keep up by viewing the archives though. Thanks. (P.S. scp was also broken in 2.3.0p1 but of course that was already a known issue, and that was not RH-specific in my experience. Afaict this problem I am having is only on RH, though I can't confirm that it doesn't exist elsewhere (other than Debian and OpenBSD).) -- Jim B. vader at conflict.net From pekkas at netcore.fi Tue Feb 20 09:25:02 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 20 Feb 2001 00:25:02 +0200 (EET) Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) box In-Reply-To: <20010219221503.26739.qmail@conflict.net> Message-ID: On Mon, 19 Feb 2001, Jim Breton wrote: > I just compiled OpenSSH-2.5.1p1 from source on my Debian potato box > using: > --prefix=/usr/local/openssh --enable-gnome-askpass --with-tcp-wrappers > --with-ipv4-default --with-ipaddr-display > --libexecdir=/usr/local/openssh/lib --disable-suid-ssh --with-pam > > I am running OpenSSL-0.9.5a compiled from source with: > --prefix=/usr/local/openssl --openssldir=/usr/local/openssl Tried --with-ipv4-default? I believe that's usually what you want. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From vader at conflict.net Tue Feb 20 09:38:09 2001 From: vader at conflict.net (Jim Breton) Date: Mon, 19 Feb 2001 22:38:09 +0000 Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) box In-Reply-To: ; from pekkas@netcore.fi on Tue, Feb 20, 2001 at 12:25:02AM +0200 References: <20010219221503.26739.qmail@conflict.net> Message-ID: <20010219223809.26936.qmail@conflict.net> On Tue, Feb 20, 2001 at 12:25:02AM +0200, Pekka Savola wrote: > On Mon, 19 Feb 2001, Jim Breton wrote: > > I just compiled OpenSSH-2.5.1p1 from source on my Debian potato box > > using: > > --prefix=/usr/local/openssh --enable-gnome-askpass --with-tcp-wrappers > > --with-ipv4-default --with-ipaddr-display > > --libexecdir=/usr/local/openssh/lib --disable-suid-ssh --with-pam > > > > I am running OpenSSL-0.9.5a compiled from source with: > > --prefix=/usr/local/openssl --openssldir=/usr/local/openssl > > Tried --with-ipv4-default? I believe that's usually what you want. Hmm well yes I did use that option on my client end, but not on the RH server side. (Not sure whether the RPMs were compiled with that option.) I just now re-compiled the RH6 box's copy with that option; no change, scp still hangs as before. :-\ -- Jim B. vader at conflict.net From ulf at openssl.org Tue Feb 20 09:41:19 2001 From: ulf at openssl.org (Ulf Moeller) Date: Mon, 19 Feb 2001 23:41:19 +0100 Subject: Dubious use of BN_num_bits in sshconnect1.c (resend) Message-ID: <20010219234119.A7371@openssl.org> >>(this brings up a related flaw in the BN_rand/BN_pseudo_rand (which is the >>reason this bug doesn't show up with OpenSSH servers) in that when called to >>generate an N-bit (pseudo)random number, these functions actually return N-1 >>bits of random data, with the msb set to 1, instead of the N random bits >>promised, but that's a side issue) >There is no flaw in BN_[pseudo_]rand() Looks like there is one, dating back all the way to SSLeay 0.6, and the OpenSSL manpage for this function was (foolishly) based on the SSLeay documentation. We'll investigate if this can be fixed directly or if we need a new bug-compatible option. By the way, it would be absolutely lovely and wonderful if people could report OpenSSL bugs to openssl-bugs at openssl.org. Ulf From ulf at openssl.org Tue Feb 20 10:15:42 2001 From: ulf at openssl.org (Ulf Moeller) Date: Tue, 20 Feb 2001 00:15:42 +0100 Subject: Dubious use of BN_num_bits in sshconnect1.c (resend) Message-ID: <20010220001542.A9210@openssl.org> I wrote: > Looks like there is one, dating back all the way to SSLeay 0.6, and the > OpenSSL manpage for this function was (foolishly) based on the SSLeay > documentation. We'll investigate if this can be fixed Actually it is more an omission in the OpenSSL docs than a flaw in the code. Sorry for any confusion I may have caused. From sah at uow.edu.au Tue Feb 20 10:51:57 2001 From: sah at uow.edu.au (Scott Hamilton) Date: Tue, 20 Feb 2001 10:51:57 +1100 Subject: openssh-2.3.0p1 for Solaris man pages Message-ID: <20010220105157.D24740@llama.its.uow.edu.au> Hi Team, I'm looking to "upgrade" my sites ssh installation from the original. I have built openssh-2.3.0p1 and it looks good. I am puzzled as to why there are so many source distributions? However, that is not why am writing - the man pages provided do not format with either Solaris 'nroff -man' or 'groff -man'. What am I missing here? Thanks for your help. Scott From pekkas at netcore.fi Tue Feb 20 11:05:51 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 20 Feb 2001 02:05:51 +0200 (EET) Subject: openssh-2.3.0p1 for Solaris man pages In-Reply-To: <20010220105157.D24740@llama.its.uow.edu.au> Message-ID: On Tue, 20 Feb 2001, Scott Hamilton wrote: > I'm looking to "upgrade" my sites ssh installation from > the original. I have built openssh-2.3.0p1 and it looks > good. I am puzzled as to why there are so many source > distributions? However, that is not why am writing - the > man pages provided do not format with either Solaris > 'nroff -man' or 'groff -man'. What am I missing here? -mandoc or -mdoc. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From josb at cncdsl.com Tue Feb 20 11:16:40 2001 From: josb at cncdsl.com (Jos Backus) Date: Mon, 19 Feb 2001 16:16:40 -0800 Subject: Portable OpenSSH 2.5.1p1: daemontools-aware? Message-ID: <20010219161640.A26669@lizzy.bugworks.com> Does this version implement the ability to be run under Dan Bernstein's supervise/multilog utilities? I.e. can sshd be told not to daemonize and log all messages to stdout/stderr instead of syslog? Thanks, -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From mouring at etoh.eviladmin.org Tue Feb 20 11:52:09 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 19 Feb 2001 18:52:09 -0600 (CST) Subject: Portable OpenSSH 2.5.1p1: daemontools-aware? In-Reply-To: <20010219161640.A26669@lizzy.bugworks.com> Message-ID: On Mon, 19 Feb 2001, Jos Backus wrote: > Does this version implement the ability to be run under Dan Bernstein's > supervise/multilog utilities? I.e. can sshd be told not to daemonize and log > all messages to stdout/stderr instead of syslog? > I have no clue who/what Dan Bernstein's tools are.. but 2.5.1 supports: sshd -d -D When this option is specified sshd will not detach and does not become a daemon. This allows easy monitoring of sshd. - Ben From josb at cncdsl.com Tue Feb 20 12:13:45 2001 From: josb at cncdsl.com (Jos Backus) Date: Mon, 19 Feb 2001 17:13:45 -0800 Subject: Portable OpenSSH 2.5.1p1: daemontools-aware? In-Reply-To: ; from mouring@etoh.eviladmin.org on Mon, Feb 19, 2001 at 06:51:47PM -0600 References: <20010219161640.A26669@lizzy.bugworks.com> Message-ID: <20010219171345.S26669@lizzy.bugworks.com> On Mon, Feb 19, 2001 at 06:51:47PM -0600, mouring at etoh.eviladmin.org wrote: > I have no clue who/what Dan Bernstein's tools are.. daemontools is a collection of tools for managing UNIX services. http://cr.yp.to/daemontools.html > but 2.5.1 supports: > > sshd -d > > -D When this option is specified sshd will not detach and does not > become a daemon. This allows easy monitoring of sshd. A patch seems still necessary, according to this message: > From: Antonio Dias > To: > Subject: ANNOUNCE: Patch for OpenSSH 2.5.1p1 run under tcpserver > > Since OpenSSH 2.5.1p1 doesn't include support for tcpserver and logging to > stdout (that new -D flag doesn't work and is useless) I've updated my > patch to this version. The diff file is available at > > -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From mikehan at mikehan.com Tue Feb 20 13:10:49 2001 From: mikehan at mikehan.com (Michael Han) Date: Mon, 19 Feb 2001 18:10:49 -0800 Subject: _PATH_STDPATH and @bindir@ Message-ID: <20010219181049.P63677@giles.mikehan.com> Sorry if this is stuff that's been talked about before. If it is, just ignore me. I'm curious to know why Portable OpenSSH doesn't include @bindir@ in the _PATH_STDPATH. This would save most installers of portable OpenSSH from having to --with-default-path=$PREFIX/bin in order to ensure that scp will work properly. This would also, I imagine, save quite a lot of hassle for developers/helpful-folks on the mailing list regarding FAQ 3.7. I could suggest a patch to do this, but figure you all know a better way than I'd suggest. Actually, might it not be better to have the server path be a run-time configurable option, rather than a build-time option? Anyway, at the very least, it'd be nice if the default installation weren't broken. -- mikehan at mikehan.com http://www.mikehan.com/ coffee achiever San Francisco, California "Notice how I blame my own mistakes on the lack of rules?" - Dan Espen From alex at foogod.com Tue Feb 20 13:58:28 2001 From: alex at foogod.com (alex at foogod.com) Date: Mon, 19 Feb 2001 18:58:28 -0800 Subject: Dubious use of BN_num_bits in sshconnect1.c In-Reply-To: <20010219150724.AC8D2207C1@citi.umich.edu> References: <20010219150724.AC8D2207C1@citi.umich.edu> Message-ID: <20010219185828.A27272@draco.foogod.com> On Mon, Feb 19, 2001 at 10:07:24AM -0500, Niels Provos wrote: > You should seriously consider updating the ssh-1.2.20 server to something > newer. Unfortunately, the server isn't mine. I will attempt to convince the administrator to upgrade (I was planning to anyway, actually).. > You are confused. In an N-bit RSA modulus the Nth bit is the most significant > bit. This is very different from an random integer taken from an N-bit range. > OpenSSH uses BN_num_bits correctly. Sorry about this.. as it turns out I was getting a bit muddled between n and e/d in the source (which is particularly embarrassing because they're quite clearly marked, I just wasn't paying attention). I'll just go off and be embarrassed in a corner now. sigh.. > There is no flaw in BN_[pseudo_]rand(), there is no such bug in > OpenSSH. Please, if you do not understand a particular issue, you > should not claim that somebody else is mistaken. Why don't you look > at the man pages the next time? Please, if you don't look at a peice of code, you should not patronize bug reporters. What I said was precisely correct, and is NOT documented in the manpage. BN_rand/BN_pseudo_rand set the msb to 1 even when the "top" parameter is false. But, this is an issue for another list (OpenSSL stuff). I mentioned it here mainly because when this behavior is fixed it may have ramifications for OpenSSH code which people might like to be aware of. -alex From kschrade at engin.umich.edu Tue Feb 20 15:00:04 2001 From: kschrade at engin.umich.edu (Kurt Schrader) Date: Mon, 19 Feb 2001 23:00:04 -0500 (EST) Subject: Possible OpenBSD client side bug In-Reply-To: Message-ID: Here ya go, sorry about the wait on that. [kschrade at cpddev3 kschrade]$ ssh -v -v -v blue OpenSSH_2.5.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090600f debug: Reading configuration data /etc/ssh/ssh_config debug: ssh_connect: getuid 502 geteuid 0 anon 0 debug: Connecting to blue [141.213.74.25] port 22. debug: Allocated local port 1022. debug: Connection established. debug: identity file /home/kschrade/.ssh/identity type 3 debug: identity file /home/kschrade/.ssh/id_dsa type 3 debug: Remote protocol version 1.5, remote software version 1.2.27 debug: no match: 1.2.27 debug: Local version string SSH-1.5-OpenSSH_2.5.1p1 debug: Waiting for server public key. debug: Received server public key (768 bits) and host key (1024 bits). The authenticity of host 'blue (141.213.74.25)' can't be established. RSA1 key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00. Are you sure you want to continue connecting (yes/no)? On Mon, 19 Feb 2001 mouring at etoh.eviladmin.org wrote: > On Mon, 19 Feb 2001, Kurt Schrader wrote: > > > > > OS: Redhat 7.0 > > OpenSSH Version: 2.5.1p1 > > Summary: Trying to connect to any host from this machine using OpenSSH > > gives the message: > > > > [kschrade at cpddev3 kschrade]$ ssh cressida > > The authenticity of host 'cressida (141.213.25.159)' can't be established. > > RSA1 key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00. > > Are you sure you want to continue connecting (yes/no)? > > > Hmm... I don't see OpenSSH 2.5.1 -> 2.5.1 under Redhat 7.0. Can we get > a ssh -v -v -v of the connection? > > - Ben > > From handler at sub-rosa.com Tue Feb 20 15:23:40 2001 From: handler at sub-rosa.com (Michael Handler) Date: Mon, 19 Feb 2001 23:23:40 -0500 Subject: Portable OpenSSH 2.5.1p1: daemontools-aware? In-Reply-To: <20010219171345.S26669@lizzy.bugworks.com> References: <20010219161640.A26669@lizzy.bugworks.com> <20010219171345.S26669@lizzy.bugworks.com> Message-ID: <20010219232340.C16648@califia.sub-rosa.com> Jos Backus writes: > A patch seems still necessary, according to this message: [...] > > Since OpenSSH 2.5.1p1 doesn't include support for tcpserver and logging to > > stdout (that new -D flag doesn't work and is useless) [...] This is incorrect. The -D flag works perfectly for what it was intended to do -- make the parent sshd process run in the foreground so that it can run cleanly under svscan and supervise from daemontools. Antonio is saying that it doesn't make sshd log to stdout or run under tcpserver (inetd mode), but that's a separate functionality request, not a bug. From cmadams at hiwaay.net Tue Feb 20 15:40:16 2001 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 19 Feb 2001 22:40:16 -0600 Subject: Problem with 2.5.1p1 client protocol v2 Message-ID: <20010219224016.A23134@HiWAAY.net> I have installed 2.5.1p1 on two systems, one running Digital Unix 4.0F and the other running Red Hat Linux 7.0. I am having trouble connecting using the 2.5.1p1 client and the version 2 protocol. Here is a connect attempt from the Linux box (this is after I blew away my ~/.ssh directory to make sure there was no "cruft" in it). Note that this also has the all zero key fingerprint that someone else just reported. ************************************************************************ Script started on Mon Feb 19 22:28:27 2001 cmadams:1:~$ ssh -2 -v -v -v fly OpenSSH_2.5.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f debug: Reading configuration data /etc/ssh/ssh_config debug: ssh_connect: getuid 500 geteuid 0 anon 0 debug: Connecting to fly [208.147.154.56] port 22. debug: Allocated local port 1022. debug: Connection established. debug: identity file /usr/local/home/cmadams/.ssh/id_dsa type 3 debug: Remote protocol version 1.99, remote software version OpenSSH_2.5.1p1 debug: match: OpenSSH_2.5.1p1 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug: Local version string SSH-2.0-OpenSSH_2.5.1p1 debug: Seeding random number generator debug: send KEXINIT debug: done debug: wait KEXINIT debug: got kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug: got kexinit: ssh-dss,ssh-rsa debug: got kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug: got kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 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: mac_init: found hmac-sha1 debug: kex: server->client 3des-cbc hmac-sha1 none debug: mac_init: found hmac-sha1 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: 1004/2049 debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. debug: Got SSH2_MSG_KEXDH_REPLY. The authenticity of host 'fly (208.147.154.56)' can't be established. RSA key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'fly,208.147.154.56' (RSA) to the list of known hosts. debug: bits set: 1041/2049 xfree: NULL pointer given as argument debug: Calling cleanup 0x8060670(0x0) cmadams:2:~$ Script done on Mon Feb 19 22:28:39 2001 ************************************************************************ I can successfully connect to the 2.5.1p1 server using protocol version 2 if I use a OpenSSH 2.3.0p1 client, but the 2.5.1p1 client always fails when trying protocol version 2 (even when connecting to a 2.3.0p1 server). Any ideas? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From josb at cncdsl.com Tue Feb 20 16:55:55 2001 From: josb at cncdsl.com (Jos Backus) Date: Mon, 19 Feb 2001 21:55:55 -0800 Subject: Portable OpenSSH 2.5.1p1: daemontools-aware? In-Reply-To: <20010219232340.C16648@califia.sub-rosa.com>; from handler@sub-rosa.com on Mon, Feb 19, 2001 at 11:23:18PM -0500 References: <20010219161640.A26669@lizzy.bugworks.com> <20010219171345.S26669@lizzy.bugworks.com> <20010219232340.C16648@califia.sub-rosa.com> Message-ID: <20010219215555.A71177@lizzy.bugworks.com> On Mon, Feb 19, 2001 at 11:23:18PM -0500, Michael Handler wrote: > This is incorrect. The -D flag works perfectly for what it was intended > to do -- make the parent sshd process run in the foreground so that it > can run cleanly under svscan and supervise from daemontools. Great! > Antonio is saying that it doesn't make sshd log to stdout or run under > tcpserver (inetd mode), but that's a separate functionality request, not a > bug. Agreed. -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From gert at greenie.muc.de Tue Feb 20 19:26:32 2001 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 20 Feb 2001 09:26:32 +0100 Subject: Portable OpenSSH 2.5.1p1 In-Reply-To: <20010219225636.F21559@folly>; from Markus Friedl on Mon, Feb 19, 2001 at 10:56:36PM +0100 References: <20010219160000.92A123C08B@mothra.mindrot.org> <20010219193735.A4074@greenie.muc.de> <20010219135247.A5888@alcove.wittsend.com> <20010219222942.B8562@greenie.muc.de> <20010219225636.F21559@folly> Message-ID: <20010220092632.A22885@greenie.muc.de> Hi, On Mon, Feb 19, 2001 at 10:56:36PM +0100, Markus Friedl wrote: > On Mon, Feb 19, 2001 at 10:29:42PM +0100, Gert Doering wrote: > > Without checking for privileged ports, you're effectively making > > RhostsRsaAuthentication completely useless, as every user can disguise as > > every other user, and should then better drop it completely. > > no. only root can read the hostkey file, so the client > is trusted because it knows the hostkey. OK, thanks for clarifying this (I hope the client checks that the host key has the correct file modes?). Maybe that should have gone into the announcement... without, it lead to wrong assumptions. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From Markus.Friedl at informatik.uni-erlangen.de Tue Feb 20 20:29:54 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Tue, 20 Feb 2001 10:29:54 +0100 Subject: Portable OpenSSH 2.5.1p1: daemontools-aware? In-Reply-To: <20010219161640.A26669@lizzy.bugworks.com>; from josb@cncdsl.com on Mon, Feb 19, 2001 at 04:16:40PM -0800 References: <20010219161640.A26669@lizzy.bugworks.com> Message-ID: <20010220102954.A23932@faui02.informatik.uni-erlangen.de> On Mon, Feb 19, 2001 at 04:16:40PM -0800, Jos Backus wrote: > Does this version implement the ability to be run under Dan Bernstein's > supervise/multilog utilities? I.e. can sshd be told not to daemonize and log > all messages to stdout/stderr instead of syslog? yes, with -D. no, logging to stdout is only supported for debugging. From a.d.stribblehill at durham.ac.uk Tue Feb 20 20:35:14 2001 From: a.d.stribblehill at durham.ac.uk (Andrew Stribblehill) Date: Tue, 20 Feb 2001 09:35:14 +0000 Subject: Question about ssh-add... In-Reply-To: <20010219211145.A8704@mail.orbiteam.de>; from paulsen@orbiteam.de on Mon, Feb 19, 2001 at 09:11:45PM +0100 References: <20010219211145.A8704@mail.orbiteam.de> Message-ID: <20010220093514.A30982@womble.dur.ac.uk> Quoting Volker Paulsen : > Evenin', > > I would like to know, why "OpenSSH ssh-add" doesn't support the -p > (pipe) option of "Ssh-1.2.X shh-add"? I used it several time within > scripts, like > > ./whisperpassphrase | ssh-add -p > > Well, I know this is some kind of security by obscurity, but this has > been proven to be handy. You could easily do this to the same effect: $ cat whisperpassphrase #! /bin/sh # echo 'secret hax0r passphrase' $ SSH_ASKPASS=./whisperpassphrase ssh-add <&- Identity added: /home/foo/.ssh/identity (foo at bar) In my opinion, it's better to make people /think/ about whether they really need this, and to make them work for it, rather than have this too-easy pipe thing. Call it security by cluefulness! Cheerio, Andrew Stribblehill Systems programmer, IT Service, University of Durham, England From Lutz.Jaenicke at aet.TU-Cottbus.DE Tue Feb 20 20:40:30 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 20 Feb 2001 10:40:30 +0100 Subject: ssh-agent and id_dsa Message-ID: <20010220104029.A19671@ws01.aet.tu-cottbus.de> Hi! I am distributing 2.5.1p1 for production use on my system by now and prepare switching to protocol 2 as default protocol. I just noted, that ssh-agent can be used for protocol 1 and 2, but the keys kept in ssh-agent are not compared against keys in .ssh. Example: I have a DSA key in id_dsa which I load into ssh-agent on login. When connecting to an account accepting the key everything is fine. If the key is not accepted, slogin will not recognize that the key was already tried from ssh-agent and will ask me again to enter the password to unlock the key (for another failure). This is due to sshconnect2.c:userauth_pubkey() where this retrial is not performed for KEY_RSA1 but for other keys. I did not dig into the functionality yet. Is there a way to "remember" which pubkeys were already tried from ssh-agent and to not try again from file (and hence ask for the passphrase)? 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 Markus.Friedl at informatik.uni-erlangen.de Tue Feb 20 21:12:19 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Tue, 20 Feb 2001 11:12:19 +0100 Subject: ssh-agent and id_dsa In-Reply-To: <20010220104029.A19671@ws01.aet.tu-cottbus.de>; from Lutz.Jaenicke@aet.TU-Cottbus.DE on Tue, Feb 20, 2001 at 10:40:30AM +0100 References: <20010220104029.A19671@ws01.aet.tu-cottbus.de> Message-ID: <20010220111219.A25897@faui02.informatik.uni-erlangen.de> why don't you rename the key? :) does the protocol-1 implementation remember keys? On Tue, Feb 20, 2001 at 10:40:30AM +0100, Lutz Jaenicke wrote: > Hi! > > I am distributing 2.5.1p1 for production use on my system by now and prepare > switching to protocol 2 as default protocol. > > I just noted, that ssh-agent can be used for protocol 1 and 2, but the > keys kept in ssh-agent are not compared against keys in .ssh. > Example: I have a DSA key in id_dsa which I load into ssh-agent on login. > When connecting to an account accepting the key everything is fine. > If the key is not accepted, slogin will not recognize that the key was > already tried from ssh-agent and will ask me again to enter the password > to unlock the key (for another failure). > This is due to sshconnect2.c:userauth_pubkey() where this retrial is not > performed for KEY_RSA1 but for other keys. > I did not dig into the functionality yet. Is there a way to "remember" > which pubkeys were already tried from ssh-agent and to not try again > from file (and hence ask for the passphrase)? > > 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 Tue Feb 20 21:35:36 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 20 Feb 2001 11:35:36 +0100 Subject: ssh-agent and id_dsa In-Reply-To: <20010220111219.A25897@faui02.informatik.uni-erlangen.de>; from Markus.Friedl@informatik.uni-erlangen.de on Tue, Feb 20, 2001 at 11:12:19AM +0100 References: <20010220104029.A19671@ws01.aet.tu-cottbus.de> <20010220111219.A25897@faui02.informatik.uni-erlangen.de> Message-ID: <20010220113536.B19903@ws01.aet.tu-cottbus.de> On Tue, Feb 20, 2001 at 11:12:19AM +0100, Markus Friedl wrote: > why don't you rename the key? :) Because I use ssh-agent when I sit in front of my workstation (automatic startup via CDE, really practical thing). When I log in from remote via slogin, I don't always startup ssh-agent and then it is ok to be asked :-) > does the protocol-1 implementation remember keys? Hmm, you tend to ask difficult questions... ws01 23: slogin -v -p 24 -l root ws01 OpenSSH_2.5.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090600f debug: Reading configuration data /home/aet/serv01/jaenicke/.ssh/config debug: Reading configuration data /etc/ssh/ssh_config debug: Applying options for * debug: ssh_connect: getuid 11019 geteuid 0 anon 0 debug: Connecting to ws01 [141.43.132.151] port 24. debug: Seeding random number generator debug: Allocated local port 601. debug: Connection established. debug: identity file /home/aet/serv01/jaenicke/.ssh/identity type 0 debug: identity file /home/aet/serv01/jaenicke/.ssh/id_dsa type 3 debug: Remote protocol version 1.99, remote software version OpenSSH_2.5.1p1 debug: match: OpenSSH_2.5.1p1 pat ^OpenSSH debug: Local version string SSH-1.5-OpenSSH_2.5.1p1 debug: Waiting for server public key. debug: Received server public key (768 bits) and host key (1024 bits). debug: Host 'ws01' is known and matches the RSA1 host key. debug: Found key in /etc/ssh/ssh_known_hosts:23 debug: Seeding random number generator debug: Encryption type: 3des debug: Sent encrypted session key. debug: Installing crc compensation attack detector. debug: Received encrypted confirmation. debug: Trying RSA authentication via agent with 'jaenicke at emserv1' debug: Server refused our key. debug: RSA authentication using agent refused. debug: Trying RSA authentication with key 'jaenicke at emserv1' debug: Server refused our key. debug: Doing password authentication. root at ws01's password: ... On the server this looks like: debug1: Bind to port 24 on 0.0.0.0. Server listening on 0.0.0.0 port 24. Generating 768 bit RSA key. debug1: Seeding random number generator RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 141.43.132.151 port 601 debug1: Client protocol version 1.5; client software version OpenSSH_2.5.1p1 debug1: match: OpenSSH_2.5.1p1 pat ^OpenSSH debug1: Local version string SSH-1.99-OpenSSH_2.5.1p1 debug1: Sent 768 bit server key and 1024 bit host key. debug1: Encryption type: 3des debug1: Received session key; encryption turned on. debug1: Installing crc compensation attack detector. debug1: Attempting authentication for root. Failed rsa for ROOT from 141.43.132.151 port 601 Failed rsa for ROOT from 141.43.132.151 port 601 ... So obviously, it remembers the key... identity file /home/aet/serv01/jaenicke/.ssh/identity type 0 is the RSA1 key I am using. It is passphrase protected and loaded into ssh-agent. ws01 23: ssh-add -l 1024 30:a7:58:3e:f5:bc:a2:0e:f5:16:09:71:b6:56:1e:ec jaenicke at emserv1 (RSA1) 1024 de:f8:a8:98:4b:18:9f:5f:d0:6f:67:91:1d:f7:c4:6a /home/aet/serv01/jaenicke/.ssh/id_dsa (DSA) If I try the same with protocol 2: ... debug: authentications that can continue: publickey,password,keyboard-interactive debug: next auth method to try is publickey debug: userauth_pubkey_agent: trying agent key /home/aet/serv01/jaenicke/.ssh/id_dsa debug: authentications that can continue: publickey,password,keyboard-interactive debug: next auth method to try is publickey debug: try pubkey: /home/aet/serv01/jaenicke/.ssh/id_dsa debug: PEM_read_PrivateKey failed debug: read SSH2 private key done: name success 0 Enter passphrase for key '/home/aet/serv01/jaenicke/.ssh/id_dsa': debug: read SSH2 private key done: name dsa w/o comment success 1 debug: sig size 20 20 debug: authentications that can continue: publickey,password,keyboard-interactive debug: next auth method to try is publickey debug: next auth method to try is password root at ws01's password: ... and on the server: ... debug1: userauth-request for user root service ssh-connection method none debug1: attempt 0 failures 0 Failed none for ROOT from 141.43.132.151 port 813 ssh2 debug1: userauth-request for user root service ssh-connection method publickey debug1: attempt 1 failures 1 Failed publickey for ROOT from 141.43.132.151 port 813 ssh2 debug1: userauth-request for user root service ssh-connection method publickey debug1: attempt 2 failures 2 Failed publickey for ROOT from 141.43.132.151 port 813 ssh2 ... 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 stas at zend.com Wed Feb 21 02:11:15 2001 From: stas at zend.com (Stanislav Malyshev) Date: Tue, 20 Feb 2001 17:11:15 +0200 (IST) Subject: Cannot connect to OpenSSH 2.5.1p1 Message-ID: I've installed today the openssh-2.5.1p1 from RPMS and I cannot use it with protocol 2. It gives: OpenSSH_2.5.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090600f debug: Reading configuration data /etc/ssh/ssh_config debug: Applying options for * debug: ssh_connect: getuid 500 geteuid 0 anon 0 debug: Connecting to int [10.1.1.1] port 22. debug: Seeding random number generator debug: Allocated local port 963. debug: Connection established. debug: identity file /home/user/.ssh/identity type 0 debug: Remote protocol version 1.99, remote software version OpenSSH_2.5.1p1 debug: match: OpenSSH_2.5.1p1 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug: Local version string SSH-2.0-OpenSSH_2.5.1p1 debug: send KEXINIT debug: done debug: wait KEXINIT debug: got kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug: got kexinit: ssh-dss,ssh-rsa debug: got kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug: got kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 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. debug: Got SSH2_MSG_KEX_DH_GEX_GROUP. debug: bits set: 1047/2049 debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. Connection closed by 10.1.1.1 debug: Calling cleanup 0x805efd0(0x0) And the conenction is dropped. The server says in the log: Feb 20 17:01:41 server sshd[5525]: fatal: xfree: NULL pointer given as argument and that's it. Any ideas? Protocol 1 works OK, so did protocol 2 with 2.3.0. -- Stanislav Malyshev, Zend Products Engineer stas at zend.com http://www.zend.com/ +972-3-6139665 ext.115 From lzirkel at cleverly.com Wed Feb 21 02:44:08 2001 From: lzirkel at cleverly.com (Louis D. Zirkel III) Date: Tue, 20 Feb 2001 08:44:08 -0700 (MST) Subject: Cannot connect to OpenSSH 2.5.1p1 In-Reply-To: Message-ID: On Tue, 20 Feb 2001, Stanislav Malyshev wrote: > I've installed today the openssh-2.5.1p1 from RPMS and I cannot use it > with protocol 2. It gives: > > ... > > And the conenction is dropped. The server says in the log: > > Feb 20 17:01:41 server sshd[5525]: fatal: xfree: NULL pointer given as > argument > > and that's it. Any ideas? Protocol 1 works OK, so did protocol 2 with > 2.3.0. When I had this same problem I got the latest openssl rpms from RedHat (I had the ones from OpenSSH.com) and it resolved the problem. What the difference is between the two I don't know. You might give that a try. -- Louis Zirkel III (lzirkel at cleverly.com) System Admin/Programmer "We're living on the Edge of the Century" -- Styx From J.Horne at plymouth.ac.uk Wed Feb 21 02:49:40 2001 From: J.Horne at plymouth.ac.uk (John Horne) Date: Tue, 20 Feb 2001 15:49:40 -0000 (GMT) Subject: Cannot connect to OpenSSH 2.5.1p1 In-Reply-To: Message-ID: On 20-Feb-01 at 15:11:15 Stanislav Malyshev wrote: > I've installed today the openssh-2.5.1p1 from RPMS and I cannot use it > with protocol 2. It gives: > [snipped] > debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. > debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. > Connection closed by 10.1.1.1 > debug: Calling cleanup 0x805efd0(0x0) > > And the conenction is dropped. The server says in the log: > > Feb 20 17:01:41 server sshd[5525]: fatal: xfree: NULL pointer given as > argument > I got this last night when trying to login to my work PC from home. The problem seemed to stem from the fact that I tried to install openssl 0.9.6 rpms at work yesterday (with openssh 2.3.1 (I think) rpms). I've gone back to openssl 0.9.5a and am using openssh 2.5.1p1 rpms with no problem. On the Sun's we have no problem with 0.9.6 and openssh 2.5.1p1 but they are complied from source. I suspect that compling openssl and openssh both from source on the linux box will sort it out. 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 Wed Feb 21 03:11:20 2001 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 20 Feb 2001 17:11:20 +0100 Subject: openssh wish list for 2.6.* Message-ID: <20010220171120.E25490@greenie.muc.de> Hi, something that I'd like to see for the next major release is "build OpenSSH without installing zlib and openssl". That is, I have a source tree with the following subdirectories: .../src/zlib-1.1.3/ /openssl-0.9.6/ /openssh_cvs/ and want "configure", run from openssh_cvs, to be able to find the zlib and openssl trees in the directory "upstairs". This is useful if you don't have any other software on the system that uses openssl (no web servers or the like installed here) and do not want to fill up your $prefix/ with lots of stuff that isn't actually used. It works, kind of, right now, if I do the following: - call configure with CFLAGS="-I../zlib-1.1.3" LDFLAGS="-L../zlib-1.1.3" - change configure to include "../openssl-0.9.6" in the list of directories to search for -lcrypto - change the resulting openbsd-compat/Makefile to "-I../../openssl-0.9.6" (configure puts "-I../openssl-0.9.6" in there, not knowing that it's a relative path, and thus failing). So this is not something really pressing, but would save me some time every time I run "autoconf"... and maybe others would benefit from it as well. 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 Nigel.Metheringham at InTechnology.co.uk Wed Feb 21 03:20:44 2001 From: Nigel.Metheringham at InTechnology.co.uk (Nigel Metheringham) Date: Tue, 20 Feb 2001 16:20:44 +0000 Subject: Cannot connect to OpenSSH 2.5.1p1 In-Reply-To: Message from "Louis D. Zirkel III" of "Tue, 20 Feb 2001 08:44:08 MST." Message-ID: lzirkel at cleverly.com said: > When I had this same problem I got the latest openssl rpms from RedHat > (I had the ones from OpenSSH.com) and it resolved the problem. What > the difference is between the two I don't know. You might give that a > try. Red Hat broke their openssl libraries - badly. It appears they spent time knocking out anything that could have patent problems, but since they didn't change the version numbers or signatures, things still link against their libraries but crash later. Avoid any RH crypto code for this reason. In general recompile all packages for your own environment. Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] From mouring at etoh.eviladmin.org Wed Feb 21 03:35:05 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 20 Feb 2001 10:35:05 -0600 (CST) Subject: openssh wish list for 2.6.* In-Reply-To: <20010220171120.E25490@greenie.muc.de> Message-ID: On Tue, 20 Feb 2001, Gert Doering wrote: > Hi, > > something that I'd like to see for the next major release is "build > OpenSSH without installing zlib and openssl". > > That is, I have a source tree with the following subdirectories: > > .../src/zlib-1.1.3/ > /openssl-0.9.6/ > /openssh_cvs/ > > and want "configure", run from openssh_cvs, to be able to find the zlib > and openssl trees in the directory "upstairs". > That's great until there is a 1.1.4 release of zlib or a 0.9.7 release of openssl. Unless you can write the patch to account for such things then I think you'll need to keep setting CFLAGS/LDFLAGS. Also consider if people have openssl-0.9.6 and openssl-1.0.0 .. Which one do we guess is right? I'm more in favor of the correct usage of: --with-ssl-dir=PATH Specify path to OpenSSL installation And maybe adding in: --with-zlib-dir=PATH - Ben From mdb at juniper.net Wed Feb 21 03:33:06 2001 From: mdb at juniper.net (Mark D. Baushke) Date: Tue, 20 Feb 2001 08:33:06 -0800 Subject: Cannot connect to OpenSSH 2.5.1p1 In-Reply-To: Mail from John Horne dated Tue, 20 Feb 2001 15:49:40 GMT Message-ID: <200102201633.IAA78057@garnet.juniper.net> > Date: Tue, 20 Feb 2001 15:49:40 -0000 (GMT) > From: John Horne > > On 20-Feb-01 at 15:11:15 Stanislav Malyshev wrote: > > I've installed today the openssh-2.5.1p1 from RPMS and I cannot use it > > with protocol 2. It gives: > > > [snipped] > > debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. > > debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. > > Connection closed by 10.1.1.1 > > debug: Calling cleanup 0x805efd0(0x0) > > > > And the conenction is dropped. The server says in the log: > > > > Feb 20 17:01:41 server sshd[5525]: fatal: xfree: NULL pointer given as > > argument > > > I got this last night when trying to login to my work PC from home. The > problem seemed to stem from the fact that I tried to install openssl 0.9.6 > rpms at work yesterday (with openssh 2.3.1 (I think) rpms). I've gone back to > openssl 0.9.5a and am using openssh 2.5.1p1 rpms with no problem. On the > Sun's we have no problem with 0.9.6 and openssh 2.5.1p1 but they are > complied from source. I suspect that compling openssl and openssh both from > source on the linux box will sort it out. I had a similar problem and recompiling from the sources fixed it. I am now using openssl-0.9.6 with openssh 2.5.1p1 with no problems on Red Hat Linux 6.2. -- Mark From gert at greenie.muc.de Wed Feb 21 03:33:29 2001 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 20 Feb 2001 17:33:29 +0100 Subject: openssh wish list for 2.6.* In-Reply-To: ; from mouring@etoh.eviladmin.org on Tue, Feb 20, 2001 at 10:35:05AM -0600 References: <20010220171120.E25490@greenie.muc.de> Message-ID: <20010220173329.N25490@greenie.muc.de> Hi, On Tue, Feb 20, 2001 at 10:35:05AM -0600, mouring at etoh.eviladmin.org wrote: > > and want "configure", run from openssh_cvs, to be able to find the zlib > > and openssl trees in the directory "upstairs". > > That's great until there is a 1.1.4 release of zlib or a 0.9.7 release > of openssl. Unless you can write the patch to account for such things > then I think you'll need to keep setting CFLAGS/LDFLAGS. I thought about that, yes, and was thinking about "look for well-known versions that are also known to work". > Also consider > if people have openssl-0.9.6 and openssl-1.0.0 .. Which one do we guess > is right? Yep. Good point. "The one that is known to work and has the highest version number"? Right now, only 0.9.5a and 0.9.6 will work, so that wouldn't be too hard... > I'm more in favor of the correct usage of: > > --with-ssl-dir=PATH Specify path to OpenSSL installation > > And maybe adding in: > > --with-zlib-dir=PATH This would be fine for me (I run configure from a script anyway due to the length command line, with --with-egd... and --with-skey=... and so on). 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 jennings at triumf.ca Wed Feb 21 03:55:10 2001 From: jennings at triumf.ca (Byron Jennings) Date: Tue, 20 Feb 2001 08:55:10 -0800 (PST) Subject: sftd problem on Tru64 Unix Message-ID: I have a Digital Unix Version 4.0B and openssh works fine excect for sftpd. I can do most things things with sftp (copy files, change directories) but when I do an ls it drops the connection. This is with the most recent version of openssh "OpenSSH_2.5.1p1". I have included the output of sftpd -v -v . OpenSSH was complied with the gcc version 2.95.2 19991024 Byron Jennings ______________________________________________________________________________________________ Connecting to alph01... debug: SSH args "ssh -oProtocol=2 -s -oForwardAgent=no -oForwardX11=no -v -v alph01 sftp" OpenSSH_2.5.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f debug: Reading configuration data /home/jennings/.ssh/config debug: Applying options for alph01 debug: Applying options for * debug: Reading configuration data /home/jennings/ssh/etc/ssh_config debug: Rhosts Authentication disabled, originating port will not be trusted. debug: ssh_connect: getuid 278 geteuid 278 anon 1 debug: Connecting to alph01 [142.90.114.17] port 22. debug: Connection established. debug: identity file /home/jennings/keys/theory_dsa type 3 debug: identity file /home/jennings/keys/user_dsa type 3 debug: Remote protocol version 1.99, remote software version OpenSSH_2.5.1p1 debug: match: OpenSSH_2.5.1p1 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug: Local version string SSH-2.0-OpenSSH_2.5.1p1 debug: Seeding random number generator debug: send KEXINIT debug: done debug: wait KEXINIT debug: got kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug: got kexinit: ssh-dss,ssh-rsa debug: got kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijn dael256-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,rijn dael256-cbc,rijndael-cbc at lysator.liu.se debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 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: mac_init: found hmac-sha1 debug: kex: server->client blowfish-cbc hmac-sha1 none debug: mac_init: found hmac-sha1 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. debug: Got SSH2_MSG_KEX_DH_GEX_GROUP. debug: bits set: 1032/2049 debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. debug: Got SSH2_MSG_KEXDH_REPLY. debug: Host 'alph01' is known and matches the RSA host key. debug: Found key in /home/jennings/.ssh/known_hosts2:48 debug: bits set: 1003/2049 debug: ssh_rsa_verify: signature correct debug: Wait SSH2_MSG_NEWKEYS. debug: GOT SSH2_MSG_NEWKEYS. debug: send SSH2_MSG_NEWKEYS. debug: done: send SSH2_MSG_NEWKEYS. debug: done: KEX2. debug: send SSH2_MSG_SERVICE_REQUEST debug: service_accept: ssh-userauth debug: got SSH2_MSG_SERVICE_ACCEPT debug: authentications that can continue: publickey,password,keyboard-interactive debug: next auth method to try is publickey debug: userauth_pubkey_agent: trying agent key keys/user_dsa debug: we sent a publickey packet, wait for reply debug: ssh-userauth2 successful: method publickey debug: fd 4 setting O_NONBLOCK debug: fd 5 IS 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: Sending subsystem: sftp debug: callback done debug: channel 0: open confirm rwindow 0 rmax 16384 debug: channel 0: rcvd adjust 32768 debug: Remote version: 2 sftp> ls debug: client_input_channel_req: channel 0 rtype exit-signal 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 2.3 seconds debug: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug: Exit status -1 Couldn't read packet: Bad file descriptor From johan.adolfsson at axis.com Wed Feb 21 03:56:04 2001 From: johan.adolfsson at axis.com (Johan Adolfsson) Date: Tue, 20 Feb 2001 17:56:04 +0100 Subject: openssh wish list for 2.6.* References: <20010220171120.E25490@greenie.muc.de> <20010220173329.N25490@greenie.muc.de> Message-ID: <00a101c09b5e$02e495e0$0a070d0a@axis.se> (Maybe slightly off topic) When experimenting with crosscompiling openSSH for our own CPU I have the needed libraries (libssl, libcrypto etc.) installed in a lib directory where i build the target image, I guess you could do something similar? (instead of having -L options pointing out the specific source locations, install the needed lib somewhere locally and have a single -L entry pointing to that location) I do something like this from a "top" Makefile (it's not nice I know...:) working as a wrapper for the openssl configur script and Makefile. (I posted some patches to improve crosscompilability some time ago, but haven't checked if they ever made it to the CVS) CONFOPTIONS = \ --with-random=/dev/urandom \ --prefix= \ --with-ssl-dir=$(prefix) \ --localstatedir=/var \ --sysconfdir=/etc CONFTARGET = elinux-aout-etrax100 CONFOPTIONS += --includedir=$(prefix)/include/uC-libc CFLAGS += -I$(prefix)/include LDFLAGS += -L$(prefix)/lib #CFLAGS += -static #LDFLAGS += -static OPTS= -DGETPGRP_VOID=1 ENVSETTINGS = WANTS_RSAREF=0 ENVSETTINGS += no_dev_ptmx=1 ENVSETTINGS += no_dev_ptc=1 ENVSETTINGS += rsa_works=1 all: build configure $(WRAPDIR)/Makefile: $(WRAPDIR)/Makefile.in rm -f $(WRAPDIR)/config.cache (cd $(WRAPDIR); RANLIB="$(RANLIB)" AR="$(AR)" INSTALL="$(INSTALL)" CC="$ (CC)" CPP="$(CPP)" CPPLAGS="$(CPPLAGS)" CFLAGS="$(CFLAGS) $(OPTS)" LDFLAGS="$(LDFLAGS)" HOST="\"elinux\"" $(ENVSETTINGS) DESTDIR=$(prefix) ./configure $(CONFOPTIONS) ) Any better ideas? /Johan ----- Original Message ----- From: Gert Doering To: ; Gert Doering Cc: Sent: Tuesday, February 20, 2001 17:33 Subject: Re: openssh wish list for 2.6.* > Hi, > > On Tue, Feb 20, 2001 at 10:35:05AM -0600, mouring at etoh.eviladmin.org wrote: > > > and want "configure", run from openssh_cvs, to be able to find the zlib > > > and openssl trees in the directory "upstairs". > > > > That's great until there is a 1.1.4 release of zlib or a 0.9.7 release > > of openssl. Unless you can write the patch to account for such things > > then I think you'll need to keep setting CFLAGS/LDFLAGS. > > I thought about that, yes, and was thinking about "look for well-known > versions that are also known to work". > > > Also consider > > if people have openssl-0.9.6 and openssl-1.0.0 .. Which one do we guess > > is right? > > Yep. Good point. "The one that is known to work and has the highest > version number"? Right now, only 0.9.5a and 0.9.6 will work, so that > wouldn't be too hard... > > > I'm more in favor of the correct usage of: > > > > --with-ssl-dir=PATH Specify path to OpenSSL installation > > > > And maybe adding in: > > > > --with-zlib-dir=PATH > > This would be fine for me (I run configure from a script anyway due to > the length command line, with --with-egd... and --with-skey=... and > so on). > > gert > > > -- > USENET is *not* the non-clickable part of WWW! > file://www.muc.de/~gert/ > Gert Doering - Munich, Germany gert at greenie.muc.de > fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de > From mouring at etoh.eviladmin.org Wed Feb 21 04:26:25 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 20 Feb 2001 11:26:25 -0600 (CST) Subject: (Solaris) Linker flags in 2.5.1p1... (fwd) Message-ID: Comments from the rest of the Solaris group? - Ben ---------- Forwarded message ---------- Date: Tue, 20 Feb 2001 11:20:33 +0100 From: Volker Paulsen To: mouring at etoh.eviladmin.org Subject: Linker flags in 2.5.1p1... While I'm compiling 2.5.1p1, I've got the following remarks: Host: sparc-sun-solaris2.7 Compiler: cc Compiler flags: -fast -xarch=v7 Preprocessor flags: -I/usr/local/include -I../include -I../include Linker flags: -L../lib/sol7/sparcv7 -L/usr/local/lib -R/usr/local/lib -L/usr/ucblib -R/usr/ucblib -L../lib -R../lib -L../lib -R../lib Libraries: -lwrap -lz -lsocket -lnsl -lgen -lcrypto You should not ever use '-L/usr/ucblib -R/usr/ucblib', since Solaris BSD compat libraries are evil broken and AFIAK you don't need anything from /usr/ucblib. Ignore '-L../lib/sol7/sparcv7'; this is for my multi sparc platform build. Also ignore '-L../lib -R../lib', which is generated by the --with-ssl-dir=.. switch. Regards, --Volker From stas at zend.com Wed Feb 21 04:40:46 2001 From: stas at zend.com (Stanislav Malyshev) Date: Tue, 20 Feb 2001 19:40:46 +0200 (IST) Subject: Cannot connect to OpenSSH 2.5.1p1 In-Reply-To: Message-ID: LDZI>> When I had this same problem I got the latest openssl rpms LDZI>> from RedHat (I had the ones from OpenSSH.com) and it LDZI>> resolved the problem. What the difference is between the LDZI>> two I don't know. You might give that a try. Recompiling from .src.rpm solved it. Thanks for the advice. BTW, I have openssl from rpms taken from OpenSSL.org, still works. -- Stanislav Malyshev, Zend Products Engineer stas at zend.com http://www.zend.com/ +972-3-6139665 ext.115 From mdb at juniper.net Wed Feb 21 04:38:54 2001 From: mdb at juniper.net (Mark D. Baushke) Date: Tue, 20 Feb 2001 09:38:54 -0800 Subject: (Solaris) Linker flags in 2.5.1p1... (fwd) In-Reply-To: Mail from dated Tue, 20 Feb 2001 11:26:25 CST Message-ID: <200102201738.JAA86032@garnet.juniper.net> Hi Ben, I agree with Volker Paulsen . Use of ucblib should be depricated. On Solaris 2.6, removing the '-L/usr/ucblib -R/usr/ucblib' still lets everything link and work correctly. It would be well to remove this extra bloat if possible. (I have not tried on Solaris 7 or Solaris 8.) -- Mark PS: An 'ldd' of the OpenSSH-2.5.1p1 executables shows that nothing is being picked up out of the /usr/ucblib libraries in any case (a default build ends up using --without-pam, but even forcing a --with-pam shows the same result). So it is not an urgent problem to address. /usr/local/bin/scp: libz.so.1.1.3 => /usr/local/lib/libz.so.1.1.3 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/local/bin/sftp: libz.so.1.1.3 => /usr/local/lib/libz.so.1.1.3 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/local/bin/slogin: libz.so.1.1.3 => /usr/local/lib/libz.so.1.1.3 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/local/bin/ssh: libz.so.1.1.3 => /usr/local/lib/libz.so.1.1.3 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/local/bin/ssh-add: libz.so.1.1.3 => /usr/local/lib/libz.so.1.1.3 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/local/bin/ssh-agent: libz.so.1.1.3 => /usr/local/lib/libz.so.1.1.3 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/local/bin/ssh-keygen: libz.so.1.1.3 => /usr/local/lib/libz.so.1.1.3 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/local/bin/ssh-keyscan: libz.so.1.1.3 => /usr/local/lib/libz.so.1.1.3 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/local/openssh/sbin/sshd: libz.so.1.1.3 => /usr/local/lib/libz.so.1.1.3 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 > Date: Tue, 20 Feb 2001 11:26:25 -0600 (CST) > From: > > Comments from the rest of the Solaris group? > > - Ben > > ---------- Forwarded message ---------- > Date: Tue, 20 Feb 2001 11:20:33 +0100 > From: Volker Paulsen > To: mouring at etoh.eviladmin.org > Subject: Linker flags in 2.5.1p1... > > While I'm compiling 2.5.1p1, I've got the following remarks: > > Host: sparc-sun-solaris2.7 > Compiler: cc > Compiler flags: -fast -xarch=v7 > Preprocessor flags: -I/usr/local/include -I../include -I../include > Linker flags: -L../lib/sol7/sparcv7 -L/usr/local/lib -R/usr/local/lib -L/usr/ucblib -R/usr/ucblib -L../lib -R../lib -L../lib -R../lib > Libraries: -lwrap -lz -lsocket -lnsl -lgen -lcrypto > > You should not ever use '-L/usr/ucblib -R/usr/ucblib', since Solaris BSD > compat libraries are evil broken and AFIAK you don't need anything from > /usr/ucblib. > > Ignore '-L../lib/sol7/sparcv7'; this is for my multi sparc platform > build. Also ignore '-L../lib -R../lib', which is > generated by the --with-ssl-dir=.. switch. > > Regards, > --Volker From devon at admin2.gisnetworks.com Wed Feb 21 04:43:08 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Tue, 20 Feb 2001 09:43:08 -0800 Subject: (Solaris) Linker flags in 2.5.1p1... (fwd) References: Message-ID: <008a01c09b64$96920240$1900a8c0@devn> everything compiles and runs on my solaris 7 system without 'em... (doesn't actually fix anything though, afaict :/ ) devon ----- Original Message ----- From: To: Sent: Tuesday, February 20, 2001 9:26 AM Subject: (Solaris) Linker flags in 2.5.1p1... (fwd) > > > Comments from the rest of the Solaris group? > > - Ben > > ---------- Forwarded message ---------- > Date: Tue, 20 Feb 2001 11:20:33 +0100 > From: Volker Paulsen > To: mouring at etoh.eviladmin.org > Subject: Linker flags in 2.5.1p1... > > While I'm compiling 2.5.1p1, I've got the following remarks: > > Host: sparc-sun-solaris2.7 > Compiler: cc > Compiler flags: -fast -xarch=v7 > Preprocessor flags: -I/usr/local/include -I../include -I../include > Linker flags: -L../lib/sol7/sparcv7 -L/usr/local/lib -R/usr/local/lib -L/usr/ucblib -R/usr/ucblib -L../lib -R../lib -L../lib -R../lib > Libraries: -lwrap -lz -lsocket -lnsl -lgen -lcrypto > > You should not ever use '-L/usr/ucblib -R/usr/ucblib', since Solaris BSD > compat libraries are evil broken and AFIAK you don't need anything from > /usr/ucblib. > > Ignore '-L../lib/sol7/sparcv7'; this is for my multi sparc platform > build. Also ignore '-L../lib -R../lib', which is > generated by the --with-ssl-dir=.. switch. > > Regards, > --Volker > > > From J.Horne at plymouth.ac.uk Wed Feb 21 05:01:30 2001 From: J.Horne at plymouth.ac.uk (John Horne) Date: Tue, 20 Feb 2001 18:01:30 -0000 (GMT) Subject: (Solaris) Linker flags in 2.5.1p1... (fwd) In-Reply-To: Message-ID: On 20-Feb-01 at 17:26:25 mouring at etoh.eviladmin.org wrote: > While I'm compiling 2.5.1p1, I've got the following remarks: > > Host: sparc-sun-solaris2.7 > Compiler: cc > Compiler flags: -fast -xarch=v7 > Preprocessor flags: -I/usr/local/include -I../include -I../include > Linker flags: -L../lib/sol7/sparcv7 -L/usr/local/lib > -R/usr/local/lib -L/usr/ucblib -R/usr/ucblib -L../lib -R../lib -L../lib > -R../lib > Libraries: -lwrap -lz -lsocket -lnsl -lgen -lcrypto > > You should not ever use '-L/usr/ucblib -R/usr/ucblib', since Solaris BSD > compat libraries are evil broken and AFIAK you don't need anything from > /usr/ucblib. > As far as I am aware, this is true. Under Solaris 8 (10/00) it seems to work okay without them. 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 sxw at dcs.ed.ac.uk Wed Feb 21 05:13:02 2001 From: sxw at dcs.ed.ac.uk (Simon Wilkinson) Date: Tue, 20 Feb 2001 18:13:02 GMT Subject: Updated patches for Kerberos v5 support Message-ID: <200102201813.SAA20339@canna.dcs.ed.ac.uk> I've updated the Kerberos v5 support patches I'm maintaining to work with OpenSSH 2.5.1p1. They're available for download from http://www.sxw.org.uk/computing/patches/ In addition to the upgrade from 2.3.0p1 to 2.5.1p1, there's a minor bug fix - KRB5CCNAME was being set to "" if ticket forwarding failed, which confused some utilities. Please note that these patches only provide support for the version 1 protocol. I am working on adding GSSAPI support to the version 2 protocol. If you're interested in testing this, please let me know. Cheers, Simon. From nemo at circinus.com Wed Feb 21 05:23:03 2001 From: nemo at circinus.com (Nemo) Date: Tue, 20 Feb 2001 10:23:03 -0800 (PST) Subject: man pages screwed Message-ID: Hi all. I just got openssh 2.5.1p1 and when I installed it, it's man pages doesn't seem to be formatted right. I'm on Solaris 8. Here is how it looks: man ssh Reformatting page. Please Wait... done (Secure Shell) is a program for logging into a remote machine and for executing commands on a remote machine. It is intended to replace rlogin and rsh, and provide secure encrypted communica- tions between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over the secure channel. connects and logs into the specified The user must prove his/her identity to the remote machine using one of several methods depending on the protocol version used: ... hard to read... plese reply to me directly since I'm not on the list, if you have an idea on how to fix or reformat this manpage. Thanks. -- nemo at circinus.com From mouring at etoh.eviladmin.org Wed Feb 21 05:29:08 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 20 Feb 2001 12:29:08 -0600 (CST) Subject: (Solaris) Linker flags in 2.5.1p1... (fwd) In-Reply-To: Message-ID: - (bal) Removed -L/usr/ucblib -R/usr/ucblib for Solaris platform. Applied. Thanks, Volker. - Ben On Tue, 20 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > Comments from the rest of the Solaris group? > > - Ben > > ---------- Forwarded message ---------- > Date: Tue, 20 Feb 2001 11:20:33 +0100 > From: Volker Paulsen > To: mouring at etoh.eviladmin.org > Subject: Linker flags in 2.5.1p1... > > While I'm compiling 2.5.1p1, I've got the following remarks: > > Host: sparc-sun-solaris2.7 > Compiler: cc > Compiler flags: -fast -xarch=v7 > Preprocessor flags: -I/usr/local/include -I../include -I../include > Linker flags: -L../lib/sol7/sparcv7 -L/usr/local/lib -R/usr/local/lib -L/usr/ucblib -R/usr/ucblib -L../lib -R../lib -L../lib -R../lib > Libraries: -lwrap -lz -lsocket -lnsl -lgen -lcrypto > > You should not ever use '-L/usr/ucblib -R/usr/ucblib', since Solaris BSD > compat libraries are evil broken and AFIAK you don't need anything from > /usr/ucblib. > > Ignore '-L../lib/sol7/sparcv7'; this is for my multi sparc platform > build. Also ignore '-L../lib -R../lib', which is > generated by the --with-ssl-dir=.. switch. > > Regards, > --Volker > > From mdb at juniper.net Wed Feb 21 05:39:44 2001 From: mdb at juniper.net (Mark D. Baushke) Date: Tue, 20 Feb 2001 10:39:44 -0800 Subject: man pages screwed In-Reply-To: Mail from Nemo dated Tue, 20 Feb 2001 10:23:03 PST Message-ID: <200102201839.KAA95228@garnet.juniper.net> Hi Nemo, >Hi all. I just got openssh 2.5.1p1 and when I installed it, it's man >pages doesn't seem to be formatted right. I'm on Solaris 8. Yeah, the man pages are in mdoc format. I used a perl script that was written by "Mark D. Roth" to convert them to standard man format for Solaris. I was under the impression that the script would make it into the contrib/solaris directory, but this seems not to have happened yet. Given you have already installed the man pages, doing something like the following should work: cd /usr/local/man for file in man1/scp.1 man1/sftp.1 man1/ssh-add.1 man1/ssh-agent.1 \ man1/ssh-keygen.1 man1/ssh-keyscan.1 man1/ssh.1 \ man8/sftp-server.8 man8/sshd.8 ; do mv $file $file.old mdoc2man.pl < $file.old > $file done # verify everything looks okay rm man1/*.old man8/*.old to clean them up using a bourne shell. Enjoy! -- Mark --------------- mdoc2man.pl --------------- #!/usr/local/bin/perl ### ### Copyright (c) 2001 University of Illinois Board of Trustees ### Copyright (c) 2001 Mark D. Roth ### 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. All advertising materials mentioning features or use of this software ### must display the following acknowledgement: ### This product includes software developed by the University of ### Illinois at Urbana, and their contributors. ### 4. The University nor the names of their ### contributors may be used to endorse or promote products derived from ### this software without specific prior written permission. ### ### THIS SOFTWARE IS PROVIDED BY THE TRUSTEES AND CONTRIBUTORS ``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 TRUSTEES OR CONTRIBUTORS 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. ### use strict; my ($name, $date, $id); my ($line); my ($optlist, $nospace, $enum, $synopsis); $optlist = 0; ### 1 = bullet, 2 = enum, 3 = tag $nospace = 0; $synopsis = 0; while ($line = ) { if ($line !~ /^\./) { print $line; next; } $line =~ s/^\.//; next if ($line =~ m/\\"/); $line = ParseMacro($line); print($line) if (defined $line); } sub ParseMacro # ($line) { my ($line) = @_; my (@words, $retval, $option, $parens, $arg); @words = split(/\s+/, $line); $retval = ''; $option = 0; $parens = 0; $arg = 0; # print('@words = ', scalar(@words), ': ', join(' ', @words), "\n"); while ($_ = shift @words) { # print "WORD: $_\n"; next if (/^(Li|Pf|X[oc])$/); if (/^Ns/) { $nospace = 1 if (! $nospace); $retval =~ s/ $//; next; } if (/^No/) { $retval =~ s/ $//; $retval .= shift @words; next; } if (/^Dq$/) { $retval .= '``' . (shift @words) . '\'\''; $nospace = 1 if (! $nospace && $words[0] =~ m/^[\.,]/); next; } if (/^(Sq|Ql)$/) { $retval .= '`' . (shift @words) . '\''; $nospace = 1 if (! $nospace && $words[0] =~ m/^[\.,]/); next; } $retval .= ' ' if (! $nospace && $retval ne '' && $retval !~ m/[\n ]$/); $nospace = 0 if ($nospace == 1); if (/^Dd$/) { $date = join(' ', @words); return undef; } if (/^Dt$/) { $id = join(' ', @words); return undef; } if (/^Os$/) { $retval .= '.TH ' . $id . " \"$date\" \"" . join(' ', @words) . "\""; last; } if (/^Sh$/) { $retval .= '.SH'; if ($words[0] eq 'SYNOPSIS') { $synopsis = 1; } else { $synopsis = 0; } next; } if (/^Xr$/) { $retval .= '\\fB' . (shift @words) . '\\fR(' . (shift @words) . ')' . (shift @words); last; } if (/^Nm$/) { $name = shift @words if (@words > 0); $retval .= ".br\n" if ($synopsis); $retval .= "\\fB$name\\fR"; $nospace = 1 if (! $nospace && $words[0] =~ m/^[\.,]/); next; } if (/^Nd$/) { $retval .= '\\-'; next; } if (/^Fl$/) { $retval .= '\\fB\\-' . (shift @words) . '\\fR'; $nospace = 1 if (! $nospace && $words[0] =~ m/^[\.,]/); next; } if (/^Ar$/) { $retval .= '\\fI'; if (! defined $words[0]) { $retval .= 'file ...\\fR'; } $arg = 1; $nospace = 1 if (! $nospace); next; } if (/^Cm$/) { $retval .= '\\fB' . (shift @words) . '\\fR'; next; } if (/^Op$/) { $option = 1; $nospace = 1 if (! $nospace); $retval .= '['; next; } if (/^Oo$/) { $retval .= "[\\c\n"; next; } if (/^Oc$/) { $retval .= ']'; next; } if (/^Pp$/) { if ($optlist) { $retval .= "\n"; } else { $retval .= '.LP'; } next; } if (/^Ss$/) { $retval .= '.SS'; next; } if (/^Pa$/ && ! $option) { $retval .= '\\fI'; $retval .= '\\&' if ($words[0] =~ m/^\./); $retval .= (shift @words) . '\\fR'; $nospace = 1 if (! $nospace && $words[0] =~ m/^[\.,]/); next; } if (/^Dv$/) { $retval .= '.BR'; next; } if (/^(Em|Ev)$/) { $retval .= '.IR'; next; } if (/^Pq$/) { $retval .= '('; $nospace = 1; $parens = 1; next; } if (/^(S[xy])$/) { $retval .= '.B ' . join(' ', @words); last; } if (/^Ic$/) { $retval .= '\\fB'; while (defined $words[0] && $words[0] !~ m/^[\.,]/) { $retval .= shift @words; $retval .= ' ' if (! $nospace); } $retval =~ s/ $//; $retval .= '\\fR'; $retval .= shift @words if (defined $words[0]); last; } if (/^Bl$/) { if ($words[0] eq '-bullet') { $optlist = 1; } elsif ($words[0] eq '-enum') { $optlist = 2; $enum = 0; } elsif ($words[0] eq '-tag') { $optlist = 3; } last; } if (/^El$/) { $optlist = 0; next; } if ($optlist && /^It$/) { if ($optlist == 1) { # bullets $retval .= '.IP \\(bu'; next; } if ($optlist == 2) { # enum $retval .= '.IP ' . (++$enum) . '.'; next; } if ($optlist == 3) { # tags $retval .= ".TP\n"; if ($words[0] =~ m/^(Pa|Ev)$/) { shift @words; $retval .= '.B'; } next; } next; } if (/^Sm$/) { if ($words[0] eq 'off') { $nospace = 2; } elsif ($words[0] eq 'on') { $retval .= "\n"; $nospace = 0; } shift @words; next; } $retval .= "$_"; } return undef if ($retval eq '.'); $retval =~ s/^\.([^a-zA-Z])/$1/; $retval =~ s/ $//; $retval .= ')' if ($parens == 1); $retval .= ']' if ($option == 1); $retval .= '\\fR' if ($arg); $retval .= '\\c' if ($nospace && $retval ne '' && $retval !~ m/\n$/); $retval .= "\n" if ($retval ne '' && $retval !~ m/\n$/); return $retval; } From roth+openssh at feep.net Wed Feb 21 07:38:29 2001 From: roth+openssh at feep.net (Mark D. Roth) Date: Tue, 20 Feb 2001 14:38:29 -0600 Subject: man pages screwed In-Reply-To: <200102201839.KAA95228@garnet.juniper.net>; from mdb@juniper.net on Tue, Feb 20, 2001 at 10:39:44AM -0800 References: <200102201839.KAA95228@garnet.juniper.net> Message-ID: <20010220143829.A3547@yorktown.isdn.uiuc.edu> On Tue Feb 20 10:39 2001 -0800, Mark D. Baushke wrote: > Yeah, the man pages are in mdoc format. I used a perl script that was > written by "Mark D. Roth" to convert them to > standard man format for Solaris. I was under the impression that the > script would make it into the contrib/solaris directory, but this > seems not to have happened yet. Funny, I was under the same impression... ;) Actually, Damien said something about integrating it into the configure script's --with-catman option, which would make more sense, since it's needed on all non-BSD systems. Unfortunately, I don't know what the current status of this is. -- Mark D. Roth http://www.feep.net/~roth/ From josb at cncdsl.com Wed Feb 21 07:48:25 2001 From: josb at cncdsl.com (Jos Backus) Date: Tue, 20 Feb 2001 12:48:25 -0800 Subject: Portable OpenSSH 2.5.1p1: daemontools-aware? In-Reply-To: <20010220102954.A23932@faui02.informatik.uni-erlangen.de>; from Markus.Friedl@informatik.uni-erlangen.de on Tue, Feb 20, 2001 at 10:29:32AM +0100 References: <20010219161640.A26669@lizzy.bugworks.com> <20010220102954.A23932@faui02.informatik.uni-erlangen.de> Message-ID: <20010220124825.C91708@lizzy.bugworks.com> This tiny patch adds a ``-e'' flag to force logging to stderr instead of syslog. --- openssh-2.5.1p1.dist/sshd.c Sun Feb 18 11:13:12 2001 +++ openssh-2.5.1p1/sshd.c Tue Feb 20 11:22:15 2001 @@ -576,7 +576,7 @@ initialize_server_options(&options); /* Parse command-line arguments. */ - while ((opt = getopt(ac, av, "f:p:b:k:h:g:V:u:dDiqQ46")) != -1) { + while ((opt = getopt(ac, av, "ef:p:b:k:h:g:V:u:dDiqQ46")) != -1) { switch (opt) { case '4': IPv4or6 = AF_INET; @@ -600,6 +600,9 @@ break; case 'D': no_daemon_flag = 1; + break; + case 'e': + log_stderr = 1; break; case 'i': inetd_flag = 1; If deemed useful I'll send a man diff as well. -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From mouring at etoh.eviladmin.org Wed Feb 21 07:53:25 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 20 Feb 2001 14:53:25 -0600 (CST) Subject: man pages screwed In-Reply-To: <20010220143829.A3547@yorktown.isdn.uiuc.edu> Message-ID: I think it was tabled until post-2.5.x release. Too many things occured at once and it all came much quicker then any of us expected. I really wish we would have had another few days for testing. But alas it was not to be. =) I'll make sure it stays on my list. If you have a first run at configure.in patch feel free to post it. - Ben On Tue, 20 Feb 2001, Mark D. Roth wrote: > On Tue Feb 20 10:39 2001 -0800, Mark D. Baushke wrote: > > Yeah, the man pages are in mdoc format. I used a perl script that was > > written by "Mark D. Roth" to convert them to > > standard man format for Solaris. I was under the impression that the > > script would make it into the contrib/solaris directory, but this > > seems not to have happened yet. > > Funny, I was under the same impression... ;) > > Actually, Damien said something about integrating it into the > configure script's --with-catman option, which would make more sense, > since it's needed on all non-BSD systems. Unfortunately, I don't know > what the current status of this is. > > From tim at multitalents.net Wed Feb 21 08:49:28 2001 From: tim at multitalents.net (Tim Rice) Date: Tue, 20 Feb 2001 13:49:28 -0800 (PST) Subject: _PATH_STDPATH and @bindir@ In-Reply-To: <20010219181049.P63677@giles.mikehan.com> Message-ID: On Mon, 19 Feb 2001, Michael Han wrote: > I'm curious to know why Portable OpenSSH doesn't include @bindir@ in > the _PATH_STDPATH. This would save most installers of portable OpenSSH > from having to --with-default-path=$PREFIX/bin in order to ensure that > scp will work properly. This would also, I imagine, save quite a lot > of hassle for developers/helpful-folks on the mailing list regarding > FAQ 3.7. I could suggest a patch to do this, but figure you all know a > better way than I'd suggest. Here is a patch that will do waht you want. > > Actually, might it not be better to have the server path be a run-time > configurable option, rather than a build-time option? Anyway, at the > very least, it'd be nice if the default installation weren't broken. > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- openssh_cvs/configure.in.old Fri Feb 16 18:15:18 2001 +++ openssh_cvs/configure.in Sat Feb 17 18:42:19 2001 @@ -46,6 +46,9 @@ CFLAGS="$CFLAGS -Wall" fi +# taken from defines.h +user_path="/usr/bin:/bin:/usr/sbin:/sbin" + # Check for some target-specific stuff case "$host" in *-*-aix*) @@ -170,6 +173,7 @@ else AC_MSG_RESULT(no) fi + user_path="/usr/sbin:/usr/bin" ;; *-*-sunos4*) CPPFLAGS="$CPPFLAGS -DSUNOS4" @@ -206,6 +210,7 @@ mansubdir=cat enable_suid_ssh=no AC_DEFINE(USE_PIPES) + user_path=":/bin:/usr/bin:/usr/X/bin" ;; *-*-sysv5*) CPPFLAGS="$CPPFLAGS -I/usr/local/include" @@ -214,6 +219,7 @@ mansubdir=cat enable_suid_ssh=no AC_DEFINE(USE_PIPES) + user_path=":/bin:/usr/bin:/usr/X/bin" ;; *-*-sysv*) CPPFLAGS="$CPPFLAGS -I/usr/local/include" @@ -237,6 +243,7 @@ AC_DEFINE(DISABLE_SHADOW) AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) AC_CHECK_FUNCS(getluid setluid) + user_path="/bin:/usr/bin:/usr/local/bin:" ;; *-*-sco3.2v5*) CPPFLAGS="$CPPFLAGS -I/usr/local/include" @@ -251,6 +258,7 @@ AC_DEFINE(DISABLE_SHADOW) AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) AC_CHECK_FUNCS(getluid setluid) + user_path="/bin:/usr/bin:/etc" ;; *-dec-osf*) if test ! -z "USE_SIA" ; then @@ -1366,12 +1377,31 @@ [ --with-default-path=PATH Specify default \$PATH environment for server], [ if test "x$withval" != "xno" ; then - AC_DEFINE_UNQUOTED(USER_PATH, "$withval") + user_path="$withval" SERVER_PATH_MSG="$withval" fi ] ) +# make sure $bindir is in USER_PATH so scp will work +t_bindir=`eval echo ${bindir}` +case $t_bindir in + NONE/*) t_bindir=`echo $t_bindir | sed "s~NONE~$prefix~"` ;; +esac +case $t_bindir in + NONE/*) t_bindir=`echo $t_bindir | sed "s~NONE~$ac_default_prefix~"` ;; +esac +echo $user_path | grep ":$t_bindir" > /dev/null 2>&1 +if test $? -ne 0 ; then + echo $user_path | grep "^$t_bindir" > /dev/null 2>&1 + if test $? -ne 0 ; then + user_path=$user_path:$t_bindir + AC_MSG_RESULT(Adding $t_bindir to USER_PATH so scp will work) + fi +fi +AC_DEFINE_UNQUOTED(USER_PATH, "$user_path") +AC_SUBST(user_path) + # Whether to force IPv4 by default (needed on broken glibc Linux) IPV4_HACK_MSG="no" AC_ARG_WITH(ipv4-default, @@ -1714,6 +1744,7 @@ E=`eval echo ${libexecdir}/ssh-askpass` ; E=`eval echo ${E}` F=`eval echo ${mandir}/${mansubdir}X` ; F=`eval echo ${F}` G=`eval echo ${piddir}` ; G=`eval echo ${G}` +H=`eval echo ${user_path}` ; H=`eval echo ${H}` echo "" echo "OpenSSH configured has been configured with the following options." @@ -1723,6 +1754,7 @@ echo " Askpass program: $E" echo " Manual pages: $F" echo " PID file: $G" +echo " sshd default user PATH: $H" echo " Random number collection: $RAND_MSG" echo " Manpage format: $MAN_MSG" echo " PAM support: ${PAM_MSG}" --- openssh_cvs/Makefile.in.old Fri Feb 16 18:15:07 2001 +++ openssh_cvs/Makefile.in Sat Feb 17 18:42:37 2001 @@ -68,7 +68,8 @@ -D/var/run/sshd.pid=$(piddir)/sshd.pid \ -D/etc/primes=$(sysconfdir)/primes \ -D/etc/sshrc=$(sysconfdir)/sshrc \ - -D/usr/X11R6/bin/xauth=$(XAUTH_PATH) + -D/usr/X11R6/bin/xauth=$(XAUTH_PATH) \ + -D/usr/bin:/bin:/usr/sbin:/sbin=@user_path@ FIXPATHSCMD = $(PERL) $(srcdir)/fixpaths $(PATHSUBS) --- openssh_cvs/sshd_config.old Sat Feb 10 19:40:00 2001 +++ openssh_cvs/sshd_config Sat Feb 17 18:29:35 2001 @@ -1,5 +1,7 @@ # $OpenBSD: sshd_config,v 1.32 2001/02/06 22:07:50 deraadt Exp $ +# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin + # This is the sshd server system-wide configuration file. See sshd(8) # for more information. From Markus.Friedl at informatik.uni-erlangen.de Wed Feb 21 08:58:37 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Tue, 20 Feb 2001 22:58:37 +0100 Subject: ssh-agent and id_dsa In-Reply-To: <20010220113536.B19903@ws01.aet.tu-cottbus.de>; from Lutz.Jaenicke@aet.TU-Cottbus.DE on Tue, Feb 20, 2001 at 11:35:36AM +0100 References: <20010220104029.A19671@ws01.aet.tu-cottbus.de> <20010220111219.A25897@faui02.informatik.uni-erlangen.de> <20010220113536.B19903@ws01.aet.tu-cottbus.de> Message-ID: <20010220225837.B16424@faui02l.informatik.uni-erlangen.de> On Tue, Feb 20, 2001 at 11:35:36AM +0100, Lutz Jaenicke wrote: > On Tue, Feb 20, 2001 at 11:12:19AM +0100, Markus Friedl wrote: > > why don't you rename the key? :) > > Because I use ssh-agent when I sit in front of my workstation (automatic > startup via CDE, really practical thing). When I log in from remote via > slogin, I don't always startup ssh-agent and then it is ok to be asked :-) > > > does the protocol-1 implementation remember keys? > > Hmm, you tend to ask difficult questions... well, it does not remember the key. however, the problems you see are due to the fact that protocol 1 and 2 are different :) perhaps i add handling of SSH2_MSG_USERAUTH_PK_OK to the ssh client, but i'm not sure. the ssh client uses just the public key to check whether the server will accept the 'indentity' file. currently in ssh2 you need access to the private key, this is why you will be asked about the passphrase. with SSH2_MSG_USERAUTH_PK_OK you need the passphrase only if the server accepts the public key. > ws01 23: slogin -v -p 24 -l root ws01 > OpenSSH_2.5.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090600f > debug: Reading configuration data /home/aet/serv01/jaenicke/.ssh/config > debug: Reading configuration data /etc/ssh/ssh_config > debug: Applying options for * > debug: ssh_connect: getuid 11019 geteuid 0 anon 0 > debug: Connecting to ws01 [141.43.132.151] port 24. > debug: Seeding random number generator > debug: Allocated local port 601. > debug: Connection established. > debug: identity file /home/aet/serv01/jaenicke/.ssh/identity type 0 > debug: identity file /home/aet/serv01/jaenicke/.ssh/id_dsa type 3 > debug: Remote protocol version 1.99, remote software version OpenSSH_2.5.1p1 > debug: match: OpenSSH_2.5.1p1 pat ^OpenSSH > debug: Local version string SSH-1.5-OpenSSH_2.5.1p1 > debug: Waiting for server public key. > debug: Received server public key (768 bits) and host key (1024 bits). > debug: Host 'ws01' is known and matches the RSA1 host key. > debug: Found key in /etc/ssh/ssh_known_hosts:23 > debug: Seeding random number generator > debug: Encryption type: 3des > debug: Sent encrypted session key. > debug: Installing crc compensation attack detector. > debug: Received encrypted confirmation. > debug: Trying RSA authentication via agent with 'jaenicke at emserv1' > debug: Server refused our key. > debug: RSA authentication using agent refused. > debug: Trying RSA authentication with key 'jaenicke at emserv1' > debug: Server refused our key. > debug: Doing password authentication. > root at ws01's password: > ... > On the server this looks like: > debug1: Bind to port 24 on 0.0.0.0. > Server listening on 0.0.0.0 port 24. > Generating 768 bit RSA key. > debug1: Seeding random number generator > RSA key generation complete. > debug1: Server will not fork when running in debugging mode. > Connection from 141.43.132.151 port 601 > debug1: Client protocol version 1.5; client software version OpenSSH_2.5.1p1 > debug1: match: OpenSSH_2.5.1p1 pat ^OpenSSH > debug1: Local version string SSH-1.99-OpenSSH_2.5.1p1 > debug1: Sent 768 bit server key and 1024 bit host key. > debug1: Encryption type: 3des > debug1: Received session key; encryption turned on. > debug1: Installing crc compensation attack detector. > debug1: Attempting authentication for root. > Failed rsa for ROOT from 141.43.132.151 port 601 > Failed rsa for ROOT from 141.43.132.151 port 601 > ... > > So obviously, it remembers the key... > identity file /home/aet/serv01/jaenicke/.ssh/identity type 0 > is the RSA1 key I am using. It is passphrase protected and loaded into > ssh-agent. > ws01 23: ssh-add -l > 1024 30:a7:58:3e:f5:bc:a2:0e:f5:16:09:71:b6:56:1e:ec jaenicke at emserv1 (RSA1) > 1024 de:f8:a8:98:4b:18:9f:5f:d0:6f:67:91:1d:f7:c4:6a /home/aet/serv01/jaenicke/.ssh/id_dsa (DSA) > > If I try the same with protocol 2: > ... > debug: authentications that can continue: publickey,password,keyboard-interactive > debug: next auth method to try is publickey > debug: userauth_pubkey_agent: trying agent key /home/aet/serv01/jaenicke/.ssh/id_dsa > debug: authentications that can continue: publickey,password,keyboard-interactive > debug: next auth method to try is publickey > debug: try pubkey: /home/aet/serv01/jaenicke/.ssh/id_dsa > debug: PEM_read_PrivateKey failed > debug: read SSH2 private key done: name success 0 > Enter passphrase for key '/home/aet/serv01/jaenicke/.ssh/id_dsa': > debug: read SSH2 private key done: name dsa w/o comment success 1 > debug: sig size 20 20 > debug: authentications that can continue: publickey,password,keyboard-interactive > debug: next auth method to try is publickey > debug: next auth method to try is password > root at ws01's password: > ... > > and on the server: > ... > debug1: userauth-request for user root service ssh-connection method none > debug1: attempt 0 failures 0 > Failed none for ROOT from 141.43.132.151 port 813 ssh2 > debug1: userauth-request for user root service ssh-connection method publickey > debug1: attempt 1 failures 1 > Failed publickey for ROOT from 141.43.132.151 port 813 ssh2 > debug1: userauth-request for user root service ssh-connection method publickey > debug1: attempt 2 failures 2 > Failed publickey for ROOT from 141.43.132.151 port 813 ssh2 > ... > > 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 Wed Feb 21 09:35:23 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 20 Feb 2001 23:35:23 +0100 Subject: ssh-agent and id_dsa In-Reply-To: <20010220225837.B16424@faui02l.informatik.uni-erlangen.de>; from Markus.Friedl@informatik.uni-erlangen.de on Tue, Feb 20, 2001 at 10:58:37PM +0100 References: <20010220104029.A19671@ws01.aet.tu-cottbus.de> <20010220111219.A25897@faui02.informatik.uni-erlangen.de> <20010220113536.B19903@ws01.aet.tu-cottbus.de> <20010220225837.B16424@faui02l.informatik.uni-erlangen.de> Message-ID: <20010220233523.A8120@serv01.aet.tu-cottbus.de> On Tue, Feb 20, 2001 at 10:58:37PM +0100, Markus Friedl wrote: > On Tue, Feb 20, 2001 at 11:35:36AM +0100, Lutz Jaenicke wrote: > > Hmm, you tend to ask difficult questions... > > well, it does not remember the key. > > however, the problems you see are due to the fact that > protocol 1 and 2 are different :) > > perhaps i add handling of SSH2_MSG_USERAUTH_PK_OK to the > ssh client, but i'm not sure. We'll see :-) > the ssh client uses just the public key to check whether the > server will accept the 'indentity' file. currently in ssh2 you need > access to the private key, this is why you will be asked about > the passphrase. with SSH2_MSG_USERAUTH_PK_OK you need the passphrase > only if the server accepts the public key. Ah, thanks for clearing this up. sshconnect1.c:99 says: key_free(key); so it would have been ... "surprising" to find it actually reused... 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 alster-openssh at blinkylights.net Wed Feb 21 09:40:42 2001 From: alster-openssh at blinkylights.net (Allen Louie) Date: Tue, 20 Feb 2001 14:40:42 -0800 Subject: 2.5.1p1 ssh-agent path problem in Solaris Message-ID: <20010220144042.B46469@blinkylights.net> I'm having a path problem with OpenSSH 2.5.1p1 in Solaris (7). When ssh-agent is run, environment variables aren't being passed to the spawned shell. sol# env | wc -l 23 sol# env | grep -i ssh SSH_CLIENT=10.0.1.146 1047 22 SSH_TTY=/dev/pts/0 sol# sol# ssh-agent sh sol# env | wc -l 1 sol# env SSH_AGENT_PID=12032 sol# If I set SSH_AUTH_SOCK manually, ssh-agent (and ssh-add) does function properly... sol# find /tmp -name 'agent*' -exec ls -l {} \; srwxr-xr-x 1 root other 0 Feb 20 14:07 /tmp/ssh-Lfa12009/agent.12009 sol# sol# SSH_AUTH_SOCK=/tmp/ssh-Lfa12009/agent.12009 sol# export SSH_AUTH_SOCK sol# /usr/local/bin/ssh-add Need passphrase for //.ssh/identity Enter passphrase for root at js: Identity added: //.ssh/identity (root at js) sol# /usr/local/bin/ssh root at foo Last login: Mon Feb 19 18:12:04 2001 from 10.0.1.210 Sun Microsystems Inc. SunOS 5.7 Generic October 1998 Sun Microsystems Inc. SunOS 5.7 Generic October 1998 foo# It doesn't look like this environment problem affects FreeBSD 4.2-stable... fbsd# env | wc -l 60 fbsd# env | grep -i ssh SSH_CLIENT=10.0.1.19 1692 22 SSH_TTY=/dev/ttyp9 fbsd# fbsd# ssh-agent sh fbsd# env | grep -i ssh SSH_CLIENT=10.0.1.19 1692 22 SSH_AGENT_PID=45672 SSH_TTY=/dev/ttyp9 SSH_AUTH_SOCK=/tmp/ssh-P0FQ5J0F/agent.45671 fbsd# env | wc -l 62 fbsd# Please advise... thanks in advance! From mouring at etoh.eviladmin.org Wed Feb 21 09:48:00 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 20 Feb 2001 16:48:00 -0600 (CST) Subject: 2.5.1p1 ssh-agent path problem in Solaris In-Reply-To: <20010220144042.B46469@blinkylights.net> Message-ID: This is a known problem. And has been fixed in the CVS tree. And I believe the latest snapshot reflect the change. - Ben On Tue, 20 Feb 2001, Allen Louie wrote: > > I'm having a path problem with OpenSSH 2.5.1p1 in Solaris (7). When > ssh-agent is run, environment variables aren't being passed to the > spawned shell. > > sol# env | wc -l > 23 > sol# env | grep -i ssh > SSH_CLIENT=10.0.1.146 1047 22 > SSH_TTY=/dev/pts/0 > sol# > sol# ssh-agent sh > sol# env | wc -l > 1 > sol# env > SSH_AGENT_PID=12032 > sol# > > If I set SSH_AUTH_SOCK manually, ssh-agent (and ssh-add) does function > properly... > > sol# find /tmp -name 'agent*' -exec ls -l {} \; > srwxr-xr-x 1 root other 0 Feb 20 14:07 /tmp/ssh-Lfa12009/agent.12009 > sol# > sol# SSH_AUTH_SOCK=/tmp/ssh-Lfa12009/agent.12009 > sol# export SSH_AUTH_SOCK > sol# /usr/local/bin/ssh-add > Need passphrase for //.ssh/identity > Enter passphrase for root at js: > Identity added: //.ssh/identity (root at js) > sol# /usr/local/bin/ssh root at foo > Last login: Mon Feb 19 18:12:04 2001 from 10.0.1.210 > Sun Microsystems Inc. SunOS 5.7 Generic October 1998 > Sun Microsystems Inc. SunOS 5.7 Generic October 1998 > foo# > > It doesn't look like this environment problem affects FreeBSD > 4.2-stable... > > fbsd# env | wc -l > 60 > fbsd# env | grep -i ssh > SSH_CLIENT=10.0.1.19 1692 22 > SSH_TTY=/dev/ttyp9 > fbsd# > fbsd# ssh-agent sh > fbsd# env | grep -i ssh > SSH_CLIENT=10.0.1.19 1692 22 > SSH_AGENT_PID=45672 > SSH_TTY=/dev/ttyp9 > SSH_AUTH_SOCK=/tmp/ssh-P0FQ5J0F/agent.45671 > fbsd# env | wc -l > 62 > fbsd# > > > Please advise... thanks in advance! > > > > From carl at bl.echidna.id.au Wed Feb 21 10:56:03 2001 From: carl at bl.echidna.id.au (carl at bl.echidna.id.au) Date: Wed, 21 Feb 2001 10:56:03 +1100 (EST) Subject: segfault on RH 6.2 with 2.5.1p1 going to a host not in ~/.ssh/known_hosts Message-ID: <200102202356.f1KNu3i12354@rollcage.bl.echidna.id.au> I recently upgraded all my boxes to 2.5.1p1 (it was a convenient opportunity to get rid of a lot of versions all floating around ...) I used the RPM for RH 6.2 from openssh.com. We have an openssl RPM, that I think I got from openssh.com too (but that was a while ago :) ) - openssl-0.9.5a-2 I am seeing a problem, when ssh'ing from a redhat 6.2 box to a host that is not in a user's .ssh/known_hosts file, and /etc/ssh/known_hosts does not exist : strace shows this : [root at ironhand ssh]# strace -u mhurst /usr/bin/ssh -v kaos . . . open("/etc/ssh/ssh_known_hosts", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/mhurst/.ssh/known_hosts", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=338, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 read(4, "chief,203.16.200.66 1024 35 1575"..., 4096) = 338 read(4, "", 4096) = 0 close(4) = 0 munmap(0x40015000, 4096) = 0 open("/etc/ssh/ssh_known_hosts", O_RDONLY) = -1 ENOENT (No such file or directory) --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ If I run it as another user, that does have "kaos" in its known_hosts file, there's no problem, everything works just fine. ssh is SUID root, shouldn't it create the /etc/ssh/ssh_known_hosts file? My upgrade process was simply to do an rpm -Fvh openssh, which seemed to work just fine. I'm guessing that at the least, it shouldn't segfault :) Carl From mouring at etoh.eviladmin.org Wed Feb 21 11:08:01 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 20 Feb 2001 18:08:01 -0600 (CST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Mon, 19 Feb 2001, Tim Rice wrote: > On Mon, 19 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > Damien commited a different patch. So I get this is the end of the > > story unless there are problems with it. > > It looks like a good patch. Too bad it doesn't work. > > It puts in -L/usr/local/ssl/lib twice. > ... > gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o log-client.o readconf. > o clientloop.o -L. -Lopenbsd-compat/ -L/usr/local/lib -L/usr/local/ssl/lib -L/u > sr/local/ssl/lib -lssh -lopenbsd-compat -lintl -lwrap -lz -lrpc -lyp -lrpc -lsoc > ket -lgen -lsocket -los -lprot -lx -ltinfo -lm -lcrypto > ld crtbegin.o: too many -L options, 6 allowed > gmake: *** [ssh] Error 1 > ... > Is it possible for you to locate what is doing it? Damien will be out for a few days, and I don't have access to any SCO machines for testing. And I don't see the problem under Redhat. - Ben From sunil at redback.com Wed Feb 21 11:04:30 2001 From: sunil at redback.com (Sunil K. Vallamkonda) Date: Tue, 20 Feb 2001 16:04:30 -0800 (PST) Subject: load host key error: Message-ID: Hello, I am seeing error: Could not load host key: /etc/ssh_host_dsa_key: Bad file descriptor Disabling protocol version 2. Could not load host key I am using sshd from OpenSSH from: development tree: openssh.20010109 However this file exists, I can do 'ls': -rw------- 1 root group 668 Jan 26 15:53 ssh_host_dsa_key -rw-r--r-- 1 root group 601 Jan 26 15:53 ssh_host_dsa_key.pub It was generated using command: ssh-keygen -d -f /etc/ssh_host_dsa_key -N '' Any suggestions ? thank you. Sunil. From mouring at etoh.eviladmin.org Wed Feb 21 11:18:39 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 20 Feb 2001 18:18:39 -0600 (CST) Subject: load host key error: In-Reply-To: Message-ID: You have a 'HostKey' entry for that dsa key in your sshd_config? On Tue, 20 Feb 2001, Sunil K. Vallamkonda wrote: > Hello, > > I am seeing error: > > Could not load host key: /etc/ssh_host_dsa_key: Bad file descriptor > Disabling protocol version 2. Could not load host key > > I am using sshd from OpenSSH from: > development tree: > openssh.20010109 > > However this file exists, I can do 'ls': > > -rw------- 1 root group 668 Jan 26 15:53 ssh_host_dsa_key > -rw-r--r-- 1 root group 601 Jan 26 15:53 ssh_host_dsa_key.pub > > > It was generated using command: > ssh-keygen -d -f /etc/ssh_host_dsa_key -N '' > > > Any suggestions ? > > thank you. > > Sunil. > > > > From ishikawa at yk.rim.or.jp Wed Feb 21 11:14:20 2001 From: ishikawa at yk.rim.or.jp (Ishikawa) Date: Wed, 21 Feb 2001 09:14:20 +0900 Subject: OpenSSH 2.5.0p1 References: <3A8E9C20.7330E90B@yk.rim.or.jp> Message-ID: <3A93085C.B46D71CC@yk.rim.or.jp> Ishikawa wrote: > mouring at etoh.eviladmin.org wrote: > > > Known issues: > > > > > > 7) Solaris '$PATH' issue -- ?? (Unfixable before 2.5.0?) [I'm getting > > more reports of this. I'll present them when they get their facts > > together] > > Attached is a memo that contains the debug output > when the problem is reproduced locally on our office machines. > > I think the afffected systems are at least solaris 7 and solaris 8 from > what I gather from the post. The log below > is generated when I tried the command against sshd > 2.3.0p1 on a solaris 7 for x86 host. > (without "-2", the command works.) > > "ssh -2 host 'echo $PATH' doesn't work against sshd on solaris7 for x86" The latest 2.5.1p1 seems to have solved the problem at least for me. A few comments. I noticed that I needed to modify sshd_config manually since the dsa key file needs to be specified. Also, the installeration using "make install" seems to have run smoother this time. The installation of manual input was interrupted due to errors before. Happy Hacking, Chiaki From sunil at redback.com Wed Feb 21 11:16:38 2001 From: sunil at redback.com (Sunil K. Vallamkonda) Date: Tue, 20 Feb 2001 16:16:38 -0800 (PST) Subject: load host key error: In-Reply-To: Message-ID: Yes, I do: HostKey /etc/ssh_host_key HostKey /etc/ssh_host_dsa_key On Tue, 20 Feb 2001 mouring at etoh.eviladmin.org wrote: > > You have a 'HostKey' entry for that dsa key in your sshd_config? > > On Tue, 20 Feb 2001, Sunil K. Vallamkonda wrote: > > > Hello, > > > > I am seeing error: > > > > Could not load host key: /etc/ssh_host_dsa_key: Bad file descriptor > > Disabling protocol version 2. Could not load host key > > > > I am using sshd from OpenSSH from: > > development tree: > > openssh.20010109 > > > > However this file exists, I can do 'ls': > > > > -rw------- 1 root group 668 Jan 26 15:53 ssh_host_dsa_key > > -rw-r--r-- 1 root group 601 Jan 26 15:53 ssh_host_dsa_key.pub > > > > > > It was generated using command: > > ssh-keygen -d -f /etc/ssh_host_dsa_key -N '' > > > > > > Any suggestions ? > > > > thank you. > > > > Sunil. > > > > > > > > > > From mouring at etoh.eviladmin.org Wed Feb 21 11:25:50 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 20 Feb 2001 18:25:50 -0600 (CST) Subject: Solaris and Latest snapshot (2001-02-21) In-Reply-To: <3A93085C.B46D71CC@yk.rim.or.jp> Message-ID: What is left that is broken under Solaris? I'm attempting get a defined list of what is left on Solaris because I feel there will be a 2.5.1p2 coming in the next week or so due to setenv() bug. - Ben On Wed, 21 Feb 2001, Ishikawa wrote: > Ishikawa wrote: > > > mouring at etoh.eviladmin.org wrote: > > > > > Known issues: > > > > > > > > > 7) Solaris '$PATH' issue -- ?? (Unfixable before 2.5.0?) [I'm getting > > > more reports of this. I'll present them when they get their facts > > > together] > > > > Attached is a memo that contains the debug output > > when the problem is reproduced locally on our office machines. > > > > I think the afffected systems are at least solaris 7 and solaris 8 from > > what I gather from the post. The log below > > is generated when I tried the command against sshd > > 2.3.0p1 on a solaris 7 for x86 host. > > (without "-2", the command works.) > > > > "ssh -2 host 'echo $PATH' doesn't work against sshd on solaris7 for x86" > > The latest 2.5.1p1 seems to have solved the problem at least for me. > > > A few comments. > I noticed that I needed to modify sshd_config manually since > the dsa key file needs to be specified. > > Also, the installeration using "make install" seems to have run > smoother this time. The installation of manual input was interrupted > due to errors before. > > Happy Hacking, > > Chiaki > > From devon at admin2.gisnetworks.com Wed Feb 21 11:47:17 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Tue, 20 Feb 2001 16:47:17 -0800 Subject: Solaris and Latest snapshot (2001-02-21) References: Message-ID: <3A931015.7359BD56@admin2.gisnetworks.com> afaict, pam breaks everything except interactive sessions (at least scp and rsh-like remote command execution), which seems like one bug, since without pam it works fine. devon mouring at etoh.eviladmin.org wrote: > > What is left that is broken under Solaris? I'm attempting get a defined > list of what is left on Solaris because I feel there will be a 2.5.1p2 > coming in the next week or so due to setenv() bug. > > - Ben > > On Wed, 21 Feb 2001, Ishikawa wrote: > > > Ishikawa wrote: > > > > > mouring at etoh.eviladmin.org wrote: > > > > > > > Known issues: > > > > > > > > > > > > 7) Solaris '$PATH' issue -- ?? (Unfixable before 2.5.0?) [I'm getting > > > > more reports of this. I'll present them when they get their facts > > > > together] > > > > > > Attached is a memo that contains the debug output > > > when the problem is reproduced locally on our office machines. > > > > > > I think the afffected systems are at least solaris 7 and solaris 8 from > > > what I gather from the post. The log below > > > is generated when I tried the command against sshd > > > 2.3.0p1 on a solaris 7 for x86 host. > > > (without "-2", the command works.) > > > > > > "ssh -2 host 'echo $PATH' doesn't work against sshd on solaris7 for x86" > > > > The latest 2.5.1p1 seems to have solved the problem at least for me. > > > > > > A few comments. > > I noticed that I needed to modify sshd_config manually since > > the dsa key file needs to be specified. > > > > Also, the installeration using "make install" seems to have run > > smoother this time. The installation of manual input was interrupted > > due to errors before. > > > > Happy Hacking, > > > > Chiaki > > > > From mouring at etoh.eviladmin.org Wed Feb 21 11:52:50 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 20 Feb 2001 18:52:50 -0600 (CST) Subject: key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 In-Reply-To: Message-ID: Only thing I can link to is the fact they are both Redhat 7.0 boxes. Are they fresh compiles or did you both install from RPMs? - Ben From mouring at etoh.eviladmin.org Wed Feb 21 11:55:38 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 20 Feb 2001 18:55:38 -0600 (CST) Subject: Solaris and Latest snapshot (2001-02-21) In-Reply-To: <3A931015.7359BD56@admin2.gisnetworks.com> Message-ID: On Tue, 20 Feb 2001, Devon Bleak wrote: > afaict, pam breaks everything except interactive sessions (at least scp > and rsh-like remote command execution), which seems like one bug, since > without pam it works fine. > > devon > Do you have last known good development snapshot? If I can find about where the breakage occured I can locate the offending patch. - Ben From devon at admin2.gisnetworks.com Wed Feb 21 12:02:25 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Tue, 20 Feb 2001 17:02:25 -0800 Subject: Solaris and Latest snapshot (2001-02-21) References: Message-ID: <3A9313A1.3FD88566@admin2.gisnetworks.com> i don't :/ the last thing that worked on there was 2.3.0p1. i didn't load up any cvs code on it til about a week ago. looks like the earliest snapshot on there is from the 9th of this month. the earlier ones are all 0k. anybody got some earlier snapshots? devon mouring at etoh.eviladmin.org wrote: > > On Tue, 20 Feb 2001, Devon Bleak wrote: > > > afaict, pam breaks everything except interactive sessions (at least scp > > and rsh-like remote command execution), which seems like one bug, since > > without pam it works fine. > > > > devon > > > > Do you have last known good development snapshot? If I can find about > where the breakage occured I can locate the offending patch. > > - Ben From aab at aab.cc.purdue.edu Wed Feb 21 12:16:19 2001 From: aab at aab.cc.purdue.edu (Paul Townsend) Date: Tue, 20 Feb 2001 20:16:19 -0500 (EST) Subject: Private key files closed twice -- Message-ID: <200102210116.UAA17818@aab.cc.purdue.edu> ===== I believe that each private key file read is closed twice as load_private_key(filename, ...) fd = open(filename, ...) ... load_private_key_rsa1(fd, ...) ... load_private_key_ssh2(fd, ...) ... close(fd); Unfortunately, "load_private_key_rsa1" and "load_private_key_ssh2" also close the file. It would simplest to remove the `close()'s in the rsa2 and ssh2 routines except that the ssh2 routine converts the file descriptor into a streams pointer. The following patch continues to allow the two routines to do their own closing but moves the `close(fd)' in "load_private_key" into the default position only. -- Paul Townsend (aab at purdue.edu) =-=-=-=-=-= --- authfile.c.orig Thu Feb 8 21:11:24 2001 +++ authfile.c Tue Feb 20 19:27:20 2001 @@ -446,6 +446,7 @@ fp = fdopen(fd, "r"); if (fp == NULL) { error("fdopen failed"); + close(fd); return 0; } pk = PEM_read_PrivateKey(fp, NULL, NULL, (char *)passphrase); @@ -536,10 +537,11 @@ case KEY_RSA: case KEY_UNSPEC: ret = load_private_key_ssh2(fd, passphrase, key, comment_return); + break; default: + close(fd); break; } - close(fd); return ret; } From tim at multitalents.net Wed Feb 21 12:22:49 2001 From: tim at multitalents.net (Tim Rice) Date: Tue, 20 Feb 2001 17:22:49 -0800 (PST) Subject: SCO 5.0.5 setluid patch In-Reply-To: Message-ID: On Fri, 16 Feb 2001, Damien Miller wrote: > On Thu, 15 Feb 2001, svaughan wrote: > > > Here is an updated patch. Sorry, I thought setluid was SCO specific. > > I have modified your patch a little. Can you please give the below one > a try? > Close, but needs some work. rlogin tim(trr)@sco504 1% id -l uid=31(tim) gid=85(trr) luid=31(tim) groups=85(trr),18(lp),50(group) ssh tim(trr)@sco504 1% id -l uid=31(tim) gid=85(trr) luid=0(root) groups=85(trr),18(lp),50(group) ^^^^^^ Not quite what we want. > It does not try to do setluid for non-OpenServer systems. From docs.sco.com > it says that Unixware also offers the get/setluid syscalls, but they will > always fail. > [patch sniped] > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Wed Feb 21 12:30:17 2001 From: tim at multitalents.net (Tim Rice) Date: Tue, 20 Feb 2001 17:30:17 -0800 (PST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Tue, 20 Feb 2001 mouring at etoh.eviladmin.org wrote: > > On Mon, 19 Feb 2001, Tim Rice wrote: > > > On Mon, 19 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > > > > Damien commited a different patch. So I get this is the end of the > > > story unless there are problems with it. > > > > It looks like a good patch. Too bad it doesn't work. > > > > It puts in -L/usr/local/ssl/lib twice. > > ... > > gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o log-client.o readconf. > > o clientloop.o -L. -Lopenbsd-compat/ -L/usr/local/lib -L/usr/local/ssl/lib -L/u > > sr/local/ssl/lib -lssh -lopenbsd-compat -lintl -lwrap -lz -lrpc -lyp -lrpc -lsoc > > ket -lgen -lsocket -los -lprot -lx -ltinfo -lm -lcrypto > > ld crtbegin.o: too many -L options, 6 allowed > > gmake: *** [ssh] Error 1 > > ... > > > > Is it possible for you to locate what is doing it? Damien will be out for > a few days, and I don't have access to any SCO machines for testing. And I > don't see the problem under Redhat. > Why not just back out that patch and install the one I sent that works. BTW. the duplicate -L's show up on Solaris and UnixWare also. It's just not a problem there. > - Ben > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mouring at etoh.eviladmin.org Wed Feb 21 12:34:27 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 20 Feb 2001 19:34:27 -0600 (CST) Subject: Solaris and Latest snapshot (2001-02-21) In-Reply-To: <3A9313A1.3FD88566@admin2.gisnetworks.com> Message-ID: On Tue, 20 Feb 2001, Devon Bleak wrote: > i don't :/ the last thing that worked on there was 2.3.0p1. i didn't > load up any cvs code on it til about a week ago. looks like the > earliest snapshot on there is from the 9th of this month. the earlier > ones are all 0k. anybody got some earlier snapshots? > I can make you snapshots if you want them. Note there are a few that are 'bad' versions due to security issues. Let me verify.. Solaris is broken for v1 and v2? Or just v2 protocol? - Ben From carl at bl.echidna.id.au Wed Feb 21 13:03:25 2001 From: carl at bl.echidna.id.au (carl at bl.echidna.id.au) Date: Wed, 21 Feb 2001 13:03:25 +1100 (EST) Subject: further problems with OpenSSH 2.5.1p1 on RH 6.2 Message-ID: <200102210203.f1L23Ps13067@rollcage.bl.echidna.id.au> I'm finding another problem with OpenSSH 2.5.1p1 on RH 6.2 (at least, I think it's the linux box that is the problem). I'm ssh'ing to a RH 6.2 box from a Solaris 7 server (scp also... seems like the same problem). I'm using authorized_keys and identity.pub files to do it automagically, and all works well when it's from user to user, where the username is the same, but if I do something like this : root at solarisbox: ssh -l blah linuxbox I'm seeing this : ssh -1 -v -l blah linuxbox OpenSSH_2.5.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f debug: Reading configuration data /opt/local/etc/ssh_config debug: Applying options for * debug: ssh_connect: getuid 0 geteuid 0 anon 0 debug: Connecting to linuxbox [1.2.3.4] port 22. debug: Seeding random number generator debug: Allocated local port 635. debug: Connection established. debug: identity file //.ssh/identity type 0 debug: Remote protocol version 1.99, remote software version OpenSSH_2.5.1p1 debug: match: OpenSSH_2.5.1p1 pat ^OpenSSH debug: Local version string SSH-1.5-OpenSSH_2.5.1p1 debug: Waiting for server public key. debug: Received server public key (768 bits) and host key (1024 bits). debug: Host 'linuxbox' is known and matches the RSA1 host key. debug: Found key in //.ssh/known_hosts:12 debug: Seeding random number generator debug: Encryption type: 3des debug: Sent encrypted session key. debug: Installing crc compensation attack detector. debug: Received encrypted confirmation. debug: Trying RSA authentication with key 'root at solarisbox' debug: Received RSA challenge from server. debug: Sending response to host key RSA challenge. debug: Remote: RSA authentication accepted. debug: RSA authentication refused. debug: Doing password authentication. blah at linuxbox's password: I didn't have this problem before upgrading from 2.3.0p1 on both. running truss on the solaris box shows this : debug: Found key in //.ssh/known_hosts:12 debug: Seeding random number generator debug: Encryption type: 3des debug: Sent encrypted session key. debug: Installing crc compensation attack detector. debug: Received encrypted confirmation. 19087: open("//.ssh/identity", O_RDONLY) = 4 debug: Trying RSA authentication with key 'root at solarisbox' debug: Received RSA challenge from server. 19087: open("//.ssh/identity", O_RDONLY) = 4 debug: Sending response to host key RSA challenge. debug: Remote: RSA authentication accepted. debug: RSA authentication refused. debug: Doing password authentication. 19087: open("/dev/tty", O_RDWR) = 4 blah at linuxbox's password: I can get a passwordless logon if I come from the same username. I'm going to back out back to 2.3.0p1, and see if that fixes it, but does anyone have any suggestions? Maybe I broke a config file? This is my sshd_config on the linuxbox : # $OpenBSD: sshd_config,v 1.32 2001/02/06 22:07:50 deraadt Exp $ # This is the sshd server system-wide configuration file. See sshd(8) # for more information. Port 22 #Protocol 2,1 #ListenAddress 0.0.0.0 #ListenAddress :: HostKey /etc/ssh/ssh_host_key HostKey /etc/ssh/ssh_host_dsa_key #HostKey /etc/ssh/ssh_host_rsa_key ServerKeyBits 768 LoginGraceTime 600 KeyRegenerationInterval 3600 PermitRootLogin yes # # 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/ssh/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 #ChallengeResponseAuthentication no # 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 yes #UseLogin no #MaxStartups 10:30:60 #Banner /etc/issue.net #ReverseMappingCheck yes Subsystem sftp /usr/libexec/openssh/sftp-server Carl From devon at admin2.gisnetworks.com Wed Feb 21 13:12:46 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Tue, 20 Feb 2001 18:12:46 -0800 Subject: Solaris and Latest snapshot (2001-02-21) References: Message-ID: <3A93241E.1869C62D@admin2.gisnetworks.com> all i use is protocol 2... someone else will have to verify v1 for sure, but i believe in the original email about this issue the author said that it was only broken when they were forcing version 2. anyways, i tested the snapshots from around the 15th (first email on the issue appeared) on bass.directhit.com and: 20010215 works. 20010216 is broken. devon mouring at etoh.eviladmin.org wrote: > > On Tue, 20 Feb 2001, Devon Bleak wrote: > > > i don't :/ the last thing that worked on there was 2.3.0p1. i didn't > > load up any cvs code on it til about a week ago. looks like the > > earliest snapshot on there is from the 9th of this month. the earlier > > ones are all 0k. anybody got some earlier snapshots? > > > > I can make you snapshots if you want them. Note there are a few that > are 'bad' versions due to security issues. > > Let me verify.. Solaris is broken for v1 and v2? Or just v2 protocol? > > - Ben From tim at multitalents.net Wed Feb 21 13:32:13 2001 From: tim at multitalents.net (Tim Rice) Date: Tue, 20 Feb 2001 18:32:13 -0800 (PST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Tue, 20 Feb 2001 mouring at etoh.eviladmin.org wrote: > > On Mon, 19 Feb 2001, Tim Rice wrote: > > > On Mon, 19 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > > > > Damien commited a different patch. So I get this is the end of the > > > story unless there are problems with it. > > > > It looks like a good patch. Too bad it doesn't work. [snip] > > Is it possible for you to locate what is doing it? Damien will be out for > a few days, and I don't have access to any SCO machines for testing. And I > don't see the problem under Redhat. OK, it wasn't tough. I had allready made this mistake making my patch. Just needed $saved_LDFLAGS in a few places where $LDFLAGS was used. > > - Ben > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- openssh_cvs/configure.in.old Tue Feb 20 18:16:17 2001 +++ openssh_cvs/configure.in Tue Feb 20 18:16:20 2001 @@ -614,12 +614,12 @@ # Try to use $ssldir/lib if it exists, otherwise # $ssldir if test -d "$ssldir/lib" ; then - LDFLAGS="$LDFLAGS -L$ssldir/lib" + LDFLAGS="$saved_LDFLAGS -L$ssldir/lib" if test ! -z "$need_dash_r" ; then LDFLAGS="$LDFLAGS -R$ssldir/lib" fi else - LDFLAGS="$LDFLAGS -L$ssldir" + LDFLAGS="$saved_LDFLAGS -L$ssldir" if test ! -z "$need_dash_r" ; then LDFLAGS="$LDFLAGS -R$ssldir" fi @@ -676,12 +676,12 @@ # Try to use $ssldir/lib if it exists, otherwise # $ssldir if test -d "$ssldir/lib" ; then - LDFLAGS="$LDFLAGS -L$ssldir/lib" + LDFLAGS="$saved_LDFLAGS -L$ssldir/lib" if test ! -z "$need_dash_r" ; then LDFLAGS="$LDFLAGS -R$ssldir/lib" fi else - LDFLAGS="$LDFLAGS -L$ssldir" + LDFLAGS="$saved_LDFLAGS -L$ssldir" if test ! -z "$need_dash_r" ; then LDFLAGS="$LDFLAGS -R$ssldir" fi From mouring at etoh.eviladmin.org Wed Feb 21 13:34:27 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 20 Feb 2001 20:34:27 -0600 (CST) Subject: Solaris and Latest snapshot (2001-02-21) In-Reply-To: <3A93241E.1869C62D@admin2.gisnetworks.com> Message-ID: On Tue, 20 Feb 2001, Devon Bleak wrote: > all i use is protocol 2... someone else will have to verify v1 for > sure, but i believe in the original email about this issue the author > said that it was only broken when they were forcing version 2. > > anyways, i tested the snapshots from around the 15th (first email on the > issue appeared) on bass.directhit.com and: > 20010215 works. > 20010216 is broken. > > devon > There is only two sets of pam patches around that date. One is a suggestion to clean up PAM space. Which I can't see any fault. And this one which stated it was for solaris. Can you apply this reverse and see if this gets us closer to fixing this? Or if the problem still exists? - Ben --- session.c Tue Feb 20 20:31:55 2001 +++ ../openssh/session.c Sun Feb 18 13:03:29 2001 @@ -1017,6 +1017,10 @@ #endif /* WITH_IRIX_ARRAY */ #endif /* WITH_IRIX_JOBS */ +#ifdef USE_PAM + do_pam_session(pw->pw_name, ttyname); + do_pam_setcred(); +#endif /* USE_PAM */ /* login(1) is only called if we execute the login shell */ if (options.use_login && command != NULL) @@ -1142,11 +1146,6 @@ #ifdef HAVE_LOGIN_CAP shell = login_getcapstr(lc, "shell", (char *)shell, (char *)shell); #endif - -#ifdef USE_PAM - do_pam_session(pw->pw_name, ttyname); - do_pam_setcred(); -#endif /* USE_PAM */ #ifdef AFS /* Try to get AFS tokens for the local cell. */ From mouring at etoh.eviladmin.org Wed Feb 21 13:51:59 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 20 Feb 2001 20:51:59 -0600 (CST) Subject: OpenSSH 2.5.0p1 In-Reply-To: Message-ID: On Tue, 20 Feb 2001, Tim Rice wrote: > On Tue, 20 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > On Mon, 19 Feb 2001, Tim Rice wrote: > > > > > On Mon, 19 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > > > > > > > Damien commited a different patch. So I get this is the end of the > > > > story unless there are problems with it. > > > > > > It looks like a good patch. Too bad it doesn't work. > [snip] > > > > Is it possible for you to locate what is doing it? Damien will be out for > > a few days, and I don't have access to any SCO machines for testing. And I > > don't see the problem under Redhat. > > OK, it wasn't tough. I had allready made this mistake making my patch. > Just needed $saved_LDFLAGS in a few places where $LDFLAGS was used. > I think a few less $saved_* could be used.. but I'm just too bloody tired of this to go one more round. We are talking about doing a clean of configure.in before the next major releas anyway.=) Applied. - Ben From kschrade at engin.umich.edu Wed Feb 21 14:39:09 2001 From: kschrade at engin.umich.edu (Kurt Schrader) Date: Tue, 20 Feb 2001 22:39:09 -0500 (EST) Subject: key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 In-Reply-To: Message-ID: Assuming that you mean that I was connecting to another RH 7 box, that is incorrect. It happens when I try to connect to SunOS 2.6 boxes and to my OpenBSD 2.7-8 (last update from current was somewhere in between) box and every other box I have tried. I don't have another RH 7 box to connect to. I installed from RPM. On Tue, 20 Feb 2001 mouring at etoh.eviladmin.org wrote: > > Only thing I can link to is the fact they are both Redhat 7.0 boxes. Are > they fresh compiles or did you both install from RPMs? > > - Ben > > From mouring at etoh.eviladmin.org Wed Feb 21 15:34:14 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 20 Feb 2001 22:34:14 -0600 (CST) Subject: key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 In-Reply-To: Message-ID: But your client is always Redhat. Did you compile the OpenSSH client on Redhat or did you use a pre-packaged RPM? If so where did you get the RPM? Unless your stating you get zero finger prints from SunOS to OpenBSD and OpenBSD to SunOS. - Ben On Tue, 20 Feb 2001, Kurt Schrader wrote: > > Assuming that you mean that I was connecting to another RH 7 box, that is > incorrect. It happens when I try to connect to SunOS 2.6 boxes and to my > OpenBSD 2.7-8 (last update from current was somewhere in between) box and > every other box I have tried. > I don't have another RH 7 box to connect to. > I installed from RPM. > > On Tue, 20 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > Only thing I can link to is the fact they are both Redhat 7.0 boxes. Are > > they fresh compiles or did you both install from RPMs? > > > > - Ben > > > > > > From kschrade at engin.umich.edu Wed Feb 21 15:51:11 2001 From: kschrade at engin.umich.edu (Kurt Schrader) Date: Tue, 20 Feb 2001 23:51:11 -0500 (EST) Subject: key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 In-Reply-To: Message-ID: I used a prepacked RPM from ftp1.usa.openbsd.org I only get the fingerprints from the RH client. On Tue, 20 Feb 2001 mouring at etoh.eviladmin.org wrote: > > But your client is always Redhat. Did you compile the OpenSSH client > on Redhat or did you use a pre-packaged RPM? If so where did you > get the RPM? Unless your stating you get zero finger prints from SunOS to > OpenBSD and OpenBSD to SunOS. > > - Ben > > On Tue, 20 Feb 2001, Kurt Schrader wrote: > > > > > Assuming that you mean that I was connecting to another RH 7 box, that is > > incorrect. It happens when I try to connect to SunOS 2.6 boxes and to my > > OpenBSD 2.7-8 (last update from current was somewhere in between) box and > > every other box I have tried. > > I don't have another RH 7 box to connect to. > > I installed from RPM. > > > > On Tue, 20 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > > > > Only thing I can link to is the fact they are both Redhat 7.0 boxes. Are > > > they fresh compiles or did you both install from RPMs? > > > > > > - Ben > > > > > > > > > > > > From mouring at etoh.eviladmin.org Wed Feb 21 15:59:58 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 20 Feb 2001 22:59:58 -0600 (CST) Subject: key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 In-Reply-To: Message-ID: Which OpenSSL package is installed? On Tue, 20 Feb 2001, Kurt Schrader wrote: > > I used a prepacked RPM from ftp1.usa.openbsd.org > I only get the fingerprints from the RH client. > > On Tue, 20 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > But your client is always Redhat. Did you compile the OpenSSH client > > on Redhat or did you use a pre-packaged RPM? If so where did you > > get the RPM? Unless your stating you get zero finger prints from SunOS to > > OpenBSD and OpenBSD to SunOS. > > > > - Ben > > > > On Tue, 20 Feb 2001, Kurt Schrader wrote: > > > > > > > > Assuming that you mean that I was connecting to another RH 7 box, that is > > > incorrect. It happens when I try to connect to SunOS 2.6 boxes and to my > > > OpenBSD 2.7-8 (last update from current was somewhere in between) box and > > > every other box I have tried. > > > I don't have another RH 7 box to connect to. > > > I installed from RPM. > > > > > > On Tue, 20 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > > > > > > > Only thing I can link to is the fact they are both Redhat 7.0 boxes. Are > > > > they fresh compiles or did you both install from RPMs? > > > > > > > > - Ben > > > > > > > > > > > > > > > > > > > From devon at admin2.gisnetworks.com Wed Feb 21 16:33:18 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Tue, 20 Feb 2001 21:33:18 -0800 Subject: Solaris and Latest snapshot (2001-02-21) References: Message-ID: <003d01c09bc7$cbdbf100$1900a8c0@devn> that fixed scp and the PATH issue... devon ----- Original Message ----- From: To: "Devon Bleak" Cc: Sent: Tuesday, February 20, 2001 6:34 PM Subject: Re: Solaris and Latest snapshot (2001-02-21) > On Tue, 20 Feb 2001, Devon Bleak wrote: > > > all i use is protocol 2... someone else will have to verify v1 for > > sure, but i believe in the original email about this issue the author > > said that it was only broken when they were forcing version 2. > > > > anyways, i tested the snapshots from around the 15th (first email on the > > issue appeared) on bass.directhit.com and: > > 20010215 works. > > 20010216 is broken. > > > > devon > > > There is only two sets of pam patches around that date. One is a > suggestion to clean up PAM space. Which I can't see any fault. And this > one which stated it was for solaris. Can you apply this reverse and see > if this gets us closer to fixing this? Or if the problem still exists? > > - Ben > > --- session.c Tue Feb 20 20:31:55 2001 > +++ ../openssh/session.c Sun Feb 18 13:03:29 2001 > @@ -1017,6 +1017,10 @@ > #endif /* WITH_IRIX_ARRAY */ > #endif /* WITH_IRIX_JOBS */ > > +#ifdef USE_PAM > + do_pam_session(pw->pw_name, ttyname); > + do_pam_setcred(); > +#endif /* USE_PAM */ > > /* login(1) is only called if we execute the login shell */ > if (options.use_login && command != NULL) > @@ -1142,11 +1146,6 @@ > #ifdef HAVE_LOGIN_CAP > shell = login_getcapstr(lc, "shell", (char *)shell, (char *)shell); > #endif > - > -#ifdef USE_PAM > - do_pam_session(pw->pw_name, ttyname); > - do_pam_setcred(); > -#endif /* USE_PAM */ > > #ifdef AFS > /* Try to get AFS tokens for the local cell. */ > > From mouring at etoh.eviladmin.org Wed Feb 21 17:25:50 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 21 Feb 2001 00:25:50 -0600 (CST) Subject: Solaris and Latest snapshot (2001-02-21) In-Reply-To: <003d01c09bc7$cbdbf100$1900a8c0@devn> Message-ID: On Tue, 20 Feb 2001, Devon Bleak wrote: > that fixed scp and the PATH issue... > > devon > So.. that is the last issues with Solaris that you have? =) (Not including manpages). - Ben From devon at admin2.gisnetworks.com Wed Feb 21 16:38:29 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Tue, 20 Feb 2001 21:38:29 -0800 Subject: Solaris and Latest snapshot (2001-02-21) References: Message-ID: <004701c09bc8$8524f490$1900a8c0@devn> that's all i have for solaris... for now ;) ----- Original Message ----- From: To: "Devon Bleak" Cc: Sent: Tuesday, February 20, 2001 10:25 PM Subject: Re: Solaris and Latest snapshot (2001-02-21) > > > On Tue, 20 Feb 2001, Devon Bleak wrote: > > > that fixed scp and the PATH issue... > > > > devon > > > So.. that is the last issues with Solaris that you have? =) (Not > including manpages). > > - Ben > > From svaughan at asterion.com Wed Feb 21 16:30:45 2001 From: svaughan at asterion.com (svaughan) Date: Tue, 20 Feb 2001 21:30:45 -0800 (PST) Subject: SCO 5.0.5 setluid patch In-Reply-To: Message-ID: Hi Tim, Could you send me some info on your SCO machine you compiled on? setluid has been working great for me on all the SCO boxes in our network. (they are all 5.0.5) Thanks, Sam On Tue, 20 Feb 2001, Tim Rice wrote: > On Fri, 16 Feb 2001, Damien Miller wrote: > > > On Thu, 15 Feb 2001, svaughan wrote: > > > > > Here is an updated patch. Sorry, I thought setluid was SCO specific. > > > > I have modified your patch a little. Can you please give the below one > > a try? > > > > Close, but needs some work. > rlogin > tim(trr)@sco504 1% id -l > uid=31(tim) gid=85(trr) luid=31(tim) groups=85(trr),18(lp),50(group) > > ssh > tim(trr)@sco504 1% id -l > uid=31(tim) gid=85(trr) luid=0(root) groups=85(trr),18(lp),50(group) > ^^^^^^ > Not quite what we want. > > > It does not try to do setluid for non-OpenServer systems. From docs.sco.com > > it says that Unixware also offers the get/setluid syscalls, but they will > > always fail. > > > [patch sniped] > > > > > > -- > Tim Rice Multitalents (707) 887-1469 > tim at multitalents.net > > From jmknoble at jmknoble.cx Wed Feb 21 16:52:39 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Wed, 21 Feb 2001 00:52:39 -0500 Subject: Portable OpenSSH 2.5.1p1: daemontools-aware? In-Reply-To: <20010220124825.C91708@lizzy.bugworks.com>; from josb@cncdsl.com on Tue, Feb 20, 2001 at 12:48:25PM -0800 References: <20010219161640.A26669@lizzy.bugworks.com> <20010220102954.A23932@faui02.informatik.uni-erlangen.de> <20010220124825.C91708@lizzy.bugworks.com> Message-ID: <20010221005239.Z25687@quipu.half.pint-stowp.cx> Circa 2001-Feb-20 12:48:25 -0800 dixit Jos Backus: : This tiny patch adds a ``-e'' flag to force logging to stderr instead of : syslog. : : --- openssh-2.5.1p1.dist/sshd.c Sun Feb 18 11:13:12 2001 : +++ openssh-2.5.1p1/sshd.c Tue Feb 20 11:22:15 2001 : @@ -576,7 +576,7 @@ : initialize_server_options(&options); : : /* Parse command-line arguments. */ : - while ((opt = getopt(ac, av, "f:p:b:k:h:g:V:u:dDiqQ46")) != -1) { : + while ((opt = getopt(ac, av, "ef:p:b:k:h:g:V:u:dDiqQ46")) != -1) { : switch (opt) { : case '4': : IPv4or6 = AF_INET; : @@ -600,6 +600,9 @@ : break; : case 'D': : no_daemon_flag = 1; : + break; : + case 'e': : + log_stderr = 1; I'd rather see this option called '-L' rather than '-e', so as to be parallel with '-D'. Comments? Nice patch otherwise. -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From mouring at etoh.eviladmin.org Wed Feb 21 17:48:27 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 21 Feb 2001 00:48:27 -0600 (CST) Subject: further problems with OpenSSH 2.5.1p1 on RH 6.2 In-Reply-To: <200102210203.f1L23Ps13067@rollcage.bl.echidna.id.au> Message-ID: Consider moving to 0.9.6 OpenSSL. I belive part of the issues are the RPMs are compiled against 0.9.6 and odd things occur when you use 0.9.5a. - Ben On Wed, 21 Feb 2001 carl at bl.echidna.id.au wrote: > I'm finding another problem with OpenSSH 2.5.1p1 on RH 6.2 (at least, > I think it's the linux box that is the problem). > > I'm ssh'ing to a RH 6.2 box from a Solaris 7 server (scp also... seems > like the same problem). > > I'm using authorized_keys and identity.pub files to do it automagically, > and all works well when it's from user to user, where the username is the > same, but if I do something like this : > > root at solarisbox: ssh -l blah linuxbox > > I'm seeing this : > > ssh -1 -v -l blah linuxbox > OpenSSH_2.5.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f > debug: Reading configuration data /opt/local/etc/ssh_config > debug: Applying options for * > debug: ssh_connect: getuid 0 geteuid 0 anon 0 > debug: Connecting to linuxbox [1.2.3.4] port 22. > debug: Seeding random number generator > debug: Allocated local port 635. > debug: Connection established. > debug: identity file //.ssh/identity type 0 > debug: Remote protocol version 1.99, remote software version OpenSSH_2.5.1p1 > debug: match: OpenSSH_2.5.1p1 pat ^OpenSSH > debug: Local version string SSH-1.5-OpenSSH_2.5.1p1 > debug: Waiting for server public key. > debug: Received server public key (768 bits) and host key (1024 bits). > debug: Host 'linuxbox' is known and matches the RSA1 host key. > debug: Found key in //.ssh/known_hosts:12 > debug: Seeding random number generator > debug: Encryption type: 3des > debug: Sent encrypted session key. > debug: Installing crc compensation attack detector. > debug: Received encrypted confirmation. > debug: Trying RSA authentication with key 'root at solarisbox' > debug: Received RSA challenge from server. > debug: Sending response to host key RSA challenge. > debug: Remote: RSA authentication accepted. > debug: RSA authentication refused. > debug: Doing password authentication. > blah at linuxbox's password: > > > I didn't have this problem before upgrading from 2.3.0p1 on both. > > running truss on the solaris box shows this : > > debug: Found key in //.ssh/known_hosts:12 > debug: Seeding random number generator > debug: Encryption type: 3des > debug: Sent encrypted session key. > debug: Installing crc compensation attack detector. > debug: Received encrypted confirmation. > 19087: open("//.ssh/identity", O_RDONLY) = 4 > debug: Trying RSA authentication with key 'root at solarisbox' > debug: Received RSA challenge from server. > 19087: open("//.ssh/identity", O_RDONLY) = 4 > debug: Sending response to host key RSA challenge. > debug: Remote: RSA authentication accepted. > debug: RSA authentication refused. > debug: Doing password authentication. > 19087: open("/dev/tty", O_RDWR) = 4 > blah at linuxbox's password: > > I can get a passwordless logon if I come from the same username. > > I'm going to back out back to 2.3.0p1, and see if that fixes it, > but does anyone have any suggestions? Maybe I broke a config file? > > This is my sshd_config on the linuxbox : > > # $OpenBSD: sshd_config,v 1.32 2001/02/06 22:07:50 deraadt Exp $ > > # This is the sshd server system-wide configuration file. See sshd(8) > # for more information. > > Port 22 > #Protocol 2,1 > #ListenAddress 0.0.0.0 > #ListenAddress :: > HostKey /etc/ssh/ssh_host_key > HostKey /etc/ssh/ssh_host_dsa_key > #HostKey /etc/ssh/ssh_host_rsa_key > ServerKeyBits 768 > LoginGraceTime 600 > KeyRegenerationInterval 3600 > PermitRootLogin yes > # > # 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/ssh/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 > #ChallengeResponseAuthentication no > > # 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 yes > #UseLogin no > > #MaxStartups 10:30:60 > #Banner /etc/issue.net > #ReverseMappingCheck yes > > Subsystem sftp /usr/libexec/openssh/sftp-server > > Carl > > From jxing at mail.com Wed Feb 21 17:04:41 2001 From: jxing at mail.com (John XING) Date: Tue, 20 Feb 2001 22:04:41 -0800 Subject: openssh-2.5.1p1 problem on redhat 6.2 Message-ID: <20010220220441.A1446@box.lyang.net> Hi, I built rpm from openssh-2.5.1p1 srpm on redhat 6.2, then installed it. When trying to ssh from other machine, sshd gives error: ..... Feb 20 17:54:24 foo PAM_pwdb[925]: (login) session opened for user doe by LOGIN(uid=0) Feb 20 17:55:15 foo sshd[1342]: Connection closed by 192.168.0.3 Feb 20 17:55:43 foo sshd[1343]: PAM unable to dlopen(/lib/security/pam_stack.so) Feb 20 17:55:43 foo sshd[1343]: PAM [dlerror: /lib/security/pam_stack.so: cannot open shared object file: No such file or directory] Feb 20 17:55:43 foo sshd[1343]: PAM adding faulty module: /lib/security/pam_stack.so Feb 20 17:55:46 foo sshd[1343]: Failed password for doe from 192.168.0.3 port 1121 Feb 20 17:56:01 foo sshd[1343]: Failed password for doe from 192.168.0.3 port 1121 ..... Seems linked to wrong lib? Any suggestions? Thanks, John From pekkas at netcore.fi Wed Feb 21 17:41:57 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 21 Feb 2001 08:41:57 +0200 (EET) Subject: openssh-2.5.1p1 problem on redhat 6.2 In-Reply-To: <20010220220441.A1446@box.lyang.net> Message-ID: On Tue, 20 Feb 2001, John XING wrote: > > I built rpm from openssh-2.5.1p1 srpm on redhat 6.2, > then installed it. When trying to ssh from other machine, > sshd gives error: > > ..... > Feb 20 17:54:24 foo PAM_pwdb[925]: (login) session opened for user doe by LOGIN(uid=0) > Feb 20 17:55:15 foo sshd[1342]: Connection closed by 192.168.0.3 > Feb 20 17:55:43 foo sshd[1343]: PAM unable to dlopen(/lib/security/pam_stack.so) > Feb 20 17:55:43 foo sshd[1343]: PAM [dlerror: /lib/security/pam_stack.so: cannot open shared object file: No such file or directory] > Feb 20 17:55:43 foo sshd[1343]: PAM adding faulty module: /lib/security/pam_stack.so > Feb 20 17:55:46 foo sshd[1343]: Failed password for doe from 192.168.0.3 port 1121 > Feb 20 17:56:01 foo sshd[1343]: Failed password for doe from 192.168.0.3 port 1121 > ..... Upgrade your pam to the errata version. I think that should help; there is no pam_stack.so on RHL6x as shipped. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From pekkas at netcore.fi Wed Feb 21 17:43:00 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 21 Feb 2001 08:43:00 +0200 (EET) Subject: key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 In-Reply-To: Message-ID: On Tue, 20 Feb 2001, Kurt Schrader wrote: > Assuming that you mean that I was connecting to another RH 7 box, that is > incorrect. It happens when I try to connect to SunOS 2.6 boxes and to my > OpenBSD 2.7-8 (last update from current was somewhere in between) box and > every other box I have tried. > I don't have another RH 7 box to connect to. > I installed from RPM. Try to --rebuild .src.rpm. I bet it'll work then. I'm guessing the binary incompatibilities between openssl 0.9.5a and 0.9.6. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From darryl at idealgroup.com Wed Feb 21 17:49:50 2001 From: darryl at idealgroup.com (Darryl Krasman) Date: Tue, 20 Feb 2001 22:49:50 -0800 Subject: SCO 5.0.5 setluid patch Message-ID: <3A93650E.C0354804@idealgroup.com> I downloaded openssh-2.5.1p1 as soon as it was on the ftp servers just to get the setluid patch. After compiling and installing on 5.0.5 I saw that the luid still wasn't being set correctly whether sshd was run from inetd or as a daemon from /etc/rc2.d/. I fiddled around and moved the setluid() stuff up higher in session.c and now luid is now being set correctly. I provided a regular diff below. I am not a power c programmer or cvs guy so I hope you'll be kind if the diff is crude. More importantly, I hope that where I moved it to is correct! -- Darryl Ideal Computer Group Inc. thor 314 : /u/sco/source/openssh-2.5.1p1 # diff session.c session.drk.c 1024a1025,1031 > /* DRK: moved this stuff up higher */ > #if defined(HAVE_GETLUID) && defined(HAVE_SETLUID) > /* Sets login uid for accounting */ > if (getluid() == -1 && setluid(pw->pw_uid) == -1) > error("setluid: %s", strerror(errno)); > #endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */ > 1128,1133d1134 < < #if defined(HAVE_GETLUID) && defined(HAVE_SETLUID) < /* Sets login uid for accounting */ < if (getluid() == -1 && setluid(pw->pw_uid) == -1) < error("setluid: %s", strerror(errno)); < #endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */ From nojunk13 at yahoo.com Wed Feb 21 18:04:40 2001 From: nojunk13 at yahoo.com (M Seid) Date: Tue, 20 Feb 2001 23:04:40 -0800 (PST) Subject: Compile problems with 2.5.1p1 and older Linux boxes Message-ID: <20010221070440.67811.qmail@web10005.mail.yahoo.com> Hi, I'm having problems building 2.5.1p1 on two of my older Linux boxes. One box is running RH 5.2 and the other Debian 2.0. Both are using gcc 2.7.2.3, openssl-0.9.6 and glibc-2.0.7. They both also die on the same error, and the configure options I use don't seem to make a difference. 2.3.0p1 compiled fine on both of these machines. [...] gcc -g -O2 -Wall -I. -I./openbsd-compat -I. -DETCDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/opt/openssh/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/opt/openssh/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/opt/openssh/libexec/sftp-server\" -DHAVE_CONFIG_H -c cli.c In file included from includes.h:39, from cli.c:1: /usr/include/signal.h:216: warning: `struct sigaction' declared inside parameter list /usr/include/signal.h:216: warning: its scope is only this definition or declaration, /usr/include/signal.h:216: warning: which is probably not what you want. /usr/include/signal.h:218: warning: `struct sigaction' declared inside parameter list cli.c: In function `cli_echo_disable': cli.c:67: `SIG_BLOCK' undeclared (first use this function) cli.c:67: (Each undeclared identifier is reported only once cli.c:67: for each function it appears in.) cli.c:71: sizeof applied to an incomplete type cli.c:72: invalid use of undefined type `struct sigaction' cli.c:73: warning: passing arg 2 of `sigaction' from incompatible pointer type cli.c:73: warning: passing arg 3 of `sigaction' from incompatible pointer type cli.c: In function `cli_echo_restore': cli.c:93: `SIG_SETMASK' undeclared (first use this function) cli.c:94: warning: passing arg 2 of `sigaction' from incompatible pointer type cli.c: At top level: cli.c:14: storage size of `nsa' isn't known cli.c:15: storage size of `osa' isn't known make: *** [cli.o] Error 1 Here are lines 215-218 from /usr/include/signal.h: extern int __sigaction __P ((int __sig, __const struct sigaction *__act, struct sigaction *__oact)); extern int sigaction __P ((int __sig, __const struct sigaction *__act, struct sigaction *__oact)); Thanks for your help! Mike __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/ From kschrade at engin.umich.edu Wed Feb 21 18:26:40 2001 From: kschrade at engin.umich.edu (Kurt Schrader) Date: Wed, 21 Feb 2001 02:26:40 -0500 (EST) Subject: key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 In-Reply-To: Message-ID: Problem solved, there were multiple conflicting OpenSSL packages installed. Removing the rpm of the older one solved the problem. Kurt On Tue, 20 Feb 2001 mouring at etoh.eviladmin.org wrote: > > Which OpenSSL package is installed? > > On Tue, 20 Feb 2001, Kurt Schrader wrote: > > > > > I used a prepacked RPM from ftp1.usa.openbsd.org > > I only get the fingerprints from the RH client. > > > > On Tue, 20 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > > > > But your client is always Redhat. Did you compile the OpenSSH client > > > on Redhat or did you use a pre-packaged RPM? If so where did you > > > get the RPM? Unless your stating you get zero finger prints from SunOS to > > > OpenBSD and OpenBSD to SunOS. > > > > > > - Ben > > > > > > On Tue, 20 Feb 2001, Kurt Schrader wrote: > > > > > > > > > > > Assuming that you mean that I was connecting to another RH 7 box, that is > > > > incorrect. It happens when I try to connect to SunOS 2.6 boxes and to my > > > > OpenBSD 2.7-8 (last update from current was somewhere in between) box and > > > > every other box I have tried. > > > > I don't have another RH 7 box to connect to. > > > > I installed from RPM. > > > > > > > > On Tue, 20 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > > > > > > > > > > Only thing I can link to is the fact they are both Redhat 7.0 boxes. Are > > > > > they fresh compiles or did you both install from RPMs? > > > > > > > > > > - Ben > > > > > > > > > > > > > > > > > > > > > > > > > > > > From randolf at skerka.de Wed Feb 21 18:33:43 2001 From: randolf at skerka.de (Randolf Skerka) Date: Wed, 21 Feb 2001 08:33:43 +0100 Subject: OpenSSH 2.5.1p1 on HP-UX: No CTRL+C possible!!! Message-ID: <3A936F57.6952C208@skerka.de> I've compiled 2.5.1p1 on HP-UX mdv010 B.11.00 A 9000/887 457369232 two-user license with --prefix=/usr --sysconfdir=/etc/ssh \ --with-ssl-dir=$MYPWD/openssl-0.9.6 \ --with-pid-dir=/etc/ssh \ --with-default-path=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin --with-entropy-timeout=250 Nothin special I think, works fine with 2.3.0p1. Well, when I try to stop a process using CTRL+C (CTRL+Z does not work too) nothing happens. Is it a known problem? Randolf -- +---------------------------------------------------------------------+ | Randolf Skerka http://www.randolf.org | +---------------------------------------------------------------------+ From pekkas at netcore.fi Wed Feb 21 19:14:31 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 21 Feb 2001 10:14:31 +0200 (EET) Subject: OpenSSL + OpenSSH version problems Message-ID: Hello all, OpenSSL 0.9.5a and 0.9.6 are incompatible, causing weird errors. I'd like to get a check for this in the RPMs. However, now I want to make sure whether anyone has experienced problems with RHL 0.9.5a OpenSSL libs vs. the 0.9.5a ones provided at openbsd.org? Ie: is it enough to check like '= 0.9.5a' or do you have to check '= 0.9.5a-xyz'. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From stevesk at sweden.hp.com Wed Feb 21 21:22:20 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Wed, 21 Feb 2001 11:22:20 +0100 (MET) Subject: OpenSSH 2.5.1p1 on HP-UX: No CTRL+C possible!!! In-Reply-To: <3A936F57.6952C208@skerka.de> Message-ID: On Wed, 21 Feb 2001, Randolf Skerka wrote: : I've compiled 2.5.1p1 on : : HP-UX mdv010 B.11.00 A 9000/887 457369232 two-user license : : with --prefix=/usr --sysconfdir=/etc/ssh \ : --with-ssl-dir=$MYPWD/openssl-0.9.6 \ : --with-pid-dir=/etc/ssh \ : --with-default-path=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin : --with-entropy-timeout=250 : : Nothin special I think, works fine with 2.3.0p1. : : Well, when I try to stop a process using CTRL+C (CTRL+Z does not work : too) nothing happens. i don't see this on hp-ux 11. what does stty -a show? does it work if you do stty intr ^c From Ulrich.Windl at rz.uni-regensburg.de Wed Feb 21 21:41:16 2001 From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl) Date: Wed, 21 Feb 2001 11:41:16 +0100 Subject: openssh-2.3.0p1 on HP-UX 11.00 went mad Message-ID: <3A93A94D.10172.CD3121@localhost> Hi, I had a strange effect: I tried to debug a program with GNU debugger when very strange messages appeared on the screen. Like: (gdb) Undefined command: "3". Try "help". (gdb) Undefined command: "". Try "help". (gdb) Undefined command: "". Try "help". (gdb) Undefined command: "". Try "help". I found out that a co-worked security-tested the machine with SAINT. Thus the syslog said this about SSH: rkdvmhp3 sshd[4041]: Bad protocol version identification 'QUIT rkdvmhp3 sshd[4095]: Did not receive ident string from 132.199.206.2. The truely odd thing is that gdb seems to work normally when I try to capture the output via "script", so it might be a terminal thing. Anyway I succeeded to capture the output: /opt/gdb/bin/gdb ~windl/src/C++/HCM/HCMextract GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "hppa2.0n-hp-hpux11.00"... (gdb) (gdb) (gdb) 466 #if 1 467 //// 468 // Workaround: "return(x)" does not set exit code 469 //// 470 #define return(x) exit(x) 471 #endif 472 473 /* main program parses arguments and begins execution */ 474 int main(int argc, char *argv[]) 475 { (gdb) Undefined command: "". Try "help". (gdb) Undefined command: "". Try "help". (gdb) The history is empty. (gdb) Undefined command: "". Try "help". (gdb) Undefined command: "". Try "help". (gdb) Undefined command: "". Try "help". (gdb) Undefined command: "". Try "help". (gdb) Undefined command: "4". Try "help". (gdb) (gdb) Undefined command: "". Try "help". (gdb) 476 SCOPE("main"); 477 int status_fd; 478 int option; 479 int bad_syntax = 0; 480 char path[PATH_MAX + 1]; 481 char *next_elem; ---Type to continue, or q to quit--- j---Type to continue, or q to quit--- j (arg: 1) j8) ---Type to continue, or q to quit--- jj     j | x t p h L @ < 8 8 48 < @ L h p t x | j j--Type to continue, or q to quit---4 48 < @ L h p t x | j j-Type to continue, or q to quit--- $48 < @ L h p t x | j--Type to continue, or q to quit--- $, $48 < @ L h p t x |  --Type to continue, or q to quit---, , $48 < @ L h p t x |  -Type to continue, or q to quit--- 4, $48 < @ L h p t x |  Type to continue, or q to quit--- 4---Type to continue, or q to quit--- 4, $48 < @ L h p t x | j je to continue, or q to quit--- 4, $48 < @ L h p t x |  ype to continue, or q to quit--- 4, $48 < @ L h p t x | Type to continue, or q to quit--- 482 To make things worse, the gdb runs normally if I log in directly as "v11adm". In the previous attempt I logged in as "root" and did a "su - v11adm". Rather puzzled. Can anybody make any sense in this? Regards, Ulrich From svaughan at asterion.com Wed Feb 21 21:46:05 2001 From: svaughan at asterion.com (svaughan) Date: Wed, 21 Feb 2001 02:46:05 -0800 (PST) Subject: SCO 5.0.5 setluid patch In-Reply-To: Message-ID: Oops, sorry. I jumped the gun here. I just remembered that I am running 2.3.0p1 with the setluid patch on my servers. Ignore my previous email. I downloaded 2.5.1p1 and tested it. It does not set the luid correctly on my SCO 5.0.5 box. setluid is erring out because: sshd[15834]: error: setluid: Operation not permitted After looking through session.c again and doing some more research. It turns out that setluid needs to be called before setuid and setgid. After these are set the LUID cannot be changed, even by root. from the setluid manpage: The setluid routine is invoked by the login(M) program just prior to the identity changes caused by setuid(S) and setgid(S) calls. Here is a patch with setluid being called in a better spot. Sorry, I should have caught this earlier. Sam *** openssh-2.5.1p1/session.c Sun Feb 18 11:13:34 2001 --- openssh-2.5.1p1_patch/session.c Wed Feb 21 02:05:28 2001 *************** *** 1075,1080 **** } #endif # else /* HAVE_LOGIN_CAP */ if (setlogin(pw->pw_name) < 0) error("setlogin failed: %s", strerror(errno)); if (setgid(pw->pw_gid) < 0) { --- 1075,1086 ---- } #endif # else /* HAVE_LOGIN_CAP */ + + #if defined(HAVE_GETLUID) && defined(HAVE_SETLUID) + /* Sets login uid for accounting */ + if (getluid() == -1 && setluid(pw->pw_uid) == -1) + error("setluid: %s", strerror(errno)); + #endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */ if (setlogin(pw->pw_name) < 0) error("setlogin failed: %s", strerror(errno)); if (setgid(pw->pw_gid) < 0) { *************** *** 1126,1136 **** } #endif /* HAVE_OSF_SIA */ - #if defined(HAVE_GETLUID) && defined(HAVE_SETLUID) - /* Sets login uid for accounting */ - if (getluid() == -1 && setluid(pw->pw_uid) == -1) - error("setluid: %s", strerror(errno)); - #endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */ #ifdef HAVE_CYGWIN if (is_winnt) --- 1132,1137 ---- } #endif /* HAVE_OSF_SIA */ #ifdef HAVE_CYGWIN if (is_winnt) > > Hi Tim, > Could you send me some info on your SCO machine you compiled > on? setluid has been working great for me on all the SCO boxes in our > network. (they are all 5.0.5) > > > Thanks, > Sam > > On Tue, 20 Feb 2001, Tim Rice wrote: > > > On Fri, 16 Feb 2001, Damien Miller wrote: > > > > > On Thu, 15 Feb 2001, svaughan wrote: > > > > > > > Here is an updated patch. Sorry, I thought setluid was SCO specific. > > > > > > I have modified your patch a little. Can you please give the below one > > > a try? > > > > > > > Close, but needs some work. > > rlogin > > tim(trr)@sco504 1% id -l > > uid=31(tim) gid=85(trr) luid=31(tim) groups=85(trr),18(lp),50(group) > > > > ssh > > tim(trr)@sco504 1% id -l > > uid=31(tim) gid=85(trr) luid=0(root) groups=85(trr),18(lp),50(group) > > ^^^^^^ > > Not quite what we want. > > > > > It does not try to do setluid for non-OpenServer systems. From docs.sco.com > > > it says that Unixware also offers the get/setluid syscalls, but they will > > > always fail. > > > > > [patch sniped] > > > > > > > > > > -- > > Tim Rice Multitalents (707) 887-1469 > > tim at multitalents.net > > > > > > From Gintautas.Grigelionis at ki.ericsson.se Wed Feb 21 22:36:58 2001 From: Gintautas.Grigelionis at ki.ericsson.se (Gintautas Grigelionis) Date: Wed, 21 Feb 2001 12:36:58 +0100 (MET) Subject: 2.5.1p1 Solaris ssh can't talk to sshd In-Reply-To: <20010221110318.A6187@faui02.informatik.uni-erlangen.de> from "Markus Friedl" at Feb 21, 2001 11:03:18 AM Message-ID: <200102211136.MAA13090@freja.eral.ericsson.se> I built KTH Kerberos 1.0.6, OpenSSL 0.9.6, zlib 1.1.3 and OpenSSH 2.5.1p1 with WorkShop 5.0 on Solaris 2.6; /dev/random is provided by cryptorand from SUNWski. ssh -v -v -v produces the same output as ssh -v > ssh -v foobar OpenSSH_2.5.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090600f debug: Reading configuration data /etc/ssh/ssh_config debug: ssh_connect: getuid 17454 geteuid 0 anon 0 debug: Connecting to foobar [100.200.200.100] port 22. debug: Seeding random number generator debug: Allocated local port 679. debug: Connection established. debug: identity file /homes/gintas/.ssh/identity type 0 debug: identity file /homes/gintas/.ssh/id_dsa type 3 Bad remote protocol version identification: '' debug: Calling cleanup 0x40a00(0x0) There are further refinements, though. I want to run the same binaries on 2.6 and 7; it works fine 2.6 ssh <-> 2.6/7 sshd (any version), 7 ssh 2.3.0 -> 2.6/7 sshd (any). What doesn't work is 7 ssh 2.5.1 -> 2.6/7 sshd (any). I rebuilt OpenSSH on Solaris 7 without much progress; the only difference between the builds is the message from linker on Solaris 7: ld: warning: symbol `error' has differing types: (file ./libssh.a(log.o) type=FUNC; file /usr/athena/lib/libdes.so type=OBJT); ./libssh.a(log.o) definition taken Thanks, Gintas > On Wed, Feb 21, 2001 at 10:54:33AM +0100, Gintautas Grigelionis wrote: > > > No, I'm still trying to understand what went wrong. I see 2.3.0p1 ssh > > talking to 2.5.1p1 sshd, but 2.5.1p1 ssh can't talk to any server. > > please try to send a bugreport to > openssh-unix-dev at mindrot.org > > include OS versions and > ssh -v -v -v > output. > > thanks, > -markus From Randolf at Skerka.de Wed Feb 21 23:50:56 2001 From: Randolf at Skerka.de (Randolf Skerka) Date: Wed, 21 Feb 2001 13:50:56 +0100 Subject: OpenSSH 2.5.1p1 on HP-UX: No CTRL+C possible!!! In-Reply-To: ; from stevesk@sweden.hp.com on Wed, Feb 21, 2001 at 11:22:20AM +0100 References: <3A936F57.6952C208@skerka.de> Message-ID: <20010221135056.A15309@rhs-notebook> Well stty -a shows the usual entries: > intr = ^C; quit = ^\; erase = ^H; kill = ^U > eof = ^D; eol = ^@; eol2 ; swtch > stop = ^S; start = ^Q; susp ; dsusp It's strange ... Randolf -- +-------------------------------------------------------------------------+ | Randolf Skerka http://www.randolf.org/ | +-------------------= Try to be successfull ... use UNIX =----------------+ From appro at fy.chalmers.se Thu Feb 22 01:37:18 2001 From: appro at fy.chalmers.se (Andy Polyakov) Date: Wed, 21 Feb 2001 15:37:18 +0100 Subject: sftp-server and chown Message-ID: <3A93D29E.7FFDDAE9@fy.chalmers.se> Hi, I've already discussed this issue in SSHSCI's SSH 2.2 context on ssh at clinet.fi list. My standpoint is that it's wrong and meaningless to perform chown in sftp-server as the file is most likely copied between systems with distinct accounting system where user is not necessarily (and even unlikely) has same numeric user id. The original bug report was that user couldn't access files transfered from Windows machine and it turned that Windows client was sending 0:0 for uid:gid pair. The catch is that some systems permit (by default or can be configured to do so) one-way chown to arbitrary uid even for non priviledged users. However, whether the latter is good or bad is more or less irrelevant as there is no guarantee that numeric IDs are the same across two systems and chown is basically meaningless. In addition I think it's also irresponsible to blindly chmod files as different systems might have different access policies (e.g. different umasks). Therefore following patch (relative to OpenSSH 2.5.1p1) is suggested. Cheers. Andy. *** sftp-server.c.orig Tue Feb 13 03:40:56 2001 --- sftp-server.c Wed Feb 21 15:12:07 2001 *************** *** 554,560 **** a = get_attrib(); TRACE("setstat id %d name %s", id, name); if (a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) { ! ret = chmod(name, a->perm & 0777); if (ret == -1) status = errno_to_portable(errno); } --- 554,572 ---- a = get_attrib(); TRACE("setstat id %d name %s", id, name); if (a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) { ! /* ! * Filter it through umask as well. Some clients (most ! * notably SSH Communications' Windows client 2.2.0) ! * send bogus bits (world-writable) which is not really ! * acceptable... ! * ! */ ! static mode_t u_mask = (mode_t)-1; ! ! if (u_mask == (mode_t)-1) ! if ((u_mask=umask(022)) != 022) umask(u_mask); ! ! ret = chmod(name, a->perm & ~u_mask & 0777); if (ret == -1) status = errno_to_portable(errno); } *************** *** 563,573 **** --- 575,597 ---- if (ret == -1) status = errno_to_portable(errno); } + #if 0 + /* + * This goes against everything we're used to and even believe in, + * namely file transfer resetting numerical uid/gid potentially + * across distinct accounting systems. In either case the original + * reason for #if-ing out was that SSH Communications' client for + * Windows (at least 2.2.0) tends to send bogus ownership (most + * notably root:root) while some systems permit non-priviledged + * user to make chown. + * + */ if (a->flags & SSH2_FILEXFER_ATTR_UIDGID) { ret = chown(name, a->uid, a->gid); if (ret == -1) status = errno_to_portable(errno); } + #endif send_status(id, status); xfree(name); } *************** *** 591,600 **** status = SSH2_FX_FAILURE; } else { if (a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) { #ifdef HAVE_FCHMOD ! ret = fchmod(fd, a->perm & 0777); #else ! ret = chmod(name, a->perm & 0777); #endif if (ret == -1) status = errno_to_portable(errno); --- 615,629 ---- status = SSH2_FX_FAILURE; } else { if (a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) { + static mode_t u_mask = (mode_t)-1; + + if (u_mask == (mode_t)-1) + if ((u_mask=umask(022)) != 022) umask(u_mask); + #ifdef HAVE_FCHMOD ! ret = fchmod(fd, a->perm & ~u_mask & 0777); #else ! ret = chmod(name, a->perm & ~u_mask & 0777); #endif if (ret == -1) status = errno_to_portable(errno); *************** *** 608,613 **** --- 637,643 ---- if (ret == -1) status = errno_to_portable(errno); } + #if 0 if (a->flags & SSH2_FILEXFER_ATTR_UIDGID) { #ifdef HAVE_FCHOWN ret = fchown(fd, a->uid, a->gid); *************** *** 617,622 **** --- 647,653 ---- if (ret == -1) status = errno_to_portable(errno); } + #endif } send_status(id, status); } From appro at fy.chalmers.se Thu Feb 22 02:03:18 2001 From: appro at fy.chalmers.se (Andy Polyakov) Date: Wed, 21 Feb 2001 16:03:18 +0100 Subject: X11 display issues Message-ID: <3A93D8B6.84CFC7AC@fy.chalmers.se> Hi, This also has been discussed in SSHSCI's SSH context. All SSH versions (both SSHSCI and OpenSSH) derive value for DISPLAY variable from `uname -n`. The problem is that the returned value is not necessarily resolvable to a valid IP number which in turn might cause a failure. To make it fool-proof I suggest to set DISPLAY to the interface's address the user has reached the system in question through. Yes, one can argue that it might "break" 'xauth add hostname/unix:10.0 ...' thing... Well, but let's wonder what's the meaning for 'xauth add hostname/unix:10.0 ...'... And the answer is "it's meaningless"! It's redundant as ssh server never listens for X11 connections on UNIX socket. Therefore a patch (relative to OpenSSH 2.5.1p1) is suggested. Cheers. Andy. *** channels.c.orig Fri Feb 16 16:56:31 2001 --- channels.c Wed Feb 21 11:49:06 2001 *************** *** 1909,1915 **** char * x11_create_display_inet(int screen_number, int x11_display_offset) { ! int display_number, sock; u_short port; struct addrinfo hints, *ai, *aitop; char strport[NI_MAXSERV]; --- 1909,1915 ---- char * x11_create_display_inet(int screen_number, int x11_display_offset) { ! int display_number, sock=-1; u_short port; struct addrinfo hints, *ai, *aitop; char strport[NI_MAXSERV]; *************** *** 1987,1992 **** --- 1987,1997 ---- } /* Set up a suitable value for the DISPLAY variable. */ + #if 0 + /* + * well, gethostname doesn't necessarily resolve to an address + * so I do something completely different. + */ if (gethostname(hostname, sizeof(hostname)) < 0) fatal("gethostname: %.100s", strerror(errno)); *************** *** 2029,2034 **** --- 2034,2070 ---- display_number, screen_number); #endif /* IPADDR_IN_DISPLAY */ + #else + /* and now something completely different:-) */ + { + struct sockaddr_in me; + socklen_t melen = sizeof(me); + struct hostent *he; + + if (getsockname(packet_get_connection_in(), + (struct sockaddr *)&me, &melen) != 0 + || me.sin_family != AF_INET) { + error("[X11-broken-fwd] Unable to getsockname or unsupported protocol family"); + packet_send_debug("[X11-broken-fwd] Unable to getsockname or unsupported protocol family"); + + shutdown(sock, SHUT_RDWR); + close(sock); + + return NULL; + } + + #ifndef IPADDR_IN_DISPLAY + if ((he = gethostbyaddr ((void *)&me.sin_addr, + sizeof(me.sin_addr),AF_INET)) != NULL) + snprintf (display, sizeof(display),"%.400s:%d.%d", + he->h_name, display_number, screen_number); + else + #endif + snprintf(display, sizeof(display), "%.50s:%d.%d", + inet_ntoa(me.sin_addr), display_number, screen_number); + } + #endif + /* Allocate a channel for each socket. */ for (n = 0; n < num_socks; n++) { sock = socks[n]; *** session.c.orig Sun Feb 18 20:13:34 2001 --- session.c Wed Feb 21 11:39:06 2001 *************** *** 1361,1366 **** --- 1361,1369 ---- "Running %.100s add %.100s %.100s %.100s\n", options.xauth_location, display, auth_proto, auth_data); + #if 0 + /* it's redundant! really! sshd *never* listens for X11 on a UNIX socket. + * */ #ifndef HAVE_CYGWIN /* Unix sockets are not supported */ if (screen != NULL) fprintf(stderr, *************** *** 1368,1373 **** --- 1371,1377 ---- (int)(screen-display), display, screen, auth_proto, auth_data); #endif + #endif } snprintf(cmd, sizeof cmd, "%s -q -", options.xauth_location); *************** *** 1375,1380 **** --- 1379,1387 ---- if (f) { fprintf(f, "add %s %s %s\n", display, auth_proto, auth_data); + #if 0 + /* it's redundant! really! sshd *never* listens for X11 on a UNIX socket. + * */ #ifndef HAVE_CYGWIN /* Unix sockets are not supported */ if (screen != NULL) fprintf(f, "add %.*s/unix%s %s %s\n", *************** *** 1381,1386 **** --- 1388,1394 ---- (int)(screen-display), display, screen, auth_proto, auth_data); #endif + #endif pclose(f); } else { fprintf(stderr, "Could not run %s\n", From Markus.Friedl at informatik.uni-erlangen.de Thu Feb 22 02:08:27 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 21 Feb 2001 16:08:27 +0100 Subject: sftp-server and chown In-Reply-To: <3A93D29E.7FFDDAE9@fy.chalmers.se>; from appro@fy.chalmers.se on Wed, Feb 21, 2001 at 03:37:18PM +0100 References: <3A93D29E.7FFDDAE9@fy.chalmers.se> Message-ID: <20010221160827.B7296@faui02.informatik.uni-erlangen.de> On Wed, Feb 21, 2001 at 03:37:18PM +0100, Andy Polyakov wrote: > I've already discussed this issue in SSHSCI's SSH 2.2 context on > ssh at clinet.fi list. My standpoint is that it's wrong and meaningless > to perform chown in sftp-server as the file is most likely copied > between systems with distinct accounting system where user is not > necessarily (and even unlikely) has same numeric user id. If the sftp-client sends a request for CHOWN, why should I ignore it? sftp-server is running with the uid/privileges of the user, so why care? and if the client does not send CHOWN, i don't call chown(). > In addition > I think it's also irresponsible to blindly chmod files as different > systems might have different access policies (e.g. different umasks). > Therefore following patch (relative to OpenSSH 2.5.1p1) is suggested. The sftp-server runs under the uid of the user, and the enviroment is setup by executing the login shell, so umask is set. perhaps am i missing the point... -markus From Markus.Friedl at informatik.uni-erlangen.de Thu Feb 22 02:13:28 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 21 Feb 2001 16:13:28 +0100 Subject: X11 display issues In-Reply-To: <3A93D8B6.84CFC7AC@fy.chalmers.se>; from appro@fy.chalmers.se on Wed, Feb 21, 2001 at 04:03:18PM +0100 References: <3A93D8B6.84CFC7AC@fy.chalmers.se> Message-ID: <20010221161328.C7296@faui02.informatik.uni-erlangen.de> On Wed, Feb 21, 2001 at 04:03:18PM +0100, Andy Polyakov wrote: > This also has been discussed in SSHSCI's SSH context. All SSH versions > (both SSHSCI and OpenSSH) derive value for DISPLAY variable from > `uname -n`. The problem is that the returned value is not necessarily > resolvable to a valid IP number which in turn might cause a failure. oh yes, this is a problem. i will probably change the sshd-X11-proxy from internet to unix domain sockets. libX is broken if i set DISPLAY=localhost:x.y and ignore any X cookies. > To make it fool-proof I suggest to set DISPLAY to the interface's > address the user has reached the system in question through. I tried this before, but it does not work since it uses AF_INET6 if i connect by $ ssh -X ::1 so it's not really acceptible. I'm still looking for a better solution... -markus From pekkas at netcore.fi Thu Feb 22 02:21:08 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 21 Feb 2001 17:21:08 +0200 (EET) Subject: sshd -t to test configuration file syntax? Message-ID: Hello all, sshd configuration file options change from one release to another. If you forget updating sshd_config, sshd will not start. This is especially painful for update scripts etc. where you can't do e.g. 'sshd -p 2022' to see if it's okay. May I suggest some option, e.g. sshd -t, which would test config files and other obvious issues and return an errorcode if something is broken? Does this seem useful? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From Markus.Friedl at informatik.uni-erlangen.de Thu Feb 22 02:27:31 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 21 Feb 2001 16:27:31 +0100 Subject: sshd -t to test configuration file syntax? In-Reply-To: ; from pekkas@netcore.fi on Wed, Feb 21, 2001 at 05:21:08PM +0200 References: Message-ID: <20010221162731.E7296@faui02.informatik.uni-erlangen.de> sounds useful. all you need is exit(0); after the /* Check certain values for sanity. */ if (options.protocol & SSH_PROTO_1) { if (options.server_key_bits < 512 || options.server_key_bits > 32768) { fprintf(stderr, "Bad server key size.\n"); exit(1); ... } in sshd.c On Wed, Feb 21, 2001 at 05:21:08PM +0200, Pekka Savola wrote: > Hello all, > > sshd configuration file options change from one release to another. > > If you forget updating sshd_config, sshd will not start. > > This is especially painful for update scripts etc. where you can't do e.g. > 'sshd -p 2022' to see if it's okay. > > May I suggest some option, e.g. sshd -t, which would test config files and > other obvious issues and return an errorcode if something is broken? > > Does this seem useful? > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > From Markus.Friedl at informatik.uni-erlangen.de Thu Feb 22 02:34:17 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 21 Feb 2001 16:34:17 +0100 (MET) Subject: Q: core dumped on keygen in Sol 2.6, ssh2.3.0p1, openssl-0.9.6 and zlib-1.1.3 Message-ID: <200102211534.QAA19685@faui02l.informatik.uni-erlangen.de> FYI >Path: news.uni-erlangen.de!uni-erlangen.de!newsfeeds.belnet.be!news.belnet.be!news.tele.dk!130.133.1.3!fu-berlin.de!server1.netnews.ja.net!news.gla.ac.uk!not-for-mail >From: Will Partain >Newsgroups: comp.security.ssh >Subject: Re: Q: core dumped on keygen in Sol 2.6, ssh2.3.0p1, openssl-0.9.6 and zlib-1.1.3 >Date: 21 Feb 2001 12:27:24 +0000 >Organization: University of Glasgow >Lines: 52 >Message-ID: >References: <9578vs$npb$1 at nnrp1.deja.com> >NNTP-Posting-Host: slicker.dcs.gla.ac.uk >Mime-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >X-Trace: singer.cent.gla.ac.uk 982758493 8576 130.209.242.51 (21 Feb 2001 12:28:13 GMT) >X-Complaints-To: newsmaster at gla.ac.uk >NNTP-Posting-Date: 21 Feb 2001 12:28:13 GMT >User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) >Xref: news.uni-erlangen.de comp.security.ssh:19258 I, too, am seeing these symptoms (and I don't think it's just the two of us :-). I can further confirm that I see the same with 2.2.0p1 and 2.5.1p1. Other facts: gcc-2.95.2, solaris2.6 reasonably well patched, sun linker, openssl stuff being linked statically (from a .a file). No difference if openssl is compiled with -O, instead of -O3 -fomit-frame-pointer. openssh is being compiled with -O2 -fstrict-aliasing. In the case I've investigated with gdb, ssh-keygen dies the first time it gets to RC4_set_key (openssl), called from arc4random_stir. It dies trying to write into the memory of "static RC4_KEY rc4;" (openbsd-compat/bsd-arc4random.c). If, just for sport, I *initialize* rc4 [with zeros] (i.e. it ends up in the data section, not bss), then we sail past this problem [but it dies a bit later in some rsa code]. Do these further details spark any thoughts? (I suspect something in the compiler-linker chain...) Will Philip J. Bondi writes: > Everything configures, configs, make, make test make install, but at > the end of the "make install" for openssh, I get the following and > keygen dumps core. Any hints? > > 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 ; > *** Error code 138 > make: Fatal error: Command failed for target `host-key' From appro at fy.chalmers.se Thu Feb 22 02:39:58 2001 From: appro at fy.chalmers.se (Andy Polyakov) Date: Wed, 21 Feb 2001 16:39:58 +0100 Subject: sftp-server and chown References: <3A93D29E.7FFDDAE9@fy.chalmers.se> <20010221160827.B7296@faui02.informatik.uni-erlangen.de> Message-ID: <3A93E14E.500BA6C2@fy.chalmers.se> > > I've already discussed this issue in SSHSCI's SSH 2.2 context on > > ssh at clinet.fi list. My standpoint is that it's wrong and meaningless > > to perform chown in sftp-server as the file is most likely copied > > between systems with distinct accounting system where user is not > > necessarily (and even unlikely) has same numeric user id. > > If the sftp-client sends a request for CHOWN, why should I > ignore it? Because chown doesn't belong in file transer protocol and sftp should not be an exclusion. As I said, numerical ids are very likely different and chown is simply meaningless. Yes, they've specified it in protocol. So what? They wanted to have the option opened, but it doesn't autiomatically qualify it for implementation. > sftp-server is running with the uid/privileges of the user, so why > care? As I already said, some systems *permit* chown to another uid even for non-priviledged users (and most systems can be configured by changing a kernel parameter to permit this operation and some do configure it so) and this is one-way operation, i.e. once I did 'chown markus file' I can't chown it back to myself. > > In addition > > I think it's also irresponsible to blindly chmod files as different > > systems might have different access policies (e.g. different umasks). > > Therefore following patch (relative to OpenSSH 2.5.1p1) is suggested. > > The sftp-server runs under the uid of the user, and the enviroment is > setup by executing the login shell, so umask is set. But umask doesn't prevent you from explicit chmod, does it? And that's what happens, client asks for explicit chmod and umask is ineffective then. Also note that explicit chmod can break file access/creation policy controlled by ACLs... To tell you the truth I don't believe absolute chmod belongs in file transfer protocol either. One should probably limit it to incremental +x only (i.e. if you ask me:-). Andy. From Markus.Friedl at informatik.uni-erlangen.de Thu Feb 22 02:48:03 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 21 Feb 2001 16:48:03 +0100 Subject: sftp-server and chown In-Reply-To: <3A93E14E.500BA6C2@fy.chalmers.se>; from appro@fy.chalmers.se on Wed, Feb 21, 2001 at 04:39:58PM +0100 References: <3A93D29E.7FFDDAE9@fy.chalmers.se> <20010221160827.B7296@faui02.informatik.uni-erlangen.de> <3A93E14E.500BA6C2@fy.chalmers.se> Message-ID: <20010221164803.A24810@faui02.informatik.uni-erlangen.de> On Wed, Feb 21, 2001 at 04:39:58PM +0100, Andy Polyakov wrote: > > If the sftp-client sends a request for CHOWN, why should I > > ignore it? > > Because chown doesn't belong in file transer protocol and sftp should > not be an exclusion. As I said, numerical ids are very likely different > and chown is simply meaningless. Yes, they've specified it in protocol. > So what? They wanted to have the option opened, but it doesn't > autiomatically qualify it for implementation. i still don't see why i should CHOWN request, just because you don't like the idea of 'chown'? > > sftp-server is running with the uid/privileges of the user, so why > > care? > > As I already said, some systems *permit* chown to another uid even for > non-priviledged users (and most systems can be configured by changing a > kernel parameter to permit this operation and some do configure it so) > and this is one-way operation, i.e. once I did 'chown markus file' I > can't chown it back to myself. well, so why should i ignore chown if it's legal on some systems? > > > In addition > > > I think it's also irresponsible to blindly chmod files as different > > > systems might have different access policies (e.g. different umasks). > > > Therefore following patch (relative to OpenSSH 2.5.1p1) is suggested. > > > > The sftp-server runs under the uid of the user, and the enviroment is > > setup by executing the login shell, so umask is set. > > But umask doesn't prevent you from explicit chmod, does it? no, but if a client want to do chmod() why should i deny the request? it's 'his' file. > And that's > what happens, client asks for explicit chmod and umask is ineffective > then. Also note that explicit chmod can break file access/creation > policy controlled by ACLs... To tell you the truth I don't believe > absolute chmod belongs in file transfer protocol either. One should > probably limit it to incremental +x only (i.e. if you ask me:-). i think you should post you concerns about chown and chmod to the ietf-ssh at clinet.fi list. -m From jc at np.ph.bham.ac.uk Thu Feb 22 02:51:56 2001 From: jc at np.ph.bham.ac.uk (James Campbell) Date: Wed, 21 Feb 2001 15:51:56 GMT Subject: openssh-2.5.1p1 etc Message-ID: <200102211551.PAA07340@nps.ph.bham.ac.uk> Hi, Is there an easy way to "fix" the man pages to work with Solaris. Solaris uses the "an" ie /usr/share/lib/tmac/an nroff macros and I guess openbsd doesnt!! cheers Jim From mouring at etoh.eviladmin.org Thu Feb 22 03:48:45 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 21 Feb 2001 10:48:45 -0600 (CST) Subject: openssh-2.5.1p1 etc In-Reply-To: <200102211551.PAA07340@nps.ph.bham.ac.uk> Message-ID: There is a perl script presented that does this. It will find it's way into OpenSSH portable soon. If you look back throught the list you can find it. - Ben On Wed, 21 Feb 2001, James Campbell wrote: > Hi, > Is there an easy way to "fix" the man pages to work with Solaris. > Solaris uses the "an" ie /usr/share/lib/tmac/an nroff macros and I guess > openbsd doesnt!! > cheers > Jim > From pekkas at netcore.fi Thu Feb 22 03:14:14 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 21 Feb 2001 18:14:14 +0200 (EET) Subject: OpenSSL + OpenSSH version problems [patch] In-Reply-To: Message-ID: On Wed, 21 Feb 2001, Pekka Savola wrote: > OpenSSL 0.9.5a and 0.9.6 are incompatible, causing weird errors. > I'd like to get a check for this in the RPMs. > > However, now I want to make sure whether anyone has experienced problems > with RHL 0.9.5a OpenSSL libs vs. the 0.9.5a ones provided at openbsd.org? > > Ie: is it enough to check like '= 0.9.5a' or do you have to check '= > 0.9.5a-xyz'. No feedback yet, so.. Attached is a patch for the spec file to Require the same version of OpenSSL (0.9.5a vs. 0.9.6) as OpenSSH was compiled against. If 'cut' were to be tailed, this could also be tailored to require _exactly_ the same version, but this might be a pain (and I'd first like to know of cases where this isn't enough..) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------- next part -------------- --- /home/pekkas/openssh_cvs/contrib/redhat/openssh.spec Mon Feb 19 19:06:30 2001 +++ openssh.spec Wed Feb 21 17:58:00 2001 @@ -22,6 +22,8 @@ # rpm -ba|--rebuild --define "rh7 1" %{?rh7:%define redhat7 1} +%define exact_openssl_version %(rpm -q openssl | cut -d - -f 2) + Summary: OpenSSH free Secure Shell (SSH) implementation Name: openssh Version: %{oversion} @@ -37,6 +39,7 @@ BuildRoot: /tmp/openssh-%{version}-buildroot Obsoletes: ssh PreReq: openssl >= 0.9.5a +RreReq: openssl = %{exact_openssl_version} Requires: openssl >= 0.9.5a Requires: rpm >= 3.0.5 BuildPreReq: perl, openssl-devel, tcp_wrappers From celinn at mtu.edu Thu Feb 22 03:20:59 2001 From: celinn at mtu.edu (Christopher Linn) Date: Wed, 21 Feb 2001 11:20:59 -0500 Subject: openssh-2.5.1p1 etc In-Reply-To: ; from mouring@etoh.eviladmin.org on Wed, Feb 21, 2001 at 10:48:45AM -0600 References: <200102211551.PAA07340@nps.ph.bham.ac.uk> Message-ID: <20010221112059.C4019@mtu.edu> i have had no problems with 2.5.1p1 on solaris 8 when i use the "--with-catman=cat" configure option... what am i missing here in this discussion? chris On Wed, Feb 21, 2001 at 10:48:45AM -0600, mouring at etoh.eviladmin.org wrote: > > > There is a perl script presented that does this. It will find it's way > into OpenSSH portable soon. > > If you look back throught the list you can find it. > > - Ben > > On Wed, 21 Feb 2001, James Campbell wrote: > > > Hi, > > Is there an easy way to "fix" the man pages to work with Solaris. > > Solaris uses the "an" ie /usr/share/lib/tmac/an nroff macros and I guess > > openbsd doesnt!! > > cheers > > Jim > > > -- Christopher Linn, | By no means shall either the CEC Staff System Administrator | or MTU be held in any way liable Center for Experimental Computation | for any opinions or conjecture I Michigan Technological University | hold to or imply to hold herein. From jones at hpc.utexas.edu Thu Feb 22 03:35:21 2001 From: jones at hpc.utexas.edu (William L. Jones) Date: Wed, 21 Feb 2001 10:35:21 -0600 Subject: X11 display issues In-Reply-To: <20010221161328.C7296@faui02.informatik.uni-erlangen.de> References: <3A93D8B6.84CFC7AC@fy.chalmers.se> <3A93D8B6.84CFC7AC@fy.chalmers.se> Message-ID: <4.2.0.58.20010221103229.01d44660@127.0.0.1> Keep the Internet domain sockets at least for a few systems. Cray UNICOS X11 does not support unix domain sockets. Do both but configure unix domain sockets by default at let porters add a define to do Internet domain sockets instead of unix domain sockets. Bill Jones At 04:13 PM 2/21/01 +0100, Markus Friedl wrote: >On Wed, Feb 21, 2001 at 04:03:18PM +0100, Andy Polyakov wrote: > > This also has been discussed in SSHSCI's SSH context. All SSH versions > > (both SSHSCI and OpenSSH) derive value for DISPLAY variable from > > `uname -n`. The problem is that the returned value is not necessarily > > resolvable to a valid IP number which in turn might cause a failure. > >oh yes, this is a problem. i will probably change the sshd-X11-proxy >from internet to unix domain sockets. > >libX is broken if i set DISPLAY=localhost:x.y and ignore any >X cookies. > > > To make it fool-proof I suggest to set DISPLAY to the interface's > > address the user has reached the system in question through. > >I tried this before, but it does not work since it uses AF_INET6 if >i connect by > $ ssh -X ::1 > >so it's not really acceptible. I'm still looking for a better >solution... > >-markus From stevesk at sweden.hp.com Thu Feb 22 03:54:19 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Wed, 21 Feb 2001 17:54:19 +0100 (MET) Subject: Solaris and Latest snapshot (2001-02-21) In-Reply-To: Message-ID: On Tue, 20 Feb 2001 mouring at etoh.eviladmin.org wrote: : There is only two sets of pam patches around that date. One is a : suggestion to clean up PAM space. Which I can't see any fault. And this : one which stated it was for solaris. Can you apply this reverse and see : if this gets us closer to fixing this? Or if the problem still exists? hp-ux broke with that. i just commited the following, which takes us back to before the first pam change: - (stevesk) session.c: back out to where we were before: - (djm) Move PAM session initialisation until after fork in sshd. Patch from Nalin Dahyabhai i have done rudimentary testing on hp-ux and redhat. can solaris users test this? we can troubleshoot after p2. Index: session.c =================================================================== RCS file: /var/cvs/openssh/session.c,v retrieving revision 1.80 diff -u -r1.80 session.c --- session.c 2001/02/21 05:53:33 1.80 +++ session.c 2001/02/21 16:28:40 @@ -481,6 +481,10 @@ session_proctitle(s); +#ifdef USE_PAM + do_pam_setcred(); +#endif /* USE_PAM */ + /* Fork the child. */ if ((pid = fork()) == 0) { /* Child. Reinitialize the log since the pid has changed. */ @@ -593,6 +597,11 @@ ptyfd = s->ptyfd; ttyfd = s->ttyfd; +#ifdef USE_PAM + do_pam_session(pw->pw_name, s->tty); + do_pam_setcred(); +#endif /* USE_PAM */ + /* Fork the child. */ if ((pid = fork()) == 0) { /* Child. Reinitialize the log because the pid has changed. */ @@ -1142,11 +1151,6 @@ #ifdef HAVE_LOGIN_CAP shell = login_getcapstr(lc, "shell", (char *)shell, (char *)shell); #endif - -#ifdef USE_PAM - do_pam_session(pw->pw_name, ttyname); - do_pam_setcred(); -#endif /* USE_PAM */ #ifdef AFS /* Try to get AFS tokens for the local cell. */ From pekkas at netcore.fi Thu Feb 22 04:11:26 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 21 Feb 2001 19:11:26 +0200 (EET) Subject: sshd -t to test configuration file syntax? In-Reply-To: <20010221162731.E7296@faui02.informatik.uni-erlangen.de> Message-ID: On Wed, 21 Feb 2001, Markus Friedl wrote: Patch attached. Pretty important, especially now as a lot of options changed. I hope this looks good -- I'd like this kind of functionality to be in 2.5.1p2. > sounds useful. > > all you need is exit(0); > after the > > /* Check certain values for sanity. */ > if (options.protocol & SSH_PROTO_1) { > if (options.server_key_bits < 512 || > options.server_key_bits > 32768) { > fprintf(stderr, "Bad server key size.\n"); > exit(1); > ... > } > > in sshd.c > > > On Wed, Feb 21, 2001 at 05:21:08PM +0200, Pekka Savola wrote: > > Hello all, > > > > sshd configuration file options change from one release to another. > > > > If you forget updating sshd_config, sshd will not start. > > > > This is especially painful for update scripts etc. where you can't do e.g. > > 'sshd -p 2022' to see if it's okay. > > > > May I suggest some option, e.g. sshd -t, which would test config files and > > other obvious issues and return an errorcode if something is broken? > > > > Does this seem useful? > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------- next part -------------- diff -uNr openssh_cvs/sshd.8 openssh_cvs.test/sshd.8 --- openssh_cvs/sshd.8 Thu Feb 15 15:07:48 2001 +++ openssh_cvs.test/sshd.8 Wed Feb 21 18:57:42 2001 @@ -43,7 +43,7 @@ .Nd secure shell daemon .Sh SYNOPSIS .Nm sshd -.Op Fl diqD46 +.Op Fl diqtD46 .Op Fl b Ar bits .Op Fl f Ar config_file .Op Fl g Ar login_grace_time @@ -240,6 +240,12 @@ Nothing is sent to the system log. Normally the beginning, authentication, and termination of each connection is logged. +.It Fl t +Test mode. +Only check the validity of the configuration file and sanity of the keys. +This is useful for updating +.Nm sshd +reliably as configuration options may change. .It Fl u Ar len This option is used to specify the size of the field in the diff -uNr openssh_cvs/sshd.c openssh_cvs.test/sshd.c --- openssh_cvs/sshd.c Tue Feb 20 14:46:54 2001 +++ openssh_cvs.test/sshd.c Wed Feb 21 18:57:17 2001 @@ -112,6 +112,9 @@ */ int debug_flag = 0; +/* Flag indicating that the daemon should only test the configuration and keys. */ +int test_flag = 0; + /* Flag indicating that the daemon is being started from inetd. */ int inetd_flag = 0; @@ -577,7 +580,7 @@ initialize_server_options(&options); /* Parse command-line arguments. */ - while ((opt = getopt(ac, av, "f:p:b:k:h:g:V:u:dDiqQ46")) != -1) { + while ((opt = getopt(ac, av, "f:p:b:k:h:g:V:u:dDiqtQ46")) != -1) { switch (opt) { case '4': IPv4or6 = AF_INET; @@ -640,6 +643,9 @@ /* only makes sense with inetd_flag, i.e. no listen() */ inetd_flag = 1; break; + case 't': + test_flag = 1; + break; case 'u': utmp_len = atoi(optarg); break; @@ -652,6 +658,7 @@ fprintf(stderr, " -d Debugging mode (multiple -d means more debugging)\n"); fprintf(stderr, " -i Started from inetd\n"); fprintf(stderr, " -D Do not fork into daemon mode\n"); + fprintf(stderr, " -t Only test configuration file and keys\n"); fprintf(stderr, " -q Quiet (no logging)\n"); fprintf(stderr, " -p port Listen on the specified port (default: 22)\n"); fprintf(stderr, " -k seconds Regenerate server key every this many seconds (default: 3600)\n"); @@ -737,6 +744,10 @@ fprintf(stderr, "Bad server key size.\n"); exit(1); } + /* Configuration looks good, so exit if in test mode. */ + if (test_flag) + exit(0); + /* * Check that server and host key lengths differ sufficiently. This * is necessary to make double encryption work with rsaref. Oh, I From vader at conflict.net Thu Feb 22 04:12:01 2001 From: vader at conflict.net (Jim Breton) Date: Wed, 21 Feb 2001 17:12:01 +0000 Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) box In-Reply-To: ; from pekkas@netcore.fi on Tue, Feb 20, 2001 at 12:25:02AM +0200 References: <20010219221503.26739.qmail@conflict.net> Message-ID: <20010221171201.13503.qmail@conflict.net> OK I am running into another problem now as well (see the earlier posts to this thread so see some of the systems involved). In addition to the aforementioned issues, I also cannot do this: ssh hostname "cat > filename" < filename which is what I had been using as a work-around to the broken scp in OpenSSH-2.3.0. This now also seems broken in 2.5.1 in some cases. In addition to the RH/Debian systems involved in my first post, I have this problem going from my Debian potato machine to a Debian potato machine (owned by someone else, on a remote network, running OpenSSL 0.9.6 compiled from source). Testing locally on my lan does not seem to be an issue, so I began to wonder whether it involved compression (I enable it by default, but disable it when connecting to machines on my lan). However I just tried it with and without compression on the lan, as well as remotely, and it didn't seem to make any difference. I have a question if someone doesn't mind answering: does scp do exactly the same thing as piping a file over ssh's stdin would do? In other words, is it just a front-end to setting up stdin/stdout on an ssh process? Hate to sound like an idiot luser and wish I could provide something more useful than "it works in scenario X but not in scenario Y" but it just doesn't make any sense to me either. -- Jim B. vader at conflict.net From vinschen at redhat.com Thu Feb 22 04:21:55 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 21 Feb 2001 18:21:55 +0100 Subject: X11 display issues In-Reply-To: <4.2.0.58.20010221103229.01d44660@127.0.0.1>; from jones@hpc.utexas.edu on Wed, Feb 21, 2001 at 10:35:21AM -0600 References: <3A93D8B6.84CFC7AC@fy.chalmers.se> <3A93D8B6.84CFC7AC@fy.chalmers.se> <20010221161328.C7296@faui02.informatik.uni-erlangen.de> <4.2.0.58.20010221103229.01d44660@127.0.0.1> Message-ID: <20010221182155.S908@cygbert.vinschen.de> On Wed, Feb 21, 2001 at 10:35:21AM -0600, William L. Jones wrote: > Keep the Internet domain sockets at least for a few systems. Cray > UNICOS X11 does not support unix domain sockets. Yep, same for Cygwin. Should be a configurable option. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From pekkas at netcore.fi Thu Feb 22 04:25:44 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 21 Feb 2001 19:25:44 +0200 (EET) Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) box In-Reply-To: <20010221171201.13503.qmail@conflict.net> Message-ID: On Wed, 21 Feb 2001, Jim Breton wrote: > OK I am running into another problem now as well (see the earlier posts > to this thread so see some of the systems involved). > > In addition to the aforementioned issues, I also cannot do this: > > ssh hostname "cat > filename" < filename > > which is what I had been using as a work-around to the broken scp in > OpenSSH-2.3.0. This now also seems broken in 2.5.1 in some cases. Might this be related to this (from TODO): --- - Linux hangs for 20 seconds when you do "sleep 20&exit". All current solutions break scp or leaves processes hanging around after the ssh connection has ended. It seems to be linked to two things. One select() under Linux is not as nice as others, and two the children of the shell are not killed on exiting the shell. --- If so, scp should work now. This was changed after 2.3.0p1 was released. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From pekkas at netcore.fi Thu Feb 22 04:38:23 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 21 Feb 2001 19:38:23 +0200 (EET) Subject: openssh-2.5.1p1 problem on redhat 6.2 [patch] In-Reply-To: <20010220220441.A1446@box.lyang.net> Message-ID: On Tue, 20 Feb 2001, John XING wrote: Perhaps it'd be best to add a Require: if you install RHL7 pam file. system-auth comes in the same package as pam_stack. As a bonus, a minor adjustment on buildroot. Not tested. --- openssh.spec~ Mon Feb 19 19:06:30 2001 +++ openssh.spec Wed Feb 21 19:34:29 2001 @@ -34,7 +34,7 @@ %endif Copyright: BSD Group: Applications/Internet -BuildRoot: /tmp/openssh-%{version}-buildroot +BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot Obsoletes: ssh PreReq: openssl >= 0.9.5a Requires: openssl >= 0.9.5a @@ -58,6 +58,9 @@ Obsoletes: ssh-server PreReq: openssh = %{version}-%{release}, chkconfig >= 0.9 Requires: initscripts >= 4.16 +%if %{redhat7} +Requires: /etc/pam.d/system-auth +%endif %package askpass Summary: OpenSSH X11 passphrase dialog > I built rpm from openssh-2.5.1p1 srpm on redhat 6.2, > then installed it. When trying to ssh from other machine, > sshd gives error: > > ..... > Feb 20 17:54:24 foo PAM_pwdb[925]: (login) session opened for user doe by LOGIN(uid=0) > Feb 20 17:55:15 foo sshd[1342]: Connection closed by 192.168.0.3 > Feb 20 17:55:43 foo sshd[1343]: PAM unable to dlopen(/lib/security/pam_stack.so) > Feb 20 17:55:43 foo sshd[1343]: PAM [dlerror: /lib/security/pam_stack.so: cannot open shared object file: No such file or directory] > Feb 20 17:55:43 foo sshd[1343]: PAM adding faulty module: /lib/security/pam_stack.so > Feb 20 17:55:46 foo sshd[1343]: Failed password for doe from 192.168.0.3 port 1121 > Feb 20 17:56:01 foo sshd[1343]: Failed password for doe from 192.168.0.3 port 1121 > ..... > > Seems linked to wrong lib? Any suggestions? > > Thanks, > > John > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From vader at conflict.net Thu Feb 22 04:41:50 2001 From: vader at conflict.net (Jim Breton) Date: Wed, 21 Feb 2001 17:41:50 +0000 Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) box In-Reply-To: ; from pekkas@netcore.fi on Wed, Feb 21, 2001 at 07:25:44PM +0200 References: <20010221171201.13503.qmail@conflict.net> Message-ID: <20010221174151.13601.qmail@conflict.net> On Wed, Feb 21, 2001 at 07:25:44PM +0200, Pekka Savola wrote: > Might this be related to this (from TODO): > > --- > - Linux hangs for 20 seconds when you do "sleep 20&exit". All current > solutions break scp or leaves processes hanging around after the ssh > connection has ended. It seems to be linked to two things. One > select() under Linux is not as nice as others, and two the children > of the shell are not killed on exiting the shell. > --- Well it could be, I had seen that but didn't think it was related because a) it happens with any command (I foolishly thought that may have been related _only_ to sleep :P ); b) it works on some of the systems I am testing which are all running the exact same version of OpenSSH (2.5.1); c) the hang lasts a lot longer than 20 seconds (I waited for 10 mins in one case, and it still hadn't exited). > If so, scp should work now. > > This was changed after 2.3.0p1 was released. But I am using 2.5.1p1. Was that a typo, or is there a patch available for the 2.5.1p1 release? Thanks again. -- Jim B. vader at conflict.net From pekkas at netcore.fi Thu Feb 22 04:51:25 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 21 Feb 2001 19:51:25 +0200 (EET) Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) box In-Reply-To: <20010221174151.13601.qmail@conflict.net> Message-ID: On Wed, 21 Feb 2001, Jim Breton wrote: > On Wed, Feb 21, 2001 at 07:25:44PM +0200, Pekka Savola wrote: > > Might this be related to this (from TODO): > > > > --- > > - Linux hangs for 20 seconds when you do "sleep 20&exit". All current > > solutions break scp or leaves processes hanging around after the ssh > > connection has ended. It seems to be linked to two things. One > > select() under Linux is not as nice as others, and two the children > > of the shell are not killed on exiting the shell. > > --- > > Well it could be, I had seen that but didn't think it was related > because a) it happens with any command (I foolishly thought that may > have been related _only_ to sleep :P ); b) it works on some of the > systems I am testing which are all running the exact same version of > OpenSSH (2.5.1); c) the hang lasts a lot longer than 20 seconds (I > waited for 10 mins in one case, and it still hadn't exited). a) the hanging connections can happen with any command, try e.g. /sbin/service httpd restart (on RHL) b) the problem exists on 2.2.0pX (or the like) and 2.5.x (also post 2.3.0 snapshots). c) the hang time is dependent on your sleep value, or how long it takes for the process to die. Try adding shopt -s huponexit in your bash initialization. That should work around the problem for now. > > If so, scp should work now. > > > > This was changed after 2.3.0p1 was released. > > But I am using 2.5.1p1. Was that a typo, or is there a patch available > for the 2.5.1p1 release? scp should work now. Connections may hang now. There is no patch yet. Ideas how this could be fixed are welcome, I'm certain :-/. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From mouring at etoh.eviladmin.org Thu Feb 22 05:48:25 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 21 Feb 2001 12:48:25 -0600 (CST) Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) box In-Reply-To: <20010221171201.13503.qmail@conflict.net> Message-ID: On Wed, 21 Feb 2001, Jim Breton wrote: > OK I am running into another problem now as well (see the earlier posts > to this thread so see some of the systems involved). > > In addition to the aforementioned issues, I also cannot do this: > > ssh hostname "cat > filename" < filename I can't replicate this on Redhat 7.0. What is the actual error message? (if any) and a ssh -v -v -v may help also. > > which is what I had been using as a work-around to the broken scp in > OpenSSH-2.3.0. This now also seems broken in 2.5.1 in some cases. > Which? scp? or the above cat? scp should work fine since we reverted out of an attempt to fix a Linux select() issue. > In addition to the RH/Debian systems involved in my first post, I have > this problem going from my Debian potato machine to a Debian potato > machine (owned by someone else, on a remote network, running OpenSSL > 0.9.6 compiled from source). Testing locally on my lan does not seem to > be an issue, so I began to wonder whether it involved compression (I > enable it by default, but disable it when connecting to machines on my > lan). However I just tried it with and without compression on the lan, > as well as remotely, and it didn't seem to make any difference. > > I have a question if someone doesn't mind answering: does scp do exactly > the same thing as piping a file over ssh's stdin would do? In other > words, is it just a front-end to setting up stdin/stdout on an ssh > process? > They should (in theory) be roughtly the same. > Hate to sound like an idiot luser and wish I could provide something > more useful than "it works in scenario X but not in scenario Y" but it > just doesn't make any sense to me either. > > scp -v -v -v or ssh -v -v -v are useful for seeing what occurs. We need more information. As stated before there is a linux bug on select() with no current patch (but there is a work around.. I'd have to look it up since it did not make it into the FAQ.) But the work around is: While browsing through bash's hugh manpage, I noticed that it has a 'huponexit' option which will send SIGHUP to all interactive processes when the shell exits. I have tested this and it does resolve the hanging at logout without causing race conditions. I now have a "shopt -s huponexit" in my /etc/bashrc and it works beautifully. (Who do I submit this to so it gets into the FAQ on the openssh.com site? This problem is going to be around for a while. =) thanks - Ben From garrick at james.net Thu Feb 22 05:05:41 2001 From: garrick at james.net (Garrick James) Date: Wed, 21 Feb 2001 10:05:41 -0800 Subject: OpenSSH 2.5.1p1 on HP-UX: No CTRL+C possible!!! In-Reply-To: <3A936F57.6952C208@skerka.de>; from randolf@skerka.de on Wed, Feb 21, 2001 at 08:33:43AM +0100 References: <3A936F57.6952C208@skerka.de> Message-ID: <20010221100541.A978@nebula.dsl.speakeasy.net> I can't help but notice this sounds just like the problem I have on my Solaris 2.6 boxen. If you search the list archives from several months ago, you can find the work around I posted. Basicly it all boiled down to the state of CTRL-C at the time sshd was launched. Go to the console of the machine in question (if you can), stop sshd and start sshd _INTERACTIVELY_ (do not use a cron job, at job, or anything else that is not interactive). Then ssh into the box and see if the CTRL-C works. If it does, you have the same problem we have on Solaris 2.6. Sshd seems to remeber the state of CTRL-C funcitonality at the time of startup and propigates that to all ssh sessions (even though stty reports otherwise). Stopping sshd and starting it from an at job or cron job when upgrading will give you a daemon that has no CTRL-C functionality (interupt key does not exist in the non-interactive shells of at and cron). -Garrick On Wed, 21 Feb 2001, Randolf Skerka wrote: > > I've compiled 2.5.1p1 on > > HP-UX mdv010 B.11.00 A 9000/887 457369232 two-user license > > with --prefix=/usr --sysconfdir=/etc/ssh \ > --with-ssl-dir=$MYPWD/openssl-0.9.6 \ > --with-pid-dir=/etc/ssh \ > --with-default-path=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin > --with-entropy-timeout=250 > > Nothin special I think, works fine with 2.3.0p1. > > Well, when I try to stop a process using CTRL+C (CTRL+Z does not work > too) nothing happens. > > > Is it a known problem? > > > Randolf > -- > +---------------------------------------------------------------------+ > | Randolf Skerka http://www.randolf.org | > +---------------------------------------------------------------------+ > > From appro at fy.chalmers.se Thu Feb 22 05:46:39 2001 From: appro at fy.chalmers.se (Andy Polyakov) Date: Wed, 21 Feb 2001 19:46:39 +0100 Subject: X11 display issues References: <3A93D8B6.84CFC7AC@fy.chalmers.se> <20010221161328.C7296@faui02.informatik.uni-erlangen.de> Message-ID: <3A940D0F.3919117F@fy.chalmers.se> > > This also has been discussed in SSHSCI's SSH context. All SSH versions > > (both SSHSCI and OpenSSH) derive value for DISPLAY variable from > > `uname -n`. The problem is that the returned value is not necessarily > > resolvable to a valid IP number which in turn might cause a failure. > > oh yes, this is a problem. i will probably change the sshd-X11-proxy > from internet to unix domain sockets. Say you run ssh against firewall in order to run X11 application on computer behind the firewall. UNIX socket would kill the idea... > libX is broken if i set DISPLAY=localhost:x.y and ignore any > X cookies. Note that I set it to anything *but* localhost:x.y (well, as long as you don't ssh localhost, but that would be confusing from key management viewpoint so that you don't normally do it). > > To make it fool-proof I suggest to set DISPLAY to the interface's > > address the user has reached the system in question through. > > I tried this before, but it does not work since it uses AF_INET6 if > i connect by > $ ssh -X ::1 Does libX11 talk IPv6 at all? Is libX11 capable to parse IPv6-style number in DISPLAY variable? Last time I've checked the answers were "no" for both... > so it's not really acceptible. I'm still looking for a better > solution... Yes, UNIX domain sockets would eliminate the IPv4/6 issue, but I'm afraid it would bring up more libX11-related problems than solutions. Take the "desire" to share memory whenever DISPLAY=:X.Y for example... It doesn't mean that we should give up the fight, but unfortunately for the time being libX11 is not really there for us and we simply have no hell of a choice but to stick to TCP (over IPv4) transport:-( What's possible to do is to replace gethostbyaddr with getnameinfo and check if it's AF_INET socket only if the latter fails so that it will become IPv6 "savvy". Something like following: /* and now something completely different:-) */ { struct sockaddr_storage me; socklen_t melen = sizeof(me); char h_name[NI_MAXHOST]; if (getsockname(packet_get_connection_in(), (struct sockaddr *)&me, &melen) != 0) { error("[X11-broken-fwd] Unable to getsockname"); packet_send_debug("[X11-broken-fwd] Unable to getsockname"); shutdown(sock, SHUT_RDWR); close(sock); return NULL; } #ifndef IPADDR_IN_DISPLAY if (getnameinfo ((void *)&me, melen, h_name,sizeof(h_name),NULL,0,NI_NAMEREQD) == 0) snprintf (display, sizeof(display),"%.*s:%d.%d", sizeof(h_name), h_name, display_number, screen_number); else #endif { if (me.ss_family != AF_INET) { error("[X11-broken-fwd] Unsupported protocol family"); packet_send_debug("[X11-broken-fwd] Unsupported protocol family"); shutdown(sock, SHUT_RDWR); close(sock); return NULL; } else snprintf(display, sizeof(display), "%.50s:%d.%d", inet_ntoa(((struct sockaddr_in *)&me)->sin_addr), display_number, screen_number); } } No, still not perfect... Andy. From appro at fy.chalmers.se Thu Feb 22 06:18:17 2001 From: appro at fy.chalmers.se (Andy Polyakov) Date: Wed, 21 Feb 2001 20:18:17 +0100 Subject: sftp-server and chown References: <3A93D29E.7FFDDAE9@fy.chalmers.se> <20010221160827.B7296@faui02.informatik.uni-erlangen.de> <3A93E14E.500BA6C2@fy.chalmers.se> <20010221164803.A24810@faui02.informatik.uni-erlangen.de> Message-ID: <3A941479.C304B2C6@fy.chalmers.se> > > > sftp-server is running with the uid/privileges of the user, so why > > > care? > > > > As I already said, some systems *permit* chown to another uid even for > > non-priviledged users (and most systems can be configured by changing a > > kernel parameter to permit this operation and some do configure it so) > > and this is one-way operation, i.e. once I did 'chown markus file' I > > can't chown it back to myself. > > well, so why should i ignore chown if it's legal on some > systems? Because it breaks things in a manner no normal user would expect it to break during a trivial file transfer. Here is system call trace for SSHCSI's SSH 2.2.x (Windows client and server): unlink("/my/dir/a.txt") = 0 open("/my/dir/a.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 fchmod(3, 0) = 0 fchown(3, 0, 0) = 0 fchmod(3, 0100666) Err#1 EPERM utime("/my/dir/a.txt", 0xEFFFF94C) Err#1 EPEPM fchmod(3, 0100666) Err#1 EPERM utime("/my/dir/a.txt", 0xEFFFF94C) Err#1 EPERM User gets ---------- file owned by root and the only thing [s]he can do is delete the damn thing. I realize that it might no be 100% applicable to OpenSSH (I didn't check if it does chmod(0) to mark "transfer-in-progress"), but the point is that when you transfer a file you expect to own it on the target system no matter what and therefore the idea of chown (in any file transer server) is inherently tainted. On the other hand even if you logged on with sftp as root, why whould you like to grant ownership to whomever on the target system who simply happened to have same numeric id as file owner on the source system? Andy. From vader at conflict.net Thu Feb 22 06:30:06 2001 From: vader at conflict.net (Jim Breton) Date: Wed, 21 Feb 2001 19:30:06 +0000 Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) box In-Reply-To: ; from mouring@etoh.eviladmin.org on Wed, Feb 21, 2001 at 12:48:25PM -0600 References: <20010221171201.13503.qmail@conflict.net> Message-ID: <20010221193006.13848.qmail@conflict.net> On Wed, Feb 21, 2001 at 12:48:25PM -0600, mouring at etoh.eviladmin.org wrote: > > In addition to the aforementioned issues, I also cannot do this: > > > > ssh hostname "cat > filename" < filename > > I can't replicate this on Redhat 7.0. What is the actual error > message? (if any) and a ssh -v -v -v may help also. There is no error message. ssh -v -v -v output will be at the end of my message. > > which is what I had been using as a work-around to the broken scp in > > OpenSSH-2.3.0. This now also seems broken in 2.5.1 in some cases. > > > Which? scp? or the above cat? Both. My first post was about scp which produces no useful output no matter how many -v args I use (which is why I didn't include it) but just today I found that stdin over ssh is also troublesome. > scp should work fine since we reverted out > of an attempt to fix a Linux select() issue. Not for me. :-\ Hopefully the output (below) will help. > > I have a question if someone doesn't mind answering: does scp do exactly > > the same thing as piping a file over ssh's stdin would do? In other > > words, is it just a front-end to setting up stdin/stdout on an ssh > > process? > > > > They should (in theory) be roughtly the same. K thanks. > I have tested this and it does resolve the hanging at logout without > causing race conditions. I now have a "shopt -s huponexit" in my > /etc/bashrc and it works beautifully. Pekka Savola also noted this in his response (I'm reading it out of the archives). Didn't do the job for me, though. Here's a sample session of each, scp and ssh. Note that this happens whether using key-auth or password-auth. ~$ shopt -s huponexit ~$ shopt huponexit huponexit on $ ls -l filelist -rw-r----- 1 jamesb jamesb 345529 Feb 18 17:01 filelist $ scp -v -v -v filelist jimb at crate: Executing: program /usr/local/openssh/bin/ssh host crate, user jimb, command scp -v -t . (hangs for a LONG time.. finally kill it with ctrl+c... sshd process stays alive on server) $ ssh -v -v -v crate "cat > filelist" < filelist OpenSSH_2.5.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f debug: Reading configuration data /home/jamesb/.ssh/config debug: Applying options for * debug: Applying options for crate debug: Reading configuration data /usr/local/openssh/etc/ssh_config debug: Applying options for * debug: Rhosts Authentication disabled, originating port will not be trusted. debug: ssh_connect: getuid 1000 geteuid 1000 anon 1 debug: Connecting to crate [ip] port 22. debug: Connection established. debug: identity file /home/jamesb/.ssh/identity type 0 debug: Bad RSA1 key file /home/jamesb/.ssh/id_dsa. debug: identity file /home/jamesb/.ssh/id_dsa type 3 debug: identity file /home/jamesb/.ssh/id_rsa1 type 3 debug: identity file /home/jamesb/.ssh/id_rsa2 type 3 debug: Remote protocol version 1.99, remote software version OpenSSH_2.5.1p1 debug: match: OpenSSH_2.5.1p1 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug: Local version string SSH-2.0-OpenSSH_2.5.1p1 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,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,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 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: mac_init: found hmac-sha1 debug: kex: server->client 3des-cbc hmac-sha1 zlib debug: mac_init: found hmac-sha1 debug: kex: client->server 3des-cbc hmac-sha1 zlib 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: 1021/2049 debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. debug: Got SSH2_MSG_KEXDH_REPLY. debug: Host 'crate' is known and matches the DSA host key. debug: Found key in /home/jamesb/.ssh/known_hosts2:27 debug: bits set: 1026/2049 debug: len 55 datafellows 0 debug: ssh_dss_verify: signature correct debug: Wait SSH2_MSG_NEWKEYS. debug: Enabling compression at level 6. 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,keyboard-interactive 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/jamesb/.ssh/id_dsa debug: read SSH2 private key done: name dsa w/o comment success 1 debug: sign_and_send_pubkey debug: sig size 20 20 debug: we sent a publickey packet, wait for reply debug: ssh-userauth2 successful: method publickey debug: fd 4 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: Sending command: cat > filelist debug: callback done debug: channel 0: open confirm rwindow 0 rmax 16384 debug: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 debug: channel 0: chan_delete_if_full_closed2: istate 1 ostate 16 -- Jim B. vader at conflict.net From sunil at redback.com Thu Feb 22 06:35:41 2001 From: sunil at redback.com (Sunil K. Vallamkonda) Date: Wed, 21 Feb 2001 11:35:41 -0800 (PST) Subject: scp vs sftp. Message-ID: I am just looking for pointers: scp vs ftp - pros and cons. Thank you. From mouring at etoh.eviladmin.org Thu Feb 22 08:00:01 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 21 Feb 2001 15:00:01 -0600 (CST) Subject: sftp-server and chown In-Reply-To: <3A941479.C304B2C6@fy.chalmers.se> Message-ID: On Wed, 21 Feb 2001, Andy Polyakov wrote: > > > > sftp-server is running with the uid/privileges of the user, so why > > > > care? > > > > > > As I already said, some systems *permit* chown to another uid even for > > > non-priviledged users (and most systems can be configured by changing a > > > kernel parameter to permit this operation and some do configure it so) > > > and this is one-way operation, i.e. once I did 'chown markus file' I > > > can't chown it back to myself. > > > > well, so why should i ignore chown if it's legal on some > > systems? > > Because it breaks things in a manner no normal user would expect it to > break during a trivial file transfer. Here is system call trace for > SSHCSI's SSH 2.2.x (Windows client and server): > > unlink("/my/dir/a.txt") = 0 > open("/my/dir/a.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 > fchmod(3, 0) = 0 > fchown(3, 0, 0) = 0 > fchmod(3, 0100666) Err#1 EPERM > utime("/my/dir/a.txt", 0xEFFFF94C) Err#1 EPEPM > fchmod(3, 0100666) Err#1 EPERM > utime("/my/dir/a.txt", 0xEFFFF94C) Err#1 EPERM > > User gets ---------- file owned by root and the only thing [s]he can do > is delete the damn thing. I realize that it might no be 100% applicable > to OpenSSH (I didn't check if it does chmod(0) to mark > "transfer-in-progress"), but the point is that when you transfer a file > you expect to own it on the target system no matter what and therefore > the idea of chown (in any file transer server) is inherently tainted. > > On the other hand even if you logged on with sftp as root, why whould > you like to grant ownership to whomever on the target system who simply > happened to have same numeric id as file owner on the source system? > > Andy. > I have a lot of quarms with how ssh.com designed their sftp client in windows. It's broken and horrible. And I don't feel we should remove a feature because a company can't figure out how to write a correct sftp client. Catering to broken software is never a valid solution. I would love to see sftp expanded. I'd love to see a remote 'MOVE' command implemented. I'm tired of all theses 'file transfer' programs/protocols that ignore the fact that people don't care about 'moving' files any more, but the fact that they want to 'manage' files between multiple machines. And downloading 50 megs of files just to upload them into a new directory is not a valid solution IMHO. From josb at cncdsl.com Thu Feb 22 07:10:07 2001 From: josb at cncdsl.com (Jos Backus) Date: Wed, 21 Feb 2001 12:10:07 -0800 Subject: Portable OpenSSH 2.5.1p1: daemontools-aware? In-Reply-To: <20010221005239.Z25687@quipu.half.pint-stowp.cx>; from jmknoble@jmknoble.cx on Wed, Feb 21, 2001 at 12:52:17AM -0500 References: <20010219161640.A26669@lizzy.bugworks.com> <20010220102954.A23932@faui02.informatik.uni-erlangen.de> <20010220124825.C91708@lizzy.bugworks.com> <20010221005239.Z25687@quipu.half.pint-stowp.cx> Message-ID: <20010221121007.A94515@lizzy.bugworks.com> On Wed, Feb 21, 2001 at 12:52:17AM -0500, Jim Knoble wrote: > I'd rather see this option called '-L' rather than '-e', so as to be > parallel with '-D'. Comments? Fine with me. I forgot to add the option to the usage text. Here's the complete patch again. diff -ur openssh-2.5.1p1.dist/sshd.8 openssh-2.5.1p1/sshd.8 --- openssh-2.5.1p1.dist/sshd.8 Wed Feb 14 19:08:06 2001 +++ openssh-2.5.1p1/sshd.8 Wed Feb 21 12:05:40 2001 @@ -43,7 +43,7 @@ .Nd secure shell daemon .Sh SYNOPSIS .Nm sshd -.Op Fl diqD46 +.Op Fl diqDL46 .Op Fl b Ar bits .Op Fl f Ar config_file .Op Fl g Ar login_grace_time @@ -256,6 +256,8 @@ should be put into the .Pa utmp file. +.It Fl L +Force logging output to be sent to standard error instead of syslogd(8). .It Fl D When this option is specified .Nm diff -ur openssh-2.5.1p1.dist/sshd.c openssh-2.5.1p1/sshd.c --- openssh-2.5.1p1.dist/sshd.c Sun Feb 18 11:13:12 2001 +++ openssh-2.5.1p1/sshd.c Wed Feb 21 12:04:57 2001 @@ -576,7 +576,7 @@ initialize_server_options(&options); /* Parse command-line arguments. */ - while ((opt = getopt(ac, av, "f:p:b:k:h:g:V:u:dDiqQ46")) != -1) { + while ((opt = getopt(ac, av, "f:p:b:k:h:g:V:u:dDiLqQ46")) != -1) { switch (opt) { case '4': IPv4or6 = AF_INET; @@ -601,6 +601,9 @@ case 'D': no_daemon_flag = 1; break; + case 'L': + log_stderr = 1; + break; case 'i': inetd_flag = 1; break; @@ -651,6 +654,7 @@ fprintf(stderr, " -d Debugging mode (multiple -d means more debugging)\n"); fprintf(stderr, " -i Started from inetd\n"); fprintf(stderr, " -D Do not fork into daemon mode\n"); + fprintf(stderr, " -L Force logging to standard error\n"); fprintf(stderr, " -q Quiet (no logging)\n"); fprintf(stderr, " -p port Listen on the specified port (default: 22)\n"); fprintf(stderr, " -k seconds Regenerate server key every this many seconds (default: 3600)\n"); -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From markus.friedl at informatik.uni-erlangen.de Thu Feb 22 07:41:06 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 21 Feb 2001 21:41:06 +0100 Subject: X11 display issues In-Reply-To: <3A940D0F.3919117F@fy.chalmers.se>; from appro@fy.chalmers.se on Wed, Feb 21, 2001 at 07:46:39PM +0100 References: <3A93D8B6.84CFC7AC@fy.chalmers.se> <20010221161328.C7296@faui02.informatik.uni-erlangen.de> <3A940D0F.3919117F@fy.chalmers.se> Message-ID: <20010221214106.B9635@folly> On Wed, Feb 21, 2001 at 07:46:39PM +0100, Andy Polyakov wrote: > > > This also has been discussed in SSHSCI's SSH context. All SSH versions > > > (both SSHSCI and OpenSSH) derive value for DISPLAY variable from > > > `uname -n`. The problem is that the returned value is not necessarily > > > resolvable to a valid IP number which in turn might cause a failure. > > > > oh yes, this is a problem. i will probably change the sshd-X11-proxy > > from internet to unix domain sockets. > > Say you run ssh against firewall in order to run X11 application on > computer behind the firewall. UNIX socket would kill the idea... well you can ssh from the firewall to the next machine. > > libX is broken if i set DISPLAY=localhost:x.y and ignore any > > X cookies. > > Note that I set it to anything *but* localhost:x.y (well, as long as you > don't ssh localhost, but that would be confusing from key management > viewpoint so that you don't normally do it). i don't like the idea of having the X11 socket listen to inaddr_any. > > > To make it fool-proof I suggest to set DISPLAY to the interface's > > > address the user has reached the system in question through. > > > > I tried this before, but it does not work since it uses AF_INET6 if > > i connect by > > $ ssh -X ::1 > > Does libX11 talk IPv6 at all? no, this is the problem. your patch breaks x11-fwd if i connect to an ipv6 address. -m From tell at telltronics.org Wed Feb 21 18:06:25 2001 From: tell at telltronics.org (Steve Tell) Date: Wed, 21 Feb 2001 02:06:25 -0500 (EST) Subject: bug?: building RPM of 2.5.1p1 uses wrong pam.d/ssh file for RH6 vs RH7 Message-ID: (I'm using RedHat 6.2 and openssl-0.9.5a-3) After rebuilding binary RPMs using openssh-2.5.1p1-1.src.rpm, I was unable to ssh in to a system upgraded to the new openssh-server-2.5.1p1.rpm After the failure, /var/log/messages on the destination indicated lots of PAM errors of the form "sshd[22814]: PAM [dlerror: /lib/security/pam_stack.so: can not open shared object file: No such file or directory]" I traced the problem to the fact that /etc/pam.d/ssh was copied from the RedHat 7 version, contrib/redhat/sshd.pam-7.x, instead of the one for RedHat 6.2 and eariler, sshd.pam-7.x Replacing the file fixed that particular system, but the rpm itself contains the wrong file. It would appear that the conditional in openssh.spec that is supposed to select the redhat version is reversed: If "--define rh7" is specified, the 6.2 file, "sshd.pam" is used, else specified, then the file for 7.0, "sshd.pam-7.x" is used The patch below fixes this by swapping if/else parts of the conditional. OTOH, if the conditional is thought to be correct without this patch, then the name of the define (and the documents comments) could really use to be made more clear... Steve -- Steve Tell tell at telltronics.org *** openssh.spec Mon Feb 19 05:51:50 2001 --- /usr/src/redhat/SPECS/openssh.spec Wed Feb 21 01:36:49 2001 *************** *** 190,198 **** install -d $RPM_BUILD_ROOT/etc/rc.d/init.d install -d $RPM_BUILD_ROOT%{_libexecdir}/openssh %if %{redhat7} - install -m644 contrib/redhat/sshd.pam $RPM_BUILD_ROOT/etc/pam.d/sshd - %else install -m644 contrib/redhat/sshd.pam-7.x $RPM_BUILD_ROOT/etc/pam.d/sshd %endif install -m755 contrib/redhat/sshd.init $RPM_BUILD_ROOT/etc/rc.d/init.d/sshd --- 190,198 ---- install -d $RPM_BUILD_ROOT/etc/rc.d/init.d install -d $RPM_BUILD_ROOT%{_libexecdir}/openssh %if %{redhat7} install -m644 contrib/redhat/sshd.pam-7.x $RPM_BUILD_ROOT/etc/pam.d/sshd + %else + install -m644 contrib/redhat/sshd.pam $RPM_BUILD_ROOT/etc/pam.d/sshd %endif install -m755 contrib/redhat/sshd.init $RPM_BUILD_ROOT/etc/rc.d/init.d/sshd From Markus.Friedl at informatik.uni-erlangen.de Thu Feb 22 08:14:38 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 21 Feb 2001 22:14:38 +0100 Subject: scp vs sftp. In-Reply-To: ; from sunil@redback.com on Wed, Feb 21, 2001 at 11:35:41AM -0800 References: Message-ID: <20010221221438.A12065@faui02.informatik.uni-erlangen.de> fast and simple: scp slow and complex: sftp On Wed, Feb 21, 2001 at 11:35:41AM -0800, Sunil K. Vallamkonda wrote: > > I am just looking for pointers: scp vs ftp - pros and cons. > > > Thank you. > > From gert at greenie.muc.de Thu Feb 22 09:01:49 2001 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 21 Feb 2001 23:01:49 +0100 Subject: OpenSSH 2.5.1p1 on HP-UX: No CTRL+C possible!!! In-Reply-To: <20010221135056.A15309@rhs-notebook>; from Randolf Skerka on Wed, Feb 21, 2001 at 01:50:56PM +0100 References: <3A936F57.6952C208@skerka.de> <20010221135056.A15309@rhs-notebook> Message-ID: <20010221230149.A4656@greenie.muc.de> Hi, On Wed, Feb 21, 2001 at 01:50:56PM +0100, Randolf Skerka wrote: > Well stty -a shows the usual entries: > > > intr = ^C; quit = ^\; erase = ^H; kill = ^U > > eof = ^D; eol = ^@; eol2 ; swtch > > stop = ^S; start = ^Q; susp ; dsusp > > It's strange ... Didn't we have that before, something about SIGINT being set to SIG_IGN from some upstream process, and not being reset by sshd to SIG_DFL? I remember reading this before... 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 Thu Feb 22 09:02:36 2001 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 21 Feb 2001 23:02:36 +0100 Subject: OpenSSH 2.5.1p1 on HP-UX: No CTRL+C possible!!! In-Reply-To: <20010221100541.A978@nebula.dsl.speakeasy.net>; from Garrick James on Wed, Feb 21, 2001 at 10:05:41AM -0800 References: <3A936F57.6952C208@skerka.de> <20010221100541.A978@nebula.dsl.speakeasy.net> Message-ID: <20010221230236.B4656@greenie.muc.de> Hi, On Wed, Feb 21, 2001 at 10:05:41AM -0800, Garrick James wrote: > Basicly it all boiled down to the state of CTRL-C at the time sshd was > launched. Go to the console of the machine in question (if you can), stop [..] Exactly. I thought we got this fixed, resetting the signal handler for SIGINT? Ages ago? 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 Thu Feb 22 09:05:43 2001 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 21 Feb 2001 23:05:43 +0100 Subject: X11 display issues In-Reply-To: <4.2.0.58.20010221103229.01d44660@127.0.0.1>; from William L. Jones on Wed, Feb 21, 2001 at 10:35:21AM -0600 References: <3A93D8B6.84CFC7AC@fy.chalmers.se> <3A93D8B6.84CFC7AC@fy.chalmers.se> <20010221161328.C7296@faui02.informatik.uni-erlangen.de> <4.2.0.58.20010221103229.01d44660@127.0.0.1> Message-ID: <20010221230543.C4656@greenie.muc.de> Hi, On Wed, Feb 21, 2001 at 10:35:21AM -0600, William L. Jones wrote: > Keep the Internet domain sockets at least for a few systems. Cray > UNICOS X11 does not support unix domain sockets. > > Do both but configure unix domain sockets by default at let porters add a > define to > do Internet domain sockets instead of unix domain sockets. Seconded. SCO doesn't have unix domain sockets either, so please make them optional. 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 mattl at livecapital.com Thu Feb 22 09:27:55 2001 From: mattl at livecapital.com (Lewandowsky, Matt) Date: Wed, 21 Feb 2001 14:27:55 -0800 Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) bo x Message-ID: <9F8E2B3F8CBAD411AAC4009027DCFDC807486E@exchange.aprivate.com> I think that you're supposed to run the shopt on crate in your .profile... --Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010221/dc1af634/attachment.html From jmknoble at jmknoble.cx Thu Feb 22 09:31:21 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Wed, 21 Feb 2001 17:31:21 -0500 Subject: openssh-2.5.1p1 etc In-Reply-To: <20010221112059.C4019@mtu.edu>; from celinn@mtu.edu on Wed, Feb 21, 2001 at 11:20:59AM -0500 References: <200102211551.PAA07340@nps.ph.bham.ac.uk> <20010221112059.C4019@mtu.edu> Message-ID: <20010221173121.B10394@quipu.half.pint-stowp.cx> The perl script Ben mentions is one hacked together by Mark Roth to translate the -mdoc macros into -man macros, so that you can install actual troff source on systems without -mdoc macros instead of installing preformatted source. This would allow you to use tools such as RosettaMan (or whatever the devil that's called now) or troff -Tps or whatnot. -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ Circa 2001-Feb-21 11:20:59 -0500 dixit Christopher Linn: : i have had no problems with 2.5.1p1 on solaris 8 when i use the : "--with-catman=cat" configure option... what am i missing here in : this discussion? : : On Wed, Feb 21, 2001 at 10:48:45AM -0600, mouring at etoh.eviladmin.org wrote: : > There is a perl script presented that does this. It will find it's way : > into OpenSSH portable soon. : > : > If you look back throught the list you can find it. : > : > - Ben : > : > On Wed, 21 Feb 2001, James Campbell wrote: : > > Is there an easy way to "fix" the man pages to work with Solaris. : > > Solaris uses the "an" ie /usr/share/lib/tmac/an nroff macros and I guess : > > openbsd doesnt!! From vader at conflict.net Thu Feb 22 09:37:01 2001 From: vader at conflict.net (Jim Breton) Date: Wed, 21 Feb 2001 22:37:01 +0000 Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) bo x In-Reply-To: <9F8E2B3F8CBAD411AAC4009027DCFDC807486E@exchange.aprivate.com>; from mattl@livecapital.com on Wed, Feb 21, 2001 at 02:27:55PM -0800 References: <9F8E2B3F8CBAD411AAC4009027DCFDC807486E@exchange.aprivate.com> Message-ID: <20010221223701.14536.qmail@conflict.net> On Wed, Feb 21, 2001 at 02:27:55PM -0800, Lewandowsky, Matt wrote: > I think that you're supposed to run the shopt on crate in your .profile... Yeah I realized that right after I sent the message... ;P didn't want to send another message out though unless it was necessary. But anyway afterward I did try it on the remote host and it still didn't change anything. :-\ -- Jim B. vader at conflict.net From mouring at etoh.eviladmin.org Thu Feb 22 10:31:00 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 21 Feb 2001 17:31:00 -0600 (CST) Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) bo x In-Reply-To: <9F8E2B3F8CBAD411AAC4009027DCFDC807486E@exchange.aprivate.com> Message-ID: On Wed, 21 Feb 2001, Lewandowsky, Matt wrote: > I think that you're supposed to run the shopt on crate in your .profile... > > --Matt > For it to be effective either you need to put it in your .profile, /etc/profile, /etc/bashrc, ~/.bashrc, or type it in *AFTER* you ssh to the linux machine in question. It will not propogate between machines. - ben From svaughan at asterion.com Thu Feb 22 09:47:39 2001 From: svaughan at asterion.com (Sam Vaughan) Date: Wed, 21 Feb 2001 14:47:39 -0800 (PST) Subject: SCO 5.0.5 setluid patch Message-ID: On Wed, 21 Feb 2001 mouring at etoh.eviladmin.org wrote: > > Can you resend that patch? It was managed in deliever and does not > apply against the current CVS tree. > > Thanks > > - Ben > No problem, here is a patch for the CVS tree that I grabbed this morning. Sam *** openssh_cvs/session.c Tue Feb 20 21:53:33 2001 --- openssh_cvs_patch/session.c Wed Feb 21 11:03:24 2001 *************** *** 1071,1076 **** } #endif # else /* HAVE_LOGIN_CAP */ if (setlogin(pw->pw_name) < 0) error("setlogin failed: %s", strerror(errno)); if (setgid(pw->pw_gid) < 0) { --- 1071,1083 ---- } #endif # else /* HAVE_LOGIN_CAP */ + + #if defined(HAVE_GETLUID) && defined(HAVE_SETLUID) + /* Sets login uid for accounting */ + if (getluid() == -1 && setluid(pw->pw_uid) == -1) + error("setluid: %s", strerror(errno)); + #endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */ + if (setlogin(pw->pw_name) < 0) error("setlogin failed: %s", strerror(errno)); if (setgid(pw->pw_gid) < 0) { *************** *** 1122,1132 **** } #endif /* HAVE_OSF_SIA */ - #if defined(HAVE_GETLUID) && defined(HAVE_SETLUID) - /* Sets login uid for accounting */ - if (getluid() == -1 && setluid(pw->pw_uid) == -1) - error("setluid: %s", strerror(errno)); - #endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */ #ifdef HAVE_CYGWIN if (is_winnt) --- 1129,1134 ---- } #endif /* HAVE_OSF_SIA */ #ifdef HAVE_CYGWIN if (is_winnt) From mouring at etoh.eviladmin.org Thu Feb 22 10:56:01 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 21 Feb 2001 17:56:01 -0600 (CST) Subject: SCO 5.0.5 setluid patch In-Reply-To: Message-ID: Applied. thanks. On Wed, 21 Feb 2001, Sam Vaughan wrote: > > On Wed, 21 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > Can you resend that patch? It was managed in deliever and does not > > apply against the current CVS tree. > > > > Thanks > > > > - Ben > > > > No problem, here is a patch for the CVS tree that I grabbed this > morning. > > Sam > > *** openssh_cvs/session.c Tue Feb 20 21:53:33 2001 > --- openssh_cvs_patch/session.c Wed Feb 21 11:03:24 2001 > *************** > *** 1071,1076 **** > } > #endif > # else /* HAVE_LOGIN_CAP */ > if (setlogin(pw->pw_name) < 0) > error("setlogin failed: %s", > strerror(errno)); > if (setgid(pw->pw_gid) < 0) { > --- 1071,1083 ---- > } > #endif > # else /* HAVE_LOGIN_CAP */ > + > + #if defined(HAVE_GETLUID) && defined(HAVE_SETLUID) > + /* Sets login uid for accounting */ > + if (getluid() == -1 && setluid(pw->pw_uid) == -1) > + error("setluid: %s", strerror(errno)); > + #endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */ > + > if (setlogin(pw->pw_name) < 0) > error("setlogin failed: %s", > strerror(errno)); > if (setgid(pw->pw_gid) < 0) { > *************** > *** 1122,1132 **** > } > #endif /* HAVE_OSF_SIA */ > > - #if defined(HAVE_GETLUID) && defined(HAVE_SETLUID) > - /* Sets login uid for accounting */ > - if (getluid() == -1 && setluid(pw->pw_uid) == -1) > - error("setluid: %s", strerror(errno)); > - #endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */ > > #ifdef HAVE_CYGWIN > if (is_winnt) > --- 1129,1134 ---- > } > #endif /* HAVE_OSF_SIA */ > > > #ifdef HAVE_CYGWIN > if (is_winnt) > > > > > > From vader at conflict.net Thu Feb 22 10:14:41 2001 From: vader at conflict.net (Jim Breton) Date: Wed, 21 Feb 2001 23:14:41 +0000 Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) bo x In-Reply-To: ; from mouring@etoh.eviladmin.org on Wed, Feb 21, 2001 at 05:31:00PM -0600 References: <9F8E2B3F8CBAD411AAC4009027DCFDC807486E@exchange.aprivate.com> Message-ID: <20010221231441.15853.qmail@conflict.net> On Wed, Feb 21, 2001 at 05:31:00PM -0600, mouring at etoh.eviladmin.org wrote: > For it to be effective either you need to put it in your .profile, > /etc/profile, /etc/bashrc, ~/.bashrc, or type it in *AFTER* you > ssh to the linux machine in question. Yup, did that, no change. -- Jim B. vader at conflict.net From slade at shore.net Thu Feb 22 11:00:39 2001 From: slade at shore.net (Richard E. Silverman) Date: Wed, 21 Feb 2001 19:00:39 -0500 Subject: Packet integrity error. (34) Message-ID: <200102220000.TAA09881@syrinx.oankali.net> markus> it seems that SecureCRT sends a display 'screen' number in the x11 markus> request packet, but did not set the matching protocol flag in an markus> earlier message. this worked before because OpenSSH-2.3.0p1 was buggy markus> and ignored the protocol flag.... I actually also noticed this also a day or so ago, and was about to post about it here when I checked and saw this thread. This is a problem with the F-Secure client as well as SecureCRT. Both programs do not set the SSH_PROTOFLAG_SCREEN_NUMBER protocol flag in SSH-1 sessions, even though they do in fact include the X11 screen number field in SSH_CMSG_X11_REQUEST_FORWARDING packets. This was not a problem -- until Markus added code to session.c in 2.5 to check actual vs expected packet lengths on these requests. Now, SSH-1 connections with X forwarding from these clients fail immediately with the message, "packet integrity error." I've submitted bug reports to both companies. A small note: I think it would be good to change the error message -- "packet integrity error" sounds like the crc-32 integrity check failed, which isn't what happened. Perhaps instead, "expected packet length did not match actual." - Richard From mouring at etoh.eviladmin.org Thu Feb 22 12:07:33 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 21 Feb 2001 19:07:33 -0600 (CST) Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) bo x In-Reply-To: <20010221231441.15853.qmail@conflict.net> Message-ID: On Wed, 21 Feb 2001, Jim Breton wrote: > On Wed, Feb 21, 2001 at 05:31:00PM -0600, mouring at etoh.eviladmin.org wrote: > > For it to be effective either you need to put it in your .profile, > > /etc/profile, /etc/bashrc, ~/.bashrc, or type it in *AFTER* you > > ssh to the linux machine in question. > > Yup, did that, no change. > I'm stumped, since I can't replicate this on any Redhat box under my control I can't provide any other suggestions, hints, tricks, etc. I wish I could help more, but without finding some hint as to what is befuddling it there is not much more I can do. =( Just to make sure your not compiling OpenSSH with that evil gcc-2.96 want-a-be 3.0 compiler are you? If so can you step back to kgcc (1.1.2) or 2.95.x and test it? - Ben From vader at conflict.net Thu Feb 22 11:22:09 2001 From: vader at conflict.net (Jim Breton) Date: Thu, 22 Feb 2001 00:22:09 +0000 Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) bo x In-Reply-To: ; from mouring@etoh.eviladmin.org on Wed, Feb 21, 2001 at 07:07:33PM -0600 References: <20010221231441.15853.qmail@conflict.net> Message-ID: <20010222002209.16028.qmail@conflict.net> On Wed, Feb 21, 2001 at 07:07:33PM -0600, mouring at etoh.eviladmin.org wrote: > I'm stumped, since I can't replicate this on any Redhat box under my > control I can't provide any other suggestions, hints, tricks, etc. > > I wish I could help more, but without finding some hint as to what is > befuddling it there is not much more I can do. =( > > Just to make sure your not compiling OpenSSH with that evil gcc-2.96 > want-a-be 3.0 compiler are you? If so can you step back to kgcc > (1.1.2) or 2.95.x and test it? Lol... well on the RH7 box I tested yes (I will re-compile and test again). The other boxen in question are 2 Debian potato with stock (2.95.) gcc, and an RH6 box with egcs-2.91.66. Heading out for the night but will do some more testing and stuff tomorrow. Thanks everyone for your time! :) -- Jim B. vader at conflict.net From henson at intranet.csupomona.edu Thu Feb 22 13:32:19 2001 From: henson at intranet.csupomona.edu (Paul B. Henson) Date: Wed, 21 Feb 2001 18:32:19 -0800 (PST) Subject: Kerberos/GSSAPI support Message-ID: Simon Wilkinson wrote: > My patches for SSH version 1 Kerberos 5 support (heavily based upon > work done by Dan Kouril) are now available from > http://www.sxw.org.uk/computing/patches/ Is there any interest in > integrating these into the distribution? If so, I'd be happy to update > them to the development version. I for one would definitely be interested in seeing these patches incorporated into the distribution. one of the main reasons I have not yet upgraded to openssh has been the lack of stable Kerberos 5 support. -- Paul B. Henson | (909) 869-3781 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | henson at intranet.csupomona.edu California State Polytechnic University | Pomona CA 91768 From tcarter at princeton.edu Thu Feb 22 13:34:40 2001 From: tcarter at princeton.edu (Troy Carter) Date: Wed, 21 Feb 2001 21:34:40 -0500 Subject: SSH connection hangs with ipchains/RH6.2/OpenSSH 2.5.1p1 (but not <= 2.3.0p1) Message-ID: <3A947AC0.7F9993D5@princeton.edu> I just recently installed OpenSSH 2.5.1p1 on a RH6.2 box (kernel 2.2.17). I run ipchains to do packet filtering, allowing incoming connections only to 22 and 80 (and some other ports for specific machines). I was able to run prior versions of openssh in this fashion (I've run it from the first release, I think). Upon installing 2.5.1p1 I found that my attempts to connect hang, here is ssh -v -v -v output: [tcarter at fletch tcarter]$ ssh -v -v -v elmo.princeton.edu OpenSSH_2.5.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f debug: Reading configuration data /etc/ssh/ssh_config debug: Applying options for * debug: ssh_connect: getuid 28419 geteuid 0 anon 0 debug: Connecting to elmo.princeton.edu [128.112.129.192] port 22. debug: Seeding random number generator debug: Allocated local port 1019. I also have a RH7 box (at work) that I had also installed 2.5.1p1 on, and this one had no such problems, but also doesn't do any packet filtering (already behind a firewall). When I turned off ipchains on the RH6.2 box, the connections go through without a problem. So for now I just created ipchains rules to allow all connections from the machines I routinely ssh to -- mostly because I saw no log entries indicating unsuccessful connection attempts... ??? I also recompiled 2.3.0p1 to make sure I wasn't crazy -- using 2.3.0p1, I connect with no problem. I also tried stopping ipchains, connecting (successfully), then restarting ipchains. The connection hangs in this case also. Is this a bug or am I doing something strange with my ipchains setup (pretty vanilla though...)? The servers I am trying to connect to are ssh-1.2.x (Solaris, IRIX) and OpenSSH 2.3.0p1,2.5.1p1 (Linux). Thanks- -Troy -- Troy Carter tcarter at princeton.edu From tcarter at princeton.edu Thu Feb 22 14:53:10 2001 From: tcarter at princeton.edu (Troy Carter) Date: Wed, 21 Feb 2001 22:53:10 -0500 Subject: SSH connection hangs with ipchains/RH6.2/OpenSSH 2.5.1p1 (butnot <= 2.3.0p1) References: Message-ID: <3A948D26.F5F19102@princeton.edu> I figured this out -- looks like 2.5.1p1 is now using ports < 1024 on the client side (wasn't before?). I had a ipchains rule to allow ACK packets to 1024:65535, which was good enough for <= 2.3.0p1 : #allow only ACK tcp packed ipchains -A input -j ACCEPT -i eth0 -s any/0 --dport 1024:65535 -p tcp ! -y So I added the following : #allow return from ssh connections ipchains -A input -j ACCEPT -i eth0 -s any/0 22 -p tcp ! -y Now everything is fine. I even see the config file option to switch back to using non-priveleged ports. What was the reason for switching to priveleged by default in 2.5.1p1? -Troy Jason Stone wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I just recently installed OpenSSH 2.5.1p1 on a RH6.2 box (kernel > > 2.2.17). I run ipchains to do packet filtering, allowing incoming > > connections only to 22 and 80 (and some other ports for specific > > machines). > > Strange. Add a logging rule to your ipchains setup to see all the deny > packets. > > If it was working with prior versions, than I imagine you already know > this, but make sure to have a rule allowing the return packets. > > -Jason > > --------------------------- > If the Revolution comes to grief, it will be because you and those you > lead have become alarmed at your own brutality. --John Gardner > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.4 (FreeBSD) > Comment: See https://private.idealab.com/public/jason/jason.gpg > > iD8DBQE6lICTswXMWWtptckRAhqFAJ4rBjhw5S/pt/rMB2zh7rrFR7HHBwCeNRB0 > JpLCTVj3M3MaDfenF/F1NS8= > =P1RP > -----END PGP SIGNATURE----- -- Troy Carter tcarter at princeton.edu From mouring at etoh.eviladmin.org Thu Feb 22 18:21:21 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 22 Feb 2001 01:21:21 -0600 (CST) Subject: Lets try this push again.. 2.5.1p2 bugs left. Message-ID: Things that are still outstanding: 1) Solaris/Redhat/HPUX session.c patch. I've not seen a ya or na on Kevin's pam patch from the Solaris group. 2) Odd Redhat/Debian scp/ssh issues. .. I'm baffled, and I can't replicate the bug. Nor have I seen anything remotely like it reported. 3) SCO.. Is it happy yet for compiling? =) Completed: 1) mdoc2man.pl .. Commited into contrib/ directory. In the semi-near future either we need a patch to configure.in to support it directly. 2) SCO setluid patch commited (Verify please). Anything else I'm missing for brokeness that was introduced between 2.3.0p1 and 2.5.1p1 that needs to be corrected? I'm expecting that 2.5.1p2 will stand for a long time. So speak up now. I want to put p2 to rest with the next week and half so we can catch back up with the OpenBSD tree and head on to bigger and better problems. =) Sorry, Kevin.. I'll get you the patches for the website by tomorrow evening I ended up being called away for the night. - Ben From mats at mindbright.se Thu Feb 22 18:57:11 2001 From: mats at mindbright.se (Mats Andersson) Date: Thu, 22 Feb 2001 08:57:11 +0100 (MET) Subject: sftp-server and chown In-Reply-To: Message-ID: Hi, On Wed, 21 Feb 2001 mouring at etoh.eviladmin.org wrote: > It's broken and horrible. And I don't feel we should remove a feature > because a company can't figure out how to write a correct sftp client. I don't know anything about their client, but after all they designed the protocol which is quite clean IMHO. > I would love to see sftp expanded. I'd love to see a remote 'MOVE' > command implemented. I'm tired of all theses 'file transfer' > programs/protocols that ignore the fact that people don't care about > 'moving' files any more, There is RENAME in the sftp protocol, it can be used to "move" files on the target system. Not sure if this is what you meant, just thought I'd mention it. Cheers, /Mats From mats at mindbright.se Thu Feb 22 19:06:14 2001 From: mats at mindbright.se (Mats Andersson) Date: Thu, 22 Feb 2001 09:06:14 +0100 (MET) Subject: scp vs sftp. In-Reply-To: <20010221221438.A12065@faui02.informatik.uni-erlangen.de> Message-ID: Hi, On Wed, 21 Feb 2001, Markus Friedl wrote: > fast and simple: scp > slow and complex: sftp :-) Well, while I do agree that scp is fast and simple (after all it's a clone of rcp), I must say that sftp IMHO is not very complex though it might have its shortcomings. I would like to put it: scp: fast/simple protocol for replacing rcp in scripts similar for moving files across an arbitrary transport such as ssh. sftp: rather clean/general protocol for implementing remote filesystem access across an arbitrary transport such as ssh. Note that I'm speaking of the protocols here, as for the client/server implementations I have nothing to say... :-) Cheers, /Mats From Markus.Friedl at informatik.uni-erlangen.de Thu Feb 22 19:01:50 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 22 Feb 2001 09:01:50 +0100 Subject: scp vs sftp. In-Reply-To: ; from mats@mindbright.se on Thu, Feb 22, 2001 at 09:06:14AM +0100 References: <20010221221438.A12065@faui02.informatik.uni-erlangen.de> Message-ID: <20010222090150.D11850@faui02.informatik.uni-erlangen.de> Yes you are probably right :) my computer was running out of battery when i was typing the mail. now that sftp is becomming a 'standard' is the more general solution. it would be nice if someone could add support for the sftp-protocol to scp. note also, that sftp works fine over the ssh protocol version 1 in openssh (sftp -1 host). -markus On Thu, Feb 22, 2001 at 09:06:14AM +0100, Mats Andersson wrote: > On Wed, 21 Feb 2001, Markus Friedl wrote: > > fast and simple: scp > > slow and complex: sftp > > :-) > > Well, while I do agree that scp is fast and simple (after all it's a clone > of rcp), I must say that sftp IMHO is not very complex though it might > have its shortcomings. I would like to put it: > > scp: fast/simple protocol for replacing rcp in scripts similar for moving > files across an arbitrary transport such as ssh. > > sftp: rather clean/general protocol for implementing remote filesystem > access across an arbitrary transport such as ssh. > > Note that I'm speaking of the protocols here, as for the client/server > implementations I have nothing to say... :-) > > Cheers, > > /Mats From Markus.Friedl at informatik.uni-erlangen.de Thu Feb 22 19:11:09 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 22 Feb 2001 09:11:09 +0100 Subject: Packet integrity error. (34) In-Reply-To: <200102220000.TAA09881@syrinx.oankali.net>; from slade@shore.net on Wed, Feb 21, 2001 at 07:00:39PM -0500 References: <200102220000.TAA09881@syrinx.oankali.net> Message-ID: <20010222091109.F11850@faui02.informatik.uni-erlangen.de> On Wed, Feb 21, 2001 at 07:00:39PM -0500, Richard E. Silverman wrote: > > markus> it seems that SecureCRT sends a display 'screen' number in the x11 > markus> request packet, but did not set the matching protocol flag in an > markus> earlier message. this worked before because OpenSSH-2.3.0p1 was buggy > markus> and ignored the protocol flag.... > > I actually also noticed this also a day or so ago, and was about to post about > it here when I checked and saw this thread. > > This is a problem with the F-Secure client as well as SecureCRT. Both > programs do not set the SSH_PROTOFLAG_SCREEN_NUMBER protocol flag in SSH-1 > sessions, even though they do in fact include the X11 screen number field in > SSH_CMSG_X11_REQUEST_FORWARDING packets. This was not a problem -- until > Markus added code to session.c in 2.5 to check actual vs expected packet > lengths on these requests. well the code was there befoe, but it was broken. the old (2.3.0) code did not check the flag and always asumed that a screen number will be given. this resulted in "packet integrity error." for other clients :( > Now, SSH-1 connections with X forwarding from > these clients fail immediately with the message, "packet integrity error." > I've submitted bug reports to both companies. > > A small note: I think it would be good to change the error message -- "packet > integrity error" sounds like the crc-32 integrity check failed, which isn't > what happened. Perhaps instead, "expected packet length did not match > actual." i'll think about this. -m From Markus.Friedl at informatik.uni-erlangen.de Thu Feb 22 19:13:58 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 22 Feb 2001 09:13:58 +0100 Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Feb 22, 2001 at 01:21:21AM -0600 References: Message-ID: <20010222091358.G11850@faui02.informatik.uni-erlangen.de> i think i have to add a workaround for buggy windows clients+x11fwd. On Thu, Feb 22, 2001 at 01:21:21AM -0600, mouring at etoh.eviladmin.org wrote: > > Things that are still outstanding: > > 1) Solaris/Redhat/HPUX session.c patch. I've not seen a ya or na on > Kevin's pam patch from the Solaris group. > > 2) Odd Redhat/Debian scp/ssh issues. .. I'm baffled, and I can't > replicate the bug. Nor have I seen anything remotely like it reported. > > 3) SCO.. Is it happy yet for compiling? =) > > Completed: > > 1) mdoc2man.pl .. Commited into contrib/ directory. In the semi-near > future either we need a patch to configure.in to support it directly. > > 2) SCO setluid patch commited (Verify please). > > Anything else I'm missing for brokeness that was introduced between > 2.3.0p1 and 2.5.1p1 that needs to be corrected? I'm expecting that > 2.5.1p2 will stand for a long time. So speak up now. I want to put p2 > to rest with the next week and half so we can catch back up with the > OpenBSD tree and head on to bigger and better problems. =) > > Sorry, Kevin.. I'll get you the patches for the website by tomorrow > evening I ended up being called away for the night. > > - Ben > From pekkas at netcore.fi Thu Feb 22 19:22:17 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 22 Feb 2001 10:22:17 +0200 (EET) Subject: SSH connection hangs with ipchains/RH6.2/OpenSSH 2.5.1p1 (butnot <= 2.3.0p1) In-Reply-To: <3A948D26.F5F19102@princeton.edu> Message-ID: On Wed, 21 Feb 2001, Troy Carter wrote: > I figured this out -- looks like 2.5.1p1 is now using ports < 1024 on > the client side (wasn't before?). I had a ipchains rule to allow ACK > packets to 1024:65535, which was good enough for <= 2.3.0p1 : > Now everything is fine. I even see the config file option to switch > back to using non-priveleged ports. What was the reason for switching > to priveleged by default in 2.5.1p1? This has always been the case, and is caused by the setuid bit (by default) in your ssh binary. You can disable this (as you probably had done) by removing the bit, or adding 'UsePrivilegedPort no' in your ssh_config. (Note that this breaks RhostsAuthentication, see man page) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From garrick at james.net Thu Feb 22 15:03:22 2001 From: garrick at james.net (Garrick James) Date: Wed, 21 Feb 2001 20:03:22 -0800 Subject: OpenSSH 2.5.1p1 on HP-UX: No CTRL+C possible!!! In-Reply-To: <20010221230236.B4656@greenie.muc.de>; from gert@greenie.muc.de on Wed, Feb 21, 2001 at 11:02:36PM +0100 References: <3A936F57.6952C208@skerka.de> <20010221100541.A978@nebula.dsl.speakeasy.net> <20010221230236.B4656@greenie.muc.de> Message-ID: <20010221200322.A2258@nebula.dsl.speakeasy.net> Well, I'm not much of a C coder, so I cannot make heads or tails of the code. I don't know if this ever got all straightened out or not. All I know is that I have 2.3.0.p1 on my Solaris boxen and its "broken". I haven't gotten around to trying 2.5.1p1 (or whatever the current is) to see if the problem is fixed (on Solaris) or not, yet. -Garrick On Wed, 21 Feb 2001, Gert Doering wrote: > Hi, > > On Wed, Feb 21, 2001 at 10:05:41AM -0800, Garrick James wrote: > > Basicly it all boiled down to the state of CTRL-C at the time sshd was > > launched. Go to the console of the machine in question (if you can), stop > [..] > > Exactly. I thought we got this fixed, resetting the signal handler for > SIGINT? Ages ago? > > 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 Thu Feb 22 20:09:54 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 22 Feb 2001 11:09:54 +0200 (EET) Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: Message-ID: On Thu, 22 Feb 2001 mouring at etoh.eviladmin.org wrote: > Anything else I'm missing for brokeness that was introduced between > 2.3.0p1 and 2.5.1p1 that needs to be corrected? I'm expecting that > 2.5.1p2 will stand for a long time. So speak up now. I want to put p2 > to rest with the next week and half so we can catch back up with the > OpenBSD tree and head on to bigger and better problems. =) Not exactly brokenness, but sshd -t functionality (patch here yesterday) would be very nice to have to ease the transition to 2.5.x. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From J.Horne at plymouth.ac.uk Thu Feb 22 20:33:47 2001 From: J.Horne at plymouth.ac.uk (John Horne) Date: Thu, 22 Feb 2001 09:33:47 -0000 (GMT) Subject: OpenSSH 2.5.1p1 on HP-UX: No CTRL+C possible!!! In-Reply-To: <20010221200322.A2258@nebula.dsl.speakeasy.net> Message-ID: On 22-Feb-01 at 04:03:22 Garrick James wrote: > I haven't gotten around to trying 2.5.1p1 (or whatever the current is) to > see if the problem is fixed (on Solaris) or not, yet. > Yup - ctrl-c works fine with 2.5.1.p1. 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 vinschen at redhat.com Thu Feb 22 20:01:03 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 22 Feb 2001 10:01:03 +0100 Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Feb 22, 2001 at 01:21:21AM -0600 References: Message-ID: <20010222100103.F908@cygbert.vinschen.de> On Thu, Feb 22, 2001 at 01:21:21AM -0600, mouring at etoh.eviladmin.org wrote: > > Things that are still outstanding: > > 1) Solaris/Redhat/HPUX session.c patch. I've not seen a ya or na on > Kevin's pam patch from the Solaris group. > > 2) Odd Redhat/Debian scp/ssh issues. .. I'm baffled, and I can't > replicate the bug. Nor have I seen anything remotely like it reported. > > 3) SCO.. Is it happy yet for compiling? =) > [...] > Anything else I'm missing for brokeness that was introduced between > 2.3.0p1 and 2.5.1p1 that needs to be corrected? I'm expecting that > 2.5.1p2 will stand for a long time. So speak up now. I want to put p2 > to rest with the next week and half so we can catch back up with the > OpenBSD tree and head on to bigger and better problems. =) OpenSSH sftp closes the sockets/pipes (dependent of the value of USE_PIPES) and then kills it's underlying ssh by calling kill(ssh, SIGHUP). This kills the underlying ssh immediately which results in breaking the connection to sshd which in turn terminates without cleanly disconnecting from the subsystem. This results in a hanging sftp-server, waiting for `select' to return on Windows/Cygwin systems. A graceful shutdown solves that problem by itself without the need to kill the underlying ssh: Index: sftp.c =================================================================== RCS file: /cvs/openssh_cvs/sftp.c,v retrieving revision 1.4 diff -u -p -r1.4 sftp.c --- sftp.c 2001/02/09 13:40:04 1.4 +++ sftp.c 2001/02/18 16:59:27 @@ -246,11 +246,18 @@ main(int argc, char **argv) interactive_loop(in, out); +#if defined(HAVE_CYGWIN) && !defined(USE_PIPES) + shutdown(in, SHUT_RDWR); + shutdown(out, SHUT_RDWR); +#endif + close(in); close(out); +#if !defined(HAVE_CYGWIN) if (kill(sshpid, SIGHUP) == -1) fatal("Couldn't terminate ssh process: %s", strerror(errno)); +#endif if (waitpid(sshpid, NULL, 0) == -1) fatal("Couldn't wait for ssh process: %s", strerror(errno)); Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From stevesk at sweden.hp.com Thu Feb 22 21:08:52 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Thu, 22 Feb 2001 11:08:52 +0100 (MET) Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: Message-ID: On Thu, 22 Feb 2001, Pekka Savola wrote: : On Thu, 22 Feb 2001 mouring at etoh.eviladmin.org wrote: : > Anything else I'm missing for brokeness that was introduced between : > 2.3.0p1 and 2.5.1p1 that needs to be corrected? I'm expecting that : > 2.5.1p2 will stand for a long time. So speak up now. I want to put p2 : > to rest with the next week and half so we can catch back up with the : > OpenBSD tree and head on to bigger and better problems. =) : : Not exactly brokenness, but sshd -t functionality (patch here yesterday) : would be very nice to have to ease the transition to 2.5.x. if markus picks that up it would be >2.5.1, which means it shouldn't be in a 2.5.1p2. it would create much confusion if 2.5.1p had base changes and fixes that are not in openbsd 2.5.1. From dws at ee.ethz.ch Thu Feb 22 21:09:23 2001 From: dws at ee.ethz.ch (David Schweikert) Date: Thu, 22 Feb 2001 11:09:23 +0100 Subject: Lets try this push again.. 2.5.1p2 bugs left. Message-ID: <20010222110923.A3080@ee.ethz.ch> > 1) Solaris/Redhat/HPUX session.c patch. I've not seen a ya or na on > Kevin's pam patch from the Solaris group. sshd works for me with that patch (on Solaris 2.6 with PAM). Cheers, David -- _ __| |___ David Schweikert / _` / __| IT Support Group, EE-Dept, ETH-Zurich | (_| \__ \ Tel: +41(0)1-6327019 Room: ETL F24.1 \__,_|___/ http://ee-staff.ethz.ch/~dws From Markus.Friedl at informatik.uni-erlangen.de Thu Feb 22 21:26:06 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 22 Feb 2001 11:26:06 +0100 Subject: Packet integrity error. (34) In-Reply-To: <802569F8.0054AEAA.00@d06mta05.portsmouth.uk.ibm.com>; from douglas.manton@uk.ibm.com on Mon, Feb 19, 2001 at 03:24:54PM +0000 References: <200102220000.TAA09881@syrinx.oankali.net> <802569F8.0054AEAA.00@d06mta05.portsmouth.uk.ibm.com> Message-ID: <20010222112605.A19403@faui02.informatik.uni-erlangen.de> could you please try this patch? -m -------------- next part -------------- An embedded message was scrubbed... From: Markus Friedl Subject: no subject Date: Thu, 22 Feb 2001 01:36:49 -0700 (MST) Size: 2100 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010222/0a04a676/attachment.mht From Markus.Friedl at informatik.uni-erlangen.de Thu Feb 22 21:27:48 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 22 Feb 2001 11:27:48 +0100 Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: <20010222100103.F908@cygbert.vinschen.de>; from vinschen@redhat.com on Thu, Feb 22, 2001 at 10:01:03AM +0100 References: <20010222100103.F908@cygbert.vinschen.de> Message-ID: <20010222112748.B19403@faui02.informatik.uni-erlangen.de> is this really CYWIN only? On Thu, Feb 22, 2001 at 10:01:03AM +0100, Corinna Vinschen wrote: > =================================================================== > RCS file: /cvs/openssh_cvs/sftp.c,v > retrieving revision 1.4 > diff -u -p -r1.4 sftp.c > --- sftp.c 2001/02/09 13:40:04 1.4 > +++ sftp.c 2001/02/18 16:59:27 > @@ -246,11 +246,18 @@ main(int argc, char **argv) > > interactive_loop(in, out); > > +#if defined(HAVE_CYGWIN) && !defined(USE_PIPES) > + shutdown(in, SHUT_RDWR); > + shutdown(out, SHUT_RDWR); > +#endif > + > close(in); > close(out); > > +#if !defined(HAVE_CYGWIN) > if (kill(sshpid, SIGHUP) == -1) > fatal("Couldn't terminate ssh process: %s", strerror(errno)); > +#endif > > if (waitpid(sshpid, NULL, 0) == -1) > fatal("Couldn't wait for ssh process: %s", strerror(errno)); > > > Corinna > > -- > Corinna Vinschen > Cygwin Developer > Red Hat, Inc. > mailto:vinschen at redhat.com From appro at fy.chalmers.se Thu Feb 22 21:32:57 2001 From: appro at fy.chalmers.se (Andy Polyakov) Date: Thu, 22 Feb 2001 11:32:57 +0100 Subject: sftp-server and chown References: Message-ID: <3A94EAD9.FA4E60A2@fy.chalmers.se> > I have a lot of quarms with how ssh.com designed their sftp client in > windows. It's broken and horrible. But people want to and do use it anyway. > And I don't feel we should remove a > feature because a company can't figure out how to write a correct sftp > client. Catering to broken software is never a valid solution. Examine sftp-client.c and note 'a.flags &= ~SSH2_FILEXFER_ATTR_UIDGID;' which basically does what I suggest and acknowledges the standpoint. The catch is that it's done in wrong place and that it should be done on server side, not client. The fact that it guards against broken clients is a side effect, not goal. Andy. From appro at fy.chalmers.se Thu Feb 22 22:59:25 2001 From: appro at fy.chalmers.se (Andy Polyakov) Date: Thu, 22 Feb 2001 12:59:25 +0100 Subject: X11 display issues References: <3A93D8B6.84CFC7AC@fy.chalmers.se> <20010221161328.C7296@faui02.informatik.uni-erlangen.de> <3A940D0F.3919117F@fy.chalmers.se> <20010221214106.B9635@folly> Message-ID: <3A94FF1D.9BCC93EC@fy.chalmers.se> > > > oh yes, this is a problem. i will probably change the sshd-X11-proxy > > > from internet to unix domain sockets. > > > > Say you run ssh against firewall in order to run X11 application on > > computer behind the firewall. UNIX socket would kill the idea... > > well you can ssh from the firewall to the next machine. well, what if it doesn't have ssh (or you want to login with xdmcp). yes, i realize that it might be too odd to really care about, but that's the only way to keep the design versatile. > i don't like the idea of having the X11 socket listen to inaddr_any. in firewall case you don't really have a choice as you don't know in advance where does x11 traffic come from. SSHSCI addresses the issue by establishing separate access policy with libwrap. > > > > To make it fool-proof I suggest to set DISPLAY to the interface's > > > > address the user has reached the system in question through. > > > > > > I tried this before, but it does not work since it uses AF_INET6 if > > > i connect by > > > $ ssh -X ::1 > > > > Does libX11 talk IPv6 at all? > > no, this is the problem. your patch breaks x11-fwd if i connect > to an ipv6 address. actually my original idea (for ssh-1.2.2x) was to *list* interfaces and that's what one can do instead of totally relying on getsockname. i.e. whenever getsockname returns IPv6, list interfaces (with SIOCGIFCONF ioctl, works even under CYGWIN:-) and pick first non loopback IPv4 interface for DISPLAY. and whenever libX11 starts speaking IPv6, switch totally to getsockname. something like following. cheers. a. /* and now something completely different:-) */ { struct sockaddr_storage me; socklen_t melen = sizeof(me); char h_name[NI_MAXHOST]; if (getsockname(packet_get_connection_in(), (struct sockaddr *)&me, &melen) != 0) { error("[X11-broken-fwd] Unable to getsockname"); packet_send_debug("[X11-broken-fwd] Unable to getsockname"); shutdown(sock, SHUT_RDWR); close(sock); return NULL; } #ifdef SIOCGIFCONF if (me.ss_family != AF_INET) { int s; struct sockaddr_in *sin; struct ifconf ifc; struct ifreq *ifr; char *ifreqs; int ifrn; if ((s=socket (AF_INET,SOCK_DGRAM,0)) < 0) fatal ("Unable to create socket: %s\n", strerror(errno)); #ifdef SIOCGIFNUM if (ioctl (s,SIOCGIFNUM,&ifrn) < 0) fatal ("Unable to SIOCGIFNUM: %s\n", strerror(errno)); #else ifrn = 64; #endif ifc.ifc_len = sizeof(struct ifreq)*ifrn; ifc.ifc_buf = ifreqs = xmalloc (ifc.ifc_len); if (ioctl (s,SIOCGIFCONF,&ifc) < 0) fatal ("Unable to SIOCGIFCONF: %s\n", strerror(errno)); ifr = ifc.ifc_req; ifrn = ifc.ifc_len/sizeof(struct ifreq); for (; ifrn--; ifr++) { if (ioctl (s,SIOCGIFFLAGS,ifr) < 0) continue; if (!(ifr->ifr_flags&IFF_UP)) continue; #ifdef IFF_UNNUMBERED if (ifr->ifr_flags&IFF_UNNUMBERED) continue; #endif if (ioctl (s,SIOCGIFADDR, ifr) < 0) continue; sin = (struct sockaddr_in *)&ifr->ifr_addr; if (sin->sin_family != AF_INET) continue; if (sin->sin_addr.s_addr == INADDR_ANY) continue; if (sin->sin_addr.s_addr == INADDR_LOOPBACK) continue; memcpy((void *)me,(void *)sin,sizeof(*sin)); break; } xfree (ifreqs); close (s); } #endif #ifndef IPADDR_IN_DISPLAY if (getnameinfo ((void *)&me, melen, h_name,sizeof(h_name),NULL,0,NI_NAMEREQD) == 0) snprintf (display, sizeof(display),"%.*s:%d.%d", sizeof(h_name), h_name, display_number, screen_number); else #endif { if (me.ss_family != AF_INET) { error("[X11-broken-fwd] Unsupported protocol family"); packet_send_debug("[X11-broken-fwd] Unsupported protocol family"); shutdown(sock, SHUT_RDWR); close(sock); return NULL; } else snprintf(display, sizeof(display), "%.50s:%d.%d", inet_ntoa(((struct sockaddr_in *)&me)->sin_addr), display_number, screen_number); } } From douglas.manton at uk.ibm.com Thu Feb 22 23:05:51 2001 From: douglas.manton at uk.ibm.com (douglas.manton at uk.ibm.com) Date: Thu, 22 Feb 2001 12:05:51 +0000 Subject: Packet integrity error. (34) Message-ID: <802569FB.00431C12.00@d06mta05.portsmouth.uk.ibm.com> > could you please try this patch? > + screen_flag = (packet_get_protocol_flags() & > + SSH_PROTOFLAG_SCREEN_NUMBER; The compiler (IBM AIX VisualAge C++) threw out the above two lines. I added a close bracket and it compiled fine. Initial testing shows that this has solved the problem connecting from SecureCRT, using ssh1 and X11 forwarding. I will let you know if I experience any problems as I find them :-) Thanks for your help, -------------------------------------------------------- Doug Manton, AT&T EMEA Commercial Security Solutions E: demanton at att.com -------------------------------------------------------- "If privacy is outlawed, only outlaws will have privacy" From hartley at smart.net Fri Feb 23 00:10:05 2001 From: hartley at smart.net (Chuck Hartley) Date: Thu, 22 Feb 2001 08:10:05 -0500 Subject: Lets try this push again.. 2.5.1p2 bugs left. References: Message-ID: <3A950FAD.FF44C55C@smart.net> Under older Redhat (i.e. 5.2) the make fails. There was a message on here before I subscribed about it with no replies, but I am seeing it too. Looks like something from signal.h is not being included. I only looked at it briefly last night at about midnight so I didn't figure out exactly what is going on there. But I did want to confirm the problem the other guy was seeing. Chuck mouring at etoh.eviladmin.org wrote: > 2) Odd Redhat/Debian scp/ssh issues. .. I'm baffled, and I can't > replicate the bug. Nor have I seen anything remotely like it reported. > From mstone at cs.loyola.edu Fri Feb 23 00:51:48 2001 From: mstone at cs.loyola.edu (Michael Stone) Date: Thu, 22 Feb 2001 08:51:48 -0500 Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Feb 22, 2001 at 01:21:21AM -0600 References: Message-ID: <20010222085148.D28365@justice.loyola.edu> There's a patch I posted a while back that hasn't made it in yet. The form currently distributed breaks, e.g., "wall" on IRIX because the recorded tty is broken. The ifdef was introduced mistakenly some time ago. --- openssh-2.5.1p1/loginrec.c Tue Feb 20 16:19:17 2001 +++ openssh-2.5.1p1.orig//loginrec.c Mon Feb 5 07:42:17 2001 @@ -539,8 +539,13 @@ memset(dst, '\0', dstsize); /* Always skip prefix if present */ +#ifdef sgi + if (strncmp(src, "/dev/tty", 8) == 0) + src += 8; +#else if (strncmp(src, "/dev/", 5) == 0) src += 5; +#endif len = strlen(src); -- Mike Stone From pekkas at netcore.fi Fri Feb 23 01:34:44 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 22 Feb 2001 16:34:44 +0200 (EET) Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: <3A950FAD.FF44C55C@smart.net> Message-ID: On Thu, 22 Feb 2001, Chuck Hartley wrote: > Under older Redhat (i.e. 5.2) the make fails. There was a message on > here > before I subscribed about it with no replies, but I am seeing it too. > Looks > like something from signal.h is not being included. I only looked at it > briefly > last night at about midnight so I didn't figure out exactly what is > going > on there. But I did want to confirm the problem the other guy was > seeing. Red Hat Linux 5.2 (w/ all errata applied) builds just fine w/ 2.5.1p1 here. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From nrawling at firedrake.net Fri Feb 23 02:38:36 2001 From: nrawling at firedrake.net (Nathan Rawling) Date: Thu, 22 Feb 2001 10:38:36 -0500 (EST) Subject: Kerberos/GSSAPI support In-Reply-To: Message-ID: I'd like to publicly state that these patches work well for me, and I would like them incorporated into the distribution. The lack of K5 support in the OpenSSH distribution has been a continuing headache for me too. Nathan On Wed, 21 Feb 2001, Paul B. Henson wrote: > > Simon Wilkinson wrote: > > > My patches for SSH version 1 Kerberos 5 support (heavily based upon > > work done by Dan Kouril) are now available from > > http://www.sxw.org.uk/computing/patches/ Is there any interest in > > integrating these into the distribution? If so, I'd be happy to update > > them to the development version. > > I for one would definitely be interested in seeing these patches > incorporated into the distribution. one of the main reasons I have not yet > upgraded to openssh has been the lack of stable Kerberos 5 support. > > > -- -- Nathan Rawling nrawling at firedrake.net KC8BOA "Rome did not create a great empire by having meetings, they did it by killing all those who opposed them." From nojunk13 at yahoo.com Thu Feb 22 18:37:18 2001 From: nojunk13 at yahoo.com (Mike Seid) Date: Wed, 21 Feb 2001 23:37:18 -0800 (PST) Subject: Compile problems with 2.5.1p1 and older Linux boxes In-Reply-To: <20010221070440.67811.qmail@web10005.mail.yahoo.com> Message-ID: <20010222073718.32112.qmail@web10010.mail.yahoo.com> Pekka Savola wrote: : On Thu, 22 Feb 2001, Chuck Hartley wrote: : > Under older Redhat (i.e. 5.2) the make fails. There was a message on here : > before I subscribed about it with no replies, but I am seeing it too. Looks : > like something from signal.h is not being included. : : Red Hat Linux 5.2 (w/ all errata applied) builds just fine w/ 2.5.1p1 : here. That was me. It turns out that sigaction.h isn't included in signal.h for some reason. I had to manually insert it to get it to work. Someone else emailed me with the same problem. BTW: I'm using gcc-2.7.2.3. Mike __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/ From roth+openssh at feep.net Fri Feb 23 03:55:15 2001 From: roth+openssh at feep.net (Mark D. Roth) Date: Thu, 22 Feb 2001 10:55:15 -0600 Subject: PAM Service Name Patch Message-ID: <20010222105515.A6457@yorktown.isdn.uiuc.edu> I've attached a patch relative to OpenSSH 2.5.1p1 which sets the default PAM service name to __progname instead of the hard-coded value "sshd". This allows you to have multiple invokations of sshd under different names, each with its own PAM configuration. Please let me know if you have any questions or problems. -- Mark D. Roth http://www.feep.net/~roth/ -------------- next part -------------- diff -urN openssh-2.5.1p1-orig/auth-pam.c openssh-2.5.1p1/auth-pam.c --- openssh-2.5.1p1-orig/auth-pam.c Wed Feb 14 18:51:32 2001 +++ openssh-2.5.1p1/auth-pam.c Thu Feb 22 10:50:10 2001 @@ -33,6 +33,8 @@ #include "canohost.h" #include "readpass.h" +extern char *__progname; + RCSID("$Id: auth-pam.c,v 1.29 2001/02/15 00:51:32 djm Exp $"); #define NEW_AUTHTOK_MSG \ diff -urN openssh-2.5.1p1-orig/ssh.h openssh-2.5.1p1/ssh.h --- openssh-2.5.1p1-orig/ssh.h Mon Feb 5 09:43:59 2001 +++ openssh-2.5.1p1/ssh.h Thu Feb 22 10:50:20 2001 @@ -61,7 +61,7 @@ #define SSH_SERVICE_NAME "ssh" #if defined(USE_PAM) && !defined(SSHD_PAM_SERVICE) -# define SSHD_PAM_SERVICE "sshd" +# define SSHD_PAM_SERVICE __progname #endif /* From irving at samurai.sfo.dead-dog.com Fri Feb 23 04:12:26 2001 From: irving at samurai.sfo.dead-dog.com (Irving Popovetsky) Date: Thu, 22 Feb 2001 09:12:26 -0800 Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Feb 22, 2001 at 01:21:21AM -0600 References: Message-ID: <20010222091226.A26687@samurai.sfo.dead-dog.com> On Thu, Feb 22, 2001 at 01:21:21AM -0600, mouring at etoh.eviladmin.org wrote: > 1) Solaris/Redhat/HPUX session.c patch. I've not seen a ya or na on > Kevin's pam patch from the Solaris group. Ben, I can confirm that the reproducible problem with PAM and env/scp/etc is gone in the latest 02/22 SNAP, at least in my Solaris 7/8 environment. Everything else is looking great, too :) Thanks, -Irving From jfeise at ics.uci.edu Fri Feb 23 04:18:08 2001 From: jfeise at ics.uci.edu (Joachim Feise) Date: Thu, 22 Feb 2001 09:18:08 -0800 Subject: OpenSSH 2.5.1p1 on RH 5.2 experience Message-ID: <3A9549D0.36CAC724@ics.uci.edu> I decided to upgrade to OpenSSH 2.5.1p1/openssl 0.9.6 on all my Linux boxes. I ran into a compilation problem with the OpenSSH tarball on a machine running Redhat 5.2. I used the tarball since I don't like RPMs, and there is no binary RPM for RH 5.2 anyway. The error manifests itself in the openbsd-compat directory. This is the compiler warning: make[1]: Entering directory `/usr/home/jfeise/source/openssh-2.5.1p1/openbsd-compat' gcc -g -O2 -Wall -I/usr/local/openssl -I/usr/local/openssl -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c bsd-arc4random.c In file included from ../includes.h:39, from bsd-arc4random.c:25: /usr/include/signal.h:217: warning: `struct sigaction' declared inside parameter list /usr/include/signal.h:217: warning: its scope is only this definition or declaration, /usr/include/signal.h:217: warning: which is probably not what you want. /usr/include/signal.h:219: warning: `struct sigaction' declared inside parameter list And this is repeated with nearly all files in the openbsd-compat directory. Compilation finally stops in the main source directory with: gcc -g -O2 -Wall -I/usr/local/openssl -I/usr/local/openssl -I. -I./openbsd-compat -I. -DETCDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -DHAVE_CONFIG_H -c cli.c In file included from includes.h:39, from cli.c:1: /usr/include/signal.h:217: warning: `struct sigaction' declared inside parameter list /usr/include/signal.h:217: warning: its scope is only this definition or declaration, /usr/include/signal.h:217: warning: which is probably not what you want. /usr/include/signal.h:219: warning: `struct sigaction' declared inside parameter list cli.c: In function `cli_echo_disable': cli.c:67: `SIG_BLOCK' undeclared (first use this function) cli.c:67: (Each undeclared identifier is reported only once cli.c:67: for each function it appears in.) cli.c:71: sizeof applied to an incomplete type cli.c:72: invalid use of undefined type `struct sigaction' cli.c:73: warning: passing arg 2 of `sigaction' from incompatible pointer type cli.c:73: warning: passing arg 3 of `sigaction' from incompatible pointer type cli.c: In function `cli_echo_restore': cli.c:93: `SIG_SETMASK' undeclared (first use this function) cli.c:94: warning: passing arg 2 of `sigaction' from incompatible pointer type cli.c: At top level: cli.c:14: storage size of `nsa' isn't known cli.c:15: storage size of `osa' isn't known make: *** [cli.o] Error 1 I traced this down to a filename problem by analyzing the preprocessor output. The openbsd-compat directory contains sigaction.c and sigaction.h The includes.h file in the main source directory contains #include , which results in the inclusion of /usr/include/signal.h That file in turn contains #include , which *should* translate to /usr/include/sigaction.h. However, the sigaction.h file in the openbsd-compat directory is included instead. My workaround is to rename the sigaction.h file to bsd-sigaction.h and update the appropriate references to it: --- openbsd-compat.h.orig Thu Feb 22 08:50:50 2001 +++ openbsd-compat.h Thu Feb 22 08:56:03 2001 @@ -16,7 +16,7 @@ #include "mktemp.h" #include "daemon.h" #include "base64.h" -#include "sigaction.h" +#include "bsd-sigaction.h" #include "inet_aton.h" #include "inet_ntoa.h" #include "strsep.h" --- sigaction.c.orig Thu Feb 22 08:51:14 2001 +++ sigaction.c Thu Feb 22 08:56:24 2001 @@ -35,7 +35,7 @@ #include #include "config.h" -#include "sigaction.h" +#include "bsd-sigaction.h" /* This file provides sigaction() emulation using sigvec() */ /* Use only if this is non POSIX system */ Cheers, -Joe From mouring at etoh.eviladmin.org Fri Feb 23 05:19:22 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 22 Feb 2001 12:19:22 -0600 (CST) Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: <20010222091226.A26687@samurai.sfo.dead-dog.com> Message-ID: On Thu, 22 Feb 2001, Irving Popovetsky wrote: > On Thu, Feb 22, 2001 at 01:21:21AM -0600, mouring at etoh.eviladmin.org wrote: > > 1) Solaris/Redhat/HPUX session.c patch. I've not seen a ya or na on > > Kevin's pam patch from the Solaris group. > > Ben, > > I can confirm that the reproducible problem with PAM and env/scp/etc is > gone in the latest 02/22 SNAP, at least in my Solaris 7/8 environment. > > Everything else is looking great, too :) > That I knew.=) However I need conformation that the patch Kevin has submitted will work on Solaris. It's been verified on HP/UX and Redhat. - Ben From stevesk at sweden.hp.com Fri Feb 23 05:03:08 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Thu, 22 Feb 2001 19:03:08 +0100 (MET) Subject: PAM Service Name Patch In-Reply-To: <20010222105515.A6457@yorktown.isdn.uiuc.edu> Message-ID: On Thu, 22 Feb 2001, Mark D. Roth wrote: : I've attached a patch relative to OpenSSH 2.5.1p1 which sets the : default PAM service name to __progname instead of the hard-coded value : "sshd". This allows you to have multiple invokations of sshd under : different names, each with its own PAM configuration. : : Please let me know if you have any questions or problems. seems fine but i think #define SSHD_PAM_SERVICE should be moved to auth-pam.h. From tom at avatar.itc.nrcs.usda.gov Fri Feb 23 05:03:20 2001 From: tom at avatar.itc.nrcs.usda.gov (Tom Rudnick) Date: Thu, 22 Feb 2001 11:03:20 -0700 (MST) Subject: X11 display issues In-Reply-To: <20010221230543.C4656@greenie.muc.de> from "Gert Doering" at Feb 21, 2001 11:05:43 PM Message-ID: <200102221803.LAA27646@avatar.itc.nrcs.usda.gov> > On Wed, Feb 21, 2001 at 10:35:21AM -0600, William L. Jones wrote: > > Keep the Internet domain sockets at least for a few systems. Cray > > UNICOS X11 does not support unix domain sockets. > > > > Do both but configure unix domain sockets by default at let porters add a > > define to > > do Internet domain sockets instead of unix domain sockets. > > Seconded. SCO doesn't have unix domain sockets either, so please make > them optional. > > gert Unixware 2.x does have unix domain sockets, but the X11 implementation may not support them. Enabling X11 forwarding in the latest version on Unixware 2.x results in the following xauth error: /usr/X/bin/xauth: (stdin):2: bad display name "hostname/unix:10.0" in "add" command -Tom -- ----------------/---------------------------------------------- Tom Rudnick | USDA Natural Resources Conservation Service Fort Collins,CO | tom at avatar.itc.nrcs.usda.gov (970) 295-5427 ** The 3rd Millennium started Jan 1, 2001. see: ** ** http://aa.usno.navy.mil/AA/faq/docs/millennium.html ** -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From vinschen at redhat.com Fri Feb 23 05:04:55 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 22 Feb 2001 19:04:55 +0100 Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: <20010222112748.B19403@faui02.informatik.uni-erlangen.de>; from Markus.Friedl@informatik.uni-erlangen.de on Thu, Feb 22, 2001 at 11:27:48AM +0100 References: <20010222100103.F908@cygbert.vinschen.de> <20010222112748.B19403@faui02.informatik.uni-erlangen.de> Message-ID: <20010222190455.W908@cygbert.vinschen.de> On Thu, Feb 22, 2001 at 11:27:48AM +0100, Markus Friedl wrote: > is this really CYWIN only? I'm trying to be careful. If you ask me, I would care for calling shutdown always when USE_PIPES isn't defined. The `kill' might be Cygwin only problem. I don't know. Corinna > > On Thu, Feb 22, 2001 at 10:01:03AM +0100, Corinna Vinschen wrote: > > =================================================================== > > RCS file: /cvs/openssh_cvs/sftp.c,v > > retrieving revision 1.4 > > diff -u -p -r1.4 sftp.c > > --- sftp.c 2001/02/09 13:40:04 1.4 > > +++ sftp.c 2001/02/18 16:59:27 > > @@ -246,11 +246,18 @@ main(int argc, char **argv) > > > > interactive_loop(in, out); > > > > +#if defined(HAVE_CYGWIN) && !defined(USE_PIPES) > > + shutdown(in, SHUT_RDWR); > > + shutdown(out, SHUT_RDWR); > > +#endif > > + > > close(in); > > close(out); > > > > +#if !defined(HAVE_CYGWIN) > > if (kill(sshpid, SIGHUP) == -1) > > fatal("Couldn't terminate ssh process: %s", strerror(errno)); > > +#endif > > > > if (waitpid(sshpid, NULL, 0) == -1) > > fatal("Couldn't wait for ssh process: %s", strerror(errno)); > > > > > > Corinna > > > > -- > > Corinna Vinschen > > Cygwin Developer > > Red Hat, Inc. > > mailto:vinschen at redhat.com -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From stevesk at sweden.hp.com Fri Feb 23 05:12:00 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Thu, 22 Feb 2001 19:12:00 +0100 (MET) Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: <20010222085148.D28365@justice.loyola.edu> Message-ID: i'm confused, you want that code removed, because it's already there? you wanted the orig first in diff i'm guessing? On Thu, 22 Feb 2001, Michael Stone wrote: : There's a patch I posted a while back that hasn't made it in yet. The : form currently distributed breaks, e.g., "wall" on IRIX because the : recorded tty is broken. The ifdef was introduced mistakenly some time ago. : : --- openssh-2.5.1p1/loginrec.c Tue Feb 20 16:19:17 2001 : +++ openssh-2.5.1p1.orig//loginrec.c Mon Feb 5 07:42:17 2001 : @@ -539,8 +539,13 @@ : memset(dst, '\0', dstsize); : : /* Always skip prefix if present */ : +#ifdef sgi : + if (strncmp(src, "/dev/tty", 8) == 0) : + src += 8; : +#else : if (strncmp(src, "/dev/", 5) == 0) : src += 5; : +#endif : : len = strlen(src); From wendyp at cray.com Fri Feb 23 06:06:22 2001 From: wendyp at cray.com (Wendy Palm) Date: Thu, 22 Feb 2001 13:06:22 -0600 Subject: X11 display issues References: <3A93D8B6.84CFC7AC@fy.chalmers.se> <3A93D8B6.84CFC7AC@fy.chalmers.se> <4.2.0.58.20010221103229.01d44660@127.0.0.1> Message-ID: <3A95632E.901990F4@cray.com> along these lines, please add this patch to define a new define for all the systems who don't allow unix sockets (and some defines i need for the cray port anyway) (thanks to bill for writing them & sending them to me in the first place). i've got more patches for cray, but will send them slowly to make sure we don't break too much all at once (and please let me know if i send things incorrectly.) Index: openssh_cvs/defines.h =================================================================== RCS file: /cvs/openssh_cvs/defines.h,v retrieving revision 1.55 diff -r1.55 defines.h 141c141,145 < # error "16 bit int type not found." --- > # ifdef _CRAY > typedef long int16_t; > # else > # error "16 bit int type not found." > # endif /* _CRAY */ 145a150,152 > # ifdef _CRAY > typedef long int32_t; > # else 146a154 > # endif /* _CRAY */ 166c174,178 < # error "16 bit int type not found." --- > # ifdef _CRAY > typedef unsigned long u_int16_t; > # else > # error "16 bit int type not found." > # endif 171c183,187 < # error "32 bit int type not found." --- > # ifdef _CRAY > typedef unsigned long u_int32_t; > # else > # error "32 bit int type not found." > # endif 398a415,421 > #endif > > /* > * Some systems don't allow unix sockets with X11. > */ > #if defined(HAVE_CYGWIN)||defined(_CRAY) /* Unix sockets are not supported */ > #define NO_X11_UNIX_SOCKETS Index: session.c =================================================================== RCS file: /cvs/openssh_cvs/session.c,v retrieving revision 1.82 diff -r1.82 session.c 1369c1369 < #ifndef HAVE_CYGWIN /* Unix sockets are not supported */ --- > #ifndef NO_X11_UNIX_SOCKETS 1375c1375 < #endif --- > #endif /* NO_X11_UNIX_SOCKETS */ 1383c1383 < #ifndef HAVE_CYGWIN /* Unix sockets are not supported */ --- > #ifndef NO_X11_UNIX_SOCKETS 1388c1388 < #endif --- > #endif /* NO_X11_UNIX_SOCKETS */ "William L. Jones" wrote: > > Keep the Internet domain sockets at least for a few systems. Cray > UNICOS X11 does not support unix domain sockets. > > Do both but configure unix domain sockets by default at let porters add a > define to > do Internet domain sockets instead of unix domain sockets. > > Bill Jones > > At 04:13 PM 2/21/01 +0100, Markus Friedl wrote: > >On Wed, Feb 21, 2001 at 04:03:18PM +0100, Andy Polyakov wrote: > > > This also has been discussed in SSHSCI's SSH context. All SSH versions > > > (both SSHSCI and OpenSSH) derive value for DISPLAY variable from > > > `uname -n`. The problem is that the returned value is not necessarily > > > resolvable to a valid IP number which in turn might cause a failure. > > > >oh yes, this is a problem. i will probably change the sshd-X11-proxy > >from internet to unix domain sockets. > > > >libX is broken if i set DISPLAY=localhost:x.y and ignore any > >X cookies. > > > > > To make it fool-proof I suggest to set DISPLAY to the interface's > > > address the user has reached the system in question through. > > > >I tried this before, but it does not work since it uses AF_INET6 if > >i connect by > > $ ssh -X ::1 > > > >so it's not really acceptible. I'm still looking for a better > >solution... > > > >-markus -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From rob at hagopian.net Fri Feb 23 06:27:17 2001 From: rob at hagopian.net (Rob Hagopian) Date: Thu, 22 Feb 2001 14:27:17 -0500 (EST) Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) box In-Reply-To: Message-ID: Keep in mind that this isn't a workaround for people who don't use bash as a shell. This problem also exists on FreeBSD machines so I'm a bit suspicious that it's a Linux only problem? -Rob On Wed, 21 Feb 2001 mouring at etoh.eviladmin.org wrote: > > As stated before there is a linux bug on select() with no current patch > (but there is a work around.. I'd have to look it up since it did not make > it into the FAQ.) > > But the work around is: > > While browsing through bash's hugh manpage, I noticed that it has a > 'huponexit' option which will send SIGHUP to all interactive processes > when the shell exits. > > I have tested this and it does resolve the hanging at logout without > causing race conditions. I now have a "shopt -s huponexit" in my > /etc/bashrc and it works beautifully. > > (Who do I submit this to so it gets into the FAQ on the openssh.com site? > This problem is going to be around for a while. =) > > > thanks > > > - Ben > > From jmknoble at jmknoble.cx Fri Feb 23 06:38:19 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Thu, 22 Feb 2001 14:38:19 -0500 Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Feb 22, 2001 at 01:21:21AM -0600 References: Message-ID: <20010222143819.C10394@quipu.half.pint-stowp.cx> Circa 2001-Feb-22 01:21:21 -0600 dixit mouring at etoh.eviladmin.org: : : Things that are still outstanding: [...] 4) Figure out whether we want to update contrib/redhat/sshd.init or not. 5) Patch to make sshd log to stderr (-L switch) for use with djb's daemontools (http://cr.yp.to/daemontools.html). Can't remember whose that was [searches...] ah, here we go: Date: Wed, 21 Feb 2001 12:10:07 -0800 From: Jos Backus Subject: Re: Portable OpenSSH 2.5.1p1: daemontools-aware? Message-ID: <20010221121007.A94515 at lizzy.bugworks.com> -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From jmknoble at jmknoble.cx Fri Feb 23 06:41:51 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Thu, 22 Feb 2001 14:41:51 -0500 Subject: X11 display issues In-Reply-To: <3A95632E.901990F4@cray.com>; from wendyp@cray.com on Thu, Feb 22, 2001 at 01:06:22PM -0600 References: <3A93D8B6.84CFC7AC@fy.chalmers.se> <3A93D8B6.84CFC7AC@fy.chalmers.se> <4.2.0.58.20010221103229.01d44660@127.0.0.1> <3A95632E.901990F4@cray.com> Message-ID: <20010222144151.D10394@quipu.half.pint-stowp.cx> Circa 2001-Feb-22 13:06:22 -0600 dixit Wendy Palm: : (and please let me know if i send things incorrectly.) : : Index: openssh_cvs/defines.h : =================================================================== : RCS file: /cvs/openssh_cvs/defines.h,v : retrieving revision 1.55 : diff -r1.55 defines.h : 141c141,145 : < # error "16 bit int type not found." : --- : > # ifdef _CRAY : > typedef long int16_t; [etc.] Wendy, you'll want to resend those patches using 'diff -u' (if you have GNU diffutils installed) or at least 'diff -c' (if you don't). Patches containing unified or context diffs are much easier both for humans to read and for 'patch' to apply. -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From pekkas at netcore.fi Fri Feb 23 06:41:50 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 22 Feb 2001 21:41:50 +0200 (EET) Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) box In-Reply-To: Message-ID: On Thu, 22 Feb 2001, Rob Hagopian wrote: > Keep in mind that this isn't a workaround for people who don't use bash as > a shell. This problem also exists on FreeBSD machines so I'm a bit > suspicious that it's a Linux only problem? I can't reproduce this with sshd-2.5.1p1 running on FreeBSD 4.2-STABLE. The problem may not be 100% limited to Linux, but BSD shouldn't be affected at least. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From jmknoble at jmknoble.cx Fri Feb 23 06:44:09 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Thu, 22 Feb 2001 14:44:09 -0500 Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: ; from pekkas@netcore.fi on Thu, Feb 22, 2001 at 11:09:54AM +0200 References: Message-ID: <20010222144409.E10394@quipu.half.pint-stowp.cx> Circa 2001-Feb-22 11:09:54 +0200 dixit Pekka Savola: : On Thu, 22 Feb 2001 mouring at etoh.eviladmin.org wrote: : > Anything else I'm missing for brokeness that was introduced between : > 2.3.0p1 and 2.5.1p1 that needs to be corrected? I'm expecting that : > 2.5.1p2 will stand for a long time. So speak up now. I want to put p2 : > to rest with the next week and half so we can catch back up with the : > OpenBSD tree and head on to bigger and better problems. =) : : Not exactly brokenness, but sshd -t functionality (patch here yesterday) : would be very nice to have to ease the transition to 2.5.x. That patch is in: Date: Wed, 21 Feb 2001 19:11:26 +0200 (EET) From: Pekka Savola Subject: Re: sshd -t to test configuration file syntax? Message-ID: -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From rob at hagopian.net Fri Feb 23 06:44:39 2001 From: rob at hagopian.net (Rob Hagopian) Date: Thu, 22 Feb 2001 14:44:39 -0500 (EST) Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) box In-Reply-To: Message-ID: Actually I may be mixing two different problems. The 'sleep 20&' aka 'httpd restart' problem I have seen with FreeBSD 3.x; the scp problem I have not. -Rob On Thu, 22 Feb 2001, Pekka Savola wrote: > On Thu, 22 Feb 2001, Rob Hagopian wrote: > > > Keep in mind that this isn't a workaround for people who don't use bash as > > a shell. This problem also exists on FreeBSD machines so I'm a bit > > suspicious that it's a Linux only problem? > > I can't reproduce this with sshd-2.5.1p1 running on FreeBSD 4.2-STABLE. > > The problem may not be 100% limited to Linux, but BSD shouldn't be > affected at least. > > From mouring at etoh.eviladmin.org Fri Feb 23 07:40:17 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 22 Feb 2001 14:40:17 -0600 (CST) Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) box In-Reply-To: Message-ID: On Thu, 22 Feb 2001, Rob Hagopian wrote: > Keep in mind that this isn't a workaround for people who don't use bash as > a shell. This problem also exists on FreeBSD machines so I'm a bit > suspicious that it's a Linux only problem? > -Rob > It is? As of when? I don't remember FreeBSD being on the list of infected platforms.. hmm... - Ben From mouring at etoh.eviladmin.org Fri Feb 23 07:42:15 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 22 Feb 2001 14:42:15 -0600 (CST) Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: <20010222143819.C10394@quipu.half.pint-stowp.cx> Message-ID: On Thu, 22 Feb 2001, Jim Knoble wrote: > Circa 2001-Feb-22 01:21:21 -0600 dixit mouring at etoh.eviladmin.org: > > : > : Things that are still outstanding: > > [...] > > 4) Figure out whether we want to update contrib/redhat/sshd.init or > not. > Hmm..I'd rather hold off on any major changes unless I know they will not bite us in the ass later on. > 5) Patch to make sshd log to stderr (-L switch) for use with djb's > daemontools (http://cr.yp.to/daemontools.html). Can't remember > whose that was [searches...] ah, here we go: > this would be considered a feature and should be held off until after 2.5.1p2. The whole point of 2.5.1p2 is to finish stablizing out the rushed 2.5.1p1 release.=) Nothing more..nothing less. - Ben From wendyp at cray.com Fri Feb 23 07:15:22 2001 From: wendyp at cray.com (Wendy Palm) Date: Thu, 22 Feb 2001 14:15:22 -0600 Subject: X11 display issues References: <3A93D8B6.84CFC7AC@fy.chalmers.se> <3A93D8B6.84CFC7AC@fy.chalmers.se> <4.2.0.58.20010221103229.01d44660@127.0.0.1> <3A95632E.901990F4@cray.com> <20010222144151.D10394@quipu.half.pint-stowp.cx> Message-ID: <3A95735A.DE51804D@cray.com> you are, of course, correct. i knew that, but did it wrong anyway. here is a resend, in a more proper format- --- defines.h.orig Thu Feb 22 13:53:46 2001 +++ defines.h Thu Feb 22 14:06:06 2001 @@ -138,12 +138,20 @@ # if (SIZEOF_SHORT_INT == 2) typedef short int int16_t; # else -# error "16 bit int type not found." +# ifdef _CRAY +typedef long int16_t; +# else +# error "16 bit int type not found." +# endif /* _CRAY */ # endif # if (SIZEOF_INT == 4) typedef int int32_t; # else -# error "32 bit int type not found." +# ifdef _CRAY +typedef long int32_t; +# else +# error "32 bit int type not found." +# endif /* _CRAY */ # endif #endif @@ -163,12 +171,20 @@ # if (SIZEOF_SHORT_INT == 2) typedef unsigned short int u_int16_t; # else -# error "16 bit int type not found." +# ifdef _CRAY +typedef unsigned long u_int16_t; +# else +# error "16 bit int type not found." +# endif # endif # if (SIZEOF_INT == 4) typedef unsigned int u_int32_t; # else -# error "32 bit int type not found." +# ifdef _CRAY +typedef unsigned long u_int32_t; +# else +# error "32 bit int type not found." +# endif # endif # endif #endif @@ -396,6 +412,13 @@ #ifndef GETPGRP_VOID # define getpgrp() getpgrp(0) +#endif + +/* + * Some systems don't allow unix sockets with X11. + */ +#if defined(HAVE_CYGWIN)||defined(_CRAY) /* Unix sockets are not supported */ +#define NO_X11_UNIX_SOCKETS #endif /* ========================================================= --- session.c.orig Thu Feb 22 13:53:47 2001 +++ session.c Thu Feb 22 13:56:19 2001 @@ -540,6 +540,7 @@ do_child(command, pw, NULL, s->display, s->auth_proto, s->auth_data, NULL); /* NOTREACHED */ } + #ifdef HAVE_CYGWIN if (is_winnt) cygwin_set_impersonation_token(INVALID_HANDLE_VALUE); @@ -639,6 +640,7 @@ s->auth_data, s->tty); /* NOTREACHED */ } + #ifdef HAVE_CYGWIN if (is_winnt) cygwin_set_impersonation_token(INVALID_HANDLE_VALUE); @@ -1366,13 +1368,13 @@ "Running %.100s add %.100s %.100s %.100s\n", options.xauth_location, display, auth_proto, auth_data); -#ifndef HAVE_CYGWIN /* Unix sockets are not supported */ +#ifndef NO_X11_UNIX_SOCKETS if (screen != NULL) fprintf(stderr, "Adding %.*s/unix%s %s %s\n", (int)(screen-display), display, screen, auth_proto, auth_data); -#endif +#endif /* NO_X11_UNIX_SOCKETS */ } snprintf(cmd, sizeof cmd, "%s -q -", options.xauth_location); @@ -1380,12 +1382,12 @@ if (f) { fprintf(f, "add %s %s %s\n", display, auth_proto, auth_data); -#ifndef HAVE_CYGWIN /* Unix sockets are not supported */ +#ifndef NO_X11_UNIX_SOCKETS if (screen != NULL) fprintf(f, "add %.*s/unix%s %s %s\n", (int)(screen-display), display, screen, auth_proto, auth_data); -#endif +#endif /* NO_X11_UNIX_SOCKETS */ pclose(f); } else { fprintf(stderr, "Could not run %s\n", Jim Knoble wrote: > Wendy, you'll want to resend those patches using 'diff -u' (if you have > GNU diffutils installed) or at least 'diff -c' (if you don't). Patches > containing unified or context diffs are much easier both for humans to > read and for 'patch' to apply. > > -- > jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From devon at admin2.gisnetworks.com Fri Feb 23 07:32:27 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Thu, 22 Feb 2001 12:32:27 -0800 Subject: Solaris and Latest snapshot (2001-02-21) (fwd) References: Message-ID: <002801c09d0e$925aa190$1900a8c0@devn> okay, i reversed that patch out and solaris 7 still works fine with pam... devon ----- Original Message ----- From: To: Sent: Thursday, February 22, 2001 10:43 AM Subject: Re: Solaris and Latest snapshot (2001-02-21) (fwd) > > > ---------- Forwarded message ---------- > Date: Wed, 21 Feb 2001 17:54:19 +0100 (MET) > From: Kevin Steves > To: mouring at etoh.eviladmin.org > Cc: Devon Bleak , openssh-unix-dev at mindrot.org > Subject: Re: Solaris and Latest snapshot (2001-02-21) > > On Tue, 20 Feb 2001 mouring at etoh.eviladmin.org wrote: > : There is only two sets of pam patches around that date. One is a > : suggestion to clean up PAM space. Which I can't see any fault. And this > : one which stated it was for solaris. Can you apply this reverse and see > : if this gets us closer to fixing this? Or if the problem still exists? > > hp-ux broke with that. i just commited the following, which takes us > back to before the first pam change: > > - (stevesk) session.c: back out to where we were before: > - (djm) Move PAM session initialisation until after fork in sshd. Patch > from Nalin Dahyabhai > > i have done rudimentary testing on hp-ux and redhat. can solaris users > test this? we can troubleshoot after p2. > > Index: session.c > =================================================================== > RCS file: /var/cvs/openssh/session.c,v > retrieving revision 1.80 > diff -u -r1.80 session.c > --- session.c 2001/02/21 05:53:33 1.80 > +++ session.c 2001/02/21 16:28:40 > @@ -481,6 +481,10 @@ > > session_proctitle(s); > > +#ifdef USE_PAM > + do_pam_setcred(); > +#endif /* USE_PAM */ > + > /* Fork the child. */ > if ((pid = fork()) == 0) { > /* Child. Reinitialize the log since the pid has changed. */ > @@ -593,6 +597,11 @@ > ptyfd = s->ptyfd; > ttyfd = s->ttyfd; > > +#ifdef USE_PAM > + do_pam_session(pw->pw_name, s->tty); > + do_pam_setcred(); > +#endif /* USE_PAM */ > + > /* Fork the child. */ > if ((pid = fork()) == 0) { > /* Child. Reinitialize the log because the pid has changed. */ > @@ -1142,11 +1151,6 @@ > #ifdef HAVE_LOGIN_CAP > shell = login_getcapstr(lc, "shell", (char *)shell, (char *)shell); > #endif > - > -#ifdef USE_PAM > - do_pam_session(pw->pw_name, ttyname); > - do_pam_setcred(); > -#endif /* USE_PAM */ > > #ifdef AFS > /* Try to get AFS tokens for the local cell. */ > > > From jmknoble at jmknoble.cx Fri Feb 23 07:55:52 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Thu, 22 Feb 2001 15:55:52 -0500 Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Feb 22, 2001 at 02:42:15PM -0600 References: <20010222143819.C10394@quipu.half.pint-stowp.cx> Message-ID: <20010222155552.G10394@quipu.half.pint-stowp.cx> Circa 2001-Feb-22 14:42:15 -0600 dixit mouring at etoh.eviladmin.org: : On Thu, 22 Feb 2001, Jim Knoble wrote: : : > 4) Figure out whether we want to update contrib/redhat/sshd.init or : > not. : > : Hmm..I'd rather hold off on any major changes unless I know they will : not bite us in the ass later on. There's a minimal set of changes that i suggested earlier on (last week, maybe?) which may still be useful in this context. [Searches...] Ah, here we go: Date: Fri, 16 Feb 2001 14:48:07 -0500 From: Jim Knoble Subject: PATCH: make contrib/redhat/sshd.init work with older RH releases Message-ID: <20010216144807.A25687 at quipu.half.pint-stowp.cx> and: Date: Fri, 16 Feb 2001 15:07:12 -0500 From: Jim Knoble Subject: Re: PATCH: make contrib/redhat/sshd.init work with older RH releases Message-ID: <20010216150712.C25687 at quipu.half.pint-stowp.cx> : > 5) Patch to make sshd log to stderr (-L switch) for use with djb's : : this would be considered a feature and should be held off until : after 2.5.1p2. You're quite right; i was thinking in "next release" mode when i wrote that.... -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From mstone at cs.loyola.edu Fri Feb 23 07:56:26 2001 From: mstone at cs.loyola.edu (Michael Stone) Date: Thu, 22 Feb 2001 15:56:26 -0500 Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: ; from stevesk@sweden.hp.com on Thu, Feb 22, 2001 at 07:12:00PM +0100 References: <20010222085148.D28365@justice.loyola.edu> Message-ID: <20010222155626.H28365@justice.loyola.edu> On Thu, Feb 22, 2001 at 07:12:00PM +0100, Kevin Steves wrote: > i'm confused, you want that code removed, because it's already there? > you wanted the orig first in diff i'm guessing? Doh! Yes, that should, of course, be diff -u openssh-2.5.1p1.orig/loginrec.c openssh-2.5.1p1/loginrec.c --- openssh-2.5.1p1.orig/loginrec.c Mon Feb 5 07:42:17 2001 +++ openssh-2.5.1p1/loginrec.c Tue Feb 20 16:19:17 2001 @@ -539,13 +539,8 @@ memset(dst, '\0', dstsize); /* Always skip prefix if present */ -#ifdef sgi - if (strncmp(src, "/dev/tty", 8) == 0) - src += 8; -#else if (strncmp(src, "/dev/", 5) == 0) src += 5; -#endif len = strlen(src); -- Mike Stone From ai at bulinfo.net Fri Feb 23 08:58:02 2001 From: ai at bulinfo.net (Alexander Ivanchev) Date: Thu, 22 Feb 2001 22:58:02 +0100 Subject: Strange behavior with 2.5.1 installed over 2.3.0 Message-ID: Hello. I've recently installed OpenSSH 2.5.1p1 over a working installation of 2.3.0p1 (both SSH1 and SSH2) and oddly enough I lost SSH2 support. The banner string states SSH-1.5-OpenSSH_2.5.1p1, which needless to say limits me to SSH1... I haven't yet bothered to check any conf files, but since I haven't really made any changes this behavior seems strange to me... Anyway, hope I'm not wasting anybody's time, Regards From Markus.Friedl at informatik.uni-erlangen.de Fri Feb 23 08:04:01 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 22 Feb 2001 22:04:01 +0100 Subject: Strange behavior with 2.5.1 installed over 2.3.0 In-Reply-To: ; from ai@bulinfo.net on Thu, Feb 22, 2001 at 10:58:02PM +0100 References: Message-ID: <20010222220401.A14531@faui02.informatik.uni-erlangen.de> add HostKey /etc/ssh_host_dsa_key to sshd_config please read the annoucement, too. (this should be in the FAQ soon) -markus On Thu, Feb 22, 2001 at 10:58:02PM +0100, Alexander Ivanchev wrote: > Hello. > > I've recently installed OpenSSH 2.5.1p1 over a working installation of > 2.3.0p1 (both SSH1 and SSH2) and oddly enough I lost SSH2 support. The > banner string states SSH-1.5-OpenSSH_2.5.1p1, which needless to say limits > me to SSH1... I haven't yet bothered to check any conf files, but since I > haven't really made any changes this behavior seems strange to me... Anyway, > hope I'm not wasting anybody's time, > > Regards > > From gjewell at cnnxn.com Fri Feb 23 05:33:29 2001 From: gjewell at cnnxn.com (Greg Jewell) Date: Thu, 22 Feb 2001 11:33:29 -0700 Subject: Problems with sftp under SCO OpenServer Message-ID: Hello, I compiled OpenSSH 2.5.1p1 for SCO OpenServer 5.0.5, HPUX B.11.00, and SunOS 5.7. When I sftp into the HP or Sun box, everything works fine. However, whenever I sftp into the OpenServer box, all remote filenames are shown as "(null)". File sizes, owners, etc. display properly. This behavior is exhibited from all origination points. OpenSSH was configured with identical parameters (apart from the path to xauth), and compiled with OpenSSL 0.9.6 and zlib-1.1.3 under all systems. Thanks, Greg Jewell From thomas at mail.phy.ornl.gov Fri Feb 23 06:49:39 2001 From: thomas at mail.phy.ornl.gov (charles thomas) Date: Thu, 22 Feb 2001 14:49:39 -0500 Subject: PATH munged on SGI IRIX 6.5 machines Message-ID: <3A956D53.6F4A2578@mail.phy.ornl.gov> Built openssh 2.5.1p1 on SGI IRIX 6.5 machines. When users connect to them via ssh, the PATH variable appears to not be initialized correctly. "echo $PATH" produces this short list: "/usr/bin /bin /usr/sbin /sbin". If you have a "setenv PATH" command in your .cshrc it appears to be ignored. If you have a "set path" it works correctly. If you have no "setenv PATH" or "set path" in your .cshrc, you get the short list above. When you login via telnet the PATH appears to be set correctly. -- +==========================+ | Charles Thomas | | System Manager | | Physics Division | | Oak Ridge Natl. Lab. | | thomas at mail.phy.ornl.gov | | (865)576-7390 | +==========================+ From jones at hpc.utexas.edu Fri Feb 23 08:16:13 2001 From: jones at hpc.utexas.edu (William L. Jones) Date: Thu, 22 Feb 2001 15:16:13 -0600 Subject: Strange behavior with 2.5.1 installed over 2.3.0 In-Reply-To: Message-ID: <4.2.0.58.20010222151252.00a1f890@127.0.0.1> In your sshd_config file make sure you have a "hostkey" line for each host key like the following: HostKey /etc/ssh_host_key HostKey /etc/ssh_host_dsa_key HostKey /etc/ssh_host_rsa_key At 10:58 PM 2/22/01 +0100, Alexander Ivanchev wrote: >Hello. > >I've recently installed OpenSSH 2.5.1p1 over a working installation of >2.3.0p1 (both SSH1 and SSH2) and oddly enough I lost SSH2 support. The >banner string states SSH-1.5-OpenSSH_2.5.1p1, which needless to say limits >me to SSH1... I haven't yet bothered to check any conf files, but since I >haven't really made any changes this behavior seems strange to me... Anyway, >hope I'm not wasting anybody's time, > > Regards From stevesk at sweden.hp.com Fri Feb 23 08:23:49 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Thu, 22 Feb 2001 22:23:49 +0100 (MET) Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: <20010222155626.H28365@justice.loyola.edu> Message-ID: On Thu, 22 Feb 2001, Michael Stone wrote: : On Thu, Feb 22, 2001 at 07:12:00PM +0100, Kevin Steves wrote: : > i'm confused, you want that code removed, because it's already there? : > you wanted the orig first in diff i'm guessing? : : Doh! Yes, that should, of course, be ok, i made that change. can you verify? thanks. From markus.friedl at informatik.uni-erlangen.de Fri Feb 23 06:41:18 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 22 Feb 2001 20:41:18 +0100 Subject: sftp-server and chown In-Reply-To: <3A94EAD9.FA4E60A2@fy.chalmers.se>; from appro@fy.chalmers.se on Thu, Feb 22, 2001 at 11:32:57AM +0100 References: <3A94EAD9.FA4E60A2@fy.chalmers.se> Message-ID: <20010222204118.B8831@folly> On Thu, Feb 22, 2001 at 11:32:57AM +0100, Andy Polyakov wrote: > > I have a lot of quarms with how ssh.com designed their sftp client in > > windows. It's broken and horrible. > > But people want to and do use it anyway. > > > And I don't feel we should remove a > > feature because a company can't figure out how to write a correct sftp > > client. Catering to broken software is never a valid solution. > > Examine sftp-client.c and note 'a.flags &= ~SSH2_FILEXFER_ATTR_UIDGID;' this is because the client does not want to update the uid after a file is uploaded. he just want's to update the timestamp -> not at all related to you suggestion. please tell ietf-ssh about your problems with the current draft. > which basically does what I suggest and acknowledges the standpoint. The > catch is that it's done in wrong place and that it should be done on > server side, not client. The fact that it guards against broken clients > is a side effect, not goal. > > Andy. From Frank.Crawford at ac3.com.au Thu Feb 22 15:39:24 2001 From: Frank.Crawford at ac3.com.au (Frank Crawford) Date: Thu, 22 Feb 2001 15:39:24 +1100 Subject: Problem with OpenSSH 2.3.0p1/2.5.1p1 and AIX Message-ID: <3A9497FC.FDF13F58@ac3.com.au> We have come across a problem with OpenSSH 2.3.0p1 (and still in 2.5.1p1) which affect authentication on an AIX 4.3 system. The code in auth-passwd.c at line 168 reads: #ifdef WITH_AIXAUTHENTICATE return (authenticate(pw->pw_name,password,&reenter,&authmsg) == 0); #endif however, the AIX manual page for "authenticate" states: "The authenticate subroutine maintains requirements users must satisfy to be authenticated to the system. It is a recallable interface that prompts for the user's name and password. The user must supply a character string at the prompt issued by the Message parameter. The Response parameter returns the user's response to the authenticate subroutine. The calling program makes no assumptions about the number of prompt messages the user must satisfy for authentication. The Reenter parameter remains a nonzero value until the user satisfies all prompt messages or answers incorrectly. Once the Reenter parameter is zero, the return code signals whether authentication passed or failed." And in our setup locally we have multiple authentication methods, which require authenticate to possibly loop multiple times. What makes it even more of a security problem is the first time around, "authenticate" returns 0 (but with reenter set to 1) for any password. The entry we have in /etc/security/user is: demo: admin=false auth1=k4init SYSTEM="NONE" An obvious simple fix is to put the block in a loop, which reenter is non-zero, but on a quick test we did, that seemed to still fail. We are currently looking into why this failed, but decided to also report the problem now, due to the security risk. Frank Crawford -- ac3 Suite G16, Bay 7, Locomotive Workshop Phone: 02 9209 4600 Australian Technology Park Fax: 02 9209 4611 Eveleigh NSW 1430 From dunlap at apl.washington.edu Fri Feb 23 09:30:43 2001 From: dunlap at apl.washington.edu (John Dunlap) Date: Thu, 22 Feb 2001 14:30:43 -0800 (PST) Subject: intermittent stderr Message-ID: <200102222230.OAA06504@ohm.apl.washington.edu> The command "ssh ls -l /doesnotexist" gives various responses: Running from a 200 MHz PentiumPro with dsa key added to ssh-agent: Mistakes worst to fast machine: To a faster 600 MHz dual processor i686 600 MHz machine: ls: /doesnotexist: No such file or directory -- correct nothing at all -- wrong ls: select: Bad file descriptor -- wrong No mistakes to slower machine. To a slower 166 MHz i586 600 MHz machine: ls: /doesnotexist: No such file or directory -- correct all the time All machines run compiled OpenSSH-2.5.1p1 on RHL 6.2 with all patches, kernel 2.2.16-3. Set up on all machines with ssh and sshd defaulting to ssh2 protocol. My test script: #!/bin/sh while [ 1 ] do date ssh tesla ls -l /doesnotexist done Responses from fast machine are not consistent: Thu Feb 22 14:15:35 PST 2001 ls: /doesnotexist: No such file or directory Thu Feb 22 14:15:37 PST 2001 Thu Feb 22 14:15:39 PST 2001 ls: /doesnotexist: No such file or directory Thu Feb 22 14:15:41 PST 2001 Thu Feb 22 14:15:43 PST 2001 ls: /doesnotexist: No such file or directory Thu Feb 22 14:15:45 PST 2001 ls: select: Bad file descriptor Thu Feb 22 14:15:47 PST 2001 Thu Feb 22 14:15:49 PST 2001 ls: /doesnotexist: No such file or directory Thu Feb 22 14:15:51 PST 2001 ls: /doesnotexist: No such file or directory Thu Feb 22 14:15:54 PST 2001 ls: /doesnotexist: No such file or directory Thu Feb 22 14:15:56 PST 2001 select: Bad file descriptor Thu Feb 22 14:15:58 PST 2001 -- John Dunlap University of Washington Senior Electrical Engineer Applied Physics Laboratory dunlap at apl.washington.edu 1013 NE 40th Street 206-543-7207, 543-1300, FAX 543-6785 Seattle, WA 98105-6698 From dunlap at apl.washington.edu Fri Feb 23 09:42:07 2001 From: dunlap at apl.washington.edu (John Dunlap) Date: Thu, 22 Feb 2001 14:42:07 -0800 (PST) Subject: 2.5.1p1 logout hangs after RHL crond start Message-ID: <200102222242.OAA06523@ohm.apl.washington.edu> The RHL 6.2 command "/etc/rc.d/init.d/crond start" prevents clean logout from compiled version of OpenSSH-2.5.1p1 on all hosts. The command "/etc/rc.d/init.d/crond stop" is OK. This occurs for interactive or command line requests. ssh remotehost /etc/rc.d/init.d/crond stop --- works every time ssh remotehost /etc/rc.d/init.d/crond start --- hangs every time Control-C will terminate the hung command. The command executed correctly. When doing this interactively no trouble is noted until logout time. Using ssh and sshd with ssh2 protocol using ssh-agent on various i586 i686 boxes. -- John Dunlap University of Washington Senior Electrical Engineer Applied Physics Laboratory dunlap at apl.washington.edu 1013 NE 40th Street 206-543-7207, 543-1300, FAX 543-6785 Seattle, WA 98105-6698 From pekkas at netcore.fi Fri Feb 23 09:44:37 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 23 Feb 2001 00:44:37 +0200 (EET) Subject: 2.5.1p1 logout hangs after RHL crond start In-Reply-To: <200102222242.OAA06523@ohm.apl.washington.edu> Message-ID: On Thu, 22 Feb 2001, John Dunlap wrote: > The RHL 6.2 command "/etc/rc.d/init.d/crond start" prevents > clean logout from compiled version of OpenSSH-2.5.1p1 on all > hosts. > > The command "/etc/rc.d/init.d/crond stop" is OK. > This occurs for interactive or command line requests. > > ssh remotehost /etc/rc.d/init.d/crond stop --- works every time > ssh remotehost /etc/rc.d/init.d/crond start --- hangs every time > > Control-C will terminate the hung command. The command executed > correctly. When doing this interactively no trouble is noted until > logout time. > > Using ssh and sshd with ssh2 protocol using ssh-agent on various > i586 i686 boxes. This is a known bug "(sleep 20& ; exit)", unfortunately. Adding 'shopt -s huponexit' in your bash initialization files on the server should work around it. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From dunlap at apl.washington.edu Fri Feb 23 10:35:19 2001 From: dunlap at apl.washington.edu (John Dunlap) Date: Thu, 22 Feb 2001 15:35:19 -0800 (PST) Subject: intermittent stderr In-Reply-To: from "dunlap" at Feb 22, 2001 02:30:43 PM Message-ID: <200102222335.PAA06879@ohm.apl.washington.edu> I've just noticed that using ssh -1 always works. The problem is with ssh -2 from slow to fast machines. -- John > > The command "ssh ls -l /doesnotexist" gives various responses: > > Running from a 200 MHz PentiumPro with dsa key added to ssh-agent: > > Mistakes worst to fast machine: > To a faster 600 MHz dual processor i686 600 MHz machine: > ls: /doesnotexist: No such file or directory -- correct > nothing at all -- wrong > ls: select: Bad file descriptor -- wrong > > No mistakes to slower machine. > To a slower 166 MHz i586 600 MHz machine: > ls: /doesnotexist: No such file or directory -- correct all the time > > All machines run compiled OpenSSH-2.5.1p1 on RHL 6.2 with all > patches, kernel 2.2.16-3. Set up on all machines with > ssh and sshd defaulting to ssh2 protocol. > > My test script: > > #!/bin/sh > while [ 1 ] > do > date > ssh tesla ls -l /doesnotexist > done > > Responses from fast machine are not consistent: > > Thu Feb 22 14:15:35 PST 2001 > ls: /doesnotexist: No such file or directory > Thu Feb 22 14:15:37 PST 2001 > Thu Feb 22 14:15:39 PST 2001 > ls: /doesnotexist: No such file or directory > Thu Feb 22 14:15:41 PST 2001 > Thu Feb 22 14:15:43 PST 2001 > ls: /doesnotexist: No such file or directory > Thu Feb 22 14:15:45 PST 2001 > ls: select: Bad file descriptor > Thu Feb 22 14:15:47 PST 2001 > Thu Feb 22 14:15:49 PST 2001 > ls: /doesnotexist: No such file or directory > Thu Feb 22 14:15:51 PST 2001 > ls: /doesnotexist: No such file or directory > Thu Feb 22 14:15:54 PST 2001 > ls: /doesnotexist: No such file or directory > Thu Feb 22 14:15:56 PST 2001 > select: Bad file descriptor > Thu Feb 22 14:15:58 PST 2001 > > -- > John Dunlap University of Washington > Senior Electrical Engineer Applied Physics Laboratory > dunlap at apl.washington.edu 1013 NE 40th Street > 206-543-7207, 543-1300, FAX 543-6785 Seattle, WA 98105-6698 From rachit at ensim.com Fri Feb 23 10:50:13 2001 From: rachit at ensim.com (Rachit Siamwalla) Date: Thu, 22 Feb 2001 15:50:13 -0800 Subject: intermittent stderr References: <200102222335.PAA06879@ohm.apl.washington.edu> Message-ID: <3A95A5B5.85CFB3B1@ensim.com> Try "ssh hostname echo 0" and see if you get a similar result. You probably will. This was a problem with early snapshots of 2.3.0p1 as well. Perhaps the problem / solution there is similar? Doing the following problbly works "ssh hostname echo 0 \; sleep 1" (i would try it again, but i do not have machines available to test). -rchit John Dunlap wrote: > > I've just noticed that using ssh -1 always works. The problem > is with ssh -2 from slow to fast machines. -- John > > > > > The command "ssh ls -l /doesnotexist" gives various responses: > > > > Running from a 200 MHz PentiumPro with dsa key added to ssh-agent: > > > > Mistakes worst to fast machine: > > To a faster 600 MHz dual processor i686 600 MHz machine: > > ls: /doesnotexist: No such file or directory -- correct > > nothing at all -- wrong > > ls: select: Bad file descriptor -- wrong > > > > No mistakes to slower machine. > > To a slower 166 MHz i586 600 MHz machine: > > ls: /doesnotexist: No such file or directory -- correct all the time > > > > All machines run compiled OpenSSH-2.5.1p1 on RHL 6.2 with all > > patches, kernel 2.2.16-3. Set up on all machines with > > ssh and sshd defaulting to ssh2 protocol. > > > > My test script: > > > > #!/bin/sh > > while [ 1 ] > > do > > date > > ssh tesla ls -l /doesnotexist > > done > > > > Responses from fast machine are not consistent: > > > > Thu Feb 22 14:15:35 PST 2001 > > ls: /doesnotexist: No such file or directory > > Thu Feb 22 14:15:37 PST 2001 > > Thu Feb 22 14:15:39 PST 2001 > > ls: /doesnotexist: No such file or directory > > Thu Feb 22 14:15:41 PST 2001 > > Thu Feb 22 14:15:43 PST 2001 > > ls: /doesnotexist: No such file or directory > > Thu Feb 22 14:15:45 PST 2001 > > ls: select: Bad file descriptor > > Thu Feb 22 14:15:47 PST 2001 > > Thu Feb 22 14:15:49 PST 2001 > > ls: /doesnotexist: No such file or directory > > Thu Feb 22 14:15:51 PST 2001 > > ls: /doesnotexist: No such file or directory > > Thu Feb 22 14:15:54 PST 2001 > > ls: /doesnotexist: No such file or directory > > Thu Feb 22 14:15:56 PST 2001 > > select: Bad file descriptor > > Thu Feb 22 14:15:58 PST 2001 > > > > -- > > John Dunlap University of Washington > > Senior Electrical Engineer Applied Physics Laboratory > > dunlap at apl.washington.edu 1013 NE 40th Street > > 206-543-7207, 543-1300, FAX 543-6785 Seattle, WA 98105-6698 From tim at multitalents.net Fri Feb 23 11:19:32 2001 From: tim at multitalents.net (Tim Rice) Date: Thu, 22 Feb 2001 16:19:32 -0800 (PST) Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: <20010222155626.H28365@justice.loyola.edu> Message-ID: On Thu, 22 Feb 2001, Michael Stone wrote: > On Thu, Feb 22, 2001 at 07:12:00PM +0100, Kevin Steves wrote: > > i'm confused, you want that code removed, because it's already there? > > you wanted the orig first in diff i'm guessing? > > Doh! Yes, that should, of course, be > > diff -u openssh-2.5.1p1.orig/loginrec.c openssh-2.5.1p1/loginrec.c > --- openssh-2.5.1p1.orig/loginrec.c Mon Feb 5 07:42:17 2001 > +++ openssh-2.5.1p1/loginrec.c Tue Feb 20 16:19:17 2001 > @@ -539,13 +539,8 @@ > memset(dst, '\0', dstsize); > I think I recall someone saying that was needed on early releases of the OS but not the later releases. But I don't have any SGI machines so I don't know for sure. > /* Always skip prefix if present */ > -#ifdef sgi > - if (strncmp(src, "/dev/tty", 8) == 0) > - src += 8; > -#else > if (strncmp(src, "/dev/", 5) == 0) > src += 5; > -#endif > > len = strlen(src); > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From dunlap at apl.washington.edu Fri Feb 23 11:21:37 2001 From: dunlap at apl.washington.edu (John Dunlap) Date: Thu, 22 Feb 2001 16:21:37 -0800 (PST) Subject: intermittent stderr In-Reply-To: <3A95A5B5.85CFB3B1@ensim.com> from "Rachit Siamwalla" at Feb 22, 2001 03:50:13 PM Message-ID: <200102230021.QAA07661@ohm.apl.washington.edu> "ssh hostname echo 0" and "ssh hostname echo 0 \; sleep 1" both work fine with ssh2 protocol. I think the problem is stderr. I also think the problem is in the server since it works fine to an SSH Version 1.2.26 server and to a SSH Version 1.2.30 server. It does not work right to a Sun with OpenSSH_2.3.0p1 with version 2 but works fine version 1. > > Try "ssh hostname echo 0" and see if you get a similar result. You > probably will. This was a problem with early snapshots of 2.3.0p1 as > well. Perhaps the problem / solution there is similar? Doing the > following problbly works "ssh hostname echo 0 \; sleep 1" > > (i would try it again, but i do not have machines available to test). > > -rchit > > John Dunlap wrote: > > > > I've just noticed that using ssh -1 always works. The problem > > is with ssh -2 from slow to fast machines. -- John > > > > > > > > The command "ssh ls -l /doesnotexist" gives various responses: > > > > > > Running from a 200 MHz PentiumPro with dsa key added to ssh-agent: > > > > > > Mistakes worst to fast machine: > > > To a faster 600 MHz dual processor i686 600 MHz machine: > > > ls: /doesnotexist: No such file or directory -- correct > > > nothing at all -- wrong > > > ls: select: Bad file descriptor -- wrong > > > > > > No mistakes to slower machine. > > > To a slower 166 MHz i586 600 MHz machine: > > > ls: /doesnotexist: No such file or directory -- correct all the time > > > > > > All machines run compiled OpenSSH-2.5.1p1 on RHL 6.2 with all > > > patches, kernel 2.2.16-3. Set up on all machines with > > > ssh and sshd defaulting to ssh2 protocol. > > > > > > My test script: > > > > > > #!/bin/sh > > > while [ 1 ] > > > do > > > date > > > ssh tesla ls -l /doesnotexist > > > done > > > > > > Responses from fast machine are not consistent: > > > > > > Thu Feb 22 14:15:35 PST 2001 > > > ls: /doesnotexist: No such file or directory > > > Thu Feb 22 14:15:37 PST 2001 > > > Thu Feb 22 14:15:39 PST 2001 > > > ls: /doesnotexist: No such file or directory > > > Thu Feb 22 14:15:41 PST 2001 > > > Thu Feb 22 14:15:43 PST 2001 > > > ls: /doesnotexist: No such file or directory > > > Thu Feb 22 14:15:45 PST 2001 > > > ls: select: Bad file descriptor > > > Thu Feb 22 14:15:47 PST 2001 > > > Thu Feb 22 14:15:49 PST 2001 > > > ls: /doesnotexist: No such file or directory > > > Thu Feb 22 14:15:51 PST 2001 > > > ls: /doesnotexist: No such file or directory > > > Thu Feb 22 14:15:54 PST 2001 > > > ls: /doesnotexist: No such file or directory > > > Thu Feb 22 14:15:56 PST 2001 > > > select: Bad file descriptor > > > Thu Feb 22 14:15:58 PST 2001 > > > > > > -- > > > John Dunlap University of Washington > > > Senior Electrical Engineer Applied Physics Laboratory > > > dunlap at apl.washington.edu 1013 NE 40th Street > > > 206-543-7207, 543-1300, FAX 543-6785 Seattle, WA 98105-6698 > -- John Dunlap University of Washington Senior Electrical Engineer Applied Physics Laboratory dunlap at apl.washington.edu 1013 NE 40th Street 206-543-7207, 543-1300, FAX 543-6785 Seattle, WA 98105-6698 From vader at conflict.net Fri Feb 23 14:24:19 2001 From: vader at conflict.net (Jim Breton) Date: Fri, 23 Feb 2001 03:24:19 +0000 Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) bo x In-Reply-To: ; from mouring@etoh.eviladmin.org on Wed, Feb 21, 2001 at 07:07:33PM -0600 References: <20010221231441.15853.qmail@conflict.net> Message-ID: <20010223032419.29918.qmail@conflict.net> On Wed, Feb 21, 2001 at 07:07:33PM -0600, mouring at etoh.eviladmin.org wrote: > I'm stumped, since I can't replicate this on any Redhat box under my > control I can't provide any other suggestions, hints, tricks, etc. > > I wish I could help more, but without finding some hint as to what is > befuddling it there is not much more I can do. =( Well, I am now volunteering to be called an *sshole. For some reason, and I promise with *no* changes of which I am aware on either the client or the server machines, this is working fine now (except scp but you already know about that... fyi I get "lost connection" on scp, hopefully that is the error everyone else gets and not something special happening to me ;) ). You saw my ssh -v -v -v output from yesterday so you know I wasn't making it up. ;P Anyway I guess we may as well put this to rest. If it happens again... I will just wait a day before re-testing and reporting. :P Sorry, and thanks for all the friendly help I got. -- Jim B. vader at conflict.net From tim at multitalents.net Fri Feb 23 14:36:39 2001 From: tim at multitalents.net (Tim Rice) Date: Thu, 22 Feb 2001 19:36:39 -0800 (PST) Subject: SCO 5.0.5 setluid patch In-Reply-To: Message-ID: On Wed, 21 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > Applied. > > thanks. CVS Feb 22 15:42 I'm not seing any improvement here. ... tim(trr)@sco504 1% id -l uid=31(tim) gid=85(trr) luid=0(root) groups=85(trr),18(lp),50(group) ... tim(trr)@sco504 12% uname -X System = SCO_SV Node = sco504 Release = 3.2v5.0.4 KernelID = 97/09/03 Machine = Pentium BusType = ISA Serial = 1NC013996 Users = 2-user OEM# = 0 Origin# = 1 NumCPU = 1 OpenSSH configured has been configured with the following options. User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /usr/local/etc Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/man/catX PID file: /usr/local/etc sshd default user PATH: /bin:/usr/bin:/etc:/usr/local/bin 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: yes MD5 password support: no IP address in $DISPLAY hack: no Use IPv4 by default hack: no Translate v4 in v6 hack: no Host: i586-pc-sco3.2v5.0.4 Compiler: cc Compiler flags: -g Preprocessor flags: -I/usr/local/include -I/usr/local/ssl/include Linker flags: -L/usr/local/lib -L/usr/local/ssl/lib Libraries: -lwrap -lz -lsocket -lprot -lx -ltinfo -lm -lgen -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. sftp-server will be disabled. Your compiler does not support 64bit integers. > > On Wed, 21 Feb 2001, Sam Vaughan wrote: > > > > > On Wed, 21 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > > > > Can you resend that patch? It was managed in deliever and does not > > > apply against the current CVS tree. > > > > > > Thanks > > > > > > - Ben > > > > > > > No problem, here is a patch for the CVS tree that I grabbed this > > morning. > > > > Sam > > > > *** openssh_cvs/session.c Tue Feb 20 21:53:33 2001 > > --- openssh_cvs_patch/session.c Wed Feb 21 11:03:24 2001 > > *************** > > *** 1071,1076 **** > > } > > #endif > > # else /* HAVE_LOGIN_CAP */ > > if (setlogin(pw->pw_name) < 0) > > error("setlogin failed: %s", > > strerror(errno)); > > if (setgid(pw->pw_gid) < 0) { > > --- 1071,1083 ---- > > } > > #endif > > # else /* HAVE_LOGIN_CAP */ > > + > > + #if defined(HAVE_GETLUID) && defined(HAVE_SETLUID) > > + /* Sets login uid for accounting */ > > + if (getluid() == -1 && setluid(pw->pw_uid) == -1) > > + error("setluid: %s", strerror(errno)); > > + #endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */ > > + > > if (setlogin(pw->pw_name) < 0) > > error("setlogin failed: %s", > > strerror(errno)); > > if (setgid(pw->pw_gid) < 0) { > > *************** > > *** 1122,1132 **** > > } > > #endif /* HAVE_OSF_SIA */ > > > > - #if defined(HAVE_GETLUID) && defined(HAVE_SETLUID) > > - /* Sets login uid for accounting */ > > - if (getluid() == -1 && setluid(pw->pw_uid) == -1) > > - error("setluid: %s", strerror(errno)); > > - #endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */ > > > > #ifdef HAVE_CYGWIN > > if (is_winnt) > > --- 1129,1134 ---- > > } > > #endif /* HAVE_OSF_SIA */ > > > > > > #ifdef HAVE_CYGWIN > > if (is_winnt) > > > > > > > > > > > > > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mouring at etoh.eviladmin.org Fri Feb 23 15:28:20 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 22 Feb 2001 22:28:20 -0600 (CST) Subject: OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) bo x In-Reply-To: <20010223032419.29918.qmail@conflict.net> Message-ID: On Fri, 23 Feb 2001, Jim Breton wrote: > On Wed, Feb 21, 2001 at 07:07:33PM -0600, mouring at etoh.eviladmin.org wrote: > > I'm stumped, since I can't replicate this on any Redhat box under my > > control I can't provide any other suggestions, hints, tricks, etc. > > > > I wish I could help more, but without finding some hint as to what is > > befuddling it there is not much more I can do. =( > > Well, I am now volunteering to be called an *sshole. > > For some reason, and I promise with *no* changes of which I am aware on > either the client or the server machines, this is working fine now > (except scp but you already know about that... fyi I get "lost > connection" on scp, hopefully that is the error everyone else gets and > not something special happening to me ;) ). > Make sure scp is in your path. By default ${PREFIX}/bin is not included. A quick and dirty solution is just to ln -s ${PREFIX/bin/scp /usr/bin/scp - Ben From tim at multitalents.net Fri Feb 23 15:01:01 2001 From: tim at multitalents.net (Tim Rice) Date: Thu, 22 Feb 2001 20:01:01 -0800 (PST) Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: Message-ID: On Thu, 22 Feb 2001 mouring at etoh.eviladmin.org wrote: > Anything else I'm missing for brokeness that was introduced between > 2.3.0p1 and 2.5.1p1 that needs to be corrected? I'm expecting that > 2.5.1p2 will stand for a long time. So speak up now. I want to put p2 > to rest with the next week and half so we can catch back up with the > OpenBSD tree and head on to bigger and better problems. =) > Here is a patch to fix double -I Preprocessor flags: -I/usr/local/include -I/usr/local/ssl/include -I/usr/local/ ssl/include > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- openssh_cvs/configure.in.old Thu Feb 22 15:42:00 2001 +++ openssh_cvs/configure.in Thu Feb 22 16:00:03 2001 @@ -619,9 +619,9 @@ # Try to use $ssldir/include if it exists, otherwise # $ssldir if test -d "$ssldir/include" ; then - CPPFLAGS="$CPPFLAGS -I$ssldir/include" + CPPFLAGS="$saved_CPPFLAGS -I$ssldir/include" else - CPPFLAGS="$CPPFLAGS -I$ssldir" + CPPFLAGS="$saved_CPPFLAGS -I$ssldir" fi fi @@ -681,9 +681,9 @@ # Try to use $ssldir/include if it exists, otherwise # $ssldir if test -d "$ssldir/include" ; then - CPPFLAGS="$CPPFLAGS -I$ssldir/include" + CPPFLAGS="$saved_CPPFLAGS -I$ssldir/include" else - CPPFLAGS="$CPPFLAGS -I$ssldir" + CPPFLAGS="$saved_CPPFLAGS -I$ssldir" fi fi fi From mouring at etoh.eviladmin.org Fri Feb 23 16:55:19 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 22 Feb 2001 23:55:19 -0600 (CST) Subject: Problem with OpenSSH 2.3.0p1/2.5.1p1 and AIX In-Reply-To: <3A9497FC.FDF13F58@ac3.com.au> Message-ID: [..] > > An obvious simple fix is to put the block in a loop, which reenter is > non-zero, but on a quick test we did, that seemed to still fail. We are > currently looking into why this failed, but decided to also report the > problem now, due to the security risk. > What is your time table? There is a 2.5.1p2 release slated for about a week or so from now. - Ben From mouring at etoh.eviladmin.org Fri Feb 23 17:06:20 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 23 Feb 2001 00:06:20 -0600 (CST) Subject: PATH munged on SGI IRIX 6.5 machines In-Reply-To: <3A956D53.6F4A2578@mail.phy.ornl.gov> Message-ID: Can you try the latest cvs snapshot on www.openssh.com/portable.html and let me know if this is still an issue. - Ben On Thu, 22 Feb 2001, charles thomas wrote: > Built openssh 2.5.1p1 on SGI IRIX 6.5 machines. When users connect to > them via ssh, > the PATH variable appears to not be initialized correctly. "echo $PATH" > produces this short list: > > "/usr/bin /bin /usr/sbin /sbin". > > If you have a "setenv PATH" command in your .cshrc it appears to > be ignored. If you have a "set path" it works correctly. If you have > no "setenv PATH" or "set path" in your .cshrc, you get the short list > above. When you > login via telnet the PATH appears to be set correctly. > > -- > +==========================+ > | Charles Thomas | > | System Manager | > | Physics Division | > | Oak Ridge Natl. Lab. | > | thomas at mail.phy.ornl.gov | > | (865)576-7390 | > +==========================+ > > > From mouring at etoh.eviladmin.org Fri Feb 23 17:08:25 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 23 Feb 2001 00:08:25 -0600 (CST) Subject: Problems with sftp under SCO OpenServer In-Reply-To: Message-ID: On Thu, 22 Feb 2001, Greg Jewell wrote: > Hello, > > I compiled OpenSSH 2.5.1p1 for SCO OpenServer 5.0.5, HPUX B.11.00, and > SunOS 5.7. When I sftp into the HP or Sun box, everything works fine. > However, whenever I sftp into the OpenServer box, all remote filenames > are shown as "(null)". File sizes, owners, etc. display properly. This > behavior is exhibited from all origination points. > Which compiler are you using under OpenServer? - Ben From tim at multitalents.net Fri Feb 23 17:17:18 2001 From: tim at multitalents.net (Tim Rice) Date: Thu, 22 Feb 2001 22:17:18 -0800 (PST) Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: Message-ID: On Thu, 22 Feb 2001 mouring at etoh.eviladmin.org wrote: > > Things that are still outstanding: > > 3) SCO.. Is it happy yet for compiling? =) It's compiling on Open Server 3 and Open Server 5 However on Open Server 3 ... tim(trr)@sco42 40% ssh uw213 Couldn't restore privileges ... Hmm, that comes from entropy.c I'll look deeper whin I have more time. On Open Server 3 & Open Server 5 the version 2 protocol has a problem. The stty modes are not set correctly. ... tim at soyo:~> ssh -2 sco504 tim at sco504.int.multitalents.net's password: Last login: Thu Feb 22 19:31:28 2001 With Enhancements by Multitalents You have mail The first time, it's a KLU DGE! The second, a trick. Later, it's a well-established technique! -- Mike Broido, Intermetrics tim(trr)@sco504 1% ... > > Completed: > > 1) mdoc2man.pl .. Commited into contrib/ directory. In the semi-near > future either we need a patch to configure.in to support it directly. > > 2) SCO setluid patch commited (Verify please). Doesn't seem to be working. > > Anything else I'm missing for brokeness that was introduced between > 2.3.0p1 and 2.5.1p1 that needs to be corrected? I'm expecting that > 2.5.1p2 will stand for a long time. So speak up now. I want to put p2 > to rest with the next week and half so we can catch back up with the > OpenBSD tree and head on to bigger and better problems. =) > > Sorry, Kevin.. I'll get you the patches for the website by tomorrow > evening I ended up being called away for the night. > > - Ben > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mouring at etoh.eviladmin.org Fri Feb 23 18:08:32 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 23 Feb 2001 01:08:32 -0600 (CST) Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: Message-ID: On Thu, 22 Feb 2001, Tim Rice wrote: > On Thu, 22 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > Things that are still outstanding: > > > > 3) SCO.. Is it happy yet for compiling? =) > > It's compiling on Open Server 3 and Open Server 5 > > However on Open Server 3 > ... > tim(trr)@sco42 40% ssh uw213 > Couldn't restore privileges > ... > Hmm, that comes from entropy.c > I'll look deeper whin I have more time. > > When you solve that problem... You solve the same issue under NeXTStep. I've not had any free time to look at it either. > On Open Server 3 & Open Server 5 the version 2 protocol has a problem. > The stty modes are not set correctly. > ... > tim at soyo:~> ssh -2 sco504 > tim at sco504.int.multitalents.net's password: > Last login: Thu Feb 22 19:31:28 2001 > Hmm... - Ben From morgan at transmeta.com Fri Feb 23 17:28:28 2001 From: morgan at transmeta.com (Andrew Morgan) Date: Thu, 22 Feb 2001 22:28:28 -0800 Subject: PAM Service Name Patch References: <20010222105515.A6457@yorktown.isdn.uiuc.edu> Message-ID: <3A96030C.4B74FE34@transmeta.com> How does this interact with this comment: http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam_appl-4.html#ss4.2 Cheers Andrew "Mark D. Roth" wrote: > > I've attached a patch relative to OpenSSH 2.5.1p1 which sets the > default PAM service name to __progname instead of the hard-coded value > "sshd". This allows you to have multiple invokations of sshd under > different names, each with its own PAM configuration. > > Please let me know if you have any questions or problems. > > -- > Mark D. Roth > http://www.feep.net/~roth/ > > ------------------------------------------------------------------------ > > openssh-2.5.1p1-pamstart.diffName: openssh-2.5.1p1-pamstart.diff > Type: Plain Text (text/plain) From svaughan at asterion.com Fri Feb 23 18:00:29 2001 From: svaughan at asterion.com (Sam Vaughan) Date: Thu, 22 Feb 2001 23:00:29 -0800 (PST) Subject: SCO 5.0.5 setluid patch In-Reply-To: Message-ID: Tim, Are you starting sshd from inetd? I see that you compiled in TCP wrappers support. I'm wondering if that is why your LUID is getting set to 0 (root). If you are, could you try it without and see if the LUID still gets set wrong. ( Or its some difference between 5.0.4 and 5.0.5 and I don't have access to 5.0.4 right now. I can install it on a spare PC tomorrow for testing. ) Thanks, Sam On Thu, 22 Feb 2001, Tim Rice wrote: > On Wed, 21 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > > > Applied. > > > > thanks. > > CVS Feb 22 15:42 > > I'm not seing any improvement here. > ... > tim(trr)@sco504 1% id -l > uid=31(tim) gid=85(trr) luid=0(root) groups=85(trr),18(lp),50(group) > ... > > tim(trr)@sco504 12% uname -X > > System = SCO_SV > Node = sco504 > Release = 3.2v5.0.4 > KernelID = 97/09/03 > Machine = Pentium > BusType = ISA > Serial = 1NC013996 > Users = 2-user > OEM# = 0 > Origin# = 1 > NumCPU = 1 > > > OpenSSH configured has been configured with the following options. > User binaries: /usr/local/bin > System binaries: /usr/local/sbin > Configuration files: /usr/local/etc > Askpass program: /usr/local/libexec/ssh-askpass > Manual pages: /usr/local/man/catX > PID file: /usr/local/etc > sshd default user PATH: /bin:/usr/bin:/etc:/usr/local/bin > 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: yes > MD5 password support: no > IP address in $DISPLAY hack: no > Use IPv4 by default hack: no > Translate v4 in v6 hack: no > > Host: i586-pc-sco3.2v5.0.4 > Compiler: cc > Compiler flags: -g > Preprocessor flags: -I/usr/local/include -I/usr/local/ssl/include > Linker flags: -L/usr/local/lib -L/usr/local/ssl/lib > Libraries: -lwrap -lz -lsocket -lprot -lx -ltinfo -lm -lgen -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. > > sftp-server will be disabled. Your compiler does not support > 64bit integers. > > > > > On Wed, 21 Feb 2001, Sam Vaughan wrote: > > > > > > > > On Wed, 21 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > > > > > > > Can you resend that patch? It was managed in deliever and does not > > > > apply against the current CVS tree. > > > > > > > > Thanks > > > > > > > > - Ben > > > > > > > > > > No problem, here is a patch for the CVS tree that I grabbed this > > > morning. > > > > > > Sam > > > > > > *** openssh_cvs/session.c Tue Feb 20 21:53:33 2001 > > > --- openssh_cvs_patch/session.c Wed Feb 21 11:03:24 2001 > > > *************** > > > *** 1071,1076 **** > > > } > > > #endif > > > # else /* HAVE_LOGIN_CAP */ > > > if (setlogin(pw->pw_name) < 0) > > > error("setlogin failed: %s", > > > strerror(errno)); > > > if (setgid(pw->pw_gid) < 0) { > > > --- 1071,1083 ---- > > > } > > > #endif > > > # else /* HAVE_LOGIN_CAP */ > > > + > > > + #if defined(HAVE_GETLUID) && defined(HAVE_SETLUID) > > > + /* Sets login uid for accounting */ > > > + if (getluid() == -1 && setluid(pw->pw_uid) == -1) > > > + error("setluid: %s", strerror(errno)); > > > + #endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */ > > > + > > > if (setlogin(pw->pw_name) < 0) > > > error("setlogin failed: %s", > > > strerror(errno)); > > > if (setgid(pw->pw_gid) < 0) { > > > *************** > > > *** 1122,1132 **** > > > } > > > #endif /* HAVE_OSF_SIA */ > > > > > > - #if defined(HAVE_GETLUID) && defined(HAVE_SETLUID) > > > - /* Sets login uid for accounting */ > > > - if (getluid() == -1 && setluid(pw->pw_uid) == -1) > > > - error("setluid: %s", strerror(errno)); > > > - #endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */ > > > > > > #ifdef HAVE_CYGWIN > > > if (is_winnt) > > > --- 1129,1134 ---- > > > } > > > #endif /* HAVE_OSF_SIA */ > > > > > > > > > #ifdef HAVE_CYGWIN > > > if (is_winnt) > > > > > > > > > > > > > > > > > > > > > > > > -- > Tim Rice Multitalents (707) 887-1469 > tim at multitalents.net > > From stevesk at sweden.hp.com Fri Feb 23 18:46:36 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Fri, 23 Feb 2001 08:46:36 +0100 (MET) Subject: PAM Service Name Patch In-Reply-To: <3A96030C.4B74FE34@transmeta.com> Message-ID: On Thu, 22 Feb 2001, Andrew Morgan wrote: : How does this interact with this comment: : : http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam_appl-4.html#ss4.2 given that sshd is not set-id, and a user can build their own version, is there an issue? From tim at multitalents.net Fri Feb 23 19:23:38 2001 From: tim at multitalents.net (Tim Rice) Date: Fri, 23 Feb 2001 00:23:38 -0800 (PST) Subject: SCO 5.0.5 setluid patch In-Reply-To: Message-ID: On Thu, 22 Feb 2001, Sam Vaughan wrote: > > > Tim, > Are you starting sshd from inetd? I see that you compiled in TCP > wrappers support. I'm wondering if that is why your LUID is getting set to > 0 (root). I actually meant to postpone that message until I tested without wrappers but hit the wrong key. No I am not running from inetd. And the problem remains without wrappers. This shows up on both Open Server 5 and Open Server 3. > > If you are, could you try it without and see if the LUID still gets set > wrong. > > ( Or its some difference between 5.0.4 and 5.0.5 and I don't have access > to 5.0.4 right now. I can install it on a spare PC tomorrow for testing. ) > > Thanks, > Sam > > On Thu, 22 Feb 2001, Tim Rice wrote: > > > On Wed, 21 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > > > > Applied. > > > > > > thanks. > > > > CVS Feb 22 15:42 > > > > I'm not seing any improvement here. > > ... > > tim(trr)@sco504 1% id -l > > uid=31(tim) gid=85(trr) luid=0(root) groups=85(trr),18(lp),50(group) > > ... > > > > tim(trr)@sco504 12% uname -X > > > > System = SCO_SV > > Node = sco504 > > Release = 3.2v5.0.4 > > KernelID = 97/09/03 > > Machine = Pentium > > BusType = ISA > > Serial = 1NC013996 > > Users = 2-user > > OEM# = 0 > > Origin# = 1 > > NumCPU = 1 > > > > > > OpenSSH configured has been configured with the following options. > > User binaries: /usr/local/bin > > System binaries: /usr/local/sbin > > Configuration files: /usr/local/etc > > Askpass program: /usr/local/libexec/ssh-askpass > > Manual pages: /usr/local/man/catX > > PID file: /usr/local/etc > > sshd default user PATH: /bin:/usr/bin:/etc:/usr/local/bin > > 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: yes > > MD5 password support: no > > IP address in $DISPLAY hack: no > > Use IPv4 by default hack: no > > Translate v4 in v6 hack: no > > > > Host: i586-pc-sco3.2v5.0.4 > > Compiler: cc > > Compiler flags: -g > > Preprocessor flags: -I/usr/local/include -I/usr/local/ssl/include > > Linker flags: -L/usr/local/lib -L/usr/local/ssl/lib > > Libraries: -lwrap -lz -lsocket -lprot -lx -ltinfo -lm -lgen -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. > > > > sftp-server will be disabled. Your compiler does not support > > 64bit integers. > > > > > > > > On Wed, 21 Feb 2001, Sam Vaughan wrote: > > > > > > > > > > > On Wed, 21 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > > > > > > > > > > Can you resend that patch? It was managed in deliever and does not > > > > > apply against the current CVS tree. > > > > > > > > > > Thanks > > > > > > > > > > - Ben > > > > > > > > > > > > > No problem, here is a patch for the CVS tree that I grabbed this > > > > morning. > > > > > > > > Sam > > > > > > > > *** openssh_cvs/session.c Tue Feb 20 21:53:33 2001 > > > > --- openssh_cvs_patch/session.c Wed Feb 21 11:03:24 2001 > > > > *************** > > > > *** 1071,1076 **** > > > > } > > > > #endif > > > > # else /* HAVE_LOGIN_CAP */ > > > > if (setlogin(pw->pw_name) < 0) > > > > error("setlogin failed: %s", > > > > strerror(errno)); > > > > if (setgid(pw->pw_gid) < 0) { > > > > --- 1071,1083 ---- > > > > } > > > > #endif > > > > # else /* HAVE_LOGIN_CAP */ > > > > + > > > > + #if defined(HAVE_GETLUID) && defined(HAVE_SETLUID) > > > > + /* Sets login uid for accounting */ > > > > + if (getluid() == -1 && setluid(pw->pw_uid) == -1) > > > > + error("setluid: %s", strerror(errno)); > > > > + #endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */ > > > > + > > > > if (setlogin(pw->pw_name) < 0) > > > > error("setlogin failed: %s", > > > > strerror(errno)); > > > > if (setgid(pw->pw_gid) < 0) { > > > > *************** > > > > *** 1122,1132 **** > > > > } > > > > #endif /* HAVE_OSF_SIA */ > > > > > > > > - #if defined(HAVE_GETLUID) && defined(HAVE_SETLUID) > > > > - /* Sets login uid for accounting */ > > > > - if (getluid() == -1 && setluid(pw->pw_uid) == -1) > > > > - error("setluid: %s", strerror(errno)); > > > > - #endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */ > > > > > > > > #ifdef HAVE_CYGWIN > > > > if (is_winnt) > > > > --- 1129,1134 ---- > > > > } > > > > #endif /* HAVE_OSF_SIA */ > > > > > > > > > > > > #ifdef HAVE_CYGWIN > > > > if (is_winnt) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Tim Rice Multitalents (707) 887-1469 > > tim at multitalents.net > > > > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bernerus at cs.chalmers.se Fri Feb 23 19:48:16 2001 From: bernerus at cs.chalmers.se (Christer Bernerus) Date: Fri, 23 Feb 2001 09:48:16 +0100 (MET) Subject: PAM Service Name Patch Message-ID: <200102230848.JAA02827@hotlips.cs.chalmers.se> What I, as a sysadmin would like to see is the possibility of not only having different service names for different programs, but also have them different depending on authentication method. One reason for this is that I would like to control who logs on to which machine, and *how*. Using passwords and using e.g. kerberos or AFS ticket transfers have results in different security exposures in the light of trojan horses, or user population on the machines. Consider the situation of university teachers logging in to student machines. In that case, we wouldn't like them to give their passwords, regardless of whether the passwords are encrypted in transfer or not. However doing Kerb5 ticket transfers probably is a different story since these tickets have time limits on their validity, something that passwords generally don't have, or at least have much longer validity. If there were an OTP password authentication method, there would be yet another method that would represent a different security risk, and could call for another policy vs who may log on. PAM is a good framework that not only can be used for selecting authentication policies, but also can be used for controlling authorization policy, regardless of the method of authentication. One way of enabling that kind of authz policy-making is to have different PAM service names for different authn-methods. Please forgive me if this have been discussed before. I'm new to this list. In that case, I'd be interested looking at som archived mail if available. Chris. From gert at greenie.muc.de Fri Feb 23 20:53:14 2001 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 23 Feb 2001 10:53:14 +0100 Subject: SCO 5.0.5 setluid patch In-Reply-To: ; from Sam Vaughan on Thu, Feb 22, 2001 at 11:00:29PM -0800 References: Message-ID: <20010223105314.A15343@greenie.muc.de> Hi, On Thu, Feb 22, 2001 at 11:00:29PM -0800, Sam Vaughan wrote: > Are you starting sshd from inetd? I see that you compiled in TCP > wrappers support. I'm wondering if that is why your LUID is getting set to > 0 (root). If you run sshd from the "login command line", logged in as root, the luid is "0", and there's no way to change it. You have to run sshd from /etc/inittab (e.G. with a "respawn ... ssh -D" entry), or from the no-luid-daemon, "sdd" (check with "man sdd"). 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 Fri Feb 23 21:03:08 2001 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 23 Feb 2001 11:03:08 +0100 Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: ; from Tim Rice on Thu, Feb 22, 2001 at 10:17:18PM -0800 References: Message-ID: <20010223110308.C15343@greenie.muc.de> Hi, On Thu, Feb 22, 2001 at 10:17:18PM -0800, Tim Rice wrote: > However on Open Server 3 > ... > tim(trr)@sco42 40% ssh uw213 > Couldn't restore privileges > ... I have seen that as well, but haven't had time to track it down yet. Will try to give it a shot at the weekend. [..] > > 2) SCO setluid patch commited (Verify please). > Doesn't seem to be working. Don't forget to run sshd from a luid=unset environment, never from the command line... 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 grenier at nef.esiea.fr Fri Feb 23 22:43:39 2001 From: grenier at nef.esiea.fr (Christophe GRENIER) Date: Fri, 23 Feb 2001 12:43:39 +0100 (CET) Subject: OpenSSH_2.5.1p1 - RH 6.2 Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp Size: 5309 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010223/42964bfc/attachment.bin From mouring at etoh.eviladmin.org Sat Feb 24 01:54:42 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 23 Feb 2001 08:54:42 -0600 (CST) Subject: OpenSSH_2.5.1p1 - RH 6.2 In-Reply-To: Message-ID: > I have a problem with OpenSSH_2.5.1p1 (from RPM) under a RedHat 6.2 when > using SSH protocol 2. I am using glibc-2.1.3-22 > The ssh client segfaults. > I don't have the problem under my RH 7.0. > > Christophe > > OpenSSH_2.5.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f ^^^^^^^^^^^^^^^^^^ The RPM has been compiled against 0.9.6 OpenSSL. Using any other version causes problems. Please upgrade your OpenSSL or compile OpenSSH from source. - Ben From roth+openssh at feep.net Sat Feb 24 02:05:52 2001 From: roth+openssh at feep.net (Mark D. Roth) Date: Fri, 23 Feb 2001 09:05:52 -0600 Subject: PAM Service Name Patch In-Reply-To: ; from stevesk@sweden.hp.com on Fri, Feb 23, 2001 at 08:46:36AM +0100 References: <3A96030C.4B74FE34@transmeta.com> Message-ID: <20010223090552.A7961@yorktown.isdn.uiuc.edu> On Fri Feb 23 08:46 2001 +0100, Kevin Steves wrote: > On Thu, 22 Feb 2001, Andrew Morgan wrote: > : How does this interact with this comment: > : > : http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam_appl-4.html#ss4.2 > > given that sshd is not set-id, and a user can build their own version, > is there an issue? That's what I was going to say. I don't see a problem here. -- Mark D. Roth http://www.feep.net/~roth/ From pekkas at netcore.fi Sat Feb 24 02:06:07 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 23 Feb 2001 17:06:07 +0200 (EET) Subject: OpenSSH_2.5.1p1 - RH 6.2 In-Reply-To: Message-ID: On Fri, 23 Feb 2001 mouring at etoh.eviladmin.org wrote: > > I have a problem with OpenSSH_2.5.1p1 (from RPM) under a RedHat 6.2 when > > using SSH protocol 2. I am using glibc-2.1.3-22 > > The ssh client segfaults. > > I don't have the problem under my RH 7.0. > > > > Christophe > > > > OpenSSH_2.5.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f > ^^^^^^^^^^^^^^^^^^ > > The RPM has been compiled against 0.9.6 OpenSSL. Using > any other version causes problems. Please upgrade your > OpenSSL or compile OpenSSH from source. Getting openssh-2.5.1p1-1.src.rpm rebulding it with 'rpm --rebuild openssh-2.5.1p1-1.src.rpm' is also fine. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From chris at ex-parrot.com Sat Feb 24 03:11:59 2001 From: chris at ex-parrot.com (Chris Lightfoot) Date: Fri, 23 Feb 2001 16:11:59 +0000 Subject: A couple of patches.... Message-ID: <20010223161159.A1071@aquila.esc.cam.ac.uk> I have made available three patches for OpenSSH 2.5.1p1 (and 2.3.0p1), two of which may be of general interest. They are described in detail at http://www.ex-parrot.com/~chris/openssh-patches/ but a brief description-- http://www.ex-parrot.com/~chris/openssh-patches/openssh-2.5.1p1-keepalives.patch modifies the code in clientloop.c to periodically send a null packet as a keepalive; this is handy if you use OpenSSH across linux masquerading routers or other routers which time out TCP connections. This is done by sending a packet of type 0 every three minutes, which seems to work OK -- should I expect this to cause any issues/problems? http://www.ex-parrot.com/~chris/openssh-patches/openssh-2.5.1p1-better-reserved-ports.patch modifies the OpenBSD compatibility code to allocate reserved ports by counting downwards from 1023, useful if your firewall only allows a small set of ports near 1023 to be used for outgoing connections. (I believe this was discussed a few months ago on this list.) (less likely to be of general interest) http://www.ex-parrot.com/~chris/openssh-patches/openssh-2.5.1p1-accounting.patch modifies various code in the server to log the amount of traffic used by SSH sessions; perhaps useful if your provider bills you for bandwidth and you aren't in a position to install per-user accounting patches to your operating system. (This one is messy and I do not advertise it as an example of good coding practice :) ) -- Chris Lightfoot -- www.ex-parrot.com/~chris/ I can see clearly now the rain has gone/ But it looks like someone's going to drop the bomb (Alice What's The Matter, Terrorvision) From chuck at fiu.edu Sat Feb 24 04:08:12 2001 From: chuck at fiu.edu (Chuck) Date: Fri, 23 Feb 2001 12:08:12 -0500 Subject: openssh-2.5.1p1 on AIX Message-ID: Hi! I've built openssh-2.5.1p1 on an AIX 4.3.3 box, and attempted to use the public/private key authentication mechanism. This appears to work for a non-root user locally, but not for the root user. I have generated the identity (key) files and copied the .pub files to the authorized_keys files in /.ssh It appears that when I allow password authentication (the default) I can log in after giving the password, but when I turn it off (PasswordAuthentication no), I receive a "permission denied" message. Again, this seems to be unique to root as I can connect locally with no problem as an ordinary user. I apologize if this is a known issue, or if I've (as usual) forgotten something simple. P.S. - Things seem to work OK on Red Hat 7.0 From morgan at transmeta.com Sat Feb 24 05:09:40 2001 From: morgan at transmeta.com (Andrew Morgan) Date: Fri, 23 Feb 2001 10:09:40 -0800 Subject: PAM Service Name Patch References: <3A96030C.4B74FE34@transmeta.com> <20010223090552.A7961@yorktown.isdn.uiuc.edu> Message-ID: <3A96A764.30FD29F5@transmeta.com> Good. I was just checking that folk had thought this through. Cheers Andrew "Mark D. Roth" wrote: > > On Fri Feb 23 08:46 2001 +0100, Kevin Steves wrote: > > On Thu, 22 Feb 2001, Andrew Morgan wrote: > > : How does this interact with this comment: > > : > > : http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam_appl-4.html#ss4.2 > > > > given that sshd is not set-id, and a user can build their own version, > > is there an issue? > > That's what I was going to say. I don't see a problem here. > > -- > Mark D. Roth > http://www.feep.net/~roth/ From tim at multitalents.net Sat Feb 24 05:24:24 2001 From: tim at multitalents.net (Tim Rice) Date: Fri, 23 Feb 2001 10:24:24 -0800 (PST) Subject: SCO 5.0.5 setluid patch In-Reply-To: <20010223105314.A15343@greenie.muc.de> Message-ID: On Fri, 23 Feb 2001, Gert Doering wrote: > Hi, > > On Thu, Feb 22, 2001 at 11:00:29PM -0800, Sam Vaughan wrote: > > Are you starting sshd from inetd? I see that you compiled in TCP > > wrappers support. I'm wondering if that is why your LUID is getting set to > > 0 (root). > > If you run sshd from the "login command line", logged in as root, the luid > is "0", and there's no way to change it. > > You have to run sshd from /etc/inittab (e.G. with a "respawn ... ssh -D" > entry), or from the no-luid-daemon, "sdd" (check with "man sdd"). > > gert > Thanks for the tip. I would have expected it to work correctly if run from a /etc/rc2.d script. Oh well. If I add "sshd:/usr/local/sbin/sshd:sysadmin" to the end of /tcb/files/no_luid/cmdtable and then run "sd sshd" it works fine. (does further testing) Opps. Sysadmin (me) malfunction. It does work if you run /usr/local/sbin/sshd from a /etc/rc2.d script I was doing a su root -c "/usr/local/sbin/sshd". That explains luid=0 All works as expected now. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From morgan at transmeta.com Sat Feb 24 05:20:27 2001 From: morgan at transmeta.com (Andrew Morgan) Date: Fri, 23 Feb 2001 10:20:27 -0800 Subject: PAM Service Name Patch References: <200102230848.JAA02827@hotlips.cs.chalmers.se> Message-ID: <3A96A9EB.68620304@transmeta.com> Other ways of achieving the same ends: Before leaving Sun, Vipin (one of the original PAM RFC authors) proposed a more elaborate method for specifying the configuration syntax in the PAM configuration file(s). The Linux-PAM implementation supports this syntax. It allows for authentication trees like this: pam_listfile 'succeed if the PAM_USER is on this list' `-failure `-pam_unix `-success `-pam_otp The trees can get quite elaborate, and can involve forward jumps to support switch/case types of branching. Additionally, there is the pam_stack.so idea that the Redhat folk ship with their repackaging of the Linux-PAM distribution. One might imagine writing a module of this sort that could conditionally invoke different service names depending on context (username/remote host etc.). Cheers Andrew Christer Bernerus wrote: > > What I, as a sysadmin would like to see is the possibility of not only > having different service names for different programs, but also have them > different depending on authentication method. > > One reason for this is that I would like to control who logs on to which > machine, and *how*. Using passwords and using e.g. kerberos or AFS ticket > transfers have results in different security exposures in the light of > trojan horses, or user population on the machines. > > Consider the situation of university teachers logging in to student machines. > In that case, we wouldn't like them to give their passwords, regardless of > whether the passwords are encrypted in transfer or not. However doing Kerb5 > ticket transfers probably is a different story since these tickets have > time limits on their validity, something that passwords generally don't have, > or at least have much longer validity. > > If there were an OTP password authentication method, there would be yet another > method that would represent a different security risk, and could call for > another policy vs who may log on. PAM is a good framework that not only can > be used for selecting authentication policies, but also can be used for > controlling authorization policy, regardless of the method of authentication. > > One way of enabling that kind of authz policy-making is to have different > PAM service names for different authn-methods. > > Please forgive me if this have been discussed before. I'm new to this list. > In that case, I'd be interested looking at som archived mail if available. > > Chris. > > From gert at greenie.muc.de Sat Feb 24 07:45:28 2001 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 23 Feb 2001 21:45:28 +0100 Subject: SCO 5.0.5 setluid patch In-Reply-To: ; from Tim Rice on Fri, Feb 23, 2001 at 10:24:24AM -0800 References: <20010223105314.A15343@greenie.muc.de> Message-ID: <20010223214528.A16941@greenie.muc.de> Hi, On Fri, Feb 23, 2001 at 10:24:24AM -0800, Tim Rice wrote: > (does further testing) Opps. Sysadmin (me) malfunction. > It does work if you run /usr/local/sbin/sshd from a /etc/rc2.d script > I was doing a su root -c "/usr/local/sbin/sshd". That explains luid=0 This "su root -c ..." stuff in SCO's rc.* scripts is done exactly for that purpuse - setting luid to something specific :-) Do we have a "how to run sshd FAQ"? This should certainly go in there. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From mouring at etoh.eviladmin.org Sat Feb 24 09:38:12 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 23 Feb 2001 16:38:12 -0600 (CST) Subject: SCO 5.0.5 setluid patch In-Reply-To: <20010223214528.A16941@greenie.muc.de> Message-ID: On Fri, 23 Feb 2001, Gert Doering wrote: > Hi, > > On Fri, Feb 23, 2001 at 10:24:24AM -0800, Tim Rice wrote: > > (does further testing) Opps. Sysadmin (me) malfunction. > > It does work if you run /usr/local/sbin/sshd from a /etc/rc2.d script > > I was doing a su root -c "/usr/local/sbin/sshd". That explains luid=0 > > This "su root -c ..." stuff in SCO's rc.* scripts is done exactly for > that purpuse - setting luid to something specific :-) > > Do we have a "how to run sshd FAQ"? This should certainly go in there. > > gert > That would best go in the www.openssh.com/faq.html under the portable questions. - ben From gert at greenie.muc.de Sat Feb 24 09:14:23 2001 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 23 Feb 2001 23:14:23 +0100 Subject: SCO 5.0.5 setluid patch In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Feb 23, 2001 at 04:38:12PM -0600 References: <20010223214528.A16941@greenie.muc.de> Message-ID: <20010223231423.E16941@greenie.muc.de> Hi, On Fri, Feb 23, 2001 at 04:38:12PM -0600, mouring at etoh.eviladmin.org wrote: > > Do we have a "how to run sshd FAQ"? This should certainly go in there. > > That would best go in the www.openssh.com/faq.html under the portable > questions. What's the procedure to feed stuff into it? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From mouring at etoh.eviladmin.org Sat Feb 24 11:49:04 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 23 Feb 2001 18:49:04 -0600 (CST) Subject: SCO 5.0.5 setluid patch In-Reply-To: <20010223231423.E16941@greenie.muc.de> Message-ID: On Fri, 23 Feb 2001, Gert Doering wrote: > Hi, > > On Fri, Feb 23, 2001 at 04:38:12PM -0600, mouring at etoh.eviladmin.org wrote: > > > Do we have a "how to run sshd FAQ"? This should certainly go in there. > > > > That would best go in the www.openssh.com/faq.html under the portable > > questions. > > What's the procedure to feed stuff into it? > Submit them to the list as patches to the HTML source. If you check out the 'www' module from the OpenBSD tree you'll find a openssh/ directory that has the complete website. - Ben From mouring at etoh.eviladmin.org Sat Feb 24 12:05:21 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 23 Feb 2001 19:05:21 -0600 (CST) Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: <20010222091358.G11850@faui02.informatik.uni-erlangen.de> Message-ID: On Thu, 22 Feb 2001, Markus Friedl wrote: > i think i have to add a workaround for buggy windows clients+x11fwd. > Let me know when you have. I've not been following the OpenBSD and I noticed a lot of files have been touched. - Ben From mouring at etoh.eviladmin.org Sat Feb 24 12:54:21 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 23 Feb 2001 19:54:21 -0600 (CST) Subject: X11 display issues In-Reply-To: <3A95735A.DE51804D@cray.com> Message-ID: On Thu, 22 Feb 2001, Wendy Palm wrote: > you are, of course, correct. i knew that, but did it wrong anyway. > > here is a resend, in a more proper format- > I'm applying most of this. I'd perfer to put the NO_X11_UNIX_SOCKETS defines in the configure.in. If you could let me know what what the correct target-host section is I'd be grateful. Out of interest, how large of a patch are we looking at to sync Cray support up to the Portable tree, and is it fully functional? BTW, if you ever have a spare Cray feel free to send it about 2 miles south of your Eagan branch.. I'd be happy to play on one.=) - Ben From mouring at etoh.eviladmin.org Sat Feb 24 13:04:19 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 23 Feb 2001 20:04:19 -0600 (CST) Subject: sftp client In-Reply-To: <20010218180558.C23099@cygbert.vinschen.de> Message-ID: > I have now further investigated the problem and found a solution to > avoid the sftp-server hanging around. > > The OpenSSH sftp closes the sockets/pipes (dependent of the value of > USE_PIPES) and then kills it's underlying ssh by calling kill(ssh, SIGHUP). > > This `kill' kills the underlying ssh immediately instead of giving > time to cleanup. This results in breaking the connection to the sshd > which in turn misses to cleanup it's connection to the subsystem. > [..] What was the final decision in on this patch? Is there going to be a different fix in the OpenSSH tree or should I apply this before 2.5.1p2? - Ben From olof23 at earthlink.net Sat Feb 24 12:25:10 2001 From: olof23 at earthlink.net (Olof Liungman) Date: Fri, 23 Feb 2001 17:25:10 -0800 Subject: Neither scp nor sftp works (2.5.1p1 and Solaris 2.6) :( Message-ID: <001701c09e00$ab4e5500$0050fea9@noname> Hi, sorry about bothering you like this but despite several tries my recent posts to ssh at clinet.fi never appear on that list, and I don't know where else to turn. I was unable to get sftp/scp to work when using OpenSSH 2.3.0p1. No one could solve this problem and evenutally I was told to try "a recent snapshot". Now I've installed 2.5.1p1, but still no cigarr :(. I have OpenSSH installed on two Sun SPARC-boxes running Solaris 2.6. I configured with PAM and TCP-wrapper support. The software compiled fine, except for a few warnings. Normal ssh/slogin works great, both from one Sun-box to another and from Windows (F-Secure 4.1 SSH Client) and Mandrake Linux (2.3.0p1), using both public key authentication and normal password. However, neither command line scp nor F-Secures sftp client work from any of the machines to any of the sun boxes, nor between the Sun-boxes. My config files are standard and the "subsystem"-entry looks just fine. I've included the output (without IP-numbers and user names) on the client and the server side below (the latter using "Loglevel DEBUG"). Everything just dies after the SIGCHILD. What is going on? Two other users have contacted me regarding my earlier, unanswered posts concerning problems with sftp (then for v. 2.3.0p1) because they hade the same problem. Any help would be very appreciated as I've exhausted all options I can think of. Sincerely, Olof Liungman acting Unix sys-admin Dept. of Oceanography, G?teborg University Sweden --------------Client side-------------------- oort% scp testfile.txt helios:/export/data/ftp/pub/olof Enter passphrase for RSA key 'olli at tellus': Received disconnect from xxx.xxx.xxx.xxx: Command terminated on signal 11. lost connection oort% -----------Server side--------------------- Feb 24 02:14:58 helios sshd[5562]: Connection from yyy.yyy.yyy.yyy port 993 Feb 24 02:14:58 helios sshd[5562]: debug1: Client protocol version 1.5; client software version OpenSSH_2.5.1p1 Feb 24 02:14:58 helios sshd[5562]: debug1: match: OpenSSH_2.5.1p1 pat ^OpenSSH Feb 24 02:14:58 helios sshd[5562]: debug1: Local version string SSH-1.99-OpenSSH_2.5.1p1 Feb 24 02:14:58 helios sshd[5562]: debug1: Sent 768 bit server key and 1024 bit host key. Feb 24 02:14:58 helios sshd[5256]: debug1: Forked child 5562. Feb 24 02:14:58 helios sshd[5256]: debug1: Seeded RNG with 26 bytes from programs Feb 24 02:14:58 helios sshd[5256]: debug1: Seeded RNG with 3 bytes from system calls Feb 24 02:15:00 helios sshd[5562]: debug1: Encryption type: 3des Feb 24 02:15:00 helios sshd[5562]: debug1: Received session key; encryption turned on. Feb 24 02:15:00 helios sshd[5562]: debug1: Installing crc compensation attack detector. Feb 24 02:15:00 helios sshd[5562]: debug1: Starting up PAM with username "MY_USER_NAME" Feb 24 02:15:00 helios sshd[5562]: debug1: Trying to reverse map address yyy.yyy.yyy.yyy. Feb 24 02:15:00 helios sshd[5562]: debug1: PAM setting rhost to "oort" Feb 24 02:15:00 helios sshd[5562]: debug1: Attempting authentication for MY_USER_NAME. Feb 24 02:15:12 helios sshd[5562]: Accepted rsa for MY_USER_NAME from yyy.yyy.yyy.yyy port 993 Feb 24 02:15:12 helios sshd[5562]: debug1: session_new: init Feb 24 02:15:12 helios sshd[5562]: debug1: session_new: session 0 Feb 24 02:15:12 helios sshd[5562]: debug1: Exec command 'scp -t /export/data/ftp/pub/olof' Feb 24 02:15:12 helios sshd[5562]: debug1: Entering interactive session. Feb 24 02:15:12 helios sshd[5562]: debug1: Received SIGCHLD. Feb 24 02:15:12 helios sshd[5562]: debug1: fd 11 setting O_NONBLOCK Feb 24 02:15:12 helios sshd[5562]: debug1: fd 11 IS O_NONBLOCK Feb 24 02:15:12 helios sshd[5562]: debug1: fd 13 setting O_NONBLOCK Feb 24 02:15:12 helios sshd[5562]: debug1: server_init_dispatch_13 Feb 24 02:15:12 helios sshd[5562]: debug1: server_init_dispatch_15 Feb 24 02:15:12 helios sshd[5562]: debug1: End of interactive session; stdin 0, stdout (read 0, sent 0), stderr 0 bytes. Feb 24 02:15:12 helios sshd[5562]: Disconnecting: Command terminated on signal 11. Feb 24 02:15:12 helios sshd[5562]: debug1: Calling cleanup 0x35ebc(0x0) Feb 24 02:15:12 helios sshd[5562]: debug1: Calling cleanup 0x49f34(0x0) Feb 24 02:15:12 helios sshd[5562]: debug1: Calling cleanup 0x4f894(0x0) Feb 24 02:15:12 helios sshd[5562]: debug1: writing PRNG seed to file file://.ssh/prng_seed From dankamin at cisco.com Sat Feb 24 12:42:23 2001 From: dankamin at cisco.com (Dan Kaminsky) Date: Fri, 23 Feb 2001 17:42:23 -0800 Subject: scp vs sftp. References: <20010221221438.A12065@faui02.informatik.uni-erlangen.de> Message-ID: <005e01c09e03$0ee51ac0$006545ab@na.cisco.com> > fast and simple: scp > slow and complex: sftp almost always works: cat, as in: ssh user at host cat file > file cat file | ssh user at host cat > file Need directories? tar cf directory | ssh user at host tar xvf - ssh This isn't particularly new, but it is useful. New stuff comes next week :-) Yours Truly, Dan Kaminsky, CISSP www.doxpara.com From abartlet at pcug.org.au Sat Feb 24 12:50:22 2001 From: abartlet at pcug.org.au (Andrew Bartlett) Date: Sat, 24 Feb 2001 12:50:22 +1100 Subject: PAM Service Name Patch References: <200102230848.JAA02827@hotlips.cs.chalmers.se> Message-ID: <3A97135E.F0BC775B@bartlett.house> Christer Bernerus wrote: > > What I, as a sysadmin would like to see is the possibility of not only > having different service names for different programs, but also have them > different depending on authentication method. > > One reason for this is that I would like to control who logs on to which > machine, and *how*. Using passwords and using e.g. kerberos or AFS ticket > transfers have results in different security exposures in the light of > trojan horses, or user population on the machines. > > Consider the situation of university teachers logging in to student machines. > In that case, we wouldn't like them to give their passwords, regardless of > whether the passwords are encrypted in transfer or not. However doing Kerb5 > ticket transfers probably is a different story since these tickets have > time limits on their validity, something that passwords generally don't have, > or at least have much longer validity. > > If there were an OTP password authentication method, there would be yet another > method that would represent a different security risk, and could call for > another policy vs who may log on. PAM is a good framework that not only can > be used for selecting authentication policies, but also can be used for > controlling authorization policy, regardless of the method of authentication. > > One way of enabling that kind of authz policy-making is to have different > PAM service names for different authn-methods. > > Please forgive me if this have been discussed before. I'm new to this list. > In that case, I'd be interested looking at som archived mail if available. > > Chris. > > I may be misunderstanding your situation - but this looks like a client rather than a server issue: Do you administer your student machines? The ssh client can be quite easily configured as to what degree it will trust various servers - but if you don't trust the server its not really worth hoping it will keep a sign up "I'm not to be trusted" after its been rooted/reconfigured. Certainly having a more flexible pam framework might be useful - i.e. with OTP actually in PAM or with a different PAM configuration depending on the client's name. For the vast majority of users the existing setup actually works surprisingly well. Just make sure your doing it for the right reasons, Andrew Bartlett -- Andrew Bartlett abartlet at pcug.org.au From dankamin at cisco.com Sat Feb 24 13:12:31 2001 From: dankamin at cisco.com (Dan Kaminsky) Date: Fri, 23 Feb 2001 18:12:31 -0800 Subject: SU vs. ssh root@host Message-ID: <00e901c09e07$3ea1e190$006545ab@na.cisco.com> All-- su cannot be run without trusting the shell. The shell cannot be trusted without trusting any instructions the shell uses, from library calls to rc scripts. Hell, the instructions the shell uses can't even be trusted, since they're all living in userspace memory. By contrast, SSHD is generally a root owned, highly secure environment with no unpriveledged userspace dependancies. So: For what possible reason would I want to su to root, or any other account, instead of simply authenticating with the correct UID in the first place? What comes to mind is the concept that only certain users might be allowed to su to root, and that by forcing to users to log in as themselves, an accounting of *who* went to root may be done. This seems to me an instance where accounting is being valued higher than authorization--a broken model, since a flaw in authorization will create misleading accounting logs. There are a couple solutions that allow us to retain such accounting, and do it *securely*, but I'd like to achieve some kind of consensus that depending on su causes root access to be dependent upon unpriveledged security, and is thus something to be engineered against. Yours Truly, Dan Kaminsky, CISSP www.doxpara.com From pekkas at netcore.fi Sat Feb 24 19:20:22 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 24 Feb 2001 10:20:22 +0200 (EET) Subject: SU vs. ssh root@host In-Reply-To: <00e901c09e07$3ea1e190$006545ab@na.cisco.com> Message-ID: On Fri, 23 Feb 2001, Dan Kaminsky wrote: > So: For what possible reason would I want to su to root, or any other > account, instead of simply authenticating with the correct UID in the first > place? If you're bulk-installing systems for customers, it's nice to block root logins if they don't remember to change a default (/null) password. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From mouring at etoh.eviladmin.org Sat Feb 24 22:16:18 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 24 Feb 2001 05:16:18 -0600 (CST) Subject: SU vs. ssh root@host In-Reply-To: <00e901c09e07$3ea1e190$006545ab@na.cisco.com> Message-ID: On Fri, 23 Feb 2001, Dan Kaminsky wrote: > All-- > > su cannot be run without trusting the shell. The shell cannot be > trusted without trusting any instructions the shell uses, from library calls > to rc scripts. Hell, the instructions the shell uses can't even be trusted, > since they're all living in userspace memory. > > By contrast, SSHD is generally a root owned, highly secure environment > with no unpriveledged userspace dependancies. > hmm... Too many assuptions... > So: For what possible reason would I want to su to root, or any other > account, instead of simply authenticating with the correct UID in the first > place? > > What comes to mind is the concept that only certain users might be > allowed to su to root, and that by forcing to users to log in as themselves, > an accounting of *who* went to root may be done. This seems to me an > instance where accounting is being valued higher than authorization--a > broken model, since a flaw in authorization will create misleading > accounting logs. > A flaw in authorization in sshd could cause a user to login without root's password (see 2.3.1 OpenSSH bug). A flaw in the AES encryption could allow replay attacks like RC4. A flaw in a PAM module could allow a user to login with higher user rights. If there is a flaw in the authorization aspect of the OS. It may not be localized to just 'su' thus sshd provides no addition security unless it implements it's own authorization method independant of the OS. > There are a couple solutions that allow us to retain such accounting, > and do it *securely*, but I'd like to achieve some kind of consensus that > depending on su causes root access to be dependent upon unpriveledged > security, and is thus something to be engineered against. > Hmm.. A few things you have to ask yourself. 1) Is limiting su to a smaller subset of users, and auditing su against known attacks engineered enough to protect you? 2) What additional security risks do you take on when you allow 'root' logins from remote (Or over localhost loopback)? 3) Is the solution worth the overhead of encryption or complex protocol exchange? 4) If there is a fatal flaw in libc that allows 'su' to be compermised what are the chances that the same flaw may spill over to 'sshd' (Refer to glibc debaco recently)? Or for that matter a function call that was added to 'sshd' to provide platform support (refer to my f---up with setenv(). Which luckly looks harmless outside the fact it messed up a few platforms). Personally, I don't think the use of 'sshd' as a form of local authentication is really any more secure then a well written 'su' on a good solid audited OS. Once a cracker with half a brain has compermised your system (via su, sshd, etc) you'll never see the log files unless you are doing remote logging. But I'm not dead sure where you are heading with this, but I perfer the idea of 'keeping things simple' (Even if I fail to do so sometimes). The simplest solution with the least amount of 'edge' cases tends to win compared to complex systems with large amounts fo 'edge' cases. Please note 'simplest solution' is really defined as the 'simplest correct solution', since there are 'incorrect' solutions that are simple.=) If you have a case which shows that 'sshd' can/will/is more secure then 'su' for the same task. Then by all means present it. I'm open to change if it's in the right direction. I think it's written into my work contract that I need to be flexible. =) - Ben From gert at greenie.muc.de Sat Feb 24 21:52:56 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 24 Feb 2001 11:52:56 +0100 Subject: SU vs. ssh root@host In-Reply-To: <00e901c09e07$3ea1e190$006545ab@na.cisco.com>; from Dan Kaminsky on Fri, Feb 23, 2001 at 06:12:31PM -0800 References: <00e901c09e07$3ea1e190$006545ab@na.cisco.com> Message-ID: <20010224115256.C11146@greenie.muc.de> Hi, On Fri, Feb 23, 2001 at 06:12:31PM -0800, Dan Kaminsky wrote: > su cannot be run without trusting the shell. The shell cannot be > trusted without trusting any instructions the shell uses, from library calls > to rc scripts. Hell, the instructions the shell uses can't even be trusted, > since they're all living in userspace memory. > > By contrast, SSHD is generally a root owned, highly secure environment > with no unpriveledged userspace dependancies. I can't really follow that reasoning. - su is a root owned, suid program, which is much smaller than sshd, so it is less prone to have errors - sshd needs to run a user shell after login, so the shell dependency is there as well. What am I missing? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From jason at dfmm.org Sat Feb 24 21:54:55 2001 From: jason at dfmm.org (Jason Stone) Date: Sat, 24 Feb 2001 02:54:55 -0800 (PST) Subject: SU vs. ssh root@host In-Reply-To: <00e901c09e07$3ea1e190$006545ab@na.cisco.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > So: For what possible reason would I want to su to root, or any > other account, instead of simply authenticating with the correct UID > in the first place? > > What comes to mind is the concept that only certain users might be > allowed to su to root, and that by forcing to users to log in as > themselves, an accounting of *who* went to root may be done. This reminds me that there was some discussion a while ago about logging the fingerprint and/or comment associated with a key when that key was used to log in. Has anyone does this yet? If not, is there any reason it wouldn't be desired? > This seems to me an instance where accounting is being valued higher > than authorization--a broken model, since a flaw in authorization will > create misleading accounting logs. Not necesarily - if you're really paranoid about your logging (eg, you log to an ultra-secure remote host, or to a line printer, etc), then you can probablly be reasonably sure that you'll have good logs. Moreover, there are many business types who feel that things like due dilligence and liability (and hence good logging) are more important than actually protecting your machines and your data. I'm not one of theses people, but I've been employed by such people in the past.... -Jason --------------------------- If the Revolution comes to grief, it will be because you and those you lead have become alarmed at your own brutality. --John Gardner -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE6l5MGswXMWWtptckRAi+/AJsFm7GOCkyd1WIvkDLE9dLDp5DDigCfUehp b16o6xbKp9ycen1QEdmExUk= =qJER -----END PGP SIGNATURE----- From vinschen at redhat.com Sat Feb 24 22:12:48 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 24 Feb 2001 12:12:48 +0100 Subject: sftp client In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Feb 23, 2001 at 08:04:19PM -0600 References: <20010218180558.C23099@cygbert.vinschen.de> Message-ID: <20010224121248.U908@cygbert.vinschen.de> On Fri, Feb 23, 2001 at 08:04:19PM -0600, mouring at etoh.eviladmin.org wrote: > > > I have now further investigated the problem and found a solution to > > avoid the sftp-server hanging around. > > > > The OpenSSH sftp closes the sockets/pipes (dependent of the value of > > USE_PIPES) and then kills it's underlying ssh by calling kill(ssh, SIGHUP). > > > > This `kill' kills the underlying ssh immediately instead of giving > > time to cleanup. This results in breaking the connection to the sshd > > which in turn misses to cleanup it's connection to the subsystem. > > > [..] > > What was the final decision in on this patch? Is there going to be a > different fix in the OpenSSH tree or should I apply this before 2.5.1p2? I can't make the decision but it would be nice to include this before 2.5.1p2 since it makes sftp on Cygwin more robust. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From vinschen at redhat.com Sat Feb 24 22:15:11 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 24 Feb 2001 12:15:11 +0100 Subject: [PATCH]: acconfig.h [was: Re: X11 display issues] In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Feb 23, 2001 at 07:54:21PM -0600 References: <3A95735A.DE51804D@cray.com> Message-ID: <20010224121511.V908@cygbert.vinschen.de> On Fri, Feb 23, 2001 at 07:54:21PM -0600, mouring at etoh.eviladmin.org wrote: > On Thu, 22 Feb 2001, Wendy Palm wrote: > > > you are, of course, correct. i knew that, but did it wrong anyway. > > > > here is a resend, in a more proper format- > > > > I'm applying most of this. I'd perfer to put the NO_X11_UNIX_SOCKETS > defines in the configure.in. If you could let me know what what the > correct target-host section is I'd be grateful. > > Out of interest, how large of a patch are we looking at to sync Cray > support up to the Portable tree, and is it fully functional? Adding NO_X11_UNIX_SOCKETS is a nice idea. However, the corresponding entry in acconfig.h is missing. Patch follows: Index: acconfig.h =================================================================== RCS file: /cvs/openssh_cvs/acconfig.h,v retrieving revision 1.102 diff -u -p -r1.102 acconfig.h --- acconfig.h 2001/02/18 06:01:00 1.102 +++ acconfig.h 2001/02/24 11:14:41 @@ -293,6 +293,9 @@ /* Define if you have BSD auth support */ #undef BSD_AUTH +/* Define if X11 doesn't support AF_UNIX sockets on that system */ +#undef NO_X11_UNIX_SOCKETS + @BOTTOM@ /* ******************* Shouldn't need to edit below this line ************** */ Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From gert at greenie.muc.de Sun Feb 25 01:37:00 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 24 Feb 2001 15:37:00 +0100 Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Feb 22, 2001 at 01:21:21AM -0600 References: Message-ID: <20010224153700.L11146@greenie.muc.de> Hi, On Thu, Feb 22, 2001 at 01:21:21AM -0600, mouring at etoh.eviladmin.org wrote: > 3) SCO.. Is it happy yet for compiling? =) Tried SCO ODT 3.0 (3.2v4.2) today, with skey. Everything compiles fine, one problem occurs at the linking stage: "-lskey" is linked after "-lintl", but references strftime() -> library order has to be reversed, -lskey first. Run time (I tested protocol 1 only): - using "ssh" without it being suid root works as expected, - using "ssh" suid root leads to: "Couldn't restore privileges" (which has been reported a couple of days ago, but it's still there) - sshd has some problems (calling with ssh.com 1.2.27, but the same with openssh client): greenie.muc.de: Doing password authentication. gert at greenie.muc.de's password: greenie.muc.de: Requesting pty. greenie.muc.de: Requesting shell. greenie.muc.de: Entering interactive session. Command terminated on signal 11. -> oops? Will investigate. - same effect with SKey-Authentication - authentication succeeds, and then it bombs: otp-md5 98 gree04564 S/Key Password: debug: Requesting pty. debug: Requesting shell. debug: Entering interactive session. Received disconnect from 193.149.48.161: Command terminated on signal 11. debug: Calling cleanup 0x9dbc(0x0) debug: Calling cleanup 0x19464(0x0) debug: Calling cleanup 0x1e898(0x0) debug: writing PRNG seed to file /u/gert/.ssh/prng_seed Hmmm. Not bad so far, but not perfect 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 pekkas at netcore.fi Sun Feb 25 04:14:24 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 24 Feb 2001 19:14:24 +0200 (EET) Subject: scp user@host1 user@host2 broken? Message-ID: Hello all, Is it just me or is 'scp user at host1 user at host2' broken (if the server asks you for the password)? 1) [password required] >From OpenSSH 2.5.1p1 -> OpenSSH 2.5.1p1 -> OpenSSH 2.3.0, I get like: > scp pekkas at xxx:~/*.patch psavola at yyy:~/temp/ psavola at xxx's password: You have no controlling tty. Cannot read passphrase. lost connection 2) [protocol1 (different host), no password required] $ scp pekkas at xxx:~/*.patch pjsavol3 at zzz:~/temp/ pekkas at xxx's password: /home/unf/openssh-SNAP-20010219-redhat-init-functions.patch: No such file or directoryselect: Bad file descriptor NOTE: ~unf (the username in the originating host) is used instead of forced pekkas at netcore.fi! NOTE: a bad file descriptor warning. I believe this will happen if you use full path names instead of '~' etc. Also, -P -flag is ignored in host-to-host copy. Looking at the source, this appears to be intentional (ie: which definition should that apply to?) Longer log of case 2): [unf at install5 unf]$ scp -v -v -v pekkas at xxx:~/*.patch pjsavol3 at zzz:~/temp/ Executing: /usr/bin/ssh -v -x -o'FallBackToRsh no' -n -l pekkas xxx scp -v ~/*.patch 'pjsavol3 at zzz:~/temp/' OpenSSH_2.5.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f debug: Reading configuration data /etc/ssh/ssh_config debug: ssh_connect: getuid 501 geteuid 0 anon 0 debug: Connecting to xxx [193.94.160.1] port 22. debug: Allocated local port 1021. debug: Connection established. debug: identity file /home/unf/.ssh/identity type 3 debug: identity file /home/unf/.ssh/id_dsa type 3 debug: Remote protocol version 1.99, remote software version OpenSSH_2.5.1p1 debug: match: OpenSSH_2.5.1p1 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug: Local version string SSH-2.0-OpenSSH_2.5.1p1 debug: Seeding random number generator debug: send KEXINIT debug: done debug: wait KEXINIT debug: got kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug: got kexinit: ssh-dss,ssh-rsa debug: got kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug: got kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 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: 1029/2049 debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. debug: Got SSH2_MSG_KEXDH_REPLY. debug: Host 'xxx' is known and matches the RSA host key. debug: Found key in /home/unf/.ssh/known_hosts2:1 debug: bits set: 1011/2049 debug: ssh_rsa_verify: signature correct debug: Wait SSH2_MSG_NEWKEYS. debug: GOT SSH2_MSG_NEWKEYS. debug: send SSH2_MSG_NEWKEYS. debug: done: send SSH2_MSG_NEWKEYS. debug: done: KEX2. debug: send SSH2_MSG_SERVICE_REQUEST debug: service_accept: ssh-userauth debug: got SSH2_MSG_SERVICE_ACCEPT debug: authentications that can continue: publickey,password,keyboard-interactive debug: next auth method to try is publickey debug: key does not exist: /home/unf/.ssh/identity debug: key does not exist: /home/unf/.ssh/id_dsa debug: next auth method to try is password pekkas at xxx's password: debug: ssh-userauth2 successful: method password debug: fd 4 setting O_NONBLOCK 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: scp -v /home/unf/openssh-SNAP-20010219-redhat-init-functions.patch pjsavol3 at zzz:~/temp/ debug: channel 0: open confirm rwindow 0 rmax 16384 debug: channel 0: read<=0 rfd 4 len 0 debug: channel 0: read failed debug: channel 0: input open -> drain debug: channel 0: close_read debug: channel 0: input: no drain shortcut debug: channel 0: ibuf empty debug: channel 0: input drain -> closed debug: channel 0: send eof Executing: program /usr/bin/ssh host zzz, user pjsavol3, command scp -v -t ~/temp/ /home/unf/openssh-SNAP-20010219-redhat-init-functions.patch: No such file or directorydebug: client_input_channel_req: channel 0 rtype exit-status reply 0 debug: channel 0: rcvd eof debug: channel 0: output open -> drain debug: channel 0: rcvd close 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 10.7 seconds debug: Bytes per second: stdin 0.0, stdout 0.0, stderr 2.7 debug: Exit status 1 -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From tim at multitalents.net Sun Feb 25 05:36:54 2001 From: tim at multitalents.net (Tim Rice) Date: Sat, 24 Feb 2001 10:36:54 -0800 (PST) Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: <20010224153700.L11146@greenie.muc.de> Message-ID: On Sat, 24 Feb 2001, Gert Doering wrote: > Hi, > > On Thu, Feb 22, 2001 at 01:21:21AM -0600, mouring at etoh.eviladmin.org wrote: > > 3) SCO.. Is it happy yet for compiling? =) > > Tried SCO ODT 3.0 (3.2v4.2) today, with skey. > > Everything compiles fine, one problem occurs at the linking stage: > > "-lskey" is linked after "-lintl", but references strftime() -> library > order has to be reversed, -lskey first. The attached patch to configure.in should fix your linking problem. > > Run time (I tested protocol 1 only): > > - using "ssh" without it being suid root works as expected, > > - using "ssh" suid root leads to: > "Couldn't restore privileges" > (which has been reported a couple of days ago, but it's still there) > > - sshd has some problems (calling with ssh.com 1.2.27, but the same > with openssh client): Hmm, It's working here with both openssh client and ssh 1.2.27 But I'm not compiling with skey support. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- openssh_cvs/configure.in.old Sat Feb 24 09:28:56 2001 +++ openssh_cvs/configure.in Sat Feb 24 09:42:54 2001 @@ -358,6 +358,8 @@ [], [ AC_CHECK_LIB(c89, utimes, LIBS="$LIBS -lc89") ] ) +AC_FUNC_STRFTIME + # Checks for header files. AC_CHECK_HEADERS(bstring.h endian.h floatingpoint.h getopt.h lastlog.h limits.h login.h login_cap.h maillock.h netdb.h netgroup.h netinet/in_systm.h paths.h poll.h pty.h regex.h shadow.h security/pam_appl.h sys/bitypes.h sys/bsdtty.h sys/cdefs.h sys/poll.h sys/queue.h sys/select.h sys/stat.h sys/stropts.h sys/sysmacros.h sys/time.h sys/ttcompat.h sys/un.h stddef.h time.h ttyent.h usersec.h util.h utime.h utmp.h utmpx.h vis.h) @@ -533,8 +535,6 @@ fi AC_FUNC_GETPGRP - -AC_FUNC_STRFTIME # Check for PAM libs PAM_MSG="no" From gert at greenie.muc.de Sun Feb 25 07:49:28 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 24 Feb 2001 21:49:28 +0100 Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: ; from Tim Rice on Sat, Feb 24, 2001 at 10:36:54AM -0800 References: <20010224153700.L11146@greenie.muc.de> Message-ID: <20010224214928.A4953@greenie.muc.de> Hi, On Sat, Feb 24, 2001 at 10:36:54AM -0800, Tim Rice wrote: > > "-lskey" is linked after "-lintl", but references strftime() -> library > > order has to be reversed, -lskey first. > > The attached patch to configure.in should fix your linking problem. Yes, works. > > - sshd has some problems (calling with ssh.com 1.2.27, but the same > > with openssh client): > > Hmm, It's working here with both openssh client and ssh 1.2.27 > But I'm not compiling with skey support. Tried w/o skey, but no difference (besides skey not working anymore): debug: Doing challenge reponse authentication. debug: No challenge. debug: Doing password authentication. gert at greenie.muc.de's password: debug: Requesting pty. debug: Requesting shell. debug: Entering interactive session. Received disconnect from 193.149.48.161: Command terminated on signal 11. debug: Calling cleanup 0x9dbc(0x0) debug: Calling cleanup 0x19464(0x0) debug: Calling cleanup 0x1e898(0x0) sending a single command ("ssh host id -l") works and gives the expected result. Signal 11 is SIGSEGV. ... will debug. 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 Feb 25 08:14:18 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 24 Feb 2001 22:14:18 +0100 Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: <20010224214928.A4953@greenie.muc.de>; from Gert Doering on Sat, Feb 24, 2001 at 09:49:28PM +0100 References: <20010224153700.L11146@greenie.muc.de> <20010224214928.A4953@greenie.muc.de> Message-ID: <20010224221418.B4953@greenie.muc.de> Hi, On Sat, Feb 24, 2001 at 09:49:28PM +0100, Gert Doering wrote: > > Hmm, It's working here with both openssh client and ssh 1.2.27 > > But I'm not compiling with skey support. > > Tried w/o skey, but no difference (besides skey not working anymore): > > debug: Doing challenge reponse authentication. > debug: No challenge. > debug: Doing password authentication. > gert at greenie.muc.de's password: > debug: Requesting pty. > debug: Requesting shell. > debug: Entering interactive session. > Received disconnect from 193.149.48.161: Command terminated on signal 11. > debug: Calling cleanup 0x9dbc(0x0) > debug: Calling cleanup 0x19464(0x0) > debug: Calling cleanup 0x1e898(0x0) > > sending a single command ("ssh host id -l") works and gives the expected > result. Update: - running "sshd -d" from gdb works - no signal 11 - running "sshd" from the command line (luid is set already) works - running "sshd -D" from the command line works - running "sshd -D" from /etc/inittab does *not* work (signal 11). This makes debugging somewhat "interesting". In syslog, I found the following message: Feb 24 21:57:06 greenie sshd.x[11686]: Disconnecting: Command terminated on signal 11. What does this mean? "child shell", or "sshd" terminated? Doing further testing: - "ssh host command" does NOT have the problem - "ssh host ksh" (my login shell) does NOT have the problem - "ssh -t host ksh" (shell with pty) does NOT have the problem - "ssh -T host" (login, no pty) does NOT have the problem - "ssh host" -> something crashes, reproducible Ok, next: First I had the following inittab entry, reliably crashing: dm3:23:respawn:/u/softadm/openssh_cvs/sshd.x -p 24 -D -f /u/softadm/openssh_cvs/sshd_config For debugging, I changed this to dm3:23:respawn:/u/softadm/openssh_cvs/sshd.x -p 24 -D -f /u/softadm/openssh_cvs/sshd_config 2>>/tmp/sshd.err >>/tmp/sshd.out (with various numbers of "-d" arguments). And, voila, *no more crashes*. If I remove the ">>/tmp/sshd.out" part, the crash is back. So what I think this boils down to is some hard-to-track error that occurs only if *stdout* is not connected to anything upon sshd startup. ... and it doesn't even crash sshd but the child process?! Now I have to give up and ask for some hints where to look in the code...? 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 jbryans at csulb.edu Sun Feb 25 08:16:34 2001 From: jbryans at csulb.edu (Jack Bryans) Date: Sat, 24 Feb 2001 13:16:34 -0800 Subject: NeXT 3.3 vs openssh-2.5.1p1 (Couldn't restore privileges) Message-ID: <15000.9394.625382.64104@swift2.csulb.edu> Wanted to make openssh w/both -lwrap and BIND 8.2.3's -lbind on an m68k NeXT 3.3. Started w/then current openssh-2.3.0p1. Had to use -posix for compiler and loader to get -lbind to work, and had to throw out all openssh NeXT porting to get -posix to work. By the time I had it all working and installed, a security mailing list said there was a new openssh version released. Bagged openssh-2.5.1p1, went thru it again, only to find ssh fatals out w/ Couldn't restore privileges. Non-root suid ssh works just fine. An archive search shows others have the same problem. Haven't seen a diagnosis or patch yet. In the meantime, how bad would it be to #comment out the seteuid change and restore at the bottom of entropy.c? Jack From mouring at etoh.eviladmin.org Sun Feb 25 09:24:35 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 24 Feb 2001 16:24:35 -0600 (CST) Subject: [PATCH]: acconfig.h [was: Re: X11 display issues] In-Reply-To: <20010224121511.V908@cygbert.vinschen.de> Message-ID: On Sat, 24 Feb 2001, Corinna Vinschen wrote: > On Fri, Feb 23, 2001 at 07:54:21PM -0600, mouring at etoh.eviladmin.org wrote: > > On Thu, 22 Feb 2001, Wendy Palm wrote: > > > > > you are, of course, correct. i knew that, but did it wrong anyway. > > > > > > here is a resend, in a more proper format- > > > > > > > I'm applying most of this. I'd perfer to put the NO_X11_UNIX_SOCKETS > > defines in the configure.in. If you could let me know what what the > > correct target-host section is I'd be grateful. > > > > Out of interest, how large of a patch are we looking at to sync Cray > > support up to the Portable tree, and is it fully functional? > > Adding NO_X11_UNIX_SOCKETS is a nice idea. However, the corresponding > entry in acconfig.h is missing. Patch follows: > Thanks. I tested everything but that patch since I was in a hurry to leave last night. - Ben From mouring at etoh.eviladmin.org Sun Feb 25 09:49:38 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 24 Feb 2001 16:49:38 -0600 (CST) Subject: NeXT 3.3 vs openssh-2.5.1p1 (Couldn't restore privileges) In-Reply-To: <15000.9394.625382.64104@swift2.csulb.edu> Message-ID: On Sat, 24 Feb 2001, Jack Bryans wrote: > Wanted to make openssh w/both -lwrap and BIND 8.2.3's -lbind on an m68k NeXT > 3.3. Started w/then current openssh-2.3.0p1. Had to use -posix for > compiler and loader to get -lbind to work, and had to throw out all openssh > NeXT porting to get -posix to work. By the time I had it all working and > installed, a security mailing list said there was a new openssh version > released. > First off.. Don't use -posix. I've spent 7 months of my life replacing broken posix functions in NeXT. You may get it to compile with -posix, but it's not going to work right. Secondly, why are you attempting to link to bind directly? What is wrong with using the native resolving libraries? > Bagged openssh-2.5.1p1, went thru it again, only to find ssh fatals out w/ > Couldn't restore privileges. > > Non-root suid ssh works just fine. > > An archive search shows others have the same problem. Haven't seen a > diagnosis or patch yet. > I'm going to attempt to look at this today. I've just been overwelmed recently. =) > In the meantime, how bad would it be to #comment out the seteuid change and > restore at the bottom of entropy.c? > Originally the seteuid code was not there. It was added to ensure that if any bad information was in the prng file that it could not be used to compromise the ssh client. So it's up to you if you wish to comment it out. - Ben From djm at mindrot.org Sun Feb 25 09:22:11 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 25 Feb 2001 09:22:11 +1100 (EST) Subject: Portable OpenSSH 2.5.1p1 In-Reply-To: <20010219193735.A4074@greenie.muc.de> Message-ID: On Mon, 19 Feb 2001, Gert Doering wrote: > Hi, > > On Tue, Feb 20, 2001 at 03:00:00AM +1100, Damien Miller wrote: > > 5) Important changes in the implementation of SSH 1 protocol: > > > > The OpenSSH server does not require a privileged source port for > > RhostsRsaAuthentication, since it adds no additional security. > > I don't buy (understand?) that. > > Using RhostsRsaAuthentication, I can give user "A" the right to log > into an account, but not user "B" on the same client machine. > > Requiring privileged ports for this means "user B can't compile his > own ssh client that pretents he's user A", so user B can't easily > hack into my account. Now if I don't trust "root" on the client > machine, or if B can get root access, I'm lost anyway, that's true > (but if they have root access, they can hijack my ssh sessions by > fiddling with ttys, so in that case, I have lost in any case). You are forgetting that the ssh client still needs access to the host's *private* key to sign the authentication request. This still implies a suid root client, but it is one less thing we need priviliges for. SSH.COM apparently implement this with a signing subprocess which is sgid to a magic group which owns the host key. This does away with the need to be suid root. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From jbryans at csulb.edu Sun Feb 25 09:26:39 2001 From: jbryans at csulb.edu (Jack Bryans) Date: Sat, 24 Feb 2001 14:26:39 -0800 Subject: NeXT 3.3 vs openssh-2.5.1p1 (Couldn't restore privileges) In-Reply-To: References: <15000.9394.625382.64104@swift2.csulb.edu> Message-ID: <15000.13599.733980.710643@swift2.csulb.edu> mouring at etoh.eviladmin.org writes: > First off.. Don't use -posix. I've spent 7 months of my life replacing > broken posix functions in NeXT. You may get it to compile with -posix, > but it's not going to work right. Openssh-2.3.0p1's ssh, scp, and sshd worked OK for me. Not exhaustively tested, but routine use showed no problems. > Secondly, why are you attempting to link to bind directly? What is wrong > with using the native resolving libraries? 1. They're really ancient, maybe BSD 4.2 even. 2. Yeah, -posix used to give me fits 'til I ported BIND V8 to NeXT. Since then -posix's been no problem. Most likely the compatability includes and library modules fixed up NeXT's posix weirdness. 3. The -posix and -lbind combo picked up a slew of HAVEs at configure time. > > An archive search shows others have the same problem. Haven't seen a > > diagnosis or patch yet. > > > I'm going to attempt to look at this today. I've just been overwelmed > recently. =) Never happens here, he lied unconvincingly. :-) > Originally the seteuid code was not there. It was added to ensure that if > any bad information was in the prng file that it could not be used to > compromise the ssh client. > > So it's up to you if you wish to comment it out. OK, thanks. I'll put it back like 2.3.0. Jack From georg.schwarz at iname.com Sun Feb 25 10:05:09 2001 From: georg.schwarz at iname.com (Georg Schwarz) Date: Sun, 25 Feb 2001 00:05:09 +0100 Subject: Fwd: OpenSSH on Ultrix? Message-ID: <1epcyuy.1wvn2qd1w27eg2M@georg.schwarz.online.de> Dear developers, I'd appreciate if you could forward this to the appropriate people doing the non-OpenBSD ports of OpenSSH. Thanks. ------- Begin Forwarded Message ------- Subject: OpenSSH on Ultrix? From: Georg Schwarz Newsgroups: comp.unix.ultrix comp.security.unix Date: Sat, 24 Feb 2001 23:06:02 +0100 Has anybody managed to run OpenSSH on DEC Ultrix? I've now managed (after some tweaking) to compile OpenSSH 2.5.1p1 onUltrix, but sshd seems to have problems, probably due to different pty handling: debug1: session_new: init debug1: session_new: session 0 debug1: Allocating pty. debug1: Ignoring unsupported tty mode opcode 12 (0xc) debug1: Ignoring unsupported tty mode opcode 18 (0x12) debug1: Ignoring unsupported tty mode opcode 41 (0x29) debug1: Ignoring unsupported tty mode opcode 60 (0x3c) debug1: Ignoring unsupported tty mode opcode 61 (0x3d) debug1: Received request for X11 forwarding with auth spoofing. debug1: fd 11 setting O_NONBLOCK debug1: fd 11 IS O_NONBLOCK debug1: channel 0: new [X11 inet listener] debug1: Entering interactive session. error: open /dev/tty failed - could not set controlling tty: No such device or address debug1: fd 5 setting O_NONBLOCK debug1: fd 10 IS O_NONBLOCK debug1: server_init_dispatch_13 debug1: server_init_dispatch_15 debug1: Received SIGCHLD. executing commands from remote works fine, as does ssh for outgoing connections. also, how do I prevent the "insufficient entropy" error from occurring from time to time? -- Georg Schwarz http://home.pages.de/~schwarz/ georg.schwarz at iname.com +49 177 2437545 -------- End Forwarded Message -------- -- Georg Schwarz http://home.pages.de/~schwarz/ georg.schwarz at iname.com +49 177 2437545 From mouring at etoh.eviladmin.org Sun Feb 25 11:14:07 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 24 Feb 2001 18:14:07 -0600 (CST) Subject: NeXT 3.3 vs openssh-2.5.1p1 (Couldn't restore privileges) In-Reply-To: <15000.13599.733980.710643@swift2.csulb.edu> Message-ID: On Sat, 24 Feb 2001, Jack Bryans wrote: > mouring at etoh.eviladmin.org writes: > > > First off.. Don't use -posix. I've spent 7 months of my life replacing > > broken posix functions in NeXT. You may get it to compile with -posix, > > but it's not going to work right. > > Openssh-2.3.0p1's ssh, scp, and sshd worked OK for me. Not exhaustively > tested, but routine use showed no problems. > It may work for 3.3, but libposix.a itself has a lot of minor bugs, and the library itself is totally broken under 4.2. I was able to run with -posix under 3.3 for almost 2 months before noticing odd occurances. > > Secondly, why are you attempting to link to bind directly? What is wrong > > with using the native resolving libraries? > > 1. They're really ancient, maybe BSD 4.2 even. I don't get this argument. DNS resolution has not changed for a long time, and I've not ran into any problems using the native resolver in over a year worth of testing. If you compile without -lbind or -posix it compiles pretty cleanly without any changes. - Ben From mouring at etoh.eviladmin.org Sun Feb 25 13:04:13 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 24 Feb 2001 20:04:13 -0600 (CST) Subject: NeXT 3.3 vs openssh-2.5.1p1 (Couldn't restore privileges) In-Reply-To: <15000.9394.625382.64104@swift2.csulb.edu> Message-ID: On Sat, 24 Feb 2001, Jack Bryans wrote: [..] > Bagged openssh-2.5.1p1, went thru it again, only to find ssh fatals out w/ > Couldn't restore privileges. > FYI.. Use 'prngd' and do --with-egd-pool=/path/to/random and this will solve your problem about "Couldn't restore priviledges." This is an issue with just using the pure-built in Entropy system. - Ben From distler at golem.ph.utexas.edu Sun Feb 25 17:52:24 2001 From: distler at golem.ph.utexas.edu (Jacques Distler) Date: Sun, 25 Feb 2001 00:52:24 -0600 Subject: next build In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- At 2001-02-24 23:22:30, wrote: >> > First off.. Don't use -posix. I've spent 7 months of my life replacing >> > broken posix functions in NeXT. You may get it to compile with -posix, >> > but it's not going to work right. >> >> Openssh-2.3.0p1's ssh, scp, and sshd worked OK for me. Not exhaustively >> tested, but routine use showed no problems. >> >It may work for 3.3, but libposix.a itself has a lot of minor bugs, and >the library itself is totally broken under 4.2. I was able to run with >-posix under 3.3 for almost 2 months before noticing odd occurances. > >> > Secondly, why are you attempting to link to bind directly? What is wrong >> > with using the native resolving libraries? >> >> 1. They're really ancient, maybe BSD 4.2 even. > >I don't get this argument. DNS resolution has not changed for a long >time, and I've not ran into any problems using the native resolver in over >a year worth of testing. > >If you compile without -lbind or -posix it compiles pretty cleanly without >any changes. I have to agree with Ben, libposix.a on NeXTStep is evil, and should be avoided at all costs. As to the new resolver libraries, at some point, libbind.a started requiring -posix if you wanted to link against it. I complained a couple of times to the BIND developers that the POSIXisms in question weren't really necessary in the library. They kept promising to fix it; eventually I just gave up and keep around an older version of libbind.a which does not require -posix. That said, there's nothing in openssh that needs the new resolver routines (and I don't bother linking against them). And I also have to concur "use prngd." Previously, I had used EGD and the entropy-gathering daemon would die about once a month or so. Prngd seems much more robust. Jacques Distler -----BEGIN PGP SIGNATURE----- Version: PGP Comment: Public Key - http://golem.ph.utexas.edu/~distler/distler.asc iQCVAwUBOpiryaIBi34rsX+ZAQEQeAQAnVSFd9puJGoD8sAAo1pMROu161B6levm ZaLLOKJJRTQlFuWwc4wl3G4buT1Pu6rCcT+adRWqiGb7e4iAgtGeQeCoKM07uyJI GiKgKvdA+lEsRQgkzX99IDv87E9UdvP19zGJTpFvh/wE7XX3cTBcpYSEJzGu/D6P eOOYrvXNMxc= =Z6Kz -----END PGP SIGNATURE----- From gert at greenie.muc.de Sun Feb 25 20:31:57 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 25 Feb 2001 10:31:57 +0100 Subject: NeXT 3.3 vs openssh-2.5.1p1 (Couldn't restore privileges) In-Reply-To: ; from mouring@etoh.eviladmin.org on Sat, Feb 24, 2001 at 08:04:13PM -0600 References: <15000.9394.625382.64104@swift2.csulb.edu> Message-ID: <20010225103157.A24968@greenie.muc.de> Hi, On Sat, Feb 24, 2001 at 08:04:13PM -0600, mouring at etoh.eviladmin.org wrote: > [..] > > Bagged openssh-2.5.1p1, went thru it again, only to find ssh fatals out w/ > > Couldn't restore privileges. > > > FYI.. Use 'prngd' and do --with-egd-pool=/path/to/random and this will > solve your problem about "Couldn't restore priviledges." This is an issue > with just using the pure-built in Entropy system. Yes, but that won't work on SCO 3, as it doesn't have unix sockets :-( What I don't really understand is why the seteuid() stuff in entropy.c isn't working here - from the docs, it should... - how is uid changing done in other parts of ssh? 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 Mon Feb 26 00:44:42 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sun, 25 Feb 2001 14:44:42 +0100 Subject: scp user@host1 user@host2 broken? In-Reply-To: ; from pekkas@netcore.fi on Sat, Feb 24, 2001 at 07:14:24PM +0200 References: Message-ID: <20010225144442.A13131@folly> On Sat, Feb 24, 2001 at 07:14:24PM +0200, Pekka Savola wrote: > Hello all, > > Is it just me or is 'scp user at host1 user at host2' broken (if the server asks > you for the password)? yes it is. it's just an 'alias' for ssh user at host1 'scp FILE user at host2' (this works only if the scp does not need a tty, e.g. if agent-fwd is used). perhaps it should do ssh -t user at host1 'scp FILE user at host2' but perhaps i'm wrong. > 1) [password required] > > >From OpenSSH 2.5.1p1 -> OpenSSH 2.5.1p1 -> OpenSSH 2.3.0, I get like: > > > scp pekkas at xxx:~/*.patch psavola at yyy:~/temp/ > psavola at xxx's password: > You have no controlling tty. Cannot read passphrase. > lost connection as expected. -markus From guenther at sendmail.com Sat Feb 24 09:16:38 2001 From: guenther at sendmail.com (Philip Guenther) Date: Fri, 23 Feb 2001 14:16:38 -0800 Subject: CVS problems Message-ID: <200102232216.f1NMGc198167@lab.sendmail.com> point% cvs -d :pserver:cvs at bass.directhit.com:/cvs co \ -rV_2_5_1_STABLE openssh_cvs cvs [server aborted]: cannot write /cvs/CVSROOT/val-tags: Permission denied point% Philip Guenther From markus.friedl at informatik.uni-erlangen.de Mon Feb 26 03:28:59 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sun, 25 Feb 2001 17:28:59 +0100 Subject: intermittent stderr In-Reply-To: <200102222230.OAA06504@ohm.apl.washington.edu>; from dunlap@apl.washington.edu on Thu, Feb 22, 2001 at 02:30:43PM -0800 References: <200102222230.OAA06504@ohm.apl.washington.edu> Message-ID: <20010225172859.A5291@folly> On Thu, Feb 22, 2001 at 02:30:43PM -0800, John Dunlap wrote: > The command "ssh ls -l /doesnotexist" gives various responses: please try this patch. after close of stdin/out remaining stderr data is ignored in the 'channel' layer of openssh-current. Index: nchan.c =================================================================== RCS file: /home/markus/cvs/ssh/nchan.c,v retrieving revision 1.22 diff -u -r1.22 nchan.c --- nchan.c 2001/01/21 19:05:52 1.22 +++ nchan.c 2001/02/25 16:19:55 @@ -406,14 +406,40 @@ { debug3("channel %d: chan_delete_if_full_closed2: istate %d ostate %d", c->self, c->istate, c->ostate); + if (c->istate == CHAN_INPUT_CLOSED && c->ostate == CHAN_OUTPUT_CLOSED) { - if (!(c->flags & CHAN_CLOSE_SENT)) { - chan_send_close2(c); - } - if ((c->flags & CHAN_CLOSE_SENT) && - (c->flags & CHAN_CLOSE_RCVD)) { - debug("channel %d: full closed2", c->self); - channel_free(c->self); + /* + * we have to delay the close message if the efd (for stderr) + * is still active + */ + if (((c->extended_usage != CHAN_EXTENDED_IGNORE) && + buffer_len(&c->extended) > 0) +#if 0 + || ((c->extended_usage == CHAN_EXTENDED_READ) && + c->efd != -1) +#endif + ) { + debug2("channel %d: active efd: %d len %d type %s", + c->self, c->efd, buffer_len(&c->extended), + c->extended_usage==CHAN_EXTENDED_READ ? + "read": "write"); + } else { +#if 0 + if (c->efd != -1) { + debug("channel %d: delayed close for efd %d", + c->self, c->efd); + close(c->efd); + c->efd = -1; + } +#endif + if (!(c->flags & CHAN_CLOSE_SENT)) { + chan_send_close2(c); + } + if ((c->flags & CHAN_CLOSE_SENT) && + (c->flags & CHAN_CLOSE_RCVD)) { + debug("channel %d: full closed2", c->self); + channel_free(c->self); + } } } } Index: channels.c =================================================================== RCS file: /home/markus/cvs/ssh/channels.c,v retrieving revision 1.92 diff -u -r1.92 channels.c --- channels.c 2001/02/16 13:38:18 1.92 +++ channels.c 2001/02/25 16:12:59 @@ -824,7 +824,14 @@ buffer_len(&c->extended)); debug2("channel %d: written %d to efd %d", c->self, len, c->efd); - if (len > 0) { + if (len < 0 && (errno == EINTR || errno == EAGAIN)) + return 1; + if (len <= 0) { + debug2("channel %d: closing write-efd %d", + c->self, c->efd); + close(c->efd); + c->efd = -1; + } else { buffer_consume(&c->extended, len); c->local_consumed += len; } @@ -833,13 +840,16 @@ len = read(c->efd, buf, sizeof(buf)); debug2("channel %d: read %d from efd %d", c->self, len, c->efd); - if (len == 0) { - debug("channel %d: closing efd %d", + if (len < 0 && (errno == EINTR || errno == EAGAIN)) + return 1; + if (len <= 0) { + debug2("channel %d: closing read-efd %d", c->self, c->efd); close(c->efd); c->efd = -1; - } else if (len > 0) + } else { buffer_append(&c->extended, buf, len); + } } } return 1; @@ -1037,19 +1047,18 @@ } else { if (c->type != SSH_CHANNEL_OPEN) continue; - if (c->istate != CHAN_INPUT_OPEN && - c->istate != CHAN_INPUT_WAIT_DRAIN) - continue; } if (compat20 && (c->flags & (CHAN_CLOSE_SENT|CHAN_CLOSE_RCVD))) { + /* XXX is this true? */ debug("channel: %d: no data after CLOSE", c->self); continue; } /* Get the amount of buffered data for this channel. */ - len = buffer_len(&c->input); - if (len > 0) { + if ((c->istate == CHAN_INPUT_OPEN || + c->istate == CHAN_INPUT_WAIT_DRAIN) && + (len = buffer_len(&c->input)) > 0) { /* Send some data for the other side over the secure connection. */ if (compat20) { if (len > c->remote_window) @@ -1089,6 +1098,9 @@ c->remote_window > 0 && (len = buffer_len(&c->extended)) > 0 && c->extended_usage == CHAN_EXTENDED_READ) { + debug2("channel %d: rwin %d elen %d euse %d", + c->self, c->remote_window, buffer_len(&c->extended), + c->extended_usage); if (len > c->remote_window) len = c->remote_window; if (len > c->remote_maxpacket) @@ -1100,6 +1112,7 @@ packet_send(); buffer_consume(&c->extended, len); c->remote_window -= len; + debug2("channel %d: sent ext data %d", c->self, len); } } } From markus.friedl at informatik.uni-erlangen.de Mon Feb 26 00:45:39 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sun, 25 Feb 2001 14:45:39 +0100 Subject: Lets try this push again.. 2.5.1p2 bugs left. In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Feb 23, 2001 at 07:05:21PM -0600 References: <20010222091358.G11850@faui02.informatik.uni-erlangen.de> Message-ID: <20010225144539.B13131@folly> the patch is in session.c rev 1.57 On Fri, Feb 23, 2001 at 07:05:21PM -0600, mouring at etoh.eviladmin.org wrote: > On Thu, 22 Feb 2001, Markus Friedl wrote: > > > i think i have to add a workaround for buggy windows clients+x11fwd. > > > > Let me know when you have. I've not been following the OpenBSD and I > noticed a lot of files have been touched. > > - Ben > > From dunlap at apl.washington.edu Mon Feb 26 05:43:03 2001 From: dunlap at apl.washington.edu (John Dunlap) Date: Sun, 25 Feb 2001 10:43:03 -0800 (PST) Subject: intermittent stderr In-Reply-To: <20010225172859.A5291@folly> from "Markus Friedl" at Feb 25, 2001 05:28:59 PM Message-ID: <200102251843.KAA29114@ohm.apl.washington.edu> The patches below seem to cure the total lack of response, but there are still "select: Bad file descriptor" messages. I patched two machines, a fast (500-P3) and a slow(166-P1) and ran this script from the slow one. I started with a clean OpenSSH-2.5.1p1 tar ball. Both machines are RHL6.2 with all RPM updates except recent February kernel upgrade. --John # cat tst #!/bin/sh while [ 1 ] do date ssh fasthost ls -l /doesnotexist done # sh tst Sun Feb 25 10:40:00 PST 2001 ls: /doesnotexist: No such file or directory Sun Feb 25 10:40:04 PST 2001 select: Bad file descriptor Sun Feb 25 10:40:08 PST 2001 ls: /doesnotexist: No such file or directory Sun Feb 25 10:40:11 PST 2001 select: Bad file descriptor Sun Feb 25 10:40:15 PST 2001 ls: select: Bad file descriptor Sun Feb 25 10:40:18 PST 2001 ls: /doesnotexist: No such file or directory Sun Feb 25 10:40:22 PST 2001 ls: /doesnotexist: No such file or directory Sun Feb 25 10:40:25 PST 2001 ls: /doesnotexist: No such file or directory Sun Feb 25 10:40:29 PST 2001 ls: /doesnotexist: No such file or directory Sun Feb 25 10:40:33 PST 2001 > > On Thu, Feb 22, 2001 at 02:30:43PM -0800, John Dunlap wrote: > > The command "ssh ls -l /doesnotexist" gives various responses: > > please try this patch. > > after close of stdin/out remaining stderr data is ignored > in the 'channel' layer of openssh-current. > > > Index: nchan.c > =================================================================== > RCS file: /home/markus/cvs/ssh/nchan.c,v > retrieving revision 1.22 > diff -u -r1.22 nchan.c > --- nchan.c 2001/01/21 19:05:52 1.22 > +++ nchan.c 2001/02/25 16:19:55 > @@ -406,14 +406,40 @@ > { > debug3("channel %d: chan_delete_if_full_closed2: istate %d ostate %d", > c->self, c->istate, c->ostate); > + > if (c->istate == CHAN_INPUT_CLOSED && c->ostate == CHAN_OUTPUT_CLOSED) { > - if (!(c->flags & CHAN_CLOSE_SENT)) { > - chan_send_close2(c); > - } > - if ((c->flags & CHAN_CLOSE_SENT) && > - (c->flags & CHAN_CLOSE_RCVD)) { > - debug("channel %d: full closed2", c->self); > - channel_free(c->self); > + /* > + * we have to delay the close message if the efd (for stderr) > + * is still active > + */ > + if (((c->extended_usage != CHAN_EXTENDED_IGNORE) && > + buffer_len(&c->extended) > 0) > +#if 0 > + || ((c->extended_usage == CHAN_EXTENDED_READ) && > + c->efd != -1) > +#endif > + ) { > + debug2("channel %d: active efd: %d len %d type %s", > + c->self, c->efd, buffer_len(&c->extended), > + c->extended_usage==CHAN_EXTENDED_READ ? > + "read": "write"); > + } else { > +#if 0 > + if (c->efd != -1) { > + debug("channel %d: delayed close for efd %d", > + c->self, c->efd); > + close(c->efd); > + c->efd = -1; > + } > +#endif > + if (!(c->flags & CHAN_CLOSE_SENT)) { > + chan_send_close2(c); > + } > + if ((c->flags & CHAN_CLOSE_SENT) && > + (c->flags & CHAN_CLOSE_RCVD)) { > + debug("channel %d: full closed2", c->self); > + channel_free(c->self); > + } > } > } > } > Index: channels.c > =================================================================== > RCS file: /home/markus/cvs/ssh/channels.c,v > retrieving revision 1.92 > diff -u -r1.92 channels.c > --- channels.c 2001/02/16 13:38:18 1.92 > +++ channels.c 2001/02/25 16:12:59 > @@ -824,7 +824,14 @@ > buffer_len(&c->extended)); > debug2("channel %d: written %d to efd %d", > c->self, len, c->efd); > - if (len > 0) { > + if (len < 0 && (errno == EINTR || errno == EAGAIN)) > + return 1; > + if (len <= 0) { > + debug2("channel %d: closing write-efd %d", > + c->self, c->efd); > + close(c->efd); > + c->efd = -1; > + } else { > buffer_consume(&c->extended, len); > c->local_consumed += len; > } > @@ -833,13 +840,16 @@ > len = read(c->efd, buf, sizeof(buf)); > debug2("channel %d: read %d from efd %d", > c->self, len, c->efd); > - if (len == 0) { > - debug("channel %d: closing efd %d", > + if (len < 0 && (errno == EINTR || errno == EAGAIN)) > + return 1; > + if (len <= 0) { > + debug2("channel %d: closing read-efd %d", > c->self, c->efd); > close(c->efd); > c->efd = -1; > - } else if (len > 0) > + } else { > buffer_append(&c->extended, buf, len); > + } > } > } > return 1; > @@ -1037,19 +1047,18 @@ > } else { > if (c->type != SSH_CHANNEL_OPEN) > continue; > - if (c->istate != CHAN_INPUT_OPEN && > - c->istate != CHAN_INPUT_WAIT_DRAIN) > - continue; > } > if (compat20 && > (c->flags & (CHAN_CLOSE_SENT|CHAN_CLOSE_RCVD))) { > + /* XXX is this true? */ > debug("channel: %d: no data after CLOSE", c->self); > continue; > } > > /* Get the amount of buffered data for this channel. */ > - len = buffer_len(&c->input); > - if (len > 0) { > + if ((c->istate == CHAN_INPUT_OPEN || > + c->istate == CHAN_INPUT_WAIT_DRAIN) && > + (len = buffer_len(&c->input)) > 0) { > /* Send some data for the other side over the secure connection. */ > if (compat20) { > if (len > c->remote_window) > @@ -1089,6 +1098,9 @@ > c->remote_window > 0 && > (len = buffer_len(&c->extended)) > 0 && > c->extended_usage == CHAN_EXTENDED_READ) { > + debug2("channel %d: rwin %d elen %d euse %d", > + c->self, c->remote_window, buffer_len(&c->extended), > + c->extended_usage); > if (len > c->remote_window) > len = c->remote_window; > if (len > c->remote_maxpacket) > @@ -1100,6 +1112,7 @@ > packet_send(); > buffer_consume(&c->extended, len); > c->remote_window -= len; > + debug2("channel %d: sent ext data %d", c->self, len); > } > } > } > From cmadams at hiwaay.net Mon Feb 26 09:04:25 2001 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 25 Feb 2001 16:04:25 -0600 Subject: Problem with sftp-server on Tru64 (long long type and %ll) Message-ID: <20010225160425.A3322@HiWAAY.net> The ls_file function in sftp-server.c calls snprintf with "%8llu" as part of the format string and a "unsigned long long" type argument. The "%ll" format is not a valid format on Tru64 (at least 4.0F). Apparently it can confuse snprintf as well - sftp-server will segfault and core dump if the user types "ls". This isn't really a needed format string on Tru64 anyway, since "long long" is just the same as "long" - both are 8 bytes. Switching to "%8lu" instead works fine. I'm not sure of the "best" way to fix this; as far as I can find, there is only one place in OpenSSH (except for some debugging code in sftp-client.c and sftp-server.c) that the "%llu" format is used. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mouring at etoh.eviladmin.org Mon Feb 26 10:05:04 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 25 Feb 2001 17:05:04 -0600 (CST) Subject: Problem with sftp-server on Tru64 (long long type and %ll) In-Reply-To: <20010225160425.A3322@HiWAAY.net> Message-ID: A solution that you can test is to go into your config.h and set this: /* Define if your snprintf is busted */ /* #undef BROKEN_SNPRINTF */ Then recompile and see if sftp-server and sftp work correctly. If that solves it then it may be better to use the internal snprintf() then Tru64's. - Ben On Sun, 25 Feb 2001, Chris Adams wrote: > The ls_file function in sftp-server.c calls snprintf with "%8llu" as > part of the format string and a "unsigned long long" type argument. > > The "%ll" format is not a valid format on Tru64 (at least 4.0F). > Apparently it can confuse snprintf as well - sftp-server will segfault > and core dump if the user types "ls". > > This isn't really a needed format string on Tru64 anyway, since "long > long" is just the same as "long" - both are 8 bytes. Switching to > "%8lu" instead works fine. > > I'm not sure of the "best" way to fix this; as far as I can find, there > is only one place in OpenSSH (except for some debugging code in > sftp-client.c and sftp-server.c) that the "%llu" format is used. > From cmadams at hiwaay.net Mon Feb 26 09:31:47 2001 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 25 Feb 2001 16:31:47 -0600 Subject: Problem with sftp-server on Tru64 (long long type and %ll) In-Reply-To: ; from mouring@etoh.eviladmin.org on Sun, Feb 25, 2001 at 05:05:04PM -0600 References: <20010225160425.A3322@HiWAAY.net> Message-ID: <20010225163147.B3322@HiWAAY.net> Once upon a time, mouring at etoh.eviladmin.org said: > A solution that you can test is to go into your config.h and set this: > > /* Define if your snprintf is busted */ > /* #undef BROKEN_SNPRINTF */ Well, BROKEN_SNPRINTF is a noop - there is no code that uses this define (it should probably be removed from the config header). > Then recompile and see if sftp-server and sftp work correctly. If that > solves it then it may be better to use the internal snprintf() then > Tru64's. Recompiling with HAVE_SNPRINTF and HAVE_VSNPRINTF both undefined fixes it (but of course make the resulting binaries larger). However, is that the right thing to do? Is st->st_size (defined as off_t) really a long long? It isn't under Tru64 or Linux/Alpha (or really, long long is the same as just long and it is defined as long) and it isn't under Linux/x86 unless additional defines are added for large file support. Only sftp-client.c and sftp-server.c seem to use long long and the %llu format; what does scp do with large files? Is there a standard that specifies "ll" as a valid format modifier for u and d? Without additional defines, off_t is usually a long anyway. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mouring at etoh.eviladmin.org Mon Feb 26 11:17:47 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 25 Feb 2001 18:17:47 -0600 (CST) Subject: Problem with sftp-server on Tru64 (long long type and %ll) In-Reply-To: <20010225163147.B3322@HiWAAY.net> Message-ID: On Sun, 25 Feb 2001, Chris Adams wrote: > Once upon a time, mouring at etoh.eviladmin.org said: > > A solution that you can test is to go into your config.h and set this: > > > > /* Define if your snprintf is busted */ > > /* #undef BROKEN_SNPRINTF */ > > Well, BROKEN_SNPRINTF is a noop - there is no code that uses this > define (it should probably be removed from the config header). > Hmm.. Extermely odd.. Wonder where that code went to. BROKEN_SNPRINTF is suppost to be a valid define. It's suppose to unset HAVE_SNPRINTF and HAVE_VNSPRINTF so the internal snprintf/vsnrpintf take over for platforms that have string termination issues. Ahh.. I see what happened. When the version of bsd-snprintf.c was replaced with the one from Mutt the BROKE_SNPRINTF check never made it back in. I'll resolve that now. - Ben From tim at multitalents.net Mon Feb 26 16:45:39 2001 From: tim at multitalents.net (Tim Rice) Date: Sun, 25 Feb 2001 21:45:39 -0800 (PST) Subject: NeXT 3.3 vs openssh-2.5.1p1 (Couldn't restore privileges) In-Reply-To: <20010225103157.A24968@greenie.muc.de> Message-ID: On Sun, 25 Feb 2001, Gert Doering wrote: > Hi, > > On Sat, Feb 24, 2001 at 08:04:13PM -0600, mouring at etoh.eviladmin.org wrote: > > [..] > > > Bagged openssh-2.5.1p1, went thru it again, only to find ssh fatals out w/ > > > Couldn't restore privileges. > > > > > FYI.. Use 'prngd' and do --with-egd-pool=/path/to/random and this will > > solve your problem about "Couldn't restore priviledges." This is an issue > > with just using the pure-built in Entropy system. > > Yes, but that won't work on SCO 3, as it doesn't have unix sockets :-( > > What I don't really understand is why the seteuid() stuff in entropy.c > isn't working here - from the docs, it should... - how is uid changing > done in other parts of ssh? See uidswap.c Have a look at this patch. It might work (it does run) but it might be doing the wrong thing security wise. I came up with this after looking at uidswap.c For SCO 3 and NeXT, #define SAVED_IDS_DO_NOT_WORK_WITH_SETEUID > > gert > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- openssh_cvs/entropy.c.old Sun Feb 18 11:04:39 2001 +++ openssh_cvs/entropy.c Sun Feb 25 21:38:19 2001 @@ -825,13 +825,36 @@ prng_seed_saved = 0; /* Give up privs while reading seed file */ +#ifndef SAVED_IDS_DO_NOT_WORK_WITH_SETEUID if ((original_uid != original_euid) && (seteuid(original_uid) == -1)) fatal("Couldn't give up privileges"); +#else /* SAVED_IDS_DO_NOT_WORK_WITH_SETEUID */ + if (original_uid != original_euid) + { + /* Propagate the privileged uid to all of our uids. */ + /* Set the effective uid to the given (unprivileged) uid. */ + if ((setuid(original_euid) || seteuid(original_uid)) == -1) + fatal("Couldn't give up privileges"); + } +#endif /* SAVED_IDS_DO_NOT_WORK_WITH_SETEUID */ prng_read_seedfile(); +#ifndef SAVED_IDS_DO_NOT_WORK_WITH_SETEUID if ((original_uid != original_euid) && (seteuid(original_euid) == -1)) fatal("Couldn't restore privileges"); +#else /* SAVED_IDS_DO_NOT_WORK_WITH_SETEUID */ + /* + * We are unable to restore the real uid to its unprivileged value. + * Propagate the real uid (usually more privileged) to effective uid + * as well. + */ + if (original_uid != original_euid) + { + if ((seteuid(original_euid) || setuid(original_uid)) == -1) + fatal("Couldn't restore privileges"); + } +#endif /* SAVED_IDS_DO_NOT_WORK_WITH_SETEUID */ fatal_add_cleanup(prng_seed_cleanup, NULL); atexit(prng_write_seedfile); From djm at mindrot.org Mon Feb 26 20:44:52 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 26 Feb 2001 20:44:52 +1100 (EST) Subject: NeXT 3.3 vs openssh-2.5.1p1 (Couldn't restore privileges) In-Reply-To: Message-ID: On Sun, 25 Feb 2001, Tim Rice wrote: > See uidswap.c > > Have a look at this patch. It might work (it does run) but > it might be doing the wrong thing security wise. > I came up with this after looking at uidswap.c > > For SCO 3 and NeXT, > #define SAVED_IDS_DO_NOT_WORK_WITH_SETEUID Can you give this patch a try? Index: ChangeLog =================================================================== RCS file: /var/cvs/openssh/ChangeLog,v retrieving revision 1.822 diff -u -r1.822 ChangeLog --- ChangeLog 2001/02/25 23:20:40 1.822 +++ ChangeLog 2001/02/26 09:43:57 @@ -1,5 +1,7 @@ 20010226 - (bal) Fixed bsd-snprinf.c so it now honors 'BROKEN_SNPRINTF' again. + - (djm) Some systems (SCO3, NeXT) have weird saved uid semantics. + Based on patch from Tim Rice 20010225 - (djm) Use %{_libexecdir} rather than hardcoded path in RPM specfile Index: acconfig.h =================================================================== RCS file: /var/cvs/openssh/acconfig.h,v retrieving revision 1.103 diff -u -r1.103 acconfig.h --- acconfig.h 2001/02/24 21:41:10 1.103 +++ acconfig.h 2001/02/26 09:43:57 @@ -296,6 +296,9 @@ /* Define if X11 doesn't support AF_UNIX sockets on that system */ #undef NO_X11_UNIX_SOCKETS +/* Needed for SCO and NeXT */ +#undef SAVED_IDS_WORK_WITH_SETEUID + @BOTTOM@ /* ******************* Shouldn't need to edit below this line ************** */ Index: configure.in =================================================================== RCS file: /var/cvs/openssh/configure.in,v retrieving revision 1.253 diff -u -r1.253 configure.in --- configure.in 2001/02/24 21:41:11 1.253 +++ configure.in 2001/02/26 09:43:57 @@ -152,6 +152,7 @@ AC_DEFINE(HAVE_NEXT) AC_DEFINE(BROKEN_REALPATH) AC_DEFINE(USE_PIPES) + AC_DEFINE(SAVED_IDS_WORK_WITH_SETEUID) CPPFLAGS="$CPPFLAGS -I/usr/local/include" CFLAGS="$CFLAGS" ;; @@ -238,6 +239,7 @@ AC_DEFINE(HAVE_SCO_PROTECTED_PW) AC_DEFINE(DISABLE_SHADOW) AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) + AC_DEFINE(SAVED_IDS_WORK_WITH_SETEUID) AC_CHECK_FUNCS(getluid setluid) ;; *-*-sco3.2v5*) @@ -252,6 +254,7 @@ AC_DEFINE(HAVE_SCO_PROTECTED_PW) AC_DEFINE(DISABLE_SHADOW) AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) + AC_DEFINE(SAVED_IDS_WORK_WITH_SETEUID) AC_CHECK_FUNCS(getluid setluid) ;; *-dec-osf*) Index: entropy.c =================================================================== RCS file: /var/cvs/openssh/entropy.c,v retrieving revision 1.29 diff -u -r1.29 entropy.c --- entropy.c 2001/02/18 11:34:32 1.29 +++ entropy.c 2001/02/26 09:43:57 @@ -825,13 +825,34 @@ prng_seed_saved = 0; /* Give up privs while reading seed file */ +#ifdef SAVED_IDS_WORK_WITH_SETEUID if ((original_uid != original_euid) && (seteuid(original_uid) == -1)) fatal("Couldn't give up privileges"); +#else /* SAVED_IDS_WORK_WITH_SETEUID */ + /* + * Propagate the privileged uid to all of our uids. + * Set the effective uid to the given (unprivileged) uid. + */ + if (original_uid != original_euid && setuid(original_euid) == -1 || + seteuid(original_uid) == -1) + fatal("Couldn't give up privileges"); +#endif /* SAVED_IDS_WORK_WITH_SETEUID */ prng_read_seedfile(); +#ifdef SAVED_IDS_WORK_WITH_SETEUID if ((original_uid != original_euid) && (seteuid(original_euid) == -1)) fatal("Couldn't restore privileges"); +#else /* SAVED_IDS_WORK_WITH_SETEUID */ + /* + * We are unable to restore the real uid to its unprivileged value. + * Propagate the real uid (usually more privileged) to effective uid + * as well. + */ + if (original_uid != original_euid && seteuid(original_euid) == -1 || + setuid(original_uid) == -1) + fatal("Couldn't restore privileges"); +#endif /* SAVED_IDS_WORK_WITH_SETEUID */ fatal_add_cleanup(prng_seed_cleanup, NULL); atexit(prng_write_seedfile); -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Mon Feb 26 20:46:26 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 26 Feb 2001 20:46:26 +1100 (EST) Subject: sftp client In-Reply-To: Message-ID: On Fri, 23 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > I have now further investigated the problem and found a solution to > > avoid the sftp-server hanging around. > > > > The OpenSSH sftp closes the sockets/pipes (dependent of the value of > > USE_PIPES) and then kills it's underlying ssh by calling kill(ssh, SIGHUP). > > > > This `kill' kills the underlying ssh immediately instead of giving > > time to cleanup. This results in breaking the connection to the sshd > > which in turn misses to cleanup it's connection to the subsystem. > > > [..] > > What was the final decision in on this patch? Is there going to be a > different fix in the OpenSSH tree or should I apply this before 2.5.1p2? Fine with me - except the shutdown() stuff shouldn't be conditional on cygwin. i.e we should always use it when using socketpairs. Commit at your leisure :) -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From j.petersen at msh.de Mon Feb 26 21:49:07 2001 From: j.petersen at msh.de (=?iso-8859-1?Q?=22Petersen=2C_J=F6rg=22?=) Date: Mon, 26 Feb 2001 11:49:07 +0100 Subject: openssh-2.5.1p1 on AIX Message-ID: Probabely / (root-Home) doesn't belong to the user "root"... J?rg Petersen -----Original Message----- From: Chuck [mailto:chuck at fiu.edu] ... I've built openssh-2.5.1p1 on an AIX 4.3.3 box, and attempted to use the public/private key authentication mechanism. This appears to work for a non-root user locally, but not for the root user. From f33003a at cc.hut.fi Tue Feb 27 06:01:58 2001 From: f33003a at cc.hut.fi (=?iso-8859-1?Q?Oskari_J=E4=E4skel=E4inen?=) Date: Mon, 26 Feb 2001 21:01:58 +0200 Subject: Packet integrity error. (34) Message-ID: <20010226210158.A105896@leka.hut.fi> Hi! Just mailing in order to report, that the patch from Markus on 2001-02-22 fixes the X11 forwarding problem also for a (broken) F-Secure SSH 1.0 client. (Of course, the missing right parenthesis had to be added.) Greetings, Oskari ----------------------------------------------------------------- Oskari Jaaskelainen Laboratory of Physics Oskari.Jaaskelainen at hut_DOT_fi Helsinki University of Technology tel +358-9-451 3110 P.O.Box 1100 fax +358-9-451 3116 02015 HUT, Finland ----------------------------------------------------------------- From wendyp at cray.com Tue Feb 27 06:01:25 2001 From: wendyp at cray.com (Wendy Palm) Date: Mon, 26 Feb 2001 13:01:25 -0600 Subject: X11 display issues References: Message-ID: <3A9AA805.D71FCCED@cray.com> mouring at etoh.eviladmin.org wrote: > > On Thu, 22 Feb 2001, Wendy Palm wrote: > > > you are, of course, correct. i knew that, but did it wrong anyway. > > > > here is a resend, in a more proper format- > > > > I'm applying most of this. I'd perfer to put the NO_X11_UNIX_SOCKETS > defines in the configure.in. If you could let me know what what the > correct target-host section is I'd be grateful. i'd planned on keeping the unicos out of the configure until i'm sure it's running properly, so users don't download & use til i'm ready to support it :) > Out of interest, how large of a patch are we looking at to sync Cray > support up to the Portable tree, and is it fully functional? i don't want to take too much credit for this myself. bill jones did an awful lot of work on it. i'm just in the test, cleanup, learn-how-the- heck-it-works-so-i-can-support-it phase. the unicos port is currently changes to 13 files, mostly small, and the addition of a bunch of code for login initialization (~200 lines). i've run into a few problems that i don't know if they are real problems or my configuration problems, so i haven't sent them out. i'm ready to send quite a bit of it though. > BTW, if you ever have a spare Cray feel free to send it about 2 miles > south of your Eagan branch.. I'd be happy to play on one.=) http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=1216561107 or something a little closer to home.... http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=1216827942 :) > > - Ben -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From mouring at etoh.eviladmin.org Tue Feb 27 07:07:08 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 26 Feb 2001 14:07:08 -0600 (CST) Subject: X11 display issues In-Reply-To: <3A9AA805.D71FCCED@cray.com> Message-ID: On Mon, 26 Feb 2001, Wendy Palm wrote: > mouring at etoh.eviladmin.org wrote: > > > > On Thu, 22 Feb 2001, Wendy Palm wrote: > > > > > you are, of course, correct. i knew that, but did it wrong anyway. > > > > > > here is a resend, in a more proper format- > > > > > > > I'm applying most of this. I'd perfer to put the NO_X11_UNIX_SOCKETS > > defines in the configure.in. If you could let me know what what the > > correct target-host section is I'd be grateful. > > i'd planned on keeping the unicos out of the configure until i'm sure > it's running properly, so users don't download & use til i'm ready > to support it :) > Very reasonable. =) [..] > > BTW, if you ever have a spare Cray feel free to send it about 2 miles > > south of your Eagan branch.. I'd be happy to play on one.=) > > http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=1216561107 > > or something a little closer to home.... > > http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=1216827942 > > :) > > Hmm... My appartment I don't think is big enough (nor is my wallet). Oh well.. I guess I'll have to take a job at a place with one. =) Thanks for the update. - Ben From wendyp at cray.com Tue Feb 27 06:18:35 2001 From: wendyp at cray.com (Wendy Palm) Date: Mon, 26 Feb 2001 13:18:35 -0600 Subject: X11 display issues References: Message-ID: <3A9AAC0B.6303DA8@cray.com> mouring at etoh.eviladmin.org wrote: > > On Mon, 26 Feb 2001, Wendy Palm wrote: > > > mouring at etoh.eviladmin.org wrote: > > > > > > On Thu, 22 Feb 2001, Wendy Palm wrote: > > > > > > > you are, of course, correct. i knew that, but did it wrong anyway. > > > > > > > > here is a resend, in a more proper format- > > > > > > > > > > I'm applying most of this. I'd perfer to put the NO_X11_UNIX_SOCKETS > > > defines in the configure.in. If you could let me know what what the > > > correct target-host section is I'd be grateful. > > > > i'd planned on keeping the unicos out of the configure until i'm sure > > it's running properly, so users don't download & use til i'm ready > > to support it :) > > > Very reasonable. =) > > [..] > > > BTW, if you ever have a spare Cray feel free to send it about 2 miles > > > south of your Eagan branch.. I'd be happy to play on one.=) > > > > http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=1216561107 > > > > or something a little closer to home.... > > > > http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=1216827942 > > > > :) > > > > > > Hmm... My appartment I don't think is big enough (nor > is my wallet). Oh well.. I guess I'll have to take a job at a place with > one. =) > > Thanks for the update. > > - Ben we *ARE* hiring, you know..... then you can play with more than just one.... :) -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From grenier at nef.esiea.fr Fri Feb 23 22:43:39 2001 From: grenier at nef.esiea.fr (Christophe GRENIER) Date: Fri, 23 Feb 2001 12:43:39 +0100 (CET) Subject: OpenSSH_2.5.1p1 - RH 6.2 Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp Size: 5310 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010223/42964bfc/attachment-0001.bin From mouring at etoh.eviladmin.org Tue Feb 27 07:48:19 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 26 Feb 2001 14:48:19 -0600 (CST) Subject: OpenSSH_2.5.1p1 - RH 6.2 In-Reply-To: Message-ID: OpenSSH_2.5.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f ^^^^^^^^^^^^^^^ The OpenSSH package was compiled against 0.9.6. Attempting to dynamicly link it against 0.9.5a produces very bad mo-jo. Please upgrade your OpenSSL RPM. - Ben From matthew_carlson at non.hp.com Tue Feb 27 08:27:15 2001 From: matthew_carlson at non.hp.com (CARLSON,MATTHEW (Non-HP-Cupertino,ex1)) Date: Mon, 26 Feb 2001 13:27:15 -0800 Subject: Openssh 2.5.1p1 and 2.3.0p1 rsa_public_encrypt() exponent too sma ll or not odd with the Openssh/SSH 1 or 1.5 protocal Message-ID: <4341EF5F8B4AD311AB4B00902740B9F2046056FB@xcup02.cup.hp.com> > I am attempting to migrate over to OpenSSH from SSH 1.2.27. I love the > code by the way. I am just having some trouble. > > The trouble is I keep getting the rsa_public_encrypt() exponent too small > or not odd with the SSH 1 or 1.5 protocols. I get that even trying to > communicate with the same OpenSSH release. The only thing that works is > the SSH 2 protocol. > > > Platform notes: > > HP-UX 11.00 Dart 51 64bit > OpenSSL 0.9.6 > Zlib 1.1.3 > > Cflags: > -Ae > > > I have tried with and without optimizations. I noticed that this problem > has cropped up in the past or other platforms. But that was one much older > releases. > > > Anyone got any ideas? > > > Yes HP unofficially loves OpenSSH. They might officially too I just am not > the one to say it. > > Great code guys/gals. > > > > > Matthew Carlson From djm at mindrot.org Tue Feb 27 08:34:47 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 27 Feb 2001 08:34:47 +1100 (EST) Subject: OpenSSH_2.5.1p1 - RH 6.2 In-Reply-To: Message-ID: On Mon, 26 Feb 2001 mouring at etoh.eviladmin.org wrote: > > OpenSSH_2.5.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f > ^^^^^^^^^^^^^^^ > > The OpenSSH package was compiled against 0.9.6. Attempting to > dynamicly link it against 0.9.5a produces very bad mo-jo. Please > upgrade your OpenSSL RPM. How about we put something like: if (SSLeay() != OPENSSL_VERSION_NUMBER) fatal("OpenSSL version mismatch. Built against %x, you have %x", OPENSSL_VERSION_NUMBER, SSLeay()); at the start of every executable to kill this thing once and for all. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Tue Feb 27 08:37:32 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 27 Feb 2001 08:37:32 +1100 (EST) Subject: OpenSSH_2.5.1p1 - RH 6.2 In-Reply-To: Message-ID: On Tue, 27 Feb 2001, Damien Miller wrote: > How about we put something like: > > if (SSLeay() != OPENSSL_VERSION_NUMBER) > fatal("OpenSSL version mismatch. Built against %x, you have %x", > OPENSSL_VERSION_NUMBER, SSLeay()); > > at the start of every executable to kill this thing once and for all. I might put this in init_rng() so we get it without any more disruption. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From mouring at etoh.eviladmin.org Tue Feb 27 09:31:31 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 26 Feb 2001 16:31:31 -0600 (CST) Subject: OpenSSH_2.5.1p1 - RH 6.2 In-Reply-To: Message-ID: On Tue, 27 Feb 2001, Damien Miller wrote: > On Mon, 26 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > > > OpenSSH_2.5.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f > > ^^^^^^^^^^^^^^^ > > > > The OpenSSH package was compiled against 0.9.6. Attempting to > > dynamicly link it against 0.9.5a produces very bad mo-jo. Please > > upgrade your OpenSSL RPM. > > How about we put something like: > Do you think we need this? When new RPMs are issued it will have a dependancy of whatever version you linked OpenSSH against. Which should be enough for RPM. I've not seen this occur outside of installing the precompiled RPMS. - Ben From djm at mindrot.org Tue Feb 27 08:41:57 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 27 Feb 2001 08:41:57 +1100 (EST) Subject: OpenSSH_2.5.1p1 - RH 6.2 In-Reply-To: Message-ID: On Mon, 26 Feb 2001 mouring at etoh.eviladmin.org wrote: > Do you think we need this? When new RPMs are issued it will have > a dependancy of whatever version you linked OpenSSH against. Which should > be enough for RPM. I've not seen this occur outside of installing the > precompiled RPMS. I have seen it on Solaris as well - shared OpenSSL libs are just more common on Linux, but recent versions of OpenSSL have made it much easier to build shared libs on other platforms so I suspect we will see it more in the future. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From devon at admin2.gisnetworks.com Tue Feb 27 08:48:07 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Mon, 26 Feb 2001 13:48:07 -0800 Subject: OpenSSH_2.5.1p1 - RH 6.2 References: Message-ID: <3A9ACF17.7AE09D47@admin2.gisnetworks.com> what about just distributing statically linked binaries? devon Damien Miller wrote: > > On Mon, 26 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > Do you think we need this? When new RPMs are issued it will have > > a dependancy of whatever version you linked OpenSSH against. Which should > > be enough for RPM. I've not seen this occur outside of installing the > > precompiled RPMS. > > I have seen it on Solaris as well - shared OpenSSL libs are just more > common on Linux, but recent versions of OpenSSL have made it much easier > to build shared libs on other platforms so I suspect we will see it more > in the future. > > -d > > -- > | Damien Miller \ ``E-mail attachments are the poor man's > | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Tue Feb 27 08:52:32 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 27 Feb 2001 08:52:32 +1100 (EST) Subject: OpenSSH_2.5.1p1 - RH 6.2 In-Reply-To: <3A9ACF17.7AE09D47@admin2.gisnetworks.com> Message-ID: On Mon, 26 Feb 2001, Devon Bleak wrote: > what about just distributing statically linked binaries? That doesn't prevent people from screwing it up themselves, the static ones are also a fair bit larger: [djm at mothra openssh]$ ls -l ssh -rwxrwxr-x 1 djm djm 634047 Feb 27 08:51 ssh [djm at mothra openssh]$ gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o log-client.o readconf.o clientloop.o -L. -Lopenbsd-compat/ -lssh -lopenbsd-compat -lpam -ldl -lwrap -lz -lnsl -lutil /usr/lib/libcrypto.a [djm at mothra openssh]$ ls -l ssh -rwxrwxr-x 1 djm djm 1271097 Feb 27 08:52 ssh -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From pekkas at netcore.fi Tue Feb 27 09:08:11 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 27 Feb 2001 00:08:11 +0200 (EET) Subject: RPM .spec files: rsh requirement removed Message-ID: Hello all, I think it's time to remove /usr/bin/rsh as a build requirement from contrib/*/*.spec files. I really want to start getting rid of r* tools already.. :-) This has been there from OpenSSH 2.1.1p4 era or so because back then, if configure couldn't find /usr/bin/rsh, it wouldn't be defined at all (see below). Also, FallBackToRsh isn't enabled by default so this shouldn't be a problem. defines.h back long time ago: --- #ifndef _PATH_RSH # ifdef RSH_PATH # define _PATH_RSH RSH_PATH # endif /* RSH_PATH */ #endif /* _PATH_RSH */ --- Ie: no fallback to /usr/bin/rsh. Nowadays, this has been: --- #ifndef _PATH_RSH # ifdef RSH_PATH # define _PATH_RSH RSH_PATH # else /* RSH_PATH */ # define _PATH_RSH "/usr/bin/rsh" # endif /* RSH_PATH */ #endif /* _PATH_RSH */ --- So, even if rsh isn't found by configure at compile-time, for Red Hat Linux, and most other OS's (and this would only affect .spec files) this would go right by default anyway. Only, rsh backward will break with an error without this. But as it is off by default, I see no problems. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From mouring at etoh.eviladmin.org Tue Feb 27 10:08:15 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 26 Feb 2001 17:08:15 -0600 (CST) Subject: OpenSSH_2.5.1p1 - RH 6.2 In-Reply-To: Message-ID: On Tue, 27 Feb 2001, Damien Miller wrote: > On Mon, 26 Feb 2001 mouring at etoh.eviladmin.org wrote: > > > Do you think we need this? When new RPMs are issued it will have > > a dependancy of whatever version you linked OpenSSH against. Which should > > be enough for RPM. I've not seen this occur outside of installing the > > precompiled RPMS. > > I have seen it on Solaris as well - shared OpenSSL libs are just more > common on Linux, but recent versions of OpenSSL have made it much easier > to build shared libs on other platforms so I suspect we will see it more > in the future. > I'll buy that. Just so long as it has not affects on static compiling. - Ben From jmknoble at jmknoble.cx Tue Feb 27 09:19:40 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Mon, 26 Feb 2001 16:19:40 -0600 Subject: OpenSSH_2.5.1p1 - RH 6.2 In-Reply-To: ; from djm@mindrot.org on Tue, Feb 27, 2001 at 08:37:32AM +1100 References: Message-ID: <20010226161940.A2915@zax.half.pint-stowp.cx> Circa 2001-Feb-27 08:37:32 +1100 dixit Damien Miller: : On Tue, 27 Feb 2001, Damien Miller wrote: : > How about we put something like: : > : > if (SSLeay() != OPENSSL_VERSION_NUMBER) : > fatal("OpenSSL version mismatch. Built against %x, you have %x", : > OPENSSL_VERSION_NUMBER, SSLeay()); : > : > at the start of every executable to kill this thing once and for all. : : I might put this in init_rng() so we get it without any more disruption. I'd rather see a warning rather than a fatal error. This allows folks to use a hypothetical upwardly-compatible OpenSSL (if there ever is one) in the future without having to recompile the server. -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From bernerus at cs.chalmers.se Tue Feb 27 09:25:57 2001 From: bernerus at cs.chalmers.se (Christer =?iso-8859-1?Q?Bern=E9rus?=) Date: Mon, 26 Feb 2001 23:25:57 +0100 Subject: PAM Service Name Patch References: <200102230848.JAA02827@hotlips.cs.chalmers.se> <3A97135E.F0BC775B@bartlett.house> Message-ID: <3A9AD7F5.891F0458@cs.chalmers.se> Andrew Bartlett wrote: > Christer Bernerus wrote: > > > > What I, as a sysadmin would like to see is the possibility of not only > > having different service names for different programs, but also have them > > different depending on authentication method. > > > > One reason for this is that I would like to control who logs on to which > > machine, and *how*. Using passwords and using e.g. kerberos or AFS ticket > > transfers have results in different security exposures in the light of > > trojan horses, or user population on the machines. > > > > Consider the situation of university teachers logging in to student machines. > > In that case, we wouldn't like them to give their passwords, regardless of > > whether the passwords are encrypted in transfer or not. However doing Kerb5 > > ticket transfers probably is a different story since these tickets have > > time limits on their validity, something that passwords generally don't have, > > or at least have much longer validity. > > > > If there were an OTP password authentication method, there would be yet another > > method that would represent a different security risk, and could call for > > another policy vs who may log on. PAM is a good framework that not only can > > be used for selecting authentication policies, but also can be used for > > controlling authorization policy, regardless of the method of authentication. > > > > One way of enabling that kind of authz policy-making is to have different > > PAM service names for different authn-methods. > > > > Please forgive me if this have been discussed before. I'm new to this list. > > In that case, I'd be interested looking at som archived mail if available. > > > > Chris. > > > > > > I may be misunderstanding your situation - but this looks like a client > rather than a server issue: Do you administer your student machines? Well, yes. However I don't administer all of the ssh clients that my students or teachers/researchers use, as these use their laptops, home PC's, or log in from other universities while being somwhere else in the world. This leaves me with administering the servers. > > The ssh client can be quite easily configured as to what degree it will Well, the problem is that I cannot do that. See above. > > trust various servers - but if you don't trust the server its not really > worth hoping it will keep a sign up "I'm not to be trusted" after its > been rooted/reconfigured. No, I'm sure it won't do that. That's why I want to distrust the student's machines all the time, and force the teachers not to use password based authentication when entering the student machines. I can of course create separate accounts for them, but that creates a lot of administration and also lots of potentially unused accounts lying around. > > Certainly having a more flexible pam framework might be useful - i.e. > with OTP actually in PAM or with a different PAM configuration depending > on the client's name. For the vast majority of users the existing setup > actually works surprisingly well. Yes, sure. It has worked for us for several years, but the hacker/sysadmin war forces us to reconsider things that has beeen taken for granted for years. The future might call for new methods. > > Just make sure your doing it for the right reasons, Well, there are reasons, as you see, but it doesn't hurt having other people scrutinizing the lines of thinking, so I'm grateful for any opinions. I'm not at all sure that this is *the* way to go, but the change is a fairly simple one, and with a nice implementation there wouldn't be a need for everyone to adapt their installations. Cheers! ---- Chris. From djm at mindrot.org Tue Feb 27 09:30:18 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 27 Feb 2001 09:30:18 +1100 (EST) Subject: OpenSSH_2.5.1p1 - RH 6.2 In-Reply-To: <20010226161940.A2915@zax.half.pint-stowp.cx> Message-ID: On Mon, 26 Feb 2001, Jim Knoble wrote: > : I might put this in init_rng() so we get it without any more disruption. > > I'd rather see a warning rather than a fatal error. I would prefer to fail utterly rather than run a suid root program with suspect crypto code. > This allows folks > to use a hypothetical upwardly-compatible OpenSSL (if there ever is > one) in the future without having to recompile the server. heh - *every* version of SSLeay/OpenSSL has broken binary compatability in some way. I do hope that they get it together in the future, but I won't hold my breath (or suffer the stream of bugreports :) -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From dave at arsdigita.com Tue Feb 27 09:40:47 2001 From: dave at arsdigita.com (Drazen Kacar) Date: Mon, 26 Feb 2001 23:40:47 +0100 Subject: Problems with OpenSSH 2.5.1p1 on Solaris 8 Message-ID: <20010226234047.A30397@washington> Hi, I'm not subscribed, so keep me in cc. And thanks for having mailing-list open for posting. I had a couple of problems with OpenSSH on Solaris 8/MU3 + recent patches. 1) When I tried to use scp from any other host, sshd on Solaris host crashed with SIGSEGV. Here's the stack trace: core 'core.sshd.7637' of 7637: ./sshd -d -d -d fefb393c strncpy (ffbee074, 5, 7, 0, 21f2c, ffbee074) + 65c ff0561a8 pam_sm_open_session (4, 0, 3e938, 0, ff076000, 0) + 17c ff362b80 pam_open_session (ff3765c8, 0, ff376000, 13, 13, 0) + c8 0002e9c0 x11_connect_display (8f4a8, 0, 0, 0, 0, 0) + 104 0003a470 ???????? (9f5b0, 8d698, 0, 0, 0, 0) 0003941c ssh_dss_verify (88414, 9f5b0, 8d698, ffbeee50, 219b4, 38564) + 160 0003904c ssh_dss_sign (8d698, 0, 8d290, 400, 8d26c, 8f498) 0002a2b8 get_remote_hostname (5, 5, 28e, ffbef8c4, 4, 1) + 44 000278d0 session_open (4, ffbef94c, ffbef960, 80c00, 0, 0) + 5c 00024970 server_loop (0, 0, 0, 0, 0, 0) + 530 The relevant code is function do_pam_session() in auth-pam.c. The stack trace leads me to believe that there is a bug in Solaris pam_unix module, which is triggered if pam_open_session() is called, but PAM_TTY is not set with pam_set_item(). I worked around the problem by disabling pam_open_session() call if ttyname == NULL, but I haven't investigated the problem further. 2) OpenSSH does not read the default PATH from /etc/default/login. That's really bad, so I implemented the feature. The patch is attached. The code is guarded by HAVE_ETC_DEFAULT_LOGIN. I didn't make autoconf check, because I don't know if it's appropriate, ie. if there is any other system which has /etc/default/login, but with a different syntax. I'm also assuming that and mmap() will be available if HAVE_ETC_DEFAULT_LOGIN is defined, which might not be true for all systems. So integrate it as you see fit. -- .-. .-. Sarcasm is just one more service we offer. (_ \ / _) | dave at arsdigita.com | -------------- next part -------------- --- session.c.orig Mon Feb 26 14:36:13 2001 +++ session.c Mon Feb 26 17:03:10 2001 @@ -78,6 +78,10 @@ #define is_winnt (GetVersion() < 0x80000000) #endif +#ifdef HAVE_ETC_DEFAULT_LOGIN +#include +#endif + /* AIX limits */ #if defined(HAVE_GETUSERATTR) && !defined(S_UFSIZE_HARD) && defined(S_UFSIZE) # define S_UFSIZE_HARD S_UFSIZE "_hard" @@ -1173,6 +1177,12 @@ #endif if (!options.use_login) { +#ifdef HAVE_ETC_DEFAULT_LOGIN + int fd, pagesize; + struct stat inode; + char *onemore = MAP_FAILED, *logstr = MAP_FAILED; + char *pathstr; +#endif /* Set basic environment. */ child_set_env(&env, &envsize, "USER", pw->pw_name); child_set_env(&env, &envsize, "LOGNAME", pw->pw_name); @@ -1188,7 +1198,83 @@ * needed for loading shared libraries. So the path better * remains intact here. */ +# ifdef HAVE_ETC_DEFAULT_LOGIN + if ((fd = open("/etc/default/login", O_RDONLY)) < 0) + goto nocando; + + if (fstat(fd, &inode) != 0 || inode.st_size < 6) { + close(fd); + goto nocando; + } + logstr = mmap(NULL, inode.st_size, PROT_READ, MAP_SHARED, + fd, 0); + close(fd); + if(logstr == MAP_FAILED) + goto nocando; + pagesize = getpagesize(); + if (inode.st_size % pagesize == 0) { + /* + * Append one more page, because we need + * zero at EOF, otherwise string and memory + * functions could get SIGSEGV. + */ +#ifdef MAP_ANON + onemore = mmap(logstr + inode.st_size, pagesize, + PROT_READ, + MAP_SHARED | MAP_FIXED | MAP_ANON, + -1, 0); +#else + int fd2; + if ((fd2 = open("/dev/zero", O_RDONLY)) < 0) + goto nocando; + onemore = mmap(logstr + inode.st_size, pagesize, + PROT_READ, + MAP_SHARED | MAP_FIXED, + fd2, 0); + close(fd2); +#endif + if(onemore == MAP_FAILED) + goto nocando; + } + if (!memcmp(logstr, "PATH=", 5)) + pathstr = logstr - 1; + else + pathstr = strstr(logstr, "\nPATH="); + if (pathstr) { + char *nl; + + pathstr += 6; + nl = strchr(pathstr, '\n'); + if (!nl) { + /* + * EOF, so PATH is the last line + */ + child_set_env(&env, &envsize, "PATH", pathstr); + } else { + char *mypath; + size_t path_len; + + path_len = nl - pathstr; + mypath = xmalloc(path_len + 1); + memcpy(mypath, pathstr, path_len); + *(mypath + path_len) = 0; + child_set_env(&env, &envsize, "PATH", mypath); + xfree(mypath); + } + } else { +nocando: + child_set_env(&env, &envsize, "PATH", _PATH_STDPATH); + } + /* + * Cleanup the crap + */ + if(onemore != MAP_FAILED) + munmap(onemore, pagesize); + if(logstr != MAP_FAILED) + munmap(logstr, inode.st_size); +# else /* HAVE_ETC_DEFAULT_LOGIN */ child_set_env(&env, &envsize, "PATH", _PATH_STDPATH); +# endif /* HAVE_ETC_DEFAULT_LOGIN */ # endif /* HAVE_CYGWIN */ #endif /* HAVE_LOGIN_CAP */ From tim at multitalents.net Tue Feb 27 10:45:23 2001 From: tim at multitalents.net (Tim Rice) Date: Mon, 26 Feb 2001 15:45:23 -0800 (PST) Subject: NeXT 3.3 vs openssh-2.5.1p1 (Couldn't restore privileges) In-Reply-To: Message-ID: On Mon, 26 Feb 2001, Damien Miller wrote: > On Sun, 25 Feb 2001, Tim Rice wrote: > > > See uidswap.c > > > > Have a look at this patch. It might work (it does run) but > > it might be doing the wrong thing security wise. > > I came up with this after looking at uidswap.c > > > > For SCO 3 and NeXT, > > #define SAVED_IDS_DO_NOT_WORK_WITH_SETEUID > > Can you give this patch a try? This works on SCO 3 except you have it backwards on which platforms should have SAVED_IDS_WORK_WITH_SETEUID defined. *-next-*) and *-*-sco3.2v4*) are the only ones that should NOT have SAVED_IDS_WORK_WITH_SETEUID defined. All others (so far) should. And those platforms that do have it defined will get warning messages like "src/uidswap.c", line 32: warning: macro redefined: SAVED_IDS_WORK_WITH_SETEUID > > Index: ChangeLog > =================================================================== > RCS file: /var/cvs/openssh/ChangeLog,v > retrieving revision 1.822 > diff -u -r1.822 ChangeLog > --- ChangeLog 2001/02/25 23:20:40 1.822 > +++ ChangeLog 2001/02/26 09:43:57 > @@ -1,5 +1,7 @@ > 20010226 > - (bal) Fixed bsd-snprinf.c so it now honors 'BROKEN_SNPRINTF' again. > + - (djm) Some systems (SCO3, NeXT) have weird saved uid semantics. > + Based on patch from Tim Rice > > 20010225 > - (djm) Use %{_libexecdir} rather than hardcoded path in RPM specfile > Index: acconfig.h > =================================================================== > RCS file: /var/cvs/openssh/acconfig.h,v > retrieving revision 1.103 > diff -u -r1.103 acconfig.h > --- acconfig.h 2001/02/24 21:41:10 1.103 > +++ acconfig.h 2001/02/26 09:43:57 > @@ -296,6 +296,9 @@ > /* Define if X11 doesn't support AF_UNIX sockets on that system */ > #undef NO_X11_UNIX_SOCKETS > > +/* Needed for SCO and NeXT */ > +#undef SAVED_IDS_WORK_WITH_SETEUID > + > @BOTTOM@ > > /* ******************* Shouldn't need to edit below this line ************** */ > Index: configure.in > =================================================================== > RCS file: /var/cvs/openssh/configure.in,v > retrieving revision 1.253 > diff -u -r1.253 configure.in > --- configure.in 2001/02/24 21:41:11 1.253 > +++ configure.in 2001/02/26 09:43:57 > @@ -152,6 +152,7 @@ > AC_DEFINE(HAVE_NEXT) > AC_DEFINE(BROKEN_REALPATH) > AC_DEFINE(USE_PIPES) > + AC_DEFINE(SAVED_IDS_WORK_WITH_SETEUID) > CPPFLAGS="$CPPFLAGS -I/usr/local/include" > CFLAGS="$CFLAGS" > ;; > @@ -238,6 +239,7 @@ > AC_DEFINE(HAVE_SCO_PROTECTED_PW) > AC_DEFINE(DISABLE_SHADOW) > AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) > + AC_DEFINE(SAVED_IDS_WORK_WITH_SETEUID) > AC_CHECK_FUNCS(getluid setluid) > ;; > *-*-sco3.2v5*) > @@ -252,6 +254,7 @@ > AC_DEFINE(HAVE_SCO_PROTECTED_PW) > AC_DEFINE(DISABLE_SHADOW) > AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) > + AC_DEFINE(SAVED_IDS_WORK_WITH_SETEUID) > AC_CHECK_FUNCS(getluid setluid) > ;; > *-dec-osf*) > Index: entropy.c > =================================================================== > RCS file: /var/cvs/openssh/entropy.c,v > retrieving revision 1.29 > diff -u -r1.29 entropy.c > --- entropy.c 2001/02/18 11:34:32 1.29 > +++ entropy.c 2001/02/26 09:43:57 > @@ -825,13 +825,34 @@ > prng_seed_saved = 0; > > /* Give up privs while reading seed file */ > +#ifdef SAVED_IDS_WORK_WITH_SETEUID > if ((original_uid != original_euid) && (seteuid(original_uid) == -1)) > fatal("Couldn't give up privileges"); > +#else /* SAVED_IDS_WORK_WITH_SETEUID */ > + /* > + * Propagate the privileged uid to all of our uids. > + * Set the effective uid to the given (unprivileged) uid. > + */ > + if (original_uid != original_euid && setuid(original_euid) == -1 || > + seteuid(original_uid) == -1) > + fatal("Couldn't give up privileges"); > +#endif /* SAVED_IDS_WORK_WITH_SETEUID */ > > prng_read_seedfile(); > > +#ifdef SAVED_IDS_WORK_WITH_SETEUID > if ((original_uid != original_euid) && (seteuid(original_euid) == -1)) > fatal("Couldn't restore privileges"); > +#else /* SAVED_IDS_WORK_WITH_SETEUID */ > + /* > + * We are unable to restore the real uid to its unprivileged value. > + * Propagate the real uid (usually more privileged) to effective uid > + * as well. > + */ > + if (original_uid != original_euid && seteuid(original_euid) == -1 || > + setuid(original_uid) == -1) > + fatal("Couldn't restore privileges"); > +#endif /* SAVED_IDS_WORK_WITH_SETEUID */ > > fatal_add_cleanup(prng_seed_cleanup, NULL); > atexit(prng_write_seedfile); > > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From djm at mindrot.org Tue Feb 27 10:44:17 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 27 Feb 2001 10:44:17 +1100 (EST) Subject: NeXT 3.3 vs openssh-2.5.1p1 (Couldn't restore privileges) In-Reply-To: Message-ID: On Mon, 26 Feb 2001, Tim Rice wrote: > This works on SCO 3 except you have it backwards on which platforms > should have SAVED_IDS_WORK_WITH_SETEUID defined. > > *-next-*) and *-*-sco3.2v4*) are the only ones that should NOT have > SAVED_IDS_WORK_WITH_SETEUID defined. All others (so far) should. > > And those platforms that do have it defined will get warning messages like > "src/uidswap.c", line 32: warning: macro redefined: SAVED_IDS_WORK_WITH_SETEUID Yeah - Mark Miller showed me the error of my ways :) Try grabbing the CVS head in an hour or two (once the anoncvs server has rsynced). It will have the new fix which is reported to work on NeXT. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From ivan at es.usyd.edu.au Tue Feb 27 11:49:19 2001 From: ivan at es.usyd.edu.au (Ivan Teliatnikov) Date: Tue, 27 Feb 2001 11:49:19 +1100 Subject: tech question "sftp to ftponly accounts" Message-ID: <3A9AF98F.43101CF4@es.usyd.edu.au> Sorry guys, I am not meant to write to this list disturbing developers with a silly end user question, but this a matter of huge importance for me. I am running ssh-server on RedHat 6.1. Before we introduced ssh we had a couple of ftponly accounts for people downloading data from our university database. It appears that they cannot access ftponly account from any windows sftp clients. However it works fine for all normal users. May be you can give a hint on this matter. Many many thanks, Ivan. From dankamin at cisco.com Tue Feb 27 13:49:54 2001 From: dankamin at cisco.com (Dan Kaminsky) Date: Mon, 26 Feb 2001 18:49:54 -0800 Subject: SU vs. ssh root@host References: Message-ID: <01b001c0a067$f7096e80$006545ab@na.cisco.com> > Personally, I don't think the use of 'sshd' as a form of local > authentication is really any more secure then a well written 'su' on a > good solid audited OS. Once a cracker with half a brain has compermised > your system (via su, sshd, etc) you'll never see the log files unless you > are doing remote logging. This is when Dan slaps his forehead and says, "Oops." I'm *not* talking about: user at host1$ ssh root at 127.0.0.1 root at host1# I'm talking about: user at host1$ ssh root at host2 root at host2# Being *far* superior to: user at host1$ ssh user at host2 user at host2$ su root root at host2# Because there's no reason to actually believe user at host2 will actually execute /bin/su, not log characters, or whatnot. There's no way to know if .profile actually contained an app called hacksh, which was entirely adept at hiding its own existence through userspace(after all, all you know about a remote host is what it sends you--there's nothing to prevent a passthrough like hacksh starting up in .profile, hiding its existence from within itself, and preventing attempts to blindly clear it.) I argue, when connecting to a remote host, one should authenticate *directly* against the account one wishes to connect to. That way, only the trusted *root* process is receiving authentication material, as opposed to any random software that the user might have configured to load on startup. >From a purely theoretical point of view, it's better to *lose* permissions than *gain* them, because exploits don't generally *reduce* access to systems--they seek to *increase* functionality by any means necessary. I'm hacking on technical solutions to solve the accounting problem(per-user root accounting becomes harder when everyone's going straight to root, but ssh has a number of appropriate systems to handle this), but I want to get some kind of consensus first that engineering out the need for su is worthwhile. Thoughts? Yours Truly, Dan Kaminsky, CISSP www.doxpara.com From tim at multitalents.net Tue Feb 27 14:21:12 2001 From: tim at multitalents.net (Tim Rice) Date: Mon, 26 Feb 2001 19:21:12 -0800 (PST) Subject: small cleanup patch Message-ID: configure.in: Open Server 5 doesn't need AC_DEFINE(BROKEN_SAVED_UIDS) pathnames.h: add #ifndef _PATH_LS to fix "src/pathnames.h", line 123: warning: macro redefined: _PATH_LS -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- openssh_cvs/configure.in.old Mon Feb 26 18:47:57 2001 +++ openssh_cvs/configure.in Mon Feb 26 18:50:28 2001 @@ -257,7 +257,6 @@ AC_DEFINE(HAVE_SCO_PROTECTED_PW) AC_DEFINE(DISABLE_SHADOW) AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) - AC_DEFINE(BROKEN_SAVED_UIDS) AC_CHECK_FUNCS(getluid setluid) ;; *-dec-osf*) --- openssh_cvs/pathnames.h.old Sat Feb 10 19:39:35 2001 +++ openssh_cvs/pathnames.h Mon Feb 26 19:08:19 2001 @@ -120,7 +120,9 @@ #ifndef _PATH_SFTP_SERVER #define _PATH_SFTP_SERVER "/usr/libexec/sftp-server" #endif +#ifndef _PATH_LS #define _PATH_LS "ls" +#endif /* path to login program */ #ifndef LOGIN_PROGRAM From djm at mindrot.org Tue Feb 27 14:43:14 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 27 Feb 2001 14:43:14 +1100 (EST) Subject: small cleanup patch In-Reply-To: Message-ID: On Mon, 26 Feb 2001, Tim Rice wrote: > > configure.in: Open Server 5 doesn't need AC_DEFINE(BROKEN_SAVED_UIDS) > > pathnames.h: add #ifndef _PATH_LS to fix > "src/pathnames.h", line 123: warning: macro redefined: _PATH_LS Thanks - applied. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Tue Feb 27 14:44:30 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 27 Feb 2001 14:44:30 +1100 (EST) Subject: tech question "sftp to ftponly accounts" In-Reply-To: <3A9AF98F.43101CF4@es.usyd.edu.au> Message-ID: On Tue, 27 Feb 2001, Ivan Teliatnikov wrote: > Sorry guys, > > I am not meant to write to this list disturbing developers with a silly > end user question, but this a matter of huge importance for me. > > I am running ssh-server on RedHat 6.1. Before we introduced ssh we had a > couple of ftponly accounts for people downloading data from our > university database. It appears that they cannot access ftponly account > from any windows sftp clients. However it works fine for all normal > users. May be you can give a hint on this matter. sftp is a completely different protocol to regular FTP. OpenSSH does not have all the pieces in place to support chroot ftp only accounts yet (unless you want to do it youself using a custom shell). -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Tue Feb 27 18:55:13 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 27 Feb 2001 18:55:13 +1100 (EST) Subject: Bad packet length in 2.5.1 with rijndael (fwd) Message-ID: I think we are not detecting and setting endianness properly for rijndael.c. Can someone on a big endian machine do a "ssh -2 -oCiphers=rijndael128-cbc littleendianmachine" and vice versa? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer ---------- Forwarded message ---------- Date: Mon, 26 Feb 2001 22:54:43 -0800 (PST) From: Gregory Steuck To: openssh at openssh.com Subject: Bad packet length in 2.5.1 with rijndael Hello, If I go between machines with different byte order using rijndael ciphers I get "Bad packet length" error. I was using openssh-openbsd-current-i386 -> openssh-2.5.1p1-sparc-solaris and vice versa. It works fine if I use 3des-cbc, blowfish-cbc, arcfour or cast128-cbc. (To make sure this is not the 2.8 rijndael blow up, I just rebulit libssl from -current, didn't change a thing) Here're the relevant parts of .ssh/config: Host puma HostName ::1 Port 10022 ForwardX11 yes Host * Protocol 2,1 Cipher blowfish Ciphers rijndael128-cbc,aes128-cbc,blowfish-cbc,3des-cbc ForwardX11 no ForwardAgent no And this is the log: ssh -v puma OpenSSH_2.5.1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f debug: Reading configuration data /home/greg/.ssh/config debug: Applying options for puma debug: Applying options for * debug: Reading configuration data /etc/ssh_config debug: ssh_connect: getuid 1001 geteuid 0 anon 0 debug: Connecting to ::1 [::1] port 10022. debug: Allocated local port 809. debug: Connection established. debug: identity file /home/greg/.ssh/identity type 0 debug: identity file /home/greg/.ssh/id_rsa type 3 debug: identity file /home/greg/.ssh/id_dsa type 3 debug: Remote protocol version 1.99, remote software version OpenSSH_2.5.1p1 debug: match: OpenSSH_2.5.1p1 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug: Local version string SSH-2.0-OpenSSH_2.5.1 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,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 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 rijndael128-cbc hmac-sha1 none debug: kex: client->server rijndael128-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: 1012/2049 debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. debug: Got SSH2_MSG_KEXDH_REPLY. debug: Forcing accepting of host key for loopback/localhost. debug: bits set: 1025/2049 debug: len 55 datafellows 0 debug: ssh_dss_verify: signature correct debug: Wait SSH2_MSG_NEWKEYS. debug: GOT SSH2_MSG_NEWKEYS. debug: send SSH2_MSG_NEWKEYS. debug: done: send SSH2_MSG_NEWKEYS. debug: done: KEX2. debug: send SSH2_MSG_SERVICE_REQUEST e3 03 f4 e0 5e 27 3c ff 53 f4 60 3e 5a 72 b5 67 Disconnecting: Bad packet length -486279968. debug: Calling cleanup 0x15f10(0x0) Thanks Greg From mouring at etoh.eviladmin.org Tue Feb 27 19:49:46 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 27 Feb 2001 02:49:46 -0600 (CST) Subject: tech question "sftp to ftponly accounts" In-Reply-To: Message-ID: On Tue, 27 Feb 2001, Damien Miller wrote: > On Tue, 27 Feb 2001, Ivan Teliatnikov wrote: > > > Sorry guys, > > > > I am not meant to write to this list disturbing developers with a silly > > end user question, but this a matter of huge importance for me. > > > > I am running ssh-server on RedHat 6.1. Before we introduced ssh we had a > > couple of ftponly accounts for people downloading data from our > > university database. It appears that they cannot access ftponly account > > from any windows sftp clients. However it works fine for all normal > > users. May be you can give a hint on this matter. > > sftp is a completely different protocol to regular FTP. OpenSSH does not > have all the pieces in place to support chroot ftp only accounts yet > (unless you want to do it youself using a custom shell). > If you don't care about chroot()ing the user into their home directory then you can set their shell to ${PREFIX}/libexec/sftp-server. This will cause them to run the sftp server no matter how they attempt to ssh into the box. Granted it causes 'scp' to hang, but it works. - Ben From mouring at etoh.eviladmin.org Tue Feb 27 20:23:21 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 27 Feb 2001 03:23:21 -0600 (CST) Subject: SU vs. ssh root@host In-Reply-To: <01b001c0a067$f7096e80$006545ab@na.cisco.com> Message-ID: On Mon, 26 Feb 2001, Dan Kaminsky wrote: > > Personally, I don't think the use of 'sshd' as a form of local > > authentication is really any more secure then a well written 'su' on a > > good solid audited OS. Once a cracker with half a brain has compermised > > your system (via su, sshd, etc) you'll never see the log files unless you > > are doing remote logging. > > This is when Dan slaps his forehead and says, "Oops." > > I'm *not* talking about: > > user at host1$ ssh root at 127.0.0.1 > root at host1# > > I'm talking about: > > user at host1$ ssh root at host2 > root at host2# > > Being *far* superior to: > > user at host1$ ssh user at host2 > user at host2$ su root > root at host2# > So.. How do I know that 'user' was the one that stepped up to 'root'? Are you asking me to trust the ssh client to give me a valid username? Are you asking me to trust the results of some 'identd' process on a remote server? Na.. The latter is much more secure then the former. I have a clear view as to who became root and there is no remote trust level. > Because there's no reason to actually believe user at host2 will actually > execute /bin/su, not log characters, or whatnot. There's no way to know if > .profile actually contained an app called hacksh, which was entirely adept > at hiding its own existence through userspace(after all, all you know about > a remote host is what it sends you--there's nothing to prevent a passthrough > like hacksh starting up in .profile, hiding its existence from within > itself, and preventing attempts to blindly clear it.) > If you have 'TRUSTED' users doing such things then you should reconsider who you allow to use 'su'. 'su' should never be accessible by any old joe. Again, if you have untrusted user on a machine. Then remove the world read/executable and require the person to be part of the 'wheel' group or 'admin' group to run su. > I argue, when connecting to a remote host, one should authenticate > *directly* against the account one wishes to connect to. That way, only the > trusted *root* process is receiving authentication material, as opposed to > any random software that the user might have configured to load on startup. > If the user can load some 'random' software that will cause authentication to misdetect users, etc. Then no matter what software you run there will be a flaw. You just remove a single method to expliot that flaw. End of Story. > >From a purely theoretical point of view, it's better to *lose* permissions > than *gain* them, because exploits don't generally *reduce* access to > systems--they seek to *increase* functionality by any means necessary. > > I'm hacking on technical solutions to solve the accounting problem(per-user > root accounting becomes harder when everyone's going straight to root, but > ssh has a number of appropriate systems to handle this), but I want to get > some kind of consensus first that engineering out the need for su is > worthwhile. > I don't feel your solution is any better. As stated before. 1) On a fully secure system 'root' should *NEVER* be allowed to be logged in remotely. This includes localhost because it's possible to spoof such things (Granted this is my view, but it's a view that has been drilled into me since I first started in the UNIX community in 92). 2) 'OpenSSH' portable code is roughtly 48,000 lines of code. 'su' is not even close to that size. Since they *BOTH* depend on the underlying unautheration system. Which one would you consider easier to secure? I'll give you a hint. It ain't OpenSSH (Markus, no offense =). 3) Whatever solution you come up with to log the 'real user' that logged directly into root will be a pure hack. Using ssh/sshd as a form of 'su replacement' is not valid. Never will be. If you have clear code that shows faults in PAM or any other authenication/logging system then your better off going to the vendors and pushing for changes. Any other solution is a hack.. Pure and simple. This also has no useful bearing on OpenSSH project. So this thread is at at an end so useful work can be done. =) - Ben From v.j.orlikowski at gte.net Tue Feb 27 05:09:48 2001 From: v.j.orlikowski at gte.net (Victor J. Orlikowski) Date: Mon, 26 Feb 2001 13:09:48 -0500 Subject: 2.5.1p1 on Redhat Linux 6.2 using PAM does not log closing of session Message-ID: <15002.39916.326727.755820@critterling.garfield.home> Hello all, On Redhat 6.2, the PAM_unix module logs the session opening, but not the session closing. This was logged as of 2.3.0p1. Upgrading to 2.5.1p1 makrs the start of the problem. Thanks in advance, Victor -- Victor J. Orlikowski ====================== v.j.orlikowski at gte.net orlikowski at apache.org vjo at us.ibm.com From alexr at xs4all.nl Mon Feb 26 23:40:50 2001 From: alexr at xs4all.nl (Alexander Rijnbeek) Date: Mon, 26 Feb 2001 13:40:50 +0100 Subject: Make error Message-ID: <3A9A5CE2.1662.140804FA@localhost> Hello, I have running FreeBSD 4.0 and problems with compiling OpenSSH 2.5.1p1 OpenSSL 0.9.6 -> installed zLib 1.1.3 -> installed su-2.03# make gcc -o sshd sshd.o auth.o auth1.o auth2.o auth-chall.o auth2- chall.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth2- pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o auth-sia.o dh.o sshpty.o log-server.o sshlogin.o loginrec.o servconf.o serverloop.o md5crypt.o session.o groupaccess.o -L. -Lopenbsd-compat/ - L/usr/local/ssl/lib -lssh -lopenbsd-compat -lz -lutil -lcrypto auth-passwd.o: In function `auth_password': /usr/tmp/openssh-2.5.1p1/auth-passwd.c(.text+0x5e): undefined reference to `crypt' *** Error code 1 Stop in /usr/tmp/openssh-2.5.1p1. Can you help me ?? output summary off ./configure OpenSSH configured has been configured with the following options. User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /usr/local/etc Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/man/manX PID file: /var/run Random number collection: Device (/dev/urandom) Manpage format: man PAM support: no KerberosIV support: no AFS support: no S/KEY support: no TCP Wrappers support: no MD5 password support: no IP address in $DISPLAY hack: no Use IPv4 by default hack: no Translate v4 in v6 hack: no Host: i386-unknown-freebsd4.0 Compiler: gcc Compiler flags: -g -O2 -Wall Preprocessor flags: -I/usr/local/ssl/include Linker flags: -L/usr/local/ssl/lib Libraries: -lz -lutil -lcrypto From markus.friedl at informatik.uni-erlangen.de Tue Feb 27 20:23:01 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Tue, 27 Feb 2001 10:23:01 +0100 Subject: Fwd: OpenSSH on Ultrix? In-Reply-To: <3A996048.A3D797E2@serendipity.palo-alto.ca.us>; from robbie@serendipity.palo-alto.ca.us on Sun, Feb 25, 2001 at 11:43:04AM -0800 References: <1epcyuy.1wvn2qd1w27eg2M@georg.schwarz.online.de> <3A996048.A3D797E2@serendipity.palo-alto.ca.us> Message-ID: <20010227102301.B19791@folly> On Sun, Feb 25, 2001 at 11:43:04AM -0800, Robbie Stone wrote: > Insufficient entropy errors occur under Ultrix because of no > /dev/random. OpenSSH takes care of this by complaining and failing to > connect. The commercial SSH stuff uses system commands to make up for > the lack of /dev/random, so it runs ps ,netstat, vmstat, etc. I haven't > found support for this in OpenSSH yet but it is terribly necessary for openssh does this, too. > OSs without /dev/random. From dankamin at cisco.com Tue Feb 27 21:40:02 2001 From: dankamin at cisco.com (Dan Kaminsky) Date: Tue, 27 Feb 2001 02:40:02 -0800 Subject: SU vs. ssh root@host References: Message-ID: <009301c0a0a9$a4941820$0200040a@na.cisco.com> Ben: [Believe it or not, I think we're going to end up coming to a consensus here.] Remote root management is a reality. We install OpenSSH *because* we need a secure way to manage services with significant import; while I respect and understand the superiority of console root management, the simple fact that servers are often colo'ed thousands of miles away in a locked facility means Remote Root *is* going to happen. I happen to believe OpenSSH is *the* way to make it happen, because it's end-to-end, highly portable, migrates elegantly, and is fast. But how to use OpenSSH most securely for remote root maintenance? When remote root is requested directly, the path of trust is essentially: 1. Unknown user at host1 requests root 2. Root SSHD authenticates Root Priveledges 3. Unknown(but authenticated) user at host1 receives root When remote root is requested from user shell, the path of trust is: 1. Unknown user at host1 requests user 2. Root SSHD authenticates User Priveledges 3. Unknown(but authenticated) user at host1 receives user 4. Interactive session is requested, causing all of user's rc scripts and paths to load 5. su is "apparently" executed, authenticating user as root. 6. Unknown(but authenticated) user at host1 receives root. Of these steps, it's #4 that I have a problem with, because it's #4 that's completely outside of the control of our secure environment! It's like we're making every effort to do everything secure, branch out to "whatever happens to be sitting in user-owned rc files", then swing back to our maximum security su app. That can't be right! It may win us additional accountability, but at a cost of allowing a user-owned file to execute arbitrary commands before the inevitable upgrade to root priveledges. Non-root must not be able to intercept root privileges. HOWEVER, root must not be accessible without non-root accountability, and if at all possible, it's *heavily* preferable to use the operating system's existing accounting infrastructure rather than trying to hack one together ourselves. You're absolutely right. Solution, as of 27-Feb-2001: ssh user at host2 -t "su -l root" What this effectively does is eliminate step four, where arbitrary apps are executed from the .profile/.cshrc files. In fact, not a single variable from the user carries over to the su execution environment--everything is defined by our root-owned SSHD process. We essentially restrict our trust *from* anything the user might have wanted to execute *to* just su, which being a setuid app can't be process traced or otherwise modified(though it could be aborted). Now, this isn't perfect. Among other things, ssh user at host2 -t "su -l" is a painfully long phrase and is thus likely to be forgotten or mistyped. I'm partial to adding an option such as: ssh -r user:root host or ssh user:root at host to signify that SSH should minimally authenticate against the user, then immediate fall back to the system for su -l root authentication. It's effectively the "present day solution" hardcoded. (-r stands for re-authenticate, and is a decent opposite to -l considering -R/-L). There is a secondary problem, and that's that this requires us to remember passwords! I'd very much like *nobody* to have the root password, and for SSH to log *which* user from the authorized_keys file logged into root. Is there any objection to this? I fully grant that we lose PAM interaction, but considering SSH's apparent desire to be free of library interactions and the value of eliminating shared root password awareness...might this not be the best way of all to handle situations where multiple people require root access? Put simply: Does the value of eliminating password systems exceed the cost of losing the PAM interface? There's a bit more, but I'll save that for later. Thoughts? Yours Truly, Dan Kaminsky, CISSP www.doxpara.com From markus.friedl at informatik.uni-erlangen.de Tue Feb 27 22:35:16 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Tue, 27 Feb 2001 12:35:16 +0100 Subject: Bad packet length in 2.5.1 with rijndael In-Reply-To: <15003.33136.244811.97967@home.nest.cx>; from greg@nest.cx on Tue, Feb 27, 2001 at 02:29:04AM -0800 References: <15003.20275.414600.237572@home.nest.cx> <20010227111757.A397@faui02.informatik.uni-erlangen.de> <15003.33136.244811.97967@home.nest.cx> Message-ID: <20010227123516.A11731@folly> it seems that this check does not work on solaris #if BYTE_ORDER != LITTLE_ENDIAN #define BYTE_SWAP #endif could you please check that BYTE_SWAP is defined in rijndael.c -m From mdb at juniper.net Tue Feb 27 23:07:13 2001 From: mdb at juniper.net (Mark D. Baushke) Date: Tue, 27 Feb 2001 04:07:13 -0800 Subject: Bad packet length in 2.5.1 with rijndael In-Reply-To: Mail from Markus Friedl dated Tue, 27 Feb 2001 12:35:16 +0100 <20010227123516.A11731@folly> Message-ID: <200102271207.EAA02721@garnet.juniper.net> > Date: Tue, 27 Feb 2001 12:35:16 +0100 > From: Markus Friedl > > it seems that this check does not work on solaris > > #if BYTE_ORDER != LITTLE_ENDIAN > #define BYTE_SWAP > #endif > > could you please check that BYTE_SWAP is defined > in rijndael.c > > -m BYTE_SWAP is NOT defined on my Solaris 2.6 sparc system. It might be useful to check if BYTE_ORDER and LITTLE_ENDIAN are defined before seeing if they are not the same... On Solaris, __BYTE_ORDER__ and __LITTLE_ENDIAN__ and __BIG_ENDIAN__ are defined in /usr/local/gcc-2.7.2.3/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2.3/include/sys/byteorder.h Something like this patch seems to work for me. It might be better to do something in config.h and test it with configure... --- rijndael.c- Mon Feb 5 10:16:28 2001 +++ rijndael.c Tue Feb 27 03:55:49 2001 @@ -58,6 +58,21 @@ #define byte(x,n) ((u1byte)((x) >> (8 * n))) +#ifndef BYTE_ORDER +#ifdef __BYTE_ORDER__ +#define BYTE_ORDER __BYTE_ORDER__ +#else +#error BYTE_ORDER is not defined +#endif +#endif +#ifndef LITTLE_ENDIAN +#ifdef __LITTLE_ENDIAN__ +#define LITTLE_ENDIAN __LITTLE_ENDIAN__ +#else +#error LITTLE_ENDIAN is not defined +#endif +#endif + #if BYTE_ORDER != LITTLE_ENDIAN #define BYTE_SWAP #endif Note that the /usr/include/sys/byteorder.h file does not define either BYTE_ORDER or LITTLE_ENDIAN or __BYTE_ORDER__ or __LITTLE_ENDIAN__ but instead references _BIG_ENDIAN and other .h files reference _LITTLE_ENDIAN even though I do not see a #define for any of them. Enjoy! -- Mark From markus.friedl at informatik.uni-erlangen.de Wed Feb 28 00:14:11 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Tue, 27 Feb 2001 14:14:11 +0100 Subject: intermittent stderr In-Reply-To: <200102251843.KAA29114@ohm.apl.washington.edu>; from dunlap@apl.washington.edu on Sun, Feb 25, 2001 at 10:43:03AM -0800 References: <20010225172859.A5291@folly> <200102251843.KAA29114@ohm.apl.washington.edu> Message-ID: <20010227141411.A22396@folly> On Sun, Feb 25, 2001 at 10:43:03AM -0800, John Dunlap wrote: > The patches below seem to cure the total lack of response, ok, please try this (against clean 2.5.1). the select errors should disappear. however, remote stderr output could still be truncated. Index: nchan.c =================================================================== RCS file: /home/markus/cvs/ssh/nchan.c,v retrieving revision 1.22 diff -u -r1.22 nchan.c --- nchan.c 2001/01/21 19:05:52 1.22 +++ nchan.c 2001/02/27 13:08:31 @@ -54,9 +54,6 @@ static void chan_send_close2(Channel *c); static void chan_send_eof2(Channel *c); -/* channel cleanup */ -chan_event_fn *chan_delete_if_full_closed = NULL; - /* helper */ static void chan_shutdown_write(Channel *c); static void chan_shutdown_read(Channel *c); @@ -249,16 +246,6 @@ break; } } -static void -chan_delete_if_full_closed1(Channel *c) -{ - debug3("channel %d: chan_delete_if_full_closed1: istate %d ostate %d", - c->self, c->istate, c->ostate); - if (c->istate == CHAN_INPUT_CLOSED && c->ostate == CHAN_OUTPUT_CLOSED) { - debug("channel %d: full closed", c->self); - channel_free(c->self); - } -} /* * the same for SSH2 @@ -401,24 +388,49 @@ c->flags |= CHAN_CLOSE_SENT; } } -static void -chan_delete_if_full_closed2(Channel *c) + +/* shared */ + +int +chan_is_dead(Channel *c) { - debug3("channel %d: chan_delete_if_full_closed2: istate %d ostate %d", + debug3("channel %d: chan_is_dead: istate %d ostate %d", c->self, c->istate, c->ostate); - if (c->istate == CHAN_INPUT_CLOSED && c->ostate == CHAN_OUTPUT_CLOSED) { + + if (c->istate != CHAN_INPUT_CLOSED || c->ostate != CHAN_OUTPUT_CLOSED) + return 0; + if (!compat20) { + debug("channel %d: is dead", c->self); + return 1; + } + /* + * we have to delay the close message if the efd (for stderr) is + * still active + */ + if (((c->extended_usage != CHAN_EXTENDED_IGNORE) && + buffer_len(&c->extended) > 0) +#if 0 + || ((c->extended_usage == CHAN_EXTENDED_READ) && + c->efd != -1) +#endif + ) { + debug2("channel %d: active efd: %d len %d type %s", + c->self, c->efd, buffer_len(&c->extended), + c->extended_usage==CHAN_EXTENDED_READ ? + "read": "write"); + } else { if (!(c->flags & CHAN_CLOSE_SENT)) { chan_send_close2(c); } if ((c->flags & CHAN_CLOSE_SENT) && (c->flags & CHAN_CLOSE_RCVD)) { - debug("channel %d: full closed2", c->self); - channel_free(c->self); + debug("channel %d: is dead", c->self); + return 1; } } + return 0; } -/* shared */ void chan_init_iostates(Channel *c) { @@ -439,8 +451,6 @@ chan_rcvd_ieof = chan_rcvd_ieof2; chan_write_failed = chan_write_failed2; chan_obuf_empty = chan_obuf_empty2; - - chan_delete_if_full_closed = chan_delete_if_full_closed2; } else { chan_rcvd_oclose = chan_rcvd_oclose1; chan_read_failed = chan_read_failed_12; @@ -449,8 +459,6 @@ chan_rcvd_ieof = chan_rcvd_ieof1; chan_write_failed = chan_write_failed1; chan_obuf_empty = chan_obuf_empty1; - - chan_delete_if_full_closed = chan_delete_if_full_closed1; } } Index: nchan.h =================================================================== RCS file: /home/markus/cvs/ssh/nchan.h,v retrieving revision 1.9 diff -u -r1.9 nchan.h --- nchan.h 2000/09/07 20:27:52 1.9 +++ nchan.h 2001/02/27 12:34:41 @@ -84,7 +84,7 @@ extern chan_event_fn *chan_write_failed; extern chan_event_fn *chan_obuf_empty; -extern chan_event_fn *chan_delete_if_full_closed; +int chan_is_dead(Channel * c); void chan_init_iostates(Channel * c); void chan_init(void); Index: channels.c =================================================================== RCS file: /home/markus/cvs/ssh/channels.c,v retrieving revision 1.92 diff -u -r1.92 channels.c --- channels.c 2001/02/16 13:38:18 1.92 +++ channels.c 2001/02/27 12:51:57 @@ -297,6 +297,7 @@ channel_close_fds(Channel *c) { if (c->sock != -1) { + shutdown(c->sock, SHUT_RDWR); close(c->sock); c->sock = -1; } @@ -331,8 +332,6 @@ debug("channel_free: channel %d: dettaching channel user", id); c->dettach_user(c->self, NULL); } - if (c->sock != -1) - shutdown(c->sock, SHUT_RDWR); channel_close_fds(c); buffer_free(&c->input); buffer_free(&c->output); @@ -824,7 +823,14 @@ buffer_len(&c->extended)); debug2("channel %d: written %d to efd %d", c->self, len, c->efd); - if (len > 0) { + if (len < 0 && (errno == EINTR || errno == EAGAIN)) + return 1; + if (len <= 0) { + debug2("channel %d: closing write-efd %d", + c->self, c->efd); + close(c->efd); + c->efd = -1; + } else { buffer_consume(&c->extended, len); c->local_consumed += len; } @@ -833,19 +839,22 @@ len = read(c->efd, buf, sizeof(buf)); debug2("channel %d: read %d from efd %d", c->self, len, c->efd); - if (len == 0) { - debug("channel %d: closing efd %d", + if (len < 0 && (errno == EINTR || errno == EAGAIN)) + return 1; + if (len <= 0) { + debug2("channel %d: closing read-efd %d", c->self, c->efd); close(c->efd); c->efd = -1; - } else if (len > 0) + } else { buffer_append(&c->extended, buf, len); + } } } return 1; } int -channel_check_window(Channel *c, fd_set * readset, fd_set * writeset) +channel_check_window(Channel *c) { if (!(c->flags & (CHAN_CLOSE_SENT|CHAN_CLOSE_RCVD)) && c->local_window < c->local_window_max/2 && @@ -876,7 +885,8 @@ channel_handle_rfd(c, readset, writeset); channel_handle_wfd(c, readset, writeset); channel_handle_efd(c, readset, writeset); - channel_check_window(c, readset, writeset); + + channel_check_window(c); } void @@ -984,7 +994,24 @@ if (ftab[c->type] == NULL) continue; (*ftab[c->type])(c, readset, writeset); - chan_delete_if_full_closed(c); + if (chan_is_dead(c)) { + /* + * we have to remove the fd's from the select mask + * before the channels are free'd and the fd's are + * closed + */ + if (c->wfd != -1) + FD_CLR(c->wfd, writeset); + if (c->rfd != -1) + FD_CLR(c->rfd, readset); + if (c->efd != -1) { + if (c->extended_usage == CHAN_EXTENDED_READ) + FD_CLR(c->efd, readset); + if (c->extended_usage == CHAN_EXTENDED_WRITE) + FD_CLR(c->efd, writeset); + } + channel_free(c->self); + } } } @@ -1037,19 +1064,18 @@ } else { if (c->type != SSH_CHANNEL_OPEN) continue; - if (c->istate != CHAN_INPUT_OPEN && - c->istate != CHAN_INPUT_WAIT_DRAIN) - continue; } if (compat20 && (c->flags & (CHAN_CLOSE_SENT|CHAN_CLOSE_RCVD))) { + /* XXX is this true? */ debug("channel: %d: no data after CLOSE", c->self); continue; } /* Get the amount of buffered data for this channel. */ - len = buffer_len(&c->input); - if (len > 0) { + if ((c->istate == CHAN_INPUT_OPEN || + c->istate == CHAN_INPUT_WAIT_DRAIN) && + (len = buffer_len(&c->input)) > 0) { /* Send some data for the other side over the secure connection. */ if (compat20) { if (len > c->remote_window) @@ -1089,6 +1115,9 @@ c->remote_window > 0 && (len = buffer_len(&c->extended)) > 0 && c->extended_usage == CHAN_EXTENDED_READ) { + debug2("channel %d: rwin %d elen %d euse %d", + c->self, c->remote_window, buffer_len(&c->extended), + c->extended_usage); if (len > c->remote_window) len = c->remote_window; if (len > c->remote_maxpacket) @@ -1100,6 +1129,7 @@ packet_send(); buffer_consume(&c->extended, len); c->remote_window -= len; + debug2("channel %d: sent ext data %d", c->self, len); } } } From eck3537 at redwood.rt.cs.boeing.com Wed Feb 28 01:56:21 2001 From: eck3537 at redwood.rt.cs.boeing.com (Chuck Klein) Date: Tue, 27 Feb 2001 06:56:21 -0800 Subject: Bug Report: Not using sysconfdir for version 2 host key Message-ID: <3A9BC015.AE2A0113@redwood.rt.cs.boeing.com> For what it's worth--only minimal time spent trying new version. Bug: OpenSSH-2.5p1 does not find version 2 host key in directory specified by sysconfdir in configure. Env: Redhat Linux 6.2- kernel 2.2.18- Alpha ev5 processor- Compaq XP1000- egcs-2.91.66 sysconfdir=/etc/openssh Testing is on single host using ssh2.5p1 to connect to sshd2.5p1. Symptom: [root at penguin sbin]# sshd -d debug1: sshd version OpenSSH_2.5.1p1 debug1: load_private_key_autodetect: type 0 RSA1 /etc/ssh_host_dsa_key: No such file or directory error: Could not load host key: /etc/ssh_host_dsa_key: No such file or directory Disabling protocol version 2. Could not load host key After moving a copy of /etc/openssh/ssh_host_dsa_key to /etc [root at penguin sbin]# sshd -d debug1: sshd version OpenSSH_2.5.1p1 debug1: load_private_key_autodetect: type 0 RSA1 debug1: read SSH2 private key done: name dsa w/o comment success 1 debug1: load_private_key_autodetect: type 2 DSA debug1: Seeding random number generator I don't follow this list, please use email for any additional info. Thanks to all for a great product, Chuck Klein -- Edward (Chuck) Klein, Jr. | email: edward.c.klein at boeing.com Boeing Phantom Works | voice: (425) 865-5629 P.O. Box 3707, M/S 7L-40 | fax: (425) 865-2965 Seattle, WA 98124-2207 From a.d.stribblehill at durham.ac.uk Wed Feb 28 02:32:59 2001 From: a.d.stribblehill at durham.ac.uk (Andrew Stribblehill) Date: Tue, 27 Feb 2001 15:32:59 +0000 Subject: [Script] ssh-add dropping keys when xscreensaver blanks Message-ID: <20010227153258.A16765@womble.dur.ac.uk> The people at Debian were chuntering that it'd be a good idea for xscreensaver to ask ssh-add to drop its keys when it blanked the screen. Would the attached script (which does just that) be worth adding to the contrib directory? It would also be useful to give ssh-agent a facility to drop its keys after some time of inactivity. How easy would this be to implement? Thanks, Andrew Stribblehill Systems programmer, IT Service, University of Durham, England From robbie at serendipity.palo-alto.ca.us Wed Feb 28 03:18:51 2001 From: robbie at serendipity.palo-alto.ca.us (Robbie Stone) Date: Tue, 27 Feb 2001 08:18:51 -0800 Subject: Fwd: OpenSSH on Ultrix? References: <1epcyuy.1wvn2qd1w27eg2M@georg.schwarz.online.de> <3A996048.A3D797E2@serendipity.palo-alto.ca.us> <20010227102301.B19791@folly> Message-ID: <3A9BD36B.E57CC51D@serendipity.palo-alto.ca.us> Markus Friedl wrote: > > On Sun, Feb 25, 2001 at 11:43:04AM -0800, Robbie Stone wrote: > > Insufficient entropy errors occur under Ultrix because of no > > /dev/random. OpenSSH takes care of this by complaining and failing to > > connect. The commercial SSH stuff uses system commands to make up for > > the lack of /dev/random, so it runs ps ,netstat, vmstat, etc. I haven't > > found support for this in OpenSSH yet but it is terribly necessary for > > openssh does this, too. > If OpenSSH does this then how does it determine which commands are appropriate? The *other* SSH that I installed had arguments that it was passing to netstat that didn't come until 4-5 years later ;-) Robbie -- Robbie Stone Serendipity Simplex From johnh at aproposretail.com Wed Feb 28 03:38:02 2001 From: johnh at aproposretail.com (John Hardin) Date: Tue, 27 Feb 2001 08:38:02 -0800 Subject: SU vs. ssh root@host Message-ID: <3A9BD7EA.9DC0721@aproposretail.com> mouring at etoh.eviladmin.org wrote: > > 1) On a fully secure system 'root' should *NEVER* be allowed to be logged > in remotely. This includes localhost because it's possible to spoof such > things (Granted this is my view, but it's a view that has been drilled > into me since I first started in the UNIX community in 92). And me since 1988. > This also has no useful bearing on OpenSSH project. So this thread is at > at an end so useful work can be done. =) I disagree. I'm finding it very useful as an administrator (granted it's noise to developers). The discussion here has caused me to review my reasoning behind modifying the default sshd_config to disable root logins as I build our internal RPMs. This is not a bad thing to do every so often. Both sides have made good points, but a consensus has not been reached yet. Can we reach a consensus and update the default configuration files (if necessary) to reflect it? -- John Hardin Internal Systems Administrator Apropos Retail Management Systems, Inc. - (425) 672-1304 From vetter at physik.uni-wuerzburg.de Wed Feb 28 03:41:55 2001 From: vetter at physik.uni-wuerzburg.de (Andreas Vetter) Date: Tue, 27 Feb 2001 17:41:55 +0100 (MET) Subject: AllowHosts / DenyHosts Message-ID: I'd like to see a feature of the commercial ssh in openssh: AllowHosts xxx.yyy.xxx.yyy *.domain.net DenyHosts xxx.yyy.xxx.* name.domain.net This allows or denies connects from certain machines (including wildcard matching). Is there any chance for this feature to be included? No, we don't want to use tcp-wrapper for this. Bye. +-------------------------------------------------------------------------+ Andreas Vetter Universitaet Wuerzburg Telefon: [++49] (931) 888-5723 Institut fuer Theoretische Physik Telefax: [++49] (931) 888-5141 Theoretische Physik I Am Hubland E-mail: vetter at physik.uni-wuerzburg.de D-97074 Wuerzburg +-------------------------------------------------------------------------+ From greg at nest.cx Wed Feb 28 03:44:36 2001 From: greg at nest.cx (Gregory Steuck) Date: Tue, 27 Feb 2001 08:44:36 -0800 (PST) Subject: Bad packet length in 2.5.1 with rijndael In-Reply-To: <20010227123516.A11731@folly> References: <15003.20275.414600.237572@home.nest.cx> <20010227111757.A397@faui02.informatik.uni-erlangen.de> <15003.33136.244811.97967@home.nest.cx> <20010227123516.A11731@folly> Message-ID: <15003.55668.609974.799702@home.nest.cx> It isn't defined. I put this error line in: #ifdef BYTE_SWAP #define io_swap(x) bswap(x) #else #error BYTE_SWAP was not defined #define io_swap(x) (x) #endif [greg at puma openssh-2.5.1p1]$ make rijndael.o gcc -g -O2 -Wall -I/usr/local/include -I. -I./openbsd-compat -I. -DETCDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -DHAVE_CONFIG_H -c rijndael.c rijndael.c:68: #error BYTE_SWAP was not defined make: *** [rijndael.o] Error 1 >>>>> "Markus" == Markus Friedl writes: Markus> it seems that this check does not work on solaris Markus> #if BYTE_ORDER != LITTLE_ENDIAN #define BYTE_SWAP #endif Markus> could you please check that BYTE_SWAP is defined in Markus> rijndael.c From pekkas at netcore.fi Wed Feb 28 03:56:10 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 27 Feb 2001 18:56:10 +0200 (EET) Subject: AllowHosts / DenyHosts In-Reply-To: Message-ID: On Tue, 27 Feb 2001, Andreas Vetter wrote: > I'd like to see a feature of the commercial ssh in openssh: > AllowHosts xxx.yyy.xxx.yyy *.domain.net > DenyHosts xxx.yyy.xxx.* name.domain.net > > This allows or denies connects from certain machines (including wildcard > matching). > > Is there any chance for this feature to be included? No, we don't want to > use tcp-wrapper for this. I begged this for a long time half a year ago or so, but never got any replies. So I gave up. Now I'm happily using tcp wrappers. I've made a patch for tcp_wrappers to enable wildcard matching (from ssh 1.2.12), and to enable file includes (from freebsd). So I can't see why tcp_wrappers should be worse than HostsAllow and friends in this aspect. So with this you could just do: --- sshd: /etc/ssh/ssh_hosts_allow : all sshd: ALL : deny --- and in /etc/ssh/ssh_hosts_allow, like: --- xxx.yyy.x??.* name*.domain.net --- Patches available at request. Both are in recent Red Hat Linux betas, btw. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From greg at nest.cx Wed Feb 28 04:04:02 2001 From: greg at nest.cx (Gregory Steuck) Date: Tue, 27 Feb 2001 09:04:02 -0800 (PST) Subject: Bad packet length in 2.5.1 with rijndael In-Reply-To: <20010227123516.A11731@folly> References: <15003.20275.414600.237572@home.nest.cx> <20010227111757.A397@faui02.informatik.uni-erlangen.de> <15003.33136.244811.97967@home.nest.cx> <20010227123516.A11731@folly> Message-ID: <15003.56834.186382.417551@home.nest.cx> I was still sleepping while typing previous e-mail. Forgot to mention it was on Solaris 7. And yes, unconditionally defining BYTE_SWAP on solaris fixes the problem. >>>>> "Markus" == Markus Friedl writes: Markus> it seems that this check does not work on solaris Markus> #if BYTE_ORDER != LITTLE_ENDIAN #define BYTE_SWAP #endif Markus> could you please check that BYTE_SWAP is defined in Markus> rijndael.c From stevesk at sweden.hp.com Wed Feb 28 05:09:39 2001 From: stevesk at sweden.hp.com (Kevin Steves) Date: Tue, 27 Feb 2001 19:09:39 +0100 (MET) Subject: Bad packet length in 2.5.1 with rijndael (fwd) In-Reply-To: Message-ID: On Tue, 27 Feb 2001, Damien Miller wrote: : I think we are not detecting and setting endianness properly for : rijndael.c. : : Can someone on a big endian machine do a "ssh -2 -oCiphers=rijndael128-cbc : littleendianmachine" and vice versa? every platform doesn't have BYTE_ORDER. this is from openbsd /include/arpa/nameser.h. should we import it? #ifndef BYTE_ORDER #if (BSD >= 199103) # include #else #ifdef linux # include #else #define LITTLE_ENDIAN 1234 /* least-significant byte first (vax, pc) */ #define BIG_ENDIAN 4321 /* most-significant byte first (IBM, net) */ #define PDP_ENDIAN 3412 /* LSB first in word, MSW first in long (pdp)*/ #if defined(vax) || defined(ns32000) || defined(sun386) || defined(i386) || \ defined(MIPSEL) || defined(_MIPSEL) || defined(BIT_ZERO_ON_RIGHT) || \ defined(__alpha__) || defined(__alpha) #define BYTE_ORDER LITTLE_ENDIAN #endif #if defined(sel) || defined(pyr) || defined(mc68000) || defined(sparc) || \ defined(is68k) || defined(tahoe) || defined(ibm032) || defined(ibm370) || \ defined(MIPSEB) || defined(_MIPSEB) || defined(_IBMR2) || defined(DGUX) ||\ defined(apollo) || defined(__convex__) || defined(_CRAY) || \ defined(__hppa) || defined(__hp9000) || \ defined(__hp9000s300) || defined(__hp9000s700) || \ defined (BIT_ZERO_ON_LEFT) || defined(m68k) #define BYTE_ORDER BIG_ENDIAN #endif #endif /* linux */ #endif /* BSD */ #endif /* BYTE_ORDER */ #if !defined(BYTE_ORDER) || \ (BYTE_ORDER != BIG_ENDIAN && BYTE_ORDER != LITTLE_ENDIAN && \ BYTE_ORDER != PDP_ENDIAN) /* you must determine what the correct bit order is for * your compiler - the next line is an intentional error * which will force your compiles to bomb until you fix * the above macros. */ error "Undefined or invalid BYTE_ORDER"; #endif From stevev at darkwing.uoregon.edu Wed Feb 28 05:10:43 2001 From: stevev at darkwing.uoregon.edu (Steve VanDevender) Date: Tue, 27 Feb 2001 10:10:43 -0800 Subject: Fwd: OpenSSH on Ultrix? In-Reply-To: <3A9BD36B.E57CC51D@serendipity.palo-alto.ca.us> References: <1epcyuy.1wvn2qd1w27eg2M@georg.schwarz.online.de> <3A996048.A3D797E2@serendipity.palo-alto.ca.us> <20010227102301.B19791@folly> <3A9BD36B.E57CC51D@serendipity.palo-alto.ca.us> Message-ID: <15003.60835.273323.571044@darkwing.uoregon.edu> Robbie Stone writes: > Markus Friedl wrote: > > > > On Sun, Feb 25, 2001 at 11:43:04AM -0800, Robbie Stone wrote: > > > Insufficient entropy errors occur under Ultrix because of no > > > /dev/random. OpenSSH takes care of this by complaining and failing to > > > connect. The commercial SSH stuff uses system commands to make up for > > > the lack of /dev/random, so it runs ps ,netstat, vmstat, etc. I haven't > > > found support for this in OpenSSH yet but it is terribly necessary for > > > > openssh does this, too. > > If OpenSSH does this then how does it determine which commands are > appropriate? The *other* SSH that I installed had arguments that it was > passing to netstat that didn't come until 4-5 years later ;-) In OpenSSH the commands used for entropy gathering are configurable in the ssh_prng_cmds file. It's completely customizable. While my original installation of OpenSSH used the built-in entropy gathering via ssh_prng_cmds, I updated OpenSSH (and other cryptographic applications like gpg and stunnel) to use EGD, and later Lutz Jaenicke's PRNGD because EGD just can't cope with high-volume use. Some of our system scripts and EGD itself were failing when they drained all the entropy out of EGD and users were complaining about being unable to make ssh connections. PRNGD also uses something like 1/100 of the CPU time as EGD on my systems. From jon at rupture.net Wed Feb 28 06:39:07 2001 From: jon at rupture.net (Jon Nathan) Date: Tue, 27 Feb 2001 14:39:07 -0500 (EST) Subject: scp hardwires location to ssh? Message-ID: hello, i'm building a solaris package of openssh 2.5.1 for my employer. my configure string is this: ./configure --prefix=/usr/share/jon --with-xauth=/usr/openwin/bin/xauth --with-ipv4-default --with-tcp-wrappers --with-pid-dir=/etc --sysconfdir=/etc i use a prefix of /usr/share/jon , then build the system V package from there. most things work great, but somehow scp does not. it seems have the location of ssh hardwired into it. root at barf:~# which scp /usr/local/bin/scp root at barf:~# strings `which scp` | grep ssh /usr/share/jon/bin/ssh usage: scp [-pqrvC46] [-S ssh] [-P port] [-c cipher] [-i identity] f1 f2; or: root at barf:~# root at barf:~# scp jon at example.com:~/file . /usr/share/jon/bin/ssh: No such file or directory lost connection root at barf:~# obviously, /usr/share/jon/bin/ssh only exists on the machine i built the package on, not the machines i distribute the package to. what can be done to get around this? can the scp binary just refer to "ssh" and assume it's in the user's path? or can i do something in the build process (of ssh, not the package) to make scp think that, eventually, the real ssh will be at a certain location? thanks for any ideas, -jon -- Jon Nathan jon at rupture.net http://www.rupture.net/~jon/ From jmknoble at jmknoble.cx Wed Feb 28 07:00:17 2001 From: jmknoble at jmknoble.cx (Jim Knoble) Date: Tue, 27 Feb 2001 14:00:17 -0600 Subject: scp hardwires location to ssh? In-Reply-To: ; from jon@rupture.net on Tue, Feb 27, 2001 at 02:39:07PM -0500 References: Message-ID: <20010227140017.A2851@zax.half.pint-stowp.cx> Circa 2001-Feb-27 14:39:07 -0500 dixit Jon Nathan: : i'm building a solaris package of openssh 2.5.1 for my employer. my : configure string is this: : : ./configure --prefix=/usr/share/jon : --with-xauth=/usr/openwin/bin/xauth --with-ipv4-default : --with-tcp-wrappers --with-pid-dir=/etc --sysconfdir=/etc : : i use a prefix of /usr/share/jon , then build the system V package : from there. most things work great, but somehow scp does not. it : seems have the location of ssh hardwired into it. Don't do that. Do this instead: ./configure --prefix=/usr/local --with-... make make install DESTDIR=/usr/share/jon This installs into, e.g., /usr/share/jon/usr/local/bin/. When you make your package, use substitute "" for "/usr/share/jon". -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ From brettl at bio.umass.edu Wed Feb 28 06:51:14 2001 From: brettl at bio.umass.edu (Brett Longworth) Date: Tue, 27 Feb 2001 14:51:14 -0500 Subject: win clients and sftp Message-ID: <200102271951.OAA02209@bell.bio.umass.edu> I'm having trouble with users transferring files to a solaris box running ossh v2.3.1p1 via sftp using ssh.com's windows client. The sftp client appears not to respect the users umask, creating files with either mode 666 or 600. We're using version 2.4.0 of the windows client. Any ideas? thanks, -Brett ----------------- Brett Longworth Systems Manager Department of Biology University of Massachusetts Amherst, MA 01003 Tel: 413.545.0216 Fax: 413.545.3243 ----------------- "Pluralitas non est ponenda sine necessitate" -William of Ockham From Martin.Biermair at quickstep.at Wed Feb 28 07:00:02 2001 From: Martin.Biermair at quickstep.at (Martin.Biermair at quickstep.at) Date: Tue, 27 Feb 2001 21:00:02 +0100 Subject: RedHat 7 - key finger print 00:00:...:00 - fatal: xfree: NULL pointer given as argument Message-ID: <41256A00.006D80D1.00@quickstep.at> I had the problems above too. The problem here is the utility ssh-keygen of the RPM-package distribution. It just generates invalid DSA-keys with key finger prints of 00:00:...:00. The only solution is to compile and install the source of OpenSSH 2.5.1p1. Though if you're as lazy as I am and still want to use the RPMs (quite easier to deinstall) then just do the following: - Install the RPMs - Extract the source (tar -xf openssh.tar.gz) and compile it ("./configure" and "make"), but do NOT install. - Rather just copy openssh-2.5.1p1/ssh-keygen to /usr/bin - Delete all *key* files in /etc/ssh (so they will be regenerated at next sshd-startup) - Restart the daemon (/etc/rc.d/init.d/sshd restart) This should fix the problems mentioned in the subject. At least it did for me and my RH-servers. -Martin Biermair From pekkas at netcore.fi Wed Feb 28 07:06:44 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 27 Feb 2001 22:06:44 +0200 (EET) Subject: RedHat 7 - key finger print 00:00:...:00 - fatal: xfree: NULL pointer given as argument In-Reply-To: <41256A00.006D80D1.00@quickstep.at> Message-ID: On Tue, 27 Feb 2001 Martin.Biermair at quickstep.at wrote: > I had the problems above too. The problem here is the utility ssh-keygen of the > RPM-package distribution. It just generates invalid DSA-keys with key finger > prints of 00:00:...:00. The only solution is to compile and install the source > of OpenSSH 2.5.1p1. Though if you're as lazy as I am and still want to use the > RPMs (quite easier to deinstall) then just do the following: > > - Install the RPMs > - Extract the source (tar -xf openssh.tar.gz) and compile it ("./configure" and > "make"), but do NOT install. > - Rather just copy openssh-2.5.1p1/ssh-keygen to /usr/bin > - Delete all *key* files in /etc/ssh (so they will be regenerated at next > sshd-startup) > - Restart the daemon (/etc/rc.d/init.d/sshd restart) > > This should fix the problems mentioned in the subject. At least it did for me > and my RH-servers. Better way to do this is to get the .src.rpm file from the FTP site and say: rpm --rebuild *.src.rpm. You get working OpenSSL (other utils beside ssh-keygen) will work too. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From Jarno.Huuskonen at uku.fi Wed Feb 28 07:58:08 2001 From: Jarno.Huuskonen at uku.fi (Jarno Huuskonen) Date: Tue, 27 Feb 2001 22:58:08 +0200 Subject: win clients and sftp In-Reply-To: <200102271951.OAA02209@bell.bio.umass.edu>; from brettl@bio.umass.edu on Tue, Feb 27, 2001 at 02:51:14PM -0500 References: <200102271951.OAA02209@bell.bio.umass.edu> Message-ID: <20010227225808.A26874@messi.uku.fi> On Tue, Feb 27, Brett Longworth wrote: > I'm having trouble with users transferring files to a solaris box running > ossh v2.3.1p1 via sftp using ssh.com's windows client. The sftp client > appears not to respect the users umask, creating files with either mode > 666 or 600. We're using version 2.4.0 of the windows client. Any ideas? Check if you have an option "preserve original file time" or something similar checked on the Windows client. If you have this option checked then sftp (client) creates the files with mode 666. This happens also with ssh(r/tm).com's sftp-server. I think that the client behavior is really stupid in this case. -Jarno -- Jarno Huuskonen - System Administrator | Jarno.Huuskonen at uku.fi University of Kuopio - Computer Center | Work: +358 17 162822 PO BOX 1627, 70211 Kuopio, Finland | Mobile: +358 40 5388169 From tim at multitalents.net Wed Feb 28 08:09:44 2001 From: tim at multitalents.net (Tim Rice) Date: Tue, 27 Feb 2001 13:09:44 -0800 (PST) Subject: Bad packet length in 2.5.1 with rijndael (fwd) In-Reply-To: Message-ID: On Tue, 27 Feb 2001, Kevin Steves wrote: > On Tue, 27 Feb 2001, Damien Miller wrote: > : I think we are not detecting and setting endianness properly for > : rijndael.c. > : > : Can someone on a big endian machine do a "ssh -2 -oCiphers=rijndael128-cbc > : littleendianmachine" and vice versa? > > every platform doesn't have BYTE_ORDER. this is from openbsd > /include/arpa/nameser.h. should we import it? > [snip] Would the AC_C_BIGENDIAN macro at configure time help? > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From djm at mindrot.org Wed Feb 28 08:12:34 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 28 Feb 2001 08:12:34 +1100 (EST) Subject: Bad packet length in 2.5.1 with rijndael (fwd) In-Reply-To: Message-ID: On Tue, 27 Feb 2001, Tim Rice wrote: > Would the AC_C_BIGENDIAN macro at configure time help? That is exactly the test that I am looking for :) Can affected people try this patch (you will need to autoreconf): Index: configure.in =================================================================== RCS file: /var/cvs/openssh/configure.in,v retrieving revision 1.256 diff -u -r1.256 configure.in --- configure.in 2001/02/27 03:42:48 1.256 +++ configure.in 2001/02/27 21:11:00 @@ -5,6 +5,7 @@ AC_CONFIG_HEADER(config.h) AC_PROG_CC AC_CANONICAL_HOST +AC_C_BIGENDIAN # Checks for programs. AC_PROG_CPP Index: rijndael.c =================================================================== RCS file: /var/cvs/openssh/rijndael.c,v retrieving revision 1.8 diff -u -r1.8 rijndael.c --- rijndael.c 2001/02/05 18:16:28 1.8 +++ rijndael.c 2001/02/27 21:11:00 @@ -58,7 +58,7 @@ #define byte(x,n) ((u1byte)((x) >> (8 * n))) -#if BYTE_ORDER != LITTLE_ENDIAN +#ifdef WORDS_BIGENDIAN #define BYTE_SWAP #endif -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From ishikawa at yk.rim.or.jp Wed Feb 28 08:15:36 2001 From: ishikawa at yk.rim.or.jp (Ishikawa) Date: Wed, 28 Feb 2001 06:15:36 +0900 Subject: Bad packet length in 2.5.1 with rijndael References: <15003.20275.414600.237572@home.nest.cx> <20010227111757.A397@faui02.informatik.uni-erlangen.de> <15003.33136.244811.97967@home.nest.cx> <20010227123516.A11731@folly> <15003.56834.186382.417551@home.nest.cx> Message-ID: <3A9C18F8.E1C029E2@yk.rim.or.jp> Gregory Steuck wrote: > I was still sleepping while typing previous e-mail. Forgot to mention it > was on Solaris 7. And yes, unconditionally defining BYTE_SWAP on solaris > fixes the problem. > > >>>>> "Markus" == Markus Friedl writes: > > Markus> it seems that this check does not work on solaris > > Markus> #if BYTE_ORDER != LITTLE_ENDIAN #define BYTE_SWAP #endif > > Markus> could you please check that BYTE_SWAP is defined in > Markus> rijndael.c I am not entirely sure how the value of BYTE_SWAP ought to be defined, but given that solaris is available for big-endian sparc/ultra and for little-endian x86 CPUs, we probably need to check the endian-ness of the CPU by running a small program and use the result to set the value for BYTE_ORDER, etc.. (Now I recall I had an issue with a very old libc on linux (circa 1996) in that it defined LITTLE_ENDIAN and BIG_ENDIAN macro in ctype.h of all the header files(!) and this uncalled-for name space pollution collided with a user program, namely crack 4-1. :-) Anyway, setting the value using a small program seems to me a non-protruding solution and is a very reliable one IMHO.) From djm at mindrot.org Wed Feb 28 08:21:54 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 28 Feb 2001 08:21:54 +1100 (EST) Subject: [Script] ssh-add dropping keys when xscreensaver blanks In-Reply-To: <20010227153258.A16765@womble.dur.ac.uk> Message-ID: On Tue, 27 Feb 2001, Andrew Stribblehill wrote: > The people at Debian were chuntering that it'd be a good idea for > xscreensaver to ask ssh-add to drop its keys when it blanked the > screen. Would the attached script (which does just that) be worth > adding to the contrib directory? You committed the capital crime of not attaching the script. Stand still, a squad is on its way to you now. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Wed Feb 28 08:23:49 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 28 Feb 2001 08:23:49 +1100 (EST) Subject: Fwd: OpenSSH on Ultrix? In-Reply-To: <3A9BD36B.E57CC51D@serendipity.palo-alto.ca.us> Message-ID: On Tue, 27 Feb 2001, Robbie Stone wrote: > Markus Friedl wrote: > > > > On Sun, Feb 25, 2001 at 11:43:04AM -0800, Robbie Stone wrote: > > > Insufficient entropy errors occur under Ultrix because of no > > > /dev/random. OpenSSH takes care of this by complaining and failing to > > > connect. The commercial SSH stuff uses system commands to make up for > > > the lack of /dev/random, so it runs ps ,netstat, vmstat, etc. I haven't > > > found support for this in OpenSSH yet but it is terribly necessary for > > > > openssh does this, too. > > > > If OpenSSH does this then how does it determine which commands are > appropriate? The *other* SSH that I installed had arguments that it was > passing to netstat that didn't come until 4-5 years later ;-) Read WARNING.RNG and @sysconfdir@/ssh_prng_cmds Unlike ssh.com's implementation, you can modify the command list yourself. Also "ssh -v -v -v" will give you obscene detail about the execution of each program. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Wed Feb 28 08:27:08 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 28 Feb 2001 08:27:08 +1100 (EST) Subject: Fwd: OpenSSH on Ultrix? In-Reply-To: <15003.60835.273323.571044@darkwing.uoregon.edu> Message-ID: On Tue, 27 Feb 2001, Steve VanDevender wrote: > While my original installation of OpenSSH used the built-in entropy > gathering via ssh_prng_cmds, I updated OpenSSH (and other cryptographic > applications like gpg and stunnel) to use EGD, and later Lutz Jaenicke's > PRNGD because EGD just can't cope with high-volume use. Some of our > system scripts and EGD itself were failing when they drained all the > entropy out of EGD and users were complaining about being unable to make > ssh connections. PRNGD also uses something like 1/100 of the CPU time > as EGD on my systems. Yes - PRNGd is very nice and is superior to portable OpenSSH's own random number collection. The fact that it is a long-lived, system-wide pool makes it more secure and less resource intensive than OpenSSH's collection routines (which need to run at least once per program invocation). I strongly recommend it to everyone without a /dev/random. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Wed Feb 28 08:36:04 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 28 Feb 2001 08:36:04 +1100 (EST) Subject: 2.5.1p1 on Redhat Linux 6.2 using PAM does not log closing of session In-Reply-To: Message-ID: On Tue, 27 Feb 2001, Pekka Savola wrote: > Looking at this, this looks like to be a real issue. Rather important as > well. > > in auth-pam.c, when do_pam_session (the same problem is with > do_pam_setcred), session_opened is set to 1 (tested with debugging). > > However, when the session closes, in do_pam_cleanup_proc: > > if (__pamh && session_opened) { > pam_retval = pam_close_session(__pamh, 0); > if (pam_retval != PAM_SUCCESS) > log("Cannot close PAM session[%d]: %.200s", > pam_retval, PAM_STRERROR(__pamh, pam_retval)); > } > > this check doesn't match; session_opened is still 0 and if (__pamh) is > used instead. I see - It is getting set in the child rather than the parent. I can't see how we can work around this. Basically we do a fork() pam_session() setuid() exec() If we change back to pam_session() fork() setuid() exec() Then things like pam_limits.so set limits for the ssh server process rather than the child. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From jcrow at zama.net Mon Feb 26 08:42:10 2001 From: jcrow at zama.net (Jerry Crow) Date: Sun, 25 Feb 2001 13:42:10 -0800 Subject: SSH2 and IPV6 curiosity Message-ID: I understand that SSH2 does not currently specify the use of ipsec. Will SSH2 be doing any development with the ESP header in the IPV6 protocol? If and when an IPV6 enabled telnet release comes out what will be the security benefits of SSH2? Wouldn't X application tunneling fly if SSH2 could be written to utilize the lower levels of the protocol? Does anyone know when and how these issues may be approached? P.S. Sorry for all the questions Thanks, Jerry From gert at greenie.muc.de Wed Feb 28 09:41:33 2001 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 27 Feb 2001 23:41:33 +0100 Subject: Fwd: OpenSSH on Ultrix? In-Reply-To: ; from Damien Miller on Wed, Feb 28, 2001 at 08:27:08AM +1100 References: <15003.60835.273323.571044@darkwing.uoregon.edu> Message-ID: <20010227234133.A15038@greenie.muc.de> Hi, On Wed, Feb 28, 2001 at 08:27:08AM +1100, Damien Miller wrote: > Yes - PRNGd is very nice and is superior to portable OpenSSH's own [..] > I strongly recommend it to everyone without a /dev/random. Are there any chances to use it on a system without unix sockets (always the same problem here - SCO 3.0)? 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 mdb at juniper.net Wed Feb 28 09:44:26 2001 From: mdb at juniper.net (Mark D. Baushke) Date: Tue, 27 Feb 2001 14:44:26 -0800 Subject: Bad packet length in 2.5.1 with rijndael (fwd) In-Reply-To: Mail from Damien Miller dated Wed, 28 Feb 2001 08:12:34 +1100 Message-ID: <200102272244.OAA98635@garnet.juniper.net> The patch works for me. -- Mark Note: I needed to upgrad autoreconf from version 2.12 to 2.13). >Date: Wed, 28 Feb 2001 08:12:34 +1100 (EST) >From: Damien Miller > >On Tue, 27 Feb 2001, Tim Rice wrote: > >> Would the AC_C_BIGENDIAN macro at configure time help? > >That is exactly the test that I am looking for :) > >Can affected people try this patch (you will need to autoreconf): > >Index: configure.in >=================================================================== >RCS file: /var/cvs/openssh/configure.in,v >retrieving revision 1.256 >diff -u -r1.256 configure.in >--- configure.in 2001/02/27 03:42:48 1.256 >+++ configure.in 2001/02/27 21:11:00 >@@ -5,6 +5,7 @@ > AC_CONFIG_HEADER(config.h) > AC_PROG_CC > AC_CANONICAL_HOST >+AC_C_BIGENDIAN > > # Checks for programs. > AC_PROG_CPP >Index: rijndael.c >=================================================================== >RCS file: /var/cvs/openssh/rijndael.c,v >retrieving revision 1.8 >diff -u -r1.8 rijndael.c >--- rijndael.c 2001/02/05 18:16:28 1.8 >+++ rijndael.c 2001/02/27 21:11:00 >@@ -58,7 +58,7 @@ > > #define byte(x,n) ((u1byte)((x) >> (8 * n))) > >-#if BYTE_ORDER != LITTLE_ENDIAN >+#ifdef WORDS_BIGENDIAN > #define BYTE_SWAP > #endif From djm at mindrot.org Wed Feb 28 09:45:19 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 28 Feb 2001 09:45:19 +1100 (EST) Subject: Fwd: OpenSSH on Ultrix? In-Reply-To: <20010227234133.A15038@greenie.muc.de> Message-ID: On Tue, 27 Feb 2001, Gert Doering wrote: > Hi, > > On Wed, Feb 28, 2001 at 08:27:08AM +1100, Damien Miller wrote: > > Yes - PRNGd is very nice and is superior to portable OpenSSH's own > [..] > > I strongly recommend it to everyone without a /dev/random. > > Are there any chances to use it on a system without unix sockets > (always the same problem here - SCO 3.0)? Lutz, Is there any chance of teaching PRNGd to listen on a localhost socket rather than (or in addition to) a Unix domain socket? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From matthew_carlson at non.hp.com Wed Feb 28 10:32:05 2001 From: matthew_carlson at non.hp.com (CARLSON,MATTHEW (Non-HP-Cupertino,ex1)) Date: Tue, 27 Feb 2001 16:32:05 -0700 Subject: rsa_public_encrypt() exponent too small or not odd Message-ID: <4341EF5F8B4AD311AB4B00902740B9F20460570A@xcup02.cup.hp.com> I am attempting to deploy OpenSSH. The trouble is I keep getting the rsa_public_encrypt() exponent too small or not odd with the SSH 1 or 1.5 protocols. I can't get OpenSSH to communicate with itself with any protocal other than SSH 2. Platform notes: HP-UX 11.00 Dart 51 64bit OpenSSL 0.9.6 Zlib 1.1.3 Cflags: -Ae I have tried with and without optimizations. I noticed that this problem has cropped up in the past on other platforms. But that was on much older releases. Anyone got any ideas? Matthew Carlson From tal at lumeta.com Wed Feb 28 10:58:18 2001 From: tal at lumeta.com (Tom Limoncelli) Date: Tue, 27 Feb 2001 18:58:18 -0500 Subject: Name change In-Reply-To: Message-ID: <5.0.2.1.0.20010227185706.02201bb8@starling.research.bell-labs.com> At 10:01 AM 2/17/2001, Jacek Pliszka wrote: >I am sorry if I am senidng it an incorrect place. > >I heard about problems with ssh trademark. If it is not solve >I propose name change to osh (Open Shell) or orsh (Open Remote Shell). You mean nobody can think of an acronym that spells T.A.T.U.? Terminal And.... hmmmm... --tal From mouring at etoh.eviladmin.org Wed Feb 28 11:58:50 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 27 Feb 2001 18:58:50 -0600 (CST) Subject: Name change In-Reply-To: <5.0.2.1.0.20010227185706.02201bb8@starling.research.bell-labs.com> Message-ID: On Tue, 27 Feb 2001, Tom Limoncelli wrote: > At 10:01 AM 2/17/2001, Jacek Pliszka wrote: > >I am sorry if I am senidng it an incorrect place. > > > >I heard about problems with ssh trademark. If it is not solve > >I propose name change to osh (Open Shell) or orsh (Open Remote Shell). > > You mean nobody can think of an acronym that spells T.A.T.U.? > > Terminal And.... hmmmm... > www.opentatu.com - Ben From tim at multitalents.net Wed Feb 28 12:09:25 2001 From: tim at multitalents.net (Tim Rice) Date: Tue, 27 Feb 2001 17:09:25 -0800 (PST) Subject: Bad packet length in 2.5.1 with rijndael (fwd) In-Reply-To: Message-ID: On Wed, 28 Feb 2001, Damien Miller wrote: > On Tue, 27 Feb 2001, Tim Rice wrote: > > > Would the AC_C_BIGENDIAN macro at configure time help? > > That is exactly the test that I am looking for :) > > Can affected people try this patch (you will need to autoreconf): Solves the problem here. > > Index: configure.in > =================================================================== > RCS file: /var/cvs/openssh/configure.in,v > retrieving revision 1.256 > diff -u -r1.256 configure.in > --- configure.in 2001/02/27 03:42:48 1.256 > +++ configure.in 2001/02/27 21:11:00 > @@ -5,6 +5,7 @@ > AC_CONFIG_HEADER(config.h) > AC_PROG_CC > AC_CANONICAL_HOST > +AC_C_BIGENDIAN > > # Checks for programs. > AC_PROG_CPP > Index: rijndael.c > =================================================================== > RCS file: /var/cvs/openssh/rijndael.c,v > retrieving revision 1.8 > diff -u -r1.8 rijndael.c > --- rijndael.c 2001/02/05 18:16:28 1.8 > +++ rijndael.c 2001/02/27 21:11:00 > @@ -58,7 +58,7 @@ > > #define byte(x,n) ((u1byte)((x) >> (8 * n))) > > -#if BYTE_ORDER != LITTLE_ENDIAN > +#ifdef WORDS_BIGENDIAN > #define BYTE_SWAP > #endif > > > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From greg at nest.cx Wed Feb 28 12:07:47 2001 From: greg at nest.cx (Gregory Steuck) Date: Tue, 27 Feb 2001 17:07:47 -0800 (PST) Subject: Endianness check: (was: Bad packet length in 2.5.1 with rijndael) In-Reply-To: <3A9C18F8.E1C029E2@yk.rim.or.jp> References: <15003.20275.414600.237572@home.nest.cx> <20010227111757.A397@faui02.informatik.uni-erlangen.de> <15003.33136.244811.97967@home.nest.cx> <20010227123516.A11731@folly> <15003.56834.186382.417551@home.nest.cx> <3A9C18F8.E1C029E2@yk.rim.or.jp> Message-ID: <15004.20323.947151.545533@home.nest.cx> autoconf's AC_C_BIGENDIAN ? Works for jikes AFAIK. >>>>> "Ishikawa" == Ishikawa writes: Ishikawa> (Now I recall I had an issue with a very old libc on linux Ishikawa> (circa 1996) in that it defined LITTLE_ENDIAN and Ishikawa> BIG_ENDIAN macro in ctype.h of all the header files(!) and Ishikawa> this uncalled-for name space pollution collided with a Ishikawa> user program, namely crack 4-1. :-) Anyway, setting the Ishikawa> value using a small program seems to me a non-protruding Ishikawa> solution and is a very reliable one IMHO.) From ishikawa at yk.rim.or.jp Wed Feb 28 12:30:09 2001 From: ishikawa at yk.rim.or.jp (Ishikawa) Date: Wed, 28 Feb 2001 10:30:09 +0900 Subject: Endianness check: (was: Bad packet length in 2.5.1 with rijndael) References: <15003.20275.414600.237572@home.nest.cx> <20010227111757.A397@faui02.informatik.uni-erlangen.de> <15003.33136.244811.97967@home.nest.cx> <20010227123516.A11731@folly> <15003.56834.186382.417551@home.nest.cx> <3A9C18F8.E1C029E2@yk.rim.or.jp> <15004.20323.947151.545533@home.nest.cx> Message-ID: <3A9C54A1.C5C0A7D8@yk.rim.or.jp> Gregory Steuck wrote: > autoconf's AC_C_BIGENDIAN ? Works for jikes AFAIK. > Nice to learn that autoconf has this covered already. [configure in 2.5.1p1 doesn't seem to use it yet.] (BTW, Is `jikes' the IBM java compiler? ) From tim at multitalents.net Wed Feb 28 12:40:25 2001 From: tim at multitalents.net (Tim Rice) Date: Tue, 27 Feb 2001 17:40:25 -0800 (PST) Subject: small patch for configure.in Message-ID: a small fix for the PRNG/EGD section -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- openssh_cvs/configure.in.old Tue Feb 27 12:56:06 2001 +++ openssh_cvs/configure.in Tue Feb 27 16:54:48 2001 @@ -5,6 +5,7 @@ AC_CONFIG_HEADER(config.h) AC_PROG_CC AC_CANONICAL_HOST +AC_C_BIGENDIAN # Checks for programs. AC_PROG_CPP @@ -1279,14 +1280,14 @@ if test -z "$RANDOM_POOL" ; then AC_MSG_CHECKING(for PRNGD/EGD socket) # Insert other locations here - for egdsock in /var/run/egd-pool /etc/entropy /tmp/entropy ; do + for egdsock in /var/run/egd-pool /tmp/egd-pool /etc/entropy /tmp/entropy ; do if test -r $egdsock && $TEST_MINUS_S_SH -c "test -S $egdsock -o -p $egdsock" ; then EGD_SOCKET="$egdsock" AC_DEFINE_UNQUOTED(EGD_SOCKET, "$EGD_SOCKET") break; fi done - if test -x "$EGD_SOCKET" ; then + if test -n "$EGD_SOCKET" ; then AC_MSG_RESULT($EGD_SOCKET) else AC_MSG_RESULT(not found) From mouring at etoh.eviladmin.org Wed Feb 28 13:36:01 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 27 Feb 2001 20:36:01 -0600 (CST) Subject: small patch for configure.in In-Reply-To: Message-ID: On Tue, 27 Feb 2001, Tim Rice wrote: > > a small fix for the PRNG/EGD section > > On the topic of PRNG/EGD.. for egdsock in /var/run/egd-pool /etc/entropy /tmp/entropy ; do Is /tmp really a valid/safe/sane directory for PRNG/EGD's pipe file? It just seems way to public. - Ben From djm at mindrot.org Wed Feb 28 12:49:52 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 28 Feb 2001 12:49:52 +1100 (EST) Subject: small patch for configure.in In-Reply-To: Message-ID: On Tue, 27 Feb 2001, Tim Rice wrote: > > a small fix for the PRNG/EGD section Applied. Thanks, Damien Miller -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Wed Feb 28 12:50:17 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 28 Feb 2001 12:50:17 +1100 (EST) Subject: small patch for configure.in In-Reply-To: Message-ID: On Tue, 27 Feb 2001 mouring at etoh.eviladmin.org wrote: > On the topic of PRNG/EGD.. > > for egdsock in /var/run/egd-pool /etc/entropy /tmp/entropy ; do > > Is /tmp really a valid/safe/sane directory for PRNG/EGD's pipe file? It > just seems way to public. Agreed - I'll pull it. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From tim at multitalents.net Wed Feb 28 12:59:21 2001 From: tim at multitalents.net (Tim Rice) Date: Tue, 27 Feb 2001 17:59:21 -0800 (PST) Subject: small patch for configure.in In-Reply-To: Message-ID: On Tue, 27 Feb 2001 mouring at etoh.eviladmin.org wrote: > On Tue, 27 Feb 2001, Tim Rice wrote: > > > > > a small fix for the PRNG/EGD section > > > > > > On the topic of PRNG/EGD.. > > for egdsock in /var/run/egd-pool /etc/entropy /tmp/entropy ; do > > Is /tmp really a valid/safe/sane directory for PRNG/EGD's pipe file? It > just seems way to public. Maybe you are right. Maybe I'll switch to /dev for the machines that don't have a /var/run /tmp/entropy was straight out of the EGD docs. > > - Ben > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From robbie at serendipity.palo-alto.ca.us Wed Feb 28 18:12:11 2001 From: robbie at serendipity.palo-alto.ca.us (Robbie Stone) Date: Tue, 27 Feb 2001 23:12:11 -0800 Subject: Fwd: OpenSSH on Ultrix? References: Message-ID: <3A9CA4CB.8629B4B6@serendipity.palo-alto.ca.us> Is this easily supported by OpenSSH? I looked at it briefly, but I'm going to need to add Ultrix support. Robbie > > Yes - PRNGd is very nice and is superior to portable OpenSSH's own > random number collection. The fact that it is a long-lived, system-wide > pool makes it more secure and less resource intensive than OpenSSH's > collection routines (which need to run at least once per program > invocation). > > I strongly recommend it to everyone without a /dev/random. > > -d > > -- > | Damien Miller \ ``E-mail attachments are the poor man's > | http://www.mindrot.org / distributed filesystem'' - Dan Geer -- Robbie Stone Serendipity Simplex From djm at mindrot.org Wed Feb 28 18:33:17 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 28 Feb 2001 18:33:17 +1100 (EST) Subject: Fwd: OpenSSH on Ultrix? In-Reply-To: <3A9CA4CB.8629B4B6@serendipity.palo-alto.ca.us> Message-ID: On Tue, 27 Feb 2001, Robbie Stone wrote: > Is this easily supported by OpenSSH? Yes, it will even autodetect it if the socket is in one of the standard locations. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From vetter at physik.uni-wuerzburg.de Wed Feb 28 19:57:11 2001 From: vetter at physik.uni-wuerzburg.de (Andreas Vetter) Date: Wed, 28 Feb 2001 09:57:11 +0100 (MET) Subject: AllowHosts / DenyHosts In-Reply-To: Message-ID: On Tue, 27 Feb 2001, Pekka Savola wrote: ->On Tue, 27 Feb 2001, Andreas Vetter wrote: ->> I'd like to see a feature of the commercial ssh in openssh: ->> AllowHosts xxx.yyy.xxx.yyy *.domain.net ->> DenyHosts xxx.yyy.xxx.* name.domain.net -> ->I begged this for a long time half a year ago or so, but never got any ->replies. So I gave up. Now I'm happily using tcp wrappers. -> ->I've made a patch for tcp_wrappers to enable wildcard matching (from ssh ->1.2.12), and to enable file includes (from freebsd). So I can't see why ->tcp_wrappers should be worse than HostsAllow and friends in this aspect. Tcp-wrappers are invoked by inetd, so when there is a DoS-attack against the inetd (usually this is done port by port): game over. If ssh can handle AllowHosts/DenyHosts itself, I don't need the (buggy) inetd. Andreas Vetter Universitaet Wuerzburg From markus.friedl at informatik.uni-erlangen.de Wed Feb 28 19:58:52 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 28 Feb 2001 09:58:52 +0100 Subject: AllowHosts / DenyHosts In-Reply-To: ; from vetter@physik.uni-wuerzburg.de on Tue, Feb 27, 2001 at 05:41:55PM +0100 References: Message-ID: <20010228095851.E13239@folly> On Tue, Feb 27, 2001 at 05:41:55PM +0100, Andreas Vetter wrote: > I'd like to see a feature of the commercial ssh in openssh: > AllowHosts xxx.yyy.xxx.yyy *.domain.net > DenyHosts xxx.yyy.xxx.* name.domain.net > > This allows or denies connects from certain machines (including wildcard > matching). > > Is there any chance for this feature to be included? No, we don't want to > use tcp-wrapper for this. why should every feature, even if there exist special solutions, included in openssh? you can deny ip-addresses with tcp-wrapper, ipfw, ipf, etc, etc. From markus.friedl at informatik.uni-erlangen.de Wed Feb 28 20:00:22 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 28 Feb 2001 10:00:22 +0100 Subject: win clients and sftp In-Reply-To: <200102271951.OAA02209@bell.bio.umass.edu>; from brettl@bio.umass.edu on Tue, Feb 27, 2001 at 02:51:14PM -0500 References: <200102271951.OAA02209@bell.bio.umass.edu> Message-ID: <20010228100022.F13239@folly> i think the sftp windows client forces the permissions. On Tue, Feb 27, 2001 at 02:51:14PM -0500, Brett Longworth wrote: > I'm having trouble with users transferring files to a solaris box running > ossh v2.3.1p1 via sftp using ssh.com's windows client. The sftp client > appears not to respect the users umask, creating files with either mode > 666 or 600. We're using version 2.4.0 of the windows client. Any ideas? > > thanks, > > -Brett > > ----------------- > Brett Longworth > Systems Manager > Department of Biology > University of Massachusetts > Amherst, MA 01003 > > Tel: 413.545.0216 > Fax: 413.545.3243 > ----------------- > "Pluralitas non est ponenda sine necessitate" > -William of Ockham > > > From pekkas at netcore.fi Wed Feb 28 20:00:21 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 28 Feb 2001 11:00:21 +0200 (EET) Subject: AllowHosts / DenyHosts In-Reply-To: Message-ID: On Wed, 28 Feb 2001, Andreas Vetter wrote: > On Tue, 27 Feb 2001, Pekka Savola wrote: > > ->On Tue, 27 Feb 2001, Andreas Vetter wrote: > ->> I'd like to see a feature of the commercial ssh in openssh: > ->> AllowHosts xxx.yyy.xxx.yyy *.domain.net > ->> DenyHosts xxx.yyy.xxx.* name.domain.net > -> > ->I begged this for a long time half a year ago or so, but never got any > ->replies. So I gave up. Now I'm happily using tcp wrappers. > -> > ->I've made a patch for tcp_wrappers to enable wildcard matching (from ssh > ->1.2.12), and to enable file includes (from freebsd). So I can't see why > ->tcp_wrappers should be worse than HostsAllow and friends in this aspect. > > Tcp-wrappers are invoked by inetd, so when there is a DoS-attack against > the inetd (usually this is done port by port): game over. If ssh can > handle AllowHosts/DenyHosts itself, I don't need the (buggy) inetd. No, this isn't necessary. Use ./configure --with-tcp-wrappers. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From yuliy at mobiltel.bg Wed Feb 28 20:19:04 2001 From: yuliy at mobiltel.bg (Yuliy Minchev) Date: Wed, 28 Feb 2001 11:19:04 +0200 (EET) Subject: AllowHosts / DenyHosts In-Reply-To: <20010228095851.E13239@folly> Message-ID: On Wed, 28 Feb 2001, Markus Friedl wrote: > On Tue, Feb 27, 2001 at 05:41:55PM +0100, Andreas Vetter wrote: > > I'd like to see a feature of the commercial ssh in openssh: > > AllowHosts xxx.yyy.xxx.yyy *.domain.net > > DenyHosts xxx.yyy.xxx.* name.domain.net > > > > This allows or denies connects from certain machines (including wildcard > > matching). > > > > Is there any chance for this feature to be included? No, we don't want to > > use tcp-wrapper for this. > > why should every feature, even if there exist special solutions, > included in openssh? you can deny ip-addresses with tcp-wrapper, > ipfw, ipf, etc, etc. There are some old (or exotic) systems which haven't nor ip filtering capabilities, nor tcp-wrapper. So it would be a good think if OpenSSH can handle Allow/Deny clauses. yuliy -- Yuliy Minchev, UNIX Administrator From pekkas at netcore.fi Wed Feb 28 20:32:31 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 28 Feb 2001 11:32:31 +0200 (EET) Subject: AllowHosts / DenyHosts In-Reply-To: Message-ID: On Wed, 28 Feb 2001, Yuliy Minchev wrote: > On Wed, 28 Feb 2001, Markus Friedl wrote: > > > On Tue, Feb 27, 2001 at 05:41:55PM +0100, Andreas Vetter wrote: > > > I'd like to see a feature of the commercial ssh in openssh: > > > AllowHosts xxx.yyy.xxx.yyy *.domain.net > > > DenyHosts xxx.yyy.xxx.* name.domain.net > > > > > > This allows or denies connects from certain machines (including wildcard > > > matching). > > > > > > Is there any chance for this feature to be included? No, we don't want to > > > use tcp-wrapper for this. > > > > why should every feature, even if there exist special solutions, > > included in openssh? you can deny ip-addresses with tcp-wrapper, > > ipfw, ipf, etc, etc. > > There are some old (or exotic) systems which haven't nor ip filtering > capabilities, nor tcp-wrapper. > So it would be a good think if OpenSSH can handle Allow/Deny clauses. [Cc: list tailored a bit] These ancient systems should not be trusted to be connected to the internet anyway, unless they're behind a firewall which can do this kind of thing. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From yuliy at mobiltel.bg Wed Feb 28 20:44:51 2001 From: yuliy at mobiltel.bg (Yuliy Minchev) Date: Wed, 28 Feb 2001 11:44:51 +0200 (EET) Subject: AllowHosts / DenyHosts In-Reply-To: Message-ID: re > > > why should every feature, even if there exist special solutions, > > > included in openssh? you can deny ip-addresses with tcp-wrapper, > > > ipfw, ipf, etc, etc. > > > > There are some old (or exotic) systems which haven't nor ip filtering > > capabilities, nor tcp-wrapper. > > So it would be a good think if OpenSSH can handle Allow/Deny clauses. > > [Cc: list tailored a bit] > > These ancient systems should not be trusted to be connected to the > internet anyway, unless they're behind a firewall which can do this kind > of thing. Yes, you are right. But, how can one increase security indoors of organization? Especialy if he takes care only for this old machines and not for communications and firewall policy? What about an organization with offices all over the country (or the world), with private network connecting these offices. No one talks about Internet in this situation. yuliy -- Yuliy Minchev, UNIX Administrator From dankamin at cisco.com Wed Feb 28 20:55:49 2001 From: dankamin at cisco.com (Dan Kaminsky) Date: Wed, 28 Feb 2001 01:55:49 -0800 Subject: AllowHosts / DenyHosts References: <20010228095851.E13239@folly> Message-ID: <01bd01c0a16c$bfd4d430$0200040a@na.cisco.com> > > Is there any chance for this feature to be included? No, we don't want to > > use tcp-wrapper for this. > > why should every feature, even if there exist special solutions, > included in openssh? you can deny ip-addresses with tcp-wrapper, > ipfw, ipf, etc, etc. Markus-- We already allow per-host configuration for the client in readconf.c; any objection to adding similar functionality to the server in servconf.c? This would let us do such things as allow X forwarding from the one lab that critically needs it but keep it banned it for everyone else. And, since the moment the server gets host-switching configs, it becomes trivial to ban authentication(simply disable all methods), one might as well save on the crypto expense as well and let certain hosts(users?) simply trigger a fatal() on contact. To be honest, most DMZ accessable daemons tend to include internal controls, particularly for cross platform compatibility, consistent configuration, and per-protocol flexibility. I'm not saying we should adopt the exact options that SSH2 has--nice and simple as they are, they're not particularly flexible. But I can see the value in what people are asking for, and I think we can do it even better than its been done. There is, of course, the inevitable problem. If you can't *trust* IP addresses, just user authenticators, then what are you doing switching your configurations based on addresses? I'd like to stick to cryptographic keys--finally, a genuine use for rhostsrsa?--but clearly we can enhance security by ruling out entire swaths of attackers simply due to their unspoofed address space. This is clearly a useful thing, though--or else tcp wrappers et al wouldn't be brought up.) Yours Truly, Dan Kaminsky, CISSP www.doxpara.com From dankamin at cisco.com Wed Feb 28 20:56:22 2001 From: dankamin at cisco.com (Dan Kaminsky) Date: Wed, 28 Feb 2001 01:56:22 -0800 Subject: AllowHosts / DenyHosts References: Message-ID: <01be01c0a16c$c062e360$0200040a@na.cisco.com> > These ancient systems should not be trusted to be connected to the > internet anyway, unless they're behind a firewall which can do this kind > of thing. Presumptuous, are we :-) There *are* ancient machines out there that *aren't* going anywhere, but *still* have telnet on them. If you're trying to eradicate telnet throughout your organization, making these machines run ssh is a Good Thing. Preventing trivial, even accidental DoS attacks on machines with low processing power by automatically rejecting all SSH connection attempts that don't come from a specific classification of hosts is a Good Thing. Yours Truly, Dan Kaminsky, CISSP www.doxpara.com From Markus.Friedl at informatik.uni-erlangen.de Wed Feb 28 21:01:36 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 28 Feb 2001 11:01:36 +0100 Subject: AllowHosts / DenyHosts In-Reply-To: <01bd01c0a16c$bfd4d430$0200040a@na.cisco.com>; from dankamin@cisco.com on Wed, Feb 28, 2001 at 01:55:49AM -0800 References: <20010228095851.E13239@folly> <01bd01c0a16c$bfd4d430$0200040a@na.cisco.com> Message-ID: <20010228110136.A8531@faui02.informatik.uni-erlangen.de> On Wed, Feb 28, 2001 at 01:55:49AM -0800, Dan Kaminsky wrote: > This would let us do such things as allow X forwarding from the one lab that > critically needs it but keep it banned it for everyone else. this could be implemented with keynote (rfc2704). someone needs to add keynote support to openssh. From john.phillips at calanais.com Wed Feb 28 21:09:07 2001 From: john.phillips at calanais.com (Phillips, John) Date: Wed, 28 Feb 2001 10:09:07 -0000 Subject: SU vs. ssh root@host Message-ID: <7D7384737DC6D2119C9B0008C7394C920405BF63@HAMSPWNTS01> I agree that it is desirable to login as root. In our environment we have 12 admin's looking after around 750 workstations/servers. Our ideal is to use openssh with keys and the Openssh patch which identifies which key has been used to login as root. This gives a degree of security and accountability. But when somebody leaves/starts then somebody has to go around all the boxes and add/remove userids or keys, so logging in directly as root is necessary with password as well unless we get into complex expect scripts etc. I realize that this may not be the "most secure" method, but I think we need to trade off risk against operational effectiveness. John (John.Phillips at calanais.com) Unix Support, Calanais Ltd Internal Phone: 700 2643 External Phone: 0141 568 2643 > -----Original Message----- > From: John Hardin [mailto:johnh at aproposretail.com] > Sent: 27 February 2001 16:38 > To: OpenSSH Development List > Subject: Re: SU vs. ssh root at host > > > mouring at etoh.eviladmin.org wrote: > > > > 1) On a fully secure system 'root' should *NEVER* be > allowed to be logged > > in remotely. This includes localhost because it's possible > to spoof such > > things (Granted this is my view, but it's a view that has > been drilled > > into me since I first started in the UNIX community in 92). > > And me since 1988. > > > This also has no useful bearing on OpenSSH project. So > this thread is at > > at an end so useful work can be done. =) > > I disagree. I'm finding it very useful as an administrator > (granted it's > noise to developers). The discussion here has caused me to review my > reasoning behind modifying the default sshd_config to disable root > logins as I build our internal RPMs. This is not a bad thing > to do every > so often. > > Both sides have made good points, but a consensus has not been reached > yet. Can we reach a consensus and update the default > configuration files > (if necessary) to reflect it? > > -- > John Hardin > Internal Systems Administrator > Apropos Retail Management Systems, Inc. > - (425) 672-1304 > From Randolf-ML at Skerka.de Wed Feb 28 21:10:20 2001 From: Randolf-ML at Skerka.de (Randolf Skerka) Date: Wed, 28 Feb 2001 11:10:20 +0100 Subject: OpenSSH 2.5.1p1 on HP-UX: No CTRL+C possible!!! In-Reply-To: <20010221230149.A4656@greenie.muc.de>; from gert@greenie.muc.de on Wed, Feb 21, 2001 at 11:01:49PM +0100 References: <3A936F57.6952C208@skerka.de> <20010221135056.A15309@rhs-notebook> <20010221230149.A4656@greenie.muc.de> Message-ID: <20010228111019.A3891@rhs-notebook> Well I made some more tests about that topic and can't find consistend results. On a System: HP-UX B.11.00 A 9000/887 two-user license no CTRL+C is possible. When I make a telnet localhost within the SecureShell session CTRL+C works as expected. On a System HP-UX B.11.00 B 9000/800 16-user license CTRL+C works as expected within SSH! I've checked /etc/termcap and /bin/sh on both systems. They are identically. More hints? Totally confused! Randolf From a.d.stribblehill at durham.ac.uk Wed Feb 28 21:10:36 2001 From: a.d.stribblehill at durham.ac.uk (Andrew Stribblehill) Date: Wed, 28 Feb 2001 10:10:36 +0000 Subject: [Script] ssh-add dropping keys when xscreensaver blanks In-Reply-To: ; from djm@mindrot.org on Wed, Feb 28, 2001 at 08:21:54AM +1100 References: <20010227153258.A16765@womble.dur.ac.uk> Message-ID: <20010228101036.A22836@womble.dur.ac.uk> Quoting Damien Miller : > On Tue, 27 Feb 2001, Andrew Stribblehill wrote: > > > The people at Debian were chuntering that it'd be a good idea for > > xscreensaver to ask ssh-add to drop its keys when it blanked the > > screen. Would the attached script (which does just that) be worth > > adding to the contrib directory? > > You committed the capital crime of not attaching the script. Stand still, > a squad is on its way to you now. D'oh! I'll try again. Cheerio, Andrew Stribblehill Systems programmer, IT Service, University of Durham, England -------------- next part -------------- #!/usr/bin/perl -w # # screenwatch. Watches xscreensaver and drops keys when screen blanks. # Adds the default key on unblank. # # Typical usage: Put this command in your .xsession # # BUGS: Only adds the default key, not all the keys that it had before. # [Matter-of-taste] Drops keys on both blank and lock. use strict; use POSIX 'setsid'; sub daemonise { chdir '/' or die "Can't chdir to /: $!"; open STDIN, '/dev/null' or die "Can't read /dev/null: $!"; open STDOUT, '>/dev/null' or die "Can't write to /dev/null: $!"; defined(my $pid = fork) or die "Can't fork: $!"; exit if $pid; setsid or die "Can't start a new session: $!"; open STDERR, '>&STDOUT' or die "Can't dup stdout: $!"; } daemonise(); my $blanked = 0; open (IN, "/usr/bin/X11/xscreensaver-command -watch |"); while () { if (m/^(BLANK|LOCK)/) { if (!$blanked) { system("/usr/bin/ssh-add -D"); $blanked = 1; } } elsif (m/^UNBLANK/) { system("ssh-add"); $blanked = 0; } } From djm at mindrot.org Wed Feb 28 21:17:56 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 28 Feb 2001 21:17:56 +1100 (EST) Subject: AllowHosts / DenyHosts In-Reply-To: Message-ID: On Wed, 28 Feb 2001, Yuliy Minchev wrote: > There are some old (or exotic) systems which haven't nor ip > filtering capabilities, nor tcp-wrapper. So it would be a good > think if OpenSSH can handle Allow/Deny clauses. tcp-wrappers is _very_ portable. What platforms that OpenSSH supports are not supported by TCP wrappers? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Wed Feb 28 21:20:43 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 28 Feb 2001 21:20:43 +1100 (EST) Subject: [Script] ssh-add dropping keys when xscreensaver blanks In-Reply-To: <20010228101036.A22836@womble.dur.ac.uk> Message-ID: On Wed, 28 Feb 2001, Andrew Stribblehill wrote: > Quoting Damien Miller : > > On Tue, 27 Feb 2001, Andrew Stribblehill wrote: > > > > > The people at Debian were chuntering that it'd be a good idea for > > > xscreensaver to ask ssh-add to drop its keys when it blanked the > > > screen. Would the attached script (which does just that) be worth > > > adding to the contrib directory? I like the concept, but I don't like how it only adds the default protocol 1 key. Could you get it to parse the output of "ssh-add -l" to pick up the other keys too? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From a.d.stribblehill at durham.ac.uk Wed Feb 28 21:59:08 2001 From: a.d.stribblehill at durham.ac.uk (Andrew Stribblehill) Date: Wed, 28 Feb 2001 10:59:08 +0000 Subject: [Script] ssh-add dropping keys when xscreensaver blanks In-Reply-To: ; from djm@mindrot.org on Wed, Feb 28, 2001 at 09:20:43PM +1100 References: <20010228101036.A22836@womble.dur.ac.uk> Message-ID: <20010228105908.B22836@womble.dur.ac.uk> Quoting Damien Miller : > On Wed, 28 Feb 2001, Andrew Stribblehill wrote: > > > Quoting Damien Miller : > > > On Tue, 27 Feb 2001, Andrew Stribblehill wrote: > > > > > > > The people at Debian were chuntering that it'd be a good idea for > > > > xscreensaver to ask ssh-add to drop its keys when it blanked the > > > > screen. Would the attached script (which does just that) be worth > > > > adding to the contrib directory? > > I like the concept, but I don't like how it only adds the default protocol > 1 key. Could you get it to parse the output of "ssh-add -l" to pick up > the other keys too? I'm not sure I can, since it can't find out the filename (or hostname, for that matter) from which the keys are read. Or is there something I'm missing. I was expecting that people using this script would hack it themselves to get it to add their extra keys. Cheerio, Andrew Stribblehill From pekkas at netcore.fi Wed Feb 28 22:08:02 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 28 Feb 2001 13:08:02 +0200 (EET) Subject: AllowHosts / DenyHosts In-Reply-To: Message-ID: On Wed, 28 Feb 2001, Yuliy Minchev wrote: > > re > > > > > why should every feature, even if there exist special solutions, > > > > included in openssh? you can deny ip-addresses with tcp-wrapper, > > > > ipfw, ipf, etc, etc. > > > > > > There are some old (or exotic) systems which haven't nor ip filtering > > > capabilities, nor tcp-wrapper. > > > So it would be a good think if OpenSSH can handle Allow/Deny clauses. > > > > [Cc: list tailored a bit] > > > > These ancient systems should not be trusted to be connected to the > > internet anyway, unless they're behind a firewall which can do this kind > > of thing. > > Yes, you are right. But, how can one increase security indoors of > organization? Especialy if he takes care only for this old machines and > not for communications and firewall policy? > > What about an organization with offices all over the country (or the > world), with private network connecting these offices. No one talks about > Internet in this situation. Most security breaches (so the statistics show) are internal. I don't quite understand organizations where you just have one huge firewall but nothing between different offices, departments, lan segments or whatever. Perhaps (usually) not as strict as the outer packet filters, but definitely a capability to do so. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From rmy at tigress.co.uk Wed Feb 28 22:09:16 2001 From: rmy at tigress.co.uk (rmy at tigress.co.uk) Date: Wed, 28 Feb 2001 11:09:16 GMT Subject: AllowHosts / DenyHosts Message-ID: <200102281109.LAA26221@tiffany.tigress.pgs.com.> Folks, Dan Kaminsky wrote: > There is, of course, the inevitable problem. If you can't *trust* IP >addresses, just user authenticators, then what are you doing switching your >configurations based on addresses? I'd like to stick to cryptographic >keys--finally, a genuine use for rhostsrsa?--but clearly we can enhance >security by ruling out entire swaths of attackers simply due to their >unspoofed address space. Sounds a bit like what I proposed back in August: >It seemed to me that it would be useful to be able to control access to >my server with the /etc/ssh_known_hosts file, using RSA authentication >of the remote host. But the protocol only allows RSA host authentication >in conjunction with rhosts, while I prefer RSA user authentication. > >I've made a patch to the server which adds a new configuration option: >RSAHostOtherAuthentication. When this option is enabled RSA host >authentication is turned on, but without the rhosts check. Also, RSA >host authentication on its own is insufficient to authenticate the user. >The server also requires one other authentication method to succeed. >It doesn't matter which, and the order in which the methods are tried >doesn't matter. > >With this modified server I can enable RSA authentication of both the >remote host and the user. This only works if the client is willing to >try different authentication methods if the first doesn't succeed. > >I'm happy with this, but does it make sense? Is there any obvious flaw? The patch against 2.1.1p4 is in the list archive: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=96538738531641&w=2 Ron From dankamin at cisco.com Wed Feb 28 22:10:00 2001 From: dankamin at cisco.com (Dan Kaminsky) Date: Wed, 28 Feb 2001 03:10:00 -0800 Subject: AllowHosts / DenyHosts References: <20010228095851.E13239@folly> <01bd01c0a16c$bfd4d430$0200040a@na.cisco.com> <20010228110136.A8531@faui02.informatik.uni-erlangen.de> Message-ID: <001301c0a176$feb6ce60$0200040a@na.cisco.com> > On Wed, Feb 28, 2001 at 01:55:49AM -0800, Dan Kaminsky wrote: > > This would let us do such things as allow X forwarding from the one lab that > > critically needs it but keep it banned it for everyone else. > > this could be implemented with keynote (rfc2704). someone > needs to add keynote support to openssh. Hadn't seen Keynote before, but I've seen the disastrous failures of certificates to take over the IT world in anything *but* web servers. There's probably something more to Keynote...what makes it worth the LOC/admin mis-grok level relative to: Host * Reject Host 129.210.*.* Allow ReverseMappingCheck no User Bob ChallengeResponseAuthentication yes AFSTokenPassing yes RhostsRSA 5c:06:8c:da:6b:db:e0:f5:6f:3d:0f:a6:32:c0:5d:d0 Banner /etc/issue.net etc? About the best that comes to mind is handling large indexes of key fingerprints...but there are better ways of doing that too. Yours Truly, Dan Kaminsky, CISSP www.doxpara.com From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Feb 28 22:18:00 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Wed, 28 Feb 2001 12:18:00 +0100 Subject: Fwd: OpenSSH on Ultrix? In-Reply-To: ; from djm@mindrot.org on Wed, Feb 28, 2001 at 09:45:19AM +1100 References: <20010227234133.A15038@greenie.muc.de> Message-ID: <20010228121800.A4682@serv01.aet.tu-cottbus.de> On Wed, Feb 28, 2001 at 09:45:19AM +1100, Damien Miller wrote: > On Tue, 27 Feb 2001, Gert Doering wrote: > > On Wed, Feb 28, 2001 at 08:27:08AM +1100, Damien Miller wrote: > > > Yes - PRNGd is very nice and is superior to portable OpenSSH's own > > [..] > > > I strongly recommend it to everyone without a /dev/random. > > > > Are there any chances to use it on a system without unix sockets > > (always the same problem here - SCO 3.0)? > > Lutz, > > Is there any chance of teaching PRNGd to listen on a localhost socket > rather than (or in addition to) a Unix domain socket? Yes, that should be possible. I don't see a problem as long as we can stay with 127.0.0.1 (otherwise access control via tcpd would be needed to be built in and we would probably come a bit far from what PRNGD actually should do :-). Give me a bit of time to realize the new feature. 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 Markus.Friedl at informatik.uni-erlangen.de Wed Feb 28 22:43:06 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 28 Feb 2001 12:43:06 +0100 Subject: AllowHosts / DenyHosts In-Reply-To: <001301c0a176$feb6ce60$0200040a@na.cisco.com>; from dankamin@cisco.com on Wed, Feb 28, 2001 at 03:10:00AM -0800 References: <20010228095851.E13239@folly> <01bd01c0a16c$bfd4d430$0200040a@na.cisco.com> <20010228110136.A8531@faui02.informatik.uni-erlangen.de> <001301c0a176$feb6ce60$0200040a@na.cisco.com> Message-ID: <20010228124306.A14063@faui02.informatik.uni-erlangen.de> On Wed, Feb 28, 2001 at 03:10:00AM -0800, Dan Kaminsky wrote: > > On Wed, Feb 28, 2001 at 01:55:49AM -0800, Dan Kaminsky wrote: > > > This would let us do such things as allow X forwarding from the one lab > that > > > critically needs it but keep it banned it for everyone else. > > > > this could be implemented with keynote (rfc2704). someone > > needs to add keynote support to openssh. > > Hadn't seen Keynote before, but I've seen the disastrous failures of > certificates to take over the IT world in anything *but* web servers. keynote is not about certificates, it's about policy. From yuliy at mobiltel.bg Wed Feb 28 22:42:59 2001 From: yuliy at mobiltel.bg (Yuliy Minchev) Date: Wed, 28 Feb 2001 13:42:59 +0200 (EET) Subject: AllowHosts / DenyHosts In-Reply-To: Message-ID: re > > There are some old (or exotic) systems which haven't nor ip > > filtering capabilities, nor tcp-wrapper. So it would be a good > > think if OpenSSH can handle Allow/Deny clauses. > > tcp-wrappers is _very_ portable. What platforms that OpenSSH supports > are not supported by TCP wrappers? In fact you are right. But if I want just to run OpenSSH on some hosts and to control access - why should I need to install yet another program (tcp-wrapper) and then to track yet another program (tcp-wrapper) for new bugs discovered? It's enough that you need zlib/openssl/egd to install OpenSSH on some machines. It's a good thing that in 2.5 there is an internal way to gather entropy. Someone said a few weeks ago, he wants to see OpenSSH capable to compile without you have installed openssl and zlib. I think it'll be a good to have all the things needed for OpenSSH to work - 'out of the box'. I mean - you get the source, compile it and that's enough. yuliy -- Yuliy Minchev, UNIX Administrator From Markus.Friedl at informatik.uni-erlangen.de Wed Feb 28 22:47:34 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 28 Feb 2001 12:47:34 +0100 Subject: AllowHosts / DenyHosts In-Reply-To: ; from yuliy@mobiltel.bg on Wed, Feb 28, 2001 at 01:42:59PM +0200 References: Message-ID: <20010228124734.A14250@faui02.informatik.uni-erlangen.de> On Wed, Feb 28, 2001 at 01:42:59PM +0200, Yuliy Minchev wrote: > In fact you are right. But if I want just to run OpenSSH on some hosts > and to control access - why should I need to install yet another program > (tcp-wrapper) and then to track yet another program (tcp-wrapper) for new > bugs discovered? why should you install bash? let's add it to openssh? why install this or that? it can be all included in openssh. > I think it'll be a good to have all the things needed for OpenSSH to work > - 'out of the box'. I mean - you get the source, compile it and that's > enough. why should openssh implement it's own crypto library? why not use openssl? you don't need to install openssl in /usr/local in order to compile openssh. From Nigel.Metheringham at InTechnology.co.uk Wed Feb 28 22:59:32 2001 From: Nigel.Metheringham at InTechnology.co.uk (Nigel Metheringham) Date: Wed, 28 Feb 2001 11:59:32 +0000 Subject: AllowHosts / DenyHosts In-Reply-To: Message from Yuliy Minchev of "Wed, 28 Feb 2001 13:42:59 +0200." Message-ID: yuliy at mobiltel.bg said: > I think it'll be a good to have all the things needed for OpenSSH to > work - 'out of the box'. I mean - you get the source, compile it and > that's enough. but that makes the task of source maintenance much much harder - much more of it, more sub-packages to either maintain yourself or track other people's work. That means more bugs - or knowing the thoroughness of the openBSD folks, more opportunities for bugs and a slowed release schedule as they sort those bugs. Far better to use a set of well known building blocks. And since openssh is basically a openBSD package, which is then also distributed in a portable form, that would actually result in the sub-packages being integrated by the portability package builders... which would mean the whole package would further trail the main source. [and should the package contain a complete libc to cater for the broken mess that some vendors have shipped in the past] I think the openssh should concentrate on what they are doing well. If someone else wants to build a further package with all the extra source set added in, fine, but its really a wasted duplication of effort. Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] From markus.friedl at informatik.uni-erlangen.de Wed Feb 28 23:46:24 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 28 Feb 2001 13:46:24 +0100 Subject: AllowHosts / DenyHosts In-Reply-To: ; from vetter@physik.uni-wuerzburg.de on Wed, Feb 28, 2001 at 09:57:11AM +0100 References: Message-ID: <20010228134624.D30778@folly> On Wed, Feb 28, 2001 at 09:57:11AM +0100, Andreas Vetter wrote: > Tcp-wrappers are invoked by inetd, so when there is a DoS-attack against > the inetd (usually this is done port by port): game over. tcp-wrappers are not at all related to inetd. they only can be used with inetd. you don't need inetd if you want to use sshd + tcpwrappers since sshd uses libwrap directly. > If ssh can > handle AllowHosts/DenyHosts itself, I don't need the (buggy) inetd. From tcs at MailAndNews.com Thu Feb 22 05:41:51 2001 From: tcs at MailAndNews.com (Neal Barney) Date: Wed, 21 Feb 2001 11:41:51 -0700 Subject: OpenSSH 2.5.1 compatibility problem Message-ID: <5.0.2.1.0.20010221113907.00a217d0@mailandnews.com> SSH server specs: ----------------------- Redhat Linux 6.2 Custom built 2.2.17 kernel OpenSSL 0.9.5a (update from RedHat). OpenSSH 2.5.1p1 I am using my Linux box as an Internet gateway. I wanted to keep the box as secure as possible while still having the functionality I needed. The only way to connect to my server is through SSH. A fair majority of the time I am attempting to connect to the server from a Windows box (whether at work, home, or on the road...). The software that I have used extensively in the past is a great little program called PuTTY (http://www.chiark.greenend.org.uk/~sgtatham/putty/). It supports SSH1 and SSH2 protocols. I have never had any problems in the past using these two pieces of software together. PuTTY has worked flawlessly with OpenSSH 2.2.0p1 and 2.3.0p1. However, using OpenSSH 2.5.1p1 PuTTY will no longer work. PuTTY will briefly flash a window and exit. No error messages are given from PuTTY. However, the sshd daemon outputs the following line to the Linux log file: Feb 21 10:13:04 rugen sshd[21915]: fatal: xfree: NULL pointer given as argument Everything works fine if I downgrade to OpenSSH 2.3.0p1. For completeness sake, I'll include some info about the client machine: PuTTY version: 0.51 (also downloaded snapshot on Feb 21st, 2001). OS: Windows 98 Connection mode: SSH Options selected: -------------------------- Connection Terminal type string xterm Auto-login username (blank) (also tried using local login name) SSH Remote command (blank) Attempt TIS or Cryptocard... (not checked) Allows agent forwarding (not checked) Don't allocate a pseudo-term. (not checked) Preferred Protocol vers. SSH2 Preferred Encryption algo. 3DES Imitate MAC bug in com... (not checked) The author of putty (putty at projects.tartarus.org) has already been contacted about this problem. I hope that enough information was given and is helpful in locating the problem.