From ESQUIRE_SITHESVARAN at dm.gov.ae Tue Apr 3 18:18:39 2007 From: ESQUIRE_SITHESVARAN at dm.gov.ae (ESQUIRE Sithesvaran) Date: Tue, 3 Apr 2007 12:18:39 +0400 Subject: Error messages after upgrading to OpenSSH_4.6p1 Message-ID: <983771046C3CD8478025E73F533B25B901652319@HQOMAIL.dm.ae> Hi, I have upgraded the openssh (OpenSSH_4.6p1) on Solaris 8 server. After upgrading I am getting the below error messages when we execute the commands in remote systems using ssh. However the ssh works fine without any issue. Please let me know is there is any fix for it. Apr 2 03:05:39 hostname sshd[7294]: [ID 800047 auth.info] Accepted publickey for user from xx.xx.xx.xx port 32808 ssh2 Apr 2 03:05:40 hostname sshd[7296]: [ID 800047 auth.error] error: channel 0: chan_read_failed for istate 3 Apr 2 03:05:40 hostname last message repeated 1 time Apr 2 03:05:41 hostname sshd[7299]: [ID 800047 auth.info] Accepted publickey for user from xx.xx.xx.xx port 32809 ssh2 Apr 2 03:05:41 hostname sshd[7301]: [ID 800047 auth.error] error: channel 0: chan_read_failed for istate 3 Apr 2 03:05:41 hostname last message repeated 1 time Thanks, Sithesvaran Thirumaran Unix Administrator Internet Operations Unit Dubai Municipality Mobile: +971-50-5494352 Email: esquire_sithesvaran at dm.gov.ae Our Vision To create an excellent city that provides the essence of success and comfort of living. Disclaimer: This Electronic Mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not an addressee, or have received the message by error, please notify the sender via E-Mail or over the telephone and delete this e-mail. You are not authorized to read, copy, disseminate, distribute or use this E-Mail or any of its attachment in any way. Any views or opinions presented in this email are solely those of the author and do not necessarily represent Dubai Municipality. The recipient should check this email and any attachments for the presence of viruses/worms. Dubai Municipality accepts no liability for any damage caused by any virus/worms transmitted by this email. Dubai Municipality, Dubai, UAE, http://www.dm.gov.ae/ From djm at mindrot.org Wed Apr 4 14:00:57 2007 From: djm at mindrot.org (Damien Miller) Date: Wed, 4 Apr 2007 14:00:57 +1000 (EST) Subject: 4.6p1 chan_read_failed error In-Reply-To: <46084BAF.2070601@lindy.stanford.edu> References: <46045AB6.6050903@lindy.stanford.edu> <20070324114902.GA8307@gate.dtucker.net> <46084BAF.2070601@lindy.stanford.edu> Message-ID: On Mon, 26 Mar 2007, Jim Stosick wrote: > On 3/24/2007 4:49 AM, Darren Tucker wrote: > > > On Fri, Mar 23, 2007 at 03:54:46PM -0700, Jim Stosick wrote: > >> The 4.6p1 sshd is logging this error during remote commands or file > >> transfers: > >> > >> error: channel 0: chan_read_failed for istate 3 > >> > >> Platform is Solaris 8, 4.6p1 + OpenSSL 0.9.8d. > > > I suspect this is related to the change for bug #52. You could try > > reverting the following patch ("patch -p1 -R") and see if the error > > messages stop. > > Yes, that eliminates the chan_read_failed error messages. Well, it also undoes the fix for bug #52. I think it is safe to simply hush the error message: Index: nchan.c =================================================================== RCS file: /var/cvs/openssh/nchan.c,v retrieving revision 1.56 diff -u -p -r1.56 nchan.c --- nchan.c 5 Aug 2006 02:39:40 -0000 1.56 +++ nchan.c 4 Apr 2007 03:56:11 -0000 @@ -135,15 +135,16 @@ chan_rcvd_oclose1(Channel *c) void chan_read_failed(Channel *c) { - debug2("channel %d: read failed", c->self); + debug2("channel %d: read failed, istate %d", c->self, c->istate); switch (c->istate) { case CHAN_INPUT_OPEN: chan_shutdown_read(c); chan_set_istate(c, CHAN_INPUT_WAIT_DRAIN); break; default: - error("channel %d: chan_read_failed for istate %d", - c->self, c->istate); + if (!c->isatty || !c->detach_close) + error("channel %d: chan_read_failed for istate %d", + c->self, c->istate); break; } } From jerry.moore at baesystems.com Wed Apr 4 08:53:30 2007 From: jerry.moore at baesystems.com (Moore, Jerry C (CSC) (US SSA)) Date: Tue, 3 Apr 2007 17:53:30 -0500 Subject: openssl-0.9.7e compile error. Message-ID: I am trying versions back. But I get the same compile error every time on HP-UX 11.0 with openssh-4.5p1. Was almost there. . . . gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconne ct1.o sshconnect2.o -L. -Lopenbsd-compat/ -L/usr/local/ssl/lib -lssh -lopenbsd-compat -lcrypto -lz -lnsl -lxnet -lsec /usr/ccs/bin/ld: Unsatisfied symbols: _U_Qfneg (first referenced in openbsd-compat//libopenbsd-compat.a(bsd-arc4random.o)) (code) collect2: ld returned 1 exit status *** Error exit code 1 Jerry Moore CSC, Principal UNIX Systems Administrator BAE Systems Electronics & Integrated Solutions 3131 Story Road West, Irving, Texas 75038 Work 972-659-3226 Mobile 214-868-6953 Jerry.Moore at baesystems.com Jmoore91 at csc.com From dtucker at zip.com.au Thu Apr 5 08:24:51 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 05 Apr 2007 08:24:51 +1000 Subject: openssl-0.9.7e compile error. In-Reply-To: References: Message-ID: <461425B3.6080200@zip.com.au> Moore, Jerry C (CSC) (US SSA) wrote: > I am trying versions back. But I get the same compile error every time > on HP-UX 11.0 with openssh-4.5p1. Was almost there. > > gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconne > ct1.o sshconnect2.o -L. -Lopenbsd-compat/ -L/usr/local/ssl/lib -lssh > -lopenbsd-compat -lcrypto -lz -lnsl -lxnet -lsec > /usr/ccs/bin/ld: Unsatisfied symbols: > _U_Qfneg (first referenced in > openbsd-compat//libopenbsd-compat.a(bsd-arc4random.o)) (code) > collect2: ld returned 1 exit status > *** Error exit code 1 Which version of gcc is that? Did you compile openssl with gcc? If not, I suggest that you try compiling openssl with gcc too. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From rapier at psc.edu Fri Apr 6 01:08:36 2007 From: rapier at psc.edu (Chris Rapier) Date: Thu, 05 Apr 2007 11:08:36 -0400 Subject: Static build under Cygwin? Message-ID: <461510F4.3070408@psc.edu> I was wondering if anyone has statically built OpenSSH under cygwin? Mostly I'm just trying to avoid the need to require a specific user to install cygwin in order to use the client. Does it involve mingw? Linker tricks? Voodoo? I tried -static but it didn't seem to work. Of course, I could have just screwed something up. Thanks for any insight. From stuge-openssh-unix-dev at cdy.org Fri Apr 6 02:56:06 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 5 Apr 2007 18:56:06 +0200 Subject: Static build under Cygwin? In-Reply-To: <461510F4.3070408@psc.edu> References: <461510F4.3070408@psc.edu> Message-ID: <20070405165606.15061.qmail@cdy.org> On Thu, Apr 05, 2007 at 11:08:36AM -0400, Chris Rapier wrote: > I was wondering if anyone has statically built OpenSSH under > cygwin? > Mostly I'm just trying to avoid the need to require a specific user > to install cygwin in order to use the client. Does it involve > mingw? Yes, it would, but MinGW != Cygwin and I don't think OpenSSH likes it very much in Win32 land. Cygwin is a POSIX compatibility layer for Win32. MinGW is gcc+friends for Win32 with little or no built-in compatibility. //Peter From rapier at psc.edu Fri Apr 6 02:29:14 2007 From: rapier at psc.edu (Chris Rapier) Date: Thu, 05 Apr 2007 12:29:14 -0400 Subject: Static build under Cygwin? In-Reply-To: <20070405165606.15061.qmail@cdy.org> References: <461510F4.3070408@psc.edu> <20070405165606.15061.qmail@cdy.org> Message-ID: <461523DA.3050202@psc.edu> Peter Stuge wrote: > On Thu, Apr 05, 2007 at 11:08:36AM -0400, Chris Rapier wrote: >> I was wondering if anyone has statically built OpenSSH under >> cygwin? >> Mostly I'm just trying to avoid the need to require a specific user >> to install cygwin in order to use the client. Does it involve >> mingw? > > Yes, it would, but MinGW != Cygwin and I don't think OpenSSH likes it > very much in Win32 land. > > Cygwin is a POSIX compatibility layer for Win32. > > MinGW is gcc+friends for Win32 with little or no built-in > compatibility. So basically it would require voodoo. How many goats? ;) From stuge-openssh-unix-dev at cdy.org Fri Apr 6 03:06:36 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 5 Apr 2007 19:06:36 +0200 Subject: Static build under Cygwin? In-Reply-To: <461523DA.3050202@psc.edu> References: <461510F4.3070408@psc.edu> <20070405165606.15061.qmail@cdy.org> <461523DA.3050202@psc.edu> Message-ID: <20070405170636.16603.qmail@cdy.org> On Thu, Apr 05, 2007 at 12:29:14PM -0400, Chris Rapier wrote: > Peter Stuge wrote: > > On Thu, Apr 05, 2007 at 11:08:36AM -0400, Chris Rapier wrote: > >> I was wondering if anyone has statically built OpenSSH under > >> cygwin? > >> Mostly I'm just trying to avoid the need to require a specific > >> user to install cygwin in order to use the client. Does it > >> involve mingw? > > > > Yes, it would, but MinGW != Cygwin and I don't think OpenSSH likes it > > very much in Win32 land. > > > > Cygwin is a POSIX compatibility layer for Win32. > > > > MinGW is gcc+friends for Win32 with little or no built-in > > compatibility. > > So basically it would require voodoo. How many goats? > ;) 42. Back to the original question: http://www.sourceware.org/ml/cygwin/2000-12/msg01162.html http://www.cygwin.com/ml/cygwin/2000-06/msg00756.html Seems it's not doable. But perhaps it's OK to distribute cygwin1.dll along with ssh.exe ? //Peter From vinschen at redhat.com Fri Apr 6 03:11:57 2007 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 5 Apr 2007 19:11:57 +0200 Subject: Static build under Cygwin? In-Reply-To: <20070405170636.16603.qmail@cdy.org> References: <461510F4.3070408@psc.edu> <20070405165606.15061.qmail@cdy.org> <461523DA.3050202@psc.edu> <20070405170636.16603.qmail@cdy.org> Message-ID: <20070405171157.GA13737@calimero.vinschen.de> On Apr 5 19:06, Peter Stuge wrote: > On Thu, Apr 05, 2007 at 12:29:14PM -0400, Chris Rapier wrote: > > Peter Stuge wrote: > > > On Thu, Apr 05, 2007 at 11:08:36AM -0400, Chris Rapier wrote: > > >> I was wondering if anyone has statically built OpenSSH under > > >> cygwin? > > >> Mostly I'm just trying to avoid the need to require a specific > > >> user to install cygwin in order to use the client. Does it > > >> involve mingw? > > > > > > Yes, it would, but MinGW != Cygwin and I don't think OpenSSH likes it > > > very much in Win32 land. > > > > > > Cygwin is a POSIX compatibility layer for Win32. > > > > > > MinGW is gcc+friends for Win32 with little or no built-in > > > compatibility. > > > > So basically it would require voodoo. How many goats? > > ;) > > 42. > > Back to the original question: > > http://www.sourceware.org/ml/cygwin/2000-12/msg01162.html > http://www.cygwin.com/ml/cygwin/2000-06/msg00756.html You can't build statically against Cygwin and it's not intended to work. > Seems it's not doable. But perhaps it's OK to distribute cygwin1.dll > along with ssh.exe ? http://cygwin.com/acronyms/#3PP. Please don't. There should be only exactly one Cygwin DLL installed on a machine and that should ideally be the Cygwin DLL installed from the Cygwin net distribution. Having two Cygwin DLLs with different version numbers on a machine is bound to result in trouble. It's roughly equivalent to trying to run two Linux kernels on the same machine in parallel without virtualization layer. Further discussions about providing the Cygwin DLL (including especially the licensing issues) should better be directed to the mailing list cygwin AT cygwin DOT com. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From rapier at psc.edu Fri Apr 6 03:23:16 2007 From: rapier at psc.edu (Chris Rapier) Date: Thu, 05 Apr 2007 13:23:16 -0400 Subject: Static build under Cygwin? In-Reply-To: <20070405171157.GA13737@calimero.vinschen.de> References: <461510F4.3070408@psc.edu> <20070405165606.15061.qmail@cdy.org> <461523DA.3050202@psc.edu> <20070405170636.16603.qmail@cdy.org> <20070405171157.GA13737@calimero.vinschen.de> Message-ID: <46153084.9040708@psc.edu> Corinna Vinschen wrote: > On Apr 5 19:06, Peter Stuge wrote: >> On Thu, Apr 05, 2007 at 12:29:14PM -0400, Chris Rapier wrote: >>> Peter Stuge wrote: >>>> On Thu, Apr 05, 2007 at 11:08:36AM -0400, Chris Rapier wrote: >>>>> I was wondering if anyone has statically built OpenSSH under >>>>> cygwin? >>>>> Mostly I'm just trying to avoid the need to require a specific >>>>> user to install cygwin in order to use the client. Does it >>>>> involve mingw? >>>> Yes, it would, but MinGW != Cygwin and I don't think OpenSSH likes it >>>> very much in Win32 land. >>>> >>>> Cygwin is a POSIX compatibility layer for Win32. >>>> >>>> MinGW is gcc+friends for Win32 with little or no built-in >>>> compatibility. >>> So basically it would require voodoo. How many goats? >>> ;) >> 42. >> >> Back to the original question: >> >> http://www.sourceware.org/ml/cygwin/2000-12/msg01162.html >> http://www.cygwin.com/ml/cygwin/2000-06/msg00756.html > > You can't build statically against Cygwin and it's not intended to work. Just curious, is this by specific design or did it just work out that way? >> Seems it's not doable. But perhaps it's OK to distribute cygwin1.dll >> along with ssh.exe ? Heh. I was just in the middle of writing some mail about how much the cygwin people don't like this :) > > http://cygwin.com/acronyms/#3PP. > > Please don't. Which is pretty much why I was looking for a way to build openssh against cygwin statically. I'll probably just end up trying to port the hpn patch over to putty (convincing people to move the globus patch as well might be tough though :) ) > There should be only exactly one Cygwin DLL installed on > a machine and that should ideally be the Cygwin DLL installed from the > Cygwin net distribution. Having two Cygwin DLLs with different version > numbers on a machine is bound to result in trouble. It's roughly > equivalent to trying to run two Linux kernels on the same machine in > parallel without virtualization layer. I have seen this happen in the past actually. Usually its really not a problem though as the vast majority of people that can benefit from SSH (eg, all the people that only need the client) don't have a need for the rest of cygwin. However, in the cases where it is a problem its intensely annoying. As such, I wouldn't do it for a externally distributed product. From vinschen at redhat.com Fri Apr 6 03:56:43 2007 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 5 Apr 2007 19:56:43 +0200 Subject: Static build under Cygwin? In-Reply-To: <46153084.9040708@psc.edu> References: <461510F4.3070408@psc.edu> <20070405165606.15061.qmail@cdy.org> <461523DA.3050202@psc.edu> <20070405170636.16603.qmail@cdy.org> <20070405171157.GA13737@calimero.vinschen.de> <46153084.9040708@psc.edu> Message-ID: <20070405175643.GD13737@calimero.vinschen.de> On Apr 5 13:23, Chris Rapier wrote: > Corinna Vinschen wrote: > > You can't build statically against Cygwin and it's not intended to work. > > Just curious, is this by specific design or did it just work out that way? It's by design. Cygwin isn't just a lib with function calls, it's providing lots of shared information between different processes kept by the DLL in a version specific way. Stuff like process table, /proc emulation, pseudo ttys, named pipes, tape access and what not, all depend on the shared information. > > Please don't. > > Which is pretty much why I was looking for a way to build openssh > against cygwin statically. I'll probably just end up trying to port the > hpn patch over to putty (convincing people to move the globus patch as > well might be tough though :) ) Yes, actually it might be better to use an already existing native Windows application like putty for that. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From jerry.moore at baesystems.com Fri Apr 6 04:20:10 2007 From: jerry.moore at baesystems.com (Moore, Jerry C (CSC) (US SSA)) Date: Thu, 5 Apr 2007 13:20:10 -0500 Subject: openssh-4.4p1 compile error. Message-ID: Darren or anyone, can anyone point me to what and where I can download the necessary src's and dependencies to make ssh work on HP-UX 11.0 PARISC 1.0. I've been trying to work with: openssh-4.4p1 openssh-4.5p1 openssl-0.9.7e openssl-0.9.8e Jerry Moore CSC, Principal UNIX Systems Administrator BAE Systems Electronics & Integrated Solutions 3131 Story Road West, Irving, Texas 75038 Work 972-659-3226 Mobile 214-868-6953 Jerry.Moore at baesystems.com Jmoore91 at csc.com -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Wednesday, April 04, 2007 5:25 PM To: Moore, Jerry C (CSC) (US SSA) Cc: openssh-unix-dev at mindrot.org Subject: Re: openssl-0.9.7e compile error. Moore, Jerry C (CSC) (US SSA) wrote: > I am trying versions back. But I get the same compile error every time > on HP-UX 11.0 with openssh-4.5p1. Was almost there. > > gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconne > ct1.o sshconnect2.o -L. -Lopenbsd-compat/ -L/usr/local/ssl/lib -lssh > -lopenbsd-compat -lcrypto -lz -lnsl -lxnet -lsec > /usr/ccs/bin/ld: Unsatisfied symbols: > _U_Qfneg (first referenced in > openbsd-compat//libopenbsd-compat.a(bsd-arc4random.o)) (code) > collect2: ld returned 1 exit status > *** Error exit code 1 Which version of gcc is that? Did you compile openssl with gcc? If not, I suggest that you try compiling openssl with gcc too. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Fri Apr 6 12:06:14 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 06 Apr 2007 12:06:14 +1000 Subject: openssh-4.4p1 compile error. In-Reply-To: References: Message-ID: <4615AB16.7020006@zip.com.au> Moore, Jerry C (CSC) (US SSA) wrote: > Darren or anyone, can anyone point me to what and where > I can download the necessary src's and dependencies to > make ssh work on HP-UX 11.0 PARISC 1.0. I've been trying > to work with: > > openssh-4.4p1 > openssh-4.5p1 > openssl-0.9.7e > openssl-0.9.8e OpenSSH requires OpenSSL (either of the versions about should work, but 0.9.8e has a bug that will stop the SSHv1 3des cipher from working correctly, and 0.9.7e is kinda old so I'd use 0.9.7l) and zlib. These are all documented in OpenSSH's INSTALL file including URLs. You also need an ANSI C compiler (both gcc and HP's ANSI compiler should be fine, although you may have problems compiling different components with different compilers). You didn't answer my question about which gcc version you're using but I suspect it's 3.3.2 or similar, which seems to have problems on HP-UX: http://marc.info/?l=openssh-unix-dev&m=113891780712349&w=2 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From william.ralph.ctr at navy.mil Fri Apr 6 03:51:13 2007 From: william.ralph.ctr at navy.mil (Bill Ralph) Date: Thu, 05 Apr 2007 13:51:13 -0400 Subject: 4.6p1 chan_read_failed error Message-ID: <46153711.6010903@navy.mil> I just applied the nchan.c patch to openssh-4.6p1 as furnished in the previous message from Damien Miller: > Well, it also undoes the fix for bug #52. I think it is safe to simply hush > the error message: > Index: nchan.c > =================================================================== > CS file: /var/cvs/openssh/nchan.c,v > retrieving revision 1.56 > diff -u -p -r1.56 nchan.c > --- nchan.c 5 Aug 2006 02:39:40 -0000 1.56 > +++ nchan.c 4 Apr 2007 03:56:11 -0000 > @@ -135,15 +135,16 @@ chan_rcvd_oclose1(Channel *c) > void > chan_read_failed(Channel *c) > { > - debug2("channel %d: read failed", c->self); > + debug2("channel %d: read failed, istate %d", c->self, c->istate); > switch (c->istate) { > case CHAN_INPUT_OPEN: > chan_shutdown_read(c); > chan_set_istate(c, CHAN_INPUT_WAIT_DRAIN); > break; > default: > - error("channel %d: chan_read_failed for istate %d", > - c->self, c->istate); > + if (!c->isatty || !c->detach_close) > + error("channel %d: chan_read_failed for istate %d", < + c->self, c->istate); > break; > } > } Unfortunately, sshd still produces the message: error: channel 0: chan_read_failed for istate 3 -- --------------------------------------- ___ _ _ _ ___ _ _ | _ |_) | | | _ \__ _| |_ __| |_ | _ \ | | | | / _` | | '_ \ ' \ |___/_|_|_| |_|_\__,_|_| .__/_||_| I work for the US Navy.|_| We are not responsible for each other's mistakes. --------------------------------------- From jerry.moore at baesystems.com Sat Apr 7 06:03:47 2007 From: jerry.moore at baesystems.com (Moore, Jerry C (CSC) (US SSA)) Date: Fri, 6 Apr 2007 15:03:47 -0500 Subject: openssh-4.4p1 compile error. Message-ID: Sorry I forgot the gcc version. You were correct. gcc 3.3.2. I was able to find a pre-compiled version for HP-UX 11.0. openssh-3[1].1p1-sd-11.00.depot.gz at borgware.com. It works. I'll try upgrading gcc, etc... and see if that helps on the compile. If I get the compile to work I'll let you know what I did for HP-UX 11.0. Thanks for your help Darren. -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Thursday, April 05, 2007 9:06 PM To: Moore, Jerry C (CSC) (US SSA) Cc: openssh-unix-dev at mindrot.org Subject: Re: openssh-4.4p1 compile error. Moore, Jerry C (CSC) (US SSA) wrote: > Darren or anyone, can anyone point me to what and where > I can download the necessary src's and dependencies to > make ssh work on HP-UX 11.0 PARISC 1.0. I've been trying > to work with: > > openssh-4.4p1 > openssh-4.5p1 > openssl-0.9.7e > openssl-0.9.8e OpenSSH requires OpenSSL (either of the versions about should work, but 0.9.8e has a bug that will stop the SSHv1 3des cipher from working correctly, and 0.9.7e is kinda old so I'd use 0.9.7l) and zlib. These are all documented in OpenSSH's INSTALL file including URLs. You also need an ANSI C compiler (both gcc and HP's ANSI compiler should be fine, although you may have problems compiling different components with different compilers). You didn't answer my question about which gcc version you're using but I suspect it's 3.3.2 or similar, which seems to have problems on HP-UX: http://marc.info/?l=openssh-unix-dev&m=113891780712349&w=2 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From Gerry.Texeira at LibertyMutual.com Sat Apr 7 04:31:05 2007 From: Gerry.Texeira at LibertyMutual.com (Texeira, Gerry) Date: Fri, 6 Apr 2007 14:31:05 -0400 Subject: Password enforcement problem with OpenSSH on AIX. Message-ID: <685543AEA172E549B33E9CB5601583A408AFC466@LM-EXMSG-05.lm.lmig.com> Hello, I've encountered a password enforcement problem with OpenSSH on AIX. In AIX, when the user contains the flags = ADMCHG in the /etc/security/passwd file, the user is forced to change the password at next login. It works for telnet but it does not work under the OpenSSH v3.4 version. Based on my research, it appears this issue is resolved with OpenSSH v3.8p1. Can anyone confirm? Thank you, -Gerry From ESQUIRE_SITHESVARAN at dm.gov.ae Sun Apr 8 18:01:38 2007 From: ESQUIRE_SITHESVARAN at dm.gov.ae (ESQUIRE Sithesvaran) Date: Sun, 8 Apr 2007 12:01:38 +0400 Subject: Error message after upgraing the openssh 4.6P1 Message-ID: <983771046C3CD8478025E73F533B25B901652616@HQOMAIL.dm.ae> Hi, We have upgraded the openssh 4.6P1 on Solaris 8 servers. After upgrade we get the below error message whenever we execute the remote commands using ssh. Please let me know what the fix is for this. Apr 8 03:03:43 dvsrv10 sshd[25379]: [ID 800047 auth.info] Accepted publickey for osteam from 10.0.93.31 port 35856 ssh2 Apr 8 03:03:50 dvsrv10 sshd[25381]: [ID 800047 auth.error] error: channel 0: chan_read_failed for istate 3 Apr 8 03:03:50 dvsrv10 last message repeated 1 time Apr 8 03:03:51 dvsrv10 sshd[25384]: [ID 800047 auth.info] Accepted publickey for osteam from 10.0.93.31 port 35857 ssh2 Apr 8 03:03:52 dvsrv10 sshd[25386]: [ID 800047 auth.error] error: channel 0: chan_read_failed for istate 3 Apr 8 03:03:52 dvsrv10 last message repeated 1 time Apr 8 03:03:52 dvsrv10 sshd[25389]: [ID 800047 auth.info] Accepted publickey for osteam from 10.0.93.31 port 35858 ssh2 Apr 8 03:03:53 dvsrv10 sshd[25391]: [ID 800047 auth.error] error: channel 0: chan_read_failed for istate 3 Apr 8 03:03:53 dvsrv10 last message repeated 1 time Apr 8 03:03:53 dvsrv10 sshd[25394]: [ID 800047 auth.info] Accepted publickey for osteam from 10.0.93.31 port 35859 ssh2 Apr 8 03:03:53 dvsrv10 sshd[25396]: [ID 800047 auth.error] error: channel 0: chan_read_failed for istate 3 Thanks, Sithesvaran Thirumaran Unix Administrator Internet Operations Unit Dubai Municipality Mobile: +971-50-5494352 Email: esquire_sithesvaran at dm.gov.ae Our Vision To create an excellent city that provides the essence of success and comfort of living. Disclaimer: This Electronic Mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not an addressee, or have received the message by error, please notify the sender via E-Mail or over the telephone and delete this e-mail. You are not authorized to read, copy, disseminate, distribute or use this E-Mail or any of its attachment in any way. Any views or opinions presented in this email are solely those of the author and do not necessarily represent Dubai Municipality. The recipient should check this email and any attachments for the presence of viruses/worms. Dubai Municipality accepts no liability for any damage caused by any virus/worms transmitted by this email. Dubai Municipality, Dubai, UAE, http://www.dm.gov.ae/ From stuge-openssh-unix-dev at cdy.org Mon Apr 9 02:07:46 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sun, 8 Apr 2007 18:07:46 +0200 Subject: Error message after upgraing the openssh 4.6P1 In-Reply-To: <983771046C3CD8478025E73F533B25B901652616@HQOMAIL.dm.ae> References: <983771046C3CD8478025E73F533B25B901652616@HQOMAIL.dm.ae> Message-ID: <20070408160746.14308.qmail@cdy.org> Hi, On Sun, Apr 08, 2007 at 12:01:38PM +0400, ESQUIRE Sithesvaran wrote: > We have upgraded the openssh 4.6P1 on Solaris 8 servers. After > upgrade we get the below error message whenever we execute the > remote commands using ssh. Please let me know what the fix is for > this. Please include debugging output, so the problem can be identified easier. Run sshd -ddd and ssh -vvv when connecting to get full debug output. Please also describe the problem as thorougly as possible. Do you know if the command actually does get executed, for example? //Peter From ssklar at stanford.edu Mon Apr 9 03:29:05 2007 From: ssklar at stanford.edu (Sandor W. Sklar) Date: Sun, 8 Apr 2007 10:29:05 -0700 Subject: Error message after upgraing the openssh 4.6P1 In-Reply-To: <983771046C3CD8478025E73F533B25B901652616@HQOMAIL.dm.ae> References: <983771046C3CD8478025E73F533B25B901652616@HQOMAIL.dm.ae> Message-ID: This sounds like the same error posted about by a coworker, in the thread here: ... there is a patch in that thread, provided by Darren Tucker, that fixed the problem for us. -s- On Apr 8, 2007, at 1:01 AM, ESQUIRE Sithesvaran wrote: > Hi, > > > > We have upgraded the openssh 4.6P1 on Solaris 8 servers. After upgrade > we get the below error message whenever we execute the remote commands > using ssh. Please let me know what the fix is for this. > > > > Apr 8 03:03:43 dvsrv10 sshd[25379]: [ID 800047 auth.info] Accepted > publickey for osteam from 10.0.93.31 port 35856 ssh2 > > Apr 8 03:03:50 dvsrv10 sshd[25381]: [ID 800047 auth.error] error: > channel 0: chan_read_failed for istate 3 > > Apr 8 03:03:50 dvsrv10 last message repeated 1 time > > Apr 8 03:03:51 dvsrv10 sshd[25384]: [ID 800047 auth.info] Accepted > publickey for osteam from 10.0.93.31 port 35857 ssh2 > > Apr 8 03:03:52 dvsrv10 sshd[25386]: [ID 800047 auth.error] error: > channel 0: chan_read_failed for istate 3 > > Apr 8 03:03:52 dvsrv10 last message repeated 1 time > > Apr 8 03:03:52 dvsrv10 sshd[25389]: [ID 800047 auth.info] Accepted > publickey for osteam from 10.0.93.31 port 35858 ssh2 > > Apr 8 03:03:53 dvsrv10 sshd[25391]: [ID 800047 auth.error] error: > channel 0: chan_read_failed for istate 3 > > Apr 8 03:03:53 dvsrv10 last message repeated 1 time > > Apr 8 03:03:53 dvsrv10 sshd[25394]: [ID 800047 auth.info] Accepted > publickey for osteam from 10.0.93.31 port 35859 ssh2 > > Apr 8 03:03:53 dvsrv10 sshd[25396]: [ID 800047 auth.error] error: > channel 0: chan_read_failed for istate 3 > > > > Thanks, > > Sithesvaran Thirumaran > Unix Administrator > Internet Operations Unit > Dubai Municipality > Mobile: +971-50-5494352 > Email: esquire_sithesvaran at dm.gov.ae > > > > > > Our Vision > To create an excellent city that provides the essence of success > and comfort of living. > > Disclaimer: > This Electronic Mail and any files transmitted with it are > confidential > and intended solely for the use of the individual or entity to > whom they > are addressed. If you are not an addressee, or have received the > message > by error, please notify the sender via E-Mail or over the > telephone and > delete this e-mail. You are not authorized to read, copy, > disseminate, > distribute or use this E-Mail or any of its attachment in any > way. Any > views or opinions presented in this email are solely those of the > author > and do not necessarily represent Dubai Municipality. The recipient > should > check this email and any attachments for the presence of viruses/ > worms. > Dubai Municipality accepts no liability for any damage caused > by any > virus/worms transmitted by this email. > > Dubai Municipality, Dubai, UAE, http://www.dm.gov.ae/ > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From djm at mindrot.org Mon Apr 9 08:46:56 2007 From: djm at mindrot.org (Damien Miller) Date: Mon, 9 Apr 2007 08:46:56 +1000 (EST) Subject: 4.6p1 chan_read_failed error In-Reply-To: References: <46045AB6.6050903@lindy.stanford.edu> <20070324114902.GA8307@gate.dtucker.net> <46084BAF.2070601@lindy.stanford.edu> Message-ID: On Wed, 4 Apr 2007, Damien Miller wrote: > Well, it also undoes the fix for bug #52. I think it is safe to simply hush > the error message: ugh, the logic in that patch was almost, but not completely, wrong. Please try this one instead: Index: channels.c =================================================================== RCS file: /var/cvs/openssh/channels.c,v retrieving revision 1.251 diff -u -p -r1.251 channels.c --- channels.c 28 Jan 2007 23:16:28 -0000 1.251 +++ channels.c 8 Apr 2007 22:43:25 -0000 @@ -932,7 +932,7 @@ channel_pre_x11_open(Channel *c, fd_set } else if (ret == -1) { logit("X11 connection rejected because of wrong authentication."); debug2("X11 rejected %d i%d/o%d", c->self, c->istate, c->ostate); - chan_read_failed(c); + chan_read_failed(c, 0); buffer_clear(&c->input); chan_ibuf_empty(c); buffer_clear(&c->output); @@ -1472,14 +1472,15 @@ channel_handle_rfd(Channel *c, fd_set *r c->type = SSH_CHANNEL_INPUT_DRAINING; debug2("channel %d: input draining.", c->self); } else { - chan_read_failed(c); + chan_read_failed(c, (errno == EAGAIN && + !(c->isatty && c->detach_close))); } return -1; } if (c->input_filter != NULL) { if (c->input_filter(c, buf, len) == -1) { debug2("channel %d: filter stops", c->self); - chan_read_failed(c); + chan_read_failed(c, 0); } } else if (c->datagram) { buffer_put_string(&c->input, buf, len); @@ -1643,7 +1644,7 @@ channel_handle_ctl(Channel *c, fd_set *r chan_mark_dead(c); return -1; } else { - chan_read_failed(c); + chan_read_failed(c, 0); chan_write_failed(c); } return -1; Index: channels.h =================================================================== RCS file: /var/cvs/openssh/channels.h,v retrieving revision 1.81 diff -u -p -r1.81 channels.h --- channels.h 5 Aug 2006 02:39:39 -0000 1.81 +++ channels.h 8 Apr 2007 22:43:41 -0000 @@ -240,7 +240,7 @@ void chan_mark_dead(Channel *); /* channel events */ void chan_rcvd_oclose(Channel *); -void chan_read_failed(Channel *); +void chan_read_failed(Channel *, int); void chan_ibuf_empty(Channel *); void chan_rcvd_ieof(Channel *); Index: nchan.c =================================================================== RCS file: /var/cvs/openssh/nchan.c,v retrieving revision 1.56 diff -u -p -r1.56 nchan.c --- nchan.c 5 Aug 2006 02:39:40 -0000 1.56 +++ nchan.c 8 Apr 2007 22:41:36 -0000 @@ -133,17 +133,19 @@ chan_rcvd_oclose1(Channel *c) } } void -chan_read_failed(Channel *c) +chan_read_failed(Channel *c, int simulated) { - debug2("channel %d: read failed", c->self); + debug2("channel %d: read failed%s, istate %d", c->self, + simulated ? " (simulated)" : "", c->istate); switch (c->istate) { case CHAN_INPUT_OPEN: chan_shutdown_read(c); chan_set_istate(c, CHAN_INPUT_WAIT_DRAIN); break; default: - error("channel %d: chan_read_failed for istate %d", - c->self, c->istate); + if (!simulated) + error("channel %d: chan_read_failed for istate %d", + c->self, c->istate); break; } } From ESQUIRE_SITHESVARAN at dm.gov.ae Mon Apr 9 16:24:21 2007 From: ESQUIRE_SITHESVARAN at dm.gov.ae (ESQUIRE Sithesvaran) Date: Mon, 9 Apr 2007 10:24:21 +0400 Subject: Error message after upgraing the openssh 4.6P1 Message-ID: <983771046C3CD8478025E73F533B25B9016526D0@HQOMAIL.dm.ae> Hi Sandor, I see the below solution for this issue. When I execute the below command, it is not giving command prompt after wards, it just keep running. Let me know which patch it reverts, what it does? > > I suspect this is related to the change for bug #52. You could try > > reverting the following patch ("patch -p1 -R") and see if the error > > messages stop. > > Yes, that eliminates the chan_read_failed error messages. Regds, Sithesvaran. -----Original Message----- From: Sandor W. Sklar [mailto:ssklar at stanford.edu] Sent: Sunday, April 08, 2007 9:29 PM To: ESQUIRE Sithesvaran Cc: OpenSSH Devel List Subject: Re: Error message after upgraing the openssh 4.6P1 This sounds like the same error posted about by a coworker, in the thread here: ... there is a patch in that thread, provided by Darren Tucker, that fixed the problem for us. -s- On Apr 8, 2007, at 1:01 AM, ESQUIRE Sithesvaran wrote: > Hi, > > > > We have upgraded the openssh 4.6P1 on Solaris 8 servers. After upgrade > we get the below error message whenever we execute the remote commands > using ssh. Please let me know what the fix is for this. > > > > Apr 8 03:03:43 dvsrv10 sshd[25379]: [ID 800047 auth.info] Accepted > publickey for osteam from 10.0.93.31 port 35856 ssh2 > > Apr 8 03:03:50 dvsrv10 sshd[25381]: [ID 800047 auth.error] error: > channel 0: chan_read_failed for istate 3 > > Apr 8 03:03:50 dvsrv10 last message repeated 1 time > > Apr 8 03:03:51 dvsrv10 sshd[25384]: [ID 800047 auth.info] Accepted > publickey for osteam from 10.0.93.31 port 35857 ssh2 > > Apr 8 03:03:52 dvsrv10 sshd[25386]: [ID 800047 auth.error] error: > channel 0: chan_read_failed for istate 3 > > Apr 8 03:03:52 dvsrv10 last message repeated 1 time > > Apr 8 03:03:52 dvsrv10 sshd[25389]: [ID 800047 auth.info] Accepted > publickey for osteam from 10.0.93.31 port 35858 ssh2 > > Apr 8 03:03:53 dvsrv10 sshd[25391]: [ID 800047 auth.error] error: > channel 0: chan_read_failed for istate 3 > > Apr 8 03:03:53 dvsrv10 last message repeated 1 time > > Apr 8 03:03:53 dvsrv10 sshd[25394]: [ID 800047 auth.info] Accepted > publickey for osteam from 10.0.93.31 port 35859 ssh2 > > Apr 8 03:03:53 dvsrv10 sshd[25396]: [ID 800047 auth.error] error: > channel 0: chan_read_failed for istate 3 > > > > Thanks, > > Sithesvaran Thirumaran > Unix Administrator > Internet Operations Unit > Dubai Municipality > Mobile: +971-50-5494352 > Email: esquire_sithesvaran at dm.gov.ae > > > > > > Our Vision > To create an excellent city that provides the essence of success > and comfort of living. > > Disclaimer: > This Electronic Mail and any files transmitted with it are > confidential > and intended solely for the use of the individual or entity to > whom they > are addressed. If you are not an addressee, or have received the > message > by error, please notify the sender via E-Mail or over the > telephone and > delete this e-mail. You are not authorized to read, copy, > disseminate, > distribute or use this E-Mail or any of its attachment in any > way. Any > views or opinions presented in this email are solely those of the > author > and do not necessarily represent Dubai Municipality. The recipient > should > check this email and any attachments for the presence of viruses/ > worms. > Dubai Municipality accepts no liability for any damage caused > by any > virus/worms transmitted by this email. > > Dubai Municipality, Dubai, UAE, http://www.dm.gov.ae/ > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev Our Vision To create an excellent city that provides the essence of success and comfort of living. Disclaimer: This Electronic Mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not an addressee, or have received the message by error, please notify the sender via E-Mail or over the telephone and delete this e-mail. You are not authorized to read, copy, disseminate, distribute or use this E-Mail or any of its attachment in any way. Any views or opinions presented in this email are solely those of the author and do not necessarily represent Dubai Municipality. The recipient should check this email and any attachments for the presence of viruses/worms. Dubai Municipality accepts no liability for any damage caused by any virus/worms transmitted by this email. Dubai Municipality, Dubai, UAE, http://www.dm.gov.ae/ From dtucker at zip.com.au Mon Apr 9 19:32:46 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 9 Apr 2007 19:32:46 +1000 Subject: 4.6p1 chan_read_failed error In-Reply-To: References: <46045AB6.6050903@lindy.stanford.edu> <20070324114902.GA8307@gate.dtucker.net> <46084BAF.2070601@lindy.stanford.edu> Message-ID: <20070409093246.GA11203@gate.dtucker.net> On Mon, Apr 09, 2007 at 08:46:56AM +1000, Damien Miller wrote: > On Wed, 4 Apr 2007, Damien Miller wrote: > > > Well, it also undoes the fix for bug #52. I think it is safe to simply hush > > the error message: > > ugh, the logic in that patch was almost, but not completely, wrong. Please > try this one instead: I can reproduce the problem on Solaris 8 but that patch does not resolve the spurious errors for me (which appears to be because the read is returning zero). BTW, While looking at it, though, I was bothered enormously by the PTY_ZEROREAD ifdef mess which made it hard to read. I think we should do something like this once the original problem is sorted out. Index: Makefile.in =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/Makefile.in,v retrieving revision 1.284 diff -u -p -r1.284 Makefile.in --- Makefile.in 25 Mar 2007 08:26:01 -0000 1.284 +++ Makefile.in 9 Apr 2007 09:01:03 -0000 @@ -71,7 +71,7 @@ LIBSSH_OBJS=acss.o authfd.o authfile.o b atomicio.o key.o dispatch.o kex.o mac.o uidswap.o uuencode.o misc.o \ monitor_fdpass.o rijndael.o ssh-dss.o ssh-rsa.o dh.o kexdh.o \ kexgex.o kexdhc.o kexgexc.o scard.o msg.o progressmeter.o dns.o \ - entropy.o scard-opensc.o gss-genr.o + entropy.o scard-opensc.o gss-genr.o platform.o SSHOBJS= ssh.o readconf.o clientloop.o sshtty.o \ sshconnect.o sshconnect1.o sshconnect2.o @@ -86,7 +86,7 @@ SSHDOBJS=sshd.o auth-rhosts.o auth-passw auth-krb5.o \ auth2-gss.o gss-serv.o gss-serv-krb5.o \ loginrec.o auth-pam.o auth-shadow.o auth-sia.o md5crypt.o \ - audit.o audit-bsm.o platform.o + audit.o audit-bsm.o MANPAGES = scp.1.out ssh-add.1.out ssh-agent.1.out ssh-keygen.1.out ssh-keyscan.1.out ssh.1.out sshd.8.out sftp-server.8.out sftp.1.out ssh-rand-helper.8.out ssh-keysign.8.out sshd_config.5.out ssh_config.5.out MANPAGES_IN = scp.1 ssh-add.1 ssh-agent.1 ssh-keygen.1 ssh-keyscan.1 ssh.1 sshd.8 sftp-server.8 sftp.1 ssh-rand-helper.8 ssh-keysign.8 sshd_config.5 ssh_config.5 Index: channels.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/channels.c,v retrieving revision 1.251 diff -u -p -r1.251 channels.c --- channels.c 28 Jan 2007 23:16:28 -0000 1.251 +++ channels.c 9 Apr 2007 09:05:35 -0000 @@ -1455,12 +1455,7 @@ channel_handle_rfd(Channel *c, fd_set *r if (len < 0 && (errno == EINTR || (errno == EAGAIN && !(c->isatty && c->detach_close)))) return 1; -#ifndef PTY_ZEROREAD - if (len <= 0) { -#else - if ((!c->isatty && len <= 0) || - (c->isatty && (len < 0 || (len == 0 && errno != 0)))) { -#endif + if (platform_rdrw_eof(len, c->isatty, errno)) { debug2("channel %d: read<=0 rfd %d len %d", c->self, c->rfd, len); if (c->type != SSH_CHANNEL_OPEN) { Index: platform.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/platform.c,v retrieving revision 1.1 diff -u -p -r1.1 platform.c --- platform.c 30 Aug 2006 17:24:41 -0000 1.1 +++ platform.c 9 Apr 2007 09:06:36 -0000 @@ -44,3 +44,15 @@ platform_post_fork_child(void) solaris_contract_post_fork_child(); #endif } + +int +platform_rdrw_eof(size_t len, int is_tty, int errno) +{ +#ifdef PTY_ZEROREAD + if (is_tty && len == 0 && errno == 0) + return 0; +#endif + if (len <= 0) + return 1; + return 0; +} Index: platform.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/platform.h,v retrieving revision 1.1 diff -u -p -r1.1 platform.h --- platform.h 30 Aug 2006 17:24:41 -0000 1.1 +++ platform.h 9 Apr 2007 09:05:35 -0000 @@ -21,3 +21,4 @@ void platform_pre_fork(void); void platform_post_fork_parent(pid_t child_pid); void platform_post_fork_child(void); +int platform_rdrw_eof(size_t, int, int); Index: serverloop.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/serverloop.c,v retrieving revision 1.151 diff -u -p -r1.151 serverloop.c --- serverloop.c 28 Jan 2007 23:16:28 -0000 1.151 +++ serverloop.c 9 Apr 2007 09:05:35 -0000 @@ -420,12 +420,7 @@ process_input(fd_set *readset) if (len < 0 && (errno == EINTR || (errno == EAGAIN && !child_terminated))) { /* do nothing */ -#ifndef PTY_ZEROREAD - } else if (len <= 0) { -#else - } else if ((!isatty(fdout) && len <= 0) || - (isatty(fdout) && (len < 0 || (len == 0 && errno != 0)))) { -#endif + } else if (platform_rdrw_eof(len, isatty(fderr), errno)) { fdout_eof = 1; } else { buffer_append(&stdout_buffer, buf, len); @@ -439,12 +434,7 @@ process_input(fd_set *readset) if (len < 0 && (errno == EINTR || (errno == EAGAIN && !child_terminated))) { /* do nothing */ -#ifndef PTY_ZEROREAD - } else if (len <= 0) { -#else - } else if ((!isatty(fderr) && len <= 0) || - (isatty(fderr) && (len < 0 || (len == 0 && errno != 0)))) { -#endif + } else if (platform_rdrw_eof(len, isatty(fderr), errno)) { fderr_eof = 1; } else { buffer_append(&stderr_buffer, buf, len); -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From tsi at ualberta.ca Tue Apr 10 04:07:18 2007 From: tsi at ualberta.ca (Marc Aurele La France) Date: Mon, 9 Apr 2007 12:07:18 -0600 (Mountain Daylight Time) Subject: 4.6p1 chan_read_failed error In-Reply-To: References: <46045AB6.6050903@lindy.stanford.edu> <20070324114902.GA8307@gate.dtucker.net> <46084BAF.2070601@lindy.stanford.edu> Message-ID: On Mon, 9 Apr 2007, Damien Miller wrote: > On Wed, 4 Apr 2007, Damien Miller wrote: >> Well, it also undoes the fix for bug #52. I think it is safe to simply hush >> the error message: > ugh, the logic in that patch was almost, but not completely, wrong. Please > try this one instead: It would also be a good idea to include errno in the debug2 message after a read(2) failure in channel_handle_rfd(). Doing so would make any future surprises in this area easier to diagnose. Marc. +----------------------------------+----------------------------------+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and | fax: 1-780-492-1729 | | Communications Technologies | email: tsi at ualberta.ca | | 352 General Services Building +----------------------------------+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply | | T6G 2H1 | | | CANADA | | +----------------------------------+----------------------------------+ XFree86 developer and VP. ATI driver and X server internals. From dtucker at zip.com.au Tue Apr 10 09:43:54 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 10 Apr 2007 09:43:54 +1000 Subject: Password enforcement problem with OpenSSH on AIX. In-Reply-To: <685543AEA172E549B33E9CB5601583A408AFC466@LM-EXMSG-05.lm.lmig.com> References: <685543AEA172E549B33E9CB5601583A408AFC466@LM-EXMSG-05.lm.lmig.com> Message-ID: <461ACFBA.403@zip.com.au> Texeira, Gerry wrote: > I've encountered a password enforcement problem with OpenSSH on AIX. In > AIX, when the user contains the flags = ADMCHG in the > /etc/security/passwd file, the user is forced to change the password at > next login. It works for telnet but it does not work under the OpenSSH > v3.4 version. Based on my research, it appears this issue is resolved > with OpenSSH v3.8p1. Can anyone confirm? Yes, support was added around that version, however it's only enforced when you actually use password authentication. If you're upgrading I would recommend the latest version, 4.6p1. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Tue Apr 10 11:57:58 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 10 Apr 2007 11:57:58 +1000 Subject: Error message after upgraing the openssh 4.6P1 In-Reply-To: <983771046C3CD8478025E73F533B25B9016526D0@HQOMAIL.dm.ae> References: <983771046C3CD8478025E73F533B25B9016526D0@HQOMAIL.dm.ae> Message-ID: <461AEF26.5090507@zip.com.au> ESQUIRE Sithesvaran wrote: > Hi Sandor, > > I see the below solution for this issue. When I execute the below > command, it is not giving command prompt after wards, it just keep > running. Let me know which patch it reverts, what it does? > >>> I suspect this is related to the change for bug #52. You could try >>> reverting the following patch ("patch -p1 -R") and see if the error >>> messages stop. >> Yes, that eliminates the chan_read_failed error messages. You need to feed the patch file into patch's standard input. If you're using a mailer such as mutt you can just pipe it ("| patch -p1 -R"), however if you save the patch to a file you need to do redirect it in, eg "patch -p1 -R References: <46045AB6.6050903@lindy.stanford.edu> <20070324114902.GA8307@gate.dtucker.net> <46084BAF.2070601@lindy.stanford.edu> Message-ID: <461AFD09.5080800@zip.com.au> Marc Aurele La France wrote: > On Mon, 9 Apr 2007, Damien Miller wrote: > >> ugh, the logic in that patch was almost, but not completely, wrong. Please >> try this one instead: > > It would also be a good idea to include errno in the debug2 message after a > read(2) failure in channel_handle_rfd(). Doing so would make any future > surprises in this area easier to diagnose. Since there's a couple of mail threads for this problem now, I have opened a bug for this and attached a new patch that seems to suppress the error for me on Solaris 8, and also puts the errno in the error message (but not the debug2). I suggest that anyone interested in this problem add themselves to the cc: list on the bug and follow up there. http://bugzilla.mindrot.org/show_bug.cgi?id=1306 Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From ESQUIRE_SITHESVARAN at dm.gov.ae Tue Apr 10 14:01:50 2007 From: ESQUIRE_SITHESVARAN at dm.gov.ae (ESQUIRE Sithesvaran) Date: Tue, 10 Apr 2007 08:01:50 +0400 Subject: Error message after upgraing the openssh 4.6P1 Message-ID: <983771046C3CD8478025E73F533B25B90165277A@HQOMAIL.dm.ae> Hi Darren, Thanks for your response. But really I don't understand you are talking about which patch file. Can you please explain me in detail? Thanks, Sithesvaran. -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Tuesday, April 10, 2007 5:58 AM To: ESQUIRE Sithesvaran Cc: OpenSSH Devel List Subject: Re: Error message after upgraing the openssh 4.6P1 ESQUIRE Sithesvaran wrote: > Hi Sandor, > > I see the below solution for this issue. When I execute the below > command, it is not giving command prompt after wards, it just keep > running. Let me know which patch it reverts, what it does? > >>> I suspect this is related to the change for bug #52. You could try >>> reverting the following patch ("patch -p1 -R") and see if the error >>> messages stop. >> Yes, that eliminates the chan_read_failed error messages. You need to feed the patch file into patch's standard input. If you're using a mailer such as mutt you can just pipe it ("| patch -p1 -R"), however if you save the patch to a file you need to do redirect it in, eg "patch -p1 -R References: <983771046C3CD8478025E73F533B25B90165277A@HQOMAIL.dm.ae> Message-ID: <461B0E22.3010105@zip.com.au> ESQUIRE Sithesvaran wrote: > Thanks for your response. But really I don't understand you are talking > about which patch file. Can you please explain me in detail? What you needed to do was to save the message as a text file, eg called "patchfile", then run the patch command. You can download a newer version of the patch from the bugzilla bug: http://bugzilla.mindrot.org/attachment.cgi?id=1260 Save it to a file called "patchfile" in /tmp, then change to the unpacked openssh-4.6p1 directory and run "patch -p0 Is it final fix or it is just workaround? Because I need to implement it in PROD environment. -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Tuesday, April 10, 2007 5:58 AM To: ESQUIRE Sithesvaran Cc: OpenSSH Devel List Subject: Re: Error message after upgraing the openssh 4.6P1 ESQUIRE Sithesvaran wrote: > Hi Sandor, > > I see the below solution for this issue. When I execute the below > command, it is not giving command prompt after wards, it just keep > running. Let me know which patch it reverts, what it does? > >>> I suspect this is related to the change for bug #52. You could try >>> reverting the following patch ("patch -p1 -R") and see if the error >>> messages stop. >> Yes, that eliminates the chan_read_failed error messages. You need to feed the patch file into patch's standard input. If you're using a mailer such as mutt you can just pipe it ("| patch -p1 -R"), however if you save the patch to a file you need to do redirect it in, eg "patch -p1 -R References: <983771046C3CD8478025E73F533B25B901652804@HQOMAIL.dm.ae> Message-ID: <20070410092219.GA24736@gate.dtucker.net> On Tue, Apr 10, 2007 at 12:45:46PM +0400, ESQUIRE Sithesvaran wrote: > Is it final fix or it is just workaround? Because I need to implement it > in PROD environment. I would consider the patch in the previous mail to be experimental. For production use , the safest thing to do would be to revert the change. The attached patch is against 4.6p1 and does that. To use, save the attachment to /tmp, change to a freshly unpacked openssh-4.6p1 directory, do "patch -p0 rfd != -1 && - (c->detach_close || FD_ISSET(c->rfd, readset))) { + FD_ISSET(c->rfd, readset)) { errno = 0; len = read(c->rfd, buf, sizeof(buf)); - if (len < 0 && (errno == EINTR || - (errno == EAGAIN && !(c->isatty && c->detach_close)))) + if (len < 0 && (errno == EINTR || errno == EAGAIN)) return 1; #ifndef PTY_ZEROREAD if (len <= 0) { @@ -1605,12 +1604,11 @@ channel_handle_efd(Channel *c, fd_set *r c->local_consumed += len; } } else if (c->extended_usage == CHAN_EXTENDED_READ && - (c->detach_close || FD_ISSET(c->efd, readset))) { + FD_ISSET(c->efd, readset)) { len = read(c->efd, buf, sizeof(buf)); debug2("channel %d: read %d from efd %d", c->self, len, c->efd); - if (len < 0 && (errno == EINTR || - (errno == EAGAIN && !c->detach_close))) + if (len < 0 && (errno == EINTR || errno == EAGAIN)) return 1; if (len <= 0) { debug2("channel %d: closing read-efd %d", Index: serverloop.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/serverloop.c,v retrieving revision 1.151 diff -u -p -r1.151 serverloop.c --- serverloop.c 28 Jan 2007 23:16:28 -0000 1.151 +++ serverloop.c 10 Apr 2007 08:58:39 -0000 @@ -280,7 +280,6 @@ wait_until_can_do_something(fd_set **rea struct timeval tv, *tvp; int ret; int client_alive_scheduled = 0; - int program_alive_scheduled = 0; /* * if using client_alive, set the max timeout accordingly, @@ -318,7 +317,6 @@ wait_until_can_do_something(fd_set **rea * the client, try to get some more data from the program. */ if (packet_not_very_much_data_to_write()) { - program_alive_scheduled = child_terminated; if (!fdout_eof) FD_SET(fdout, *readsetp); if (!fderr_eof) @@ -364,16 +362,8 @@ wait_until_can_do_something(fd_set **rea memset(*writesetp, 0, *nallocp); if (errno != EINTR) error("select: %.100s", strerror(errno)); - } else { - if (ret == 0 && client_alive_scheduled) - client_alive_check(); - if (!compat20 && program_alive_scheduled && fdin_is_tty) { - if (!fdout_eof) - FD_SET(fdout, *readsetp); - if (!fderr_eof) - FD_SET(fderr, *readsetp); - } - } + } else if (ret == 0 && client_alive_scheduled) + client_alive_check(); notify_done(*readsetp); } @@ -417,8 +407,7 @@ process_input(fd_set *readset) if (!fdout_eof && FD_ISSET(fdout, readset)) { errno = 0; len = read(fdout, buf, sizeof(buf)); - if (len < 0 && (errno == EINTR || - (errno == EAGAIN && !child_terminated))) { + if (len < 0 && (errno == EINTR || errno == EAGAIN)) { /* do nothing */ #ifndef PTY_ZEROREAD } else if (len <= 0) { @@ -436,8 +425,7 @@ process_input(fd_set *readset) if (!fderr_eof && FD_ISSET(fderr, readset)) { errno = 0; len = read(fderr, buf, sizeof(buf)); - if (len < 0 && (errno == EINTR || - (errno == EAGAIN && !child_terminated))) { + if (len < 0 && (errno == EINTR || errno == EAGAIN)) { /* do nothing */ #ifndef PTY_ZEROREAD } else if (len <= 0) { From ESQUIRE_SITHESVARAN at dm.gov.ae Tue Apr 10 19:27:47 2007 From: ESQUIRE_SITHESVARAN at dm.gov.ae (ESQUIRE Sithesvaran) Date: Tue, 10 Apr 2007 13:27:47 +0400 Subject: Error message after upgraing the openssh 4.6P1 Message-ID: <983771046C3CD8478025E73F533B25B901652818@HQOMAIL.dm.ae> Shall I use this attached patch for production? -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Tuesday, April 10, 2007 1:22 PM To: ESQUIRE Sithesvaran Cc: OpenSSH Devel List Subject: Re: Error message after upgraing the openssh 4.6P1 On Tue, Apr 10, 2007 at 12:45:46PM +0400, ESQUIRE Sithesvaran wrote: > Is it final fix or it is just workaround? Because I need to implement it > in PROD environment. I would consider the patch in the previous mail to be experimental. For production use , the safest thing to do would be to revert the change. The attached patch is against 4.6p1 and does that. To use, save the attachment to /tmp, change to a freshly unpacked openssh-4.6p1 directory, do "patch -p0 References: <983771046C3CD8478025E73F533B25B901652818@HQOMAIL.dm.ae> Message-ID: <461B59BA.8070409@zip.com.au> ESQUIRE Sithesvaran wrote: > Shall I use this attached patch for production? Yes, unless the hang-on-exit bug (#52) is/was a killer for you. If 4.5 and below worked for you then the safest thing to do at this time is apply the patch in my previous mail (openssh-4.6p1-chan_read_failed.patch). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From ESQUIRE_SITHESVARAN at dm.gov.ae Tue Apr 10 19:42:51 2007 From: ESQUIRE_SITHESVARAN at dm.gov.ae (ESQUIRE Sithesvaran) Date: Tue, 10 Apr 2007 13:42:51 +0400 Subject: Error message after upgraing the openssh 4.6P1 Message-ID: <983771046C3CD8478025E73F533B25B90165281D@HQOMAIL.dm.ae> Yes. We were using openssh 3.5P1 and it was working fine without any issue. So for my servers, it is better to apply the patch u have given in your previous mail. -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Tuesday, April 10, 2007 1:33 PM To: ESQUIRE Sithesvaran Cc: OpenSSH Devel List Subject: Re: Error message after upgraing the openssh 4.6P1 ESQUIRE Sithesvaran wrote: > Shall I use this attached patch for production? Yes, unless the hang-on-exit bug (#52) is/was a killer for you. If 4.5 and below worked for you then the safest thing to do at this time is apply the patch in my previous mail (openssh-4.6p1-chan_read_failed.patch). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. Our Vision To create an excellent city that provides the essence of success and comfort of living. Disclaimer: This Electronic Mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not an addressee, or have received the message by error, please notify the sender via E-Mail or over the telephone and delete this e-mail. You are not authorized to read, copy, disseminate, distribute or use this E-Mail or any of its attachment in any way. Any views or opinions presented in this email are solely those of the author and do not necessarily represent Dubai Municipality. The recipient should check this email and any attachments for the presence of viruses/worms. Dubai Municipality accepts no liability for any damage caused by any virus/worms transmitted by this email. Dubai Municipality, Dubai, UAE, http://www.dm.gov.ae/ From ldv at altlinux.org Wed Apr 11 09:39:55 2007 From: ldv at altlinux.org (Dmitry V. Levin) Date: Wed, 11 Apr 2007 03:39:55 +0400 Subject: [PATCH 3/6] auth-pam.c: Replace malloc+memset with calloc In-Reply-To: <20070410233107.GA4984@nomad.office.altlinux.org> References: <20070410233107.GA4984@nomad.office.altlinux.org> Message-ID: <20070410233955.GC5171@nomad.office.altlinux.org> --- openssh/auth-pam.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) --- a/openssh/auth-pam.c +++ b/openssh/auth-pam.c @@ -686,8 +686,7 @@ sshpam_init_ctx(Authctxt *authctxt) return (NULL); } - ctxt = xmalloc(sizeof *ctxt); - memset(ctxt, 0, sizeof(*ctxt)); + ctxt = xcalloc(1, sizeof *ctxt); /* Start the authentication thread */ if (socketpair(AF_UNIX, SOCK_STREAM, PF_UNSPEC, socks) == -1) { @@ -1131,9 +1130,8 @@ sshpam_passwd_conv(int n, sshpam_const struct pam_message **msg, if (n <= 0 || n > PAM_MAX_NUM_MSG) return (PAM_CONV_ERR); - if ((reply = malloc(n * sizeof(*reply))) == NULL) + if ((reply = calloc(n, sizeof(*reply))) == NULL) return (PAM_CONV_ERR); - memset(reply, 0, n * sizeof(*reply)); for (i = 0; i < n; ++i) { switch (PAM_MSG_MEMBER(msg, i, msg_style)) { -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070411/d34ef7b6/attachment.bin From ldv at altlinux.org Wed Apr 11 09:39:34 2007 From: ldv at altlinux.org (Dmitry V. Levin) Date: Wed, 11 Apr 2007 03:39:34 +0400 Subject: [PATCH 2/6] auth-pam.c (sshpam_tty_conv): Check fgets() return code In-Reply-To: <20070410233107.GA4984@nomad.office.altlinux.org> References: <20070410233107.GA4984@nomad.office.altlinux.org> Message-ID: <20070410233934.GB5171@nomad.office.altlinux.org> --- openssh/auth-pam.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) --- a/openssh/auth-pam.c +++ b/openssh/auth-pam.c @@ -985,7 +985,8 @@ sshpam_tty_conv(int n, sshpam_const struct pam_message **msg, break; case PAM_PROMPT_ECHO_ON: fprintf(stderr, "%s\n", PAM_MSG_MEMBER(msg, i, msg)); - fgets(input, sizeof input, stdin); + if (fgets(input, sizeof input, stdin) == NULL) + input[0] = '\0'; if ((reply[i].resp = strdup(input)) == NULL) goto fail; reply[i].resp_retcode = PAM_SUCCESS; -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070411/4e1a92ff/attachment.bin From ldv at altlinux.org Wed Apr 11 09:39:25 2007 From: ldv at altlinux.org (Dmitry V. Levin) Date: Wed, 11 Apr 2007 03:39:25 +0400 Subject: [PATCH 1/6] auth2.c (DELIM): Remove unused macro In-Reply-To: <20070410233107.GA4984@nomad.office.altlinux.org> References: <20070410233107.GA4984@nomad.office.altlinux.org> Message-ID: <20070410233925.GA5171@nomad.office.altlinux.org> --- openssh/auth2.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) --- a/openssh/auth2.c +++ b/openssh/auth2.c @@ -281,8 +281,6 @@ userauth_finish(Authctxt *authctxt, int authenticated, char *method) } } -#define DELIM "," - static char * authmethods_get(void) { -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070411/2a3e7e80/attachment-0001.bin From ldv at altlinux.org Wed Apr 11 09:40:09 2007 From: ldv at altlinux.org (Dmitry V. Levin) Date: Wed, 11 Apr 2007 03:40:09 +0400 Subject: [PATCH 4/6] Fix pointer arithmetics to avoid breaking gcc strict-aliasing rules In-Reply-To: <20070410233107.GA4984@nomad.office.altlinux.org> References: <20070410233107.GA4984@nomad.office.altlinux.org> Message-ID: <20070410234009.GD5171@nomad.office.altlinux.org> --- openssh/readconf.c | 7 ++++--- openssh/servconf.c | 14 ++++++++------ 2 files changed, 12 insertions(+), 9 deletions(-) --- a/openssh/readconf.c +++ b/openssh/readconf.c @@ -326,6 +326,7 @@ process_config_line(Options *options, const char *host, { char *s, **charptr, *endofnumber, *keyword, *arg, *arg2, fwdarg[256]; int opcode, *intptr, value, value2, scale; + LogLevel *log_level_ptr; long long orig, val64; size_t len; Forward fwd; @@ -692,14 +693,14 @@ parse_int: break; case oLogLevel: - intptr = (int *) &options->log_level; + log_level_ptr = &options->log_level; arg = strdelim(&s); value = log_level_number(arg); if (value == SYSLOG_LEVEL_NOT_SET) fatal("%.200s line %d: unsupported log level '%s'", filename, linenum, arg ? arg : ""); - if (*activep && (LogLevel) *intptr == SYSLOG_LEVEL_NOT_SET) - *intptr = (LogLevel) value; + if (*activep && *log_level_ptr == SYSLOG_LEVEL_NOT_SET) + *log_level_ptr = (LogLevel) value; break; case oLocalForward: --- a/openssh/servconf.c +++ b/openssh/servconf.c @@ -622,6 +622,8 @@ process_server_config_line(ServerOptions *options, char *line, { char *cp, **charptr, *arg, *p; int cmdline = 0, *intptr, value, n; + SyslogFacility *log_facility_ptr; + LogLevel *log_level_ptr; ServerOpCodes opcode; u_short port; u_int i, flags = 0; @@ -977,25 +979,25 @@ parse_flag: goto parse_flag; case sLogFacility: - intptr = (int *) &options->log_facility; + log_facility_ptr = &options->log_facility; arg = strdelim(&cp); value = log_facility_number(arg); if (value == SYSLOG_FACILITY_NOT_SET) fatal("%.200s line %d: unsupported log facility '%s'", filename, linenum, arg ? arg : ""); - if (*intptr == -1) - *intptr = (SyslogFacility) value; + if (*log_facility_ptr == -1) + *log_facility_ptr = (SyslogFacility) value; break; case sLogLevel: - intptr = (int *) &options->log_level; + log_level_ptr = &options->log_level; arg = strdelim(&cp); value = log_level_number(arg); if (value == SYSLOG_LEVEL_NOT_SET) fatal("%.200s line %d: unsupported log level '%s'", filename, linenum, arg ? arg : ""); - if (*intptr == -1) - *intptr = (LogLevel) value; + if (*log_level_ptr == -1) + *log_level_ptr = (LogLevel) value; break; case sAllowTcpForwarding: -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070411/5175dde9/attachment-0001.bin From ldv at altlinux.org Wed Apr 11 09:40:18 2007 From: ldv at altlinux.org (Dmitry V. Levin) Date: Wed, 11 Apr 2007 03:40:18 +0400 Subject: [PATCH 5/6] Fix "format '%llu' expects type 'long long unsigned int'" warnings In-Reply-To: <20070410233107.GA4984@nomad.office.altlinux.org> References: <20070410233107.GA4984@nomad.office.altlinux.org> Message-ID: <20070410234018.GE5171@nomad.office.altlinux.org> --- openssh/sftp-server.c | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-) --- a/openssh/sftp-server.c +++ b/openssh/sftp-server.c @@ -319,7 +319,8 @@ handle_log_close(int handle, char *emsg) logit("%s%sclose \"%s\" bytes read %llu written %llu", emsg == NULL ? "" : emsg, emsg == NULL ? "" : " ", handle_to_name(handle), - handle_bytes_read(handle), handle_bytes_write(handle)); + (unsigned long long) handle_bytes_read(handle), + (unsigned long long) handle_bytes_write(handle)); } else { logit("%s%sclosedir \"%s\"", emsg == NULL ? "" : emsg, emsg == NULL ? "" : " ", @@ -702,7 +703,8 @@ process_setstat(void) a = get_attrib(); debug("request %u: setstat name \"%s\"", id, name); if (a->flags & SSH2_FILEXFER_ATTR_SIZE) { - logit("set \"%s\" size %llu", name, a->size); + logit("set \"%s\" size %llu", + name, (unsigned long long) a->size); ret = truncate(name, a->size); if (ret == -1) status = errno_to_portable(errno); @@ -754,7 +756,8 @@ process_fsetstat(void) char *name = handle_to_name(handle); if (a->flags & SSH2_FILEXFER_ATTR_SIZE) { - logit("set \"%s\" size %llu", name, a->size); + logit("set \"%s\" size %llu", + name, (unsigned long long) a->size); ret = ftruncate(fd, a->size); if (ret == -1) status = errno_to_portable(errno); -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070411/568ca93b/attachment.bin From ldv at altlinux.org Wed Apr 11 09:40:26 2007 From: ldv at altlinux.org (Dmitry V. Levin) Date: Wed, 11 Apr 2007 03:40:26 +0400 Subject: [PATCH 6/6] sshd.c (main): Clear rexec_flag in test mode In-Reply-To: <20070410233107.GA4984@nomad.office.altlinux.org> References: <20070410233107.GA4984@nomad.office.altlinux.org> Message-ID: <20070410234026.GF5171@nomad.office.altlinux.org> --- openssh/sshd.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) --- a/openssh/sshd.c +++ b/openssh/sshd.c @@ -1365,7 +1365,7 @@ main(int ac, char **av) break; } } - if (rexeced_flag || inetd_flag) + if (rexeced_flag || inetd_flag || test_flag) rexec_flag = 0; if (rexec_flag && (av[0] == NULL || *av[0] != '/')) fatal("sshd re-exec requires execution with an absolute path"); -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070411/1f48eaf0/attachment.bin From ldv at altlinux.org Wed Apr 11 09:31:07 2007 From: ldv at altlinux.org (Dmitry V. Levin) Date: Wed, 11 Apr 2007 03:31:07 +0400 Subject: [PATCH 0/6] openssh V_4_6: minor fixes/cleanups Message-ID: <20070410233107.GA4984@nomad.office.altlinux.org> This patch series consists of minor fixes and cleanups I made during update to openssh V_4_6 branch. openssh/auth-pam.c | 9 ++++----- openssh/auth2.c | 2 -- openssh/readconf.c | 7 ++++--- openssh/servconf.c | 14 ++++++++------ openssh/sftp-server.c | 9 ++++++--- openssh/sshd.c | 2 +- 6 files changed, 23 insertions(+), 20 deletions(-) -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070411/4412560c/attachment.bin From ESQUIRE_SITHESVARAN at dm.gov.ae Wed Apr 11 20:23:54 2007 From: ESQUIRE_SITHESVARAN at dm.gov.ae (ESQUIRE Sithesvaran) Date: Wed, 11 Apr 2007 14:23:54 +0400 Subject: Error message after upgraing the openssh 4.6P1 Message-ID: <983771046C3CD8478025E73F533B25B9016528EC@HQOMAIL.dm.ae> Hi Darren, I executed as per your below mail, it is asking for File to Patch: please let me know what I need to give there. Here is the screen shot. Please let me know if I am wrong anywhere. bexml20: /root/ssh_latest_packages#ls 112438-03 openssh-4.6p1-sol8-sparc-local 112438-03.zip openssl-0.9.8e-sol8-sparc-local libgcc-3.4.6-sol8-sparc-local zlib-1.2.3-sol8-sparc-local bexml20: /root/ssh_latest_packages#ls /tmp/open* /tmp/openssh-4.6p1-chan_read_failed.patch bexml20: /root/ssh_latest_packages#patch -p0 Is it final fix or it is just workaround? Because I need to implement it > in PROD environment. I would consider the patch in the previous mail to be experimental. For production use , the safest thing to do would be to revert the change. The attached patch is against 4.6p1 and does that. To use, save the attachment to /tmp, change to a freshly unpacked openssh-4.6p1 directory, do "patch -p0 References: <983771046C3CD8478025E73F533B25B9016528EC@HQOMAIL.dm.ae> Message-ID: <461CBA18.2030108@zip.com.au> ESQUIRE Sithesvaran wrote: > I executed as per your below mail, it is asking for File to Patch: > please let me know what I need to give there. Here is the screen shot. > Please let me know if I am wrong anywhere. Those look like binary packages from sunfreeware or similar, and you can't patch those. You need to either build from the source[1] or ask whoever built your packages to apply the patch and rebuild. [1] eg from ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/ -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From ESQUIRE_SITHESVARAN at dm.gov.ae Thu Apr 12 18:05:25 2007 From: ESQUIRE_SITHESVARAN at dm.gov.ae (ESQUIRE Sithesvaran) Date: Thu, 12 Apr 2007 12:05:25 +0400 Subject: Error message after upgraing the openssh 4.6P1 Message-ID: <983771046C3CD8478025E73F533B25B9016529A0@HQOMAIL.dm.ae> Yes. I got it from Sun Freeware. Is there any fix for these packages? Or should I use only source files and build. Then why they have kept these packages for downloading? Thanks, -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Wednesday, April 11, 2007 2:36 PM To: ESQUIRE Sithesvaran Cc: OpenSSH Devel List Subject: Re: Error message after upgraing the openssh 4.6P1 ESQUIRE Sithesvaran wrote: > I executed as per your below mail, it is asking for File to Patch: > please let me know what I need to give there. Here is the screen shot. > Please let me know if I am wrong anywhere. Those look like binary packages from sunfreeware or similar, and you can't patch those. You need to either build from the source[1] or ask whoever built your packages to apply the patch and rebuild. [1] eg from ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/ -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement Our Vision To create an excellent city that provides the essence of success and comfort of living. Disclaimer: This Electronic Mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not an addressee, or have received the message by error, please notify the sender via E-Mail or over the telephone and delete this e-mail. You are not authorized to read, copy, disseminate, distribute or use this E-Mail or any of its attachment in any way. Any views or opinions presented in this email are solely those of the author and do not necessarily represent Dubai Municipality. The recipient should check this email and any attachments for the presence of viruses/worms. Dubai Municipality accepts no liability for any damage caused by any virus/worms transmitted by this email. Dubai Municipality, Dubai, UAE, http://www.dm.gov.ae/ From dtucker at zip.com.au Thu Apr 12 19:37:47 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 12 Apr 2007 19:37:47 +1000 Subject: Error message after upgraing the openssh 4.6P1 In-Reply-To: <983771046C3CD8478025E73F533B25B9016529A0@HQOMAIL.dm.ae> References: <983771046C3CD8478025E73F533B25B9016529A0@HQOMAIL.dm.ae> Message-ID: <461DFDEB.6000105@zip.com.au> ESQUIRE Sithesvaran wrote: > Yes. I got it from Sun Freeware. Is there any fix for these packages? I don't know, you would have to ask them. > Or should I use only source files and build. The patch that I sent is a source patch so in order to use it you (or someone else) needs to apply it to a source tree and compile the result. > Then why they have kept these packages for downloading? Again, you would have to ask them. Have you contacted them? They may not even be aware of it. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From thomas at ohzone.de Sat Apr 14 17:17:32 2007 From: thomas at ohzone.de (Thomas Blank) Date: Sat, 14 Apr 2007 09:17:32 +0200 Subject: HiddenStore option may be useful Message-ID: <4620800C.3000000@ohzone.de> I'm missing a HiddenStore option in OpenSSH, known from some ftp-server implementations like ProFTPd. Consider the following scenario: - A process PROCA is frequently polling the directory for a file called myfile.txt - Someone transfers this file via sftp or scp to the directory - While transfer is going on and the file is not completely written, PROCA reads in the file and removes is -> Corrupt data is seen by PROCA Knowing this problem you have to solutions: 1. PROCA must check if myfile.txt is changing (filesize, mtime...) and wait until it does not change any more 2. sftp and scp use a HiddenStore by writing the file with a unique filename (eg. .myfile.txt) and renaming it at the end of the transfer (mv .myfile.txt myfile.txt) What do you think about this? Thomas From openssh at lakedaemon.net Sun Apr 15 12:54:43 2007 From: openssh at lakedaemon.net (Jason) Date: Sat, 14 Apr 2007 22:54:43 -0400 Subject: HiddenStore option may be useful In-Reply-To: <4620800C.3000000@ohzone.de> References: <4620800C.3000000@ohzone.de> Message-ID: <462193F3.1010600@lakedaemon.net> Thomas Blank wrote: > I'm missing a HiddenStore option in OpenSSH, known from some ftp-server > implementations like ProFTPd. > > Consider the following scenario: > - A process PROCA is frequently polling the directory for a file called > myfile.txt > - Someone transfers this file via sftp or scp to the directory > - While transfer is going on and the file is not completely written, > PROCA reads in the file and removes is > -> Corrupt data is seen by PROCA > > Knowing this problem you have to solutions: > 1. PROCA must check if myfile.txt is changing (filesize, mtime...) and > wait until it does not change any more > 2. sftp and scp use a HiddenStore by writing the file with a unique > filename (eg. .myfile.txt) and renaming it at the end of the transfer > (mv .myfile.txt myfile.txt) > > What do you think about this? Why not have PROCA use inotify? See /usr/src/linux/Documentation/filesystems/inotify.txt hth, Jason. From william at 25thandClement.com Sun Apr 15 14:18:18 2007 From: william at 25thandClement.com (William Ahern) Date: Sat, 14 Apr 2007 21:18:18 -0700 Subject: HiddenStore option may be useful In-Reply-To: <462193F3.1010600@lakedaemon.net> References: <4620800C.3000000@ohzone.de> <462193F3.1010600@lakedaemon.net> Message-ID: <20070415041818.GA25270@wilbur.25thandClement.com> On Sat, Apr 14, 2007 at 10:54:43PM -0400, Jason wrote: > Thomas Blank wrote: > > I'm missing a HiddenStore option in OpenSSH, known from some ftp-server > > implementations like ProFTPd. > > > > Consider the following scenario: > > - A process PROCA is frequently polling the directory for a file called > > myfile.txt > > - Someone transfers this file via sftp or scp to the directory > > - While transfer is going on and the file is not completely written, > > PROCA reads in the file and removes is > > -> Corrupt data is seen by PROCA > > > > Knowing this problem you have to solutions: > > 1. PROCA must check if myfile.txt is changing (filesize, mtime...) and > > wait until it does not change any more > > 2. sftp and scp use a HiddenStore by writing the file with a unique > > filename (eg. .myfile.txt) and renaming it at the end of the transfer > > (mv .myfile.txt myfile.txt) > > > > What do you think about this? > > Why not have PROCA use inotify? > > See /usr/src/linux/Documentation/filesystems/inotify.txt > How does that address the race condition? inotify is just a better poll in this case. It doesn't even tell you how many processes have an open descriptor. Excluding OpenSSH modifications, the following might work: 1) Poll for new files (stat + sleep or dnotify or inotify or FAM or kqueue). 2) Open the file 3) unlink(2) the file 3) ?? Track the number of open file descriptors on the file and wait till it drops to 1 (just you). I don't know how to do this. 4) Process the file however you want, i.e. by copying the data to another file elsewhere. The downside here is that you may accidentally unlink the wrong file, if a new one was created in its place after open(2) and before unlink(2). Ideally, inotify or kqueue would return to you a file descriptor, rather than a simple path [component]. And the gods would somehow bestow the Unix API w/ a funlink(2) system call, which would magically remove filesystem references to the file (or maybe atomically unlink a fd/path pair, failing if the relationship doesn't exist). Then in conjunction w/ the wait for others to lose their reference, you'd have a solid solution where you are assured to hold a reference to a finalized version of the file. Alas, none of this exists. The only real answer, in this case, for race free, provably correct behavior, is to hack up sftp. OTOH, if "good enough" is sufficient, you're probably already there. From dkg-openssh.com at fifthhorseman.net Sun Apr 15 14:05:46 2007 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 15 Apr 2007 00:05:46 -0400 Subject: HiddenStore option may be useful In-Reply-To: <462193F3.1010600@lakedaemon.net> (openssh@lakedaemon.net's message of "Sat, 14 Apr 2007 22:54:43 -0400") References: <4620800C.3000000@ohzone.de> <462193F3.1010600@lakedaemon.net> Message-ID: <87zm5az3hh.fsf@squeak.fifthhorseman.net> On Sat 2007-04-14 22:54:43 -0400, Jason wrote: > Why not have PROCA use inotify? > > See /usr/src/linux/Documentation/filesystems/inotify.txt It's possible that Thomas Blank is not using Linux. Has inotify been ported to other kernels? --dkg From Jefferson.Ogata at noaa.gov Sun Apr 15 17:20:29 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Sun, 15 Apr 2007 07:20:29 +0000 Subject: HiddenStore option may be useful In-Reply-To: <20070415041818.GA25270@wilbur.25thandClement.com> References: <4620800C.3000000@ohzone.de> <462193F3.1010600@lakedaemon.net> <20070415041818.GA25270@wilbur.25thandClement.com> Message-ID: <4621D23D.4020306@noaa.gov> On 2007-04-15 04:18, William Ahern wrote: > On Sat, Apr 14, 2007 at 10:54:43PM -0400, Jason wrote: >> Thomas Blank wrote: >>> I'm missing a HiddenStore option in OpenSSH, known from some ftp-server >>> implementations like ProFTPd. >>> >>> Consider the following scenario: >>> - A process PROCA is frequently polling the directory for a file called >>> myfile.txt >>> - Someone transfers this file via sftp or scp to the directory >>> - While transfer is going on and the file is not completely written, >>> PROCA reads in the file and removes is >>> -> Corrupt data is seen by PROCA >>> >>> Knowing this problem you have to solutions: >>> 1. PROCA must check if myfile.txt is changing (filesize, mtime...) and >>> wait until it does not change any more >>> 2. sftp and scp use a HiddenStore by writing the file with a unique >>> filename (eg. .myfile.txt) and renaming it at the end of the transfer >>> (mv .myfile.txt myfile.txt) >>> >>> What do you think about this? >> Why not have PROCA use inotify? >> >> See /usr/src/linux/Documentation/filesystems/inotify.txt > > How does that address the race condition? inotify is just a better poll in > this case. It doesn't even tell you how many processes have an open > descriptor. [snip] > The only real answer, in this case, for race free, provably correct > behavior, is to hack up sftp. OTOH, if "good enough" is sufficient, you're > probably already there. Most systems have fuser. PROCA could either shell out to fuser or do whatever fuser does on your target platform. This doesn't protect you if the sftp/scp gets killed, but it comes closer. An even better option is to do the transfer using tunneled rsync, which does a HiddenStore-type thing on its own. Not that I'm against the HiddenStore option. But I don't see why it's really necessary for this particular case. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From openssh at lakedaemon.net Mon Apr 16 02:01:07 2007 From: openssh at lakedaemon.net (Jason) Date: Sun, 15 Apr 2007 12:01:07 -0400 Subject: HiddenStore option may be useful In-Reply-To: <20070415041818.GA25270@wilbur.25thandClement.com> References: <4620800C.3000000@ohzone.de> <462193F3.1010600@lakedaemon.net> <20070415041818.GA25270@wilbur.25thandClement.com> Message-ID: <46224C43.6040702@lakedaemon.net> William Ahern wrote: > On Sat, Apr 14, 2007 at 10:54:43PM -0400, Jason wrote: >> Thomas Blank wrote: >>> I'm missing a HiddenStore option in OpenSSH, known from some ftp-server >>> implementations like ProFTPd. >>> >>> Consider the following scenario: >>> - A process PROCA is frequently polling the directory for a file called >>> myfile.txt >>> - Someone transfers this file via sftp or scp to the directory >>> - While transfer is going on and the file is not completely written, >>> PROCA reads in the file and removes is >>> -> Corrupt data is seen by PROCA >>> >>> Knowing this problem you have to solutions: >>> 1. PROCA must check if myfile.txt is changing (filesize, mtime...) and >>> wait until it does not change any more >>> 2. sftp and scp use a HiddenStore by writing the file with a unique >>> filename (eg. .myfile.txt) and renaming it at the end of the transfer >>> (mv .myfile.txt myfile.txt) >>> >>> What do you think about this? >> Why not have PROCA use inotify? >> >> See /usr/src/linux/Documentation/filesystems/inotify.txt >> > > How does that address the race condition? inotify is just a better poll in > this case. It doesn't even tell you how many processes have an open > descriptor. Given that PROCA is there before the file is created, inotify allows you to detect when a new file is created (IN_CREATE), opened (IN_OPEN), and how many times that occurred. Once PROCA receives enough file close events (IN_CLOSE) to match the create and all the opens (if they occurred), then it can consider the file transfer is finished and pull it out of the directory. On a technical note, inotify is _not_ a better poll, rather it is interrupt driven (select() on file descriptor created by inotify_init()). hth, Jason. From dtucker at zip.com.au Mon Apr 16 07:45:48 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 16 Apr 2007 07:45:48 +1000 Subject: HiddenStore option may be useful In-Reply-To: <4620800C.3000000@ohzone.de> References: <4620800C.3000000@ohzone.de> Message-ID: <46229D0C.8090406@zip.com.au> Thomas Blank wrote: > I'm missing a HiddenStore option in OpenSSH, known from some ftp-server > implementations like ProFTPd. > > Consider the following scenario: > - A process PROCA is frequently polling the directory for a file called > myfile.txt > - Someone transfers this file via sftp or scp to the directory > - While transfer is going on and the file is not completely written, > PROCA reads in the file and removes is > -> Corrupt data is seen by PROCA > > Knowing this problem you have to solutions: > 1. PROCA must check if myfile.txt is changing (filesize, mtime...) and > wait until it does not change any more > 2. sftp and scp use a HiddenStore by writing the file with a unique > filename (eg. .myfile.txt) and renaming it at the end of the transfer > (mv .myfile.txt myfile.txt) Do you have control over the clients? If so: 3. Use sftp to upload the file with a temporary name then rename it when it's complete. Something like this (untested): sftp -b /dev/stdin server.example.com << EOD put myfile.txt .myfile.txt rename .myfile.txt myfile.txt EOD -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From william at 25thandClement.com Mon Apr 16 07:59:44 2007 From: william at 25thandClement.com (William Ahern) Date: Sun, 15 Apr 2007 14:59:44 -0700 Subject: HiddenStore option may be useful In-Reply-To: <46229D0C.8090406@zip.com.au> References: <4620800C.3000000@ohzone.de> <46229D0C.8090406@zip.com.au> Message-ID: <20070415215944.GA18731@wilbur.25thandClement.com> On Mon, Apr 16, 2007 at 07:45:48AM +1000, Darren Tucker wrote: > Do you have control over the clients? If so: > > 3. Use sftp to upload the file with a temporary name then rename it when > it's complete. Something like this (untested): > > sftp -b /dev/stdin server.example.com << EOD > put myfile.txt .myfile.txt > rename .myfile.txt myfile.txt > EOD Maybe this, in case clients could concurrently upload different versions of the same files: SUFFIX="$(hexdump -n8 -e '8/1 "%02X"' /dev/urandom)" sftp -b /dev/stdin server.example.com < References: <20070314185309.GA40932@fjarlq.com> <20070315001416.GA28880@gate.dtucker.net> <20070315011208.GA48513@fjarlq.com> <20070315024347.GA10841@gate.dtucker.net> <20070315025904.GA50787@fjarlq.com> <20070315032213.GA12369@gate.dtucker.net> <20070315055242.GA15006@gate.dtucker.net> <20070315084012.GA58996@fjarlq.com> Message-ID: <20070416081525.GA61867@fjarlq.com> On Thu, Mar 15, 2007 at 02:40:12AM -0600, Matt Day wrote: > I have installed these changes on my server and will let you know > when I get confirmation in my logfile that the fix is working. Hello, An update on this issue: I've been running the fix, as sent in this message, on my production server for the past few weeks: http://marc.info/?l=openssh-unix-dev&m=117394810109160 (Message-ID <20070315084012.GA58996 at fjarlq.com>) and I can confirm now that it has indeed fixed the problem. The "timed out while waiting to read" message has been logged on my system and the problem was handled correctly. Thanks very much for the fix! I hope it can make it into the next release of OpenSSH. Matt From thomas at ohzone.de Mon Apr 16 20:49:34 2007 From: thomas at ohzone.de (Thomas Blank) Date: Mon, 16 Apr 2007 12:49:34 +0200 Subject: HiddenStore option may be useful Message-ID: <26620951.387401176720574810.JavaMail.servlet@kundenserver> Darren Tucker wrote: > Do you have control over the clients? If so: > > 3. Use sftp to upload the file with a temporary name then rename it when > it's complete. Something like this (untested): > > sftp -b /dev/stdin server.example.com << EOD > put myfile.txt .myfile.txt > rename .myfile.txt myfile.txt > EOD No, I do not have control over the clients. Jefferson's suggestion of using tunneled rsnc is therefore also not possible. Implementing this is much more work as using standard sftp-commands in a script. inotify may help but I'm using Solaris not Linux - although not knowing but inotify may not have been ported to Solaris. Any other suggestions? From David.Leonard at quest.com Mon Apr 16 21:53:40 2007 From: David.Leonard at quest.com (David Leonard) Date: Mon, 16 Apr 2007 21:53:40 +1000 Subject: HiddenStore option may be useful In-Reply-To: <26620951.387401176720574810.JavaMail.servlet@kundenserver> References: <26620951.387401176720574810.JavaMail.servlet@kundenserver> Message-ID: <462363C4.8020203@quest.com> Two design comments: I noticed that firefox starts writing the file 'foo' as 'foo.part' and then renames it at the end. I like this approach precisely because it is *not* hidden. Users aren't dumb. They'll figure it out and they can better manage problems they can see. Hidden files are probably just asking for trouble. I'm slightly uncomfortable with the assumptions that the auxillary filename will be valid and that the final rename() operation is going to be cheap, or even available. It may be that the user wants to copying files into a virtual filesystem, where files have special semantics based on their name (eg /dev/). Or that the filesystem is something that doesn't support rename very well (eg a live-burning CD fs). I think also you may be interested in a previous discussion on whether sftp is a file transfer protocol or a filesystem protocol. d Thomas Blank wrote: > Darren Tucker wrote: > >> Do you have control over the clients? If so: >> >> 3. Use sftp to upload the file with a temporary name then rename it when >> it's complete. Something like this (untested): >> >> sftp -b /dev/stdin server.example.com << EOD >> put myfile.txt .myfile.txt >> rename .myfile.txt myfile.txt >> EOD >> > > No, I do not have control over the clients. > Jefferson's suggestion of using tunneled rsnc is therefore also not possible. Implementing this is much more work as using standard sftp-commands in a script. > > inotify may help but I'm using Solaris not Linux - although not knowing but inotify may not have been ported to Solaris. > > Any other suggestions? > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > From Jefferson.Ogata at noaa.gov Tue Apr 17 01:13:11 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Mon, 16 Apr 2007 15:13:11 +0000 Subject: HiddenStore option may be useful In-Reply-To: <26620951.387401176720574810.JavaMail.servlet@kundenserver> References: <26620951.387401176720574810.JavaMail.servlet@kundenserver> Message-ID: <46239287.40400@noaa.gov> On 2007-04-16 10:49, Thomas Blank wrote: > No, I do not have control over the clients. > Jefferson's suggestion of using tunneled rsnc is therefore also not possible. Implementing this is much more work as using standard sftp-commands in a script. > > inotify may help but I'm using Solaris not Linux - although not knowing but inotify may not have been ported to Solaris. > > Any other suggestions? I re-suggest fuser. Why won't that work? -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From djm at mindrot.org Tue Apr 17 07:54:57 2007 From: djm at mindrot.org (Damien Miller) Date: Tue, 17 Apr 2007 07:54:57 +1000 (EST) Subject: HiddenStore option may be useful In-Reply-To: <26620951.387401176720574810.JavaMail.servlet@kundenserver> References: <26620951.387401176720574810.JavaMail.servlet@kundenserver> Message-ID: On Mon, 16 Apr 2007, Thomas Blank wrote: > No, I do not have control over the clients. Jefferson's suggestion of > using tunneled rsnc is therefore also not possible. Implementing this > is much more work as using standard sftp-commands in a script. Do you think that getting a new option into sftp, and somehow getting all your clients (who you don't control) to upgrade to a version that supports it will be easy? Marking transfers as complete is a very old and repeatedly solved problem. There is no need for weird additional options in sftp to support it. An excellent solution has already been proposed: upload using a temporary name and rename it once complete. Other solutions include uploading a tiny (one, or zero byte) marker file to indicate that a transfer is done, or using a file format with a verifiable checksum (zip, gzip, pgp, etc.) -d From dkg-openssh.com at fifthhorseman.net Tue Apr 17 08:12:29 2007 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 16 Apr 2007 18:12:29 -0400 Subject: HiddenStore option may be useful In-Reply-To: (Damien Miller's message of "Tue, 17 Apr 2007 07:54:57 +1000 (EST)") References: <26620951.387401176720574810.JavaMail.servlet@kundenserver> Message-ID: <87bqhoarzm.fsf@squeak.fifthhorseman.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon 2007-04-16 17:54:57 -0400, Damien Miller wrote: > Do you think that getting a new option into sftp, and somehow > getting all your clients (who you don't control) to upgrade to a > version that supports it will be easy? I think the suggestion was that "HiddenStore" would be an option on the server. That way it could be controlled centrally without asking the clients to change their habits. --dkg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ iD8DBQFGI/TBiXTlFKVLY2URAt7gAJ0dKh9Q3VmhvZg/izNKftR6rlFUlgCgz/c5 S/8rgGYoxlExbVemZ7zbiug= =/pWt -----END PGP SIGNATURE----- From kzhang at redhat.com Tue Apr 17 13:41:02 2007 From: kzhang at redhat.com (Zhang Kexin) Date: Tue, 17 Apr 2007 11:41:02 +0800 Subject: where is the point the client command is executed? Message-ID: <1176781262.17425.24.camel@dhcp-0-103.pek.redhat.com> Hi, I met some difficult in reading ssh/sshd souce code, I want to find out how the command that user input in client is executed on the server. I only found out the process_input function put the command in a buffer,but can not find how it is executed. Could you please help me on that? Thank you very much. B Rgds, Kexin From dtucker at zip.com.au Tue Apr 17 13:45:49 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 17 Apr 2007 13:45:49 +1000 Subject: where is the point the client command is executed? In-Reply-To: <1176781262.17425.24.camel@dhcp-0-103.pek.redhat.com> References: <1176781262.17425.24.camel@dhcp-0-103.pek.redhat.com> Message-ID: <462442ED.4040505@zip.com.au> Zhang Kexin wrote: > Hi, > > I met some difficult in reading ssh/sshd souce code, I want to > find out how the command that user input in client is executed on the > server. I only found out the process_input function put the command in a > buffer,but can not find how it is executed. Could you please help me on > that? You mean when you run "ssh someserver echo foo" or similar? Look in session.c in do_exec() and do_exec_no_pty(). Ultimately it will end up running the command via the user's shell via execve(1) after setting up its environment, descriptors and such. > Thank you very much. You're welcome. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From kzhang at redhat.com Tue Apr 17 15:09:57 2007 From: kzhang at redhat.com (Zhang Kexin) Date: Tue, 17 Apr 2007 13:09:57 +0800 Subject: where is the point the client command is executed? In-Reply-To: <462442ED.4040505@zip.com.au> References: <1176781262.17425.24.camel@dhcp-0-103.pek.redhat.com> <462442ED.4040505@zip.com.au> Message-ID: <1176786597.17425.35.camel@dhcp-0-103.pek.redhat.com> On Tue, 2007-04-17 at 13:45 +1000, Darren Tucker wrote: > Zhang Kexin wrote: > > Hi, > > > > I met some difficult in reading ssh/sshd souce code, I want to > > find out how the command that user input in client is executed on the > > server. I only found out the process_input function put the command in a > > buffer,but can not find how it is executed. Could you please help me on > > that? > > You mean when you run "ssh someserver echo foo" or similar? I mean after I have connected to server successfully, when I input "ls" in client, how the command is executed. Your explain is exactly what i'm looking for. But I need more explain. > > Look in session.c in do_exec() and do_exec_no_pty(). Ultimately it will > end up running the command via the user's shell via execve(1) after > setting up its environment, descriptors and such. I looked do_exec_no_pty, is do_child(s, command) the place the command is executed? There are two execve's in do_child, one is for fork a shell, the other execve, it seems never invoked. So I still do not know how where command is executed. > > Thank you very much. > > You're welcome. Thank again. > From thomas at ohzone.de Tue Apr 17 15:11:17 2007 From: thomas at ohzone.de (Thomas Blank) Date: Tue, 17 Apr 2007 07:11:17 +0200 Subject: HiddenStore option may be useful In-Reply-To: References: <26620951.387401176720574810.JavaMail.servlet@kundenserver> Message-ID: <462456F5.50604@ohzone.de> Daniel Kahn Gillmor wrote: > > I think the suggestion was that "HiddenStore" would be an option on > the server. That way it could be controlled centrally without asking > the clients to change their habits. That's it - I not have control over the clients. Damien Miller wrote: > > Do you think that getting a new option into sftp, and somehow getting > all your clients (who you don't control) to upgrade to a version that > supports it will be easy? If I have to upgrade the clients (which I don't control) it will be hard work. But saving the contents to a temporary filename and renaming at the end is a completely transparent way to the clients. They do not recognize it (exactly like David Leonard's firefox download). If a would have control over the clients, you can be sure, I would implement it somehow like > upload using a temporary name and rename it once complete. Other > solutions include uploading a tiny > (one, or zero byte) marker file to indicate that a transfer is done, > or using a file format > with a verifiable checksum (zip, gzip, pgp, etc.) From dtucker at zip.com.au Tue Apr 17 15:35:52 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 17 Apr 2007 15:35:52 +1000 Subject: where is the point the client command is executed? In-Reply-To: <1176786597.17425.35.camel@dhcp-0-103.pek.redhat.com> References: <1176781262.17425.24.camel@dhcp-0-103.pek.redhat.com> <462442ED.4040505@zip.com.au> <1176786597.17425.35.camel@dhcp-0-103.pek.redhat.com> Message-ID: <46245CB8.4030208@zip.com.au> Zhang Kexin wrote: > On Tue, 2007-04-17 at 13:45 +1000, Darren Tucker wrote: >> Zhang Kexin wrote: >>> Hi, >>> >>> I met some difficult in reading ssh/sshd souce code, I want to >>> find out how the command that user input in client is executed on the >>> server. I only found out the process_input function put the command in a >>> buffer,but can not find how it is executed. Could you please help me on >>> that? >> You mean when you run "ssh someserver echo foo" or similar? > I mean after I have connected to server successfully, when I input "ls" > in client, how the command is executed. Your explain is exactly what i'm > looking for. But I need more explain. It works differently depending on whether or not you specify a command on the command line. When you run "ssh yoursever" without a command, sshd allocates a pty then starts up an interactive login shell. This shell receives commands on its standard input (via the pty) and executes them. The output is returned via the pty to sshd, which sends it back to the client. For example, if we look at my login shell: $ pstree -a -p 16714 sshd,16714 `-bash,16715 `-pstree,11185 -a -p 16714 $ lsof -p 16715 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME [...] bash 16715 dtucker 0u CHR 136,1 3 /dev/pts/1 bash 16715 dtucker 1u CHR 136,1 3 /dev/pts/1 bash 16715 dtucker 2u CHR 136,1 3 /dev/pts/1 bash 16715 dtucker 255u CHR 136,1 3 /dev/pts/1 The shell's standard input, output and error are connected to the pty pts/1... $ sudo lsof -p 16714 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME [...] sshd 16714 dtucker 7u CHR 5,2 889 /dev/ptmx sshd 16714 dtucker 8u CHR 5,2 889 /dev/ptmx sshd 16714 dtucker 9u CHR 5,2 889 /dev/ptmx and the corresponding sshd is reading from and writing to that pty (via the pseudo terminal multiplexer). If I then strace the shell while I type "ls[CR]" in it, you can see the keystrokes flowing in descriptor 0 (stdin): $ strace -p 16715 Process 16715 attached - interrupt to quit read(0, "l", 1) = 1 write(2, "l", 1) = 1 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 read(0, "s", 1) = 1 write(2, "s", 1) = 1 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 read(0, "\r", 1) = 1 write(2, "\n", 1) = 1 rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0 [lots of output] >> Look in session.c in do_exec() and do_exec_no_pty(). Ultimately it will >> end up running the command via the user's shell via execve(1) after >> setting up its environment, descriptors and such. > I looked do_exec_no_pty, is do_child(s, command) the place the command is executed? > There are two execve's in do_child, one is for fork a shell, the other > execve, it seems never invoked. So I still do not know how where > command is executed. The first is executed if you don't supply a command on the ssh client command line (it's preceded by "if (!command)") the second is used if you do supply a command and effectively runs /bin/sh -c "commands you specified". -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From rapier at psc.edu Wed Apr 18 07:21:51 2007 From: rapier at psc.edu (Chris Rapier) Date: Tue, 17 Apr 2007 17:21:51 -0400 Subject: SCP v. SFTP Message-ID: <46253A6F.3030106@psc.edu> I was comparing some traces from SCP and SFTP when transferring the same file 200MB file between the same host pairs. Even when I put SFTP in batch mode I noticed that I saw 403208 bytes from the receiver in comparison to 3368 bytes with SCP. I've attached the relevant output from tcptrace below (the b->a column is the return side of the trace). Mostly I'm just curious as to what is generating so much return traffic for SFTP? Actually, now that I think about it, why almost an additional 9000 packets* for SFTP on the sending side as well? Is it just some artifact of my network that I didn't pick up on or does the sftp mechanism require this? Thanks! Chris Rapier *I didn't disable TSO before taking these dumps so these pakets size don't necessarily correspond to the actual MTU. Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004 155626 packets seen, 155626 TCP packets traced elapsed wallclock time: 0:00:00.722889, 215283 pkts/sec analyzed trace file elapsed time: 0:00:19.943138 TCP connection info: 1 TCP connection traced: TCP connection 1: host a: delta host b: echo complete conn: yes first packet: Tue Apr 17 16:27:22.204583 2007 last packet: Tue Apr 17 16:27:42.147722 2007 elapsed time: 0:00:19.943138 total packets: 155626 filename: sftp2echo200mb.dump a->b: b->a: total packets: 74547 total packets: 81079 ack pkts sent: 74546 ack pkts sent: 81079 pure acks sent: 34 pure acks sent: 74806 sack pkts sent: 0 sack pkts sent: 0 dsack pkts sent: 0 dsack pkts sent: 0 max sack blks/ack: 0 max sack blks/ack: 0 unique bytes sent: 205796103 unique bytes sent: 403208 actual data pkts: 74511 actual data pkts: 6271 actual data bytes: 205848615 actual data bytes: 403208 rexmt data pkts: 22 rexmt data pkts: 0 rexmt data bytes: 52512 rexmt data bytes: 0 zwnd probe pkts: 0 zwnd probe pkts: 0 zwnd probe bytes: 0 zwnd probe bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 18049 pushed data pkts: 6271 SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1 req 1323 ws/ts: Y/Y req 1323 ws/ts: Y/Y adv wind scale: 9 adv wind scale: 7 req sack: Y req sack: Y sacks sent: 0 sacks sent: 0 urgent data pkts: 0 pkts urgent data pkts: 0 ================================ TCP connection 2: host c: delta host d: echo complete conn: yes first packet: Tue Apr 17 13:40:48.350911 2007 last packet: Tue Apr 17 13:40:55.841408 2007 elapsed time: 0:00:07.490497 total packets: 140843 filename: scp2echo200mb.dump c->d: d->c: total packets: 65970 total packets: 74873 ack pkts sent: 65969 ack pkts sent: 74873 pure acks sent: 20 pure acks sent: 74837 sack pkts sent: 0 sack pkts sent: 0 dsack pkts sent: 0 dsack pkts sent: 0 max sack blks/ack: 0 max sack blks/ack: 0 unique bytes sent: 205256455 unique bytes sent: 3368 actual data pkts: 65948 actual data pkts: 34 actual data bytes: 205364239 actual data bytes: 3368 rexmt data pkts: 37 rexmt data pkts: 0 rexmt data bytes: 107784 rexmt data bytes: 0 zwnd probe pkts: 0 zwnd probe pkts: 0 zwnd probe bytes: 0 zwnd probe bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 10483 pushed data pkts: 34 SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1 req 1323 ws/ts: Y/Y req 1323 ws/ts: Y/Y adv wind scale: 9 adv wind scale: 7 req sack: Y req sack: Y sacks sent: 0 sacks sent: 0 From rapier at psc.edu Thu Apr 19 02:50:01 2007 From: rapier at psc.edu (Chris Rapier) Date: Wed, 18 Apr 2007 12:50:01 -0400 Subject: SCP v. SFTP In-Reply-To: <46253A6F.3030106@psc.edu> References: <46253A6F.3030106@psc.edu> Message-ID: <46264C39.1090102@psc.edu> Okay, so I believe I figured out why this is happening but I still have a couple of questions I'm hoping someone can answer. So I believe the extra data is from the SFTP messages requesting data (in chunk sizes determined by -B) and the subsequent acknowledgment of the write to the file system. So the larger you set -B (up to 256K) the fewer messages will be passed back and forth and so less extra data. From my tests it seems that this step is actually blocking so fewer messages not only decreases the total amount of data but it also keeps the link from sitting idle as often. If I am correct in this I was wondering why its set up this way? Is it to prevent writing to a full file system or some place where the user doesn't have appropriate permission? Thanks! Chris Rapier wrote: > I was comparing some traces from SCP and SFTP when transferring the same > file 200MB file between the same host pairs. Even when I put SFTP in > batch mode I noticed that I saw 403208 bytes from the receiver in > comparison to 3368 bytes with SCP. I've attached the relevant output > from tcptrace below (the b->a column is the return side of the trace). > Mostly I'm just curious as to what is generating so much return traffic > for SFTP? Actually, now that I think about it, why almost an additional > 9000 packets* for SFTP on the sending side as well? > > Is it just some artifact of my network that I didn't pick up on or does > the sftp mechanism require this? > > > Thanks! > Chris Rapier > > > > *I didn't disable TSO before taking these dumps so these pakets size > don't necessarily correspond to the actual MTU. > > Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004 > > 155626 packets seen, 155626 TCP packets traced > elapsed wallclock time: 0:00:00.722889, 215283 pkts/sec analyzed > trace file elapsed time: 0:00:19.943138 > TCP connection info: > 1 TCP connection traced: > TCP connection 1: > host a: delta > host b: echo > complete conn: yes > first packet: Tue Apr 17 16:27:22.204583 2007 > last packet: Tue Apr 17 16:27:42.147722 2007 > elapsed time: 0:00:19.943138 > total packets: 155626 > filename: sftp2echo200mb.dump > a->b: b->a: > total packets: 74547 total packets: > 81079 > ack pkts sent: 74546 ack pkts sent: > 81079 > pure acks sent: 34 pure acks sent: > 74806 > sack pkts sent: 0 sack pkts sent: > 0 > dsack pkts sent: 0 dsack pkts sent: > 0 > max sack blks/ack: 0 max sack blks/ack: > 0 > unique bytes sent: 205796103 unique bytes sent: > 403208 > actual data pkts: 74511 actual data pkts: > 6271 > actual data bytes: 205848615 actual data bytes: > 403208 > rexmt data pkts: 22 rexmt data pkts: > 0 > rexmt data bytes: 52512 rexmt data bytes: > 0 > zwnd probe pkts: 0 zwnd probe pkts: > 0 > zwnd probe bytes: 0 zwnd probe bytes: > 0 > outoforder pkts: 0 outoforder pkts: > 0 > pushed data pkts: 18049 pushed data pkts: > 6271 > SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: > 1/1 > req 1323 ws/ts: Y/Y req 1323 ws/ts: > Y/Y > adv wind scale: 9 adv wind scale: > 7 > req sack: Y req sack: > Y > sacks sent: 0 sacks sent: > 0 > urgent data pkts: 0 pkts urgent data pkts: 0 > > > > ================================ > TCP connection 2: > host c: delta > host d: echo > complete conn: yes > first packet: Tue Apr 17 13:40:48.350911 2007 > last packet: Tue Apr 17 13:40:55.841408 2007 > elapsed time: 0:00:07.490497 > total packets: 140843 > filename: scp2echo200mb.dump > c->d: d->c: > total packets: 65970 total packets: > 74873 > ack pkts sent: 65969 ack pkts sent: > 74873 > pure acks sent: 20 pure acks sent: > 74837 > sack pkts sent: 0 sack pkts sent: > 0 > dsack pkts sent: 0 dsack pkts sent: > 0 > max sack blks/ack: 0 max sack blks/ack: > 0 > unique bytes sent: 205256455 unique bytes sent: > 3368 > actual data pkts: 65948 actual data pkts: > 34 > actual data bytes: 205364239 actual data bytes: > 3368 > rexmt data pkts: 37 rexmt data pkts: > 0 > rexmt data bytes: 107784 rexmt data bytes: > 0 > zwnd probe pkts: 0 zwnd probe pkts: > 0 > zwnd probe bytes: 0 zwnd probe bytes: > 0 > outoforder pkts: 0 outoforder pkts: > 0 > pushed data pkts: 10483 pushed data pkts: > 34 > SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: > 1/1 > req 1323 ws/ts: Y/Y req 1323 ws/ts: > Y/Y > adv wind scale: 9 adv wind scale: > 7 > req sack: Y req sack: > Y > sacks sent: 0 sacks sent: > 0 > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From savan.patel21 at yahoo.com Thu Apr 19 20:48:55 2007 From: savan.patel21 at yahoo.com (hfgj ghgj) Date: Thu, 19 Apr 2007 03:48:55 -0700 (PDT) Subject: error: *** zlib missing Message-ID: <35480.54790.qm@web58914.mail.re1.yahoo.com> I am very new to linux and openSSH ,, i am trying to compile openssh for jungo openrg IXP45. but while configuring i am getting following error,, hecking for libgen.h... yes checking for getspnam... yes checking for library containing basename... none required checking for deflate in -lz... no configure: error: *** zlib missing - please install first or check config.log *** if anybody will me then it would be realy appriciated,, i used to give path of zlib also,, but i dont know what is going wrong,, can anybody tell me how to set -lz with libz.a and config.log file showing like below,, (IN CONFIG.LOG file) | /* Override any GCC internal prototype to avoid an error. | Use char because int might match the return type of a GCC | builtin and then its argument prototype would still apply. */ | #ifdef __cplusplus | extern "C" | #endif | char deflate (); | int | main () | { | return deflate (); | ; | return 0; | } configure:10140: result: no configure:10189: /usr/local/openrg/armv5b-jungo-linux-gnu/bin/armv5b-jungo-linux-gnu-gcc -o conftest -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -std=gnu99 -I/usr/local/include -I/usr/local/openrg/openrg/pkg/zlib/ -L/usr/local/lib -L/usr/local/openrg/openrg/pkg/zlib/ conftest.c -lnsl -lz >&5 /usr/local/openrg/armv5b-jungo-linux-gnu/lib/gcc-lib/armv5b-jungo-linux-gnu/3.3.2/../../../../armv5b-jungo-linux-gnu/bin/ld: skipping incompatible /usr/local/lib/libz.a when searching for -lz /tmp/ccysCctu.o(.text+0x4): In function `main': /usr/local/openrg/openrg/pkg/openssh/conftest.c:83: undefined reference to `deflate' collect2: ld returned 1 exit status configure:10195: $? = 1 configure: failed program was: | /* confdefs.h. */ thanks --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. From stuge-openssh-unix-dev at cdy.org Fri Apr 20 01:11:31 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 19 Apr 2007 17:11:31 +0200 Subject: error: *** zlib missing In-Reply-To: <35480.54790.qm@web58914.mail.re1.yahoo.com> References: <35480.54790.qm@web58914.mail.re1.yahoo.com> Message-ID: <20070419151131.22102.qmail@cdy.org> On Thu, Apr 19, 2007 at 03:48:55AM -0700, hfgj ghgj wrote: > checking for deflate in -lz... no > configure: error: *** zlib missing - please install first or check config.log *** [..] > if anybody will me then it would be realy appriciated,, i used to > give path of zlib also,, but i dont know what is going wrong,, > > can anybody tell me how to set -lz with libz.a You did this the correct way, but.. > /usr/local/openrg/armv5b-jungo-linux-gnu/lib/gcc-lib/armv5b-jungo-linux-gnu/3.3.2/../../../../armv5b-jungo-linux-gnu/bin/ld: skipping incompatible /usr/local/lib/libz.a when searching for -lz ..the libz.a you specified is not usable on this platform it seems. The easiest would probably be to re-install zlib from source on your target system. //Peter From petrus69 at gmx.de Fri Apr 20 01:12:37 2007 From: petrus69 at gmx.de (Peter Fischer) Date: Thu, 19 Apr 2007 17:12:37 +0200 Subject: Is it possible to add %u for local user to ControlPath's argument in the portable version of OpenSSH? Message-ID: <462786E5.7050101@gmx.de> Hi! >From man 5 ssh_config > ControlPath > Specify the path to the control socket used for connection sharing as described in the > ControlMaster section above or the string ``none'' to disable connection sharing. In > the path, `%l' will be substituted by the local host name, `%h' will be substituted by > the target host name, `%p' the port, and `%r' by the remote login username. It is rec- > ommended that any ControlPath used for opportunistic connection sharing include at least > %h, %p, and %r. This ensures that shared connections are uniquely identified. Question: Could you please add an %u for the local user to the control path setting? *pleeze* ;) With the latest OpenSSH version on Gentoo linux > me at myhost ~ % ssh -V > OpenSSH_4.6p1-hpn12v16, OpenSSL 0.9.8d 28 Sep 2006 using %u gives this error: > me at myhost ~ % ssh qqgss at dbha30.muc > percent_expand: unknown key %u >From http://marc.info/?l=openssh-unix-dev&m=111856810721769&w=2 and followups I learned that it is availible in the BSD version since a few years ago. If %u was availible one could put ControlMaster auto ControlPath /tmp/%u@%L->%r@%h:%p in /etc/ssh/ssh_config and all users on a machine would benefit from connection sharing with two centrally maintained lines of configuration and without the following problem. DESCRIPTION: ============ /etc/ssh/ssh_config settings are: > ControlMaster auto > ControlPath /tmp/%l->%r@%h:%p # because %u does not work user1 on localmachine sshs to remoteaccount on remotemachine, socket looks like: > localmachine ~ # ls -l /tmp > srw------- 1 user1 user1 0 19. Apr 14:05 localmachine->remoteaccount at remotemachine:22= if now user2 on localmachine tries the same, he gets an error message > user2 at localmachine ~ % ssh remoteaccount at remotemachine > Control socket connect(/tmp/localmachine->remoteaccount at remotemachine:22): Permission denied > ControlSocket /tmp/localmachine->remoteaccount at remotemachine:22 already exists because user1 owns a connection sharing socket of that name already. If one could use %u in ControlPath's argument, sockets would look like > localmachine ~ # ls -l /tmp > srw------- 1 user1 user1 0 19. Apr 14:06 user1 at localmachine->remoteaccount at remotemachine:22= > srw------- 1 user2 user2 0 19. Apr 14:07 user2 at localmachine->remoteaccount at remotemachine:22= and user1 as well as user2 could experience fast subsequent ssh connections to remoteaccount at remotemachine. Alternatives would be: > ControlPath ~/.ssh/%r@%h:%p ...but I do not like the idea of a cluttered ~/.ssh/ with stale entries (/tmp is usually maintained/uncluttered by tmpreaper etc, mine is on a tmpfs, also some users' ~ are filled to the quota sometimes) or one would have to maintain some lines in every ~/.ssh/config in every user's home... > ControlMaster auto > ControlPath /tmp/username@%l->%r@%h:%p # because %u does not work :( Thank you for reading, Peter From dkg-openssh.com at fifthhorseman.net Fri Apr 20 11:02:46 2007 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 19 Apr 2007 21:02:46 -0400 Subject: Is it possible to add %u for local user to ControlPath's argument in the portable version of OpenSSH? In-Reply-To: <462786E5.7050101@gmx.de> (Peter Fischer's message of "Thu, 19 Apr 2007 17:12:37 +0200") References: <462786E5.7050101@gmx.de> Message-ID: <874pnbkgcp.fsf@squeak.fifthhorseman.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu 2007-04-19 11:12:37 -0400, Peter Fischer wrote: > Question: > Could you please add an %u for the local user to the control path > setting? *pleeze* ;) Maybe something like this would work better: ControlPath ~/.ssh/control.%r@%h:%p (and make sure every new user starts off with a ~/.ssh: mkdir /etc/skel/.ssh ) That way there's no possibility of collisions or deliberate denial of service by cluttering /tmp. --dkg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ iD8DBQFGKBEwiXTlFKVLY2URApntAKDAyUO1avOrUKO0Y3U0FymYcrALMACfa2S+ H7H9sY8kZuUKLQdxkXt72sw= =7JvE -----END PGP SIGNATURE----- From savan.patel21 at yahoo.com Fri Apr 20 12:16:16 2007 From: savan.patel21 at yahoo.com (hfgj ghgj) Date: Thu, 19 Apr 2007 19:16:16 -0700 (PDT) Subject: error: *** zlib missing In-Reply-To: <20070419151131.22102.qmail@cdy.org> Message-ID: <809777.54004.qm@web58915.mail.re1.yahoo.com> I tried to reinstall zlib from the source, but then also it showing like that only,, is there any way to to link libz.a to liker of arm5-gcc compiler ? It would be appriciated if anybody give solution. Peter Stuge wrote: On Thu, Apr 19, 2007 at 03:48:55AM -0700, hfgj ghgj wrote: > checking for deflate in -lz... no > configure: error: *** zlib missing - please install first or check config.log *** [..] > if anybody will me then it would be realy appriciated,, i used to > give path of zlib also,, but i dont know what is going wrong,, > > can anybody tell me how to set -lz with libz.a You did this the correct way, but.. > /usr/local/openrg/armv5b-jungo-linux-gnu/lib/gcc-lib/armv5b-jungo-linux-gnu/3.3.2/../../../../armv5b-jungo-linux-gnu/bin/ld: skipping incompatible /usr/local/lib/libz.a when searching for -lz ..the libz.a you specified is not usable on this platform it seems. The easiest would probably be to re-install zlib from source on your target system. //Peter _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. From tambet at gmail.com Fri Apr 20 18:02:06 2007 From: tambet at gmail.com (Tambet Ingo) Date: Fri, 20 Apr 2007 11:02:06 +0300 Subject: New gnome-ssh-askpass Message-ID: Hello, I wrote a new askpass frontend for gnome that uses gnome-keyring to store the password in keyring. Is there any interest in including it in openssh? Tambet -------------- next part -------------- A non-text attachment was scrubbed... Name: gnome-keyring-ssh-askpass.c Type: text/x-csrc Size: 6882 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070420/80f6b50b/attachment-0001.bin From stevec at FutureSoft.com Sat Apr 21 06:39:58 2007 From: stevec at FutureSoft.com (Cooper, Steve) Date: Fri, 20 Apr 2007 15:39:58 -0500 Subject: Cannot receive more that ~64k from host? Message-ID: <8E9BDA21B46D6A4C8ECFB6444DACAF1C22D19B@exchange.futuresoft.com> Hi All, I have "converted" the openssh code into a Windows DLL and everything "works" up until around 64k of data packets is received from the host. What I see from extensive debugging is that select() never reports that there is more data to read. I was hoping someone could give me a clue as to what to try next??? I believe the Winsock receive buffer defaults to 64k, but the problem is not speed related. - Yes, I have two different hosts to connect with (older Redhat and FreeBSD) - Does not matter if SSH1 or SSH2 - Does not matter if interactive over time (listing files, editing programs, etc) or blasted (ll -R /usr) (ie: ~64k of data from the host over time or all at once.) - The connection is still active...I run sshd in debug mode and the connection stays active until I end the SSH session and everything shuts down cleanly... Any crazy ideas? Thanks, Steve Steve Cooper Developer FutureSoft, Inc. ** This email is confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you have received this email in error, please contact the sender. ** -- ---------------------------------------------------------------------- FutureSoft, Inc. 12012 Wickchester Lane, Suite 600 Houston, TX 77079 If you no longer want to receive commercial e-mail correspondence from FutureSoft, you may remove your address from our records by visiting www.futuresoft.com/emailremoval.asp ---------------------------------------------------------------------- From eric.noulard at gmail.com Wed Apr 25 08:30:21 2007 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 25 Apr 2007 00:30:21 +0200 Subject: chmod sftp command and setgid/setuid bit Message-ID: Hi OpenSSH developers, I'm using OpenSSH on a daily basis and I'm very pleased with the work you've done. I am contributing to some Open Source software hosted at Savannah https://savannah.nongnu.org/projects/tsp and we recently hit some sftp unexpected behavior: https://savannah.gnu.org/support/?105838 when using chmod sftp client command it appears that setuid / setgid bits are not handled on the server-side. that when I sftp> chmod 2775 afile I would expect afile to show: -rwxrwsr-x 1 openssh isgreat 0 2007-04-25 00:19 afile but I get: -rwxrwxr-x 1 openssh isgreat 0 2007-04-25 00:19 afile just as if I had typed: "chmod 775 afile " on server-side. As far as I understand sftp-server.c code is seems that chmod(name, a->perm & 0777); is responsible for this behavior. Could you tell me if not handling setuid/setgid bits on sftp-server is done on purpose? Is it a feature or should it be considered a bug? If it is a feature could you tell me what motivates this choice? By the way "-p" option of scp command seems to handle setuid/setgid bits as (I) expected. Thanks in advance -- Erk From stuge-openssh-unix-dev at cdy.org Wed Apr 25 09:28:29 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Wed, 25 Apr 2007 01:28:29 +0200 Subject: chmod sftp command and setgid/setuid bit In-Reply-To: References: Message-ID: <20070424232830.19675.qmail@cdy.org> On Wed, Apr 25, 2007 at 12:30:21AM +0200, Eric Noulard wrote: > As far as I understand sftp-server.c code is seems that > > chmod(name, a->perm & 0777); > > is responsible for this behavior. > > Could you tell me if not handling setuid/setgid bits on sftp-server > is done on purpose? > Is it a feature or should it be considered a bug? Seems like a bug.. --8<-- draft-ietf-secsh-filexfer-12.txt 7.6. Permissions The server SHOULD NOT apply a 'umask' to the mode bits; but should set the mode bits as specified by the client. The client MUST apply an appropriate 'umask' to the mode bits before sending them. -->8-- //Peter From djm at mindrot.org Wed Apr 25 10:00:18 2007 From: djm at mindrot.org (Damien Miller) Date: Wed, 25 Apr 2007 10:00:18 +1000 (EST) Subject: chmod sftp command and setgid/setuid bit In-Reply-To: <20070424232830.19675.qmail@cdy.org> References: <20070424232830.19675.qmail@cdy.org> Message-ID: On Wed, 25 Apr 2007, Peter Stuge wrote: > On Wed, Apr 25, 2007 at 12:30:21AM +0200, Eric Noulard wrote: > > As far as I understand sftp-server.c code is seems that > > > > chmod(name, a->perm & 0777); > > > > is responsible for this behavior. > > > > Could you tell me if not handling setuid/setgid bits on sftp-server > > is done on purpose? > > Is it a feature or should it be considered a bug? > > Seems like a bug.. > > --8<-- draft-ietf-secsh-filexfer-12.txt 7.6. Permissions We do not implement filexfer-12, we stopped chasing newer filexfer drafts when the authors started loading NFS-like features into the protocol. The reason for the mask is probably simple paranoia, and it could probably be relaxed. Please file a bug at http://bugzilla.mindrot.org/ -d From rapier at psc.edu Thu Apr 26 00:17:14 2007 From: rapier at psc.edu (Chris Rapier) Date: Wed, 25 Apr 2007 10:17:14 -0400 Subject: chmod sftp command and setgid/setuid bit In-Reply-To: References: <20070424232830.19675.qmail@cdy.org> Message-ID: <462F62EA.90509@psc.edu> Can I ask which, if any, RFC you do follow for SFTP? I'm doing some work in SFTP and this would be good for me to know. Any documentation on the protocol implementation would be supremely useful. Chris Damien Miller wrote: > On Wed, 25 Apr 2007, Peter Stuge wrote: > >> On Wed, Apr 25, 2007 at 12:30:21AM +0200, Eric Noulard wrote: >>> As far as I understand sftp-server.c code is seems that >>> >>> chmod(name, a->perm & 0777); >>> >>> is responsible for this behavior. >>> >>> Could you tell me if not handling setuid/setgid bits on sftp-server >>> is done on purpose? >>> Is it a feature or should it be considered a bug? >> Seems like a bug.. >> >> --8<-- draft-ietf-secsh-filexfer-12.txt 7.6. Permissions > > We do not implement filexfer-12, we stopped chasing newer filexfer drafts > when the authors started loading NFS-like features into the protocol. > > The reason for the mask is probably simple paranoia, and it could probably > be relaxed. Please file a bug at http://bugzilla.mindrot.org/ > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From Andy.Anderson at srpnet.com Wed Apr 25 09:44:38 2007 From: Andy.Anderson at srpnet.com (Anderson Russell D (Andy)) Date: Tue, 24 Apr 2007 16:44:38 -0700 Subject: Logging enhancement Message-ID: <67CB8ED9E971994EBC91568A2997E24102858B78@EXCV22.srp.gov> I would like to suggest a logging enhancement that would contribute greatly to access auditing. Currently nothing is logged when a user connects to another server as a different user. The auditing trail is broken for tracing access. userA> ssh userB at hostB A simple syslog addition (for example) to ssh.c closes that gap. /* Log into the remote system. This never returns if the login fails. */ ssh_login(&sensitive_data, host, (struct sockaddr *)&hostaddr, pw); /* added for NERC logging and auditing */ syslog(LOG_NOTICE, "ssh: user %s connected to host %s as %s", pw->pw_name, host, options.user); Thanks From dtucker at zip.com.au Thu Apr 26 01:15:13 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 26 Apr 2007 01:15:13 +1000 Subject: chmod sftp command and setgid/setuid bit In-Reply-To: <462F62EA.90509@psc.edu> References: <20070424232830.19675.qmail@cdy.org> <462F62EA.90509@psc.edu> Message-ID: <462F7081.6060706@zip.com.au> Chris Rapier wrote: > Can I ask which, if any, RFC you do follow for SFTP? I'm doing some work > in SFTP and this would be good for me to know. Any documentation on the > protocol implementation would be supremely useful. It's filexfer draft 3. There's no RFC for sftp. http://tools.ietf.org/html/draft-ietf-secsh-filexfer-03 $ sftp localhost Connecting to localhost... sftp> version SFTP protocol version 3 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From rapier at psc.edu Thu Apr 26 01:21:44 2007 From: rapier at psc.edu (Chris Rapier) Date: Wed, 25 Apr 2007 11:21:44 -0400 Subject: SFTP and outstanding requests Message-ID: <462F7208.2010006@psc.edu> I've been looking at the SFTP code and the filexfer RFC (and ended up answering my prior questions). I was wondering if anyone had any thoughts as to what might happen if the maximum number of outstanding requests was increased. Currently its set in sftp.c at /* Number of concurrent outstanding requests */ size_t num_requests = 16; From rapier at psc.edu Thu Apr 26 01:50:38 2007 From: rapier at psc.edu (Chris Rapier) Date: Wed, 25 Apr 2007 11:50:38 -0400 Subject: chmod sftp command and setgid/setuid bit In-Reply-To: <462F7081.6060706@zip.com.au> References: <20070424232830.19675.qmail@cdy.org> <462F62EA.90509@psc.edu> <462F7081.6060706@zip.com.au> Message-ID: <462F78CE.3000803@psc.edu> Thank you! This was very helpful. :) I had been reading filexfer-13 - this one is much more straightforward. Darren Tucker wrote: > Chris Rapier wrote: >> Can I ask which, if any, RFC you do follow for SFTP? I'm doing some work >> in SFTP and this would be good for me to know. Any documentation on the >> protocol implementation would be supremely useful. > > It's filexfer draft 3. There's no RFC for sftp. > > http://tools.ietf.org/html/draft-ietf-secsh-filexfer-03 > > $ sftp localhost > Connecting to localhost... > sftp> version > SFTP protocol version 3 > From rapier at psc.edu Thu Apr 26 02:15:54 2007 From: rapier at psc.edu (Chris Rapier) Date: Wed, 25 Apr 2007 12:15:54 -0400 Subject: SFTP and outstanding requests In-Reply-To: <462F7208.2010006@psc.edu> References: <462F7208.2010006@psc.edu> Message-ID: <462F7EBA.9090408@psc.edu> Quick note of clarification. I know you can change this from the command line with -R. Mostly I'm just wondering if there are situations where increasing it might cause problems. Chris Rapier wrote: > I've been looking at the SFTP code and the filexfer RFC (and ended up > answering my prior questions). I was wondering if anyone had any > thoughts as to what might happen if the maximum number of outstanding > requests was increased. > > Currently its set in sftp.c at > /* Number of concurrent outstanding requests */ > size_t num_requests = 16; > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From jmknoble at pobox.com Thu Apr 26 03:01:23 2007 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 25 Apr 2007 13:01:23 -0400 Subject: Logging enhancement In-Reply-To: <67CB8ED9E971994EBC91568A2997E24102858B78@EXCV22.srp.gov> References: <67CB8ED9E971994EBC91568A2997E24102858B78@EXCV22.srp.gov> Message-ID: <20070425170123.GA6365@crawfish.ais.com> Circa 2007-04-24 19:44 dixit Anderson Russell D (Andy): : I would like to suggest a logging enhancement that would contribute : greatly to access auditing. : : Currently nothing is logged when a user connects to another server as a : different user. : : The auditing trail is broken for tracing access. : : userA> ssh userB at hostB : : A simple syslog addition (for example) to ssh.c closes that gap. : [...] And what if the user logs into a remote system using an ssh program they compiled themselves which doesn't have that logging bit in it? userA at hostA$ /path/to/my/own/ssh userB at hostB At the very least, you'll need to track every command run by every user, including its environment (PATH, other environment variables that can control program behavior, including LD_PRELOAD on appropriate systems). Furthermore, what if the user sets up a tunneled connection to hostB via hostA and logs into hostB over that connection? user5 at hostQ$ ssh -f -N -L 23456:hostB:22 userA at hostA user5 at hostQ$ ssh -p 23456 userB at hostB Now command logging doesn't even help, unless you can log commands run on hostQ as well. You're probably better off forcing users to use public key authentication only, controlling the contents of ~/.ssh/authorized_keys on the hosts on your network, setting sshd's LogLevel to VERBOSE, and using the fingerprints logged by sshd to tell who logged into where from where. Maybe look into whether using Kerberos and GSSAPI authentication can help you. You'll need policies to deal with things like users allowing use of their accounts or credentials by someone else as well. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: 6F39C2CC >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC) +----------------------------------------------------------------------+ |[L]iberty, as we all know, cannot flourish in a country that is perma-| | nently on a war footing, or even a near-war footing. --Aldous Huxley| +----------------------------------------------------------------------+ From djm at mindrot.org Thu Apr 26 14:51:39 2007 From: djm at mindrot.org (Damien Miller) Date: Thu, 26 Apr 2007 14:51:39 +1000 (EST) Subject: chmod sftp command and setgid/setuid bit In-Reply-To: <462F62EA.90509@psc.edu> References: <20070424232830.19675.qmail@cdy.org> <462F62EA.90509@psc.edu> Message-ID: On Wed, 25 Apr 2007, Chris Rapier wrote: > Can I ask which, if any, RFC you do follow for SFTP? I'm doing some work > in SFTP and this would be good for me to know. Any documentation on the > protocol implementation would be supremely useful. It is draft-ietf-secsh-filexfer-03.txt -d From djm at mindrot.org Thu Apr 26 14:54:33 2007 From: djm at mindrot.org (Damien Miller) Date: Thu, 26 Apr 2007 14:54:33 +1000 (EST) Subject: SFTP and outstanding requests In-Reply-To: <462F7208.2010006@psc.edu> References: <462F7208.2010006@psc.edu> Message-ID: On Wed, 25 Apr 2007, Chris Rapier wrote: > I've been looking at the SFTP code and the filexfer RFC (and ended up > answering my prior questions). I was wondering if anyone had any > thoughts as to what might happen if the maximum number of outstanding > requests was increased. > > Currently its set in sftp.c at > /* Number of concurrent outstanding requests */ > size_t num_requests = 16; I'm not sure what you are asking. Obviously, increasing this will cause more requests to be made before waiting for the first request ACK. You can change this from the commandline with the -R flag. -d From djm at mindrot.org Thu Apr 26 14:56:37 2007 From: djm at mindrot.org (Damien Miller) Date: Thu, 26 Apr 2007 14:56:37 +1000 (EST) Subject: SFTP and outstanding requests In-Reply-To: <462F7EBA.9090408@psc.edu> References: <462F7208.2010006@psc.edu> <462F7EBA.9090408@psc.edu> Message-ID: On Wed, 25 Apr 2007, Chris Rapier wrote: > Quick note of clarification. I know you can change this from the command > line with -R. Mostly I'm just wondering if there are situations where > increasing it might cause problems. Not that I am aware of. The current value is fairly arbitrary and was based IIRC on a value that produced a good transfer speed between a host in Melbourne and one in Singapore. The default could easily be cranked up or down if you can present some evidence to justify it. -d From savan.patel21 at yahoo.com Thu Apr 26 19:51:35 2007 From: savan.patel21 at yahoo.com (hfgj ghgj) Date: Thu, 26 Apr 2007 02:51:35 -0700 (PDT) Subject: libcrypto.so: undefined reference to `utc_time' Message-ID: <753953.77126.qm@web58908.mail.re1.yahoo.com> I am trying to cross compile openssh for arm5b-jungo-gnu-gcc,, and also using openssl and zlib from same compiler arm5b-jungo-gnu-gcc but i am getting following error,,, /usr/local/openrg/armv5b-jungo-linux-gnu/bin/armv5b-jungo-linux-gnu-ld: warning: cannot find entry symbol _start; defaulting to 0000b9c8 /usr/local/openrg/armv5b-jungo-linux-gnu/bin/../armv5b-jungo-linux-gnu/lib/libcrypto.so: undefined reference to `utc_time' make: *** [ssh] Error 1 i have clear "libcrypto.so: undefined reference to `ldclose'" error, by putting -ldl can anybody tell me how to clear utc_time ,which library i should add ? i am stuck since last 2 days due to this error,, plz help me,, regards,, Savan --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. From savan.patel21 at yahoo.com Thu Apr 26 21:32:02 2007 From: savan.patel21 at yahoo.com (hfgj ghgj) Date: Thu, 26 Apr 2007 04:32:02 -0700 (PDT) Subject: libcrypto.so: undefined reference to `utc_time' Message-ID: <85778.54173.qm@web58903.mail.re1.yahoo.com> I am trying to cross compile openssh for arm5b-jungo-gnu-gcc,, and also using openssl and zlib from same compiler arm5b-jungo-gnu-gcc but i am getting following error,,, /usr/local/openrg/armv5b-jungo-linux-gnu/bin/armv5b-jungo-linux-gnu-ld: warning: cannot find entry symbol _start; defaulting to 0000b9c8 /usr/local/openrg/armv5b-jungo-linux-gnu/bin/../armv5b-jungo-linux-gnu/lib/libcrypto.so: undefined reference to `utc_time' make: *** [ssh] Error 1 i have clear "libcrypto.so: undefined reference to `ldclose'" error, by putting -ldl can anybody tell me how to clear utc_time ,which library i should add ? i am stuck since last 2 days due to this error,, plz help me,, regards,, Savan --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. From rapier at psc.edu Fri Apr 27 02:28:53 2007 From: rapier at psc.edu (Chris Rapier) Date: Thu, 26 Apr 2007 12:28:53 -0400 Subject: SFTP and outstanding requests In-Reply-To: References: <462F7208.2010006@psc.edu> <462F7EBA.9090408@psc.edu> Message-ID: <4630D345.5000107@psc.edu> Damien Miller wrote: > On Wed, 25 Apr 2007, Chris Rapier wrote: > >> Quick note of clarification. I know you can change this from the command >> line with -R. Mostly I'm just wondering if there are situations where >> increasing it might cause problems. > > Not that I am aware of. The current value is fairly arbitrary and was based > IIRC on a value that produced a good transfer speed between a host in > Melbourne and one in Singapore. > > The default could easily be cranked up or down if you can present some > evidence to justify it. > > -d Damien, Well, currently the default shouldn't be a problem in most any situation. As far as I can tell it pretty much acts like a flow control buffer with (by default) a 512K window (16x32k). So when you layer that on top of SSH's flow control and on top of TCP's as long as its not the minimum value it shouldn't act as a bottleneck. It does end up being problematic with the HPN patch (boosting it to 256 gave me 32MB/s while before it was maxing out at 4MB/s) but I can address that, probably, with user education. There is another, more complicated, method that wouldn't tax low memory systems, but I'm not even going to think about that until I get back. What I am curious about, and maybe you can help point me to the right portion of the code, is what happens when transferring multiple files in SFTP (SCP as well). If you look at outstanding data graphs (derived by tcptrace from a tcpdump) it seems that between each file there is something happening that causes the network to drain completely and then there is a 2RTT pause before the next file gets sent out. I can put a copy of the data somewhere if you want to look at it. If I can get a better understanding of what is happening there I can at least explain to my users why they should do a tar pipe if they have many small files. Chris From Andy.Anderson at srpnet.com Fri Apr 27 03:44:24 2007 From: Andy.Anderson at srpnet.com (Anderson Russell D (Andy)) Date: Thu, 26 Apr 2007 10:44:24 -0700 Subject: Logging enhancement In-Reply-To: <20070425170123.GA6365@crawfish.ais.com> Message-ID: <67CB8ED9E971994EBC91568A2997E24102858D1B@EXCV22.srp.gov> I think you read way to deep. I'm not talking about every keystroke. I'm talking basic syslog connection monitoring here. There sure doesn't seem to be a problem with sshd logging connection info! There sure doesn't seem to be a problem populating client environment variables with connection info! SSH_CLIENT='10.10.10.100 2926 22' SSH_CONNECTION='10.10.10.100 2926 10.20.20.100 22' I'm just asking why ssh can't do a basic sylog entry on a user like "su". Maybe a ssh_config option that provides it for any ssh aware client (sftp, scp, etc). Keeps it out of O/S specific features like BSM, etc. And yes, your right, anyone can compile and run anything on any port. (including the sshd daemon). I'm just talking about the probable 99% of users that use ssh out-of-the-box. The ssh client is always the starting point for most uses I'm aware of. There are plenty of log analysis packages and correlation tools (sec.pl) that could take advantage of it. I guess I do not understand the reluctance, especially considering the nature of the product. BASIC PREMISE userA at hostA> ssh userB at hostB With no ssh client syslog entry ------------------------ sshd server host syslog entry: Apr 26 09:26:01 hostB sshd[11486]: Accepted password for userB from 10.10.10.100 port 2926 ssh2 Could be anyone, can't even make a stab in the dark. With a minimum ssh client syslog entry: --------------------------------- ssh client host syslog entry: Apr 26 09:26:01 hostA ssh[11486]: ssh: user userA connected to host hostB as userB At least I can probably correlate the event to userA Sounded like hack your own or go commercial or other options: http://www.balabit.com/products/scb/ Thanks for the response. -----Original Message----- From: Jim Knoble [mailto:jmknoble at pobox.com] Sent: Wednesday, April 25, 2007 10:01 AM To: Anderson Russell D (Andy) Cc: openssh-unix-dev at mindrot.org Subject: Re: Logging enhancement Circa 2007-04-24 19:44 dixit Anderson Russell D (Andy): : I would like to suggest a logging enhancement that would contribute : greatly to access auditing. : : Currently nothing is logged when a user connects to another server as a : different user. : : The auditing trail is broken for tracing access. : : userA> ssh userB at hostB : : A simple syslog addition (for example) to ssh.c closes that gap. : [...] And what if the user logs into a remote system using an ssh program they compiled themselves which doesn't have that logging bit in it? userA at hostA$ /path/to/my/own/ssh userB at hostB At the very least, you'll need to track every command run by every user, including its environment (PATH, other environment variables that can control program behavior, including LD_PRELOAD on appropriate systems). Furthermore, what if the user sets up a tunneled connection to hostB via hostA and logs into hostB over that connection? user5 at hostQ$ ssh -f -N -L 23456:hostB:22 userA at hostA user5 at hostQ$ ssh -p 23456 userB at hostB Now command logging doesn't even help, unless you can log commands run on hostQ as well. You're probably better off forcing users to use public key authentication only, controlling the contents of ~/.ssh/authorized_keys on the hosts on your network, setting sshd's LogLevel to VERBOSE, and using the fingerprints logged by sshd to tell who logged into where from where. Maybe look into whether using Kerberos and GSSAPI authentication can help you. You'll need policies to deal with things like users allowing use of their accounts or credentials by someone else as well. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: 6F39C2CC >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC) +----------------------------------------------------------------------+ |[L]iberty, as we all know, cannot flourish in a country that is perma-| | nently on a war footing, or even a near-war footing. --Aldous Huxley| +----------------------------------------------------------------------+ From jmknoble at pobox.com Fri Apr 27 04:53:53 2007 From: jmknoble at pobox.com (Jim Knoble) Date: Thu, 26 Apr 2007 14:53:53 -0400 Subject: Logging enhancement In-Reply-To: <67CB8ED9E971994EBC91568A2997E24102858D1B@EXCV22.srp.gov> References: <20070425170123.GA6365@crawfish.ais.com> <67CB8ED9E971994EBC91568A2997E24102858D1B@EXCV22.srp.gov> Message-ID: <20070426185353.GF6365@crawfish.ais.com> Circa 2007-04-26 13:44 dixit Anderson Russell D (Andy): : I think you read way to deep. : I'm not talking about every keystroke. : I'm talking basic syslog connection monitoring here. I understand what you're talking about. I pointed out that your "auditing" doesn't really accomplish that much; in fact, savvy attackers could not only circumvent your auditing completely, but perhaps even use it to hide what they're actually doing. : There sure doesn't seem to be a problem with sshd logging connection : info! sshd is able to be controlled by the system administrator. It's the place where logging should occur. : There sure doesn't seem to be a problem populating client environment : variables with connection info! : SSH_CLIENT='10.10.10.100 2926 22' : SSH_CONNECTION='10.10.10.100 2926 10.20.20.100 22' These environment variables are set up by sshd, not by a client. : I'm just asking why ssh can't do a basic sylog entry on a user like : "su". As i pointed out, the ssh client is the wrong spot to do the logging. The 'su' program is the right spot for its logging, because the system administrator can control what executables are owned by root and have setuid permissions, and because those are the only executables that are supposed to be able to grant a user additional privileges. That is, there are a limited number of entry points to what is effectively an 'su' service. The ssh client, however, is only one of a large possible number of entry points into the sshd service. : Maybe a ssh_config option that provides it for any ssh aware client : (sftp, scp, etc). Not all ssh clients read ssh_config. Not all ssh clients read the ssh_config file controlled by the system administrator. Not all ssh clients can be trusted to comply with options set in the system administrator's ssh_config. : And yes, your right, anyone can compile and run anything on any port. : (including the sshd daemon). Red herring. Users running sshd without root privileges can only acquire their own credentials. A system administrator can stop users from allowing remote connections to sshd processes they run using firewall/packet-filter rules. : I'm just talking about the probable 99% of users that use ssh : out-of-the-box. : The ssh client is always the starting point for most uses I'm aware of. What's your goal with this auditing? Are you trying to track 99% of the remote logins to your network, or 100%? If it's not 100%, you might as well write a wrapper script for your ssh/scp/sftp clients which does the logging and leave it at that. : There are plenty of log analysis packages and correlation tools (sec.pl) : that could take advantage of it. I guess I do not understand the : reluctance, especially considering the nature of the product. I'm not an OpenSSH developer (although I have contributed packaging, testing, and the x11-ssh-askpass program). I don't speak for the OpenSSH development team. I merely pointed out the flaws in your proposal. These flaws make it rather unlikely that the OpenSSH developers would incorporate your proposal into OpenSSH. Most folks who use OpenSSH don't want to rely on auditing that only leaves an audit trail for "dumb" people, letting attackers circumvent the auditing completely. I also made suggestions which take advantage of OpenSSH's current logging which would be more effective and require no code changes on your part. They would, however, require setting policies, which any network concerned with auditing ought to do anyway. : sshd server host syslog entry: : Apr 26 09:26:01 hostB sshd[11486]: : Accepted password for userB from 10.10.10.100 port 2926 ssh2 : : Could be anyone, can't even make a stab in the dark. Actually, setting up your firewall to log TCP packets containing a SYN flag destined for port 22 any host, together with the user ID of the process generating the packet, goes a long way toward correlating sshd's entry with a user on the source machine. Linux's iptables is capable of doing this with the LOG action and the '--log-uid' option. Or, if connections are coming only from machines you control, set up an ident server which you trust on those machines, and use TCP wrappers to log the response from identd. Even easier to configure. Both of these approaches capture information about every connection to sshd servers from inside your network, except for tunneled connections. In contrast, your approach captures only information from clients which cooperate with your logging scheme. Neither approach---nor your approach---is able to capture reliable information about connections from untrusted machines outside your network. Using public key authentication together with administrator-controlled authorized_keys files, however, allows you to capture information about which identity is used to log in via sshd's normal logging, in every case. You still need policies to keep users from sharing private keys and their passphrases, and to deal with subverted private keys. You need these same policies in any case, including with your approach, to keep users from sharing accounts and to deal with subverted user accounts. : Sounded like hack your own or go commercial or other options: : http://www.balabit.com/products/scb/ If you're willing to spring for something like the above, then fine ... but that sounds to me like you're moving from a skateboard directly to a rocket-propelled car. Not knowing more about your goals or requirements, i'd recommend trying something in the middle first. Good luck. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: 6F39C2CC >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC) +----------------------------------------------------------------------+ |[L]iberty, as we all know, cannot flourish in a country that is perma-| | nently on a war footing, or even a near-war footing. --Aldous Huxley| +----------------------------------------------------------------------+ From dtucker at zip.com.au Fri Apr 27 09:32:29 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 27 Apr 2007 09:32:29 +1000 Subject: chmod sftp command and setgid/setuid bit In-Reply-To: <462F78CE.3000803@psc.edu> References: <20070424232830.19675.qmail@cdy.org> <462F62EA.90509@psc.edu> <462F7081.6060706@zip.com.au> <462F78CE.3000803@psc.edu> Message-ID: <4631368D.40108@zip.com.au> Chris Rapier wrote: > Darren Tucker wrote: >> It's filexfer draft 3. There's no RFC for sftp. >> >> http://tools.ietf.org/html/draft-ietf-secsh-filexfer-03 Correction: that draft is sftp protocol version 4. Right now, according to "version" OpenSSH supports protocol version 3 which is filexfer-02. > I had been reading filexfer-13 - this one is much more straightforward. The other fun thing is that if a client reports that it implements filexfer-13, it must also handle 1-12 as well. During protocol initialization, the client tells the server what version it's using then the server replies with the lower of whatever it and the client support. After that they both must use whatever version the server selected. The upshot is that if the client claims to support v13, it must be prepared to process any lower version too; there's no way for the client to say "I support 1,2,3 or 13". (Within a single session, that is. In this example the client could potentially try 13 then abort if the server selects 4-12 and retry with 3 but that's kinda ugly.) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From jpv at vandyke.com Fri Apr 27 09:42:51 2007 From: jpv at vandyke.com (Jeff P. Van Dyke) Date: Thu, 26 Apr 2007 17:42:51 -0600 Subject: chmod sftp command and setgid/setuid bit References: <20070424232830.19675.qmail@cdy.org> <462F62EA.90509@psc.edu> <462F7081.6060706@zip.com.au><462F78CE.3000803@psc.edu> <4631368D.40108@zip.com.au> Message-ID: <000a01c7885c$a3b279a0$6501a8c0@gt> ----- Original Message ----- From: "Darren Tucker" To: "Chris Rapier" Cc: Sent: Thursday, April 26, 2007 5:32 PM Subject: Re: chmod sftp command and setgid/setuid bit > Chris Rapier wrote: > > Darren Tucker wrote: > >> It's filexfer draft 3. There's no RFC for sftp. > >> > >> http://tools.ietf.org/html/draft-ietf-secsh-filexfer-03 > > Correction: that draft is sftp protocol version 4. Right now, according to > "version" OpenSSH supports protocol version 3 which is filexfer-02. > >> I had been reading filexfer-13 - this one is much more straightforward. > > The other fun thing is that if a client reports that it implements filexfer-13, it > must also handle 1-12 as well. During protocol initialization, the client tells > the server what version it's using then the server replies with the lower of > whatever it and the client support. After that they both must use whatever > version the server selected. > > The upshot is that if the client claims to support v13, it must be prepared to > process any lower version too; there's no way for the client to say "I support > 1,2,3 or 13". (Within a single session, that is. In this example the client could > potentially try 13 then abort if the server selects 4-12 and retry with 3 but > that's kinda ugly.) As I recall, there is only v1-v6. the version didn't get bumped for each draft. --Jeff From dtucker at zip.com.au Fri Apr 27 10:15:52 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 27 Apr 2007 10:15:52 +1000 Subject: chmod sftp command and setgid/setuid bit In-Reply-To: <000a01c7885c$a3b279a0$6501a8c0@gt> References: <20070424232830.19675.qmail@cdy.org> <462F62EA.90509@psc.edu> <462F7081.6060706@zip.com.au><462F78CE.3000803@psc.edu> <4631368D.40108@zip.com.au> <000a01c7885c$a3b279a0$6501a8c0@gt> Message-ID: <463140B8.7080701@zip.com.au> Jeff P. Van Dyke wrote: > ----- Original Message ----- From: "Darren Tucker" [...] >> The upshot is that if the client claims to support v13, it must be >> prepared to process any lower version too; there's no way for the >> client to say "I support 1,2,3 or 13". (Within a single session, that >> is. In this example the client could potentially try 13 then abort if >> the server selects 4-12 and retry with 3 but that's kinda ugly.) > > As I recall, there is only v1-v6. the version didn't get bumped for each > draft. Fair enough, filexfer-13 is indeed protocol version 6. Thanks for the correction. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From Dave at Yost.com Fri Apr 27 09:28:05 2007 From: Dave at Yost.com (Dave Yost) Date: Thu, 26 Apr 2007 16:28:05 -0700 Subject: setting current dir of remote shell Message-ID: I have a command that will upload stuff from the current dir within a local copy of a web site to the corresponding dir on the web server. http://Yost.com/computers/yostupload The command has a -l argument that will log you in to the server via ssh. So far so good. But I would like this -l argument to set the current dir on the remote host so it is the dir corresponding to the current dir on the local host. I can't see how to do that with ssh, and if I try something like the following, ssh barfs. #!/bin/zsh ssh foo.com <<< cd website/bar/baz <& 0 Seems to me that it would be useful for ssh to have an optional parameter that specifies an initial command to execute in the remote shell before turning over control to the local user. I would use that option to run a cd command. Thanks Dave From dtucker at zip.com.au Fri Apr 27 11:29:50 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 27 Apr 2007 11:29:50 +1000 Subject: setting current dir of remote shell In-Reply-To: References: Message-ID: <4631520E.4080602@zip.com.au> Dave Yost wrote: > I have a command that will upload stuff from the current dir within a > local copy of a web site to the corresponding dir on the web server. > http://Yost.com/computers/yostupload > > The command has a -l argument that will log you in to the server via > ssh. So far so good. > > But I would like this -l argument to set the current dir on the > remote host so it is the dir corresponding to the current dir on the > local host. > I can't see how to do that with ssh, and if I try something like the > following, ssh barfs. > > #!/bin/zsh > > ssh foo.com <<< cd website/bar/baz <& 0 It's not exactly the same as a login shell but it's close: ssh -t someserver "(cd `pwd` && exec $SHELL -)" -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Fri Apr 27 11:35:40 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 27 Apr 2007 11:35:40 +1000 Subject: setting current dir of remote shell In-Reply-To: <4631520E.4080602@zip.com.au> References: <4631520E.4080602@zip.com.au> Message-ID: <4631536C.5030602@zip.com.au> Darren Tucker wrote: > It's not exactly the same as a login shell but it's close: > ssh -t someserver "(cd `pwd` && exec $SHELL -)" Actually, the () brackets aren't necessary either. ssh -t someserver "cd `pwd` && exec $SHELL -" -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Fri Apr 27 13:29:22 2007 From: djm at mindrot.org (Damien Miller) Date: Fri, 27 Apr 2007 13:29:22 +1000 (EST) Subject: SFTP and outstanding requests In-Reply-To: <4630D345.5000107@psc.edu> References: <462F7208.2010006@psc.edu> <462F7EBA.9090408@psc.edu> <4630D345.5000107@psc.edu> Message-ID: On Thu, 26 Apr 2007, Chris Rapier wrote: > Damien, > > Well, currently the default shouldn't be a problem in most any situation. As > far as I can tell it pretty much acts like a flow control buffer with (by > default) a 512K window (16x32k). So when you layer that on top of SSH's flow > control and on top of TCP's as long as its not the minimum value it shouldn't > act as a bottleneck. > > It does end up being problematic with the HPN patch (boosting it to 256 gave > me 32MB/s while before it was maxing out at 4MB/s) but I can address that, > probably, with user education. There is another, more complicated, method that > wouldn't tax low memory systems, but I'm not even going to think about that > until I get back. Did you measure the memory impact of increasing it? I'm not averse to cranking it up if it improves performance and doesn't have too much of an effect on memory use. > What I am curious about, and maybe you can help point me to the right > portion of the code, is what happens when transferring multiple files > in SFTP (SCP as well). If you look at outstanding data graphs (derived > by tcptrace from a tcpdump) it seems that between each file there is > something happening that causes the network to drain completely and > then there is a 2RTT pause before the next file gets sent out. I can > put a copy of the data somewhere if you want to look at it. If I can > get a better understanding of what is happening there I can at least > explain to my users why they should do a tar pipe if they have many > small files. There is a pipeline stall between each file because of the current client implementation. To fix this, sftp-client.c:do_(up|down)load really needs to be modified to accept a vector of files rather than a single file at a time. The other point where we waste round-trips in sftp is globbing. There are lots of round-trips there and (worse) the glob implementation we use throws away the Attrib data, which we then have to refetch (another round-trip per file). A while back, I posted these as part of a list of TODOs for sftp. It's a pity I wasn't more organised earlier in the year because they would have been excellent projects for Google's Summer of Code. -d From rapier at psc.edu Sat Apr 28 01:17:33 2007 From: rapier at psc.edu (Chris Rapier) Date: Fri, 27 Apr 2007 11:17:33 -0400 Subject: SFTP and outstanding requests In-Reply-To: References: <462F7208.2010006@psc.edu> <462F7EBA.9090408@psc.edu> <4630D345.5000107@psc.edu> Message-ID: <4632140D.2080201@psc.edu> > Did you measure the memory impact of increasing it? I'm not averse to > cranking it up if it improves performance and doesn't have too much of an > effect on memory use. Not as of yet. If I have a chance I'll try and get to that today. Personally, I don't think it will have an impact on memory in the current implementation because I'm not thinking you'll ever have that many default block sizes in transit. I'll try getting some memory stats using multiple block sizes and request values. Obviously I'm interested in this because of the impact on the HPN work I'm doing so I'll also be looking at that. If the memory impact is too high in heavily used servers I'll have to figure out some other methodology. >> What I am curious about, and maybe you can help point me to the right >> portion of the code, is what happens when transferring multiple files >> in SFTP (SCP as well). If you look at outstanding data graphs (derived >> by tcptrace from a tcpdump) it seems that between each file there is >> something happening that causes the network to drain completely and >> then there is a 2RTT pause before the next file gets sent out. I can >> put a copy of the data somewhere if you want to look at it. If I can >> get a better understanding of what is happening there I can at least >> explain to my users why they should do a tar pipe if they have many >> small files. > > There is a pipeline stall between each file because of the current client > implementation. To fix this, sftp-client.c:do_(up|down)load really > needs to be modified to accept a vector of files rather than a single > file at a time. Okay, this makes sense and I'll see if there is anything I can do there. Would there be any benefit to prepping multiple files as a single data stream and using a control channel to provide offsets and files data to rebuild the files on the far end? Mostly I'm just looking at keeping the data pipe as full as possible. Also, I see the same sort of behaviour in scp as well which is why I was looking at the ssh code. Is this mostly just due to similar methods being used in both clients? > The other point where we waste round-trips in sftp is globbing. There > are lots of round-trips there and (worse) the glob implementation we > use throws away the Attrib data, which we then have to refetch (another > round-trip per file). Interesting... I might look at this first. If I can reduce the number of RTTs even by 1 that would make a big difference in performance. > A while back, I posted these as part of a list of TODOs for sftp. It's > a pity I wasn't more organised earlier in the year because they would > have been excellent projects for Google's Summer of Code. Trust me I understand this. I had been planning on hiring a student this summer but I've had so much else going on that I just forgot about it until yesterday. Of course, I'll be gone for three weeks and by the time I get back all the students will have left :\ From bob at proulx.com Sat Apr 28 03:20:37 2007 From: bob at proulx.com (Bob Proulx) Date: Fri, 27 Apr 2007 11:20:37 -0600 Subject: setting current dir of remote shell In-Reply-To: <4631536C.5030602@zip.com.au> References: <4631520E.4080602@zip.com.au> <4631536C.5030602@zip.com.au> Message-ID: <20070427172037.GA5099@dementia.proulx.com> > Darren Tucker wrote: > It's not exactly the same as a login shell but it's close: > ... > ssh -t someserver "cd `pwd` && exec $SHELL -" If the shell supports it then the -l extension (e.g. bash) can enable it to be a login shell and then it would be the same. ssh -t someserver "cd $(pwd) && exec -l $SHELL" However that does make for a funny looking $0. echo $0 -/bin/bash For me the following works: ssh -t someserver "cd $(pwd) && exec -l \$0" $ echo $0 -bash Bob From Dave at Yost.com Sat Apr 28 05:40:47 2007 From: Dave at Yost.com (Dave Yost) Date: Fri, 27 Apr 2007 12:40:47 -0700 Subject: setting current dir of remote shell In-Reply-To: <20070427172037.GA5099@dementia.proulx.com> References: <4631520E.4080602@zip.com.au> <4631536C.5030602@zip.com.au> <20070427172037.GA5099@dementia.proulx.com> Message-ID: I assume you mean ssh -t someserver "cd $(pwd) && exec \$0 -l" This works well enough that I've updated yostupload to use it. http://Yost.com/computers/yostupload But is this the final word for ssh? Should there be a more formal facility that works for shells that don't support -l ? Thanks! Dave At 11:20 AM -0600 2007-04-27, Bob Proulx wrote: > > Darren Tucker wrote: >> It's not exactly the same as a login shell but it's close: >> ... >> ssh -t someserver "cd `pwd` && exec $SHELL -" > >If the shell supports it then the -l extension (e.g. bash) can enable >it to be a login shell and then it would be the same. > > ssh -t someserver "cd $(pwd) && exec -l $SHELL" > >However that does make for a funny looking $0. > > echo $0 > -/bin/bash > >For me the following works: > > ssh -t someserver "cd $(pwd) && exec -l \$0" > $ echo $0 > -bash > >Bob From stuge-openssh-unix-dev at cdy.org Sat Apr 28 11:39:47 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 28 Apr 2007 03:39:47 +0200 Subject: setting current dir of remote shell In-Reply-To: References: <4631520E.4080602@zip.com.au> <4631536C.5030602@zip.com.au> <20070427172037.GA5099@dementia.proulx.com> Message-ID: <20070428013947.11341.qmail@cdy.org> On Fri, Apr 27, 2007 at 12:40:47PM -0700, Dave Yost wrote: > Should there be a more formal facility that works for shells that > don't support -l ? Not in ssh IMHO. ssh is not a network filesystem. There are so many ways to send data from the client to the server; Environment variables, subsystems, custom commands... //Peter From dtucker at zip.com.au Sat Apr 28 13:06:33 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 28 Apr 2007 13:06:33 +1000 Subject: setting current dir of remote shell In-Reply-To: References: <4631520E.4080602@zip.com.au> <4631536C.5030602@zip.com.au> <20070427172037.GA5099@dementia.proulx.com> Message-ID: <4632BA39.9040605@zip.com.au> Dave Yost wrote: > I assume you mean > > ssh -t someserver "cd $(pwd) && exec \$0 -l" > > This works well enough that I've updated yostupload to use it. > http://Yost.com/computers/yostupload > > But is this the final word for ssh? > Should there be a more formal > facility that works for shells that don't support -l ? I don't think so. There's no mechanism in the protocol to explicitly specify the working directory on the server. There was one proposed on the IETF working group list but one problem is it would allow a user with a restricted shell to bypass the restriction on changing directories (and sshd has no reliable way of knowing a shell is restricted and preventing it). As Peter suggested you could use a "CWD" environment variable or similar passed over the SSH connection but that would still have the same problem. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From amine.salhi at gmail.com Fri Apr 27 00:37:39 2007 From: amine.salhi at gmail.com (Amine SALHI) Date: Thu, 26 Apr 2007 16:37:39 +0200 Subject: fail to build ssh Message-ID: hi everybody, when trying to cross compile openssh-4.6 i got the following error : --------------------- /opt/sparc-linux/bin/sparc-linux-ld -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o -L. -Lopenbsd-compat/ -L/opt/sparc-linux/lib -L/usr/src/SparcV8Linux/zlib-1.2.3-L/opt/sparc-linux/sparc-linux/sys-include/ -lssh -lopenbsd-compat -lresolv -lcrypto -lutil -lz -lnsl -ldl -lcrypt /opt/sparc-linux/bin/sparc-linux-ld.real: AVERTISSEMENT: ne peut trouver le symbole d'entr?e _start; utilise par d?faut 0000000000012200 readconf.o(.text+0x1014): In function `process_config_line': /usr/src/SparcV8Linux/openssh-4.6p1/readconf.c:527: undefined reference to `__muldi3' readconf.o(.text+0x1028):/usr/src/SparcV8Linux/openssh-4.6p1/readconf.c:529: undefined reference to `__divdi3' ./libssh.a(packet.o)(.text+0xab4): In function `set_newkeys': /usr/src/SparcV8Linux/openssh-4.6p1/packet.c:670: undefined reference to `__ashldi3' /opt/sparc-linux/lib/libcrypto.a(bn_div.o)(.text+0x264): In function `BN_div': : undefined reference to `__udivdi3' /opt/sparc-linux/lib/libcrypto.a(bn_word.o)(.text+0x264): In function `BN_mod_word': : undefined reference to `__umoddi3' /opt/sparc-linux/lib/libcrypto.a(b_print.o)(.text+0x3c4): In function `fmtint': : undefined reference to `__umoddi3' /opt/sparc-linux/lib/libcrypto.a(b_print.o)(.text+0x3fc): In function `fmtint': : undefined reference to `__udivdi3' make: *** [ssh] Erreur 1 ------------------- i have cross-compiled OpenSSL and istalled it but it didn't resolv the problem any suggestion? thx From dtucker at zip.com.au Sun Apr 29 11:53:30 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 29 Apr 2007 11:53:30 +1000 Subject: fail to build ssh In-Reply-To: References: Message-ID: <4633FA9A.6050206@zip.com.au> Amine SALHI wrote: > hi everybody, > when trying to cross compile openssh-4.6 i got the following error : > --------------------- > /opt/sparc-linux/bin/sparc-linux-ld -o ssh ssh.o readconf.o clientloop.o [...] > /usr/src/SparcV8Linux/openssh-4.6p1/readconf.c:527: undefined reference to > `__muldi3' These are gcc internal functions that are in libgcc, and the linker doesn't know to look there. Try using gcc to do the linking instead (eg LD=sparc-linux-gcc or similar) instead. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From stuge-openssh-unix-dev at cdy.org Sun Apr 29 11:56:47 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sun, 29 Apr 2007 03:56:47 +0200 Subject: fail to build ssh In-Reply-To: References: Message-ID: <20070429015647.29673.qmail@cdy.org> This has little to do with OpenSSH, but.. On Thu, Apr 26, 2007 at 04:37:39PM +0200, Amine SALHI wrote: > hi everybody, > when trying to cross compile openssh-4.6 i got the following error : > /opt/sparc-linux/bin/sparc-linux-ld.real: AVERTISSEMENT: ne peut > trouver le symbole d'entr?e _start; utilise par d?faut > 0000000000012200 It is always best to send error messages in english so that everyone can understand exactly what is going on. > /usr/src/SparcV8Linux/openssh-4.6p1/readconf.c:527: undefined > reference to `__muldi3' [..] > /opt/sparc-linux/lib/libcrypto.a(bn_div.o)(.text+0x264): In > function `BN_div': > : undefined reference to `__udivdi3' [..] > i have cross-compiled OpenSSL and istalled it but it didn't resolv > the problem Something is not right with your cross compilation setup, multiplication and division implementations seem to be missing.. //Peter From bob at proulx.com Mon Apr 30 10:25:58 2007 From: bob at proulx.com (Bob Proulx) Date: Sun, 29 Apr 2007 18:25:58 -0600 Subject: setting current dir of remote shell In-Reply-To: References: <4631520E.4080602@zip.com.au> <4631536C.5030602@zip.com.au> <20070427172037.GA5099@dementia.proulx.com> Message-ID: <20070430002558.GA29914@dementia.proulx.com> Dave Yost wrote: > Bob Proulx wrote: > >For me the following works: > > ssh -t someserver "cd $(pwd) && exec -l \$0" > > $ echo $0 > > -bash > > I assume you mean > > ssh -t someserver "cd $(pwd) && exec \$0 -l" No, I really did mean 'exec -l \$0'. Your transposition is similar and will have similar effects but is not identical. (Very close to though, and the difference is quite subtle.) help exec exec: exec [-cl] [-a name] file [redirection ...] Exec FILE, replacing this shell with the specified program. If FILE is not specified, the redirections take effect in this shell. If the first argument is '-l', then place a dash in the zeroth arg passed to FILE, as login does. If the '-c' option is supplied, FILE is executed with a null environment. The '-a' option means to make set argv[0] of the executed process to NAME. If the file cannot be executed and the shell is not interactive, then the shell exits, unless the shell option 'execfail' is set. The magic part is: "If the first argument is '-l', then place a dash in the zeroth arg passed to FILE, as login does." The classic /bin/login program has always placed a dash as the first character of the shell when starting up login shells. Shells inspect their first argument, their own name, and look for a '-' in the leading part of the name. If the shell finds a '-' there then they assume they were started by login and configure themselves as a login shell. Login shells read the defined list of environment files such as /etc/profile and others. The transposition of using 'exec \$0 -l' instead of 'exec -l \$0' won't place a dash in the leading part of the shell's name. Therefore the shell won't think it is a login in the same way that it would if it were really a login shell started by /bin/login. However the shell will by the -l option be told to behave as a login shell. At that point the shell will behave fully as a login shell and there is no difference. However if child programs want to deduce if the parent shell is a login shell or not they usually look at $0, as I did in my example, and look to see if the shell's name starts with a dash or not. This difference is probably insignificant but child processes won't be able to tell if the parent is a login shell in that case. The problem is that POSIX does not specify any options to exec and therefore use of 'exec -l' is non-standard by definition. I do not know which shells support it and which do not. Bash supports it and so if it is known to be working with bash then it is fine to use. But if it must be completely portable to unspecified shells then of course it would be a problem. Meanwhile, the very reason I like it is that 'exec -l $SOMESHELL' can spawn a random, unknown, unspecified shell as $SOMESHELL and guarantee that it will be a login shell even if $SOMESHELL does not take the -l option. Because of the /bin/login interface of placing a leading dash all shells will respect that interface. The classic csh is an example of a shell that does not accept a -l option to behave as a login shell. Therefore 'exec csh -l' would fail while 'exec -l csh' would succeed in producing csh running as a login shell. (I think newer csh variants have added the -l option for compatibility.) Bob From Dave at Yost.com Mon Apr 30 11:14:55 2007 From: Dave at Yost.com (Dave Yost) Date: Sun, 29 Apr 2007 18:14:55 -0700 Subject: setting current dir of remote shell In-Reply-To: <20070430002558.GA29914@dementia.proulx.com> References: <4631520E.4080602@zip.com.au> <4631536C.5030602@zip.com.au> <20070427172037.GA5099@dementia.proulx.com> <20070430002558.GA29914@dementia.proulx.com> Message-ID: Thanks for pointing out the subtleties of exec -l. But there's a problem. Zsh doesn't support exec -l but instead supports "zsh -l". Doing what you propose doesn't work when the remote shell is zsh. And doing it the way that works for remote zsh fails with remote bash. Is this the unsolvable problem it appears to be? Thanks again. Dave At 06:25 PM -0600 2007-04-29, Bob Proulx wrote: >Dave Yost wrote: >> Bob Proulx wrote: >> >For me the following works: >> > ssh -t someserver "cd $(pwd) && exec -l \$0" >> > $ echo $0 >> > -bash >> >> I assume you mean >> >> ssh -t someserver "cd $(pwd) && exec \$0 -l" > >No, I really did mean 'exec -l \$0'. Your transposition is similar >and will have similar effects but is not identical. (Very close to >though, and the difference is quite subtle.) > > help exec > exec: exec [-cl] [-a name] file [redirection ...] > Exec FILE, replacing this shell with the specified program. > If FILE is not specified, the redirections take effect in this > shell. If the first argument is '-l', then place a dash in the > zeroth arg passed to FILE, as login does. If the '-c' option > is supplied, FILE is executed with a null environment. The '-a' > option means to make set argv[0] of the executed process to NAME. > If the file cannot be executed and the shell is not interactive, > then the shell exits, unless the shell option 'execfail' is set. > >The magic part is: > > "If the first argument is '-l', then place a dash in the zeroth arg > passed to FILE, as login does." > >The classic /bin/login program has always placed a dash as the first >character of the shell when starting up login shells. Shells inspect >their first argument, their own name, and look for a '-' in the >leading part of the name. If the shell finds a '-' there then they >assume they were started by login and configure themselves as a login >shell. Login shells read the defined list of environment files such >as /etc/profile and others. > >The transposition of using 'exec \$0 -l' instead of 'exec -l \$0' >won't place a dash in the leading part of the shell's name. Therefore >the shell won't think it is a login in the same way that it would if >it were really a login shell started by /bin/login. However the shell >will by the -l option be told to behave as a login shell. At that >point the shell will behave fully as a login shell and there is no >difference. However if child programs want to deduce if the parent >shell is a login shell or not they usually look at $0, as I did in my >example, and look to see if the shell's name starts with a dash or >not. This difference is probably insignificant but child processes >won't be able to tell if the parent is a login shell in that case. > >The problem is that POSIX does not specify any options to exec and >therefore use of 'exec -l' is non-standard by definition. I do not >know which shells support it and which do not. Bash supports it and >so if it is known to be working with bash then it is fine to use. But >if it must be completely portable to unspecified shells then of course >it would be a problem. > >Meanwhile, the very reason I like it is that 'exec -l $SOMESHELL' can >spawn a random, unknown, unspecified shell as $SOMESHELL and guarantee >that it will be a login shell even if $SOMESHELL does not take the -l >option. Because of the /bin/login interface of placing a leading dash >all shells will respect that interface. The classic csh is an example >of a shell that does not accept a -l option to behave as a login >shell. Therefore 'exec csh -l' would fail while 'exec -l csh' would >succeed in producing csh running as a login shell. (I think newer csh >variants have added the -l option for compatibility.) > >Bob