From amcintosh at atreus-systems.com Wed May 1 04:27:35 2002 From: amcintosh at atreus-systems.com (Allan McIntosh) Date: Tue, 30 Apr 2002 13:27:35 -0500 (CDT) Subject: SSH client, dup, pty. In-Reply-To: Message-ID: >You probably haven't set the controlling terminal, have a look at >Stevens _Advanced Programming in the Unix Environment_ or I have done so. I created the pty how ever, I am trying to control the ssh session from the parent. IE write the password through the pty, execute commands and log out. Essentially, I want don't want to interact with the ssh session via the key board. I'll revisit it. Thanks -- ------------------------------------------------------------------ Allan McIntosh, Software Designer http://www.atreus-systems.com Phone: (613) 233-1741, (800) 764-5514 Ext 217 ------------------------------------------------------------------ From mstsurvey at yahoo.com Wed May 1 05:32:16 2002 From: mstsurvey at yahoo.com (Chris Nunez) Date: Tue, 30 Apr 2002 12:32:16 -0700 Subject: Introducing MultiSensit SDK Message-ID: <200204301930.g3UJU2860478@postoffice.telstra.net>

www.mstcorporation.com
info at mstcorporation.com

To be removed from our list please reply with "remove" in the subject line. We will immediately update our list accordingly. From djm at mindrot.org Wed May 1 10:31:50 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 1 May 2002 10:31:50 +1000 (EST) Subject: SSH client, dup, pty. In-Reply-To: Message-ID: On Tue, 30 Apr 2002, Allan McIntosh wrote: > > > >You probably haven't set the controlling terminal, have a look at > >Stevens _Advanced Programming in the Unix Environment_ or > > I have done so. I created the pty how ever, I am trying to control the ssh > session from the parent. IE write the password through the pty, execute > commands and log out. Essentially, I want don't want to interact with the > ssh session via the key board. dupping stdio to the pty may not be enough. Are you doing a TIOCSCTTY or similar? -d From bugzilla-daemon at mindrot.org Wed May 1 17:52:51 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 1 May 2002 17:52:51 +1000 (EST) Subject: [Bug 230] UsePrivilegeSeparation turns off Banner. Message-ID: <20020501075251.C16A7E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=230 ------- Additional Comments From krh at lemniscate.net 2002-05-01 17:52 ------- The patch does not apply cleanly to any snapshot between April 27 and April 30. Applying it by hand doesn't help, because whether or not I do that, the compile fails with: readpassphrase.c: In function `handler': readpassphrase.c:183: `signo' undeclared (first use in this function) readpassphrase.c:183: (Each undeclared identifier is reported only once readpassphrase.c:183: for each function it appears in.) readpassphrase.c: At top level: readpassphrase.c:181: warning: `handler' defined but not used ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From lhecking at nmrc.ie Wed May 1 20:35:31 2002 From: lhecking at nmrc.ie (Lars Hecking) Date: Wed, 1 May 2002 11:35:31 +0100 Subject: scp 3.1p1 problem on Solaris Message-ID: <20020501103531.GA4360@nmrc.ie> I have removed ANDIrand from my Solaris8 system and installed patch 112438-01 which provides native /dev/random and /dev/urandom devices. Recompiled both openssl-0.9.6c and openssh-3.1p1, restarted sshd. Now I seem unable to use scp, and connections to the local sshd appear to be very slow. $ scp php-4.2.0.tar.gz user at remote:/WWWserv/src local at bastion's password: php-4.2.0.tar.gz 6% |* | 224 KB - stalled - When I'm trussing this scp process, I find that the following output repeats over and over at some stage: ... Received signal #14, SIGALRM, in write() [caught] write(7, " AF8 d >FF z y 9FF02 z x".., 8192) = 5120 ioctl(1, TIOCGSID, 0xFFBEDE34) = 0 getsid(0) = 508 ioctl(1, TIOCGPGRP, 0xFFBEDE9C) = 0 ioctl(1, TIOCGWINSZ, 0xFFBEDEF8) = 0 write(1, "\r p h p - 4 . 2 . 0 . t".., 80) = 80 sigaction(SIGALRM, 0xFFBEDFF8, 0xFFBEE078) = 0 alarm(1) = 0 setcontext(0xFFBEE1E8) ... Has anyone seens this before? Is openssh at fault here, or is it openssl? openssh configure: --prefix=/opt/ssh --without-rpath --sysconfdir=/etc . (Still not on this list; please Cc: replies :) From bugzilla-daemon at mindrot.org Wed May 1 22:02:48 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 1 May 2002 22:02:48 +1000 (EST) Subject: [Bug 230] UsePrivilegeSeparation turns off Banner. Message-ID: <20020501120248.26D7DE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=230 ------- Additional Comments From djm at mindrot.org 2002-05-01 22:02 ------- Thanks - the fix for that will be in the next snapshot. If you are impatient, you can edit openbsd-compat/readpassphrase.c and move the "#endif" from below the readpassphase() function (~line 168) to the end of the file. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djm at mindrot.org Wed May 1 22:07:06 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 1 May 2002 22:07:06 +1000 (EST) Subject: scp 3.1p1 problem on Solaris In-Reply-To: <20020501103531.GA4360@nmrc.ie> Message-ID: On Wed, 1 May 2002, Lars Hecking wrote: > > I have removed ANDIrand from my Solaris8 system and installed patch > 112438-01 which provides native /dev/random and /dev/urandom devices. > Recompiled both openssl-0.9.6c and openssh-3.1p1, restarted sshd. > > Now I seem unable to use scp, and connections to the local sshd appear > to be very slow. > > $ scp php-4.2.0.tar.gz user at remote:/WWWserv/src > local at bastion's password: > php-4.2.0.tar.gz 6% |* | 224 KB - stalled - > > When I'm trussing this scp process, I find that the following > output repeats over and over at some stage: > > ... > Received signal #14, SIGALRM, in write() [caught] > write(7, " AF8 d >FF z y 9FF02 z x".., 8192) = 5120 > ioctl(1, TIOCGSID, 0xFFBEDE34) = 0 > getsid(0) = 508 > ioctl(1, TIOCGPGRP, 0xFFBEDE9C) = 0 > ioctl(1, TIOCGWINSZ, 0xFFBEDEF8) = 0 > write(1, "\r p h p - 4 . 2 . 0 . t".., 80) = 80 > sigaction(SIGALRM, 0xFFBEDFF8, 0xFFBEE078) = 0 > alarm(1) = 0 > setcontext(0xFFBEE1E8) > ... This is just the progress meter periodically updating, which will happen regardless of data flow. You need to see why the connection stalls. Does a FTP connection stall between the two hosts? If no, you should try "scp -v -v -v xxxx yy:zzzz" to turn on full debugging. -d From dtucker at zip.com.au Wed May 1 22:30:56 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 01 May 2002 22:30:56 +1000 Subject: scp 3.1p1 problem on Solaris References: <20020501103531.GA4360@nmrc.ie> Message-ID: <3CCFE000.516AB24D@zip.com.au> Lars Hecking wrote: > I have removed ANDIrand from my Solaris8 system and installed patch > 112438-01 which provides native /dev/random and /dev/urandom devices. > Recompiled both openssl-0.9.6c and openssh-3.1p1, restarted sshd. You did reboot it, right? The patch installs a kernel driver and touches /reconfigure. Try ls -l /dev/*rand* and see if the devices really are there. -Daz. From lhecking at nmrc.ie Wed May 1 23:54:40 2002 From: lhecking at nmrc.ie (Lars Hecking) Date: Wed, 1 May 2002 14:54:40 +0100 Subject: scp 3.1p1 problem on Solaris In-Reply-To: <3CCFE000.516AB24D@zip.com.au> References: <20020501103531.GA4360@nmrc.ie> <3CCFE000.516AB24D@zip.com.au> Message-ID: <20020501135440.GA4793@nmrc.ie> Darren Tucker writes: > Lars Hecking wrote: > > I have removed ANDIrand from my Solaris8 system and installed patch > > 112438-01 which provides native /dev/random and /dev/urandom devices. > > Recompiled both openssl-0.9.6c and openssh-3.1p1, restarted sshd. > > You did reboot it, right? The patch installs a kernel driver and touches > /reconfigure. Try ls -l /dev/*rand* and see if the devices really are > there. Yes and yes. I am quite familiar with patch-application and related procedures :-) In this case, I was applying the recommended patch cluster plus 112438-01 after an upgrade to Sol8 02/02. From dtucker at zip.com.au Thu May 2 00:25:07 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 02 May 2002 00:25:07 +1000 Subject: scp 3.1p1 problem on Solaris References: <20020501103531.GA4360@nmrc.ie> <3CCFE000.516AB24D@zip.com.au> <20020501135440.GA4793@nmrc.ie> Message-ID: <3CCFFAC3.802B6FF@zip.com.au> Lars Hecking wrote: > Darren Tucker writes: [snip] > > You did reboot it, right? [snip] > Yes and yes. I am quite familiar with patch-application and related > procedures :-) In this case, I was applying the recommended patch cluster > plus 112438-01 after an upgrade to Sol8 02/02. Okedokee. I asked because you didn't mention it. The patch readme doesn't actually say you have to either. I've had good results even without recompiling, but I previously used the ssh built-in prng. I installed the patch (and rebooted!) and sshd then started immediately instead of hanging for a couple of minutes. -Daz. From lhecking at nmrc.ie Thu May 2 01:24:47 2002 From: lhecking at nmrc.ie (Lars Hecking) Date: Wed, 1 May 2002 16:24:47 +0100 Subject: scp 3.1p1 problem on Solaris In-Reply-To: References: <20020501103531.GA4360@nmrc.ie> Message-ID: <20020501152447.GA820@nmrc.ie> > This is just the progress meter periodically updating, which will happen > regardless of data flow. > > You need to see why the connection stalls. Does a FTP connection stall > between the two hosts? If no, you should try "scp -v -v -v xxxx yy:zzzz" > to turn on full debugging. Thanks for hitting the nail on the head - I should have checked beforehand. The problem is not related to either openssh or openssl, sorry for bothering you all. The machine came back in 100MBs hdx mode after reboot despite being explicitly configured to 100fdx. No matter what /var/adm/messages and ndd are telling you at which speed the network interface runs, they're lying. Stay away from Cisco switches if you have Sun workstations with hme interfaces. From ed at UDel.Edu Thu May 2 02:00:05 2002 From: ed at UDel.Edu (Ed Phillips) Date: Wed, 1 May 2002 12:00:05 -0400 (EDT) Subject: scp 3.1p1 problem on Solaris In-Reply-To: <3CCFFAC3.802B6FF@zip.com.au> Message-ID: On Thu, 2 May 2002, Darren Tucker wrote: > Date: Thu, 02 May 2002 00:25:07 +1000 > From: Darren Tucker > To: Lars Hecking > Cc: openssh-unix-dev at mindrot.org > Subject: Re: scp 3.1p1 problem on Solaris > > Lars Hecking wrote: > > Darren Tucker writes: > [snip] > > > You did reboot it, right? > [snip] > > Yes and yes. I am quite familiar with patch-application and related > > procedures :-) In this case, I was applying the recommended patch cluster > > plus 112438-01 after an upgrade to Sol8 02/02. > > Okedokee. I asked because you didn't mention it. The patch readme > doesn't actually say you have to either. During the patch installation, it prints out a message that tells you to reboot. > I've had good results even without recompiling, but I previously used > the ssh built-in prng. I installed the patch (and rebooted!) and sshd > then started immediately instead of hanging for a couple of minutes. FWIW, it should "just work". Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From rodgers at nlm.nih.gov Thu May 2 06:02:42 2002 From: rodgers at nlm.nih.gov (R. P. Channing Rodgers, M.D.) Date: Wed, 1 May 2002 16:02:42 -0400 (EDT) Subject: Using openssh 3.1p1 on Solaris with tcp wrappers 7.6 Message-ID: <200205012002.g41K2gA04532@billings.nlm.nih.gov> Dear Open SSH and TCP Wrappers Colleagues, We are trying to use open ssh 3.1p1 on SPARC platforms under Solaris 2.8 using gcc 2.95.2, in conjunction with tcp wrappers 7.6 (IPv6 version). The wrapping of open ssh is not too well documented but I think we have figured most of this out (hearty thanks to Wietse Venema, Jim Mintha & Niels Provos for their helpful email exchanges) -- but have one final question. Tcp wrappers can send out banner messages in response to various network service requests. The Banners.makefile that is used to create the various banner files from a prototype (inserting any special content that a particular service protocol such as ftp might require) does contain this comment: # Other services: banners may interfere with normal operation # so they should probably be used only when refusing service. # In particular, banners don't work with standard rsh daemons. # You would have to use an rshd that has built-in tcp wrapper # support, for example the rshd that is part of the logdaemon # utilities. And there is no target to create a sshd banner. Is there a mechanism in open ssh, when using tcp wrappers, to support a banner? Thanks in advance for any helpful insights. We would be happy to share our installation instructions for both systems and welcome comments about the most efficient way in which we might do so. Cheerio, Rick Rodgers From bugzilla-daemon at mindrot.org Thu May 2 06:05:37 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 2 May 2002 06:05:37 +1000 (EST) Subject: [Bug 231] New: ssh-keygen has fatal error while updating comment in RSA1 key Message-ID: <20020501200537.DD605E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=231 Summary: ssh-keygen has fatal error while updating comment in RSA1 key Product: Portable OpenSSH Version: 3.1p1 Platform: HPPA OS/Version: HP-UX Status: NEW Severity: normal Priority: P2 Component: ssh-keygen AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: rusr at cup.hp.com ssh-keygen reports a fatal error while trying to update the comment field of an RSA1 key. The error reported is "Couldn't obtain random bytes (error 604389476)" This happens because somewhere between 3.0.2p1 and 3.1p1 (the two versions I examined), the calls to the init_rng() and seed_rng() in the main function got moved from near the beginning of the function to after where all the options are processed. The function do_change_comment() handles the comment changing and is called during option processing. do_change_comment() calls a function save the key file, which uses the random number generator, which has not been initialized or seeded and therefore the random number generator reports an error. The simplest fix, in my opinion, is to move the calls to init_rng() and seed_rng () back to the beginning of the main function so the random number generator is always ready to be used. Since this program is not often called, the performance impact is negligible. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mouring at etoh.eviladmin.org Thu May 2 06:08:01 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 1 May 2002 15:08:01 -0500 (CDT) Subject: Using openssh 3.1p1 on Solaris with tcp wrappers 7.6 In-Reply-To: <200205012002.g41K2gA04532@billings.nlm.nih.gov> Message-ID: What is wrong with the native 'Banner' option within OpenSSH? V2 protocol allows a banner to be presented. - Ben On Wed, 1 May 2002, R. P. Channing Rodgers, M.D. wrote: > > Dear Open SSH and TCP Wrappers Colleagues, > > We are trying to use open ssh 3.1p1 on SPARC platforms > under Solaris 2.8 using gcc 2.95.2, in conjunction with > tcp wrappers 7.6 (IPv6 version). The wrapping of open ssh > is not too well documented but I think we have figured > most of this out (hearty thanks to Wietse Venema, Jim > Mintha & Niels Provos for their helpful email exchanges) -- > but have one final question. Tcp wrappers can send out > banner messages in response to various network service > requests. The Banners.makefile that is used to create > the various banner files from a prototype (inserting any > special content that a particular service protocol such > as ftp might require) does contain this comment: > > # Other services: banners may interfere with normal operation > # so they should probably be used only when refusing service. > # In particular, banners don't work with standard rsh daemons. > # You would have to use an rshd that has built-in tcp wrapper > # support, for example the rshd that is part of the logdaemon > # utilities. > > And there is no target to create a sshd banner. Is there > a mechanism in open ssh, when using tcp wrappers, to > support a banner? Thanks in advance for any helpful > insights. > > We would be happy to share our installation instructions > for both systems and welcome comments about the most > efficient way in which we might do so. > > Cheerio, Rick Rodgers > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From wietse at porcupine.org Thu May 2 06:15:42 2002 From: wietse at porcupine.org (Wietse Venema) Date: Wed, 1 May 2002 16:15:42 -0400 (EDT) Subject: Using openssh 3.1p1 on Solaris with tcp wrappers 7.6 In-Reply-To: <200205012002.g41K2gA04532@billings.nlm.nih.gov> "from R. P. Channing Rodgers, M.D. at May 1, 2002 04:02:42 pm" Message-ID: <20020501201542.CDB95BC078@spike.porcupine.org> There is no official mechanism for sending SSH banners that I am aware of. I once did a little hack in the SSH client to allow for additional text, newline terminated, that is sent prior to the SSH server version string. The banner would of course break generic clients. Wietse R. P. Channing Rodgers, M.D.: > > Dear Open SSH and TCP Wrappers Colleagues, > > We are trying to use open ssh 3.1p1 on SPARC platforms > under Solaris 2.8 using gcc 2.95.2, in conjunction with > tcp wrappers 7.6 (IPv6 version). The wrapping of open ssh > is not too well documented but I think we have figured > most of this out (hearty thanks to Wietse Venema, Jim > Mintha & Niels Provos for their helpful email exchanges) -- > but have one final question. Tcp wrappers can send out > banner messages in response to various network service > requests. The Banners.makefile that is used to create > the various banner files from a prototype (inserting any > special content that a particular service protocol such > as ftp might require) does contain this comment: > > # Other services: banners may interfere with normal operation > # so they should probably be used only when refusing service. > # In particular, banners don't work with standard rsh daemons. > # You would have to use an rshd that has built-in tcp wrapper > # support, for example the rshd that is part of the logdaemon > # utilities. > > And there is no target to create a sshd banner. Is there > a mechanism in open ssh, when using tcp wrappers, to > support a banner? Thanks in advance for any helpful > insights. > > We would be happy to share our installation instructions > for both systems and welcome comments about the most > efficient way in which we might do so. > > Cheerio, Rick Rodgers > From mouring at etoh.eviladmin.org Thu May 2 06:14:47 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 1 May 2002 15:14:47 -0500 (CDT) Subject: Using openssh 3.1p1 on Solaris with tcp wrappers 7.6 In-Reply-To: <20020501201542.CDB95BC078@spike.porcupine.org> Message-ID: SSH Protocol 2 added the ability to send a banner. - Ben On Wed, 1 May 2002, Wietse Venema wrote: > There is no official mechanism for sending SSH banners that I am > aware of. > > I once did a little hack in the SSH client to allow for additional > text, newline terminated, that is sent prior to the SSH server > version string. The banner would of course break generic clients. > > Wietse > > R. P. Channing Rodgers, M.D.: > > > > Dear Open SSH and TCP Wrappers Colleagues, > > > > We are trying to use open ssh 3.1p1 on SPARC platforms > > under Solaris 2.8 using gcc 2.95.2, in conjunction with > > tcp wrappers 7.6 (IPv6 version). The wrapping of open ssh > > is not too well documented but I think we have figured > > most of this out (hearty thanks to Wietse Venema, Jim > > Mintha & Niels Provos for their helpful email exchanges) -- > > but have one final question. Tcp wrappers can send out > > banner messages in response to various network service > > requests. The Banners.makefile that is used to create > > the various banner files from a prototype (inserting any > > special content that a particular service protocol such > > as ftp might require) does contain this comment: > > > > # Other services: banners may interfere with normal operation > > # so they should probably be used only when refusing service. > > # In particular, banners don't work with standard rsh daemons. > > # You would have to use an rshd that has built-in tcp wrapper > > # support, for example the rshd that is part of the logdaemon > > # utilities. > > > > And there is no target to create a sshd banner. Is there > > a mechanism in open ssh, when using tcp wrappers, to > > support a banner? Thanks in advance for any helpful > > insights. > > > > We would be happy to share our installation instructions > > for both systems and welcome comments about the most > > efficient way in which we might do so. > > > > Cheerio, Rick Rodgers > > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From Darren.Moffat at Sun.COM Thu May 2 06:21:37 2002 From: Darren.Moffat at Sun.COM (Darren Moffat) Date: Wed, 1 May 2002 13:21:37 -0700 (PDT) Subject: Using openssh 3.1p1 on Solaris with tcp wrappers 7.6 Message-ID: <200205012021.g41KLaJe010477@jurassic.eng.sun.com> I suspect you answers are in reference to version 1 of the protocol, since v2 has solutions for both of the things you raise. >There is no official mechanism for sending SSH banners that I am >aware of. draft-ietf-secsh-userauth-15.txt Section 2.5 >I once did a little hack in the SSH client to allow for additional >text, newline terminated, that is sent prior to the SSH server >version string. The banner would of course break generic clients. draft-ietf-secsh-transport-14.txt Section 3.2 The server MAY send other lines of data before sending the version string. Each line SHOULD be terminated by a carriage return and newline. Such lines MUST NOT begin with "SSH-", and SHOULD be encoded in ISO-10646 UTF-8 [RFC2279] (language is not specified). Clients MUST be able to process such lines; they MAY be silently ignored, or MAY be displayed to the client user; if they are displayed, control character filtering discussed in [SSH-ARCH] SHOULD be used. The primary use of this feature is to allow TCP-wrappers to display an error message before disconnecting. -- Darren J Moffat From wietse at porcupine.org Thu May 2 06:24:55 2002 From: wietse at porcupine.org (Wietse Venema) Date: Wed, 1 May 2002 16:24:55 -0400 (EDT) Subject: Using openssh 3.1p1 on Solaris with tcp wrappers 7.6 In-Reply-To: <200205012021.g41KLaJe010477@jurassic.eng.sun.com> "from Darren Moffat at May 1, 2002 01:21:37 pm" Message-ID: <20020501202455.CFC3EBC078@spike.porcupine.org> Cool. Wietse Darren Moffat: > I suspect you answers are in reference to version 1 of the protocol, > since v2 has solutions for both of the things you raise. > > >There is no official mechanism for sending SSH banners that I am > >aware of. > > draft-ietf-secsh-userauth-15.txt Section 2.5 > > >I once did a little hack in the SSH client to allow for additional > >text, newline terminated, that is sent prior to the SSH server > >version string. The banner would of course break generic clients. > > draft-ietf-secsh-transport-14.txt Section 3.2 > > The server MAY send other lines of data before sending the version > string. Each line SHOULD be terminated by a carriage return and > newline. Such lines MUST NOT begin with "SSH-", and SHOULD be > encoded in ISO-10646 UTF-8 [RFC2279] (language is not specified). > Clients MUST be able to process such lines; they MAY be silently > ignored, or MAY be displayed to the client user; if they are > displayed, control character filtering discussed in [SSH-ARCH] SHOULD > be used. The primary use of this feature is to allow TCP-wrappers to > display an error message before disconnecting. > > > > -- > Darren J Moffat > > From bugzilla-daemon at mindrot.org Thu May 2 07:56:38 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 2 May 2002 07:56:38 +1000 (EST) Subject: [Bug 232] New: 3.1p1 does not make Message-ID: <20020501215638.A4226E8FF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=232 Summary: 3.1p1 does not make Product: Portable OpenSSH Version: 3.1p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: general_anders at hotmail.com I am running RedHat 7.2, on Intel. ./configure runs fine, but make gives me error 1. Here's what I get: (cd openbsd-compat && make) make[1]: Entering directory `/home/aolserver/openssh-3.1p1/openbsd-compat' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/aolserver/openssh-3.1p1/openbsd-compat' gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. - I/usr/local/ssl/include -DSSHDIR=\"/usr/local/etc\" - D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" - D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" - D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" - D_PATH_SSH_PIDDIR=\"/var/run\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand- helper\" -DHAVE_CONFIG_H -c cipher.c cipher.c: In function `cipher_init': cipher.c:200: void value not ignored as it ought to be cipher.c:206: warning: implicit declaration of function `EVP_CIPHER_CTX_set_key_length' cipher.c:210: void value not ignored as it ought to be cipher.c: In function `cipher_crypt': cipher.c:220: void value not ignored as it ought to be cipher.c: In function `cipher_cleanup': cipher.c:227: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_init': cipher.c:280: warning: assignment from incompatible pointer type cipher.c:299: void value not ignored as it ought to be cipher.c:300: void value not ignored as it ought to be cipher.c:301: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cbc': cipher.c:314: warning: assignment from incompatible pointer type cipher.c:318: void value not ignored as it ought to be cipher.c:319: void value not ignored as it ought to be cipher.c:320: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cleanup': cipher.c:329: warning: assignment from incompatible pointer type cipher.c: In function `evp_ssh1_3des': cipher.c:346: warning: assignment from incompatible pointer type cipher.c:347: warning: assignment from incompatible pointer type cipher.c:348: warning: assignment from incompatible pointer type cipher.c:349: structure has no member named `flags' cipher.c:349: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:349: (Each undeclared identifier is reported only once cipher.c:349: for each function it appears in.) cipher.c:349: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c: In function `evp_ssh1_bf': cipher.c:392: warning: assignment from incompatible pointer type cipher.c:394: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_init': cipher.c:413: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cbc': cipher.c:440: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cleanup': cipher.c:477: warning: assignment from incompatible pointer type cipher.c: In function `evp_rijndael': cipher.c:494: warning: assignment from incompatible pointer type cipher.c:495: warning: assignment from incompatible pointer type cipher.c:496: warning: assignment from incompatible pointer type cipher.c:497: structure has no member named `flags' cipher.c:497: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:497: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c:498: `EVP_CIPH_ALWAYS_CALL_INIT' undeclared (first use in this function) make: *** [cipher.o] Error 1 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djm at mindrot.org Thu May 2 10:07:09 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 2 May 2002 10:07:09 +1000 (EST) Subject: Administrivia Message-ID: You have probably noticed the steady stream of Outlook viruses that have been appearing on the mailing list. To stem this flow somewhat, I have reduced the maxiumum message size of the list back to 40kb - most of these viruses create messages greater than 100kb. If you have large patches or logs, please post them on a website somewhere and send a URL. Apologies for any hassle that this creates for anyone. Regards, Damien Miller From bugzilla-daemon at mindrot.org Thu May 2 14:41:35 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 2 May 2002 14:41:35 +1000 (EST) Subject: [Bug 230] UsePrivilegeSeparation turns off Banner. Message-ID: <20020502044135.04B9FE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=230 krh at lemniscate.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From krh at lemniscate.net 2002-05-02 14:41 ------- Well, to get the May 1 snapshot to compile, I had to edit config.h and manually undefine HAVE_READPASSPHRASE, and I had to edit readpass.c and include openbsd-compat/readpassphrase.h. Otherwise the compile fails at readpass.c:101 with RPP_ECHO_{ON,OFF} and RPP_REQUIRE_TTY undefined. But once I did that (and I'm sure it's not the Right Thing, because sshd didn't recognize the keywords KerberosAuthentication and AFSTokenPassing in sshd_config), everything compiled and Banner worked with UsePrivilegeSeparation. Thanks! ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu May 2 16:19:54 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 2 May 2002 16:19:54 +1000 (EST) Subject: [Bug 230] UsePrivilegeSeparation turns off Banner. Message-ID: <20020502061954.89AF6E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=230 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From djm at mindrot.org 2002-05-02 16:19 ------- I'll reopen the bug until the fix gets committed. Could you please file a seperate bug for the readpassphrase problem? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu May 2 17:38:47 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 2 May 2002 17:38:47 +1000 (EST) Subject: [Bug 233] New: could we please learn how to spell the word license Message-ID: <20020502073847.08832E8EA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=233 Summary: could we please learn how to spell the word license Product: Portable OpenSSH Version: 3.0.2p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Documentation AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: ian at ians.net the license distributed with openssh is contained in a file named 'LICENCE'. the proper spelling of the word is 'LICENSE'. in the LICENCE file the word is spelled both correctly and incorrectly. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu May 2 19:44:19 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 2 May 2002 19:44:19 +1000 (EST) Subject: [Bug 233] could we please learn how to spell the word license Message-ID: <20020502094419.36A12E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=233 ------- Additional Comments From dtucker at zip.com.au 2002-05-02 19:44 ------- dictionary.com lists "licence" as a variant of "license" according to The American Heritage Dictionary (go check, we'll wait). It's listed as chiefly British but both variants are commonly used in Australia (and, I suspect, Canada). Inconsistent? Yes. Incorrect? No. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From pgl at yoyo.org Thu May 2 21:37:02 2002 From: pgl at yoyo.org (Peter Lowe) Date: Thu, 2 May 2002 12:37:02 +0100 Subject: Request: Please incorporate Hideaki Gotos Watchdog patch into OpenSSH Message-ID: <20020502113702.GA35691@yoyo.org> Hello, Hideaki Goto has written a patch for OpenSSH that adds heartbeat and watchdog functions to OpenSSH: http://www.sc.isc.tohoku.ac.jp/~hgot/sources/openssh-watchdog.html The heartbeat function sends an SSH_MSG_IGNORE packet every seconds to the server, and the watchdog function checks incoming packets only to see if the connection has been interrupted. Where I work, all Internet connections go through an HTTPS proxy. Without this patch, I wouldn't be able to stay connected to any outside servers at all, because the proxy's timeout is about 30 seconds. Please incorporate this patch into OpenSSH proper -- it's very very useful. I'm sure there are plenty of people in the same situation that would benefit from it. regards, Peter Lowe. -- Litres of beer drunk in the Czech Republic so far this year: 5923793.26 http://yoyo.org/~pgl/beer/ From yoshfuji at linux-ipv6.org Thu May 2 22:31:11 2002 From: yoshfuji at linux-ipv6.org (YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) Date: Thu, 02 May 2002 21:31:11 +0900 Subject: problem with X11 forwarding and use_localhost on Linux (solution) (fwd) In-Reply-To: References: Message-ID: <20020502213111U.yoshfuji@linux-ipv6.org> Hi, I think we should try other AF for "x11_use_localhost" case. --- openssh-3.1p1/channels.c Tue Mar 5 10:57:45 2002 +++ openssh-3.1p1-fix/channels.c Thu May 2 21:26:28 2002 @@ -2356,6 +2356,13 @@ continue; } } +#ifdef IPV6_V6ONLY + if (ai->ai_family == AF_INET6) { + int on = 1; + if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, &on, sizeof(on)) < 0) + debug("x11_create_display_inet: setsockopt(IPV6_V6ONLY) failed."); + } +#endif if (bind(sock, ai->ai_addr, ai->ai_addrlen) < 0) { debug("bind port %d: %.100s", port, strerror(errno)); close(sock); @@ -2374,7 +2381,12 @@ if (num_socks == NUM_SOCKS) break; #else - break; + if (x11_use_localhost) { + if (num_socks == NUM_SOCKS) + break; + } else { + break; + } #endif } freeaddrinfo(aitop); In article (at Tue, 30 Apr 2002 13:35:52 -0700 (PDT)), Kevin Steves says: > itojun, > > do you have any recommendations on this? > > http://bugzilla.mindrot.org/show_bug.cgi?id=164 > > ---------- Forwarded message ---------- > Date: Mon, 29 Apr 2002 11:32:21 +0200 > From: Stig Venaas > To: Kevin Steves > Cc: openssh-unix-dev at mindrot.org > Subject: Re: problem with X11 forwarding and use_localhost on Linux > (solution) > > On Thu, Apr 25, 2002 at 10:09:40AM -0700, Kevin Steves wrote: > > : #else > > :- break; > > :+ if (!x11_use_localhost || num_socks == NUM_SOCKS) > > :+ break; > > : #endif > > : } > > : freeaddrinfo(aitop); > > > > this is what is in: > > http://bugzilla.mindrot.org/show_bug.cgi?id=164 > > Right, I should have checked there. > > > i still don't understand exactly why DONT_TRY_OTHER_AF is needed? > > It's needed because if you first bind an IPv6 socket to the ANY address, > then subsequent IPv4 bind will fail on Linux. You could of course remove > DONT_TRY_OTHER_AF, but then you need to ignore the error on the IPv4 bind > call. Currently it will clean up (closing the already opened IPv6 socket), > and then try the next display (which will again fail) until MAX_DISPLAYS > is reached, and it will then simply fail. If the code for the ANY case > was separated from the x11_use_localhost case, you would only need > DONT_TRY_OTHER_AF in the ANY part, that is the only part where Linux is > different from *BSD. > > Stig > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From bugzilla-daemon at mindrot.org Thu May 2 23:25:25 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 2 May 2002 23:25:25 +1000 (EST) Subject: [Bug 233] could we please learn how to spell the word license Message-ID: <20020502132525.A9396E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=233 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From mouring at eviladmin.org 2002-05-02 23:25 ------- Both are considered correct depending on where you live. It is like whiningabout how one spells colour ('colour' vs 'color').I do feel that we should be consistant. *ALWAYS* use one or the other spelling,but I have no feelings either way which one should be used.Lets face it.. English (in it's many forms from Bastardized American tothe Queen's English) is just a horriblely scattered language.=) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Marty.Williams at ps.net Fri May 3 01:51:16 2002 From: Marty.Williams at ps.net (Williams, Marty) Date: Thu, 2 May 2002 10:51:16 -0500 Subject: Possible issue with PAM/OpenSSH? Message-ID: I recently compiled OpenSSH and its supporting products (see version list below) for my Solaris 8 system. With the exception of options changing the install locations of the products and the fact that the versions of the software I used were current, I followed same procedure used to compile and install the products outlined in the Sun white paper "Building and Deploying OpenSSH for the Solaris Operating Enviornment" (http://www.sun.com/solutions/blueprints/0701/openSSH.pdf) using gcc. Version List ------------ OpenSSH 3.1p1 Libgcc 3.0.3 OpenSSL 0.9.6c Prngd 0.9.24 Xinetd 2.3.3 Zlib 1.1.4 After the compilation and installation, when attempting to use ssh to login to a system as a user with an expired password (but only if password aging is turned off for that user - either zeroes or blanks in the min and max fields in /etc/shadow), the ssh server system prompts me to change the password and then asks for the current password. Upon entering the current password, on an intermittant basis I get a message saying: "removing root credentials would break the rpc services that use secure rpc on this host! root may use keylogout -f to do this (at your own risk)!" and then the connection is closed. This message is apparently coming from the pam_unix.so.1 library. At other times, after entering the current password, I am prompted for the new password, as one would expect and I can successfully change the password. The messages file indicates an unknown error (-1) with the function pam_chauthtok. Also, if password aging is turned on for the user, I have not seen this problem. I checked this issue out on another system (a Netra with a pre-loaded OS) where OpenSSH and the supporting products had been installed from the Solaris packages available from SunFreeware.com. This system never showed the problem even if the shadow file contained zeroes or blanks for the min and max values for the user with an expired password.) Do you have any thoughts on why I am seeing this error message? Marty Williams From bpinilla at internodos.com Fri May 3 02:50:01 2002 From: bpinilla at internodos.com (bpinilla at internodos.com) Date: 02 May 2002 11:50:01 -0500 Subject: Carlos Donoso en la UIS Message-ID: <200205021547.g42FlBs29046@mail.ingelcom.com> -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- (This safeguard is not inserted when using the registered version) -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- LA TUNA DE LA UIS PR ESENTA NUEVO SHOW DE CARLOS DONOSO "La Historia de la Humanidad seg?n Kini" Auditorio Luis A. Calvo - UIS S?bado 4 de mayo - 7:30 pm Boleter?a: Ense?anza V?ctor, Almac?n Leo, Taxi Telas y Taquillas del Auditorio. Domicilios: 6453876 - 6352199 Platea $ 25.000 - Balcones $ 20.000 -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- (This safeguard is not inserted when using the registered version) -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- From david.r.steiner at Dartmouth.EDU Fri May 3 05:19:24 2002 From: david.r.steiner at Dartmouth.EDU (David Steiner) Date: Thu, 2 May 2002 15:19:24 -0400 Subject: IRIX 6.5 + AFS/Kerberos Problems Message-ID: I am having problems compiling ssh 3.1.p1 under IRIX 6.5.15. I can get ssh to compile but it does not seem to be able to authenticate using afs passwords. Some details: gcc 3.0.1 ssl-0.9.6c zlib-1.1.4. I am configuring with: ./configure --with-kerberos4=/usr/kerberos --with-afs=/usr/afsws \ --with-tcp-wrappers=/usr/local Straight out of the box, this fails with: gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/usr/local/ ssl/include -I/usr/local/include -I/usr/local/include -I/usr/kerberos/include - I/usr/afsws/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/loca l/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_ PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/usr/l ocal/etc\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONF IG_H -c auth-passwd.c In file included from auth-passwd.c:49: /usr/include/crypt.h:38: conflicting types for `des_encrypt' /usr/kerberos/include/des.h:181: previous declaration of `des_encrypt' *** Error code 1 (bu21) I found a "fix" for this in a post in the mailing list archive indicating that there was a name conflict with the SGI libs which could be worked around by modifying auth-passwd.c and auth.h as follows: auth-passwd.c: -------------- at line 46: add line: #define ONLY_PASSWD_AUTH (just before: #include "auth.h" ) auth.h ------ make include of krb.h conditional (starts at line 100): #ifdef KRB4 new--> #ifndef ONLY_PASSWD_AUTH #include int auth_krb4(Authctxt *, KTEXT, char **); int auth_krb4_password(Authctxt *, const char *); void krb4_cleanup_proc(void *); new--> #endif /* ! ONLY_PASSWD_AUTH */ After making this change, ssh will build and run but sshd does not allow logging in using AFS accounts despite the defaults saying it should. There was another post in the archives that said the problem might be taken care of by removing the #include directive from auth-passwd.c but this exhibits the same behavior as the the previous fix. Can anyone out there point me in the right direction. TIA, -- David R. Steiner david.r.steiner at dartmouth.edu UNIX System Manager Phone: 603.646.3127 Dartmouth College Fax: 603.646.1041 From bugzilla-daemon at mindrot.org Fri May 3 07:40:15 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 May 2002 07:40:15 +1000 (EST) Subject: [Bug 234] New: OpenSSH does not compile on OpenBSD 3.1 Message-ID: <20020502214015.C9CA2E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=234 Summary: OpenSSH does not compile on OpenBSD 3.1 Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: OpenBSD Status: NEW Severity: normal Priority: P1 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: krh at lemniscate.net When trying to compile recent OpenSSH-portable snapshots on OpenBSD 3.1, I get: readpass.c: In function `read_passphrase': readpass.c:100: `RPP_ECHO_ON' undeclared (first use in this function) readpass.c:100: (Each undeclared identifier is reported only once readpass.c:100: for each function it appears in.) readpass.c:100: `RPP_ECHO_OFF' undeclared (first use in this function) readpass.c:105: `RPP_REQUIRE_TTY' undeclared (first use in this function) readpass.c:121: warning: implicit declaration of function `readpassphrase' *** Error code 1 The required defines are in openbsd-compat/readpassphrase.h, and they assume that HAVE_READPASSPHRASE is undefined. If I undefine HAVE_READPASSPHRASE, make clean, and make, everything compiles, but when I try to turn on sshd, I get: /usr/local/etc/sshd_config: line 68: Bad configuration option: KerberosAuthentication /usr/local/etc/sshd_config: line 69: Bad configuration option: KerberosOrLocalPasswd /usr/local/etc/sshd_config: line 70: Bad configuration option: KerberosTicketCleanup /usr/local/etc/sshd_config: line 74: Bad configuration option: AFSTokenPassing /usr/local/etc/sshd_config: line 77: Bad configuration option: KerberosTgtPassing /usr/local/etc/sshd_config: terminating, 5 bad configuration options Experimentation reveals that these are the only options that sshd does not recognize. ssh does not like these configuration options, either: /usr/local/etc/ssh_config: line 20: Bad configuration option: AFSTokenPassing /usr/local/etc/ssh_config: line 38: Bad configuration option: KerberosAuthentication /usr/local/etc/ssh_config: line 39: Bad configuration option: KerberosTgtPassing /usr/local/etc/ssh_config: terminating, 3 bad configuration options I don't have the facilities to test whether or not Kerberos or AFS are actually working. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri May 3 10:16:27 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 3 May 2002 10:16:27 +1000 (EST) Subject: [Bug 233] could we please learn how to spell the word license Message-ID: <20020503001627.C7755E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=233 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED ------- Additional Comments From djm at mindrot.org 2002-05-03 10:16 ------- Licence is the correct spelling, as used in Britian, Australia and many other parts of the world. We have no choice over the various spellings of "licence" in the file either - these are licences that we inherited from a number of developers. We do not have the legal right to change these in any way. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From austin at coremetrics.com Fri May 3 21:59:59 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 03 May 2002 06:59:59 -0500 Subject: Does OpenSSH have tcp_wrappers *built-in* or just compatibility? Message-ID: <1020427199.15612.1.camel@UberGeek> I was under the impression it was just compatibility, and not actually built-in, but I thought I'd ask here and just make sure of what I'm saying. :) TIA. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020503/69b5f070/attachment.bin From peterw at usa.net Fri May 3 22:28:01 2002 From: peterw at usa.net (Peter Watkins) Date: Fri, 3 May 2002 08:28:01 -0400 Subject: Does OpenSSH have tcp_wrappers *built-in* or just compatibility? In-Reply-To: <1020427199.15612.1.camel@UberGeek>; from austin@coremetrics.com on Fri, May 03, 2002 at 06:59:59AM -0500 References: <1020427199.15612.1.camel@UberGeek> Message-ID: <20020503082801.B6969@usa.net> On Fri, May 03, 2002 at 06:59:59AM -0500, Austin Gonyou wrote: > I was under the impression it was just compatibility, and not actually > built-in, but I thought I'd ask here and just make sure of what I'm > saying. :) TIA. OpenSSH and tcp_wrappers are separate software packages. OpenSSH can be built against the tcp_wrappers library (if tcp_wrappers is available on your system) so that the resulting binaries support tcp_wrappers' access control mechanisms. Normally tcp_wrappers is compiled as an archive, libwrap.a, so that if OpenSSH is compiled with tcp_wrappers support, tcp_wrappers is literally built-in (using Wietse Venema's code) to the resulting binaries, though some systems provide tcp_wrappers as a shared object and use standard dynamic linking mechanisms to add tcp_wrappers functionality to their applications. Wietse, if you're here, I'd love to hear what you think about libwrap.a vs libwrap.so. :-) -- Peter Watkins - peterw at tux.org - peterw at usa.net - http://www.tux.org/~peterw/ Private personal mail: use PGP key F4F397A8; more sensitive data? Use 2D123692 From austin at coremetrics.com Fri May 3 23:01:50 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 03 May 2002 08:01:50 -0500 Subject: Does OpenSSH have tcp_wrappers *built-in* or just compatibili ty? In-Reply-To: <20020503082801.B6969@usa.net> References: <20020503082801.B6969@usa.net> Message-ID: <1020430910.16131.3.camel@UberGeek> On solaris 8, that would probably be something we could do. We're looking into how we can limit specific users from being able to ssh out of a box, and someone mentioned tcp_wrappers being built into OpenSSH. We'll check it out and see. Any ideas around limiting users from sshing out btw? :) TIA On Fri, 2002-05-03 at 07:28, Peter Watkins wrote: > On Fri, May 03, 2002 at 06:59:59AM -0500, Austin Gonyou wrote: > > > I was under the impression it was just compatibility, and not actually > > built-in, but I thought I'd ask here and just make sure of what I'm > > saying. :) TIA. > > OpenSSH and tcp_wrappers are separate software packages. OpenSSH can be > built against the tcp_wrappers library (if tcp_wrappers is available on > your system) so that the resulting binaries support tcp_wrappers' access > control mechanisms. Normally tcp_wrappers is compiled as an archive, > libwrap.a, so that if OpenSSH is compiled with tcp_wrappers support, > tcp_wrappers is literally built-in (using Wietse Venema's code) to the > resulting binaries, though some systems provide tcp_wrappers as a shared > object and use standard dynamic linking mechanisms to add tcp_wrappers > functionality to their applications. > > Wietse, if you're here, I'd love to hear what you think about libwrap.a > vs > libwrap.so. :-) > > -- > Peter Watkins - peterw at tux.org - peterw at usa.net - > http://www.tux.org/~peterw/ > Private personal mail: use PGP key F4F397A8; more sensitive data? Use > 2D123692 > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020503/cbc4d073/attachment.bin From tim at multitalents.net Sat May 4 03:40:57 2002 From: tim at multitalents.net (Tim Rice) Date: Fri, 3 May 2002 10:40:57 -0700 (PDT) Subject: OpenSSH - configure In-Reply-To: <3C8F515F.34D8A8A9@germany.sun.com> Message-ID: On Wed, 13 Mar 2002, Frank Winkler wrote: > Hi there ! > > I'm just building OpenSSH 3.1 and just found out that the 'configure' > script seems to have the same bug as the one provided with 3.0.1: the > resulting Makefile has a wrong entry in the include list (.../lib instead > of .../include). Looking at the prefix, I suppose this is caused by either > '--with-zlib' or '--with-ssl-dir' but I didn't check this in detail yet. > After correcting this, the code compiles without problems :) ... > > Can anybody confirm this behavior? What configure options did you use? -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From austin at coremetrics.com Sat May 4 06:17:43 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 03 May 2002 15:17:43 -0500 Subject: OpenSSH - configure In-Reply-To: References: Message-ID: <1020457063.18899.4.camel@UberGeek> Not to be a big stinker, but I've *yet* to run into this problem. I build on Linux glibc 2.2.x with GCC3. On Fri, 2002-05-03 at 12:40, Tim Rice wrote: > On Wed, 13 Mar 2002, Frank Winkler wrote: > > > Hi there ! > > > > I'm just building OpenSSH 3.1 and just found out that the 'configure' > > script seems to have the same bug as the one provided with 3.0.1: the > > resulting Makefile has a wrong entry in the include list (.../lib > instead > > of .../include). Looking at the prefix, I suppose this is caused by > either > > '--with-zlib' or '--with-ssl-dir' but I didn't check this in detail > yet. > > After correcting this, the code compiles without problems :) ... > > > > Can anybody confirm this behavior? > > What configure options did you use? > > > -- > Tim Rice Multitalents (707) 887-1469 > tim at multitalents.net > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020503/145818b5/attachment.bin From david.r.steiner at Dartmouth.EDU Sat May 4 06:50:02 2002 From: david.r.steiner at Dartmouth.EDU (David Steiner) Date: Fri, 3 May 2002 16:50:02 -0400 Subject: AFS/Kerberos authentication problems on IRIX 6.5.15 Message-ID: With a little help, I managed to get ssh to compile. (original post 05.02.02) Now, I can login using an account that is local to the target machine but logins with AFS accounts fail. The details: IRIX 6.5.15 ssh 3.1.p1 gcc 3.0.1 ssl-0.9.6c zlib-1.1.4. I am configuring with: env CC=gcc CFLAGS=-g LDFLAGS=-Wl,-rpath,/usr/local/krb4/lib,-rpath,/usr/local/ssl/lib ./configure --prefix=/usr/etc/ssh --with-afs=/usr/afsws --with-kerberos4=/usr/local/krb4 --sysconfdir=/etc/ssh --with-pid-dir=/var/run --with-ipv4-default --with-default-path=/usr/bin:/bin:/usr/bsd:/usr/sbin:/sbin:/usr/afsws/bin:/usr/local/bin I also had to remove the first occurrence of '-ldes' from the LIBS in the makefile. When trying to login with an AFS account the user sees "Permission denied" Running 'sshd -d' on the server shows that the Kerberos authentication fails with "Principal unknown" (see debug output below). I have also attached my sshd_config file. Any help would be greatly appreciated. TIA =====Debug output (user names and IPs have been sanitized)===== debug1: userauth-request for user user1 service ssh-connection method none debug1: attempt 0 failures 0 Failed none for user1 from 192.xx.xx.xx port 49297 ssh2 debug1: userauth-request for user user1 service ssh-connection method keyboard-interactive debug1: attempt 1 failures 1 debug1: keyboard-interactive devs debug1: auth2_challenge: user=user1 devs= debug1: kbdint_alloc: devices '' Failed keyboard-interactive for user1 from 192.xx.xx.xx port 49297 ssh2 debug1: userauth-request for user user1 service ssh-connection method password debug1: attempt 2 failures 2 kerberos-iv/udp unknown service, using default port 750 debug1: Kerberos v4 password authentication for user1 failed: Principal unknown (kerberos) debug1: krb4_cleanup_proc called Failed password for user1 from 192.xx.xx.xx port 49297 ssh2 ======sshd_config========= # $OpenBSD: sshd_config,v 1.48 2002/02/19 02:50:59 deraadt Exp $ # This is the sshd server system-wide configuration file. See sshd(8) # for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/bsd:/usr/sbin:/sbin:/usr/afsws/bin:/usr/local/bin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. Port 22 Protocol 2,1 ListenAddress 0.0.0.0 #ListenAddress :: # HostKey for protocol version 1 HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768 # Logging #obsoletes QuietMode and FascistLogging SyslogFacility AUTH LogLevel INFO # Authentication: LoginGraceTime 600 PermitRootLogin no StrictModes yes RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys # rhosts authentication should not be used RhostsAuthentication no # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts RhostsRSAAuthentication yes # similar for protocol version 2 HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication IgnoreUserKnownHosts no # To disable tunneled clear text passwords, change to no here! PasswordAuthentication yes PermitEmptyPasswords no # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes # Kerberos options # KerberosAuthentication automatically enabled if keyfile exists KerberosAuthentication yes KerberosOrLocalPasswd no KerberosTicketCleanup yes # AFSTokenPassing automatically enabled if k_hasafs() is true AFSTokenPassing yes # Kerberos TGT Passing only works with the AFS kaserver KerberosTgtPassing yes # Set this to 'yes' to enable PAM keyboard-interactive authentication # Warning: enabling this may bypass the setting of 'PasswordAuthentication' #PAMAuthenticationViaKbdInt yes X11Forwarding no X11DisplayOffset 10 X11UseLocalhost yes PrintMotd yes PrintLastLog yes KeepAlive yes UseLogin no MaxStartups 10 # no default banner path #Banner /some/path VerifyReverseMapping no # override default of no subsystems Subsystem sftp /usr/ssh/libexec/sftp-server -- David R. Steiner david.r.steiner at dartmouth.edu UNIX System Manager Phone: 603.646.3127 Dartmouth College Fax: 603.646.1041 From dtucker at zip.com.au Sat May 4 14:22:03 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 04 May 2002 14:22:03 +1000 Subject: Does OpenSSH have tcp_wrappers *built-in* or just compatibility? References: <3CD29744.5542C400@zip.com.au> <1020436364.15708.10.camel@UberGeek> Message-ID: <3CD361EB.A7BC99B0@zip.com.au> Austin Gonyou wrote: > Yeah..we thought about that..but it's really not *hard* enough. Since > they will still have access to multiple other solaris boxes to be able > to make portable binaries with and /tmp is useable by all. Though > solaris ACLs would take care of that, it's not a good first step for our > production environment. I think we are on the same wavelength though. :) > > On Fri, 2002-05-03 at 08:57, Darren Tucker wrote: > > Austin Gonyou wrote: > > > On solaris 8, that would probably be something we could do. We're > > > looking into how we can limit specific users from being able to ssh > > out > > > of a box, and someone mentioned tcp_wrappers being built into OpenSSH. > > > > Assuming they can't copy their own binaries onto the box how about > > "chgrp sshusers ssh; chmod o-rwx ssh"? OK, how about this: 1) Install the real ssh setuid root, gid sshusers, mode 4110. 2) Set "UsePrivilegedPort" to "yes". 3) Arrange for a firewall/router/local packet filter to drop all outbound tcp connections on port 22 with a source port >1023. This will also defeat using a forwarder (like netcat) from an internal box: ProxyCommand ssh gatewayhost nc externalhost 22 You could also mount /home, /tmp and /var noexec. This would stop someone copying another ssh and getting an external server to run sshd on another port (eg 443). It'd be a lot easier to use "userdel" :-) Once you've got collusion on both sides it's very hard to stop. -Daz. From tino.schwarze at informatik.tu-chemnitz.de Sat May 4 19:25:41 2002 From: tino.schwarze at informatik.tu-chemnitz.de (Tino Schwarze) Date: Sat, 4 May 2002 11:25:41 +0200 Subject: mysterious connection breakdown Message-ID: <20020504112541.D2460@informatik.tu-chemnitz.de> Hi there, at a school I have two servers and I created a little backup "system" for them. A cron job runs on the first server (fserver), backs stuff up there and then ssh's to the second server to run a backup script there too. (the first server is located in internal network, the second in a DMZ). When I tried everything on console, it worked fine, but when run from cron, the connection mysteriously collapses. Here is the output of my scripts (messages starting with +++ come from my scripts and only inform of the progress). ----- Forwarded message from Cron Daemon ----- Delivered-To: tisc at mail.agricola-gymnasium.de Date: Sat, 4 May 2002 10:49:00 +0200 From: root at agricola-gymnasium.de (Cron Daemon) To: tisc at agricola-gymnasium.de Subject: Cron /root/daily_backup X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: +++ 04.05,10:49 - Beginne Backup. [...] +++ 04.05,10:49 - Beginne Backup von communicator. +++ 04.05,10:49 - Kopiere Backup-Liste auf communicator. > using scp to copy the list of things to back up +++ 04.05,10:49 - Starte Backup-Skript auf communicator. > ssh -v www-intern /root/daily_backup.remote OpenSSH_2.9.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090601f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Seeding random number generator debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 0 geteuid 0 anon 1 debug1: Connecting to www-intern [10.1.2.1] port 22. debug1: temporarily_use_uid: 0/0 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 0/0 (e=0) debug1: restore_uid debug1: Connection established. debug1: read PEM private key done: type DSA debug1: read PEM private key done: type RSA debug1: identity file /root/.ssh/identity type 0 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9.9p2 debug1: match: OpenSSH_2.9.9p2 pat ^OpenSSH debug1: Local version string SSH-1.5-OpenSSH_2.9.9p2 debug1: Waiting for server public key. debug1: Received server public key (768 bits) and host key (1024 bits). debug1: Host 'www-intern' is known and matches the RSA1 host key. debug1: Found key in /root/.ssh/known_hosts:1 debug1: Encryption type: 3des debug1: Sent encrypted session key. debug1: Installing crc compensation attack detector. debug1: Received encrypted confirmation. debug1: Trying RSA authentication with key '/root/.ssh/identity' debug1: Received RSA challenge from server. debug1: Sending response to host key RSA challenge. debug1: Remote: RSA authentication accepted. debug1: RSA authentication accepted by server. debug1: Sending command: /root/daily_backup.remote debug1: Entering interactive session. debug1: fd 1 setting O_NONBLOCK > this is strange, there should be a message "+++ ... Beginne Backup" > there should also be messages inserted for debugging purposes > after all, there are three lines of output missing + echo starting + read filesystem archivename taroptions + echo filter comment Disconnecting: Corrupted check bytes on input. > !!! This usually points to a CRC compensation attack but this is > rather unlikely since it's an internal server. debug1: Calling cleanup 0x8065650(0x0) [...] ----- End forwarded message ----- Any hints? What goes wrong here? Bye+Thanx! Tino. -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ From bugzilla-daemon at mindrot.org Sun May 5 23:45:52 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 5 May 2002 23:45:52 +1000 (EST) Subject: [Bug 235] New: While PermitEmptyPasswords no, user can connect, entering ANY other password Message-ID: <20020505134552.C5021E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=235 Summary: While PermitEmptyPasswords no, user can connect, entering ANY other password Product: Portable OpenSSH Version: 3.1p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: maxim at idknet.com set "PermitEmptyPasswords no" in sshd_config useradd test vi shadow for setting EMPTY password ssh test at localhost after prompt "test at localhost's password:", enter any non empty password. Authorization succeeds and "remote" user gain access to system. It also valid if user is root. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon May 6 06:09:35 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 6 May 2002 06:09:35 +1000 (EST) Subject: [Bug 235] While PermitEmptyPasswords no, user can connect, entering ANY other password Message-ID: <20020505200935.612FEE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=235 ------- Additional Comments From mouring at eviladmin.org 2002-05-06 06:09 ------- Created an attachment (id=92) Try the following patch to auth-passwd.c ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon May 6 09:28:09 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 6 May 2002 09:28:09 +1000 (EST) Subject: [Bug 235] While PermitEmptyPasswords no, user can connect, entering ANY other password Message-ID: <20020505232809.177E0E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=235 ------- Additional Comments From djm at mindrot.org 2002-05-06 09:28 ------- Are you using PAM? Your problem isn't related to http://www.openssh.com/faq.html#3.2, is it? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon May 6 10:56:41 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 6 May 2002 10:56:41 +1000 (EST) Subject: [Bug 235] While PermitEmptyPasswords no, user can connect, entering ANY other password Message-ID: <20020506005641.C2BDEE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=235 ------- Additional Comments From mouring at eviladmin.org 2002-05-06 10:56 ------- DJM, as stated in the private list I can reproduce this with OpenBSD's release so it is not PAM related. Just bad code that we picked up from back in the old SSH Corp releases. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bordewijk at fox-it.com Mon May 6 22:17:14 2002 From: bordewijk at fox-it.com (Lourens Bordewijk) Date: Mon, 6 May 2002 14:17:14 +0200 Subject: cryptocard RB-1 Message-ID: Hello , I have bought a cryptocard and i want to make it work openssh, now I need to initialize my token, install the cryptocard patch ( http://projects.jdimedia.nl/files/openssh-cryptocard.patch). The patch reads it's data from a file I've heard that some users made a conversion script from the CryptoADMIN server export to a crypto users file that the patch want. Is there anybody who can tell me a little bit more about:how I can initialize my cryptocard RB-1 and something about the conversion script !!!!!!! Thanx in advance, Lourens Bordewijk From tino.schwarze at informatik.tu-chemnitz.de Mon May 6 23:10:00 2002 From: tino.schwarze at informatik.tu-chemnitz.de (Tino Schwarze) Date: Mon, 6 May 2002 15:10:00 +0200 Subject: mysterious connection breakdown - resolved Message-ID: <20020506151000.B14510@informatik.tu-chemnitz.de> Hi there, I was able to get things working. I do not get "Corrupted check bytes on input" any more. I'm not sure what the cause was though. First, I installed OpenSSH 3.1p1. Then, I explicitly disabled anything not needed: ssh -2 -4 -a -n -T -x $host $script What stays odd is, that the debug output still says "entering interactive session". There is _no_ interactive session. It is non-interactive! Is this a bug? Bye, Tino. -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ From Stephan.Hendl at lds.brandenburg.de Mon May 6 23:57:37 2002 From: Stephan.Hendl at lds.brandenburg.de (Stephan Hendl) Date: Mon, 06 May 2002 15:57:37 +0200 Subject: tunnel connection like a service with cygwin or other products? Message-ID: Hi all, I try to implement a secure ODBC connection via ssh tunnel from a win-pc to a linux server. I am looking for a kind of service under nt that builds a secure tunnel connection from the pc to the server at time of login of the user at the desktop and going into the background after that. That means the conncetion is always open until the user shuts down the pc. It should run completely in the backgroung, not in a minimized window... Does anybody have an idea? Thanks! Stephan -- LDS Brandenburg Dr. Stephan Hendl fon: +49-(0)331-39 471 fax: +49-(0)331-27548 1187 EMail: stephan.hendl at lds.brandenburg.de From dtucker at zip.com.au Tue May 7 00:54:00 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 07 May 2002 00:54:00 +1000 Subject: tunnel connection like a service with cygwin or otherproducts? References: Message-ID: <3CD69908.374861D9@zip.com.au> Stephan Hendl wrote: > I try to implement a secure ODBC connection via ssh tunnel from a win-pc > to a linux server. I am looking for a kind of service under nt that builds > a secure tunnel connection from the pc to the server at time of login > of the user at the desktop and going into the background after that. That > means the conncetion is always open until the user shuts down the pc. > It should run completely in the backgroung, not in a minimized window... The first part should be easy: use cygwin openssh client using some kind of passwordless authentication (eg RSA). To make it run entirely in the background, run it from cygrunsrv (part of Cygwin) or SRVANY (NT resource kit). Neither of these work on W95, only NT or W2K. -Daz. From don_gathman at hp.com Tue May 7 02:58:02 2002 From: don_gathman at hp.com (GATHMAN,DON (HP-Boise,ex1)) Date: Mon, 6 May 2002 12:58:02 -0400 Subject: SCP file corruptions Message-ID: Hi, I apparently was asleep at the wheel using scp, and accidentally copied a file onto itself. Scp generated an Input/Output error and did not perform the copy. However, now the file is corrupt. Is this a but? Is there anyway to fix the file I messed up? Thanks, Don Gathman 208.396.6675 From mjs at ams.org Tue May 7 03:13:35 2002 From: mjs at ams.org (Matt Studley) Date: Mon, 6 May 2002 13:13:35 -0400 (EDT) Subject: SCP file corruptions In-Reply-To: Message-ID: What options did you use with scp and what was the exact error message? Generally, at least in my experience, scp will not copy over a file when the 'source' and 'destination' are identical when doing a local copy: $ scp test test cp: test and test are identical when doing a remote copy, you will overwrite the remote file but that is a different situation and should not corrupt the file. Matt Studley American Mathematical Society UNIX Sys Admin "Quantum Mechanics - mjs at ams.org The dreams that stuff is made of" On Mon, 6 May 2002, GATHMAN,DON (HP-Boise,ex1) wrote: > Hi, > > I apparently was asleep at the wheel using scp, and accidentally copied a > file onto itself. Scp generated an Input/Output error and did not perform > the copy. However, now the file is corrupt. Is this a but? Is there anyway > to fix the file I messed up? > > Thanks, > Don Gathman > 208.396.6675 > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From Nicolas.Williams at ubsw.com Tue May 7 03:20:32 2002 From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com) Date: Mon, 6 May 2002 13:20:32 -0400 Subject: SCP file corruptions Message-ID: <9403F8EE868566448AA1B70D8F783C95334ED2@NSTMC004PEX1.ubsgs.ubsgroup.net> if /somedir/fileA on hostA == /path/to/fileB on hostB because of NFS/AFS/DFS/whatever then "hostA/somedir/: scp fileA hostB:/path/to/fileB" will corrupt the file fi -- > -----Original Message----- > From: Matt Studley [mailto:mjs at ams.org] > Sent: Monday, May 06, 2002 1:14 PM > To: GATHMAN,DON (HP-Boise,ex1) > Cc: 'openssh-unix-dev at mindrot.org' > Subject: Re: SCP file corruptions > > > What options did you use with scp and what was the exact > error message? > Generally, at least in my experience, scp will not copy over > a file when > the 'source' and 'destination' are identical when doing a local copy: > > $ scp test test > cp: test and test are identical > > when doing a remote copy, you will overwrite the remote file > but that is > a different situation and should not corrupt the file. > > > Matt Studley > American Mathematical Society > UNIX Sys Admin "Quantum Mechanics - > mjs at ams.org The dreams that stuff > is made of" > > On Mon, 6 May 2002, GATHMAN,DON (HP-Boise,ex1) wrote: > > > Hi, > > > > I apparently was asleep at the wheel using scp, and > accidentally copied a > > file onto itself. Scp generated an Input/Output error and > did not perform > > the copy. However, now the file is corrupt. Is this a > but? Is there anyway > > to fix the file I messed up? > > > > Thanks, > > Don Gathman > > 208.396.6675 > > _______________________________________________ > > openssh-unix-dev at mindrot.org mailing list > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From mjs at ams.org Tue May 7 03:40:13 2002 From: mjs at ams.org (Matt Studley) Date: Mon, 6 May 2002 13:40:13 -0400 (EDT) Subject: SCP file corruptions In-Reply-To: <9403F8EE868566448AA1B70D8F783C95334ED2@NSTMC004PEX1.ubsgs.ubsgroup.net> Message-ID: I just tried this with an AFS mounted partition and it worked as expected (normal remote copy). Is your statement only true if the file is a binary? I did try it with a plain text file. Matt Studley American Mathematical Society UNIX Sys Admin "Quantum Mechanics - mjs at ams.org The dreams that stuff is made of" On Mon, 6 May 2002 Nicolas.Williams at ubsw.com wrote: > > if /somedir/fileA on hostA == /path/to/fileB on hostB because of NFS/AFS/DFS/whatever > then > "hostA/somedir/: scp fileA hostB:/path/to/fileB" will corrupt the file > fi > > > -- > > > -----Original Message----- > > From: Matt Studley [mailto:mjs at ams.org] > > Sent: Monday, May 06, 2002 1:14 PM > > To: GATHMAN,DON (HP-Boise,ex1) > > Cc: 'openssh-unix-dev at mindrot.org' > > Subject: Re: SCP file corruptions > > > > > > What options did you use with scp and what was the exact > > error message? > > Generally, at least in my experience, scp will not copy over > > a file when > > the 'source' and 'destination' are identical when doing a local copy: > > > > $ scp test test > > cp: test and test are identical > > > > when doing a remote copy, you will overwrite the remote file > > but that is > > a different situation and should not corrupt the file. > > > > > > Matt Studley > > American Mathematical Society > > UNIX Sys Admin "Quantum Mechanics - > > mjs at ams.org The dreams that stuff > > is made of" > > > > On Mon, 6 May 2002, GATHMAN,DON (HP-Boise,ex1) wrote: > > > > > Hi, > > > > > > I apparently was asleep at the wheel using scp, and > > accidentally copied a > > > file onto itself. Scp generated an Input/Output error and > > did not perform > > > the copy. However, now the file is corrupt. Is this a > > but? Is there anyway > > > to fix the file I messed up? > > > > > > Thanks, > > > Don Gathman > > > 208.396.6675 > > > _______________________________________________ > > > openssh-unix-dev at mindrot.org mailing list > > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > > > _______________________________________________ > > openssh-unix-dev at mindrot.org mailing list > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From Nicolas.Williams at ubsw.com Tue May 7 03:42:35 2002 From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com) Date: Mon, 6 May 2002 13:42:35 -0400 Subject: SCP file corruptions Message-ID: <9403F8EE868566448AA1B70D8F783C95334ED3@NSTMC004PEX1.ubsgs.ubsgroup.net> It was an IIRC. There's been plenty on this in the list. It's possible that this applies only to SCP with SSHv1. Nico -- > -----Original Message----- > From: Matt Studley [mailto:mjs at ams.org] > Sent: Monday, May 06, 2002 1:40 PM > To: Williams, Nicolas > Cc: don_gathman at hp.com; openssh-unix-dev at mindrot.org > Subject: RE: SCP file corruptions > > > > I just tried this with an AFS mounted partition and it worked > as expected > (normal remote copy). Is your statement only true if the file is a > binary? I did try it with a plain text file. > > Matt Studley > American Mathematical Society > UNIX Sys Admin "Quantum Mechanics - > mjs at ams.org The dreams that stuff > is made of" > > On Mon, 6 May 2002 Nicolas.Williams at ubsw.com wrote: > > > > > if /somedir/fileA on hostA == /path/to/fileB on hostB > because of NFS/AFS/DFS/whatever > > then > > "hostA/somedir/: scp fileA hostB:/path/to/fileB" will > corrupt the file > > fi > > > > > > -- > > > > > -----Original Message----- > > > From: Matt Studley [mailto:mjs at ams.org] > > > Sent: Monday, May 06, 2002 1:14 PM > > > To: GATHMAN,DON (HP-Boise,ex1) > > > Cc: 'openssh-unix-dev at mindrot.org' > > > Subject: Re: SCP file corruptions > > > > > > > > > What options did you use with scp and what was the exact > > > error message? > > > Generally, at least in my experience, scp will not copy over > > > a file when > > > the 'source' and 'destination' are identical when doing a > local copy: > > > > > > $ scp test test > > > cp: test and test are identical > > > > > > when doing a remote copy, you will overwrite the remote file > > > but that is > > > a different situation and should not corrupt the file. > > > > > > > > > Matt Studley > > > American Mathematical Society > > > UNIX Sys Admin "Quantum Mechanics - > > > mjs at ams.org The dreams that stuff > > > is made of" > > > > > > On Mon, 6 May 2002, GATHMAN,DON (HP-Boise,ex1) wrote: > > > > > > > Hi, > > > > > > > > I apparently was asleep at the wheel using scp, and > > > accidentally copied a > > > > file onto itself. Scp generated an Input/Output error and > > > did not perform > > > > the copy. However, now the file is corrupt. Is this a > > > but? Is there anyway > > > > to fix the file I messed up? > > > > > > > > Thanks, > > > > Don Gathman > > > > 208.396.6675 > > > > _______________________________________________ > > > > openssh-unix-dev at mindrot.org mailing list > > > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > > > > > > _______________________________________________ > > > openssh-unix-dev at mindrot.org mailing list > > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > > > Visit our website at http://www.ubswarburg.com > > > > This message contains confidential information and is intended only > > for the individual named. If you are not the named addressee you > > should not disseminate, distribute or copy this e-mail. Please > > notify the sender immediately by e-mail if you have received this > > e-mail by mistake and delete this e-mail from your system. > > > > E-mail transmission cannot be guaranteed to be secure or error-free > > as information could be intercepted, corrupted, lost, destroyed, > > arrive late or incomplete, or contain viruses. The sender therefore > > does not accept liability for any errors or omissions in > the contents > > of this message which arise as a result of e-mail transmission. If > > verification is required please request a hard-copy version. This > > message is provided for informational purposes and should not be > > construed as a solicitation or offer to buy or sell any > securities or > > related financial instruments. > > > > _______________________________________________ > > openssh-unix-dev at mindrot.org mailing list > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From don_gathman at hp.com Tue May 7 04:55:27 2002 From: don_gathman at hp.com (GATHMAN,DON (HP-Boise,ex1)) Date: Mon, 6 May 2002 14:55:27 -0400 Subject: SCP file corruptions Message-ID: Thanks for the replies.. My use of scp was just as Nico described, and I'm using SSHv1. I guess I'm without a paddle on the file I corrupted. I'll chalk it up to a Monday morning lesson and see if I can update SSH on the machines I'm working with.. Thanks, Don -----Original Message----- From: Nicolas.Williams at ubsw.com [mailto:Nicolas.Williams at ubsw.com] Sent: Monday, May 06, 2002 11:43 AM To: mjs at ams.org Cc: don_gathman at hp.com; openssh-unix-dev at mindrot.org Subject: RE: SCP file corruptions It was an IIRC. There's been plenty on this in the list. It's possible that this applies only to SCP with SSHv1. Nico -- > -----Original Message----- > From: Matt Studley [mailto:mjs at ams.org] > Sent: Monday, May 06, 2002 1:40 PM > To: Williams, Nicolas > Cc: don_gathman at hp.com; openssh-unix-dev at mindrot.org > Subject: RE: SCP file corruptions > > > > I just tried this with an AFS mounted partition and it worked > as expected > (normal remote copy). Is your statement only true if the file is a > binary? I did try it with a plain text file. > > Matt Studley > American Mathematical Society > UNIX Sys Admin "Quantum Mechanics - > mjs at ams.org The dreams that stuff > is made of" > > On Mon, 6 May 2002 Nicolas.Williams at ubsw.com wrote: > > > > > if /somedir/fileA on hostA == /path/to/fileB on hostB > because of NFS/AFS/DFS/whatever > > then > > "hostA/somedir/: scp fileA hostB:/path/to/fileB" will > corrupt the file > > fi > > > > > > -- > > > > > -----Original Message----- > > > From: Matt Studley [mailto:mjs at ams.org] > > > Sent: Monday, May 06, 2002 1:14 PM > > > To: GATHMAN,DON (HP-Boise,ex1) > > > Cc: 'openssh-unix-dev at mindrot.org' > > > Subject: Re: SCP file corruptions > > > > > > > > > What options did you use with scp and what was the exact > > > error message? > > > Generally, at least in my experience, scp will not copy over > > > a file when > > > the 'source' and 'destination' are identical when doing a > local copy: > > > > > > $ scp test test > > > cp: test and test are identical > > > > > > when doing a remote copy, you will overwrite the remote file > > > but that is > > > a different situation and should not corrupt the file. > > > > > > > > > Matt Studley > > > American Mathematical Society > > > UNIX Sys Admin "Quantum Mechanics - > > > mjs at ams.org The dreams that stuff > > > is made of" > > > > > > On Mon, 6 May 2002, GATHMAN,DON (HP-Boise,ex1) wrote: > > > > > > > Hi, > > > > > > > > I apparently was asleep at the wheel using scp, and > > > accidentally copied a > > > > file onto itself. Scp generated an Input/Output error and > > > did not perform > > > > the copy. However, now the file is corrupt. Is this a > > > but? Is there anyway > > > > to fix the file I messed up? > > > > > > > > Thanks, > > > > Don Gathman > > > > 208.396.6675 > > > > _______________________________________________ > > > > openssh-unix-dev at mindrot.org mailing list > > > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > > > > > > _______________________________________________ > > > openssh-unix-dev at mindrot.org mailing list > > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > > > Visit our website at http://www.ubswarburg.com > > > > This message contains confidential information and is intended only > > for the individual named. If you are not the named addressee you > > should not disseminate, distribute or copy this e-mail. Please > > notify the sender immediately by e-mail if you have received this > > e-mail by mistake and delete this e-mail from your system. > > > > E-mail transmission cannot be guaranteed to be secure or error-free > > as information could be intercepted, corrupted, lost, destroyed, > > arrive late or incomplete, or contain viruses. The sender therefore > > does not accept liability for any errors or omissions in > the contents > > of this message which arise as a result of e-mail transmission. If > > verification is required please request a hard-copy version. This > > message is provided for informational purposes and should not be > > construed as a solicitation or offer to buy or sell any > securities or > > related financial instruments. > > > > _______________________________________________ > > openssh-unix-dev at mindrot.org mailing list > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From don_gathman at hp.com Tue May 7 04:57:54 2002 From: don_gathman at hp.com (GATHMAN,DON (HP-Boise,ex1)) Date: Mon, 6 May 2002 11:57:54 -0700 Subject: SCP file corruptions Message-ID: FYI, Turns out I was using package openssh-2.9p2-11.7... -----Original Message----- From: GATHMAN,DON (HP-Boise,ex1) Sent: Monday, May 06, 2002 12:55 PM To: 'Nicolas.Williams at ubsw.com'; mjs at ams.org Cc: GATHMAN,DON (HP-Boise,ex1); openssh-unix-dev at mindrot.org Subject: RE: SCP file corruptions Thanks for the replies.. My use of scp was just as Nico described, and I'm using SSHv1. I guess I'm without a paddle on the file I corrupted. I'll chalk it up to a Monday morning lesson and see if I can update SSH on the machines I'm working with.. Thanks, Don -----Original Message----- From: Nicolas.Williams at ubsw.com [mailto:Nicolas.Williams at ubsw.com] Sent: Monday, May 06, 2002 11:43 AM To: mjs at ams.org Cc: don_gathman at hp.com; openssh-unix-dev at mindrot.org Subject: RE: SCP file corruptions It was an IIRC. There's been plenty on this in the list. It's possible that this applies only to SCP with SSHv1. Nico -- > -----Original Message----- > From: Matt Studley [mailto:mjs at ams.org] > Sent: Monday, May 06, 2002 1:40 PM > To: Williams, Nicolas > Cc: don_gathman at hp.com; openssh-unix-dev at mindrot.org > Subject: RE: SCP file corruptions > > > > I just tried this with an AFS mounted partition and it worked > as expected > (normal remote copy). Is your statement only true if the file is a > binary? I did try it with a plain text file. > > Matt Studley > American Mathematical Society > UNIX Sys Admin "Quantum Mechanics - > mjs at ams.org The dreams that stuff > is made of" > > On Mon, 6 May 2002 Nicolas.Williams at ubsw.com wrote: > > > > > if /somedir/fileA on hostA == /path/to/fileB on hostB > because of NFS/AFS/DFS/whatever > > then > > "hostA/somedir/: scp fileA hostB:/path/to/fileB" will > corrupt the file > > fi > > > > > > -- > > > > > -----Original Message----- > > > From: Matt Studley [mailto:mjs at ams.org] > > > Sent: Monday, May 06, 2002 1:14 PM > > > To: GATHMAN,DON (HP-Boise,ex1) > > > Cc: 'openssh-unix-dev at mindrot.org' > > > Subject: Re: SCP file corruptions > > > > > > > > > What options did you use with scp and what was the exact > > > error message? > > > Generally, at least in my experience, scp will not copy over > > > a file when > > > the 'source' and 'destination' are identical when doing a > local copy: > > > > > > $ scp test test > > > cp: test and test are identical > > > > > > when doing a remote copy, you will overwrite the remote file > > > but that is > > > a different situation and should not corrupt the file. > > > > > > > > > Matt Studley > > > American Mathematical Society > > > UNIX Sys Admin "Quantum Mechanics - > > > mjs at ams.org The dreams that stuff > > > is made of" > > > > > > On Mon, 6 May 2002, GATHMAN,DON (HP-Boise,ex1) wrote: > > > > > > > Hi, > > > > > > > > I apparently was asleep at the wheel using scp, and > > > accidentally copied a > > > > file onto itself. Scp generated an Input/Output error and > > > did not perform > > > > the copy. However, now the file is corrupt. Is this a > > > but? Is there anyway > > > > to fix the file I messed up? > > > > > > > > Thanks, > > > > Don Gathman > > > > 208.396.6675 > > > > _______________________________________________ > > > > openssh-unix-dev at mindrot.org mailing list > > > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > > > > > > _______________________________________________ > > > openssh-unix-dev at mindrot.org mailing list > > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > > > Visit our website at http://www.ubswarburg.com > > > > This message contains confidential information and is intended only > > for the individual named. If you are not the named addressee you > > should not disseminate, distribute or copy this e-mail. Please > > notify the sender immediately by e-mail if you have received this > > e-mail by mistake and delete this e-mail from your system. > > > > E-mail transmission cannot be guaranteed to be secure or error-free > > as information could be intercepted, corrupted, lost, destroyed, > > arrive late or incomplete, or contain viruses. The sender therefore > > does not accept liability for any errors or omissions in > the contents > > of this message which arise as a result of e-mail transmission. If > > verification is required please request a hard-copy version. This > > message is provided for informational purposes and should not be > > construed as a solicitation or offer to buy or sell any > securities or > > related financial instruments. > > > > _______________________________________________ > > openssh-unix-dev at mindrot.org mailing list > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From sherwin at nlm.nih.gov Tue May 7 05:42:59 2002 From: sherwin at nlm.nih.gov (Ziying Sherwin) Date: Mon, 6 May 2002 15:42:59 -0400 (EDT) Subject: X11 forwarding does not work as normal user Message-ID: We installed openssh 3.1p1 on our Solaris 2.8 machine using gcc 2.95.2. During the installation, we modified ssh_config and sshd_config to enable X11 and agent forwarding. In sshd_config, we changed the following line to read: X11Forwarding yes In ssh_config, we changed the following two lines to read: ForwardAgent yes ForwardX11 yes Both files are set to permission readable to all. The X11 forwarding works fine if we logged as super user, but does not work for normal users. What is the problem? Thanks, Ziying Sherwin P.S. I am not on the mailing list, please reply to sherwin at nlm.nih.gov From pekkas at netcore.fi Tue May 7 07:03:20 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 7 May 2002 00:03:20 +0300 (EEST) Subject: patch: contrib/redhat/openssh.spec updates for privsep Message-ID: Hello! Now that PrivSep stuff works for PAM too, I took the time to update contrib/redhat/openssh.spec to create the sshd user and set up the /var/empty dir when installing the packages. These have been done the Red Hat style, the uid/gif 74 is currently free in RHL. The only minor issues I could think of were: - I'm not sure if /var/empty should be owned by openssh-server package, but rather a filesystems package or such.. Is this even LSB compliant? - do all of these 'useradd' options also work in some "ancient" versions of RHL, like 5.2? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------- next part -------------- Index: openssh.spec =================================================================== RCS file: /cvs/openssh/contrib/redhat/openssh.spec,v retrieving revision 1.97 diff -u -r1.97 openssh.spec --- openssh.spec 23 Apr 2002 11:17:18 -0000 1.97 +++ openssh.spec 6 May 2002 21:01:42 -0000 @@ -85,7 +85,7 @@ Summary: The OpenSSH server daemon. Group: System Environment/Daemons Obsoletes: ssh-server -PreReq: openssh = %{version}-%{release}, chkconfig >= 0.9 +PreReq: openssh = %{version}-%{release}, chkconfig >= 0.9, /usr/sbin/useradd %if %{redhat7} Requires: /etc/pam.d/system-auth %endif @@ -202,6 +202,7 @@ DESTDIR=/ # Hack to disable key generation +install -d $RPM_BUILD_ROOT/var/empty install -d $RPM_BUILD_ROOT/etc/pam.d/ install -d $RPM_BUILD_ROOT/etc/rc.d/init.d install -d $RPM_BUILD_ROOT%{_libexecdir}/openssh @@ -238,6 +239,9 @@ /sbin/chkconfig --del sshd fi +%pre server +/usr/sbin/useradd -c "sshd privilege separation user" -r -M -s /sbin/nologin -u 74 -d /var/empty sshd 2>/dev/null || : + %files %defattr(-,root,root) %doc CREDITS ChangeLog INSTALL LICENCE OVERVIEW README* RFC* TODO WARNING* @@ -271,6 +275,7 @@ %files server %defattr(-,root,root) +%attr(0755,root,root) /var/empty %attr(0755,root,root) %{_sbindir}/sshd %attr(0755,root,root) %{_libexecdir}/openssh/sftp-server %attr(0644,root,root) %{_mandir}/man8/sshd.8* From kevin at atomicgears.com Tue May 7 07:36:23 2002 From: kevin at atomicgears.com (Kevin Steves) Date: Mon, 6 May 2002 14:36:23 -0700 (PDT) Subject: X11 forwarding does not work as normal user In-Reply-To: Message-ID: On Mon, 6 May 2002, Ziying Sherwin wrote: :The X11 forwarding works fine if we logged as super user, but does not work :for normal users. What is the problem? debugging information would help (ssh -vvv; sshd -ddd). what happens when you run a client? also: [stevesk at scott stevesk]$ echo $DISPLAY localhost:10.0 [stevesk at scott stevesk]$ xauth list scott/unix:10 MIT-MAGIC-COOKIE-1 6b18d84bd88a222d6c78fa582cfece84 scott/unix:11 MIT-MAGIC-COOKIE-1 5ce99b3240b88a2ab4624e80fb0cd790 scott/unix:12 MIT-MAGIC-COOKIE-1 1b686867a502022b8fc55e263dd8db31 From djm at mindrot.org Tue May 7 10:22:44 2002 From: djm at mindrot.org (Damien Miller) Date: Tue, 7 May 2002 10:22:44 +1000 (EST) Subject: mysterious connection breakdown - resolved In-Reply-To: <20020506151000.B14510@informatik.tu-chemnitz.de> Message-ID: On Mon, 6 May 2002, Tino Schwarze wrote: > Hi there, > I was able to get things working. I do not get "Corrupted check bytes on > input" any more. I'm not sure what the cause was though. First, I > installed OpenSSH 3.1p1. Then, I explicitly disabled anything not > needed: ssh -2 -4 -a -n -T -x $host $script Can you post a full debug trace "ssh -v -v -v host"? We can't really debug if we don't see the full error. -d From djm at mindrot.org Tue May 7 10:28:00 2002 From: djm at mindrot.org (Damien Miller) Date: Tue, 7 May 2002 10:28:00 +1000 (EST) Subject: SCP file corruptions In-Reply-To: Message-ID: On Mon, 6 May 2002, GATHMAN,DON (HP-Boise,ex1) wrote: > Thanks for the replies.. > > My use of scp was just as Nico described, and I'm using SSHv1. I guess I'm > without a paddle on the file I corrupted. I'll chalk it up to a Monday > morning lesson and see if I can update SSH on the machines I'm working > with.. This problem has come up before: "scp fileA fileA" will give an error, while "scp fileA localhost:fileA" will silently corrupt the file. There is no real way we can detect the latter in the general case. -d From djm at mindrot.org Tue May 7 12:24:44 2002 From: djm at mindrot.org (Damien Miller) Date: Tue, 7 May 2002 12:24:44 +1000 (EST) Subject: patch: contrib/redhat/openssh.spec updates for privsep In-Reply-To: Message-ID: On Tue, 7 May 2002, Pekka Savola wrote: > Hello! > > Now that PrivSep stuff works for PAM too, I took the time to update > contrib/redhat/openssh.spec to create the sshd user and set up the > /var/empty dir when installing the packages. > > These have been done the Red Hat style, the uid/gif 74 is currently free > in RHL. > > The only minor issues I could think of were: > - I'm not sure if /var/empty should be owned by openssh-server package, > but rather a filesystems package or such.. Agreed - I was thinking of making it /var/run/empty until such time as there is an officially blessed place for it. > Is this even LSB compliant? No idea :) > - do all of these 'useradd' options also work in some "ancient" versions > of RHL, like 5.2? Since the spec won't build with rpm < 4.x I don't think that this is too much of a problem. I'll take a look at the patch itself when time permits, probably this weekend. -d From pekkas at netcore.fi Tue May 7 15:25:06 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 7 May 2002 08:25:06 +0300 (EEST) Subject: PrivSep and SSH1 [Re: patch: contrib/redhat/openssh.spec updates for privsep] In-Reply-To: Message-ID: Hi, By the way, I just noticed that PrivSep + SSH1 (+PAM) does not work. This is probably known already.. but PrivSep + SSH1 works for OpenBSD, so this may only be some bug. Connecting log: [...] debug1: Host 'netcore.fi' is known and matches the RSA1 host key. debug1: Found key in /home/oldwolf/.ssh/known_hosts:1 debug1: Encryption type: blowfish debug1: Sent encrypted session key. debug1: Installing crc compensation attack detector. debug1: Received encrypted confirmation. Connection closed by 193.94.160.1 Server log: [...] Connection from ::ffff:130.233.25.176 port 49395 debug1: Client protocol version 1.5; client software version OpenSSH_2.9 FreeBSD localisations 20020307 debug1: match: OpenSSH_2.9 FreeBSD localisations 20020307 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1* debug1: Local version string SSH-1.99-OpenSSH_3.2.1p1 debug2: Network child is on pid 2016 debug3: preauth child monitor started debug3: mm_request_receive entering debug3: privsep user:group 74:74 debug1: PAM establishing creds debug1: PAM setcred failed[4]: System error <=== HMM?? debug1: Sent 768 bit server key and 1024 bit host key. debug1: Encryption type: blowfish debug3: mm_request_send entering: type 26 debug3: monitor_read: checking request 26 debug3: mm_request_receive_expect entering: type 27 debug3: mm_request_receive entering debug3: mm_request_send entering: type 27 debug2: monitor_read: 26 used once, disabling now debug3: mm_request_receive entering debug3: mm_ssh1_session_id entering debug3: mm_request_send entering: type 28 debug1: Received session key; encryption turned on. debug3: monitor_read: checking request 28 debug3: mm_answer_sessid entering debug2: monitor_read: 28 used once, disabling now debug3: mm_request_receive entering debug1: Installing crc compensation attack detector. debug3: mm_getpwnamallow entering debug3: mm_request_send entering: type 6 debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM debug3: mm_request_receive_expect entering: type 7 debug3: mm_request_receive entering debug3: monitor_read: checking request 6 debug3: mm_answer_pwnamallow debug3: Trying to reverse map address 130.233.25.176. debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 debug3: mm_request_send entering: type 7 debug2: monitor_read: 6 used once, disabling now debug3: mm_request_receive entering debug3: mm_start_pam entering debug3: mm_request_send entering: type 35 debug1: Attempting authentication for pekkas. debug3: mm_auth_password entering debug3: mm_request_send entering: type 8 debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: mm_request_receive_expect entering: type 9 debug3: mm_request_receive entering debug3: monitor_read: checking request 35 monitor_read: unsupported request: 35 debug1: Calling cleanup 0x806cee0(0x0) One comment below. On Tue, 7 May 2002, Damien Miller wrote: > On Tue, 7 May 2002, Pekka Savola wrote: > > > Hello! > > > > Now that PrivSep stuff works for PAM too, I took the time to update > > contrib/redhat/openssh.spec to create the sshd user and set up the > > /var/empty dir when installing the packages. > > > > These have been done the Red Hat style, the uid/gif 74 is currently free > > in RHL. > > > > The only minor issues I could think of were: > > - I'm not sure if /var/empty should be owned by openssh-server package, > > but rather a filesystems package or such.. > > Agreed - I was thinking of making it /var/run/empty until such time as > there is an officially blessed place for it. A good idea. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From Irene.Geiseler at lrz-muenchen.de Tue May 7 17:46:30 2002 From: Irene.Geiseler at lrz-muenchen.de (I. Geiseler) Date: Tue, 07 May 2002 09:46:30 +0200 Subject: openssh-3.0.2p1 with AFS and Irix 6.5.12 Message-ID: <3CD78656.9E5142A0@lrz-muenchen.de> Dear all, I've tried to install openssh-3.0.2p1 with AFS-support on a Irix 6.5.12 Maschine. I can login as a local user, but I can't login as AFS-User. The message is : AFS token for cell lrz-muenchen.de rejected. and then : Permission denied. I have installed krb4-1.1, openssl-0.9.6c, zlib-1.1.4, prngd-0.9.24 and I've compiled all that with ggc and mabi=n32. The configure options were: --prefix=/usr/local/openssh --exec-prefix=/usr/local/openssh --sysconfdir=/etc/openssh --with-utmpx --with-pid-dir=/etc/openssh --with-xauth=/usr/bin/X11 --with-ipv4-default --with-ssl-dir=/usr/local/ssl --with-random=/usr/local/prngd/prngd-seed --with-prngd-socket=/var/run/egd-pool --with-zlib=/usr/local /lib--with-kerberos4=/usr/athena4.1 --with-afs=/usr/afsws The openssh is pached (radix.c, bufaux*). Could you help me please? Best regards Irene Geiseler -- Leibniz-Rechenzentrum der Bayerischen Akademie Irene Geiseler der Wissenschaften, Abteilung Rechensysteme, Tel. +49 89 289-28755 Gruppe Hochleistungssysteme EMail: geiseler at lrz.de Barer Strasse 21, D-80333 Muenchen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020507/ce32dd56/attachment.html From tino.schwarze at informatik.tu-chemnitz.de Tue May 7 18:15:52 2002 From: tino.schwarze at informatik.tu-chemnitz.de (Tino Schwarze) Date: Tue, 7 May 2002 10:15:52 +0200 Subject: mysterious connection breakdown - resolved In-Reply-To: ; from djm@mindrot.org on Tue, May 07, 2002 at 10:22:44AM +1000 References: <20020506151000.B14510@informatik.tu-chemnitz.de> Message-ID: <20020507101552.A16170@informatik.tu-chemnitz.de> On Tue, May 07, 2002 at 10:22:44AM +1000, Damien Miller wrote: > > I was able to get things working. I do not get "Corrupted check bytes on > > input" any more. I'm not sure what the cause was though. First, I > > installed OpenSSH 3.1p1. Then, I explicitly disabled anything not > > needed: ssh -2 -4 -a -n -T -x $host $script > > Can you post a full debug trace "ssh -v -v -v host"? We can't really > debug if we don't see the full error. I tried to construct a test script and got all kinds of silly behaviour! :-( Often, the remote sshd just hung. After killing it, I got mailed some of the output of my script but not all. I could not get it to work on the command line though - redirecting stdin, stdout and stderr did not help. The error appears only when run from cron. Here are two examples (including the script triggering the bug). The first one produced a hanging sshd without any childs - I had to kill it. >----------------trace.sshbug.1-------------- From: root at agricola-gymnasium.de (Cron Daemon) To: tisc at agricola-gymnasium.de Subject: Cron /root/bugtrace.ssh X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: Status: RO Content-Length: 3594 Lines: 116 +++ 07.05,10:02 - we currently execute this script: #!/bin/bash # # test des SSH-Bugs function log_event () { echo "+++ `date +%d.%m,%H:%M` - $*" } if [ "$1" = "remote" ] ; then log_event " we're on the remote host." # just some random messages to produce output echo cleaning $MOVEDFILES echo cp /dev/null "$MOVEDFILES" echo cleaning $CHANGEDFILES echo cp /dev/null "$CHANGEDFILES" #echo set -x #set -x echo starting sleep 5 log_event " remote script ended." exit 0 fi log_event " we currently execute this script:" cat $0 log_event " copying script to remote host." scp $0 www-intern:$0 log_event " running script on remote host" ssh -v -v -v www-intern $0 remote # it works this way: #ssh -2 -4 -a -n -T -x www-intern $0 remote log_event " done." +++ 07.05,10:02 - copying script to remote host. +++ 07.05,10:02 - running script on remote host OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090601f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 0 geteuid 0 anon 1 debug1: Connecting to www-intern [10.1.2.1] port 22. debug1: temporarily_use_uid: 0/0 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 0/0 (e=0) debug1: restore_uid debug1: Connection established. debug1: read PEM private key done: type DSA debug1: read PEM private key done: type RSA debug1: identity file /root/.ssh/identity type 0 debug1: identity file /root/.ssh/id_rsa type 0 debug3: Not a RSA1 key file /root/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file /root/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.1p1 debug1: match: OpenSSH_3.1p1 pat OpenSSH* debug1: Local version string SSH-1.5-OpenSSH_3.1p1 debug1: Waiting for server public key. debug1: Received server public key (768 bits) and host key (1024 bits). debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug1: Host 'www-intern' is known and matches the RSA1 host key. debug1: Found key in /root/.ssh/known_hosts:1 debug1: Encryption type: blowfish debug1: Sent encrypted session key. debug1: Installing crc compensation attack detector. debug1: Received encrypted confirmation. debug1: Trying RSA authentication with key '/root/.ssh/identity' debug1: Received RSA challenge from server. debug1: Sending response to host key RSA challenge. debug1: Remote: RSA authentication accepted. debug1: RSA authentication accepted by server. debug3: clear hostkey 0 debug3: clear hostkey 1 debug3: clear hostkey 2 debug1: Sending command: /root/bugtrace.ssh remote debug1: Entering interactive session. debug2: fd 0 is O_NONBLOCK debug1: fd 1 setting O_NONBLOCK debug2: fd 2 is O_NONBLOCK +++ 07.05,10:02 - we're on the remote host. cleaning cp /dev/null cleaning cp /dev/null starting Disconnecting: Corrupted check bytes on input. debug1: Calling cleanup 0x80645c0(0x0) +++ 07.05,10:04 - done. >----------------trace.sshbug.1-------------- If I uncomment the "set -x", then I get (and don't need to kill sshd). >----------------trace.sshbug.2-------------- From: root at agricola-gymnasium.de (Cron Daemon) To: tisc at agricola-gymnasium.de Subject: Cron /root/bugtrace.ssh X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: Status: RO Content-Length: 3520 Lines: 112 +++ 07.05,10:09 - we currently execute this script: #!/bin/bash # # test des SSH-Bugs function log_event () { echo "+++ `date +%d.%m,%H:%M` - $*" } if [ "$1" = "remote" ] ; then log_event " we're on the remote host." # just some random messages to produce output #echo cleaning $MOVEDFILES #echo cp /dev/null "$MOVEDFILES" #echo cleaning $CHANGEDFILES #echo cp /dev/null "$CHANGEDFILES" #echo set -x set -x echo starting sleep 5 log_event " remote script ended." exit 0 fi log_event " we currently execute this script:" cat $0 log_event " copying script to remote host." scp $0 www-intern:$0 log_event " running script on remote host" ssh -v -v -v www-intern $0 remote # it works this way: #ssh -2 -4 -a -n -T -x www-intern $0 remote log_event " done." +++ 07.05,10:09 - copying script to remote host. +++ 07.05,10:09 - running script on remote host OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090601f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 0 geteuid 0 anon 1 debug1: Connecting to www-intern [10.1.2.1] port 22. debug1: temporarily_use_uid: 0/0 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 0/0 (e=0) debug1: restore_uid debug1: Connection established. debug1: read PEM private key done: type DSA debug1: read PEM private key done: type RSA debug1: identity file /root/.ssh/identity type 0 debug1: identity file /root/.ssh/id_rsa type 0 debug3: Not a RSA1 key file /root/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file /root/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.1p1 debug1: match: OpenSSH_3.1p1 pat OpenSSH* debug1: Local version string SSH-1.5-OpenSSH_3.1p1 debug1: Waiting for server public key. debug1: Received server public key (768 bits) and host key (1024 bits). debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug1: Host 'www-intern' is known and matches the RSA1 host key. debug1: Found key in /root/.ssh/known_hosts:1 debug1: Encryption type: blowfish debug1: Sent encrypted session key. debug1: Installing crc compensation attack detector. debug1: Received encrypted confirmation. debug1: Trying RSA authentication with key '/root/.ssh/identity' debug1: Received RSA challenge from server. debug1: Sending response to host key RSA challenge. debug1: Remote: RSA authentication accepted. debug1: RSA authentication accepted by server. debug3: clear hostkey 0 debug3: clear hostkey 1 debug3: clear hostkey 2 debug1: Sending command: /root/bugtrace.ssh remote debug1: Entering interactive session. debug2: fd 0 is O_NONBLOCK debug1: fd 1 setting O_NONBLOCK debug2: fd 2 is O_NONBLOCK + echo starting + sleep 5 Disconnecting: Corrupted check bytes on input. debug1: Calling cleanup 0x80645c0(0x0) +++ 07.05,10:09 - done. >----------------trace.sshbug.2-------------- -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ From tino.schwarze at informatik.tu-chemnitz.de Tue May 7 18:20:21 2002 From: tino.schwarze at informatik.tu-chemnitz.de (Tino Schwarze) Date: Tue, 7 May 2002 10:20:21 +0200 Subject: mysterious connection breakdown - resolved In-Reply-To: ; from djm@mindrot.org on Tue, May 07, 2002 at 10:22:44AM +1000 References: <20020506151000.B14510@informatik.tu-chemnitz.de> Message-ID: <20020507102021.B16170@informatik.tu-chemnitz.de> On Tue, May 07, 2002 at 10:22:44AM +1000, Damien Miller wrote: > > Hi there, > > I was able to get things working. I do not get "Corrupted check bytes on > > input" any more. I'm not sure what the cause was though. First, I > > installed OpenSSH 3.1p1. Then, I explicitly disabled anything not > > needed: ssh -2 -4 -a -n -T -x $host $script > > Can you post a full debug trace "ssh -v -v -v host"? We can't really > debug if we don't see the full error. Additional information: If I add "-n", everything works fine: >----------------trace.sshbug.3---------------- From: root at agricola-gymnasium.de (Cron Daemon) To: tisc at agricola-gymnasium.de Subject: Cron /root/bugtrace.ssh X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: Status: RO Content-Length: 3982 Lines: 129 +++ 07.05,10:18 - we currently execute this script: #!/bin/bash # # test des SSH-Bugs function log_event () { echo "+++ `date +%d.%m,%H:%M` - $*" } if [ "$1" = "remote" ] ; then log_event " we're on the remote host." # just some random messages to produce output echo cleaning $MOVEDFILES echo cp /dev/null "$MOVEDFILES" echo cleaning $CHANGEDFILES echo cp /dev/null "$CHANGEDFILES" echo set -x set -x echo starting sleep 5 log_event " remote script ended." exit 0 fi log_event " we currently execute this script:" cat $0 log_event " copying script to remote host." scp $0 www-intern:$0 log_event " running script on remote host" ssh -n -v -v -v www-intern $0 remote # it works this way: #ssh -2 -4 -a -n -T -x www-intern $0 remote log_event " done." +++ 07.05,10:18 - copying script to remote host. +++ 07.05,10:18 - running script on remote host OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090601f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 0 geteuid 0 anon 1 debug1: Connecting to www-intern [10.1.2.1] port 22. debug1: temporarily_use_uid: 0/0 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 0/0 (e=0) debug1: restore_uid debug1: Connection established. debug1: read PEM private key done: type DSA debug1: read PEM private key done: type RSA debug1: identity file /root/.ssh/identity type 0 debug1: identity file /root/.ssh/id_rsa type 0 debug3: Not a RSA1 key file /root/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file /root/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.1p1 debug1: match: OpenSSH_3.1p1 pat OpenSSH* debug1: Local version string SSH-1.5-OpenSSH_3.1p1 debug1: Waiting for server public key. debug1: Received server public key (768 bits) and host key (1024 bits). debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug1: Host 'www-intern' is known and matches the RSA1 host key. debug1: Found key in /root/.ssh/known_hosts:1 debug1: Encryption type: blowfish debug1: Sent encrypted session key. debug1: Installing crc compensation attack detector. debug1: Received encrypted confirmation. debug1: Trying RSA authentication with key '/root/.ssh/identity' debug1: Received RSA challenge from server. debug1: Sending response to host key RSA challenge. debug1: Remote: RSA authentication accepted. debug1: RSA authentication accepted by server. debug3: clear hostkey 0 debug3: clear hostkey 1 debug3: clear hostkey 2 debug1: Sending command: /root/bugtrace.ssh remote debug1: Entering interactive session. debug2: fd 0 is O_NONBLOCK debug1: fd 1 setting O_NONBLOCK debug2: fd 2 is O_NONBLOCK debug1: Sending eof. + echo starting + sleep 5 +++ 07.05,10:18 - we're on the remote host. cleaning cp /dev/null cleaning cp /dev/null set -x starting + log_event ' remote script ended.' ++ date +%d.%m,%H:%M + echo '+++ 07.05,10:18 - remote script ended.' + exit 0 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK debug2: fd 2 is not O_NONBLOCK +++ 07.05,10:18 - remote script ended. debug1: Transferred: stdin 0, stdout 153, stderr 147 bytes in 5.0 seconds debug1: Bytes per second: stdin 0.0, stdout 30.4, stderr 29.2 debug1: Exit status 0 +++ 07.05,10:18 - done. >----------------trace.sshbug.3---------------- -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ From dtucker at zip.com.au Tue May 7 21:09:45 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 07 May 2002 21:09:45 +1000 Subject: tunnel connection like a service with cygwin orotherproducts? References: Message-ID: <3CD7B5F9.8A7BC75E@zip.com.au> Stephan Hendl wrote: >Darren Tucker wrote: >> The first part should be easy: use cygwin openssh client using some kind >> of passwordless authentication (eg RSA). >> >> To make it run entirely in the background, run it from cygrunsrv (part >> of Cygwin) or SRVANY (NT resource kit). Neither of these work on W95, >> only NT or W2K. > > How does the cygrunsrv work? Unfortunately I cannot find this utility in the cygwin distribution... Download the setup.exe from sources.redhat.com/cygwin. You can find cygrunsrv under "Admin" Category. I just set up a basic forwarder. The steps I took were (on the client): # ssh-keygen -t rsa -f /.ssh/id_rsa Generating public/private rsa key pair. [set a null password] # scp /.ssh/id_rsa.pub dtucker at 192.168.1.1:.ssh/authorized_keys Password: # ssh 192.168.1.1 echo passwordless auth works passwordless auth works # cygrunsrv -I SSHFWD -p /usr/bin/ssh -a "-L 3128:192.168.1.1:3128 -v -N -l dtucker 192.168.1.1" # net start SSHFWD # netstat -an | grep 3128 TCP 127.0.0.1:3128 0.0.0.0:0 LISTENING # telnet 127.0.0.1 3128 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. HEAD http://www.openssh.com/ HTTP/1.0 HTTP/1.0 200 OK [snip] Connection closed by foreign host. # tail -1 /var/log/SSHFWD.log debug1: channel_free: channel 1: direct-tcpip: listening port 3128 for 192.168.1.1 port 3128, connect from 127.0.0.1 port 1891, nchannels 2 For production use, you'd probably want to set up a dedicated account (possibly with a shell of /bin/false), make the authetication stronger (eg by specifying "from=" on the authorized_keys entry) and write a wrapper script for the client side to restart on connection failure. -Daz. From johnh at aproposretail.com Wed May 8 00:27:22 2002 From: johnh at aproposretail.com (John Hardin) Date: 07 May 2002 07:27:22 -0700 Subject: X11 forwarding and LBX Message-ID: <1020781643.9859.12.camel@johnh.apropos.com> So I'm working from home today, and for the first time I've tried running Evolution over a forwarded X11 connection. Even though work has a T1 and I have 640k at home, and ssh is compressing, it's ... rather slow. So I fire off lbxproxy and try to run an xterm to see if it works. No dice, authentication denied. Does anybody have any experience with this? Is it possible to run lbxproxy and ssh X11 forwarding simultaneously? If so, does it result in any noticable performance gains over basic ssh compressing? -- John Hardin Internal Systems Administrator voice: (425) 672-1304 Apropos Retail Management Systems, Inc. fax: (425) 672-0192 ----------------------------------------------------------------------- "To disable the Internet to save EMI and Disney is the moral equivalent of burning down the library of Alexandria to ensure the livelihood of monastic scribes." -- John Ippolito of the Guggenheim ----------------------------------------------------------------------- 9 days until Star Wars episode II: Attack of the Clones From sherwin at nlm.nih.gov Wed May 8 00:34:47 2002 From: sherwin at nlm.nih.gov (Ziying Sherwin) Date: Tue, 7 May 2002 10:34:47 -0400 (EDT) Subject: X11 forwarding does not work as normal user In-Reply-To: Message-ID: Thanks very much for the reply. When I tried to use ssh both as normal user and super user with "-vvv" option, I found some difference between two outputs. The outputs are appended below. Apparently, there is no debugging information about requesting X11 forwarding if I use ssh as a normal user and DISPLAY variable is not set either. Is there something wrong with the code or the configuration that I used? Thanks, Ziying ------------------------------------------------------------------------------ Output from "ssh -vvv noble -l " as super user >ssh -vvv noble -l foo [debug information] debug1: authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey [...] debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: next auth method to try is password foo at noble's password: debug1: packet_send2: adding 64 (len 58 padlen 6 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: ssh-userauth2 successful: method password debug3: clear hostkey 0 debug3: clear hostkey 1 debug3: clear hostkey 2 debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug2: callback start debug1: ssh_session2_setup: id 0 debug1: channel request 0: pty-req debug3: tty_make_modes: ospeed 9600 debug3: tty_make_modes: ispeed 9600 debug3: tty_make_modes: 1 3 [...] debug3: tty_make_modes: 92 0 debug3: tty_make_modes: 93 0 debug2: x11_get_proto /usr/openwin/bin/xauth list :0.0 2>/dev/null debug1: Requesting X11 forwarding with authentication spoofing. debug1: channel request 0: x11-req debug1: channel request 0: shell debug1: fd 5 setting TCP_NODELAY debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 Last login: Tue May 7 09:59:01 2002 from hume Sun Microsystems Inc. SunOS 5.8 Generic February 2000 debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 49464 debug1: fd 9 setting O_NONBLOCK debug2: fd 9 is O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 nob[foo]csh:51>echo $DISPLAY localhost:10.0 nob[foo]csh:52>xauth list noble:0 MIT-MAGIC-COOKIE-1 542e4645344831694c3164595a513559 noble/unix:0 MIT-MAGIC-COOKIE-1 542e4645344831694c3164595a513559 130.14.35.142:0 MIT-MAGIC-COOKIE-1 435433683137484e51415761444b7348 image3pc:0 MIT-MAGIC-COOKIE-1 7976416b43797453317662554133314c [...] Output from "ssh -vvv noble " as normal user hum[zs]ksh:306>ssh -vvv noble -l foo [debug message] debug1: authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey [...] debug2: we sent a keyboard-interactive packet, wait for reply debug1: authentications that can continue: publickey,password,keyboard-interactive debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: next auth method to try is password foo at noble's password: debug1: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: ssh-userauth2 successful: method password debug3: clear hostkey 0 debug3: clear hostkey 1 debug3: clear hostkey 2 debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug2: callback start debug1: ssh_session2_setup: id 0 debug1: channel request 0: pty-req debug3: tty_make_modes: ospeed 9600 debug3: tty_make_modes: ispeed 9600 debug3: tty_make_modes: 1 3 [...] debug3: tty_make_modes: 92 0 debug3: tty_make_modes: 93 0 debug1: channel request 0: shell debug1: fd 6 setting TCP_NODELAY debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 Last login: Mon May 6 13:48:17 2002 from noble Sun Microsystems Inc. SunOS 5.8 Generic February 2000 nob[foo]ksh:156>nob[zs]ksh:157>echo $DISPLAY nob[zs]ksh:158>xauth list hume:0 MIT-MAGIC-COOKIE-1 7a76423953564963475a397735434777 hume/unix:0 MIT-MAGIC-COOKIE-1 7a76423953564963475a397735434777 noble:0 MIT-MAGIC-COOKIE-1 386a366156644f4b5141667642516c56 noble/unix:0 MIT-MAGIC-COOKIE-1 386a366156644f4b5141667642516c56 [...] On Mon, 6 May 2002, Kevin Steves wrote: > On Mon, 6 May 2002, Ziying Sherwin wrote: > :The X11 forwarding works fine if we logged as super user, but does not work > :for normal users. What is the problem? > > debugging information would help (ssh -vvv; sshd -ddd). what happens when > you run a client? also: > > [stevesk at scott stevesk]$ echo $DISPLAY > localhost:10.0 > [stevesk at scott stevesk]$ xauth list > scott/unix:10 MIT-MAGIC-COOKIE-1 6b18d84bd88a222d6c78fa582cfece84 > scott/unix:11 MIT-MAGIC-COOKIE-1 5ce99b3240b88a2ab4624e80fb0cd790 > scott/unix:12 MIT-MAGIC-COOKIE-1 1b686867a502022b8fc55e263dd8db31 > > From jmknoble at pobox.com Wed May 8 04:07:54 2002 From: jmknoble at pobox.com (Jim Knoble) Date: Tue, 7 May 2002 14:07:54 -0400 Subject: patch: contrib/redhat/openssh.spec updates for privsep In-Reply-To: ; from djm@mindrot.org on Tue, May 07, 2002 at 12:24:44PM +1000 References:

Message-ID: <20020507140754.A1408@zax.half.pint-stowp.cx> Circa 2002-May-07 12:24:44 +1000 dixit Damien Miller: : On Tue, 7 May 2002, Pekka Savola wrote: : : > Now that PrivSep stuff works for PAM too, I took the time to update : > contrib/redhat/openssh.spec to create the sshd user and set up the : > /var/empty dir when installing the packages. : > : > These have been done the Red Hat style, the uid/gif 74 is currently free : > in RHL. : > : > The only minor issues I could think of were: : > - I'm not sure if /var/empty should be owned by openssh-server package, : > but rather a filesystems package or such.. : : Agreed - I was thinking of making it /var/run/empty until such time as : there is an officially blessed place for it. vsftpd uses /usr/share/empty. However, either or both of /usr and /usr/share could be network-mounted. I also don't like the idea of several servers potentially chrooted into the same directory. : > Is this even LSB compliant? : : No idea :) According to FHS-2.2, /var/run/ is allowed. I would advocate either /var/run/openssh/empty/ or /var/run/sshd/empty/, so that no other service is liable to be chrooted into the same spot. However, note this: 5.13 /var/run : Run-time variable data 5.13.1 [...] Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process. [...] Unless there will never be any files inside .../empty/, this sounds like /var/run/ may not be the right place. In that case, i would advocate either /var/lib/openssh/empty/ or /var/lib/sshd/empty/. FHS-2.2 seems to indicate that /var/lib/, not /var/lib/, is preferred. Thus, /var/lib/openssh/empty/ would be the preferred spot. : > - do all of these 'useradd' options also work in some "ancient" versions : > of RHL, like 5.2? : : Since the spec won't build with rpm < 4.x I don't think that this is too : much of a problem. useradd is part of shadow-utils, which does come with RHL-5.x. It doesn't come with 4.x, but folks who are still using it really should have backported shadow-utils to RHL-4.x by now (along with other useful things such as chkconfig, recent automake/autoconf/libtool, recent EGCS or GCC compiler, recent rsync, openssl, etc.). I don't think there's any problem with using 'useradd' in the %pre scriptlet. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 262 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020507/721b6f87/attachment.bin From sherwin at nlm.nih.gov Wed May 8 06:11:02 2002 From: sherwin at nlm.nih.gov (Ziying Sherwin) Date: Tue, 7 May 2002 16:11:02 -0400 (EDT) Subject: X11 forwarding does not work as normal user In-Reply-To: <3CD80335.8B30D5A3@pico.apple.com> Message-ID: Thanks again for the reply. Following your instruction, I captured the output on both server and client side. The transcript is appended below. It seems that if I use ssh as a super user on the client side, there are several extra lines on the server output (those lines are marked with >>>> in the attachment): >>>debug1: server_input_channel_req: channel 0 request x11-req reply 0 >>>debug1: session_by_channel: session 0 channel 0 >>>debug1: session_input_channel_req: session 0 req x11-req >>>debug1: fd 12 setting O_NONBLOCK >>>debug2: fd 12 is O_NONBLOCK >>>debug1: channel 1: new [X11 inet listener] >>>debug1: fd 13 setting O_NONBLOCK >>>debug2: fd 13 is O_NONBLOCK >>>debug1: channel 2: new [X11 inet listener]1 On the client side, there are a few extra lines if the client is a super user: debug2: x11_get_proto /usr/openwin/bin/xauth list :0.0 2>/dev/null debug1: Requesting X11 forwarding with authentication spoofing. debug1: channel request 0: x11-req The difference between super users and normal users is that the super users set their DISPLAY environmental variable, while the normal users do not. Also the super users and normal users have different privillege over the configuration file ssh_config. Then, I further checked the code by putting additional lines to print the debug information. It seems that in routine ssh_session2_setup in ssh.c file, the program checks whether forward_x11 option is set AND the environmental variable DISPLAY is set. In our case, we set the forward_x11 option in the /etc/ssh_config file, however, from the debuggin message, the forward_x11 option is not set unless we manually specify it in the command line using "-X" option. And since DISPLAY is not set either, the function x11_get_proto is not called for normal users. So here is our questions: 1. We used to use ssh as security shell. It works for both super users and normal users no matter whether the DISPLAY environmental variable is set or not. We are using both CDE and openwin on Solaris 2.8 platform. As a widely used security shell, openssh should not decide whether to establish a X11 forwarding based on the assumtion that all users set their DISPLAY environmental variable. Is it possible for openssh to handle this more flexible? 2. Why the X11 forwarding setting does not get picked up by normal user? Thanks. Ziying ------------------------------------------------------------------------------ Output from "ssh -vvv noble -l " as super user >ssh -vvv noble -l foo [debug information] debug1: authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey [...] debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: next auth method to try is password foo at noble's password: debug1: packet_send2: adding 64 (len 58 padlen 6 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: ssh-userauth2 successful: method password debug3: clear hostkey 0 debug3: clear hostkey 1 debug3: clear hostkey 2 debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug2: callback start debug1: ssh_session2_setup: id 0 debug1: channel request 0: pty-req debug3: tty_make_modes: ospeed 9600 debug3: tty_make_modes: ispeed 9600 debug3: tty_make_modes: 1 3 [...] debug3: tty_make_modes: 92 0 debug3: tty_make_modes: 93 0 debug2: x11_get_proto /usr/openwin/bin/xauth list :0.0 2>/dev/null debug1: Requesting X11 forwarding with authentication spoofing. debug1: channel request 0: x11-req debug1: channel request 0: shell debug1: fd 5 setting TCP_NODELAY debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 debug3: Trying to reverse map address 130.14.31.40. Last login: Tue May 7 11:12:24 2002 from :0 Environment: USER=foo LOGNAME=foo HOME=/home/foo PATH=/usr/bin:/bin:/usr/sbin:/sbin MAIL=/var/mail//foo SHELL=/bin/ksh TZ=US/Eastern SSH_CLIENT=130.14.31.40 34829 22 SSH_TTY=/dev/pts/8 TERM=sun-cmd DISPLAY=localhost:10.0 debug3: channel_close_fds: channel 0: r -1 w -1 e -1 debug3: channel_close_fds: channel 1: r 12 w 12 e -1 debug3: channel_close_fds: channel 2: r 13 w 13 e -1 Running /usr/openwin/bin/xauth add unix:10.0 MIT-MAGIC-COOKIE-1 45b4a6b13aaf6d34e15c6874b43b8ba0 debug1: Received SIGCHLD. Sun Microsystems Inc. SunOS 5.8 Generic February 2000 debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 38777 debug1: fd 9 setting O_NONBLOCK debug2: fd 9 is O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 debug1: channel 1: rcvd eof debug1: channel 1: output open -> drain debug1: channel 1: obuf empty debug1: channel 1: close_write debug1: channel 1: output drain -> closed debug1: channel 1: FORCE input drain debug1: channel 1: ibuf empty debug1: channel 1: send eof debug1: channel 1: input drain -> closed debug1: channel 1: send close debug3: channel 1: will not send data after close debug1: channel 1: rcvd close debug3: channel 1: will not send data after close debug1: channel 1: is dead debug1: channel 1: garbage collecting debug1: channel_free: channel 1: x11, nchannels 2 debug3: channel_free: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/0 fd 6/7) #1 x11 (t4 r3 i3/0 o3/0 fd 9/9) debug3: channel_close_fds: channel 1: r 9 w 9 e -1 debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 38778 debug1: fd 9 setting O_NONBLOCK debug2: fd 9 is O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 debug1: channel 1: rcvd eof debug1: channel 1: output open -> drain debug1: channel 1: obuf empty debug1: channel 1: close_write debug1: channel 1: output drain -> closed debug1: channel 1: FORCE input drain debug1: channel 1: ibuf empty debug1: channel 1: send eof debug1: channel 1: input drain -> closed debug1: channel 1: send close debug3: channel 1: will not send data after close debug1: channel 1: rcvd close debug3: channel 1: will not send data after close debug1: channel 1: is dead debug1: channel 1: garbage collecting debug1: channel_free: channel 1: x11, nchannels 2 debug3: channel_free: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/0 fd 6/7) #1 x11 (t4 r3 i3/0 o3/0 fd 9/9) debug3: channel_close_fds: channel 1: r 9 w 9 e -1 mer[zs]ksh:171>echo $DISPLAY localhost:10.0 nob[foo]csh:52>xauth list noble:0 MIT-MAGIC-COOKIE-1 542e4645344831694c3164595a513559 noble/unix:0 MIT-MAGIC-COOKIE-1 542e4645344831694c3164595a513559 130.14.35.142:0 MIT-MAGIC-COOKIE-1 435433683137484e51415761444b7348 image3pc:0 MIT-MAGIC-COOKIE-1 7976416b43797453317662554133314c [...] ------------------------------------------------------------------------------ Output from "ssh -vvv noble " as normal user hum[zs]ksh:306>ssh -vvv noble -l foo [debug message] debug1: authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey [...] debug2: we sent a keyboard-interactive packet, wait for reply debug1: authentications that can continue: publickey,password,keyboard-interactive debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: next auth method to try is password foo at noble's password: debug1: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: ssh-userauth2 successful: method password debug3: clear hostkey 0 debug3: clear hostkey 1 debug3: clear hostkey 2 debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug2: callback start debug1: ssh_session2_setup: id 0 debug1: channel request 0: pty-req debug3: tty_make_modes: ospeed 9600 debug3: tty_make_modes: ispeed 9600 debug3: tty_make_modes: 1 3 [...] debug3: tty_make_modes: 93 0 debug1: channel request 0: shell debug1: fd 6 setting TCP_NODELAY debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 debug3: Trying to reverse map address 130.14.31.40. Last login: Tue May 7 13:43:47 2002 from hume Environment: USER=foo LOGNAME=foo HOME=/home/foo PATH=/usr/bin:/bin:/usr/sbin:/sbin MAIL=/var/mail//foo SHELL=/bin/ksh TZ=US/Eastern SSH_CLIENT=130.14.31.40 34839 22 SSH_TTY=/dev/pts/8 TERM=sun-cmd debug3: channel_close_fds: channel 0: r -1 w -1 e -1 Sun Microsystems Inc. SunOS 5.8 Generic February 2000 mer[zs]ksh:173>echo $DISPLAY nob[zs]ksh:158>xauth list hume:0 MIT-MAGIC-COOKIE-1 7a76423953564963475a397735434777 hume/unix:0 MIT-MAGIC-COOKIE-1 7a76423953564963475a397735434777 noble:0 MIT-MAGIC-COOKIE-1 386a366156644f4b5141667642516c56 noble/unix:0 MIT-MAGIC-COOKIE-1 386a366156644f4b5141667642516c56 [...] ------------------------------------------------------------------------------ Output from "/usr/sbin/sshd -d -d -d" for a connection from super user mer[root]csh:64>/usr/sbin/sshd -d -d -d debug1: sshd version OpenSSH_3.1p1 debug3: Not a RSA1 key file /etc/openssh_3.1p1/etc/ssh_host_rsa_key. [...] debug1: userauth_banner: sent Failed none for foo from 130.14.31.40 port 34848 ssh2 debug1: userauth-request for user foo service ssh-connection method keyboard-interactive debug1: attempt 1 failures 1 debug2: input_userauth_request: try method keyboard-interactive debug1: keyboard-interactive devs debug1: auth2_challenge: user=foo devs= debug1: kbdint_alloc: devices '' debug2: auth2_challenge_start: devices Failed keyboard-interactive for foo from 130.14.21.40 port 34848 ssh2 debug1: userauth-request for user foo service ssh-connection method password debug1: attempt 2 failures 2 debug2: input_userauth_request: try method password Accepted password for foo from 130.14.21.40 port 34848 ssh2 debug1: Entering interactive session for SSH2. debug1: fd 3 setting O_NONBLOCK debug1: fd 9 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request pty-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_pty_req: session 0 alloc /dev/pts/8 debug3: tty_parse_modes: SSH2 n_bytes 266 debug3: tty_parse_modes: ospeed 9600 debug3: tty_parse_modes: ispeed 9600 [...] debug3: tty_parse_modes: 91 1 debug3: tty_parse_modes: 92 0 debug3: tty_parse_modes: 93 0 >>>debug1: server_input_channel_req: channel 0 request x11-req reply 0 >>>debug1: session_by_channel: session 0 channel 0 >>>debug1: session_input_channel_req: session 0 req x11-req >>>debug1: fd 12 setting O_NONBLOCK >>>debug2: fd 12 is O_NONBLOCK >>>debug1: channel 1: new [X11 inet listener] >>>debug1: fd 13 setting O_NONBLOCK >>>debug2: fd 13 is O_NONBLOCK >>>debug1: channel 2: new [X11 inet listener] debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: fd 5 setting TCP_NODELAY debug1: fd 11 setting O_NONBLOCK debug2: fd 10 is O_NONBLOCK debug1: X11 connection requested. debug1: fd 15 setting TCP_NODELAY debug2: fd 15 is O_NONBLOCK debug2: fd 15 is O_NONBLOCK debug1: channel 3: new [X11 connection from 127.0.0.1 port 38781] debug1: channel 3: open confirm rwindow 121 rmax 16384 debug1: channel 3: read<=0 rfd 15 len 0 debug1: channel 3: read failed debug1: channel 3: close_read debug1: channel 3: input open -> drain debug1: channel 3: ibuf empty debug1: channel 3: send eof debug1: channel 3: input drain -> closed debug1: channel 3: rcvd eof debug1: channel 3: output open -> drain debug1: channel 3: obuf empty debug1: channel 3: close_write debug1: channel 3: output drain -> closed debug1: channel 3: rcvd close debug3: channel 3: will not send data after close debug1: channel 3: send close debug1: channel 3: is dead debug1: channel 3: garbage collecting debug1: channel_free: channel 3: X11 connection from 127.0.0.1 port 38781, nchannels 4 debug3: channel_free: status: The following connections are open: #0 server-session (t4 r0 i0/0 o0/0 fd 11/10) #3 X11 connection from 127.0.0.1 port 38781 (t4 r1 i3/0 o3/0 fd 15/15) debug3: channel_close_fds: channel 3: r 15 w 15 e -1 debug1: X11 connection requested. debug1: fd 15 setting TCP_NODELAY debug2: fd 15 is O_NONBLOCK debug2: fd 15 is O_NONBLOCK debug1: channel 3: new [X11 connection from 127.0.0.1 port 38782] debug1: channel 3: open confirm rwindow 131072 rmax 16384 debug1: channel 3: read<=0 rfd 15 len 0 debug1: channel 3: read failed debug1: channel 3: close_read debug1: channel 3: input open -> drain debug1: channel 3: ibuf empty debug1: channel 3: send eof debug1: channel 3: input drain -> closed debug1: channel 3: rcvd eof debug1: channel 3: output open -> drain debug1: channel 3: obuf empty debug1: channel 3: close_write debug1: channel 3: output drain -> closed debug1: channel 3: rcvd close debug3: channel 3: will not send data after close debug1: channel 3: send close debug1: channel 3: is dead debug1: channel 3: garbage collecting debug1: channel_free: channel 3: X11 connection from 127.0.0.1 port 38782, nchannels 4 debug3: channel_free: status: The following connections are open: #0 server-session (t4 r0 i0/0 o0/0 fd 11/10) #3 X11 connection from 127.0.0.1 port 38782 (t4 r1 i3/0 o3/0 fd 15/15) debug3: channel_close_fds: channel 3: r 15 w 15 e -1 debug1: Received SIGCHLD. debug1: session_by_pid: pid 4785 debug1: session_exit_message: session 0 channel 0 pid 4785 debug1: channel request 0: exit-status debug1: session_exit_message: release channel 0 debug1: channel 0: write failed debug1: channel 0: close_write debug1: channel 0: output open -> closed debug1: session_close: session 0 pid 4785 debug1: session_pty_cleanup: session 0 release /dev/pts/8 debug2: notify_done: reading debug1: channel 0: read<=0 rfd 11 len 0 debug1: channel 0: read failed debug1: channel 0: close_read debug1: channel 0: input open -> drain debug1: channel 0: ibuf empty debug1: channel 0: send eof debug1: channel 0: input drain -> closed debug1: channel 0: send close debug3: channel 0: will not send data after close debug1: channel 0: rcvd close debug3: channel 0: will not send data after close debug1: channel 0: is dead debug1: channel 0: garbage collecting debug1: channel_free: channel 0: server-session, nchannels 3 debug3: channel_free: status: The following connections are open: #0 server-session (t4 r0 i3/0 o3/0 fd -1/-1) debug3: channel_close_fds: channel 0: r -1 w -1 e -1 Connection closed by remote host. debug1: channel_free: channel 1: X11 inet listener, nchannels 2 debug3: channel_free: status: The following connections are open: debug3: channel_close_fds: channel 1: r 12 w 12 e -1 debug1: channel_free: channel 2: X11 inet listener, nchannels 1 debug3: channel_free: status: The following connections are open: debug3: channel_close_fds: channel 2: r 13 w 13 e -1 Closing connection to 130.14.21.40 ------------------------------------------------------------------------------ Output from "/usr/sbin/sshd -d -d -d" for a connection from normal user mer[root]csh:68>/usr/sbin/sshd -d -d -d debug1: sshd version OpenSSH_3.1p1 debug3: Not a RSA1 key file /etc/openssh_3.1p1/etc/ssh_host_rsa_key. [...] debug1: userauth_banner: sent Failed none for foo from 130.14.31.40 port 34852 ssh2 debug1: userauth-request for user foo service ssh-connection method keyboard-interactive debug1: attempt 1 failures 1 debug2: input_userauth_request: try method keyboard-interactive debug1: keyboard-interactive devs debug1: auth2_challenge: user=foo devs= debug1: kbdint_alloc: devices '' debug2: auth2_challenge_start: devices Failed keyboard-interactive for foo from 130.14.21.40 port 34852 ssh2 debug1: userauth-request for user foo service ssh-connection method password debug1: attempt 2 failures 2 debug2: input_userauth_request: try method password Accepted password for foo from 130.14.21.40 port 34852 ssh2 debug1: Entering interactive session for SSH2. debug1: fd 3 setting O_NONBLOCK debug1: fd 9 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request pty-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_pty_req: session 0 alloc /dev/pts/8 debug3: tty_parse_modes: SSH2 n_bytes 266 debug3: tty_parse_modes: ospeed 9600 [...] debug3: tty_parse_modes: 92 0 debug3: tty_parse_modes: 93 0 debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: fd 5 setting TCP_NODELAY debug1: fd 11 setting O_NONBLOCK debug2: fd 10 is O_NONBLOCK debug1: Received SIGCHLD. debug1: session_by_pid: pid 4814 debug1: session_exit_message: session 0 channel 0 pid 4814 debug1: channel request 0: exit-status debug1: session_exit_message: release channel 0 debug1: channel 0: write failed debug1: channel 0: close_write debug1: channel 0: output open -> closed debug1: session_close: session 0 pid 4814 debug1: session_pty_cleanup: session 0 release /dev/pts/8 debug2: notify_done: reading debug1: channel 0: read<=0 rfd 11 len 0 debug1: channel 0: read failed debug1: channel 0: close_read debug1: channel 0: input open -> drain debug1: channel 0: ibuf empty debug1: channel 0: send eof debug1: channel 0: input drain -> closed debug1: channel 0: send close debug3: channel 0: will not send data after close debug1: channel 0: rcvd close debug3: channel 0: will not send data after close debug1: channel 0: is dead debug1: channel 0: garbage collecting debug1: channel_free: channel 0: server-session, nchannels 1 debug3: channel_free: status: The following connections are open: #0 server-session (t4 r0 i3/0 o3/0 fd -1/-1) debug3: channel_close_fds: channel 0: r -1 w -1 e -1 Connection closed by remote host. Closing connection to 130.14.21.40 On Tue, 7 May 2002, Dennis Haag wrote: > Hmm, not sure. Try running the server in debug mode (-d -d -d) and the > client in verbose mode (-v -v -v) and compare the output between the one > that works and the one that doesn't. If you are still stuck send the debug > output to the openssh list. > > > Ziying Sherwin wrote: > > > > Thanks you very much for the help. > > > > I tried to build openssh with the three options that you mentioned in the > > email, but it still does not work. Apparently, if I use ssh as super user, > > there is no problem to find the path to the xauth. > > > > On Mon, 6 May 2002, Dennis Haag wrote: > > > > > If you configure it it with the --with-xauth=/usr/openwin/bin/xauth > > > --x-includes=/usr/openwin/include --x-libraries=/usr/openwin/lib options > > > does it work? > > > > > > Ziying Sherwin wrote: > > > > > > > > We installed openssh 3.1p1 on our Solaris 2.8 machine using gcc 2.95.2. During > > > > the installation, we modified ssh_config and sshd_config to enable X11 and > > > > agent forwarding. > > > > > > > > In sshd_config, we changed the following line to read: > > > > > > > > X11Forwarding yes > > > > > > > > In ssh_config, we changed the following two lines to read: > > > > > > > > ForwardAgent yes > > > > ForwardX11 yes > > > > > > > > Both files are set to permission readable to all. > > > > > > > > The X11 forwarding works fine if we logged as super user, but does not work > > > > for normal users. What is the problem? > > > > > > > > Thanks, > > > > Ziying Sherwin > > > > > > > > P.S. I am not on the mailing list, please reply to sherwin at nlm.nih.gov > > > > > > > > _______________________________________________ > > > > openssh-unix-dev at mindrot.org mailing list > > > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > > -- > > > Dennis Haag Engineering Computer Services > > > haag at apple.com unix-support at apple.com > > > 408-974-6630 ECS Hotline: 408-974-4747 > > > > > -- > Dennis Haag Engineering Computer Services > haag at apple.com unix-support at apple.com > 408-974-6630 ECS Hotline: 408-974-4747 > From bugzilla-daemon at mindrot.org Wed May 8 06:21:41 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 8 May 2002 06:21:41 +1000 (EST) Subject: [Bug 208] SCO build/runtime fixes Message-ID: <20020507202141.A0E85E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=208 ------- Additional Comments From gert at greenie.muc.de 2002-05-08 06:21 ------- Tim, thanks for the patch. It works as expected - with the patch applied to CVS as of today (2002/05/07), and my local changes thrown away, everything compiles just fine. So please commit it to the master sources. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From d_wllms at lanl.gov Wed May 8 06:55:11 2002 From: d_wllms at lanl.gov (David Williams) Date: Tue, 07 May 2002 14:55:11 -0600 Subject: snapshots not up-to-date Message-ID: <3CD83F2F.29149D78@lanl.gov> Hey All, Is there a reason that the snapshots in OpenSSH/portable/snapshot stopped on May 1? I am working on building portable to support quite a few Unices and have relyed on the snapshots for my source. Do I need to switch my efforts to building off of the source from CVS?? DW -- David M. Williams Phone: 505-665-5021 Systems Engineer, CCN-2 Fax: 505-667-7428 Los Alamos National Laboratory Email: d_wllms at lanl.gov From bugzilla-daemon at mindrot.org Wed May 8 11:40:45 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 8 May 2002 11:40:45 +1000 (EST) Subject: [Bug 236] New: No setproctitle() replacement for many unices Message-ID: <20020508014045.4D9A9E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=236 Summary: No setproctitle() replacement for many unices Product: Portable OpenSSH Version: -current Platform: Other OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Miscellaneous AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: djm at mindrot.org We don't have a setproctitle() replacement for most unices which lack it ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed May 8 11:41:43 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 8 May 2002 11:41:43 +1000 (EST) Subject: [Bug 236] No setproctitle() replacement for many unices Message-ID: <20020508014143.87328E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=236 ------- Additional Comments From djm at mindrot.org 2002-05-08 11:41 ------- Created an attachment (id=93) setproctitle() replacement for more OSs ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Wed May 8 12:17:31 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 08 May 2002 12:17:31 +1000 Subject: X11 forwarding and LBX References: <1020781643.9859.12.camel@johnh.apropos.com> Message-ID: <3CD88ABB.B74E68D2@zip.com.au> John Hardin wrote: > So I fire off lbxproxy and try to run an xterm to see if it works. No > dice, authentication denied. > > Does anybody have any experience with this? Is it possible to run > lbxproxy and ssh X11 forwarding simultaneously? If so, does it result in > any noticable performance gains over basic ssh compressing? I've used it with a network management product over a WAN link. To open a map with compressing ssh took ~12sec. With LBX, it took ~9sec, but to re-open a map that had previously been opened took <1sec. The script I used to sort out xauth stuff is attached. The caveats are: you need to source it (ie ". ./lbx") and various versions of LBX behave differently so you may need to adjust it to local conditions. I also found that some versions of LBX running on Solaris wouldn't bind() unless they ran as root, although I never figured out why. -Daz. -------------- next part -------------- #!/bin/sh LIBPATH=/usr/X11R6.4/lib:$LIBPATH export LIBPATH PATH=/usr/openwin/bin:$PATH export PATH if [ "$DISPLAY" = "" ] then echo "No DISPLAY variable set, LBX cannot start." exit 1 fi echo Starting Low Bandwidth X proxy. >$HOME/.lbxproxy lbxproxy :10 2> $HOME/.lbxproxy & until egrep "Using port number .[0-9]*." $HOME/.lbxproxy do sleep 1 done lbxport=`awk '/Using port number/{print $4}' $HOME/.lbxproxy | tr -d "'"` LBXDISPLAY="`hostname`:$lbxport.0" authtype=`xauth list $DISPLAY | awk '{print $2}'` authkey=`xauth list $DISPLAY | awk '{print $3}'` if [ ! -z "$authtype" ] then echo "Adding Xauthority for lbxproxy" xauth add $LBXDISPLAY $authtype $authkey else echo "No Xauthority found for display $DISPLAY." echo "You may have authorization problems (especially via SSH!)" fi echo Standard X11 display: $DISPLAY echo LBX proxy display: $LBXDISPLAY ps -eaf |grep [l]bxproxy DISPLAY=$LBXDISPLAY export DISPLAY From djm at mindrot.org Wed May 8 12:29:47 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 8 May 2002 12:29:47 +1000 (EST) Subject: PrivSep and SSH1 [Re: patch: contrib/redhat/openssh.spec updates for privsep] In-Reply-To: Message-ID: On Tue, 7 May 2002, Pekka Savola wrote: > Hi, > > By the way, I just noticed that PrivSep + SSH1 (+PAM) does not work. > > This is probably known already.. but PrivSep + SSH1 works for OpenBSD, so > this may only be some bug. > > debug1: PAM establishing creds > debug1: PAM setcred failed[4]: System error <=== HMM?? Fixed - thanks. > debug3: mm_request_receive_expect entering: type 9 > debug3: mm_request_receive entering > debug3: monitor_read: checking request 35 > monitor_read: unsupported request: 35 Fixed - thanks. -d From djm at mindrot.org Wed May 8 12:36:39 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 8 May 2002 12:36:39 +1000 (EST) Subject: snapshots not up-to-date In-Reply-To: <3CD83F2F.29149D78@lanl.gov> Message-ID: On Tue, 7 May 2002, David Williams wrote: > Hey All, > Is there a reason that the snapshots in OpenSSH/portable/snapshot > stopped on May 1? > I am working on building portable to support quite a few Unices and > have relyed on the snapshots for my source. Do I need to switch my > efforts to building off of the source from CVS?? They look like they are there now. -d From djm at mindrot.org Wed May 8 12:37:39 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 8 May 2002 12:37:39 +1000 (EST) Subject: [Bug 236] No setproctitle() replacement for many unices In-Reply-To: <20020508014143.87328E881@shitei.mindrot.org> Message-ID: On Wed, 8 May 2002, bugzilla-daemon at mindrot.org wrote: > http://bugzilla.mindrot.org/show_bug.cgi?id=236 > > ------- Additional Comments From djm at mindrot.org 2002-05-08 11:41 ------- > Created an attachment (id=93) > setproctitle() replacement for more OSs It would be great if people could test this patch on a wide variety of OSs. I have done some basic testing on Linux. -d From bugzilla-daemon at mindrot.org Wed May 8 12:54:09 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 8 May 2002 12:54:09 +1000 (EST) Subject: [Bug 208] SCO build/runtime fixes Message-ID: <20020508025409.7BCD0E8EA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=208 tim at multitalents.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From tim at multitalents.net 2002-05-08 12:54 ------- Commited patch (attachment 90)to CVS ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed May 8 18:36:17 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 8 May 2002 18:36:17 +1000 (EST) Subject: [Bug 237] New: Key authentication failed with SSH 2 / Path wrong Message-ID: <20020508083617.0FAE7E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=237 Summary: Key authentication failed with SSH 2 / Path wrong Product: Portable OpenSSH Version: 3.1p1 Platform: Sparc OS/Version: Solaris Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: s_guegan at voila.fr Hye, I've installed OpenSSH 3.1p1 on a SUN Sparc station running Solaris 2.6. I've also installed EGD 0.8 and OpenSSL 0.9.6c. The password authentication seems to work correctly but there is apparently a major problem with the key authentication. The OpenSSH server where sshd is running is an NFS client and the users account where the .ssh/ are stored are on an NFS partition. Both client & server are configured to use Protocol 2 only. If I force ssh to follow authentication by SSH 2 and if I give the path to find the private key, here is the result : ++++++++++++ client1 at sgu: slogin -v -i ~/.ssh/id_dsa -2 client1 debug1: authentications that can continue: publickey,keyboard-interactive debug1: next auth method to try is publickey debug1: try pubkey: /export/home/sgu/.ssh/id_dsa debug1: authentications that can continue: publickey,keyboard-interactive debug1: next auth method to try is keyboard-interactive debug1: authentications that can continue: publickey,keyboard-interactive debug1: no more auth methods to try Permission denied (publickey,keyboard-interactive). debug1: Calling cleanup 0x33ecc(0x0) If I try the same thing without options, I've got the following results : ++++++++++++++++++++ client1 at sgu: slogin -v client1 debug1: authentications that can continue: publickey,keyboard-interactive debug1: next auth method to try is publickey debug1: try privkey: /export/home/sgu/.ssh/id_rsa debug1: try pubkey: /export/home/sgu/.ssh/id_dsa debug1: authentications that can continue: publickey,keyboard-interactive debug1: next auth method to try is keyboard-interactive debug1: authentications that can continue: publickey,keyboard-interactive debug1: no more auth methods to try Permission denied (publickey,keyboard-interactive). debug1: Calling cleanup 0x33ecc(0x0) It seems that it doesn't "recognise" correctly SSH 2 and that the 'path' to the keys (public & private) are wrong. I've also noticed that it seems to skip completely the file "authorized_keys" even I specify it "as it is" in sshd_conf! I didn't finish completely the tests but apparently it's working fine with OpenSSH rel. < 3. Thanks in advance and do not hesitate if you need more informations. Kind Regards, S.G. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed May 8 19:25:37 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 8 May 2002 19:25:37 +1000 (EST) Subject: [Bug 237] Key authentication failed with SSH 2 / Path wrong Message-ID: <20020508092537.D7300E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=237 aet at cc.hut.fi changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Key authentication failed |Key authentication failed |with SSH 2 / Path wrong |with SSH 2 / Path wrong ------- Additional Comments From aet at cc.hut.fi 2002-05-08 19:25 ------- Probably yet another broken realpath() implementation, pre 3.x releases only used realpath() for sftp-server. Ben, have you reviewed openbsd-compat/realpath.c yet? I'd still consider applying my SAFE_REALPATH patch. :-) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From astrand at lysator.liu.se Wed May 8 22:53:54 2002 From: astrand at lysator.liu.se (Peter Astrand) Date: Wed, 8 May 2002 14:53:54 +0200 (CEST) Subject: Password from open filedescriptor In-Reply-To: Message-ID: > > > No, it doesn't. It'd be nice if it did (protocol changes required?), > > > though I wonder what the UI would look like. It can't very well ask > > > for a password from the user after it daemonizes itself; is there some > > > standard program it can launch to ask for a password? > > > > It will ask $SSH_ASKPASS for a password if $DISPLAY is set. Have a look > > at http://bugzilla.mindrot.org/show_bug.cgi?id=69 for a patch to make it > > do more. > > Nice. I like it. Will this patch be accepted? Any updates on this issue? I can rewrite my password-from-open-fd-patch to an askpass-program, but it would be nice to know if the SSH_ASKPASS generalization above will be accepted, so I don't write code in vain. -- /Peter ?strand From kevin at atomicgears.com Thu May 9 02:58:04 2002 From: kevin at atomicgears.com (Kevin Steves) Date: Wed, 8 May 2002 09:58:04 -0700 (PDT) Subject: X11 forwarding does not work as normal user In-Reply-To: Message-ID: On Tue, 7 May 2002, Ziying Sherwin wrote: :On the client side, there are a few extra lines if the client is a super user: : : debug2: x11_get_proto /usr/openwin/bin/xauth list :0.0 2>/dev/null : debug1: Requesting X11 forwarding with authentication spoofing. : debug1: channel request 0: x11-req : :The difference between super users and normal users is that the super users :set their DISPLAY environmental variable, while the normal users do not. Also :the super users and normal users have different privillege over the :configuration file ssh_config. DISPLAY must be set, or ssh does not know where to plug forwarded X11 connections to. I don't understand your permissions issue, but the global ssh_config is intended to be read other. From Maria.Wiese at McKesson.com Thu May 9 04:07:52 2002 From: Maria.Wiese at McKesson.com (Wiese, Maria) Date: Wed, 8 May 2002 11:07:52 -0700 Subject: Help with OpenSSL config for Sol7 SUN4U Message-ID: <23ED36D4661BD51199E000D0B782508D014C8210@ddce0051.mckesson.com> I need some help with .Configure for OpenSSL. I compiled versions for all Solaris (2.5, 2.6, 2.8) platforms, but I am having problems with the SUN sparc Ultra-60 (220-r) running Solaris 7 SUN4U configuration. I am trying to configure OpenSSL 0.9.6.C and have GCC version 2.95.3 for Solaris 7. When executing ./config , I received the following errors: Operating system: sun4u-whatever-solaris2 Can't locate strict.pm in @INC at ./Configure line 9. BEGIN failed--compilation aborted at ./Configure line 9. Can't locate strict.pm in @INC at ./Configure line 9. BEGIN failed--compilation aborted at ./Configure line 9. This system (solaris-sparcv9-gcc) is not supported. See file INSTALL for details I also try : ./Configure solaris-sparcv7-gcc ./Configure solaris-sparcv9-gcc27. Anything else I can try ?.... I did not have a problem in any of the other server releases or architecture. . Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. From kevin at atomicgears.com Thu May 9 04:49:10 2002 From: kevin at atomicgears.com (Kevin Steves) Date: Wed, 8 May 2002 11:49:10 -0700 (PDT) Subject: X11 forwarding and LBX In-Reply-To: <3CD88ABB.B74E68D2@zip.com.au> Message-ID: On Wed, 8 May 2002, Darren Tucker wrote: :The script I used to sort out xauth stuff is attached. The caveats are: :you need to source it (ie ". ./lbx") and various versions of LBX behave :differently so you may need to adjust it to local conditions. I also :found that some versions of LBX running on Solaris wouldn't bind() :unless they ran as root, although I never figured out why. You can probably also do the X authorization adds in .ssh/rc. You may also want to consider X11UseLocalhost=yes, where "xauth list $DISPLAY" does not match a cookie. We have this now in ssh.1: if read proto cookie && [ -n "$DISPLAY" ]; then if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then # X11UseLocalhost=yes xauth add unix:`echo $DISPLAY | cut -c11-` $proto $cookie else # X11UseLocalhost=no xauth add $DISPLAY $proto $cookie fi fi From maxwell at cs.dal.ca Thu May 9 06:09:35 2002 From: maxwell at cs.dal.ca (Chris Maxwell) Date: Wed, 8 May 2002 17:09:35 -0300 Subject: Maybe problem in openbsd-compat/bsd-arc4random.c Message-ID: <20020508170935.A20463@cs.dal.ca> I believe there is a problem with the openbsd-compat/bsd-arc4random.c file. If arc4random () is called without seed_rng having previously been called (eg if you run ssh-keygen -p ) then it does not in fact invoke seed_rng () if it is the first time. Instead it will invoke seed_rng every time BUT the first time. At least that is the way I read the code, and changing it as below allowed me to change my passphrase. :-) Thank you very much for all your wonderful work, -- Chris Maxwell Unix SysAdmin, Faculty of Computer Science, Dalhousie University, Halifax, Nova Scotia, Canada (902) 494-1369 / chris.maxwell at dal.ca / FAX: (902) 492-1517 *** openbsd-compat/bsd-arc4random.c.old Sun Mar 18 19:00:53 2001 --- bsd-arc4random.c Wed May 8 16:44:22 2002 *************** *** 48,54 **** static int first_time = 1; if (rc4_ready <= 0) { ! if (!first_time) seed_rng(); first_time = 0; arc4random_stir(); --- 48,54 ---- static int first_time = 1; if (rc4_ready <= 0) { ! if (first_time) seed_rng(); first_time = 0; arc4random_stir(); From brugolsky at telemetry-investments.com Thu May 9 06:41:19 2002 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Wed, 8 May 2002 16:41:19 -0400 Subject: [PATCH] Strip trailing . when using HostbasedUsesNameFromPacketOnly Message-ID: <20020508164119.B13045@ti20> The following simple patch (against openssh-3.1) moves the test for a trailing dot in the client-supplied hostname so that it is also stripped when using the server option HostbasedUsesNameFromPacketOnly. Please CC me on any replies, as I'm not subscribed to the list. Cheers, Bill Rugolsky --- ssh/auth2.c~ Sun Feb 24 14:14:59 2002 +++ ssh/auth2.c Wed May 8 16:26:26 2002 @@ -709,15 +709,15 @@ debug2("userauth_hostbased: chost %s resolvedname %s ipaddr %s", chost, resolvedname, ipaddr); + if (((len = strlen(chost)) > 0) && chost[len - 1] == '.') { + debug2("stripping trailing dot from chost %s", chost); + chost[len - 1] = '\0'; + } if (options.hostbased_uses_name_from_packet_only) { if (auth_rhosts2(pw, cuser, chost, chost) == 0) return 0; lookup = chost; } else { - if (((len = strlen(chost)) > 0) && chost[len - 1] == '.') { - debug2("stripping trailing dot from chost %s", chost); - chost[len - 1] = '\0'; - } if (strcasecmp(resolvedname, chost) != 0) log("userauth_hostbased mismatch: " "client sends %s, but we resolve %s to %s", From tim at multitalents.net Thu May 9 08:59:45 2002 From: tim at multitalents.net (Tim Rice) Date: Wed, 8 May 2002 15:59:45 -0700 (PDT) Subject: Maybe problem in openbsd-compat/bsd-arc4random.c In-Reply-To: <20020508170935.A20463@cs.dal.ca> Message-ID: On Wed, 8 May 2002, Chris Maxwell wrote: I've commited the change to CVS. Thanks. > > I believe there is a problem with the openbsd-compat/bsd-arc4random.c > file. If arc4random () is called without seed_rng having previously > been called (eg if you run ssh-keygen -p ) then it does not in > fact invoke seed_rng () if it is the first time. Instead it > will invoke seed_rng every time BUT the first time. At least > that is the way I read the code, and changing it as below allowed > me to change my passphrase. :-) > > Thank you very much for all your wonderful work, > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From fcusack at fcusack.com Thu May 9 13:13:29 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Wed, 8 May 2002 20:13:29 -0700 Subject: cryptocard RB-1 In-Reply-To: ; from bordewijk@fox-it.com on Mon, May 06, 2002 at 02:17:14PM +0200 References: Message-ID: <20020508201329.Y14036@google.com> On Mon, May 06, 2002 at 02:17:14PM +0200, Lourens Bordewijk wrote: > it's data from a file I've heard that some users made a conversion script > from the CryptoADMIN server export to a crypto users file that the patch I've never heard of this but I am also very interested in such a script. /fc From bugzilla-daemon at mindrot.org Thu May 9 13:38:34 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 9 May 2002 13:38:34 +1000 (EST) Subject: [Bug 117] OpenSSH second-guesses PAM Message-ID: <20020509033834.0D58EE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=117 ------- Additional Comments From fcusack at fcusack.com 2002-05-09 13:38 ------- Forwarding a fake username also means there is an undocumented username that has side effects caused by sshd; although all caps probably makes this a non-concern, to me it still smacks of special names like COM. This will be my last comment on the matter: - You are not doing anything by using 'NOUSER', at least nothing I can figure out. If this is to prevent some kind of attack, please add comments in the code. - You *are* causing problems. eg, my sshd w/ PAM uses a RADIUS backend. On my RADIUS server I get logs for 'NOUSER' failing. I would like to know what the attempted username was, and I would like to get this from a central source (the RADIUS server). I will admit, on the level of "problems" this is minor if 'NOUSER' actually prevents some attack. - The protocol 1 code path does not call PAM at all for invalid users. This would be acceptable for the protocol 2 code path, and better than using 'NOUSER', but eliminate the possibility of non-login services. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Thu May 9 14:35:22 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 09 May 2002 14:35:22 +1000 Subject: make distprep broken? Message-ID: <3CD9FC8A.C0CF5C91@zip.com.au> Hello All, Doing a make distprep doesn't seem to work anymore: $ make -f Makefile.in distprep make: @SH@: Command not found make: *** [catman-do] Error 127 I've seen this on AIX & Redhat (gnu make) and Solaris (native make). I suspect this occurs on most platforms. Is this still the recommended way of autoreconf'ing CVS releases for building? -Daz. From djm at mindrot.org Thu May 9 15:29:52 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 9 May 2002 15:29:52 +1000 (EST) Subject: make distprep broken? In-Reply-To: <3CD9FC8A.C0CF5C91@zip.com.au> Message-ID: On Thu, 9 May 2002, Darren Tucker wrote: > Hello All, > > Doing a make distprep doesn't seem to work anymore: > > $ make -f Makefile.in distprep > make: @SH@: Command not found > make: *** [catman-do] Error 127 > > I've seen this on AIX & Redhat (gnu make) and Solaris (native make). I > suspect this occurs on most platforms. Is this still the recommended way > of autoreconf'ing CVS releases for building? hmmm, that is broken. Tim - you committed that change, is there anyway to default to /bin/sh if @SH@ isn't substituted? In the meantime, you can do "make -f Makefile.in distprep SHELL=/bin/sh" -d From rhowland at nucleum.com Thu May 9 15:54:09 2002 From: rhowland at nucleum.com (Royce Howland) Date: Wed, 08 May 2002 23:54:09 -0600 Subject: Bug report: OpenSSH 3.1p1 Message-ID: <3CDA0F01.6B44639F@nucleum.com> I believe auth-rhosts.c, function check_rhosts_file(), contains a bug that shows up when doing host-based authentication where the client_user name is not the same as the server_user name. Line 76 reads: strlcpy(userbuf, server_user, sizeof(userbuf)); I believe it should read: strlcpy(userbuf, client_user, sizeof(userbuf)); Otherwise later in the function this test will fail: /* Verify that user name matches. */ if (user[0] == '@') { if (!innetgr(user + 1, NULL, client_user, NULL)) continue; } else if (strcmp(user, client_user) != 0) continue; /* Different username. */ Please reply directly if necessary; I'm not subscribed to this list. Royce Howland From dtucker at zip.com.au Thu May 9 16:47:08 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 09 May 2002 16:47:08 +1000 Subject: make distprep broken? References: Message-ID: <3CDA1B6C.3F5AB5AF@zip.com.au> Damien Miller wrote: > On Thu, 9 May 2002, Darren Tucker wrote: [make -f Makefile.in distprep broken] > hmmm, that is broken. Tim - you committed that change, is there anyway to > default to /bin/sh if @SH@ isn't substituted? I've since discovered that the make distprep works on OpenBSD with native make. > In the meantime, you can do "make -f Makefile.in distprep SHELL=/bin/sh" Thanks for the suggestion but I'll leave it as it is for now. I have a cron job that does a cvs update and attempts to build an AIX package twice a day. It'll just complain to me every twelve hours until it's fixed :-). -Daz. From VikashB at ComparexAfrica.co.za Thu May 9 20:45:15 2002 From: VikashB at ComparexAfrica.co.za (Vikash Badal / PCS) Date: Thu, 9 May 2002 12:45:15 +0200 Subject: functions : server_input_channel_req userauth_pubkey Message-ID: <501BF453CDCFD111A6E40080C83DAC04E4BD8F@PSICS001> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, I am not sure if this is the correct place to ask these question, if I am at the wrong place please advise. I am currently working on some modifications to openssh which record the users rsa/dsa identity comment file to a log file when the user logs in (password authentication is disabled). The ssh1 portion of the modification works perfectly but the ssh2 portion has me completely lost. in userauth_pubkey() [ in auth2.c ] i defined a variable realname (char 40). which gets set after user_key_allowed2 is processed. i want to pass this variable to server_input_channel_req but i can not find where these two functions are being called from. vix at osr5: openssh-3.1p1 > grep -l "userauth_pubkey" *.c auth2.c sshconnect2.c vix at osr5: openssh-3.1p1 > grep -l server_input_channel_req *.c serverloop.c I can not determine where these two functions are called from. please advise the diffs are attached . I am not much of a programmer, I ported these mod from some-one elses mods (ssh1-1.2.17). there probabably are a lot of ugliness to them and if you could point out any idiotic things that i have done, i will greatly appreciate it. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ diff -ru openssh-3.1p1/auth-rsa.c openssh-3.1p1-mods/auth-rsa.c - --- openssh-3.1p1/auth-rsa.c Thu May 9 12:18:25 2002 +++ openssh-3.1p1-mods/auth-rsa.c Thu May 9 12:19:54 2002 @@ -123,8 +123,11 @@ * successful. This may exit if there is a serious protocol violation. */ int - -auth_rsa(struct passwd *pw, BIGNUM *client_n) +auth_rsa(struct passwd *pw, BIGNUM *client_n, char *realname, int realnamesize) { char line[8192], *file; int authenticated; @@ -134,6 +137,8 @@ struct stat st; Key *key; char *fp; + char *comment; + int commentlen; /* no user given */ if (pw == NULL) @@ -219,6 +224,11 @@ continue; } /* cp now points to the comment part. */ + /* NaTIS */ + comment = cp; + commentlen = strlen(comment); + if (commentlen > 0 && comment[commentlen -1] == '\n') + comment[commentlen - 1] = '\0'; /* Check if the we have found the desired key (identified by its modulus). */ if (BN_cmp(key->rsa->n, client_n) != 0) @@ -231,6 +241,8 @@ file, linenum, BN_num_bits(key->rsa->n), bits); /* We have found the desired key. */ + debug("Found desired key for %s", comment); /* NaTIS */ + /* * If our options do not allow this key to be used, * do not send challenge. @@ -241,7 +253,10 @@ /* Perform the challenge-response dialog for this key. */ if (!auth_rsa_challenge_dialog(key->rsa)) { /* Wrong response. */ - - verbose("Wrong response to RSA authentication challenge. "); + /* + * added identity (comment) + */ + verbose("Wrong response to RSA authentication challenge for %s.", comment); packet_send_debug("Wrong response to RSA authentication challenge."); /* * Break out of the loop. Otherwise we might send @@ -264,6 +279,12 @@ key_type(key), fp); xfree(fp); + strncpy(realname, comment, commentlen - 1); break; } @@ -276,8 +297,14 @@ key_free(key); - - if (authenticated) - - packet_send_debug("RSA authentication accepted."); + if (authenticated) { + /* + * Assume that the comment field contains the real name of the + * person who owns the key. + */ + packet_send_debug("RSA authentication of %s as user %s accepted.", + comment, pw->pw_name); + } else auth_clear_options(); diff -ru openssh-3.1p1/auth.h openssh-3.1p1-mods/auth.h - --- openssh-3.1p1/auth.h Thu May 9 12:18:26 2002 +++ openssh-3.1p1-mods/auth.h Thu May 9 12:19:54 2002 @@ -94,7 +94,7 @@ int auth_rhosts_rsa(struct passwd *, const char *, Key *); int auth_password(Authctxt *, const char *); - -int auth_rsa(struct passwd *, BIGNUM *); +int auth_rsa(struct passwd *, BIGNUM *, char *realname, int realnamesize); int auth_rsa_challenge_dialog(RSA *); #ifdef KRB4 diff -ru openssh-3.1p1/auth1.c openssh-3.1p1-mods/auth1.c - --- openssh-3.1p1/auth1.c Thu May 9 12:18:26 2002 +++ openssh-3.1p1-mods/auth1.c Thu May 9 12:19:54 2002 @@ -63,7 +63,7 @@ * return only if authentication is successful */ static void - -do_authloop(Authctxt *authctxt) +do_authloop(Authctxt *authctxt, const char *realname) { int authenticated = 0; u_int bits; @@ -229,7 +229,7 @@ fatal("do_authloop: BN_new failed"); packet_get_bignum(n); packet_check_eom(); - - authenticated = auth_rsa(pw, n); + authenticated = auth_rsa(pw, n, realname, sizeof(realname)); BN_clear_free(n); break; @@ -363,6 +363,12 @@ u_int ulen; char *p, *user, *style = NULL; + /* Added the following so that the real ID of the owner of the + * public key used for successful authentication, can be returned by + * auth_rsa. + */ + char realname[40] = "unknown"; + /* Get the name of the user that we wish to log in as. */ packet_read_expect(SSH_CMSG_USER); @@ -411,7 +417,7 @@ * Loop until the user has been authenticated or the connection is * closed, do_authloop() returns only if authentication is successful */ - - do_authloop(authctxt); + do_authloop(authctxt, realname); /* The user has been authenticated and accepted. */ packet_start(SSH_SMSG_SUCCESS); @@ -419,5 +425,5 @@ packet_write_wait(); /* Perform session preparation. */ - - do_authenticated(authctxt); + do_authenticated(authctxt, realname); } diff -ru openssh-3.1p1/auth2.c openssh-3.1p1-mods/auth2.c - --- openssh-3.1p1/auth2.c Thu May 9 12:18:26 2002 +++ openssh-3.1p1-mods/auth2.c Thu May 9 12:19:55 2002 @@ -75,7 +75,7 @@ /* helper */ static Authmethod *authmethod_lookup(const char *); static char *authmethods_get(void); - -static int user_key_allowed(struct passwd *, Key *); +static int user_key_allowed(struct passwd *, Key *, char *realname); static int hostbased_key_allowed(struct passwd *, const char *, char *, Key *); /* auth */ @@ -105,6 +105,28 @@ {NULL, NULL, NULL} }; +/* VIX + * this piece is my attempt to pass the value of realname from userauth_pubkey + * to server_input_channel_req but i have no idea what is really happening + * the value gets passed in from userauthkey but gets destroyed by + * server_input_channel_req wtf ??? + */ +char sshid(char *realname, int oopt, char temprealname[40]) +{ + int lengrn; + + debug("realname passed in %s var is %d ", realname, oopt); + if (oopt == 1) { + /* write value to realname */ + debug("writing temp value for realname"); + lengrn = strlen(realname); + strncpy(temprealname, realname, lengrn ); + debug(" VIX tempvar is %s", temprealname); + } else { + /* rewrite realname from temprealname */ + debug("reading temp value for realname"); + lengrn = strlen(temprealname); + strncpy(realname,&temprealname,lengrn); + } + debug(" VIX realname passed out is %s", realname); + debug(" VIX tempvar passed out %s", temprealname); +} + /* * loop until authctxt->success == TRUE */ @@ -114,8 +136,11 @@ { Authctxt *authctxt = authctxt_new(); + char realname[40] = "unknown"; + x_authctxt = authctxt; /*XXX*/ + /* challenge-response is implemented via keyboard interactive */ if (options.challenge_response_authentication) options.kbd_interactive_authentication = 1; @@ -125,7 +150,7 @@ dispatch_init(&dispatch_protocol_error); dispatch_set(SSH2_MSG_SERVICE_REQUEST, &input_service_request); dispatch_run(DISPATCH_BLOCK, &authctxt->success, authctxt); - - do_authenticated(authctxt); + do_authenticated(authctxt, realname); } static void @@ -403,6 +428,13 @@ u_int alen, blen, slen; int have_sig, pktype; int authenticated = 0; + + char realname[40] = "UNKNOWN" ; + char tempreal[40] = "UNKNOWN" ; + + debug("**************************"); + debug("VIX userauth_pubkey called"); + debug("**************************"); if (!authctxt->valid) { debug2("userauth_pubkey: disabled because of invalid user"); @@ -467,7 +499,7 @@ buffer_dump(&b); #endif /* test for correct signature */ - - if (user_key_allowed(authctxt->pw, key) && + if (user_key_allowed(authctxt->pw, key, realname) && key_verify(key, sig, slen, buffer_ptr(&b), buffer_len(&b)) = = 1) authenticated = 1; buffer_clear(&b); @@ -484,7 +516,7 @@ * if a user is not allowed to login. is this an * issue? -markus */ - - if (user_key_allowed(authctxt->pw, key)) { + if (user_key_allowed(authctxt->pw, key, realname)) { packet_start(SSH2_MSG_USERAUTH_PK_OK); packet_put_string(pkalg, alen); packet_put_string(pkblob, blen); @@ -505,6 +537,10 @@ if (check_nt_auth(0, authctxt->pw) == 0) return(0); #endif + sshid(realname, 1, tempreal); + debug("**************************"); + debug("VIX userauth_pubkey done"); + debug("**************************"); return authenticated; } @@ -638,7 +674,7 @@ /* return 1 if user allows given key */ static int - -user_key_allowed2(struct passwd *pw, Key *key, char *file) +user_key_allowed2(struct passwd *pw, Key *key, char *file, char *realname) { char line[8192]; int found_key = 0; @@ -647,6 +683,8 @@ struct stat st; Key *found; char *fp; + char *comment; + int commentlen; if (pw == NULL) return 0; @@ -714,6 +752,12 @@ found_key = 1; debug("matching key found: file %s, line %lu", file, linenum); + + comment = cp; + commentlen = strlen(comment); + if (commentlen > 0 && comment[commentlen -1] == '\n') + comment[commentlen - 1] = '\0'; + fp = key_fingerprint(found, SSH_FP_MD5, SSH_FP_HEX); verbose("Found matching %s key: %s", key_type(found), fp); @@ -721,6 +765,9 @@ break; } } + + strncpy(realname, comment, commentlen); + restore_uid(); fclose(f); key_free(found); @@ -731,20 +778,19 @@ /* check whether given key is in .ssh/authorized_keys* */ static int - -user_key_allowed(struct passwd *pw, Key *key) +user_key_allowed(struct passwd *pw, Key *key, char *realname) { int success; char *file; file = authorized_keys_file(pw); - - success = user_key_allowed2(pw, key, file); + success = user_key_allowed2(pw, key, file, realname); xfree(file); if (success) return success; - - /* try suffix "2" for backward compat, too */ file = authorized_keys_file2(pw); - - success = user_key_allowed2(pw, key, file); + success = user_key_allowed2(pw, key, file, realname); xfree(file); return success; } diff -ru openssh-3.1p1/serverloop.c openssh-3.1p1-mods/serverloop.c - --- openssh-3.1p1/serverloop.c Thu May 9 12:18:34 2002 +++ openssh-3.1p1-mods/serverloop.c Thu May 9 12:20:03 2002 @@ -734,12 +734,13 @@ } void - -server_loop2(Authctxt *authctxt) +server_loop2(Authctxt *authctxt, const char *realname) { fd_set *readset = NULL, *writeset = NULL; int rekeying = 0, max_fd, nalloc = 0; debug("Entering interactive session for SSH2."); + debug("VIX realname is %s ", realname); mysignal(SIGCHLD, sigchld_handler); child_terminated = 0; @@ -996,10 +997,20 @@ } static void server_input_channel_req(int type, u_int32_t seq, void *ctxt) +/* + * VIX expected to get realname from calling funtion + * but i can't find the calling function !!!!!! +server_input_channel_req(int type, u_int32_t seq, void *ctxt, const char *realn ame) +*/ { Channel *c; int id, reply, success = 0; char *rtype; + char realname[40] = "UNDEFINED"; + char tempreal[40] = "UNDEFINED"; + + debug("*******************************"); + debug("server_input_channel_req called"); + debug("*******************************"); id = packet_get_int(); rtype = packet_get_string(NULL); @@ -1012,7 +1023,7 @@ packet_disconnect("server_input_channel_req: " "unknown channel %d", id); if (c->type == SSH_CHANNEL_LARVAL || c->type == SSH_CHANNEL_OPEN) - - success = session_input_channel_req(c, rtype); + success = session_input_channel_req(c, rtype, realname); if (reply) { packet_start(success ? SSH2_MSG_CHANNEL_SUCCESS : SSH2_MSG_CHANNEL_FAILURE); @@ -1020,6 +1031,10 @@ packet_send(); } xfree(rtype); + sshid(realname, 0, tempreal); + debug("*****************************"); + debug("server_input_channel_req done"); + debug("*****************************"); } static void diff -ru openssh-3.1p1/serverloop.h openssh-3.1p1-mods/serverloop.h - --- openssh-3.1p1/serverloop.h Thu May 9 12:18:34 2002 +++ openssh-3.1p1-mods/serverloop.h Thu May 9 12:20:03 2002 @@ -22,6 +22,6 @@ #define SERVERLOOP_H void server_loop(pid_t, int, int, int); - -void server_loop2(Authctxt *); +void server_loop2(Authctxt *, const char *realname); #endif diff -ru openssh-3.1p1/session.c openssh-3.1p1-mods/session.c - --- openssh-3.1p1/session.c Thu May 9 12:18:34 2002 +++ openssh-3.1p1-mods/session.c Thu May 9 12:20:03 2002 @@ -98,10 +98,10 @@ static void session_pty_cleanup(void *); void session_proctitle(Session *); int session_setup_x11fwd(Session *); - -void do_exec_pty(Session *, const char *); +void do_exec_pty(Session *, const char *, const char *realname); void do_exec_no_pty(Session *, const char *); - -void do_exec(Session *, const char *); - -void do_login(Session *, const char *); +void do_exec(Session *, const char *, const char *realname); +void do_login(Session *, const char *, const char *realname); #ifdef LOGIN_NEEDS_UTMPX static void do_pre_login(Session *s); #endif @@ -109,8 +109,8 @@ void do_motd(void); int check_quietlogin(Session *, const char *); - -static void do_authenticated1(Authctxt *); - -static void do_authenticated2(Authctxt *); +static void do_authenticated1(Authctxt *, const char *realname); +static void do_authenticated2(Authctxt *, const char *realname); static void session_close(Session *); static int session_pty_req(Session *); @@ -140,7 +140,7 @@ #endif void - -do_authenticated(Authctxt *authctxt) +do_authenticated(Authctxt *authctxt, const char *realname) { /* * Cancel the alarm we set to limit the time taken for @@ -176,9 +176,9 @@ channel_permit_all_opens(); if (compat20) - - do_authenticated2(authctxt); + do_authenticated2(authctxt, realname); else - - do_authenticated1(authctxt); + do_authenticated1(authctxt, realname); /* remove agent socket */ if (auth_get_socket_name()) @@ -200,7 +200,7 @@ * are requested, etc. */ static void - -do_authenticated1(Authctxt *authctxt) +do_authenticated1(Authctxt *authctxt, const char *realname) { Session *s; char *command; @@ -352,10 +352,10 @@ if (type == SSH_CMSG_EXEC_CMD) { command = packet_get_string(&dlen); debug("Exec command '%.500s'", command); - - do_exec(s, command); + do_exec(s, command, realname); xfree(command); } else { - - do_exec(s, NULL); + do_exec(s, NULL, realname); } packet_check_eom(); session_close(s); @@ -517,7 +517,7 @@ * lastlog, and other such operations. */ void - -do_exec_pty(Session *s, const char *command) +do_exec_pty(Session *s, const char *command, const char *realname) { int fdout, ptyfd, ttyfd, ptymaster; pid_t pid; @@ -557,7 +557,7 @@ /* record login, etc. similar to login(1) */ #ifndef HAVE_OSF_SIA if (!(options.use_login && command == NULL)) - - do_login(s, command); + do_login(s, command, realname); # ifdef LOGIN_NEEDS_UTMPX else do_pre_login(s); @@ -637,7 +637,7 @@ * to be forced, execute that instead. */ void - -do_exec(Session *s, const char *command) +do_exec(Session *s, const char *command, const char *realname) { if (forced_command) { original_command = command; @@ -646,7 +646,7 @@ } if (s->ttyfd != -1) - - do_exec_pty(s, command); + do_exec_pty(s, command, realname); else do_exec_no_pty(s, command); @@ -656,7 +656,7 @@ /* administrative, login(1)-like work */ void - -do_login(Session *s, const char *command) +do_login(Session *s, const char *command, const char *realname) { char *time_string; char hostname[MAXHOSTNAMELEN]; @@ -690,7 +690,7 @@ /* Record that there was a login on that tty from the remote host. */ record_login(pid, s->tty, pw->pw_name, pw->pw_uid, get_remote_name_or_ip(utmp_len, options.verify_reverse_mapping), - - (struct sockaddr *)&from); + (struct sockaddr *)&from, realname); #ifdef USE_PAM /* @@ -1509,7 +1509,7 @@ } static int - -session_subsystem_req(Session *s) +session_subsystem_req(Session *s, const char *realname) { struct stat st; u_int len; @@ -1530,7 +1530,7 @@ } debug("subsystem: exec() %s", cmd); s->is_subsystem = 1; - - do_exec(s, cmd); + do_exec(s, cmd, realname); success = 1; break; } @@ -1566,20 +1566,22 @@ } static int - -session_shell_req(Session *s) +session_shell_req(Session *s, const char *realname) { + char test1111[40] = "Unknown" ; + packet_check_eom(); - - do_exec(s, NULL); + do_exec(s, NULL, realname); return 1; } static int - -session_exec_req(Session *s) +session_exec_req(Session *s, const char *realname) { u_int len; char *command = packet_get_string(&len); packet_check_eom(); - - do_exec(s, command); + do_exec(s, command, realname); xfree(command); return 1; } @@ -1602,7 +1604,7 @@ } int - -session_input_channel_req(Channel *c, const char *rtype) +session_input_channel_req(Channel *c, const char *rtype, const char *realname) { int success = 0; Session *s; @@ -1620,9 +1622,9 @@ */ if (c->type == SSH_CHANNEL_LARVAL) { if (strcmp(rtype, "shell") == 0) { - - success = session_shell_req(s); + success = session_shell_req(s, realname); } else if (strcmp(rtype, "exec") == 0) { - - success = session_exec_req(s); + success = session_exec_req(s, realname); } else if (strcmp(rtype, "pty-req") == 0) { success = session_pty_req(s); } else if (strcmp(rtype, "x11-req") == 0) { @@ -1630,7 +1632,7 @@ } else if (strcmp(rtype, "auth-agent-req at openssh.com") == 0) { success = session_auth_agent_req(s); } else if (strcmp(rtype, "subsystem") == 0) { - - success = session_subsystem_req(s); + success = session_subsystem_req(s, realname); } } if (strcmp(rtype, "window-change") == 0) { @@ -1679,6 +1681,18 @@ if (s->pid != 0) record_logout(s->pid, s->tty, s->pw->pw_name); + /* Remove the file which contains login info. */ + { + char filename[80]; + char *cp; + + cp = strrchr(s->tty, '/'); + if (cp != NULL) { + sprintf(filename, "/usr/adm/sshd/%s", cp); + unlink(filename); + } + } + /* Release the pseudo-tty. */ pty_release(s->tty); @@ -1921,7 +1935,7 @@ } static void - -do_authenticated2(Authctxt *authctxt) +do_authenticated2(Authctxt *authctxt, const char *realname) { - - server_loop2(authctxt); + server_loop2(authctxt, realname); } diff -ru openssh-3.1p1/session.h openssh-3.1p1-mods/session.h - --- openssh-3.1p1/session.h Thu May 9 12:18:34 2002 +++ openssh-3.1p1-mods/session.h Thu May 9 12:20:03 2002 @@ -26,10 +26,10 @@ #ifndef SESSION_H #define SESSION_H - -void do_authenticated(Authctxt *); +void do_authenticated(Authctxt *, const char *realname); int session_open(Authctxt*, int); - -int session_input_channel_req(Channel *, const char *); +int session_input_channel_req(Channel *, const char *, const char *realname ); void session_close_by_pid(pid_t, int); void session_close_by_channel(int, void *); void session_destroy_all(void); diff -ru openssh-3.1p1/sshd.c openssh-3.1p1-mods/sshd.c - --- openssh-3.1p1/sshd.c Thu May 9 12:18:37 2002 +++ openssh-3.1p1-mods/sshd.c Thu May 9 12:20:06 2002 @@ -1519,3 +1519,4 @@ #endif debug("KEX done"); } + diff -ru openssh-3.1p1/sshlogin.c openssh-3.1p1-mods/sshlogin.c - --- openssh-3.1p1/sshlogin.c Thu May 9 12:18:37 2002 +++ openssh-3.1p1-mods/sshlogin.c Thu May 9 12:20:07 2002 @@ -67,14 +67,64 @@ void record_login(pid_t pid, const char *ttyname, const char *user, uid_t uid, - - const char *host, struct sockaddr * addr) + const char *host, struct sockaddr * addr, const char *realname) { struct logininfo *li; + char filename[80], line[132]; + char *cp; + time_t Now; + struct tm *tp; + int fd; li = login_alloc_entry(pid, user, host, ttyname); login_set_addr(li, addr, sizeof(struct sockaddr)); login_login(li); login_free_entry(li); + + /* We will create a separate file in "/usr/adm/sshd" for each user + ** who logs in. The filename will be the same as the ttyname. The + ** file will contain only one line, showing: + ** username + ** ttyname + ** Date and time when login started + ** PID + ** hostname of client. + ** Real name of public key's owner + */ + cp = strrchr(ttyname, '/'); + if (cp != NULL) + { + cp++; + sprintf(filename, "/usr/adm/sshd/%s", cp); + if (strcmp(user, "") != 0) + { + /* We are recording a login, not a logout */ + fd = open(filename, O_WRONLY|O_CREAT, 0644); + chmod(filename, 0644); /* to make sure */ + if (fd >= 0) + { + char namebuffer[21]; + + time(&Now); + tp = localtime(&Now); + strncpy(namebuffer, realname, 20); + namebuffer[20] = '\0'; /* prevent overruning line buffer */ + sprintf(line, "%-12s %-8s %02d/%02d %02d:%02d:%02d %-5u %-12s %-20s\n", + user, cp, tp->tm_mon, tp->tm_mday, + tp->tm_hour, tp->tm_min, tp->tm_sec, + pid, host, namebuffer); + if (write(fd, line, strlen(line)) != strlen(line)) + verbose("Could not write to %s", filename); + close(fd); + } + else + verbose("Could not open %s: %s", filename, strerror(errno)); + } + else /* This is a logout, not a login */ + { + unlink(filename); + } + } } #ifdef LOGIN_NEEDS_UTMPX diff -ru openssh-3.1p1/sshlogin.h openssh-3.1p1-mods/sshlogin.h - --- openssh-3.1p1/sshlogin.h Thu May 9 12:18:37 2002 +++ openssh-3.1p1-mods/sshlogin.h Thu May 9 12:20:07 2002 @@ -16,7 +16,7 @@ void record_login(pid_t, const char *, const char *, uid_t, - - const char *, struct sockaddr *); + const char *, struct sockaddr *, const char *realname); void record_logout(pid_t, const char *, const char *); u_long get_last_login_time(uid_t, const char *, char *, u_int); Thanks Vikash -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1i for non-commercial use iQA/AwUBPNo3XhvA3JmlEONgEQLeDACg6WjQR6l77RQ5PpXt2S9G5Ta08QAAoPNy 2S4TWi5B3YXtr61j8g03sJHk =fJSw -----END PGP SIGNATURE----- From bugzilla-daemon at mindrot.org Thu May 9 22:58:44 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 9 May 2002 22:58:44 +1000 (EST) Subject: [Bug 194] still problems with libutil Message-ID: <20020509125844.A7298E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=194 dh at onclick.org changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P2 |P1 ------- Additional Comments From dh at onclick.org 2002-05-09 22:58 ------- This problem still appears with the newest cvs: openssh-SNAP-20020508.tar.gz I condifured the system using these options: ./configure --prefix=/usr --with-4in6 --with-md5-passwords --disable-libutil Though I chose to not use libutil, it appears in the list of dependencies (configure output): OpenSSH has been configured with the following options: User binaries: /usr/bin System binaries: /usr/sbin Configuration files: /usr/etc Askpass program: /usr/libexec/ssh-askpass Manual pages: /usr/man/catX PID file: /var/run sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin Manpage format: cat PAM support: no KerberosIV support: no KerberosV support: no Smartcard support: no AFS support: no S/KEY support: no TCP Wrappers support: no MD5 password support: yes IP address in $DISPLAY hack: no Use IPv4 by default hack: no Translate v4 in v6 hack: yes BSD Auth support: no Random number source: OpenSSL internal ONLY Host: i686-pc-linux-gnu Compiler: gcc Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized Preprocessor flags: Linker flags: Libraries: -lutil -lz -lnsl -lcrypto -lcrypt ere is the error message: /bin/ld -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o -L. -Lopenbsd-compat/ -lssh -lopenbsd-compat -lutil -lz -lnsl -lcrypto -lcrypt /bin/ld: warning: cannot find entry symbol _start; defaulting to 0804b208 /usr/lib/libutil.so: undefined reference to `atexit' make: *** [ssh] Fehler 1 Please, I am without OpenSSH for over a year now! I have to keep an old system on a separate partition to log into my sourceforge account. I really need support. thanks ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu May 9 23:55:07 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 9 May 2002 23:55:07 +1000 (EST) Subject: [Bug 238] New: sshd.pid file written AFTER key generation causes race condition Message-ID: <20020509135507.39B51E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=238 Summary: sshd.pid file written AFTER key generation causes race condition Product: Portable OpenSSH Version: 3.1p1 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: libove at felines.org The SSH Daemon writes its sshd.pid file only after it generates its ephemeral server key. This makes the amount of time between starting the daemon and the creation / update of the sshd.pid file variable, and can cause a race condition with e.g. /sbin/init.d scripts which start the daemon and then want to check to see that the start was successful. Please move the sshd.pid create/update to happen before the generation of the ephemeral server key, so that the new SSH Daemon pid is written to the sshd.pid file very shortly after the process starts executing. Thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tim at multitalents.net Fri May 10 00:11:32 2002 From: tim at multitalents.net (Tim Rice) Date: Thu, 9 May 2002 07:11:32 -0700 (PDT) Subject: make distprep broken? In-Reply-To: Message-ID: On Thu, 9 May 2002, Damien Miller wrote: > On Thu, 9 May 2002, Darren Tucker wrote: > > > Hello All, > > > > Doing a make distprep doesn't seem to work anymore: > > > > $ make -f Makefile.in distprep > > make: @SH@: Command not found > > make: *** [catman-do] Error 127 > > > > I've seen this on AIX & Redhat (gnu make) and Solaris (native make). I > > suspect this occurs on most platforms. Is this still the recommended way > > of autoreconf'ing CVS releases for building? > > hmmm, that is broken. Tim - you committed that change, is there anyway to > default to /bin/sh if @SH@ isn't substituted? I've commented out the SHELL = @SH@ line until I can figure out a better way. Sorry for the trouble. > > In the meantime, you can do "make -f Makefile.in distprep SHELL=/bin/sh" > > -d > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From ja2morri at student.math.uwaterloo.ca Fri May 10 01:42:04 2002 From: ja2morri at student.math.uwaterloo.ca (James A Morrison) Date: Thu, 9 May 2002 11:42:04 -0400 (EDT) Subject: [Bug 238] New: sshd.pid file written AFTER key generation causes race condition In-Reply-To: <20020509135507.39B51E881@shitei.mindrot.org> (bugzilla-daemon@mindrot.org) References: <20020509135507.39B51E881@shitei.mindrot.org> Message-ID: <200205091542.LAA09883@rees.math.uwaterloo.ca> The SSH Daemon writes its sshd.pid file only after it generates its ephemeral server key. This makes the amount of time between starting the daemon and the creation / update of the sshd.pid file variable, and can cause a race condition with e.g. /sbin/init.d scripts which start the daemon and then want to check to see that the start was successful. Please move the sshd.pid create/update to happen before the generation of the ephemeral server key, so that the new SSH Daemon pid is written to the sshd.pid file very shortly after the process starts executing. Thanks. Isn't this the proper behavior. If the server key isn't generated the daemon isn't actually started. James A. Morrison From tim at multitalents.net Fri May 10 05:45:50 2002 From: tim at multitalents.net (Tim Rice) Date: Thu, 9 May 2002 12:45:50 -0700 (PDT) Subject: make distprep broken? In-Reply-To: Message-ID: Anyone have a problem with this patch? It fixes stty problems on SCO with broken (most PC) clients. It only effects systems that use BSD-style ptys. Ie. running "egrep "PTY|DEV" config.h" produces /* #undef HAVE_DEV_PTMX */ /* #undef HAVE_DEV_PTS_AND_PTC */ /* #undef HAVE_OPENPTY */ /* #undef HAVE_PTY_H */ /* #undef HAVE__GETPTY */ ----------< cut >---------- --- sshpty.c.old Tue Jan 15 17:06:39 2002 +++ sshpty.c Thu May 9 12:19:06 2002 @@ -199,6 +199,7 @@ const char *ptyminors = "0123456789abcdef"; int num_minors = strlen(ptyminors); int num_ptys = strlen(ptymajors) * num_minors; + struct termios tio; for (i = 0; i < num_ptys; i++) { snprintf(buf, sizeof buf, "/dev/pty%c%c", ptymajors[i / num_minors], @@ -223,6 +224,19 @@ close(*ptyfd); return 0; } + /* set tty modes to a sane state for broken clients */ + if (tcgetattr(*ptyfd, &tio) < 0) + log("Getting tty modes for pty failed: %.100s", strerror(errno)); + else { + tio.c_lflag |= (ECHO | ISIG | ICANON); + tio.c_oflag |= (OPOST | ONLCR); + tio.c_iflag |= ICRNL; + + /* Set the new modes for the terminal. */ + if (tcsetattr(*ptyfd, TCSANOW, &tio) < 0) + log("Setting tty modes for pty failed: %.100s", strerror(errno)); + } + return 1; } return 0; ----------< end cut >---------- -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Fri May 10 05:47:51 2002 From: tim at multitalents.net (Tim Rice) Date: Thu, 9 May 2002 12:47:51 -0700 (PDT) Subject: patch to sshpty.c In-Reply-To: Message-ID: Sorry, forgot to fix the subject. On Thu, 9 May 2002, Tim Rice wrote: Anyone have a problem with this patch? It fixes stty problems on SCO with broken (most PC) clients. It only effects systems that use BSD-style ptys. Ie. running "egrep "PTY|DEV" config.h" produces /* #undef HAVE_DEV_PTMX */ /* #undef HAVE_DEV_PTS_AND_PTC */ /* #undef HAVE_OPENPTY */ /* #undef HAVE_PTY_H */ /* #undef HAVE__GETPTY */ ----------< cut >---------- --- sshpty.c.old Tue Jan 15 17:06:39 2002 +++ sshpty.c Thu May 9 12:19:06 2002 @@ -199,6 +199,7 @@ const char *ptyminors = "0123456789abcdef"; int num_minors = strlen(ptyminors); int num_ptys = strlen(ptymajors) * num_minors; + struct termios tio; for (i = 0; i < num_ptys; i++) { snprintf(buf, sizeof buf, "/dev/pty%c%c", ptymajors[i / num_minors], @@ -223,6 +224,19 @@ close(*ptyfd); return 0; } + /* set tty modes to a sane state for broken clients */ + if (tcgetattr(*ptyfd, &tio) < 0) + log("Getting tty modes for pty failed: %.100s", strerror(errno)); + else { + tio.c_lflag |= (ECHO | ISIG | ICANON); + tio.c_oflag |= (OPOST | ONLCR); + tio.c_iflag |= ICRNL; + + /* Set the new modes for the terminal. */ + if (tcsetattr(*ptyfd, TCSANOW, &tio) < 0) + log("Setting tty modes for pty failed: %.100s", strerror(errno)); + } + return 1; } return 0; ----------< end cut >---------- -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bugzilla-daemon at mindrot.org Fri May 10 06:10:24 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 10 May 2002 06:10:24 +1000 (EST) Subject: [Bug 2] sshd should have BSM auditing on Solaris Message-ID: <20020509201024.90C8DE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=2 ------- Additional Comments From Darren.Moffat at Sun.COM 2002-05-10 06:10 ------- Created an attachment (id=94) Current revision of Solaris BSM audit diffs - missing autoconf changes and it hasn't been tested (may not compile). Needs to link with -lbsm ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri May 10 06:21:16 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 10 May 2002 06:21:16 +1000 (EST) Subject: [Bug 239] New: ssh didn't resolv name server on HPUX 11i Message-ID: <20020509202116.535ACE8EA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=239 Summary: ssh didn't resolv name server on HPUX 11i Product: Portable OpenSSH Version: 3.0.1p1 Platform: HPPA OS/Version: HP-UX Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: pascalrouchon at yahoo.fr after applying December or March HP-UX 11i bundle patches ssh and scp are not able to resolve nameserver. ssh ssh: : host nor service provided, or not known ssh Working fine i can reproduct the problem on all my HP-UX servers. also on brand new installed: 1- installation of HP-Ux 2- Patch with HWenable 11i GoldApps 11i Goldbase 11i 3- compilation and installation of openssh. 4- ssh didn't resolve name i'm compiling openssh3.1.0p1 Thanks ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri May 10 06:36:54 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 10 May 2002 06:36:54 +1000 (EST) Subject: [Bug 239] ssh didn't resolv name server on HPUX 11i Message-ID: <20020509203654.6F950E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=239 ------- Additional Comments From stevesk at pobox.com 2002-05-10 06:36 ------- i have heard that newer releases have getaddrinfo() and that it does not function properly. is HAVE_GETADDRINFO defined? if so, can you raise the issue with HP support before we do something like add BROKEN_GETADDRINFO? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Darren.Moffat at Sun.COM Fri May 10 06:50:25 2002 From: Darren.Moffat at Sun.COM (Darren Moffat) Date: Thu, 9 May 2002 13:50:25 -0700 (PDT) Subject: OSSH_PATH_ENTROPY_PROG' unexpected Message-ID: <200205092051.g49Kp393507307@jurassic.eng.sun.com> I'm trying to configure and build the current bits from the CVS tree, I've used autoconf (GNU Autoconf) 2.52 to generated configure from the configure.ac file. When I run configure on Solaris 9 I get a failure thus: $ ./configure .... checking for OpenSSL directory... /usr/local/ssl checking for RSA support... yes checking whether OpenSSL's headers match the library... yes checking whether OpenSSL's PRNG is internally seeded... yes checking for PRNGD/EGD socket... not found ./configure: syntax error at line 7698: `OSSH_PATH_ENTROPY_PROG' unexpected I've tried with and without --with-rand-helper=no and I get the same failure. I've tried this using: cc: Sun WorkShop 6 update 1 C 5.2 2000/09/11 gcc version 2.95.3 20010315 (release) rep Full configure.out is attached. Any pointers to FAQs or other docs appreciated, I searched the list archives for rand-helper and OSS_PATH_ENTROY_PROG but found nothing that helps me solve my problem. Once I have this resolved I can start testing the Solaris BSM audit patches for OpenSSH. Thanks -- Darren J Moffat -------------- next part -------------- checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for executable suffix... checking for object suffix... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking build system type... sparc-sun-solaris2.9 checking host system type... sparc-sun-solaris2.9 checking whether byte ordering is bigendian... yes checking how to run the C preprocessor... gcc -E checking for ranlib... ranlib checking for a BSD compatible install... /opt/sfw/bin/ginstall -c checking for ar... /usr/ccs/bin/ar checking for perl5... /usr/dist/exe/perl5 checking for ent... no checking for filepriv... no checking for bash... /usr/bin/bash checking for ksh... (cached) /usr/bin/bash checking for sh... (cached) /usr/bin/bash checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... 64 checking for _LARGE_FILES value needed for large files... no checking for login... /usr/bin/login checking for gcc option to accept ANSI C... none needed checking for inline... inline checking for obsolete utmp and wtmp in solaris2.x... yes checking for bstring.h... no checking for crypt.h... yes checking for endian.h... no checking for floatingpoint.h... yes checking for getopt.h... no checking for glob.h... yes checking for lastlog.h... yes checking for limits.h... yes checking for login.h... no checking for login_cap.h... no checking for maillock.h... yes checking for netdb.h... yes checking for netgroup.h... no checking for netinet/in_systm.h... yes checking for paths.h... no checking for poll.h... yes checking for pty.h... no checking for rpc/types.h... yes checking for security/pam_appl.h... yes checking for shadow.h... yes checking for stddef.h... yes checking for stdint.h... no checking for strings.h... yes checking for sys/bitypes.h... no checking for sys/bsdtty.h... no checking for sys/cdefs.h... yes checking for sys/poll.h... yes checking for sys/queue.h... no checking for sys/select.h... yes checking for sys/stat.h... yes checking for sys/stropts.h... yes checking for sys/sysmacros.h... yes checking for sys/time.h... yes checking for sys/un.h... yes checking for time.h... yes checking for ttyent.h... no checking for usersec.h... no checking for util.h... no checking for utime.h... yes checking for utmp.h... yes checking for utmpx.h... yes checking for yp_match... no checking for yp_match in -lnsl... yes checking for setsockopt... no checking for setsockopt in -lsocket... yes checking for getspnam... yes checking for deflate in -lz... yes checking for strcasecmp... yes checking for utimes... yes checking for libutil.h... no checking for library containing login... no checking for logout... no checking for updwtmp... yes checking for logwtmp... no checking for strftime... yes checking for GLOB_ALTDIRFUNC support... no checking for gl_matchc field in glob_t... no checking whether struct dirent allocates space for d_name... no checking for libwrap... yes checking for arc4random... no checking for atexit... yes checking for b64_ntop... no checking for bcopy... yes checking for bindresvport_sa... no checking for clock... yes checking for fchmod... yes checking for fchown... yes checking for freeaddrinfo... yes checking for futimes... no checking for gai_strerror... yes checking for getaddrinfo... yes checking for getcwd... yes checking for getgrouplist... no checking for getnameinfo... yes checking for getopt... yes checking for getrlimit... yes checking for getrusage... yes checking for getttyent... no checking for glob... yes checking for inet_aton... no checking for inet_ntoa... yes checking for inet_ntop... yes checking for innetgr... yes checking for login_getcapbool... no checking for md5_crypt... no checking for memmove... yes checking for mkdtemp... no checking for on_exit... no checking for openpty... no checking for readpassphrase... no checking for realpath... yes checking for rresvport_af... yes checking for setdtablesize... no checking for setegid... yes checking for setenv... no checking for seteuid... yes checking for setlogin... no checking for setproctitle... no checking for setresgid... no checking for setreuid... yes checking for setrlimit... yes checking for setsid... yes checking for setvbuf... yes checking for sigaction... yes checking for sigvec... no checking for snprintf... yes checking for strerror... yes checking for strlcat... yes checking for strlcpy... yes checking for strmode... no checking for strsep... no checking for sysconf... yes checking for tcgetpgrp... yes checking for utimes... (cached) yes checking for vhangup... yes checking for vsnprintf... yes checking for waitpid... yes checking for __b64_ntop... no checking for _getpty... no checking for dirname... yes checking for libgen.h... yes checking for gettimeofday... yes checking for time... yes checking for endutent... yes checking for getutent... yes checking for getutid... yes checking for getutline... yes checking for pututline... yes checking for setutent... yes checking for utmpname... yes checking for endutxent... yes checking for getutxent... yes checking for getutxid... yes checking for getutxline... yes checking for pututxline... yes checking for setutxent... yes checking for utmpxname... yes checking for getuserattr... no checking for getuserattr in -ls... no checking for daemon... no checking for daemon in -lbsd... no checking for getpagesize... yes checking whether snprintf correctly terminates long strings... yes checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... (cached) yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... (cached) yes checking for inttypes.h... yes checking for stdint.h... (cached) no checking for unistd.h... yes checking whether getpgrp takes no argument... yes checking for dlopen in -ldl... yes checking for pam_set_item in -lpam... yes checking for pam_getenvlist... yes checking whether pam_strerror takes only one argument... no checking for OpenSSL directory... /usr/local/ssl checking for RSA support... yes checking whether OpenSSL's headers match the library... yes checking whether OpenSSL's PRNG is internally seeded... yes ./configure: syntax error at line 7566: `OSSH_PATH_ENTROPY_PROG' unexpected From gert at greenie.muc.de Fri May 10 06:53:39 2002 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 9 May 2002 22:53:39 +0200 Subject: patch to sshpty.c In-Reply-To: ; from tim@multitalents.net on Thu, May 09, 2002 at 12:47:51PM -0700 References:

Message-ID: <20020509225338.H16454@greenie.muc.de> Hi, On Thu, May 09, 2002 at 12:47:51PM -0700, Tim Rice wrote: > Anyone have a problem with this patch? Looks good to me (and explains why I needed "stty onlcr opost" when connecting with MindTerm to my SCO box). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From tim at multitalents.net Fri May 10 07:05:30 2002 From: tim at multitalents.net (Tim Rice) Date: Thu, 9 May 2002 14:05:30 -0700 (PDT) Subject: OSSH_PATH_ENTROPY_PROG' unexpected In-Reply-To: <200205092051.g49Kp393507307@jurassic.eng.sun.com> Message-ID: On Thu, 9 May 2002, Darren Moffat wrote: > I'm trying to configure and build the current bits from the CVS tree, > I've used autoconf (GNU Autoconf) 2.52 to generated configure from > the configure.ac file. > > When I run configure on Solaris 9 I get a failure thus: > $ ./configure > .... > checking for OpenSSL directory... /usr/local/ssl > checking for RSA support... yes > checking whether OpenSSL's headers match the library... yes > checking whether OpenSSL's PRNG is internally seeded... yes > checking for PRNGD/EGD socket... not found > ./configure: syntax error at line 7698: `OSSH_PATH_ENTROPY_PROG' unexpected configure didn't get built correctly. Did you run autoconf or autoreconf? (try autoreconf) -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From austin at coremetrics.com Fri May 10 07:23:18 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 09 May 2002 16:23:18 -0500 Subject: Feature request: Discussion. Message-ID: <1020979398.10028.62.camel@UberGeek> I was wondering if anyone would find the syntax: ssh://someuser at host#port or even as simple as ssh://somehost#port useful? -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "One ought never to turn one's back on a threatened danger and try to run away from it. If you do that, you will double the danger. But if you meet it promptly and without flinching, you will reduce the danger by half." Sir Winston Churchill -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020509/6a46d8f4/attachment.bin From ed at UDel.Edu Fri May 10 07:29:16 2002 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 9 May 2002 17:29:16 -0400 (EDT) Subject: OSSH_PATH_ENTROPY_PROG' unexpected In-Reply-To: <200205092051.g49Kp393507307@jurassic.eng.sun.com> Message-ID: Side note: From what I've heard, any "Sun Workshop 6" or "Sun Forte 6" less than "Update 2" is "broken"... and OpenSSL will not compile correctly with the "broken" versions. Your mileage may vary. ;-) Ed On Thu, 9 May 2002, Darren Moffat wrote: > Date: Thu, 9 May 2002 13:50:25 -0700 (PDT) > From: Darren Moffat > To: openssh-unix-dev at mindrot.org > Subject: OSSH_PATH_ENTROPY_PROG' unexpected > > I'm trying to configure and build the current bits from the CVS tree, > I've used autoconf (GNU Autoconf) 2.52 to generated configure from > the configure.ac file. > > When I run configure on Solaris 9 I get a failure thus: > $ ./configure > .... > checking for OpenSSL directory... /usr/local/ssl > checking for RSA support... yes > checking whether OpenSSL's headers match the library... yes > checking whether OpenSSL's PRNG is internally seeded... yes > checking for PRNGD/EGD socket... not found > ./configure: syntax error at line 7698: `OSSH_PATH_ENTROPY_PROG' unexpected > > I've tried with and without --with-rand-helper=no and I get the same > failure. > > I've tried this using: > cc: Sun WorkShop 6 update 1 C 5.2 2000/09/11 > gcc version 2.95.3 20010315 (release) rep > > Full configure.out is attached. > > Any pointers to FAQs or other docs appreciated, I searched the list > archives for rand-helper and OSS_PATH_ENTROY_PROG but found nothing that > helps me solve my problem. > > Once I have this resolved I can start testing the Solaris BSM audit > patches for OpenSSH. > > Thanks > > -- > Darren J Moffat > Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From mouring at etoh.eviladmin.org Fri May 10 07:28:38 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 9 May 2002 16:28:38 -0500 (CDT) Subject: Feature request: Discussion. In-Reply-To: <1020979398.10028.62.camel@UberGeek> Message-ID: Considering # is a shell comment character.. No.. And in reality if your using URL formating you really should be doing ssh://user at host:port which conflicts with scp, but without knowing what you are planning.. It may not make a difference. - Ben On 9 May 2002, Austin Gonyou wrote: > I was wondering if anyone would find the syntax: > ssh://someuser at host#port or even as simple as ssh://somehost#port > useful? > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin at coremetrics.com > > "One ought never to turn one's back on a threatened danger and > try to run away from it. If you do that, you will double the danger. > But if you meet it promptly and without flinching, you will > reduce the danger by half." > Sir Winston Churchill > From bugzilla-daemon at mindrot.org Fri May 10 09:11:20 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 10 May 2002 09:11:20 +1000 (EST) Subject: [Bug 2] sshd should have BSM auditing on Solaris Message-ID: <20020509231120.08725E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=2 ------- Additional Comments From Darren.Moffat at Sun.COM 2002-05-10 09:11 ------- Created an attachment (id=95) Solaris BSM audit patches against OpenSSH 3.1p1 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri May 10 09:12:28 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 10 May 2002 09:12:28 +1000 (EST) Subject: [Bug 2] sshd should have BSM auditing on Solaris Message-ID: <20020509231228.4C02FE904@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=2 ------- Additional Comments From Darren.Moffat at Sun.COM 2002-05-10 09:12 ------- I've added a new set of attachments for BSM audit diffs against 3.1p1, these build (as per below) and work on Solaris 9. The audit interfaces used by this code should allow it to work on all Solaris releases from 2.4 onwards, though I haven't built and tested on anything other than Solaris 9. Note that the required changes to autoconf are not included in this. Someone more familiar with autoconf is better qualified to add those, particularly if you want to have a --with-solarisbsm option. To use the patch as it stands just now: 1. bsmaudit.o needs to be added to SSHDOBJS 2. HAVE_BSM_AUDIT_H needs to be defined 3. sshd needs to be linked with -lbsm (which is in /usr/lib). The diffs also include a suggested update to the INSTALL file that mentions the need to update audit_event, the included changes to buildpkg.sh add a postinstall script that does the update. I'm more than happy for this to be reworded or moved somewhere more appropriate. Finally I would like to publicly say sorry to Theo personally and all of the OpenSSH developers and Solaris users for the delay in getting the patches posted. The delay was not caused by Sun Microsystems Inc but by procrastination on my part. A mail from Theo today reminded me I had dropped the ball on this and prompted me to complete the work to its current stage. The changes and new files maybe included in any revision of OpenSSH, they are under the following license which is included in bsmaudit.h and bsmaudit.c, this is what is refered to by the phrase "Use is subject to license terms" that appears beneath the copyright notice. * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri May 10 09:16:59 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 10 May 2002 09:16:59 +1000 (EST) Subject: [Bug 194] still problems with libutil Message-ID: <20020509231659.D07BFE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=194 ------- Additional Comments From djm at mindrot.org 2002-05-10 09:16 ------- Why is libutil a problem? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri May 10 09:19:46 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 10 May 2002 09:19:46 +1000 (EST) Subject: [Bug 239] ssh didn't resolv name server on HPUX 11i Message-ID: <20020509231946.8109CE902@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=239 ------- Additional Comments From djm at mindrot.org 2002-05-10 09:19 ------- Can you please try a CVS snapshot? http://www.openssh.com/portable.html ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From rac at tenzing.org Fri May 10 10:45:59 2002 From: rac at tenzing.org (Roger Cornelius) Date: Thu, 9 May 2002 20:45:59 -0400 Subject: patch to sshpty.c In-Reply-To: Message-ID: <200205100045.g4A0jxQ18468@tenzing.org> Tim, I posted this patch to the list on February 12th in response to a message from "Frank S. Bernhardt" (frank at bcsi.ca). Except for the fact that it's now against sshpty.c instead of session.c, one comment has been changed, and I had enclosed it within #ifdefs, the patch is the same. I'm happy the patch will benefit other ssh users (that's why I posted it), but it would be nice if I were at least credited. Roger Cornelius Tim Rice (tim at multitalents.net) wrote: > >Sorry, forgot to fix the subject. > >On Thu, 9 May 2002, Tim Rice wrote: > >Anyone have a problem with this patch? > >It fixes stty problems on SCO with broken (most PC) clients. >It only effects systems that use BSD-style ptys. >Ie. running "egrep "PTY|DEV" config.h" produces >/* #undef HAVE_DEV_PTMX */ >/* #undef HAVE_DEV_PTS_AND_PTC */ >/* #undef HAVE_OPENPTY */ >/* #undef HAVE_PTY_H */ >/* #undef HAVE__GETPTY */ > >----------< cut >---------- >--- sshpty.c.old Tue Jan 15 17:06:39 2002 >+++ sshpty.c Thu May 9 12:19:06 2002 >@@ -199,6 +199,7 @@ > const char *ptyminors = "0123456789abcdef"; > int num_minors = strlen(ptyminors); > int num_ptys = strlen(ptymajors) * num_minors; >+ struct termios tio; > > for (i = 0; i < num_ptys; i++) { > snprintf(buf, sizeof buf, "/dev/pty%c%c", ptymajors[i / num_minors], >@@ -223,6 +224,19 @@ > close(*ptyfd); > return 0; > } >+ /* set tty modes to a sane state for broken clients */ >+ if (tcgetattr(*ptyfd, &tio) < 0) >+ log("Getting tty modes for pty failed: %.100s", strerror(errno)); >+ else { >+ tio.c_lflag |= (ECHO | ISIG | ICANON); >+ tio.c_oflag |= (OPOST | ONLCR); >+ tio.c_iflag |= ICRNL; >+ >+ /* Set the new modes for the terminal. */ >+ if (tcsetattr(*ptyfd, TCSANOW, &tio) < 0) >+ log("Setting tty modes for pty failed: %.100s", strerror(errno)); >+ } >+ > return 1; > } > return 0; >----------< end cut >---------- > >-- >Tim Rice Multitalents (707) 887-1469 >tim at multitalents.net > >_______________________________________________ >openssh-unix-dev at mindrot.org mailing list >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Roger Cornelius rac at tenzing.org From tim at multitalents.net Fri May 10 10:50:59 2002 From: tim at multitalents.net (Tim Rice) Date: Thu, 9 May 2002 17:50:59 -0700 (PDT) Subject: patch to sshpty.c In-Reply-To: <200205100045.g4A0jxQ18468@tenzing.org> Message-ID: On Thu, 9 May 2002, Roger Cornelius wrote: > Tim, > > I posted this patch to the list on February 12th in response to a > message from "Frank S. Bernhardt" (frank at bcsi.ca). Except for the fact > that it's now against sshpty.c instead of session.c, one comment has > been changed, and I had enclosed it within #ifdefs, the patch is the > same. I'm happy the patch will benefit other ssh users (that's why I > posted it), but it would be nice if I were at least credited. > > Roger Cornelius > It is indeed based directly on your patch and I was going to give you credit when it's commited. :-) Didn't mean to apear to be taking credit for this one. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mouring at etoh.eviladmin.org Fri May 10 11:58:55 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 9 May 2002 20:58:55 -0500 (CDT) Subject: patch to sshpty.c In-Reply-To: Message-ID: Is this patch required for all platforms or just SCO? If it is just for SCO then why is not stated as such.. If it is more a universal issue then do you plan on submitting it back to Markus when we open up the main tree? I'd like to see us move some of the more 'Must have for X platform' out into openbsd-contrib/port-*.c because the diff is getting too large and too unwielding to audit. - Ben On Thu, 9 May 2002, Tim Rice wrote: > On Thu, 9 May 2002, Roger Cornelius wrote: > > > Tim, > > > > I posted this patch to the list on February 12th in response to a > > message from "Frank S. Bernhardt" (frank at bcsi.ca). Except for the fact > > that it's now against sshpty.c instead of session.c, one comment has > > been changed, and I had enclosed it within #ifdefs, the patch is the > > same. I'm happy the patch will benefit other ssh users (that's why I > > posted it), but it would be nice if I were at least credited. > > > > Roger Cornelius > > > > It is indeed based directly on your patch and I was going to give > you credit when it's commited. :-) > > Didn't mean to apear to be taking credit for this one. > > -- > Tim Rice Multitalents (707) 887-1469 > tim at multitalents.net > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From bugzilla-daemon at mindrot.org Fri May 10 12:04:58 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 10 May 2002 12:04:58 +1000 (EST) Subject: [Bug 124] Terminal hangs when data is streaming to it... Message-ID: <20020510020458.C40C7E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=124 ------- Additional Comments From gdg at zplane.com 2002-05-10 12:04 ------- I'm seeing this same thing, except for even relatively small files or streaming transfers. (A few hundred kb on scp, or a few hundred kb of streamed X11 data.). In my case I'm running client 3.1p1 and the sshd is 2.0.13 (non-commercial) patched to 2.0.18. Again, using Protocol 1 is a workaround. Glenn Golden gdg at zplane.com ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri May 10 12:15:37 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 10 May 2002 12:15:37 +1000 (EST) Subject: [Bug 124] Terminal hangs when data is streaming to it... Message-ID: <20020510021537.7080BE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=124 ------- Additional Comments From gdg at zplane.com 2002-05-10 12:15 ------- I'm seeing same thing. My client is 3.1p1 running on Linux 2.4.18 on i686. Server (sshd) info is listed as "2.0.13 (non-commercial)... patched to 2.0.19" running on a Linux 2.2.18 kernel on i686. Using protocol 2, scp of more than a few hundred kb usually hangs. Similarly, for X11 forwarding, after a few hundred kb of fairly intense transfer activity, it usually hangs. Using Protocol 1, neither problem is ever observed. I would agree this is a critical bug. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tim at multitalents.net Fri May 10 13:40:49 2002 From: tim at multitalents.net (Tim Rice) Date: Thu, 9 May 2002 20:40:49 -0700 (PDT) Subject: patch to sshpty.c In-Reply-To: Message-ID: On Thu, 9 May 2002, Ben Lindstrom wrote: > > Is this patch required for all platforms or just SCO? If it is just for > SCO then why is not stated as such.. If it is more a universal issue then > do you plan on submitting it back to Markus when we open up the main tree? I suspect it's a universal issue on BSD-style pty's, but I'm not sure. That's why I sent it to the list. The only platform I have here that uses the BSD-style pty is SCO. It's highly unlikely that it would break the others. I'd be interested in feedback from anyone that has a platform (other than SCO) that uses BSD-style ptys. Ie. running egrep "PTY|DEV" config.h produces /* #undef HAVE_DEV_PTMX */ /* #undef HAVE_DEV_PTS_AND_PTC */ /* #undef HAVE_OPENPTY */ /* #undef HAVE_PTY_H */ /* #undef HAVE__GETPTY */ > > I'd like to see us move some of the more 'Must have for X platform' > out into openbsd-contrib/port-*.c because the diff is getting too large > and too unwielding to audit. > > - Ben > The patch again -------------------< cut > ----------------- --- sshpty.c.old Tue Jan 15 17:06:39 2002 +++ sshpty.c Thu May 9 12:19:06 2002 @@ -199,6 +199,7 @@ const char *ptyminors = "0123456789abcdef"; int num_minors = strlen(ptyminors); int num_ptys = strlen(ptymajors) * num_minors; + struct termios tio; for (i = 0; i < num_ptys; i++) { snprintf(buf, sizeof buf, "/dev/pty%c%c", ptymajors[i / num_minors], @@ -223,6 +224,19 @@ close(*ptyfd); return 0; } + /* set tty modes to a sane state for broken clients */ + if (tcgetattr(*ptyfd, &tio) < 0) + log("Getting tty modes for pty failed: %.100s", strerror(errno)); + else { + tio.c_lflag |= (ECHO | ISIG | ICANON); + tio.c_oflag |= (OPOST | ONLCR); + tio.c_iflag |= ICRNL; + + /* Set the new modes for the terminal. */ + if (tcsetattr(*ptyfd, TCSANOW, &tio) < 0) + log("Setting tty modes for pty failed: %.100s", strerror(errno)); + } + return 1; } return 0; -----------------< end cut > ----------------- -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bugzilla-daemon at mindrot.org Sat May 11 01:03:01 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 11 May 2002 01:03:01 +1000 (EST) Subject: [Bug 194] still problems with libutil Message-ID: <20020510150301.1F094E8FF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=194 ------- Additional Comments From dh at onclick.org 2002-05-11 01:02 ------- Ahem, did you read the message body? Maybe the problem is not because of libutil but OpenSSH stops because of reference problems with libutil. If you know the reason and solution then please tell me. Your qeustion does not make sense to me, I don't understand position. Please explain what you want to say or know! ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mjs at ams.org Sat May 11 01:05:36 2002 From: mjs at ams.org (Matt Studley) Date: Fri, 10 May 2002 11:05:36 -0400 (EDT) Subject: building OpenSSH-3.1p1 w/OpenSSL-0.9.6d Message-ID: Has anyone tried to build 3.1p1 on Solaris with the new openssl-0.9.6d? I am having trouble building; here is my setup: GNU ld, GNU make and my config options are as follows: ./configure --prefix=/usr/local/stow/openssh-3.1p1 \ --sysconfdir=/usr/local/etc --with-md5-passwords --disable-suid-ssh \ --with-ssl-dir=/usr/local/ssl Here is the error is fails on: /usr/local/bin/ld -o scp scp.o -L. -Lopenbsd-compat/ -R/usr/local/ssl/lib -L/usr/local/ssl/lib -L/usr/local/lib -R/usr/local/lib -lssh -lopenbsd-compat -lz -lsocket -lnsl -lcrypto /usr/local/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000010fd0 scp.o: In function `progressmeter': /usr/local/src/security/openssh-3.1p1/scp.c:1132: undefined reference to `__floatdidf' /usr/local/src/security/openssh-3.1p1/scp.c:1132: undefined reference to `__floatdidf' /usr/local/src/security/openssh-3.1p1/scp.c:1179: undefined reference to `__floatdidf' /usr/local/src/security/openssh-3.1p1/scp.c:1179: undefined reference to `__floatdidf' gmake: *** [scp] Error 1 Any ideas? Matt Studley American Mathematical Society UNIX Sys Admin "Quantum Mechanics - mjs at ams.org The dreams that stuff is made of" From bugzilla-daemon at mindrot.org Sat May 11 01:09:51 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 11 May 2002 01:09:51 +1000 (EST) Subject: [Bug 194] still problems with libutil Message-ID: <20020510150951.96EB6E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=194 ------- Additional Comments From mouring at eviladmin.org 2002-05-11 01:09 ------- atexit no longer exists within the code base. How can this be tripping up compile? Can you provide us with the compile time error? Or more details as to why you are saying. "I always stumble over libutil not being able to reference atexit." When.. 20020406 [..] - (bal) We no longer use atexit()/xatexit()/on_exit() Maybe what Linux.. Because I have not seen any problems compiling under Redhat nor Mandrake. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 11 03:03:08 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 11 May 2002 03:03:08 +1000 (EST) Subject: [Bug 194] still problems with libutil Message-ID: <20020510170308.883F1E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=194 ------- Additional Comments From dh at onclick.org 2002-05-11 03:03 ------- Do you call this support! I already gave the information. Maybe you should learn to read a message to its bottom. To tell you how it looks like for the user of your product: =========================================================== I disabled the use of libutil (--disable-libutil) but got this configuration output: Libraries: -lutil -lz -lnsl -lcrypto -lcrypt So, at least your configuration option does not render very clearly what actually happens. A user is a bit confused by that. Then I get this compilation error: /bin/ld -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o -L. -Lopenbsd-compat/ -lssh -lopenbsd-compat -lutil -lz -lnsl -lcrypto -lcrypt /bin/ld: warning: cannot find entry symbol _start; defaulting to 0804b208 /usr/lib/libutil.so: undefined reference to `atexit' make: *** [ssh] Fehler 1 The second line shows the reference to -lutil. So, libutil is still enabled. The forelast line expresses that the reference to atexit was not working. But you write: - (bal) We no longer use atexit()/xatexit()/on_exit() So, if not you who else? How the user shall answer this? To him this is only paradox. So, if not your product uses atexit then at least a product which you refer to. Then, it is still your problem since that product works otherwise. Then you write this: Maybe what Linux.. Because I have not seen any problems compiling under Redhat nor Mandrake. Why you ask me this. If I was telling you that I use SuSE would you then know the solution. Or would you just complement me to my distributor. So, only RedHat users can get your support? Is RedHat the measure for free source? To tell you what I am using: Free Source as mother GNU has created it. Did I loose support now? I don't use any distribution and, though RedHat took over being the measure, just the source still works fine. My system consists of thousands of products like: GNOME, Mozilla, Gnumeric, Evolution, Apache 2.0, PHP4, PERL, Python, MySQL, PostgreSQL, OpenSSL, the compilation environment (as I wrote earlier I tested atexit and my little c prog worked out of the box). So, don't tell me it's my system. Some product that Open SSH refers to seems to need atexit. Since that product works otherwise the culprit could be the autoconf system. Maybe your Makefile does not set environment variables correctly when spitting out gcc commands. I did not append a complete make log but send it to the maintainer directly because bugzilla did everything except sending the message when an attachment was specified. I lost an hour waiting and trying and waiting and trying. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 11 03:22:53 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 11 May 2002 03:22:53 +1000 (EST) Subject: [Bug 194] still problems with libutil Message-ID: <20020510172253.2FF0AE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=194 ------- Additional Comments From wendyp at cray.com 2002-05-11 03:22 ------- you might want to remember that the developers are volunteers here. they are providing support because they want to. your belligerent attitude will not exactly encourage anyone to look into your problem. you should always provide what OS you are running with every bug report. sometimes others may have come across the same problem. ben's statement that it works on mandrake and redhat wasn't a shot at you, but an attempt to better pigeonhole exactly where the problem is. damien's response looks strange in the order it appears to have been received, but remember that email can cross and he may have sent it quite a while before you sent your response. so, at risk of getting whapped by someone- please chill out. these are volunteers and shouldn't be treated badly when they are trying to figure out a problem you've waited a year on. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 11 03:25:21 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 11 May 2002 03:25:21 +1000 (EST) Subject: [Bug 239] ssh didn't resolv name server on HPUX 11i Message-ID: <20020510172521.16A3BE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=239 ------- Additional Comments From pascalrouchon at yahoo.fr 2002-05-11 03:25 ------- yes HAVE_GETADDRINFO 1 is defined i have try the source OpenSSH_3.2.1p1 from cvs wich didn't work. i have open a call at HP. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 11 03:50:59 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 11 May 2002 03:50:59 +1000 (EST) Subject: [Bug 194] still problems with libutil Message-ID: <20020510175059.11AB7E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=194 ------- Additional Comments From dh at onclick.org 2002-05-11 03:50 ------- You might remember that people now depend on your product because since you offered it for free many sites just force a user like me to use your product. Thus, you carry some responsibility. And, that your supporters are volunteers does not mean that they can write what they want while I have to be quiet. As you stated correctly I am now without OpenSSH since over a year (on my main system, my old SuSE uses an older version which is insecure). And, my first report was posted a month ago now. Since then I only got one creative message stating that the problem was solved which is not true. Now your volunteers do so as if the problem does not even exist. I only got "belligerent" (what is not true, I just tried to get sense into the communication) because your volunteers were, lets say, the opposite of wordy. I am in need and would apprecheate some helpful contact. Maybe you consider this. Or do I have to dance for your volunteers? When they are willing to help? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 11 04:14:01 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 11 May 2002 04:14:01 +1000 (EST) Subject: [Bug 194] still problems with libutil Message-ID: <20020510181401.E62E2E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=194 ------- Additional Comments From dh at onclick.org 2002-05-11 04:13 ------- Here is what ver_linux tells about my system: Linux orgc 2.4.16 #3 Mit M?r 27 16:34:35 CET 2002 i686 unknown Gnu C 2.95.3 Gnu make 3.79.1 binutils 2.11.2 util-linux 2.11i mount 2.11i modutils 2.4.12 e2fsprogs 1.25 PPP 2.4.1 Linux C Library 2.2.4 Dynamic linker (ldd) 2.2.4 Procps 2.0.7 Net-tools 1.60 Kbd 1.06 Sh-utils 2.0 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From gert at greenie.muc.de Sat May 11 04:33:10 2002 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 10 May 2002 20:33:10 +0200 Subject: [Bug 194] still problems with libutil In-Reply-To: <20020510170308.883F1E881@shitei.mindrot.org>; from bugzilla-daemon@mindrot.org on Sat, May 11, 2002 at 03:03:08AM +1000 References: <20020510170308.883F1E881@shitei.mindrot.org> Message-ID: <20020510203310.A26074@greenie.muc.de> Hi, On Sat, May 11, 2002 at 03:03:08AM +1000, dh at onclick.org wrote: > To tell you what I am using: Free Source as mother GNU has created it. Did I > loose support now? The "free" in "Free Source" means "you pay no money, you can fix it yourself if you have problems". If you do not want to use ready-made packages for ready-made distributions, yes, it's "free as mother GNU has created it", but this does also mean "*YOU* have to do all the work" if it doesn't work. If you want to be constructive, then send in patches or some explanation what is happening and why things are failing - in this specific example, linking -lutil should not do any harm if it is not needed, but if it does, something is really messed up with your system, and this is NOT the fault of the openssh developers. (Note: I am NOT one of the "developers". I just try to help porting this to the systems that I need - but an attitude as yours shows that you haven't understand Free Software at all). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From bugzilla-daemon at mindrot.org Sat May 11 04:33:55 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 11 May 2002 04:33:55 +1000 (EST) Subject: [Bug 194] still problems with libutil Message-ID: <20020510183355.56961E8EA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=194 ------- Additional Comments From tim at multitalents.net 2002-05-11 04:33 ------- If you edit your Makefile and remove -lutil from the LIBS= line, does it compile? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From gem at rellim.com Sat May 11 05:02:44 2002 From: gem at rellim.com (Gary E. Miller) Date: Fri, 10 May 2002 12:02:44 -0700 (PDT) Subject: [Bug 194] still problems with libutil In-Reply-To: <20020510170308.883F1E881@shitei.mindrot.org> Message-ID: Yo ! I have seen this before. It happens when some of your libraries are built with gcc before < 3.0 and some with gcc >= 3.0 It has nothing to do with openssh. Take this up with the GCC and Glibc folks that created this mess when they removed atexit from libc. Your best fix is to recompile all the libaries you think are being used with the current compiler. That is not always sufficient for some projects like X11 that do strange and unnatural things with dynamic libs. If you search on google you will see this is drving everyone crazy... RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 On Sat, 11 May 2002 bugzilla-daemon at mindrot.org wrote: > Then I get this compilation error: > > /bin/ld -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o > readconf.o clientloop.o -L. -Lopenbsd-compat/ -lssh -lopenbsd-compat -lutil -lz > -lnsl -lcrypto -lcrypt > /bin/ld: warning: cannot find entry symbol _start; defaulting to 0804b208 > /usr/lib/libutil.so: undefined reference to `atexit' > make: *** [ssh] Fehler 1 From bugzilla-daemon at mindrot.org Sat May 11 05:03:51 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 11 May 2002 05:03:51 +1000 (EST) Subject: [Bug 194] still problems with libutil Message-ID: <20020510190351.E6426E8EA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=194 ------- Additional Comments From mouring at eviladmin.org 2002-05-11 05:03 ------- ermm.. This looks like a glibc issue. Because atexit() is part of glibc. [mouring at newton ~]$nm /usr/lib/libc.a | grep atexit [..] atexit.o: [..] 00000000 T atexit So I'm not sure why libutil would be kicking out that error. This is really not a valid test of atexit(), but can you try compiling this? It would at least show us if atexit() support even exists in glibc. void test(void) { printf("Hello World\n"); } int main(){ atexit(test); } BTW, I don't care to get into distro wars.. I work on servers from Linux/Redhat to Solaris to NeXTStep. To tell you the truth they all piss me off for all different reasons. =) And I'm sorry if you feel we are not solving your problem, but just randomly disabling libraries is the wrong approach to solve this problem. - Ben ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mouring at etoh.eviladmin.org Sat May 11 05:02:36 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 10 May 2002 14:02:36 -0500 (CDT) Subject: [Bug 194] still problems with libutil In-Reply-To: Message-ID: Please note people replying to an email does not cause it to be entered into the bugzilla tree. So Gary if you could. Please repost this in bugzilla for the record. http://bugzilla.mindrot.org/show_bug.cgi?id=194 - Ben On Fri, 10 May 2002, Gary E. Miller wrote: > Yo ! > > I have seen this before. It happens when some of your libraries are > built with gcc before < 3.0 and some with gcc >= 3.0 > > It has nothing to do with openssh. Take this up with the GCC and Glibc > folks that created this mess when they removed atexit from libc. Your > best fix is to recompile all the libaries you think are being used with > the current compiler. That is not always sufficient for some projects > like X11 that do strange and unnatural things with dynamic libs. > > If you search on google you will see this is drving everyone crazy... > > > RGDS > GARY > --------------------------------------------------------------------------- > Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 > gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 > > On Sat, 11 May 2002 bugzilla-daemon at mindrot.org wrote: > > > Then I get this compilation error: > > > > /bin/ld -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o > > readconf.o clientloop.o -L. -Lopenbsd-compat/ -lssh -lopenbsd-compat -lutil -lz > > -lnsl -lcrypto -lcrypt > > /bin/ld: warning: cannot find entry symbol _start; defaulting to 0804b208 > > /usr/lib/libutil.so: undefined reference to `atexit' > > make: *** [ssh] Fehler 1 > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From bugzilla-daemon at mindrot.org Sat May 11 05:09:51 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 11 May 2002 05:09:51 +1000 (EST) Subject: [Bug 239] ssh didn't resolv name server on HPUX 11i Message-ID: <20020510190951.020FAE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=239 ------- Additional Comments From pascalrouchon at yahoo.fr 2002-05-11 05:09 ------- Ok guys i have found the problem and a solution. The HP patch is PHCO_25452 which implement getaddrinfo function in libc. to make ssh working i have undefined HAVE_GETADDRINFO in config.h after the configure. and now ssh is resolving name server. i think the implementation of getaddrinfo on hpux is different. Thx. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From stephen at tgivan.com Sat May 11 05:15:21 2002 From: stephen at tgivan.com (Stephen Rasku) Date: Fri, 10 May 2002 12:15:21 -0700 (PDT) Subject: gvim hangs under ssh Message-ID: <200205101915.MAA26692@aukland.tgivan.com> This happens every time. I: 1. ssh into another machine 2. start gvim 3. Select another color scheme from "Edit | Color Scheme" At this point gvim hangs and so does the terminal that I am ssh'ed into. I am using vim 6.1 on Solaris 7 machines. I am using: OpenSSH_2.9p1, SSH protocols 1.5/2.0, OpenSSL 0x0090600f This problem doesn't happen if I rlogin and set my DISPLAY variable back to the client machine. Has anyone else seen this? -- Stephen Rasku E-mail: stephen at tgivan.com Senior Software Engineer Web: http://www.pop-star.net/ TGI Technologies From bugzilla-daemon at mindrot.org Sat May 11 05:28:16 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 11 May 2002 05:28:16 +1000 (EST) Subject: [Bug 194] still problems with libutil Message-ID: <20020510192816.33EE2E8EA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=194 ------- Additional Comments From gem at rellim.com 2002-05-11 05:28 ------- Yo ! I have seen this before. It happens when some of your libraries a re built with gcc before < 3.0 and some with gcc >= 3.0. It also is related to the removal of atexit() from the libc.so file around 26 Feb 01. It has nothing to do with openssh. Take this up with the GCC and Glibc folks that created this mess when they removed atexit from libc. Your best fix is to recompile all the libaries you think are being used with the current compiler. That is not always sufficient for some projects like X11 that do strange and unnatural things with dynamic libs. If you search on google you will see this is drving everyone crazy... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 11 05:38:08 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 11 May 2002 05:38:08 +1000 (EST) Subject: [Bug 194] still problems with libutil Message-ID: <20020510193808.6B233E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=194 ------- Additional Comments From gem at rellim.com 2002-05-11 05:38 ------- This from the glibc-2-2.5 FAQ > 3.23. I get "undefined reference to `atexit'" > > {UD} This means that your installation is somehow broken. The situation is > the same as for 'stat', 'fstat', etc (see question 2.7). Investigate why the > linker does not pick up libc_nonshared.a. It was noted earlier that atexit is in libc.a, but by default the linker uses libc.so and that does NOT contain atexit() in newer versions. RGDS GARY ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 11 07:33:46 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 11 May 2002 07:33:46 +1000 (EST) Subject: [Bug 194] still problems with libutil Message-ID: <20020510213346.A0BB2E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=194 ------- Additional Comments From dh at onclick.org 2002-05-11 07:33 ------- Some examples why I got angry: First: There was a Gert who flamed me with an email directed to my private address. I already answered. Second: Ben writes (at this place) that I should try a small prog to see if "atexit() support even exists in glibc". He tries to help but he did not read my messages. I already wrote a test prog and atexit works fine on my system. Nevertheless: thanks for being helpful. Third: gem at rellim.com wrote about the problem with changing compilers. Again somebody is creative, thanks. I did not mix compilers, still use the same for all progs on my system (would not mix). He then writes about the newer glibc releases and that they do not include atexit anymore (same problem like with Ben): "It has nothing to do with openssh." This is not true because if the maintainers of glibc change the rules then you have to follow since you, and with you your users, depend on that. He then writes that I shall: "Take this up with the GCC and Glibc folks that created this mess when they removed atexit from libc." I think this was just a call for revolution but, please, your product wants to find something though you already know it is gone. Why I shall struggle with the maintainers of glibc then? And, again, atexit is there and accessible. Fourth: Gary writes: "It was noted earlier that atexit is in libc.a, but by default the linker uses libc.so and that does NOT contain atexit() in newer versions." That is a hint into the right direction but, as I wrote, my atexit works fine by just including stdio.h. So, ok, its good information still. And, in the end, I wonder what you are talking about because you now want me to find atexit though Ben writes that: "We no longer use atexit()/xatexit()/on_exit()". Better is finding the right library which still wants to use atexit, and checking if it's yours or belonging to another project. Then, I could actually bore them. tim at multitalents.net actually helped me most. He wrote: "If you edit your Makefile and remove -lutil from the LIBS= line, does it compile?". I tried out and came a bit more far. Now the error is: /bin/ld -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o -L. -Lopenbsd-compat/ -lssh -lopenbsd-compat -lz -lnsl -lcrypto -lcrypt /bin/ld: warning: cannot find entry symbol _start; defaulting to 0804b1f8 /usr/lib/libnsl.so: undefined reference to `atexit' As you can see, still a library of the glibc package wants atexit. And, I think that is the real problem. The glibc library will always want to find atexit. I tell again here, because you seem to forget this quickly, that I already checked for atexit and it is existing and working. Thus, I still believe that there is a problem with the setting of search paths through variables. I am shure you included the stdio.h, otherwise more would not work. One thing on your support really works good now: the frequency ;) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From WWINTON at stratech.com Sat May 11 08:10:04 2002 From: WWINTON at stratech.com (Winton, William) Date: Fri, 10 May 2002 18:10:04 -0400 Subject: Patch for SOCKS4A in OpenSsh Message-ID: <98EC0F1ABF39D411B9E900B0D0214DF2060FB3@buckman.jax.pathtech.com> I love SSH's ability to dynamically forward ports using SOCKS (either -D or DynamicForward) (ie "ssh -D 1081 private.mine.net"). But the thing that has caused me some pain, is that only SOCKS4 is supported. The SOCKS4 proxy specification does not permit hostnames, but only IP addresses. This isn't much of a problem if the target host is a public Internet host or otherwise DNS resolvable target ... but frequently SSH tunneling is used to get into a private network, and the DNS which can resolve the hostname is on the wrong side of the tunnel. I don't think that SOCKS5 or anything that complex would be usefully helpful, but there is an addition to SOCKS4 (called SOCKS4A) which does permit host names to be passed in in the SOCKS4 initiation packet. See http://www.socks.nec.com/protocol/socks4a.protocol for details, and here's a brief synopsis. The SOCKS4 initiation packet looks like this: +----+----+----+----+----+----+----+----+----+----+....+----+ | VN | CD | DSTPORT | DSTIP | USERID |NULL| +----+----+----+----+----+----+----+----+----+----+....+----+ # of bytes: 1 1 2 4 variable 1 >For version 4A, if the client cannot resolve the destination host's domain name to find its IP address, it should set the first three bytes of DSTIP to NULL and the last byte to a non-zero value. >Following the NULL byte terminating USERID, the client must sends the destination domain name and terminates it with another NULL byte. The SOCKS4A initiation packet looks like this (where DSTIP is 0.0.0.X): +----+----+----+----+----+----+----+----+----+----+....+----+----+----+....+ ----+ | VN | CD | DSTPORT | DSTIP | USERID |NULL| HOSTNAME |NULL| +----+----+----+----+----+----+----+----+----+----+....+----+----+----+....+ ----+ # of bytes: 1 1 2 4 variable 1 variable 1 I propose a change/addition to SSH (the client program only) which will permit SOCKS4A proxy connections. This only requires a relatively minor change to the "channel_decode_socks4" function in "channels.c" . Here's a DIFF which will apply this patch to openssh-3.1p1-1: ----------< cut >---------- --- openssh-3.1p1-1/channels.c Mon Mar 4 20:57:45 2002 +++ openssh-3.1p1-1-socks4a/channels.c Fri May 10 16:52:12 2002 @@ -908,11 +908,34 @@ channel_decode_socks4(Channel *c, fd_set strlcpy(username, p, sizeof(username)); buffer_consume(&c->input, len); buffer_consume(&c->input, 1); /* trailing '\0' */ - host = inet_ntoa(s4_req.dest_addr); - strlcpy(c->path, host, sizeof(c->path)); c->host_port = ntohs(s4_req.dest_port); + + /* check for socks4a vs socks4 */ + if (0 == (s4_req.dest_addr.s_addr & htonl(IN_CLASSC_NET))) { + /* + * is client using socks4a? if the first three octets of the IP + * are zero, ie 0.0.0.1, then we get the host name from after user + */ + have = buffer_len(&c->input); + p = buffer_ptr(&c->input); + len = strlen(p); + + debug2("channel %d: decode socks4a: host %s/%d", c->self, p, len); + if (len > have) + fatal("channel %d: decode socks4a: len %d > have %d", + c->self, len, have); + + strlcpy(c->path, p, sizeof(c->path)); + buffer_consume(&c->input, len); + buffer_consume(&c->input, 1); /* trailing '\0' */ + + } else { + /* build the hostname from the IP, ie 44.33.22.11, socks4 style */ + host = inet_ntoa(s4_req.dest_addr); + strlcpy(c->path, host, sizeof(c->path)); + } debug("channel %d: dynamic request: socks4 host %s port %u command %u", c->self, host, c->host_port, s4_req.command); ----------< end cut >---------- I did a brief test of this under CYGWIN, but this patch should work globally. ~ William Winton From bugzilla-daemon at mindrot.org Sat May 11 08:19:36 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 11 May 2002 08:19:36 +1000 (EST) Subject: [Bug 194] still problems with libutil Message-ID: <20020510221936.E7ADBE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=194 ------- Additional Comments From mouring at eviladmin.org 2002-05-11 08:19 ------- I sent this in private email, but I'll restate this for the record. Working off of Gary's comment.. Try adding /usr/lib/libc_nonshared.a to your LIBC= and see if that resolves it. If it does then I'm unsure what we (as the portable group) can do to find to correct this since that should be linked by default by the compiler. - Ben ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 11 08:26:46 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 11 May 2002 08:26:46 +1000 (EST) Subject: [Bug 194] still problems with libutil Message-ID: <20020510222646.282A5E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=194 ------- Additional Comments From gem at rellim.com 2002-05-11 08:26 ------- Yo All! > Try adding /usr/lib/libc_nonshared.a to your > LIBC= and see if that resolves it. Or link statically. Since you know atexit() is in your libc.a and I bet it is NOT in your libc.so. I'll also bet you updated your libc about the time you first had problems compiling OpenSSH. You said you had problems for about a year and glibc had this bad change about 14 months ago. RGDS GARY ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dan at doxpara.com Sat May 11 08:39:48 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Fri, 10 May 2002 15:39:48 -0700 Subject: Patch for SOCKS4A in OpenSsh References: <98EC0F1ABF39D411B9E900B0D0214DF2060FB3@buckman.jax.pathtech.com> Message-ID: <019f01c1f873$97ccbf70$1701000a@effugas> Winton-- Excellent! Absolutely wonderful. I'm wondering which apps/encapsulators support 4A? This gets me around the DNS leakage problem quite nicely. Incidentally, we do need SOCKS5 support -- if for no other reason, the fact that there's *operating system* level support in OSX for SOCKS5 redirection. So OpenSSH can become a completely transparent VPN system in OSX w/ SOCKS5. Even without OSX, a decent number of apps only support SOCKS5 proxying. --Dan From michael at bizsystems.com Sat May 11 12:27:33 2002 From: michael at bizsystems.com (Michael Robinton) Date: Fri, 10 May 2002 19:27:33 -0700 (PDT) Subject: socks5 support Message-ID: > Winton-- > > Excellent! Absolutely wonderful. > > I'm wondering which apps/encapsulators support 4A? This gets me > around > the DNS leakage problem quite nicely. > > Incidentally, we do need SOCKS5 support -- if for no other > reason, the > fact that there's *operating system* level support in OSX for SOCKS5 > redirection. So OpenSSH can become a completely transparent VPN > system in OSX w/ SOCKS5. > > Even without OSX, a decent number of apps only support SOCKS5 > proxying. > Good luck, I sent in a patch for socks5 support back in October of last year and got blown out of the water by the "developers". The patch consists of three files: README.patch patch_Applied-2-openssh-2.9.9p2.diff do_configure.sh which you will find attached :-) The one drawback that I saw when rummaging around in openssh code is that it is nicely set up to support ipv6 and the socks stuff only works for ipv4. The socks support is identical to that supplied in the pre-openssh ssh-1.2.xx stuff. I have not tested the socks4 support. Michael -------------- next part -------------- --with-socks5 patch apply the patch regenerate config.h.in autoheader configure.in > config.h.in regenerate configure autoconf configure.in > configure then build the configuration this example is for Linux #!/bin/sh CFLAGS="-O2 -Wall" ./configure \ --prefix=/usr \ --sysconfdir=/etc/ssh \ --without-pam \ --with-md5-passwords \ --with-tcp-wrappers \ --with-socks5 \ --disable-scp-stats \ --with-default-path=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin/i386-slackware-linux this script can be found in do_configure.sh -------------- next part -------------- #!/bin/sh CFLAGS="-O2 -Wall" ./configure \ --prefix=/usr \ --sysconfdir=/etc/ssh \ --without-pam \ --with-md5-passwords \ --with-tcp-wrappers \ --with-socks5 \ --disable-scp-stats \ --with-default-path=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin/i386-slackware-linux -------------- next part -------------- diff -u openssh-2.9.9p2.old/acconfig.h openssh-2.9.9p2/acconfig.h --- openssh-2.9.9p2.old/acconfig.h Thu Sep 20 12:43:41 2001 +++ openssh-2.9.9p2/acconfig.h Sat Oct 6 17:44:07 2001 @@ -111,6 +111,9 @@ * message at run-time. */ #undef RSAREF +/* Define to disable scp statistics */ +#undef DISABLE_SCP_STATISTICS + /* struct timeval */ #undef HAVE_STRUCT_TIMEVAL @@ -332,6 +335,30 @@ /* Define if you want smartcard support */ #undef SMARTCARD + +/* The code in sshconnect.c is written for SOCKS4. If SOCKS5 should be used + these needs redefining */ +#undef Rconnect +#undef Rgetsockname +#undef Rgetpeername +#undef Rbind +#undef Raccept +#undef Rlisten +#undef Rselect +#undef Rrecvfrom +#undef Rsendto +#undef Rrecv +#undef Rsend +#undef Rread +#undef Rwrite +#undef Rrresvport +#undef Rshutdown +#undef Rlisten +#undef Rclose +#undef Rdup +#undef Rdup2 +#undef Rfclose +#undef Rgethostbyname @BOTTOM@ diff -u openssh-2.9.9p2.old/channels.c openssh-2.9.9p2/channels.c --- openssh-2.9.9p2.old/channels.c Mon Sep 17 22:53:12 2001 +++ openssh-2.9.9p2/channels.c Sat Oct 6 17:09:30 2001 @@ -2481,7 +2481,12 @@ struct hostent *he; struct in_addr my_addr; +#if defined(SOCKS5) + he = Rgethostbyname(hostname); +#else + he = gethostbyname(hostname); +#endif if (he == NULL) { error("[X11-broken-fwd-hostname-workaround] Could not get " "IP address for hostname %s.", hostname); diff -u openssh-2.9.9p2.old/configure.in openssh-2.9.9p2/configure.in --- openssh-2.9.9p2.old/configure.in Tue Sep 25 15:39:38 2001 +++ openssh-2.9.9p2/configure.in Sat Oct 6 17:41:54 2001 @@ -480,6 +480,141 @@ ] ) +dnl checkfor SOCKS support +AC_MSG_CHECKING(whether to support SOCKS) +AC_ARG_WITH(socks, + [ --with-socks Build with SOCKS firewall support.], + [ case "$withval" in + no) + AC_MSG_RESULT(no) + ;; + yes) + AC_MSG_RESULT(yes) + AC_CHECK_LIB(socks5, SOCKSconnect, [ + socks=5 + LIBS="-lsocks5 $LIBS"], [ + AC_CHECK_LIB(socks, Rconnect, [ + socks=4 + LIBS="-lsocks $LIBS"], [ + AC_MSG_ERROR(SOCKS library missing. You must first install socks.) ] ) ] ) + ;; + esac ], + AC_MSG_RESULT(no) +) + +if test "x$socks" = "x"; then + AC_MSG_CHECKING(whether to support SOCKS5) + AC_ARG_WITH(socks5, + [ --with-socks5[=PATH] Build with SOCKS5 firewall support.], + [ case "$withval" in + no) + AC_MSG_RESULT(no) + ;; + *) + AC_MSG_RESULT(yes) + socks=5 + if test "x$withval" = "xyes"; then + withval="-lsocks5" + else + if test -d "$withval"; then + if test -d "$withval/include"; then + CFLAGS="$CFLAGS -I$withval/include" + else + CFLAGS="$CFLAGS -I$withval" + fi + if test -d "$withval/lib"; then + withval="-L$withval/lib -lsocks5" + else + withval="-L$withval -lsocks5" + fi + fi + fi + LIBS="$withval $LIBS" + # If Socks was compiled with Kerberos support, we will need + # to link against kerberos libraries. Temporarily append + # to LIBS. This is harmless if there is no kerberos support. + TMPLIBS="$LIBS" + LIBS="$LIBS $KERBEROS_LIBS" + AC_TRY_LINK([], + [ SOCKSconnect(); ], + [], + [ AC_MSG_ERROR(Could not find the $withval library. You must first install socks5.) ]) + LIBS="$TMPLIBS" + ;; + esac ], + AC_MSG_RESULT(no) + ) +fi + +if test "x$socks" = "x"; then + AC_MSG_CHECKING(whether to support SOCKS4) + AC_ARG_WITH(socks4, + [ --with-socks4[=PATH] Compile with SOCKS4 firewall traversal +support.], + [ case "$withval" in + no) + AC_MSG_RESULT(no) + ;; + *) + AC_MSG_RESULT(yes) + socks=4 + if test "x$withval" = "xyes"; then + withval="-lsocks" + else + if test -d "$withval"; then + withval="-L$withval -lsocks" + fi + fi + LIBS="$withval $LIBS" + AC_TRY_LINK([], + [ Rconnect(); ], + [], + [ AC_MSG_ERROR(Could not find the $withval library. +You must first install socks.) ]) + ;; + esac ], + AC_MSG_RESULT(no) + ) +fi + + + +if test "x$socks" = "x4"; then + AC_DEFINE(SOCKS) + AC_DEFINE(SOCKS4) + CPPFLAGS="$CPPFLAGS -I/usr/local/include" + LDFLAGS="$LDFLAGS -L/usr/local/lib" +fi + +if test "x$socks" = "x5"; then + AC_DEFINE(SOCKS) + AC_DEFINE(SOCKS5) + AC_DEFINE(Rconnect,SOCKSconnect) + AC_DEFINE(Rgetsockname,SOCKSgetsockname) + AC_DEFINE(Rgetpeername,SOCKSgetpeername) + AC_DEFINE(Rbind,SOCKSbind) + AC_DEFINE(Raccept,SOCKSaccept) + AC_DEFINE(Rlisten,SOCKSlisten) + AC_DEFINE(Rselect,SOCKSselect) + AC_DEFINE(Rrecvfrom,SOCKSrecvfrom) + AC_DEFINE(Rsendto,SOCKSsendto) + AC_DEFINE(Rrecv,SOCKSrecv) + AC_DEFINE(Rsend,SOCKSsend) + AC_DEFINE(Rread,SOCKSread) + AC_DEFINE(Rwrite,SOCKSwrite) + AC_DEFINE(Rrresvport,SOCKSrresvport) + AC_DEFINE(Rshutdown,SOCKSshutdown) + AC_DEFINE(Rlisten,SOCKSlisten) + AC_DEFINE(Rclose,SOCKSclose) + AC_DEFINE(Rdup,SOCKSdup) + AC_DEFINE(Rdup2,SOCKSdup2) + AC_DEFINE(Rfclose,SOCKSfclose) + AC_DEFINE(Rgethostbyname,SOCKSgethostbyname) + CPPFLAGS="$CPPFLAGS -I/usr/local/include" + CFLAGS="$CFLAGS -DSOCKS" + LDFLAGS="$LDFLAGS -L/usr/local/lib" +fi + dnl Checks for library functions. AC_CHECK_FUNCS(arc4random atexit b64_ntop bcopy bindresvport_sa clock dirname fchown fchmod freeaddrinfo futimes gai_strerror getcwd getaddrinfo getgrouplist getopt getnameinfo getrlimit getrusage getttyent glob inet_aton inet_ntoa inet_ntop innetgr login_getcapbool md5_crypt memmove mkdtemp on_exit openpty readpassphrase realpath rresvport_af setdtablesize setenv setegid seteuid setlogin setproctitle setresgid setreuid setrlimit setsid setvbuf sigaction sigvec snprintf strerror strlcat strlcpy strmode strsep sysconf tcgetpgrp utimes vsnprintf vhangup waitpid _getpty __b64_ntop) dnl Checks for time functions @@ -1838,6 +1973,12 @@ [ --disable-pututxline disable use of pututxline() etc. ([uw]tmpx) [no]], [ AC_DEFINE(DISABLE_PUTUTXLINE) ] ) +AC_ARG_ENABLE(scp-stats, +[ --disable-scp-stats disable scp statistics display [no]], + AC_DEFINE(DISABLE_SCP_STATISTICS) + AC_MSG_RESULT(yes) +) + AC_ARG_WITH(lastlog, [ --with-lastlog=FILE|DIR specify lastlog location [common locations]], [ diff -u openssh-2.9.9p2.old/includes.h openssh-2.9.9p2/includes.h --- openssh-2.9.9p2.old/includes.h Wed Sep 19 19:07:51 2001 +++ openssh-2.9.9p2/includes.h Sat Oct 6 17:10:37 2001 @@ -23,6 +23,11 @@ #include "openbsd-compat/bsd-nextstep.h" +#if defined(SOCKS5) +/* does not support IPV6 */ +#include "socks.h" +#endif + #include #include #include diff -u openssh-2.9.9p2.old/scp.c openssh-2.9.9p2/scp.c --- openssh-2.9.9p2.old/scp.c Wed Sep 19 17:57:56 2001 +++ openssh-2.9.9p2/scp.c Sat Oct 6 17:42:08 2001 @@ -128,7 +128,11 @@ int verbose_mode = 0; /* This is set to zero if the progressmeter is not desired. */ +#if defined(DISABLE_SCP_STATISTICS) +int showprogress = 0; +#else int showprogress = 1; +#endif /* This is the program to execute for the secured connection. ("ssh" or -S) */ char *ssh_program = _PATH_SSH_PROGRAM; diff -u openssh-2.9.9p2.old/sshconnect.c openssh-2.9.9p2/sshconnect.c --- openssh-2.9.9p2.old/sshconnect.c Tue Aug 7 15:29:09 2001 +++ openssh-2.9.9p2/sshconnect.c Sat Oct 6 17:10:55 2001 @@ -15,8 +15,6 @@ #include "includes.h" RCSID("$OpenBSD: sshconnect.c,v 1.110 2001/07/25 14:35:18 markus Exp $"); -#include - #include "ssh.h" #include "xmalloc.h" #include "rsa.h" @@ -182,7 +180,12 @@ */ if (privileged) { int p = IPPORT_RESERVED - 1; +#if defined(SOCKS) +/* does not support IPV6 */ + sock = Rrresvport(&p); +#else /* SOCKS */ sock = rresvport_af(&p, family); +#endif /* SOCKS */ if (sock < 0) error("rresvport: af=%d %.100s", family, strerror(errno)); else @@ -326,7 +329,12 @@ * the remote uid as root. */ temporarily_use_uid(pw); - if (connect(sock, ai->ai_addr, ai->ai_addrlen) >= 0) { +#if defined(SOCKS) + if (Rconnect(sock, ai->ai_addr, ai->ai_addrlen) >= 0) +#else /* SOCKS */ + if (connect(sock, ai->ai_addr, ai->ai_addrlen) >= 0) +#endif /* SOCKS */ + { /* Successful connection. */ memcpy(hostaddr, ai->ai_addr, ai->ai_addrlen); restore_uid(); From elf at buici.com Sat May 11 15:57:26 2002 From: elf at buici.com (elf at buici.com) Date: Fri, 10 May 2002 22:57:26 -0700 Subject: PubkeyAuthentication broken because ssh cannot ready it's identity keys Message-ID: <20020511055725.GB7180@buici.com> This is a copy of the bug report I sent debian. Package: ssh Version: 1:3.0.2p1-9 Severity: important I want to be able to login between two hosts without entering passwords. ssh-keygen -t dsa * Copy key to other machine cat id_dsa.pub >> .ssh/authorized_keys chmod 600 .ssh/authorized_keys Trouble is that the originating host appears unable to parse its own keys. This is the debug output from the machine that successfully performs the password-free login: debug1: read PEM private key done: type DSA debug1: read PEM private key done: type RSA debug1: identity file /home/elf/.ssh/identity type 0 debug1: identity file /home/elf/.ssh/id_rsa type -1 debug2: key_type_from_name: unknown key type '-----BEGIN' debug2: key_type_from_name: unknown key type '-----END' debug1: identity file /home/elf/.ssh/id_dsa type 2 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.0.2p1 Debian 1:3.0.2p1-9 The other host reports differently: debug1: read PEM private key done: type DSA debug1: read PEM private key done: type RSA debug1: identity file /home/elf/.ssh/identity type 0 debug2: key_type_from_name: unknown key type '-----BEGIN' debug2: key_type_from_name: unknown key type '-----END' debug1: identity file /home/elf/.ssh/id_dsa type 2 debug2: key_type_from_name: unknown key type '-----BEGIN' debug2: key_type_from_name: unknown key type '-----END' debug1: identity file /home/elf/.ssh/id_rsa type 1 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.0.2p1 Debian 1:3.0.2p1-9 Note that I'm using the id_dsa key for authentication. Here is the dsa key and no, I'm not concerned about being compromised. -----BEGIN DSA PRIVATE KEY----- MIIBugIBAAKBgQCHaKeWvF4kc+SNvV5iph7u6av4nnbALON9bJuio0YXuh8rwY4X o9fzf3ogOOYs+32wFp5MYT7w6Enp6Wm7WeUGuOLXpco4TiWEUpfYcApex+JagVTh FDYc5oeOeXR420b87VPRyVYnjqxGCLQpDw8ROSAkOX1xHGEzETKwzPxtcwIVALzn T1lFsWARKdqaVbI4Xo4SWKFBAoGARvAxvIDbaPnYz5fY76jhi4QTbLP8e10qEKyU OC+E6oWWZSMtnn1Z1VhgPnzvsuMnrrw4n26TuaQwg0TITJ2kep67g1Pyp02OoTOn Px84+EC/+u8KRXghl2V4DQySe7Nd45nEdRgRAfU/byKoDj2U+EF3vD18j4pWU5fW RBHyu34CgYAZh/eFfTPyULWpb45Rgh0JKHYxKrWDRB/T7kLmgs1p9JTzhf+sBXI4 qkuQHfD41NgSp4azg4i322Etr8U1slIAORHGIM5z56TGsu29E3Q18tL1/+KZiMjh 1O0fzXdsJHLhqPABphlZ96tmiVet0pxwJlS/Nw3hI1+nKfjONGmNJgIUdf0w0kl7 b68BgwdevQPU7UCLMx0= -----END DSA PRIVATE KEY----- -- System Information Debian Release: 3.0 Kernel Version: Linux cerise 2.4.18 #15 Fri May 10 00:26:54 PDT 2002 i686 unknown Versions of the packages ssh depends on: ii debconf 1.0.32 Debian configuration management system ii libc6 2.2.5-6 GNU C Library: Shared libraries and Timezone ii libpam-modules 0.72-35 Pluggable Authentication Modules for PAM ii libpam0g 0.72-35 Pluggable Authentication Modules library ii libssl0.9.6 0.9.6c-2 SSL shared libraries ii libwrap0 7.6-9 Wietse Venema's TCP wrappers library ii zlib1g 1.1.4-1 compression library - runtime --- Begin /etc/ssh/ssh_config (modified conffile) Host * ForwardX11 yes --- End /etc/ssh/ssh_config --- Begin /etc/ssh/moduli (modified conffile) Config file not present or no permissions for access --- End /etc/ssh/moduli --- Begin /etc/init.d/ssh (modified conffile) Config file not present or no permissions for access --- End /etc/init.d/ssh From gert at greenie.muc.de Sat May 11 19:12:23 2002 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 11 May 2002 11:12:23 +0200 Subject: [Bug 194] still problems with libutil In-Reply-To: <20020510213346.A0BB2E881@shitei.mindrot.org>; from bugzilla-daemon@mindrot.org on Sat, May 11, 2002 at 07:33:46AM +1000 References: <20020510213346.A0BB2E881@shitei.mindrot.org> Message-ID: <20020511111223.D9954@greenie.muc.de> Hi, On Sat, May 11, 2002 at 07:33:46AM +1000, bugzilla-daemon at mindrot.org wrote: > ------- Additional Comments From dh at onclick.org 2002-05-11 07:33 ------- > Some examples why I got angry: > > First: There was a Gert who flamed me with an email directed to my private > address. I already answered. To clarify this: I flamed you after you already exhibited very annoying "give it to me now! *whine*!" behaviour here. *After* this. So don't try to blame your misbehaviour on me. [..] > readconf.o clientloop.o -L. -Lopenbsd-compat/ -lssh -lopenbsd-compat -lz -lnsl > -lcrypto -lcrypt > /bin/ld: warning: cannot find entry symbol _start; defaulting to 0804b1f8 > /usr/lib/libnsl.so: undefined reference to `atexit' > > As you can see, still a library of the glibc package wants atexit. So why do you bother the OpenSSH people with this now? As Ben wrote: OpenSSH does not use atexit(). If your glibc is weird, try to figure out what is wrong there, and either fix glibc, or tell the OpenSSH developers what to change in the link order to work around it. Always remember: this is volunteer effort. You don't pay for it. The ONLY right you have is "help yourself". gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From dan at doxpara.com Sat May 11 19:35:32 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Sat, 11 May 2002 02:35:32 -0700 Subject: socks5 support References: Message-ID: <020001c1f8cf$324b7810$1701000a@effugas> > Good luck, I sent in a patch for socks5 support back in October of last > year and got blown out of the water by the "developers". Ack. My fault. I don't think I ever made the point sufficiently clear as to why SOCKS4, despite its ridiculous usefulness, is insufficient for a number of security critical applications. Let me be blunt: SOCKS4 DYNAMIC FORWARDS AREN'T SECURE ENOUGH. Given a SOCKS4 dynamic forward from Alice's network to Bob's, the DNS server on Alice's network is able to monitor tunnel destinations into Bob's network, and may even redirect those tunnels to arbitrary locations. This doesn't happen with SOCKS5 *or* HTTP -- DNS is handled remotely, just like in SSH Local Port Forwards. This issue isn't horrific enough to remove SOCKS4 support entirely, because it's only a problem when communicating from actively hostile networks -- but if we've got the SOCKS5 support sitting in front of us, not only are we supporting a greater range of applications, but we're not exposing users to a genuine security concern. Why HTTP as well? Because I know we've got that code too, and it allows us to say we've got a trivial API for SSH port forwards. SOCKS is only trivial once you learn it :-) As for SOCKS4A -- I'm inordinately pleased to have the code, but I just don't know what supports it on the client side. --Dan From mouring at etoh.eviladmin.org Sat May 11 19:53:48 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 11 May 2002 04:53:48 -0500 (CDT) Subject: [Bug 194] still problems with libutil In-Reply-To: <20020511111223.D9954@greenie.muc.de> Message-ID: Can we drop this and go on with finishing a solution? I'm not too much of a fan of improperly placed ranting (even if I love a good rant every once in a while myself =) and posturing. I think we need to focus on issues and leave the rest of the crap to the football games (or Rugby for you non-americans =). Gert, if anyone should be getting pissed by his messages it should be me or maybe Damien. However, after almost twelve years of cattering to open source (in some form or another) I've learned I will live longer if I take it in stride. To steal a quote from Demolition Man.. "Enhance your calm." - Ben On Sat, 11 May 2002, Gert Doering wrote: > Hi, > > On Sat, May 11, 2002 at 07:33:46AM +1000, bugzilla-daemon at mindrot.org wrote: > > ------- Additional Comments From dh at onclick.org 2002-05-11 07:33 ------- > > Some examples why I got angry: > > > > First: There was a Gert who flamed me with an email directed to my private > > address. I already answered. > > To clarify this: I flamed you after you already exhibited very annoying > "give it to me now! *whine*!" behaviour here. *After* this. So don't try > to blame your misbehaviour on me. > > [..] > > readconf.o clientloop.o -L. -Lopenbsd-compat/ -lssh -lopenbsd-compat -lz -lnsl > > -lcrypto -lcrypt > > /bin/ld: warning: cannot find entry symbol _start; defaulting to 0804b1f8 > > /usr/lib/libnsl.so: undefined reference to `atexit' > > > > As you can see, still a library of the glibc package wants atexit. > > So why do you bother the OpenSSH people with this now? As Ben wrote: > OpenSSH does not use atexit(). If your glibc is weird, try to figure out > what is wrong there, and either fix glibc, or tell the OpenSSH developers > what to change in the link order to work around it. > > Always remember: this is volunteer effort. You don't pay for it. The > ONLY right you have is "help yourself". > > gert > > -- > USENET is *not* the non-clickable part of WWW! > //www.muc.de/~gert/ > Gert Doering - Munich, Germany gert at greenie.muc.de > fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From bugzilla-daemon at mindrot.org Sat May 11 23:29:34 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 11 May 2002 23:29:34 +1000 (EST) Subject: [Bug 194] still problems with libutil Message-ID: <20020511132934.D7665E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=194 ------- Additional Comments From dh at onclick.org 2002-05-11 23:29 ------- Wow, much going on now :) I already read Ben's message about finishing the flame war. I don't want to flame further, just state what I state now since three messages. Gert, again, wrote me about his "bigger dig", and appended some details about his good relations to RMS, Linus, etc. (He enforced a useless flame war about the term free source and its impact on the user in his previous email). I definately don't agree with: "Always remember: this is volunteer effort. You don't pay for it. The ONLY right you have is "help yourself"." He always sticks to free as in free beer. He should proof his opinion with RMS again. But, the most disturbing point is this "do or dare" opinion. I did not criticize free source, was just angry about YOUR support. This is something individual and not defined by the GPL, FSF, or the community. And, as a dependent user *I have the right* to find out on whom I am dependent. But, ok, have said this, lets skip now. I now see that over months nothing happened here till I got more harsh. Now, everybody takes part with his comments. So, there is never enough time for support but always for flame wars. This is a bad truth not only for this project. I agree to ben: "Gert, if anyone should be getting pissed by his messages it should be me or maybe Damien." There are actually some more helpful people. Ben, I want to excuse because you seem to care. "If you take my original message or this one as being 'condensing' or 'elitest' non-sense then please stop reading into my writing because I'm not. I'm honestly trying to find the right question or bit of information that may help." It wasn't clear at the beginning because the first messages were, say, not that logical. Now, there still is the problem with atexit(). You, and others, asked if I could try appending /usr/lib/libc_nonshared.a to LIBS=. This way of co-operation I seekd for. I tried but still the same referencing error with libutil. As I wrote, the error does not happen to my own prog and thousands of other free source products. Thus, I don't think that glibc messes up something. It still seems to be a referencing problem of the configuration and installation procedure. I did not have to link to any place to let my own prog run. GCC found everything needed and atexit worked. This is my experience, what shall I say. You say: "I've not had anyone bring up this issue and so it leads me to believe there is some uniqueness of your system. Not saying that it is broken, but something unique enough to trigger it. What that means is will be impossible for anyone, but you to resolve it since no one else can reproduce it." I think this is at least a bit incorrect because of my overall good experience. My system is just non-manipulated source, as it should be. It works fine and clean. I was never happier about a linux system. I love it (slime). So, even if this is unique to you, still your product does something that others do not. Means: my system is only unique and triggering to openssh. So, maybe, openssh does something unique under thousands of products (we can now start the next flame war). I still stick to autoconf or similar as the culprit. As a consequence, it does not help to bore the glibc-people. They will send me back to you. I am not a jo-jo and don't want to be pushed from here to there. Maybe you can now start just giving some hints. Maybe I could send config.cache and makefiles to you. Maybe there are other things I could try. Please, you are more experienced in such big projects. You may know better what to do now. I would ask Gert because of his relations to the masters of free source but this is not a good deal, I believe. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun May 12 04:04:07 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 12 May 2002 04:04:07 +1000 (EST) Subject: [Bug 14] Can't change expired /etc/shadow password without PAM Message-ID: <20020511180407.56928E902@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=14 ------- Additional Comments From stevesk at pobox.com 2002-05-12 04:04 ------- i'm not immediately positive if no_port_forwarding_flag=1 is sufficient. need to investigate more. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at mindrot.org Sun May 12 04:07:34 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 12 May 2002 04:07:34 +1000 (EST) Subject: [Bug 239] ssh didn't resolv name server on HPUX 11i Message-ID: <20020511180734.992DCE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=239 ------- Additional Comments From stevesk at pobox.com 2002-05-12 04:07 ------- can you log a defect report with HP on this and provide the defect ID? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun May 12 05:31:26 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 12 May 2002 05:31:26 +1000 (EST) Subject: [Bug 231] ssh-keygen has fatal error while updating comment in RSA1 key Message-ID: <20020511193126.A7C62E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=231 ------- Additional Comments From stevesk at pobox.com 2002-05-12 05:31 ------- the error is not seen in current i believe due to the fix to arc4random() to call seed_rng() correctly. is there a way we can reduce the diff in terms of moving function calls around due to delaying RNG seeding? http://www.eviladmin.org/cgi-bin/cvsweb.cgi/ssh-keygen.c.diff?r1=1.87&r2=1.88 http://www.eviladmin.org/cgi-bin/cvsweb.cgi/ssh-keygen.c.diff?r1=1.91&r2=1.92 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From kevin at atomicgears.com Sun May 12 08:37:27 2002 From: kevin at atomicgears.com (Kevin Steves) Date: Sat, 11 May 2002 15:37:27 -0700 (PDT) Subject: socks5 support In-Reply-To: Message-ID: On Fri, 10 May 2002, Michael Robinton wrote: :Good luck, I sent in a patch for socks5 support back in October of last :year and got blown out of the water by the "developers". This is best handled by a ProxyCommand helper. From tim at multitalents.net Sun May 12 08:55:43 2002 From: tim at multitalents.net (Tim Rice) Date: Sat, 11 May 2002 15:55:43 -0700 (PDT) Subject: building OpenSSH-3.1p1 w/OpenSSL-0.9.6d In-Reply-To: Message-ID: On Fri, 10 May 2002, Matt Studley wrote: > > Has anyone tried to build 3.1p1 on Solaris with the new openssl-0.9.6d? I > am having trouble building; here is my setup: GNU ld, GNU make and my > config options are as follows: Try not using GNU ld. Builds OK here on Solaris with gcc, native ld, GNU make, openssl-0.9.6d > > ./configure --prefix=/usr/local/stow/openssh-3.1p1 \ > --sysconfdir=/usr/local/etc --with-md5-passwords --disable-suid-ssh \ ^^^^^^^^^^^^^^^^^^^^ Do you really want this? > --with-ssl-dir=/usr/local/ssl > > Here is the error is fails on: > > /usr/local/bin/ld -o scp scp.o -L. -Lopenbsd-compat/ -R/usr/local/ssl/lib > -L/usr/local/ssl/lib -L/usr/local/lib -R/usr/local/lib -lssh > -lopenbsd-compat -lz -lsocket -lnsl -lcrypto > /usr/local/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000010fd0 > scp.o: In function `progressmeter': > /usr/local/src/security/openssh-3.1p1/scp.c:1132: undefined reference to `__floatdidf' > /usr/local/src/security/openssh-3.1p1/scp.c:1132: undefined reference to `__floatdidf' > /usr/local/src/security/openssh-3.1p1/scp.c:1179: undefined reference to `__floatdidf' > /usr/local/src/security/openssh-3.1p1/scp.c:1179: undefined reference to `__floatdidf' > gmake: *** [scp] Error 1 > > Any ideas? > > Matt Studley > American Mathematical Society > UNIX Sys Admin "Quantum Mechanics - > mjs at ams.org The dreams that stuff is made of" > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mouring at etoh.eviladmin.org Sun May 12 09:04:03 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 11 May 2002 18:04:03 -0500 (CDT) Subject: socks5 support In-Reply-To: Message-ID: The only problem with ProxyCommand and sock{4,4a,5} is the fact that DNS is not being handled at the right time. Which is what the 4a and 5 patches are doing. Doing DNS out of band in sock 4a/5 can be a security risk. At least a bit of information leakage. Not saying that I agree with his sock5 patch. Just ProxyCommand just won't cut it unless...... I don't know the ProxyCommand code off hand, but what would be the chances that one could do a simple modification to have all DNS lookups to be passed to the 'ProxyCommand' program and let it handle such things? That would solve both problems cleanly. - Ben On Sat, 11 May 2002, Kevin Steves wrote: > On Fri, 10 May 2002, Michael Robinton wrote: > :Good luck, I sent in a patch for socks5 support back in October of last > :year and got blown out of the water by the "developers". > > This is best handled by a ProxyCommand helper. > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From michael at bizsystems.com Sun May 12 09:46:18 2002 From: michael at bizsystems.com (Michael Robinton) Date: Sat, 11 May 2002 16:46:18 -0700 (PDT) Subject: socks5 support Message-ID: > On Fri, 10 May 2002, Michael Robinton wrote: > :Good luck, I sent in a patch for socks5 support back in October of > last :year and got blown out of the water by the "developers". > > This is best handled by a ProxyCommand helper. > ProxyCommand helper does not allow you to bridge multiple socks servers since it knows nothing about the next server. i.e. to go from behind firewall A over the internet to B then behind firewall B transparently. Michael From abartlet at pcug.org.au Mon May 13 00:17:38 2002 From: abartlet at pcug.org.au (Andrew Bartlett) Date: Mon, 13 May 2002 00:17:38 +1000 Subject: Feature request: Discussion. References: Message-ID: <3CDE7982.F7D0651A@bartlett.house> Ben Lindstrom wrote: > > Considering # is a shell comment character.. No.. > > And in reality if your using URL formating you really should be > doing ssh://user at host:port which conflicts with scp, but without > knowing what you are planning.. It may not make a difference. How so? Scp would simply use the second : if the first consisted only of a number. The only issue I can see is if you wanted to transfer to a remote directory containing a : on the remote server... Andrew Bartlett -- Andrew Bartlett abartlet at pcug.org.au Manager, Authentication Subsystems, Samba Team abartlet at samba.org Student Network Administrator, Hawker College abartlet at hawkerc.net http://samba.org http://build.samba.org http://hawkerc.net From markus at openbsd.org Mon May 13 00:55:36 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 12 May 2002 16:55:36 +0200 Subject: OpenSSH server stops returning data from a server module In-Reply-To: <200204281538.RAA18321@post.webmailer.de> References: <200204101827.UAA21406@post.webmailer.de> <20020410221839.GA2529@folly> <200204281538.RAA18321@post.webmailer.de> Message-ID: <20020512145536.GA3318@folly> On Sun, Apr 28, 2002 at 05:36:47PM +0200, Norbert Sendetzky wrote: > The problem seems to be that the server module writes a lot of debug > messages to stderr and the server can handle only a certain amount. > After I changed the location where the messages are written to from > stderr to a file descriptor pointing to a real file, everything is > fine. Can someone please verify my observation? stderr handling in ssh2 has been improved in the recent snapshots. From bugzilla-daemon at mindrot.org Mon May 13 00:55:36 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 May 2002 00:55:36 +1000 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020512145536.E0C07E8FF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 patl at cag.lcs.mit.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From patl at cag.lcs.mit.edu 2002-05-13 00:55 ------- I can confirm that blowfish + ssh1 + OpenSSL 0.9.5a is still broken with this most recent patch. I suggest reopening this bug ticket or creating a new one, unless there are no plans to fix this. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Mon May 13 01:02:28 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 12 May 2002 17:02:28 +0200 Subject: SCP file corruptions In-Reply-To: References: Message-ID: <20020512150228.GB3318@folly> scp /bsd localhost:/bsd should work with a recent version of scp on both client and server. On Mon, May 06, 2002 at 12:58:02PM -0400, GATHMAN,DON (HP-Boise,ex1) wrote: > Hi, > > I apparently was asleep at the wheel using scp, and accidentally copied a > file onto itself. Scp generated an Input/Output error and did not perform > the copy. However, now the file is corrupt. Is this a but? Is there anyway > to fix the file I messed up? > > Thanks, > Don Gathman > 208.396.6675 > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From markus at openbsd.org Mon May 13 01:05:23 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 12 May 2002 17:05:23 +0200 Subject: patch: contrib/redhat/openssh.spec updates for privsep In-Reply-To: References: Message-ID: <20020512150523.GC3318@folly> On Tue, May 07, 2002 at 12:03:20AM +0300, Pekka Savola wrote: > Hello! > > Now that PrivSep stuff works for PAM too, I took the time to update > contrib/redhat/openssh.spec to create the sshd user and set up the > /var/empty dir when installing the packages. > > These have been done the Red Hat style, the uid/gif 74 is currently free > in RHL. > > The only minor issues I could think of were: > - I'm not sure if /var/empty should be owned by openssh-server package, > but rather a filesystems package or such.. Is this even LSB compliant? don't think so :) it's popa3d compliant From markus at openbsd.org Mon May 13 01:08:14 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 12 May 2002 17:08:14 +0200 Subject: [PATCH] Strip trailing . when using HostbasedUsesNameFromPacketOnly In-Reply-To: <20020508164119.B13045@ti20> References: <20020508164119.B13045@ti20> Message-ID: <20020512150814.GD3318@folly> HostbasedUsesNameFromPacketOnly is not documented and experimental only. not sure about wether we should strip the dot. On Wed, May 08, 2002 at 04:41:19PM -0400, Bill Rugolsky Jr. wrote: > The following simple patch (against openssh-3.1) moves the test for a > trailing dot in the client-supplied hostname so that it is also stripped > when using the server option HostbasedUsesNameFromPacketOnly. > > Please CC me on any replies, as I'm not subscribed to the list. > > Cheers, > > Bill Rugolsky > > --- ssh/auth2.c~ Sun Feb 24 14:14:59 2002 > +++ ssh/auth2.c Wed May 8 16:26:26 2002 > @@ -709,15 +709,15 @@ > debug2("userauth_hostbased: chost %s resolvedname %s ipaddr %s", > chost, resolvedname, ipaddr); > > + if (((len = strlen(chost)) > 0) && chost[len - 1] == '.') { > + debug2("stripping trailing dot from chost %s", chost); > + chost[len - 1] = '\0'; > + } > if (options.hostbased_uses_name_from_packet_only) { > if (auth_rhosts2(pw, cuser, chost, chost) == 0) > return 0; > lookup = chost; > } else { > - if (((len = strlen(chost)) > 0) && chost[len - 1] == '.') { > - debug2("stripping trailing dot from chost %s", chost); > - chost[len - 1] = '\0'; > - } > if (strcasecmp(resolvedname, chost) != 0) > log("userauth_hostbased mismatch: " > "client sends %s, but we resolve %s to %s", > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From markus at openbsd.org Mon May 13 01:11:29 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 12 May 2002 17:11:29 +0200 Subject: Bug report: OpenSSH 3.1p1 In-Reply-To: <3CDA0F01.6B44639F@nucleum.com> References: <3CDA0F01.6B44639F@nucleum.com> Message-ID: <20020512151129.GE3318@folly> this is how .rhosts is supposed to work. On Wed, May 08, 2002 at 11:54:09PM -0600, Royce Howland wrote: > I believe auth-rhosts.c, function check_rhosts_file(), contains a bug > that shows up when doing host-based authentication where the > client_user name is not the same as the server_user name. > > Line 76 reads: > strlcpy(userbuf, server_user, sizeof(userbuf)); > > I believe it should read: > strlcpy(userbuf, client_user, sizeof(userbuf)); > > Otherwise later in the function this test will fail: > /* Verify that user name matches. */ > if (user[0] == '@') { > if (!innetgr(user + 1, NULL, client_user, NULL)) > continue; > } else if (strcmp(user, client_user) != 0) > continue; /* Different username. */ > > Please reply directly if necessary; I'm not subscribed to this list. > > Royce Howland > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From markus at openbsd.org Mon May 13 01:15:11 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 12 May 2002 17:15:11 +0200 Subject: Feature request: Discussion. In-Reply-To: <1020979398.10028.62.camel@UberGeek> References: <1020979398.10028.62.camel@UberGeek> Message-ID: <20020512151511.GF3318@folly> On Thu, May 09, 2002 at 04:23:18PM -0500, Austin Gonyou wrote: > I was wondering if anyone would find the syntax: > ssh://someuser at host#port or even as simple as ssh://somehost#port > useful? i don't like this. scp uses rcp syntax not the (ugly) url syntax. From markus at openbsd.org Mon May 13 01:21:15 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 12 May 2002 17:21:15 +0200 Subject: Patch for SOCKS4A in OpenSsh In-Reply-To: <019f01c1f873$97ccbf70$1701000a@effugas> References: <98EC0F1ABF39D411B9E900B0D0214DF2060FB3@buckman.jax.pathtech.com> <019f01c1f873$97ccbf70$1701000a@effugas> Message-ID: <20020512152115.GG3318@folly> you know where to find my socks5 patches. On Fri, May 10, 2002 at 03:39:48PM -0700, Dan Kaminsky wrote: > Winton-- > > Excellent! Absolutely wonderful. > > I'm wondering which apps/encapsulators support 4A? This gets me around > the DNS leakage problem quite nicely. > > Incidentally, we do need SOCKS5 support -- if for no other reason, the > fact that there's *operating system* level support in OSX for SOCKS5 > redirection. So OpenSSH can become a completely transparent VPN system in > OSX w/ SOCKS5. > > Even without OSX, a decent number of apps only support SOCKS5 proxying. > > --Dan > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From steffen at pistillum.de Mon May 13 03:54:43 2002 From: steffen at pistillum.de (Steffen Stempel) Date: Sun, 12 May 2002 19:54:43 +0200 Subject: Traffic Accounting for OpenSSH 3.1pl1 Message-ID: <3CDEAC63.3000301@home.pistillum.de> Hi, I've patched OpenSSH 3.1pl1 to be able to send traffic accounting (bytes sent and received to/from the network) to the system log at the end of each session. The feature is disabled by default and can be activated by the configuration file option "accounting yes". A context diff is attached to this message for includig this feature in the source code. For any questions or comments, please send mail directly to me, because I'm not a subscriber of the openssh-unix-dev mailing lists. Regards, Steffen -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-3.1p1-accountingpatch.diff Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020512/5b7585cd/attachment.ksh From bugzilla-daemon at mindrot.org Mon May 13 11:02:18 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 May 2002 11:02:18 +1000 (EST) Subject: [Bug 230] UsePrivilegeSeparation turns off Banner. Message-ID: <20020513010218.87CB8E8EA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=230 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2002-05-13 11:02 ------- Patch committed ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon May 13 11:05:01 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 May 2002 11:05:01 +1000 (EST) Subject: [Bug 231] ssh-keygen has fatal error while updating comment in RSA1 key Message-ID: <20020513010501.C8E13E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=231 ------- Additional Comments From djm at mindrot.org 2002-05-13 11:04 ------- We can just put the call to seed_rng() above all the actions. That is safe and "future-proof" at the cost of some extraneous processing for some options which don't need it. Alternately we can just move the chance comment call to below the seed_rng call ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From kevin at atomicgears.com Mon May 13 13:31:17 2002 From: kevin at atomicgears.com (Kevin Steves) Date: Sun, 12 May 2002 20:31:17 -0700 (PDT) Subject: socks5 support In-Reply-To: Message-ID: On Sat, 11 May 2002, Michael Robinton wrote: :> This is best handled by a ProxyCommand helper. :> :ProxyCommand helper does not allow you to bridge multiple socks :servers since it knows nothing about the next server. : :i.e. to go from behind firewall A over the internet to B then behind :firewall B transparently. Wouldn't that depend on how full-featured the proxycommand program is? Below is what Sun did for Solaris 9, which I think is pretty basic. The complete man page can be found at docs.sun.com. Also, there are 2 SOCKS discussions going on I think: one for client support to connect thru SOCKS servers and another to have SOCKS5 server support for dynamic forwards. NAME ssh-socks5-proxy-connect - Secure Shell proxy for SOCKS5 SYNOPSIS /usr/lib/ssh/ssh-socks5-proxy-connect [-h socks5_proxy_host] [-p socks5_proxy_port] connect_host connect_port DESCRIPTION A proxy command for ssh(1) that uses SOCKS5 (RFC 1928). Typical use is where connections external to a network are only allowed via a socks gateway server. From tim at multitalents.net Mon May 13 13:46:08 2002 From: tim at multitalents.net (Tim Rice) Date: Sun, 12 May 2002 20:46:08 -0700 (PDT) Subject: buildpkg.sh (UsePrivilegeSeparation) In-Reply-To: <20020511193126.A7C62E881@shitei.mindrot.org> Message-ID: I was going to update buildpkg.sh to optionally support UsePrivilegeSeparation yes My question is, do package builders want the option at package build time or package install time? -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bugzilla-daemon at mindrot.org Mon May 13 15:14:24 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 May 2002 15:14:24 +1000 (EST) Subject: [Bug 234] OpenSSH does not compile on OpenBSD 3.1 Message-ID: <20020513051424.BB84DE8FF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=234 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2002-05-13 15:14 ------- Fix committed - thanks ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon May 13 15:19:42 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 May 2002 15:19:42 +1000 (EST) Subject: [Bug 232] 3.1p1 does not make Message-ID: <20020513051942.39FAFE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=232 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From djm at mindrot.org 2002-05-13 15:19 ------- *** This bug has been marked as a duplicate of 138 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon May 13 15:19:47 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 May 2002 15:19:47 +1000 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020513051947.2836EE8FF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |general_anders at hotmail.com ------- Additional Comments From djm at mindrot.org 2002-05-13 15:19 ------- *** Bug 232 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon May 13 15:30:39 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 May 2002 15:30:39 +1000 (EST) Subject: [Bug 124] Terminal hangs when data is streaming to it... Message-ID: <20020513053039.3F4E4E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=124 ------- Additional Comments From djm at mindrot.org 2002-05-13 15:30 ------- Can any of you replicate it with the most recent versions of OpenSSH & SSH.COM ssh? Also, please record large blocks of data (debug output, etc) as attachments rather than inserting them inline to the bug - it make it a fair bit easier to read. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon May 13 15:35:28 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 May 2002 15:35:28 +1000 (EST) Subject: [Bug 77] Configure Script contains /usr/local/lib /usr/local/include FLAGS Message-ID: <20020513053528.01AD1E8FF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=77 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Summary|Configure Script contains |Configure Script contains |/usr/local/lib |/usr/local/lib |/usr/local/include FLAGS |/usr/local/include FLAGS ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon May 13 15:37:45 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 May 2002 15:37:45 +1000 (EST) Subject: [Bug 41] Static compilation Message-ID: <20020513053745.60453E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=41 ------- Additional Comments From djm at mindrot.org 2002-05-13 15:37 ------- For this bug to progress, someone needs to write some autoconf tests to determine which of the getopt()-related variables are exported by libc and which we have to declare for ourselves. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon May 13 15:39:20 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 May 2002 15:39:20 +1000 (EST) Subject: [Bug 44] Can't pass KRB4 TGT on RH7.2 due to glibc mkstemp Message-ID: <20020513053920.5C623E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=44 ------- Additional Comments From djm at mindrot.org 2002-05-13 15:39 ------- Have you filed a bug in the glibc bug tracking system? BTW, how did you compile with krb4 on Redhat 7.2 without running over libdes conflicts? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon May 13 15:47:27 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 May 2002 15:47:27 +1000 (EST) Subject: [Bug 236] No setproctitle() replacement for many unices Message-ID: <20020513054727.6B60CE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=236 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon May 13 17:15:50 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 May 2002 17:15:50 +1000 (EST) Subject: [Bug 240] New: ssh fails to handle errno == EHOSTUNREACH properly Message-ID: <20020513071550.BE97AE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=240 Summary: ssh fails to handle errno == EHOSTUNREACH properly Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Miscellaneous AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: schwartz+q-bugzilla-mindrot at bio.cse.psu.edu ssh is littered with open coded checks of errno after a read or write. As a matter of good engineering, these should be consolidated into one routine, try_again(errno). The current set of checks (which are quite inconsistent) fail to include all the values of errno that signal that a retry is called for. For example, EHOSTUNREACH, is an advisory rather than an error. Currently ssh will abort a session when TCP/IP is perfectly happy to continue. Because we want ssh to be robust and reliable, this oversight should be repaired. One might argue that if write constantly returns EHOSTUNREACH then we should quit. That's reasonable, and it underscores that the current behaviour is wrong. It should indeed require many advisories before taking such action. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon May 13 19:50:24 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 13 May 2002 19:50:24 +1000 (EST) Subject: [Bug 44] Can't pass KRB4 TGT on RH7.2 due to glibc mkstemp Message-ID: <20020513095024.52F6CE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=44 ------- Additional Comments From jan.iven at cern.ch 2002-05-13 19:50 ------- the "XXXX" for glibc mkstemp behaviour is as documented in their man page ("...The last six characters of template must be XXXXXX and these are replaced with a string that makes the filename unique..."). I see no "bug" in there, but if you think that this should get reported, I will. As to the libdes problem -- we have krb4 recompiled against openssl. Mail me directly if you need the spec file/SRPM. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue May 14 00:33:37 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 14 May 2002 00:33:37 +1000 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020513143337.12431E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 ------- Additional Comments From markus at openbsd.org 2002-05-14 00:33 ------- can anyone look into ssh1+bf+old-openssl? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From michael at bizsystems.com Tue May 14 01:04:40 2002 From: michael at bizsystems.com (Michael Robinton) Date: Mon, 13 May 2002 08:04:40 -0700 (PDT) Subject: socks5 support Message-ID: >:> This is best handled by a ProxyCommand helper. >:> >:ProxyCommand helper does not allow you to bridge multiple socks >:servers since it knows nothing about the next server. >: >:i.e. to go from behind firewall A over the internet to B then behind >:firewall B transparently. > >Wouldn't that depend on how full-featured the proxycommand program is? >Below is what Sun did for Solaris 9, which I think is pretty basic. >The complete man page can be found at docs.sun.com. >Also, there are 2 SOCKS discussions going on I think: one for client >support to connect thru SOCKS servers and another to have SOCKS5 >server support for dynamic forwards. > >NAME > >ssh-socks5-proxy-connect - Secure Shell proxy for SOCKS5 > >SYNOPSIS > >/usr/lib/ssh/ssh-socks5-proxy-connect [-h socks5_proxy_host] [-p >socks5_proxy_port] connect_host connect_port > >DESCRIPTION > >A proxy command for ssh(1) that uses SOCKS5 (RFC 1928). Typical use is >where connections external to a network are only allowed via a socks >gateway server. I guess it's you point of view. I consider the above implementation to be a bit brain dead. The whole purpose of integrated socks support is to allow seamless operation and to allow a single point of configuration i.e. the socks config files. Using the proxy approach requires that each use of a proxy be individually configured which means extra work, extra room for error and extra security problems. The point can be argued to death. There is either support for socks or there is not. Personally I think it is a useful feature. Michael From markus at openbsd.org Tue May 14 01:26:38 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 13 May 2002 17:26:38 +0200 Subject: socks5 support In-Reply-To: References: Message-ID: <20020513152637.GD13654@faui02> On Mon, May 13, 2002 at 08:04:40AM -0700, Michael Robinton wrote: > Using the proxy approach requires that each use of a proxy be individually > configured which means extra work, extra room for error and extra security > problems. that's wrong, ssh passes the hostname and port. From ewheeler at kaico.com Tue May 14 01:52:58 2002 From: ewheeler at kaico.com (ewheeler at kaico.com) Date: Mon, 13 May 2002 08:52:58 -0700 (PDT) Subject: Feature request: Discussion. In-Reply-To: <20020512151511.GF3318@folly> Message-ID: I agree that we shouldn't add the 'ssh://' since we're trying to keep r* compatibility, but is there a reason that a '--url ssh://someones:password at somehoston#thisport/some/file' could/should not be added? I suppose --url could simply override the source for the scp. Ideas? --Eric On Sun, 12 May 2002, Markus Friedl wrote: > On Thu, May 09, 2002 at 04:23:18PM -0500, Austin Gonyou wrote: > > I was wondering if anyone would find the syntax: > > ssh://someuser at host#port or even as simple as ssh://somehost#port > > useful? > > i don't like this. scp uses rcp syntax not the (ugly) url syntax. > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Eric Wheeler Network Administrator KAICO 20417 SW 70th Ave. Tualatin, OR 97062 www.kaico.com Voice: 503.692.5268 From epa98 at doc.ic.ac.uk Tue May 14 02:07:11 2002 From: epa98 at doc.ic.ac.uk (Edward Avis) Date: Mon, 13 May 2002 17:07:11 +0100 (BST) Subject: Feature request: Discussion. In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 13 May 2002 ewheeler at kaico.com wrote: >but is there a reason that a >'--url ssh://someones:password at somehoston#thisport/some/file' could/should >not be added? If you do add it, the port number should be separated from the hostname by a colon, as in http. And of course writing the password in the URL should be discouraged (but ftp allows it, so might as well follow this precedent). - -- Ed Avis Finger for PGP key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE83+SxIMp73jhGogoRAgRdAKCG90VP2vicLOALgl/7gCqyCxVEggCdEZNR /p1VcAiRXNQShl6n3UQB++Q= =lvUy -----END PGP SIGNATURE----- From stephen at tgivan.com Tue May 14 02:08:44 2002 From: stephen at tgivan.com (Stephen Rasku) Date: Mon, 13 May 2002 09:08:44 -0700 (PDT) Subject: gvim hangs under ssh Message-ID: <200205131608.JAA29655@aukland.tgivan.com> I wrote: >This happens every time. I: > > 1. ssh into another machine > 2. start gvim > 3. Select another color scheme from "Edit | Color Scheme" > >At this point gvim hangs and so does the terminal that I am ssh'ed >into. I am using vim 6.1 on Solaris 7 machines. I am using: > > OpenSSH_2.9p1, SSH protocols 1.5/2.0, OpenSSL 0x0090600f > >This problem doesn't happen if I rlogin and set my DISPLAY variable >back to the client machine. Has anyone else seen this? Upgrading to ssh 3.1p1 seems to have fixed the problem. From dan at doxpara.com Tue May 14 02:16:39 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Mon, 13 May 2002 09:16:39 -0700 Subject: socks5 support References: <20020513152637.GD13654@faui02> Message-ID: <02b801c1fa99$902293d0$1701000a@effugas> Whoa people, there are two forms of SOCKS support: 1) SOCKS to get to the SSH server 2) SOCKS to get to hosts behind the SSH server In the former, the SSH client is a SOCKS client. ProxyCommand does this. In the latter, the SSH client is a SOCKS server. ProxyCommand doesn't touch this. The latter is ridiculously useful (semi-VPN style behavior becomes possible, especially on OSX with integrated OS level SOCKS). The former is also really useful for a decent set of places. The way I see it, Dynamic Forwarding (SOCKS or HTTP to direct SSH tunnels) is useful enough to justify its presence, and as long as we're going to have the understanding of those protocols integrated into the SSH client anyway, we might as well add the 5-20 lines of code to allow the SSH client to be a SOCKS client too. Save ProxyCommand for the really, really weird kind of things that I like to do :-) Markus -- send me your patches, I lost 'em (again *laughs*). --Dan From mouring at etoh.eviladmin.org Tue May 14 02:10:21 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 13 May 2002 11:10:21 -0500 (CDT) Subject: Feature request: Discussion. In-Reply-To: Message-ID: Reason not to.. 1) Adds useless bload 2) adds anonying and very poorly thought out GNU style getopts. 3) Does not provide us with anything we don't already have. - Ben On Mon, 13 May 2002 ewheeler at kaico.com wrote: > I agree that we shouldn't add the 'ssh://' since we're trying to keep r* > compatibility, but is there a reason that a > '--url ssh://someones:password at somehoston#thisport/some/file' could/should > not be added? I suppose --url could simply override the source for the > scp. Ideas? > > --Eric > > On Sun, 12 May 2002, Markus Friedl wrote: > > > On Thu, May 09, 2002 at 04:23:18PM -0500, Austin Gonyou wrote: > > > I was wondering if anyone would find the syntax: > > > ssh://someuser at host#port or even as simple as ssh://somehost#port > > > useful? > > > > i don't like this. scp uses rcp syntax not the (ugly) url syntax. > > _______________________________________________ > > openssh-unix-dev at mindrot.org mailing list > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > -- > > Eric Wheeler > Network Administrator > KAICO > 20417 SW 70th Ave. > Tualatin, OR 97062 > www.kaico.com > Voice: 503.692.5268 > > > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From robmccau at RadOnc.Duke.EDU Tue May 14 02:17:03 2002 From: robmccau at RadOnc.Duke.EDU (Rob McCauley) Date: Mon, 13 May 2002 12:17:03 -0400 (EDT) Subject: Feature request: Discussion. In-Reply-To: Message-ID: I'd say that the best reason not to add it is lack of a compelling reason *to* add it. ssh is not http. I don't see any good reason to make scp or ssh try to look like http, and I have to agree with Markus Friedl's assessment that url syntax lacks something in the aesthetics department. I'd never use it. I don't like the idea of supporting a password in the command line at all. I can ignore the url syntax, but the thoughts of enabling my users to create rsh like aliases with plaintext passwords embedded in them would be unacceptable. You have to know that given the choice, most would opt to do that rather than configure public key authentication. I just received a reply to this same message saying FTP supports passwords on the command line, so we may as well support it. I disagree. FTP supports lots of evil things. Let's support the core functionality securely. Passwords in the command line is just an invitation for Bad Things to happen. There's some enhanced risk, and I see no benefit. Rob -- ------------------------------------------------------------------------------ Rob McCauley Radiation Oncology Duke University Medical Center On Mon, 13 May 2002 ewheeler at kaico.com wrote: > I agree that we shouldn't add the 'ssh://' since we're trying to keep r* > compatibility, but is there a reason that a > '--url ssh://someones:password at somehoston#thisport/some/file' could/should > not be added? I suppose --url could simply override the source for the > scp. Ideas? From Nicolas.Williams at ubsw.com Tue May 14 02:25:30 2002 From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com) Date: Mon, 13 May 2002 12:25:30 -0400 Subject: Feature request: Discussion. Message-ID: <9403F8EE868566448AA1B70D8F783C95334EF3@NSTMC004PEX1.ubsgs.ubsgroup.net> Ultimately you can write a wrapper that implements ssh urls if you really care... Nico -- > -----Original Message----- > From: Rob McCauley [mailto:robmccau at RadOnc.Duke.EDU] > Sent: Monday, May 13, 2002 12:17 PM > To: ewheeler at kaico.com > Cc: OpenSSH Devel List > Subject: Re: Feature request: Discussion. > > > > I'd say that the best reason not to add it is lack of a > compelling reason > *to* add it. ssh is not http. I don't see any good reason > to make scp or > ssh try to look like http, and I have to agree with Markus Friedl's > assessment that url syntax lacks something in the aesthetics > department. I'd never use it. > > I don't like the idea of supporting a password in the command line at > all. I can ignore the url syntax, but the thoughts of > enabling my users > to create rsh like aliases with plaintext passwords embedded > in them would > be unacceptable. You have to know that given the choice, > most would opt > to do that rather than configure public key authentication. > > I just received a reply to this same message saying FTP > supports passwords > on the command line, so we may as well support it. I disagree. FTP > supports lots of evil things. Let's support the core functionality > securely. Passwords in the command line is just an invitation for Bad > Things to happen. There's some enhanced risk, and I see no benefit. > > Rob > > -- > -------------------------------------------------------------- > ---------------- > Rob McCauley > Radiation Oncology > Duke University Medical Center > > On Mon, 13 May 2002 ewheeler at kaico.com wrote: > > > I agree that we shouldn't add the 'ssh://' since we're > trying to keep r* > > compatibility, but is there a reason that a > > '--url > ssh://someones:password at somehoston#thisport/some/file' could/should > > not be added? I suppose --url could simply override the > source for the > > scp. Ideas? > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From ewheeler at kaico.com Tue May 14 02:39:50 2002 From: ewheeler at kaico.com (ewheeler at kaico.com) Date: Mon, 13 May 2002 09:39:50 -0700 (PDT) Subject: Feature request: Discussion. In-Reply-To: Message-ID: > I'd say that the best reason not to add it is lack of a compelling reason > *to* add it. ssh is not http. I don't see any good reason to make scp or > ssh try to look like http, and I have to agree with Markus Friedl's > assessment that url syntax lacks something in the aesthetics > department. I'd never use it. Cirtainly, ssh is not http, but neither is telnet, gopher, irc, ftp, or beer (yes, there is even a beer protocol: http://cs.eboch.com/beerRun/). The URL was defined to be protocol independant. I am no decorator so asthetics don't bother me one way or the other. The benefit I see would be to add helpers to mozilla/netscape to download files via scp. > I don't like the idea of supporting a password in the command line at > all. I can ignore the url syntax, but the thoughts of enabling my users > to create rsh like aliases with plaintext passwords embedded in them would > be unacceptable. You have to know that given the choice, most would opt > to do that rather than configure public key authentication. I agree that passwords via the command line should not be supported, and maybe that could be an option "DisableCommandLinePasswords" or some such animal to disable it site-wide. (un?)fortunately, commandline passwords *do* exist -- I saw a patch committed some time ago which would allow this, which could be scarry in it's own right: $ echo password | ssh -fd 0 someone at nowhere.com > 1) Adds useless bload Bloat? the parser for a url command would only be used with '--url' or some equivilent, and be very small in size. I don't know that you can call a url parser's code size or complexity bloated with respect to any pk based crypto algorithm. > 2) adds anonying and very poorly thought out GNU style getopts. Not required. There is no reason you could not use your own system to read in options. --url is only a suggestion; it could be -X where X is "somethign" > 3) Does not provide us with anything we don't already have. Does the current ssh or scp implentation allow you to click a link and securely download a file (hopefully after you've entered a password)? -- Eric Wheeler Network Administrator KAICO 20417 SW 70th Ave. Tualatin, OR 97062 www.kaico.com Voice: 503.692.5268 From ed at UDel.Edu Tue May 14 03:08:11 2002 From: ed at UDel.Edu (Ed Phillips) Date: Mon, 13 May 2002 13:08:11 -0400 (EDT) Subject: Feature request: Discussion. In-Reply-To: Message-ID: On Mon, 13 May 2002 ewheeler at kaico.com wrote: > Does the current ssh or scp implentation allow you to click a link and > securely download a file (hopefully after you've entered a password)? The browser implements the "click a link" feature, and the mapping of URL to actual commands or protocal connections or whatever. I can't see how you'd actually make this work in any browser you don't compile yourself (to tell it that "ssh://user at host..." means run "ssh ssh://user at host", etc.). And, if you compile it yourself, you can specify that "ssh://user at host..." means "Run `ssh user at host...'". I can't type "ssh://blah.blah.blah" into any of my browsers and make it run some command (although, I'll admit, I haven't actually tried to configure it to do so)? I could make a MIME type that is an "ssh connection" or "scp command" or whatever - and I can put the actual arguments in the "helper" configuration tho'. If you want someone to securely download a file by clicking on a link, why should we need to change ssh to accept a special URL as an argument... because the browser can only pass a verbatim URL to "helper" programs that it doesn't know about? I like the "roll your own wrapper for ssh" idea. Or you can use MIME types and configure your own behavior using the existing scp/ssh syntax. My 2 cents... Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From dschiebe at cisco.com Tue May 14 03:29:28 2002 From: dschiebe at cisco.com (Schieber, Dustin) Date: Mon, 13 May 2002 13:29:28 -0400 Subject: When will the next rev be released? Message-ID: I need the version with this bugfix: http://bugzilla.mindrot.org/show_bug.cgi?id=182 . ("ssh should still force SIGCHLD to be SIG_DFL when calling ssh-rand-helper") It is apparently in the next release. Anyone have an estimate of when it will be released? thx, -das From mouring at etoh.eviladmin.org Tue May 14 04:23:30 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 13 May 2002 13:23:30 -0500 (CDT) Subject: Feature request: Discussion. In-Reply-To: Message-ID: On Mon, 13 May 2002, Ed Phillips wrote: > On Mon, 13 May 2002 ewheeler at kaico.com wrote: > > > Does the current ssh or scp implentation allow you to click a link and > > securely download a file (hopefully after you've entered a password)? > > The browser implements the "click a link" feature, and the mapping of URL > to actual commands or protocal connections or whatever. I can't see how > you'd actually make this work in any browser you don't compile yourself > (to tell it that "ssh://user at host..." means run "ssh ssh://user at host", > etc.). And, if you compile it yourself, you can specify that > "ssh://user at host..." means "Run `ssh user at host...'". I can't type > "ssh://blah.blah.blah" into any of my browsers and make it run some > command (although, I'll admit, I haven't actually tried to configure it to > do so)? I could make a MIME type that is an "ssh connection" or "scp > command" or whatever - and I can put the actual arguments in the "helper" > configuration tho'. > > If you want someone to securely download a file by clicking on a link, why > should we need to change ssh to accept a special URL as an argument... > because the browser can only pass a verbatim URL to "helper" programs that > it doesn't know about? > > I like the "roll your own wrapper for ssh" idea. Or you can use MIME > types and configure your own behavior using the existing scp/ssh syntax. > > My 2 cents... > Or use SSL which is what it was designed for.. 'Encrypted communications' =) - Ben From markus at openbsd.org Tue May 14 07:08:39 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 13 May 2002 23:08:39 +0200 Subject: socks5 support In-Reply-To: <02b801c1fa99$902293d0$1701000a@effugas> References: <20020513152637.GD13654@faui02> <02b801c1fa99$902293d0$1701000a@effugas> Message-ID: <20020513210839.GA12684@folly> On Mon, May 13, 2002 at 09:16:39AM -0700, Dan Kaminsky wrote: > The way I see it, Dynamic Forwarding (SOCKS or HTTP to direct SSH tunnels) diffs for Dynamic Forwarding with SOCKS5 are in the cvs history. From djm at mindrot.org Tue May 14 08:27:16 2002 From: djm at mindrot.org (Damien Miller) Date: Tue, 14 May 2002 08:27:16 +1000 (EST) Subject: socks5 support In-Reply-To: Message-ID: On Mon, 13 May 2002, Michael Robinton wrote: > I guess it's you point of view. I consider the above implementation to be > a bit brain dead. The whole purpose of integrated socks support is to > allow seamless operation and to allow a single point of configuration i.e. > the socks config files. So make a proxy which read the socks config file. -d From djm at mindrot.org Tue May 14 08:29:10 2002 From: djm at mindrot.org (Damien Miller) Date: Tue, 14 May 2002 08:29:10 +1000 (EST) Subject: Feature request: Discussion. In-Reply-To: Message-ID: On Mon, 13 May 2002, ewheeler at kaico.com wrote: > > > I'd say that the best reason not to add it is lack of a compelling reason > > *to* add it. ssh is not http. I don't see any good reason to make scp or > > ssh try to look like http, and I have to agree with Markus Friedl's > > assessment that url syntax lacks something in the aesthetics > > department. I'd never use it. > > Cirtainly, ssh is not http, but neither is telnet, gopher, irc, > ftp, or beer (yes, there is even a beer protocol: > http://cs.eboch.com/beerRun/). The URL was defined to be protocol > independant. > > I am no decorator so asthetics don't bother me one way or the other. The > benefit I see would be to add helpers to mozilla/netscape to download > files via scp. You don't need to teach ssh to use URLs to do this - just write a small wrapper script. -d From bugzilla-daemon at mindrot.org Tue May 14 11:26:58 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 14 May 2002 11:26:58 +1000 (EST) Subject: [Bug 241] New: When I kill scp, the underlying ssh child process remains alive Message-ID: <20020514012658.E4BD3E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=241 Summary: When I kill scp, the underlying ssh child process remains alive Product: Portable OpenSSH Version: 3.1p1 Platform: All OS/Version: Linux Status: NEW Severity: minor Priority: P3 Component: scp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: esb at hawaii.edu I am trying to use scp in an automated script, and would like to be able to kill it (automatically) if there is a timeout. However, when I kill the scp process, the ssh process that scp created continues to run. This causes problems with my automated system -- the ssh processes take a long time to time out or complete, and sometimes complete inappropriately. Fix: I enclose some diffs that work on linux. I have only caught SIGTERM -- a more complete implementation might catch other signals as well (maybe at least SIGINT). The /*esb*/ comments are for my reference only and may be removed -- I do not need to be credited. The version openssh-3.1p1x is the one with my changes. An acknowledgement that this message has reached the correct individual(s) would be appreciated (your listed address, openssh at openssh.com, does not appear to accept mail). Many thanks for your excellent software! edo -- esb at hawaii.edu edo at maru 36-> diff -c openssh-3.1p1*/scp.c *** openssh-3.1p1/scp.c Tue Mar 5 08:59:45 2002 --- openssh-3.1p1x/scp.c Sat May 4 15:42:50 2002 *************** *** 133,138 **** --- 133,142 ---- /* This is the program to execute for the secured connection. ("ssh" or -S) */ char *ssh_program = _PATH_SSH_PROGRAM; + /* esb: added the child PID so we can kill it if we get killed */ + pid_t childpid; + static void killchild(int signo); + /* * This function executes the given command as the specified user on the * given host. This returns < 0 if execution fails, and >= 0 otherwise. This *************** *** 167,173 **** close(reserved[1]); /* For a child to execute the command on the remote host using ssh. */ ! if (fork() == 0) { /* Child. */ close(pin[1]); close(pout[0]); --- 171,178 ---- close(reserved[1]); /* For a child to execute the command on the remote host using ssh. */ ! /* esb */ ! if ((childpid = fork()) == 0) { /* Child. */ close(pin[1]); close(pout[0]); *************** *** 191,196 **** --- 196,203 ---- *fdout = pin[1]; close(pout[1]); *fdin = pout[0]; + /* esb */ + (void) signal(SIGTERM, killchild); return 0; } *************** *** 1086,1091 **** --- 1093,1105 ---- signal(SIGALRM, updateprogressmeter); alarm(PROGRESSTIME); errno = save_errno; + } + + static void + killchild(int signo) + { + kill (childpid, signo); + _exit(1); } static int ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue May 14 13:09:52 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 14 May 2002 13:09:52 +1000 (EST) Subject: [Bug 242] New: cipher.c doesn't compile in openssh-3.1p1 (i386-solaris2.8-gcc) Message-ID: <20020514030952.BDCB3E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=242 Summary: cipher.c doesn't compile in openssh-3.1p1 (i386- solaris2.8-gcc) Product: Portable OpenSSH Version: 3.1p1 Platform: ix86 OS/Version: Solaris Status: NEW Severity: minor Priority: P3 Component: Miscellaneous AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: boyland at cs.uwm.edu Using gcc on Solaris 8 for x86: (only option to configure: --with-pam) (THis is with latest: openssh-3.1p1. openssh-3.0.2p1 compiles and works fine.) (cd openbsd-compat && make) gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/usr/local/ssl/include -I/usr/local/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/var/run\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c cipher.c cipher.c: In function `cipher_init': cipher.c:200: void value not ignored as it ought to be cipher.c:206: warning: implicit declaration of function `EVP_CIPHER_CTX_set_key_length' cipher.c:210: void value not ignored as it ought to be cipher.c: In function `cipher_crypt': cipher.c:220: void value not ignored as it ought to be cipher.c: In function `cipher_cleanup': cipher.c:227: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_init': cipher.c:280: warning: assignment from incompatible pointer type cipher.c:299: void value not ignored as it ought to be cipher.c:300: void value not ignored as it ought to be cipher.c:301: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cbc': cipher.c:314: warning: assignment from incompatible pointer type cipher.c:318: void value not ignored as it ought to be cipher.c:319: void value not ignored as it ought to be cipher.c:320: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cleanup': cipher.c:329: warning: assignment from incompatible pointer type cipher.c: In function `evp_ssh1_3des': cipher.c:346: warning: assignment from incompatible pointer type cipher.c:347: warning: assignment from incompatible pointer type cipher.c:348: warning: assignment from incompatible pointer type cipher.c:349: structure has no member named `flags' cipher.c:349: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:349: (Each undeclared identifier is reported only once cipher.c:349: for each function it appears in.) cipher.c:349: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c: In function `evp_ssh1_bf': cipher.c:392: warning: assignment from incompatible pointer type cipher.c:394: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_init': cipher.c:413: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cbc': cipher.c:440: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cleanup': cipher.c:477: warning: assignment from incompatible pointer type cipher.c: In function `evp_rijndael': cipher.c:494: warning: assignment from incompatible pointer type cipher.c:495: warning: assignment from incompatible pointer type cipher.c:496: warning: assignment from incompatible pointer type cipher.c:497: structure has no member named `flags' cipher.c:497: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:497: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c:498: `EVP_CIPH_ALWAYS_CALL_INIT' undeclared (first use in this function) *** Error code 1 make: Fatal error: Command failed for target `cipher.o' ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue May 14 13:13:05 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 14 May 2002 13:13:05 +1000 (EST) Subject: [Bug 242] cipher.c doesn't compile in openssh-3.1p1 (i386-solaris2.8-gcc) Message-ID: <20020514031305.2615CE8FF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=242 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From djm at mindrot.org 2002-05-14 13:13 ------- *** This bug has been marked as a duplicate of 138 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue May 14 13:13:10 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 14 May 2002 13:13:10 +1000 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020514031310.49B0BE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |boyland at cs.uwm.edu ------- Additional Comments From djm at mindrot.org 2002-05-14 13:13 ------- *** Bug 242 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From janfrode at parallab.uib.no Wed May 15 00:06:16 2002 From: janfrode at parallab.uib.no (Jan-Frode Myklebust) Date: Tue, 14 May 2002 16:06:16 +0200 Subject: AIX capabilities not set Message-ID: <20020514140616.GA18432@ii.uib.no> Hi, we're in the process of setting up large-page support on IBM regattas, but for large-page support the users have to have a set of extra capabilities (CAP_BYPASS_RAC_VMM,CAP_PROPAGATE). This are configured on a per user basis by listing which capability each user have in /etc/security/user. Unfortunately they don't get set when the users log in via OpenSSH (3.1p1). Does anybody know what changes are needed for OpenSSH to support this feature of AIX? I imagine it could be achieved by using 'UseLogin' (but I'd prefer not to, and anyway it fails when I try to enable it). -jf From niladrida at yahoo.com Wed May 15 00:14:16 2002 From: niladrida at yahoo.com (niladri bhandari) Date: Tue, 14 May 2002 07:14:16 -0700 (PDT) Subject: Encription in unix and decryption in windows Message-ID: <20020514141416.69794.qmail@web14803.mail.yahoo.com> Dear all, First we have to encrypt a file in solaris. That file i have to decrypt in windows. But problem is in byte allocation. If I write this way encContent[0] = buf[3]; encContent[1] = buf[2]; encContent[2] = buf[1]; encContent[3] = buf[0]; encContent[4] = buf[7]; encContent[5] = buf[6]; encContent[6] = buf[5]; encContent[7] = buf[4] it will work but in windows side i have to change again position. I am using blowfish. If you have any idea kindly help me. Regards Niladri __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From markus at openbsd.org Wed May 15 05:26:58 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 14 May 2002 21:26:58 +0200 Subject: bug in openssh sftp-server (fwd) Message-ID: <20020514192658.GB4248@folly> what is this about ? -------------- next part -------------- An embedded message was scrubbed... From: "Thomas Baumann" Subject: bug in openssh sftp-server Date: Sun, 28 Apr 2002 20:40:48 +0200 Size: 5441 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020514/6f32f7ac/attachment.mht From dcole at keysoftsys.com Wed May 15 05:22:54 2002 From: dcole at keysoftsys.com (Darren Cole) Date: Tue, 14 May 2002 12:22:54 -0700 Subject: trusted hpux 1026 hang on exit References: Message-ID: <004f01c1fb7c$d12fece0$9b78a8c0@oedserver> As some of you know I have working on getting openssh running on trusted hpux. Thanks for all your help, and accepting most of the patch I have sent in. I am still having one problem. Hang on exit. I can login into the machine, and immediately type exit. This results in a hang everytime. In my patch I had two lines that solved the problem, unfortunately these lines can cause data watch (which was why those lines were not accepted). Looking at the code, it appears to me wait_until_can_do_something in serverloop.c expects to have the master pty returned for read from the select when all of the slaves are closed. Is this correct, or is something else supposed to be happening? This does not happen for /dev/ptym devices, though it will work from /dev/ptmx. Then again /dev/ptmx doesn't work with login. Using lsof and debug messages I can see all slaves of the master pty closed, but not the master pty. This seems like it may be a bug in hpux, but not having enough experience with pty's I don't know for sure. Any ideas on where to look, or acceptable work arounds? Darren dcole at keysoftsys.com From Nicolas.Williams at ubsw.com Wed May 15 05:38:15 2002 From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com) Date: Tue, 14 May 2002 15:38:15 -0400 Subject: bug in openssh sftp-server (fwd) Message-ID: <9403F8EE868566448AA1B70D8F783C95334EFC@NSTMC004PEX1.ubsgs.ubsgroup.net> Whoever wrote the report you attached failed to understand Unix permissions. You know: - You can delete files you does not own if you have write permissions to the containing directory and either you own the directory or the directory lacks the +t bit. - You can't delete files you own if you lack write permission for the containing directory (even if you own it, unless you're root). - etc... Cheers, Nico -- > -----Original Message----- > From: Markus Friedl [mailto:markus at openbsd.org] > Sent: Tuesday, May 14, 2002 3:27 PM > To: openssh-unix-dev at mindrot.org > Subject: bug in openssh sftp-server (fwd) > > > what is this about ? > Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From advax at triumf.ca Wed May 15 10:12:40 2002 From: advax at triumf.ca (Andrew Daviel) Date: Tue, 14 May 2002 17:12:40 -0700 (PDT) Subject: /etc/usertty and SSH login Message-ID: I want to set up a machine which has an account with no password that can only be used locally, i.e. you cannot login over the network. The machine is in a room which is normally locked. It needs access to the network for videoconferencing, and this seemed a reasonable way to do things rather than putting passwords on post-it notes or Web pages. This is on a PC running RedHat Linux (7.0) I thought I had this working by specifying an entry in /etc/usertty - I could login from the console, but using ssh got a password challenge. When I tried to set it up on another machine I found that any non-null string would work as a password logging in with ssh, and in fact that I could login from other virtual consoles than the one I had listed. I see that I can specify DenyUsers in sshd_config, which gives the effect I want (since telnet, rlogin etc. are disabled). But I wondered what was going on. Hmm, if PermitEmptyPasswords is set to yes, then I can login using ssh with no password. With it set to no, sshd wants a password but it is ignored. /etc/usertty is mentioned in the manpage and info page for "login", but I can not see it in the binary nor see that it is even being accessed so I wonder what gives (I know this isn't really an openssh question) -- Andrew Daviel, TRIUMF, Canada Tel. +1 (604) 222-7376 security at triumf.ca From bugzilla-daemon at mindrot.org Wed May 15 20:16:42 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 15 May 2002 20:16:42 +1000 (EST) Subject: [Bug 243] New: fatal: buffer_get Message-ID: <20020515101642.5F2A6E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=243 Summary: fatal: buffer_get Product: Portable OpenSSH Version: 3.0.1p1 Platform: Sparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: marco at linuxpro.nl After succesfull compilation sshd started normally. Whenever a loginattemt is made the system log shows: May 15 11:56:18 sol01 sshd[14069]: [ID 800047 auth.crit] fatal: buffer_get: trying to get more bytes 129 than in buffer 39 Installation of the Solaris packages returns the same problem ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed May 15 21:17:57 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 15 May 2002 21:17:57 +1000 (EST) Subject: [Bug 243] fatal: buffer_get Message-ID: <20020515111757.6EBA4E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=243 ------- Additional Comments From markus at openbsd.org 2002-05-15 21:17 ------- could you please provide full debugging output from the server and information on what authentication methods are tried? when does this happen? it looks like you have malformed entries in .ssh/authorized_keys ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From lars at nocrew.org Thu May 16 01:06:57 2002 From: lars at nocrew.org (Lars Brinkhoff) Date: 15 May 2002 17:06:57 +0200 Subject: Support for non-8-bit char? Message-ID: <85ptzxa1ri.fsf@junk.nocrew.org> Hello, Would you consider a port to a machine that doesn't have an 8-bit char type? (On this machine, char is 9 bits, short is 18s bit, and int is 36 bits.) Please CC me, as I'm not on the list. Best regards, Lars From bugzilla-daemon at mindrot.org Thu May 16 03:03:17 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 16 May 2002 03:03:17 +1000 (EST) Subject: [Bug 244] New: Remote port forwarding on solaris 8x86 doesn't work Message-ID: <20020515170317.39AFEE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=244 Summary: Remote port forwarding on solaris 8x86 doesn't work Product: Portable OpenSSH Version: 3.1p1 Platform: ix86 OS/Version: Solaris Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dvit at addition.pt ssh deamon on solaris 8 cannot assign any port. I've tried localhost and gateway ports; I've tried low medium and high ports. The error is always the same: netstat -na doesn't list the LISTEN; ...... sshd[16194]: [ID 800047 auth.error] error: bind: Cannot assign requested address ...... sshd[16194]: [ID 800047 auth.error] error: channel_setup_fwd_listener: cannot listen to port: 4312 ...... sshd[16214]: [ID 800047 auth.error] error: bind: Cannot assign requested address ...... sshd[16214]: [ID 800047 auth.error] error: channel_setup_fwd_listener: cannot listen to port: 40312 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From aman_57 at hotmail.com Thu May 16 06:45:41 2002 From: aman_57 at hotmail.com (Amandeep Singh) Date: Wed, 15 May 2002 20:45:41 +0000 Subject: static h in detect_attack() Message-ID: Hi All, Did anybody ever had problems created by static h in function detect_attack() in deattack.c? In our system which is based on pSOS OS, this static h is causing a crash, because after closing first ssh session, it pSOS system is allocating same memory to another ssh session and this static h is overwriting that memory. I would appreciate if you know why h is statically allocated. detect_attack is used to check crc32 compensation attack. Thanks, Aman _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From austin at coremetrics.com Thu May 16 07:35:14 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 15 May 2002 16:35:14 -0500 Subject: Curious about final KRB5/GSSAPI patch inclusion. Message-ID: <1021498514.8037.8.camel@UberGeek> What is the target version for all the KRB5 bits to be in place. I know there is very much in place right now, but I remember someone mentioning there was just a GSSAPI/MITKRB5 patch being waited for. TIA. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "One ought never to turn one's back on a threatened danger and try to run away from it. If you do that, you will double the danger. But if you meet it promptly and without flinching, you will reduce the danger by half." Sir Winston Churchill -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020515/9aa3a4e7/attachment.bin From mouring at etoh.eviladmin.org Thu May 16 07:43:47 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 15 May 2002 16:43:47 -0500 (CDT) Subject: static h in detect_attack() In-Reply-To: Message-ID: From muhammad at uac.edu.au Thu May 16 08:57:20 2002 From: muhammad at uac.edu.au (Muhammad Mughal) Date: Thu, 16 May 2002 08:57:20 +1000 (EST) Subject: ssh3 with ssh1 Message-ID: On Solaris 8, I have ssh 3.1.0 and on other box Sol 7 I have 1.2.26 (min version for comtable with ssh 3), I checked also /etc/ssh2/sshd2_config file ## SSH1 compatibility # Ssh1Compatibility # Sshd1Path Message-ID: Not sure how this affects us. Looks like your using SSH Corp's 3.1.0 and 1.2.26 programs. - Ben On Thu, 16 May 2002, Muhammad Mughal wrote: > > On Solaris 8, I have ssh 3.1.0 and on other box Sol 7 I have 1.2.26 (min > version for comtable with ssh 3), I checked also /etc/ssh2/sshd2_config > file > > ## SSH1 compatibility > # Ssh1Compatibility > # Sshd1Path > 2) generate key for ssh3 # ssh-keygen2 -P /etc/ssh2/hostkey > and add hostkey.pub in ssh1 authorized_keys file. > From ssh3 machine > > 3 )xxx#ssh -v yyy > debug: > SshAppCommon/sshappcommon.c:133/ssh_app_get_global_regex_context: > Allocating > global SshRegex context. > debug: SshConfig/sshconfig.c:2232/ssh2_parse_config: Unable to open > //.ssh2/ssh2_config > debug: Connecting to harmugi, port 22... (SOCKS not used) > ssh: FATAL: Connecting to harmugi failed: No address associated to the > name > ######################################################################### > My objective is connect from ssh3 machine to ssh1 machine as root and > without asking password ie xxx#ssh yyy > yyy# > > Any body can help me to sort out this problem or point me to right > direction. > > Rgeards > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From aman_57 at hotmail.com Thu May 16 12:27:34 2002 From: aman_57 at hotmail.com (Amandeep Singh) Date: Thu, 16 May 2002 02:27:34 +0000 Subject: static h in detect_attack() Message-ID: Thanks Ben. The crash only happens if I close the first session. OS reallocates memory allocated to hash table to new session thinking that memory is no longer in use. But if this routine is being called from multiple tasks, should this allocate static memory? Do you know if there is any other version of this routine that is not using static h? Thanks, Aman >From: Ben Lindstrom >To: Amandeep Singh >CC: openssh-unix-dev at mindrot.org >Subject: Re: static h in detect_attack() >Date: Wed, 15 May 2002 16:43:47 -0500 (CDT) > > >From the looks of the code the first pass initializes the hash table and >each pass afterwards looks to see if the hash table has grown. > >If pSOS OS is having issues I'd question your compiler or OS for >reallocating memory that should be tagged as used. > >- Ben > >On Wed, 15 May 2002, Amandeep Singh wrote: > > > Hi All, > > > > Did anybody ever had problems created by static h in function > > detect_attack() in deattack.c? In our system which is based on pSOS OS, >this > > static h is causing a crash, because after closing first ssh session, it > > pSOS system is allocating same memory to another ssh session and this >static > > h is overwriting that memory. > > > > I would appreciate if you know why h is statically allocated. >detect_attack > > is used to check crc32 compensation attack. > > Thanks, > > Aman > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > _______________________________________________ > > openssh-unix-dev at mindrot.org mailing list > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > Amandeep Singh * Email:aman_57 at hotmail.com * * * * Life is a mystery, unfolds it! * ** * * * * * _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From djm at mindrot.org Thu May 16 13:03:04 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 16 May 2002 13:03:04 +1000 (EST) Subject: Curious about final KRB5/GSSAPI patch inclusion. In-Reply-To: <1021498514.8037.8.camel@UberGeek> Message-ID: On 15 May 2002, Austin Gonyou wrote: > What is the target version for all the KRB5 bits to be in place. I know > there is very much in place right now, but I remember someone mentioning > there was just a GSSAPI/MITKRB5 patch being waited for. The GSSAPI patch has not been included - it is based on a protocol spec which seems to be still in flux. -d From muhammad at uac.edu.au Thu May 16 14:34:43 2002 From: muhammad at uac.edu.au (Muhammad Mughal) Date: Thu, 16 May 2002 14:34:43 +1000 (EST) Subject: ssh3 with ssh1 In-Reply-To: Message-ID: I figured out some config hitches. Now I am getting Received signal 11. (no core) xxx=ssh 3 yyy=ssh 1..2.26 xxx#ssh -v yyy debug: SshAppCommon/sshappcommon.c:133/ssh_app_get_global_regex_context: Allocating global SshRegex context. debug: SshConfig/sshconfig.c:2232/ssh2_parse_config: Unable to open //.ssh2/ssh2_config debug: Connecting to harumagi, port 22... (SOCKS not used) debug: Ssh2/ssh2.c:1977/main: Entering event loop. debug: Ssh2Client/sshclient.c:1403/ssh_client_wrap: Creating transport protocol. debug: SshAuthMethodClient/sshauthmethodc.c:85/ssh_client_authentication_initialize: Added "hostbased" to usable methods. debug: SshAuthMethodClient/sshauthmethodc.c:85/ssh_client_authentication_initialize: Added "publickey" to usable methods. debug: SshAuthMethodClient/sshauthmethodc.c:85/ssh_client_authentication_initialize: Added "password" to usable methods. debug: Ssh2Client/sshclient.c:1444/ssh_client_wrap: Creating userauth protocol. debug: client supports 3 auth methods: 'hostbased,publickey,password' debug: Ssh2Common/sshcommon.c:560/ssh_common_wrap: local ip = 192.168.205.176, local port = 52254 debug: Ssh2Common/sshcommon.c:562/ssh_common_wrap: remote ip = 192.168.205.102, remote port = 22 debug: SshConnection/sshconn.c:1930/ssh_conn_wrap: Wrapping... debug: Remote version: SSH-1.5-1.2.26 warning: Remote server talks SSH-1.5 protocol. Received signal 11. (no core) ############################################################# Help in this regard is apppreciated Thanks On Thu, 16 May 2002, Muhammad Mughal wrote: > > On Solaris 8, I have ssh 3.1.0 and on other box Sol 7 I have 1.2.26 (min > version for comtable with ssh 3), I checked also /etc/ssh2/sshd2_config > file > > ## SSH1 compatibility > # Ssh1Compatibility > # Sshd1Path > 2) generate key for ssh3 # ssh-keygen2 -P /etc/ssh2/hostkey > and add hostkey.pub in ssh1 authorized_keys file. > >From ssh3 machine > > 3 )xxx#ssh -v yyy > debug: > SshAppCommon/sshappcommon.c:133/ssh_app_get_global_regex_context: > Allocating > global SshRegex context. > debug: SshConfig/sshconfig.c:2232/ssh2_parse_config: Unable to open > //.ssh2/ssh2_config > debug: Connecting to harmugi, port 22... (SOCKS not used) > ssh: FATAL: Connecting to harmugi failed: No address associated to the > name > ######################################################################### > My objective is connect from ssh3 machine to ssh1 machine as root and > without asking password ie xxx#ssh yyy > yyy# > > Any body can help me to sort out this problem or point me to right > direction. > > Rgeards > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From GILBERT.R.LOOMIS at saic.com Thu May 16 23:23:40 2002 From: GILBERT.R.LOOMIS at saic.com (Loomis, Rip) Date: Thu, 16 May 2002 09:23:40 -0400 Subject: ssh3 with ssh1 Message-ID: <3C1E3607B37295439F7C409EFBA08E680E2B2F@US-Columbia-CIST.mail.saic.com> Not only is Ben absolutely correct that your questions are going to the wrong list (please try ssh.com for support on these products), but: - SSH.com 1.2.26 is not suitable for use on the Internet, because of the CRC32 vulnerability. See http://www.ssh.com/products/ssh/advisories/ssh1_crc-32.cfm for info on getting 1.2.32 or later if you really need/want to run the SSH.com commercial version. - To the best of my knowledge, and what little I can find on the SSH.com site without downloading new software, SSH 2.x and 3.x don't implement the SSH1 protocol, so they're not interoperable with 1.2.26 (where did you get the information that 1.2.26 was interoperable with SSH.com 3.x?) - The error you received > > ssh: FATAL: Connecting to harmugi failed: No address > associated to the > > name doesn't look to me like a problem in any ssh binaries, but in your network config. (Ah, looking now at your later message you seem to have gotten that sorted...but it looks as though you're still running into protocol incompatibilities as mentioned above.) Please feel free to contact an appropriate list for help... or check out www.openssh.org for info on source code that I think is a better solution. Contact me off-list if you would like info on pre-compiled OpenSSH packages for Solaris 7 and 8 that I use on a regular basis. -- Rip Loomis Senior Systems Security Engineer, SAIC Secure Business Solutions Brainbench MVP for Internet Security - http://www.brainbench.com > -----Original Message----- > From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org] > Sent: Wednesday, 15 May, 2002 18:26 > To: Muhammad Mughal > Cc: openssh-unix-dev at mindrot.org > Subject: Re: ssh3 with ssh1 > > > > Not sure how this affects us. Looks like your using SSH > Corp's 3.1.0 and > 1.2.26 programs. > > - Ben > > On Thu, 16 May 2002, Muhammad Mughal wrote: > > > > > On Solaris 8, I have ssh 3.1.0 and on other box Sol 7 I > have 1.2.26 (min > > version for comtable with ssh 3), ... > From Nicolas.Williams at ubsw.com Thu May 16 23:50:45 2002 From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com) Date: Thu, 16 May 2002 09:50:45 -0400 Subject: Curious about final KRB5/GSSAPI patch inclusion. Message-ID: <9403F8EE868566448AA1B70D8F783C95334F09@NSTMC004PEX1.ubsgs.ubsgroup.net> All of the SSHv2 specs have been in flux for most of the history of most SSHv2 implementations. Cheers, Nico -- > -----Original Message----- > From: Damien Miller [mailto:djm at mindrot.org] > Sent: Wednesday, May 15, 2002 11:03 PM > To: Austin Gonyou > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Curious about final KRB5/GSSAPI patch inclusion. > > > On 15 May 2002, Austin Gonyou wrote: > > > What is the target version for all the KRB5 bits to be in > place. I know > > there is very much in place right now, but I remember > someone mentioning > > there was just a GSSAPI/MITKRB5 patch being waited for. > > The GSSAPI patch has not been included - it is based on a > protocol spec > which seems to be still in flux. > > -d > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Douglas.Chimento at FMR.COM Fri May 17 06:32:11 2002 From: Douglas.Chimento at FMR.COM (Chimento, Douglas) Date: Thu, 16 May 2002 16:32:11 -0400 Subject: uidswap Message-ID: <13619E2D7C7ED748ADD005E8D6C748F3A7837C@MSGBOS684NTS.fmr.com> All, Could someone explain the purpose of the uidswap functions with respect to ssh ( the client ). From what I gathered , ssh installs as setuid root and swaps ids when reading potential key files that may be read only by root. Also , I think when binding to a privileged port ssh swaps id. Is that so? What are the consequnences if you do not install ssh setuid root? ( As far I as know no uid swaping occurs ) Thanks Doug Chimento From austin at coremetrics.com Fri May 17 07:04:52 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 16 May 2002 16:04:52 -0500 Subject: Curious about final KRB5/GSSAPI patch inclusion. In-Reply-To: References: Message-ID: <1021583092.8629.0.camel@UberGeek> Darn it....most of the krb5 code is there already. :( Should it be removed, or is the plan to wait till flux is at a minimum or no longer, and go ahead anyway? On Wed, 2002-05-15 at 22:03, Damien Miller wrote: > On 15 May 2002, Austin Gonyou wrote: > > > What is the target version for all the KRB5 bits to be in place. I > know > > there is very much in place right now, but I remember someone > mentioning > > there was just a GSSAPI/MITKRB5 patch being waited for. > > The GSSAPI patch has not been included - it is based on a protocol > spec > which seems to be still in flux. > > -d -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "One ought never to turn one's back on a threatened danger and try to run away from it. If you do that, you will double the danger. But if you meet it promptly and without flinching, you will reduce the danger by half." Sir Winston Churchill -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020516/09432330/attachment.bin From Markus_Friedl at genua.de Fri May 17 08:36:22 2002 From: Markus_Friedl at genua.de (Markus Friedl) Date: Fri, 17 May 2002 00:36:22 +0200 Subject: OpenSSH 3.2.2 released Message-ID: <20020516223622.GA12334@muamat> OpenSSH 3.2.2 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support and encouragement. Security Changes: ================= - fixed buffer overflow in Kerberos/AFS token passing - fixed overflow in Kerberos client code - sshd no longer auto-enables Kerberos/AFS - experimental support for privilege separation, see UsePrivilegeSeparation in sshd(8) and http://www.citi.umich.edu/u/provos/ssh/privsep.html for more information. - only accept RSA keys of size SSH_RSA_MINIMUM_MODULUS_SIZE (768) or larger Other Changes: ============== - improved smartcard support (including support for OpenSC, see www.opensc.org) - improved Kerberos support (including support for MIT-Kerberos V) - fixed stderr handling in protocol v2 - client reports failure if -R style TCP forwarding fails in protocol v2 - support configuration of TCP forwarding during interactive sessions (~C) - improved support for older sftp servers - improved support for importing old DSA keys (from ssh.com software). - client side suport for PASSWD_CHANGEREQ in protocol v2 - fixed waitpid race conditions - record correct lastlogin time Reporting Bugs: =============== - please read http://www.openssh.com/report.html and http://bugzilla.mindrot.org/ OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller and Ben Lindstrom. From markus at openbsd.org Fri May 17 09:17:34 2002 From: markus at openbsd.org (Markus Friedl) Date: Fri, 17 May 2002 01:17:34 +0200 Subject: uidswap In-Reply-To: <13619E2D7C7ED748ADD005E8D6C748F3A7837C@MSGBOS684NTS.fmr.com> References: <13619E2D7C7ED748ADD005E8D6C748F3A7837C@MSGBOS684NTS.fmr.com> Message-ID: <20020516231734.GB22312@folly> On Thu, May 16, 2002 at 04:32:11PM -0400, Chimento, Douglas wrote: > What are the consequnences if you do not install ssh setuid > root? ( As far I as know no uid swaping occurs ) hostbased authentication won't work. From bugzilla-daemon at mindrot.org Fri May 17 14:03:12 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 17 May 2002 14:03:12 +1000 (EST) Subject: [Bug 245] New: SSH can not log out under Solaris 2.6 Message-ID: <20020517040312.3D013E8FF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=245 Summary: SSH can not log out under Solaris 2.6 Product: Portable OpenSSH Version: -current Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: critical Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: bfriesen at simple.dallas.tx.us Using the recently announced OpenSSH 3.2.2p1 release package under SPARC Solaris 2.6, built using gcc 3.1, ssh hangs when the user types 'exit' in the remote shell. This message is recorded to /var/adm/messages: sshd[18076]: error: open /dev/tty failed - could not set controlling tty: No such device or address OpenSSH 3.1p1 built using the same compiler works fine. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From kongar at tsrsb.org.tr Fri May 17 16:00:38 2002 From: kongar at tsrsb.org.tr (Kagan Kongar) Date: Fri, 17 May 2002 09:00:38 +0300 Subject: erroneous reporting of md5 usage, openssh-3.2.2p1 Message-ID: <20020517090038.4248252b.kongar@tsrsb.org.tr> Talking about openssh-3.2.2p1 The configure script erroneously reporting the md5-password status. The script, when activated with "--with-md5-passwords" correctly sets the config.h but reporting "MD5 password support: no" Seems that is due to a bug in configure.ac, line 2026 Kind regards, Kagan Kongar From MPak at dotsconnect.com Fri May 17 16:10:20 2002 From: MPak at dotsconnect.com (MPak at dotsconnect.com) Date: Fri, 17 May 2002 02:10:20 -0400 Subject: SSH and .exrc of vi Message-ID: I am trying to use "~/.exrc" file to customize vi sessions. The file is properly configured: I can telnet or establish a serial terminal session to the server and I can use my customizations when I invoke vi. Still when I use vi with ssh sessions, the mappings in the .exrc file are not working. What part am I missing here? Any help will be greatly appreciated. Thanks. Mesut Pak From bugzilla-daemon at mindrot.org Fri May 17 16:48:21 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 17 May 2002 16:48:21 +1000 (EST) Subject: [Bug 246] New: md5_crypt conflict fails Message-ID: <20020517064821.4451DE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=246 Summary: md5_crypt conflict fails Product: Portable OpenSSH Version: -current Platform: Other OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: quelrods at mail.utexas.edu on both a slackware 7.1 and slackware 8.0 system when attempting --with-md5-passwords everything is fine except one line of configure: checking for md5_crypt... no checking config.log yields: $ ./configure --with-md5-passwords --with-bsd-auth --sysconfdir=/etc/ssh --with-ipv4-default configure:6441: checking for md5_crypt openssh-3.2.2p1/configure:6474: undefined reference to `md5_crypt' which can conflict with char md5_crypt (); below. */ char md5_crypt (); #if defined (__stub_md5_crypt) || defined (__stub___md5_crypt) f = md5_crypt; ac_cv_func_md5_crypt=no fought w/ this an hour, played w/ editing the configure, played w/ compiling new openssl, any help would be welcome ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jakob at crt.se Fri May 17 17:31:15 2002 From: jakob at crt.se (Jakob Schlyter) Date: Fri, 17 May 2002 09:31:15 +0200 (MEST) Subject: Problems with OpenSSH 3.2.2p1 on Solaris 7 Message-ID: just upgraded to OpenSSH 3.2.2p1 on a box running Solaris 7. now I get the following when logging on: Warning: no access to tty (Inappropriate ioctl for device). Thus no job control in this shell. everything works alright with 3.0p1, but 3.1p1 and 3.2.2p1 seems to have this problem. jakob From bugzilla-daemon at mindrot.org Fri May 17 18:11:45 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 17 May 2002 18:11:45 +1000 (EST) Subject: [Bug 247] New: 3.2.2p1, hang on exit on Solaris Message-ID: <20020517081145.3FB4AE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=247 Summary: 3.2.2p1, hang on exit on Solaris Product: Portable OpenSSH Version: -current Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: js at phil.uu.nl When connecting to a 3.2.2p1 sshd (running on Solaris), a hang occurs on logout. The ssh version/platform version used makes no difference. This didn't (and doesn't) happen with the 3.1p1 sshd. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From nide at ics.nara-wu.ac.jp Fri May 17 18:42:57 2002 From: nide at ics.nara-wu.ac.jp (NIDE Naoyuki) Date: Fri, 17 May 2002 17:42:57 +0900 Subject: openssh-3.2.2p1 on Linux 2.0 Message-ID: <20020517174257N.nide@narams.cc.nara-wu.ac.jp> Hi I've found that openssh-3.2.2p1 can't be compiled on my Linux 2.0.36, because it doesn't define CMSG_DATA and CMSG_FIRSTHDR in . The patch below solved this problem. Regards, NIDE Maoyuki, nide at ics.nara-wu.ac.jp ------------------------------------------------------------------------ diff -ru openssh-3.2.2p1.orig/defines.h openssh-3.2.2p1/defines.h --- openssh-3.2.2p1.orig/defines.h Fri Apr 26 02:56:07 2002 +++ openssh-3.2.2p1/defines.h Fri May 17 17:21:13 2002 @@ -410,6 +410,15 @@ #define CMSG_SPACE(len) (__CMSG_ALIGN(sizeof(struct cmsghdr)) + __CMSG_ALIGN(len)) #endif +/* Linux 2.0 does not have CMSG_DATA, CMSG_FIRSTHDR */ +#ifndef CMSG_DATA +#define CMSG_DATA(cmsg) ((void *)((char *)(cmsg) + __CMSG_ALIGN(sizeof(struct cmsghdr)))) +#endif +#ifndef CMSG_FIRSTHDR +#define CMSG_FIRSTHDR(msg) (((msg)->msg_controllen) >= sizeof(struct cmsghdr) ? \ + (struct cmsghdr *)((msg)->msg_control) : (struct cmsghdr *)NULL) +#endif + /* Function replacement / compatibility hacks */ #if !defined(HAVE_GETADDRINFO) && (defined(HAVE_OGETADDRINFO) || defined(HAVE_NGETADDRINFO)) From sean at boran.com Fri May 17 19:03:01 2002 From: sean at boran.com (Sean Boran) Date: Fri, 17 May 2002 11:03:01 +0200 Subject: SSH 3.2.2 on Solaris 8 with /kernel/drv/random Message-ID: <00fa01c1fd81$a6356450$0a1111b0@swissptt.ch> Hi, I'm like to try a get the new release to work with Sun's new device, that can be installed with patch 112438-01. I compiled SSL attempting to point it at the random device: cd openssl-0.9.6d ./Configure solaris-sparcv7-gcc make DEVRANDOM="/kernel/drv/random" And then ran the SSH configure: ./configure --prefix=/opt/OBSDssh --with-pam --without-rsh \ --sysconfdir=/etc/ssh --with-pid-dir=/var/run --disable-suid-ssh \ --with-tcp-wrappers=../tcp_wrappers_7.6 But am not convinced this is correct. and I also tried: ./configure --prefix=/opt/OBSDssh --with-pam --without-rsh \ --sysconfdir=/etc/ssh --with-pid-dir=/var/run --disable-suid-ssh \ --with-tcp-wrappers=../tcp_wrappers_7.6 \ --with-prngd-socket=/kernel/drv/random And configure says: Random number source: ssh-rand-helper ssh-rand-helper collects from: Unix domain socket "/kernel/drv/random" But I don't think /kernel/drv/random is a socket, "ls" lists it as a normal file. ls -alF /kernel/drv/random -rwxr-xr-x 1 root sys 15704 Mar 15 00:33 /kernel/drv/random* If I compile SSH as above and then try to use the random device I get: ./ssh-rand-helper Couldn't connect to PRNGD socket "/kernel/drv/random": Socket operation on non-socket. Entropy collection failed So the question: has anyone got SSH to work with Sun's random device and if so, how did you do it? Thanks in advance, Sean ___________________________________________ Sean Boran Tel: +41-79-2444.607 From vinschen at redhat.com Fri May 17 20:40:24 2002 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 17 May 2002 12:40:24 +0200 Subject: OpenSSH 3.2.2 released In-Reply-To: <20020516223622.GA12334@muamat> References: <20020516223622.GA12334@muamat> Message-ID: <20020517124024.U2671@cygbert.vinschen.de> On Fri, May 17, 2002 at 12:36:22AM +0200, Markus Friedl wrote: > OpenSSH 3.2.2 has just been released. It will be available from the > mirrors listed at http://www.openssh.com/ shortly. Sigh. I'm somewhat annoyed. Sorry. Why has the setgroups() call been added to sshd.c a week ago w/o asking for further testing? It doesn't exist in Cygwin. All other setgroups() calls are #ifndef'd HAVE_CYGWIN. Why not this one? Now this error which screws up building ssh on Cygwin is in an official release. :-((((( Grrr, Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From jm.poure at freesurf.fr Fri May 17 21:34:43 2002 From: jm.poure at freesurf.fr (Jean-Michel POURE) Date: Fri, 17 May 2002 13:34:43 +0200 Subject: OpenSSH 3.2.2 released : chroot In-Reply-To: <20020516223622.GA12334@muamat> References: <20020516223622.GA12334@muamat> Message-ID: <200205171334.43224.jm.poure@freesurf.fr> Le Vendredi 17 Mai 2002 00:36, Markus Friedl a ?crit : > OpenSSH 3.2.2 has just been released. It will be available from the > mirrors listed at http://www.openssh.com/ shortly. Do you plan to add chrooting to OpenSSH shortly? Chrooting is, IMHO, the most wanted add-on feature. Cheers, Jean-Michel POURE From ed at UDel.Edu Fri May 17 23:14:01 2002 From: ed at UDel.Edu (Ed Phillips) Date: Fri, 17 May 2002 09:14:01 -0400 (EDT) Subject: SSH 3.2.2 on Solaris 8 with /kernel/drv/random In-Reply-To: <00fa01c1fd81$a6356450$0a1111b0@swissptt.ch> Message-ID: On Fri, 17 May 2002, Sean Boran wrote: > Date: Fri, 17 May 2002 11:03:01 +0200 > From: Sean Boran > To: openssh-unix-dev at mindrot.org > Subject: SSH 3.2.2 on Solaris 8 with /kernel/drv/random > > Hi, > > I'm like to try a get the new release to work with Sun's new device, > that can be installed with patch 112438-01. > > I compiled SSL attempting to point it at the random device: > cd openssl-0.9.6d > ./Configure solaris-sparcv7-gcc > make DEVRANDOM="/kernel/drv/random" Not necessary. Just do "make". > And then ran the SSH configure: > ./configure --prefix=/opt/OBSDssh --with-pam --without-rsh \ > --sysconfdir=/etc/ssh --with-pid-dir=/var/run --disable-suid-ssh \ > --with-tcp-wrappers=../tcp_wrappers_7.6 Also add, --without-rand-helper. > But am not convinced this is correct. > > and I also tried: > ./configure --prefix=/opt/OBSDssh --with-pam --without-rsh \ > --sysconfdir=/etc/ssh --with-pid-dir=/var/run --disable-suid-ssh \ > --with-tcp-wrappers=../tcp_wrappers_7.6 \ > --with-prngd-socket=/kernel/drv/random > > And configure says: > Random number source: ssh-rand-helper > ssh-rand-helper collects from: Unix domain socket > "/kernel/drv/random" It'll say "Random number source: OpenSSL internal" or something to that effect... > But I don't think /kernel/drv/random is a socket, "ls" lists it as a > normal file. > ls -alF /kernel/drv/random > -rwxr-xr-x 1 root sys 15704 Mar 15 00:33 > /kernel/drv/random* /kernel/drv/random is the kernel *driver* which is not the random number "device" file that you want to read. OpenSSL will automatically use "/dev/urandom". > If I compile SSH as above and then try to use the random device I get: > ./ssh-rand-helper > Couldn't connect to PRNGD socket "/kernel/drv/random": Socket operation > on non-socket. Entropy collection failed > > So the question: has anyone got SSH to work with Sun's random device and > if so, how did you do it? Yep... it works great! ;-) Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From Denis.Ducamp at hsc.fr Fri May 17 23:43:30 2002 From: Denis.Ducamp at hsc.fr (Denis Ducamp) Date: Fri, 17 May 2002 15:43:30 +0200 Subject: UsePrivilegeSeparation doesn t work on Linux 2.2.x [Re: OpenSSH 3.2.2 released] In-Reply-To: <20020516223622.GA12334@muamat>; from Markus_Friedl@genua.de on Fri, May 17, 2002 at 12:36:22AM +0200 References: <20020516223622.GA12334@muamat> Message-ID: <20020517154330.A29088@hsc.fr> On Fri, May 17, 2002 at 12:36:22AM +0200, Markus Friedl wrote: > - experimental support for privilege separation, > see UsePrivilegeSeparation in sshd(8) and > http://www.citi.umich.edu/u/provos/ssh/privsep.html > for more information. This is a very good feature and I want to thanks again Niels Provos and others for their work on it. I tested it during snapshot and worked well on my non-production systems but this morning I couldn't make it work on some of my production systems. In fact the difference is the linux kernel version : 2.4.x vs 2.2.x UsePrivilegeSeparation work on all my slackware 8.0 linux 2.4.17 glibc 2.2.3 UsePrivilegeSeparation doesn't work on following systems with the same result : . slackware 7.1-cur linux 2.2.19pre16 glibc 2.2.2 . slackware 7.1 linux 2.2.19 glibc 2.1.3 . redhat 6.0 linux 2.2.19 glibc 2.1.1 . debian 3.0 linux 2.2.20 glibc 2.2.5 All configured with : ./configure --with-tcp-wrappers --with-ssl-dir=/usr/local/ssl --with-md5-passwords --disable-suid-ssh Here is the sshd dump : root at server:openssh-3.2.2p1# ./sshd -p 28 -d -D -o 'UsePrivilegeSeparation yes' debug1: sshd version OpenSSH_3.2.2p1 debug1: private host key: #0 type 0 RSA1 debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA socket: Address family not supported by protocol debug1: Bind to port 28 on 0.0.0.0. Server listening on 0.0.0.0 port 28. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. setsid: Operation not permitted Connection from 62.4.21.62 port 3247 debug1: Client protocol version 2.0; client software version OpenSSH_3.2.2p1 debug1: match: OpenSSH_3.2.2p1 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_3.2.2p1 mmap(65536) debug1: Calling cleanup 0x8068954(0x0) root at server:openssh-3.2.2p1# Here is what strace can see (on the debian system) : fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 socketpair(PF_UNIX, SOCK_STREAM, 0, [3, 7]) = 0 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 fcntl(7, F_SETFD, FD_CLOEXEC) = 0 mmap2(NULL, 65536, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0) = -1 ENOSYS (Function not implemented) old_mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0) = -1 EINVAL (Invalid argument) write(2, "mmap(65536)\r\n", 13mmap(65536) ) = 13 write(2, "debug1: Calling cleanup 0x806ae9"..., 40debug1: Calling cleanup 0x806ae9c(0x0) ) = 40 shutdown(4, 2 /* send and receive */) = 0 close(4) = 0 _exit(255) = ? The connexion is made with a simple 'ssh server -p 28' and the result in the same in sshv1/2 with publickey/password authentication. Best regards, Denis Ducamp. -- Denis.Ducamp at hsc.fr --- Herv? Schauer Consultants --- http://www.hsc.fr/ Owl/Openwall/snort/hping/dsniff en fran?ais http://www.groar.org/trad/ Owl en fran?ais http://www.openwall.com/Owl/fr/ Du bon usage de ... http://usenet-fr.news.eu.org/fr-chartes/rfc1855.html From Nicolas.Williams at ubsw.com Fri May 17 23:55:05 2002 From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com) Date: Fri, 17 May 2002 09:55:05 -0400 Subject: OpenSSH 3.2.2 released : chroot Message-ID: <9403F8EE868566448AA1B70D8F783C95334F0E@NSTMC004PEX1.ubsgs.ubsgroup.net> You must mean your most wanted feature. Mine is the integration of Simon's GSS patches. Nico -- > -----Original Message----- > From: Jean-Michel POURE [mailto:jm.poure at freesurf.fr] > Sent: Friday, May 17, 2002 7:35 AM > To: Markus Friedl; openssh-unix-dev at mindrot.org > Subject: OpenSSH 3.2.2 released : chroot > > > Le Vendredi 17 Mai 2002 00:36, Markus Friedl a ?crit : > > OpenSSH 3.2.2 has just been released. It will be available from the > > mirrors listed at http://www.openssh.com/ shortly. > > Do you plan to add chrooting to OpenSSH shortly? Chrooting > is, IMHO, the most > wanted add-on feature. > > Cheers, > Jean-Michel POURE > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From hin at stacken.kth.se Sat May 18 00:09:31 2002 From: hin at stacken.kth.se (Hans Insulander) Date: 17 May 2002 16:09:31 +0200 Subject: OpenSSH 3.2.2 released : chroot In-Reply-To: Nicolas.Williams@ubsw.com's message of "Fri, 17 May 2002 09:55:05 -0400" References: <9403F8EE868566448AA1B70D8F783C95334F0E@NSTMC004PEX1.ubsgs.ubsgroup.net> Message-ID: <86k7q29884.fsf@hink.dynarc.se> > > Do you plan to add chrooting to OpenSSH shortly? Chrooting > > is, IMHO, the most > > wanted add-on feature. > You must mean your most wanted feature. Mine is the integration of Simon's GSS patches. Note that he did say "IMHO" which reads out as "In My Humble Opinion". So what is the problem? -- --- Hans Insulander , SM0UTY ----------------------- The difference between men and women: On the one hand, we'll never experience childbirth. On the other hand, we can open all our own jars. -- Bruce Willis From provos at citi.umich.edu Sat May 18 00:16:55 2002 From: provos at citi.umich.edu (Niels Provos) Date: Fri, 17 May 2002 10:16:55 -0400 Subject: UsePrivilegeSeparation doesn t work on Linux 2.2.x [Re: OpenSSH 3.2.2 released] In-Reply-To: <20020517154330.A29088@hsc.fr> References: <20020516223622.GA12334@muamat> <20020517154330.A29088@hsc.fr> Message-ID: <20020517141655.GW29316@citi.citi.umich.edu> On Fri, May 17, 2002 at 03:43:30PM +0200, Denis Ducamp wrote: > fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 > socketpair(PF_UNIX, SOCK_STREAM, 0, [3, 7]) = 0 > fcntl(3, F_SETFD, FD_CLOEXEC) = 0 > fcntl(7, F_SETFD, FD_CLOEXEC) = 0 > mmap2(NULL, 65536, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0) = -1 ENOSYS (Function not implemented) > old_mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0) = -1 EINVAL (Invalid argument) > write(2, "mmap(65536)\r\n", 13mmap(65536) > ) = 13 > write(2, "debug1: Calling cleanup 0x806ae9"..., 40debug1: Calling cleanup 0x806ae9c(0x0) > ) = 40 > shutdown(4, 2 /* send and receive */) = 0 That looks more like a kernel problem to me. It does not know about the mmap2 system call. That is sort of pretty weird. Did you you pre-compiled binaries or did you compile it yourself? And then it seems that the fallback old_mmap does not like one of the parameters. You need to see what API changed in Linux to make this break. Niels. From Nicolas.Williams at ubsw.com Sat May 18 00:23:10 2002 From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com) Date: Fri, 17 May 2002 10:23:10 -0400 Subject: OpenSSH 3.2.2 released : chroot Message-ID: <9403F8EE868566448AA1B70D8F783C95334F0F@NSTMC004PEX1.ubsgs.ubsgroup.net> There is no problem. I think Markus et. al. can figure out what is the most wanted feature. -- > -----Original Message----- > From: Hans Insulander [mailto:hin at stacken.kth.se] > Sent: Friday, May 17, 2002 10:10 AM > To: Williams, Nicolas > Cc: jm.poure at freesurf.fr; openssh-unix-dev at mindrot.org > Subject: Re: OpenSSH 3.2.2 released : chroot > > > > > > Do you plan to add chrooting to OpenSSH shortly? Chrooting > > > is, IMHO, the most > > > wanted add-on feature. > > > You must mean your most wanted feature. Mine is the > integration of Simon's GSS patches. > > Note that he did say "IMHO" which reads out as "In My Humble Opinion". > > So what is the problem? > > -- > --- Hans Insulander , SM0UTY > ----------------------- > The difference between men and women: > On the one hand, we'll never experience childbirth. > On the other hand, we can open all our own jars. -- > Bruce Willis > Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Douglas.Chimento at FMR.COM Sat May 18 00:26:57 2002 From: Douglas.Chimento at FMR.COM (Chimento, Douglas) Date: Fri, 17 May 2002 10:26:57 -0400 Subject: uidswap Message-ID: <13619E2D7C7ED748ADD005E8D6C748F3A7837D@MSGBOS684NTS.fmr.com> Thanks Markkus. Please excuse my ignorance , I am not much of a UNIX programmer but I believe I see a potential issue. Suppose ssh in NOT installed setuid root. If you take a look at the function permanently_set_uid() in uidswap.c ( line 146 in 3.1p1 ) I believe these lines below can fail unexpectedly: if (setgid(pw->pw_gid) < 0) fatal("setgid %u: %.100s", (u_int) pw->pw_gid, strerror(errno)); Here's why , Suppose you "switch" primary group id with the newgrp command. ( For instance: [doug at host ~]$ id uid=1065(doug) gid=100(staff) [doug at host ~]$ newgrp test [doug at host ~]$ id uid=1065(doug) gid=1001(test) [doug at host ~]$ ) Now clearly pw->pw_gid != getgid() and so setgid(pw->pw_gid) will always fail because the user is no longer a part of pw->pw_gid group. ( I hope that made sense ). I think the solution would be to do what is done in the restore_uid() function ( line 108 in uidswap.c ). That is, check to see if the user is "privileged". So we could have this in permanently_set_uid(): { if (temporarily_use_uid_effective) fatal("restore_uid: temporarily_use_uid effective"); if (!privileged) return; if (setgid(pw->pw_gid) < 0) fatal("setgid %u: %.100s", (u_int) pw->pw_gid, strerror(errno)); if (setuid(pw->pw_uid) < 0) fatal("setuid %u: %.100s", (u_int) pw->pw_uid, strerror(errno)); } instead of.... { if (temporarily_use_uid_effective) fatal("restore_uid: temporarily_use_uid effective"); if (setgid(pw->pw_gid) < 0) fatal("setgid %u: %.100s", (u_int) pw->pw_gid, strerror(errno)); if (setuid(pw->pw_uid) < 0) fatal("setuid %u: %.100s", (u_int) pw->pw_uid, strerror(errno)); } What are your thoughts? Thanks for your time. -----Original Message----- From: Markus Friedl [mailto:markus at openbsd.org] Sent: Thursday, May 16, 2002 7:18 PM To: Chimento, Douglas Cc: openssh-unix-dev at mindrot.org Subject: Re: uidswap On Thu, May 16, 2002 at 04:32:11PM -0400, Chimento, Douglas wrote: > What are the consequnences if you do not install ssh setuid > root? ( As far I as know no uid swaping occurs ) hostbased authentication won't work. From jdennis at law.harvard.edu Sat May 18 00:44:47 2002 From: jdennis at law.harvard.edu (James Dennis) Date: Fri, 17 May 2002 10:44:47 -0400 Subject: Updated chroot patch Message-ID: <20020517104447.0de22b35.jdennis@law.harvard.edu> Hello everyone, I have updated the patch for adding chroot functionality for users to OpenSSH. -James -------------- next part -------------- A non-text attachment was scrubbed... Name: osshChroot.patch Type: application/octet-stream Size: 3059 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020517/122f800c/attachment.obj From jdennis at law.harvard.edu Sat May 18 00:46:49 2002 From: jdennis at law.harvard.edu (James Dennis) Date: Fri, 17 May 2002 10:46:49 -0400 Subject: One last thing Message-ID: <20020517104649.42a74f9d.jdennis@law.harvard.edu> I also forgot to mention. If anyone has any questions please cc jdennis at law.harvard.edu as I'm not on the openssh developer mailing list (I'm not an openssh developer :). -James From bugzilla-daemon at mindrot.org Sat May 18 00:58:10 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 00:58:10 +1000 (EST) Subject: [Bug 245] SSH can not log out under Solaris 2.6 Message-ID: <20020517145810.0F04BE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=245 ------- Additional Comments From wknox at mitre.org 2002-05-18 00:58 ------- Same issue with Solaris 8 built with gcc 2.95.2 with the following configure options: --without-rsh --with-tcp-wrappers --with-pam --disable-suid-ssh --with-prngd-socket --with-default-path=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin Running a ssh -v -v -v hangs up at the following point (I will happily attach the entire output of this if anyone wants) $ exit logout debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 Hung here until sshd killed debug1: channel_free: channel 0: client-session, nchannels 1 debug3: channel_free: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/0 fd 5/6) debug3: channel_close_fds: channel 0: r 5 w 6 e 7 Connection to oraadm closed by remote host. Connection to oraadm closed. debug1: Transferred: stdin 0, stdout 0, stderr 75 bytes in 55.7 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 1.3 debug1: Exit status 0 Unfortunately, running sshd with -d -d -d doesn't completely capture the problem, as the sshd promptly exits after the first connection closes down (though this does point to the fact that sshd is able to close). The only oddity in the sshd -d -d -d is the following message (last message issued before finishing): debug1: Cannot delete credentials[7]: Permission denied ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jm.poure at freesurf.fr Sat May 18 01:01:15 2002 From: jm.poure at freesurf.fr (Jean-Michel POURE) Date: Fri, 17 May 2002 17:01:15 +0200 Subject: OpenSSH 3.2.2 released : chroot In-Reply-To: <9403F8EE868566448AA1B70D8F783C95334F0E@NSTMC004PEX1.ubsgs.ubsgroup.net> References: <9403F8EE868566448AA1B70D8F783C95334F0E@NSTMC004PEX1.ubsgs.ubsgroup.net> Message-ID: <200205171701.15016.jm.poure@freesurf.fr> Le Vendredi 17 Mai 2002 15:55, Nicolas.Williams at ubsw.com a ?crit : > You must mean your most wanted feature. Mine is the integration of Simon's > GSS patches. I agree Simon's GSS patches are very interesting. I was planning to install a Kerberos V5 authentication server. My primary need is to be sure SSH users will not browse other accounts ... or use SSH commands to connect to other machines. OpenSSH is too powerfull not to have a real chroot environment. Chroot may be the last reason why some users turn to commercial SSH. Cheers, Jean-Michel From Denis.Ducamp at hsc.fr Sat May 18 01:25:40 2002 From: Denis.Ducamp at hsc.fr (Denis Ducamp) Date: Fri, 17 May 2002 17:25:40 +0200 Subject: UsePrivilegeSeparation doesn t work on Linux 2.2.x [Re: OpenSSH 3.2.2 released] In-Reply-To: <20020517141655.GW29316@citi.citi.umich.edu>; from provos@citi.umich.edu on Fri, May 17, 2002 at 10:16:55AM -0400 References: <20020516223622.GA12334@muamat> <20020517154330.A29088@hsc.fr> <20020517141655.GW29316@citi.citi.umich.edu> Message-ID: <20020517172540.B29088@hsc.fr> On Fri, May 17, 2002 at 10:16:55AM -0400, Niels Provos wrote: > On Fri, May 17, 2002 at 03:43:30PM +0200, Denis Ducamp wrote: > > fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 > > socketpair(PF_UNIX, SOCK_STREAM, 0, [3, 7]) = 0 > > fcntl(3, F_SETFD, FD_CLOEXEC) = 0 > > fcntl(7, F_SETFD, FD_CLOEXEC) = 0 > > mmap2(NULL, 65536, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0) = -1 ENOSYS (Function not implemented) > > old_mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0) = -1 EINVAL (Invalid argument) > > write(2, "mmap(65536)\r\n", 13mmap(65536) > > ) = 13 > > write(2, "debug1: Calling cleanup 0x806ae9"..., 40debug1: Calling cleanup 0x806ae9c(0x0) > > ) = 40 > > shutdown(4, 2 /* send and receive */) = 0 > That looks more like a kernel problem to me. It does not know about > the mmap2 system call. That is sort of pretty weird. Did you you > pre-compiled binaries or did you compile it yourself? And then > it seems that the fallback old_mmap does not like one of the > parameters. You need to see what API changed in Linux to make this > break. Yep, it works on linux 2.4 (where I tested several snapshots) but not on linux 2.2 (where I tested no snapshot). The trace above is with the newest glibc used (2.2.5), on an older glibc I have : socketpair(PF_UNIX, SOCK_STREAM, 0, [3, 7]) = 0 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 fcntl(7, F_SETFD, FD_CLOEXEC) = 0 old_mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0) = -1 EINVAL (Invalid argument) On Linux 2.4 I have : socketpair(PF_UNIX, SOCK_STREAM, 0, [3, 7]) = 0 shmat(3, 0x810d0f0, 0x2ptrace: umoven: Input/output error ) = ? shmat(7, 0x810d0f0, 0x2ptrace: umoven: Input/output error ) = ? mmap2(NULL, 65536, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0) = 0x40182000 mmap2(NULL, 1310720, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0) = 0x40192000 fork() = 24666 I don't see anything different between mmap(2) on my Linux 2.2 system and my Linux 2.4 that could have a link with the parameters used by the old_mmap/mmap2 system calls. I let someone with more knowledge on Linux kernel compare both versions. Hope this will help... Denis Ducamp. -- Denis.Ducamp at hsc.fr --- Herv? Schauer Consultants --- http://www.hsc.fr/ Owl/Openwall/snort/hping/dsniff en fran?ais http://www.groar.org/trad/ Owl en fran?ais http://www.openwall.com/Owl/fr/ Du bon usage de ... http://usenet-fr.news.eu.org/fr-chartes/rfc1855.html From Nicolas.Williams at ubsw.com Sat May 18 01:31:23 2002 From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com) Date: Fri, 17 May 2002 11:31:23 -0400 Subject: [Bug 245] SSH can not log out under Solaris 2.6 Message-ID: <9403F8EE868566448AA1B70D8F783C95334F15@NSTMC004PEX1.ubsgs.ubsgroup.net> Sounds like a race condition bug. There used to be one like this on the client side at one point. There also used to be one on the server side. Nico -- > -----Original Message----- > From: bugzilla-daemon at mindrot.org [mailto:bugzilla-daemon at mindrot.org] > Sent: Friday, May 17, 2002 10:58 AM > To: openssh-unix-dev at mindrot.org > Subject: [Bug 245] SSH can not log out under Solaris 2.6 > > > http://bugzilla.mindrot.org/show_bug.cgi?id=245 > > > > > > ------- Additional Comments From wknox at mitre.org 2002-05-18 > 00:58 ------- > Same issue with Solaris 8 built with gcc 2.95.2 with the > following configure > options: > > --without-rsh --with-tcp-wrappers --with-pam --disable-suid-ssh > --with-prngd-socket > --with-default-path=/usr/local/bin:/usr/bin:/bin:/usr/local/sb > in:/usr/sbin:/sbin > > Running a ssh -v -v -v hangs up at the following point (I > will happily attach > the entire output of this if anyone wants) > > $ exit > logout > debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 > > Hung here until sshd killed > > debug1: channel_free: channel 0: client-session, nchannels 1 > debug3: channel_free: status: The following connections are open: > #0 client-session (t4 r0 i0/0 o0/0 fd 5/6) > > debug3: channel_close_fds: channel 0: r 5 w 6 e 7 > Connection to oraadm closed by remote host. > Connection to oraadm closed. > debug1: Transferred: stdin 0, stdout 0, stderr 75 bytes in > 55.7 seconds > debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 1.3 > debug1: Exit status 0 > > Unfortunately, running sshd with -d -d -d doesn't completely > capture the > problem, as the sshd promptly exits after the first > connection closes down > (though this does point to the fact that sshd is able to > close). The only oddity > in the sshd -d -d -d is the following message (last message > issued before > finishing): > > debug1: Cannot delete credentials[7]: Permission denied > > > > > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From tim at multitalents.net Sat May 18 02:02:09 2002 From: tim at multitalents.net (Tim Rice) Date: Fri, 17 May 2002 09:02:09 -0700 (PDT) Subject: erroneous reporting of md5 usage, openssh-3.2.2p1 In-Reply-To: <20020517090038.4248252b.kongar@tsrsb.org.tr> Message-ID: Thanks for the report. The fix should show up in the next SNAP On Fri, 17 May 2002, Kagan Kongar wrote: > > Talking about openssh-3.2.2p1 > > The configure script erroneously reporting the md5-password status. > > The script, when activated with "--with-md5-passwords" correctly sets the > config.h but reporting "MD5 password support: no" > > Seems that is due to a bug in configure.ac, line 2026 > > Kind regards, > > Kagan Kongar > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mouring at etoh.eviladmin.org Sat May 18 02:05:07 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 17 May 2002 11:05:07 -0500 (CDT) Subject: OpenSSH 3.2.2 released : chroot In-Reply-To: <200205171701.15016.jm.poure@freesurf.fr> Message-ID: Out of interest why do you feel it's required to do chroot() at the OpenSSH level? Why don't you invest time into a shell that does the chroot() for you? That would work for telnet, ssh, etc. No need to clutter up OpenSSH with options that can easily be implemented at a higher level. - Ben On Fri, 17 May 2002, Jean-Michel POURE wrote: > Le Vendredi 17 Mai 2002 15:55, Nicolas.Williams at ubsw.com a ?crit : > > You must mean your most wanted feature. Mine is the integration of Simon's > > GSS patches. > > I agree Simon's GSS patches are very interesting. I was planning to install a > Kerberos V5 authentication server. My primary need is to be sure SSH users > will not browse other accounts ... or use SSH commands to connect to other > machines. > > OpenSSH is too powerfull not to have a real chroot environment. Chroot may be > the last reason why some users turn to commercial SSH. > > Cheers, > Jean-Michel > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From mike at enoch.org Sat May 18 02:27:38 2002 From: mike at enoch.org (Mike Johnson) Date: Fri, 17 May 2002 12:27:38 -0400 Subject: OpenSSH 3.2.2 released : chroot In-Reply-To: References: <200205171701.15016.jm.poure@freesurf.fr> Message-ID: <20020517162738.GF23204@enoch.org> Ben Lindstrom [mouring at etoh.eviladmin.org] wrote: > > Out of interest why do you feel it's required to do chroot() at the > OpenSSH level? Why don't you invest time into a shell that does the > chroot() for you? That would work for telnet, ssh, etc. No need to > clutter up OpenSSH with options that can easily be implemented at a higher > level. Because, like you said, that required the shell to do it. I'd rather trust OpenSSH to 'do the right thing' than a shell. Plus, it's harder to break out of the OpenSSH chroot, than the shell based one. While it can be implemented at a higher level, I think it's -better- implemented at an OpenSSH level. So, my question is: would a decent patch be accepted? Mike -- "Let the power of Ponch compel you! Let the power of Ponch compel you!" -- Zorak on Space Ghost GNUPG Key fingerprint = ACD2 2F2F C151 FB35 B3AF C821 89C4 DF9A 5DDD 95D1 GNUPG Key = http://www.enoch.org/mike/mike.pubkey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020517/8d1d0846/attachment.bin From mouring at etoh.eviladmin.org Sat May 18 02:39:15 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 17 May 2002 11:39:15 -0500 (CDT) Subject: OpenSSH 3.2.2 released : chroot In-Reply-To: <20020517162738.GF23204@enoch.org> Message-ID: On Fri, 17 May 2002, Mike Johnson wrote: > Ben Lindstrom [mouring at etoh.eviladmin.org] wrote: > > > > Out of interest why do you feel it's required to do chroot() at the > > OpenSSH level? Why don't you invest time into a shell that does the > > chroot() for you? That would work for telnet, ssh, etc. No need to > > clutter up OpenSSH with options that can easily be implemented at a higher > > level. > > Because, like you said, that required the shell to do it. I'd rather > trust OpenSSH to 'do the right thing' than a shell. Plus, it's harder > to break out of the OpenSSH chroot, than the shell based one. > It is? HOW can you break out of a 10 line application written sole to handle a chroot environment? Which also allows you to clean up the environment from nasty ~/.ssh/environment variables you many not want. I'm not saying 'rksh'. I'm saying write a program that DOES the chrooting for you. You saying that almost 30,000 lines of code of which I venture to guess 5,000 or more are hit before you spawn a shell is more secure than a 10 line C application that handles the chroot process? (No offence Markus/Theo =) Every line of code, every feature added, every platform added adds a greater chance of error. Add enough lines, features, platforms you get to a point where you have more code than you can confortable audit without missing edge cases. > While it can be implemented at a higher level, I think it's -better- > implemented at an OpenSSH level. > Don't agree with you on this. Never will. I've considered it for the last few years and I can't come up with a good reason why it should not be handled by a 'helper' style program instead of directly in the system. > So, my question is: would a decent patch be accepted? > We have declined such patches in the past. And I suspect we will decline such patches in the future. There is a chroot patch floating around already. And I know people that apply it and use it happily. - Ben From mike at enoch.org Sat May 18 03:18:09 2002 From: mike at enoch.org (Mike Johnson) Date: Fri, 17 May 2002 13:18:09 -0400 Subject: OpenSSH 3.2.2 released : chroot In-Reply-To: References: <20020517162738.GF23204@enoch.org> Message-ID: <20020517171808.GG23204@enoch.org> Ben Lindstrom [mouring at etoh.eviladmin.org] wrote: > It is? HOW can you break out of a 10 line application written sole > to handle a chroot environment? Which also allows you to clean up > the environment from nasty ~/.ssh/environment variables you many not > want. I'm not saying 'rksh'. I'm saying write a program that DOES the > chrooting for you. Okay, I immediately assumed you meant rksh or rbash, hence the knee-jerk reaction. > Every line of code, every feature added, every platform added adds a > greater chance of error. Add enough lines, features, platforms you > get to a point where you have more code than you can confortable audit > without missing edge cases. Fair enough. > We have declined such patches in the past. And I suspect we will decline > such patches in the future. That's all I needed to hear, really. > There is a chroot patch floating around already. And I know people that > apply it and use it happily. Yup. I've been maintaining my own. But, I have to admit that after reading your mail a few times, it makes sense. At the very least, I wouldn't have to keep updating the damned patch for every OpenSSH release. Off to write and test a wrapper... Mike -- "Let the power of Ponch compel you! Let the power of Ponch compel you!" -- Zorak on Space Ghost GNUPG Key fingerprint = ACD2 2F2F C151 FB35 B3AF C821 89C4 DF9A 5DDD 95D1 GNUPG Key = http://www.enoch.org/mike/mike.pubkey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020517/017a4059/attachment.bin From bugzilla-daemon at mindrot.org Sat May 18 03:12:32 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 03:12:32 +1000 (EST) Subject: [Bug 246] md5_crypt conflict fails Message-ID: <20020517171232.CBC3BE8EA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=246 ------- Additional Comments From tim at multitalents.net 2002-05-18 03:12 ------- Perhaps you are getting confused by the "MD5 password support: no" line. configure is reporting that in error as pointed out by Kagan Kongar Try removing line 2026 (MD5_MSG="no") of configure.ac and run autoconf. If you don't have autoconf 2.52, grab the corrected configure from http://www.multitalents.net/openssh/configure-OpenSSH_3.2.2p1.gz or ftp://ftp.multitalents.net/pub/openssh/configure-OpenSSH_3.2.2p1.gz ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 18 04:54:25 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 04:54:25 +1000 (EST) Subject: [Bug 247] 3.2.2p1, hang on exit on Solaris Message-ID: <20020517185425.393EDE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=247 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From stevesk at pobox.com 2002-05-18 04:54 ------- *** This bug has been marked as a duplicate of 245 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 18 04:54:30 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 04:54:30 +1000 (EST) Subject: [Bug 245] SSH can not log out under Solaris 2.6 Message-ID: <20020517185430.21CA0E8FF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=245 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |js at phil.uu.nl ------- Additional Comments From stevesk at pobox.com 2002-05-18 04:54 ------- *** Bug 247 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 18 05:28:48 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 05:28:48 +1000 (EST) Subject: [Bug 245] SSH can not log out under Solaris 2.6 Message-ID: <20020517192848.6DB42E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=245 ------- Additional Comments From stevesk at pobox.com 2002-05-18 05:28 ------- i don't know why yet, but the setsid() added to sshd.c seems to break pty_make_controlling_tty(). will add a patch to try. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 18 05:30:56 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 05:30:56 +1000 (EST) Subject: [Bug 245] SSH can not log out under Solaris 2.6 Message-ID: <20020517193056.3D0AEE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=245 ------- Additional Comments From stevesk at pobox.com 2002-05-18 05:30 ------- Created an attachment (id=96) remove call to setsid() ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From kevin at atomicgears.com Sat May 18 05:34:24 2002 From: kevin at atomicgears.com (Kevin Steves) Date: Fri, 17 May 2002 12:34:24 -0700 (PDT) Subject: Problems with OpenSSH 3.2.2p1 on Solaris 7 In-Reply-To: Message-ID: On Fri, 17 May 2002, Jakob Schlyter wrote: :just upgraded to OpenSSH 3.2.2p1 on a box running Solaris 7. now I get the :following when logging on: : : Warning: no access to tty (Inappropriate ioctl for device). : Thus no job control in this shell. : :everything works alright with 3.0p1, but 3.1p1 and 3.2.2p1 seems to have :this problem. you have that with 3.1p1 as well? does this change anything? Index: sshd.c =================================================================== RCS file: /var/cvs/openssh/sshd.c,v retrieving revision 1.205 diff -u -r1.205 sshd.c --- sshd.c 15 May 2002 16:25:02 -0000 1.205 +++ sshd.c 17 May 2002 19:17:01 -0000 @@ -1336,8 +1336,10 @@ * setlogin() affects the entire process group. We don't * want the child to be able to affect the parent. */ +#if 0 if (setsid() < 0) error("setsid: %.100s", strerror(errno)); +#endif /* * Disable the key regeneration alarm. We will not regenerate the From djast at cs.toronto.edu Sat May 18 05:54:38 2002 From: djast at cs.toronto.edu (Dan Astoorian) Date: Fri, 17 May 2002 15:54:38 -0400 Subject: OpenSSH 3.2.2 released : chroot In-Reply-To: Your message of "Fri, 17 May 2002 12:05:07 EDT." Message-ID: <02May17.155443edt.453167-474@jane.cs.toronto.edu> On Fri, 17 May 2002 12:05:07 EDT, Ben Lindstrom writes: > > Out of interest why do you feel it's required to do chroot() at the > OpenSSH level? Playing devil's advocate: because chroot() needs to be done by a privileged process... > Why don't you invest time into a shell that does the > chroot() for you? ...and such a shell would have to be setuid-root. It would therefore also have to protect against a greater range of attacks, because it can't assume it's being run from a trusted context. For example, the program would need a way to determine what directory it's supposed to chroot() to, and it would have to be a method that users cannot subvert. In that sense, it's in some ways easier to do it within sshd before dropping privileges than it is to regain the privileges from a setuid-root helper program later. Having said that, I agree with Ben that a standalone product would be very much preferable to complicating OpenSSH's daemon, even if it's harder to do correctly. > There is a chroot patch floating around already. And I know people that > apply it and use it happily. I've seen a number of chroot patches floating around. Some of them were really awful: they did things like trust environment variables (or the command line, or other user-manipulable sources), and could easily be used to compromise a system. I've commented on some of those patches on this list in the past. I don't know of any specific exploitable problems with the patch James Dennis posted here; however, I'd feel a lot better about it, for example, if it did basic hygiene such as doing a chdir("/") immediately after the chroot(user_dir). I haven't investigated that closely, but I suspect it might be possible for a user to break out of the chroot() jail by removing u=x permission from his home directory at the right time, so that the chdir(pw->pw_dir) fails. The patch also seems to declare two arguments to do_setusercontext() for no apparent reason--from a casual inspection, the function only appears to use them as local variables, and the caller passes in uninitialized pointers for some reason. I'd also feel more comfortable if there were sanity checks in the code, to protect a sysadmin from misconfiguring a system in a way that would allow a user to chroot() to an insecure place (e.g., somewhere that the user could manipulate critical things like /dev, /etc, /usr, /proc, /bin...) At this time I know of no implementation of either an OpenSSHd patch or a standalone shell which is trustworthy enough that I would feel comfortable recommending it to anyone. Ideally, I'd like to see someone who knows what they're doing write a properly-implemented wrapper, and for that package to become the solution that the OpenSSH team recommends in their FAQs. I personally don't require the ability to chroot() from within an ssh session like this, so I'm not motivated to write such a package, but if someone else wanted to do so, I'd be willing to help with the design and to help audit the thing for security problems. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From gjewell at cnnxn.com Sat May 18 06:05:33 2002 From: gjewell at cnnxn.com (Greg Jewell) Date: Fri, 17 May 2002 14:05:33 -0600 Subject: Ctrl-C disconnects when connected to Solaris with 3.2.2p1 Message-ID: Hi All, I've seen the various reports about the problems logging out under Solaris. I can duplicate this under both Solaris 7 and 8 (sparc). I've also noticed another behavior, though. Anytime I press Ctrl-C while connected to a Solaris system running the 3.2.2 server, the session completely disconnects. This only appears to be happening with Solaris, as tests under SCO OpenServer and HPUX do not yield this. Thanks, Greg Jewell From wknox at mitre.org Sat May 18 06:15:59 2002 From: wknox at mitre.org (William R. Knox) Date: Fri, 17 May 2002 16:15:59 -0400 (EDT) Subject: Ctrl-C disconnects when connected to Solaris with 3.2.2p1 In-Reply-To: Message-ID: The patch posted to bug #245 also fixes this problem. Bill Knox Senior Operating Systems Programmer/Analyst The MITRE Corporation On Fri, 17 May 2002, Greg Jewell wrote: > Date: Fri, 17 May 2002 14:05:33 -0600 > From: Greg Jewell > To: openssh-unix-dev at mindrot.org > Subject: Ctrl-C disconnects when connected to Solaris with 3.2.2p1 > > Hi All, > > I've seen the various reports about the problems logging out under Solaris. I can duplicate this under both Solaris 7 and 8 (sparc). > > I've also noticed another behavior, though. Anytime I press Ctrl-C while connected to a Solaris system running the 3.2.2 server, the session completely disconnects. This only appears to be happening with Solaris, as tests under SCO OpenServer and HPUX do not yield this. > > > > Thanks, > Greg Jewell > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From bugzilla-daemon at mindrot.org Sat May 18 06:16:55 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 06:16:55 +1000 (EST) Subject: [Bug 245] SSH can not log out under Solaris 2.6 Message-ID: <20020517201655.B686AE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=245 ------- Additional Comments From wknox at mitre.org 2002-05-18 06:16 ------- The patch allows logout to occur, and I note that version 3.1p1 run with -d -d -d also ends with "debug1: Cannot delete credentials[7]: Permission denied", so this is not related. I also note that this patch solves the problem reported on openssh-unix-dev at mindrot.org in an e-mail by Greg Jewell , wherein hitting Ctrl-C will break a connection (I both confirmed the problem without the patch and the lack of the problem with the patch). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 18 06:27:49 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 06:27:49 +1000 (EST) Subject: [Bug 245] SSH can not log out under Solaris 2.6 Message-ID: <20020517202749.6B771E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=245 ------- Additional Comments From bfriesen at simple.dallas.tx.us 2002-05-18 06:27 ------- The suggested patch resolves the logout problem on my system. Is it the right fix? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From gleblanc at linuxweasel.com Sat May 18 06:59:29 2002 From: gleblanc at linuxweasel.com (Gregory Leblanc) Date: 17 May 2002 13:59:29 -0700 Subject: [Fwd: Re: X-windows security in Gnome] Message-ID: <1021669179.21625.31.camel@peecee> This is from a security discussion on one of the GNOME lists. Jim is one of the original X11 people, for what that's worth. I just thought I'd try to tempt some folks here into looking at doing ssh and X integration "right". Greg -- Portland, Oregon, USA. Please don't copy me on replies to the list. -------------- next part -------------- An embedded message was scrubbed... From: Subject: Re: X-windows security in Gnome Date: Fri, 17 May 2002 10:51:22 -0700 (PDT) Size: 3837 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020517/2163916f/attachment.mht From bugzilla-daemon at mindrot.org Sat May 18 07:12:43 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 07:12:43 +1000 (EST) Subject: [Bug 248] New: scp doesn't support ssh2 protocol Message-ID: <20020517211243.7CD41E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=248 Summary: scp doesn't support ssh2 protocol Product: Portable OpenSSH Version: -current Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: liug at mama.indstate.edu server: running commercial ssh, with ssh2 procotol ONLY. client: OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090601f from the client, when I run scp to the server, I get: scp: warning: Executing scp1 compatibility. scp: FATAL: Executing ssh1 in compatibility mode failed (Check that scp1 is in your PATH). Is this a bug in the scp or is it ssh2 protocol is NOT supported? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 18 07:14:20 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 07:14:20 +1000 (EST) Subject: [Bug 248] scp doesn't support ssh2 protocol Message-ID: <20020517211420.6EC14E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=248 ------- Additional Comments From liug at mama.indstate.edu 2002-05-18 07:14 ------- I tried several different versions of openssh, and got the same problem with scp. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Nicolas.Williams at ubsw.com Sat May 18 07:13:25 2002 From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com) Date: Fri, 17 May 2002 17:13:25 -0400 Subject: [Fwd: Re: X-windows security in Gnome] Message-ID: <9403F8EE868566448AA1B70D8F783C95334F1B@NSTMC004PEX1.ubsgs.ubsgroup.net> The "integration" of SSH with apps is already there. Read the OpenSSH [or other SSH implementation's] man pages and the SSHv2 specs. RTFM! Essentially SSH supports tunneling of X11 traffic. The SSH daemon is responsible for creating a local X11 display endpoint and setting the DISPLAY environment variable appropriately, then the apps you run in SSH sessions with X11 forwarding do the right thing and open a display which is really the SSH daemon and which proxies back-and-forth to the SSH client, which then proxies back and forth to its DISPLAY. Oh, and, yes, there are patches for doing Kerberos authentication in SSHv2 with OpenSSH. So yes, SSHv2 w/ X11 forwarding and w/ GSS (w/ Kerberos) key exchange / userauth is a decent approximation of kerberized X11 - it's better even, since one need not forward or proxy any tickets to make the SSH approach work, but one does have to forward or proxy tickets to make the kerberized X11 approach work. And SSH can compress SSH traffic too. Cheers, Nico -- > -----Original Message----- > From: Gregory Leblanc [mailto:gleblanc at linuxweasel.com] > Sent: Friday, May 17, 2002 4:59 PM > To: OpenSSH Devel List > Subject: [Fwd: Re: X-windows security in Gnome] > > > This is from a security discussion on one of the GNOME lists. Jim is > one of the original X11 people, for what that's worth. I just thought > I'd try to tempt some folks here into looking at doing ssh and X > integration "right". > Greg > > -- > Portland, Oregon, USA. > Please don't copy me on replies to the list. > Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From gleblanc at linuxweasel.com Sat May 18 07:32:59 2002 From: gleblanc at linuxweasel.com (Gregory Leblanc) Date: 17 May 2002 14:32:59 -0700 Subject: [Fwd: Re: X-windows security in Gnome] In-Reply-To: <9403F8EE868566448AA1B70D8F783C95334F1B@NSTMC004PEX1.ubsgs.ubsgroup.net> References: <9403F8EE868566448AA1B70D8F783C95334F1B@NSTMC004PEX1.ubsgs.ubsgroup.net> Message-ID: <1021671190.21624.38.camel@peecee> On Fri, 2002-05-17 at 14:13, Nicolas.Williams at ubsw.com wrote: > The "integration" of SSH with apps is already there. I'm fully aware of the ability of OpenSSH to tunnel X11 connections, as is Jim (per his message). Jim was saying that there was a potential to do more, or cleaner, integration between X applications and SSH. I'm not familiar enough with either SSH or the X Window System to know exactly where that integration could be done, or how the existing integration could be "cleaner". Greg P.S. Is my signature not explicit enough? I don't need to receive multiple copies, one to the list is plenty, thanks. > Read the OpenSSH [or other SSH implementation's] man pages and the SSHv2 specs. RTFM! > > Essentially SSH supports tunneling of X11 traffic. The SSH daemon is responsible for creating a local X11 display endpoint and setting the DISPLAY environment variable appropriately, then the apps you run in SSH sessions with X11 forwarding do the right thing and open a display which is really the SSH daemon and which proxies back-and-forth to the SSH client, which then proxies back and forth to its DISPLAY. > > Oh, and, yes, there are patches for doing Kerberos authentication in SSHv2 with OpenSSH. So yes, SSHv2 w/ X11 forwarding and w/ GSS (w/ Kerberos) key exchange / userauth is a decent approximation of kerberized X11 - it's better even, since one need not forward or proxy any tickets to make the SSH approach work, but one does have to forward or proxy tickets to make the kerberized X11 approach work. And SSH can compress SSH traffic too. > > Cheers, > > Nico > -- > > > -----Original Message----- > > From: Gregory Leblanc [mailto:gleblanc at linuxweasel.com] > > Sent: Friday, May 17, 2002 4:59 PM > > To: OpenSSH Devel List > > Subject: [Fwd: Re: X-windows security in Gnome] > > > > > > This is from a security discussion on one of the GNOME lists. Jim is > > one of the original X11 people, for what that's worth. I just thought > > I'd try to tempt some folks here into looking at doing ssh and X > > integration "right". > > Greg > > > > -- > > Portland, Oregon, USA. > > Please don't copy me on replies to the list. > > -- Portland, Oregon, USA. Please don't copy me on replies to the list. From Nicolas.Williams at ubsw.com Sat May 18 07:41:51 2002 From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com) Date: Fri, 17 May 2002 17:41:51 -0400 Subject: [Fwd: Re: X-windows security in Gnome] Message-ID: <9403F8EE868566448AA1B70D8F783C95334F20@NSTMC004PEX1.ubsgs.ubsgroup.net> What else can possibly be done to integrate SSH and apps? I mean, it works, doesn't it? Jim's message was unclear - I was left with the impression that Jim was not aware of the existing X11 forwarding in SSH. Cheers, Nico -- > -----Original Message----- > From: Gregory Leblanc [mailto:gleblanc at linuxweasel.com] > Sent: Friday, May 17, 2002 5:33 PM > To: OpenSSH Devel List > Subject: RE: [Fwd: Re: X-windows security in Gnome] > > > On Fri, 2002-05-17 at 14:13, Nicolas.Williams at ubsw.com wrote: > > The "integration" of SSH with apps is already there. > > I'm fully aware of the ability of OpenSSH to tunnel X11 > connections, as > is Jim (per his message). Jim was saying that there was a > potential to > do more, or cleaner, integration between X applications and SSH. I'm > not familiar enough with either SSH or the X Window System to know > exactly where that integration could be done, or how the existing > integration could be "cleaner". > Greg > > P.S. Is my signature not explicit enough? I don't need to receive > multiple copies, one to the list is plenty, thanks. > > > Read the OpenSSH [or other SSH implementation's] man pages > and the SSHv2 specs. RTFM! > > > > Essentially SSH supports tunneling of X11 traffic. The SSH > daemon is responsible for creating a local X11 display > endpoint and setting the DISPLAY environment variable > appropriately, then the apps you run in SSH sessions with X11 > forwarding do the right thing and open a display which is > really the SSH daemon and which proxies back-and-forth to the > SSH client, which then proxies back and forth to its DISPLAY. > > > > Oh, and, yes, there are patches for doing Kerberos > authentication in SSHv2 with OpenSSH. So yes, SSHv2 w/ X11 > forwarding and w/ GSS (w/ Kerberos) key exchange / userauth > is a decent approximation of kerberized X11 - it's better > even, since one need not forward or proxy any tickets to make > the SSH approach work, but one does have to forward or proxy > tickets to make the kerberized X11 approach work. And SSH can > compress SSH traffic too. > > > > Cheers, > > > > Nico > > -- > > > > > -----Original Message----- > > > From: Gregory Leblanc [mailto:gleblanc at linuxweasel.com] > > > Sent: Friday, May 17, 2002 4:59 PM > > > To: OpenSSH Devel List > > > Subject: [Fwd: Re: X-windows security in Gnome] > > > > > > > > > This is from a security discussion on one of the GNOME > lists. Jim is > > > one of the original X11 people, for what that's worth. I > just thought > > > I'd try to tempt some folks here into looking at doing ssh and X > > > integration "right". > > > Greg > > > > > > -- > > > Portland, Oregon, USA. > > > Please don't copy me on replies to the list. > > > > > -- > Portland, Oregon, USA. > Please don't copy me on replies to the list. > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From dnewman at maraudingpirates.org Sat May 18 07:43:09 2002 From: dnewman at maraudingpirates.org (David F. Newman) Date: Fri, 17 May 2002 17:43:09 -0400 Subject: [Fwd: Re: X-windows security in Gnome] In-Reply-To: <9403F8EE868566448AA1B70D8F783C95334F1B@NSTMC004PEX1.ubsgs.ubsgroup.net> References: <9403F8EE868566448AA1B70D8F783C95334F1B@NSTMC004PEX1.ubsgs.ubsgroup.net> Message-ID: <200205171743.19791.dnewman@maraudingpirates.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 17 May 2002 05:13 pm, Nicolas.Williams at ubsw.com wrote: > The "integration" of SSH with apps is already there. > > Read the OpenSSH [or other SSH implementation's] man pages and the SSHv2 > specs. RTFM! > > Essentially SSH supports tunneling of X11 traffic. The SSH daemon is > responsible for creating a local X11 display endpoint and setting the > DISPLAY environment variable appropriately, then the apps you run in SSH > sessions with X11 forwarding do the right thing and open a display which is > really the SSH daemon and which proxies back-and-forth to the SSH client, > which then proxies back and forth to its DISPLAY. > [snip] IMHO, I wouldn't call that "integrated". ssh is an external tool which provides a tunnel for the X traffic. I would consider it integrated if the X server itself talked SSH as well as the core X libraries. X clients would connect to :0 instead of and the X libraries would transparently use the SSH protocol if available. This would be analogous to a non-SSL aware mail client using stunnel to access an SSL imap mailbox. If the mail client to talk SSL natively to the server without anything in between then you could call it integrated. - -Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (SunOS) iD8DBQE85Xlxu3B/p4jCw/IRAtNwAKCIYKLbmiT0lY6Q27L1kHFQldSQ3QCfRDm+ Wam0KRzwdx+W1GSmOQqodg4= =KUkw -----END PGP SIGNATURE----- From austin at coremetrics.com Sat May 18 07:48:18 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 17 May 2002 16:48:18 -0500 Subject: [Bug 248] New: scp doesn't support ssh2 protocol In-Reply-To: <20020517211243.7CD41E881@shitei.mindrot.org> References: <20020517211243.7CD41E881@shitei.mindrot.org> Message-ID: <1021672098.12809.6.camel@UberGeek> Personally I would see if you get this after restarting your SSH daemon, #1. #2, I would also produce a test scenario with the latest SSH installed on two hosts and see if you get this same problem between them. I've run into stuff like this before, but usually occurred if I changed unerlying libs, without restarting sshd. On Fri, 2002-05-17 at 16:12, bugzilla-daemon at mindrot.org wrote: > http://bugzilla.mindrot.org/show_bug.cgi?id=248 > > Summary: scp doesn't support ssh2 protocol > Product: Portable OpenSSH > Version: -current > Platform: Other > OS/Version: other > Status: NEW > Severity: normal > Priority: P2 > Component: scp > AssignedTo: openssh-unix-dev at mindrot.org > ReportedBy: liug at mama.indstate.edu > > > server: running commercial ssh, with ssh2 procotol ONLY. > client: OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090601f > > from the client, when I run scp to the server, I get: > scp: warning: Executing scp1 compatibility. > scp: FATAL: Executing ssh1 in compatibility mode failed (Check that scp1 > is in > your PATH). > > Is this a bug in the scp or is it ssh2 protocol is NOT supported? > > > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "One ought never to turn one's back on a threatened danger and try to run away from it. If you do that, you will double the danger. But if you meet it promptly and without flinching, you will reduce the danger by half." Sir Winston Churchill -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020517/1b89b09c/attachment.bin From Nicolas.Williams at ubsw.com Sat May 18 07:51:07 2002 From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com) Date: Fri, 17 May 2002 17:51:07 -0400 Subject: [Fwd: Re: X-windows security in Gnome] Message-ID: <9403F8EE868566448AA1B70D8F783C95334F21@NSTMC004PEX1.ubsgs.ubsgroup.net> On Friday, May 17, 2002, David F. Newman wrote: > [snip] > > IMHO, I wouldn't call that "integrated". ssh is an external > tool which > provides a tunnel for the X traffic. I would consider it > integrated if the X > server itself talked SSH as well as the core X libraries. X > clients would > connect to :0 instead of and > the X libraries > would transparently use the SSH protocol if available. This can be done now using ssh -L ... And if you want the X11 libraries to actually initiate the ssh client, then you need to change the X11 libraries, preferably to support generic external proxy-starting commands, and you're done. Why ask for that here though? Nico -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From kevin at atomicgears.com Sat May 18 08:05:49 2002 From: kevin at atomicgears.com (Kevin Steves) Date: Fri, 17 May 2002 15:05:49 -0700 (PDT) Subject: [Fwd: Re: X-windows security in Gnome] In-Reply-To: <1021669179.21625.31.camel@peecee> Message-ID: On 17 May 2002, Gregory Leblanc wrote: :This is from a security discussion on one of the GNOME lists. Jim is :one of the original X11 people, for what that's worth. I just thought :I'd try to tempt some folks here into looking at doing ssh and X :integration "right". I'm not really certain what Jim is referring to. From an X11 purist standpoint we should use Xlib, Xau and maybe other X11 libs to do some of the stuff we do to make X11 forwarding function, but for security reasons we do not. From Jim_Donovan at Playstation.sony.com Sat May 18 08:26:30 2002 From: Jim_Donovan at Playstation.sony.com (Jim_Donovan at Playstation.sony.com) Date: Fri, 17 May 2002 15:26:30 -0700 Subject: [Bug 239] ssh didn't resolv name server on HPUX 11i Message-ID: A poster to the HP Support Forums site stated that patch PHCO_25568 fixes the ssh ssh: : host nor service provided, or not known problem you're encountering with ssh. See: http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x7a2618276953d61190040090279cd0f9,00.html for details Jim Donovan Sr. Systems Administrator Sony Computer Entertainment America From bugzilla-daemon at mindrot.org Sat May 18 08:32:21 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 08:32:21 +1000 (EST) Subject: [Bug 248] scp doesn't support ssh2 protocol Message-ID: <20020517223221.E37A3E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=248 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From mouring at eviladmin.org 2002-05-18 08:32 ------- This is an issue with how SSH Corp did their ssh 2.x and above clients. They decided that rcp over ssh was not good enough so they moved to sftp. As a result they also renamed sftp to scp2 and pretended as if the original scp did not exist. Please complain to them about breaking compatibility. There is nothing we can do about it. - Ben ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From austin at coremetrics.com Sat May 18 09:02:59 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 17 May 2002 18:02:59 -0500 Subject: OpenSSH 3.2.2 supports kerberos5 but.... Message-ID: <1021676579.12809.17.camel@UberGeek> I can't seem to login with only a TGS? (i.e. no password) Do I need another patch to have that part work? Password auth seems to be working against the KDC just fine. TIA. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "One ought never to turn one's back on a threatened danger and try to run away from it. If you do that, you will double the danger. But if you meet it promptly and without flinching, you will reduce the danger by half." Sir Winston Churchill -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020517/47c361a3/attachment.bin From bugzilla-daemon at mindrot.org Sat May 18 09:44:58 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 09:44:58 +1000 (EST) Subject: [Bug 164] X-forwarding when connecting to an IPv6-enabled host doesn't work. Message-ID: <20020517234458.E4A99E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=164 ------- Additional Comments From yoshfuji at linux-ipv6.org 2002-05-18 09:44 ------- Created an attachment (id=97) Try to set IPV6_V6ONLY if available. Open ::1 and 127.0.0.1 if x11_use_localhost is set. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dan at doxpara.com Sat May 18 10:18:05 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Fri, 17 May 2002 17:18:05 -0700 Subject: [Fwd: Re: X-windows security in Gnome] References: <9403F8EE868566448AA1B70D8F783C95334F20@NSTMC004PEX1.ubsgs.ubsgroup.net> Message-ID: <00da01c1fe01$7b302620$1701000a@effugas> > What else can possibly be done to integrate SSH and apps? I mean, it works, doesn't it? X could use SSH as the native transport for all non-localhost connections, actually instantiating ssh sessions on demand. This has...interesting security implications. It can imply an authentication mode that allows remote display forwarding but not command execution or port forwarding. Why not SSL? SSH's auth model is more flexible and useful. SSL client auth is...yeah. X has some issues, though. Global inter-window keyboard sniffing is in my mind far and away the largest security issue with X. Merely by having an open channel for X traffic to pass, a hostile daemon can sniff my keyboard activity -- even if I have *no* windows open from that other server. This is a huge issue that we've only addressed by removing Default X-Forwarding. Anyway, certainly more is *possible*. --Dan From bugzilla-daemon at mindrot.org Sat May 18 10:46:19 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 10:46:19 +1000 (EST) Subject: [Bug 249] New: open /dev/tty failed Message-ID: <20020518004619.C1686E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=249 Summary: open /dev/tty failed Product: Portable OpenSSH Version: -current Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: critical Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: sam at kalessin.jpl.nasa.gov built openssh-3.2.2p1 for solaris 2.7, 2.8. ssh works fine, but the sshd is not usable. Login proceeds past the password stage, then sometimes hangs. If not hung, then su fails. /var/adm/messages (login hung) says May 17 17:05:06 kalessin sshd[3846]: [ID 800047 auth.error] error: open /d\ ev/tty failed - could not set controlling tty: No such device or address OpenSSH_3.1p1 works fine. Here's the configure ./configure \ --sysconfdir=/etc/openssh \ --with-kerberos4=/opt/kerberos \ --with-pam \ --with-cflags=-I/dsw/gca-local/include \ --with-ldflags='-L/dsw/gca-local/lib -R/dsw/gca-local/lib' \ --with-ssl-dir=/dsw/gca-other/openssl-0.9.6d (openssh-3.1p1 was built with openssl-0.9c, if that makes a difference) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 18 11:13:43 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 11:13:43 +1000 (EST) Subject: [Bug 250] New: Attaching to controlling tty is broken on Solaris/UltraSparc Message-ID: <20020518011343.54E99E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=250 Summary: Attaching to controlling tty is broken on Solaris/UltraSparc Product: Portable OpenSSH Version: -current Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: AVShutko at mail.khstu.ru After upgrage OpenSSH 3.2.2p1 sshd doesn't work correctly under Solaris 8/UltraSparc. After login it write: sshd[6980]: [ID 800047 auth.error] error: open /dev/tty failed - could not set controlling tty: No such device or address... And then su doesn't ask password and write: Sorry.. :) Then I compiled OpenSSH 3.1p1 and it is works just fine... And there is one more problem... On Solaris box after activating BSM security root can't change crontab file correctly thru sshd (some problem with cridentians ?). Telnet/Console crontab changes works good... But sshd not... This behavior can be solved using "UseLogin yes" directive in sshd_config System: SunFire880 (8 cpu/16Gb RAM, m64 video); Solaris 8 10/01 with latest patches; compiler GCC 2.95.3 20010315; GNU Make version 3.79.1; configure called with --with- prngd-socket=/var/spool/prngd/pool parameter..... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 18 11:34:54 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 11:34:54 +1000 (EST) Subject: [Bug 249] open /dev/tty failed Message-ID: <20020518013454.F3143E8EA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=249 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From stevesk at pobox.com 2002-05-18 11:34 ------- please search for dups before sumitting new bugs folks. *** This bug has been marked as a duplicate of 245 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 18 11:34:59 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 11:34:59 +1000 (EST) Subject: [Bug 245] SSH can not log out under Solaris 2.6 Message-ID: <20020518013459.9C89FE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=245 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sam at kalessin.jpl.nasa.gov ------- Additional Comments From stevesk at pobox.com 2002-05-18 11:34 ------- *** Bug 249 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 18 11:37:22 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 11:37:22 +1000 (EST) Subject: [Bug 250] Attaching to controlling tty is broken on Solaris/UltraSparc Message-ID: <20020518013722.4DC34E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=250 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From stevesk at pobox.com 2002-05-18 11:37 ------- dup, and openssh doesn't support BSM natively right now. *** This bug has been marked as a duplicate of 245 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 18 11:37:27 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 11:37:27 +1000 (EST) Subject: [Bug 245] SSH can not log out under Solaris 2.6 Message-ID: <20020518013727.1F978E902@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=245 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |AVShutko at mail.khstu.ru ------- Additional Comments From stevesk at pobox.com 2002-05-18 11:37 ------- *** Bug 250 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Douglas.Chimento at FMR.COM Sat May 18 14:05:47 2002 From: Douglas.Chimento at FMR.COM (Chimento, Douglas) Date: Sat, 18 May 2002 00:05:47 -0400 Subject: uidswap Message-ID: <13619E2D7C7ED748ADD005E8D6C748F3A78386@MSGBOS684NTS.fmr.com> This bug has already been reported as bug 136, Sorry to be a bother -----Original Message----- From: Chimento, Douglas [mailto:Douglas.Chimento at fmr.com] Sent: Friday, May 17, 2002 10:27 AM To: openssh-unix-dev at mindrot.org Subject: RE: uidswap Thanks Markkus. Please excuse my ignorance , I am not much of a UNIX programmer but I believe I see a potential issue. Suppose ssh in NOT installed setuid root. If you take a look at the function permanently_set_uid() in uidswap.c ( line 146 in 3.1p1 ) I believe these lines below can fail unexpectedly: if (setgid(pw->pw_gid) < 0) fatal("setgid %u: %.100s", (u_int) pw->pw_gid, strerror(errno)); Here's why , Suppose you "switch" primary group id with the newgrp command. ( For instance: [doug at host ~]$ id uid=1065(doug) gid=100(staff) [doug at host ~]$ newgrp test [doug at host ~]$ id uid=1065(doug) gid=1001(test) [doug at host ~]$ ) Now clearly pw->pw_gid != getgid() and so setgid(pw->pw_gid) will always fail because the user is no longer a part of pw->pw_gid group. ( I hope that made sense ). I think the solution would be to do what is done in the restore_uid() function ( line 108 in uidswap.c ). That is, check to see if the user is "privileged". So we could have this in permanently_set_uid(): { if (temporarily_use_uid_effective) fatal("restore_uid: temporarily_use_uid effective"); if (!privileged) return; if (setgid(pw->pw_gid) < 0) fatal("setgid %u: %.100s", (u_int) pw->pw_gid, strerror(errno)); if (setuid(pw->pw_uid) < 0) fatal("setuid %u: %.100s", (u_int) pw->pw_uid, strerror(errno)); } instead of.... { if (temporarily_use_uid_effective) fatal("restore_uid: temporarily_use_uid effective"); if (setgid(pw->pw_gid) < 0) fatal("setgid %u: %.100s", (u_int) pw->pw_gid, strerror(errno)); if (setuid(pw->pw_uid) < 0) fatal("setuid %u: %.100s", (u_int) pw->pw_uid, strerror(errno)); } What are your thoughts? Thanks for your time. -----Original Message----- From: Markus Friedl [mailto:markus at openbsd.org] Sent: Thursday, May 16, 2002 7:18 PM To: Chimento, Douglas Cc: openssh-unix-dev at mindrot.org Subject: Re: uidswap On Thu, May 16, 2002 at 04:32:11PM -0400, Chimento, Douglas wrote: > What are the consequnences if you do not install ssh setuid > root? ( As far I as know no uid swaping occurs ) hostbased authentication won't work. _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From bugzilla-daemon at mindrot.org Sat May 18 17:48:31 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 17:48:31 +1000 (EST) Subject: [Bug 245] SSH can not log out under Solaris 2.6 Message-ID: <20020518074831.24532E8EA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=245 ------- Additional Comments From rl at math.technion.ac.il 2002-05-18 17:48 ------- Another manifestation of the bug, on solaris 8, was that the ps command broke, with the message "no controlling terminal". Using the proposed patch solved the problem completely. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 18 18:15:19 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 18 May 2002 18:15:19 +1000 (EST) Subject: [Bug 251] New: openssh-3.2.2p1-1.src.rpm won't build under RH6.2 Message-ID: <20020518081519.BA3ECE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=251 Summary: openssh-3.2.2p1-1.src.rpm won't build under RH6.2 Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: seba at iq.pl Openssl updated to openssl-0.9.6b-18 error: /usr/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load': dso_dlfcn.o(.text+0xb9): undefined reference to `dlopen' dso_dlfcn.o(.text+0xc8): undefined reference to `dlopen' dso_dlfcn.o(.text+0x121): undefined reference to `dlclose' /usr/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_unload': dso_dlfcn.o(.text+0x192): undefined reference to `dlclose' /usr/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var': dso_dlfcn.o(.text+0x253): undefined reference to `dlsym' /usr/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func': dso_dlfcn.o(.text+0x305): undefined reference to `dlsym' collect2: ld returned 1 exit status make: *** [ssh] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.23187 (%build) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From pekkas at netcore.fi Sat May 18 20:10:31 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 18 May 2002 13:10:31 +0300 (EEST) Subject: OpenSSH 3.2.2 released : chroot In-Reply-To: Message-ID: On Fri, 17 May 2002, Ben Lindstrom wrote: > Out of interest why do you feel it's required to do chroot() at the > OpenSSH level? Why don't you invest time into a shell that does the > chroot() for you? That would work for telnet, ssh, etc. No need to > clutter up OpenSSH with options that can easily be implemented at a higher > level. One word: sftp. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From kouril at ics.muni.cz Sat May 18 21:24:00 2002 From: kouril at ics.muni.cz (Daniel Kouril) Date: Sat, 18 May 2002 13:24:00 +0200 Subject: Curious about final KRB5/GSSAPI patch inclusion. In-Reply-To: <1021583092.8629.0.camel@UberGeek>; from austin@coremetrics.com on Thu, May 16, 2002 at 04:04:52PM -0500 References: <1021583092.8629.0.camel@UberGeek> Message-ID: <20020518132400.A18970@odorn.ics.muni.cz> On Thu, May 16, 2002 at 04:04:52PM -0500, Austin Gonyou wrote: > Darn it....most of the krb5 code is there already. :( Should it be > removed, or is the plan to wait till flux is at a minimum or no longer, > and go ahead anyway? GSSAPI is not krb5 at all. Besides krb5 implementations of GSS-API, there is also a widely used implementation based on SSL and X.509 authentication (www.globus.org/security/). Thus, the same openssh binary compiled with GSS-API support can work either with krb5 or X.509 authentication -- the only thing you have to do is supply the rigth gssapi library. And when some more sophisticated implementation of gss library is available (I mean mechglue or something similar), more different methods could be used with the same GSS code at once. I would really appreciate adding of the Simon's code. There are many users who are already using it at this time and who must mantain a separate openssh distribution. > > On Wed, 2002-05-15 at 22:03, Damien Miller wrote: > > On 15 May 2002, Austin Gonyou wrote: > > > > > What is the target version for all the KRB5 bits to be in place. I > > know > > > there is very much in place right now, but I remember someone > > mentioning > > > there was just a GSSAPI/MITKRB5 patch being waited for. > > > > The GSSAPI patch has not been included - it is based on a protocol > > spec > > which seems to be still in flux. > > > > -d > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin at coremetrics.com > > "One ought never to turn one's back on a threatened danger and > try to run away from it. If you do that, you will double the danger. > But if you meet it promptly and without flinching, you will > reduce the danger by half." > Sir Winston Churchill From jm.poure at freesurf.fr Sat May 18 21:49:14 2002 From: jm.poure at freesurf.fr (Jean-Michel POURE) Date: Sat, 18 May 2002 13:49:14 +0200 Subject: OpenSSH 3.2.2 released : chroot In-Reply-To: <20020517162738.GF23204@enoch.org> References: <200205171701.15016.jm.poure@freesurf.fr> <20020517162738.GF23204@enoch.org> Message-ID: <200205181349.14327.jm.poure@freesurf.fr> Le Vendredi 17 Mai 2002 18:27, Mike Johnson a ?crit : > Because, like you said, that required the shell to do it. I'd rather > trust OpenSSH to 'do the right thing' than a shell. Plus, it's harder > to break out of the OpenSSH chroot, than the shell based one. Dear all, Many users, like myself, do not have the knowledge to set up a decent chroot shell. Therefore, I would be very happy if a chroot patch was accepted. Cheers, Jean-Michel From jm.poure at freesurf.fr Sat May 18 21:55:04 2002 From: jm.poure at freesurf.fr (Jean-Michel POURE) Date: Sat, 18 May 2002 13:55:04 +0200 Subject: OpenSSH 3.2.2 released : chroot In-Reply-To: References: Message-ID: <200205181355.04668.jm.poure@freesurf.fr> Le Vendredi 17 Mai 2002 18:05, Ben Lindstrom a ?crit : > Out of interest why do you feel it's required to do chroot() at the > OpenSSH level? Why don't you invest time into a shell that does the > chroot() for you? That would work for telnet, ssh, etc. No need to > clutter up OpenSSH with options that can easily be implemented at a higher > level. Hello Ben, Could you point out a chroot howto at shell level? I would like to set up such a solution for testing. Can it really be done by some beginner like myself? Cheers, Jean-Michel POURE From jm.poure at freesurf.fr Sat May 18 21:57:52 2002 From: jm.poure at freesurf.fr (Jean-Michel POURE) Date: Sat, 18 May 2002 13:57:52 +0200 Subject: OpenSSH 3.2.2 released : chroot In-Reply-To: <20020517171808.GG23204@enoch.org> References: <20020517162738.GF23204@enoch.org> <20020517171808.GG23204@enoch.org> Message-ID: <200205181357.52027.jm.poure@freesurf.fr> Le Vendredi 17 Mai 2002 19:18, Mike Johnson a ?crit : > Yup. I've been maintaining my own. But, I have to admit that after > reading your mail a few times, it makes sense. At the very least, I > wouldn't have to keep updating the damned patch for every OpenSSH > release. I can help you build RPMs for Mandrake and RedHat paltforms. There are many users interested by this chroot patch. I need an easy solution which can be installed "right-out-of-the-box" with an RPM. Setting a chrooted shell environment is too difficult for me. Cheers, Jean-Michel From phil-openssh-unix-dev at ipal.net Sat May 18 22:53:50 2002 From: phil-openssh-unix-dev at ipal.net (Phil Howard) Date: Sat, 18 May 2002 07:53:50 -0500 Subject: OpenSSH 3.2.2p1 sshd: fatal: xfree: NULL pointer given as argument Message-ID: <20020518125350.GA14317@vega.ipal.net> Server host config: Slackware 8.0 (custom boot scripts) glibc-2.2.3 gcc-2.95.3 Linux-2.4.18 Client host config: (same as server) Symptom: session disconnects with no message to client: ============================================================================= phil at antares:/home/phil 153> ssh -V OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f phil at antares:/home/phil 154> ssh -p 10 root at polaris.ipal.net Connection closed by 209.102.208.19 phil at antares:/home/phil 155> ============================================================================= phil at polaris:/home/phil 1> ssh -V OpenSSH_3.2.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f phil at polaris:/home/phil 2> ssh -p 10 root at polaris.ipal.net Connection closed by 209.102.208.19 phil at polaris:/home/phil 3> ============================================================================= Message in syslog on server: fatal: xfree: NULL pointer given as argument Additional test: Telnet to SSH port (test port 10, not 22) shows normal banner and after pressing return gives "Protocol mismatch." as normally seen when using telnet to sshd (e.g. the above error must be later in the protocol sequence than raw telnet would engage). Debug output (-ddd -e): ============================================================================= debug3: cipher ok: aes256-cbc [aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,3des-cbc] debug3: cipher ok: aes192-cbc [aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,3des-cbc] debug3: cipher ok: aes128-cbc [aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,3des-cbc] debug3: cipher ok: blowfish-cbc [aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,3des-cbc] debug3: cipher ok: 3des-cbc [aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,3des-cbc] debug3: ciphers ok: [aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,3des-cbc] debug1: sshd version OpenSSH_3.2.2p1 debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #0 type 2 DSA debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug1: Bind to port 10 on 0.0.0.0. Server listening on 0.0.0.0 port 10. debug1: Server will not fork when running in debugging mode. Connection from 209.102.208.19 port 32846 debug1: Client protocol version 2.0; client software version OpenSSH_3.2.2p1 debug1: match: OpenSSH_3.2.2p1 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.2.2p1 debug1: list_hostkey_types: ssh-dss,ssh-rsa debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss,ssh-rsa debug2: kex_parse_kexinit: aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: 3des-cbc,blowfish-cbc debug2: kex_parse_kexinit: 3des-cbc,blowfish-cbc debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: zlib debug2: kex_parse_kexinit: zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: client->server 3des-cbc hmac-md5 zlib debug2: mac_init: found hmac-md5 debug1: kex: server->client 3des-cbc hmac-md5 zlib debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: dh_gen_key: priv key bits set: 194/384 debug1: bits set: 1047/2049 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 1031/2049 xfree: NULL pointer given as argument debug1: Calling cleanup 0x806b00c(0x0) ============================================================================= Server config file: (Note, this is for port 10 used for testing, not port 22) ============================================================================= Port 10 ListenAddress 0.0.0.0 Banner /etc/ssh/sshd_banner_10 AllowGroups root wheel ssh10 staff sys adm admin Ciphers aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,3des-cbc ClientAliveInterval 0 ClientAliveCountMax 3 DenyGroups nossh nossh10 DenyUsers nobody DSAAuthentication yes GatewayPorts yes HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_rsa_key IgnoreRhosts yes IgnoreUserKnownHosts yes KeepAlive no LoginGraceTime 600 LogLevel INFO MaxStartups 32:50:64 PasswordAuthentication yes PermitEmptyPasswords no PermitRootLogin yes PidFile /var/run/sshd_10.pid PrintLastLog yes PrintMotd yes Protocol 2 PubkeyAuthentication yes StrictModes yes SyslogFacility AUTH UseLogin no VerifyReverseMapping no X11DisplayOffset 10 X11Forwarding yes X11UseLocalhost yes ============================================================================= -- ----------------------------------------------------------------- | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/ | ----------------------------------------------------------------- From djast at cs.toronto.edu Sat May 18 22:56:38 2002 From: djast at cs.toronto.edu (Dan Astoorian) Date: Sat, 18 May 2002 08:56:38 -0400 Subject: OpenSSH 3.2.2 released : chroot In-Reply-To: Message from Pekka Savola of "Sat, 18 May 2002 06:10:31 EDT." Message-ID: <02May18.085647edt.453131-474@jane.cs.toronto.edu> On Sat, 18 May 2002 06:10:31 EDT, Pekka Savola writes: > On Fri, 17 May 2002, Ben Lindstrom wrote: > > Out of interest why do you feel it's required to do chroot() at the > > OpenSSH level? Why don't you invest time into a shell that does the > > chroot() for you? That would work for telnet, ssh, etc. No need to > > clutter up OpenSSH with options that can easily be implemented at a higher > > level. > > One word: sftp. How is sftp different from any other application or subsystem? If the user's login shell is a wrapper which calls chroot() and then runs a real shell, then sftp-server will be wrapped along with anything else the user could run via ssh. Incidentally, does the chroot patch work with UsePrivilegeSeparation=yes? I haven't tried it, but I suspect it might not work, since my understanding of UsePrivilegeSeparation is that the child process never runs with sufficient privileges for the chroot() to succeed. However, a wrapper program wouldn't have that sort of problem. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From hyun10310 at kornet.net Sat May 18 22:13:24 2002 From: hyun10310 at kornet.net (��) Date: Sat, 18 May 2002 21:13:24 +0900 Subject: (no subject) Message-ID: <20020518131841.BBEF6E8EA@shitei.mindrot.org> An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020518/f5cea862/attachment.html From rdawes at mweb.co.za Sat May 18 23:16:59 2002 From: rdawes at mweb.co.za (Rogan Dawes) Date: Sat, 18 May 2002 15:16:59 +0200 Subject: OpenSSH library Message-ID: <01dd01c1fe6e$519a9f30$497d1ec4@rampage> Hi folks, I was thinking about the possibility of separating the OpenSSH transport and authentication functions from the terminal emulation functions, and making it available as a library for other applications to use for secure authenticated transport. My thinking is along the lines of: A whole bunch of applications have implemented "secure" versions of the transport protocol, using SSL (e.g. POP3S, IMAPS, NNTPS, IRC - I think), however, they did not address the authentication problems at the same time in a more flexible manner than client certificates. E.g. POP3 over SSL, but you still use a possibly weak password to authenticate. I can certainly imagine a whole class of developers who would love to be able to replace a standard connect() call, followed by an authentication process, with a simple ssh_connect() call. That way, they would not have to worry about handling the various possible authentication combinations, as well as being able to handle new authentication methods as SSH matures and evolves, with little effort on their part in reimplementing them, other than adding a configuration option in the application config files. Ultimately, they would be able to know that, as a server process, any data that comes out of the fd is securely authenticated as coming from the user returned by a ssh_get_user() call. The OpenSSH daemon could be implemented something like: Daemon starts up, reads the config file, initialises the ssh_transport library with parameters such as acceptable auth methods, location of keyauth files, port-forwarding allowed, etc, and then the library starts listening for connections. When a connection is received, the library handles all the negotiation of algorithms and authentication methods, and once an acceptable authentication occurs, the file descriptor (fd) is returned to the daemon. A library function would return the UID of the user associated with the fd, and the daemon would then continue with the shell specific functions, such as opening pty's, setuid(user), executing .ssh/rc, and spawning a shell. One immediate use I could see for this is in writing a graphical SCP/SFTP client, since the GUI developer would not need to worry about re-implementing the security part, and could instead concentrate on the functionality and usability of the GUI client. Similarly, this could be used by someone writing an SFTPD, listening on a non-port-22, where SFTPD includes all the functionality of, say, wu-ftpd, or the openbsd ftpd, such as chroot, limits, etc, and does not need to create chroot jails with shells, etc in them for users that just want to transfer files. SFTPD users would have their own keyauth files, say in .ssh/sftpd_authorized_keys, which would not be read by a normal SSH daemon, and thus would not imply allowing FTP only users access to a shell. I can imagine that I will get a bunch of answers saying that people who are not interested in security should not be implementing things like FTP daemons, etc, but I think that it is more intelligent to rely on a group that IS interested in security to do it properly, and reuse those efforts where possible. I can also imagine answers like "We don't like libraries in security critical code, the fewer interfaces, the fewer mistakes". Maybe that's valid, I don't know, and will bow to experience. I would just like to see more use of secure protocols, and think that this might be one way of achieving it. Comments? Rogan From pekkas at netcore.fi Sat May 18 23:54:22 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 18 May 2002 16:54:22 +0300 (EEST) Subject: OpenSSH 3.2.2 released : chroot In-Reply-To: <02May18.085647edt.453131-474@jane.cs.toronto.edu> Message-ID: On Sat, 18 May 2002, Dan Astoorian wrote: > On Sat, 18 May 2002 06:10:31 EDT, Pekka Savola writes: > > On Fri, 17 May 2002, Ben Lindstrom wrote: > > > Out of interest why do you feel it's required to do chroot() at the > > > OpenSSH level? Why don't you invest time into a shell that does the > > > chroot() for you? That would work for telnet, ssh, etc. No need to > > > clutter up OpenSSH with options that can easily be implemented at a higher > > > level. > > > > One word: sftp. > > How is sftp different from any other application or subsystem? Sftp is moderately self-sufficient. Trying to invent a "magic bullet" for e.g. chrooting shell is rather difficult and not really usable for most people (because of the troubles with populating chroot directories; with sftp there is no such need). So, really.. the only difference is pragmatic: sftp should be relatively easy to chroot in practise -- in contrast to e.g. shell, and very usable for most people ("ftp + chroot to homedirs replacement"). > If the user's login shell is a wrapper which calls chroot() and then > runs a real shell, then sftp-server will be wrapped along with anything > else the user could run via ssh. A wrapper would be fine by me. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From mouring at etoh.eviladmin.org Sun May 19 00:16:22 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 18 May 2002 09:16:22 -0500 (CDT) Subject: OpenSSH 3.2.2 released : chroot In-Reply-To: Message-ID: ${YOURSHELL} -c {$PATHTOSUBSYSTEM}/${SUBSYSTEMPROGRAM} Looks pretty simple to solve. Just like the scp issue. ain't anything special around here. - Ben On Sat, 18 May 2002, Pekka Savola wrote: > On Fri, 17 May 2002, Ben Lindstrom wrote: > > Out of interest why do you feel it's required to do chroot() at the > > OpenSSH level? Why don't you invest time into a shell that does the > > chroot() for you? That would work for telnet, ssh, etc. No need to > > clutter up OpenSSH with options that can easily be implemented at a higher > > level. > > One word: sftp. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > From Ray.Caruso at netvion.com Sun May 19 01:41:55 2002 From: Ray.Caruso at netvion.com (Ray Caruso) Date: Sat, 18 May 2002 08:41:55 -0700 Subject: OpenSSH library In-Reply-To: <01dd01c1fe6e$519a9f30$497d1ec4@rampage> Message-ID: <5.1.0.14.0.20020518084023.01ffaf20@antero> I think this is a great idea. There are many applications for this lib. I actually started to investigate this a while back. At 06:16 AM Saturday 5/18/2002, Rogan Dawes wrote: >Hi folks, > >I was thinking about the possibility of separating the OpenSSH transport and >authentication functions from the terminal emulation functions, and making >it available as a library for other applications to use for secure >authenticated transport. > >My thinking is along the lines of: > >A whole bunch of applications have implemented "secure" versions of the >transport protocol, using SSL (e.g. POP3S, IMAPS, NNTPS, IRC - I think), >however, they did not address the authentication problems at the same time >in a more flexible manner than client certificates. > >E.g. POP3 over SSL, but you still use a possibly weak password to >authenticate. > >I can certainly imagine a whole class of developers who would love to be >able to replace a standard connect() call, followed by an authentication >process, with a simple ssh_connect() call. That way, they would not have to >worry about handling the various possible authentication combinations, as >well as being able to handle new authentication methods as SSH matures and >evolves, with little effort on their part in reimplementing them, other than >adding a configuration option in the application config files. > >Ultimately, they would be able to know that, as a server process, any data >that comes out of the fd is securely authenticated as coming from the user >returned by a ssh_get_user() call. > >The OpenSSH daemon could be implemented something like: > >Daemon starts up, reads the config file, initialises the ssh_transport >library with parameters such as acceptable auth methods, location of keyauth >files, port-forwarding allowed, etc, and then the library starts listening >for connections. > >When a connection is received, the library handles all the negotiation of >algorithms and authentication methods, and once an acceptable authentication >occurs, the file descriptor (fd) is returned to the daemon. A library >function would return the UID of the user associated with the fd, and the >daemon would then continue with the shell specific functions, such as >opening pty's, setuid(user), executing .ssh/rc, and spawning a shell. > >One immediate use I could see for this is in writing a graphical SCP/SFTP >client, since the GUI developer would not need to worry about >re-implementing the security part, and could instead concentrate on the >functionality and usability of the GUI client. > >Similarly, this could be used by someone writing an SFTPD, listening on a >non-port-22, where SFTPD includes all the functionality of, say, wu-ftpd, or >the openbsd ftpd, such as chroot, limits, etc, and does not need to create >chroot jails with shells, etc in them for users that just want to transfer >files. > >SFTPD users would have their own keyauth files, say in >.ssh/sftpd_authorized_keys, which would not be read by a normal SSH daemon, >and thus would not imply allowing FTP only users access to a shell. > >I can imagine that I will get a bunch of answers saying that people who are >not interested in security should not be implementing things like FTP >daemons, etc, but I think that it is more intelligent to rely on a group >that IS interested in security to do it properly, and reuse those efforts >where possible. > >I can also imagine answers like "We don't like libraries in security >critical code, the fewer interfaces, the fewer mistakes". Maybe that's >valid, I don't know, and will bow to experience. I would just like to see >more use of secure protocols, and think that this might be one way of >achieving it. > >Comments? > >Rogan > > >_______________________________________________ >openssh-unix-dev at mindrot.org mailing list >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From austin at coremetrics.com Sun May 19 04:42:33 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 18 May 2002 13:42:33 -0500 Subject: Curious about final KRB5/GSSAPI patch inclusion. In-Reply-To: <20020518132400.A18970@odorn.ics.muni.cz> References: <20020518132400.A18970@odorn.ics.muni.cz> Message-ID: <1021747353.15919.2.camel@UberGeek> On Sat, 2002-05-18 at 06:24, Daniel Kouril wrote: > On Thu, May 16, 2002 at 04:04:52PM -0500, Austin Gonyou wrote: > > Darn it....most of the krb5 code is there already. :( Should it be > > removed, or is the plan to wait till flux is at a minimum or no > longer, > > and go ahead anyway? > > GSSAPI is not krb5 at all. Besides krb5 implementations of GSS-API, > there is > also a widely used implementation based on SSL and X.509 > authentication ... Ahh...this makes sense now. > I would really appreciate adding of the Simon's code. There are many > users > who are already using it at this time and who must mantain a > separate openssh > distribution. > Simon, or anyone else, If you're listening, can you let us know if there will be a new patch set for 3.2.2p1 for gssapi or mit-kerberos pieces like before. As I stated in latest mail, krb5 auth works with passwords only as far as I can tell right now. Ticket based auth does *not* seem to work. TIA. > > > > On Wed, 2002-05-15 at 22:03, Damien Miller wrote: > > > On 15 May 2002, Austin Gonyou wrote: > > > > > > > What is the target version for all the KRB5 bits to be in > place. I > > > know > > > > there is very much in place right now, but I remember someone > > > mentioning > > > > there was just a GSSAPI/MITKRB5 patch being waited for. > > > > > > The GSSAPI patch has not been included - it is based on a > protocol > > > spec > > > which seems to be still in flux. > > > > > > -d > > -- > > Austin Gonyou > > Systems Architect, CCNA > > Coremetrics, Inc. > > Phone: 512-698-7250 > > email: austin at coremetrics.com > > > > "One ought never to turn one's back on a threatened danger and > > try to run away from it. If you do that, you will double the > danger. > > But if you meet it promptly and without flinching, you will > > reduce the danger by half." > > Sir Winston Churchill -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "One ought never to turn one's back on a threatened danger and try to run away from it. If you do that, you will double the danger. But if you meet it promptly and without flinching, you will reduce the danger by half." Sir Winston Churchill -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020518/10b542b4/attachment.bin From kevin at atomicgears.com Sun May 19 08:56:44 2002 From: kevin at atomicgears.com (Kevin Steves) Date: Sat, 18 May 2002 15:56:44 -0700 Subject: OpenSSH 3.2.2p1 sshd: fatal: xfree: NULL pointer given as argument In-Reply-To: <20020518125350.GA14317@vega.ipal.net> References: <20020518125350.GA14317@vega.ipal.net> Message-ID: <20020518225644.GA13680@jenny.crlsca.adelphia.net> On Sat, May 18, 2002 at 07:53:50AM -0500, Phil Howard wrote: > debug1: dh_gen_key: priv key bits set: 194/384 > debug1: bits set: 1047/2049 > debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT > debug1: bits set: 1031/2049 > xfree: NULL pointer given as argument > debug1: Calling cleanup 0x806b00c(0x0) Can you narrow the config down a bit in terms of what may cause this, or get a stack trace? From hyun10310 at kornet.net Sun May 19 13:01:44 2002 From: hyun10310 at kornet.net (�Ѱ渮ġ��Ŭ��) Date: Sun, 19 May 2002 12:01:44 +0900 Subject: ��, �� ʴϴ�.[��] Message-ID: <20020519025949.CE0A0E881@shitei.mindrot.org> An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020519/21516b5a/attachment.html From mouring at etoh.eviladmin.org Sun May 19 14:14:33 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 18 May 2002 23:14:33 -0500 (CDT) Subject: OpenSSH library In-Reply-To: <5.1.0.14.0.20020518084023.01ffaf20@antero> Message-ID: This has come up a few times, but the issue as Markus has stated it the current libssh.a is really just a collection of object files to improve compile preformance. The other issue you will face is if you want to do hostbased authentication (like the .shost, etc style) the binary in question that is linked to libssh.a will have to be setuid root. I think it may more useful to take the sftp*.[ch] framework and build it into a library/wrapper. That way you can leverage OpenSSH or SSH Corp or "John Joe's Local SSH install" without having to create yet another setuid binary. Personally I like this approach for a few reasons. The main reason is I believe it could be provided with a simple interface like below. ssh_password_callback(callback_passwd); fd = ssh_connect("site"); {int,int64,char*)get_buffer{_int,_int64,}(fd); ssh_close(fd); Granted, I'm not looking at the code so it may need a bit more TLC. But if memory serves right that is pretty much all sftp does at it's core. The other advantage this could bring is the ability to pass -o commands to the ssh client which would not be part of the libssh.a since it would be too low level for such concepts. Thus making code reuse much higher. Only issue is SSH Corp and OpenSSH's -o commands are different, but one could handle it cleanly if they spent some time and pondered it. Consider that, and have fun.=) - Ben On Sat, 18 May 2002, Ray Caruso wrote: > I think this is a great idea. There are many applications for this lib. I > actually started to investigate this a while back. > > > > At 06:16 AM Saturday 5/18/2002, Rogan Dawes wrote: > >Hi folks, > > > >I was thinking about the possibility of separating the OpenSSH transport and > >authentication functions from the terminal emulation functions, and making > >it available as a library for other applications to use for secure > >authenticated transport. > > > >My thinking is along the lines of: > > > >A whole bunch of applications have implemented "secure" versions of the > >transport protocol, using SSL (e.g. POP3S, IMAPS, NNTPS, IRC - I think), > >however, they did not address the authentication problems at the same time > >in a more flexible manner than client certificates. > > > >E.g. POP3 over SSL, but you still use a possibly weak password to > >authenticate. > > > >I can certainly imagine a whole class of developers who would love to be > >able to replace a standard connect() call, followed by an authentication > >process, with a simple ssh_connect() call. That way, they would not have to > >worry about handling the various possible authentication combinations, as > >well as being able to handle new authentication methods as SSH matures and > >evolves, with little effort on their part in reimplementing them, other than > >adding a configuration option in the application config files. > > > >Ultimately, they would be able to know that, as a server process, any data > >that comes out of the fd is securely authenticated as coming from the user > >returned by a ssh_get_user() call. > > > >The OpenSSH daemon could be implemented something like: > > > >Daemon starts up, reads the config file, initialises the ssh_transport > >library with parameters such as acceptable auth methods, location of keyauth > >files, port-forwarding allowed, etc, and then the library starts listening > >for connections. > > > >When a connection is received, the library handles all the negotiation of > >algorithms and authentication methods, and once an acceptable authentication > >occurs, the file descriptor (fd) is returned to the daemon. A library > >function would return the UID of the user associated with the fd, and the > >daemon would then continue with the shell specific functions, such as > >opening pty's, setuid(user), executing .ssh/rc, and spawning a shell. > > > >One immediate use I could see for this is in writing a graphical SCP/SFTP > >client, since the GUI developer would not need to worry about > >re-implementing the security part, and could instead concentrate on the > >functionality and usability of the GUI client. > > > >Similarly, this could be used by someone writing an SFTPD, listening on a > >non-port-22, where SFTPD includes all the functionality of, say, wu-ftpd, or > >the openbsd ftpd, such as chroot, limits, etc, and does not need to create > >chroot jails with shells, etc in them for users that just want to transfer > >files. > > > >SFTPD users would have their own keyauth files, say in > >.ssh/sftpd_authorized_keys, which would not be read by a normal SSH daemon, > >and thus would not imply allowing FTP only users access to a shell. > > > >I can imagine that I will get a bunch of answers saying that people who are > >not interested in security should not be implementing things like FTP > >daemons, etc, but I think that it is more intelligent to rely on a group > >that IS interested in security to do it properly, and reuse those efforts > >where possible. > > > >I can also imagine answers like "We don't like libraries in security > >critical code, the fewer interfaces, the fewer mistakes". Maybe that's > >valid, I don't know, and will bow to experience. I would just like to see > >more use of secure protocols, and think that this might be one way of > >achieving it. > > > >Comments? > > > >Rogan > > > > > >_______________________________________________ > >openssh-unix-dev at mindrot.org mailing list > >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From carson at taltos.org Sun May 19 15:43:59 2002 From: carson at taltos.org (Carson Gaspar) Date: Sun, 19 May 2002 01:43:59 -0400 Subject: Curious about final KRB5/GSSAPI patch inclusion. In-Reply-To: <20020518132400.A18970@odorn.ics.muni.cz> References: <20020518132400.A18970@odorn.ics.muni.cz> Message-ID: <266088109.1021772639@[192.168.0.2]> --On Saturday, May 18, 2002 1:24 PM +0200 Daniel Kouril wrote: > Thus, the same openssh binary compiled with > GSS-API support can work either with krb5 or X.509 authentication -- the > only thing you have to do is supply the rigth gssapi library. And when > some more sophisticated implementation of gss library is available (I > mean mechglue or something similar), more different methods could be used > with the same GSS code at once. Ummm... sort-of. GSS-API is _not_ an ABI (binary interface), it's an source level API. And each underlying method uses different datatypes. So combining more than one in the same binary is non-trivial. And you can't just add a new .o - you have to recompile everything that references a GSS-API datatype. Feh. Of course, my GSS-API knowledge is a bit stale, so it's possible they've fixed something. But it definitely used to suck. -- Carson From phil-openssh-unix-dev at ipal.net Sun May 19 19:04:31 2002 From: phil-openssh-unix-dev at ipal.net (Phil Howard) Date: Sun, 19 May 2002 04:04:31 -0500 Subject: OpenSSH 3.2.2p1 sshd: fatal: xfree: NULL pointer given as argument In-Reply-To: <20020518225644.GA13680@jenny.crlsca.adelphia.net> References: <20020518125350.GA14317@vega.ipal.net> <20020518225644.GA13680@jenny.crlsca.adelphia.net> Message-ID: <20020519090431.GA1023@vega.ipal.net> On Sat, May 18, 2002 at 03:56:44PM -0700, Kevin Steves wrote: | On Sat, May 18, 2002 at 07:53:50AM -0500, Phil Howard wrote: | > debug1: dh_gen_key: priv key bits set: 194/384 | > debug1: bits set: 1047/2049 | > debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT | > debug1: bits set: 1031/2049 | > xfree: NULL pointer given as argument | > debug1: Calling cleanup 0x806b00c(0x0) | | Can you narrow the config down a bit in terms of what may cause this, | or get a stack trace? It's the config I've been using for ages. What's to narrow down? If you have a different config you would like me to try, I can do that. Or should I take each line out one at a time? What is the means to run this to get a stack trace? I just discovered that when the 3.2.2p1 client connects to a 3.1p1 server, the client dies with the same error message: xfree: NULL pointer given as argument I don't know if it would have done that with the 3.2.2p1 server had the server not died first. All my key files were built in earlier versions of OpenSSH (most even before 3.1p1). Here is the full debug level 3 of the client running (209 lines): ============================================================================= OpenSSH_3.2.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f debug1: Reading configuration data /home/phil/.ssh/config debug1: Applying options for * debug3: cipher ok: 3des-cbc [3des-cbc,blowfish-cbc] debug3: cipher ok: blowfish-cbc [3des-cbc,blowfish-cbc] debug3: ciphers ok: [3des-cbc,blowfish-cbc] debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 600 geteuid 0 anon 1 debug1: Connecting to hamal [209.102.192.71] port 22. debug1: temporarily_use_uid: 600/600 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 600/600 (e=0) debug1: restore_uid debug1: Connection established. debug3: Not a RSA1 key file /home/phil/.ssh/id0. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file /home/phil/.ssh/id0 type -1 debug3: Not a RSA1 key file /home/phil/.ssh/id1. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file /home/phil/.ssh/id1 type -1 debug3: Not a RSA1 key file /home/phil/.ssh/id2. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file /home/phil/.ssh/id2 type -1 debug3: Not a RSA1 key file /home/phil/.ssh/id3. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file /home/phil/.ssh/id3 type -1 debug3: Not a RSA1 key file /home/phil/.ssh/id4. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file /home/phil/.ssh/id4 type -1 debug3: Not a RSA1 key file /home/phil/.ssh/id5. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file /home/phil/.ssh/id5 type -1 debug3: Not a RSA1 key file /home/phil/.ssh/id6. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file /home/phil/.ssh/id6 type -1 debug1: identity file /home/phil/.ssh/id7 type -1 debug1: identity file /home/phil/.ssh/id8 type -1 debug1: identity file /home/phil/.ssh/id9 type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.1p1 debug1: match: OpenSSH_3.1p1 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.2.2p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: 3des-cbc,blowfish-cbc debug2: kex_parse_kexinit: 3des-cbc,blowfish-cbc debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: zlib debug2: kex_parse_kexinit: zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss,ssh-rsa debug2: kex_parse_kexinit: aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client 3des-cbc hmac-md5 zlib debug2: mac_init: found hmac-md5 debug1: kex: client->server 3des-cbc hmac-md5 zlib debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 193/384 debug1: bits set: 515/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/phil/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug3: check_host_in_hostfile: filename /home/phil/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug1: Host 'hamal' is known and matches the RSA host key. debug1: Found key in /home/phil/.ssh/known_hosts:1 debug1: bits set: 515/1024 xfree: NULL pointer given as argument debug1: Calling cleanup 0x8063b4c(0x0) ============================================================================= -- ----------------------------------------------------------------- | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/ | ----------------------------------------------------------------- From rdawes at mweb.co.za Mon May 20 00:51:24 2002 From: rdawes at mweb.co.za (Rogan Dawes) Date: Sun, 19 May 2002 16:51:24 +0200 Subject: OpenSSH library References: Message-ID: <004001c1ff44$a804f240$4c7b1fc4@rampage> So, from what Ben is saying, the recommended method of doing this is to develop your app as a "patch" to OpenSSH? I.e. do "deep linking" directly to the various .o or .a files? Is there a documented interface that one could consider to be fairly static, that can be used? Or would any such use be done at the coder's risk? It would be great to get an example of how this could be done, with a recommended sequence of calls that would invoke all the right security functions to achieve a secure authenticated transport, without leaving anything out. I guess that could be inferred from the source of openssh itself, but I would worry about leaving something out :-( Rogan ----- Original Message ----- From: "Ben Lindstrom" To: "Ray Caruso" Cc: "Rogan Dawes" ; Sent: Sunday, May 19, 2002 6:14 AM Subject: Re: OpenSSH library > > This has come up a few times, but the issue as Markus has stated it the > current libssh.a is really just a collection of object files to improve > compile preformance. > > The other issue you will face is if you want to do hostbased > authentication (like the .shost, etc style) the binary in question that > is linked to libssh.a will have to be setuid root. > > I think it may more useful to take the sftp*.[ch] framework and build it > into a library/wrapper. That way you can leverage OpenSSH or SSH Corp or > "John Joe's Local SSH install" without having to create yet another > setuid binary. > > Personally I like this approach for a few reasons. The main reason is I > believe it could be provided with a simple interface like below. > > ssh_password_callback(callback_passwd); > fd = ssh_connect("site"); > {int,int64,char*)get_buffer{_int,_int64,}(fd); > ssh_close(fd); > > Granted, I'm not looking at the code so it may need a bit more TLC. But > if memory serves right that is pretty much all sftp does at it's core. > > The other advantage this could bring is the ability to pass -o commands to > the ssh client which would not be part of the libssh.a since it would be > too low level for such concepts. Thus making code reuse much higher. > Only issue is SSH Corp and OpenSSH's -o commands are different, but one > could handle it cleanly if they spent some time and pondered it. > > Consider that, and have fun.=) > > - Ben > > > > On Sat, 18 May 2002, Ray Caruso wrote: > > > I think this is a great idea. There are many applications for this lib. I > > actually started to investigate this a while back. > > > > > > > > At 06:16 AM Saturday 5/18/2002, Rogan Dawes wrote: > > >Hi folks, > > > > > >I was thinking about the possibility of separating the OpenSSH transport and > > >authentication functions from the terminal emulation functions, and making > > >it available as a library for other applications to use for secure > > >authenticated transport. > > > > > >My thinking is along the lines of: > > > > > >A whole bunch of applications have implemented "secure" versions of the > > >transport protocol, using SSL (e.g. POP3S, IMAPS, NNTPS, IRC - I think), > > >however, they did not address the authentication problems at the same time > > >in a more flexible manner than client certificates. > > > > > >E.g. POP3 over SSL, but you still use a possibly weak password to > > >authenticate. > > > > > >I can certainly imagine a whole class of developers who would love to be > > >able to replace a standard connect() call, followed by an authentication > > >process, with a simple ssh_connect() call. That way, they would not have to > > >worry about handling the various possible authentication combinations, as > > >well as being able to handle new authentication methods as SSH matures and > > >evolves, with little effort on their part in reimplementing them, other than > > >adding a configuration option in the application config files. > > > > > >Ultimately, they would be able to know that, as a server process, any data > > >that comes out of the fd is securely authenticated as coming from the user > > >returned by a ssh_get_user() call. > > > > > >The OpenSSH daemon could be implemented something like: > > > > > >Daemon starts up, reads the config file, initialises the ssh_transport > > >library with parameters such as acceptable auth methods, location of keyauth > > >files, port-forwarding allowed, etc, and then the library starts listening > > >for connections. > > > > > >When a connection is received, the library handles all the negotiation of > > >algorithms and authentication methods, and once an acceptable authentication > > >occurs, the file descriptor (fd) is returned to the daemon. A library > > >function would return the UID of the user associated with the fd, and the > > >daemon would then continue with the shell specific functions, such as > > >opening pty's, setuid(user), executing .ssh/rc, and spawning a shell. > > > > > >One immediate use I could see for this is in writing a graphical SCP/SFTP > > >client, since the GUI developer would not need to worry about > > >re-implementing the security part, and could instead concentrate on the > > >functionality and usability of the GUI client. > > > > > >Similarly, this could be used by someone writing an SFTPD, listening on a > > >non-port-22, where SFTPD includes all the functionality of, say, wu-ftpd, or > > >the openbsd ftpd, such as chroot, limits, etc, and does not need to create > > >chroot jails with shells, etc in them for users that just want to transfer > > >files. > > > > > >SFTPD users would have their own keyauth files, say in > > >.ssh/sftpd_authorized_keys, which would not be read by a normal SSH daemon, > > >and thus would not imply allowing FTP only users access to a shell. > > > > > >I can imagine that I will get a bunch of answers saying that people who are > > >not interested in security should not be implementing things like FTP > > >daemons, etc, but I think that it is more intelligent to rely on a group > > >that IS interested in security to do it properly, and reuse those efforts > > >where possible. > > > > > >I can also imagine answers like "We don't like libraries in security > > >critical code, the fewer interfaces, the fewer mistakes". Maybe that's > > >valid, I don't know, and will bow to experience. I would just like to see > > >more use of secure protocols, and think that this might be one way of > > >achieving it. > > > > > >Comments? > > > > > >Rogan > > > > > > > > >_______________________________________________ > > >openssh-unix-dev at mindrot.org mailing list > > >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > _______________________________________________ > > openssh-unix-dev at mindrot.org mailing list > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > From eperez at it.uc3m.es Mon May 20 01:26:40 2002 From: eperez at it.uc3m.es (eperez at it.uc3m.es) Date: Sun, 19 May 2002 15:26:40 +0000 Subject: using full ip/tcp address in known_hosts Message-ID: <20020519152640@localhost.localdomain> Hello, What about using the full ip/tcp address in known_hosts? I have two hosts at (sample addresses): 192.168.0.1:22 192.168.0.1:2222 When I connect to the first one everything is OK, but if I connect to the second one I get: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! When everything is OK. ssh thinks that they are the same sshd. Another solution would be not checking any ip address in known_hosts and just checking that the fingerprint is trusted (it's in known_hosts). Anyone has a fix? I'm using OpenSSH_3.0.2p1 from debian/sid. Eduardo From bugzilla-daemon at mindrot.org Mon May 20 05:41:38 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 20 May 2002 05:41:38 +1000 (EST) Subject: [Bug 248] scp doesn't support ssh2 protocol Message-ID: <20020519194138.80F25E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=248 ------- Additional Comments From markus at openbsd.org 2002-05-20 05:41 ------- openssh's scp speaks RCP, openssh's sftp speaks SFTP, ssh.com's scp and sftp both speak SFTP only, unless you install a scp1 program. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Mon May 20 05:43:47 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 19 May 2002 21:43:47 +0200 Subject: [Fwd: Re: X-windows security in Gnome] In-Reply-To: <1021669179.21625.31.camel@peecee> References: <1021669179.21625.31.camel@peecee> Message-ID: <20020519194347.GC14258@folly> On Fri, May 17, 2002 at 01:59:29PM -0700, Gregory Leblanc wrote: > This is from a security discussion on one of the GNOME lists. Jim is > one of the original X11 people, for what that's worth. I just thought > I'd try to tempt some folks here into looking at doing ssh and X > integration "right". well, what is he talking about? From bugzilla-daemon at mindrot.org Mon May 20 09:29:41 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 20 May 2002 09:29:41 +1000 (EST) Subject: [Bug 251] openssh-3.2.2p1-1.src.rpm won't build under RH6.2 Message-ID: <20020519232941.DD832E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=251 ------- Additional Comments From seba at iq.pl 2002-05-20 09:29 ------- update bug info error at link time: i386-redhat-linux-gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o -L. -Lopenbsd-compat/ -L/usr/kerberos/lib -l ssh -lopenbsd-compat -lresolv -lutil -lz -lnsl /usr/lib/libcrypto.a -lkrb5 -l k5crypto -lcom_err only when: # Do we want to link against a static libcrypto? (1=yes 0=no) %define static_libcrypto 1 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon May 20 09:38:25 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 20 May 2002 09:38:25 +1000 (EST) Subject: [Bug 245] SSH can not log out under Solaris 2.6 Message-ID: <20020519233825.06C89E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=245 ------- Additional Comments From robert at gslt.hum.gu.se 2002-05-20 09:38 ------- i think this is related to this bug, compiling 3.2.2p1 for solaris 8, using gcc 3.2 or 2.95.3 will give the following error when logging into tcsh "Warning: no access to tty (Inappropriate ioctl for device). Thus no job control in this shell." in addition to hang on logout. this error does not occur in openssh 3.1p1 on the same machine. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon May 20 09:43:00 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 20 May 2002 09:43:00 +1000 (EST) Subject: [Bug 245] SSH can not log out under Solaris 2.6 Message-ID: <20020519234300.D5CB8E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=245 ------- Additional Comments From robert at gslt.hum.gu.se 2002-05-20 09:42 ------- right forgot to mention in my earlier comment regarding this bug -- login into sh seems to work just fine. not tcsh though, have not tried other shells ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon May 20 10:29:32 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 20 May 2002 10:29:32 +1000 (EST) Subject: [Bug 251] openssh-3.2.2p1-1.src.rpm won't build under RH6.2 Message-ID: <20020520002932.58FD5E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=251 seba at iq.pl changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From seba at iq.pl 2002-05-20 10:29 ------- Fixed some time ago: http://groups.google.com/groups?hl=pl&lr=&frame=right&th=74c666b050f07d80&seekm=1015852517.770111%40sj-nntpcache-5#link1 Please update spec file: -perl -pi -e "s|-lcrypto|/usr/lib/libcrypto.a|g" Makefile +perl -pi -e "s|-lcrypto|/usr/lib/libcrypto.a -ldl|g" Makefile ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon May 20 20:41:16 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 20 May 2002 20:41:16 +1000 (EST) Subject: [Bug 252] New: Patch for use of /etc/default/login Message-ID: <20020520104116.3108EE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=252 Summary: Patch for use of /etc/default/login Product: Portable OpenSSH Version: -current Platform: All OS/Version: Solaris Status: NEW Severity: enhancement Priority: P4 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: Robert.Dahlem at siemens.com There is a file /etc/default/login on Solaris 2.x and ReliantUNIX. See http://docs.sun.com/ab2/coll.40.6/REFMAN1/%40Ab2PageView/174009 (Sun likes to change URLs ... it's not more than 'man login') for a description. It handles things like setting a different PATH for root and normal users at login time and the umask setting, quite a convenient feature for administrators. This file exists and is used in SINIX / ReliantUnix also. /etc/default/login was handled in SSH 1 since at least 1998. I rewrote some of the old code to gather at least PATH and UMASK. I added a paranoia check to have always a minimum PATH set but take care! I fear this changed the semantics of --with-default-path. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon May 20 20:44:52 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 20 May 2002 20:44:52 +1000 (EST) Subject: [Bug 252] Patch for use of /etc/default/login Message-ID: <20020520104452.50F17E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=252 ------- Additional Comments From Robert.Dahlem at siemens.com 2002-05-20 20:44 ------- Created an attachment (id=98) description? ... the proposed patch itself :-) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mm at mail.deuba.com Mon May 20 21:03:48 2002 From: mm at mail.deuba.com (Markus Moeller) Date: Mon, 20 May 2002 12:03:48 +0100 Subject: Openssh 3.2.2p1 KRB5 addition Message-ID: <3CE8D814.8CEFC90C@mail.deuba.com> The Kerberos V support may still fail on hosts with two or more interfaces. Regards Markus -------------- next part -------------- *** auth-krb5.c.orig Mon May 20 11:51:57 2002 --- auth-krb5.c Mon May 20 11:53:34 2002 *************** *** 38,43 **** --- 38,44 ---- #include "servconf.h" #include "uidswap.h" #include "auth.h" + #include "canohost.h" #ifdef KRB5 #include *************** *** 80,85 **** --- 81,87 ---- krb5_data reply; krb5_ticket *ticket; int fd, ret; + char *localname; ret = 0; server = NULL; *************** *** 108,114 **** if (problem) goto err; ! problem = krb5_sname_to_principal(authctxt->krb5_ctx, NULL, NULL , KRB5_NT_SRV_HST, &server); if (problem) goto err; --- 110,118 ---- if (problem) goto err; ! localname=get_local_hostname(fd); ! ! problem = krb5_sname_to_principal(authctxt->krb5_ctx, localname, NULL , KRB5_NT_SRV_HST, &server); if (problem) goto err; -------------- next part -------------- *** canohost.c.orig Mon May 20 11:54:18 2002 --- canohost.c Mon May 20 11:59:56 2002 *************** *** 22,27 **** --- 22,100 ---- static void check_ip_options(int, char *); /* + * Return the canonical name of the localhost of the socket. The + * caller should free the returned string with xfree. + */ + + const char * + get_local_hostname(int socket) + { + struct sockaddr_storage addr_6or4; + int i; + socklen_t addr_6or4_len; + char name[NI_MAXHOST], ntop[NI_MAXHOST]; + + /* Get local IP address*/ + addr_6or4_len = sizeof(addr_6or4); + memset(&addr_6or4, 0, sizeof(addr_6or4)); + if (getsockname(socket, (struct sockaddr *) &addr_6or4, &addr_6or4_len) < 0) { + debug("getsockname failed: %.100s", strerror(errno)); + fatal_cleanup(); + } + #ifdef IPV4_IN_IPV6 + if (addr_6or4.ss_family == AF_INET6) { + struct sockaddr_in6 *addr6 = (struct sockaddr_in6 *)&addr_6or4; + + /* Detect IPv4 in IPv6 mapped address and convert it to */ + /* plain (AF_INET) IPv4 address */ + if (IN6_IS_ADDR_V4MAPPED(&addr6->sin6_addr)) { + struct sockaddr_in *addr4 = (struct sockaddr_in *)&addr_6or4; + struct in_addr addr; + u_int16_t port; + + memcpy(&addr, ((char *)&addr6->sin6_addr) + 12, sizeof(addr)); + port = addr6->sin6_port; + + memset(&addr_6or4, 0, sizeof(addr_6or4)); + + addr4->sin_family = AF_INET; + memcpy(&addr4->sin_addr, &addr, sizeof(addr)); + addr4->sin_port = port; + } + } + #endif + if (addr_6or4.ss_family == AF_INET) + check_ip_options(socket, ntop); + + if (getnameinfo((struct sockaddr *)&addr_6or4, addr_6or4_len, ntop, sizeof(ntop), + NULL, 0, NI_NUMERICHOST) != 0) + fatal("get_local_hostname: getnameinfo NI_NUMERICHOST failed"); + + debug3("Trying to resolve local address %.100s to hostname", ntop); + /* Map the IP address to a host name. */ + if (getnameinfo((struct sockaddr *)&addr_6or4, addr_6or4_len, name, sizeof(name), + NULL, 0, NI_NAMEREQD) != 0) { + /* Host name not found. Use ip address. */ + log("Could not resolve local address %.100s to hostname", ntop); + return xstrdup(ntop); + } + + /* Got host name. */ + name[sizeof(name) - 1] = '\0'; + /* + * Convert it to all lowercase (which is expected by the rest + * of this software). + */ + for (i = 0; name[i]; i++) + if (isupper(name[i])) + name[i] = tolower(name[i]); + + debug("Resolved local address %.100s to hostname %s", ntop,name); + + return xstrdup(name); + } + + /* * Return the canonical name of the host at the other end of the socket. The * caller should free the returned string with xfree. */ -------------- next part -------------- *** canohost.h.orig Mon May 20 11:54:30 2002 --- canohost.h Mon May 20 11:56:19 2002 *************** *** 12,17 **** --- 12,18 ---- * called by a name other than "ssh" or "Secure Shell". */ + const char *get_local_hostname(int); const char *get_canonical_hostname(int); const char *get_remote_ipaddr(void); const char *get_remote_name_or_ip(u_int, int); From dtucker at zip.com.au Tue May 21 00:09:58 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 21 May 2002 00:09:58 +1000 Subject: OpenSSH AIX native packages available Message-ID: <3CE903B6.419D439A@zip.com.au> Hello All, Since (a) I've offered them to people and (b) the previous source of AIX OpenSSH packages (freeware.bull.net) seems to be offline I've put my AIX bff (SMIT/installp installable) packages up for download. Packages for 3.1p1 and 3.2.2p1 are currently available. If you want AIX packages I recommend you build them yourself with contrib/aix/buildbff.sh, however if you can't (or won't) then you can download these. They're built and tested on AIX 4.2.1 and also tested on 4.3.3. They'll probably work on any version in between. They have detached GPG (key fingerprint D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69) and MD5 signatures. They come with no warranty. They may be nothing more than streams of random bytes, however I've had good success with "smitty install". Any problems with them are probably my fault and should be reported directly to me. They can be had from either of: http://www.zip.com.au/~dtucker/openssh/ or http://home.usf.advantra.com.au/~dtucker/openssh/ Regards, -Daz. From janfrode at parallab.uib.no Tue May 21 00:15:20 2002 From: janfrode at parallab.uib.no (Jan-Frode Myklebust) Date: Mon, 20 May 2002 16:15:20 +0200 Subject: OpenSSH 3.2.2 released In-Reply-To: <20020516223622.GA12334@muamat> References: <20020516223622.GA12334@muamat> Message-ID: <20020520141520.GA1848@ii.uib.no> On Fri, May 17, 2002 at 12:36:22AM +0200, Markus Friedl wrote: > - experimental support for privilege separation, > see UsePrivilegeSeparation in sshd(8) and > http://www.citi.umich.edu/u/provos/ssh/privsep.html > for more information. I can't get this working on AIX 5.1: ./configure --prefix=/usr/openssh --sysconfdir=/etc/openssh --disable-suid-ssh OpenSSH has been configured with the following options: User binaries: /usr/openssh/bin System binaries: /usr/openssh/sbin Configuration files: /etc/openssh Askpass program: /usr/openssh/libexec/ssh-askpass Manual pages: /usr/openssh/man/manX PID file: /var/run Privilege separation chroot path: /var/empty sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/openssh/bin Manpage format: man PAM support: no KerberosIV support: no KerberosV support: no Smartcard support: no AFS support: no S/KEY support: no TCP Wrappers support: no MD5 password support: no IP address in $DISPLAY hack: no Use IPv4 by default hack: no Translate v4 in v6 hack: no BSD Auth support: no Random number source: ssh-rand-helper ssh-rand-helper collects from: Command hashing (timeout 200) Host: powerpc-ibm-aix5.1.0.0 Compiler: cc Compiler flags: -g Preprocessor flags: -I/usr/local/ssl/include -I/usr/local/include Linker flags: -L/usr/local/ssl/lib -L/usr/local/lib -blibpath:/usr/lib:/lib:/usr/local/lib Libraries: -lz -lcrypto # /usr/openssh/sbin/sshd -p 2022 -d -D -o 'UsePrivilegeSeparation yes' debug1: sshd version OpenSSH_3.2.2p1 debug1: private host key: #0 type 0 RSA1 debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: Bind to port 2022 on 0.0.0.0. Server listening on 0.0.0.0 port 2022. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. setsid: Not owner Connection from 217.13.1.91 port 38497 debug1: Client protocol version 2.0; client software version OpenSSH_3.1p1 debug1: match: OpenSSH_3.1p1 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_3.2.2p1 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client->server aes128-cbc hmac-md5 zlib debug1: kex: server->client aes128-cbc hmac-md5 zlib debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: dh_gen_key: priv key bits set: 129/256 debug1: bits set: 1534/3191 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 1617/3191 debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: Enabling compression at level 6. debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user janfrode service ssh-connection method none debug1: attempt 0 failures 0 Failed none for janfrode from 217.13.1.91 port 38497 ssh2Failed none for janfrode from 217.13.1.91 port 38497 ssh2 debug1: userauth-request for user janfrode service ssh-connection method publickey debug1: attempt 1 failures 1 debug1: test whether pkalg/pkblob are acceptable debug1: temporarily_use_uid: 50012/50012 (e=0) debug1: trying public key file /home/parallab/plab/janfrode/.ssh/authorized_keys debug1: matching key found: file /home/parallab/plab/janfrode/.ssh/authorized_keys, line 2 Found matching DSA key: d6:73:c1:54:51:df:56:18:43:8c:ca:fd:ec:a1:c4:4b debug1: restore_uid Postponed publickey for janfrode from 217.13.1.91 port 38497 ssh2 debug1: userauth-request for user janfrode service ssh-connection method publickey debug1: attempt 2 failures 1 debug1: temporarily_use_uid: 50012/50012 (e=0) debug1: trying public key file /home/parallab/plab/janfrode/.ssh/authorized_keys debug1: matching key found: file /home/parallab/plab/janfrode/.ssh/authorized_keys, line 2 Found matching DSA key: d6:73:c1:54:51:df:56:18:43:8c:ca:fd:ec:a1:c4:4b debug1: restore_uid debug1: ssh_dss_verify: signature correct Accepted publickey for janfrode from 217.13.1.91 port 38497 ssh2 Accepted publickey for janfrode from 217.13.1.91 port 38497 ssh2debug1: monitor_child_preauth: janfrode has been authenticated by privileged process debug1: newkeys: mode 0 debug1: newkeys: mode 1 debug1: Entering interactive session for SSH2. debug1: fd 8 setting O_NONBLOCK debug1: fd 9 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request pty-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_new: init debug1: session_new: session 0 debug1: session_pty_req: session 0 alloc /dev/pts/10 debug1: Ignoring unsupported tty mode opcode 13 (0xd) debug1: Ignoring unsupported tty mode opcode 18 (0x12) debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: fd 4 setting TCP_NODELAY debug1: channel 0: rfd 11 isatty debug1: fd 11 setting O_NONBLOCK setsid: Operation not permitted. debug1: session_by_tty: session 0 tty /dev/pts/10 debug1: session_pty_cleanup: session 0 release /dev/pts/10 Connection closed by remote host. debug1: channel_free: channel 0: server-session, nchannels 1 debug1: session_close: session 0 pid 49666 Closing connection to 217.13.1.91 debug1: session_by_tty: unknown tty /dev/pts/10 debug1: dump: used 0 session 0 200326c0 channel -1 pid 29204 debug1: dump: used 0 session 0 2003285c channel 0 pid 0 debug1: dump: used 0 session 0 200329f8 channel 0 pid 0 debug1: dump: used 0 session 0 20032b94 channel 0 pid 0 debug1: dump: used 0 session 0 20032d30 channel 0 pid 0 debug1: dump: used 0 session 0 20032ecc channel 0 pid 0 debug1: dump: used 0 session 0 20033068 channel 0 pid 0 debug1: dump: used 0 session 0 20033204 channel 0 pid 0 debug1: dump: used 0 session 0 200333a0 channel 0 pid 0 debug1: dump: used 0 session 0 2003353c channel 0 pid 0 On the client side i get the /etc/motd printed, and then the connection is closed. Any hints to what I might be doing wrong? -jf From Nicolas.Williams at ubsw.com Tue May 21 00:19:57 2002 From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com) Date: Mon, 20 May 2002 10:19:57 -0400 Subject: OpenSSH library Message-ID: <9403F8EE868566448AA1B70D8F783C95335749@NSTMC004PEX1.ubsgs.ubsgroup.net> The OpenSSH code is far from usable as a library. Throughout the OpenSSH code you'll find the use of globals and static globals and calls to fatal() (which is a fancy wrapper around exit()) and so on, to say nothing of the fact that OpenSSH has its own event loop and, if you want to use OpenSSH as a library, you have to either fit the app into that loop or abstract the loop so the library could fit into the app's event loop - or use multiple threads (but OpenSSH code is not thread-safe currently). So no, you can't make a useful library out of OpenSSH as it stands. A lot of the major issues that prevent OpenSSH from being made into a library could be fixed with some work. Stuff the globals into a context structure, make sure it gets passed around... give the app a way to register its own exit() and select() functions for use by the library (the app-provided exit() might just longjmp()), provide an I/O abstraction so the app can read/write from/to SSH channels, etc... Actually, that's a bit more than "some work"... But I kinda doubt that libopenssh is a goal or a high-priority goal for the OpenSSH folk. In the meantime you can use ssh w/ pipes and/or port forwarding to achieve mostly the same effect, though with more context switching and data copying. Cheers, Nico -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From markus at openbsd.org Tue May 21 00:41:23 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 20 May 2002 16:41:23 +0200 Subject: OpenSSH library In-Reply-To: <9403F8EE868566448AA1B70D8F783C95335749@NSTMC004PEX1.ubsgs.ubsgroup.net> References: <9403F8EE868566448AA1B70D8F783C95335749@NSTMC004PEX1.ubsgs.ubsgroup.net> Message-ID: <20020520144123.GA9896@faui02> > But I kinda doubt that libopenssh is a goal or a high-priority > goal for the OpenSSH folk. we think about this in the re-write From d.love at dl.ac.uk Tue May 21 00:47:14 2002 From: d.love at dl.ac.uk (Dave Love) Date: 20 May 2002 15:47:14 +0100 Subject: 3.2.2p1 build problem on Irix6.5 Message-ID: On Irix 6.5.15m with version 7.3 of the development tools, monitor_fdpass.c won't compile after a normal configure because SCM_RIGHTS isn't defined. In sys/socket.h it's protected by #ifdef _XOPEN_SOURCE but if I define _XOPEN_SOURCE, I get a storm of IPV6-related errors. Defining SCM_RIGHTS explicitly does allow it to build. I can't immediately figure out how to fix this properly. From genty at dgenty.austin.ibm.com Tue May 21 01:49:12 2002 From: genty at dgenty.austin.ibm.com (Denise Genty) Date: Mon, 20 May 2002 10:49:12 -0500 Subject: OpenSSH AIX installp images Message-ID: <200205201549.g4KFnC538740@dgenty.austin.ibm.com> AIX is now shipping OpenSSH on the AIX 5L Bonus Pack CD in SMIT/installp format. The 2.9.9.p2 version shipped contains all of the latest security fixes. We made some modifications to add National Language Support. The images are also available from: oss.software.ibm.com/developerworks/projects/opensshi The NLS patch is available from: oss.software/ibm.com/developerworks/projects/openssh -- Denise M. Genty genty at austin.ibm.com (512)838-8170 - T/L 678-8170 AIX Network Security Development Server Division, pSeries From lhecking at nmrc.ie Tue May 21 03:07:41 2002 From: lhecking at nmrc.ie (Lars Hecking) Date: Mon, 20 May 2002 18:07:41 +0100 Subject: openssh 3.2.2p1 problem on Solaris Message-ID: <20020520170741.GA5716@nmrc.ie> I have compiled openssh with the Sun compiler, for the first time :) Installed it on my Solaris 8 box, restarted sshd, and connected to localhost. It works, basically, but I get ... debug1: Entering interactive session. Warning: no access to tty (Inappropriate ioctl for device). Thus no job control in this shell. and also May 20 18:01:01 localhost sshd[5753]: error: open /dev/tty failed - could not set controlling tty: No such device or address in sylog, and when I exit the shell via ^D, I have to ^C, too, to get back to the original shell. I think the problem is not on the client side, because it works fine when connecting to another Sol8 box (running openssh 3.1p1, compiled with gcc). /dev/tty is a link to /devices/pseudo/sy at 0:tty crw-rw-rw- 1 root tty 22, 0 May 20 18:01 sy at 0:tty sshd runs as root $ /bin/ps -ef |grep sshd root 5617 1 0 17:57:09 ? 0:00 /opt/ssh/sbin/sshd OS is Solaris 8/SPARC 02/02, recommended patch cluster of about 3 weeks ago. Have I overlooked anything? From tim at multitalents.net Tue May 21 03:16:14 2002 From: tim at multitalents.net (Tim Rice) Date: Mon, 20 May 2002 10:16:14 -0700 (PDT) Subject: openssh 3.2.2p1 problem on Solaris In-Reply-To: <20020520170741.GA5716@nmrc.ie> Message-ID: There was a setsid() call added that seems to bother solaris. See http://bugzilla.mindrot.org/show_bug.cgi?id=245 On Mon, 20 May 2002, Lars Hecking wrote: > > I have compiled openssh with the Sun compiler, for the first time :) > Installed it on my Solaris 8 box, restarted sshd, and connected to > localhost. It works, basically, but I get > > ... > debug1: Entering interactive session. > Warning: no access to tty (Inappropriate ioctl for device). > Thus no job control in this shell. > > and also > > May 20 18:01:01 localhost sshd[5753]: error: open /dev/tty failed - could not set controlling tty: No such device or address > > in sylog, and when I exit the shell via ^D, I have to ^C, too, to get back to > the original shell. I think the problem is not on the client side, because > it works fine when connecting to another Sol8 box (running openssh 3.1p1, > compiled with gcc). > > /dev/tty is a link to /devices/pseudo/sy at 0:tty > > crw-rw-rw- 1 root tty 22, 0 May 20 18:01 sy at 0:tty > > sshd runs as root > > $ /bin/ps -ef |grep sshd > root 5617 1 0 17:57:09 ? 0:00 /opt/ssh/sbin/sshd > > OS is Solaris 8/SPARC 02/02, recommended patch cluster of about 3 weeks ago. > > Have I overlooked anything? > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From lhecking at nmrc.ie Tue May 21 03:20:55 2002 From: lhecking at nmrc.ie (Lars Hecking) Date: Mon, 20 May 2002 18:20:55 +0100 Subject: openssh 3.2.2p1 problem on Solaris In-Reply-To: References: <20020520170741.GA5716@nmrc.ie> Message-ID: <20020520172055.GA5904@nmrc.ie> Tim Rice writes: > > There was a setsid() call added that seems to bother solaris. > See http://bugzilla.mindrot.org/show_bug.cgi?id=245 I see. My case is covered by Robert Andersson's comments then, my login shell is tcsh, too. From florin at sgi.com Tue May 21 03:32:08 2002 From: florin at sgi.com (Florin Andrei) Date: 20 May 2002 10:32:08 -0700 Subject: OpenSSH 3.2.2 released : chroot In-Reply-To: References: Message-ID: <1021915928.7086.4.camel@stantz.corp.sgi.com> On Fri, 2002-05-17 at 09:05, Ben Lindstrom wrote: > > Out of interest why do you feel it's required to do chroot() at the > OpenSSH level? Why don't you invest time into a shell that does the > chroot() for you? That would work for telnet, ssh, etc. No need to > clutter up OpenSSH with options that can easily be implemented at a higher > level. Perhaps because an OpenSSH-level chroot will also work for sftp-restricted accounts. Remember, if you want to restrict an account to sftp-only, you have to declare the sftp-server as a shell. Which is kinda annoying, but it's ok. Now, if you chroot at the shell level, it suddenly becomes more complicated for sftp-only accounts. -- Florin Andrei Spiderman according to Jon Katz: "the web-slinging arachnoid-nerd from Queens who gets the bad guy but really wants the girl." From mouring at etoh.eviladmin.org Tue May 21 03:40:01 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 20 May 2002 12:40:01 -0500 (CDT) Subject: OpenSSH 3.2.2 released : chroot In-Reply-To: <1021915928.7086.4.camel@stantz.corp.sgi.com> Message-ID: On 20 May 2002, Florin Andrei wrote: > On Fri, 2002-05-17 at 09:05, Ben Lindstrom wrote: > > > > Out of interest why do you feel it's required to do chroot() at the > > OpenSSH level? Why don't you invest time into a shell that does the > > chroot() for you? That would work for telnet, ssh, etc. No need to > > clutter up OpenSSH with options that can easily be implemented at a higher > > level. > > Perhaps because an OpenSSH-level chroot will also work for > sftp-restricted accounts. > Remember, if you want to restrict an account to sftp-only, you have to > declare the sftp-server as a shell. Which is kinda annoying, but it's > ok. Now, if you chroot at the shell level, it suddenly becomes more > complicated for sftp-only accounts. > chroot in sshd.c does not improve sftp-only chroot support. If you think that then you are mistaken. You still need to put a bunch of crap in the user's directory. Only way around it is suiding sftp-server and embeding the chroot there. In general a suid chroot wrapper or chroot in sshd.c results in the same crap. Besides, you have to take your pick. chroot at the sshd.c level or at the sftp-server.c level. You really can't have both. - Ben From phil-openssh-unix-dev at ipal.net Tue May 21 04:27:01 2002 From: phil-openssh-unix-dev at ipal.net (Phil Howard) Date: Mon, 20 May 2002 13:27:01 -0500 Subject: OpenSSH 3.2.2p1 sshd: fatal: xfree: NULL pointer given as argument In-Reply-To: <20020518225644.GA13680@jenny.crlsca.adelphia.net> References: <20020518125350.GA14317@vega.ipal.net> <20020518225644.GA13680@jenny.crlsca.adelphia.net> Message-ID: <20020520182701.GA7221@vega.ipal.net> On Sat, May 18, 2002 at 03:56:44PM -0700, Kevin Steves wrote: | On Sat, May 18, 2002 at 07:53:50AM -0500, Phil Howard wrote: | > debug1: dh_gen_key: priv key bits set: 194/384 | > debug1: bits set: 1047/2049 | > debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT | > debug1: bits set: 1031/2049 | > xfree: NULL pointer given as argument | > debug1: Calling cleanup 0x806b00c(0x0) | | Can you narrow the config down a bit in terms of what may cause this, | or get a stack trace? How about this. I modified all 486 instances of xfree() calls and all 146 instances of buffer_free() calls to also have a debug3() call before that call, (inside {} so it's handled right in conditionals), saying what source file and line number was doing the calling. This was done on the same line so as not to distort line numbering from the original. Here's what my test runs now look like: client: ============================================================================= ... debug3: check_host_in_hostfile: match line 1 debug3: key.c#144 xfree debug3: key.c#144 xfree debug1: Host 'hamal' is known and matches the RSA host key. debug1: Found key in /home/phil/.ssh/known_hosts:1 debug3: sshconnect.c#815 xfree debug3: bufaux.c#138 xfree debug1: bits set: 515/1024 debug3: kexgex.c#216 xfree debug3: bufaux.c#128 xfree debug3: bufaux.c#128 xfree debug3: bufaux.c#128 xfree debug3: bufaux.c#128 xfree debug3: bufaux.c#128 xfree debug3: kexgex.c#93 buffer_free debug3: buffer.c#38 xfree xfree: NULL pointer given as argument debug1: Calling cleanup 0x806467c(0x0) debug3: packet.c#336 buffer_free debug3: buffer.c#38 xfree debug3: packet.c#337 buffer_free debug3: buffer.c#38 xfree debug3: packet.c#338 buffer_free debug3: buffer.c#38 xfree debug3: packet.c#339 buffer_free debug3: buffer.c#38 xfree ============================================================================= server: ============================================================================= ... debug3: kex.c#110 xfree debug3: kex.c#111 xfree debug3: packet.c#1266 xfree debug3: packet.c#746 xfree debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug3: bufaux.c#128 xfree debug3: bufaux.c#128 xfree debug3: packet.c#1266 xfree debug1: dh_gen_key: priv key bits set: 186/384 debug1: bits set: 1075/2049 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug3: packet.c#1266 xfree debug3: packet.c#746 xfree debug3: bufaux.c#138 xfree debug1: bits set: 1031/2049 debug3: kexgex.c#352 xfree debug3: bufaux.c#128 xfree debug3: bufaux.c#128 xfree debug3: key.c#754 buffer_free debug3: buffer.c#38 xfree debug3: bufaux.c#128 xfree debug3: bufaux.c#128 xfree debug3: bufaux.c#128 xfree debug3: bufaux.c#128 xfree debug3: bufaux.c#128 xfree debug3: kexgex.c#93 buffer_free debug3: buffer.c#38 xfree xfree: NULL pointer given as argument debug1: Calling cleanup 0x806bd4c(0x0) debug3: packet.c#336 buffer_free debug3: buffer.c#38 xfree debug3: packet.c#337 buffer_free debug3: buffer.c#38 xfree debug3: packet.c#338 buffer_free debug3: buffer.c#38 xfree debug3: packet.c#339 buffer_free debug3: buffer.c#38 xfree ============================================================================= The buffer_free() function is involved, so that's why I include it in what debug3() would be tracking: ============================================================================= void buffer_free(Buffer *buffer) { memset(buffer->buf, 0, buffer->alloc); {debug3("buffer.c#38 xfree");xfree(buffer->buf);} } ============================================================================= So kexgex.c at line 93 looks like the culprit. The code around there looks like (with my change in place): ============================================================================= static u_char * kexgex_hash( char *client_version_string, char *server_version_string, char *ckexinit, int ckexinitlen, char *skexinit, int skexinitlen, u_char *serverhostkeyblob, int sbloblen, int min, int wantbits, int max, BIGNUM *prime, BIGNUM *gen, BIGNUM *client_dh_pub, BIGNUM *server_dh_pub, BIGNUM *shared_secret) { Buffer b; static u_char digest[EVP_MAX_MD_SIZE]; const EVP_MD *evp_md = EVP_sha1(); EVP_MD_CTX md; buffer_init(&b); buffer_put_cstring(&b, client_version_string); buffer_put_cstring(&b, server_version_string); /* kexinit messages: fake header: len+SSH2_MSG_KEXINIT */ buffer_put_int(&b, ckexinitlen+1); buffer_put_char(&b, SSH2_MSG_KEXINIT); buffer_append(&b, ckexinit, ckexinitlen); buffer_put_int(&b, skexinitlen+1); buffer_put_char(&b, SSH2_MSG_KEXINIT); buffer_append(&b, skexinit, skexinitlen); buffer_put_string(&b, serverhostkeyblob, sbloblen); if (min == -1 || max == -1) buffer_put_int(&b, wantbits); else { buffer_put_int(&b, min); buffer_put_int(&b, wantbits); buffer_put_int(&b, max); } buffer_put_bignum2(&b, prime); buffer_put_bignum2(&b, gen); buffer_put_bignum2(&b, client_dh_pub); buffer_put_bignum2(&b, server_dh_pub); buffer_put_bignum2(&b, shared_secret); #ifdef DEBUG_KEXDH buffer_dump(&b); #endif EVP_DigestInit(&md, evp_md); EVP_DigestUpdate(&md, buffer_ptr(&b), buffer_len(&b)); EVP_DigestFinal(&md, digest, NULL); {debug3("kexgex.c#93 buffer_free");buffer_free(&b);} ============================================================================= -- ----------------------------------------------------------------- | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/ | ----------------------------------------------------------------- From bugzilla-daemon at mindrot.org Tue May 21 04:54:41 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 21 May 2002 04:54:41 +1000 (EST) Subject: [Bug 245] SSH can not log out under Solaris 2.6 Message-ID: <20020520185441.43706E8EA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=245 ------- Additional Comments From carson at taltos.org 2002-05-21 04:54 ------- An explanation of the problem is provided by the man page for setsid() on Solaris. I'm fairly sure that the behaviour specified is per POSIX. DESCRIPTION The setsid() function creates a new session, if the calling process is not a process group leader. Upon return the cal- ling process will be the session leader of this new session, will be the process group leader of a new process group, and will have no controlling terminal. The lack of controlling terminal appears to be the key issue. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue May 21 05:01:57 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 21 May 2002 05:01:57 +1000 (EST) Subject: [Bug 253] New: Patch to write process ID to a file when ssh sets itself into daemon mode Message-ID: <20020520190157.435CCE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=253 Summary: Patch to write process ID to a file when ssh sets itself into daemon mode Product: Portable OpenSSH Version: -current Platform: ix86 URL: http://evan.prodromou.san-francisco.ca.us/openssh- 3.2.2p1.withpid.diff OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: evan at prodromou.san-francisco.ca.us I find it necessary on occasion to write scripts that set up an ssh tunnel, do some commands using that tunnel, and then tear down the tunnel. Tunnelling POP3 connections with fetchmail is a good example: ssh -f -N -L 10110:mailhost:110 mailhost fetchmail localhost [tear down tunnel] The -f option here is key, because you want to be sure that the tunnel is set up before running fetchmail. However, it's difficult to tear down the tunnel, since it's hard to find out what the backgrounded ssh process's PID is. I've written a patch to allow a command-line option, "-d pidfile", which writes the process ID of the fork()'d child to a file, so the script can then just kill `cat pidfile`. In order to do this, I had to unfold the calls to daemon() in ssh.c to actually do the fork(), exit() and setsid() manually, since we want to be sure that the pidfile exists before the parent exits, to avoid races. This works fine on Linux, but I'm unsure if daemon() does any other fancy things on other operating systems. I'm also not sure what the proper behavior of the parent should be if it can't write the pidfile. Currently, it does _not_ kill the child, although this might be the Right Thing. I also changed the manual page to include mention of the -d option. The patch should apply cleanly by changing to the source directory and running: patch -Np1 < /path/to/openssh-3.2.2p1.withpid.diff I hope this is useful to someone else besides me. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue May 21 05:04:23 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 21 May 2002 05:04:23 +1000 (EST) Subject: [Bug 253] Patch to write process ID to a file when ssh sets itself into daemon mode Message-ID: <20020520190423.2E1EFE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=253 ------- Additional Comments From evan at prodromou.san-francisco.ca.us 2002-05-21 05:04 ------- Created an attachment (id=99) Patch to write pid out to a file in daemon mode for ssh ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jaearick at colby.edu Tue May 21 05:06:12 2002 From: jaearick at colby.edu (Jeff A. Earickson) Date: Mon, 20 May 2002 15:06:12 -0400 (EDT) Subject: patch for bug 245? Message-ID: Hi, Has a patch against 3.2.2p1 been posted for bug 245, the bug that gives the following syslog complaint? open /dev/tty failed - could not set controlling tty: No such device or address I hit this when upgrading from 3.1p1, solaris 8, using Sun Forte 6 C compiler. I would get authenticated at login, but my shell would never get going. I had to roll back to 3.1p1. ** Jeff A. Earickson, Ph.D PHONE: 207-872-3659 ** Senior UNIX Sysadmin, Information Technology EMAIL: jaearick at colby.edu ** Colby College, 4214 Mayflower Hill, FAX: 207-872-3076 ** Waterville ME, 04901-8842 ---------------------------------------------------------------------------- From Todd.Miller at courtesan.com Tue May 21 05:10:03 2002 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Mon, 20 May 2002 13:10:03 -0600 Subject: patch for bug 245? In-Reply-To: Your message of "Mon, 20 May 2002 15:06:12 EDT." References: Message-ID: <200205201910.g4KJA370012033@xerxes.courtesan.com> Just comment out the setsid() call in sshd.c for now. That will get around the problem. - todd From tim at multitalents.net Tue May 21 09:00:21 2002 From: tim at multitalents.net (Tim Rice) Date: Mon, 20 May 2002 16:00:21 -0700 (PDT) Subject: 3.2.2p1 build problem on Irix6.5 In-Reply-To: Message-ID: What is the output of grep _MSG config.h On 20 May 2002, Dave Love wrote: > On Irix 6.5.15m with version 7.3 of the development tools, > monitor_fdpass.c won't compile after a normal configure because > SCM_RIGHTS isn't defined. In sys/socket.h it's protected by > #ifdef _XOPEN_SOURCE but if I define _XOPEN_SOURCE, I get a storm of > IPV6-related errors. Defining SCM_RIGHTS explicitly does allow it to > build. I can't immediately figure out how to fix this properly. > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mjt at tls.msk.ru Tue May 21 09:26:45 2002 From: mjt at tls.msk.ru (Michael Tokarev) Date: Tue, 21 May 2002 03:26:45 +0400 Subject: SSH 3.2.2 on Solaris 8 with /kernel/drv/random References: <00fa01c1fd81$a6356450$0a1111b0@swissptt.ch> Message-ID: <3CE98635.79BC1CE8@tls.msk.ru> Sean Boran wrote: > > Hi, > > I'm like to try a get the new release to work with Sun's new device, > that can be installed with patch 112438-01. > > I compiled SSL attempting to point it at the random device: > cd openssl-0.9.6d > ./Configure solaris-sparcv7-gcc > make DEVRANDOM="/kernel/drv/random" [] > But I don't think /kernel/drv/random is a socket, "ls" lists it as a > normal file. > ls -alF /kernel/drv/random > -rwxr-xr-x 1 root sys 15704 Mar 15 00:33 > /kernel/drv/random* Sean, /kernel/drv/random is a DRIVER, an object file loadable to a kernel, not a device. You should configure the driver somehow to be loaded at startup and to assign a device (by reboot -r). It was a time since I last used solaris, so I don't remember more details. Maybe /kernel/drv/random.conf or something... /mjt From janfrode at parallab.uib.no Tue May 21 16:28:14 2002 From: janfrode at parallab.uib.no (Jan-Frode Myklebust) Date: Tue, 21 May 2002 08:28:14 +0200 Subject: 3.2.2p1 build problem on Irix6.5 In-Reply-To: References:

Message-ID: <20020521062814.GA14394@ii.uib.no> On Mon, May 20, 2002 at 04:00:21PM -0700, Tim Rice wrote: > > What is the output of grep _MSG config.h > I see the same problem on IRIX 6.5.15m, and the grep returns: % grep _MSG config.h #define HAVE_ACCRIGHTS_IN_MSGHDR 1 #define HAVE_CONTROL_IN_MSGHDR 1 % -jf From jakob at crt.se Tue May 21 16:32:20 2002 From: jakob at crt.se (Jakob Schlyter) Date: Tue, 21 May 2002 08:32:20 +0200 (MEST) Subject: Problems with OpenSSH 3.2.2p1 on Solaris 7 In-Reply-To: Message-ID: On Fri, 17 May 2002, Kevin Steves wrote: > On Fri, 17 May 2002, Jakob Schlyter wrote: > :just upgraded to OpenSSH 3.2.2p1 on a box running Solaris 7. now I get the > :following when logging on: > : > : Warning: no access to tty (Inappropriate ioctl for device). > : Thus no job control in this shell. > : > :everything works alright with 3.0p1, but 3.1p1 and 3.2.2p1 seems to have > :this problem. > > you have that with 3.1p1 as well? yes. > does this change anything? > > Index: sshd.c > =================================================================== > RCS file: /var/cvs/openssh/sshd.c,v > retrieving revision 1.205 > diff -u -r1.205 sshd.c > --- sshd.c 15 May 2002 16:25:02 -0000 1.205 > +++ sshd.c 17 May 2002 19:17:01 -0000 > @@ -1336,8 +1336,10 @@ > * setlogin() affects the entire process group. We don't > * want the child to be able to affect the parent. > */ > +#if 0 > if (setsid() < 0) > error("setsid: %.100s", strerror(errno)); > +#endif > > /* > * Disable the key regeneration alarm. We will not regenerate the > yes, this works better. jakob From d.love at dl.ac.uk Tue May 21 19:18:22 2002 From: d.love at dl.ac.uk (Dave Love) Date: 21 May 2002 10:18:22 +0100 Subject: 3.2.2p1 build problem on Irix6.5 References: Message-ID: Tim Rice writes: > What is the output of grep _MSG config.h #define HAVE_ACCRIGHTS_IN_MSGHDR 1 #define HAVE_CONTROL_IN_MSGHDR 1 From markus at openbsd.org Tue May 21 20:31:09 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 21 May 2002 12:31:09 +0200 Subject: OpenSSH 3.2.2 released : chroot In-Reply-To: <1021915928.7086.4.camel@stantz.corp.sgi.com> References: <1021915928.7086.4.camel@stantz.corp.sgi.com> Message-ID: <20020521103109.GA29192@folly> On Mon, May 20, 2002 at 10:32:08AM -0700, Florin Andrei wrote: > On Fri, 2002-05-17 at 09:05, Ben Lindstrom wrote: > > > > Out of interest why do you feel it's required to do chroot() at the > > OpenSSH level? Why don't you invest time into a shell that does the > > chroot() for you? That would work for telnet, ssh, etc. No need to > > clutter up OpenSSH with options that can easily be implemented at a higher > > level. > > Perhaps because an OpenSSH-level chroot will also work for chroot at sshd level requires a sftp-server binary in every chroot target and that's not desirable. From markus at openbsd.org Tue May 21 20:35:02 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 21 May 2002 12:35:02 +0200 Subject: OpenSSH 3.2.2p1 sshd: fatal: xfree: NULL pointer given as argument In-Reply-To: <20020520182701.GA7221@vega.ipal.net> References: <20020518125350.GA14317@vega.ipal.net> <20020518225644.GA13680@jenny.crlsca.adelphia.net> <20020520182701.GA7221@vega.ipal.net> Message-ID: <20020521103501.GB29192@folly> could you please print put b.buf after buffer_init and before buffer_free ? On Mon, May 20, 2002 at 01:27:01PM -0500, Phil Howard wrote: > So kexgex.c at line 93 looks like the culprit. The code around there > looks like (with my change in place): > ============================================================================= > static u_char * > kexgex_hash( > char *client_version_string, > char *server_version_string, > char *ckexinit, int ckexinitlen, > char *skexinit, int skexinitlen, > u_char *serverhostkeyblob, int sbloblen, > int min, int wantbits, int max, BIGNUM *prime, BIGNUM *gen, > BIGNUM *client_dh_pub, > BIGNUM *server_dh_pub, > BIGNUM *shared_secret) > { > Buffer b; > static u_char digest[EVP_MAX_MD_SIZE]; > const EVP_MD *evp_md = EVP_sha1(); > EVP_MD_CTX md; > > buffer_init(&b); allocates b.buf > buffer_put_cstring(&b, client_version_string); > buffer_put_cstring(&b, server_version_string); > > /* kexinit messages: fake header: len+SSH2_MSG_KEXINIT */ > buffer_put_int(&b, ckexinitlen+1); > buffer_put_char(&b, SSH2_MSG_KEXINIT); > buffer_append(&b, ckexinit, ckexinitlen); > buffer_put_int(&b, skexinitlen+1); > buffer_put_char(&b, SSH2_MSG_KEXINIT); > buffer_append(&b, skexinit, skexinitlen); > > buffer_put_string(&b, serverhostkeyblob, sbloblen); > if (min == -1 || max == -1) > buffer_put_int(&b, wantbits); > else { > buffer_put_int(&b, min); > buffer_put_int(&b, wantbits); > buffer_put_int(&b, max); > } > buffer_put_bignum2(&b, prime); > buffer_put_bignum2(&b, gen); > buffer_put_bignum2(&b, client_dh_pub); > buffer_put_bignum2(&b, server_dh_pub); > buffer_put_bignum2(&b, shared_secret); > > #ifdef DEBUG_KEXDH > buffer_dump(&b); > #endif > EVP_DigestInit(&md, evp_md); > EVP_DigestUpdate(&md, buffer_ptr(&b), buffer_len(&b)); > EVP_DigestFinal(&md, digest, NULL); > > {debug3("kexgex.c#93 buffer_free");buffer_free(&b);} free's b.buf From phil-openssh-unix-dev at ipal.net Tue May 21 21:16:52 2002 From: phil-openssh-unix-dev at ipal.net (Phil Howard) Date: Tue, 21 May 2002 06:16:52 -0500 Subject: OpenSSH 3.2.2p1 sshd: fatal: xfree: NULL pointer given as argument In-Reply-To: <20020521103501.GB29192@folly> References: <20020518125350.GA14317@vega.ipal.net> <20020518225644.GA13680@jenny.crlsca.adelphia.net> <20020520182701.GA7221@vega.ipal.net> <20020521103501.GB29192@folly> Message-ID: <20020521111652.GA19140@vega.ipal.net> On Tue, May 21, 2002 at 12:35:02PM +0200, Markus Friedl wrote: | could you please print put b.buf after buffer_init and before buffer_free ? I already got further than that for some off-list conversation and found that the pointers/values in the Buffer b struct were all made 0 at the call to EVP_DigestFinal(). I then found another symptom which was that ssh-keygen was segfaulting. Things were pointing at libcrypto so I grabbed the 0.9.6c source, upgraded that, and recompiled 3.2.2p1 and now it all works like a charm. It seems to be a problem with the openssl that came in Slackware or that I had previously compiled (unfortunately, I don't recall at the moment whether my prior compile of openssl was before or after I upgraded Slackware to version 8.0). | > EVP_DigestFinal(&md, digest, NULL); It changed in the above call (I had diagnostics inserted at every line in the kexgex_hash() function), which really makes no sense at all since it was not being given Buffer b at all. But given some other weirdnesses I started just generally suspecting a bad library image. I'm also suspecting the executeable was linked against libcrypto 0.9.6a or 0.9.6b and then used with 0.9.6c. I forgot to check the version of libcrypto before I recompiled openssl on the build system. -- ----------------------------------------------------------------- | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/ | ----------------------------------------------------------------- From bugzilla-daemon at mindrot.org Tue May 21 21:32:00 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 21 May 2002 21:32:00 +1000 (EST) Subject: [Bug 58] Cannot find a type to use in place of socklen_t Message-ID: <20020521113200.51D55E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=58 ------- Additional Comments From kamo at ITmanage.co.jp 2002-05-21 21:31 ------- On my system (RHL6.2), socklen_t is defined in /usr/include/bits/socket.h . My workarond: echo 'ac_cv_type_socklen_t=${ac_cv_type_socklen_t=yes}' >config.cache ./configure -C --with.... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djast at cs.toronto.edu Tue May 21 23:17:50 2002 From: djast at cs.toronto.edu (Dan Astoorian) Date: Tue, 21 May 2002 09:17:50 -0400 Subject: OpenSSH 3.2.2 released : chroot In-Reply-To: Your message of "Tue, 21 May 2002 06:31:09 EDT." <20020521103109.GA29192@folly> Message-ID: <02May21.091755edt.25238-17923@sanjuan.cs.toronto.edu> On Tue, 21 May 2002 06:31:09 EDT, Markus Friedl writes: > > chroot at sshd level requires a sftp-server binary in every chroot target > and that's not desirable. The same is true for a shell wrapper. Chroot() at any level above the sftp-server binary itself would require an sftp-server binary in the chroot() targets. The alternatives would seem to be a) An sftp-server binary in every chroot target b) Making sftp-server setuid-root and teaching it how to chroot(). a) is inconvenient for the sysadmin, but b) seems somewhat riskier from a security standpoint. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From kouril at ics.muni.cz Tue May 21 23:23:20 2002 From: kouril at ics.muni.cz (Daniel Kouril) Date: Tue, 21 May 2002 15:23:20 +0200 Subject: Curious about final KRB5/GSSAPI patch inclusion. In-Reply-To: <266088109.1021772639@[192.168.0.2]>; from carson@taltos.org on Sun, May 19, 2002 at 01:43:59AM -0400 References: <20020518132400.A18970@odorn.ics.muni.cz> <266088109.1021772639@[192.168.0.2]> Message-ID: <20020521152319.A20269@odorn.ics.muni.cz> On Sun, May 19, 2002 at 01:43:59AM -0400, Carson Gaspar wrote: > > > --On Saturday, May 18, 2002 1:24 PM +0200 Daniel Kouril > wrote: > > > Thus, the same openssh binary compiled with > > GSS-API support can work either with krb5 or X.509 authentication -- the > > only thing you have to do is supply the rigth gssapi library. And when > > some more sophisticated implementation of gss library is available (I > > mean mechglue or something similar), more different methods could be used > > with the same GSS code at once. > > Ummm... sort-of. GSS-API is _not_ an ABI (binary interface), it's an source > level API. And each underlying method uses different datatypes. So > combining more than one in the same binary is non-trivial. And you can't > just add a new .o - you have to recompile everything that references a > GSS-API datatype. Feh. I didn't say it was easy. But it can be implemented eg. by means of dynamic linking linker (via dlopen() etc.). However, the main advantage of GSS-API is that only one adaptation of an application code is needed, and once it's done it's very easy to switch among various authentication mechanisms (or even make them cooperate -- see above) without any changes in the source code. I believe that the Simon's patch is very well written (and there is quite large community of users who use it) and could be placed in the standard Openssh distribuiton. cheers -- Dan From tim at multitalents.net Tue May 21 23:48:58 2002 From: tim at multitalents.net (Tim Rice) Date: Tue, 21 May 2002 06:48:58 -0700 (PDT) Subject: 3.2.2p1 build problem on Irix6.5 In-Reply-To: <20020521062814.GA14394@ii.uib.no> Message-ID: On Tue, 21 May 2002, Jan-Frode Myklebust wrote: > On Mon, May 20, 2002 at 04:00:21PM -0700, Tim Rice wrote: > > > > What is the output of grep _MSG config.h > > > > I see the same problem on IRIX 6.5.15m, and the grep returns: > > % grep _MSG config.h > #define HAVE_ACCRIGHTS_IN_MSGHDR 1 > #define HAVE_CONTROL_IN_MSGHDR 1 > % Try commenting out #define HAVE_CONTROL_IN_MSGHDR 1 and tell me what happens. > > -jf > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From andreas at conectiva.com.br Tue May 21 23:58:52 2002 From: andreas at conectiva.com.br (Andreas Hasenack) Date: Tue, 21 May 2002 10:58:52 -0300 Subject: OpenSSH 3.2.2 supports kerberos5 but.... In-Reply-To: <1021676579.12809.17.camel@UberGeek> References: <1021676579.12809.17.camel@UberGeek> Message-ID: <20020521135852.GD26121@conectiva.com.br> Em Fri, May 17, 2002 at 06:02:59PM -0500, Austin Gonyou escreveu: > I can't seem to login with only a TGS? (i.e. no password) > Do I need another patch to have that part work? Password auth seems to > be working against the KDC just fine. Try ssh -1 From janfrode at parallab.uib.no Wed May 22 00:01:04 2002 From: janfrode at parallab.uib.no (Jan-Frode Myklebust) Date: Tue, 21 May 2002 16:01:04 +0200 Subject: 3.2.2p1 build problem on Irix6.5 In-Reply-To: References: <20020521062814.GA14394@ii.uib.no> Message-ID: <20020521140104.GA21510@ii.uib.no> On Tue, May 21, 2002 at 06:48:58AM -0700, Tim Rice wrote: > > > > > > > I see the same problem on IRIX 6.5.15m, and the grep returns: > > > > % grep _MSG config.h > > #define HAVE_ACCRIGHTS_IN_MSGHDR 1 > > #define HAVE_CONTROL_IN_MSGHDR 1 > > % > > Try commenting out #define HAVE_CONTROL_IN_MSGHDR 1 and tell me what happens. Then it builds and works! Thanks! -jf From andreas at conectiva.com.br Tue May 21 23:57:05 2002 From: andreas at conectiva.com.br (Andreas Hasenack) Date: Tue, 21 May 2002 10:57:05 -0300 Subject: Curious about final KRB5/GSSAPI patch inclusion. In-Reply-To: <1021747353.15919.2.camel@UberGeek> References: <20020518132400.A18970@odorn.ics.muni.cz> <1021747353.15919.2.camel@UberGeek> Message-ID: <20020521135705.GC26121@conectiva.com.br> Em Sat, May 18, 2002 at 01:42:33PM -0500, Austin Gonyou escreveu: > As I stated in latest mail, krb5 auth works with passwords only as far > as I can tell right now. Ticket based auth does *not* seem to work. TIA. It works here, but only for ssh 1, not ssh 2. From Nicolas.Williams at ubsw.com Wed May 22 00:01:37 2002 From: Nicolas.Williams at ubsw.com (Nicolas.Williams at ubsw.com) Date: Tue, 21 May 2002 10:01:37 -0400 Subject: Curious about final KRB5/GSSAPI patch inclusion. Message-ID: <9403F8EE868566448AA1B70D8F783C95334F2A@NSTMC004PEX1.ubsgs.ubsgroup.net> SEAM's GSS implementation is, indeed, fully dynamic, that is, it uses dlopen() to get at the shared objects implementing specific GSS mechanisms. Unfortunately the GSS-API is not enough - some mechanism-specific APIs are needed to properly handle credentials and what not, so SEAM's GSS implementation can't be used with OpenSSH because the underlying mechanism APIs are not public. Nico -- > -----Original Message----- > From: Daniel Kouril [mailto:kouril at ics.muni.cz] > Sent: Tuesday, May 21, 2002 9:23 AM > To: Carson Gaspar > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Curious about final KRB5/GSSAPI patch inclusion. > > > On Sun, May 19, 2002 at 01:43:59AM -0400, Carson Gaspar wrote: > > > > > > --On Saturday, May 18, 2002 1:24 PM +0200 Daniel Kouril > > wrote: > > > > > Thus, the same openssh binary compiled with > > > GSS-API support can work either with krb5 or X.509 > authentication -- the > > > only thing you have to do is supply the rigth gssapi > library. And when > > > some more sophisticated implementation of gss library is > available (I > > > mean mechglue or something similar), more different > methods could be used > > > with the same GSS code at once. > > > > Ummm... sort-of. GSS-API is _not_ an ABI (binary > interface), it's an source > > level API. And each underlying method uses different datatypes. So > > combining more than one in the same binary is non-trivial. > And you can't > > just add a new .o - you have to recompile everything that > references a > > GSS-API datatype. Feh. > > I didn't say it was easy. But it can be implemented eg. by > means of dynamic > linking linker (via dlopen() etc.). However, the main > advantage of GSS-API is > that only one adaptation of an application code is needed, > and once it's done > it's very easy to switch among various authentication > mechanisms (or even > make them cooperate -- see above) without any changes in the > source code. > > I believe that the Simon's patch is very well written (and > there is quite > large community of users who use it) and could be placed in > the standard > Openssh distribuiton. > > cheers > > -- > Dan > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From kouril at ics.muni.cz Wed May 22 00:16:39 2002 From: kouril at ics.muni.cz (Daniel Kouril) Date: Tue, 21 May 2002 16:16:39 +0200 Subject: Curious about final KRB5/GSSAPI patch inclusion. In-Reply-To: <9403F8EE868566448AA1B70D8F783C95334F2A@NSTMC004PEX1.ubsgs.ubsgroup.net>; from Nicolas.Williams@ubsw.com on Tue, May 21, 2002 at 10:01:37AM -0400 References: <9403F8EE868566448AA1B70D8F783C95334F2A@NSTMC004PEX1.ubsgs.ubsgroup.net> Message-ID: <20020521161639.A20346@odorn.ics.muni.cz> On Tue, May 21, 2002 at 10:01:37AM -0400, Nicolas.Williams at ubsw.com wrote: > > SEAM's GSS implementation is, indeed, fully dynamic, that is, it uses > dlopen() to get at the shared objects implementing specific GSS mechanisms. > Unfortunately the GSS-API is not enough - some mechanism-specific APIs are > needed to properly handle credentials and what not, so SEAM's GSS > implementation can't be used with OpenSSH because the underlying mechanism > APIs are not public. There is draft, which tryies to add these missing functions. See draft-ggf-gss-extensions-05.txt available from http://www.gridforum.org/security/gsi/index.html --> GSS-API Extensions A kerberos implementation of these functions should be trivial. -- Dan From sxw at dcs.ed.ac.uk Wed May 22 00:26:35 2002 From: sxw at dcs.ed.ac.uk (Simon Wilkinson) Date: Tue, 21 May 2002 15:26:35 +0100 (BST) Subject: Curious about final KRB5/GSSAPI patch inclusion. In-Reply-To: <1021747353.15919.2.camel@UberGeek> Message-ID: On 18 May 2002, Austin Gonyou wrote: > Simon, or anyone else, If you're listening, can you let us know if there > will be a new patch set for 3.2.2p1 for gssapi or mit-kerberos pieces > like before. The MIT Kerberos pieces are now incorporated in the portable distribution. They only work (by design) with protocol version 1. The standard way of doing Kerberos with protocol version 2 is through the GSSAPI, which still requires patches. Patches for 3.2.2p1 should be available Real Soon Now. > As I stated in latest mail, krb5 auth works with passwords only as far > as I can tell right now. Ticket based auth does *not* seem to work. TIA. Are you establishing a version 1 connection - by default ssh uses v2 if the peer supports it. Use the -1 option to ssh. Cheers, Simon. From sxw at dcs.ed.ac.uk Wed May 22 00:39:28 2002 From: sxw at dcs.ed.ac.uk (Simon Wilkinson) Date: Tue, 21 May 2002 15:39:28 +0100 (BST) Subject: Curious about final KRB5/GSSAPI patch inclusion. In-Reply-To: <9403F8EE868566448AA1B70D8F783C95334F2A@NSTMC004PEX1.ubsgs.ubsgroup.net> Message-ID: On Tue, 21 May 2002 Nicolas.Williams at ubsw.com wrote: > Unfortunately the GSS-API is not enough - some > mechanism-specific APIs are needed to properly handle credentials and > what not In particular, there are problems with user authorization (the kuserok() step), and with storing delegated credentials locally. Both of the two supported GSSAPI mechanisms (Kerberos and GSI) handle these differently, and Heimdal and MIT Kerberos even differ in their handling of credentials storage. Gack. The Grid folk have an extensions draft that handles the credential storage issue, but doesn't address the authorization one (although Nico's extension of authorized_keys could do so). The extensions draft also still leaves somethings as "mechanism dependent" I guess the upshot is that the OpenSSH GSSAPI code will still need some knowledge of the underlying mechanism for some time to come. However, it should be possible to make it work with an implementation supporting multiple mechanisms, providing that portions of the underlying API are exposed. Cheers, Simon. From jdennis at law.harvard.edu Wed May 22 01:37:42 2002 From: jdennis at law.harvard.edu (James Dennis) Date: Tue, 21 May 2002 11:37:42 -0400 Subject: Chroot (theres that word again...) Message-ID: <20020521113742.14954831.jdennis@law.harvard.edu> Hey everyone, It appears my last patch doesn't work entirely. Looks like I forgot to edit sshd.c for the priv seperation scheme (which is really cool by the way). Heres the new patch for chrooting system users (does not attempt to chroot the priv seperation user as ssh does that on it's own already). -James PS. Once again, I'm not on the openssh mailing list so if you have any questions, please email me at jdennis at law.harvard.edu From Nicolas.Williams at ubsw.com Wed May 22 01:50:23 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 21 May 2002 11:50:23 -0400 Subject: Curious about final KRB5/GSSAPI patch inclusion. In-Reply-To: ; from sxw@dcs.ed.ac.uk on Tue, May 21, 2002 at 03:39:28PM +0100 References: <9403F8EE868566448AA1B70D8F783C95334F2A@NSTMC004PEX1.ubsgs.ubsgroup.net> Message-ID: <20020521115023.A388@W0594878> On Tue, May 21, 2002 at 03:39:28PM +0100, Simon Wilkinson wrote: > > In particular, there are problems with user authorization (the kuserok() > step), and with storing delegated credentials locally. Both of the two > supported GSSAPI mechanisms (Kerberos and GSI) handle these differently, > and Heimdal and MIT Kerberos even differ in their handling of credentials > storage. Gack. > > The Grid folk have an extensions draft that handles the credential storage > issue, but doesn't address the authorization one (although Nico's > extension of authorized_keys could do so). The extensions draft also still > leaves somethings as "mechanism dependent" As long as account authorization is done in a name-based way (as the MIT and Heimdal krb5_kuserok() implementations do, or as I suspect GSI does, and as the GSS RFCs say authorization should be done) then implementing name-based authorization using exported GSS names will do. And in the case of OpenSSH, because of the additional constraints that one can place on account access using authorized_keys entry options, I believe this approach to be superior. As for credentials management, it may well be possible to remove much mech-specific code from your patches by moving some tasks to PAM. This means that a sort of protocol needs to be established by which OpenSSH/GSS/PAM can interact such that: a) the end result is as today with your code, b) OpenSSH requires no GSS mech-specific code and c) all GSS mech-specific code is moved to PAM modules which would then be expected to be distributed as part of the underlying GSS implementation. What I envision is a PAM module interface where GSS path in OpenSSH calls pam_setcred() on a PAM handle for a PAM service name indicating the use of GSS; the module(s) in the stack would prompt OpenSSH for the GSS context structure and OpenSSH would furnish a pointer to it in response and it would be the module(s)' responsibility to perform mech-specific credentials actions. The PAM service name might be "ssh-gss," say. But such a protocol for app/gss/pam interaction might be easier to specify and implement than the GGF proposal (well, at least that one is specified :) > I guess the upshot is that the OpenSSH GSSAPI code will still need some > knowledge of the underlying mechanism for some time to come. However, > it should be possible to make it work with an implementation supporting > multiple mechanisms, providing that portions of the underlying API are > exposed. Hmmmm. See above. I'm not sure there's any incentive to try to get rid of all mech-specific code though, not as long as the GSS implementors aren't helping or as long as the necessary APIs (e.g., PAM) are less than widely and well established or a pain to work with. > Cheers, > > Simon. Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From bugzilla-daemon at mindrot.org Wed May 22 03:17:26 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 22 May 2002 03:17:26 +1000 (EST) Subject: [Bug 245] SSH can not log out under Solaris 2.6 Message-ID: <20020521171726.0D365E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=245 ------- Additional Comments From robert at gslt.hum.gu.se 2002-05-22 03:17 ------- hey the patch, id=96, seemed to fix these problems altogether... :) thanks ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From kevin at atomicgears.com Wed May 22 03:41:50 2002 From: kevin at atomicgears.com (Kevin Steves) Date: Tue, 21 May 2002 10:41:50 -0700 Subject: Problems with OpenSSH 3.2.2p1 on Solaris 7 In-Reply-To: References:

Message-ID: <20020521174150.GB1728@jenny.crlsca.adelphia.net> On Tue, May 21, 2002 at 08:32:20AM +0200, Jakob Schlyter wrote: > On Fri, 17 May 2002, Kevin Steves wrote: > > : Warning: no access to tty (Inappropriate ioctl for device). > > : Thus no job control in this shell. > > : > > :everything works alright with 3.0p1, but 3.1p1 and 3.2.2p1 seems to have > > :this problem. > > > > you have that with 3.1p1 as well? > > yes. I don't recall seeing that reported for 3.1, and I have not seen it myself on Solaris 8. From kevin at atomicgears.com Wed May 22 04:00:36 2002 From: kevin at atomicgears.com (Kevin Steves) Date: Tue, 21 May 2002 11:00:36 -0700 Subject: OpenSSH 3.2.2 released In-Reply-To: <20020517124024.U2671@cygbert.vinschen.de> References: <20020516223622.GA12334@muamat> <20020517124024.U2671@cygbert.vinschen.de> Message-ID: <20020521180036.GC1728@jenny.crlsca.adelphia.net> On Fri, May 17, 2002 at 12:40:24PM +0200, Corinna Vinschen wrote: > Why has the setgroups() call been added to sshd.c a week ago > w/o asking for further testing? It doesn't exist in Cygwin. > All other setgroups() calls are #ifndef'd HAVE_CYGWIN. Why > not this one? This is the change I just commited: Index: sshd.c =================================================================== RCS file: /var/cvs/openssh/sshd.c,v retrieving revision 1.206 diff -u -r1.206 sshd.c --- sshd.c 21 May 2002 17:50:21 -0000 1.206 +++ sshd.c 21 May 2002 17:57:25 -0000 @@ -1005,6 +1005,7 @@ if (test_flag) exit(0); +#ifndef HAVE_CYGWIN /* * Clear out any supplemental groups we may have inherited. This * prevents inadvertent creation of files with bad modes (in the @@ -1014,6 +1015,7 @@ */ if (setgroups(0, NULL) < 0) debug("setgroups() failed: %.200s", strerror(errno)); +#endif /* !HAVE_CYGWIN */ /* Initialize the log (it is reinitialized below in case we forked). */ if (debug_flag && !inetd_flag) From ewheeler at kaico.com Wed May 22 04:10:09 2002 From: ewheeler at kaico.com (ewheeler at kaico.com) Date: Tue, 21 May 2002 11:10:09 -0700 (PDT) Subject: chroot for sftp using unix sockets In-Reply-To: <20020521103109.GA29192@folly> Message-ID: > Re: OpenSSH 3.2.2 released : chroot > chroot at sshd level requires a sftp-server binary in every chroot target > and that's not desirable. You would also need all the libraries necessary to run sftp-server. What if there were an sftpd which ssh would talk over a pair of pipes or unix socket to to avoid having an sftp-server binary and associated libraries living in the jail as well? My idea is as follows: Process: 1. User authenticates and requests the execution of sftp-server. 2. sshd realizes that sftp-server is being executed and connects instead to some unix socket (/var/run/sftpd? probably 600, owned by root). This would require some option like this: OverideBinaryWithSocket /usr/bin/sftp-server /var/run/sftpd 3. sftpd accepts the AF_UNIX connection, forks a child, chroots, and gives up root access in favor of the user logging in (this means you never need to worry about sshd chrooting). Implementation: Instead of running the process sftp-server and passing it's stdio via the ssh connection, it would instead connect to the unix socket which would be controlled by the sftp-server. My guess is that this could be relatively easy to implement. Just use the socket for the in/out fd's and add a little socket listening code to sftp-server. The other option would be to create an sftpd which forks and exec's sftp-server using sftp-server's stdio as the data to be passed across the socket -- maybe some type of generic unix socket server would make more sense to quickly implement than adding code to sftp-server. I am not sure what this would introduce to the problem, but it could see it as being a rather usefull tool. It would also secure other services which the server admin wanted to override. Ideas? -- Eric Wheeler Network Administrator KAICO 20417 SW 70th Ave. Tualatin, OR 97062 www.kaico.com Voice: 503.692.5268 From kevin at atomicgears.com Wed May 22 04:17:17 2002 From: kevin at atomicgears.com (Kevin Steves) Date: Tue, 21 May 2002 11:17:17 -0700 Subject: 3.2.2p1 build problem on Irix6.5 In-Reply-To: References: Message-ID: <20020521181717.GD1728@jenny.crlsca.adelphia.net> On Tue, May 21, 2002 at 10:18:22AM +0100, Dave Love wrote: > Tim Rice writes: > > > What is the output of grep _MSG config.h > > #define HAVE_ACCRIGHTS_IN_MSGHDR 1 > #define HAVE_CONTROL_IN_MSGHDR 1 I think we need to have runtime checks in configure that result in: HAVE_ACCRIGHTS_FD_PASSING HAVE_CONTROL_FD_PASSING From bugzilla-daemon at mindrot.org Wed May 22 04:40:26 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 22 May 2002 04:40:26 +1000 (EST) Subject: [Bug 245] SSH can not log out under Solaris 2.6 Message-ID: <20020521184026.47264E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=245 ------- Additional Comments From stevesk at pobox.com 2002-05-22 04:40 ------- - (stevesk) [sshd.c] bug 245; disable setsid() for now ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From austin at coremetrics.com Wed May 22 05:12:50 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 21 May 2002 14:12:50 -0500 Subject: Curious about final KRB5/GSSAPI patch inclusion. In-Reply-To: References: Message-ID: <1022008370.1939.5.camel@UberGeek> Ahh...I will attempt that. That make sense. Thanks much for the hard work. On Tue, 2002-05-21 at 09:26, Simon Wilkinson wrote: > On 18 May 2002, Austin Gonyou wrote: > > > Simon, or anyone else, If you're listening, can you let us know if > there > > will be a new patch set for 3.2.2p1 for gssapi or mit-kerberos > pieces > > like before. > > The MIT Kerberos pieces are now incorporated in the portable > distribution. They only work (by design) with protocol version 1. > The > standard way of doing Kerberos with protocol version 2 is through > the > GSSAPI, which still requires patches. Patches for 3.2.2p1 should be > available Real Soon Now. > > > As I stated in latest mail, krb5 auth works with passwords only as > far > > as I can tell right now. Ticket based auth does *not* seem to > work. TIA. > > Are you establishing a version 1 connection - by default ssh uses v2 > if the peer supports it. Use the -1 option to ssh. > > Cheers, > > Simon. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "One ought never to turn one's back on a threatened danger and try to run away from it. If you do that, you will double the danger. But if you meet it promptly and without flinching, you will reduce the danger by half." Sir Winston Churchill -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020521/540dbb33/attachment.bin From vinschen at redhat.com Wed May 22 05:17:12 2002 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 21 May 2002 21:17:12 +0200 Subject: OpenSSH 3.2.2 released In-Reply-To: <20020521180036.GC1728@jenny.crlsca.adelphia.net> References: <20020516223622.GA12334@muamat> <20020517124024.U2671@cygbert.vinschen.de> <20020521180036.GC1728@jenny.crlsca.adelphia.net> Message-ID: <20020521211712.V23036@cygbert.vinschen.de> On Tue, May 21, 2002 at 11:00:36AM -0700, Kevin Steves wrote: > On Fri, May 17, 2002 at 12:40:24PM +0200, Corinna Vinschen wrote: > > Why has the setgroups() call been added to sshd.c a week ago > > w/o asking for further testing? It doesn't exist in Cygwin. > > All other setgroups() calls are #ifndef'd HAVE_CYGWIN. Why > > not this one? > > This is the change I just commited: Looks good. Thanks, Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From austin at coremetrics.com Wed May 22 07:09:34 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 21 May 2002 16:09:34 -0500 Subject: Curious about final KRB5/GSSAPI patch inclusion. In-Reply-To: <1022008370.1939.5.camel@UberGeek> References: <1022008370.1939.5.camel@UberGeek> Message-ID: <1022015374.2675.1.camel@UberGeek> As predicted, ssh v1 protocol works with TGS just fine.(no passwords) Now that this has been verified, I know I'm not crazy..much. :) Thanks for all your responses. On Tue, 2002-05-21 at 14:12, Austin Gonyou wrote: > Ahh...I will attempt that. That make sense. Thanks much for the hard > work. > -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "One ought never to turn one's back on a threatened danger and try to run away from it. If you do that, you will double the danger. But if you meet it promptly and without flinching, you will reduce the danger by half." Sir Winston Churchill -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020521/0516303d/attachment.bin From ssklar at stanford.edu Wed May 22 13:47:59 2002 From: ssklar at stanford.edu (Sandor W. Sklar) Date: Tue, 21 May 2002 20:47:59 -0700 Subject: chrooting/jailing transfer-only accounts Message-ID: Folks, I've been tasked to find a solution that will create file-transfer-only accounts that are jailed or chrooted to a specific directory. (Not an uncommon task, I think.) Using the OpenSSH server and the OpenSSH scp client program, I can achieve the goal of having a file transfer only account jailed to a specified directory, by using the "scpjail" script (attached) as a forced command. However, if the client is using the SSH.COM's scp2 client program, the above technique does not work, since the commercial version uses sftp as the underlying method. So, the only solution I can see is to use one of the several chrooting patches that are floating around to the OpenSSH source, and set the user's shell to sftp-server. If I do this, I make it impossible to use the OpenSSH scp client ; all connections must be done using sftp clients. I am also tied to selecting and using one of these patches, which I admit, I do not have the technical ability to judge on their merits and potential weaknesses. I am phobic about using patches that are not part of the baseline code (especially for security-related software), as it creates one more thing to worry about. My question is, does anyone see a solution that I am missing here? Complaining to SSH.COM is not a solution, as it does not solve my problem. It is not in my power to force the user community to use only the OpenSSH implementation. I've seen many mails on this list lately talking about the pros and cons of including chroot-ability; the people who seem to feel that it is unnecessary have said that it is easy enough to implement outside of OpenSSH. I don't have the ability to do so; among the community of OpenSSH users, I doubt I'm alone in this. (As an aside, I'd appreciate it if people would look at the attached script, and let me know if they can see any obvious holes in it. I've tried unsuccessfully to break out if it is set up properly, but others may have more success.) Thanks, -S- -- Sandor W. Sklar - Unix Systems Administrator - Stanford University ITSS Non impediti ratione cogitationis. http://whippet.stanford.edu/~ssklar/ -------------- next part -------------- A non-text attachment was scrubbed... Name: scpjail Type: application/mac-binhex40 Size: 11846 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020521/cf77c2c8/attachment.bin From bugzilla-daemon at mindrot.org Wed May 22 18:16:17 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 22 May 2002 18:16:17 +1000 (EST) Subject: [Bug 254] New: Problems building. Message-ID: <20020522081617.ACAACE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=254 Summary: Problems building. Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dsusman at sinectis.com.ar Greetings. I'm receiving what's below while configuring. I've installed OpenSSL 0.9.6d and the configure script can't identify the version. I've run it without the --with-ssl-dir parameter, but it's no use. Thanks, Dario Susman [root at scotty openssh-3.2.3p1]# ./configure --with-tcp-wrappers --with-md5-passwords --with-mantype=man --with-ssl-dir=/usr/local/ssl/ checking whether OpenSSL's headers match the library... no configure: error: Your OpenSSL headers do not match your library ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From nomaafa at airfrance.fr Wed May 22 19:36:26 2002 From: nomaafa at airfrance.fr (nomaafa at airfrance.fr) Date: Wed, 22 May 2002 11:36:26 +0200 Subject: (no subject) Message-ID: This is the output of ./buidpkg.sh of openssh-3.1p1 on "SunOS 5.6 Generic_105181-17 sun4m sparc SUNW,SPARCstation-20" Building pkginfo file... Building prototype file... Building package.. ## Building pkgmap from package prototype file. ## Processing pkginfo file. pkgmk: ERROR: parameter cannot be null ## Packaging was not successful. pkgtrans: ERROR: unable to complete package transfer - no packages were selected from ---------------- Les donnees et renseignements contenus dans ce message sont personnels, confidentiels et secrets. Ce message est adresse a l'individu ou l'entite dont les coordonnees figurent ci-dessus. Si vous n'etes pas le bon destinataire, nous vous demandons de ne pas lire, copier, utiliser ou divulguer cette communication. Nous vous prions de notifier cette erreur a l'expediteur et d'effacer immediatement cette communication de votre systeme. The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity adressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others ;also please notify the sender by replying to this message, and then delete it from your system. From bugzilla-daemon at mindrot.org Wed May 22 20:03:24 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 22 May 2002 20:03:24 +1000 (EST) Subject: [Bug 255] New: You must "exec" login from the lowest login shell. Message-ID: <20020522100324.83758E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=255 Summary: You must "exec" login from the lowest login shell. Product: Portable OpenSSH Version: -current Platform: PPC OS/Version: AIX Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dmanton at emea.att.com The UseLogin option is broken on AIX in openssh-3.2.2p1. Setting "UseLogin yes" results in an error message and failed login for each attempted login: /dev/pts/1: 3004-004 You must "exec" login from the lowest login shell. I can re-create this problem unser 3.0.2p1, 3.1pq and 3.2.2p2 on multiple AIX 4.3.3 systems (ML6 up to ML10). Does anyone know AIX well enough to diagnose the cause and propose a solution? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed May 22 20:06:38 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 22 May 2002 20:06:38 +1000 (EST) Subject: [Bug 255] You must "exec" login from the lowest login shell. Message-ID: <20020522100638.0D778E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=255 ------- Additional Comments From dmanton at emea.att.com 2002-05-22 20:06 ------- Created an attachment (id=100) sshd -d -d -d ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Wed May 22 21:49:47 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 22 May 2002 21:49:47 +1000 Subject: (no subject) References: Message-ID: <3CEB85DB.F79C7E89@zip.com.au> nomaafa at airfrance.fr wrote: > This is the output of ./buidpkg.sh of openssh-3.1p1 on "SunOS 5.6 > Generic_105181-17 sun4m sparc SUNW,SPARCstation-20" > > Building pkginfo file... > Building prototype file... > Building package.. > ## Building pkgmap from package prototype file. > ## Processing pkginfo file. > pkgmk: ERROR: parameter cannot be null > ## Packaging was not successful. > pkgtrans: ERROR: unable to complete package transfer > - no packages were selected from Delete the blank line at the end of version.h or upgrade to 3.2.2p1. See http://bugzilla.mindrot.org/show_bug.cgi?id=140 for details. -Daz. From mouring at etoh.eviladmin.org Thu May 23 00:20:14 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 22 May 2002 09:20:14 -0500 (CDT) Subject: chrooting/jailing transfer-only accounts In-Reply-To: Message-ID: I'm sorry but I know I don't read binhex. But assuming you did what has been discussed here before which is wrote some from of program that detects the -c argument passed to it and accept or deny the commands. This can work for sftp-server also. Because we do ${SHELL} -c sftp-server just like one would expect. - Ben On Tue, 21 May 2002, Sandor W. Sklar wrote: > Folks, > > I've been tasked to find a solution that will create > file-transfer-only accounts that are jailed or chrooted to a specific > directory. (Not an uncommon task, I think.) > > Using the OpenSSH server and the OpenSSH scp client program, I can > achieve the goal of having a file transfer only account jailed to a > specified directory, by using the "scpjail" script (attached) as a > forced command. > > However, if the client is using the SSH.COM's scp2 client program, > the above technique does not work, since the commercial version uses > sftp as the underlying method. > > So, the only solution I can see is to use one of the several > chrooting patches that are floating around to the OpenSSH source, and > set the user's shell to sftp-server. If I do this, I make it > impossible to use the OpenSSH scp client ; all connections must be > done using sftp clients. I am also tied to selecting and using one > of these patches, which I admit, I do not have the technical ability > to judge on their merits and potential weaknesses. I am phobic about > using patches that are not part of the baseline code (especially for > security-related software), as it creates one more thing to worry > about. > > My question is, does anyone see a solution that I am missing here? > Complaining to SSH.COM is not a solution, as it does not solve my > problem. It is not in my power to force the user community to use > only the OpenSSH implementation. > > I've seen many mails on this list lately talking about the pros and > cons of including chroot-ability; the people who seem to feel that it > is unnecessary have said that it is easy enough to implement outside > of OpenSSH. I don't have the ability to do so; among the community > of OpenSSH users, I doubt I'm alone in this. > > (As an aside, I'd appreciate it if people would look at the attached > script, and let me know if they can see any obvious holes in it. > I've tried unsuccessfully to break out if it is set up properly, but > others may have more success.) > > Thanks, -S- > > -- > Sandor W. Sklar - Unix Systems Administrator - Stanford University ITSS > Non impediti ratione cogitationis. http://whippet.stanford.edu/~ssklar/ From rusnlind at hlrs.de Thu May 23 00:34:18 2002 From: rusnlind at hlrs.de (Natalia Currle-Linde) Date: Wed, 22 May 2002 16:34:18 +0200 Subject: OpenSSH programming Message-ID: <3CEBAC6A.2818875D@hlrs.de> Hello all, is there any recent information on programming on how to add a new authentication method into OpenSSH / OpenSSL ?! Is there any other way, to add a new authentication method into openssh (one-time passwords), apart from adding the functions into sshconnect.c and sshconnect2.c Particularly I'm interested in information on "struct Authctxt" in sshconnect2 and sshuserauth2. Thank You very much in advance. Greetings, N. Linde PS: Please CC to me directly, since I'm not subscribed to the list. -- --------------------------------------------------------------- Dipl.-Inf. N. Currle-Linde Linde at hlrs.de Allmandring 30 http://www.hlrs.de/people/linde 70550 Stuttgart Tel.: 0711 / 685 5801 From markus at openbsd.org Thu May 23 00:38:24 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 22 May 2002 16:38:24 +0200 Subject: OpenSSH programming In-Reply-To: <3CEBAC6A.2818875D@hlrs.de> References: <3CEBAC6A.2818875D@hlrs.de> Message-ID: <20020522143823.GB2128@faui02> one-time passwords are supported, see auth-bsdauth.c auth-skey.c for example. there is no need to change the client side software. the client uses kbd-interactive in ssh2 and the tis protocol messages in ssh1. -m On Wed, May 22, 2002 at 04:34:18PM +0200, Natalia Currle-Linde wrote: > Hello all, > is there any recent information on programming on how to add a new > authentication method into OpenSSH / OpenSSL ?! > > Is there any other way, to add a new authentication method into openssh > (one-time passwords), apart from adding the functions into sshconnect.c > and sshconnect2.c > > Particularly I'm interested in information on "struct Authctxt" in > sshconnect2 and sshuserauth2. > > Thank You very much in advance. > > Greetings, > N. Linde > > PS: Please CC to me directly, since I'm not subscribed to the list. > -- > --------------------------------------------------------------- > Dipl.-Inf. N. Currle-Linde Linde at hlrs.de > Allmandring 30 http://www.hlrs.de/people/linde > 70550 Stuttgart Tel.: 0711 / 685 5801 > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From bbense at networking.stanford.edu Thu May 23 00:41:11 2002 From: bbense at networking.stanford.edu (Booker C. Bense) Date: Wed, 22 May 2002 07:41:11 -0700 (PDT) Subject: OpenSSH programming In-Reply-To: <3CEBAC6A.2818875D@hlrs.de> Message-ID: On Wed, 22 May 2002, Natalia Currle-Linde wrote: > Hello all, > is there any recent information on programming on how to add a new > authentication method into OpenSSH / OpenSSL ?! > > Is there any other way, to add a new authentication method into openssh > (one-time passwords), apart from adding the functions into sshconnect.c > and sshconnect2.c - Probably the easiest way to accomplish this would be to write a PAM module. There are existing PAM modules for several different kinds of authentication methods. Try looking on sourceforge.net for some examples. - Booker C. Bense From shawn.starr at datawire.net Wed May 22 20:19:51 2002 From: shawn.starr at datawire.net (Shawn Starr) Date: 22 May 2002 06:19:51 -0400 Subject: Strange behaviour with OpenSSH 3.1p1 + Message-ID: <1022062791.23492.17.camel@unaropia.dw> I've been using OpenSSH for quite along time now and I've ran into this strange bug: ssh_askpass: exec(/usr/local/libexec/ssh-askpass): No such file or directory Host key verification failed. This happens when i have X running. Without X I see the following: .... debug1: read PEM private key done: type DSA debug1: read PEM private key done: type RSA debug1: identity file /home/spstarr/.ssh/identity type -1 debug1: identity file /home/spstarr/.ssh/id_rsa type -1 debug1: identity file /home/spstarr/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.1p1 debug1: match: OpenSSH_3.1p1 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.1p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 141/256 debug1: bits set: 1604/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY Host key verification failed. debug1: Calling cleanup 0x80643b0(0x0) Also, when I wipe out $HOME/.ssh SSH does *NOT* generate a known_hosts file. Its supposed to prompt me for host identification/key but it doesn't. I've also removed ssh_config and sshd_config and this still happens. But when I run ssh as root it works fine (?). sshd is setuid root. If I copy root's .ssh to my $HOME dir, then SSH runs but it rejects all methods of authentification. OpenSSH built with configure options: --sysconfdir=/etc/ssh --with-md5-passwords What broke? ;-) This is from a Linux environment. -- Shawn Starr Developer Support Engineer Datawire Communication Networks Inc. 10 Carlson Court, Suite 300 Toronto, ON, M9W 6L2 T: 416-213-2001 ext 179 F: 416-213-2008 From lhecking at nmrc.ie Thu May 23 03:10:19 2002 From: lhecking at nmrc.ie (Lars Hecking) Date: Wed, 22 May 2002 18:10:19 +0100 Subject: openssh 3.2.2p1 problem on Solaris In-Reply-To: <20020520172055.GA5904@nmrc.ie> References: <20020520170741.GA5716@nmrc.ie> <20020520172055.GA5904@nmrc.ie> Message-ID: <20020522171019.GA20980@nmrc.ie> Lars Hecking writes: > Tim Rice writes: > > > > There was a setsid() call added that seems to bother solaris. > > See http://bugzilla.mindrot.org/show_bug.cgi?id=245 > > I see. > > My case is covered by Robert Andersson's comments then, my login shell > is tcsh, too. For the record, Kevin's patch fixes both problems here (no controlling terminal, and problem logging out). As for Carson's comment on the POSIXness of Solaris' setsid(): Stevens' Advanced Programming in the UNIX Environment, section 9.5 Sessions, describes setsid() in the same way. Which is good enough for me to assume Solaris conformance :) From john at scl.co.uk Thu May 23 03:10:16 2002 From: john at scl.co.uk (John Sutton) Date: Wed, 22 May 2002 18:10:16 +0100 Subject: error: ioctl(TIOCSCTTY) Message-ID: <02052218255300.26266@diva.localdomain> Hi there I've just upgraded to openssh-3.2.2p1 from openssh-1.2.3 and am having some difficulties. On one of the platforms I'm using (linux kernel 2.2.19 with glibc 2.1.1) it works fine, but on another (linux kernel 2.2.20 with glibc 2.0.7) I get this in the syslog every time I log in: sshd[12277]: Accepted publickey for root from 212.38.67.158 port 2397 ssh2 PAM_pwdb[12277]: (sshd) session opened for user root by (uid=0) sshd[12280]: error: ioctl(TIOCSCTTY): Operation not permitted sshd[12280]: error: open /dev/tty failed - could not set controlling tty: Device not configured But the real issue (and this might be related to the stuff in the log?) is the behaviour of the INTR key. ssty -a says that intr has the "usual" mapping to ^C. But pressing ^C terminates the session rather than terminating the current command! Ouch. It doesn't matter whether there _is_ a current command running or the shell is just sitting at the prompt - pressing ^C terminates the current session - and the only difference is this: if there _is_ a command running when I press ^C, that command becomes detached from the controlling terminal and continues to run. I've built from source on both platforms. Any ideas? TIA *************************************************** John Sutton SCL Internet URL http://www.scl.co.uk/ Tel. +44 (0) 1239 711 888 *************************************************** From mouring at etoh.eviladmin.org Thu May 23 03:51:38 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 22 May 2002 12:51:38 -0500 (CDT) Subject: error: ioctl(TIOCSCTTY) In-Reply-To: <02052218255300.26266@diva.localdomain> Message-ID: This sounds like the same issue as Solaris. See http://bugzilla.mindrot.org/show_bug.cgi?id=245 - Ben On Wed, 22 May 2002, John Sutton wrote: > Hi there > > I've just upgraded to openssh-3.2.2p1 from openssh-1.2.3 and am having > some difficulties. > > On one of the platforms I'm using (linux kernel 2.2.19 with glibc 2.1.1) > it works fine, but on another (linux kernel 2.2.20 with glibc 2.0.7) I get > this in the syslog every time I log in: > > sshd[12277]: Accepted publickey for root from 212.38.67.158 port 2397 ssh2 > PAM_pwdb[12277]: (sshd) session opened for user root by (uid=0) > sshd[12280]: error: ioctl(TIOCSCTTY): Operation not permitted > sshd[12280]: error: open /dev/tty failed - could not set controlling tty: Device not configured > > But the real issue (and this might be related to the stuff in the log?) is > the behaviour of the INTR key. ssty -a says that intr has the "usual" > mapping to ^C. But pressing ^C terminates the session > rather than terminating the current command! Ouch. It doesn't matter > whether there _is_ a current command running or the shell is just sitting > at the prompt - pressing ^C terminates the current session - and the only > difference is this: if there _is_ a command running when I press ^C, > that command becomes detached from the controlling terminal and continues > to run. > > I've built from source on both platforms. > > Any ideas? > > TIA > > *************************************************** > John Sutton > SCL Internet > URL http://www.scl.co.uk/ > Tel. +44 (0) 1239 711 888 > *************************************************** > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From bugzilla-daemon at mindrot.org Thu May 23 05:02:18 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 23 May 2002 05:02:18 +1000 (EST) Subject: [Bug 207] Connect timeout patch Message-ID: <20020522190218.95ACCE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=207 ------- Additional Comments From jclonguet at free.fr 2002-05-23 05:02 ------- Created an attachment (id=101) Patch for OpenSSH-3.2.2p1 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu May 23 05:03:58 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 23 May 2002 05:03:58 +1000 (EST) Subject: [Bug 207] Connect timeout patch Message-ID: <20020522190358.43749E904@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=207 ------- Additional Comments From jclonguet at free.fr 2002-05-23 05:03 ------- Created an attachment (id=102) Patch for OpenSSH-3.2.3p1 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jclonguet at free.fr Thu May 23 05:10:47 2002 From: jclonguet at free.fr (Jean-Charles Longuet) Date: Wed, 22 May 2002 21:10:47 +0200 Subject: [PATCH] connect() timeout Message-ID: <3CEBED37.D74C57F7@free.fr> Here are the new versions of this widely used patch for OpenSSH 3.2.2p1 and 3.2.3p1. The patch avoids waiting to long when using ssh() or scp() on a down host, it is usefull when you have to update many hosts via rsync or rdist themselves relying upon ssh(). It enables a new option 'ConnectTimeout' to control exactly the timeout value, so that it can be used even on slow links. These patches can also be found on http://charts.free.fr/ If you think this patch is worth to be included in the main tree, then you can vote for it on http://bugzilla.mindrot.org/showvotes.cgi?voteon=207 but this requires a login. You can also just browse the case at http://bugzilla.mindrot.org/show_bug.cgi?id=207 Hope this patch help you. -- Jean-Charles -------------- next part -------------- --- openssh-3.2.2p1/readconf.c.ORIG Tue Feb 5 02:26:35 2002 +++ openssh-3.2.2p1/readconf.c Tue May 21 15:40:06 2002 @@ -115,7 +115,8 @@ oKbdInteractiveAuthentication, oKbdInteractiveDevices, oHostKeyAlias, oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication, oHostKeyAlgorithms, oBindAddress, oSmartcardDevice, - oClearAllForwardings, oNoHostAuthenticationForLocalhost + oClearAllForwardings, oNoHostAuthenticationForLocalhost, + oConnectTimeout } OpCodes; /* Textual representations of the tokens. */ @@ -187,6 +188,7 @@ { "smartcarddevice", oSmartcardDevice }, { "clearallforwardings", oClearAllForwardings }, { "nohostauthenticationforlocalhost", oNoHostAuthenticationForLocalhost }, + { "connecttimeout", oConnectTimeout }, { NULL, oBadOption } }; @@ -294,6 +296,19 @@ /* don't panic, but count bad options */ return -1; /* NOTREACHED */ + + case oConnectTimeout: + intptr = &options->connection_timeout; +parse_time: + arg = strdelim(&s); + if (!arg || *arg == '\0') + fatal("%.200s line %d: Missing time argument.", filename, linenum); + if ((value = convtime(arg)) == -1) + fatal("%.200s line %d: Invalid time argument.", filename, linenum); + if (*intptr == -1) + *intptr = value; + break; + case oForwardAgent: intptr = &options->forward_agent; parse_flag: @@ -775,6 +790,7 @@ options->compression_level = -1; options->port = -1; options->connection_attempts = -1; + options->connection_timeout = -1; options->number_of_password_prompts = -1; options->cipher = -1; options->ciphers = NULL; --- openssh-3.2.2p1/readconf.h.ORIG Tue Mar 5 02:53:05 2002 +++ openssh-3.2.2p1/readconf.h Tue May 21 15:40:06 2002 @@ -68,6 +68,8 @@ int port; /* Port to connect. */ int connection_attempts; /* Max attempts (seconds) before * giving up */ + int connection_timeout; /* Max time (seconds) before + * aborting connection attempt */ int number_of_password_prompts; /* Max number of password * prompts. */ int cipher; /* Cipher to use. */ --- openssh-3.2.2p1/ssh.1.ORIG Wed May 15 23:36:46 2002 +++ openssh-3.2.2p1/ssh.1 Tue May 21 15:40:06 2002 @@ -813,6 +813,12 @@ The argument must be an integer. This may be useful in scripts if the connection sometimes fails. The default is 1. +.It Cm ConnectTimeout +Specifies the timeout used when connecting to the ssh +server, instead of using default system values. This value is used +only when the target is down or really unreachable, not when it +refuses the connection. This may be usefull for tools using ssh +for communication, as it avoid long TCP timeouts. .It Cm DynamicForward Specifies that a TCP/IP port on the local machine be forwarded over the secure channel, and the application --- openssh-3.2.2p1/ssh.c.ORIG Tue Apr 23 13:09:46 2002 +++ openssh-3.2.2p1/ssh.c Tue May 21 15:40:06 2002 @@ -677,7 +677,7 @@ /* Open a connection to the remote host. */ cerr = ssh_connect(host, &hostaddr, options.port, IPv4or6, - options.connection_attempts, + options.connection_attempts, options.connection_timeout, original_effective_uid != 0 || !options.use_privileged_port, pw, options.proxy_command); --- openssh-3.2.2p1/sshconnect.c.ORIG Tue Mar 5 19:59:46 2002 +++ openssh-3.2.2p1/sshconnect.c Tue May 21 15:40:06 2002 @@ -222,6 +222,63 @@ return sock; } +int +timeout_connect(int sockfd, const struct sockaddr *serv_addr, + socklen_t addrlen, int timeout) +{ + fd_set *fdset; + struct timeval tv; + socklen_t optlen; + int fdsetsz, optval, rc; + + if (timeout <= 0) + return(connect(sockfd, serv_addr, addrlen)); + + if (fcntl(sockfd, F_SETFL, O_NONBLOCK) < 0) + return -1; + + rc = connect(sockfd, serv_addr, addrlen); + if (rc == 0) + return 0; + if (errno != EINPROGRESS) + return -1; + + fdsetsz = howmany(sockfd+1, NFDBITS) * sizeof(fd_mask); + fdset = (fd_set *)xmalloc(fdsetsz); + memset(fdset, 0, fdsetsz); + FD_SET(sockfd, fdset); + tv.tv_sec = timeout; + tv.tv_usec = 0; + rc=select(sockfd+1, NULL, fdset, NULL, &tv); + + switch(rc) { + case 0: + errno = ETIMEDOUT; + case -1: + return -1; + break; + case 1: + optval = 0; + optlen = sizeof(optval); + if (getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &optval, &optlen) == -1) + return -1; + if (optval != 0) + { + errno = optval; + return -1; + } + return 0; + + default: + /* Should not occur */ + return -1; + break; + } + + return -1; + +} + /* * Opens a TCP/IP connection to the remote server on the given host. * The address of the remote host will be returned in hostaddr. @@ -241,7 +298,7 @@ */ int ssh_connect(const char *host, struct sockaddr_storage * hostaddr, - u_short port, int family, int connection_attempts, + u_short port, int family, int connection_attempts, int connection_timeout, int anonymous, struct passwd *pw, const char *proxy_command) { int gaierr; @@ -323,7 +380,8 @@ * the remote uid as root. */ temporarily_use_uid(pw); - if (connect(sock, ai->ai_addr, ai->ai_addrlen) >= 0) { + if (timeout_connect(sock, ai->ai_addr, ai->ai_addrlen, + connection_timeout) >= 0) { /* Successful connection. */ memcpy(hostaddr, ai->ai_addr, ai->ai_addrlen); restore_uid(); --- openssh-3.2.2p1/sshconnect.h.ORIG Wed Oct 10 07:07:45 2001 +++ openssh-3.2.2p1/sshconnect.h Tue May 21 15:40:06 2002 @@ -28,7 +28,7 @@ int ssh_connect(const char *, struct sockaddr_storage *, u_short, int, int, - int, struct passwd *, const char *); + int, int, struct passwd *, const char *); void ssh_login(Key **, int, const char *, struct sockaddr *, struct passwd *); -------------- next part -------------- --- openssh-3.2.3p1/readconf.c.ORIG Tue Feb 5 02:26:35 2002 +++ openssh-3.2.3p1/readconf.c Wed May 22 19:45:13 2002 @@ -115,7 +115,8 @@ oKbdInteractiveAuthentication, oKbdInteractiveDevices, oHostKeyAlias, oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication, oHostKeyAlgorithms, oBindAddress, oSmartcardDevice, - oClearAllForwardings, oNoHostAuthenticationForLocalhost + oClearAllForwardings, oNoHostAuthenticationForLocalhost, + oConnectTimeout } OpCodes; /* Textual representations of the tokens. */ @@ -187,6 +188,7 @@ { "smartcarddevice", oSmartcardDevice }, { "clearallforwardings", oClearAllForwardings }, { "nohostauthenticationforlocalhost", oNoHostAuthenticationForLocalhost }, + { "connecttimeout", oConnectTimeout }, { NULL, oBadOption } }; @@ -294,6 +296,19 @@ /* don't panic, but count bad options */ return -1; /* NOTREACHED */ + + case oConnectTimeout: + intptr = &options->connection_timeout; +parse_time: + arg = strdelim(&s); + if (!arg || *arg == '\0') + fatal("%.200s line %d: Missing time argument.", filename, linenum); + if ((value = convtime(arg)) == -1) + fatal("%.200s line %d: Invalid time argument.", filename, linenum); + if (*intptr == -1) + *intptr = value; + break; + case oForwardAgent: intptr = &options->forward_agent; parse_flag: @@ -775,6 +790,7 @@ options->compression_level = -1; options->port = -1; options->connection_attempts = -1; + options->connection_timeout = -1; options->number_of_password_prompts = -1; options->cipher = -1; options->ciphers = NULL; --- openssh-3.2.3p1/readconf.h.ORIG Tue Mar 5 02:53:05 2002 +++ openssh-3.2.3p1/readconf.h Wed May 22 19:45:13 2002 @@ -68,6 +68,8 @@ int port; /* Port to connect. */ int connection_attempts; /* Max attempts (seconds) before * giving up */ + int connection_timeout; /* Max time (seconds) before + * aborting connection attempt */ int number_of_password_prompts; /* Max number of password * prompts. */ int cipher; /* Cipher to use. */ --- openssh-3.2.3p1/ssh.1.ORIG Wed May 15 23:36:46 2002 +++ openssh-3.2.3p1/ssh.1 Wed May 22 19:45:13 2002 @@ -813,6 +813,12 @@ The argument must be an integer. This may be useful in scripts if the connection sometimes fails. The default is 1. +.It Cm ConnectTimeout +Specifies the timeout used when connecting to the ssh +server, instead of using default system values. This value is used +only when the target is down or really unreachable, not when it +refuses the connection. This may be usefull for tools using ssh +for communication, as it avoid long TCP timeouts. .It Cm DynamicForward Specifies that a TCP/IP port on the local machine be forwarded over the secure channel, and the application --- openssh-3.2.3p1/ssh.c.ORIG Tue Apr 23 13:09:46 2002 +++ openssh-3.2.3p1/ssh.c Wed May 22 19:45:13 2002 @@ -677,7 +677,7 @@ /* Open a connection to the remote host. */ cerr = ssh_connect(host, &hostaddr, options.port, IPv4or6, - options.connection_attempts, + options.connection_attempts, options.connection_timeout, original_effective_uid != 0 || !options.use_privileged_port, pw, options.proxy_command); --- openssh-3.2.3p1/sshconnect.c.ORIG Tue Mar 5 19:59:46 2002 +++ openssh-3.2.3p1/sshconnect.c Wed May 22 19:45:13 2002 @@ -222,6 +222,63 @@ return sock; } +int +timeout_connect(int sockfd, const struct sockaddr *serv_addr, + socklen_t addrlen, int timeout) +{ + fd_set *fdset; + struct timeval tv; + socklen_t optlen; + int fdsetsz, optval, rc; + + if (timeout <= 0) + return(connect(sockfd, serv_addr, addrlen)); + + if (fcntl(sockfd, F_SETFL, O_NONBLOCK) < 0) + return -1; + + rc = connect(sockfd, serv_addr, addrlen); + if (rc == 0) + return 0; + if (errno != EINPROGRESS) + return -1; + + fdsetsz = howmany(sockfd+1, NFDBITS) * sizeof(fd_mask); + fdset = (fd_set *)xmalloc(fdsetsz); + memset(fdset, 0, fdsetsz); + FD_SET(sockfd, fdset); + tv.tv_sec = timeout; + tv.tv_usec = 0; + rc=select(sockfd+1, NULL, fdset, NULL, &tv); + + switch(rc) { + case 0: + errno = ETIMEDOUT; + case -1: + return -1; + break; + case 1: + optval = 0; + optlen = sizeof(optval); + if (getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &optval, &optlen) == -1) + return -1; + if (optval != 0) + { + errno = optval; + return -1; + } + return 0; + + default: + /* Should not occur */ + return -1; + break; + } + + return -1; + +} + /* * Opens a TCP/IP connection to the remote server on the given host. * The address of the remote host will be returned in hostaddr. @@ -241,7 +298,7 @@ */ int ssh_connect(const char *host, struct sockaddr_storage * hostaddr, - u_short port, int family, int connection_attempts, + u_short port, int family, int connection_attempts, int connection_timeout, int anonymous, struct passwd *pw, const char *proxy_command) { int gaierr; @@ -323,7 +380,8 @@ * the remote uid as root. */ temporarily_use_uid(pw); - if (connect(sock, ai->ai_addr, ai->ai_addrlen) >= 0) { + if (timeout_connect(sock, ai->ai_addr, ai->ai_addrlen, + connection_timeout) >= 0) { /* Successful connection. */ memcpy(hostaddr, ai->ai_addr, ai->ai_addrlen); restore_uid(); --- openssh-3.2.3p1/sshconnect.h.ORIG Wed Oct 10 07:07:45 2001 +++ openssh-3.2.3p1/sshconnect.h Wed May 22 19:45:13 2002 @@ -28,7 +28,7 @@ int ssh_connect(const char *, struct sockaddr_storage *, u_short, int, int, - int, struct passwd *, const char *); + int, int, struct passwd *, const char *); void ssh_login(Key **, int, const char *, struct sockaddr *, struct passwd *); From ssklar at stanford.edu Thu May 23 05:49:49 2002 From: ssklar at stanford.edu (Sandor W. Sklar) Date: Wed, 22 May 2002 12:49:49 -0700 Subject: chrooting/jailing transfer-only accounts In-Reply-To: References: Message-ID: At 9:20a -0500 5/22/02, Ben Lindstrom wrote: >I'm sorry but I know I don't read binhex. sorry bout that; I've pasted the script below (and attached it with mime-encoding.) > >But assuming you did what has been discussed here before which is wrote >some from of program that detects the -c argument passed to it and accept >or deny the commands. This can work for sftp-server also. Because we >do ${SHELL} -c sftp-server just like one would expect. Right, but when using (openssh) scp, the $SSH_ORIGINAL_COMMAND contains "scp", and one of several arguments, and the name (or names) of the file(s) being transferred. Thus, it is easy to break up that command and modify it on the server-side. I see no equivalent way of doing so when the server is spawning the sftp-server. Thanks, -S- #!/usr/local/bin/perl # ===================================================================== # scpjail - restricts a user account to doing nothing but scp'ing to # and from a "jailed" directory. Adapted from (and improved # on) a script included in the Snailbook FAQ. # --------------------------------------------------------------------- # $Id: scpjail,v 1.8 2002/05/22 19:05:03 ssklar Exp ssklar $ # ===================================================================== use strict; use Sys::Syslog; # ===================================================================== # the following options should be defined in this script: # ===================================================================== # $scp : the location of scp on this system ... my $scp = "/usr/local/bin/scp"; # $jail : the directory UNDERNEATH the user's home directory that the # user's account will be restricted to ... my $jail = "JAIL"; # $logfac : the facility to be used by syslog when logging messages from # this program ... my $logfac = "auth"; # ===================================================================== # change nothing below here (except in the RCS version, of course) # ===================================================================== # what's my name? ( my $me = $0 ) =~ s|\S+/||g; # who is running me? my $user = getpwuid($<); # open syslog for logging ... openlog ("$me", "pid", "$logfac") or die ("$me : couldn't open syslog, dying now.\n"); # log at priority info ... syslog ("info", "starting $me for $user"); # get the user's home directory ... my $home = sub { $_[7] } -> (getpwuid($<)) or fail ("info", "couldn't get user home directory, dying now."); # make sure that $SSH_ORIGINAL_COMMAND has a value ... unless ( $ENV{SSH_ORIGINAL_COMMAND} ) { fail ("info", "environment variable SSH_ORIGINAL_COMMAND undefined, dying now.") }; # split $SSH_ORIGINAL_COMMAND on whitespace ... my @command = split ( /\s+/, $ENV{SSH_ORIGINAL_COMMAND} ); # empty out the environment for safety's sake ... undef %ENV; # die unless the first element of @command is not "scp" ... unless ( $command[0] eq "scp" ) { fail ("info", "account rescticted to scp only, dying now.") }; shift @command; # start looping through the contents of @command ... my ($action, $file); while (@command) { # figure out the "action" and the "file" ... if ($command[0] eq "-d") { # the user is "putting" multiple files ... $action = "-d -t"; # $file is the destination directory and (possibily) the name that # the file is to be called on the server ... $file = "$command[$#command]"; last } elsif ($command[0] eq "-t") { # the user is "putting" a single file ... $action = "-t"; # $file is the destination directory and (possibily) the name that # the file is to be called on the server ... $file = "$command[$#command]"; last } elsif ($command[0] eq "-f") { # the user is "getting" a file or files from the server ... $action = "-f"; shift @command; # $file is either a single file or multiple files (space-separated) # that the user is retrieving ... $file = join(" ", @command); last } else { # the user either specified "-v" with their command, or is trying to # do evil things ... shift @command } }; # unless both $action and $file are defined, something went wrong ... unless (defined($action) && defined($file)) { fail ("info", "action and/or file is not defined, dying now.") }; # fix up potential weird values of $file ... if ($file eq "." || $file eq "~") { $file = "$home/$jail" }; if ($file eq "$home" || $file eq "$home/$jail") { $file = "$home/$jail" }; # check for possible shell escapes in the contents of $file ... if ( $file =~ /;|\(|\|\>|&/ ) { fail ("info", "file contains suspicious character: $file") }; # if we made it this far, log our success and do the requested # scp operation ... syslog ("notice", "executing $scp $action $file for user $user"); closelog (); exec ( "$scp", "$action", "$file" ); # --------------------------------------------------------------------- # fail : subroutine that logs an error to syslog, prints it to the, # user, and dies. # --------------------------------------------------------------------- sub fail { my ($priority, $msg) = @_; syslog ("$priority", "$msg"); closelog (); die ("$me : $msg\n") }; # --------------------------------------------------------------------- # here be POD ... # --------------------------------------------------------------------- =pod =head1 NAME scpjail - forces a restricted scp-only account within a jailed directory. =head1 USAGE =over 2 =item * Create the user account in the normal way, with a real shell, and a real home directory. Do NOT set a password for the account (i.e., have a "*" or "!" in /etc/security/user | /etc/shadow | whatever.) =item * Set the permissions on the user's home directory so that the user DOES NOT have write access. If other users on the system will need read or write access to content in the jailed user's home, that is fine, but it is critical that the jailed user does not have write access. # chmod 500 /home/luser ; ls -ld /home/luser dr-x------ 4 luser staff 512 May 09 21:41 /home/luser =item * Confirm that any files directly in the user's home directory are NOT writable by the user account. This includes any shell startup files. In fact, there is no reason to have any shell startup files, so if it is easier to just delete .login or .profile, go for it. =item * Create the .ssh directory in the user's home directory. This directory MUST be owned by the user account, and MUST be chmod'ed 500 (so that it is not writable by anyone, and is readable/executable only for the user.) # mkdir /home/luser/.ssh ; chmod 500 /home/luser/.ssh # ls -ld /home/luser/.ssh dr-x------ 2 luser system 512 May 07 19:50 /home/luser/.ssh =item * In that .ssh directory, place the user's public half of their keypair into the file "authorized_keys". THIS IS IMPORTANT: insert, on the same line as the key, before the key, the text: command="/path/to/scpjail". This is important, because it restricts any use of this key to the execution of this scpjail script, no matter what the user tries to do. It is also important to again make sure that the authorized_keys file is NOT writable by the user account (or anyone.) # chmod 400 /home/luser/.ssh/authorized_keys # ls -ld /home/luser/.ssh/authorized_keys -r-------- 1 luser system 1291 May 09 21:41 /home/luser/.ssh/authorized_keys # cat /home/luser/.ssh/authorized_keys command="/usr/local/sbin/scpjail" ssh-dss AAAAB3NMAAACBAIIPIu9j2 ... blah blah blah ... LQwxMc7k6xoIE1qFBWWXjMZeQ== luser at foobar =item * Finally, create the "jail" directory, inside the home directory of the user. By default, the name of this directory is "JAIL", but this can be changed by modifying the scpjail script. The user must be able to write to this directory (in fact, it should be the only place that the user can write to.) # mkdir /home/luser/JAIL ; chmod 740 /home/luser/JAIL # ls -ld /home/luser/JAIL drwxr----- 2 luser system 512 May 09 22:04 /home/luser/JAIL And that is it! =back =head1 LOGGING scpjail will write a message to syslog at facility "auth", priority "notice" each time it is used sucessfully: May 9 22:04:49 whippet scpjail[43364]: executing /usr/local/bin/scp -t /home/luser/JAIL for user luser scpjail also logs messages at priority "info" at numerous places in the script where the attempted connection might fail for various reasons: May 9 21:48:09 whippet scpjail[31482]: environment variable SSH_ORIGINAL_COMMAND undefined, dying now. =head1 CONFIGURATION There are three configurable items, all set by modifying the scpjail script: I<$scp> contains the full path and name of the scp program on the server. By default, it is defined as "/usr/local/bin/scp". I<$jail> contains the name of the directory within the user's home that the user will be jailed into. By default, it is defined as "JAIL". I<$logfac> contains the facility at which scpjail will send syslog messages. By default, it is defined as "auth". =head1 VERSION $Revision: 1.8 $ =head1 AUTHOR Sandor W. Sklar Stanford University ITSS ssklar at stanford.edu http://whippet.stanford.edu/~ssklar/openssh/ =head1 COPYRIGHT This program is free software; you may redistribute it and/or modify it under the same terms as Perl itself. =cut > >- Ben > >On Tue, 21 May 2002, Sandor W. Sklar wrote: > >> Folks, >> >> I've been tasked to find a solution that will create >> file-transfer-only accounts that are jailed or chrooted to a specific >> directory. (Not an uncommon task, I think.) >> >> Using the OpenSSH server and the OpenSSH scp client program, I can >> achieve the goal of having a file transfer only account jailed to a >> specified directory, by using the "scpjail" script (attached) as a >> forced command. >> >> However, if the client is using the SSH.COM's scp2 client program, >> the above technique does not work, since the commercial version uses >> sftp as the underlying method. >> >> So, the only solution I can see is to use one of the several >> chrooting patches that are floating around to the OpenSSH source, and >> set the user's shell to sftp-server. If I do this, I make it >> impossible to use the OpenSSH scp client ; all connections must be >> done using sftp clients. I am also tied to selecting and using one >> of these patches, which I admit, I do not have the technical ability >> to judge on their merits and potential weaknesses. I am phobic about >> using patches that are not part of the baseline code (especially for >> security-related software), as it creates one more thing to worry >> about. >> >> My question is, does anyone see a solution that I am missing here? >> Complaining to SSH.COM is not a solution, as it does not solve my >> problem. It is not in my power to force the user community to use >> only the OpenSSH implementation. >> >> I've seen many mails on this list lately talking about the pros and >> cons of including chroot-ability; the people who seem to feel that it >> is unnecessary have said that it is easy enough to implement outside >> of OpenSSH. I don't have the ability to do so; among the community >> of OpenSSH users, I doubt I'm alone in this. >> >> (As an aside, I'd appreciate it if people would look at the attached >> script, and let me know if they can see any obvious holes in it. >> I've tried unsuccessfully to break out if it is set up properly, but >> others may have more success.) >> >> Thanks, -S- >> >> -- >> Sandor W. Sklar - Unix Systems Administrator - Stanford >>University ITSS >> Non impediti ratione cogitationis. >>http://whippet.stanford.edu/~ssklar/ > >_______________________________________________ >openssh-unix-dev at mindrot.org mailing list >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- Sandor W. Sklar - Unix Systems Administrator - Stanford University ITSS Non impediti ratione cogitationis. http://whippet.stanford.edu/~ssklar/ -------------- next part -------------- A non-text attachment was scrubbed... Name: %scpjail Type: application/applefile Size: 117 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020522/3072cbf2/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: scpjail Type: application/octet-stream Size: 8677 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020522/3072cbf2/attachment.obj From markus at openbsd.org Thu May 23 05:54:04 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 22 May 2002 21:54:04 +0200 Subject: Openssh still logs in while passwd is locked (fwd) Message-ID: <20020522195404.GA10894@faui02> -------------- next part -------------- An embedded message was scrubbed... From: John Horne Subject: Openssh still logs in while passwd is locked Date: Wed, 22 May 2002 15:20:08 +0100 (BST) Size: 2486 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020522/8eef78dd/attachment.mht From Darren.Moffat at Sun.COM Thu May 23 06:12:07 2002 From: Darren.Moffat at Sun.COM (Darren Moffat) Date: Wed, 22 May 2002 13:12:07 -0700 (PDT) Subject: Openssh still logs in while passwd is locked Message-ID: <200205222012.g4MKCn6U317449@jurassic.eng.sun.com> >Using OpenSSH 3.1p1 on a Sun Solaris 7 box, I disabled an account using the >'passwd -l ...' command to lock the users password. However, the user can >still access the system via ssh. Whilst I could do other things such as >moving their .ssh directory, removing their account home directory, etc, >etc, is there some 'nicer' way to inform ssh that the account is now locked >and thus to not allow them to login? The pam_unix.so module doesn't check for *LK* in pam_acct_mgmt since it was assuming that pam_authenticate() had been called already - in those cases it would fail. If however you are using publickey authentication rather than going through PAM with a password pam_acct_mgmt is called without first going to pam_authenticate(). This has been fixed in the new pam modules for Solaris 9 where pam_unix_account.so does an explicit check for *LK* so it is now safe to call pam_acct_mgmt() if pam_authenticate() wasn't called. I would say that this is a bug in pam_unix.so on Solaris 2.6 onwards, you should log a call with Sun Enterprise Services. I would recommend stating the bug as follows: pam_sm_acct_mgmt() in pam_unix.so.1 does not check for the users password being the lockstring (*LK*). This has already been fixed in Solaris 9 pam_unix_account.so and I would like a similar fix applied to pam_unix.so.1 for Solaris 7 onwards. -- Darren J Moffat From bugzilla-daemon at mindrot.org Thu May 23 09:23:48 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 23 May 2002 09:23:48 +1000 (EST) Subject: [Bug 124] Terminal hangs when data is streaming to it... Message-ID: <20020522232348.12930E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=124 ------- Additional Comments From gdg at zplane.com 2002-05-23 09:23 ------- Damien, I just installed 3.2.3p1, no help. Glenn ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Graham.King at team.ozemail.com.au Thu May 23 10:12:31 2002 From: Graham.King at team.ozemail.com.au (Graham King) Date: Thu, 23 May 2002 10:12:31 +1000 Subject: Problems with OpenSSH 3.2.2p1 on Solaris 7 Message-ID: <74AB07E55B7BD411B33200508B605FCF0611D3A0@mail-is.internal.ozemail.com.au> Hi, just joined the list... got this problem as mentioned above, so found this list, and in reply: We just tried out 3.2.2p1 on Solaris 7, got the same error message as prev mentioned >>Warning: no access to tty (Inappropriate ioctl for device). >>Thus no job control in this shell. >>everything works alright with 3.0p1, but 3.1p1 and 3.2.2p1 seems to have this problem. you have that with 3.1p1 as well? We find 3.1p1 is OK on Solaris 7, with openssl 0.9.6c and when compiled from source (had issues with the precompiled package). cheers Graham From tim at multitalents.net Thu May 23 14:33:40 2002 From: tim at multitalents.net (Tim Rice) Date: Wed, 22 May 2002 21:33:40 -0700 (PDT) Subject: 3.2.2p1 build problem on Irix6.5 In-Reply-To: <20020521181717.GD1728@jenny.crlsca.adelphia.net> Message-ID: On Tue, 21 May 2002, Kevin Steves wrote: > On Tue, May 21, 2002 at 10:18:22AM +0100, Dave Love wrote: > > Tim Rice writes: > > > > > What is the output of grep _MSG config.h > > > > #define HAVE_ACCRIGHTS_IN_MSGHDR 1 > > #define HAVE_CONTROL_IN_MSGHDR 1 > > I think we need to have runtime checks in configure that result in: > HAVE_ACCRIGHTS_FD_PASSING > HAVE_CONTROL_FD_PASSING > I think I have the configure tests worked out. I'll post a patch in the next couple of days for the Irix people to test. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bugzilla-daemon at mindrot.org Thu May 23 16:27:30 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 23 May 2002 16:27:30 +1000 (EST) Subject: [Bug 223] ProxyCommand commands don't exit Message-ID: <20020523062730.99AD0E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=223 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- OS/Version|FreeBSD |All Platform|ix86 |All Version|3.0.1p1 |-current ------- Additional Comments From dtucker at zip.com.au 2002-05-23 16:27 ------- Also observed on Solaris 7 & 8 with OpenSSH 3.2.2p1. You end up with an orphaned sh -c: $ ps -eaf | grep nc root 219 218 0 16:18:27 pts/4 0:01 ssh relayhost nc 10.3.1.1 22 root 218 1 0 16:18:27 pts/4 0:00 /bin/sh -c ssh relayhost nc 10.3.1.1 22 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Markus_Friedl at genua.de Thu May 23 18:08:13 2002 From: Markus_Friedl at genua.de (Markus Friedl) Date: Thu, 23 May 2002 10:08:13 +0200 Subject: OpenSSH 3.2.3 released Message-ID: <20020523080813.GA27960@muamat> OpenSSH 3.2.3 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support and encouragement. Changes since OpenSSH 3.2.2: ============================ This release fixes several problems in OpenSSH 3.2.2: - a defect in the BSD_AUTH access control handling for OpenBSD and BSD/OS systems: Under certain conditions, on systems using YP with netgroups in the password database, it is possible that sshd does ACL checks for the requested user name but uses the password database entry of a different user for authentication. This means that denied users might authenticate successfully while permitted users could be locked out (OpenBSD PR 2659). - login/tty problems on Solaris (bug #245) - build problems on Cygwin systems Changes between OpenSSH 3.1 and OpenSSH 3.2.2: ============================================== Security Changes: ================= - fixed buffer overflow in Kerberos/AFS token passing - fixed overflow in Kerberos client code - sshd no longer auto-enables Kerberos/AFS - experimental support for privilege separation, see UsePrivilegeSeparation in sshd(8) and http://www.citi.umich.edu/u/provos/ssh/privsep.html for more information. - only accept RSA keys of size SSH_RSA_MINIMUM_MODULUS_SIZE (768) or larger Other Changes: ============== - improved smartcard support (including support for OpenSC, see www.opensc.org) - improved Kerberos support (including support for MIT-Kerberos V) - fixed stderr handling in protocol v2 - client reports failure if -R style TCP forwarding fails in protocol v2 - support configuration of TCP forwarding during interactive sessions (~C) - improved support for older sftp servers - improved support for importing old DSA keys (from ssh.com software). - client side suport for PASSWD_CHANGEREQ in protocol v2 - fixed waitpid race conditions - record correct lastlogin time Reporting Bugs: =============== - please read http://www.openssh.com/report.html and http://bugzilla.mindrot.org/ OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller and Ben Lindstrom. From markus at openbsd.org Thu May 23 18:33:04 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 23 May 2002 10:33:04 +0200 Subject: RSARhosts / Hostbased auth and euid=0 requirement In-Reply-To: <1630745343.989337796@ZATHROS> References: <20010508234323.A16403@folly> <1630745343.989337796@ZATHROS> Message-ID: <20020523083304.GA5156@folly> On Tue, May 08, 2001 at 04:03:16PM -0700, Carson Gaspar wrote: > >however, i think about moving the client side of > >hostbased authentication out of ssh, to a setuid binary > > /usr/libexec/ssh-keysign > >and remove the sbit from ssh. > >ssh-keysign will read the hostkeys and generate a valid > >signature. > > Great. Is this going to be implemented anytime soon? If so, I withdraw my > suggestion. If not, please lets get a stop-gap solution in place quickly. here's an experimental patch (against OpenBSD's cvs): http://wwwcip.informatik.uni-erlangen.de/user/msfriedl/openssh/ssh-keysign.dif From bugzilla-daemon at mindrot.org Thu May 23 20:02:44 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 23 May 2002 20:02:44 +1000 (EST) Subject: [Bug 223] ProxyCommand commands don't exit Message-ID: <20020523100244.A56E0E92A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=223 ------- Additional Comments From dtucker at zip.com.au 2002-05-23 20:02 ------- Created an attachment (id=103) Kill ProxyCommand child process ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu May 23 20:05:44 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 23 May 2002 20:05:44 +1000 (EST) Subject: [Bug 223] ProxyCommand commands don't exit Message-ID: <20020523100544.C6602E92F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=223 ------- Additional Comments From dtucker at zip.com.au 2002-05-23 20:05 ------- I had a poke around and came up with the attached patch to send a SIGTERM to the ProxyCommand child when ssh exits. I also added an explicit exec to the shell command passed to sh -c, which prevents the shell hanging around on Solaris. This problem doesn't seem to exist on Linux but I think the exec is safe for any platform. The remaining problem is that the child process can send an error message to stderr after the SIGTERM. I'm not sure what (if anything) can be done about that: $ ./ssh -o 'ProxyCommand nc localhost 22' localhost echo punt! Feedback welcome but since this is my first attempt to actually modify openssh please be nice :-). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djm at mindrot.org Fri May 24 00:29:44 2002 From: djm at mindrot.org (Damien Miller) Date: 24 May 2002 00:29:44 +1000 Subject: OpenSSH programming In-Reply-To: References: Message-ID: <1022164184.1423.2.camel@mothra.mindrot.org> On Thu, 2002-05-23 at 00:41, Booker C. Bense wrote: > On Wed, 22 May 2002, Natalia Currle-Linde wrote: > > > Hello all, > > is there any recent information on programming on how to add a new > > authentication method into OpenSSH / OpenSSL ?! > > > > Is there any other way, to add a new authentication method into openssh > > (one-time passwords), apart from adding the functions into sshconnect.c > > and sshconnect2.c > > - Probably the easiest way to accomplish this would be to write a > PAM module. There are existing PAM modules for several different > kinds of authentication methods. Try looking on sourceforge.net > for some examples. Yes, but you still need to hook PAM up to kbd-int properly. It is currently broken with privsep. I posted a patch about 3 weeks ago to make it work, but got no feedback. Since privsep is going to activate by default in future and (IMO) privsep is more important than PAM, people really should start testing this... -d From emh at lfi.cc Fri May 24 02:27:11 2002 From: emh at lfi.cc (Ed Hilovsky) Date: Thu, 23 May 2002 12:27:11 -0400 Subject: SCO Unix Message-ID: I am trying to find ssh_os504.tar.Z for SCO Unix version 5.0.4 This was originally part of the OpenSsh 2.2.0p1 package compiled for different SCO's OSes. Please advise if there is an archive version or where I might get obtain this. Thank you, Ed Hilovsky From francis.le.quellec at cgi.ca Fri May 24 03:52:09 2002 From: francis.le.quellec at cgi.ca (Francis Le Quellec) Date: Thu, 23 May 2002 13:52:09 -0400 Subject: OpenSSH scp gives "truncate file too large" openssh v3.2.3p1 Message-ID: Why the heck a ~2MB file would be too large for a transfer with scp?? I just recompile my sshd on a Linux Sparc machine and got that with version 3.2.3p1 TIA for your responses Francis From greg17 at jewell.net Fri May 24 04:17:43 2002 From: greg17 at jewell.net (Greg Jewell) Date: Thu, 23 May 2002 12:17:43 -0600 Subject: 3.2.3p1 on OpenServer Message-ID: <20020523181743.NBBL11659.rwcrmhc53.attbi.com@solar> Hi All, I compiled the 3.2.3p1 source on SCO OpenServer 5.0.6. When a client connects to it now, they get stair-stepping everywhere. Issuing an stty sane resolves the issue for that login. For bug 245 in 3.2.2p1, the call to setsid() is sshd.c was bypassed due to problems it was causing with Solaris. However, by allowing this method to be called, the stair-stepping goes away. Thanks, Greg Jewell From austin at coremetrics.com Fri May 24 06:02:14 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 23 May 2002 15:02:14 -0500 Subject: Openssh still logs in while passwd is locked In-Reply-To: <200205222012.g4MKCn6U317449@jurassic.eng.sun.com> References: <200205222012.g4MKCn6U317449@jurassic.eng.sun.com> Message-ID: <1022184134.5340.1.camel@UberGeek> I do still see this behavior on Linux as well though. What is the list recommendation for that case, if any? On Wed, 2002-05-22 at 15:12, Darren Moffat wrote: > >Using OpenSSH 3.1p1 on a Sun Solaris 7 box, I disabled an account > using the > >'passwd -l ...' command to lock the users password. However, the > user can > >still access the system via ssh. Whilst I could do other things > such as > >moving their .ssh directory, removing their account home directory, > etc, > >etc, is there some 'nicer' way to inform ssh that the account is > now locked > >and thus to not allow them to login? > > The pam_unix.so module doesn't check for *LK* in pam_acct_mgmt since > it > was assuming that pam_authenticate() had been called already - in > those > cases it would fail. If however you are using publickey > authentication > rather than going through PAM with a password pam_acct_mgmt is > called > without first going to pam_authenticate(). > > This has been fixed in the new pam modules for Solaris 9 where > pam_unix_account.so does an explicit check for *LK* so it is now > safe > to call pam_acct_mgmt() if pam_authenticate() wasn't called. > > I would say that this is a bug in pam_unix.so on Solaris 2.6 > onwards, > you should log a call with Sun Enterprise Services. I would > recommend > stating the bug as follows: > pam_sm_acct_mgmt() in pam_unix.so.1 does not check for the > users > password being the lockstring (*LK*). This has already been > fixed > in Solaris 9 pam_unix_account.so and I would like a similar > fix > applied to pam_unix.so.1 for Solaris 7 onwards. > > -- > Darren J Moffat -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "One ought never to turn one's back on a threatened danger and try to run away from it. If you do that, you will double the danger. But if you meet it promptly and without flinching, you will reduce the danger by half." Sir Winston Churchill -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020523/f4b7f450/attachment.bin From mouring at etoh.eviladmin.org Fri May 24 09:20:12 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 23 May 2002 18:20:12 -0500 (CDT) Subject: chrooting/jailing transfer-only accounts In-Reply-To: Message-ID: On Wed, 22 May 2002, Sandor W. Sklar wrote: > At 9:20a -0500 5/22/02, Ben Lindstrom wrote: > >I'm sorry but I know I don't read binhex. > > sorry bout that; I've pasted the script below (and attached it with > mime-encoding.) > > > > >But assuming you did what has been discussed here before which is wrote > >some from of program that detects the -c argument passed to it and accept > >or deny the commands. This can work for sftp-server also. Because we > >do ${SHELL} -c sftp-server just like one would expect. > > Right, but when using (openssh) scp, the $SSH_ORIGINAL_COMMAND > contains "scp", and one of several arguments, and the name (or names) > of the file(s) being transferred. Thus, it is easy to break up that > command and modify it on the server-side. I see no equivalent way of > doing so when the server is spawning the sftp-server. > [..] > In that .ssh directory, place the user's public half of their keypair > into the file "authorized_keys". THIS IS IMPORTANT: insert, on the > same line as the key, before the key, the text: > command="/path/to/scpjail". This is important, because it restricts > any use of this key to the execution of this scpjail script, no > matter what the user tries to do. > Why? Why don't you just change the user's shell to /path/to/scpjail ? By doing it this way you capture all subsystems, standard logins and remote commands by just reading the command line and looking at anything past the first -c. I don't see a reason why one needs to use command="". The other question is should SSH_ORIGINAL_COMMAND reflect subsystem calls? - Ben From gleblanc at linuxweasel.com Fri May 24 09:52:56 2002 From: gleblanc at linuxweasel.com (Gregory Leblanc) Date: 23 May 2002 16:52:56 -0700 Subject: [Fwd: Re: X-windows security in Gnome] In-Reply-To: <20020519194347.GC14258@folly> References: <1021669179.21625.31.camel@peecee> <20020519194347.GC14258@folly> Message-ID: <1022197987.1657.5.camel@peecee> On Sun, 2002-05-19 at 12:43, Markus Friedl wrote: > On Fri, May 17, 2002 at 01:59:29PM -0700, Gregory Leblanc wrote: > > This is from a security discussion on one of the GNOME lists. Jim is > > one of the original X11 people, for what that's worth. I just thought > > I'd try to tempt some folks here into looking at doing ssh and X > > integration "right". > > well, what is he talking about? I asked Jim for some more info. Here's a link to what he posted. (it's too big to be appropriate for the mailing list) http://mail.gnome.org/archives/gnome-hackers/2002-May/msg00113.html Greg -- Portland, Oregon, USA. Please don't copy me on replies to the list. From ssklar at stanford.edu Sat May 25 00:57:55 2002 From: ssklar at stanford.edu (Sandor W. Sklar) Date: Fri, 24 May 2002 07:57:55 -0700 Subject: chrooting/jailing transfer-only accounts In-Reply-To: References: Message-ID: At 6:20 PM -0500 5/23/02, Ben Lindstrom wrote: > >Why? > >Why don't you just change the user's shell to /path/to/scpjail ? By doing >it this way you capture all subsystems, standard logins and remote >commands by just reading the command line and looking at anything past >the first -c. I don't see a reason why one needs to use command="". I'm not sure what practical difference that makes ... unless I'm missing something, doing so results in the scpjail script being passed the same values, and thus, resulting in the same problem. It would also prevent other users from logging in to the account using a different key, or from other users "su"ing to the account. > >The other question is should SSH_ORIGINAL_COMMAND reflect subsystem calls? > That is not for me to answer. I'm just looking for a solution to the problem I stated in the previous email. Some people feel that this is a "trivial" problem that can be solved without adding code to OpenSSH. If it is, I'm not smart enough to figure it out, and I haven't seen any examples of such a solution posted to the list. -S- -- Sandor W. Sklar - Unix Systems Administrator - Stanford University ITSS Non impediti ratione cogitationis. http://whippet.stanford.edu/~ssklar/ From mouring at etoh.eviladmin.org Sat May 25 00:57:28 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 24 May 2002 09:57:28 -0500 (CDT) Subject: chrooting/jailing transfer-only accounts In-Reply-To: Message-ID: On Fri, 24 May 2002, Sandor W. Sklar wrote: > At 6:20 PM -0500 5/23/02, Ben Lindstrom wrote: > > > >Why? > > > >Why don't you just change the user's shell to /path/to/scpjail ? By doing > >it this way you capture all subsystems, standard logins and remote > >commands by just reading the command line and looking at anything past > >the first -c. I don't see a reason why one needs to use command="". > > I'm not sure what practical difference that makes ... unless I'm > missing something, doing so results in the scpjail script being > passed the same values, and thus, resulting in the same problem. It The difference is you used $0 - $9 to read arguments passed to the shell instead of depending on $SSH_ORIGINAL_COMMAND. The former always gets it right where the latter seems to be missing subsystems. > would also prevent other users from logging in to the account using a > different key, or from other users "su"ing to the account. > The idea of multiple users on one account is sick. It is harder to pin down what is going on and does not improve security. - Ben From tim at multitalents.net Sat May 25 02:20:46 2002 From: tim at multitalents.net (Tim Rice) Date: Fri, 24 May 2002 09:20:46 -0700 (PDT) Subject: 3.2.2p1 build problem on Irix6.5 In-Reply-To: <20020521062814.GA14394@ii.uib.no> Message-ID: On Tue, 21 May 2002, Jan-Frode Myklebust wrote: > On Mon, May 20, 2002 at 04:00:21PM -0700, Tim Rice wrote: > > > > What is the output of grep _MSG config.h > > > > I see the same problem on IRIX 6.5.15m, and the grep returns: > > % grep _MSG config.h > #define HAVE_ACCRIGHTS_IN_MSGHDR 1 > #define HAVE_CONTROL_IN_MSGHDR 1 > % Please test the attached patch. You'll need to run autoconf and remove config.status before running configure. If you don't have autoconf 2.52, grab configure from http://www.multitalents.net/openssh/configure-msghdr-fix.gz ftp://ftp.multitalents.net/pub/openssh/configure-msghdr-fix.gz -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- openssh/configure.ac.old Tue May 21 21:27:46 2002 +++ openssh/configure.ac Thu May 23 21:11:57 2002 @@ -1499,15 +1499,23 @@ AC_DEFINE(HAVE_PW_CHANGE_IN_PASSWD) fi +dnl make sure we're using the real structure members and not defines AC_CACHE_CHECK([for msg_accrights field in struct msghdr], ac_cv_have_accrights_in_msghdr, [ - AC_TRY_COMPILE( + AC_TRY_RUN( [ #include #include #include +int main() { +#ifdef msg_accrights +exit(1); +#endif +struct msghdr m; +m.msg_accrights = 0; +exit(0); +} ], - [ struct msghdr m; m.msg_accrights = 0; ], [ ac_cv_have_accrights_in_msghdr="yes" ], [ ac_cv_have_accrights_in_msghdr="no" ] ) @@ -1518,13 +1526,20 @@ AC_CACHE_CHECK([for msg_control field in struct msghdr], ac_cv_have_control_in_msghdr, [ - AC_TRY_COMPILE( + AC_TRY_RUN( [ #include #include #include +int main() { +#ifdef msg_control +exit(1); +#endif +struct msghdr m; +m.msg_control = 0; +exit(0); +} ], - [ struct msghdr m; m.msg_control = 0; ], [ ac_cv_have_control_in_msghdr="yes" ], [ ac_cv_have_control_in_msghdr="no" ] ) --- openssh/monitor_fdpass.c.old Sat May 11 15:20:08 2002 +++ openssh/monitor_fdpass.c Thu May 23 21:15:32 2002 @@ -39,14 +39,13 @@ struct iovec vec; char ch = '\0'; int n; -#if !defined(HAVE_ACCRIGHTS_IN_MSGHDR) || \ - (defined(HAVE_ACCRIGHTS_IN_MSGHDR) && defined(HAVE_CONTROL_IN_MSGHDR)) +#ifndef HAVE_ACCRIGHTS_IN_MSGHDR char tmp[CMSG_SPACE(sizeof(int))]; struct cmsghdr *cmsg; #endif memset(&msg, 0, sizeof(msg)); -#if defined(HAVE_ACCRIGHTS_IN_MSGHDR) && !defined(HAVE_CONTROL_IN_MSGHDR) +#ifdef HAVE_ACCRIGHTS_IN_MSGHDR msg.msg_accrights = (caddr_t)&fd; msg.msg_accrightslen = sizeof(fd); #else @@ -84,8 +83,7 @@ struct iovec vec; char ch; int fd, n; -#if !defined(HAVE_ACCRIGHTS_IN_MSGHDR) || \ - (defined(HAVE_ACCRIGHTS_IN_MSGHDR) && defined(HAVE_CONTROL_IN_MSGHDR)) +#ifndef HAVE_ACCRIGHTS_IN_MSGHDR char tmp[CMSG_SPACE(sizeof(int))]; struct cmsghdr *cmsg; #endif @@ -95,7 +93,7 @@ vec.iov_len = 1; msg.msg_iov = &vec; msg.msg_iovlen = 1; -#if defined(HAVE_ACCRIGHTS_IN_MSGHDR) && !defined(HAVE_CONTROL_IN_MSGHDR) +#ifdef HAVE_ACCRIGHTS_IN_MSGHDR msg.msg_accrights = (caddr_t)&fd; msg.msg_accrightslen = sizeof(fd); #else @@ -109,7 +107,7 @@ fatal("%s: recvmsg: expected received 1 got %d", __FUNCTION__, n); -#if defined(HAVE_ACCRIGHTS_IN_MSGHDR) && !defined(HAVE_CONTROL_IN_MSGHDR) +#ifdef HAVE_ACCRIGHTS_IN_MSGHDR if (msg.msg_accrightslen != sizeof(fd)) fatal("%s: no fd", __FUNCTION__); #else From kbrint at rufus.net Sat May 25 07:31:51 2002 From: kbrint at rufus.net (kevin brintnall) Date: Fri, 24 May 2002 16:31:51 -0500 Subject: patch for openssh/contrib/solaris/buildpkg.sh Message-ID: <20020524163151.A3228@rufus.net> Here is a small patch for OpenSSH 3.2.3p1.. When the package postinstall script runs, it presumes that the package will be installed relative to the current / directory.. If this package is installed as part of a Solaris Jumpstart installation, this will not be the case. Consequentially, the /etc/ssh/sshd_config.default will never get copied to /etc/ssh/sshd_config on the new operating system. The Solaris package installer defines the environment variable PKG_INSTALL_ROOT to point to the root directory of the installed package. The attached patch makes the postinstall script aware of this. It should now function as designed in a Jumpstart environment also (or any other environment where the PKG_INSTALL_ROOT != /) Cheers! -- kevin brintnall =~ -------------- next part -------------- 174,180c174,180 < [ -f ${sysconfdir}/ssh_config ] || \\ < cp -p ${sysconfdir}/ssh_config.default ${sysconfdir}/ssh_config < [ -f ${sysconfdir}/sshd_config ] || \\ < cp -p ${sysconfdir}/sshd_config.default ${sysconfdir}/sshd_config < [ -f ${sysconfdir}/ssh_prng_cmds.default ] && { < [ -f ${sysconfdir}/ssh_prng_cmds ] || \\ < cp -p ${sysconfdir}/ssh_prng_cmds.default ${sysconfdir}/ssh_prng_cmds --- > [ -f \${PKG_INSTALL_ROOT}${sysconfdir}/ssh_config ] || \\ > cp -p \${PKG_INSTALL_ROOT}${sysconfdir}/ssh_config.default \${PKG_INSTALL_ROOT}${sysconfdir}/ssh_config > [ -f \${PKG_INSTALL_ROOT}${sysconfdir}/sshd_config ] || \\ > cp -p \${PKG_INSTALL_ROOT}${sysconfdir}/sshd_config.default \${PKG_INSTALL_ROOT}${sysconfdir}/sshd_config > [ -f \${PKG_INSTALL_ROOT}${sysconfdir}/ssh_prng_cmds.default ] && { > [ -f \${PKG_INSTALL_ROOT}${sysconfdir}/ssh_prng_cmds ] || \\ > cp -p \${PKG_INSTALL_ROOT}${sysconfdir}/ssh_prng_cmds.default \${PKG_INSTALL_ROOT}${sysconfdir}/ssh_prng_cmds 194,197c194,197 < installf ${PKGNAME} $TEST_DIR/etc/rcS.d/K30${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s < installf ${PKGNAME} $TEST_DIR/etc/rc0.d/K30${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s < installf ${PKGNAME} $TEST_DIR/etc/rc1.d/K30${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s < installf ${PKGNAME} $TEST_DIR/etc/rc2.d/S98${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s --- > installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rcS.d/K30${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s > installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rc0.d/K30${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s > installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rc1.d/K30${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s > installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rc2.d/S98${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s 200,203c200,203 < installf ${PKGNAME} $TEST_DIR/etc/rcS.d/K30${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l < installf ${PKGNAME} $TEST_DIR/etc/rc0.d/K30${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l < installf ${PKGNAME} $TEST_DIR/etc/rc1.d/K30${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l < installf ${PKGNAME} $TEST_DIR/etc/rc2.d/S98${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l --- > installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rcS.d/K30${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l > installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rc0.d/K30${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l > installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rc1.d/K30${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l > installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR/etc/rc2.d/S98${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l 207c207 < [ -d $piddir ] || installf ${PKGNAME} $TEST_DIR$piddir d 755 root sys --- > [ -d $piddir ] || installf ${PKGNAME} \${PKG_INSTALL_ROOT}$TEST_DIR$piddir d 755 root sys From peterw at usa.net Sat May 25 14:33:47 2002 From: peterw at usa.net (Peter Watkins) Date: Sat, 25 May 2002 00:33:47 -0400 Subject: chrooting/jailing - put it in the FAQ? In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, May 23, 2002 at 06:20:12PM -0500 References:

Message-ID: <20020525003347.C28059@usa.net> On Thu, May 23, 2002 at 06:20:12PM -0500, Ben Lindstrom wrote: > Why don't you just change the user's shell to /path/to/scpjail ? By doing > it this way you capture all subsystems, standard logins and remote > commands by just reading the command line and looking at anything past > the first -c. I don't see a reason why one needs to use command="". > > The other question is should SSH_ORIGINAL_COMMAND reflect subsystem calls? I'd like to suggest that the official OpenSSH FAQ cover the chroot topics. Chroot jails, whatever folks may think of their merits, are frequently requested. It would be wonderful if the core team could use the FAQ to explain the development position and perhaps outline suggested ways that admins could implement chroot jails, via small wrappers, alternate shells, whatever. -- Peter Watkins - peterw at tux.org - peterw at usa.net - http://www.tux.org/~peterw/ Private personal mail: use PGP key F4F397A8; more sensitive data? Use 2D123692 From bugzilla-daemon at mindrot.org Sat May 25 17:49:34 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 25 May 2002 17:49:34 +1000 (EST) Subject: [Bug 223] ProxyCommand commands don't exit Message-ID: <20020525074934.40E9CE881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=223 ------- Additional Comments From markus at openbsd.org 2002-05-25 17:49 ------- so 'ProxyCommand exec nc localhost 22' works without any patches? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 25 18:39:31 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 25 May 2002 18:39:31 +1000 (EST) Subject: [Bug 223] ProxyCommand commands don't exit Message-ID: <20020525083931.64D85E906@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=223 ------- Additional Comments From dtucker at zip.com.au 2002-05-25 18:39 ------- It works but still leaves an orphaned nc (on Solaris anyway): $ ssh -o 'ProxyCommand exec nc localhost 22' localhost echo $ ps -eaf | grep nc dtucker 9919 9049 0 18:23:45 pts/2 0:00 grep nc dtucker 9912 1 1 18:23:40 pts/2 0:00 nc localhost 22 After some more investigation I think there's 2 issues: 1) On all platforms, the child process isn't signalled when ssh exits, leaving them orphaned. 2) On Solaris (and possibly other platforms), running the ProxyCommand without "exec" also leaves an extra "sh -c". Additionally, the "sh -c" ignores SIGHUP and doesn't propogate SIGTERM, so even if ssh kills its child you're still left with 1 orphan rather than 2. FWIW, I've been working on a better patch that fixes 1 by always using exec and fixes 2 by sending SIGHUP (then SIGTERM then SIGKILL) to the child. This seems to be a clean solution. I'm cleaning the patch up for posting now. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 25 19:33:36 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 25 May 2002 19:33:36 +1000 (EST) Subject: [Bug 223] ProxyCommand commands don't exit Message-ID: <20020525093336.DD1A0E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=223 ------- Additional Comments From dtucker at zip.com.au 2002-05-25 19:33 ------- Created an attachment (id=104) Updated patch to kill proxycommand child process ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat May 25 19:41:17 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 25 May 2002 19:41:17 +1000 (EST) Subject: [Bug 223] ProxyCommand commands don't exit Message-ID: <20020525094117.534E5E922@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=223 ------- Additional Comments From dtucker at zip.com.au 2002-05-25 19:41 ------- OK the new patch seems to work (on Solaris anyway) even in the pathological case. (nc-nosig is netcat modified to ignore all signals). $ ./ssh -v -o 'ProxyCommand ./nc-nosig localhost 22' localhost echo [snip] debug1: Exit status 0 debug1: Terminating ProxyCommand child process pid:10203 debug1: ProxyCommand terminated with signal 9 Neither nc-nosig or the normal netcat leave orphaned processes. The timeout is currently hardcoded at 2 seconds per signal. Is this enough? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From fcusack at fcusack.com Sat May 25 19:52:57 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Sat, 25 May 2002 02:52:57 -0700 Subject: OpenSSH programming In-Reply-To: <1022164184.1423.2.camel@mothra.mindrot.org>; from djm@mindrot.org on Fri, May 24, 2002 at 12:29:44AM +1000 References: <1022164184.1423.2.camel@mothra.mindrot.org> Message-ID: <20020525025257.P817@google.com> On Fri, May 24, 2002 at 12:29:44AM +1000, Damien Miller wrote: > Yes, but you still need to hook PAM up to kbd-int properly. It is > currently broken with privsep. > > I posted a patch about 3 weeks ago to make it work, but got no feedback. > Since privsep is going to activate by default in future and (IMO) > privsep is more important than PAM, people really should start testing > this... FWIW, I did make note of that but haven't tested 'cuz I'm not ready to look at privsep yet (... although, mostly 'cuz it breaks PAM! argh) IMHO PAM is more important. I cannot have a functional sshd without PAM, but I can without privsep. /fc From markus at openbsd.org Sun May 26 00:52:40 2002 From: markus at openbsd.org (Markus Friedl) Date: Sat, 25 May 2002 16:52:40 +0200 Subject: OpenSSH programming In-Reply-To: <20020525025257.P817@google.com> References: <1022164184.1423.2.camel@mothra.mindrot.org> <20020525025257.P817@google.com> Message-ID: <20020525145240.GB17531@folly> On Sat, May 25, 2002 at 02:52:57AM -0700, Frank Cusack wrote: > IMHO PAM is more important. I cannot have a functional sshd without PAM, > but I can without privsep. even if you consider PAM more important, the patch works around the problems with the PAM API as discussed earlier (ssh-dispatch loop vs. pam loop). From mouring at etoh.eviladmin.org Sun May 26 01:48:10 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 25 May 2002 10:48:10 -0500 (CDT) Subject: SCO Unix In-Reply-To: Message-ID: I know of no such tar file ever included in OpenSSH. Why is this important? - Ben On Thu, 23 May 2002, Ed Hilovsky wrote: > I am trying to find ssh_os504.tar.Z for SCO Unix version 5.0.4 This was > originally part of the OpenSsh 2.2.0p1 package compiled for different SCO's > OSes. Please advise if there is an archive version or where I might get > obtain this. > > Thank you, > > Ed Hilovsky > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From mouring at etoh.eviladmin.org Sun May 26 01:48:40 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 25 May 2002 10:48:40 -0500 (CDT) Subject: 3.2.3p1 on OpenServer In-Reply-To: <20020523181743.NBBL11659.rwcrmhc53.attbi.com@solar> Message-ID: Did this happen under 3.1? - Ben On Thu, 23 May 2002, Greg Jewell wrote: > Hi All, > > I compiled the 3.2.3p1 source on SCO OpenServer 5.0.6. When a client connects to it now, they get stair-stepping everywhere. Issuing an stty sane resolves the issue for that login. > > For bug 245 in 3.2.2p1, the call to setsid() is sshd.c was bypassed due to problems it was causing with Solaris. However, by allowing this method to be called, the stair-stepping goes > away. > > > Thanks, > Greg Jewell > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From kevin at atomicgears.com Sun May 26 02:35:33 2002 From: kevin at atomicgears.com (Kevin Steves) Date: Sat, 25 May 2002 09:35:33 -0700 Subject: Openssh still logs in while passwd is locked In-Reply-To: <1022184134.5340.1.camel@UberGeek> References: <200205222012.g4MKCn6U317449@jurassic.eng.sun.com> <1022184134.5340.1.camel@UberGeek> Message-ID: <20020525163533.GD1578@jenny.crlsca.adelphia.net> On Thu, May 23, 2002 at 03:02:14PM -0500, Austin Gonyou wrote: > I do still see this behavior on Linux as well though. What is the list > recommendation for that case, if any? Are you using PAM? Can you provide version specifics so someone can dup? We have issues with some account and expire checks on various platforms, and I'd like to hear about them so we can document and continue to address them. From bugzilla-daemon at mindrot.org Sun May 26 03:34:55 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 26 May 2002 03:34:55 +1000 (EST) Subject: [Bug 255] You must "exec" login from the lowest login shell. Message-ID: <20020525173455.E4CE4E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=255 ------- Additional Comments From stevesk at pobox.com 2002-05-26 03:34 ------- can you try with LOGIN_NEEDS_UTMPX defined? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From carson at taltos.org Sun May 26 04:20:35 2002 From: carson at taltos.org (Carson Gaspar) Date: Sat, 25 May 2002 14:20:35 -0400 Subject: 3.2.3p1 on OpenServer In-Reply-To: <20020523181743.NBBL11659.rwcrmhc53.attbi.com@solar> References: <20020523181743.NBBL11659.rwcrmhc53.attbi.com@solar> Message-ID: <830349796.1022336435@[192.168.0.2]> --On Thursday, May 23, 2002 12:17 PM -0600 Greg Jewell wrote: > For bug 245 in 3.2.2p1, the call to setsid() is sshd.c was bypassed due > to problems it was causing with Solaris. However, by allowing this > method to be called, the stair-stepping goes away. Sadly, my APUE has gone walkabout, but I think he issue lies in calling setsid() and not opening a terminal. From Solaris termio(7d): The first terminal file opened by the ses- sion leader that is not already associated with a session becomes the controlling terminal for that session. The con- trolling terminal plays a special role in handling quit and interrupt signals, as discussed below. The controlling ter- minal is inherited by a child process during a fork(2). A process can break this association by changing its session using setsid() (see getsid(2)). If OpenSSH is going to call setsid(), it must then open whatever terminal is going to be used (and then dup the fd to 0,1,2). Of course, this probably won't fix the real problem for OpenServer, which seems to be in the propogation of tty settings. -- Carson From kevin at atomicgears.com Sun May 26 04:26:15 2002 From: kevin at atomicgears.com (Kevin Steves) Date: Sat, 25 May 2002 11:26:15 -0700 Subject: Openssh still logs in while passwd is locked In-Reply-To: <200205222012.g4MKCn6U317449@jurassic.eng.sun.com> References: <200205222012.g4MKCn6U317449@jurassic.eng.sun.com> Message-ID: <20020525182615.GE1578@jenny.crlsca.adelphia.net> On Wed, May 22, 2002 at 01:12:07PM -0700, Darren Moffat wrote: > >Using OpenSSH 3.1p1 on a Sun Solaris 7 box, I disabled an account using the > >'passwd -l ...' command to lock the users password. However, the user can > >still access the system via ssh. Whilst I could do other things such as > >moving their .ssh directory, removing their account home directory, etc, > >etc, is there some 'nicer' way to inform ssh that the account is now locked > >and thus to not allow them to login? > > The pam_unix.so module doesn't check for *LK* in pam_acct_mgmt since it > was assuming that pam_authenticate() had been called already - in those > cases it would fail. If however you are using publickey authentication > rather than going through PAM with a password pam_acct_mgmt is called > without first going to pam_authenticate(). > > This has been fixed in the new pam modules for Solaris 9 where > pam_unix_account.so does an explicit check for *LK* so it is now safe > to call pam_acct_mgmt() if pam_authenticate() wasn't called. What else is special besides "*LK*" (I'm wondering about "NP")? How exactly does ``passwd -sa'' determine LK status? Are there issues with/without /etc/shadow (I see pwconv(1M) for example)? From markus at openbsd.org Sun May 26 04:39:20 2002 From: markus at openbsd.org (Markus Friedl) Date: Sat, 25 May 2002 20:39:20 +0200 Subject: 3.2.3p1 on OpenServer In-Reply-To: <830349796.1022336435@[192.168.0.2]> References: <20020523181743.NBBL11659.rwcrmhc53.attbi.com@solar> <830349796.1022336435@[192.168.0.2]> Message-ID: <20020525183920.GB12989@faui02> On Sat, May 25, 2002 at 02:20:35PM -0400, Carson Gaspar wrote: > If OpenSSH is going to call setsid(), it must then open whatever terminal > is going to be used (and then dup the fd to 0,1,2). setsid() also interacts with setlogin() so OpenSSH is calling setsid() for pty-less sessions for more then 2 years. -m From carson at taltos.org Sun May 26 04:47:26 2002 From: carson at taltos.org (Carson Gaspar) Date: Sat, 25 May 2002 14:47:26 -0400 Subject: 3.2.3p1 on OpenServer In-Reply-To: <20020525183920.GB12989@faui02> References: <20020525183920.GB12989@faui02> Message-ID: <831960125.1022338046@[192.168.0.2]> --On Saturday, May 25, 2002 8:39 PM +0200 Markus Friedl wrote: > On Sat, May 25, 2002 at 02:20:35PM -0400, Carson Gaspar wrote: >> If OpenSSH is going to call setsid(), it must then open whatever >> terminal is going to be used (and then dup the fd to 0,1,2). > > setsid() also interacts with setlogin() so OpenSSH is > calling setsid() for pty-less sessions for more then 2 years. setlogin() is apparantly some BSDism. Of course, if you're having a pty-less session, you don't have to set a controlling terminal, so you can just call setsid(). But for pty-full sessions, my advice holds (at least across POSIX systems). -- Carson From markus at openbsd.org Sun May 26 04:56:43 2002 From: markus at openbsd.org (Markus Friedl) Date: Sat, 25 May 2002 20:56:43 +0200 Subject: 3.2.3p1 on OpenServer In-Reply-To: <831960125.1022338046@[192.168.0.2]> References: <20020525183920.GB12989@faui02> <831960125.1022338046@[192.168.0.2]> Message-ID: <20020525185643.GE12989@faui02> On Sat, May 25, 2002 at 02:47:26PM -0400, Carson Gaspar wrote: > setlogin() is apparantly some BSDism. Of course, if you're having a > pty-less session, you don't have to set a controlling terminal, so you can > just call setsid(). But for pty-full sessions, my advice holds (at least > across POSIX systems). > but the problem seen on solaris is a call to setsid() just after the connection is accepted. there are not pty's involved at this point. From mjt at tls.msk.ru Sun May 26 05:02:45 2002 From: mjt at tls.msk.ru (Michael Tokarev) Date: Sat, 25 May 2002 23:02:45 +0400 Subject: Openssh still logs in while passwd is locked (fwd) References: <20020522195404.GA10894@faui02> Message-ID: <3CEFDFD5.26954F78@tls.msk.ru> Markus Friedl wrote: > > Subject: Openssh still logs in while passwd is locked > Date: Wed, 22 May 2002 15:20:08 +0100 (BST) > From: John Horne > Organization: University of Plymouth > To: secureshell at securityfocus.com > > Hello, > > Using OpenSSH 3.1p1 on a Sun Solaris 7 box, I disabled an account using the > 'passwd -l ...' command to lock the users password. However, the user can > still access the system via ssh. Whilst I could do other things such as > moving their .ssh directory, removing their account home directory, etc, > etc, is there some 'nicer' way to inform ssh that the account is now locked > and thus to not allow them to login? It seems this topic should be covered in the FAQ somewhere. I too was surprized by this behaviour. `passwd -l' locks user's PASSWORD, but not his ~/.ssh/authorized_keys. I.e. after locking user's password, he will not be able to log on using other mechanisms (e.g. typing his username and password at login: prompt on the console), but he may log in to the machine using ssh and a valid and authorized key. There is nothing wrong with that. Besides the fact that there MAY be a need for an option that disallows logins for certain users/accounts based on ~/.ssh/ directory. Let me draw an example where this may be needed. Imagine a samba server, where users aren't allowed to log in and use shell prompt, but may use the server for file/print from their winblows workstations (e.g. using samba's "encrypted" passwords in /etc/samba/smbpasswd). Obviously, such users will have a read-write home directory (e.g. for storing their private files and windows profiles). And it is pretty possible to create .ssh directory and place any files within it, including properly formatted authorized_keys. Now it may be possible to log in and bypass a "nologin" restriction. But it is possible IF there is a valid shell listed for their accounts. I'm not sure if this is the case - will e.g. ssh remotehost /bin/sh work if /etc/passwd contains /bin/true or /bin/nologin for a user? Also, will such users be able to use sftp? If yes, this may be another security issue as well: using samba it is possible to restrict filesystem visibility, but with e.g. sftp it is not possible, all the filesystem is available (with corresponding permissions, but who knows why an administrator may choose to limit visibility for samba). /mjt From bugzilla-daemon at mindrot.org Sun May 26 05:07:49 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 26 May 2002 05:07:49 +1000 (EST) Subject: [Bug 255] You must "exec" login from the lowest login shell. Message-ID: <20020525190749.73FD7E881@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=255 ------- Additional Comments From dmanton at emea.att.com 2002-05-26 05:07 ------- -DLOGIN_NEEDS_UTMPX solves the problem for 3.2.2. I'll try it with 3.2.3 when I am back in the office. If successful then it would be great to have this auto-defined for AIX by configure. Thanks for your help :) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From phil-openssh-unix-dev at ipal.net Sun May 26 06:13:43 2002 From: phil-openssh-unix-dev at ipal.net (Phil Howard) Date: Sat, 25 May 2002 15:13:43 -0500 Subject: mismatch against version of openssl, letter version brokeness Message-ID: <20020525201343.GA20065@vega.ipal.net> What risk exists in changing the check for the matching version of openssl so that the final letter part of the version (e.g. 0.9.6c vs. 0.9.6d) is ignored? Are there any security vulnerabilities in such a thing? What if ssh(d) is linked against an older _letter_ version such as 0.9.6c and now finds the library is 0.9.6d? Is there a security risk in that? Surely a major API change would not happen between version c and version d, would it? My concern here is that openssl's versioning scheme is broken, and depending on it causes problems. For example, I cannot concurrently have separate executables with some linked to 0.9.6c and some linked to 0.9.6d and expect them to get the correct library, because the library itself cannot have concurrent versions installed (hence why I say it is broken). -- ----------------------------------------------------------------- | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/ | ----------------------------------------------------------------- From jmknoble at pobox.com Sun May 26 08:04:53 2002 From: jmknoble at pobox.com (Jim Knoble) Date: Sat, 25 May 2002 18:04:53 -0400 Subject: mismatch against version of openssl, letter version brokeness In-Reply-To: <20020525201343.GA20065@vega.ipal.net>; from phil-openssh-unix-dev@ipal.net on Sat, May 25, 2002 at 03:13:43PM -0500 References: <20020525201343.GA20065@vega.ipal.net> Message-ID: <20020525180453.D14977@zax.half.pint-stowp.cx> Circa 2002-May-25 15:13:43 -0500 dixit Phil Howard: : What risk exists in changing the check for the matching version of : openssl so that the final letter part of the version (e.g. 0.9.6c : vs. 0.9.6d) is ignored? Are there any security vulnerabilities in : such a thing? What if ssh(d) is linked against an older _letter_ : version such as 0.9.6c and now finds the library is 0.9.6d? Is : there a security risk in that? Surely a major API change would not : happen between version c and version d, would it? : : My concern here is that openssl's versioning scheme is broken, and : depending on it causes problems. For example, I cannot concurrently : have separate executables with some linked to 0.9.6c and some linked : to 0.9.6d and expect them to get the correct library, because the : library itself cannot have concurrent versions installed (hence why : I say it is broken). According to the INSTALL file included with OpenSSL-0.9.6d: Shared library is currently an experimental feature. The only reason to have them would be to conserve memory on systems where several program are using OpenSSL. Binary backward compatibility can't be guaranteed before OpenSSL version 1.0. That explains why it's necessary for OpenSSH to explicitly depend on a particular version of OpenSSL (i.e., backwards compatibility can't be guaranteed with v0.9.x). That said, what i usually do is apply the attached patch (for Linux on x86 hardware) to change the SONAME of the libraries from, for example, 'libcrypto.so.0.9.6' to 'libcrypto-0.9.6d.so.0'. This does the following: (1) Allows easy coexistence between different version of the OpenSSL libraries. (2) Makes explicit what the INSTALL text implies, i.e. that libcrypto-0.9.6c.so.0 and libcrypto-0.9.6d.so.0 are not guaranteed to be ABI compatible. YMMV. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) -------------- next part -------------- --- ./Configure.orig-shlib Fri May 10 15:05:03 2002 +++ ./Configure Fri May 10 15:12:22 2002 @@ -334,7 +334,7 @@ # The intel boxes :-), It would be worth seeing if bsdi-gcc can use the # bn86-elf.o file file since it is hand tweaked assembler. -"linux-elf", "gcc:\$(OPTFLAGS) -DL_ENDIAN -DTERMIO::-D_REENTRANT:-ldl:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", +"linux-elf", "gcc:\$(OPTFLAGS) -DL_ENDIAN -DTERMIO::-D_REENTRANT:-ldl:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-fPIC::-\$(VERSION).so.0.0.0", "debug-linux-elf","gcc:-DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DL_ENDIAN -DTERMIO -g -m486 -Wall::-D_REENTRANT:-lefence -ldl:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-fPIC:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", "debug-linux-elf-noefence","gcc:-DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DL_ENDIAN -DTERMIO -g -m486 -Wall::-D_REENTRANT:-ldl:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}:dlfcn", "linux-aout", "gcc:-DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall::(unknown)::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_out_asm}", --- ./Makefile.org.orig-shlib Fri May 10 15:07:00 2002 +++ ./Makefile.org Fri May 10 15:11:35 2002 @@ -261,8 +261,8 @@ do_gnu-shared: libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \ ( set -x; ${CC} ${SHARED_LDFLAGS} \ - -shared -o lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \ - -Wl,-soname=lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \ + -shared -o lib$$i-${VERSION}.so.0.0.0 \ + -Wl,-soname=lib$$i-${VERSION}.so.0 \ -Wl,-Bsymbolic \ -Wl,--whole-archive lib$$i.a \ -Wl,--no-whole-archive $$libs ${EX_LIBS} -lc ) || exit 1; \ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 262 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020525/87f485c6/attachment.bin From carson at taltos.org Sun May 26 09:47:30 2002 From: carson at taltos.org (Carson Gaspar) Date: Sat, 25 May 2002 19:47:30 -0400 Subject: 3.2.3p1 on OpenServer In-Reply-To: <20020525185643.GE12989@faui02> References: <20020525185643.GE12989@faui02> Message-ID: <8349859.1022356050@[192.168.0.2]> --On Saturday, May 25, 2002 8:56 PM +0200 Markus Friedl wrote: > but the problem seen on solaris is a call to setsid() just > after the connection is accepted. there are not pty's > involved at this point. The problem is that a controlling terminal is never set. This is either due to a bug in Solaris (possible, but not likely, as it also affected other OS's), or due to OpenSSH not following POSIX tty semantics. All that should be required is an open() of the appropriate device, immediately following the setsid() call. Be careful of opening any tty/pty-like device in-between, as it will become the controlling terminal. I'll try and take a look at the code in the next few days and see if I can track down what was going wrong. -- Carson From markus at openbsd.org Sun May 26 17:59:27 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 26 May 2002 09:59:27 +0200 Subject: mismatch against version of openssl, letter version brokeness In-Reply-To: <20020525201343.GA20065@vega.ipal.net> References: <20020525201343.GA20065@vega.ipal.net> Message-ID: <20020526075927.GA18678@folly> On Sat, May 25, 2002 at 03:13:43PM -0500, Phil Howard wrote: > What risk exists in changing the check for the matching version of > openssl so that the final letter part of the version (e.g. 0.9.6c > vs. 0.9.6d) is ignored? Are there any security vulnerabilities in > such a thing? the API is not stable between the releases. From bugzilla-daemon at mindrot.org Sun May 26 20:47:10 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 26 May 2002 20:47:10 +1000 (EST) Subject: [Bug 256] New: Expired password unchangeable again with pam support Message-ID: <20020526104710.69A28E921@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=256 Summary: Expired password unchangeable again with pam support Product: Portable OpenSSH Version: -current Platform: All OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: smueller at atsec.com Version: openssh-3.2.3p1 It is not possible to change expired passwords. Reason: in auth-pam.c the case statement of PAM_NEW_AUTHTOK_REQD is commended out. If you remove the #if 0 everything runs smoothly again. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From janfrode at parallab.uib.no Sun May 26 22:50:53 2002 From: janfrode at parallab.uib.no (Jan-Frode Myklebust) Date: Sun, 26 May 2002 14:50:53 +0200 Subject: 3.2.2p1 build problem on Irix6.5 In-Reply-To: References: <20020521062814.GA14394@ii.uib.no> Message-ID: <20020526125053.GA7262@ii.uib.no> On Fri, May 24, 2002 at 09:20:46AM -0700, Tim Rice wrote: > > Please test the attached patch. > You'll need to run autoconf and remove config.status before running configure. > > If you don't have autoconf 2.52, grab configure from > http://www.multitalents.net/openssh/configure-msghdr-fix.gz I used your configure-msghdr-fix.gz since the 3.2.2p1 tarball doesn't contain configure.in, and after applying your patch it builds successfully. -jf From mouring at etoh.eviladmin.org Mon May 27 01:15:49 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sun, 26 May 2002 10:15:49 -0500 (CDT) Subject: 3.2.2p1 build problem on Irix6.5 In-Reply-To: <20020526125053.GA7262@ii.uib.no> Message-ID: On Sun, 26 May 2002, Jan-Frode Myklebust wrote: > On Fri, May 24, 2002 at 09:20:46AM -0700, Tim Rice wrote: > > > > Please test the attached patch. > > You'll need to run autoconf and remove config.status before running configure. > > > > If you don't have autoconf 2.52, grab configure from > > http://www.multitalents.net/openssh/configure-msghdr-fix.gz > > I used your configure-msghdr-fix.gz since the 3.2.2p1 tarball doesn't > contain configure.in, and after applying your patch it builds > successfully. > The new standards is configure.ac which is included within every tarball. - Ben From austin at coremetrics.com Mon May 27 05:54:16 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 26 May 2002 14:54:16 -0500 Subject: Openssh still logs in while passwd is locked In-Reply-To: <20020525163533.GD1578@jenny.crlsca.adelphia.net> References: <20020525163533.GD1578@jenny.crlsca.adelphia.net> Message-ID: <1022442856.25221.5.camel@UberGeek> In this case RH 7.1, latest updates, OpenSSH 3.2.2p1. On Sat, 2002-05-25 at 11:35, Kevin Steves wrote: > On Thu, May 23, 2002 at 03:02:14PM -0500, Austin Gonyou wrote: > > I do still see this behavior on Linux as well though. What is the > list > > recommendation for that case, if any? > > Are you using PAM? Can you provide version specifics so someone > can dup? > > We have issues with some account and expire checks on various > platforms, and I'd like to hear about them so we can document > and continue to address them. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "One ought never to turn one's back on a threatened danger and try to run away from it. If you do that, you will double the danger. But if you meet it promptly and without flinching, you will reduce the danger by half." Sir Winston Churchill -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020526/16381fa2/attachment.bin From tim at multitalents.net Mon May 27 08:43:26 2002 From: tim at multitalents.net (Tim Rice) Date: Sun, 26 May 2002 15:43:26 -0700 (PDT) Subject: 3.2.3p1 on OpenServer In-Reply-To: <20020523181743.NBBL11659.rwcrmhc53.attbi.com@solar> Message-ID: On Thu, 23 May 2002, Greg Jewell wrote: > Hi All, > > I compiled the 3.2.3p1 source on SCO OpenServer 5.0.6. When a client > connects to it now, they get stair-stepping everywhere. Issuing an stty > sane resolves the issue for that login. I can not duplicate that problem here on my SCO 5.0.6 box. What client are you using? > > For bug 245 in 3.2.2p1, the call to setsid() is sshd.c was bypassed due > to problems it was causing with Solaris. However, by allowing this > method to be called, the stair-stepping goes away. The setsid() call seemed to make no difference here on SCO. > > > Thanks, > Greg Jewell > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bugzilla-daemon at mindrot.org Mon May 27 16:24:53 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 27 May 2002 16:24:53 +1000 (EST) Subject: [Bug 257] New: sftp and 32 bit integar Message-ID: <20020527062453.5BF2CE933@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=257 Summary: sftp and 32 bit integar Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: other Status: NEW Severity: normal Priority: P2 Component: sftp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: liug at mama.indstate.edu Watcom c/c++ compiler on qnx4 doesn't support 64 bit int, and openssh ./configure refuses to compile sftp and sftp-server for me. I see 32 bit int support in the TODO list and am wondering when it will be supported. BTW, when I use the ssh from ssh.com, sftp works fine in qnx4. Isn't openssh derived from ssh.com, how come their ssh supports sftp but openssh doesn't for 32bit int? Thanks! ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon May 27 17:09:13 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 27 May 2002 17:09:13 +1000 (EST) Subject: [Bug 257] sftp and 32 bit integar Message-ID: <20020527070913.CE0BBE915@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From markus at openbsd.org 2002-05-27 17:09 ------- openssh is not derived from ssh.com-2.x or 3.x. but adding support for 32bit int is not hard. you can attach patches to this bug. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From papadopo at REMOVE.shfj.DECOY.cea.fr Mon May 27 22:13:11 2002 From: papadopo at REMOVE.shfj.DECOY.cea.fr (Dimitri Papadopoulos) Date: Mon, 27 May 2002 14:13:11 +0200 Subject: $HOME/.ssh/config is ignored Message-ID: <3CF222D7.8080100@REMOVE.shfj.DECOY.cea.fr> Hi, By default the configure script has this option enabled: --enable-suid-ssh Could it be disabled by default in the case where openSSH is not installed by root? I'm in the peculiar situation where I had to install OpenSSH as a regular user to be able to connect to outside machines. I've built OpenSHH without specifying "--disable-suid-ssh": $ /usr/ucb/whoami papadopo $ ls -l /usr/local/openssh-3.1p1/bin/ssh /usr/local/openssh-3.2.3p1/bin/ssh -rws--x--x 1 Plocal Glocal 1332064 Mar 8 14:03 /usr/local/openssh-3.1p1/bin/ssh -rws--x--x 1 Plocal Glocal 1379020 May 24 11:29 /usr/local/openssh-3.2.3p1/bin/ssh $ As you can see the set-ID bit is set for OpenSSH 3.1p1 and OpenSSH 3.2.3p1. The problem is that the user/group Plocal/Glocal under which OpenSSH is installed is a special user. I can log to this user without password through NIS mechanisms, for reasons beyond my reach. The result is that OpenSSH will ignore my personal config file. If I reset the set-ID bit of ssh, the config file is taken into account again. I do agree this is really a peculiar installation. However I would suggest that the set-ID bit is not set when the installer is not root, if at all possible. Best Regards, Dimitri From djast at cs.toronto.edu Tue May 28 00:34:33 2002 From: djast at cs.toronto.edu (Dan Astoorian) Date: Mon, 27 May 2002 10:34:33 -0400 Subject: chrooting/jailing transfer-only accounts In-Reply-To: Your message of "Fri, 24 May 2002 10:57:55 EDT." Message-ID: <02May27.103434edt.453142-29971@jane.cs.toronto.edu> On Fri, 24 May 2002 10:57:55 EDT, "Sandor W. Sklar" writes: > > [...] I'm just looking for a solution to the > problem I stated in the previous email. Some people feel that this > is a "trivial" problem that can be solved without adding code to > OpenSSH. If it is, I'm not smart enough to figure it out, and I > haven't seen any examples of such a solution posted to the list. Ben said (and I agreed) that adding code to OpenSSH was the wrong approach, but I don't remember anyone claiming the problem, let alone the solution, was trivial. In fact, I've been jumping up and down trying to point out how dangerous it is from a security standpoint to do chroot()s carelessly. If you don't need a general solution for many users (e.g., if you only need a single chroot'd account for anonymous-scp), then a reasonably simple program similar to this might be sufficient: #define JAIL "/path/to/jail" #define SHELL "/bin/sh" int main(int argc, char **argv) { if (!chroot(JAIL)) { perror("chroot"); } else if (!chdir("/")) { perror("chdir"); } else if (!setuid(getuid())) { perror("setuid"); } else { execv(SHELL, argv); perror("execv"); } exit(1); } Note: the above is completely untested! Use at your own risk. The wrapper is also not completely rigorous--it does nothing to try to prevent fd's from outside the jail from being passed through it, for example (not that this is likely to be a problem in most cases). And it puts a burden on the sysadmin to make sure JAIL is a safe place to chroot() into (e.g., no system directories like /etc or /dev are writable). If you try to modify the above so that JAIL depends on the context in which the wrapper is run, you're very likely to introduce security holes. Unless you know what you're doing, in which case you're only moderately likely to introduce security holes. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From djm at mindrot.org Tue May 28 00:43:45 2002 From: djm at mindrot.org (Damien Miller) Date: 28 May 2002 00:43:45 +1000 Subject: Administrivia: Listing mail.mindrot.org in spamcop Message-ID: <1022510625.1508.27.camel@mothra.mindrot.org> Someone on this mailing list has been reporting spam emails forwarded by the mailing list to spamcop. This has resulted in several listings of my mail server in their database of spam relays and a significant amount of inconvenience for myself and the other users of the mail relay. You have all been warned in the list welcome message that this is an open list and that the occasional spam gets through. If you don't like this policy, please unsubscribe rather than attempting to list my mailserver. I believe that the odd spam is not too high a price to pay in return for access by legitimate non-list members and I thus have no intention of changing this policy. -d From bugzilla-daemon at mindrot.org Tue May 28 00:58:59 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 28 May 2002 00:58:59 +1000 (EST) Subject: [Bug 257] sftp and 32 bit integar Message-ID: <20020527145859.12F2AE990@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From liug at mama.indstate.edu 2002-05-28 00:58 ------- > but adding support for 32bit int is not hard. "adding"? somehow I got the impression that 32 bit int was in the openssh at some point in the history, but then got dropped. Anyway, it would be greatly appreciated if someone can provide a 32bit int patch so that I can test it. It seems SCO also suffers from the same problem (per TODO file). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue May 28 01:05:01 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 28 May 2002 01:05:01 +1000 (EST) Subject: [Bug 258] New: scanf format not portable Message-ID: <20020527150501.E66DFE995@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=258 Summary: scanf format not portable Product: Portable OpenSSH Version: -current Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: liug at mama.indstate.edu It seems the scanf format %[0-9] in Watcom doesn't work the same way as in gcc. Here is a note in the Watcom C/C++ reference: Note: A dash (-) in the scanset doesn't indicate a range of characters. For example, the string [0-9] matches the characters 0, -, and 9, not the characters 0 through 9. I have to make the following change to make -R/-L option of ssh to work: --- ssh.c.orig Tue Apr 23 04:09:46 2002 +++ ssh.c Sun May 26 19:48:49 2002 @@ -467,9 +467,9 @@ case 'L': case 'R': - if (sscanf(optarg, "%5[0-9]:%255[^:]:%5[0-9]", + if (sscanf(optarg, "%5[0123456789]:%255[^:]:%5[012345678 9]", sfwd_port, buf, sfwd_host_port) != 3 && - sscanf(optarg, "%5[0-9]/%255[^/]/%5[0-9]", + sscanf(optarg, "%5[0123456789]/%255[^/]/%5[0123456789]", sfwd_port, buf, sfwd_host_port) != 3) { fprintf(stderr, "Bad forwarding specification '%s'\n", ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue May 28 02:53:49 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 28 May 2002 02:53:49 +1000 (EST) Subject: [Bug 258] scanf format not portable Message-ID: <20020527165349.A3582E99C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=258 ------- Additional Comments From liug at mama.indstate.edu 2002-05-28 02:53 ------- Here are some more info I gathered from the Watcom newsgroup: The C99 draft explicitly said that: "If a - character is in the scanlist and is not the first, nor the second where the first character is a ^, nor the last character, the behavior is implementation-defined." So (assuming the draft did not change in this respect) for portable programs you can only trust [-09] or [09-] and [0123456789]. But are free to rely on [0-9] if you depend on compiler (library really) X and Y (Borland, glibc, ...), or Z for the other interpretation (the Watcom RTL, IBM VAC++, ...). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue May 28 02:57:52 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 28 May 2002 02:57:52 +1000 (EST) Subject: [Bug 257] sftp and 32 bit integar Message-ID: <20020527165752.77124E9A1@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From mouring at eviladmin.org 2002-05-28 02:57 ------- At one point it was a high/low 32bit integer structure, but after the code was looked at it was realized that 64bit integers would make it cleaner. I looked at supporting platforms without 64bit using the old way, but I realized how ugly it would be. It would have been a nightmare to audit and a nightmare to merge changes to. Below is the event that removed 32bit integers and combined them into a 64bit. If you can show me a clean way of implementing 32bit without destorying the reability of the code I'd be extremely happy. http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sftp-server.c.diff? r1=1.9&r2=1.10 Granted sftp client I believe never did have 32bit support. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue May 28 04:00:25 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 28 May 2002 04:00:25 +1000 (EST) Subject: [Bug 257] sftp and 32 bit integar Message-ID: <20020527180025.7D189E9A4@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From liug at mama.indstate.edu 2002-05-28 04:00 ------- I am not an expert in programming, but is it possible to create our own data types, and typedef them as our Int32, Int64 rather than using the OS one? That should solve both sftp and sftp-server problem? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djast at cs.toronto.edu Tue May 28 04:20:42 2002 From: djast at cs.toronto.edu (Dan Astoorian) Date: Mon, 27 May 2002 14:20:42 -0400 Subject: chrooting/jailing transfer-only accounts In-Reply-To: Your message of "Mon, 27 May 2002 10:34:33 EDT." Message-ID: <02May27.142045edt.453143-29971@jane.cs.toronto.edu> On Mon, 27 May 2002 10:34:33 EDT, I wrote: > > Note: the above is completely untested! [...] ...in fact, it wasn't even _proofread_. :-( Now that I've had my morning coffee, this is a little closer to what I had in mind. It's still not well-tested, but it's not quite as spectacularly wrong. #define JAIL "/path/to/jail" #define SHELL "/bin/sh" int main(int argc, char **argv) { if (chroot(JAIL) != 0) { perror("chroot"); } else if (chdir("/") != 0) { perror("chdir"); } else if (setuid(getuid()) != 0) { perror("setuid"); } else { execv(SHELL, argv); perror("execv"); } exit(1); } My apologies for not paying attention. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From sxw at dcs.ed.ac.uk Tue May 28 04:29:33 2002 From: sxw at dcs.ed.ac.uk (Simon Wilkinson) Date: Mon, 27 May 2002 19:29:33 +0100 (BST) Subject: GSSAPI patches for OpenSSH 3.2.3p1 Message-ID: The latest version of my patches providing GSSAPI support for OpenSSH is available from http://www.sxw.org.uk/computing/patches/openssh.html These patches provide support for authentication mechanisms such as Kerberos and GSI with version 2 of the SSH protocol. They are conditionally compliant with draft-ietf-secsh-gsskeyex-03.txt, with the optional error message passing and host key validation sections not implemented. As yet, I have not look at their interaction with the new privsep code. Feedback and patches are greatly appreciated - as is feedback from those performing interoperability testing. A full list of contributors is available from the above website. Cheers, Simon. From bugzilla-daemon at mindrot.org Tue May 28 05:08:08 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 28 May 2002 05:08:08 +1000 (EST) Subject: [Bug 257] sftp and 32 bit integar Message-ID: <20020527190808.9CA32E9B2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From markus at openbsd.org 2002-05-28 05:08 ------- Created an attachment (id=105) i thought about something like this ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue May 28 06:05:38 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 28 May 2002 06:05:38 +1000 (EST) Subject: [Bug 257] sftp and 32 bit integar Message-ID: <20020527200538.8FB20E9B6@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From mouring at eviladmin.org 2002-05-28 06:05 ------- That would work, but the question is how much auditing would have to be done to ensure that one does not wrap the 32bit int since the code by default assumes 64bit. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mouring at etoh.eviladmin.org Tue May 28 06:22:53 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 27 May 2002 15:22:53 -0500 (CDT) Subject: chrooting/jailing transfer-only accounts In-Reply-To: <02May27.142045edt.453143-29971@jane.cs.toronto.edu> Message-ID: On Mon, 27 May 2002, Dan Astoorian wrote: > On Mon, 27 May 2002 10:34:33 EDT, I wrote: > > > > Note: the above is completely untested! [...] > > ...in fact, it wasn't even _proofread_. :-( > > Now that I've had my morning coffee, this is a little closer to what I > had in mind. It's still not well-tested, but it's not quite as > spectacularly wrong. > > #define JAIL "/path/to/jail" > #define SHELL "/bin/sh" > int main(int argc, char **argv) { > if (chroot(JAIL) != 0) { > perror("chroot"); > } else if (chdir("/") != 0) { > perror("chdir"); [..] ^^ Won't one want to consider dropping root before this? Less code that is ran by root the better. The only thing that should be considered is how to correctly pull the user's home directory. One should ponder if that code should be ran as a non-root user. As for argument processing with getopt() that is a no brainner. You handle all getopt() just before you spawn the shell. Thus any issue should be less tramatic. - Ben From bugzilla-daemon at mindrot.org Tue May 28 06:41:22 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 28 May 2002 06:41:22 +1000 (EST) Subject: [Bug 257] sftp and 32 bit integar Message-ID: <20020527204122.1221DE9BE@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From liug at mama.indstate.edu 2002-05-28 06:41 ------- Created an attachment (id=106) I also have to modify sftp-client.c for Watcom to compile or else it complains about invalid type. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue May 28 07:28:10 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 28 May 2002 07:28:10 +1000 (EST) Subject: [Bug 257] sftp and 32 bit integar Message-ID: <20020527212810.23286E9C2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From gert at greenie.muc.de 2002-05-28 07:28 ------- As a side note: on SCO, 64bit is not a problem if you use gcc as a compiler, which has "long long" as a valid 64bit type on i386. To liug at mama.indstate.edu: just typedef'ing something that the compiler cannot generate valid 64bit code for won't help. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djast at cs.toronto.edu Tue May 28 09:04:10 2002 From: djast at cs.toronto.edu (Dan Astoorian) Date: Mon, 27 May 2002 19:04:10 -0400 Subject: chrooting/jailing transfer-only accounts In-Reply-To: Your message of "Mon, 27 May 2002 16:22:53 EDT." Message-ID: <02May27.190417edt.453142-29971@jane.cs.toronto.edu> On Mon, 27 May 2002 16:22:53 EDT, Ben Lindstrom writes: > > > #define JAIL "/path/to/jail" > > #define SHELL "/bin/sh" > > int main(int argc, char **argv) { > > if (chroot(JAIL) != 0) { > > perror("chroot"); > > } else if (chdir("/") != 0) { > > perror("chdir"); > [..] > ^^ Won't one want to consider dropping root before this? Less > code that is ran by root the better. In general, yes. Also in general, the sooner you rid yourself of any file descriptors outside the new root, the better, which is the only reason I wrote it in the order I did. The other order would probably be better, but in this specific instance, I don't think it really matters (although if the chdir() were to anyplace other than "/", then it would definitely be more important to drop root first). > The only thing that should be considered is how to correctly pull the > user's home directory. One should ponder if that code should be ran as a > non-root user. Personally, if I were setting up a wrapper for a single sftp-only account, I'd probably just hard-code everything into the script before the execv(). In fact, I'd probably hard-code the environment and arguments too, rather than allowing SHELL to inherit them. I didn't mean to suggest that this 15-line off-the-cuff program was a complete prepackaged solution: I was hoping it would be enough of a hint for people like Sandor, who lamented that: | [...]Some people feel that this | is a "trivial" problem that can be solved without adding code to | OpenSSH. If it is, I'm not smart enough to figure it out, and I | haven't seen any examples of such a solution posted to the list. to perhaps fill in the pieces. > As for argument processing with getopt() that is a no brainner.[...] I don't see any need for argument processing in the wrapper.... -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From tim at multitalents.net Tue May 28 10:40:25 2002 From: tim at multitalents.net (Tim Rice) Date: Mon, 27 May 2002 17:40:25 -0700 (PDT) Subject: 3.2.2p1 build problem on Irix6.5 In-Reply-To: <20020526125053.GA7262@ii.uib.no> Message-ID: On Sun, 26 May 2002, Jan-Frode Myklebust wrote: > On Fri, May 24, 2002 at 09:20:46AM -0700, Tim Rice wrote: > > > > Please test the attached patch. > > You'll need to run autoconf and remove config.status before running configure. > > > > If you don't have autoconf 2.52, grab configure from > > http://www.multitalents.net/openssh/configure-msghdr-fix.gz > > I used your configure-msghdr-fix.gz since the 3.2.2p1 tarball doesn't > contain configure.in, and after applying your patch it builds > successfully. The changes are now in CVS. Thanks for testing. > > > -jf > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mjt at tls.msk.ru Tue May 28 10:45:26 2002 From: mjt at tls.msk.ru (Michael Tokarev) Date: Tue, 28 May 2002 04:45:26 +0400 Subject: [Bug 257] sftp and 32 bit integar References: <20020527212810.23286E9C2@shitei.mindrot.org> Message-ID: <3CF2D326.9399A90C@tls.msk.ru> bugzilla-daemon at mindrot.org wrote: > > http://bugzilla.mindrot.org/show_bug.cgi?id=257 > > ------- Additional Comments From gert at greenie.muc.de 2002-05-28 07:28 ------- > As a side note: on SCO, 64bit is not a problem if you use gcc as a compiler, > which has "long long" as a valid 64bit type on i386. > > To liug at mama.indstate.edu: just typedef'ing something that the compiler > cannot generate valid 64bit code for won't help. Please forgive me for replying here instead of bugzilla: I need an account there but *now* isn't a time to create it (it's 04:41 here), and tomorrow I'll forget about this whole topic... Watcom C has 64bit integers for a very long time, I think on ALL supported platforms, including 16bit (!!) MS-DOS. If memory serves me right, it is called _i64 or something like that. I don't have watcom handy to check that, but it should be trivial (this type mentioned in manual, both printed and online), and is used in headers. I think that a simple typedef should help here and close this issue (and a configure test for the typedef). /mjt From bugzilla-daemon at mindrot.org Tue May 28 13:02:59 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 28 May 2002 13:02:59 +1000 (EST) Subject: [Bug 257] sftp and 32 bit integar Message-ID: <20020528030259.7207DE9D2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From liug at mama.indstate.edu 2002-05-28 13:02 ------- Hi Markus, I tried your patch. sftp (client) seems to work fine. sftp-server seems to have problems: I can sftp connect into the box, but I can get/put files. "ls -l" gives the error "Couldn't stat remote file: No such file or directory" and "ls" or "dir" will disconnect me immediately. Any ideas? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mathias at koerber.org Tue May 28 13:55:26 2002 From: mathias at koerber.org (Mathias Koerber) Date: Tue, 28 May 2002 11:55:26 +0800 Subject: Problems with UsePrivilegeSeparation (was: port fwd as user != root? In-Reply-To: <161450000.1022379830@noisy.koerber.org> Message-ID: I just upgraded to OpenSSH3.2.3p1 as it seemed that UsePrivilegeSeparation yes might help with my problem (connections forwarded are owned by root instead of the user I logged in as on the server), but instead, sshd barfs on receiving a connection. Without UsePrivilegeSeparation the server works fine. # strace -o /tmp/sshd.str sshd -d debug1: sshd version OpenSSH_3.2.3p1 debug1: private host key: #0 type 0 RSA1 debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 202.42.176.138 port 2483 debug1: Client protocol version 2.0; client software version 3.3.1 SecureCRT debug1: no match: 3.3.1 SecureCRT Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_3.2.3p1 mmap(65536) debug1: Calling cleanup 0x806a470(0x0) root at matjes:/usr/local/etc Here is the tail of the strace: write(2, "debug1: Client protocol version "..., 78) = 78 write(2, "debug1: no match: 3.3.1 SecureCR"..., 35) = 35 write(2, "Enabling compatibility mode for "..., 46) = 46 write(2, "debug1: Local version string SSH"..., 55) = 55 fcntl(5, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 socketpair(PF_UNIX, SOCK_STREAM, , 0, [4, 8]) = 0 fcntl(4, F_SETFD, FD_CLOEXEC) = 0 fcntl(8, F_SETFD, FD_CLOEXEC) = 0 mmap(0, 65536, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0) = -1 EINVAL (Invalid argument) write(2, "mmap(65536)\r\n", 13) = 13 write(2, "debug1: Calling cleanup 0x806a47"..., 40) = 40 shutdown(5, 2 /* send and receive */) = 0 close(5) = 0 _exit(255) = ? The kernel is a somewhat older Linux 2.2.13. regards From jason at ncac.gwu.edu Tue May 28 14:33:25 2002 From: jason at ncac.gwu.edu (Jason Mader) Date: Tue, 28 May 2002 00:33:25 -0400 Subject: Build problem on IRIX 6.5.16m Message-ID: <0D1DB3A6-71F4-11D6-8C46-000393751136@ncac.gwu.edu> I had a problem building OpenSSH 3.2.3p1 on IRIX 6.5.16m. The configure command I used was: env CC=cc ./configure --prefix=/usr --sysconfdir=/etc/ssh --libexecdir=/usr/lib \ --mandir=/usr/share/man/u_man --with-catman=man --without-rsh \ --with-xauth=/usr/bin/X11/xauth --with-ssl- dir=../openssl-0.9.6d \ --with-prngd-socket=/dev/egd-pool The errors during make are: (cd openbsd-compat && make) cc -g -I. -I. -I../openssl-0.9.6d/include -I/usr/local/include -DSSHDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/lib/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/lib/sftp-server\" -D_PATH_SSH_PIDDIR=\"/etc/ssh\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/lib/ssh-rand-helper\" -DHAVE_CONFIG_H -c monitor_fdpass.c cc-1020 cc: ERROR File = monitor_fdpass.c, Line = 58 The identifier "SCM_RIGHTS" is undefined. cmsg->cmsg_type = SCM_RIGHTS; ^ cc-1020 cc: ERROR File = monitor_fdpass.c, Line = 117 The identifier "SCM_RIGHTS" is undefined. if (cmsg->cmsg_type != SCM_RIGHTS) ^ 2 errors detected in the compilation of "monitor_fdpass.c". *** Error code 2 (bu21) -- Jason Mader \\ jason at ncac.gwu.edu // 703-726-8373 From bugzilla-daemon at mindrot.org Tue May 28 14:41:45 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 28 May 2002 14:41:45 +1000 (EST) Subject: [Bug 257] sftp and 32 bit integar Message-ID: <20020528044145.5D650E9DE@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From liug at mama.indstate.edu 2002-05-28 14:41 ------- here is the sftp -vvv output: sftp> dir debug3: Sending SSH2_FXP_READDIR I:3 debug1: client_input_channel_req: channel 0 rtype exit-signal reply 0 debug1: channel 0: rcvd eof debug1: channel 0: output open -> drain debug1: channel 0: obuf empty debug1: channel 0: close_write debug1: channel 0: output drain -> closed debug1: channel 0: rcvd close debug1: channel 0: close_read debug1: channel 0: input open -> closed debug3: channel 0: will not send data after close debug1: channel 0: almost dead debug1: channel 0: gc: notify user debug1: channel 0: gc: user detached debug1: channel 0: send close debug1: channel 0: is dead debug1: channel 0: garbage collecting debug1: channel_free: channel 0: client-session, nchannels 1 debug3: channel_free: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1) debug3: channel_close_fds: channel 0: r -1 w -1 e 6 debug1: fd 0 clearing O_NONBLOCK debug2: fd 1 is not O_NONBLOCK debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 20.9 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status -1 Connection closed ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From janfrode at parallab.uib.no Tue May 28 16:48:04 2002 From: janfrode at parallab.uib.no (Jan-Frode Myklebust) Date: Tue, 28 May 2002 08:48:04 +0200 Subject: Build problem on IRIX 6.5.16m In-Reply-To: <0D1DB3A6-71F4-11D6-8C46-000393751136@ncac.gwu.edu> References: <0D1DB3A6-71F4-11D6-8C46-000393751136@ncac.gwu.edu> Message-ID: <20020528064804.GA3410@ii.uib.no> On Tue, May 28, 2002 at 12:33:25AM -0400, Jason Mader wrote: > I had a problem building OpenSSH 3.2.3p1 on IRIX 6.5.16m. > > > The identifier "SCM_RIGHTS" is undefined. > > cmsg->cmsg_type = SCM_RIGHTS; > ^ > > cc-1020 cc: ERROR File = monitor_fdpass.c, Line = 117 > The identifier "SCM_RIGHTS" is undefined. > > if (cmsg->cmsg_type != SCM_RIGHTS) > ^ I just had the same problem on 3.2.2p1, and the fix was to comment out '#define HAVE_CONTROL_IN_MSGHDR 1' from config.h. Tim Rice just committed a fix to the CVS tree, so that it should be fixed in the next release. -jf From bugzilla-daemon at mindrot.org Tue May 28 18:09:41 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 28 May 2002 18:09:41 +1000 (EST) Subject: [Bug 164] X-forwarding when connecting to an IPv6-enabled host doesn't work. Message-ID: <20020528080941.CB163E904@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=164 ------- Additional Comments From pekkas at netcore.fi 2002-05-28 18:09 ------- It would be nice to get this fixed... :-) (NOTE: I don't think all that many OS's support IPV6_V6ONLY setsockopt, but that's a separate issue.) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue May 28 20:59:26 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 28 May 2002 20:59:26 +1000 (EST) Subject: [Bug 245] SSH can not log out under Solaris 2.6 Message-ID: <20020528105926.68972E8FF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=245 ------- Additional Comments From pitu at caipy.de 2002-05-28 20:59 ------- Hi there, additional informations: I installed openssh3.2.2p1 under Solaris 2.6 with the following solution I found in the mailinglist (I wonder that the same error is still in it ...) #define _FILE_OFFSET_BITS 64 (This is already in) #define _LARGEFILE64_SOURCE (This I added) into config.h. So I got also the message that is meantioned from tcsh, it apears when starting a new shell. "Warning: no access to tty (Inappropriate ioctl for device). Thus no job control in this shell." But also I got a similar message when starting bash instead: "bash: no job control in this shell" So if one already applied the patch please check this behavior? greetings, pitu ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From fabricehalimi at aol.com Tue May 28 21:27:18 2002 From: fabricehalimi at aol.com (VOTRE SITE ...) Date: Tue, 28 May 2002 13:27:18 +0200 Subject: LA ROLLS DES SITES POUR 750 EUROS H.T. AVEC SON INTERFACE DE MISE A JOUR Message-ID: <200205281129.g4SBTb850585@postoffice.telstra.net> An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020528/7184314f/attachment.html From bugzilla-daemon at mindrot.org Tue May 28 21:32:08 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 28 May 2002 21:32:08 +1000 (EST) Subject: [Bug 259] New: UsePrivilegeSeparation crashed sshd under Linux 2.2 Message-ID: <20020528113208.0BEF9E927@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=259 Summary: UsePrivilegeSeparation crashed sshd under Linux 2.2 Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: mathias at koerber.org I just upgraded to OpenSSH3.2.3p1 as it seemed that UsePrivilegeSeparation yes might help with my problem (connections forwarded are owned by root instead of the user I logged in as on the server), but instead, sshd barfs on receiving a connection. Without UsePrivilegeSeparation the server works fine. # strace -o /tmp/sshd.str sshd -d debug1: sshd version OpenSSH_3.2.3p1 debug1: private host key: #0 type 0 RSA1 debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 202.42.176.138 port 2483 debug1: Client protocol version 2.0; client software version 3.3.1 SecureCRT debug1: no match: 3.3.1 SecureCRT Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_3.2.3p1 mmap(65536) debug1: Calling cleanup 0x806a470(0x0) root at matjes:/usr/local/etc Here is the tail of the strace: write(2, "debug1: Client protocol version "..., 78) = 78 write(2, "debug1: no match: 3.3.1 SecureCR"..., 35) = 35 write(2, "Enabling compatibility mode for "..., 46) = 46 write(2, "debug1: Local version string SSH"..., 55) = 55 fcntl(5, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 socketpair(PF_UNIX, SOCK_STREAM, , 0, [4, 8]) = 0 fcntl(4, F_SETFD, FD_CLOEXEC) = 0 fcntl(8, F_SETFD, FD_CLOEXEC) = 0 mmap(0, 65536, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0) = -1 EINVAL (Invalid argument) write(2, "mmap(65536)\r\n", 13) = 13 write(2, "debug1: Calling cleanup 0x806a47"..., 40) = 40 shutdown(5, 2 /* send and receive */) = 0 close(5) = 0 _exit(255) = ? The kernel is a somewhat older Linux 2.2.13. regards ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From kiolkgj23 at lycos.co.kr Tue May 28 23:15:37 2002 From: kiolkgj23 at lycos.co.kr (��ȣ��) Date: Tue, 28 May 2002 22:15:37 +0900 Subject: [��] �� ο�ȭ�� Ұ��մϴ� Message-ID: <20020528131621.669E9E90D@shitei.mindrot.org> An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020528/c9093cf2/attachment.html From trebula at ui42.com Wed May 29 00:59:56 2002 From: trebula at ui42.com (Robert Trebula) Date: Tue, 28 May 2002 16:59:56 +0200 Subject: 'Corrupted check bytes on input' when connecting to 1.2.30 server Message-ID: <20020528145956.GD14527@mail.ui42.sk> Hello, I get this error when trying to connect to an ancient server from the 3.2.3p1 client on Linux 2.2 (OpenSSL 0.9.5): [root at XXX openssh-3.2.3p1]# /usr/local/bin/ssh -vv LOGIN_STRIPPED at decef.elf.stuba.sk OpenSSH_3.2.3p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 0 geteuid 0 anon 1 debug1: Connecting to decef.elf.stuba.sk [147.175.111.11] port 22. debug1: temporarily_use_uid: 0/0 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 0/0 (e=0) debug1: restore_uid debug1: Connection established. debug1: read PEM private key done: type DSA debug1: read PEM private key done: type RSA debug1: identity file /root/.ssh/identity type -1 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: Remote protocol version 1.5, remote software version 1.2.30 debug1: match: 1.2.30 pat 1.2.1*,1.2.2*,1.2.3* debug1: Local version string SSH-1.5-OpenSSH_3.2.3p1 debug1: Waiting for server public key. debug1: Received server public key (768 bits) and host key (1024 bits). debug1: Host 'decef.elf.stuba.sk' is known and matches the RSA1 host key. debug1: Found key in /root/.ssh/known_hosts:31 debug1: Encryption type: blowfish debug1: Sent encrypted session key. debug1: Installing crc compensation attack detector. Disconnecting: Corrupted check bytes on input. debug1: Calling cleanup 0x8064d54(0x0) The machine name real, it is FreeBSD 4.1.1-RELEASE, host in my school. I guess you can try it yourself there. Robert -- Bc. Robert TREBULA ui42 spol. s r.o. Hrdlickova 16, 831 01 Bratislava, Slovakia tel.: (+421) 2 5479 3646 mailto:trebula at ui42.sk http://www.ui42.com From mouring at etoh.eviladmin.org Wed May 29 02:05:52 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 28 May 2002 11:05:52 -0500 (CDT) Subject: Problems with UsePrivilegeSeparation (was: port fwd as user != root? In-Reply-To: Message-ID: You do have a user called 'sshd' in your /etc/passwd right? - Ben On Tue, 28 May 2002, Mathias Koerber wrote: > I just upgraded to OpenSSH3.2.3p1 as it seemed that > UsePrivilegeSeparation yes > might help with my problem (connections forwarded > are owned by root instead of the user I logged in as > on the server), but instead, sshd barfs on receiving > a connection. Without UsePrivilegeSeparation > the server works fine. > > > # strace -o /tmp/sshd.str sshd -d > debug1: sshd version OpenSSH_3.2.3p1 > debug1: private host key: #0 type 0 RSA1 > debug1: read PEM private key done: type RSA > debug1: private host key: #1 type 1 RSA > debug1: read PEM private key done: type DSA > debug1: private host key: #2 type 2 DSA > debug1: Bind to port 22 on 0.0.0.0. > Server listening on 0.0.0.0 port 22. > Generating 768 bit RSA key. > RSA key generation complete. > debug1: Server will not fork when running in debugging mode. > Connection from 202.42.176.138 port 2483 > debug1: Client protocol version 2.0; client software version 3.3.1 SecureCRT > debug1: no match: 3.3.1 SecureCRT > Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-1.99-OpenSSH_3.2.3p1 > mmap(65536) > debug1: Calling cleanup 0x806a470(0x0) > root at matjes:/usr/local/etc > > > Here is the tail of the strace: > > write(2, "debug1: Client protocol version "..., 78) = 78 > write(2, "debug1: no match: 3.3.1 SecureCR"..., 35) = 35 > write(2, "Enabling compatibility mode for "..., 46) = 46 > write(2, "debug1: Local version string SSH"..., 55) = 55 > fcntl(5, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 > socketpair(PF_UNIX, SOCK_STREAM, , 0, [4, 8]) = 0 > fcntl(4, F_SETFD, FD_CLOEXEC) = 0 > fcntl(8, F_SETFD, FD_CLOEXEC) = 0 > mmap(0, 65536, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0) = -1 > EINVAL (Invalid argument) > write(2, "mmap(65536)\r\n", 13) = 13 > write(2, "debug1: Calling cleanup 0x806a47"..., 40) = 40 > shutdown(5, 2 /* send and receive */) = 0 > close(5) = 0 > _exit(255) = ? > > > The kernel is a somewhat older Linux 2.2.13. > > regards > > From markus at openbsd.org Wed May 29 02:13:45 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 28 May 2002 18:13:45 +0200 Subject: 'Corrupted check bytes on input' when connecting to 1.2.30 server In-Reply-To: <20020528145956.GD14527@mail.ui42.sk> References: <20020528145956.GD14527@mail.ui42.sk> Message-ID: <20020528161345.GA28595@folly> On Tue, May 28, 2002 at 04:59:56PM +0200, Robert Trebula wrote: > I get this error when trying to connect to an ancient server from the 3.2.3p1 > client on Linux 2.2 (OpenSSL 0.9.5): > OpenSSH_3.2.3p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f > debug1: Encryption type: blowfish openssl < 0.9.6 + ssh1 + blowfish is currently broken, please try -c 3des or upgrade openssl (or make openssh work with openssl 0.9.5 :)) -m From kevin at atomicgears.com Wed May 29 02:40:08 2002 From: kevin at atomicgears.com (Kevin Steves) Date: Tue, 28 May 2002 09:40:08 -0700 Subject: Problems with UsePrivilegeSeparation (was: port fwd as user != root? In-Reply-To: References: <161450000.1022379830@noisy.koerber.org> Message-ID: <20020528164008.GB1575@jenny.crlsca.adelphia.net> On Tue, May 28, 2002 at 11:55:26AM +0800, Mathias Koerber wrote: > mmap(0, 65536, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0) = -1 > EINVAL (Invalid argument) > > The kernel is a somewhat older Linux 2.2.13. i don't know. what can cause EINVAL from that mmap() call? From josh-openssh at untruth.org Wed May 29 03:49:23 2002 From: josh-openssh at untruth.org (Joshua Hill) Date: Tue, 28 May 2002 10:49:23 -0700 Subject: Problems with UsePrivilegeSeparation (was: port fwd as user != root? In-Reply-To: ; from mathias@koerber.org on Tue, May 28, 2002 at 11:55:26AM +0800 References: <161450000.1022379830@noisy.koerber.org> Message-ID: <20020528104923.A13529@delusion.private.untruth.org> On Tue, May 28, 2002 at 11:55:26AM +0800, Mathias Koerber wrote: > I just upgraded to OpenSSH3.2.3p1 [snip] > Without UsePrivilegeSeparation > the server works fine. [snip] > mmap(65536) [snip] > mmap(0, 65536, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0) = -1 > EINVAL (Invalid argument) > write(2, "mmap(65536)\r\n", 13) = 13 [snip] > The kernel is a somewhat older Linux 2.2.13. [snip] Herein lies your problem. The flag combination (MAP_SHARED|MAP_ANONYMOUS) is not supported in the linux 2.2 kernels. Searching the linux-mm list archives reveals that this can't be trivially added due the linux-2.2 VM's assumption that all swap cache pages are read-only; see the linux-mm thread that starts at http://mail.nl.linux.org/linux-mm/1999-01/msg00034.html for some proposals for adding shared anonymous mappings to the linux 2.2 VM that didn't quite work out The linux-2.4 VM supports shared anonymous mappings. I'm not prepared to move my production boxes to a 2.4 kernel, and it would seem that adding shared anonymous mappings to the v2.2 VM is not a trivial matter. All this being said, I'm really interested in using the Privilege Separation feature of OpenSSH. As such, I'm going to try to add SYSV IPC SHM support to openssh... Unless someone else beats me to it, of course. :-) Josh From mouring at etoh.eviladmin.org Wed May 29 04:23:32 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 28 May 2002 13:23:32 -0500 (CDT) Subject: Problems with UsePrivilegeSeparation (was: port fwd as user != root? In-Reply-To: <20020528104923.A13529@delusion.private.untruth.org> Message-ID: On Tue, 28 May 2002, Joshua Hill wrote: [..] > > Herein lies your problem. > > The flag combination (MAP_SHARED|MAP_ANONYMOUS) is not supported in > the linux 2.2 kernels. Searching the linux-mm list archives reveals > that this can't be trivially added due the linux-2.2 VM's assumption > that all swap cache pages are read-only; see the linux-mm thread that > starts at http://mail.nl.linux.org/linux-mm/1999-01/msg00034.html for > some proposals for adding shared anonymous mappings to the linux 2.2 VM > that didn't quite work out > > The linux-2.4 VM supports shared anonymous mappings. I'm not prepared > to move my production boxes to a 2.4 kernel, and it would seem that > adding shared anonymous mappings to the v2.2 VM is not a trivial matter. > All this being said, I'm really interested in using the Privilege > Separation feature of OpenSSH. As such, I'm going to try to add SYSV > IPC SHM support to openssh... Unless someone else beats me to it, of > course. :-) > There are too many issues in regards to SysV Shared Memory. It leaks at best and is corrupted at worse. Even under Solaris (I have too many UNIFY 'databases' roaming around that step all over SysV Memory. It's a horrible design). The mmap() is only required is you wish to have compression support in the server. Looking at our current code base I see we have not merged what is needed to handle lack of mmap() yet. You may want to focus our energy on a patch that would kill two birds with one stone. The the lack mmap() (on cray and other OSes) and your issues by allowing the admin to disable compression at runtime. This would allow for a lot more platform support. - Ben From jdennis at law.harvard.edu Wed May 29 04:57:29 2002 From: jdennis at law.harvard.edu (James Dennis) Date: Tue, 28 May 2002 14:57:29 -0400 Subject: chroot patch In-Reply-To: References: Message-ID: <20020528145729.34d1a87b.jdennis@law.harvard.edu> Hello everyone, In response to emails such as the one below I have started a sourceforge site for this patch. If your chuckling to yourself at the thought of a sourceforge site over a patch, well, I did too when I first thought of it. I don't have the bandwidth requirements at home to host it and Harvard Law School doesn't want to host the patch for me either. Please check out http://chrootssh.sourceforge.net I have some very basic documentation online, but it should give a general idea of how to use it. I'd love suggestions or anything else you feel the site lacks. Seeing as the patches are quite easy to make my main goal for the site is to provide enough documentation that I can continue to update the patches and users and can download them and follow the documentation to set it up (and because classes will be taking up time I'd otherwise use to answer questions). Please try not to overwhelm me. :) -James PS. I'm expecting to be overwhelmed with this as I usally am, with replies so please try to make your questions "good questions" and try my documentation first. :) On Tue, 28 May 2002 13:31:23 -0500 hutch at brandonhutchinson.com wrote: > Hello James! > > I noticed a post of yours for an OpenSSH chroot patch, but I do not seem > to be able to find your updated patch in the message you sent. > > Here is the referenced post: > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=102199576913629&w=2 > > Would it be possible to post the patch to the newsgroup or send it to me > as an attachment? I would greatly appreciate it, as I'm trying to get > chrooted SFTP going in my environment. > > Thanks! > > Brandon > > > From tim at multitalents.net Wed May 29 06:39:45 2002 From: tim at multitalents.net (Tim Rice) Date: Tue, 28 May 2002 13:39:45 -0700 (PDT) Subject: Problems with UsePrivilegeSeparation (was: port fwd as user != root? In-Reply-To: Message-ID: Please try the attached patch. It tests for a working mmap that supports MAP_ANONYMOUS. You'll need autoconf 2.52 installed Run autoreconf after applying the patch. If you don't have autoconf 2.52 installed, grab the new configure from http://www.multitalents.net/openssh/configure-map-anon.gz or ftp://ftp.multitalents.net/pub/openssh/configure-map-anon.gz and add the following line to config.h.in #undef HAVE_MMAP On Tue, 28 May 2002, Mathias Koerber wrote: > I just upgraded to OpenSSH3.2.3p1 as it seemed that > UsePrivilegeSeparation yes > might help with my problem (connections forwarded > are owned by root instead of the user I logged in as > on the server), but instead, sshd barfs on receiving > a connection. Without UsePrivilegeSeparation > the server works fine. [snip] > mmap(0, 65536, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0) = -1 > EINVAL (Invalid argument) > write(2, "mmap(65536)\r\n", 13) = 13 > write(2, "debug1: Calling cleanup 0x806a47"..., 40) = 40 > shutdown(5, 2 /* send and receive */) = 0 > close(5) = 0 > _exit(255) = ? > > > The kernel is a somewhat older Linux 2.2.13. > > regards -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- openssh/acconfig.h.old Sun May 12 20:25:01 2002 +++ openssh/acconfig.h Tue May 28 12:36:48 2002 @@ -355,6 +355,9 @@ /* Path that unprivileged child will chroot() to in privep mode */ #undef PRIVSEP_PATH +/* Define if you have the `mmap' function. with working MAP_ANONYMOUS */ +#undef HAVE_MMAP + @BOTTOM@ /* ******************* Shouldn't need to edit below this line ************** */ --- openssh/configure.ac.old Mon May 27 17:37:33 2002 +++ openssh/configure.ac Tue May 28 12:26:38 2002 @@ -569,12 +569,34 @@ getaddrinfo getcwd getgrouplist getnameinfo getopt \ getrlimit getrusage getttyent glob inet_aton inet_ntoa \ inet_ntop innetgr login_getcapbool md5_crypt memmove \ - mkdtemp mmap ngetaddrinfo openpty ogetaddrinfo readpassphrase \ + mkdtemp ngetaddrinfo openpty ogetaddrinfo readpassphrase \ realpath recvmsg rresvport_af sendmsg setdtablesize setegid \ setenv seteuid setlogin setproctitle setresgid setreuid setrlimit \ setsid setvbuf sigaction sigvec snprintf socketpair strerror \ strlcat strlcpy strmode strsep sysconf tcgetpgrp truncate utimes \ vhangup vsnprintf waitpid __b64_ntop _getpty) + +AC_MSG_CHECKING([for mmap with working MAP_ANONYMOUS]) +AC_TRY_RUN( + [ +#include +#include +#if !defined(MAP_ANON) && defined(MAP_ANONYMOUS) +#define MAP_ANON MAP_ANONYMOUS +#endif +main() { void *address; +address = mmap(NULL, 10, PROT_WRITE|PROT_READ, MAP_ANON|MAP_SHARED, -1, 0); +if (address == MAP_FAILED) + exit(1); +exit(0); +} + ], + [ + AC_MSG_RESULT(yes) + AC_DEFINE(HAVE_MMAP) + ], + [ AC_MSG_RESULT(no) ] +) dnl IRIX and Solaris 2.5.1 have dirname() in libgen AC_CHECK_FUNCS(dirname, [AC_CHECK_HEADERS(libgen.h)] ,[ From tim at multitalents.net Wed May 29 07:22:41 2002 From: tim at multitalents.net (Tim Rice) Date: Tue, 28 May 2002 14:22:41 -0700 (PDT) Subject: Problems with UsePrivilegeSeparation (was: port fwd as user != root? In-Reply-To: Message-ID: On Tue, 28 May 2002, Ben Lindstrom wrote: > On Tue, 28 May 2002, Joshua Hill wrote: > > [..] > > > > Herein lies your problem. > > > > The flag combination (MAP_SHARED|MAP_ANONYMOUS) is not supported in > > the linux 2.2 kernels. Searching the linux-mm list archives reveals > > that this can't be trivially added due the linux-2.2 VM's assumption > > that all swap cache pages are read-only; see the linux-mm thread that > > starts at http://mail.nl.linux.org/linux-mm/1999-01/msg00034.html for > > some proposals for adding shared anonymous mappings to the linux 2.2 VM > > that didn't quite work out > > There are too many issues in regards to SysV Shared Memory. It leaks at > best and is corrupted at worse. Even under Solaris (I have too many UNIFY > 'databases' roaming around that step all over SysV Memory. It's a > horrible design). > > The mmap() is only required is you wish to have compression support in the > server. Looking at our current code base I see we have not merged what is > needed to handle lack of mmap() yet. > > You may want to focus our energy on a patch that would kill two birds with > one stone. The the lack mmap() (on cray and other OSes) and your issues > by allowing the admin to disable compression at runtime. This would allow > for a lot more platform support. For the platforms that have mmap but don't support MAP_ANON we can do something like this. --- monitor_mm.c.orig Tue May 28 13:49:29 2002 +++ monitor_mm.c Tue May 28 13:53:03 2002 @@ -84,9 +84,14 @@ */ mm->mmalloc = mmalloc; -#if defined(HAVE_MMAP) && defined(MAP_ANON) +#ifdef HAVE_MMAP +#ifdef MAP_ANON address = mmap(NULL, size, PROT_WRITE|PROT_READ, MAP_ANON|MAP_SHARED, -1, 0); +#else + address = mmap(NULL, size, PROT_WRITE|PROT_READ, MAP_PRIVATE, + open("/dev/zero", O_RDWR), 0); +#endif if (address == MAP_FAILED) fatal("mmap(%lu)", (u_long)size); #else The only stumbling block is that the unprivileged child calls initgroups() and it's fatal. --------< session.c >-------- /* Initialize the group list. */ if (initgroups(pw->pw_name, pw->pw_gid) < 0) { perror("initgroups"); exit(1); } If I comment out the exit(1) call I can get privsep working on a platform that has mmap but no MAP_ANON. Any clue how to tell if we are in the unprivileged child? > > - Ben > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From austin at coremetrics.com Wed May 29 07:52:12 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 28 May 2002 16:52:12 -0500 Subject: Chroot works..but sftp chroot does not it seems. In-Reply-To: <20020528145729.34d1a87b.jdennis@law.harvard.edu> References: <20020528145729.34d1a87b.jdennis@law.harvard.edu> Message-ID: <1022622732.2828.8.camel@UberGeek> Any tips on that? SFTP is the last thing to work. sftp-server is in the crhooted libexec. TIA. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "One ought never to turn one's back on a threatened danger and try to run away from it. If you do that, you will double the danger. But if you meet it promptly and without flinching, you will reduce the danger by half." Sir Winston Churchill -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020528/8d291c75/attachment.bin From mathias at koerber.org Wed May 29 11:22:22 2002 From: mathias at koerber.org (Mathias Koerber) Date: Wed, 29 May 2002 09:22:22 +0800 Subject: Problems with UsePrivilegeSeparation (was: port fwd as user != root? In-Reply-To: Message-ID: > You do have a user called 'sshd' in your /etc/passwd right? ah, that need is mentioned in README.privsep, but not the manpage. I suggest that the manpage be updated to mention the need for the sshd user and the /var/empty directory. I'll try again with this (and whatever other solutions I may get). thanks From mathias at koerber.org Wed May 29 13:30:38 2002 From: mathias at koerber.org (Mathias Koerber) Date: Wed, 29 May 2002 11:30:38 +0800 Subject: Problems with UsePrivilegeSeparation (was: port fwd as user != root? In-Reply-To: Message-ID: > Please try the attached patch. It tests for a working mmap that > supports MAP_ANONYMOUS. You'll need autoconf 2.52 installed > Run autoreconf after applying the patch. > > If you don't have autoconf 2.52 installed, > grab the new configure from > http://www.multitalents.net/openssh/configure-map-anon.gz > or > ftp://ftp.multitalents.net/pub/openssh/configure-map-anon.gz > and add the following line to config.h.in > #undef HAVE_MMAP That line was already there.. With the patch (against 3.2.p1), I always get this error: fatal: mm_create: UsePrivilegeSeparation=yes not supported rgds From tim at multitalents.net Wed May 29 13:35:54 2002 From: tim at multitalents.net (Tim Rice) Date: Tue, 28 May 2002 20:35:54 -0700 (PDT) Subject: Problems with UsePrivilegeSeparation (was: port fwd as user != root? In-Reply-To: Message-ID: On Wed, 29 May 2002, Mathias Koerber wrote: > > Please try the attached patch. It tests for a working mmap that > > supports MAP_ANONYMOUS. You'll need autoconf 2.52 installed > > Run autoreconf after applying the patch. > > > > If you don't have autoconf 2.52 installed, > > grab the new configure from > > http://www.multitalents.net/openssh/configure-map-anon.gz > > or > > ftp://ftp.multitalents.net/pub/openssh/configure-map-anon.gz > > and add the following line to config.h.in > > #undef HAVE_MMAP > That line was already there.. > > With the patch (against 3.2.p1), I always get this error: > > fatal: mm_create: UsePrivilegeSeparation=yes not supported So it found your mmap was not working, good. Without a working version of mmap that supports MAP_ANON, privsep is NOT supported (yet). Sorry. I'm working on it. > > rgds > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mathias at koerber.org Wed May 29 13:39:04 2002 From: mathias at koerber.org (Mathias Koerber) Date: Wed, 29 May 2002 11:39:04 +0800 Subject: Problems with UsePrivilegeSeparation (was: port fwd as user != root? In-Reply-To: Message-ID: > > fatal: mm_create: UsePrivilegeSeparation=yes not supported > > So it found your mmap was not working, good. > > Without a working version of mmap that supports MAP_ANON, > privsep is NOT supported (yet). Sorry. > I'm working on it. Thanks. Do you know whether using prisep will make port forwarding open forwarded ports as the authenticated user. Right now, local forwards will be opened on the server as root, which makes identd reports useless. This is my main purpose for using (trying) privsep.. rgds From tim at multitalents.net Wed May 29 13:41:09 2002 From: tim at multitalents.net (Tim Rice) Date: Tue, 28 May 2002 20:41:09 -0700 (PDT) Subject: Problems with UsePrivilegeSeparation (was: port fwd as user != root? In-Reply-To: Message-ID: On Wed, 29 May 2002, Mathias Koerber wrote: > > > fatal: mm_create: UsePrivilegeSeparation=yes not supported > > > > So it found your mmap was not working, good. > > > > Without a working version of mmap that supports MAP_ANON, > > privsep is NOT supported (yet). Sorry. > > I'm working on it. > > Thanks. > > Do you know whether using prisep will make port forwarding > open forwarded ports as the authenticated user. Right now, > local forwards will be opened on the server as root, which > makes identd reports useless. This is my main purpose for > using (trying) privsep.. Sorry, don't know. > > rgds > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From zacheiss at MIT.EDU Wed May 29 14:29:37 2002 From: zacheiss at MIT.EDU (Garry Zacheiss) Date: Wed, 29 May 2002 00:29:37 -0400 Subject: [PATCH] Add config option disabling drop_connection() behavior Message-ID: <200205290429.AAA26058@riff-raff.mit.edu> The patch below (against openssh 3.2.3p1) adds a CheckMaxStartups option, defaulting to yes, to determine whether sshd calls drop_connection(). The motivation behind this is twofold. In our environment, our timesharing machines get enough incoming connections that will trigger spuriously with the default value (10 forked unauthenticated connections) as well as some significantly higher values, and I'd rather disable this feature than just configure it to some ridiculously high value. A secondary motivation is that this code is sometimes triggered when the machine's AFS client has gotten into a broken state (forked sshd tries to touch AFS for user homedir, loses), and I've already had at least one coworker get dragged down the wrong debugging path and "try to debug why sshd is accepting new connections and immediately dropping them" when the real problem the machine is experiencing is different. It didn't seem like being able to selectively disable this feature would be a bad thing, so please consider this patch for inclusion in a future version of OpenSSH. I'm not currently subscribed to this list, so please cc me on any replies. Thanks in advance for your consideration. Garry --- servconf.h 2002/05/29 03:50:01 1.1 +++ servconf.h 2002/05/29 03:50:53 @@ -112,6 +112,7 @@ char *subsystem_name[MAX_SUBSYSTEMS]; char *subsystem_command[MAX_SUBSYSTEMS]; + int check_max_startups; int max_startups_begin; int max_startups_rate; int max_startups; --- servconf.c 2002/05/29 03:49:54 1.1 +++ servconf.c 2002/05/29 03:54:09 @@ -112,6 +112,7 @@ options->protocol = SSH_PROTO_UNKNOWN; options->gateway_ports = -1; options->num_subsystems = 0; + options->check_max_startups = -1; options->max_startups_begin = -1; options->max_startups_rate = -1; options->max_startups = -1; @@ -228,6 +229,8 @@ options->allow_tcp_forwarding = 1; if (options->gateway_ports == -1) options->gateway_ports = 0; + if (options->check_max_startups == -1) + options->check_max_startups = 1; if (options->max_startups == -1) options->max_startups = 10; if (options->max_startups_rate == -1) @@ -281,7 +284,8 @@ sUseLogin, sAllowTcpForwarding, sAllowUsers, sDenyUsers, sAllowGroups, sDenyGroups, sIgnoreUserKnownHosts, sCiphers, sMacs, sProtocol, sPidFile, - sGatewayPorts, sPubkeyAuthentication, sXAuthLocation, sSubsystem, sMaxStartups, + sGatewayPorts, sPubkeyAuthentication, sXAuthLocation, sSubsystem, + sCheckMaxStartups, sMaxStartups, sBanner, sVerifyReverseMapping, sHostbasedAuthentication, sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, @@ -353,6 +357,7 @@ { "protocol", sProtocol }, { "gatewayports", sGatewayPorts }, { "subsystem", sSubsystem }, + { "checkmaxstartups", sCheckMaxStartups }, { "maxstartups", sMaxStartups }, { "banner", sBanner }, { "verifyreversemapping", sVerifyReverseMapping }, @@ -835,6 +840,10 @@ options->num_subsystems++; break; + case sCheckMaxStartups: + intptr = &options->check_max_startups; + goto_parse_flag; + case sMaxStartups: arg = strdelim(&cp); if (!arg || *arg == '\0') --- sshd.8 2002/05/29 03:50:10 1.1 +++ sshd.8 2002/05/29 03:54:38 @@ -656,6 +656,11 @@ Multiple algorithms must be comma-separated. The default is .Dq hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 . +.It Cm CheckMaxStartups +Specifies whether the server should check the number of concurrent +unauthenticated connections to the daemon, and drop new incoming +connections if this number exceeds some threshold. See the +"MaxStartups" configuration option for more information. .It Cm MaxStartups Specifies the maximum number of concurrent unauthenticated connections to the .Nm --- sshd.c 2002/05/29 03:50:13 1.1 +++ sshd.c 2002/05/29 03:55:59 @@ -1243,7 +1243,8 @@ close(newsock); continue; } - if (drop_connection(startups) == 1) { + if (options.check_max_startups && + drop_connection(startups) == 1) { debug("drop connection #%d", startups); close(newsock); continue; From mouring at etoh.eviladmin.org Wed May 29 15:10:56 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 29 May 2002 00:10:56 -0500 (CDT) Subject: [PATCH] Add config option disabling drop_connection() behavior In-Reply-To: <200205290429.AAA26058@riff-raff.mit.edu> Message-ID: I'd rather see the following applied before yours. Mainly because I don't want 'Yet another Fine Option' floating arounding. Plus it touchs less code and acts the way 90% of what people expect. The more options you provide the more chances someone will fuck up. Besides this follows the KISS concept. =) - Ben [Against -current portable] Index: sshd.c =================================================================== RCS file: /var/cvs/openssh/sshd.c,v retrieving revision 1.207 diff -u -r1.207 sshd.c --- sshd.c 21 May 2002 17:59:13 -0000 1.207 +++ sshd.c 29 May 2002 05:12:07 -0000 @@ -721,6 +721,10 @@ { double p, r; + /* If Max Startup is zero, then the feature is disabled */ + if (options->max_startups == 0) + return 0; + if (startups < options.max_startups_begin) return 0; if (startups >= options.max_startups) On Wed, 29 May 2002, Garry Zacheiss wrote: > The patch below (against openssh 3.2.3p1) adds a > CheckMaxStartups option, defaulting to yes, to determine whether sshd > calls drop_connection(). > > The motivation behind this is twofold. In our environment, our > timesharing machines get enough incoming connections that will trigger > spuriously with the default value (10 forked unauthenticated > connections) as well as some significantly higher values, and I'd rather > disable this feature than just configure it to some ridiculously high > value. > > A secondary motivation is that this code is sometimes triggered > when the machine's AFS client has gotten into a broken state (forked > sshd tries to touch AFS for user homedir, loses), and I've already had > at least one coworker get dragged down the wrong debugging path and "try > to debug why sshd is accepting new connections and immediately dropping > them" when the real problem the machine is experiencing is different. > > It didn't seem like being able to selectively disable this > feature would be a bad thing, so please consider this patch for > inclusion in a future version of OpenSSH. > > I'm not currently subscribed to this list, so please cc me on > any replies. Thanks in advance for your consideration. > > Garry > > --- servconf.h 2002/05/29 03:50:01 1.1 > +++ servconf.h 2002/05/29 03:50:53 > @@ -112,6 +112,7 @@ > char *subsystem_name[MAX_SUBSYSTEMS]; > char *subsystem_command[MAX_SUBSYSTEMS]; > > + int check_max_startups; > int max_startups_begin; > int max_startups_rate; > int max_startups; > --- servconf.c 2002/05/29 03:49:54 1.1 > +++ servconf.c 2002/05/29 03:54:09 > @@ -112,6 +112,7 @@ > options->protocol = SSH_PROTO_UNKNOWN; > options->gateway_ports = -1; > options->num_subsystems = 0; > + options->check_max_startups = -1; > options->max_startups_begin = -1; > options->max_startups_rate = -1; > options->max_startups = -1; > @@ -228,6 +229,8 @@ > options->allow_tcp_forwarding = 1; > if (options->gateway_ports == -1) > options->gateway_ports = 0; > + if (options->check_max_startups == -1) > + options->check_max_startups = 1; > if (options->max_startups == -1) > options->max_startups = 10; > if (options->max_startups_rate == -1) > @@ -281,7 +284,8 @@ > sUseLogin, sAllowTcpForwarding, > sAllowUsers, sDenyUsers, sAllowGroups, sDenyGroups, > sIgnoreUserKnownHosts, sCiphers, sMacs, sProtocol, sPidFile, > - sGatewayPorts, sPubkeyAuthentication, sXAuthLocation, sSubsystem, sMaxStartups, > + sGatewayPorts, sPubkeyAuthentication, sXAuthLocation, sSubsystem, > + sCheckMaxStartups, sMaxStartups, > sBanner, sVerifyReverseMapping, sHostbasedAuthentication, > sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, > sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, > @@ -353,6 +357,7 @@ > { "protocol", sProtocol }, > { "gatewayports", sGatewayPorts }, > { "subsystem", sSubsystem }, > + { "checkmaxstartups", sCheckMaxStartups }, > { "maxstartups", sMaxStartups }, > { "banner", sBanner }, > { "verifyreversemapping", sVerifyReverseMapping }, > @@ -835,6 +840,10 @@ > options->num_subsystems++; > break; > > + case sCheckMaxStartups: > + intptr = &options->check_max_startups; > + goto_parse_flag; > + > case sMaxStartups: > arg = strdelim(&cp); > if (!arg || *arg == '\0') > --- sshd.8 2002/05/29 03:50:10 1.1 > +++ sshd.8 2002/05/29 03:54:38 > @@ -656,6 +656,11 @@ > Multiple algorithms must be comma-separated. > The default is > .Dq hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 . > +.It Cm CheckMaxStartups > +Specifies whether the server should check the number of concurrent > +unauthenticated connections to the daemon, and drop new incoming > +connections if this number exceeds some threshold. See the > +"MaxStartups" configuration option for more information. > .It Cm MaxStartups > Specifies the maximum number of concurrent unauthenticated connections to the > .Nm > --- sshd.c 2002/05/29 03:50:13 1.1 > +++ sshd.c 2002/05/29 03:55:59 > @@ -1243,7 +1243,8 @@ > close(newsock); > continue; > } > - if (drop_connection(startups) == 1) { > + if (options.check_max_startups && > + drop_connection(startups) == 1) { > debug("drop connection #%d", startups); > close(newsock); > continue; > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From markus at openbsd.org Wed May 29 16:47:07 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 29 May 2002 08:47:07 +0200 Subject: Problems with UsePrivilegeSeparation (was: port fwd as user != root? In-Reply-To: References: Message-ID: <20020529064707.GB23615@folly> On Wed, May 29, 2002 at 11:39:04AM +0800, Mathias Koerber wrote: > open forwarded ports as the authenticated user. Right now, > local forwards will be opened on the server as root, which > makes identd reports useless. identd is always useless :) but with privsep, the privileged process does not touch the network. the call to bind() will happen in the 'user' process. -m From maciej.bogucki at efigence.com Wed May 29 17:51:16 2002 From: maciej.bogucki at efigence.com (Maciej Bogucki) Date: Wed, 29 May 2002 09:51:16 +0200 Subject: New initial patch to implement partial auth with SSH2 Message-ID: <3CF48874.5050406@efigence.com> HI! I would like to introduce new patch which adds new config option "AuthOrder2" to sshd_config. I would like to say that I only modyfied the patch made by Carson Gaspar. If you want to know more about this patch see thread at: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=98577021011067&w=2 I will appreciate any feedback from you. This patch is against 3.1p1. BTW: I'd like to thank Carson Gaspar for his cool patch. Best Regards Maciej Bogucki -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-3.1p1 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020529/d0350a40/attachment.ksh From janfrode at parallab.uib.no Wed May 29 19:38:56 2002 From: janfrode at parallab.uib.no (Jan-Frode Myklebust) Date: Wed, 29 May 2002 11:38:56 +0200 Subject: AIX capabilities not set In-Reply-To: <20020514140616.GA18432@ii.uib.no> References: <20020514140616.GA18432@ii.uib.no> Message-ID: <20020529093856.GA22679@ii.uib.no> Following up on myself... On Tue, May 14, 2002 at 04:06:16PM +0200, Jan-Frode Myklebust wrote: > Hi, > > we're in the process of setting up large-page support on IBM regattas, > but for large-page support the users have to have a set of extra > capabilities (CAP_BYPASS_RAC_VMM,CAP_PROPAGATE). This are configured > on a per user basis by listing which capability each user have in > /etc/security/user. > > Unfortunately they don't get set when the users log in via OpenSSH > (3.1p1). It would be nice if someone more familiar with AIX could comment on this. It seems to me that openbsd-compat/port-aix.c is doing more work than it should to set up the user environment, but I don't know if this might be for backward compatibility. If instead of setting all limits manually via setrlimit() one were to call setpcred()/setpenv() everything should be set up correctly, including the capabilities. Here's a patch replacing the whole body of set_limits_from_userattr() with calls to these functions. Please consider applying this so that we get the full AIX environment set up. I have only tested this on AIX 5.1, and have no idea if these calls are available on earlier versions of AIX. -jf -------------- next part -------------- --- port-aix.h-original Wed May 29 11:29:00 2002 +++ port-aix.h Wed May 29 11:17:13 2002 @@ -1,7 +1,6 @@ #ifdef _AIX #ifdef HAVE_GETUSERATTR -void set_limit(char *user, char *soft, char *hard, int resource, int mult); void set_limits_from_userattr(char *user); #endif /* HAVE_GETUSERATTR */ -------------- next part -------------- --- port-aix.c-original Wed May 29 10:01:59 2002 +++ port-aix.c Wed May 29 11:27:50 2002 @@ -24,79 +24,16 @@ /* * AIX-specific login initialisation */ -void -set_limit(char *user, char *soft, char *hard, int resource, int mult) -{ - struct rlimit rlim; - int slim, hlim; - - getrlimit(resource, &rlim); - - slim = 0; - if (getuserattr(user, soft, &slim, SEC_INT) != -1) { - if (slim < 0) { - rlim.rlim_cur = RLIM_INFINITY; - } else if (slim != 0) { - /* See the wackiness below */ - if (rlim.rlim_cur == slim * mult) - slim = 0; - else - rlim.rlim_cur = slim * mult; - } - } - hlim = 0; - if (getuserattr(user, hard, &hlim, SEC_INT) != -1) { - if (hlim < 0) { - rlim.rlim_max = RLIM_INFINITY; - } else if (hlim != 0) { - rlim.rlim_max = hlim * mult; - } - } - - /* - * XXX For cpu and fsize the soft limit is set to the hard limit - * if the hard limit is left at its default value and the soft limit - * is changed from its default value, either by requesting it - * (slim == 0) or by setting it to the current default. At least - * that's how rlogind does it. If you're confused you're not alone. - * Bug or feature? AIX 4.3.1.2 - */ - if ((!strcmp(soft, "fsize") || !strcmp(soft, "cpu")) - && hlim == 0 && slim != 0) - rlim.rlim_max = rlim.rlim_cur; - /* A specified hard limit limits the soft limit */ - else if (hlim > 0 && rlim.rlim_cur > rlim.rlim_max) - rlim.rlim_cur = rlim.rlim_max; - /* A soft limit can increase a hard limit */ - else if (rlim.rlim_cur > rlim.rlim_max) - rlim.rlim_max = rlim.rlim_cur; - - if (setrlimit(resource, &rlim) != 0) - error("setrlimit(%.10s) failed: %.100s", soft, strerror(errno)); -} void set_limits_from_userattr(char *user) { - int mask; - char buf[16]; - - set_limit(user, S_UFSIZE, S_UFSIZE_HARD, RLIMIT_FSIZE, 512); - set_limit(user, S_UCPU, S_UCPU_HARD, RLIMIT_CPU, 1); - set_limit(user, S_UDATA, S_UDATA_HARD, RLIMIT_DATA, 512); - set_limit(user, S_USTACK, S_USTACK_HARD, RLIMIT_STACK, 512); - set_limit(user, S_URSS, S_URSS_HARD, RLIMIT_RSS, 512); - set_limit(user, S_UCORE, S_UCORE_HARD, RLIMIT_CORE, 512); -#if defined(S_UNOFILE) - set_limit(user, S_UNOFILE, S_UNOFILE_HARD, RLIMIT_NOFILE, 1); -#endif - - if (getuserattr(user, S_UMASK, &mask, SEC_INT) != -1) { - /* Convert decimal to octal */ - (void) snprintf(buf, sizeof(buf), "%d", mask); - if (sscanf(buf, "%o", &mask) == 1) - umask(mask); - } + /* + Set up the process credentials and process environment + based on the AIX userdatabase. + */ + setpcred (user); + setpenv (user); } #endif /* defined(HAVE_GETUSERATTR) */ From mathias at koerber.org Wed May 29 19:52:48 2002 From: mathias at koerber.org (Mathias Koerber) Date: Wed, 29 May 2002 17:52:48 +0800 Subject: Problems with UsePrivilegeSeparation (was: port fwd as user != root? In-Reply-To: <20020529064707.GB23615@folly> References: <20020529064707.GB23615@folly> Message-ID: <32180000.1022665968@noisy.koerber.org> > identd is always useless :) Not so. identd is helpful for the onerunning it (and knowing it's correct) to track down problems connections (and or their users). It's useless for the remote end to base their decisions on, as they won't know whether the replies are faked or not.. But some sites allocate privileged based on it (in particular,one IRC server will not allow connections from a socket owned by 'root', which is currently my problem). > but with privsep, the privileged process does not > touch the network. the call to bind() will happen > in the 'user' process. That should help me.. thanks From jdennis at law.harvard.edu Wed May 29 23:20:10 2002 From: jdennis at law.harvard.edu (James Dennis) Date: Wed, 29 May 2002 09:20:10 -0400 Subject: Chroot works..but sftp chroot does not it seems. In-Reply-To: <1022622732.2828.8.camel@UberGeek> References: <20020528145729.34d1a87b.jdennis@law.harvard.edu> <1022622732.2828.8.camel@UberGeek> Message-ID: <20020529092010.6ae52ad5.jdennis@law.harvard.edu> It might be worth checking to make sure any libs sftp-server was compiled against are also in the chroot. You can use ldd or pull some funny magic with shell scripting to strace sftp-server. -James On Tue, 28 May 2002 16:52:12 -0500 austin at coremetrics.com wrote: > Any tips on that? SFTP is the last thing to work. sftp-server is in the > crhooted libexec. TIA. > > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin at coremetrics.com > > "One ought never to turn one's back on a threatened danger and > try to run away from it. If you do that, you will double the danger. > But if you meet it promptly and without flinching, you will > reduce the danger by half." > Sir Winston Churchill > From jm.poure at freesurf.fr Thu May 30 02:43:51 2002 From: jm.poure at freesurf.fr (Jean-Michel POURE) Date: Wed, 29 May 2002 18:43:51 +0200 Subject: chroot patch In-Reply-To: <20020528145729.34d1a87b.jdennis@law.harvard.edu> References: <20020528145729.34d1a87b.jdennis@law.harvard.edu> Message-ID: <200205291843.51132.jm.poure@freesurf.fr> Le Mardi 28 Mai 2002 20:57, James Dennis a ?crit : > Hello everyone, > In response to emails such as the one below I have started a sourceforge > site for this patch. If your chuckling to yourself at the thought of a > sourceforge site over a patch, well, I did too when I first thought of it. > I don't have the bandwidth requirements at home to host it and Harvard Law > School doesn't want to host the patch for me either. Please check out > http://chrootssh.sourceforge.net > I have some very basic documentation online, but it should give a general > idea of how to use it. I'd love suggestions or anything else you feel the > site lacks. Seeing as the patches are quite easy to make my main goal for > the site is to provide enough documentation that I can continue to update > the patches and users and can download them and follow the documentation to > set it up (and because classes will be taking up time I'd otherwise use to > answer questions). Please try not to overwhelm me. :) > -James > PS. I'm expecting to be overwhelmed with this as I usally am, with replies > so please try to make your questions "good questions" and try my > documentation first. :) Hi James, I can hardly read the html pages because of their colours. Apart from that, I would love to apply the patch to existing OpenSSH rpms for Mandrake and RedHat. OpenSSH needs a chroot patch. Cheers, Jean-Michel POURE From tim at multitalents.net Thu May 30 04:14:13 2002 From: tim at multitalents.net (Tim Rice) Date: Wed, 29 May 2002 11:14:13 -0700 (PDT) Subject: privsep patch, Please test In-Reply-To: Message-ID: Please try the attached patch. It adds support for platforms that have mmap() but do not support MAP_ANONYMOUS. You'll need autoconf 2.52 installed Run autoreconf after applying the patch. If you don't have autoconf 2.52 installed, grab the new configure from http://www.multitalents.net/openssh/configure-privsep.gz or ftp://ftp.multitalents.net/pub/openssh/configure-privsep.gz and add the following line to config.h.in #undef HAVE_WORKING_MAP_ANONYMOUS It works on UnixWare 2.1.3, Caldera eDesktop 2.4 (2.2.14 kernel), and Solaris 7. (In addition to the platforms that worked before) It doesn't work with SCO yet. A problem with recvmsg in mm_receive_fd() -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- openssh/acconfig.h.old Sun May 12 20:25:01 2002 +++ openssh/acconfig.h Wed May 29 08:15:21 2002 @@ -355,6 +355,9 @@ /* Path that unprivileged child will chroot() to in privep mode */ #undef PRIVSEP_PATH +/* Define if you have the `mmap' function. with working MAP_ANONYMOUS */ +#undef HAVE_WORKING_MAP_ANONYMOUS + @BOTTOM@ /* ******************* Shouldn't need to edit below this line ************** */ --- openssh/configure.ac.old Mon May 27 17:37:33 2002 +++ openssh/configure.ac Wed May 29 08:17:13 2002 @@ -576,6 +576,28 @@ strlcat strlcpy strmode strsep sysconf tcgetpgrp truncate utimes \ vhangup vsnprintf waitpid __b64_ntop _getpty) +AC_MSG_CHECKING([for mmap with working MAP_ANONYMOUS]) +AC_TRY_RUN( + [ +#include +#include +#if !defined(MAP_ANON) && defined(MAP_ANONYMOUS) +#define MAP_ANON MAP_ANONYMOUS +#endif +main() { void *address; +address = mmap(NULL, 10, PROT_WRITE|PROT_READ, MAP_ANON|MAP_SHARED, -1, 0); +if (address == MAP_FAILED) + exit(1); +exit(0); +} + ], + [ + AC_MSG_RESULT(yes) + AC_DEFINE(HAVE_WORKING_MAP_ANONYMOUS) + ], + [ AC_MSG_RESULT(no) ] +) + dnl IRIX and Solaris 2.5.1 have dirname() in libgen AC_CHECK_FUNCS(dirname, [AC_CHECK_HEADERS(libgen.h)] ,[ AC_CHECK_LIB(gen, dirname,[ --- openssh/monitor_mm.c.old Fri Apr 12 17:49:51 2002 +++ openssh/monitor_mm.c Wed May 29 08:22:54 2002 @@ -84,9 +84,14 @@ */ mm->mmalloc = mmalloc; -#if defined(HAVE_MMAP) && defined(MAP_ANON) +#ifdef HAVE_MMAP +#ifdef HAVE_WORKING_MAP_ANONYMOUS address = mmap(NULL, size, PROT_WRITE|PROT_READ, MAP_ANON|MAP_SHARED, -1, 0); +#else + address = mmap(NULL, size, PROT_WRITE|PROT_READ, MAP_PRIVATE, + open("/dev/zero", O_RDWR), 0); +#endif if (address == MAP_FAILED) fatal("mmap(%lu)", (u_long)size); #else --- openssh/session.c.old Sun May 12 20:25:02 2002 +++ openssh/session.c Wed May 29 07:39:22 2002 @@ -1089,10 +1089,11 @@ exit(1); } /* Initialize the group list. */ - if (initgroups(pw->pw_name, pw->pw_gid) < 0) { - perror("initgroups"); - exit(1); - } + if (strcmp(pw->pw_name, SSH_PRIVSEP_USER)) + if (initgroups(pw->pw_name, pw->pw_gid) < 0) { + perror("initgroups"); + exit(1); + } endgrent(); # ifdef USE_PAM /* From foster at dim.ucsd.edu Thu May 30 08:09:28 2002 From: foster at dim.ucsd.edu (David Foster) Date: Wed, 29 May 2002 15:09:28 -0700 (PDT) Subject: OpenSSH 3.2.3p1 won't compile under IRIX 6.5.14 Message-ID: <200205292209.g4TM9Sw23327@dim.ucsd.edu> Previously 3.2.2 would not compile under Solaris, then 3.2.3 came out with a bug fix for the problem. Now 3.2.3 won't compile under IRIX 6.5.14. I've tried using both gcc 3.0.1 and the IRIX MIPSpro 7.1 compilers. I've been compiling previous versions of OpenSSH for years using these same compilers (we haven't updated the MIPSpro compiler for 3 years, and I've been using it on the IRIX platform exclusively), so I think something broke in 3.2.3. Here's what I get (cc): cc -g -I. -I. -I/usr/local/lib -I/usr/local/lib -I/usr/local/include -DSSHDIR=\"/etc/openssh\" -D_PATH_SSH_PROGRAM=\"/usr/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/etc/openssh\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c monitor_fdpass.c cc-1020 cc: ERROR File = monitor_fdpass.c, Line = 58 The identifier "SCM_RIGHTS" is undefined. cmsg->cmsg_type = SCM_RIGHTS; ^ cc-1020 cc: ERROR File = monitor_fdpass.c, Line = 117 The identifier "SCM_RIGHTS" is undefined. if (cmsg->cmsg_type != SCM_RIGHTS) ^ 2 errors detected in the compilation of "monitor_fdpass.c". *** Error code 2 (bu21) And from gcc: gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/usr/local/lib -I/usr/local/lib -I/usr/local/include -DSSHDIR=\"/etc/openssh\" -D_PATH_SSH_PROGRAM=\"/usr/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/etc/openssh\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c monitor_fdpass.c monitor_fdpass.c: In function `mm_send_fd': monitor_fdpass.c:58: `SCM_RIGHTS' undeclared (first use in this function) monitor_fdpass.c:58: (Each undeclared identifier is reported only once monitor_fdpass.c:58: for each function it appears in.) monitor_fdpass.c: In function `mm_receive_fd': monitor_fdpass.c:117: `SCM_RIGHTS' undeclared (first use in this function) make: *** [monitor_fdpass.o] Error 1 Dave Foster =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= David Foster National Center for Microscopy and Imaging Research Programmer/Analyst University of California, San Diego dfoster at ucsd.edu Department of Neuroscience, Mail 0608 (858) 534-7968 http://ncmir.ucsd.edu/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable." -- George Bernard Shaw From tim at multitalents.net Thu May 30 08:34:52 2002 From: tim at multitalents.net (Tim Rice) Date: Wed, 29 May 2002 15:34:52 -0700 (PDT) Subject: OpenSSH 3.2.3p1 won't compile under IRIX 6.5.14 In-Reply-To: <200205292209.g4TM9Sw23327@dim.ucsd.edu> Message-ID: